目錄
1 軟件開發涉及哪些環節
我認為軟件開發涉及的環節有：團隊管理、開發模式選取、需求管理、開發管理、測試管理、配置管理、發布管理、變更管理。打造出高水平的研發團隊，開發出高質量的軟件產品，要理順其中相關的各個環節。
2 團隊管理
團隊管理包括公司或部門級的能力，也有產品或項目級的。
團隊管理主要涉及：研發管理制度、研發管理軟件、績效評價體系及針對某個產品的研發團隊的組建。
當然，團隊建設還涉及其它方面，如人員培訓體系建設、知識庫建設等等，本文就不探討了。
2.1 建立配套研發管理制度
研發管理制度一般是公司級，至少是部門級的。
此處主要針對研發流程、各節點的具體要求而制定的研發制度。
不同公司體量和發展階段不斷，不能生搬硬套，需要建立符合公司或部門實際情況的研發管理制度，目的是規范研發的流程，以研發團隊目前的能力水平盡可能高效地開發出可靠、可用的軟件產品。
1）規定研發流程，由哪些環節組成，每個節點的輸入、輸出及關鍵工作內容，對輸入、輸出資料的格式或內容要點的要求；
2）規定使用的研發管理軟件平台；
3）規定研發團隊的開發約定，如：
-
代碼規范；
-
評審制度；
-
代碼配置規范；
-
代碼merge審核規范；
-
單元測試規范；
-
設計規范（如C4模式）；
-
數據庫設計和變更的規范；
-
日志或ELK埋點規范；
-
復雜業務邏輯的策略模式代碼規范要求；
-
高可靠性消息隊列的訪問規范；
-
項目階段性復盤規范；
-
code review規范；
-
項目迭代的MVP編制規范；
-
等等...。
這些研發管理制度及相關子項應有具體的文件和使用指南（比如發布在知識庫中，便於訪問和更新），並輔以充分培訓和檢查，使之深入人心。
研發管理制度，是軟件質量保障體系的制度保障。
2.2 選擇合適的研發管理軟件平台
一個好的研發管理軟件，可以為研發團隊帶來極大的便利，大幅度降低溝通成本，是研發管理的利器。
研發管理軟件有很多，如禪道、華為軟件開發雲、碼雲Gitee、Redmine、Teambition、JIRA等。
有些軟件有開源版，或針對小型團隊免費。
研發管理軟件，最好能覆蓋軟件項目各個環節，即所謂的一站式，包括需求管理、開發管理、測試管理、發布管理，及相關的文檔管理。
但是目前各款軟件都有側重和優劣，還有免費和收費的區別。
我認為，對於中小型團隊，使用禪道開源版就差不多夠了，其令人詬病的文檔支持能力，可以使用其它系統來補充，如FTP服務器、網盤或知識庫。
用好研發管理軟件，是公司研發軟實力的組成部分。
2.3 配套合適的績效評價體系
合適的績效評價體系，對激發和保持研發團隊戰斗力是非常重要的。當然，不合適的績效評價體系，可能適得其反。績效評價體系一般是公司級，至少是部門級的。
根據我的經驗，大部分研發團隊基本符合2/8法則，即20%的人員做了80%的工作。因此，如何激發80%的人員，使之可以承擔更多比例的工作，對團隊管理非常重要。
這里有主觀意願因素，也有能力因素和業務熟悉度問題，作為研發管理者，應努力提高團隊的各個體的能力，激發上進心，營造融洽的溝通文化。
因此，績效評價體系必不可少，否則容易導致劣幣驅逐良幣，也就談不上高效的研發團隊。
績效評價分為客觀部分和主觀部分。客觀部分由工作量和工作質量組成，主觀部分一般是主管和協作同事或部門評價打分，包括各種能力和態度。
關於開發工作量評估，我的經驗，是在部門建立專家組（高級程序員），評價任務工作量時，抽出2個高級，加上team leader，再臨時召集2個中級，作為工作量評估小組。
針對一批任務，先由team leader講解任務內容，然后大家各自寫出工作量（以代碼開發任務以中級程序員能力為基准），以小時為單位，然后大家亮出結果，如果最高和最低相差較大，則需要闡述理由，大家覺得理由充分，就投票決定工作量；如果相差不大，取中位數的工作量即可。評估后的工作量，作為標准工作量，不管誰來完成該任務，其標准工作量是不變的。
這種做法，只能是相對客觀，但確實是發揮了研發團隊的大致能力。當然，還是可以通過度量、復盤來持續改進（多次迭代），提高工作量評估的准確性。
至於不同崗位相對於標准工作量，可以有一個系數，如初級工程師來做，實際工作時間要超過標准工作量，但相對於其能力來說，已經做得很好了，因此需要適當補償。具體怎么量化，大家可以自行估計，可通過多次迭代，使之符合研發團隊現狀，這也是成熟研發團隊的軟實力的一部分。
建立合理績效評價體系，讓我們可以更專注工作本身，而不必拘泥於所謂的996或007的加班形式，避免出現老板與員工關於工作付出和收益之間博弈，提高團隊的凝聚力。
2.4 組建研發團隊
研發團隊，R&D Team，這里是指圍繞特定軟件產品組建的研發隊伍。
組建研發團隊是整個研發工作的基礎。如果隊伍陣容不整，軟件項目的成功將面臨更多挑戰。
對軟件產品而言，一個相對健全的研發團隊包含產品經理、項目經理、開發團隊（包括開發項目經理、系統分析員或高級程序員、UI&UE設計人員、若干前后端開發人員）、測試團隊（測試組長及若干測試人員）、配置管理員、運維人員。
管理者要根據產品或項目的特點組建合適的研發團隊。要認識哪些崗位是不可或缺的，對不可或缺的崗位，可以安排兼任，但不能丟棄其職責。
2.4.1 產品經理
按照百度百科的說法，產品經理（Product Manager）是企業中專門負責產品管理的職位，產品經理負責市場調查並根據產品、市場及用戶等的需求，確定開發何種產品，選擇何種業務模式、商業模式等。並推動相應產品的開發組織，他還要根據產品的生命周期，協調研發、營銷、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。
對於大一點的公司，有專門的產品部門。
對於產品類軟件，產品經理是不可或缺的。
產品經理一頭是對外的，對接市場、銷售和客戶，其負責規划、裁剪和導入產品需求，制定產品路線圖（RoadMap），編制階段性大版本的功能性能需求集合。其對需求的取舍有最終的裁決權，因為其對最終交付的軟件產品負責。
產品經理往往是業務領域的專家，至少要努力成為業務領域的專家，這樣才能准確理解和把握客戶的需求。對業務領域不熟悉的產品經理，對整個團隊而言，可能是致命的。
產品經理另一頭是對內的，對接開發、測試、運維團隊。產品經理不必是技術專家，但其需要能夠理解開發團隊的訴求，包括開發測試資源（或環境）需求的滿足，對存在技術實現障礙或實現代價較大的需求是否進行需求降級的取舍。
對於工程項目類的定制開發軟件，也是需要產品經理的。
如果公司接觸的是全新的業務領域，此時往往客戶方是業務領域的專家，公司往往會指定開發項目經理來對接技術。此時要求客戶方作為產品經理的角色足夠投入，並且需要相互信任和理解對方，容易溝通，不會在問題發生時強調責任歸屬而扯皮，否則項目實施的風險就會很大。
如果公司在某個業務領域有類似經驗，公司應將有經驗的產品經理加入團隊，由其對接客戶，可大大提高項目的成功率。這種情況，產品經理可以兼顧多個同類項目。
遺憾的是，很多項目大都是由對業務不熟悉的開發項目經理（Team leader）負責，其可能是軟件技術方面的高手，但由於不熟悉業務，於是項目團隊不知要踩多少個坑，結果往往不太理想。
2.4.2 項目經理
按照百度百科的說法，項目經理（Project Manager），簡稱PM，主要負責統籌規划項目進度及產品生命，其工作職能直接對公司高層負責。作為項目的管理者，PM通常會參與到一個或多個項目的管理與決策工作中。主要工作要求即在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的全部工作進行有效地管理。從項目的投資決策開始到項目結束的全過程進行計划、組織、指揮、協調、控制和評價，以實現項目的目標。
比較認同網上的一個觀點：產品經理對產品成功負責，項目經理對完成項目負責。
對於大一點的公司，有專門的項目部門。
項目經理強調過程控制並確保項目有計划、有序的、風險受控方式的開展和完成，而產品經理則強調結果，需要產品成功交付或銷售額達到一定數額。
如果公司較大，項目團隊的成員分屬多個部門，此時項目經理是不可或缺的，需要他來發揮組織、協調、管理進度和質量的作用。
對於小型團隊，項目經理不是必需的，此時往往由開發項目經理來兼任。
具體而言，項目經理是協助產品經理，來組織管理產品的每一次交付集合的開發工作。包括：
-
組建項目實施團隊並為項目和團隊命名；
-
協調研發團隊各方並起草項目開發計划；
-
度量和評價項目進度和質量指標；
-
當進度或質量指標發生異常時，及時介入並會同研發團隊想方法解決；
-
協調研發團隊各參與方的有序銜接，消除無人負責的灰色地帶；
-
組織相關評審工作；
-
組織變更的分析、評估、評審和實施；
-
組織配置管理（版本管理）的基線管理；
-
組織版本的發布工作。
2.4.3 開發團隊
開發團隊，Development Team，這里指針對特定軟件需求的開發隊伍，負責軟件開發實現。主要職責為：
-
軟件需求分析；
-
系統設計（或稱架構設計）；
-
接口設計；
-
UI&UE設計；
-
子系統或模塊的概要設計；
-
重要功能的詳細設計；
-
編碼實現；
-
單元測試和聯調測試。
軟件開發團隊的核心成員是開發項目經理，即技術負責人，一般是高級程序員或開發總監來擔當。其帶領整個開發團隊進行開發活動。如果項目不大，軟件開發團隊縮小為一個軟件開發小組，開發項目經理即為開發項目組長，即Team Leader。
如果公司較大，有專門的系統部，系統分析員或架構師歸屬於該部門。
對於中小型公司，仍需要有系統分析員或架構師（中小型項目一般由Team Leader兼任）來參與到項目中，其主要職責是：
-
軟件需求分析；
-
系統設計（或稱總體設計、架構設計）；
軟件需求分析對軟件項目是十分重要且必要的。軟件需求與產品需求並不是一回事，軟件需求來源於產品需求，然后轉化為軟件需求，包括功能需求、性能需求及各種質量屬性需求（如靈活性、安全性、可靠性、可移植性、可用性、可維護性、國際化等等）。做好軟件需求分析，等於項目成功了一半。詳細闡述在需求管理章節中展開。
系統設計，也是非常重要的。好的架構設計，可以大大延長軟件產品的生命期。很多年前，流行一句話：好的產品都是設計出來的，確實如此。
UI&UE設計，即用戶界面及交互設計。UI&UE設計，低保真模型，用於產品需求的原型，是非常合適的；高保真模型，可用於軟件需求的一部分，指導前端開發，及前后端的接口開發。
開發團隊的主體是軟件開發小組，小組的數量取決於軟件涉及的子系統的數目。中小型軟件，只需一個軟件開發小組。
軟件開發小組的成員組成，與項目選取的技術棧有很大關系。如采用前后端分離模式，后端使用Java語言Spring boot框架，前端使用VUE，則要求相關人員按此需求來配置。
軟件開發小組主要工作是編碼實現，但應包括子系統或模塊的概要設計文檔，接口文檔；視需要，重要功能也應該有詳細設計文檔。
軟件開發小組還需要實現單元測試。要充分利用已有的單元測試框架，如Java的JUnit，以提高單元測試的效率。
代碼提交測試人員測試前，還需要完成聯調測試，如果聯調測試都通不過，而直接提交測試部門測試，將造成測試資源的極大浪費。
2.4.4 測試團隊
測試團隊，Test Team或QA，是保障軟件質量的重要單元。對於中小型軟件，可以是一兩個軟件測試工程師，甚至一個軟件測試工程師兼顧多個項目。
但測試人員是必不可少的。
測試團隊使用軟件測試方法，根據需要，提供下列測試：
-
功能測試（黑盒測試）；
-
接口測試；
-
性能測試（壓力測試）；
-
視需要與開發人員共同完成白盒測試；
-
必要時，搭建自動化測試框架，以更好地支持回歸測試。
測試人員和開發人員的視角不同，不可相互替代。
2.4.5 配置管理員
配置管理包含版本管理，對於較復雜的系統，其涉及多個子系統，每個子系統又有依賴的組件版本，這些構成了全部的配置項。
對於Java，有Maven工具，幫助管理組件的版本，可以省心不少。
配置管理員一般由開發項目經理兼任，如果項目較大，可以另行專門指定一個配置管理員。
配置管理員協助項目經理（PM）和開發項目經理（Team Leader），完成配置管理工作。
代碼的版本管理，一般使用版本管理工具，如VSS、SVN、Git。現在一般用git。
配置管理員創建必要的代碼分支，並進行代碼merge審核，設置代碼基線（或tag）。
沒有良好的配置管理，導致代碼版本混亂不堪，質量保證就無從談起。
2.4.6 運維人員
現在項目大多是雲部署的項目。涉及web服務器、數據庫服務器、消息隊列、Redis等，從可靠性和性能角度，還可能集群或分布式部署，還要考慮網絡安全等因素。
因此，如果項目涉及雲部署，應該有專門的運維人員，他可以兼顧多個項目。
運維人員往往兼任數據庫管理員，及版本上線發布。