很是道-中小軟件公司項目管理（4.1 項目啓動並不是項目的起點）

傳統項目管理，不管是典型的軟件銷售服務類型、仍是互聯網軟件公司。在過程管理中，一般是從需求輸入開始。這當中形成的誤判範圍、過分承諾、信息傳遞變形甚至黑洞的狀況家常便飯。不管企業中是否有諸如PMO或是項目管理委員會這樣的組織，大多數都忽視了需求並不是憑空而來，從組織和成本角度上去，不管是創新類公司仍是擁有成熟市場的公司，都應當把需求從售前（需求產生）之時進行度量和梳理。有一句老話「假設（需求）什麼都不是，只有當它可以被證僞或證明，纔有價值」，有了價值，纔會有去實現的必要。

敏捷對售前(需求價值)的侷限

傳統的敏捷宣言，只關注了在項目過程當中，團隊如何保證需求價值的實現，如何交付價值。即敏捷首先假設的是這個項目（需求）的價值是存在的，依據這個價值依據，在項目過程當中持續交付可評估的產品，以達到接近用戶真實需求價值的目標。

咱們不妨追問一下敏捷的本質是什麼，敏捷宣言的核心價值告訴你們是以下四條

• 個體和互動  高於  流程和工具
• 工做的軟件  高於  詳盡的文檔
• 客戶合做      高於  合同談判
• 響應變化     高於  遵循計劃

就這四條核心價值來說，更加貼近於軟件開發中的過程管理。就真正的項目全生命週期來看，敏捷忽視了項目啓動以前的價值假設過程，若是這個需求的價值假設在商業模式or成本預期or客戶（運營）YY之上的，你再怎麼努力敏捷也不過是多走幾步仍是少走幾步掉坑的結局罷了。你們捫心自問一下，你所從事的敏捷項目，有多少是從開始就將商業價值和企業目標與敏捷項目結合起來進行管理的。

軟件開發團隊一般重視的項目的成功交付和驗收，而非項目是否真正爲企業（用戶）創造了價值。不管是項目型公司仍是互聯網公司，開發團隊一般在短時間上對項目交付最重視，而從長期看，交付一堆沒有達到預期價值甚至毫無價值的產品（功能）時，對團隊的損害要遠遠超過儘早識別不具有價值不須要交付的危害。

那麼如何將敏捷擴展到項目啓動以前，進行項目全生命週期的敏捷管理呢。這個問題，目前有一個流派，就是將精益思想與敏捷相結合，將企業的價值目標與敏捷過程管理相結合，將商業價值與團隊動態管理相結合，重視產品交付價值自己而非項目成功，雙方共同在價值最大化的目標和框架下協同工做。經過精益思想的7項原則，很大程度上避免了敏捷對企業（用戶）價值層面的假設推論確認過早的問題。

這幾個原則的重要性依次以下

一、尊重人

這裏的尊重人，來自於精益和敏捷思想中的核心：相信創新來自於人的主動性，而非機器。即便是在精益的發源地豐田，這個流水線的工廠內，也奉行人的主觀創造力是第一輩子產力的觀點。反觀國內的互聯網公司和創新工場，管理層和創業團隊不多去主動將價值傳遞到研發團隊。不少研發團隊也是接到需求就開始評估怎麼作，不問爲何作，也歷來不問價值，就算問了，也只是要求排個優先級而已。這種對企業價值和商業本質的漠視，也致使了技術團隊缺少大局觀，而只是反過來要求產品作出一個不靠譜的年度規劃來預估架構上的合理性。放眼目前的商業環境，都是在不停的市場契機中發現商機，若是靠產品經理或是公司老大就能正確的判斷公司將來一年的產品路線，那爲何整個中國成功的公司還就是那麼幾家？作正確的事，永遠比正確的作事更重要。

從尊重人的角度出發，公司的管理層首先要放低姿態，認可本身也會犯錯，並將商業目標和價值要求，通暢地傳達到研發團隊。而研發團隊在面對需求時，須要多問幾個爲何要作，勇於質疑價值不明確的需求。

目前在我所在的公司，推行的是對於大中型需求，須要提供《商業畫布》和《價值時分表》，經過這兩個文檔的討論，明確需求的價值和實現的急迫性，並從中提取需求實現後的上線跟蹤指標。這兩個工具來自於《精益創業》這本書。感興趣的童鞋，能夠去看看這本書，很經典。

二、消除浪費

在咱們作一項商業決策時，每每是憑藉過去的經驗和有限的試驗及數據作出的假設。這自己沒有錯，而每每人們犯的錯誤就是：忽視了驗證這個假設可以承受多大的成本。合適的時間，用合適的成本去作合適的事，這也是風口上的豬也能飛那句話本來的意思。

