大規模需求協作的挑戰與思路

網際網路公司的典型業務場景下，乙個需求會涉及到運營、產品、前端、後端、資料、測試等不同部門的配合，乙個需求正常情況下都需要拆解成多個模組，而其中的一些模組可能還涉及到其他模組的功能，導致需求完成的子目標比預期的多很多，需求的管理工作就會變得特別困難。

一：前端支援，當前公司有了固定的元件，但並不能完全滿足展示需求，出於長遠角度考慮，應該將元件中加入新的功能，以支援當前需求，但排期很長；

二：後端支援，後端對於頁面的展現邏輯提出了質疑，部分場景下展示資料過多或者組合邏輯太複雜，會導致潛在的效能問題，希望修改設計稿；

三：資料支援，資料的常規需求是支援t-1粒度的資料統計，但運營同學希望看到實時的變化，在架構的設計和維護複雜性上驟然增加了很多，需要增加對於實時資料統計的預研工作，排期要很久；

四：測試支援，測試同學由於公司集群的技術架構，不能夠偽造資料來驗證邏輯準確性，需要等其他部門完成後才能投入測試，工期一下子從並行變成了序列；

五：產品支援，某天部門領導參與了會議，發現需求稿存在很多問題，不願意浪費時間，於是需求評審會議從乙個變成了多個，總是定不下方案。

以上種種問題，就成為了大規模需求協作中難以繞過的挑戰專案。

雖然每個公司都會有自己的需求管理平台，能夠很好的跟蹤每個需求的進展情況，但是對於每個人的時間分配，就缺乏相應的工作來支援了。在這種情況下，就會產生如下各種的衝突情景：

一：需求多且複雜，不同團隊管理不同的專案空間，而分配到每個人的需求分散到了各個不同的專案空間中，難以窺探進度全貌；

二：管理方式不同，不同團隊或者部門，都有自己的開發標準與需求管理方式，標準不同，進度就不統一，導致相互之間的依賴情況難以解決，延期就變得很自然；

三：需求優先順序不同，雖然每個需求之間有大致的優先順序，但具體到每個人上，需求的優先順序就發生了變化，如果高階別領導提出了一些需求，對應的一些專案就要延期，增加了整體的排期難度；

四：需求數量難以度量：我們一直在做需求，但很難知道我們接下來到底有多少需求，有很多團隊內部的優化工作因此而延期，系統變得越來越臃腫，士氣就產生了巨大的影響。

沒有那種方式可以一勞永逸，那麼我們就需要盡可能讓挑戰變得可控，具體有如下幾種指導思路：

一：問題及時可見：我們需要面對的挑戰，存在很多隱藏問題，是導致延期的重要因素，因此及時的把這些問題提出來，就非常重要。但這種提出方式，並不是把問題放到線上就可以了，需要每個遇到問題的人去主動推進，為我們的重要決策提供很重要的參考依據。

二：過程相對可控：面對需求的過程中，總要有長期方案和短期方案的pk，短期大家都有時間成本，長期會導致上線時間不可控，因此如何對齊進度，是否需要存在中間過渡狀態，需要每個人的參與、跟蹤和同步。

三：問題主因回溯：每一次的會議都會有很多衝突，那麼導致劇烈衝突的主要原因是什麼，需要在會議之後進行總結討論，如果各方存在自己的方案，能夠對應不同的情況，那麼就應該把這些方案達成共識，後續在遇到類似的問題的時候，就不會陷入重複的討論。

不論哪種思路，需求管理都不會一直很難，每個人出於自身角度出發，都會多少去推動它的改善，最好能夠有小範圍內的聊一聊，有時候私底下說事情，會講很多臺面上聽不到的東西，這對於你理解需求全貌，很有幫助。畢竟每個人都在走向leader的路線上，純技術的leader，可太難了。