這是人月神話：軟體專案管理之道（20週年紀念版）的第六章：意念的傳達，這一章的開場白：『他將會坐在這兒，說：「做這個！做那個！」然後什麼事都不會發生。』—杜魯門．《總統的權力》，繁體中文版的有個譯註解釋這句開場白的由來，簡體中文好像沒有這個解釋，但是如果你去Google還是可以找得到『More quotes by Harry S. Truman』的一些引用，這是一場總統大選時杜魯門揶揄艾森豪這個軍人當上總統會是怎樣，我想很多的台灣的選舉，很多競選人也多會運用這樣的批評對頭吧！
但是如果把它運用在本章的話，有另外一個詮釋了，一個專案經理如何指揮實作人員來落實架構設計的決策呢？ㄚ琪覺得這一章一言以蔽之，應該就是溝通吧，如何做好溝通，以下介紹了一些工具：
書面規格–手冊
『手冊載明的是產品的外部(external)規格，用來描述並制定出使用者從外觀上將會看到的所有細節，而撰寫手冊便是架構設計師的主要工作。』
『架構設計師為了造福實作人員，將修改的程度予以量化(quantize)是很重要的–在時程上應該要有載明日期的版本資訊。』
『架構設計師應該提出一種實作方式…但不應硬性規定採用特定的實作方式。』
秉持不流於瑣碎(not trial)的原則。
正式定義
採用正式標記法(formal notation)，這個標記法有優缺點，所以也需另外有個散文式的定義，以便讓人看懂，有一些工具，Backus-Naur Form（巴科斯範式，即 BNF）、抽象語法(abstract syntax)、APL（APL語言）以及新型註記法。
避免拿現成的實作來當作正式定義，雖然這樣開法比較快，但是後續還是會發生問題。
將定義直接融入實作
開會
這裡附上一段簡體文的引用：『
1. 數月內，相同小組——架構設計師、用戶和實作人員——每周交流一次。因此，大家對專案相關的內容比較了解，不需要安排額外時間對人員進行培訓。
2. 上述小組十分睿智和敏銳，深刻理解所面對的問題，並且與產品密切相關。沒有人是“顧問”的角色，每個人都要承擔義務。
3. 當問題出現時，在界線的內部和外部同時尋求解決方案。
4. 正式的書面建議集中了注意力，強制了決策的制訂，避免了會議草稿紀錄方式的不一致。
5. 清晰地授予首席系統架構設計師決策的權力，避免了妥協和拖延。』
總之，開會是必要且重要的，雖然我一直很討厭開會。
多重實作
電話紀錄
還記得以前當兵時候，在安官室站哨最重要的就是電話紀錄，我一直很嚮往這種方式，真的是好啊！
產品測試
有誰認為這不用做的，應該沒有人說不用，繼續保持！