定制化系統開發：需求做的好，項目不亂跑

01.04 / 2024

在之前的文章中，我們談到以項目交付作為商業模型的公司，要想業務規模做大做強、又要賺錢要利潤，就一定要做KA大客戶、百萬以上大項目。而越大的項目，風險又越大，這既是一個殘酷的事實又是一個充滿矛盾的命題。

其實不只是百萬以上級別的項目才會出現風險，只要脫離了【標準產品】實施的范疇，或是基于標品定制開發，都會存在一定的風險，從腦海中的需求到開發出來的產品，需要以項目化的方式進行管控，否則就會以失敗告終。

分析報告指出，多達76%的項目失敗是因為差勁的需求管理，這個是項目失敗的最主要原因，比技術、進度失控或者混亂的變更管理還要關鍵。很多項目經理或客戶成功經理并沒有把需求管理重視起來，甚至認為這只是產品經理的事情，自己只做交付和統籌即可，俗話說：好的開始是成功的一半，一開始就沒有管理好，注定為后續埋下了很多坑。

百萬級項目可能考驗的是綜合項目管理能力，那么"短平快"的中小項目，如幾十萬、十幾萬甚至幾萬元的開發任務，就更加聚焦對于【定制需求】的管理管控與落地交付能力了，但這也是項目管理中最難得一點，項目的全生命周期絕對不是到了需求給我們才是項目管理的開始，越往前參與越深，我們的價值就越大。

為什么要做好需求管理？

為什么需求管理是項目管理中的一大難點呢？我們先看看這些場景是不是都很熟悉：

1）產品提的期望是A ，結果做出來演示的是B，實際出現很大的偏差，從期望到真正可落地的需求千差萬別；

2）老板和產品負責人對需求的理解不一致，經常出現已經定好的目標，產品負責人要變更，但老板覺得沒必要，項目經理受夾板氣；

3）老板經常性的插入需求，導致變更率居高不下，需求變更流程形同虛設；

4）需求落地執行的過程中，一切都看上去挺順利的，都在按計劃執行，結果到驗收階段，各種問題頻出，不是功能缺失，就是進度延遲，功能看著像是做完了，但各種小問題一大堆；

5）多方不斷地插入需求，但時間又不允許增加，還要求按原計劃完成，導致團隊怨聲載道，滿意度很低。

以上這些場景，是不是都不陌生。事實上，可能遠不止這些問題。

就我們項目管理日常的一些場景來分析，需求管理的難點在于：

1）需求管理本身，因為項目的特點是漸進明晰，不確定性是貫穿整個周期的，而需求是源頭，一旦源頭有問題，對整個項目全流程都有很大的影響；

2）需求管理“背后”，需求輸出、實現、交付、完成，都是由人來參與的，有人參與的地方，人的復雜性，就使得整個鏈路都不會太簡單。比如對需求方期望的真正理解、對老板變更預期的理解、對團隊執行過程中的跟進與監控、還有團隊執行的滿意度。

作為一名項目經理，或是說一個需求任務的管理者，在我們日常項目管控中非常重要的一項工作，就是需求管理。如何做好需求管理，非常考驗項目經理能力。下面就需求管理進行系統性拆解。

如何做好需求管理？

1、【了解背景】

我們在負責一個項目或接到某個需求任務之初時，需要花大量的時間了解清楚項目/需求的背景，這是一個非常重要的前提。何謂項目的背景，簡單來說，就是這是一款什么樣的產品？是什么類型的產品？市場上是否已經有類似的競品？和競品相比，產品的優勢和亮點體現在哪里？項目的主要干系人有哪些？項目發起人，項目核心管理層的預期是什么？

除了這些以外，還有必要了解清楚，我們為什么要做這個項目？做這個項目能帶來的價值是什么？再更深入一點的，這個項目主要要針對的是哪些用戶？這些目標用戶，我們的項目交付成果是否可以滿足他們的期望和訴求？我們項目將圍繞怎樣的目標來展開，以便滿足這些用戶的期望和訴求。

當了解項目的背景之后，會有助于我們真正理解需求方/客戶方的業務。

2、【明確目標】

當了解了項目背景之后，接著就要進一步明確項目的目標，從項目階段來說可分為：短期目標、中期目標和遠期目標。從產品本身來說，項目目標分為：最直接的目標、業務目標和戰略目標。不論項目內部自己怎么劃分，重點是需要明確項目的目標。

