上一篇我們講了，我們通過對任務進行切分，確定項目的真實任務量，保證勞動付出和報酬收益之間的等價匹配。但就像一次交易，除了價格以外，還有其他很多需要考慮的因素。本篇將繼續探討在軟件開發過程中，如何進行流程控制和責任劃分。
緣起
有一次，一個朋友約我接一個私活。客戶之前已經花了3萬，做了一個仿凡客的網站，都交付使用了，才發現bug一大堆，根本沒辦法用。想讓我們給接著做，讓我們給報個價。看他演示了一會兒，我告訴他，這價格我們報不了，因為需求都不清楚。
“怎么就不清楚了呢？”客戶很是不解，“你們就把這些問題解決了就完了呀！”
“這些問題，究竟有哪些問題？”我追問道。
“就我剛才給你們演示的呀！”
“是不是就只有這些？”，我一定要把這一點弄明白，“那我們用筆把他們一條一條的記下來，修完這些問題就完事？其他的不管！”
他不說話，似乎還不太明白，我接著解釋，“比如你這個頁面，現在是打不開，崩潰了，我們是不是只要做到這個頁面能打開，就OK了？至于這個頁面打開后，上面的功能是不是已經實現了，我們不管。”
“那不行！”，他馬上就跳起來了，“必須得做完啊！得好好的跑起來。你看，就像凡客這樣……”
我基本上失去了和他談下去的興趣。直接給他兩個選擇：1、我們做兼職，在他眼皮子底下做，多少錢一天/小時；2、把bug一個一個列出來，根據bug的難度，確定每個bug的價錢，按時結算。客戶兩個都不愿意，一定要我們報個總價。
下來之后，我那朋友還和我聯系，說客戶其實很欣賞我做事的風格，希望能繼續談。我直接回她，“如果他真的欣賞我做事的風格，就按我說的方案做。需求都定不下來，總價沒法報。‘照著凡客做’，那不是需求！你坑死我啊，一個凡客，3萬就做出來了？而且凡客里面，估計都還有一堆bug，大部分時間普通用戶沒發現而已……”
這種注定扯皮的活我堅決不做！又不缺這點錢，以前做律師做裝飾，扯皮真的是扯傷神了！這種稀里糊涂又已經上過當的客戶，百分百扯皮。最后我那朋友另外找人，報了個總價，也還是沒做成這業務，因為客戶要留50%的質保金，1年內付清。我哈哈大笑，想起當年我裝飾公司請人做網站，最后也是把做網站的小伙子煩得連尾款都不要了，直接閃人。
思考
現在想來，應該就是這件事，讓我動了念頭，開發目前這個任務管理系統。
“像凡客那樣”，“參考阿里巴巴”，“類似于QQ”……這些話，我聽到就害怕。還不如通過任務切分，把需求一條一條的真正的固化下來，然后我們再開始做。這些土豪客戶是絕對沒有這種耐心的，你嫌麻煩，整理需求（切分任務）這事我們做都可以，但你要“認賬”。至少這些需求，你或者你指定的人，要一條一條的去看，不要憑空想個大概，三言兩語打發就完事。
驗收的時候，你就認認真真的驗收，一項一項的，驗收完了就完了，不要稀里糊涂的系統上線幾個月了，這里有問題那里有毛病。我做維護這么久，接手的這些項目，哪一個不是交付上線了的？而且還是專業人士驗收通過的，運行了這么多年，bug都還是一堆一堆的。你說這項目算不算“合格”？你說系統都交付驗收正常運行這么多年了，哪個系統沒bug呢？windows都還藍屏呢。但按普通客戶的觀點，還有這么多問題，怎么能算合格呢，你得給我改，是你自己事沒做好，加錢？門都沒有！
所以，除非是800-1000的企業宣傳網站，或者政府機關驗收主要靠喝酒公關的項目，稍微復雜一點的、客戶用心一點的外包項目，按項目整體報價簽合同的，陷進去就是個泥潭。怎么賺錢，是八仙過海各顯神通，但我看來，都沒幾個走正道的。我以前面試，一些非IT行業的公司，我了解他們的項目之后，就建議他們，干脆外包算了，干嘛自己招程序員，不劃算啊？他們頭搖得像撥浪鼓似的，“算了算了，這個當已經上過了！坑死人！”我周圍接私活的朋友，是碰到肥羊就宰，碰到釘子就甩，接單的秘訣就是看這個客戶“好不好說話”，想想也都是些可憐人啊！
需求
需求方的深度參與，是項目成功的前提。這是毋庸置疑的，但很遺憾，很少有人真正的足夠的重視這一點。
行業外人士，上面已經很多吐槽了。就是行業內，部門與部門之間，一個項目組內部，需求分析這事，都做得不盡人意稀疏平常。我經歷的，大致有這些個情形：
- 口頭交待的。通常都是其他業務部門抓壯丁，“小葉啊，我們這里要改一下。很簡單，就這樣，……”你要是想我當年一樣，是個愣頭青，相信了他說的“很簡單”，到時候你就一邊哭去吧！
- 發Email之類的。這種現象外企比較多，比帶個口信好一點，至少有個憑據。但稍微復雜一點的功能，一個email來來回回，扯到后面也是醉了。
- 給需求文檔。這種最正式最規范，但不要高興得太早。因為要寫個需求文檔的功能，一般都是比較復雜的，三言兩語是說不清楚的。所以就很容易有疏漏，得改。改來改去就出問題，Email還有一個更改記錄；word文檔改了就改了，到后來就忘了究竟改了些什么了。
以上這些，如果沒工期要求，問題都不大，就多做點無用功而已。但哪有沒工期要求的項目呢？（我的這個玩具項目，呵呵，不要求工期。）所以，扯皮的事就來了！我記得印象最深的是，有一次，deadline的前一天，我們項目經理在辦公室破口大罵，“媽個逼的，現在還在改需求！我們怎么做？”但業務部門也有話說啊，“你們做之前怎么不仔細審查需求文檔呢？”這中間又還夾著其他一些亂七八糟的事，官司打到上頭，還是項目延期加班完事。
切割
我發現有很多程序員喜歡“撈到半截就開跑”，需求還是迷迷糊糊的時候，憑著自己的想象就開始寫代碼，老是做無用功。（還有更奇葩的，他自己一路狂奔九頭牛都拉不回來，最后你和他說需求是怎樣怎樣的，他還特別不服氣，覺得他做出來的效果比需求要好！按他的想法，應該改的，是需求而不是代碼。）除此以外，需求常常也給得模糊有歧義，所以這個官司就有得打了。我記得有一個研究結果：日常的單向溝通，大概有80%的信息會被忽略或誤解。所以需求其實也不好弄，這個我們以前提到過，使用測試化文檔是一個方法。
但本文，我們主要講責任。正如我們上文所述，鞭子還是必須的。沒有監督和責任約束的制度最后肯定是一紙空文。
所以我反復的考慮，覺得還是業務部門說得更有道理一些。這就像貨物交割，交貨前理應由收貨方進行仔細驗收，貨物到手之后才說我剛才沒看清楚要求退貨，這肯定是沒道理的。對應到軟件開發，如果需求方是外部客戶，這就涉及到報價預算商業信譽等一系列問題；即使是內部人員，也有可能影響別人的工作安排。所以，承接任務時對需求的審查責任應該在開發人員一方。
同理，任務完成之后，驗收的責任就在驗收人一方。一旦任務已經被驗收合格，今后就不要再說什么當時沒考慮周全。
工具
既然確定了這種指導思想或制度，就需要一個順手的工具來予以貫徹執行。我們任務管理系統的做法就是，把功能切分成一個個的任務，每個任務都有：發布 > 承接 > 驗收 三個大的階段：
- 發布：相當于闡述需求，但同時要指明任務的難度、工作量、完成日期等其他相關屬性。
- 承接：開始工作，以完成任務
- 驗收：任務完成后檢查是否合格
(以下統一使用任務發布人/承接人/驗收人表明相關人員，也就是責任人的身份)
在階段與階段交接的時候，確立相關人員的責任，具體來說：
任務一旦被承接：
- 除非承接人同意，其發布內容就不能再更改。任務發布人就必須盡可能的認真對待需求，減少隨意修改。但是，
- 如果任務發布內容有多種合理解釋，將按照有利于發布人的原則進行解釋。這是不是就要求承接人在承接的時候要慎重，多考慮一下了？
任務一旦被驗收：
- 任務結束，誰都改不了。驗收人甭想再回頭把“合格”變成“不合格”！
換言之，這些規則就是針對的下面這樣一些現象：
- 不認真發布需求 （人家承接了任務就不能改了喲！）
- 不認真審核需求 （出現分歧時按有利于需求發布方解釋喲！）
- 不認真驗收任務 （驗收合格就合格了，沒后悔藥喲！）
通常，任務發布人就是業務部門需求方，承接人就是開發人員。但也有例外，完全可以靈活應用，比如我就讓開發人員發布任務給業務人員，任務內容就是需求文檔，驗收人也是開發人員。所以業務人員的需求文檔一樣要開發人員審核驗收，這樣就可以提高需求文檔的質量，讓需求反過來配合開發。
異常處理
當然，實際工作中，事情往往沒有這么簡單。需求會不時更改調整，驗收也會有疏漏。但正是因為如此，我們才更應該堅持本系列文章所提到的原則。
比如一個任務，需要進行調整。那么，首先看它是不是已經被人承接了？如果還沒人承接，OK，隨便改；如果已經被承接了，那么就必須得到承接人的許可之后才能修改。承接人的許可有以下作用：
- 承接人得到及時的通知。必須的！
- 給承接人一個機會，考量任務（需求）變動的實質是什么。究竟是新功能覆蓋了舊的功能，還是在新功能的基礎上添加了其他的功能，或者是兩者的混合？進而采取相應的措施，比如建議新加一個任務，拆分原任務再更改等。
- 承接人已經付出的勞動應該得到認可。我做都開始做了，是吧？不能不算我的工作量。
任務驗收也是同樣的道理。干脆一些，一個任務，驗收了，就完了，不要再糾纏了——哪怕以后在其基礎上再發現了問題，都不能再“重開”這個任務。
這一個原則的理由很不好講，算是一種實踐體會吧！你如果硬要說，以后又出現的bug是之前一個任務帶來的，邏輯上也說得過去，因為確實是他完成那次任務時提交的代碼，造成了現在的這個問題。但是，當時誰都沒發現啊？！很多代碼其實就是這樣改過來又改過去，修改代碼引起復雜的連鎖反應是很正常的事，不能因此就抹殺了這過程中承接人的辛勤勞動吧？這對承接人不公平。
所以，再開一個新任務吧！或者，驗收時你就使勁想長遠點。如果自己想不到，就不要要求別人能想到。
總結
本文花了大量的篇幅，描述項目開發中，需求從發布到實現以及驗收過程中的糾結或問題，就些都是極其常見、反復出現的。看起來這是一溝通問題，很多團隊也反復強調溝通，這并沒有錯。但如何進行有效溝通呢？就像我們說要提高效率，這當然沒有錯，但這個效率怎么才能提高呢？看到大家在辦公室里經常吵架，就拉出去吃個飯喝喝酒消消氣，其實治標不治本；就像項目延期，加班加人一樣，最終效果如何，我想大家都知道。
所以，我認為，制度或者流程上的改進才是最核心的力量。而明確的責任劃分，是其關鍵。
好像沒多少人對項目管理敢興趣啊？上一篇反響平平，碼字這么多，唉……
++++++++++ 精華評論答復 ++++++++++++
雖然說的很對，但是解決不了問題，所謂分清責任，一是人都習慣推卸責任，二是即便是分清了又能怎么樣？該改的是時候還是得改，因為客戶都是甲方。小單子，私活可以不管不顧，可以牛。大項目遇到客戶說話時候，還敢說不？你不干后面很多人在排隊了
-- 這是個非常好的問題。有兩種方式解決：
1、把需求和項目管理隔離開來。開發人員不要直接面對最終用戶，應該設置一個“門面”或“窗口”，由他們專門的面向客戶，了解需求，并將需求轉化成一個一個的任務。我待過的一家公司這一點就做得相當好。至少，有了這樣一個“隔離墻”之后，開發人員很舒服，至于和最終用戶打交道的那些家伙怎么過日子的，呵呵，我就不知道了……
2、站在公司/團隊的角度，能挑選用戶的時候還是挑一下吧。我做裝修的時候就體會到了：有的客戶注定是要扯皮的客戶，他的錢賺起來太累太累了，不如放棄，這里面還有一個機會成本的問題呢！
文章列表
留言列表