說道理有點枯燥，舉個例子吧：

我所在的公司，曾經在B2B快消品市場上，投入過一個業務員端的產品。當時這個產品是給公司內部業務員用的，在開拓外區市場時，根據市場人員的調研和相關領導的從業經驗，一致以爲外部快消廠商和經銷商是須要這個產品的。因此咯，二話不說，爲了搶佔先機，爲了作那個風口上的豬。產品率先將業務員端作了改造，適配了外部經銷商和廠家業務員的模式，還沒等投入到市場，這個項目就由於種種緣由而收縮，取消了與外部的合做。還好當初留了個心眼，只作了個簡單的適配，但也耗費了一個迭代（三週）的成本。從敏捷來看，項目自己一點沒有問題，但從商業價值來看，成本的浪費不言而喻。

可能你們看到這裏，會有不少疑問：唉，商業價值又不是研發說了算的，領導決定的啊，運營的鍋啊，產品的債啊。但回想一下，若是敏捷不能創造價值，那團隊的價值如何體現？

所以，當咱們在假設一個價值目標時，要遵循的是成本最小和決策推遲原則。譬如，先來遍線下先行的驗證怎麼樣，我堆兩個實習生每天收集數據在excel統計分析後，發在廠家和經銷商的業務員的微信羣可不能夠。這樣浪費的成本孰高孰低，一目瞭然，行不通止損也快。也不用後面咱們又要考慮把這一套代碼下線，避免後續還要付出維護成本要來得划算。

三、推遲決策

推遲決策並不是官僚，也不是將責任推諉至他人，而是由於太多拍腦殼和屁股所作的商業決定所帶來的高昂實現成本，形成了大量的浪費。而提早決策偏偏違反了第2條的「消除浪費」。

推遲決策的時間點：決策的最佳響應時間點是指，作出決策的成本跟推遲決策形成的損失大體至關的時間點。

推遲決策的實踐：在敏捷中，有一個推遲決策的最佳實踐：真實期權。聽起來挺拗口，下面簡單解釋下。

期權你們都知道，而真實期權你們拆成「真實」和「期權」兩部分來看，即針對項目在分階段投入成本的狀況下，咱們須要有在特定條件下的對各階段所擁有的三種投資成本的方式：一是放棄投資（即條件不成熟）；二是繼續投資（即達到此階段的約定條件）；三是從新評估未達到的條件，決定是否變動條件或減小投資規模。這些實踐，有部分來自於金融期權的數學模型，有部分來源於決策心理學。歸根結底，是指在決策時，須要知足事先約定的條件並瞭解決策所須要的緣由後，再作決策。真實期權的終止日是條件性的而非契約性，你能夠延後期權的終止日，直到發現最優解，從機率上來看，推遲決策要比提早決策更能提供價值。

舉個例子：公司即將開始一個全新的平臺引流項目，咱們有一個商業目標，但願經過產品來實現日均50萬的PV和>=10%的訂單轉化率，公司之前沒有相似的經驗能夠借鑑，即便有人有相應的經驗，在這個平臺上也從未實踐過。

傳統意義上的項目，應該是開始商業計劃書，而後PRD，而後項目實現並上線驗證。在這裏，就埋下了決策陷阱：一開始的目標推導出來的商業計劃書中的成本產生的ROI，頂可能是個估算，誰來爲估算的決策埋單?我相信沒有一我的是有100%的信心和承諾去作這個決策的，即便是計劃作得再好，憑經驗作出來的也知足不了隨時變化的市場和社會環境的變化。那些商業大V給的無非是天花亂墜的計劃如何作得詳細分解，而這並不是投資的最佳路徑。

真實的世界裏，咱們要將決策帶來的成本損失減到最少。所以，好的作法，在面對一個不可知的目標時，是將目標拆分紅不一樣的階段，這個項目由於未知因素太多，但又須要快速推動的話，應該是在商業計劃成型以前，作一次小規模的驗證，這個驗證應該是針對特定的極少部分種子用戶，並利用現成的最小化成本（H5工具生成的落地頁、現有平臺產品的簡單對接）去實現，觀察預約的指標，總結是否須要調整變現路徑和方法，再造成完整的可推論的商業計劃（BRD）並劃分階段和成本，而後纔是分階段實施的PRD和條件。有了這樣一個先驗過程並將階段驗證條件作爲下一階段的決策依據，才能更好的迎接在過程當中不斷變化的問題，並最終以最合理化的成本和收益達到項目目標（雖然項目目標可能會調整，但也是基於真實驗證下的調整，並且成本並未浪費）。

