首先,這篇說的只是正式會議,意味著不是站立會議,或者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個子模組是合理的,否則要考慮重新劃分 由於這個癖好,自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了,這部分其實又涉及另外乙個很大的...