今天看了一篇博客https://www.cnblogs.com/alabo1999/p/12887588.html 寫了關於團隊的各個角色的一些介紹。根據文章中的觀點，進行了摘要，並且增加了一些個人看法。
總結如下：
組建研發團隊
研發團隊（R&D Team），指圍繞特定軟件產品組建的研發隊伍。
組建研發團隊是整個研發工作的基礎。如果隊伍陣容不整，軟件項目的成功將面臨更多挑戰。
對軟件產品而言，一個相對健全的研發團隊包含產品經理、項目經理、開發團隊（開發項目經理、系統分析員或者高級程序員、UI&UE設計人員、前后端開發人員）、測試團隊（測試組長及若干測試人員）、配置管理員、運維人員UI&UE設計人員、前后端開發人員）、測試團隊（測試組長及若干測試人員）、配置管理員、運維人員
管理者要根據產品或項目的特點組建合適的研發團隊。要認識哪些崗位是不可或缺的，有些職位可以安排兼職，但不能丟棄其職責。
產品經理
產品經理負責市場調查並根據產品、市場及用戶等的需求，確定開發何種產品，選擇何種業務模式、商業模式等。並推動相應產品的開發組織，他還要根據產品的生命周期，協調研發、營銷、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。
對於產品類軟件，產品經理是不可或缺的。
產品經理一頭是對外的，對接市場、銷售和客戶，其負責規划、裁剪和導入產品需求，制定產品路線圖（RoadMap），編制階段性大版本的功能性能需求集合。其對需求的取舍有最終的裁決權，因為其對最終交付的軟件產品負責。
產品經理往往是業務領域的專家，至少要努力成為業務領域的專家，這樣才能准確理解和把握客戶的需求。對業務領域不熟悉的產品經理，對整個團隊而言，可能是致命的。
產品經理另一頭是對內的，對接開發、測試、運維團隊。產品經理不必是技術專家，但其需要能夠理解開發團隊的訴求，包括開發測試資源（或環境）需求的滿足，對存在技術實現障礙或實現代價較大的需求是否進行需求降級的取舍。
對於工程項目類的定制開發軟件，也是需要產品經理的。
如果公司接觸的是全新的業務領域，此時往往客戶方是業務領域的專家，公司往往會指定開發項目經理來對接技術。此時要求客戶方作為產品經理的角色足夠投入，並且需要相互信任和理解對方，容易溝通，不會在問題發生時強調責任歸屬而扯皮，否則項目實施的風險就會很大。
如果公司在某個業務領域有類似經驗，公司應將有經驗的產品經理加入團隊，由其對接客戶，可大大提高項目的成功率。這種情況，產品經理可以兼顧多個同類項目。
項目經理
主要負責統籌規划項目進度及產品生命，其工作職能直接對公司高層負責。作為項目的管理者，PM通常會參與到一個或多個項目的管理與決策工作中。主要工作要求即在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的全部工作進行有效地管理。從項目的投資決策開始到項目結束的全過程進行計划、組織、指揮、協調、控制和評價，以實現項目的目標。
比較認同網上的一個觀點：產品經理對產品成功負責，項目經理對完成項目負責。
項目經理強調過程控制並確保項目有計划、有序的、風險受控方式的開展和完成，而產品經理則強調結果，需要產品成功交付或銷售額達到一定數額。
開發團隊
1軟件需求分析
（軟件需求分析對軟件項目是十分重要且必要的。軟件需求與產品需求並不是一回事，軟件需求來源於產品需求，然后轉化為軟件需求，包括功能需求、性能需求及各種質量屬性需求如靈活性、安全性、可靠性。做好軟件需求分析，等於項目成功了一半）
2 系統設計或架構設計
（服務器配置、前后端開發語言和框架選型、架構模式選擇如：微服務/SOA、是否前后端分離）
3 接口設計（如采用微服務，則各子系統調用接口、跟第三方對接的接口設計、內部使用的抽象接口設計）
4 UI&UE設計
（用戶界面及交互設計）
5 子系統或模塊的概要設計
（選用的開發語言、開發框架、部署架構、數據庫設計等形成文檔）
6 重要的功能的詳細設計
（國內大部分公司的詳細設計文檔都是后補的，尤其是敏捷開發模式，不太重視文檔，詳細設計文檔一般都是驗收的時候補的。所以重要功能的詳細設計文檔，可以在開發之前寫一下，以便核對和留底）
7 編碼實現
聯調測試和單元測試
（前后端聯調、正常的黑白盒測試）
測試團隊
測試團隊，Test Team或QA，是保障軟件質量的重要單元。對於中小型軟件，可以是一兩個軟件測試工程師，甚至一個軟件測試工程師兼顧多個項目。
但是測試人員是比不可少的。
測試團隊使用軟件測試方法，根據需要，提供下列測試：
功能測試（黑盒測試）
接口測試
性能測試（壓力測試）
視需要與開發人員共同完成白盒測試
必要時，搭建自動化測試框架，以更好地支持回歸測試。
配置管理員
配置管理包含版本管理，對於較復雜的系統，其涉及多個子系統，每個子系統又有依賴的組件版本，這些構成了全部的配置項。
對於Java，有maven工具，幫助管理組件的版本，可以省心不少。
配置管理員一般由開發項目經理兼任，如果項目較大，可以另行專門指定一個配置管理員。
配置管理員協助項目經理和開發經理，完成配置管理工作。
代碼的版本管理，一般使用版本管理，如SVN、Git。
配置管理員創建必要的代碼分支，並進行代碼merge審核，設置代碼基線（或tag）。
沒有良好的配置管理，導致代碼版本混亂不堪，質量保證就無從談起。
運維人員
現在項目大多數是雲部署的項目。設計web服務器、數據庫服務器、消息隊列、Redis等，從可靠性和性能角度，還可能集群或分布式部署，還要考慮網絡安全等因素。
因此，如果涉及雲部署，應該有專門的運維人員，他可以兼顧多個項目。
運維人員往往兼任數據庫管理員，及版本上線發布。
個人感想：
1 對於中小型企業，開發經理和項目經理一般不怎么區分，尤其外包型公司。因為開發經理也要負責管理人員，划分功能，所以很多時候項目經理和開發經理可能是一個人擔任。
2 有的企業甚至連高級工程師都沒有，都由開發經理來擔任，當然這樣是不好的。尤其項目時間緊張的時候，如果都是初級工程師，他們由於自身的局限性，無法保證代碼質量，只能保證按期完成。那么對於代碼質量、后續的技術和功能的擴展、項目的技術沉淀都是不利的。還會導致開發經理的時間被分散，要去指導初級工程師一些初級的問題。
3 項目有項目經理或者開發經理存在是非常重要的，尤其需求比較多變或者系統比較大或者對文檔要求比較多的項目，如果由程序員去兼任負責人，會導致這些人核對需求和編寫代碼同時進行，會導致哪個都做不好。而且普通程序員對文檔，尤其是需求文檔、概要設計、詳細設計沒什么重視性，多半是應付了事，對於文檔要求嚴格的客戶，應付了事反而會讓客戶比較反感。由項目負責人去核對需求、安排相關文檔的編寫，可以保證需求和文檔的統一及一致性。