程式設計師要勇於說不

　　又一次情緒激動、氣氛高度緊張的會議，這一次是商議如何讓目前這個重要專案“重回正軌”——計劃的完工日期早已超了幾個星期。所有的這些場景聽起來都很耳熟嗎？我想說的是，專案超期在任何行業裡都是常見的事情。然而，軟體行業裡看起來更容易出現這種情況。

　　我們怎麼會走到這種地步的？這還要從我們夢開始的地方說起。所有的開始都是精神抖擻、幹勁十足。一個漂亮的創意，這次我們發誓絕不會重蹈上次的覆轍，不會犯上次的錯誤。這次我們告訴自己，這次的計劃將會“正確”的執行，不會圖省事，也不會中途變更。經常有時候我們會感覺夢想正朝正確的方向前進，設計很成功，每個人都很樂觀，外界評論也很好。然後，噩夢開始降臨，因為各種打擊開始出現。

　　系統中最容易的部分卻耗用了大家全部的時間。一個微小的疏忽就可能意味著當初一系列簡單的假設都不再成立。錯誤的假設產生連鎖效應，導致系統設計陷入死局。需要對設計進行修改來糾正這些問題。希望仍然存在，只要付出足夠不眠之夜和週末加班，我們仍然能讓專案“重回正軌”。

　　具有里程碑意義的原型終於誕生了，所有人都充滿信心，因為原型表現的非常好。外人不知道這是多少個通宵達旦的努力換來的。很快，“小需求”開始出現。通常的說辭都是從“這有什麼難的？”或“這真的很簡單！”開始，更經典的話是“如果我們能夠…那將會太神奇了”。通過交換意見發現，這些新增的小的功能特徵不僅看起來“簡單”，而且實際可做。當然，你是不會說不的，然而，歷史的悲劇即將重演。

　　現在，你和你的團隊終於回到了現實世界，再次檢視這些新增需求。在經過了近距離的觀察這些看起來“非常簡單的功能特徵”後，突然意識到它們並不像起初聽起來的那樣簡單。但為時已晚，你已經答應了這些新修改。

　　“呯！”你的郵箱通知你有了一封新郵件，真是火上澆油，銷售已經向客戶許諾。銷售向客戶談到了這些“簡單”的新功能，而客戶提出來更多他們想要的“更簡單”的新功能。銷售照單全收，因為這些新需求聽起來比起初那些更簡單。

　　停，不能這麼幹

　　在80年代和90年代期間有一個非常流行的運動口號： “Just Say No”，是用來宣傳讓孩子們遠離毒品。不管你是否還記得這場運動，它表達的資訊是非常有力的。相似的，我們應該使用同樣的語氣來面對我們遇到的問題。

　　當然，我並不是在慫恿抵制任何的需求變更。從我的角度，任何需要編碼開發的新增內容我都會用紅線劃分開。但諸如介面或前端內容的修改不包括在內。

　　任何新增需求在接受前一定要確定相應的充裕的追加時間。內心裡對新需求的預設反應應該是“just say no”。當然，並不需要從表面上暴露這種反應，可以用適當的外交手段達到這種效果。在專案開始之日，任何一個最初沒有規劃的“需求變更”都要謹慎斟酌。任何後來新增的功能特徵都要堅持這個原則。有了這個原則你很容易說出“不”。因為這是一個標尺，所有人都明白，後加的新功能會耗費額外的時間。把這種壓力放在客戶和老闆的身上，要麼延緩完工日期，要麼放棄另外一個功能做替換。

　　結論

　　有各種各樣的原因會導致一個軟體專案不能按時完工。專案進展緩慢，程式設計師持續在高強度壓力下工作，這使專案開發時間的預估變得更加困難。程式設計師應該有心理準備，新增需求的情況肯定會出現。把“just say no”記在心裡，多少能預防你張嘴就說“行”的習慣。玩槍很危險，給槍加上保險裝置，至少能防止傷了自己的腳。

　　英文原文：Just Say No