談談不同技術團隊的協作

• 2019 年 10 月 11 日
• 筆記

互聯網公司或者軟體公司一般都會有多個團隊，產品，開發，測試，運維和運營，軟體系統的持續完善必須是建立在團隊協作的基礎上的，團隊協作越順暢，協作效率越高，則公司的市場反應能力越快，客戶滿意度越高，公司的競爭力也越強。現實情況下，團隊協作一直是一個老大難問題，所以才有太多的互聯網行業故事，產品和開發吵架甚至動刀子，國外還甚至發生了資深程式設計師不滿初級程式設計師不遵守注釋規範，槍殺同事的事件。

下圖是團隊協作當中常發生的事情，被人畫成了漫畫，也怪搞笑的。

首先講一個著名的心理效應理論，鄧寧-克魯格效應，也叫」達克效應」。

多數新入行的人都會經歷巨嬰階段，在這個階段，自己不知道自己不知道，在軟體行業，其實很多即使工作多年的人會一直處於這個狀態，經驗不一定和時間成正比，聰明的人會在短時間內快速跨越絕望之谷，不思進取的人會始終在愚昧山峰。

團隊協作不順暢的根源就是認知問題

很多時候，我們只知道自己領域的知識，但是不知道協作方領域的知識，導致雙方溝通常常出現錯位溝通，協作成了牛頭不對馬嘴，討論溝通會成了抬杠會議，時間白白浪費，問題沒有得到任何解決。五環連接怎麼能夠牢固呢？必須有貫穿和一定重疊，如果只是把圓環的邊輕輕接觸，怎麼可能牢固呢，團隊協作是一樣的道理。

為啥產品總覺得開發簡單呢？因為產品總是思考當前的提出的單一功能，他不會考慮在編碼環節是需要和之前的模組進行協同銜接的，而且他只是考慮了主流程，但實際上最燒腦子的最費時間的是太多的異常流程，而對這些異常流程系統化處理才決定了產品的穩定性和可靠性。開發為啥愛說」在我這裡明明好的」，因為開發不會站到測試角度思考問題，不會站到客戶使用場景考慮問題，因為他根本不了解運營同學那邊的痛。我一直提倡開發需要具備產品和測試思維，具體分析請您參看」程式設計師要有產品和測試思維」，」測試是對思維嚴密性的考驗」，」為什麼講中國軟體開發有90%以上浪費」。

團隊協作案例說明

因為研發部門是為業務服務的，所以常常是站在一個被動和弱勢的位置，常常容易被業務部門指揮的團團轉，而且需要無條件服從，產品然後又把這種隨意和混亂傳遞給開發，開發的計劃常常被打破，搞得開發無所適從。這些協作混亂問題，最後導致開發積極性不高，喜歡互相推卸責任，甚至產生了自我保護意識，事情能躲就躲，免得承擔責任。之前看到論壇上，一個程式設計師講，自己發現問題也不講，講了大家覺得多管閑事，老闆不領情，等最後發生問題了，挺身而出解決問題，反而得到老闆的嘉獎。這就是人們常說的，告訴你預防疾病的醫生，人們不覺得是好醫生，到後面得了重病，散盡家財治好了病，卻認為是最好的醫生。在一個昏頭技術領導下面做事，這種事情天天發生也不奇怪。

軟體開發不是簡單重複性勞動，和工廠工人管理，建築工地管理完全不同，我遇到過一些老闆希望能把團隊的開發工作量化，比如這個功能2個小時，那個功能6個小時，簡直太不懂這個行業了。一些公司還制定了KPI考核，暈，他們殊不知這種僵化的KPI正在殺死團隊的創造力，詳細分析，請您參看」KPI和過多分工正在殺死開發團隊」。

運營團隊和開發團隊協作可以分4個等級。第一級，拖延交付型，技術團隊對業務認知不足，自己能力認知不足，導致時間預估誤差很大；第二級，按時交付，品質一般，完全是外包公司的水準，後續測試發現成堆問題，發現一個修改一個，典型的敲一下走一步；第三級，按時交付，按要求交付，品質優秀，你要求做5分，做到了4分或者5分，後續測試沒有發現愚蠢類型缺陷，但會有偶發的難發現BUG；第四級，不但完成了要求，而且主動發現產品的設計缺陷，提升了研發效率，而且提出己方的建設性意見，產品超預期完成。

什麼是超預期完成呢？比如，運營提出了一個需求，希望使用EXCEL表格導入數據，然後給你一個樣式數據。第三級的開發，理解溝通了一下需求，按照要求完成了需求。什麼是第四級的做法呢？了解需求以後，開發會根據自己的經驗，問運營，你平時導入的數據多嗎？運營想了想說，有時候還是蠻多的，比如幾千行吧。開發會說，要不我給你做個數據導入校驗吧，如果導入的數據有錯誤的行，自動分離出來，把好的數據導入，把錯誤的返回給你，並且指出錯誤的原因，這樣你就可以快速發現數據問題了。這就是四級開發的回答，會更多的為對方考慮，利用自己的專業知識，主動解決潛在的問題，因為運營不懂編程，很多時候不知道，很多事情是程式可以自動完成的。

