另外，你還可以采用一些專業的方法論來解決這種討論問題，比如的六頂思考帽。你可以按照不同的帽子顏色來組織大家思考，如在白色帽子里討論客觀的事實；在黃色帽子里討論做這個事情的好處；在綠色帽子里發揮創新，看看這個事情能做成什么樣子，發揮想象力；在藍色帽子里討論做事情的邏輯、步驟；在黑色帽子里討論未來的風險和預防措施；在紅色的帽子里談談大家對這個事情的主觀感受。這樣會議才不會失控，觀點也被羅列得很清楚。
在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我不知道如何檢查。所以，給開發小組布置任務的時候要考慮如何檢查結果，比如我見過一個計劃，里面有一個任務【開發人員熟悉EJB編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情，我聽說有些老項目經理拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然后決定工作計劃。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性很大了。做項目是為了驗收，拿到錢，我們的角色不是研究機構，我們的目的是在付出那么多勞動后得到結果。另外我插一句：我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流，很容易引起沖突和矛盾（技術人員的本性決定的）。我的做法是項目經理和項目實施人員到現場，軟件開發人員還是在公司做項目。項目實施人員是初級項目經理，他們了解自己的產品，懂得一些客戶的業務，關鍵是在于他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發人員的橋梁，其職業方向也是很機動靈活，以后可以有很多方向可以轉，比如銷售、行業顧問等，其出路反而比開發人員的路要寬得多。接著，我們再談談讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更；另一種是沒改變目標，但是客戶不滿意目前的實現方式，大到流程的實現，小到界面的布局，都是屬于這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改并且你的戰略是容許這種情況的，那么注意下面幾點：
1. 確保以前的文檔，是記載著以前的結論的東西，客戶是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客戶自己確認一下你的方案，然后讓他簽字，避免以后說話沒有憑據；
2. 和客戶坐下來，自己探討他修改的根本目的是什么，是不是有同樣能達到相同目的，但是對你來說有代價更小的選擇？
3. （項目初期的工作）明確更改流程，一般是客戶指定一人簽字（否則客戶每個領導都有權力來插一杠子，你廢了），以正式項目文件的方式提交給你，然后，你做評估分析，分析對成本、進度的影響，在你的領導同意后，出相應意見書，主要是要說明更改設計的原因和指出由此帶來的不確定后果（這個東西先寫出來，后面如果真的發生了，至少不是你的錯）。然后再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人簽的免責條款嗎？對，學習那個，讓大家都意識到任何的更改都有成本和代價。
所以，對于這種需求天天變的客戶，你一定要事先做好規矩：一、統一聯系人，客戶指定一個人和項目組進行溝通，不能張領導、王領導都來說幾句，如果他們意見不一致，那你只有得罪領導的選擇了，所以，項目的初要定好規矩，我項目組只認一個的意見，有什么要求你們內部先統一再和我談，我不想卷入你們內部業務部門之間的矛盾之中；
一、所有需求變更全部要有書面文字，這點切記！這樣做好處多多：
*有書面證據，以后他還想改，你有了他以前要求的證據，告訴他：你以前可是這么說的；
*便于需求變更管理，需求如何慢慢演變的歷史可以看清楚，從而更深切地體會客戶的目的；
*對于客戶來說，嘴巴一動方便，反正是你們做，不花他的資源，所以要求是否合理，是否和項目的目的一致，他是不負責任的。但是如果要他寫書面要求，還要簽字蓋章，他要謹慎多了，而且一寫東西，思想會更加深入，很多無理要求也這樣胎死腹中了；
系統開發告一段落后，進入客戶培訓、系統驗收階段，這個階段，我一般會注意以下幾個問題：
給客戶做培訓前，多注意一些表面功夫。很多程序員認為，既然很多系統采用原型法，有一個由粗到精的過程，那么系統的邏輯核心是否正確才是關鍵，至于界面如何，界面上的用詞是否準確，那是無關緊要的問題；而且培訓的時候也是空手上臺、信手拈來，想到哪里說到哪里，下面聽講的人不知所云，云山霧罩，培訓效果自然可以想象。我的體會是，給客戶做培訓的版本，如果你在做多次測試以后仍然不能確定邏輯是否合乎要求，那么，你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、鏈接的正確性等等，總之不要讓客戶看到一些他不該看到的東西，否則，僅僅因為一些無關緊要的報錯讓客戶第一印象覺得系統不穩定，那你真的比竇娥還冤了。如果工作再做得詳細一點，可以做一些類似Flash的東西，把一些你要強調的重點用通俗易懂、輕松愉快的方式表達出來。文檔方面，準備至少兩個文檔：用戶手冊和培訓手冊。這兩個文檔的內容很多都是一致的，但是角度完全不同。用戶手冊往往是站在系統設計者的角度，按照自己的思路，分模塊講解系統的操作和功能；而培訓手冊，一定要站在客戶業務人員的角度，根據每個角色面對不同業務的辦理，如何通過使用本系統的一系列功能來實現目標。所以，第一次培訓以前，系統界面是否完整正確、培訓文檔是否完備、培訓時所舉的例子是否有代表性都是很關鍵的因素，第一炮打不響，以后麻煩很多。
上面講的是培訓的時候，丑媳婦要化妝好再去見公婆的問題。其實，項目實施中還有一個考驗項目經理功力的是如何調動客戶積極性的問題。一般來說，客戶是懶的，這是他花錢找你做事情的原因。一個項目的成敗，和客戶的配合程度很有關系。根據我的分析，一般項目中的客戶都可以分為三類：支持的、消極觀望的、抵觸的。他們人數的分布一般是一個紡錘形：支持的和抵觸的人少，觀望的人多（如果你接了一個人人都抵觸你的項目，那你還是不要做了）。首先，分析一下那些人為什么支持你和抵觸你。很簡單，于公于私兩個方面分析，上了新系統，誰的工作量有所變化？誰的潛在利益是否受到威脅？誰的崗位是不是因為新系統而消失？傳統的利益格局因為新系統的使用而發生怎么樣的變化，這些東西，都是項目經理必須去了解的，這樣，你才能團結那些支持你的人，消減那些抵觸你的人。項目經理是一個很奇怪的角色，屬于典型的責任大、權力小的角色，他能做的只有借力打力，不管在自己公司還是在客戶那里，一定要依靠別人才能完成自己的目的。只有了解哪些人會因為什么而幫助你，哪些人會因為什么而抵觸你，你才能讓客戶配合你做工作。比如上一些內部計算機輔助管理系統，其必然后果是讓本來管理混亂時有人可以渾水摸魚的一些利益消失掉了，這樣，有些人肯定要搗亂，到處詆毀這個系統。這時候，你可以散布一些"誰抵制新系統說明自己屁股上有屎"這類的論調去壓制他們，減弱他們的影響。總之，團結積極分子，打壓敵對分子，帶動大多數是你的基本策略。還有一個體會和大家分享：千萬不要覺得對方的領導（中層干部）是應該配合你工作的，特別是一些國營單位，多一事不如少一事，他干嗎要幫你？我的經驗是：對方領導如果沒有拿你的事情作為內部斗爭的武器而從中作梗（當然，他針對的不一定是你），那已經是算合作的了，記住，他不搗亂是幫你忙了。作為項目經理，其實腦子里是幾樣東西：做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優先級。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬于典型的又要馬兒跑，又要馬兒不吃草的類型。一般說來，項目經理在考慮問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你后期限，所以保進度是第一位的；省是第二位的，企業的根本目的是盈利，如果收入不能增加的話，至少費用要控制住；好是第三位的，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質量只好先犧牲了；后是多，客戶的要求源源不斷，如何降低客戶的期望值，把項目控制在一個合適的范圍內，讓客戶從理想回到現實也是項目經理的分內工作。
