老翅寒暑

項目管理沙龍第八次聚會紀要

本次沙龍依然是NSEC的敏捷經(jīng)驗總結。這次依然談到了客戶與需求的問題。因為客戶和開發(fā)組不在同一個地區(qū)，所以客戶完全沒有參與到項目的開發(fā)工作，所有的溝通都通過項目經(jīng)理來進行。從開發(fā)人員的角度看，需求變化最大的問題是開發(fā)人員無法確定是否真的是對客戶有用的。客戶首先是自己有很多的想法，變來變去，PM也因為距離的關系，無法和客戶面對面溝通，所以也就只能拍腦袋和猜謎語。結果開發(fā)人員心里沒底，做不出成就感，心情自然也就好不起來。引出的問題就是：開發(fā)人員到底怎么辦？

面對這種情況，經(jīng)過討論，大家認為首先還是要充分信任PM，但是PM也有責任去和客戶充分溝通。這個時候，我們一直強調的“原型法”就會有很大的作用。原型工具可以有很多種，比如一連串簡單的html頁面，或者一個ppt演示。前者的好處是可以快速地完整演示一個流程，后者的好處是可以將一些用戶界面效果也同時演示出來。總之，原型工具就是那種可以快速構建，快速拋棄的東西。非常適合用在客戶需求不穩(wěn)定甚至不成形的情況下。

實際上，NSEC的需求問題根源并不在客戶，也不在PM，而是和其他大多數(shù)項目一樣，缺少了一個角色，“業(yè)務分析師”，簡稱BA。許多項目的BA都由PM擔任，或者商務人員擔任，但是他們要么身兼多職，要么沒有受過專門的業(yè)務分析訓練，無法充分引導客戶的需求，結果就造成了需求不明確，不穩(wěn)定等問題。引用沙龍成員的一句話：程序員不反對變更，但是反對浪費！

BA的作用很重要，在敏捷結對中，BA的結對對象就是客戶代表。他的工作就是負責引導客戶，讓他們的需求變得更明確，更穩(wěn)定。原型法是一種很好的需求引導方法，就像我們一直強調的，“客戶不知道自己要什么，但是明確知道自己不要什么”，原型法的作用就是讓客戶能夠不斷地否定自己的想法，最終形成一個明確穩(wěn)定的客戶想要的東西。這個也就是項目組夢寐以求的“穩(wěn)定的”需求。其實BA的工具遠遠不止這些，“語法分析”也是BA的工作利器。根據(jù)客戶所說的語句，將其劃分為名詞、動詞、形容詞和主語、謂語、賓語。根據(jù)每一個詞語的特性，我們可以整理出一系列有針對的問題。一個有經(jīng)驗的BA，只要客戶不斷地開口說話，就會將客戶的所有需求都問出來。具體的方法，我們可以在以后的沙龍中詳細探討。

NSEC的另外一個問題是客戶不定期不定時地要求項目組發(fā)布成果。針對這種情況，我們覺得自動化構建和上次談到的UAT環(huán)境就很有作用了。這種問題的出現(xiàn)，根源其實還是在客戶需求的不穩(wěn)定上。當然，定期發(fā)布成果并讓客戶能夠感受到進度的變化，也是非常重要的。

“沒有驗收標準文檔”是另外一個NSEC的問題。從我們的角度看，這個是中國幾乎所有項目的共同問題。理論上，我們會在中標之后對客戶進行需求調研，然后把形成的需求規(guī)格說明書作為合同的附件，并以此作為客戶驗收的標準。實際上能夠做到這種程度的項目幾乎沒有，即使做到了，這個合同附件中的需求也會在開發(fā)過程中不斷地變更，最終變得面目全非。有經(jīng)驗的人肯定會拿出“變更控制”的辦法來，可是實際項目過程中，有多少客戶愿意每次需求變更都來簽字呢？又有多少客戶代表因為要簽字就放棄需求變更呢？答案都是“很少”甚至“沒有”。很多項目就是因為限制客戶變更需求，或者變更需求過程中和客戶經(jīng)常產(chǎn)生不愉快，導致客戶關系惡化，最終項目失敗。這個也是“傳統(tǒng)”項目和“敏捷”項目的最大的區(qū)別。

從敏捷的角度去看，項目組完全接受變更所帶來的影響，但是所有的變更都不能影響當前正在進行的迭代過程，所有的變更最快也要到下一個迭代才能生效。但是真的有緊急的需求變更怎么辦？事實上并不存在什么“緊急”的需求變更，因為所有的需求的實現(xiàn)都是需要有時間的，需求是一種未來性質的東西，項目組一定要把“需求”和“BUG”區(qū)分清楚，不能用解決BUG的方法去應對“需求變更”（這個也是大多數(shù)項目組常犯的錯誤，任務沒有優(yōu)先級的結果就是經(jīng)常性的加班）。針對一個需求變更，除非它能夠讓當前迭代的某個任務即刻作廢，我們才需要即時改變迭代的任務安排，否則本次迭代不受影響。

沒有驗收標準文檔是一個問題，但是“依賴客戶進行測試”是另外一個更嚴重的問題。因為之前所講的客戶不定期要求項目發(fā)布，所以項目組在發(fā)布的時候的時間都很緊張，加上平時沒有充分的測試，所以項目組就希望客戶能夠抽出人力去做驗收測試。實際上，客戶幾乎不會去做什么認真的測試。有與會成員認為“依賴客戶進行測試”本身就是項目的一種失敗。