老翅寒暑

項目管理沙龍第三次聚會紀要--模式“玩就是心跳”

聚會開始之前先強調了參與沙龍的要點：與會者都是有經驗的項目管理者，既然大家都想通過聚會來獲得一些知識和經驗，那么每個人都要積極地想辦法去引導其他人與自己交流，在這個沙龍里，等待和被動是沒有意義的。

《項目百態(tài): 深入理解軟件項目行為模式》是一本得到jolt大獎的書。它歸納出來項目管理中經常出現的86個模式，這些模式有些是正模式（就是好的做法），但是大部分都是反模式，就是不好的模式。這些模式普遍存在于各個項目組中，我們公司也當然不例外。

"玩的就是心跳"（adrenaline junkie）是這本書的第一個模式，從http://book.51cto.com/art/201101/244194.htm可以閱讀，它是一個反模式，說的是一種項目組的類型。該型組織的特點就是：“優(yōu)先級總是變化不休，所有事項都是"昨天"就要，總是沒有足夠的時間交付項目，所有項目都是緊迫項目，緊迫的項目源源不斷。每個人都忙得焦頭爛額……永遠如此。” 沙龍的每個成員都對這種類型的“忙碌”深有感觸。

“這些組織里面的人不會從戰(zhàn)略層次上思考問題，只是按照緊迫程度來完成工作”，這句話引發(fā)了我們的討論。

很明顯，這種類型的項目組存在的原因之一是沒有優(yōu)先級，經過其他人的補充，確切地說項目組無法得到優(yōu)先級，因為客戶通常也搞不清楚哪一個優(yōu)先級較高。所以很多時候，客戶就會要求項目組盡快給出一個東西給他看看。在前幾次沙龍我們已經談到了“客戶經常是不知道自己要什么，但是知道自己不要什么”，正是因為這個原因，“原型法”在這里應用的效果就會很好。

客戶通過原型就可以直觀地看到自己未來所要接觸的軟件是什么樣子和擁有什么功能，而且原型還可以刺激客戶進一步思考，發(fā)掘出一些未曾想到的需求，甚至出現“需求爆炸”。有與會者提出要防止用戶這樣的聯(lián)想，擔心這樣的需求過多可能對項目不利，但是經過討論，我們一直認為“需求爆炸”是一件好事。

通常的項目接單流程是這樣的：客戶接觸、訂立合同、需求調研、系統(tǒng)設計、編碼、測試、交付。事實上，大部分中國的公司忽視了需求調研的階段，而是在項目邊開發(fā)邊設計邊調研需求，這就意味著“需求爆炸”通常是在項目進行過程中出現的，毫無疑問，“返工”就出現了，問題也就來了。

如果我們保留了需求調研階段，同時使用“原型法”來引導客戶需求，結合客戶需求的優(yōu)先級評估，在調研結束之后，我們基本可以掌握60%甚至更多的客戶需求。然后對每一個需求評估出來優(yōu)先級，形成一個列表放在客戶的面前。不要擔心客戶會讓你實現所有的列表中的需求，除非這是個本來就想著只花10萬元讓你做一個淘寶的家伙，否則他一定會捏著錢包來選擇他想要實現的功能需求的。

我們使用scrumworks中的優(yōu)先級評估方法：對一個需求（backlog）評估兩個值，一個是做了這個需求之后的收益值，另一個是不做這個需求之后的損失值，兩個值的相加結果就是該需求的優(yōu)先級值（顯然做了收益最大且不做損失最大的事情優(yōu)先級最高）。

如果客戶是比較強勢的話，項目組也可以讓步，但是千萬不要將demo當作正式版去交付，一定要抽時間重構甚至重做也在所不惜，否則，因為架構問題會引起的非常大的麻煩，到時候“長期性的加班”恐怕也是輕的。

我們認為“過度忙碌”的項目存在的第二個原因是管理者的素質問題。很多老板都希望自己的員工能夠忙一些，加班多一些。其實很少有老板能夠想到“產出=效率×時間”這個公式，認為一味地增加時間就可以完成任務，而從未想到效率也是可以為0的。他們總是以為可以不斷地去挖掘員工的潛能，寄希望于某一天有人會來個能力大爆發(fā)。

但是這個假設可能并不那么簡單，就拿任正非來說，我們大家都覺得他應該是一個聰明人，不會想不到這個效率公式。但是他依然號召華為拼命加班的原因是什么？有人覺得要么他想在華為形成一種時刻有緊迫感的企業(yè)文化氛圍（他做到了）；要么就是他認為即使加班，效率為0的時間也比較少，所以加班還是會有收益的，更何況加班還是免費的呢（也做到了）；要么就還有其他我們沒有想到的原因。

