昨天同事分享了一篇文章，programmers-are-bad-estimating，
鏈接在這裏：http://java.dzone.com/programmers-are-bad-estimating
沒怎麼認真看這篇文章，但這篇文章引起了我的思考
身處互聯網行業，敏捷開發被一致認爲是“制勝法寶”，大家一致認同快速開發，
快速收集用戶反饋，快速迭代。其中經常出現的一幕是，在需求會上，產品同學問開發同學，
這東西要搞多久，什麼時候可以發佈。然後開發同學開始痛苦地盡其所能地在需求沒看懂，
甚至原有代碼不熟悉的情況下用幾秒鐘的時間去評估，
即使開發同學發現在這種情況下還不能比較準確地評估時，產品同學也一般也會要求給個大概時間，
然後開發同學只好絞盡腦汁去評估，然後給出一個“大概時間”。
如果給出的“大概時間”超出產品同學的預期，產品同學就會去質疑開發同學，
一種常見的做法是，找一個開發leader，或者他覺得可以評估地更好的開發過來評估。
期望是這個人評估出一個更短的“大概時間”。
一個很簡單的場景，一直在重複着，如果不是昨天同事分享的文章，還真沒怎麼想這件事情。
產品同學側
1：產品同學不懂技術，無法知道技術實現，更無法評估時間，所以對他來說，
時間多少是未知的東西。人對不確定的東西和未知的東西都有一種天生的恐懼感。
消除這種恐懼感的方法就是把不確定變成確定，所以產品同學會要求開發評估時間。
2：開發時間是產品同學對需求優先級評定的一個重要因素。這很容易理解，
如果投入和產出不成正比，產品同學需要去調整或者延遲這個需求。
3：希望開發時間越短越好，越敏捷越好。這樣產品才能更快地去對產品根據用戶反饋做出調整，
在這個競爭激烈的市場中更有競爭力。否則，很可能就被淘汰。
開發同學側
1：互聯網的開發不像傳統軟件的開發，前期有很嚴格的需求評審，架構設計等等，
可以什麼都確定下來再動工。互聯網講究有感覺就去嘗試，就去做，發現不行再調整。
快當然是好事也是優勢，同時也帶來了一些需求不確定，需求文檔比較粗糙。
有時候連產品同學自己都沒想好細節，只是有個大方向。
2：發現需求不確定，或者原有代碼不熟悉時，不敢輕易評估，
因爲曾經的“傷害”已經深深地在印在他的腦海裏了。“因爲評估不準導致影響整個項目進度”，
“因爲需求的一個小改動導致全盤推倒重來”，
“不確定的情況下評估出來的時間遠遠大於實際時間，只好精神高度緊張，然後加班加點，
耐心地跟產品同學解釋”，“擔心別人對你的能力的否定”等等。
這些擔心導致了開發同學在不確定的情況下不敢輕易評估，
因爲開發同學和產品同學一樣，對不確定的事情感到恐懼。
3：產品同學的再三要求，開發同學只好給出“大概時間”，
這個“大概時間”有點用腳投票的感覺。比如說，評估的“大概時間”爲一週，
可能3天就搞完了，也可能要個兩週。相關因素很多，需求文檔的清晰度，
產品策劃的變更情況，開發個人的能力，現有代碼的框架和質量等等都會影響開發的進度。
從上邊可以看出，問題很容易就產生了。
1：產品同學本身不瞭解開發的實現等，需要多少時間來開發實現對於產品同學來說是一個黑盒。
但是產品同學又會經常根據以往的經驗對開發時間產生一個心理預期，
而且要求開發同學在幾秒鐘就給出個“大概時間”。
因爲這個“大概時間”會影響到很多產品同學的決定。
2：開發同學每次都痛苦地用腳投票，給出自己都不信服的“大概時間”。
“大概時間”的不靠譜如上邊所說。
有經驗的開發給出“大概時間”時往往會留出一些緩衝時間來讓自己不處於上邊所說的被動的情況。
但讓自己處於舒適區，不管是對自己，還是團隊和項目，都是不太好的。
3：產品同學的做法，找一個開發leader，或者他覺得可以評估地更好的開發過來評估。
期望是這個人評估出一個更短的“大概時間”。這種做法其實比較傷害團隊氣氛，
如果那個被找過來的人的做法不是很恰當，比如在不瞭解情況當面就做出快速給出“評估時間”，
會傷害到去真正去實現開發的同學。所以，當你是那個被找過去的人時，
不要不負責任地隨便給出“評估時間”。起碼先考慮下那個去真正去實現的同事的能力，
以及對現有的架構的熟悉程度和和現有的代碼質量，
然後再去了解清楚需求和真正去實現的同事的擔憂的地方。
事情好像無解了，互聯網要求敏捷開發，而且變化很快。
產品同學需要根據開發同學給出的評估時間來安排以後的工作和策略。
技術同學又需要時間去了解需求，而且受限於自身的能力以及對代碼的熟悉程度，
以及現有的框架和代碼質量。
怎麼辦？
首先，一個相互信任，團結合作的工作氣氛是基礎。
開發同學和產品同學是一條戰線上的戰友，都是想把產品做好，把項目做好，沒有衝突。
起碼那種希望自己的項目做的越來越差，希望自己處於一個一團糟的團隊裏邊的人還是少數。
不要輕易去懷疑別人，去質疑別人。如果有這樣的氣氛，開發同學也更敢於去給出評估時間，
更敢於去挑戰自己，因爲不會以爲一次估計錯誤而導致種種質疑和“傷害”。
估計錯誤了，去總結和學習，以後不會在同一個地方跌倒就ok了。
其次，做好溝通
產品同學爲什麼會要求開發給出評估時間？開發同學爲什麼難於給出比較準確的評估時間？
需求在實現過程中爲什麼需要修改？爲什麼這點小的調整需要格外的兩天？
等等，還有很多，如果發生這種情況的時候，儘量去溝通好，爲什麼會這樣？
你知道或你覺得應該這樣的，別人不一定知道或覺得應該這樣。
第三，多點理解
不管是產品同學還是開發同學，當對方做出了讓你不爽的事情的時候，多點信任，多點理解。
千萬不要把問題放大，不要去猜測，不要去幻想。然後在心情平靜下來後，去主動溝通，
去了解對方這樣做的原因。尋找好的，你就會找到好的，甚至會創造出好的。
第四：開發同學需要提高自身能力
如果開發同學能力很強，產品意識很好，甚至比產品強，技術能力也很好，那麼一個需求出來，
不確定的地方必然就少了很多，需求不清晰的地方，他可以補全，對代碼現有框架和質量瞭如指掌，
對現有細節很熟悉，開發效率很高，那你評估時間必然會很輕鬆和愉快。
因爲你給出的評估時間往往比產品同學經驗當中的都要短，而且評估時你是很清晰的，
不是用腳投票的。那麼，你慢慢就會成爲一個靠譜的人。
第五：給充足的時間給開發同學評估
很明顯，越充足的時間，開發同學越能跟清晰的評估。覺得這一點也不影響敏捷，
相反，這樣做會更敏捷。因爲如果能給出更準確的評估時間，一般都會比那些“大概時間”短很多。
我說的，不一定是對的