研發(fā)部需求開(kāi)發(fā)流程管理

1、管理目標(biāo)1 、 所有關(guān)系人清晰明確地了解項(xiàng)目的需求和期望，努力做到滿足項(xiàng)目所有關(guān)系人的不同需求；項(xiàng)目關(guān)系人包括：項(xiàng)目團(tuán)隊(duì)成員和項(xiàng)目團(tuán)隊(duì)外（內(nèi)部/外部客戶，內(nèi)部/外部合作伙伴，經(jīng)銷商 /客戶等）。2 、 項(xiàng)目管理三要素平衡（時(shí)間/ 成本 / 質(zhì)量） ，即開(kāi)發(fā)項(xiàng)目按需按時(shí)按質(zhì)的完成。3 、 目標(biāo)：功能滿足需求，設(shè)計(jì)支持變化，開(kāi)發(fā)快速迭代，成果持續(xù)交付。執(zhí)行概述1 、 建立有效的工作流程保證項(xiàng)目的順利進(jìn)行，初期使用傳統(tǒng)RUP 過(guò)程，引入部分敏捷方法，團(tuán)隊(duì)磨合完成后逐步實(shí)現(xiàn)敏捷開(kāi)發(fā)全流程管理。2 、 明確項(xiàng)目目標(biāo)，制定具有可行性的項(xiàng)目計(jì)劃，有效明確的分解項(xiàng)目需求。3 、 跟蹤設(shè)計(jì)/開(kāi)發(fā)/測(cè)試/回歸 /

2、發(fā)布全流程，推動(dòng)項(xiàng)目按預(yù)定計(jì)劃執(zhí)行。4 、 解決項(xiàng)目過(guò)程中出現(xiàn)的問(wèn)題和沖突，一般集中在需求不明/工作量或時(shí)長(zhǎng)/開(kāi)發(fā)難度/跨部門協(xié)調(diào)等幾個(gè)方面。5 、 調(diào)動(dòng)開(kāi)發(fā)團(tuán)隊(duì)的積極性，創(chuàng)造力，推動(dòng)團(tuán)隊(duì)成員在項(xiàng)目過(guò)程中的學(xué)習(xí)成長(zhǎng)。6 、 風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)控制以及風(fēng)險(xiǎn)的預(yù)案。項(xiàng)目管理1 、需求階段對(duì)項(xiàng)目進(jìn)行技術(shù)可行性分析、技術(shù)評(píng)估、成本評(píng)估以及風(fēng)險(xiǎn)評(píng)估。與需求提出方的代表進(jìn)行需求討論，明確項(xiàng)目的目標(biāo)、價(jià)值。確定項(xiàng)目范圍、功能及優(yōu)先級(jí)。組建項(xiàng)目團(tuán)隊(duì)，特別要搞清楚項(xiàng)目的關(guān)鍵人。項(xiàng)目啟動(dòng)會(huì)議，相關(guān)的關(guān)系人都必須參加。2、設(shè)計(jì)階段根據(jù)確認(rèn)后的軟件需求規(guī)格說(shuō)明書，制定項(xiàng)目進(jìn)度計(jì)劃，工作任務(wù)分解（WBS） ；資源申請(qǐng)，項(xiàng)目

3、涉及到的開(kāi)發(fā)資源、測(cè)試資源、設(shè)計(jì)資源（包括人員和軟硬件資源）；數(shù)據(jù)庫(kù)設(shè)計(jì)；系統(tǒng)設(shè)計(jì)；文檔（包括系統(tǒng)用例、Demo 、測(cè)試用例等）；評(píng)審會(huì)議。設(shè)計(jì)階段結(jié)果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設(shè)計(jì)文檔（概要設(shè)計(jì)和詳細(xì)設(shè)計(jì) ）/數(shù)據(jù)庫(kù)設(shè)計(jì)文檔等。該階段交付成果需要進(jìn)行評(píng)審。3、執(zhí)行階段（開(kāi)發(fā)和測(cè)試）準(zhǔn)備開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境。跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。項(xiàng)目成員以日?qǐng)?bào)/項(xiàng)目負(fù)責(zé)人以周報(bào)的形式通報(bào)各關(guān)系人當(dāng)前項(xiàng)目的進(jìn)展情況。按里程碑對(duì)階段成果進(jìn)行評(píng)估，以確保該階段完成的質(zhì)量。代碼審核，包括CS 審核、 SQL 審核、 WEB 審核等。對(duì)需求變更進(jìn)行控制管理。測(cè)試階段BUG 響應(yīng)及改進(jìn)、收集反饋意見(jiàn)。對(duì)項(xiàng)目風(fēng)險(xiǎn)

