前言

在1997年，開源運動的領導者之一 Eric S·Raymond發表文章，闡述了開源項目兩種不同開發模式，并將其比喻為「大教堂模式」與「集市模式」。隨后在 1999 年出版成書，被稱為開源圣經的《大教堂與集市》。

在Linux的開源世界里，采用的是“集市”模式，更多是自主、自發、自我的協作和創作，面對未知的領域，通過Bottom-Up自下而上，Linux是顛覆性的，并取得了巨大的成功。

受此啟發，對于商業軟件系統、對于企業、對于創業團隊，應該采用哪種開發流程、哪個協作模式，才不會混亂、才不會內耗、反而更能讓項目取得成功呢？

標準化研發流程搭建思路和方向

一家企業，從招聘軟件開發工程師、產品經理、技術經理、測試人員到組建開發團隊，在日常企業辦公過程中，在國內，與國外的氛圍不同，需要在內部制定一套標準化的研發流程，明確每個崗位、每個人員需要共事的流轉流程。不能過于崇尚所謂的敏捷開發而任其個人自我發揮。

在過往十多年的研發管理過程中，我發現，不管是做游戲開發，還是做電商行業；不管是幾個人的創業團隊，還是幾百人成熟企業亦或是上市公司，作為老板、CTO、技術管理者、或技術經理，都需要在內部明確一套標準化的開發流程，甚至還需要在企業大范圍內明確好和其他部門進行跨部門溝通協作的大流程。

沒有流程那不行；有了標準化的研發流程卻不匹配你的現狀也不行；流程匹配了但不執行也不行；執行了卻沒有及時動態調整升級你的流程也不行。總而言之，研發流程不是萬能的，沒有最好的說法，只有更合適。更適合你和你自己團隊的，就是更好的。匹配，更重要。

我曾經在給一家做SaaS解決方案的企業做技術顧問時，就見證了他們研發從痛苦到規范化的成長過程。一開始，他們內部也有明確研發流程，但是不匹配。表現出來的癥狀是什么呢？最明顯、最為痛苦、最尷尬的莫過于在每次要給股東大客戶進行系統演示時，總會出現這樣那樣的問題，驗收時總掉鏈子。老板很尷尬、很糾結也很無力感，明明知道問題出現在那，卻不知道怎么規避和從根本上解決。員工和團隊也很累，天天都很忙，驗收演示前一晚總得要加班到很晚，第2天一演示還是有問題。開發說是測試的問題，測試說是開發的問題，差點都要拍桌子干起來，怎么辦？！

后來經過梳理發現，背后的流程明顯不匹配產品開發和交付的現狀。例如：缺少統一的預發布環境，都是在開發人員本地電腦上進行聯調測試，在驗收前直接合并發布到正式環境，東拼西湊，總會有這個那個的遺漏，沒有統一進行集成測試。又如：每次演示時經常會出現數據庫報錯。為什么？因為數據庫新加的字段又沒忘了同步到正式數據庫！后來要求每一次DDL和DML都要記錄到git代碼倉庫中，發布前統一申請線上數據庫變更，有了記錄和變更申請的環節，后來這類問題就給杜絕了。還有：以前每次發布都是人工進行操作，沒有做到自動化、一鍵發布，甚至那邊正在驗收開大會投大屏演示，這邊還在手動發布改正式環境，那有系統不崩的道理。很多問題，都是流程不規范、操作不規范、不透明、不科學導致的。

歸根到底，要么是流程有問題、要么是溝通有問題、要么是太依賴于人員和手工操作，導致每一次交付的質量和效率，都不如人意。

為此，老板總是私下問我：軟件開發，怎么就那么難？

管理者需要一個好工具

軟件開發，真的好難嗎？不見得。那，軟件開發，真的好容易嗎？也不是。

但，辦法總比困難多，花點時間、花點精力，問題總是能解決的。這也是作為技術管理者應該肩負的責任。

如果你的團隊也正在經歷開發慢、協作難、交付差的情況，我的建議是，重新再一起梳理你團隊現有的開發流程，并且讓每個成員（如開發人員、測試人員、產品經理、項目經理等）、每個對接的部門（如市場部門、客服部門、財務部門、運營部門等）、每個老板（如你的上級、總監、老板）都清楚、認同和支持統一的開發流程。最后，把開發流程圖畫出來，貼出來，共享出來。有必要，可以組織會議進行培訓、講解和明確。

 

接下來，再結合你團隊現在正在使用的項目管理工具，進行流程上的約束、明確和記錄。

例如，過往我們就用YesDev為不少企業解決了研發過程中遇到的各類問題，而且還根據企業的需要進行了開發流程的個性化設置、配置和調整。

 

后臺管理：如何搭建和設計你團隊的開發流程？

首先，定義你團隊開發流程中所需要的需求節點狀態。對于互聯網SaaS產品，常用的需求狀態是（從起點到結束）：需求中、設計中、排期中、研發中、待測試、測試中、待發布、已上線、已完成、掛起。

企業管理員也可以到YesDev后臺自己進行配置，包括：需求狀態、需求優先級、需求評審狀態。

 

例如，對于需求優先級，在某家輕醫美企業他們的定義是：P0：臨時緊急且重要需求；P1:緊急且重要；P2:重要不緊急；P3: 緊急不重要；P4：不緊急且不重要。并且，需求收集每個月和各部門需求方開會收集一次，先放到騰訊在線excel文檔，再同步錄入到YesDev需求池集中管理。

隨后，管理員還可以根據實際需求流轉的過程，把每一個需求狀態能流轉的節點和順序在后臺進行約束和配置。例如：對于已完成的需求，不希望再進行任何流轉，可以對于已完成的需求，取消全部的狀態流轉。

 

上面兩步是針對需求開發流程的設計和配置，簡單好用又直接。如果管理員還需要針對需求列表和單個開發的需求進行調整和偏好配置，例如，如果需要對需求列表默認顯示的需求字段和需求搜索條件進行調整，可以自行設置默認需求篩選器：

 

最后對于單個需求所需要的默認組件，管理員也可以根據業務需要進行個性化配置。

 

前臺使用：如何落地進行和形成閉環考核？

對于產品經理：

可以定期收集業務部門的需求，用excel批量導入或單個錄入到YesDev需求池。如果需要區分不同的產品線需求，可以通過產品分類來實現；如果需要區分不同需求方的需求，可以使用需求方字段；如果還需要其他自定義的需求分類方式，可以使用自定義需求標簽。

 

對于需求方：

可以查看每周需求排期，查看本周或自己提的需求什么時候可以發布上線，以及當前是處理什么流轉階段。

 

對于開發人員：

在每個協作的需求，可以根據制定的需求流轉順序和過程，進行流轉。后面還可以統計每個需求狀態停留的時長和研發效率。

 

對于項目經理：

可以統一管理和查看每個項目的需求數量、完成情況和項目進度，還可以進行分組管理。

 

對于測試人員：

測試人員可以創建測試用例、測試庫和測試計劃，并和項目關聯，最后提交Bug缺陷時，還可以和需求進行關聯。

 

最后，當需要進行每月考核時，可以使用YesDev提供的周報、月報、統計報表和其他分析數據，形成你團隊的閉環考核。持續復盤總結和提升。