在開發的過程中需要進行pdca的循環，下面這些流程並不是意味着做完一個才能開始下一個。一個合格的技術經理不應該循規蹈矩，在所有的產品過程中唯一不變的就是變，適應變化擁抱變化。時間因素在任何事情中都是很重要的，從市場競爭上講，先一步就是先機，從開發上講快一步就是成本降低。
產品立項：由決策人員描述大概要做個什麼產品或者實現什麼理念，大致功能有哪些，大致的目標市場和用戶。這一步可能是領導拍腦袋的發明，也可以是客戶提出來的需求。產品的決策要符合公司的決策。
可行研究：由產品經理對產品進行明確的語言描述，並從經濟、技術、法律等多方面進行可行性分析其可行性，以及決定是自己開發、外包還是外部購買後二次開發，如果可行還需要確定核心功能。這一步至少要從市場和技術兩方面進行論證。
大致計劃：確定最終的產品大致交付日期，各個里程碑的時間點，交付的產品必須包括可行性分析中的核心功能。
需求分析：定義軟件系統的全部需求，編寫《需求分析說明書》和《需求規格說明書》，最好做一個產品原型，提交評審。
技術選型：一般項目缺少這個環節，但是非常重要，影響深遠。在這裏選擇使用的開發語言等大方面，這個受公司條件影響比較大，如果和當時公司團隊語音相左，選擇困難還是很大。
團隊建設：一般也是缺少這個環節。對於初創公司或者新的團隊，這點是必須要考慮的，直接影響到產品是否能正常順利的開發完成。放在技術選型後面是因爲團隊是要爲開發產品這個目標服務。
開發計劃：每個版本的交付時間，功能點時間點和資源分配。這個計劃是需要隨着進度發展進行修正的。
架構設計：由架構師或高級程序員搭建軟件的架構，一般基於權限管理，好架構具有連續性，以後的開發只是增加功能，新增功能類似插件一樣整合進去而不影響原有代碼。
詳細設計：由高級程序員描述類和接口等之間的關係，這部分如果是好的框架，直接在代碼裏面處理就行，也就是將接口定製出來交給程序員實現即可。
開發編碼：將接口進行實現。這部分工作還包括單元測試等，界面部分的就按照《需求規格說明書》來做。
項目測試：QC對開發部提供過來的項目進行測試，包括功能和性能測試，依據《需求分析說明書》和《需求規格說明書》,通過發佈《用戶手冊》，測試驗收後才能發佈。
產品維護：包括bug修改，新功能收集、完善性維護等相關操作。bug要及時修改，新功能可以放置到下一版本中增加。
重要性來講，越是前面的過程對項目產品影響越大。從商業角度講，產品立項最重要；純粹開發技術來講，架構設計應該是最有技術含量的。
這些都是我多年工作經驗基礎上總結的。