4、進(jìn)行管理。4、發(fā)布階段包括制定項(xiàng)目發(fā)布計(jì)劃，用戶培訓(xùn)，發(fā)布上線。5、試運(yùn)行階段數(shù)據(jù)監(jiān)控（日志、服務(wù)器狀態(tài)），根據(jù)監(jiān)控出現(xiàn)的問(wèn)題，及時(shí)進(jìn)行處理，改進(jìn)性能問(wèn)題，特定情況執(zhí)行補(bǔ)丁升級(jí)。6、收尾階段產(chǎn)品交付，項(xiàng)目總結(jié)會(huì)。常見(jiàn)問(wèn)題1 、開(kāi)發(fā)時(shí)間的估算制定項(xiàng)目計(jì)劃時(shí)，需要估算每個(gè)任務(wù)所需的時(shí)間，其中主要是開(kāi)發(fā)任務(wù)中模塊的分配和時(shí)間估算，在公司現(xiàn)有的技術(shù)框架下，開(kāi)發(fā)人員主要的工作是投入在具體的業(yè)務(wù)邏輯實(shí)現(xiàn)上。通常單個(gè)模塊開(kāi)發(fā)時(shí)間取決于以下因素：1 、負(fù)責(zé)模塊的業(yè)務(wù)邏輯的復(fù)雜程度。2、 開(kāi)發(fā)人員的技術(shù)水平和對(duì)項(xiàng)目所在應(yīng)用的熟悉程度（包括對(duì)框架和應(yīng)用的熟悉程度）。3、 模塊技術(shù)實(shí)現(xiàn)上是否存在難點(diǎn)，所謂的技術(shù)難點(diǎn)

5、定義是：在現(xiàn)有系統(tǒng)中還未實(shí)現(xiàn)的、開(kāi)發(fā)人員自身未沒(méi)接觸過(guò)的技術(shù)。對(duì)于這樣的難點(diǎn)，開(kāi)發(fā)者沒(méi)有相關(guān)的代碼可以參考，自己也沒(méi)有經(jīng)驗(yàn)，所以需要投入學(xué)習(xí)時(shí)間用于研究解決。模塊分配和開(kāi)發(fā)時(shí)間估算的步驟：1 、在劃分好模塊后，首先項(xiàng)目管理人員預(yù)先估算各個(gè)模塊所需要的開(kāi)發(fā)時(shí)間。2、召集所有開(kāi)發(fā)人員，討論模塊的分配和開(kāi)發(fā)時(shí)間估算。將劃分好的模塊，分配給開(kāi)發(fā)人員， 如狀況允許可允許開(kāi)發(fā)人員自主選擇以提高開(kāi)發(fā)人員的主動(dòng)性和參與性。分配模塊的時(shí)為確保開(kāi)發(fā)的速度和質(zhì)量，基本原則如下：A、類似的模塊由同一人負(fù)責(zé)開(kāi)發(fā)，比如用戶信息的增刪改應(yīng)由同一開(kāi)發(fā)者負(fù)責(zé)。這樣開(kāi)發(fā)者對(duì)相關(guān)邏輯會(huì)比較熟悉，代碼/接口的定義也會(huì)相對(duì)明確，溝通的

