【轉載】40人月變更的秘密

前一陣聽老總說ZHANYA項目組做的一個項目工作量170個人月，變更工作量40個人月，項目組向使用者要到了接近25%的變更。

他們是怎麼做到的？有什麼秘訣？這些疑問勾起了我的好奇心，於是乎伺機抓住ZHAN和XIAOLIN“嚴刑審問”了一番。現將交流內容結合個人經驗提煉加工“昭告天下”。

一、40個人月裡有什嗎？

謹尊偉大領袖毛主席“沒有調查就沒有發言權”的教導，仔細向XIAOLIN調查了40個人月的來龍去脈。其中最大一塊28個人月是由於業務介面人提出的需求並不滿足終端使用者要求引起的一次性變更，其中一個模組幾乎是推倒重來。其他12個人月是系統實現修改積累而成。

二、12個人月的積累

XIAOLIN坦白“交代”12個人月的變更是自己一天一天向業主方爭取積累而來。

“憑什麼你認為是變更？”。XIAOLIN採用先兵後禮的策略把醜話放在前面，早在需求調研時就向使用者說明在什麼情況下要走變更，並取得使用者的認可。然後在需求調研將要結束時向業主方明確需求調研結束後一切需求的變動都要算作變更，就是要在業主方的腦袋裡面畫一條線，過了這條線是要計劃外的開銷來彌補的。很多時候業主方，尤其是業務介面方（IT管理）與需求提出方（真正業務部門）不是同一人的情況下，對變更的界定概念不是很清楚，有些甚至都不知道變更是什麼，這就有必要向他們做個“普法”宣傳，避免以後的爭執和衝突，也可以讓業主方協助我們控制好變更。 XIAOLIN就表示之前的項目中就出現過需求提出方與業務介面方不是同一人，需求調研結束後需求提出方還不斷提新需求及改變老需求，後來算變更時需求提出方又不認為是變更與我方爭執的情況。

“為什麼要這麼多工作量？給個理由先！”。XIAOLIN他們在與業主方交涉時，工作量申報細化到了半天，給出業主方的變更影響了哪些代碼，需要做哪些工作，讓業主方無法質疑。對這一點我是有深刻體會的，一次跟業主方要變更，我方申報的工作量不詳細有漏洞，被業主方當場找出破綻，結果業主方就對我們的整體工作量產生了懷疑，最後計劃13天的變更業主方    只認可5天。

“豪爽點，各讓一步，工作量就少算點！”這時候怎麼辦？各位會怎麼做呢？讓我們看看ZHANYA他們是怎麼做的：一點不讓！嚇了我一跳，業主方都這樣說了，你還不就坡下驢？ZHANYA當時就說你讓了就讓對方懷疑你還可以退，你既然可以讓2天為什麼不能讓7天，你都讓了7天了是不是工作量有水分？所以堅決不讓，軟硬不吃刀槍不入！

三、28個人月的聯想

在項目中常常會遇到提出需求的業主方並不是系統最終使用者，產生需求介面人提出的需求與實際使用者有偏差的情況，這也往往是較大變更量發生的原因，XIAOLIN28個人月也是這麼來的。遇到這種情況大家會怎麼辦？ 談談我的想法。

首先需求階段就要儘可能的把系統最終使用者納入到需求調研的範圍中，道理相信大家都明白。

其次系統開發階段，最好能夠增加原型設計內容，把操作方式和頁面整體布局與實際使用者達成一致。系統每一個階段性開發完成後都要向終端使用者及業務介面人示範，記錄下大家的意見，再區分修改還是變更，不要等到最後系統整體功能完善後再去示範，就好比大家抱著顆定時炸彈，你是等到時間到了和它一起同歸於盡呢，還是自己動手先拆引信逃生呢？而且過了正常生產時間，組織再生產的話成本也會比前者高很多。

 

其實很多同事對跟業主要工作量顧慮很多，怕影響客戶關係、怕與客戶衝突。其實我們不去爭取就是在給業主方培養一種潛意識“他們會滿足我的任何要求”而不顧及成本。我們爭取變更的目的也並不只是為了“吃”業主方那點工作量，而是將項目前期已經定好的工作範圍和項目成本轉化為對業主方實實在在的約束之一，在使用者對系統產生過高的期望或激情的時候能給他們降降溫，保證項目的成功。協助使用者控制好變更，讓他們真真切切感覺到我們是為他們著想，自然就會信任我們，依賴我們，這也正是我們比別人專業的地方。大家是如何看待這個問題的呢？