所以，推遲決策並不是不決策，而是在有先決條件下分階段去實現項目目標，決定是繼續按計劃作，仍是終止，或是變動下條件適當投入再看看。

任何一本軟件工程教材都會告訴你：假設在分析階段找到並解決一個錯誤的成本爲1，在設計階段解決同一個錯誤的成本就變成10，在實現階段就變成100，在維護階段就變成1000。敏捷軟件開發中的真實期權實踐正是爲了不不正確決策所帶來的浪費。

四、建立知識

在敏捷團隊中，傳遞知識是一項細微而且不會短時間內看到收益的工做。可是一旦真正創建了一我的人願意維護的知識庫，哪怕這個知識庫是存在於代碼的規範性註釋之上，帶來的收益和價值每每隨着時間的推移而愈來愈有價值。

這裏須要說明的是，團隊須要有一些激勵機制和本身總結的適用方法，利用現有的知識構建工具譬如wiki、規範化代碼註釋、甚至是文件服務器上，將知識點先沉澱上去，再進行概括和分類後，從而進行提取、再加工，並落實到由這些知識點產生的改良活動中，並再反饋到知識庫中。

這須要領導者鼓勵並長期關注知識庫的質量，並激勵團隊作出知識貢獻，打造學習的氛圍。

而對於進入項目前的售前和需求分析過程，每每藉助的是知識庫中的兩個類別的知識：項目度量、風險庫。

在實際知識沉澱過程，須要特別注意這兩個方面知識的總結和概括，並交待好事件的來龍去脈和Action的結果。項目度量能夠幫助分析和市場人員，大體的評估項目成本和週期（在樂觀和悲觀兩個維度下）。而風險庫，是在項目啓動前一次最好的檢驗項目風險的實踐活動，而且，隨着知識庫中風險點不斷的積累和概括，檢查的清單會愈來愈詳盡，會盡量的讓你避免拍腦殼決策所帶來的失敗因子。

五、快速交付

一旦決策下達，團隊的快速交付就顯得重要了。這個階段其實就是一個核心"儘早、持續交付有價值的軟件，是咱們知足客戶的最優先考慮"。這個階段中，尤其重要的是需求分析。成功的項目各有不一樣，但失敗的項目卻老是那麼類似。這固然是句無限抽象的戲說，但需求分析的誤差和模糊每每是重要的緣由。回到本章的重點，快速交付在敏捷的售前階段好像沒有任何關係，但若是咱們把任何一個項目階段（售前、立項、分析、設計、實現、部署、運維）拆開來看，每一個階段其實都有交付，並且仍然能夠圍繞」儘早、持續交付有價值的軟件「這一核心。

舉個例子：

某大型證券公司，咱們有多個團隊爲此公司進行項目開發。甲方決策人，一般但願看到有成型的可演示demo才決定是否由咱們承接，這個過程在之前，會由乙方團隊趕鴨子上架同樣在現有框架和平臺下搭一個按甲方領導意思想看的demo，每每還涉及到須要走一些簡單的設計和測試工做，等花上一週甚至兩週多給領導看時，還要擔憂會議上是否時不時報個錯，會不會在會議上又提出新的想法。後來，咱們通過討論，發現人家根本不關心你這套demo後面是否有真實的數據進入系統，就是看看點擊後界面的交互和跳轉是否按他的想法來，demo中有沒有更好的亮點或解決思路。想通以後就簡單了，改用axure上吧，對於有比較複雜的邏輯和流程要求的，實在不行就用靜態頁面整，也比要構建一套須要持久化數據的系統快，畢竟客戶只看效果才決定接下來是否是交給你作。這樣咱們不只將演示週期縮短到了平均三天左右，並且反饋給客戶的速度相應的大大提升，客戶的滿意度也上來了，會上有個什麼改動，回來後調整下原型，也頂多就是半天的時間而已。

六、品質爲先

敏捷強調經過測試驅動、自動化工具創建可持續化、平常化的質量檢測方法。在售前工做中，咱們須要避免的是銷售人員爲了迎合客戶需求，漫天畫餅卻給出一個奇低的價格。

所以，在售前階段，銷售的方案和demo必需要和技術團隊中的負責人過一下，而且經過知識庫判斷大至的成本。關於成本判斷的方法，後續章節會有一篇專門介紹。