6、成本低，相應(yīng)可以降低功能實(shí)現(xiàn)的缺陷概率。B、技術(shù)難度較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。C、業(yè)務(wù)邏輯比較復(fù)雜的由對(duì)業(yè)務(wù)邏輯比較了解的人負(fù)責(zé)。3、模塊分配完成后，開(kāi)發(fā)人員評(píng)估自己負(fù)責(zé)開(kāi)發(fā)的模塊所需要的時(shí)間。在此過(guò)程中應(yīng)與開(kāi)發(fā)者討論每個(gè)模塊的技術(shù)實(shí)現(xiàn)細(xì)節(jié)，使時(shí)間的估算更加準(zhǔn)確。4、對(duì)開(kāi)發(fā)人員估算的時(shí)間進(jìn)行確認(rèn)。在確認(rèn)過(guò)程中作為，項(xiàng)目管理者將預(yù)估時(shí)間和開(kāi)發(fā)人員估算時(shí)間進(jìn)行比較。那些差異較大的，與人員探討其中的緣由。對(duì)于時(shí)間周期比較長(zhǎng)的任務(wù)，將任務(wù)拆分為更小的子任務(wù)，每個(gè)任務(wù)的完成時(shí)間為8-24 工時(shí)，消除時(shí)間周期較長(zhǎng)的任務(wù)，避免不確定性影響項(xiàng)目的進(jìn)度。2、CodeReviewCodeReview 是

7、保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié)，在這一環(huán)控制不嚴(yán)往往是測(cè)試后出現(xiàn)大量bug 的主因，有時(shí)甚至導(dǎo)致返工；關(guān)于CodeReview 執(zhí)行，首先應(yīng)有編碼規(guī)范和代碼審查規(guī)范。通過(guò)這兩個(gè)文檔來(lái)規(guī)范開(kāi)發(fā)人員的代碼實(shí)現(xiàn)，代碼編寫者必須要嚴(yán)格按照規(guī)范來(lái)進(jìn)行；代碼審核者根據(jù)這些標(biāo)準(zhǔn)來(lái)CodeReview 代碼，同時(shí)在CodeReview 過(guò)程中需要不斷完善該文檔。 CodeReview 一般可按以下步驟實(shí)施：1 、 檢查開(kāi)發(fā)者的代碼實(shí)現(xiàn)是否遵循了編碼規(guī)范。2 、 從代碼的易維護(hù)性、可擴(kuò)展性角度考察代碼的質(zhì)量，提出修改建議。3 、 代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase 依次講解自己

8、負(fù)責(zé)的代碼和相關(guān)邏輯，代碼審核者在此過(guò)程中可以隨時(shí)提出自己的疑問(wèn)，同時(shí)積極發(fā)現(xiàn)隱藏的 bug ，對(duì)這些bug 記錄在案。4 、 代碼講解完畢后，代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。代碼需要檢查Bug 。同時(shí)全面兼顧，確保代碼整體上結(jié)構(gòu)優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報(bào)告”記錄發(fā)現(xiàn)的問(wèn)題及修改建議，提交給相關(guān)人員。5 、 代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見(jiàn)，修改好代碼，有不清楚的地方可積極向代碼審核者提出。6 、 代碼編寫者bugfixed 完畢之后給出反饋。7 、 代碼審核者把CodeReview 中發(fā)現(xiàn)的有價(jià)值的問(wèn)題更新到"代碼審核規(guī)范"的文

9、檔中，對(duì)于特別值得提醒的問(wèn)題可群發(fā)email 給所有技術(shù)人員。3、需求變更管理需求變更管理也是項(xiàng)目管理中最重要的一個(gè)環(huán)節(jié)，對(duì)需求變更管理的有效性將直接影響項(xiàng)目的成功與否。對(duì)待需求變更的正確態(tài)度：1 、需求變更是不可避免的。2、需求變更要必須被管理。3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來(lái)的風(fēng)險(xiǎn)。需求變更管理的目標(biāo)：1 、相關(guān)的干系人必須清楚地了解發(fā)生的變更。2、變更處于有效的管理中。3、盡量降低變更帶來(lái)的風(fēng)險(xiǎn)。通過(guò)制定需求變更的流程，確保項(xiàng)目中的需求變更有效地進(jìn)行，實(shí)現(xiàn)上述的目標(biāo)。需求變更流程：1 、確定需求的基準(zhǔn)線。將以UserCase 作為需求基準(zhǔn)線，在UserCa

