|
|
英文原文：Just Say No
又一次情緒激動、氣氛高度緊張的會議，這一次是商議如何讓目前這個重要項目“重回正軌”——計劃的完工日期早已超了幾個星期。所有的這些場景聽起來都很耳熟嗎？我想說的是，項目超期在任何行業里都是常見的事情。然而，軟件行業里看起來更容易出現這種情況。
我們怎么會走到這種地步的？這還要從我們夢開始的地方說起。所有的開始都是精神抖擻、干勁十足。一個漂亮的創意，這次我們發誓絕不會重蹈上次的覆轍，不會犯上次的錯誤。這次我們告訴自己，這次的計劃將會“正確”的執行，不會圖省事，也不會中途變更。經常有時候我們會感覺夢想正朝正確的方向前進，設計很成功，每個人都很樂觀，外界評論也很好。然后，噩夢開始降臨，因為各種打擊開始出現。
系統中最容易的部分卻耗用了大家全部的時間。一個微小的疏忽就可能意味著當初一系列簡單的假設都不再成立。錯誤的假設產生連鎖效應，導致系統設計陷入死局。需要對設計進行修改來糾正這些問題。希望仍然存在，只要付出足夠不眠之夜和周末加班，我們仍然能讓項目“重回正軌”。
具有里程碑意義的原型終于誕生了，所有人都充滿信心，因為原型表現的非常好。外人不知道這是多少個通宵達旦的努力換來的。很快，“小需求”開始出現。通常的說辭都是從“這有什么難的？”或“這真的很簡單！”開始，更經典的話是“如果我們能夠…那將會太神奇了”。通過交換意見發現，這些新增的小的功能特征不僅看起來“簡單”，而且實際可做。當然，你是不會說不的，然而，歷史的悲劇即將重演。
現在，你和你的團隊終于回到了現實世界，再次查看這些新增需求。在經過了近距離的觀察這些看起來“非常簡單的功能特征”后，突然意識到它們并不像起初聽起來的那樣簡單。但為時已晚，你已經答應了這些新修改。
“呯！”你的郵箱通知你有了一封新郵件，真是火上澆油，銷售已經向客戶許諾。銷售向客戶談到了這些“簡單”的新功能，而客戶提出來更多他們想要的“更簡單”的新功能。銷售照單全收，因為這些新需求聽起來比起初那些更簡單。
程序員們，請勇于說不
停，不能這么干
在 80 年代和 90 年代期間有一個非常流行的運動口號： “Just Say No”，是用來宣傳讓孩子們遠離毒品。不管你是否還記得這場運動，它表達的信息是非常有力的。相似的，我們應該使用同樣的語氣來面對我們遇到的問題。
當然，我并不是在慫恿抵制任何的需求變更。從我的角度，任何需要編碼開發的新增內容我都會用紅線劃分開。但諸如界面或前端內容的修改不包括在內。
任何新增需求在接受前一定要確定相應的充裕的追加時間。內心里對新需求的缺省反應應該是“just say no”。當然，并不需要從表面上暴露這種反應，可以用適當的外交手段達到這種效果。在項目開始之日，任何一個最初沒有規劃的“需求變更”都要謹慎斟酌。任何后來新增的功能特征都要堅持這個原則。有了這個原則你很容易說出“不”。因為這是一個標尺，所有人都明白，后加的新功能會耗費額外的時間。把這種壓力放在客戶和老板的身上，要么延緩完工日期，要么放棄另外一個功能做替換。
結論
有各種各樣的原因會導致一個軟件項目不能按時完工。項目進展緩慢，程序員持續在高強度壓力下工作，這使項目開發時間的預估變得更加困難。程序員應該有心理準備，新增需求的情況肯定會出現。把“just say no”記在心里，多少能預防你張嘴就說“行”的習慣。玩槍很危險，給槍加上保險裝置，至少能防止傷了自己的腳。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