再講講開發和測試協同的例子，現在自動化測試非常流行，但真正能夠做到位的少之又少，尤其是UI自動化，大家都覺得很難實現，即使勉強實現了，維護成本太高。其實，大家覺得難，不代表不能高效低成本實現，實現的障礙就在於軟體的整體結構設計和團隊協同作戰能力，具體的UI自動化測試案例，請您參看」APP的UI自動化測試」。網上經常有人問我，他們能不能實現自動化UI測試，我想說的是，不行，因為不具備條件。這個案例需要開發端的組件化，測試端的組件化，還有統一的規範的UI命名標準，這些條件絕大多數公司都是不具備的。

開發和運維怎麼實現緊密配合呢？大家知道，自動化運維是非常流行的，還有DevOps，現在很多公司一般只能做到初級的自動化運維，就是說，自己開發的系統沒有真正的實現自動化運維。所以，要實現這個目標，開發軟體設計階段就需要考慮到運維的需求，而且為了開發效率，節約成本，還需要考慮和現有成熟的運維工具的融合，實現對開源工具的二次開發。

所以，團隊之間協作是一個全局概念，需要有非常強的全局把控能力，同時各個團隊也需要很強的執行能力，真正做到，不容易，需要持續優化磨練。即使在開發團隊內部也存在協作問題，前端和後台協作，APP前端和H5前端的協作，具體這些分析，請您參看」程式設計師要有產品和測試思維」和」敏捷開發怎麼真正實現落地」。

提升團隊協作的手段

下面講講提升團隊協作的一些手段，這些手段要持續使用，不能指望一口吃個大胖子，畢竟肌肉不是幾天練成的。

1. 定期的程式碼review和技術交流會

很多老闆非常吝惜這個交流時間，認為這個太浪費時間，確實，這種討論會常常要消耗一天的時間。磨刀不費砍柴功，刀子過於鋒利，會更容易折斷，單向追求工作時間，只會帶來相反的結果。很多項目前期強調快快快，然後逐漸陷入發展泥潭，後期花費的時間遠遠大於前期的計劃時間，具體的論述，請您參看」評「[高品質軟體生產成本更低]」。而且，能力越高的團隊，效率越高，發現錯誤速度越快，越有能力把問題消滅在萌芽狀態。但能力的提升不是CTO講幾句話就能實現的，特種部隊是單純聽課實現的嗎？程式碼review和技術交流會是對過去的總結，有總結才有積累，否則就成了狗熊掰玉米。而且，交流會讓團隊之間更加了解對方，讓後續的團隊溝通更加順暢，是溝通的潤滑劑。

2. 培養文檔流程圖能力

團隊溝通要有統一的語言，就和特種部隊需要手勢語一樣，統一語言需要簡潔易懂，協作的統一語言就是文檔，流程圖，類圖和資料庫表圖。很多開發覺得自己很牛逼，比產品厲害，總是拿自己的專業對比對方的非專業，但真正超一流的開發是懂得怎麼和產品測試團隊交流，能夠通過簡潔的文檔和圖表表達出自己的思路，捋清楚自己的思路。關於這個方面能力的培養，請您參看」為啥開發的文檔能力是核心競爭力之一」。文檔和圖表的目標不只是給自己和開發看的，需要讓測試，產品甚至運維都能看懂。

3. 提倡全棧能力，但不是全乾

全棧確實比較難達到，但不代表不能，不是每個士兵都能當元帥，但拿破崙也講了，不願意當元帥的士兵不是好士兵。全棧對於不同崗位的人含義也不同，全棧是希望去盡量了解自己的隊友，逐步具備全局觀。全棧不是全乾，不是否定功能劃分。之前有些老闆希望能讓後台代替運維，讓開發代替測試，這也有些走極端。有些後台可能是懂些LINUX命令，但畢竟不是專業選手，我也很懂LINUX，尤其是底層原理部分，但運維的事情，真幹不了，那麼一大堆的命令，怎麼可能做到熟練，解決一個問題花幾個小時學習操作手冊嗎？這就和我們去餐廳吃飯，餐廳老闆說需要去買麥子，然後磨粉，然後再做面似的。我不能做運維的工作，但很多時候，可以給運維做指導，因為我更懂原理，更懂開發，更懂全局分析。就拿運維來講，現在自動化運維流行起來，運維也必須具備開發的能力，所以，綜合能力才是一個團隊的最大最可怕的競爭力。

總之，團隊協作是一個全局工程，當然協作的總教練是非常關鍵的，就像超級一流球隊需要一個好教練一樣，關於CTO的論述，請您參看」技術領頭人需要全才而不是專才」。

希望看到更多的團隊關注協作，關注效率，有同感，請您關注和幫我轉發。