本篇主要分成「需求來源」「需求優先級」「需求文檔質量」「需求評審」「需求驗收」和「需求上線」六部分。

需求來源

我們在公司做內部支撐平臺的產品，一開始一窮二白啥都沒有，所以主要需求有1）產品規劃 2）系統缺陷 3）用戶反饋 三類。

來到公司我們做的第一件事情，就是摸排公司在研發效能這個方向上的水位，公司都有哪些活動，哪些流程，有哪些工具，每個工具都在哪些部門的誰手里，工具的使用程度如何，大家都有哪些訴求等等。經過和相關小伙伴聊了N遍之后，我們定下了主要方向和相關的時間節點。所以大部分需求都是產品規劃中的需求。另外一種是系統缺陷，這部分改動大的就放到產品需求里，小的直接修復，主要考慮工作量大小和優先級。用戶反饋的需求，這部分要仔細判斷。大量用戶反饋的共性需求，可以考慮；但是對于很多專家型的小伙伴提出的訴求，評估時一定要慎重。尤其是產品前期，要把精力絕對地放到基本訴求，核心功能上。而不是很多「高級」「酷炫」「最好有」的需求。用戶的痛點很多，要投入到真正的痛點上，做那些「立刻馬上必須有的」需求。當然研發小伙伴也會發現一些技術方面的需求，我們也會視輕重緩急排期修復。

人人皆知以多勝少是最好的辦法，然后很多人不能做，相反地每每分散兵力，原因就在于指導者>缺乏戰略頭腦

- 毛主席選集

需求優先級

我個人覺得作為業務負責人和產品經理，對這些需求優先級都會有自己的判斷的。這也體現出了業務負責人和產品經理的領域知識、業務素養。我們團隊都是領域專家，也就是對研發效能領域有很深的認識，對需求高優與否有判斷能力，基本上不會受嗓門高低影響。

需求文檔質量

我們團隊很小，一開始只有5個人（1前端，2后端，1設計師，1產品）。

很慚愧，一開始我們的需求都是沒有文檔的。最開始我們的很多想法都直接落到 confluence wiki 上，那里有我們最初的一些思考。比如現在公司整體情況如何，各個方面的成熟度如何，我們從哪里入手，做什么，預期什么時候完成。這些都是寫到了 confluence wiki 上，當然也不是所有都寫上去了。因為咸魚(二偉哥)那個時候就坐到我對面，有事情張嘴就說，有問題拉到白板旁就畫。我們做第一個產品的時候，需求還是寫到 confluence wiki上，然后在 Team 上創建一個任務，把 confluence wiki鏈接貼上去（那個需求的模板還是從 confluence 上搜來的，形式不重要，內容是關鍵）。如果遇到中間有變更的，我們團隊就坐到一起討論，討論完畢后把結論直接寫到任務下面，這事就這么定了，決策鏈路短且高效。

團隊內中間討論的一些產物基本都在白板上，那個時候就是討論完了，手機拍個照片發到群里。重要的貼到 confluence 上，也就這種程度了。團隊小，這種程度也就夠了。

后來團隊大了，需求文檔質量要求也高了，后來的需求都轉到了在線文檔上。在線文檔比wiki 太好用了，尤其是可以對每一行進行評注討論，在線協作，方便省心。

當然我們也從其它團隊那里聽到了一些不太好的案例。一句話的需求和回字有四種寫法是需求的兩個極端，兩種做法都不好，這里涉及一個度的問題。只要團隊里的所有人的目標是做成產品，向著同一個方向努力，做成一件事，那么我認為大方向就是可以接受的。

總結一下，在團隊小的時候，在產品啥都沒有的時候，把握好大的方向，只要「整個團隊」都了解需求沒有歧義，只要產品進度不受大的影響，我可以接受文檔質量不高的情況。小步快跑么，如果跑不起來那就放棄一些目前不重要的。

需求評審

一開始我們的需求評審可以說是隨時評審，也就是沒有正式評審。前后端和產品都坐到一個地方工作，有問題隨時溝通，幾乎沒有因為需求評審造成了延期交付、功能不符等。

后來團隊大了，正式的需求評審也就有了。我們團隊那個時候是每周二四評審。其實我認為這種評審節奏是不好的。我比較認可當時「 Team團隊」的做法，每天下午2點到3點是預留需求評審時間，有需求就評審，沒有就過。

需求驗收

對于中小規模（3PD）的需求，其實不用經過業務負責人和產品經理驗收，完全可以直接上線，直接線上預發環境驗收。因為功能簡單、明確，前期都經過了幾輪評審，測試用例也評審過了，設計稿也通過了，要上線的功能基本不會出現問題。對于中大型需求（5PD～）功能上線前，我們有兩輪產品驗證，第一輪是在測試環境驗收，第二輪是線上預發環境的需求驗收。

測試環境的需求驗收，主要為了避免重大需求的實現和最初的功能不符、不滿足要求、重大bug等問題；

需求上線

預發環境是線上環境穩定性的重要保障，是把問題不帶給用戶的最后一道保障。建議各個團隊都要建設好自己的預發環境。對于上線時機，我覺得產品研發的前期，只要有信心可以隨時上線。盡早地把需求放到線上讓用戶感知到產品改進，也可以讓用戶對產品慢慢地建立起信心。

雖說是可以隨時上線，我也是建議要有產品或者QA驗證的環節。千萬不要邊改邊上，而是改過之后需要有人在單獨的環境中驗證沒有問題再上線。在線上直接改，這么業余的騷操作咱們就不提了，我覺得很大一部分公司還是可以避免的。千萬別在線上調試，真擔心變成面多了加水，水多了加面。

上線失敗怎么辦？立刻回滾。回滾到上一個版本后再去追因。

總結

軟件開發活動是生產活動的一種，也是平均智商比較高的一類生產活動。說一千道一萬，每個小伙伴的自驅是最關鍵的。如果大家的心往一處想勁往一處使，遇到問題，有人能主動站出來，而不是放任問題惡化、發生，很多問題都不會出現。每個小伙伴都是團隊中不能缺少的一個伙伴，要把做產品做需求當成自己的事來做，那么很多問題都不是問題。很多人提到流程建設，其實我個人覺得流程只是保證大家整體處在一個能接受的水平，如果想突破有更高的產出，人的主觀能動性才是最關鍵的。流程都是不完美的，不能一出了事情就怪流程，最后流程成了背鍋俠。我期望能有高效務實流程規范下，有更多主觀能動性的體現。控制團隊規模，提高專業度，優化組織架構是提高團隊戰斗力的三個方法，但這又是另外一個話題了。

BTW：這里面的一部分做法來自大叔 @甄誠 的指點，也有部分是我從「Team團隊」的日常管理中學來，從@羅振興 身上也學到了很多，也有很多是耳濡目染從老板的身上悟來的，三人行必有我師，從我們的團隊學到了很多。歡迎加vx（xueliuan）進入我們這個圈子 :-)