以最直接的目標為例，其實就是弄清楚時間、成本（人力）、范圍和質量這四要素。要做這個項目，預計是在什么時間，投入多少人力資源，做多少需求，達到怎樣的質量標準，這是必須要確定且非常具象化的。比如我們常常會去界定，項目在某個時間節點必須上線，這就是最直接的目標。

一個項目（無論大小）都必須有一個固定點"關門"時間，因為"鑼鼓長了沒好戲"，特別是在這樣一個VUCA時代。

3、【界定范圍】

在目標明確之后，要落地好目標需求，就必然要界定清楚需求交付的范圍。這個需求范圍通常可以按照MoSCoW的簡潔法則來界定即：Must have（一定有）、Should have（應該有）、Could have（可以有） or Won't have for now（現在沒有）。

以一個為期半年的項目為例：

1）項目最直接的目標是，一年后要達成上線運行；

2）為期半年的項目，說長不長，說短也不短。界定范圍時，得先有一個整體的需求框架，這個是整個項目的大范圍。梳理需求框架的目的不言而喻，就是我們要做一款產品/系統，會涉及到哪些功能模塊。如下圖表格所呈現的模式，把要做的需求先都界定清楚。

3）有了整體的需求框架之后，如果這是一個拆分版本迭代交付的項目，此時則需要進行版本的整體規劃，我們不能完全憑靠拍腦袋做一份規劃或計劃，需要和產品/用戶負責人進行深入的溝通和交流，確保彼此的理解一致。

進行需求優先級的劃分更有利于需求的落地執行，同時定要預留時間緩沖期，以便可以應對各種突發情況。

4、【確認需求】

范圍確定之后，接下來就是確定需求。需求管理，最根本在于對需求源頭的管理，只有源頭抓好了，后面的每個環節才會更順。所以，具體到每個需求在正式開始落地之前，一定要經過確認。

特別是對于甲乙方視角的合同交付項目，很多時候客戶提出的不一定是真需求，可能是某一個期望。這種情況下，從期望到真正落地的需求，項目經理是需要花費更多的時間來對齊確認的。這也是定制化需求開發落地比較難管理的點之一，確實有時依賴項目負責人的專業經驗甚至風格魅力。

所以，需求是一定需要經過確認的，只有經過需求提出方/用戶方確認過的需求，包括甲方項目負責人/業務部門Leader等一并確認過的需求，才會被提到需求開發List中來。這也是項目需求范圍管理的最基本的原則之一。

一旦沒有經過確認的需求進入開發，項目的風險和問題就會"涌現"出來。

5、【需求開發】

近年來很多甲方客戶會提出敏捷開發的概念，但真正的敏捷開發方法論和大眾所理解的敏捷卻有所不同，敏捷提倡我們小步快跑，快速迭代，但并不代表著對需求的輸出質量和時間沒有要求。傳統瀑布式開發往往甲方客戶希望在保證質量的前提下，實現的功能越多越好且越快越好，還不能追加成本。而現代敏捷開發推崇的是迭代周期和資源負荷是恒定不能改變的，但需求功能是可以隨時變化的，如下圖所示：

需求的源頭確認了，那么在需求進入開發階段的伊始，也需要多次核對并確認。正所謂磨刀不誤砍柴工，千萬不要認為這個時間花了，還不如提前介入寫幾行代碼，試想，如果為了省這個幾天的時間，結果導致需求開發完成之后，出現一堆bug，最后驗收效果不好，測試過程坎坷，看著前面省了一點時間，但其實整個需求的開發周期都拉長了。

在軟件開發行業里面有一句話：質量是設計出來的。項目經理或測試人員通常是質量最后的“守門員”，但不應把所有的質量問題都留在最后測試環節。

6、【搭建可視化】

需求管理的過程需要透明化，可視化。市面上有很多好用的工具，可以借助工具來搭建搭建可視化，建立需求自動化運轉流程。一個好的工具，可以讓我們在對需求管理時事半功倍。如果是內部產研型組織的項目，成熟的TAPD工具就已經非常強大了。

因為每個公司的項目管理工具可能不一樣，但利用工具的目的都是為了更好的提升效率，讓整個項目管理過程更加的可視化，透明化，想盡一切辦法讓能夠可視化的都盡量可視化，這也是項目管理的核心價值之一。

高呈自Q3季度開始，從部分項目試點開始率先使用了一款SaaS級的甲乙協同可視化產品，能夠將需求、任務、資源進行可視化的呈現給內部團隊成員與甲方客戶，除關鍵節點郵件往來與紙質文件外，其余本地/線上文檔都可以通過此工具可視化出來，如下圖所示是自動生成的項目計劃甘特圖：