一個有說服力、邏輯嚴密的售前方案，對客戶來講一是意味着有落地的把握，二是解答了從目標到實現的各個清晰的路徑（目標、範圍、業務邏輯分析、模塊分析、難點分析、項目管理分析、項目預估算），三是回答了項目中確實存在的大機率風險如何避免。若是不能成，並不表明你的價格不合適，只是由於其它非商業緣由而落選（你懂的）。相反，藉助這些有質量的方案，當客戶真的想作點有價值的事情時，必定會考慮你，因此你在後續還有大量的高價值項目能夠介入。

 

七、全局優化

有關於精益管理的介紹，請點擊個人另外一篇培訓文章《精益產品思想》。同時放上一個參考連接：精益的智庫百科連接

 

CMM對售前的模糊

CMM的成熟度模型，更加偏重於項目的執行過程。與敏捷相似，都是假設有一個已立項、清晰的項目目標的前提下，如何按最佳實踐去實現項目目標。

限於篇幅，我只舉一些CMM中在售前遇到的侷限的案例：

CMM也好，CMMI也罷。對售前的過程域，比較匹配的仍是需求管理的過程域，這個過程域強調的是需求理解的一致性。

實際項目中，咱們承接過一個大型集團的協同平臺，在售前階段，甲方提出了一個很宏大的規劃，若是用我上面的快速交付法顯示不合適了，估計要畫幾百頁原型才能知足。這個時候，首先澄清用戶的目標，和項目範圍後，才能爲接下來的有價值交付鋪平道路。所以，接下來的一週，咱們並無提交方案，而是按照初次訪談獲得的規劃信息，和技術負責人一塊兒，對甲方信息中心的關鍵人員作了一輪訪談，並邀請甲方參觀了一些相似的客戶項目。取得信任後，咱們在甲方的支持和協助下，對業務部門的核心人員作了一輪訪談，再根據這些信息和訪談紀要，輸入出了一份長達98頁，裝訂成兩冊（一冊爲項目建設方案建議，一冊爲方案圖集）的文件，影印了10份（沒給電子檔）交給甲方信息中心和各部門查閱，咱們分別約時間在會前收集意見並反饋和修訂，並在接下來的會議中經過討論，明確了目標的範圍和優先級，肯定了各個階段的里程碑和輸入條件後，以第一階段爲重點，纔開始製做demo和原型。這個項目最終的招標技術部分，實際上就是按咱們提供的項目建議方案書來的，甲方也很是信任咱們前期作的詳細分析確實能落地，而且也看到了部分核心功能的原型，感受很是靠譜，在投標評審中，傾向性給咱們打了最高分（沒有任何貓膩），其它公司倒不是不努力，不過大可能是憑過往經驗，x軟甚至copy了一份在其它集團投標的技術標文件，不少地方徹底不符合甲方的實際業務場景。從這個故事中，不難看出，咱們即便在售前，對需求的澄清是至關慎重的，經過合理的成本付出（方案建議->原型）給用戶不斷提供分階段的價值輸出，明確項目範圍，落實項目的可行性，從而爲後續項目的開展提供了良好的可落地基礎

項目可否成功取決於售前/商業計劃

傳統軟件管理重視開發過程管理，而一旦開始立項，成本會直線上升。企業的成本永遠是有限的，如何避免在大規模投入以前，先小規模驗證一遍是否可行，分期投入，按階段決策。在目前的創新創業大潮中就顯得尤其重要。

一家企業的初創資金老是有限的，比如一條100米長的跑道，中間沒有任何標識，並且跑道上佈滿了商業和市場的一切不肯定的因素（競爭迷霧）。每跨一步，不少人認爲就離目標近一步，實際上就算方向對了，中間有沒有路障，裁判會不會吹黑哨，路上有沒有石頭和陷阱，這一切都是未知的，你跑得越快可能摔得越重，也可能當你衝刺跑完用盡力氣（資金）時才發現偏了那麼幾米錯過了終點線。

因此試錯，還得加一句，在最小成本下去試錯。推遲你的投資決策，只到條件顯現足夠你去決策時再作。想要贏，先得活。

往前推是過程管理的精髓

其實，項目管理的精髓無外乎就一條，將過程當中的活動儘可能向前推，不光是開發、測試、集成、維護，甚至包括了咱們都忽略了但其實決定了成敗的售前/商業計劃。把活動往前推，小規模的利用原型、自動化工具、測試驅動等一切方法去驗證，拿到的驗證條件越早越好，這樣才能避免在後續的項目過程當中由屁股決定腦殼、憑經驗臆測的決定，開發完成後才發現行不通而等待轉向或衰落要好。

從機率上講，將錯誤越早暴露，成本越低。而決策儘可能在條件顯現時決定，項目成功性更大。