10、se 確認(rèn)之后的任何需求改變，都需要走需求變更流程。2、項(xiàng)目管理者接收到需求變更的要求。需求變更的提出者可以是項(xiàng)目中的任何人包括產(chǎn)品經(jīng)理、市場(chǎng)人員、開(kāi)發(fā)人員、測(cè)試人員等。3、項(xiàng)目管理者評(píng)估該需求變更。針對(duì)接收到的需求變更的要求，召集相關(guān)人員討論該需求變更的合理性、可行性，實(shí)施的代價(jià)以及對(duì)項(xiàng)目的影響。項(xiàng)目管理者對(duì)項(xiàng)目的成功與否負(fù)有主要的責(zé)任。需求變更的決策應(yīng)由項(xiàng)目管理者做出。4、需求變更確認(rèn)后，由專人將生成需求變更單記錄下來(lái)，通知給項(xiàng)目中所有關(guān)系人。5、 確定變更的負(fù)責(zé)人。承擔(dān)需求變更的具體工作，比如基線控制，對(duì)需求變更的記錄，并通知相關(guān)人員。6、相關(guān)人員接收到確認(rèn)的需求變更后，需求分析人員修改

11、需求說(shuō)明書和UserCase 的相關(guān)內(nèi)容。測(cè)試人員修改測(cè)試用例的相關(guān)內(nèi)容。開(kāi)發(fā)人員修改代碼中的相關(guān)部分。7、按照變更后的計(jì)劃實(shí)施項(xiàng)目，并進(jìn)行檢查，跟蹤，對(duì)變更后的實(shí)施反饋和可能出現(xiàn)的問(wèn)題及時(shí)溝通和處理。8、需求凍結(jié)。項(xiàng)目越到后期，需求變更對(duì)項(xiàng)目的影響就越大，所以在一定時(shí)候要進(jìn)入需求凍結(jié)階段，不再接收新需求或需求的變更。4、風(fēng)險(xiǎn)管理影響項(xiàng)目成敗的因素涉及方方面面，并且風(fēng)險(xiǎn)伴隨著項(xiàng)目的始終，是客觀存在的，風(fēng)險(xiǎn)引起的負(fù)面后果集中體現(xiàn)在進(jìn)度延后、成本超支、質(zhì)量不達(dá)標(biāo)等方面，常見(jiàn)風(fēng)險(xiǎn)如下：I 、目標(biāo)以及需求不明確為了市場(chǎng)競(jìng)爭(zhēng)或內(nèi)部管理決策的需要，業(yè)務(wù)部門提出的需求往往要求的時(shí)間比較緊迫， 需求的提出大多

12、停留在幾張紙或口頭的傳達(dá)上，沒(méi)有正式的業(yè)務(wù)需求文檔，在沒(méi)有明確的需求范圍的情況下，有時(shí)為了迎合業(yè)務(wù)部門的口味匆匆開(kāi)工，過(guò)程中用戶不斷地提出新的想法，技術(shù)人員開(kāi)始疲于奔命和應(yīng)付，很難保證項(xiàng)目的進(jìn)度和質(zhì)量，也難以取得業(yè)務(wù)部門的認(rèn)可。在項(xiàng)目的前期一定要采取相應(yīng)的手段或措施，與業(yè)務(wù)部門共同明確項(xiàng)目目標(biāo)、需求范圍， 充分考慮現(xiàn)有的時(shí)間和資源約束，將需求排定優(yōu)先級(jí)，對(duì)于關(guān)鍵的需求優(yōu)先實(shí)現(xiàn)，其他輔助性的根據(jù)過(guò)程中的具體情況進(jìn)行滾動(dòng)式計(jì)劃，并取得業(yè)務(wù)部門的書面確認(rèn)。在此過(guò)程中要注重挖掘用戶的隱性需求，可以通過(guò)引導(dǎo)、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。2、項(xiàng)目目標(biāo)擴(kuò)大以及需求變更在有了明確的目標(biāo)