所以有人說，要做老板，一定要想一下自己到底要員工是一個什么樣的工作狀態(tài)。但是無論如何，只有保持員工有充足的休息時間，才能保證有持久的工作效率。否則難保出現華為的例子：一個員工長期加班實在撐不住了，去醫(yī)院一檢查，立刻被下了一張“病危通知書”，糖尿病晚期！

管理者的素質問題不僅僅是這些，現在中國公司的普遍問題是PM太技術化，回顧歷史，當年那些編程厲害的人，現在還有幾個在編程序？公司都是把這樣的人提拔成PM，結果在新的位置上他們需要重新學習和積累經驗。就等同于少了一個編程高手，多了一個蹩腳的項目經理。你說這樣的人來做管理，怎么會不亂？

引申出來，其實這個可能也是當前中國的IT公司“脈沖式增長”的原因之一。所謂“脈沖式增長”，就是公司借著一個機會迅速擴張，然后在一段時間之內又迅速縮小，如此循環(huán)不已。一個可能的合理解釋就是創(chuàng)業(yè)團隊成功之后，公司迅速擴張，創(chuàng)業(yè)團隊的成員被迫離開技術去做管理，這樣導致產品的技術水平下降，進而引起質量問題，最后失去市場。與此同時，蹩腳的管理導致公司的文化和氣氛發(fā)生變化，進而導致人員離職潮...最終公司又回到原來的起點，而且創(chuàng)業(yè)團隊也分崩離析。如果運氣好，這個公司還會茍延殘喘，等待下一次脈沖的時機。

那么我們是不是可以避免這種編程高手到管理初學者的情況呢？職場心理方面的研究告訴我們，“每個人都有不斷追逐不稱職崗位的欲望”，2010年搞笑諾貝爾獎的管理獎就是關于這個問題的http://www.cnbeta.com/articles/123444.htm，他們從數學上證明，如果隨機選擇一個人升遷，可以讓公司運作更有效率。由此，現行的升遷制度的效果可見一斑了。

第三個可能原因，不外乎錢的問題。有人說“所有錢能解決的問題，都不是問題”，可是另外一個事實則嚴酷的多：“所有因為省錢而省出來的問題，最后都變成了錢解決不了的問題”。

我們總結出來了一個典型的場景：某公司研發(fā)了一個新產品，大賣。于是該項目的架構師A也覺得當年自己的收入會很好，結果公司沒給他加薪或升職，于是失望。接連幾次失望之后，于是架構師A離職了。架構師B接手項目，發(fā)現架構上有些需要改進的地方，但是因為時間緊，打了一個補丁上去，心想有時間的時候在重構。同樣公司最后也帶給他一連串失望，架構師B沒來得及重構就走了。接下來架構師CDEF 基本都是同樣命運...。 最終架構師Z登場，等到他看到一個補丁摞補丁的系統(tǒng)的時候，他想改也無能為力了。最終，項目成了一塊硬骨頭，丟不得，又吃不消。金蝶的 EAS 多半就是這個狀態(tài)，不過好消息是，基于中國的現狀推斷，用友也肯定不會好到哪里去！

有人提出，這樣的產品路線，其實不是沒有人看到，只不過怕當時花錢多，覺得能拖就拖罷了，誰想最后就拖不起了。

最后，按照本次沙龍的規(guī)矩，我們需要給所討論的模式給出一個“藥方”。我們對“玩的就是心跳”模式的解決方案是：
1. 如果到一個公司就發(fā)現是這種類型的話，直接離開是上上策。其次如果努力之后無法改變，離開也來得及。
2. 充分溝通，減少焦慮感。對客戶，要引導他，讓他在對需求和項目有充分的了解之后再做決定；對于員工，則要盡可能透明，比如一些戰(zhàn)略規(guī)劃，收益情況和收益的分配方法等，通過這些信息公開，逐漸形成一個“價值反饋循環(huán)”，即項目組和商業(yè)的互動反饋模式。
3. 讓管理層了解公司自身的實際能力，尤其是工作效率。避免出現“讓出租車一天內從深圳機場開到北京”的情況出現。一個人開汽車的時候能夠知道自己的最大速度是多少，同樣的人開公司，我想也應該讓他知道這個公司的速度。