首先，這篇說的只是正式會議，意味著不是站立會議，或者2、3個人在座位邊、過道上的討論，而是需要像模像樣的找一間會議室的那種。說到這裡，你一定有很多苦水想倒了，沒錯，大家都很痛苦，聽到「開會」這兩個字頭皮都發麻，那麼我們來一起看看怎麼減少痛苦吧。
首先，明確目的，最最重要，其實做乙個會議和做乙個產品也是一樣的。不要試圖在乙個會議中解決所有的問題，就算你要連著召集兩個參與人大部分相同的會議，我也建議你把它們分開，甚至，更好的做法，合理安排乙個會議中的議題，可以讓部分人早點走，或者晚點到。依據目的，類似的日常會議一般在15min～2、3個小時不等。
會議前，做好準備工作，資源的確定是小：會議室、投影儀、白板、紙筆、網路等等（視情況而定）；人員的確定是大：確認好「必選」的和「可選」的，不要漏人，也不要叫閒人，把握「大會決定小事，小會決定大事」的原則（「大/小」指的是參會人數，比如全公司的會議，是沒法討論事情的，只能傳達資訊）。識別出會議的kp（key person，關鍵人物），通常是最大的乙個或幾個老闆，提前當面或者**知會一下，然後發出會議邀請，我們用outlook。而傳送時間，我覺得日常會議提前24～72小時比較合適，看情況。邀請中需要註明會議的時間、地點、議程，每一項議程的估計時長，並且附上需要討論的文件初稿，要求大家會前閱讀（雖然很少有人能做到，很現實的問題），而對於kp，爭取提前與他討論關鍵議題，達成一致，叫做「串供」，這會讓會上省很多時間和精力。正所謂，要想讓會議不流於形式，就要把會議本身變成走走形式。
會議中，關鍵人物，在會前10min左右再次確認。關於遲到問題，其實沒法避免，一般等個5min是 極限，如果能想出合適的懲罰規則，會比較好。會議要有明確的主持人和記錄人，當然可以是同乙個人，主持人主要掌握整體時間進度，控制個人發言時間，均衡發 言機會，保證議題不走偏；記錄人要如實做好記錄，特別是「會議決議」與「遺留問題」（詳見下一節）。所有事情，盡量在會上達成一致，給出「會議決議」，實 在不行的可以作為「遺留問題」。最後，牢記很實用的「所有人提供意見，少數人討論，乙個人拍板」的民主集中原則。
會議後，會議記錄最重要。盡量在24小時內郵件發出，收件人是所有參與者，抄送給所有參與者的老闆，讓老闆們看到手下幹的活，讓大家知道老闆們看得到他們幹的活。然後給出「時間、地點、主持人、記錄人、議程資訊」，其實都不關鍵，關鍵是「會議決議」與「遺留問題」。 會議決議就是傳達，是會上大家確認過的，寫明是誰最終拍板的，其實也是增加他反悔的成本，形成習慣以後，大家才能都清楚決議的嚴肅性，並且保證後續動作的 連貫；遺留問題要描述清楚是什麼問題，誰負責解決（一定只能是乙個人），這個人承諾解決的時間點。相應討論過的文件有更新，也應該補充發出（不一定是做郵 件附件，我們通常給個wiki永久鏈結，自己去隨時檢視最新文件就好了）。
這一套跑下來還有個好處，因為難免會有人到不了會上，這樣通過會議前和後的兩個郵件，他也可以大概了解到主要情況。
最後還有興趣的同學，可以看看我寫過的幾個目的各不相同的會議例項：1～3小時不等的
評審會
；15min左右的
專案kick off
會
；半天時間，需要邀約產品使用者，提前布置會場，有預算的
使用者大會
。
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...
產品設計體會（十二） 少而精
長假回來，這兩天基本在全力做 批量定時上架 的需求，n多的pk 評審 確認會搞得頭昏腦脹，不過終於算是把需求確認掉了。其中有些關於功能做多做少的爭論，這個話題在體會 三 中有所設計，但說的不深，這裡再寫點。一 個功能的多次需求會議中，必然有這樣乙個過程。開始對乙個功能想的不完整，說著說著大家都想把這...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...