13、和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務(wù)部門在看到具體系統(tǒng)的真實(shí)雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對(duì)此加以控制， 新的需求的加入通常會(huì)影響已實(shí)現(xiàn)的需求，并且對(duì)項(xiàng)目進(jìn)度和成本產(chǎn)生很大的影響。項(xiàng)目管理者針對(duì)這種情況一定要采取嚴(yán)格的變更控制流程，不能礙于面子，否則最終的結(jié)果往往是出力不討好。針對(duì)用戶提出的新需求，按照正式流程提出變更申請(qǐng)，組織相關(guān)團(tuán)隊(duì)成員進(jìn)行分析及評(píng)估，作為是否實(shí)施的依據(jù)，變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷是否批準(zhǔn)，如果批準(zhǔn)，那項(xiàng)目組可以安排實(shí)施，否則，正式拒絕用戶的請(qǐng)求。前期的需求討論要詳細(xì)、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項(xiàng)目中需求的決策

14、者（通常會(huì)是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶），所有的需求要經(jīng)過(guò)他們的認(rèn)可。客戶在項(xiàng)目過(guò)程中的全程參與有助于降低此類風(fēng)險(xiǎn)。需求討論、需求確認(rèn)、 UserCase 確認(rèn)、測(cè)試階段的客戶驗(yàn)收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時(shí)， 嚴(yán)格按照需求變更流程執(zhí)行。在分析設(shè)計(jì)階段的中的確認(rèn)和評(píng)審也是降低此類風(fēng)險(xiǎn)的重要手段。3、代碼質(zhì)量風(fēng)險(xiǎn)質(zhì)量風(fēng)險(xiǎn)主要指開(kāi)發(fā)代碼的質(zhì)量。在制定項(xiàng)目計(jì)劃時(shí)，對(duì)開(kāi)發(fā)時(shí)間的評(píng)估要盡可能的合適。 合理的開(kāi)發(fā)時(shí)間對(duì)開(kāi)發(fā)質(zhì)量的影響很大。開(kāi)發(fā)人員為了趕進(jìn)度在比較緊張的時(shí)間需要完成指定的任務(wù)，可能就存在很大的開(kāi)發(fā)質(zhì)量問(wèn)題。在編碼前，開(kāi)發(fā)人員要對(duì)框架熟練掌握；一份好的系統(tǒng)設(shè)計(jì)文檔對(duì)指導(dǎo)開(kāi)發(fā)非常

15、重要。往往有這樣一種情況，每個(gè)團(tuán)隊(duì)成員按照項(xiàng)目計(jì)劃報(bào)告進(jìn)度都是100% 完成， 但一到最后系統(tǒng)交互測(cè)試或集成的時(shí)候就會(huì)發(fā)現(xiàn)一大堆問(wèn)題。這需要在項(xiàng)目實(shí)施過(guò)程中采取有效的措施來(lái)規(guī)避風(fēng)險(xiǎn)，通常的做法有同行評(píng)審，比如概要設(shè)計(jì)完成之后，邀請(qǐng)其他項(xiàng)目組的技術(shù)專家進(jìn)行技術(shù)評(píng)審以發(fā)現(xiàn)架構(gòu)設(shè)計(jì)問(wèn)題；管理評(píng)審，通過(guò)組織級(jí)的質(zhì)量審計(jì)看產(chǎn)品以及實(shí)施過(guò)程是否滿足質(zhì)量要求；代碼走查，在編碼過(guò)程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70% 的錯(cuò)誤；每日構(gòu)建， 這是一種非常有效的方法，可以避免把各部分的集成問(wèn)題拖到最后，并且能夠及時(shí)發(fā)現(xiàn)相應(yīng)的錯(cuò)誤，日構(gòu)建一般在項(xiàng)目的中后期開(kāi)始，每天

16、自動(dòng)從版本服務(wù)器上獲取源代碼進(jìn)行自動(dòng)編譯和測(cè)試。4、人員技能和資源的不足項(xiàng)目實(shí)施過(guò)程中由于人員技能欠缺造成的進(jìn)度延后和軟件質(zhì)量問(wèn)題并不少見(jiàn)，一個(gè)熟練的技術(shù)人員完成同樣一個(gè)任務(wù)需要3 天，但一個(gè)新手可能就需要7-10 天。項(xiàng)目管理者應(yīng)該在前期就分析清楚項(xiàng)目所要采用的技術(shù)以及相應(yīng)的人員技能要求，針對(duì)不同的角色，及時(shí)采取相應(yīng)的技能培訓(xùn)，以保證項(xiàng)目的順利實(shí)施。開(kāi)發(fā)過(guò)程中遇到技術(shù)難題，導(dǎo)致開(kāi)發(fā)時(shí)間延遲或者需求不得不發(fā)生變更。在項(xiàng)目開(kāi)始前的技術(shù)評(píng)估階段，明確技術(shù)難點(diǎn)， 提前安排人員進(jìn)行攻克。如果在可預(yù)期的時(shí)間內(nèi)無(wú)法解決，如果可以，將向需求提出方要求變更需求或?qū)ふ铱商娲桨?。這樣的風(fēng)險(xiǎn)應(yīng)該在項(xiàng)目的前期階段就

