這是人月神話：軟體專案管理之道（20週年紀念版）的第十四章：釀成大災難(Hatching a Catastrophe），簡體版譯作祸起萧墙，翻成禍起蕭牆還真有點怪，因為這個的比喻是這樣寫的『《論語．季氏》：“吾恐季孫之憂，不在顓臾，而在蕭牆之內也。”蕭牆，門屏，用來分隔內外的小牆。比喻禍亂發生在內部』，但是ㄚ琪在看全篇文章時，與其說是災難倒不如說是專案延後，或許比較沒有那麼嚴重吧，不過至於翻譯的準確度，就請繼續看吧。
里程碑或沈重的包袱
這裡提到里程碑(milestone)，我想我終於瞭解了為什麼我的專案管理會有這個選項的功能了，專案裡面有工作，而工作就得憑經驗來預估一個日期，所以沒經驗要預估應該是很難的。可是下文又說，里程碑必需是具體、明確、可量測的事件，哇哩咧，這不就很矛盾了，看得讓人霧煞煞的。但是如果里程碑真的定得很模糊的話，那麼我想老闆真的無法得知事實的真相，所以老闆要真相，就得找誠實的工人了，不然人的本性如何，大家很清楚。但是有時候大家又覺得小事情可以自己解決，所以在不清楚事情的嚴重性時，應該也是稍微延後事情的真相吧，這個不論在工作場合，甚且在教會的事工場合，ㄚ琪也是都或多或少有碰過，有時自己是受害者，有時自己是罪魁禍首，不論怎樣我們都要悔改，但要悔改如果你不看完這篇，我想憑智慧也不會覺得哪裡不對吧。
「反正其他部份也會落後」
這種心態充斥於所有的人事物場合，反正別人都這樣，那我為什麼不可以這樣，我們很容易以他人的隨便敷衍的態度來找台階下，看起來是非常不可取的行為，我們真的需要一種很有幹勁(hustle)的精神，很積極的態度去看待所有事。至於在專案工作裡面，是否可以延後，評估的基準課本題到了ㄚ琪學過的一個工具，計畫評核圖(PERT chart)或要徑時程表(critical-path schedule)，應該就可以幫助我們瞭解什麼是可以延後的，另外這兩者看起來也很像，所以作者直接把要徑網路圖(critical-path network)稱作計畫評核圖。
在一切順利的表象之下
所謂冰山一角吧，上位者如果太遜，搞不懂下位者的行事作風，那麼指鹿為馬的事不重出江湖也難，所以老闆要學習的就是，降低角色的衝突以鼓勵據實回報；以及審查制度。歷史真的可以借鑒，唐朝的魏徵為什麼可以據實回報並且可以諫勸，很清楚地還是來自上位者的鼓勵。而審查制度的執行及設計，應該最主要的就在避免因人產生的問題吧，所以要真相就得靠這兩個部份。舉個簡單例子，如果一位主管不懂現場的事務，不會去看現場，我想現場很容易被好玩技倆的現場員工蒙蔽掉，這是不爭的事實，所以要精明不是那麼簡單的事。
最後我覺得全篇文章在鼓勵計畫評核圖的使用，另外計畫監控小組的編制看起來在控管專案的的準確執行以避免大災難一點一點地變大是有早期預警的效果，還是防範重於預防，可是如果真的發生了，是否有危機處理的功夫，ㄚ琪倒是很想學，雖然我已經學過了，不過我認為沒有精。