（微信公眾號：生菜閱讀）
今天菜園子發(fā)起的話題是團隊協(xié)作工具，有人問: 什么是團隊協(xié)作工具？
簡單來說，就是由于團隊分工不同，大家協(xié)同工作的時候需要借助一些工具，來幫助分解安排工作細節(jié)、確定任務(wù)優(yōu)先級和執(zhí)行計劃、記錄和確認各不同環(huán)節(jié)的交付物等。目前此類工具非常多，但是側(cè)重點略有不同，看大家的發(fā)言提到的就有十余款工具，諸如Teambition、禪道、TAPD、Confluence、Slack、Bearychat、企業(yè)微信、釘釘?shù)鹊?。一般來說，大家總是會選擇其中一款或多款聯(lián)合使用。
工具如此多，也從側(cè)面反映了，其實沒有一款工具能滿足于所有場景。這當(dāng)然不是說這些工具做的不好，而是軟件研發(fā)、互聯(lián)網(wǎng)應(yīng)用研發(fā)、特別是今天的移動互聯(lián)網(wǎng)應(yīng)用研發(fā)，在過去這些年變化發(fā)展太快，傳統(tǒng)的項目管理方法論幾乎全部被顛覆，新的方法論沒有形成并被標(biāo)準化，所以今天各團隊的實際執(zhí)行情況，如果去做一個調(diào)研，會發(fā)現(xiàn)各有一套，和下圍棋“千古無同局”一樣，幾乎是“業(yè)內(nèi)無同法”。
在我剛工作那會兒，其實還不是這樣，我們大學(xué)里已經(jīng)有軟件工程導(dǎo)論這樣的課程、還有諸如設(shè)計模式、UML建模等課程來系統(tǒng)傳授從需求分析，到系統(tǒng)架構(gòu)設(shè)計的各環(huán)節(jié)。等到進了公司里，也是各組分工明確，還有專職的PMO團隊，負責(zé)制定整體的項目計劃并保證執(zhí)行環(huán)節(jié)的各節(jié)點，幾乎隨便啥事兒，都有一個標(biāo)準化流程等在那里，一旦被觸發(fā)，先做什么后做什么一目了然。偶爾有個事兒流程沒有包含，那么做的第一件事，一定是先把這個空白給補上，保證下次再遇到，就可以有流程來控制。
所有的文檔、都有中心化的地方來存儲。也有一個Wiki，供所有人查閱，哪怕是幾年前一個產(chǎn)品需求說明書，也都能找到。
一個產(chǎn)品從需求誕生到最終交付，按照當(dāng)時的教科書來說，需要有：需求分析、概要設(shè)計、詳細設(shè)計、編碼、測試、交付、驗收、維護? 等環(huán)節(jié)，每個環(huán)節(jié)都有標(biāo)準的文檔輸出作為記錄，這些文檔都會有一個模板(通常由十幾頁)，每一個環(huán)節(jié)和下一個環(huán)節(jié)的交接，都需要開會，比如產(chǎn)品經(jīng)理完成了需求分析，交給研發(fā)團隊，必須開一個會，雙方對需求分析的結(jié)果表示沒有異議，一旦這個會雙方確認完了，就表示研發(fā)團隊認可了這個需求的合理性，后續(xù)必須在指定的時間內(nèi)完成編碼，不能再甩鍋給產(chǎn)品經(jīng)理說需求不明確，或者技術(shù)實現(xiàn)有難度。
類似這樣的會在整個研發(fā)過程中，也會有十余次，期間還可能有反復(fù)。
如此冗長的流程，帶來的結(jié)果有幾個：
團隊之間的責(zé)任非常明晰、也會起到互相督促的作用，比如不靠譜或者沒想明白的需求，在很早期就會被攔住，根本無法獲得研發(fā)資源；
所有的文檔都質(zhì)量較高(低了無法被下游團隊接受)，并且由于都有命名規(guī)范，使得未來的檢索和追溯非常方便；
交付的產(chǎn)品質(zhì)量較高，畢竟被打磨的時間很長，引入了各方意見，考慮的比較周到細致；
交付的周期很長，當(dāng)時大約是18個月左右向市場推出一個大版本；
由于交付周期很長，一旦錯過了一趟車，就意味著要等很久，如果做錯了一件事，那更是很糟糕，要挽救幾乎只能用一些召回策略，不大可能得到快速修復(fù)。
由于5，所以對質(zhì)量的把控也很重要，一般都有嚴格的質(zhì)檢團隊，保證出廠的產(chǎn)品沒有大的瑕疵，也因此會進一步加長交付周期。
十年前的這一套流程，是非常標(biāo)準化的，幾個跨國大廠，雖然細節(jié)有差別，但是基本上都遵循了這套方式（不然也無法寫入教科書），所以當(dāng)時的PMO崗位從一個大廠切換到另一個大廠，對個人是差別不大，對公司也是可以很好的復(fù)用其經(jīng)驗的。
不過，大家都知道，隨著移動互聯(lián)網(wǎng)時代的到來，今天已經(jīng)幾乎沒有哪個廠是這么玩的了，原因很簡單，移動互聯(lián)網(wǎng)是一個全新的增量市場，而且瞬息萬變，幾乎沒有一個產(chǎn)品能夠以如此緩慢的迭代速度面向市場，所以：
團隊規(guī)模急劇縮減了、更提倡小分隊作戰(zhàn)；
團隊之間更提倡協(xié)同配合而不是互相監(jiān)督，有問題不管是誰的鍋，大家必須一起扛；
文檔質(zhì)量也沒法要求了，差不多就得了，不然來不及做；
發(fā)布周期也縮短了，一周一發(fā)甚至一周雙發(fā)也不是不可以；
相應(yīng)的交付質(zhì)量也下降了，用快速迭代來解決可能的質(zhì)量問題；
測試的重要性被大大削弱了，基本只有很少的測試，甚至沒有專職測試，真正的完整的測試其實交給用戶來完成了，反正很快下一版又出了，有問題可以修(高級的還有熱修復(fù)技術(shù))；
正是在這樣的快節(jié)奏的催促下，無論用什么工具，投入在工具本身的維護成本，都變成了一個需要考量的問題，因為每多一個工具，就意味著你需要維護這個工具上的信息正確性，在繁雜而快速的工作中，這一點是很難保證的，以至于實際執(zhí)行過程中，這個活兒很可能就變成了產(chǎn)品經(jīng)理的工作。專職的PMO也變得不大需要了，團隊需要每一個人都是有實際產(chǎn)出的，全程“監(jiān)工”性質(zhì)的PMO就顯得太奢侈，而且由于變化快速，即使有專職的PMO，也會疲于奔命的在各團隊之間搬運信息。也有一些團隊協(xié)作應(yīng)用在嘗試用機器人輔助一定的AI技術(shù)來擔(dān)任這個職責(zé)，也是有趣的嘗試，不過還沒有看到顯著的成果。
所以現(xiàn)在最理想的團隊工作模式是怎樣的呢？
把團隊足夠細分，不超過5人，把產(chǎn)品經(jīng)理、設(shè)計師、架構(gòu)師、后端工程師、前端工程師、測試的活兒全干了，所以必定有人是身兼多職的，這也是為什么全棧工程師一度很流行，因為1個人可以干這里面的三個活兒。
給團隊充分授權(quán)，最好不需要再請示任何人，就可以直接決定產(chǎn)品層面的所有事情、包括需求、優(yōu)先級、排期、交付時間、交付方式等等。
被充分授權(quán)的團隊，作為一個統(tǒng)一的管理單元，向上級負責(zé)，考核方式可以是KPI，也可以O(shè)KR。
團隊內(nèi)部的工具，就不那么重要了，完全可以自己決策，由于是一個利益共同體，所以如果產(chǎn)品經(jīng)理花了太多的時間在寫文檔上，研發(fā)也會捉急。所以團隊內(nèi)部會磨合出一個最合適的度，使得研發(fā)能理解產(chǎn)品的設(shè)計、即使出現(xiàn)了表述不清，也能夠隨時溝通。
在理想狀態(tài)下，這樣的幾人小組，不用任何團隊協(xié)作工具，哪怕就記記筆記，也是完全可行的。
菜園子里，經(jīng)常聽到有小伙伴抱怨，說自己寫的文檔一直被研發(fā)團隊?wèi)?，怎么辦？ 我通常的答案是：
如果你的研發(fā)團隊總是懟你，多半來說，是你的文檔的確寫的不夠好，但是解決的方式，并不是立即去提升自己的文檔水平（這也很難在短時間內(nèi)提升）。
被懟反映的更深層的問題是產(chǎn)品和研發(fā)團隊處于對立的立場，雙方?jīng)]有綁在一起，在這種情況下，研發(fā)去挑戰(zhàn)產(chǎn)品的方案，是完全符合其自身利益的，畢竟一旦接受了你的方案，就變成自己要承擔(dān)所有的風(fēng)險了。
所以要解決這個問題，必須主動和研發(fā)團隊立場一致，如果公司沒有從制度上保證這一點，就只能靠自己去點對點的解決了。
畢竟產(chǎn)品和研發(fā)坐在一個板凳上實時溝通，才是效率最高最信息無損的溝通方式啊！
P.S. 我不是教你們?nèi)チ醚邪l(fā)小哥哥......