17、應(yīng)該解決在萌芽狀態(tài)來(lái)避免這樣的風(fēng)險(xiǎn)在后期或中期出現(xiàn)。5、缺乏良好的團(tuán)隊(duì)協(xié)作軟件項(xiàng)目實(shí)施屬于知識(shí)型，要發(fā)揮團(tuán)隊(duì)成員的創(chuàng)造力，不同于制造業(yè)計(jì)件生產(chǎn)，各模塊最終要集成在一起形成一個(gè)有機(jī)的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關(guān)系，并在實(shí)施過(guò)程中持續(xù)地溝通交流和共享，首先團(tuán)隊(duì)要融為一體，產(chǎn)出的軟件才能融為一體。這是一個(gè)團(tuán)隊(duì)的軟實(shí)力，團(tuán)隊(duì)之間的協(xié)作好壞也將是個(gè)潛在的風(fēng)險(xiǎn)問(wèn)題，在項(xiàng)目啟動(dòng)和團(tuán)隊(duì)組建的時(shí)候就應(yīng)該加以規(guī)避這樣的風(fēng)險(xiǎn)出現(xiàn)。6、項(xiàng)目會(huì)議組織會(huì)議是項(xiàng)目執(zhí)行過(guò)程中一項(xiàng)非常重要的工作任務(wù)，項(xiàng)目過(guò)程中很多重要的決定都是在會(huì)議中做出的，不成功的會(huì)議會(huì)對(duì)項(xiàng)目本身造成了不好的影響。不成功的會(huì)

18、議通常表現(xiàn)為如下形式：II 、會(huì)議氛圍不好，參與者發(fā)言不踴躍；2、會(huì)議討論常常偏離主題；3、會(huì)議沒(méi)有取得預(yù)期的結(jié)果；4、會(huì)議時(shí)間常常一拖再拖。這些不成功的會(huì)議最終的結(jié)果就是：既浪費(fèi)了大家的寶貴時(shí)間又沒(méi)有達(dá)到會(huì)議的目的，很多人都對(duì)這樣的會(huì)議都有抵觸情緒，對(duì)此也是深惡痛絕。以下是組織會(huì)議時(shí)應(yīng)該注意的問(wèn)題，也可看作組織會(huì)議的最佳實(shí)踐。在列出最佳實(shí)踐之前有三點(diǎn)我們必須要清楚：III 、會(huì)議是否會(huì)取得成功很大程度上取決于會(huì)議的組織者。只有組織得有力，會(huì)議才有可能取得成功，這是會(huì)議成功的充分條件。2、會(huì)議的組織者和參與者的想法通常是不一致的，有時(shí)候甚至?xí)笙鄰酵ァＫ圆灰Ｍ麜?huì)議的參與者和你一樣，對(duì)會(huì)議有著如此的期待，對(duì)大多數(shù)參與者而言，在會(huì)議中他只是一個(gè)發(fā)表想法的人，他不用對(duì)會(huì)議的成功承擔(dān)責(zé)任。3、以下十一條最佳實(shí)踐是形式上的約定，具體的實(shí)施可以根據(jù)實(shí)際情況來(lái)做。組織會(huì)議的十一條最佳實(shí)踐：IV 、只有需要開(kāi)會(huì)時(shí)才開(kāi)會(huì)。有時(shí)候兩三個(gè)人單獨(dú)小范圍溝通會(huì)更加有效。2、提前發(fā)出會(huì)議議程，以便會(huì)議參與者知道他們來(lái)做什么。