顯然，對於我當前所處的團隊，手冊是不存在的，我到現在都不知道手冊該寫些什麼，誠然，我看過很多說明手冊，教如何使用產品或者如何操作手順書。作者所說的手冊是「不但要能夠描述包括所有介面在內的使用者可見的一切，同時要避免描述使用者看不見的事物」。之前在日企工作時，大量的產品說明手冊，我不知道日本人是怎麼做出來的，很多還沒有創造出來的產品，他們就能夠寫出大量詳細的文件以及圖形。
思考：手冊到底該描述寫什麼？針對我當前所開發的**交易平台，我們的手冊是什麼？
也就是說，在寫手冊的時候，手冊的寫作內容要形式化，避免表達的不夠精確，如果可以的話，需要伴隨一定的記述性定義。
作者所說的會議室周例會，而大會就是所謂的年會。當然對於我當前的專案來說，會議就是和客戶、領導一起，討論新需求的合理性，如果需求合理，大家討論如何實現，然後就是分解需求，進而實現它。
面對客戶和領導的壓力，我需要在會議上堅持如下要點：
需求的合理性，往往很多時候，客戶提出的需求都是憑空想象的，當然他已經擁有了很多經驗。
需求的必要性，客戶和領導很少會去衡量他們想法的必要性。
需求的優先順序，他們似乎從來不去認真的思考需求的優先順序，當前階段有必要做不做，做完以後用不用。
需求的負影響，如果要做這個需求，對當前已經穩定的系統有什麼影響。
然後再來看看作者提出的觀點和方法：
結構師、使用者和實現人員每週交流一次，會讓大家對專案內容比較了解。
會讓每個人承擔理解面對問題的義務。
明確首席結構師的話語權。
在這個小節中，我認為作者的這句話非常好，如下「對於存在疑問的程式設計師，鼓勵他們打**詢問相應的結構師，而不是一邊猜測一邊工作，這是項基本措施」，這句話看似簡單，在我們的專案團隊中卻遇到了很大問題，多數情況下，需求不停變換，進而導致程式設計師對於模糊的需求不求甚解，在開發的時候依靠自己的判斷力去決策，最終導致大量的返工。
看完這個章節的內容後，我有點莫名的憂傷。因為一年前，我的專案小組就沒有專職的測試人員，一直到現在，充當測試的人員是我，多重角色的苦惱一直無法解決，肯定是成本和重視的原因。
拋開個人團隊因素，產品測試非常的重要，乙個成熟的測試團隊是保證產品質量以及產品創新的驅動力，測試團隊就是使用者的代表，他們反饋的問題是結構師、開發人員最不願意看到的，然而這樣就會保證bug無所遁從。
《人月神話》筆記 貫徹執行
假設乙個專案經理已經擁有形式規範 富有經驗的結構師和許多程式設計實現人員，那麼，他如何確保每個人聽到 理解並實現結構師的決策？對於乙個由1000人開發的系統，乙個10個結構師的小組如何保持系統概念上的完整性？我們可以使用以下措施 或方法 來提公升我們的執行力 文件化的規格說明 手冊 形式化定義 定期...
人月神話（6）貫徹執行
思維導圖 問題主旨 在概念性完整性的情況下，更好的執行，和高質量執行的方法 手冊作用和功能 手冊是產品的外部規格說明，它描述和規定了使用者所見的每乙個細節，同樣地，它也是結構師的主要產物 如何製作手冊額注意事項 優秀手冊具備的要素 形式化定義 優點 形式化定義是準確額，傾向完整。差異越明顯，填補得越...
人月神話札記 溝通
前言 在最初的世界，人們只有一種語言，所以大家溝通好說去建立乙個通天塔，可以通往天堂的巴比倫塔，然而上帝出現了，他交給人們不同的語言，讓大夥最終無法進行交流，最終隊伍遣散，巴比倫塔就此失敗，那麼本章作者想要告訴我們的就是 溝通 對於成功的專案很重要。書中主要針對的是大型專案的交流，然而同樣適合我當前...