傳統專案管理，無論是典型的軟體銷售服務型別、還是網際網路軟體公司。在過程管理中，通常是從需求輸入開始。這當中造成的誤判範圍、過度承諾、資訊傳遞變形甚至黑洞的情況屢見不鮮。無論企業中是否有諸如PMO或是專案管理委員會這樣的組織，大多數都忽視了需求並非憑空而來，從組織和成本角度上去，無論是創新類公司還是擁有成熟市場的公司，都應當把需求從售前（需求產生）之時進行度量和梳理。有一句老話“假設（需求）什麼都不是，只有當它能夠被證偽或證實，才有價值”，有了價值，才會有去實現的必要。
敏捷對售前(需求價值)的侷限
傳統的敏捷宣言，只關注了在專案過程中，團隊如何保證需求價值的實現，如何交付價值。即敏捷首先假設的是這個專案（需求）的價值是存在的，依據這個價值依據，在專案過程中持續交付可評估的產品，以達到接近使用者真實需求價值的目標。
我們不妨追問一下敏捷的本質是什麼，敏捷宣言的核心價值告訴大家是如下四條
-
個體和互動 高於 流程和工具
-
工作的軟體 高於 詳盡的文件
-
客戶合作 高於 合同談判
-
響應變化 高於 遵循計劃
就這四條核心價值來講，更加貼近於軟體開發中的過程管理。就真正的專案全生命週期來看，敏捷忽視了專案啟動之前的價值假設過程，如果這個需求的價值假設在商業模式or成本預期or客戶（運營）YY之上的，你再怎麼努力敏捷也不過是多走幾步還是少走幾步掉坑的結局罷了。大家捫心自問一下，你所從事的敏捷專案，有多少是從開始就將商業價值和企業目標與敏捷專案結合起來進行管理的。
軟體開發團隊通常重視的專案的成功交付和驗收，而非專案是否真正為企業（使用者）創造了價值。無論是專案型公司還是網際網路公司，開發團隊通常在短期上對專案交付最重視，而從長期看，交付一堆沒有達到預期價值甚至毫無價值的產品（功能）時，對團隊的損害要遠遠超過儘早識別不具備價值不需要交付的危害。
那麼如何將敏捷擴充套件到專案啟動之前，進行專案全生命週期的敏捷管理呢。這個問題，目前有一個流派，就是將精益思想與敏捷相結合，將企業的價值目標與敏捷過程管理相結合，將商業價值與團隊動態管理相結合，重視產品交付價值本身而非專案成功，雙方共同在價值最大化的目標和框架下協同工作。通過精益思想的7項原則，很大程度上避免了敏捷對企業（使用者）價值層面的假設推論確認過早的問題。
這幾個原則的重要性依次如下
1、尊重人
這裡的尊重人，來自於精益和敏捷思想中的核心：相信創新來自於人的主動性，而非機器。即使是在精益的發源地豐田，這個流水線的工廠內，也奉行人的主觀創造力是第一生產力的觀點。反觀國內的網際網路公司和創新工場，管理層和創業團隊很少去主動將價值傳遞到研發團隊。很多研發團隊也是接到需求就開始評估怎麼做，不問為什麼做，也從來不問價值，就算問了，也只是要求排個優先順序而已。這種對企業價值和商業本質的漠視，也導致了技術團隊缺乏大局觀，而只是反過來要求產品做出一個不靠譜的年度規劃來預估架構上的合理性。放眼目前的商業環境，都是在不停的市場契機中發現商機，如果靠產品經理或是公司老大就能正確的判斷公司未來一年的產品路線，那為什麼整個中國成功的公司還就是那麼幾家？做正確的事，永遠比正確的做事更重要。
從尊重人的角度出發，公司的管理層首先要放低姿態，承認自己也會犯錯，並將商業目標和價值要求，通暢地傳達到研發團隊。而研發團隊在面對需求時，需要多問幾個為什麼要做，敢於質疑價值不明確的需求。
目前在我所在的公司，推行的是對於大中型需求，需要提供《商業畫布》和《價值時分表》，通過這兩個文件的討論，明確需求的價值和實現的急迫性，並從中提取需求實現後的上線跟蹤指標。這兩個工具來自於《精益創業》這本書。感興趣的童鞋，可以去看看這本書，很經典。
2、消除浪費
在我們做一項商業決策時，往往是憑藉過去的經驗和有限的試驗及資料做出的假設。這本身沒有錯，而往往人們犯的錯誤就是：忽視了驗證這個假設能夠承受多大的成本。合適的時間，用合適的成本去做合適的事，這也是風口上的豬也能飛那句話原本的意思。
說道理有點枯燥，舉個例子吧：
我所在的公司，曾經在B2B快消品市場上，投入過一個業務員端的產品。當時這個產品是給公司內部業務員用的，在開拓外區市場時，根據市場人員的調研和相關領導的從業經驗，一致覺得外部快消廠商和經銷商是需要這個產品的。所以咯，二話不說，為了搶佔先機，為了做那個風口上的豬。產品率先將業務員端做了改造，適配了外部經銷商和廠家業務員的模式，還沒等投入到市場，這個專案就因為種種原因而收縮，取消了與外部的合作。還好當初留了個心眼，只做了個簡單的適配，但也耗費了一個迭代（三週）的成本。從敏捷來看，專案本身一點沒有問題，但從商業價值來看，成本的浪費不言而喻。
可能大家看到這裡，會有很多疑問：唉，商業價值又不是研發說了算的，領導決定的啊，運營的鍋啊，產品的債啊。但回想一下，如果敏捷不能創造價值，那團隊的價值如何體現？
因此，當我們在假設一個價值目標時，要遵循的是成本最小和決策推遲原則。譬如，先來遍線下先行的驗證怎麼樣，我堆兩個實習生天天收集資料在excel統計分析後，發在廠家和經銷商的業務員的微信群可不可以。這樣浪費的成本孰高孰低，一目瞭然，行不通止損也快。也不用後面我們又要考慮把這一套程式碼下線，避免後續還要付出維護成本要來得划算。
3、推遲決策
推遲決策並非官僚，也不是將責任推諉至他人，而是因為太多拍腦袋和屁股所做的商業決定所帶來的高昂實現成本，造成了大量的浪費。而提前決策恰恰違反了第2條的“消除浪費”。
推遲決策的時間點：決策的最佳響應時間點是指，做出決策的成本跟推遲決策造成的損失大致相當的時間點。
推遲決策的實踐：在敏捷中，有一個推遲決策的最佳實踐：真實期權。聽起來挺拗口，下面簡單解釋下。
期權大家都知道，而真實期權大家拆成“真實”和“期權”兩部分來看，即針對專案在分階段投入成本的情況下，我們需要有在特定條件下的對各階段所擁有的三種投資成本的方式：一是放棄投資（即條件不成熟）；二是繼續投資（即達到此階段的約定條件）；三是重新評估未達到的條件，決定是否變更條件或減少投資規模。這些實踐，有部分來自於金融期權的數學模型，有部分來源於決策心理學。歸根結底，是指在決策時，需要滿足事先約定的條件並瞭解決策所需要的原因後，再做決策。真實期權的終止日是條件性的而非契約性，你可以延後期權的終止日，直到發現最優解，從概率上來看，推遲決策要比提前決策更能提供價值。
舉個例子：公司即將開始一個全新的平臺引流專案，我們有一個商業目標，希望通過產品來實現日均50萬的PV和>=10%的訂單轉化率，公司以前沒有類似的經驗可以借鑑，即使有人有相應的經驗，在這個平臺上也從未實踐過。
傳統意義上的專案，應該是開始商業計劃書，然後PRD，然後專案實現並上線驗證。在這裡，就埋下了決策陷阱：一開始的目標推匯出來的商業計劃書中的成本產生的ROI，頂多是個估算，誰來為估算的決策埋單?我相信沒有一個人是有100%的信心和承諾去做這個決策的，即使是計劃做得再好，憑經驗做出來的也滿足不了隨時變化的市場和社會環境的變化。那些商業大V給的無非是天花亂墜的計劃如何做得詳細分解，而這並非投資的最佳路徑。
真實的世界裡，我們要將決策帶來的成本損失減到最少。因此，好的做法，在面對一個不可知的目標時，是將目標拆分成不同的階段，這個專案因為未知因素太多，但又需要快速推進的話，應該是在商業計劃成型之前，做一次小規模的驗證，這個驗證應該是針對特定的極少部分種子使用者，並利用現成的最小化成本（H5工具生成的落地頁、現有平臺產品的簡單對接）去實現，觀察預定的指標，總結是否需要調整變現路徑和方法，再形成完整的可推論的商業計劃（BRD）並劃分階段和成本，然後才是分階段實施的PRD和條件。有了這樣一個先驗過程並將階段驗證條件做為下一階段的決策依據，才能更好的迎接在過程中不斷變化的問題，並最終以最合理化的成本和收益達到專案目標（雖然專案目標可能會調整，但也是基於真實驗證下的調整，而且成本並未浪費）。
因此，推遲決策並非不決策，而是在有先決條件下分階段去實現專案目標，決定是繼續按計劃做，還是終止，或是變更下條件適當投入再看看。
任何一本軟體工程教材都會告訴你：假設在分析階段找到並解決一個錯誤的成本為1，在設計階段解決同一個錯誤的成本就變成10，在實現階段就變成100，在維護階段就變成1000。敏捷軟體開發中的真實期權實踐正是為了避免不正確決策所帶來的浪費。
4、建立知識
在敏捷團隊中，傳遞知識是一項細微並且不會短期內看到收益的工作。但是一旦真正建立了一個人人願意維護的知識庫，哪怕這個知識庫是存在於程式碼的規範性註釋之上，帶來的收益和價值往往隨著時間的推移而越來越有價值。
這裡需要說明的是，團隊需要有一些激勵機制和自己總結的適用方法，利用現有的知識構建工具譬如wiki、規範化程式碼註釋、甚至是檔案伺服器上，將知識點先沉澱上去，再進行歸納和分類後，從而進行提取、再加工，並落實到由這些知識點產生的改良活動中，並再反饋到知識庫中。
這需要領導者鼓勵並長期關注知識庫的質量，並激勵團隊做出知識貢獻，打造學習的氛圍。
而對於進入專案前的售前和需求分析過程，往往藉助的是知識庫中的兩個類別的知識：專案度量、風險庫。
在實際知識沉澱過程，需要特別注意這兩個方面知識的總結和歸納，並交待好事件的前因後果和Action的結果。專案度量可以幫助分析和市場人員，大致的評估專案成本和週期（在樂觀和悲觀兩個維度下）。而風險庫，是在專案啟動前一次最好的檢驗專案風險的實踐活動，並且，隨著知識庫中風險點不斷的積累和歸納，檢查的清單會越來越詳盡，會盡可能的讓你避免拍腦袋決策所帶來的失敗因子。
5、快速交付
一旦決策下達，團隊的快速交付就顯得重要了。這個階段其實就是一個核心"儘早、持續交付有價值的軟體，是我們滿足客戶的最優先考慮"。這個階段中，尤為重要的是需求分析。成功的專案各有不同，但失敗的專案卻總是那麼相似。這當然是句無限抽象的戲說，但需求分析的偏差和模糊往往是重要的原因。回到本章的重點，快速交付在敏捷的售前階段好像沒有任何關係，但如果我們把任何一個專案階段（售前、立項、分析、設計、實現、部署、運維）拆開來看，每個階段其實都有交付，而且仍然可以圍繞”儘早、持續交付有價值的軟體“這一核心。
舉個例子：
某大型證券公司，我們有多個團隊為此公司進行專案開發。甲方決策人，通常希望看到有成型的可演示demo才決定是否由我們承接，這個過程在以前，會由乙方團隊趕鴨子上架一樣在現有框架和平臺下搭一個按甲方領導意思想看的demo，往往還涉及到需要走一些簡單的設計和測試工作，等花上一週甚至兩週多給領導看時，還要擔心會議上是否時不時報個錯，會不會在會議上又提出新的想法。後來，我們經過討論，發現人家根本不關心你這套demo後面是否有真實的資料進入系統，就是看看點選後介面的互動和跳轉是否按他的想法來，demo中有沒有更好的亮點或解決思路。想通之後就簡單了，改用axure上吧，對於有比較複雜的邏輯和流程要求的，實在不行就用靜態頁面整，也比要構建一套需要持久化資料的系統快，畢竟客戶只看效果才決定接下來是不是交給你做。這樣我們不僅將演示週期縮短到了平均三天左右，而且反饋給客戶的速度相應的大大提高，客戶的滿意度也上來了，會上有個什麼改動，回來後調整下原型，也頂多就是半天的時間而已。
6、品質為先
敏捷強調通過測試驅動、自動化工具建立可持續化、日常化的質量檢測方法。在售前工作中，我們需要避免的是銷售人員為了迎合客戶需求，漫天畫餅卻給出一個奇低的價格。
因此，在售前階段，銷售的方案和demo必須要和技術團隊中的負責人過一下，並且通過知識庫判斷大至的成本。關於成本判斷的方法，後續章節會有一篇專門介紹。
一個有說服力、邏輯嚴密的售前方案，對客戶來說一是意味著有落地的把握，二是解答了從目標到實現的各個清晰的路徑（目標、範圍、業務邏輯分析、模組分析、難點分析、專案管理分析、專案預估算），三是回答了專案中確實存在的大機率風險如何避免。如果不能成，並不代表你的價格不合適，只是因為其它非商業原因而落選（你懂的）。相反，藉助這些有質量的方案，當客戶真的想做點有價值的事情時，一定會考慮你，所以你在後續還有大量的高價值專案可以介入。
7、全域性優化
有關於精益管理的介紹，請點選我的另一篇培訓文章《精益產品思想》。同時放上一個參考連結：精益的智庫百科連結
CMM對售前的模糊
CMM的成熟度模型，更加偏重於專案的執行過程。與敏捷類似，都是假設有一個已立項、清晰的專案目標的前提下，如何按最佳實踐去實現專案目標。
限於篇幅，我只舉一些CMM中在售前遇到的侷限的案例：
CMM也好，CMMI也罷。對售前的過程域，比較匹配的還是需求管理的過程域，這個過程域強調的是需求理解的一致性。
實際專案中，我們承接過一個大型集團的協同平臺，在售前階段，甲方提出了一個很巨集大的規劃，如果用我上面的快速交付法顯示不合適了，估計要畫幾百頁原型才能滿足。這個時候，首先澄清使用者的目標，和專案範圍後，才能為接下來的有價值交付鋪平道路。因此，接下來的一週，我們並沒有提交方案，而是按照初次訪談得到的規劃資訊，和技術負責人一起，對甲方資訊中心的關鍵人員做了一輪訪談，並邀請甲方參觀了一些類似的客戶專案。取得信任後，我們在甲方的支援和協助下，對業務部門的核心人員做了一輪訪談，再根據這些資訊和訪談紀要，輸入出了一份長達98頁，裝訂成兩冊（一冊為專案建設方案建議，一冊為方案圖集）的檔案，影印了10份（沒給電子檔）交給甲方資訊中心和各部門查閱，我們分別約時間在會前收集意見並反饋和修訂，並在接下來的會議中通過討論，明確了目標的範圍和優先順序，確定了各個階段的里程碑和輸入條件後，以第一階段為重點，才開始製作demo和原型。這個專案最終的招標技術部分，實際上就是按我們提供的專案建議方案書來的，甲方也非常信任我們前期做的詳細分析確實能落地，並且也看到了部分核心功能的原型，感覺非常靠譜，在投標評審中，傾向性給我們打了最高分（沒有任何貓膩），其它公司倒不是不努力，不過大多是憑過往經驗，x軟甚至copy了一份在其它集團投標的技術標檔案，很多地方完全不符合甲方的實際業務場景。從這個故事中，不難看出，我們即使在售前，對需求的澄清是相當慎重的，通過合理的成本付出（方案建議->原型）給使用者不斷提供分階段的價值輸出，明確專案範圍，落實專案的可行性，從而為後續專案的開展提供了良好的可落地基礎
專案能否成功取決於售前/商業計劃
傳統軟體管理重視開發過程管理，而一旦開始立項，成本會直線上升。企業的成本永遠是有限的，如何避免在大規模投入之前，先小規模驗證一遍是否可行，分期投入，按階段決策。在目前的創新創業大潮中就顯得尤為重要。
一家企業的初創資金總是有限的，好比一條100米長的跑道，中間沒有任何標識，而且跑道上佈滿了商業和市場的一切不確定的因素（競爭迷霧）。每跨一步，很多人認為就離目標近一步，實際上就算方向對了，中間有沒有路障，裁判會不會吹黑哨，路上有沒有石頭和陷阱，這一切都是未知的，你跑得越快可能摔得越重，也可能當你衝刺跑完用盡力氣（資金）時才發現偏了那麼幾米錯過了終點線。
所以試錯，還得加一句，在最小成本下去試錯。推遲你的投資決策，只到條件顯現足夠你去決策時再做。想要贏，先得活。
往前推是過程管理的精髓
其實，專案管理的精髓無外乎就一條，將過程中的活動儘量向前推，不光是開發、測試、整合、維護，甚至包括了我們都忽略了但其實決定了成敗的售前/商業計劃。把活動往前推，小規模的利用原型、自動化工具、測試驅動等一切方法去驗證，拿到的驗證條件越早越好，這樣才能避免在後續的專案過程中由屁股決定腦袋、憑經驗臆測的決定，開發完成後才發現行不通而等待轉向或衰落要好。
從概率上講，將錯誤越早暴露，成本越低。而決策儘量在條件顯現時決定，專案成功性更大。