結合公司目前現(xiàn)狀和以往工作經(jīng)驗，總結了一些拙見。
團隊管理是一個很大的話題，一個團隊的主體是人，每個人的思維方式、溝通方式、專業(yè)特長千差萬別，管理團隊其實是在管理人，也可以說是在管理人性。
人性是貪婪自私的。我們總說團隊中每個人都要負起責任，所以在項目開發(fā)過程中，大到一個sprint，小到一個task，都應該明確團隊中責任人是誰，又向誰負責，不然空談負責任毫無意義。
假如我們接到一個開發(fā)需求，首先應該有前端的leader和后端的leader指定一個master，前后端master應該協(xié)助產品完成需求設計（特別是在產品力量不足的情況下），參加每次的需求評審會議，充分了解需求，與各自leader協(xié)商分配開發(fā)人員。然后項目經(jīng)理應該在jira上創(chuàng)建一個史詩，史詩描述中應該關聯(lián)需求文檔、設計稿，以及后續(xù)的接口文檔、測試用例等，那么這個史詩的責任人就是項目經(jīng)理，項目經(jīng)理應該關心這個史詩的進展情況。master應該是最了解該需求的人，master應該創(chuàng)建前后端各自的任務，然后指派給具體的開發(fā)人員，每個開發(fā)人員應該對自己的任務負責。項目經(jīng)理應該創(chuàng)建一個釘釘群，應該把產品經(jīng)理、前后端master邀請進來，master再把各自的組員拉進來。這樣的話，一個包含項目經(jīng)理、產品經(jīng)理、任務master、開發(fā)組員的開發(fā)小組就組建好了。如果由于某些原因，某個角色缺失，應該指明團隊中某個人來兼任這個角色，同時擔起這個角色的責任，各自一定要明確各自要負責的東西，例如jira上的史詩一定要項目經(jīng)理來創(chuàng)建，因為那是他的責任，前后端任務一定要各自的master來創(chuàng)建，因為那是他們的責任。如果生產過程中出現(xiàn)問題，應該首先找到項目經(jīng)理和產品經(jīng)理，項目和產品層面認為需要我們開發(fā)來解決的話，再找該任務的master，master分配相關的開發(fā)人員分析具體問題，不應該武斷認為是前端或者后端，或者某個人的責任。問題不但要分析具體原因，還要明確是哪個成員的責任，問題嚴重的，應該提出批評，這樣才是真正的負責任。
以上是開發(fā)一個需求的情況，如果開發(fā)部同時進行多個需求開發(fā)，也都應該嚴格按照以上團隊責任劃分進行管理。一個需求的話責任劃分非常清楚明了，但是多個需求同時開發(fā)的時候，就會非?；靵y，這就需要項目經(jīng)理做好每個需求誰是產品經(jīng)理，誰是maser的記錄，該記錄非常重要，全體人員應該隨時能夠很方便的通過這個記錄找到具體需求的責任人。開發(fā)這一塊有問題盡量找master，master層面解決不了的再去找leader，因為具體業(yè)務master會比leader更清楚，也避免所有的問題都落在leader上，這也叫任務下放。而且任務的進度也應該有項目經(jīng)理來把控，而不是leader，leader的任務重點應該是各小組人力配置、溝通協(xié)調、團隊建設等方面。
目前項目開發(fā)過程中暴露很多問題，包括各部門溝通不充分、需求理解不透徹等，根本原因是責任劃分不明確，出了問題又相互推諉。責任劃分清楚，不是為了追究誰的責任，而是為了鞭策大家盡心盡責，大家各司其職，也能消除各部門之間的隔閡，促進溝通交流。
另外關于站會，我認為一個需求小組，包括前后端每天早上應該在一起開站會，同步下該小組內的需求進度，而前端和后端每天的站會分別開的意義不大，因為每個人只會關心自己小組內的任務進度，有必要的話也應該拉上產品進來，這樣也能促進各部門之間的溝通。前端和后端的人員也在逐漸增多，一直在一起開站會也會越來越不現(xiàn)實，前端和后端最少應該有一個周會，周會應該是用來溝通團隊內部的一些問題。