CTO來分享：推薦一款多功能研發協同工具

2022年10月13日00:58:15 科技 1395

前言

「軟體開發，是一個需要高智力、頻繁溝通和密切協作的過程」。

如果你也在從事技術編程相關的工作，你會發現，軟體開發從來都不是一件容易的事情。

一方面，軟體開發既要從抽象的需求到實現具體的功能、界面，又要從具體重複的代碼抽離提取抽象的設計模式、系統架構、UML模型；另一方面，軟體開發既要充分發揮個人專業技能處理複雜邏輯的能力，又要協同不同崗位共同配合協作的過程；此外，既要給技術人員預留和保護程序員個人沉浸式、忘我的、高效工作的寶貴時間，又要保持隨時的溝通、響應、會議、彙報；最後，老闆和需求方、客戶，還不會忘記給你和你的團隊提出這也要那還要的需求，而且都是很緊急的需求。

更別說，還要一年365天持續、高效、穩定地進行軟體交付，是有多麼難了。但辦法總比困難多。

回到當下，回到現在。

假如你是一位CTO或技術負責人，又或者你和你的研發團隊也正在經歷研發過程中效率低、故障多、質量差、溝通難等困擾，又或者處於空降、高速增長、業務轉型、團隊擴張、結構調整、技術變革等歷史轉折點上，我們繼續來探討如何迎難而上，從源頭、基本的流程上和管理模型上本質上解決交付類的通用問題，而不僅僅是case by case地重複處理一個又一個日常的問題。

論合適工具的重要性

為什麼要講協同工具？

工具是具體的系統，第一，它在使用上都比較簡單，比起抽象的理論、經驗和條條框框，更容易讓人理解和接受。第二，協同工具並非是那麼簡單的。一款合適的協同工具，應該能幫助領導層、管理者、一線技術團隊，甚至業務部門和客戶，更好地進行流轉、協作和管理。

正如，在選擇另一半時，我們很難在未來大半輩子的時間改變一個人原來的習慣，但我們可以在一開始就選擇合適的另一半；對於團隊的成員也是一樣，我們不能或非常難去改變、引導或培育一個人，但在當初面試時作為面試官和企業僱主，我們可以選擇合適、有潛質、有能力、有經驗、願意做事的候選人。同樣道理，我們去修改或改變一款協同工具會很難，並且人不應該是適應工具，而是工具要順應人和團隊的使用習慣，並且在一開始我們就要給團隊物色和尋找一款合適的工具。

沒必要讓自己和自己的團隊，每天都在艱難、痛苦和糾結中進行研發的協作、溝通、反饋。如果目前的協同工具不能滿足或者輔助你進行管理、協作和彙報，那麼是時候可以考慮和尋找更合適的工具。

一款好用、實用、耐用的研發協同工具

作為已經擁有超過十年互聯網工作經驗且已過而立之年的我，一直也在思考，研發團隊到底應該需要一款怎樣的協同工具？

我曾經在某上市企業，擔任高級開發工程師，當時幾千人的研發團隊，使用的是公司找外包團隊專業研發的內部系統。也經歷過在上千人快速發展的公司，在帶領幾十人的研發團隊時，使用國外Jira這樣優秀但複雜又不符合國內習慣的產品。在創業階段，也使用過國內和國外開源的項目管理工具；也用過Excel和郵件這樣傳統手工的方式進行需求管理。當然，一些大廠研發和提供的協同平台也有用過。

不同的協同工具，各有它的特色和優勢。

不同規模的企業和團隊，也會因為發展階段的差異、所處的環境不同以及業務特點，需要不同的協同工具，以滿足當前個人、研發團隊、技術管理、企業、老闆不同層面的需求。

和軟體編程一樣，協同工具也不存在放之四海而皆準的「銀彈」。

但我認為，一款好用、實用和耐用的研發協同工具，應該在以下三個方面進行充分考慮和支持。

第一個方面：協作流

第二個方面：信息流

第三個方面：價值流

協作流+信息流+價值流=研發閉環管理

