摘要：作為專案領導者，對於專案的進度和功能設計必須進行前期估算，以便專案能夠按時完成。本文以tagging為例，總結了三點經驗教訓僅供參考。正如作者說的：痛苦的過程常常能給我們帶來經驗教訓，很值了！
有時候很難估算出完成乙個專案需要多長時間，開發者常常會低估乙個功能的交付時間，尤其是遇到更改和迭代方面的事情。一旦工作上出了差錯，隊員們就會洩氣，這是常有的事。
作為乙個專案領導者，在經歷過多次錯誤估算之後，我吸取了沉痛的經驗教訓。客戶不斷提出新的要求，還要擴大功能範圍，以至於原本只需乙個月的專案在經過反反覆覆的修改之後，竟然花費了五個月的時間。這是我所沒想到的情況。
案例研究：tagging
最近我在new relic搭建了乙個新功能，能夠讓使用者在自己的應用程式、伺服器和關鍵事務上貼上標籤。其實tagging是乙個非常簡單的創意和功能，為了保持事物的基本要素並有所增值，我們計畫將新增標籤的功能首先用在伺服器上。我本來估算完成這個專案需要乙個月的時間——每個星期都有合理的分配計畫：
前兩周一切照常，沒有什麼問題。接下來，就是我們能夠想象得到的——不可避免的，令人痛苦的修改，這打破了原來規定的時間計畫。值得慶幸的是，痛苦的過程常常能給我們帶來經驗教訓。
教訓 1：要做兩手準備
第三週，在召開的設計團隊會議上，我明確表示低估了專案所需的收集和實施反饋時間。我原本打算只用乙個星期就能在這個會議上宣布這個簡單的功能，但是從我收到反饋數量上來看，我覺得現在的日程安排已經偏離了事先制定的計畫。
這讓我吸取了第乙個教訓：對一些事情做出假設的時候，應該把時間放寬，並想清楚這麼做的原因。對於一些即將實施的專案，預算長時間和提前準備總要好過時間不夠用以至於無限期延遲專案。
教訓 2：重新評估貫穿整個專案過程
在new relic，我們規定，將不斷提公升**的效能放在首位，並且這個優先權把範圍延伸引入到了新增標籤專案當中。在我工作的網頁上給ui新增標籤的速度並不是很快，所以為了提高效能和減少技術上的問題，我們決定在使用者端mvc框架（backbone）上進行重寫。
儘管重寫過程超出了工作專案範圍，但是必須得這麼做。我仔細考慮如何讓tagging介面的backbone檢視起來更便捷和能夠重複使用——這樣就能夠更加方便的將tagging傳送到應用程式和關鍵事務裡。我喜歡這樣有創意的想法：通過backbone集合進行搜尋而不是直接在dom上的列表行裡進行搜尋。事實上，這有點讓我洋洋自得，所以專案延長了兩周時間，每週在backbone裡重寫兩個頁面。
我並不後悔在這個專案裡新增這個條件。為這些網頁重寫ui的確可以減輕專案的後續工作，而且網頁的**也變得更加簡潔。真正令我感到後悔的是沒有回過頭來把計畫作為乙個整體再看一遍。
我的第二個教訓是：不管在專案要求上做了多大的改變，都有必要重新進行評估。
教訓 3：所有的修改都是可行的
這有點老生常談了，但不要害怕改變。不管是在生活中還是在工作中，改變都是必不可免的。重要的是我們怎麼應對這些改變：三思而後行。
如果這些改變能讓初次發行變得更有用，或者能夠減少技術上的問題，並且讓以後的工作/維護變得更加簡便，那麼就可以考慮將這些更改方案加入到專案計畫中。
重新評估整個專案是及其重要的，可以為接下來所要作的改變起到鋪墊作用。之後改寫的backbone導致的一些變化是我在開始的時候沒想到的。這些可能只會導致些許延遲，可是，延遲的次數太多了也會影響士氣的。
乙個單獨的變化，和由此產生的額外費用，不能歸結於是改變專案造成的，因為它會影響之後的每乙個要求。
總結
我曾經認為只會耗費乙個月時間就能完成的功能，最終卻花了五個月，我沒有信心按照預期計畫交付專案。我一直在想，如果我以前足夠小心謹慎，也許現在就不會有失敗感了。
把事情所需的計畫時間延長，想想為什麼，並依據個人需求，給自己更充裕的時間。
微不足道的改變可以讓你的在專案重新評估上更有保障。可以考慮長期的新增或改變要求。
理性對待改變——你能處理多少改變，並且對於專案的成本有什麼影響。而不是試圖避免改變。
一次失敗的購物帶來的幾點啟示
家裡的天然氣灶壞了，修理成本很高，電磁爐母親又用不習慣，所以，必須買乙個新的天然氣灶。一直關注家電，不過僅限於娛樂類黑電和白電，對於廚房用具卻不大熟悉，這是我的陌生領域。在網上簡單查了下資料，第乙個想到了京東，不過京東主推的都是天然氣灶 抽油煙機的套裝，抽油煙機還沒有壞，對於我來說是多餘，而且京東看...
《開發除錯》一次bug的啟示
最近改了乙個bug，改了好幾天，改的有些崩潰，在每次要放棄的時候，都冷靜的告訴自己，再試試別的方法，再捋一捋思路，再找介面問問清楚，終於解決了，有種如釋重負的感覺，也讓我獲得了一些新的認識 1.先確定自己的演算法沒有問題。在資料大的情況下，寫一下小的例子驗證關鍵步驟。2.確定對介面的資料格式和資料傳...
Initrd is too big 的一次錯誤嘗試
luo weifeng 2011 5 2 昨天編譯完核心開始製作initrd，由於在編譯的時候選擇了除錯資訊，所以肯定編譯出來的東東就超級的大，是 讓做核心除錯搞的，所以也沒有辦法，網路上關於這個too big的問題一般都是 disable memory hole，但是我在vmware bios裡邊...