一、需求整理方面
完整詳盡的需求規格說明書會有以下好處：
1、便于與客戶溝通
盡可能地以書面形式將客戶對產品的功能需求、性能指標、技術參數記錄下來，在開發之前若需與客戶溝通，便可以產品需求規格說明書為依據與客戶溝通，看是否存在認識上和理解上的差異。必要時可請客戶簽字以表確認。
例如：趙教授相關項目是一個典型的例子，啟動之初，需求上不太明確，我們應敦促其寫好需求文檔，然后我們和其討論具體需求規格。或者引導客戶將需求逐漸表達出來，我們將規格需求整理好，發至客戶公司，讓其確認，這樣更方便促進對項目的理解，避免產生偏差，造成不必要的時間上的浪費。
2、便于開發團隊內部使用
一個描述詳細的產品性能指標說明書，便于開發人員和項目負責人對產品各項功能的認識達到統一，利于開發人員盡快理解產品的各項功能、性能，盡快開始展開工作，提高工作效率，也便于其他相關產品開發人員理解產品的性能。
例如：我們的鑰匙產品，功能雖然不是特別復雜，但是初接觸鑰匙時，可能會對各種鑰匙的功能、特性、用途以及名稱產生疑惑，如果事先有各種鑰匙各項功能以及用途的詳細說明，以及各種鑰匙之間都有哪些聯系的詳細說明，可能更便于開發人員對產品的理解，盡快開始相關工作。
3、便于后期產品的測試和形成說明書
有了產品需求說明書，也就有了產品的各項功能指標，略加修改，就可以成為指導測試人員進行測試各項功能、性能的依據。也可以略加修改成為產品的說明書，便于客戶閱讀。
二、開發與文檔
1、文檔的完整性
文檔描述盡量做到完整、充分、易于理解，對于協議文檔最好每個協議命令有格式方面的描述，也有示例，便于開發人員理解，開發人員拿到文檔之后，基本對文檔所描述的產品或協議理解了90%以上，這樣就能夠花盡量少的時間，就達到理解的目的。完備、描述清晰的文檔，也便于后期測試產品時核查，后期升級同類產品時也能夠用于參考。
2、軟件與文檔版本的一致性
開發人員手中的技術文檔不是最新的技術文檔，或者各個技術人員手中的技術文檔版本不同，內容略有差異，這時開發人員對于所要開發產品的性能指標或技術細節理解可能就會產生偏差，如果技術文檔中描述的技術協議不同，就會造成開發人員合作開發同類產品時，某些技術點對接不成功，經反復溝通，對照代碼與文檔，最后才發現不一致的地方。這樣就會造成工作效率的下降。
這個問題在我們的開發過程中有時也會存在，例如：GPRS產品的通訊協議與軟件程序不一致，開發期間，有時會以產品功能為準，這時就應該修改技術協議，否則，后期其他開發人員用到此產品和協議時，會非常費解，因為技術協議和產品運行結果的實際情況不一致。應該以何為準呢？雖然不會造成大的后果，但對后期的類似新產品開發、前后臺對接都會造成一些影響，影響進度和效率。
建議安裝使用版本控制軟件，并且養成及時更新文檔的好習慣。
3、代碼的重查
隨著開發產品的增多，開發經驗的積累，開發人員的水平也逐漸提高了，有時候回頭看自己以前寫的代碼，可能會發現有很多可以優化的地方，可以提高代碼的效率節省資源，另外，也可能會發現代碼中潛在的bug，一直沒有發現，這個bug可能會在某種情況下觸發，造成產品出現問題。代碼重查就是要提前發現程序中潛在的問題，及早修正。
建議把代碼重查作為我們開發人員的一個好習慣，逐漸養成。
三、建立全面完整的測試機制
在產品出廠之前，進行全面而細致的測試非常重要，不論我們的硬件產品還是軟件產品。否則到了客戶那里出現這樣那樣的問題，會造成壞的影響。
我們現在基本是每人負責一個產品，此時就需要將產品性能、技術參數、各個功能點羅列齊全，客戶有新的功能需求提出來，我們就把新增加的功能點添加到需求文檔中，同時添加到測試文檔中。如果對產品的測試流程有影響，也要對測試流程進行相應的調整，便于后期測試人員對產品進行全面的測試。
測試方面可能會存在的問題，一般是開發人員或客戶發現某一個問題之后，反饋給研發部，開發人員將產品問題修改之后，提交給測試人員測試這一功能點，若這一功能點不再出現這一問題，即大功告成。其實開發人員修改此功能之后，可能會影響其他功能，應將產品交給測試人員進行全面測試。測試人員將整體功能按照測試流程全部重新測試一遍，以保證其他功能沒有受到影響。
例如：湖南的設備曾出現的問題，有功總不等于尖峰平谷之和。以前是相等的。后來有其它問題修改之后，代碼上可能動到了這一部分，但是由于客戶要求匆忙，沒有時間讓測試人員進行全面的測試，以至于后來遺留了這個問題，當時是由后臺軟件彌補了這個問題。
測試產品應該盡量形成常態化和規范化，不久前見到有一套“客戶”編寫的短信設備測試流程圖，我們更應該對每個產品建立這樣一套的流程圖，便于測試人員測試，也便于新員工的快速掌握。否則測試步驟不同可能就得不到正確的結果。這樣的步驟也可以后期形成用戶的操作說明書。
如果沒有完整且全面的測試機制，產品的性能可能完全依賴于某個開發人員的責任心和技術水平。產品的性能就會因技術人員的狀態變化受到太大的影響。有完整且全面的測試機制的話，就可以盡早發現問題，解決問題，盡量避免在客戶使用時產生問題。
四、建立常見問題集
隨著產品的生產、使用，我們都盡力保證產品不出現問題，但再完善的測試條件和測試手段可能還是與用戶的現實環境有差別，產品出現問題也是在所難免。可能是軟件的問題，或者某一個硬件的問題，有時候這些問題存在普遍性，我們可以更改，有時候一些問題比較偶然，不太常見。另外，有時候我們內部測試人員分工可能不同。不同的測試人員測試不同種類的產品，對自己負責的產品熟悉，別人負責的產品不熟悉，當因為某測試人員另有工作安排時，他負責的產品別人可能不太熟悉，遇到問題不知該如何解決。
有時候某些問題解決不了，還要麻煩開發人員親自解決。
如果我們養成了解決了某類問題，將此類問題，匯集起來的好習慣，積少成多，分門別類的總結下來，某類產品常見的問題和解決方法就能夠匯集成冊，能夠方便測試維修人員進行測試和維修，這樣也能適當減輕開發人員的維修任務，并且提高了效率，有了積累。
例如：不久前測試短信設備，測試人員一直說短信設備有問題，發某個命令后，短信設備會死機。但在我們研發部這里一直測不出所說的問題，后來發現是跟設備電壓有關，使用備用電池，并且電壓低于 6.8V時，會出現死機的問題，而在研發部一直接的交流電，所以沒有這個問題。但是這個事情是后來才聽其他測試人員說才知道的，此前陳杰和我都不知道有此問題，雙方都測了好多遍，在測試該短信設備時，就花了一些本不該花的時間，感覺有些冤枉。如果此前有問題集，當中提到了這個問題，我想我們就不會再花費時間在上面了。
五、其他建議
1、工作的計劃性
開發工作需協調有序進行，不因某些原因（如某個開發人員忙于其他事情）而耽擱整個開發進程。
某一段時間內，各開發人員將該時間段內的工作計劃提交總工，總工可將需協調合作的項目協調好，對時間進行統籌安排。最好不要看到一件干一件，最后時間可能會拉得過長。
2、項目的總結
建立事后分析報告：在某一個項目或產品生產發布之后，對整個需求、研發、測試、生產、銷售過程的分析描述，分析各個過程中遇到的問題，解決的過程，以及該產品有哪些優點、閃光點，以總結經驗，優點以后可以繼續推廣使用，遇到的困難以及產品存在的缺陷，在以后盡量彌補和避免，以期以后可以做得更好。
最后
每遇到一個問題，我們都應當慶幸，因為現在公司規模還小，現在遇到這個問題，我們還有時間和精力去審視這個問題出現的原因，并且避免以后再出現類似的問題。以后隨著公司規模擴大，市場擴大，再出現某些問題，可能就會造成極大的惡劣影響。所以現在每次遇到問題時，無論是產品缺陷還是其他非技術性問題，我覺得這都是好事，我們目前就是要遇到問題，并解決問題，逐步建立起機制，避免類似問題的發生，逐步完善并成長。
公司已經有著自己的運行機制和方法，可能需要不斷的完善和進步，以上幾點建議只是我個人的建議和看法，希望能對我們產品的開發和生產有益處，同時希望能起到拋磚引玉的作用，讓我們大家能進行思考，完善自我，讓我們的事業蒸蒸日上。