前言
「軟體開發，是一個需要高智力、頻繁溝通和密切協作的過程」。
如果你也在從事技術編程相關的工作，你會發現，軟體開發從來都不是一件容易的事情。
一方面，軟體開發既要從抽象的需求到實現具體的功能、界面，又要從具體重複的代碼抽離提取抽象的設計模式、系統架構、UML模型；另一方面，軟體開發既要充分發揮個人專業技能處理複雜邏輯的能力，又要協同不同崗位共同配合協作的過程；此外，既要給技術人員預留和保護程序員個人沉浸式、忘我的、高效工作的寶貴時間，又要保持隨時的溝通、響應、會議、彙報；最後，老闆和需求方、客戶，還不會忘記給你和你的團隊提出這也要那還要的需求，而且都是很緊急的需求。
更別說，還要一年365天持續、高效、穩定地進行軟體交付，是有多麼難了。但辦法總比困難多。
回到當下，回到現在。
假如你是一位CTO或技術負責人，又或者你和你的研發團隊也正在經歷研發過程中效率低、故障多、質量差、溝通難等困擾，又或者處於空降、高速增長、業務轉型、團隊擴張、結構調整、技術變革等歷史轉折點上，我們繼續來探討如何迎難而上，從源頭、基本的流程上和管理模型上本質上解決交付類的通用問題，而不僅僅是case by case地重複處理一個又一個日常的問題。
論合適工具的重要性
為什麼要講協同工具？
工具是具體的系統，第一，它在使用上都比較簡單，比起抽象的理論、經驗和條條框框，更容易讓人理解和接受。第二，協同工具並非是那麼簡單的。一款合適的協同工具，應該能幫助領導層、管理者、一線技術團隊，甚至業務部門和客戶，更好地進行流轉、協作和管理。
正如，在選擇另一半時，我們很難在未來大半輩子的時間改變一個人原來的習慣，但我們可以在一開始就選擇合適的另一半；對於團隊的成員也是一樣，我們不能或非常難去改變、引導或培育一個人，但在當初面試時作為面試官和企業僱主，我們可以選擇合適、有潛質、有能力、有經驗、願意做事的候選人。同樣道理，我們去修改或改變一款協同工具會很難，並且人不應該是適應工具，而是工具要順應人和團隊的使用習慣，並且在一開始我們就要給團隊物色和尋找一款合適的工具。
沒必要讓自己和自己的團隊，每天都在艱難、痛苦和糾結中進行研發的協作、溝通、反饋。如果目前的協同工具不能滿足或者輔助你進行管理、協作和彙報，那麼是時候可以考慮和尋找更合適的工具。
一款好用、實用、耐用的研發協同工具
作為已經擁有超過十年互聯網工作經驗且已過而立之年的我，一直也在思考，研發團隊到底應該需要一款怎樣的協同工具？
我曾經在某上市企業，擔任高級開發工程師，當時幾千人的研發團隊，使用的是公司找外包團隊專業研發的內部系統。也經歷過在上千人快速發展的公司，在帶領幾十人的研發團隊時，使用國外Jira這樣優秀但複雜又不符合國內習慣的產品。在創業階段，也使用過國內和國外開源的項目管理工具；也用過Excel和郵件這樣傳統手工的方式進行需求管理。當然，一些大廠研發和提供的協同平台也有用過。
不同的協同工具，各有它的特色和優勢。
不同規模的企業和團隊，也會因為發展階段的差異、所處的環境不同以及業務特點，需要不同的協同工具，以滿足當前個人、研發團隊、技術管理、企業、老闆不同層面的需求。
和軟體編程一樣，協同工具也不存在放之四海而皆準的「銀彈」。
但我認為，一款好用、實用和耐用的研發協同工具，應該在以下三個方面進行充分考慮和支持。
第一個方面：協作流
第二個方面：信息流
第三個方面：價值流
協作流+信息流+價值流=研發閉環管理
首先，先來說協作流。
作為一款研發協同工具，首先要滿足基本的功能，就是研發團隊日常工作的協作流程，從需求提出到最後上線發布這一過程的主要環節。例如以下這張協作流程圖。當然，你和你的團隊，更需要的是一張適合自己和能滿足自己協同需求的流程圖，這，才是最關鍵的。
結合目前ToC最為熱門的社交產品，參考了很多在產品上把用戶體驗做到極致的優秀做法，我也一直在思考，為什麼管理系統一定要那麼難用呢？為什麼不能用做ToC產品的用戶思維來研發和提供一款ToB的、低頻的、複雜的系統呢？
為此，我提出了用ToC的用戶體驗方式來設計和研發ToB的協同工具。也就有了這張slice：
以項目協作為核心，根據PC電腦版用戶關注的F焦點原則，左側是當前你團隊的項目，右側是具體的項目信息。和社交聊天軟體一樣，你可以快速、輕鬆切換和查看不同的項目。在左側的項目菜單列表中，會實時顯示最新的項目動態（就好比如你有多少條未讀的聊天消息），也會根據最近更新的項目進行排序（這樣你就能知道哪個項目是最近活躍和有變化、有進展的），還有貼心的項目小紅點，讓你可以快速知道哪個項目是你需要重要關注和參與的。當然，你還能進行項目置頂等操作。
更重要的是，在一個項目中，你和你的團隊可以進行All In One地協作。下文會具體介紹。
更更重要的是，這是一款懂你和懂研發的協同工具。後續會繼續介紹。
再來說說信息流。
人們都說，「美好的愛情都是雙向奔赴的」。在職場上，特別是在軟體研發上，溝通和反饋也是這樣的。
一般技術研發人員，都比較忙，又不擅於表達和溝通，更不喜歡向別人暴露出自己的問題、過錯和不足（甚至也不認為是自己的不足或問題）。你可能會感受到或經歷過這樣的場景：老闆或需求方急得要死，而技術人員一臉平靜；你迫切想知道最近的研發進展、當前的風險和預計什麼時候能完成，技術只會和你說「快了快了」，或者說「我也不知道還要多久，不好評估」。
需求提了出來，什麼時候能完成？不知道。任務分配和安排了下去，進度怎麼樣？不知道。這個Bug和改一個小小的文案，到底是哪一位在跟進？不知道。
我們是真的不知道嗎？非也。歸根到底，一方面，是溝通上的問題；另一方面，缺少工具的自動支撐；第三方面，是團隊人員的習慣和風格問題。
如果是人員問題，那麼我建議下次還是選擇更合適的新人；如果是溝通的問題，可以臨時就本次事件進行私下、工位和會議上的溝通。如果是協同工具，總結下來，我覺得：企業郵件+群通知+站內提醒+歷史變更 這樣的組合通知是更為合適的。
企業郵件，本身郵件就是一件正式、重要的通知，因此對於個人重要的指派和需要完成的事項，我們會選擇使用郵箱來發送。同時針對閉環反饋和中途的變更，也應提供恰到好處的提醒。因此，也就有了這一份完整的、經過充分設計和實際驗證的郵件通知規則。
企業郵件是To個人的通知提醒，群通知，例如：釘釘群通知、企業微信群通知、飛書群通知，就是針對團隊、針對項目組、To項目干係人的。因為一個項目團隊，除了研發人員、產品、測試外，還有項目經理、技術管理、領導、老闆、需求方、業務部門等項目干係人。這些干係人，他們不需要直接參与項目，但他們對於項目的實際狀況和進度、風險需要保持關注或同步。讓他們知道「正在發生什麼」，並且要「共同看見」（正如釘釘的酷應用中所提到的概念）。而不是讓研發始終成為一個「黑洞」，外界對此一無所知。
所以，個人會看到這樣的郵件圖文通知（Tips：圖片是第一張正文裡面的截圖，方便提醒研發人員快速回憶這是哪個需求、哪個bug或哪個項目）。
在聊天群里，則可以看到這樣透明、同步的實時項目動態信息。例如：釘釘群通知、企業信息群通知、飛書群通知（飛書群因為需要先傳到企業內部的圖片，比較繁鎖，所以暫時還沒能顯示首圖）。
再結合站內提醒、頁面提示、歷史變更記錄、項目小紅點等，就能讓信息和數據多跑腿，讓研發團隊和管理者多省心。
讓協同工具能幫助我們和團隊，實現快速記錄、持續跟進、自動反饋、閉環管理。
最後，就是價值流。
你說，一個研發團隊，聚在一起，那麼多人，寫了幾十萬行代碼，每天查看和回復那麼多信息，為了什麼？就是為了最後能交付正常運行、有價值的軟體。
過程和結果，同樣重要。
交付同樣的軟體，你可以很高效，也可以很慢；你可以通過自動化一鍵完成，也可以人工重複操作（還會容易出錯）；你可以反覆問了又問還得不到真實、全面、及時的結果，也可以通過工具進行可視化、及時地反饋和推送。
例如，結合DevOps和持續交付等思想和理念，在最終發布上，我們可以結合：一鍵發布+自動化單元測試+實時釘釘群通知，實現既高效、又穩定地持續發布。
又如，開發人員每天都會寫代碼，提交git。那麼，我們可以從這個作為切入點，結合【Git代碼提交】+【群聊天】+【每日工作登記】+【需求進度反饋】，這幾個高頻方面和協作的剛需，進行設計和效率提升。
當一個git代碼提交時（只需要開發人員複製一下需求標題，或手動指定需求ID），就能實現一系列的動作：把代碼提交自動關聯到需求（方便後面追蹤和進行code review）、把需求狀態自動更新為研發中（需求流轉）、自動創建需要的任務（方便登記工時，也可以關閉）、進行必要的群通知。
多功能研發協同工具介紹
介紹了這麼多經驗和心得，接下來，放鬆一下。一起來感受和看下這款多功能研發協同工具，它又有哪些不同和特色。
由於邊幅有限，這些著重分享介紹YesDev在協作流的能力，即如何在一個項目里，協作更多內容。
1、項目協作：敏捷開發
適合短平快的產品迭代，小步快跑。
2、項目管理：瀑布流研發
適合外包項目和大項目，例如超過500人天的大項目全流程管理。
3、項目集管理
任意關聯多個項目，重點關心項目經理或技術負責人你要關心的項目集合。
4、技術專項協作
例如重構、系統優化、線上故障復盤、調研、第三方對接等。
5、知識庫
分享技術、傳承知識、沉澱經驗。
6、外部協作
和外部合作夥伴、上下游，甚至和客戶一起協同。
7、自定義研發模型
配置自己和自己團隊喜歡的模板，支持個人、團隊、企業等自定義項目模板。
8、工作項
需要團隊成員執行和完成的工作項。有：文檔、需求、任務、問題等。
9、統計圖表
可視化統計圖表，自動生成，隨時查看。如：概覽、每日燃盡圖、七彩甘特圖、增量排期表……
10、通用模塊
常規的功能，例如：歷史記錄、附件、備註、doc文檔/Excel導出導入等。
概括來講，YesDev支持：敏捷開發 / DevOps / Scrum / 瀑布 / 混合研發模型。它結合了敏捷開發和DevOps雙引擎，實現研發全流程扁平化協作和閉環管理。
-
-
-
-
-
-
-
-
-
-