場景一：
專案經理接到乙個新的專案，把大家叫到一起開會來介紹這個新的專案。首先，他介紹了這個專案是幹什麼用的。然後開始了下面的介紹。
「大家看，這個地方使用者需要輸入乙個訂單，這個訂單呢，就是這麼乙個表」(說著畫出了標的結構)「這個欄位呢可能有些問題。。。。。。」
下面有乙個人馬上就說了：「可是我覺得叫這個名字怎麼這麼奇怪呢，是不是可以叫。。。」
之後，專案的介紹會陷入了討論的「氛圍」，一會研究表結構，一會覺得功能多，**不合理。總之３個小時之後，出現了戲劇性的一幕：
專案經理：最後，房地產開發商就會察看這些單子。。。。。。
話還沒說完，下面乙個人問：這個專案和房地產開發商有什麼關係？
專案經理：這個系統就是給他們用的阿！
那個人：啊？我們討論的不是給零售連鎖店用的阿！？
結果乙個星期後，這個專案取消了。
場景二：
專案經理：這個功能需要修改一下，你看一下怎麼修改比較好。
ｐｌ：嗯，如果這樣的話，我需要增加乙個表，然後欄位會很麻煩。
很可惜得是，專案經理不熟悉資料庫這個東西，兩個人開始了爭論表結構的開始。
場景三：
專案經理接到乙個專案的意向書，客戶寫了１００個字的需求。他召開了乙個會議，要大家從這１００個字裡挖掘出更多的需求。於是乎，大家用了３個小時，討論了架構，討論了資料庫，討論了一切可以討論的東西。
等回到座位，專案經理收到了客戶的信，長達１４頁的word文件，需求完全改變。
三個場景不是我胡編亂造的，都是我親身經歷的。
第乙個場景中，最後那句話「啊？我們討論的不是給零售連鎖店用的阿！？」就是我問的。
第二個場景中，我是旁聽者。
第三個場景中，我早就預計到結果，所以我沒有浪費太多的體力。
請原諒我使用了「專案經理」這個詞，這只是乙個代號而已，別誣衊了專案經理這個職位的名聲。
為什麼有那麼多人就那麼喜歡在一開始就一頭扎入到細節中呢？
[list]
[*]在專案還沒有被確定的時候，就開始討論架構，討論資料庫。
[*]在客戶的需求還沒確定的時候，就開始討論表結構。
[/list]
在需求採集階段，或者說需求磨合階段，[b]請不要過早討論細節！[/b]細節的完善是乙個漫長的過程，在這之前，我們要拋開細節，要先弄清楚客戶想要什麼，之後我們再去討論細節，因為這些東西對於客戶來說一點意義也沒有。
不要沉迷細節
沉迷在細節中 開發者沉浸在細節中不可自拔？最終發現整體目標沒達到，驗收標準不過關，時間沒有按照要求。最終導致了專案延遲，客戶滿意度下降。其實敏捷也是提倡最小mvp，可交付的這些概念，跟關鍵路徑的概念一脈相承。我們必須在有限的資源的情況下最大化交付價值。但是這幾周我們全都過於沉浸在細節中，忽視了交付的...
討論記錄之C 細節
participants lf，hzp，cpp，zy date 08 09 16 7 20pm recorder cpp，zy 參考文獻 1 effective c 2nd edition，scott meyers etc.2 c 程式設計教程 錢能 3 高質量c c程式設計指南 林銳 4 應大家的...
穩定的完成埠開發細節討論
完成埠做為windows上最高效的網路程式設計模型，做為眾多伺服器網路層的首選。網上有很多參考資料和示例原始碼，大多存在問題，本文將以開發乙個穩定易用的完成埠元件為目標，詳細討論開發過程中所遇到的細節問題，並給出相應的解決方案。閱讀本文需要你有這方面的開發經驗，對於iocp的工作流程以及上層的應用有...