一個項目經理的工作日誌：
這一天，我們的部門研發經理把我叫了過去，告訴我我們小組要接手一個新的項目，這個項目已經經過客戶和公司兩方高層的確認了，最後要求完成的時間是2個月，也就是在6月5日之前必須完成，合同都簽署了。然後，研發經理把客戶fax過來的需求交給了我。我拿過需求來一看，上面寫着：
【XXX機頂盒系統需求】
需要支持HTML4.0的瀏覽器，支持JavaScript和Flash
支持Email
支持MP3音樂格式文件的播放
支持記事本、時間安排表、待辦、計算器、英漢字典、地址簿等PIM應用
視頻點播系統
運行系統最終要求16M DOC和32M RAM上。
…
因爲大部分的PIM（Personal Information Manager）程序都已經寫過一遍了，VOD系統又是採用合作伙伴的產品，因此我把視線集中到了如何構建一個更好的桌面系統，把應用集成到一個框架中來。
我們首先詢問了客戶對界面的需求，他們回覆我們，需要類似Windows的桌面風格，並且Email給我們一張圖片。值得慶幸的是，我們原有的界面就是這種風格的，並不需要太大的修改。我覺得這個項目問題不大，有望在2個月內完成。
我大概做了一下近期的計劃，首先我們要對桌面系統和用戶交互方面進行一次深入的討論，拿出一個讓我們自豪，讓客戶滿意的方案；然後考慮採用哪些技術，並進行軟件設計；最終進行編碼實現。
儘管時間緊迫，我還是準備在3～4周之內，拿出用戶交互設計的方案。這段時間中，我們不停的在開討論會，大家提出了很多好的見解和近乎瘋狂的想法，期間我們還參考了一些資料，包括計算機雜誌上一篇介紹SUI（Social User Interface）的文章，還有《衝破技術牢籠》（一本專門講述交互設計的書籍）。期間，我們還討論了要進行集成的應用程序，以及構建UI系統的方案。最終，我們決定：
採用XML作爲桌面系統的配置方案，提供極強的可定製、可擴充性。
採用Netscape4.76作爲我們的Browser。
利用Browser實現WebMail。
採用SUI的一些思想，加入一個桌面精靈程序。
爲支持更好的桌面特性、以及精靈程序的需求，支持Always On Top屬性。
MP3和VOD程序作爲Netscape的Plugin。
然後，我大概預計了一下工作量和人力資源的安排：
1．XML解析器（基於SAX的XML解析）： 1人月
2．窗口管理器（包括基於XML可配置、和支持總在最前）： 2人月
3．桌面精靈程序： 1人月
4．MP3程序： 2人周
5．系統集成： 1人周
6．系統測試：1人周
（注：在我進行估計的潛意識中，每週是工作七天的）。
但是現在我只有5個人周了，而且我現在的人手已經分配到各個項目中了。我在項目討論會上，向事業部經理提出了我的資源和時間問題。我得到的回覆是，時間不能改變了，五一加班，這樣就有六週時間了；然後，把我的一個小組成員Lee從另外一個項目（週期較長）調到我這個項目中來，負責窗口管理器。
最終，我的項目小組由4人組成，一個兼職的學生John（水平不錯，在我們討論交互設計的時候，就開始準備XML解析器的前期工作了），Lee負責桌面系統的窗口管理部分，Huang負責協同合作伙伴的開發工作並進行集成VOD系統的工作，我負責桌面精靈程序以及總體系統的設計工作。然後，我們開始工作了。（這時，John已經完成了他的XML解析器。）
首先我們考查了這些功能的實現技術，大體做了設計的工作：桌面系統的構架、模塊劃分以及模塊之間的關係（包括桌面配置和窗口管理兩部分，分別由John和Lee負責）；考慮了Netscape的運行方式；如何使Mp3、VOD與Netscape相結合等問題。這時，又有1周過去了，我們還有整整5周時間。Rush！
John和Lee和我在五一加班一週，期間我們在公司喫住，每天都是通宵工作，然後白天睡覺，下午還一起去打一小時檯球。我們還各自換了公司裏最好的顯示器，這種感覺很棒。很快的，在五一假期結束後，John和Lee各自的模塊編寫基本完成了，我的桌面精靈程序的功能也基本實現了。
這時突然，用戶由於在國外參加了一次展會，對他們原先提出的界面設計有了新的想法，併發回給我們展會上的一些圖片。應該承認，國外的設計的確是優秀的。我們負責這個項目的銷售人員在沒有和我協商的情況下對客戶做出了承諾，OK，按照這個做，只是換換圖片嘛。其實，這並不是換換圖片的問題，需要在桌面配置管理部分進行不小的代碼改動。我想提出異議，但是已經爲時已晚了。好吧，重新進行設計和編碼，好在由於原來的設計靈活度比較大，沒有傷筋動骨。但是，返工還是花了幾天時間。
這時，意料之外的情況發生了，John由於導師佈置的課題進行了調整，現在必須要花加倍的時間在他的畢業設計上了，只有晚上有幾個小時可以過來、週六日可以工作。
同時，桌面系統進入整合階段了。首先，是在整合中發現Lee和John沒有充分考慮到他們兩個人的模塊是工作在一個進程中的，他們原本設計的基礎是兩個模塊是並行的，這不得不花了3天的時間，把兩個人的接口重新進行了組織，程序終於可以運行了。但是，桌面系統顯得非常不穩定，經常發生core dump，Bug是隨機出現的而且還無法確定其發生的地點，gdb報告說錯誤發生在glibc的內存管理部分中。這個Bug極大的困擾了我們，我們整整花了一天一夜24小時連續調試和檢查代碼終於發現了錯誤（我在後面的代碼評審中會談到這個錯誤）。不幸的是，在John準備備份（tar gz）的時候，由於連續作戰精神恍惚，錯誤的刪除了新修改的代碼，這不得不又花費了3個小時以上的時間，在最近一次備份的基礎上重新修改並驗證。
在這個Bug解決之後，我們希望把桌面系統提交系統測試部門進行測試。但是，測試部門拒絕了我們單一應用測試的請求，理由是他們只接受產品的測試，這個單一應用無法進行系統測試，而且這個測試應該由我們自己完成。這使我大爲光火，堅持認爲系統測試部門應該進行單一程序的測試，這樣及時發現Bug（而不要使Bug激增出現在一起）有助於我們節省開發的時間。最終，大家不歡而散。
我們把Netscape和桌面、精靈程序集成在了一起，發現了一個非常嚴重的問題。由於我們之前的設計（爲了節約內存，同時也爲了多個應用能並行執行），並不啓動多個Netscape，而是採用外部控制的方式通知運行中的Netscape新建一個窗口。然而，Netscape程序本身經常由於不確切原因僵住（經常是在網絡訪問過程中，懷疑是Netscape程序內部關鍵代碼區域互斥的結果，而且所有的Netscape窗口都Block），導致應用僵死、切換失效。而且，這種外部控制的方式已經硬編碼在模塊中了，改變這種方式將會帶來大量的代碼修改。我們略微修改了一下調用的邏輯關係，情況有了好轉。
這期間，合作伙伴的VOD程序也早應該就位了。但是，不幸的是由於合作伙伴所在的公司發生了併購，交付的時間大大的被推遲了。Huang發現VOD程序在測試板上經常死機，Huang每天保持和合作公司的聯絡，終於解決了問題。
接下來是整個系統的整合，突然我們發現原來的由另一個由多媒體小組提供的Mp3播放程序使用的是Widget－XXX1.0，而我們使用的是其2.0版本，而且由於兩個版本有很大的體系結構差異，加之這個Mp3程序使用了很多1.0版本中未公開的功能，移植起來非常困難。這個程序的作者也是一個兼職人員，而且已經離開了公司，我一直聯繫不到他，他的代碼沒有任何註釋，而且沒有留下任何有關的設計文檔。不得已我們決定重寫，我自己花了4天3夜終於完成了Mp3程序。
這時已經6月5日了，我們告訴事業部經理，工作已經完成了99％，只差整合了。整合的時候，也發生了一些意外情況：小系統的Shell同大系統中的B Shell是不同的，有的腳本需要調整；精靈程序運行太慢了，這跟系統資源緊張有很大的關係，最後不得不取消了這個精靈程序；Netscape在資源緊張、CPU較慢的情況下，僵死的情況又頻繁發生了… …
已經6月12日了，整合仍然沒有最終完成，我們大量的設想權益之計設法讓系統基本運行正常。最終，在6月19日，我們把一個傷痕累累的系統提交給了系統測試部門。
系統測試部門進行了爲期4天的測試，然後用了兩天時間對所發現的Bug我們做了必要的修正，其餘全部的作爲限制型Bug，在6月26日把產品提交給用戶了。我們驚奇的發現，原來客戶對於不能在6月5日交付的反應並不強烈，這讓我們開始懷疑6月5日的Dead Line是如何得來的？
客戶在收到產品之後不久，就放棄了這個產品… …