首先，先來說協作流。

作為一款研發協同工具，首先要滿足基本的功能，就是研發團隊日常工作的協作流程，從需求提出到最後上線發布這一過程的主要環節。例如以下這張協作流程圖。當然，你和你的團隊，更需要的是一張適合自己和能滿足自己協同需求的流程圖，這，才是最關鍵的。

結合目前ToC最為熱門的社交產品，參考了很多在產品上把用戶體驗做到極致的優秀做法，我也一直在思考，為什麼管理系統一定要那麼難用呢？為什麼不能用做ToC產品的用戶思維來研發和提供一款ToB的、低頻的、複雜的系統呢？

為此，我提出了用ToC的用戶體驗方式來設計和研發ToB的協同工具。也就有了這張slice：

以項目協作為核心，根據PC電腦版用戶關注的F焦點原則，左側是當前你團隊的項目，右側是具體的項目信息。和社交聊天軟體一樣，你可以快速、輕鬆切換和查看不同的項目。在左側的項目菜單列表中，會實時顯示最新的項目動態（就好比如你有多少條未讀的聊天消息），也會根據最近更新的項目進行排序（這樣你就能知道哪個項目是最近活躍和有變化、有進展的），還有貼心的項目小紅點，讓你可以快速知道哪個項目是你需要重要關注和參與的。當然，你還能進行項目置頂等操作。

更重要的是，在一個項目中，你和你的團隊可以進行All In One地協作。下文會具體介紹。

更更重要的是，這是一款懂你和懂研發的協同工具。後續會繼續介紹。

再來說說信息流。

人們都說，「美好的愛情都是雙向奔赴的」。在職場上，特別是在軟體研發上，溝通和反饋也是這樣的。

一般技術研發人員，都比較忙，又不擅於表達和溝通，更不喜歡向別人暴露出自己的問題、過錯和不足（甚至也不認為是自己的不足或問題）。你可能會感受到或經歷過這樣的場景：老闆或需求方急得要死，而技術人員一臉平靜；你迫切想知道最近的研發進展、當前的風險和預計什麼時候能完成，技術只會和你說「快了快了」，或者說「我也不知道還要多久，不好評估」。

需求提了出來，什麼時候能完成？不知道。任務分配和安排了下去，進度怎麼樣？不知道。這個Bug和改一個小小的文案，到底是哪一位在跟進？不知道。

我們是真的不知道嗎？非也。歸根到底，一方面，是溝通上的問題；另一方面，缺少工具的自動支撐；第三方面，是團隊人員的習慣和風格問題。

如果是人員問題，那麼我建議下次還是選擇更合適的新人；如果是溝通的問題，可以臨時就本次事件進行私下、工位和會議上的溝通。如果是協同工具，總結下來，我覺得：企業郵件+群通知+站內提醒+歷史變更這樣的組合通知是更為合適的。

企業郵件，本身郵件就是一件正式、重要的通知，因此對於個人重要的指派和需要完成的事項，我們會選擇使用郵箱來發送。同時針對閉環反饋和中途的變更，也應提供恰到好處的提醒。因此，也就有了這一份完整的、經過充分設計和實際驗證的郵件通知規則。

企業郵件是To個人的通知提醒，群通知，例如：釘釘群通知、企業微信群通知、飛書群通知，就是針對團隊、針對項目組、To項目干係人的。因為一個項目團隊，除了研發人員、產品、測試外，還有項目經理、技術管理、領導、老闆、需求方、業務部門等項目干係人。這些干係人，他們不需要直接參与項目，但他們對於項目的實際狀況和進度、風險需要保持關注或同步。讓他們知道「正在發生什麼」，並且要「共同看見」（正如釘釘的酷應用中所提到的概念）。而不是讓研發始終成為一個「黑洞」，外界對此一無所知。

所以，個人會看到這樣的郵件圖文通知（Tips：圖片是第一張正文裡面的截圖，方便提醒研發人員快速回憶這是哪個需求、哪個bug或哪個項目）。