推薦一本寫給IT項目經理的好書 - Patrick,Song

推薦一本寫給IT項目經理的好書

清理電腦,十數年來,無數資料,近來每天抽空好好整理整理, 做IT的特别是整ERP的,四個字形容:命苦可憐.   發現本給IT項目經理的好書.

内容簡介

這個世界上寫給項目經理的書很多，寫給IT項目經理的書也不少，但寫給從事管理軟體實施的項目管理書籍并不多。

　　 而筆者在從事項目經理工作中感到一個很苦惱的問題是，很多書其實非常經典，但都有一個缺點：理論正确，實戰指導作用不足。

　　 不是親身親曆的人是很難領悟到那些理論的精髓，而每個剛剛入行又立志成為一個IT實施的新人往往不是一開始就能從理論上武裝自己，在他們起步的時候，每天要面臨着各種具體工作任務，例如做調研，寫計劃，寫方案，寫備忘錄，做項目彙報，做示範，這些活動與其說是項目管理發揮作用大，不如說這是具體業務技能的領域。

一個IT人如果沒有經受專業的教育訓練，在不能掌握這些技能之前，我個人體會是往往是努力的把事情做砸。

　　 目前的IT服務品質更大程度上取決于實施人員個人能力，也許隻有有一大批同等品質服務的實施人員湧現，一個公司的才有可能順利推進項目管理的思路。

　　 是以筆者就有一個想法，想把自己在項目實施從售前到售後的體會和經驗總結為一些專項技能，并希望它具有可操作性，和大家一起交流總結，不斷積累并臻于完善。

　　 也希望各位朋友看後多評論，多留言，多給筆者提出改進意見，本人将結合大家意見不斷完善，将大家的想法變成業内智慧的結晶，讓更多的人能在IT實施工作中做到遊刃有餘

目   錄

前言

2 如何做業務調研？

2.1 調研工作如何組織？

2.2 調研準備階段容易犯哪些錯誤？

2.3 調研準備階段容易犯哪些錯誤？)

2.4 調研準備階段容易犯哪些錯誤？

2.5 現場調研階段容易犯哪些錯誤？

2.6 現場調研階段容易犯哪些錯誤？

2.7 現場調研階段容易犯哪些錯誤？

2.8 現場調研階段容易犯哪些錯誤？)

2.9 現場調研階段容易犯哪些錯誤？

2.10 現場調研階段容易犯哪些錯誤？

2.11 調研工作方法推薦

2.12 接口調研背景知識(上)

2.13 接口調研背景知識(下)

2.14 調研後續工作落實階段

3 如何寫解決方案？

3.1 解決方案難寫在哪裡？(連載十五)

3.2 壞的解決方案有哪些特征？(上)(連載十六)

3.3 壞的解決方案有哪些特征？(中)(連載十七)

3.4 壞的解決方案有哪些特征？(下)(連載十八)

3.5 寫好方案心得(上)(連載十九)

3.6 寫好方案心得(下)(連載二十)

3.7 方案分類及用途(連載二十一)

4 如何做産品示範？

4.1 什麼是示範？(連載二十二)

4.2 示範的目的

4.3 售前示範為什麼效果不好？(上)(連載二十三)

4.4 售前示範為什麼效果不好？(下)(連載二十四)

4.5 售前示範工作應如何組織？(上)(連載二十五)

4.6 售前示範工作應如何組織？(下)(連載二十六)

4.7 如何準備标準示範套路？(上)(連載二十七)

4.8 如何準備标準示範套路？(下)(連載二十八)

4.9 如何進行現場示範(一)(連載二十九)

4.10 如何進行現場示範(二)(連載三十)

4.11 如何進行現場示範(三)(連載三十一)

4.12 如何進行現場示範(四)(連載三十二)

4.13 如何進行現場示範(五)(連載三十三)

4.14 如何組織示範後工作(連載三十四)

4.15 示範方案準備經常考慮的問題(連載三十五)

5 如何做使用者考察？

5.1 前言(連載三十六)

5.2 典型使用者有什麼意義？

5.3 典型使用者應如何管理(上)(連載三十七)

5.4 典型使用者應如何管理(下)(連載三十八)

5.5 使用者現場考察應如何組織？(上)(連載三十九)

5.6 使用者現場考察應如何組織？(中)(連載四十)

5.7 使用者現場考察應如何組織？(下)(連載四十一)

6 如何做公司介紹？

6.1 前言(連載四十二)

6.2 哪些情況下需要公司介紹

6.3 正式陳述時常見錯誤？

6.4 口頭和會面介紹時常見技巧(連載四十三)

6.5 在客戶處進行公司介紹三個要點

6.6 如何對在公司考察客戶做介紹(連載四十四)

6.7 做好總部公司介紹的三個決竅

6.8 公司總部接待考察客戶要注意的細節

7.1 教育訓練工作在項目實施中作用(上)(連載四十五)

7.2 教育訓練工作在項目實施中作用(中)(連載四十六)

7.3 教育訓練工作在項目實施中作用(下)(連載四十七)

7.4 教育訓練工作應如何組織？(連載四十八)

7.5 教育訓練注意事項(連載四十九)

7.6 總部教育訓練

8 如何做現場推廣?

8.1 現場推廣工作可進行條件？(連載五十)

8.2 現場推廣工作為什麼進展慢？

8.2.2 要推廣的業務流不完整(連載五十一)

8.2.4 沒有激發使用者的主動性(連載五十二)

8.2.6 邊界總在變更(連載五十三)

8.3 現場推廣工作如何才能做好？(連載五十四)

9 如何做項目驗收?

9.1 驗收工作應如何組織？(連載五十五)

9.1.3 主動溝通(連載五十六)

9.1.4 寫好備忘錄(連載五十七)

9.2 如何催款？

10 如何做項目團隊管理

10.1 前言(連載五十八)

10.2 好的項目團隊建構要求

10.3 好團隊的兩個特征(連載五十九)

10.4 如何看待項目經理在團隊中作用

10.5 團隊建設心得和誤區(連載六十)

1 前言

　　在IT行業，特别是管理軟體實施行業能夠成為一個成功的項目經理是非常困難的一件事情，一個成功的IT經理，被要求熟悉計算機軟硬體知識，精通企業業務背景，擁有良好的溝通技巧和說服能力，當然在項目團隊中還必須具有威信和執行力，這樣的人才簡直是完人。

　　一般人即使努力也不可能達到這樣的一個完美的項目經理的境界，如果相信自己努力就可以做到可能是受哪些成功書籍的毒害太深。

　更多的項目經理是擁有崗位并非擁有崗位技能，但可笑的是，往往是一個人剛剛被發現具備這樣的潛質就會沒有多少機會實施項目，而是陷入另一種疲于奔命的狀态。

　　因為一個具有豐富實戰經驗的人對企業最有價值的場合不是深入實施某個具體的項目，而是進入售前。

　　管理軟體銷售是最合适顧問式銷售技術，但很難想象一個沒有實際實施項目經驗的顧問可以有效把握企業需求和打動對軟體供應商本質上都保持狐疑的潛在客戶，這些都隻有通過經驗豐富的項目經理才可以做到。

　　如果一家軟體公司的問題還是生存的問題，這樣優秀的實施顧問最合理的選擇就是售前咨詢顧問。很多使用者往往在合作後感覺到售前和售後交流時存在巨大落差，就是因為售前你看到的是已經證明過自己的顧問，售後你看到的就是還需要證明自己的顧問。

　　筆者自己也是走過了這麼一條路，是以現在想一想，做項目經理難，做管理軟體的項目經理尤其難，五年下來，忙得不亦樂乎。常常笑言自己是職業“三陪”，陪客戶交流，陪客戶考察，陪客戶吃飯。

　　不過和大量客戶交流也的确從另一個角度豐富了本人的閱曆，也對整個管理資訊化事業的建設從另一個角度(售前)增加了新的認識，在本文本人将自己售前售後一些工作心得分為九種技能(業務調研，解決方案，産品示範，使用者考察，公司介紹，使用者教育訓練，現場推廣，項目驗收，團隊管理)，分别整理成文，希望能給在這個行業内拼搏的同道一些啟發。

2 如何做業務調研？

　　2.1 調研工作如何組織？

　　很多人認為調研工作極難，水準最高的人才能做好一次調研，軟體工程中也強調需求擷取是最難的事情。有的人要麼認為不過如此，甚至是一個普通技術支援都可以做的工作。

　　現在有很多企業上管理軟體之前都希望軟體公司派人來了解情況，提出針對性建議。這其實給很多軟體公司銷售經理出了個難題，自己親自上企業不信任，而且也不專業，請公司派咨詢顧問過來資源難以協調，響應不及時使用者也不滿意，而且贻誤商機，随便來一個技術支援又不能保證調研品質，在後續工作中也難以讓使用者信服。

　　其實難和不難，在于是否用正确的方法做事，經常用正确的方法做事人，眼裡是沒有難事的。

　　雖然說調研工作品質和調研個人能力是直接相關的，有豐富經驗的人在很短時間内就可以完成高品質的調研，取得被調研使用者的認可，沒經驗的人花費大量時間在現場了解情況可能還是給使用者一個不懂行的印象。

　　但最有經驗的人也不可能了解所有的行業，他們對于一些陌生的行業一樣可以将調研工作完成得很好，我發現有經驗的調研人員和沒有經驗調研人員最大的差別是他們是否按照正确的過程組織調研工作，按照正确的方式做事自然會更容易取得成功，有無其它行業經驗隻是成功調研的一個積極因素而已。

　　在一個有調研經驗的業務人員眼裡，調研決不是現場調研這麼簡單，無論是售前還是售後調研工作本身都可以分為三個階段。

　　第一個階段叫調研準備階段，這個階段要完成調研計劃的确認，調研背景資料的準備兩方面的工作。這個階段工作品質将對能否順利開展調研工作起到關鍵保障作用。

　　第二個階段就是現場調研階段，根據調研計劃完成各項調研工作，并取得使用者認同。

　　第三個階段就是調研後續工作落實階段，調研結束後往往要準備産品示範，技術交流，解決方案等工作，是以調研結束後一定要趁熱打鐵，把後續工作落實到一定程度才能再做其它工作，此時調研工作才能算結束。

　　這是很多人忽視的一點，以為調研成功事情就結束了，其實調研工作和後續工作往往不是同一個人準備，高品質調研資訊如果不能及時有效完整傳遞到後續工作者頭腦中，調研工作實際上是更大的機會成本喪失。

　　從商務的角度來講，售前調研還存在一個時機問題，調研本身應該是商務策劃中的一個環節。

　　很多商務人員和使用者接觸以後，技術講不清楚，業務談不清楚，隻好給一個模闆化的方案給使用者，結果這種方案又沒有說服力，大家的方案高度雷同，使用者無法鑒别，往往提出一個請求：是否請安排貴公司業務人員做一個調研，然後再提供一個針對性方案？

　　有經驗的銷售人員還應該明白，調研是一個适當實際要去做的工作，不應該被使用者牽着走，應該是整個商務策劃中的一部分，不過這不是本文闡述重點，本文将重點介紹業務調研需要的技能。

2.2 調研準備階段容易犯哪些錯誤？

一般接到一個調研工作任務後，大家都會去編制一個調研工作現場工作計劃，同時進行一些調研準備工作。

　　根據我的觀察，在調研準備階段大家常常存在這麼幾個錯誤。

　　2.2.1 第一個容易犯的錯誤：不清楚調研的的目的

　　很多人編制計劃，寫本次現場工作目的時往往是這樣寫的：“完成項目現場調研工作”。

　　其實完成現場調研工作不是計劃本次活動的目的，而恰恰是完成本次調研目的的有效手段。

　　那麼調研的目的到底是什麼呢？

　　真正的調研目的有三條：

　　對使用者：讓使用者認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

　　對競争對手：如果是售前調研，還要随時制造給競争對手的門檻，了解競争對手給我們設計的門檻。

　　對公司：調研獲得資訊足夠讓後續者進入下一階段工作。

　　我們很多人認為調研時一定要搞清楚企業業務，可是一定要切記，能夠評價你是否了解企業業務的人不是你公司的成員，而是使用者。

　　如果使用者都認為調研者非常或者有能力了解他們的業務，他們自然也比較相信這個調研者的後續的解決方案或産品示範。

　　如果使用者都認為調研者非常或者有能力了解他們的業務，調研者說服或者高品質幫助公司的同僚進行後續工作自然不在話下。

　　明白這個目的的人，在調研階段就會設計大量的機會不斷強化使用者對調研者的認同感。如果最終使用者認同了調研者，或者大量的使用者認同了調研者，無論是對售前打單還是售後實施就開始取得了最廣泛的支援，項目成功的機會就在不斷的增加。

　　有的企業業務非常複雜，企業使用者自己都可能搞不太清楚，不太可能在短期内了解全部業務細節，特别是售前調研階段，使用者不太可能有積極性花費大量時間配合進行調研工作，這個時候調研工作目的就是要能讓使用者充分信服調研者所在公司或團隊是有能力了解企業業務。有了這個信任基礎，後面很多工作也容易推進。

　　有的項目使用者同時安排幾家供應商在同一時間段，或者在很緊湊的一個時間段安排幾家供應商都用兩三天的時間做一個調研，此時所有供應商恐怕都很難立即對項目情況有一個完備的了解，這個時候與其說調研目的是搞完全清楚企業業務流程，不如說是讓使用者認為我們在這個領域最有經驗，最有可能搞清楚企業業務流程，進而給競争對手制造進入門檻。

　　是以在調研工作中要通過規範的業務程式讓使用者感覺到我們作為一家大公司的風範，通過業務交流讓使用者認可我們在這個領域的專業知識和技能，通過業務需求确認突出我們強項，給競争對手制造壓力，同時了解競争對手給我們制造了哪些門檻，靈活化解，或者為後續技術交流工作提供可利用的資訊。

　　我們調研工作品質越高，認同程度越高，對手壓力就越大。一般對手在壓力下出錯的機會就越多，我們了解充分準備也容易充分，這樣我們項目成功的機率就越大。

　　調研一旦結束，調研者還要清楚一個環節，調研後要做什麼？是做解決方案還是做技術交流，還是做産品示範，還是做實施方案？

　　不管進行什麼工作，特别是在後續工作是公司其它同僚配合完成的情況下，調研者有責任有義務确認自己調研工作資訊明确被需要獲知這些資訊的同僚收到并了解，并能很好開展後續工作。

　　做到這一點，調研工作才能算結束，否則調研者個人認為其調研工作品質很高，後續者如果對調研情況不認同或者對調研業務報告不了解，後續工作品質還是沒有保障，這個時候調研工作并沒有發揮作用，是以調研者就是從尊重自己工作的角度而言，也要安排時間讓後續人員認同和了解自己的業務調研内容。

　　實際上有效的團隊在調研過程中會随時收集團隊成員對調研記錄的意見，不斷動态調整調研過程，而不是在最後調研結束時一骨腦讓團隊成員吸收大量資訊。同樣有經驗的人員在規劃一個項目時也一定會考慮調研工作和後續工作的協同，提前要求各個階段人員及時溝通和配合。

　　2.2.2 第二個容易犯的錯誤：計劃不夠細緻

　　很多人調研計劃落實具體活動的時候，往往隻有這麼簡要的幾句，某年某月某日，在某地某部門進行業務調研。

　　這樣寫計劃要麼是不清楚調研從哪裡下手，隻好先這樣寫着，到現場再走一步看一步，要麼就是自以為有一些調研經驗，知道如何處理，是以在寫計劃時為了糊弄内部分管上司，好歹也寫了，品質上偷工減料。

　　實際上我們寫一個計劃寫給誰看？計劃是我們給使用者分管上司确認的，使用者上司對你的工作内容了解越清楚，他幫助你安排工作就越友善。

　　使用者上司或者有時候是使用者協調人也一定希望我們在現場的工作緊湊合理，不浪費彼此的時間。但使用者并不清楚如何做這種調研，他們能做的就是按照我們意見盡量安排合适人員配合。

　　如果你的調研是某幾天要來你們這裡調研的話語，實際上使用者上司可能會回答，拿你們先來，來了再說。結果現場大部分時間都在協調調研資源和等待上，大量時間都無價值的浪費掉。

　　是以一份好的計劃應該是可操作，可執行的，也可以讓使用者看明白的。

　　我個人建議計劃不妨細化到每天的上午下午分别調研哪個部門，需要怎樣資曆人員配合，需要配合多長時間，将了解哪些方面的業務問題，需要準備哪些相關資料。這樣也便于使用者上司配合安排。

　　而且一份詳細的計劃做為開始，正是恰到好處的展現了我們的專業背景和職業素養。還有什麼比這更劃算的呢？我們隻需要做一份合理的模闆，每次多寫幾個字，就可以換來一個好的印象。

　　還有一點必須要明确的是，寫一份詳細的計劃并非一定要讓計劃時間變得很長。任何調研工作都不可能把所有情況搞清楚，調研并不是一次就可以結束的事情。

　　實際上在一個項目中要随時有調研的意識，一旦發現新的事實和曆史調研不符合，我們馬上可以重新完善我們的調研結論，進行相關調整。

　　是以知道這一點我們每次調研都有一個成本的概念，調研的目的對内隻是獲得可以進入下一階段工作的足夠品質資訊即可。

　　有時候一兩天的調研也可以達到這個目的，調研同樣可以結束。

　　即使是一天的調研計劃同樣可以認真細緻地準備。

2.3 調研準備階段容易犯哪些錯誤？

2.3.1 第三個容易犯的錯誤：計劃沒有在内部溝通

　　很多人接到調研任務，将計劃寫好，立即就開始和使用者溝通，工作精神很好，是不折不扣的行動派。

　　但是前面已經強調過，調研工作不是一個單獨的業務行為，調研是承上啟下的一個工作。是以我們的調研計劃一定要征求客戶經理，參與過調研其它人員意見，一些重點項目甚至是公司高管的意見，看看是否還值得推敲。

　　最關鍵的是，内部溝通計劃的過程是和其它部門約定後續工作配合的過程，通過内部溝通在完善調研合理性基礎上實際上确定如果調研工作結束，如何将我的工作移交給其它人，便于其安排後續工作。

　　調研者不要匆匆忙忙搞完一個調研，送出一份文檔，就投入另外一個項目。然後客戶經理過了一段時間又要求示範，然後示範準備者看着業務調研報告雲裡霧裡的時候，又無法和調研者當面深入溝通一下業務，無法高品質開展工作。

　　是以做内部溝通的時候實際上也是調研者的一個自我保護，和别人約定階段工作的輸入輸出文檔和品質要求，那麼做完這份工作，後續同僚也就能夠獨立開展工作，而是是糾纏不清。

　　例如有的項目在調研階段就要同步準備示範方案，那麼調研者最好在調研階段就清楚誰負責這個示範配置，并在調研期間約定和其有效溝通方式，便于在調研進行時可以考慮如何準備。

　　如果很明确要進行這類工作，但又沒有安排示範準備人員。調研者作為一個職業人員，我們至少要盡到提醒客戶經理去申請資源提前準備的責任。

　　幫助自己團隊成員少犯低級錯誤也是一個成熟職業經理人的心态，不管你的工作崗位有多麼重要或者不重要。

　　此外在内部溝通時，如果是售前項目，要考慮和客戶經理溝通一個很重要的問題：調研的切入時機。

　　一般情況下不要輕易的做第一個調研者，做第一個調研者一定要安排能力強的人，在使用者關系不錯的情況下，經過調研做好工作，給後續對手制造壓力。

　　因為使用者如果發現後續者能力不強或者不夠職業會加強對第一個調研者的認同感。

　　但是如果你派的人能力不足，那就給對手超越的機會此時再次安排調研，已經很難挽回第一印象分。

　　不做第一個調研者除了規避這方面的風險之外，還有一個比較大的好處：不做栽樹人，要做栽果子的人。

　　很多使用者往往并不清楚他們要購買的軟體到底是什麼東西，是以第一批調研者很多精力要花費在灌輸概念的工作上，如果基本概念不清楚，使用者往往不能提出有價值的需求，調研時往往沒有邊際。

　　第二個調研者再進行調研時使用者就會清楚很多事情，回答問題品質就比較高，同時我們也可以有機會了解對手的牌，進行針對性準備，後發制人。

　　當然何時切入調研應該更多程度上是客戶經理考慮的工作，我們調研者至少要知道客戶經理對這個問題是如何考慮的。此外調研一般要客戶經理到現場配合，是以調研計劃行程安排也一定要得到客戶經理确認，防止出現意外變化。

　　不過說實話在這個行業内，基本上客戶經理是很幼稚的，調研工作往往是盲目啟動，草草收尾。

　　2.3.2 第四個容易犯的錯誤：計劃沒有得到使用者确認

　　我們有的人把調研計劃做好，告訴使用者形成，就準備按計劃去現場了，這樣的調研者不及格。

　　有的人會提前發郵件或傳真給使用者，然後電話确認收到，然後确認時間無問題，然後再去，這樣的調研者60分。

　　有的人不但會确認計劃時間，還會認真了解計劃内容是否認同和有相關業務人員配合，得到肯定承諾後再去，這樣的人80分。

　　有的人還會準備一些前期調研文卷和資料準備清單，讓客戶經理配合落實後再去調研，這樣的人100分。

　　我們至少要做到80分！

　　計劃發給使用者後使用者一般是不會認真看和落實的，這是中國人做事的習慣，特别是一些地位不高的聯系人，可能連為這個事找上司這個協調的膽都沒有。

　　是以打電話确認的時候一定要請使用者确認是否可以按計劃進行，得到肯定答複後再出發，這樣第一計劃執行保障性會高一些，第二也給别人留下一個認真的印象。

　　這個計劃落實的工作也可以和客戶經理溝通後，請其利用其在企業的人脈落實。

　　最近我有一個同僚就犯了一個這樣的錯誤，代理在合同簽訂後非常着急催促我們去現場落實調研工作，這位同僚就立即制定計劃，并發送給代理，同時電話确認收到計劃，然後就立即按計劃動身。

　　結果到了現場，代理說使用者還沒有準備好，你怎麼就來了？我們的同僚也很郁悶，計劃上說如果有問題就打電話，沒有問題就不用打電話，既然沒有打電話反對當然是按計劃執行。結果雙方的開始很不愉快，這就是不了解中國人的辦事特點造成的，中國人是預期性的事情一定要口頭溝通确認，擔責任的事情一定要書面溝通确認。

2.4 調研準備階段容易犯哪些錯誤？

2.4.1 第五個容易犯的錯誤：沒有認真進行準備

　　調研要認真準備，但說來容易做來難，很多人調研前的準備工作其實都是很随意的。

　　沒有經過認真準備的調研，到了現場很可能對各種突發情況措手不及。

　　從應付各種使用者刁專古怪的問題的角度而言，調研準備永無止境。

　　好的調研準備工作可以包括這麼18個方面：

　　1、如果有的話，一定要認真閱讀商務合同和技術協定。

　　2、閱讀前期技術方案和各類備忘錄。

　　此點非常重要，不僅僅要閱讀，還要保證自己工作品質和規範和前期保持一緻，一個行為高度一緻性的公司是核心競争力很強的公司。

　　此處有一個很重要的工作一定要向前期參加從業人員了解是否已經收集了一些資料，并想辦法獲得，已經搜集的資料和問題盡量避免重複詢問，這對使用者會造成巨大不滿。如果萬一前期資料不能獲得，也要另外提前準備好說法避免這種情況出現。

　　3、和項目前期人員(咨詢顧問、客戶經理和平台主管)充分溝通。

　　聽取他們的建議，使自己調研更有針對性。

　　4、熟悉公司已實施的相近項目的情況。

　　他們企業業務調研報告和解決方案将對我們現在工作很有幫助，甚至在調研過程中給我們很多思路上的啟發。

　　5、熟悉相關軟體産品的功能及發展方向。

　　很多人在工作中不注意和規劃人員的溝通，其實在調研前确認自己了解産品的發展方向，現有和近期可實作的功能對調研時遇到一些很難回避的技術問題就可以做到心中有數，提前想好說法。當然最好的說法是這個功能我們已經實作了，在某某項目上也是這樣要求的。

　　6、了解企業所處行業的行業特點、競争态勢、産品研發特點。

　　這些要從公司，特别是網上查詢資料分析，建立一個基本的業務原型，這樣在調研時可以讓使用者感覺到我們還是做了很多工作，對項目很認真。

　　7、準備同使用者交流時的軟體原型或交流PPT。

　　有的時候使用者在調研過程中提出要我們做一個教育訓練和軟體示範的要求，一般情況下我們應該避免在售前調研階段做這個工作，因為這些要經過精心調研仔細準備後再進行品質更高。

　　但在售後實施調研時我們可能要先主動做這個軟體示範和理念教育訓練工作，收斂使用者的思路，引導項目邊界，是以調研者也應提前對這些方面工作做一準備。即使是售前也很難完全避免這個情況，不但要準備，而且在語氣上還要有所區分。

　　8、準備企業業務調研問卷。不一定要給使用者，但一定可以讓自己不遺漏該問的問題。

　　9、設計業務調研方案。業務調研方案可以将自己調研經驗不斷積累，形成體系化的經驗，大家現在看到的文字就是我不斷完善業務調研方案的結果。

　　10、設計業務調研計劃。計劃一定要用心，用心才能做好。

　　11、準備業務調研教育訓練材料。

　　到現場調研時需要讓使用者知道我們的調研方法和思路，使用者才好配合，也認可我們的專業化程度，這個應該結合公司流程和自己體會進行準備。

　　12、軟體安裝盤和加密狗。有備無患。

　　13、電腦筆記本。IT農民的必備勞作工具，如果沒有就用筆記本解決問題，沒有電腦前麥肯錫一直是手記錄問題，現在他們還是提倡手記錄，因為友善。

　　14、WINDOWS2000/SQL SERVER/ORACLE安裝盤等常用工具軟體安裝盤。有時候很有用。

　　15、别的項目常用樣例及标準配置，使用者很難提供明确需求的時候，讓他們看看我們在别的企業成功樣例，有助打開思路，也展現我們給使用者帶去先進管理方式和成功經驗的合作初衷。

　　16、公司各種流程管理文檔。對于一些使用者了解我們公司内部問題的時候，如果搞不清楚該什麼講的時候不要信口開河，翻翻資料再說。

　　17、可能涉及業務難點教育訓練資料和問題集。

　　使用者的問題千奇百怪，多準備一點沒錯，不斷積累這些問題就是一個個人知識完善的過程。

　　18、公司小禮品。

　　調研完成後送給調研對象一個小禮品是很容易給對方留下好印象的機會。如果有政策，一定不要浪費。

　　實際上我們每個做過調研的人扪心自問，調研準備18條我們到底做了幾條？

　　也許認真不認真就是我們一個工作到底有沒有品質的根本原因。

2.5 現場調研階段容易犯哪些錯誤？

調研計劃确認，抵達現場就需要進行調研工作。在調研工作階段我們常常容易犯以下錯誤。

　　2.5.1 常見錯誤一：立即進入調研狀态

　　很多人非常努力，一到現場，就開始按計劃進行調研工作。

　　其實調研計劃到現場第一件事情不是啟動調研，而是再次确認調研計劃。

　　這樣做的理由有三點：

　　第一雖然很多企業和你電話口頭認同了計劃，但隻有調研者到現場了才會真的重視，是以我們必須要重新确認計劃，保證我們的計劃需要的調研配合資源已經落實；

　　第二确認調研計劃往往不是和協調人确認，要主動通過這個機會見一見企業負責的高管，很多時候企業也會安排這個一次見面。和高管見面要做好三件非常重要的事情：

　　一、彙報我們的計劃，請其再次确認，并請其協調資源安排人員配合。

　　記住給上司溝通最有效方式之一就是“多請示，多彙報”。根據我個人的經驗，一般上司看過的東西不如口頭彙報的東西印象深刻，彙報也是建立上司對我們認同的手段。

　　很多時候被調研人員不願意配合我們進行調研，因為這樣可能會影響他們正常工作或者有其它顧慮，是以當調研工作是上司的工作任務安排，他們配合積極性就高了。

　　很多時候上司也不能立即協調完所有的工作，特别是這個時候可以要求上司配置一個專門的聯絡人，由他出進行聯絡工作，可能的話，也要求其全程參與調研，這樣的人會給調研帶來極大友善。

　　二、彙報我們的調研工作方法，讓高管覺得我們做事很有套路，同時請其提出意見，做相應客戶化調整。

　　在彙報計劃的同時要順便告訴高管我們調研工作方法，先做什麼，後做什麼，每天需要如何開始，要花費多少時間調研，花費多少時間在整理，是否要開一次業務分析會，需要哪些人參加。

　　上司明白你思路了，也就知道我們這些天工作量都會很飽滿，很有組織性，也就對調研工作有信心并積極支援。

　　此外上司可能提出一些要求，例如進行教育訓練或者其它要求，我們可以根據實際情況确定是否要進行或者不進行。此時就有可能需要調整計劃内容和時間。

三、借彙報機會上司了解他們上項目的初衷。

　　很多時候上司看待一個項目角度和高度和我們進行下層調研人員了解是不同的，這個時候和上司交流其對項目的想法，是有助于我們在調研工作進行時判斷一些業務需求是否真的符合企業上司的構思，并可以尋求更好的方案。

　　從調研的角度，了解不同人員對同一個項目的需求也是調研工作的一個内容。上司層往往是管理性思維，業務層往往是技術性思維，兩種思維達成一緻才能設計一個好的方案。這些都需要通過調研獲得。

　　第三和高管見面要約定如何彙報工作的機制。

　　調研如果有一段時期，不可能天天找上司彙報，也不能不彙報，那麼這個時候就可以請示上司每幾天安排一次當面彙報還是書面彙報。

　　多和上司見面，多用肯定語氣溝通，就會讓上司不斷強化對我們積極的印象，逐漸将感情的天平傾斜到對我們有利的方面。

　　不過有一點，首次和高管彙報工作原則一定要言簡意赅，不要表現自己。

　　讓上司建立對自己個人專業認同感就可以說達到目的了，對于一個上司認為有專業技巧的人，見面的機會他是一定會繼續提供的，是以不要追求一次搞定，這都是極為有害的冒進思想。

　　低調切入，等調研過程中收集足夠事實了再根據情況确定是否逐漸擡高調門，表現自己的思路，是更穩妥和合理的政策。

　　和高管見面可能存在一個時間不确定因素。是以在調研準備階段計劃确認時盡量先保證這個時間，如果到現場時間不能保證，必須留機動調整的可能，一般情況下可以進行企業曆史，企業現狀，網絡硬體，組織機構等方面的業務調研，也可以為上司見面提供溝通的素材。

　　此外高管并非一定是企業的最高上司，高管是依據企業規模和項目規模動态确定的，一般選擇彙報高管對象的原則是對項目直接負責的人上級或以上級别的人。

　　企業大了，高管并非隻有一位，有的彙報必要時該重複就重複，不要給别人不尊重的感覺。

　　2.5.2 常見錯誤二：匆忙地進入調研狀态

　　計劃一旦得到上司确認很多人就立即着手調研，這個時候容易犯的錯誤就是匆忙地進入調研狀态。

　　進行具體調研業務前首先是和企業調研協調人确定今天一天的調研計劃和資源可以到位，如果萬一今天計劃所在配合資源不在，給企業調研協調人幾個替代性調整方案，其負責落實到位後才能放心的開展調研。這就避免出現上午調研完了發現下午沒有人配合了的情況。

　　這個提前預約時間，即尊重被調研使用者又讓被調研使用者有所準備，保證品質。

　　那麼安排使用者配合調研工作在可能情況下一定還要得到其直接主管上司的确認，讓訪談者上司出面安排會面會保證調研者的積極性，他就不必擔心調研影響正常工作而導緻直接上司不滿。

　　這些工作完成後還不以開始調研，而是針對所訪談的對象，再一次回顧自己要問的問題，理清發問的思路，不要想到什麼說問什麼。

　　想清楚後就可以開始調研了，但和被調研對象見面不要三句話不到就立即進入主題，必須有一點點鋪陳才能展開調研。

　　這個鋪陳包括三個方面，第一是自我介紹，有時候還包括公司介紹，調研者也是公司的活名片，第二是了解被調研者的背景，對其配合調研表示感謝，順便奉承一下，例如說能得到您這樣有經驗人員配合是我們非常高興的事情，讓其有一個好心情開始配合調研工作，第三是對調研總體内容和時間有一個說明，說明我們想通過調研能為其業務設計好的資訊化支援手段，讓其配合時做到心中有數，樂于協助。

　　做完這些工作才不是匆忙展開調研工作。

2.6 現場調研階段容易犯哪些錯誤？(二)

2.6.1 常見錯誤三：不斷地問問題，唱獨角戲

　　很多人在開始進行調研的時候準備了一份業務調研問卷，是以在調研的時候就按照調研問卷開始提問，這個方法對剛開始做調研的人是很有用的，可以幫助他在對業務不熟悉的時候不至于無話可問。

　　但這樣調研的後果就是調研者在唱獨角戲。調研者不停的提出問題，被調研者不斷的再回答，好象成了一種審問和被審問的關系，這樣的調研狀态雖然可以收集大量資訊，但從調研角度而言，不是最佳的選擇。

　　真正有經驗的調研者首先是先向使用者了解整個業務過程，在具體業務過程中順便了解我們想重點關心的問題。

　　被調研的使用者如果沒有經過精心準備是無法回答很多具體的問題的，他也不知道你為什麼要問這些問題，這樣的問題問多了，使用者一定很厭煩，也會産生一些戒備心理。

　　但是所有使用者一定很熟悉自己每天進行的業務，并知道業務中他感覺比較痛苦的一些問題。是以調研的方式應該是站在使用者的角度了解業務，有了一個對業務的總體認識，再了解細節也就更深入和細緻。

　　是以好的調研者要充分的讓使用者講話，自己隻是在提話題，讓使用者有興趣有心情把自己知道的事情完整有序地講明白。

　　舉一個例子，我們做PDM調研的很多關心你用什麼設計軟體，産生哪些格式，每月設計幾個項目，産生多少圖紙，但如果是一個個問題這樣問下去，對使用者而言的确是一種折磨。還不如問他你每天設計任務是如何獲得的，如何開始，需要哪些資料參考，做完了以後形成什麼文檔，交給誰？在這個過程中您覺得什麼地方不太友善？在整個業務調研過程不斷順便問一句，這樣的任務你每個月大概接多少，多的時候多少，少的時候多少，每次出圖量多少，用什麼軟體設計為主之類的問題。

　　這樣交流的好處是使用者對熟悉的業務可以很自如的進行表達和溝通，而不至于讓整個交流變成一個單向的資訊收集，交流的氣氛會越來越好，問題也會越談越深入，而不僅僅停留在一些準備的表面問題上。

　　而且很多問題在一次業務溝通中就交流完成了，不需要反複去問，增加被調研者的工作強度，也節約了調研者的時間。

　　一個小塊業務問題問完後立即要做的一個工作，也是很重要的工作：立即主動複述使用者所講的業務和過程，讓使用者确認你明白他所說的内容。

　　當使用者發現他說講的内容你可以了解并接受的時候，是很高興的，第一覺得自己沒有白講，第二他就開始認為你也是比較熟悉業務或者有能力熟悉業務的人員了，第三如果發現複述有什麼不對，可以立即糾正。

是以調研不是調研人員的獨角戲，而是使用者為主介紹，我們隻要起到引出話題，複述内容的作用即可。一個滔滔不絕的使用者應該是一個成功調研的特征。

　　調研結束後一定不要忘記的一句話就是感謝！

　　感謝之餘還要請使用者有時間稽核我們的調研記錄。

　　根據麥肯錫的建議，有些人在快結束會談時可以再提出一個相對敏感的問題，這個時候問題人容易放松，會有心情回答一些一開始不願意回答的問題，這個辦法有時候可以試一試。

　　2.6.2 常見錯誤四：不注意收集異常的事實，挖掘背後的需求

　　很多人做調研，問問題很積極，溝通也很有技巧，但是就是缺少一些職業敏感，很多很有價值的資訊使用者已經說出來了，就是不注意。

　　一般多次調研的人很容易發現很多業務在不同的企業都是一樣的，漸漸在調研中失去新鮮感，其實調研不是簡單了解企業業務流程，而是要找到業務流程中問題。使用者請我們來就是準确發現問題，然後再提供解決方案的。

　　可以如何發現問題呢？

　　問題往往是隐藏在意外事故之中的，如果聽到一件和流程不符合的事情，或者和管理預期不符合的事情，這些事實就是異常的事實，值得我們高度重視，深挖窮究。

　　為什麼會産生這個事實？原因是什麼？這個原因到底是什麼産生的？一層一層了解下去，就象撥筍一樣，最後把事情分析得很透徹和明白了，問題的解決思路也就出來了。

　　比如有的企業更改非常多，很多調研人員就寫上一句，更改管理業務很重要。或者更改管理是要重點解決的問題，可以為什麼企業有這麼多更改呢？這樣一查下去，就會發現不同企業造成更改的原因是不同的，不同的原因自然要用不同的藥去診療，才能收效。

　　如果我們不關注細節，不收集大量支援我們的事實，等我們真有機會見高管的時候，我們又怎麼讓企業上司相信我們這些相對年輕的人可以找到企業的病根，并有好的解決思路呢？

　　唯有事實，大量的事實會幫助我們說服企業的上司支援我們。

　　是以在調研過程中要随時分析現有流程存在的問題，而且一定要找到事例證明問題存在，并事後分析可能存在的改進點。

　　打動使用者的力量就在在于你對其業務了解的程度！

2.7 現場調研階段容易犯哪些錯誤？(三)

2.7.1 常見錯誤五：每天調研工作時間太長

　　有的人有一個習慣，喜歡把調研工作都完成後才開始寫調研報告，認為這樣有整體感。有的人每天從早調研到晚，用個把小時整理下調研記錄。這些都是不好的調研習慣。

　　其實每天調研的時間一般不要超過四個小時！

　　對每個個體一次通路的時間也不要超過兩個小時！

　　四個小時的調研内容是需要用同等長度甚至更長時間整理才能成型成體系的，是以在每天的調研計劃中，必須要和企業溝通好我們自己的工作方法，保障我們整理調研内容的時間。不要讓使用者以為我們每天沒有調研的時間沒有在工作，實際上為了整理四個小時的調研内容往往要用掉八個小時。

　　如果要想控制每次調研時間又不至于遺漏關鍵資訊，比較好的方法有兩個。

　　第一是将要調研的問題結構化，建立結構化的問題可以友善自己快速把調研資訊轉換成調研記錄，也容易防止遺漏問題。

　　問題結構化就是針對一類業務将一組相關問題形成一個開放性和封閉性的問題引導區，這樣在短時間内可以把一個業務快速搞清楚，被調研者也容易順着業務思路解釋。

　　第二就是盡量不要一個人調研，應該兩個人調研，如果兩個調研者中有一個是企業項目組成員就更好，因為大家可以一起在調研中互相補充可能會遺漏的問題。而且可以一個主問，一個主記，合理分工，提高機關時間内的調研生産率。

　　調研完成後要及時迅速把調研内容轉化成文字，而且要轉化為結構化文字，不是使用者說什麼我們寫什麼。這樣做有很多好處：

　　第一避免遺忘，好記性不如爛筆頭，調研過程中不停把資訊記錄在本子上，但可能還是有一些遺漏，必須用一些時間趁着大腦有印象，趕緊補記下來。

　　第二寫記錄的過程就很容易發現一些自己感覺清楚但實際上并不清楚的内容，這些内容馬上可以形成第二天的問題進一步确認，把調研逐漸推向深入。

　　第三每天寫清晰完整的調研記錄，可以立即回報給使用者确認修改，使用者也會認可我們的職業精神和專業水準，而且每天都看到具體的工作内容記錄，工作成果也容易得到确認。

　　第四可以回報給公司相關同僚，讓他們立即提供回報意見調整調研程序。

　　第五整理的過程就是對企業問題深入思考的過程，這是一個很有趣的腦力勞動。

　　有的人想在這些方面偷懶，不随時注意整理調研資訊，最終調研報告品質就不會太高，缺少深入的分析，也就不能為後續工作提供有價值的資訊。

　　2.7.2 常見錯誤六：聆聽，而不是提供解決方案

　　有的人在使用者提出一個疑難點的時候，很希望把自己的産品特色展示出來，花了大量時間講自己的賣點和特色，給使用者做了大量啟蒙工作。

　　當然有些使用者還會對一些特色功能念念不忘，并拿來要求其它供應商提供。

　　其實在調研過程不是做解決方案的過程，調研就是為解決方案奠定基礎的，過早在調研過程中提供問題的答案有如下壞處。

　　沒有經過精心準備的示範可以有幾個亮點，但很難形成整體打動别人決定性力量，反而浪費了調研的時間，影響了為有價值解決方案制作的調研時間。

　　提供解決方案往往是臨時思考沒有經過全面分析，難免偏頗，為了表現能力而承諾一定可行的内容發現實際上并不是那麼容易，導緻後期實施騎虎難下。

　　做項目不是一個人在做，而是一個團隊在做，如果沒有溝通就向使用者提供了自己的思路，可能會給整個團隊的思路帶來幹擾，解決方案一定要在内部達成一緻才能提供給使用者。

　　一些的确非常成熟有特色的業務解決方案可能會提前洩露給競争對手，對手可以針對性進行準備，導緻殺手锏失靈。

　　是以調研過程中不要過多花費精力介紹我們的産品，而是做一個好的發問者和聆聽者，用耳朵去聽，用心去想，用大腦去分析使用者的資訊，去發現有價值的内容。

2.8 現場調研階段容易犯哪些錯誤？(四)

2.8.1 常見錯誤七：沒有開業務分析會

　　很多人做完調研，就按計劃打道回府，準備後續工作，其實有經驗的調研人員還會多做一個工作，就是開一個針對企業上司、項目負責人和主要業務層面的調研工作彙報會。

　　我們說調研目的是讓使用者讓使用者認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

　　單個使用者是否建立這種認識我們是通過複述技巧實作的。但對于企業上司又如何知道我們了解企業業務呢？

　　有人說這些将在解決方案中完整展現，不過說實話，有幾個人相信我們這些管理供應商寫的多達百頁的文檔企業裡會有三個以上的人看一遍？

　　都是在浪費紙張而已！

　　是以在調研完成之前，在調研計劃中調研者應主動安排或者創造這麼一次彙報的機會，專門陳述我們對企業業務和要解決關鍵問題的認識，這個認識陳述好了，企業自然對供應商刮目相看，就算有一些偏差，也可以立即得到糾偏的機會。

　　這個彙報會時間不一定要很長，但可以讓企業上司真切感到我們調研工作的成效，我們對事實把握可靠程度，我們對企業業務了解深入程度，我們對問題分析細緻程度，我們在該領域的專業程度即可。

　　有了這個階段性總結，調研工作就可以說順利完成了，可以進入下一階段準備工作了。

　　不過在業務分析會上一定要注意一點，不能用過高的姿态切入。

　　有的人經過調研确實發現了企業一些問題，也想到一些很好的解決思路。于是其在業務分析會上企圖指點天下，痛陳不足，确有嚴加改進必要的時候，就有可能犯一個大錯誤的時候。

　　有了表現欲，就容易昏頭。

　　業務分析會一個鐵的原則就是不要輕易說自己使用者的不足，即使要說，也應用一種委婉的方式表達；指出可進步的地方，而不是指出落後的地方。指出不受控的地方，而不是失控的地方，指出實作不友善的地方，而不是指出無業務管理覆寫的地方。

　　這些都是做業務分析會要替自己客戶考慮到地方，不要随意批評别人不足，也不要以為企業沒有人知道這些毛病，更不要以為他們不知道這些毛病該如何解決，有時候無非是外來的和尚無牽挂，好念經而已。

2.9 現場調研階段容易犯哪些錯誤？(五)

2.9.1 常見錯誤八：隻重視正式溝通，不重視非正式溝通

　　調研工作特别是在正式調研活動中有些問題并不友善了解，是以調研工作還包括一些非正式場合，這些場合适合調研者問一些相對敏感或者自己有看法但沒有把握的問題。

　　是以調研不僅僅在工作計劃中所列走訪，座談，會議等形式中，也在和使用者一起聚餐等非正式溝通活動中。

　　隻要調研計劃沒有結束，所有的時間都是為調研而準備的，走路，閑談，吃飯都是可以進行調研的機會，不一定要正式場合才能開始調研。

　　這種非正式溝通資訊一樣很重要，而且往往是真實運作企業的資訊，和正式調研得到的資訊正好可以互相印證。

　　在非正式溝通中調研者還可以和企業一些人建立友好的關系，為今後工作也奠定了良好的基礎。

　　是以好的調研者不僅僅是一個專業人員，在非正式場合也是一個可以讓别人說話的人，這樣的調研行為才是完整的。

　　2.9.2 常見錯誤九：關鍵業務隻詢問了個别人意見

　　一些業務在整個調研工作中是占據很重要分量，而且涉及多個業務部門，這個時候調研就要記住“兼聽則明，偏聽則暗”，一定要把業務涉及不同部門意見都聽到，也要把不同人對同一業務描述進行對比調研，從中能發現很多錯誤。

　　此時不可因為覺得調研内容很飽滿或者時間緊張而隻做單點調研，關鍵業務一定要從其它人那裡不斷得到印證。

　　不過再問第二個人的時候，就可以用主動複述業務的方式，請其重點指出不對的地方，加快調研進度。

　　2.9.3 常見錯誤十：調研時有選擇問問題

　　有的調研者在調研階段就非常小心，特别是在其對自己軟體不足的地方有足夠了解的時候，總想在調研階段引導使用者，接受自己的系統，繞過這些自己産品不足的地方，這也是一種錯誤的做法。

　　首先如果調研發現使用者迫切需要很有價值的問題是公司目前不能解決的問題，并不等于不調研就可以回避，無論将來在技術答辯還是售後實施，這個問題總是要冒出來，與其回避，不如主動搞清楚，彙報給公司，看看到底有什麼辦法可以解決。

　　真正的問題都是回避不了，繞不過去的。

　　我個人意見，越是有公司明顯不能解決的問題，越要調研清楚，搞清楚來龍去脈，為公司今後産品發展提供完整的需求建議，作為一家負責任的軟體公司，首先要承認自己的軟體不可能解決所有的問題，但一定要在發展過程中逐漸解決更多的問題，調研時都回避了，不就失去了公司産品發展的機會了嗎？

　　其次如果有選擇性問問題，就會遺漏一些關鍵性業務，這樣對調研整體品質有影響，在後續工作中容易被動。

　　至于不想将使用者一些天馬行空問題，或者的确不想引發他們高度興趣的問題回避的方法，不是不通過調研，而是認真記錄，但不提供在正式文檔的方式規避。

　　很多人很多需求都是一時靈感，沒有經過認真思考，是以口舌之快，過了也就過了，不形成文字記錄，他自己也不記得自己說過什麼了。如果是真的關鍵問題，在後續複述，确認調研記錄還有業務分析會上還會提出來的，這個時候再确定寫入正式檔案也不遲。

　　對于這些暫時不能滿足的需求和超出範圍的需求，可以另外整理一份内部文檔給公司分析。

2.10 現場調研階段容易犯哪些錯誤？(六)

2.10.1 常見錯誤十一：一次調研就企圖鎖定需求

　　很多項目啟動後轟轟烈烈進行了一次深入調研，然後開始配置開發實施，忙得不亦樂乎。好象把企業問題搞清楚了，就應該是實作和解決的階段。

　　實際上很少有人能夠在短短幾天内把企業的問題搞清楚，即使你努力進行了半個月甚至一個月的調研，在實施過程中你還是會發現對很多問題認識我們依然不夠深入，不夠完整。

　　這個時候我們應該意識到，我們依然還需要進行調研，切不可因為是大規模調研完成了，對此時的調研就随意了，不留記錄，不進行确認了。

　　事實上這些調研資訊要随時記錄确認并最終完善到項目解決方案中，可以這樣說，資訊化項目中始終要有随時開始調研的意識，如果我們承認資訊化需求是無止境的話，那麼調研也是無止境的。

　　為什麼不能通過一次調研鎖定需求呢？

　　正确的需求是系統成功的關鍵。預先鎖定需求的假設前提是使用者不經過系統上實踐的過程，使用者就能預先精确的提出所有的系統需求。

　　某些簡單軟體或者具有極高技術水準的使用者可能可以，但是一般情況是使用者隻對其目标和需求最初隻有模糊籠統的認識，許多細節都不清楚。要求一個隻有初步設想的使用者或個别使用者負責人準确無誤地說出全部需求，顯然是不切實際的。

　　使用者為了證明和細化他們的設想，往往需要在某個系統上持續不斷學習和實踐的過程。特别是在大型管理系統軟體上。

　　即使經過深入細緻的預先鎖定需求的工作，當人們實地觀察和使用了目标系統以後，也常常會改變原來的某些想法，對系統提出一些新的要求，以使系統更加符合他們要求，事先鎖定需求的方式其實也會經過多次反複，甚至完全失敗。

　　大型軟體的開發需要系統分析員、軟體工程師、程式員、實施經理、使用者上司、使用者負責人、具體使用者等衆多各類不同層次不同技術水準人員的一緻協調努力，是以良好的通信和互相了解對于保證工程成功至關重要，傳統的需求鎖定方法假設使用适當的文檔可以做到項目參加者之間清晰、準确、有效的溝通。但是各種文檔本質上是被動、靜止的通信工具，通過它們來了解一個動态系統是困難的。

　　使用者變更需求是正常的，使用者沒有實際操作過軟體之前無論你怎樣描述都會有對軟體功能了解不一緻的地方，可能是技術協定上書面文字表達一緻但對實際軟體操作了解不一緻，可能根本就是不用不知道哪裡不适合自己的需求。

　　打個比方，就象買衣服，無論别人怎樣推銷，客人一般都會試一試覺得合身再買，我們一般比較大的項目都沒有讓使用者體驗過而且在推銷時說了很多動聽的話，自然期待高，失望也高，而且使用者為适應ISO認證或PDM/ERP系統必然伴随組織機構和業務流程重組，這裡面有很多反複的過程，對應的文檔，設計流程，對軟體操作提出變更是正常的。

　　我們的問題不再于要使用者不變更需求，而在于找到一種方法讓使用者認識到我們的軟體能發揮作用，當有新的需求時通過使用我們軟體建立的信任關系重新形成新的業務，這也是調研時要保持一種理念。

　　2.10.2 常見錯誤十二：調研工作表現不職業

　　有的調研人員工作很努力，但在現場很難得到使用者的認可，就是因為經常表現出一些職業不成熟的緣故，甚至有的表現是不道德的。

　　常見不成熟職業表現有：

　　1、 不征求使用者同意就翻看其資料(如果有的競争對手敏感資料想獲得，也一定不要給别人看到)；

　　2、 調研過程中電話短消息不斷；

　　3、 在使用者現場上網工作時順便聊天看和工作無關的内容；

　　4、 沒有征求使用者同意使用使用者電話；

　　5、 使用者同意使用電話講起來沒完沒了；

　　6、 對使用者現有各方面狀态流露輕視的态度，例如認為使用者條件不成熟，管理不到位，表現出眼界高人一等的想法。

2.11 調研工作方法推薦

2.11.1 每日調研流程

　　1、提出調研内容，請企業項目組成員配合預約人員時間安排訪談；

　　2、訪談

　　3、當場複述内容，确認了解對方表達的問題

　　4、立即将整理訪談結果形成文檔記錄，确認需要繼續了解的内容和未清楚的内容

　　5、如果需要，安排時間請被訪談對象确認訪談文檔記錄，特别是一些關鍵名詞定義部分

　　6、和企業項目組成員配合約定下一時間段訪談安排。

　　2.11.2 訪談成功的九個要點

　　讓訪談者上司安排會面

　　調研前應向調研者介紹調研内容和時間大概安排，讓其心中有數

　　聆聽，不要發表指導意見，要靠和使用者交流發現問題核心所在

　　随時收集和記錄事實，尋找異常現象，發掘管理改進需求，認真記錄并探讨原因

　　盡量兩個人一起采訪，最好一個是企業項目組的成員

　　複述、複述再複述

　　一次不要問得太多

　　在結束會談後又提出一個問題

　　訪談結束後一定要表示感謝

　　2.11.3 良好的結構化調研順序

　　先了解企業基本情況和項目組成員情況，由此建立對企業初步認識，對項目有個初步判斷；

　　再了解企業組織結構和崗位設計，由此确定訪談對象；

　　再逐個按照業務口了解業務流，業務流要關心業務可以劃分為哪些階段，每個階段應該是互相獨立，彼此窮盡的。

　　每個業務階段要問清楚業務目的，輸入資料和輸出資料，過程步驟，每個步驟的負責人，什麼時候開始，什麼時候結束。

　　輸入資料其什麼作用，有哪些資訊傳遞到輸出資料中。輸出資料又起什麼作用，是指導下遊還是回報上遊。

　　業務流程調研品質評判标準就是能否清晰簡明畫出企業業務流程圖和資料流程圖。

　　2.11.4 售前和售後調研的不同

　　售前調研一般是為産品示範，技術交流做準備，同時調研過程要注意突出自己強項，給競争對手制造門檻。

　　售後調研一般是為解決方案，項目實施做準備，同時調研過程中要注意尋求項目價值點，利用價值點置換項目邊界，盡量把項目邊界最小化，項目才容易成功和受控。

　　售前調研一般由商務主動和使用者協商時機，根據實際情況确定先調研還是後調研。售後調研必須盡快啟動，而且應該在項目啟動大會後展開調研。

　　售後調研前一般要和企業高管親密接觸，取得支援。在啟動大會上對調研方法和需要取得支援告訴企業配合人員後進行。

　　售前調研一般要協助拿項目，是以不要輕易發表對問題傾向性看法，要了解事實，用比較文飾的語言表達對問題的認識，通過對事物認識深度擷取支援。售後調研可以相對直接提出問題，擺事實，陳厲害，争取最大範圍重視，進而獲得支援。

　　2.11.5 如何寫調研日志

　　調研日志有三個要求：工作過程清晰化，調研内容結構化，不明内容有後續計劃。

　　首先調研日志上要看出本日你調研了哪些部門，走訪了哪些人，用了多少時間，擷取了哪些業務的資訊，這就叫工作過程清晰化。

　　然後調研内容不能是流水帳記錄，必須将被調研者的話組織成一個個合理的單元，這些單元獨立可以反映某個業務層面的情況，然後整體上構成一個業務調研報告的部分。

　　不同的資訊結構化方法可能不太一樣，有的适合用表格，有的适合用文字段落，有的适合繪制圖形(例如框圖，魚骨圖等等)。

　　調研日志最後要說明今天調研中還有哪些問題，需要進一步明确，并有認真記錄。

　　2.11.6 如何寫調研備忘錄

　　調研備忘錄一般情況下并不是把自己調研日志的内容彙總重新羅列，因為調研日志和業務調研報告就是做這個工作的。

　　調研備忘錄和一般的備忘錄一樣，主要是說明本次現場工作進行了哪些工作内容，達到了怎樣的目的，和企業約定的下一步工作安排是什麼，并得到企業負責人簽字認可。

　　備忘錄主要讓使用者看到我們做事的規範性，而且在今後合作中将不斷用同一格式備忘錄強化我們在規範上的一緻性，同時備忘錄要讓使用者感覺到我們本次現場調研工作時間緊湊，内容豐富，層次清晰，讓使用者對我們形成良好的印象。

2.12 接口調研背景知識(上)

現在管理軟體項目中接口需求很多，很多項目接口實作得并不理想，原因就在于接口協定品質不高，而接口協定是和接口調研緊密相關的。一般接口調研和其它調研方法是一樣的，但要做好接口調研就必須具備一定的專業知識，這可能是能否做好接口調研的關鍵。

　　接口協定除一般性協定要素外，應該包括如下内容：

　　2.12.1 接口技術實作方式

　　接口方式最進階一種是主動式。

　　即通過直接對其它軟體的資料庫進行操作。這種方式因為涉及到對使用者資料讀寫操作，對于對方軟體而言，安全性是最大的問題，驗證的複雜程度也最高。主動式基本有兩種方式：

　　1)DATA方式，通過資料庫語言對資料庫進行直接讀寫。這種情況要求對對方資料有詳細認識。需要對方的人員可以提供資料庫的詳細資料。為了保障資料的安全，要界定對讀寫要求。一般和使用者自行開發的系統會比較多出現此類要求，商品化ERP很少提出這種方式。

　　2)利用其它軟體提供的工具。除了直接對資料進行讀寫外，有些軟體也提供了一些工具(可能是控件，函數，腳本等)。可以通過這些工具對資料庫進行操作。例如現在神州數位易飛ERP就全部采用控件方式接口。

　　這種情況下要提供這些工具的詳細使用說明。

　　接口方式相對主動式的就是被動式開放。

　　同主動式對應，即開放軟體商自己的資料庫或開發接口給其它供應商讀取資料。這種方式涉及到軟體商提供的資料或開發程式。對方要我們的哪些資料，将成為了解需求的重點。按提供方式的不同可以分為以下四種。

　　1)DATA方式。即開方我們的檔案或資料庫格式給對方。由對方軟體直接讀取資料。這樣的情況一般在企業有開發能力，而且隻需要資訊提取(不是寫入)時才使用。這種情況很少。

　　2)腳本方式。早期的腳本語言，多是一種專用進階程式設計語言。實作了基本的程式流程語句，簡單的資料結構，在此基礎上，提供通路軟體内部資料的語句。通過這類專用語言，使用者可以對程式進行界面配置，實作簡單的功能擴充，給使用者提供了一定的靈活性。而隻需使用者懂一點程式設計知識即可。這類語言的缺點是沒有通用性，功能有限，由于解釋執行，速度受到很大限制，并且應用軟體開發商實作專用程式設計語言及調試環境有較大難度。對于應用程式，需實作三個要求，就可擁有腳本語言程式設計接口：

　　A)應用程式的對象模型

　　B)适合應用程式對象模型的對象

　　C)腳本語言程式設計引擎

前面兩個方面，需要應用程式用元件對象模型的方式構造。采用元件方式，是軟體開發的發展方向，提供對象模型是一件很自然的事情。第三個方面，有通用腳本語言程式設計引擎供選擇，微軟的ActiveX腳本程式設計引擎可以免費使用，VBA腳本引擎需要購買。ActiveX腳本引擎實作了基本功能，沒有調試環境。VBA是一種通用程式設計語言，其核心就是應用廣泛的VB，擁有大量函數支援，視窗編輯能力，強大的調試環境。很明顯，微軟希望VBA成為應用軟體二次開發的通用語言。例如CAPP和國外PDM的接口就屬于這種開放方式。

　　3)連結庫方式。基于結構化的軟體，可以提供軟體内部使用的動态連接配接庫，供使用者使用。動态連接配接庫是速度最快的接口，應該說是一種很好的選擇，CAPP目前的二次開發接口就屬于動态連接配接庫方式。

　　但是動态連接配接庫在接口更新時會遇到麻煩，使用者程式難以和正在運作的應用程式進行資料交換。使用者也難以使自己的子產品(使用者實作的動态連接配接庫)嵌入應用程式。因為動态連接配接庫的通常首先實作的(至少要定義輸出函數接口)，而後才能使用動态庫。但應用軟體開發時，使用者實作的動态庫根本不存在，AutoCAD的ObjectARX用一種特殊的機制，才使AutoCAD可以使用使用者開發的動态庫。目前國内很多AutoCAD二次開發軟體，就是使用ObjectARX開發的，可以完全的嵌入AutoCAD。

　　4)COM元件方式。COM對象接口：基于元件對象模型的軟體，可以提供軟體的COM對象接口。元件應用程式由多個元件打包而成，元件之間的聯系是一種松散耦合，使其中某個元件的改變不影響其他元件，應用程式修改，改進變得友善。這就如同一台複雜的機械裝置的各種零部件用螺栓連接配接起來，零部件可以輕易更換。而傳統應用程式就像所有零部件都通過焊接連接配接的，如果要改進，隻能重新做一個新的。元件程式由于由許多具有位置透明性(無需知道元件的位置)的元件構成，可以很容易實作分布式應用。元件架構強調實作對象模型，開發接口是基于對象的，符合使用者的思維方式，比動态庫提供的API，更易于了解，使用。元件是完全與語言無關的,任何過程性語言夠可以用來開發元件，根據不同的需求，可以輕易的用不同語言開發應用程式的不同部分，使用者可以選擇任何過程性語言做二次開發。通過COM的底層機制，可以通路運作中的應用程式對象，實作與運作中程式交換資料。使用者元件也可以易于嵌入應用程式中。COM的主要問題是，運作速度比動态庫慢，特别是自動化接口；對系統穩定性要求高于動态庫，要求系統的COM平台能正常工作。

　　最常用也是最安全，成本最低的接口方式是中間檔案接口。

　　雙方的資料交流通過中間檔案進行。這種方式由于比較靈活，接口雙方都比較明确工作。而且重要是的，接口雙方的軟體更新，對于接口本身(對方軟體本身)可以說沒有影響。是目前采用較多的接口方式。

　　如果是中間檔案的還需要确定是全量式接口還是增量式接口。

　　接口本身是為了雙方資料可以保持交流和資料一緻性進行的。一方提供資料，另一方根據對方的資料來更新自己的系統的資料。是以對于哪些資訊是新加，哪些是删，哪些是更新要進行判斷。從資料提供方而言可以提供以下幾種：

　　全量：按軟體資料内的資料提供全部的資料，不進行區分哪些是增，哪些是删。這種方式需要使用者對比自己内部的資料進行區分哪些是增，哪些是删。

　　增量：由資料提供方進行對比後，區分哪些資料是要更改的，哪些是要删除的。對方軟體根據資料提供方提供的檔案直接更新資料庫。這種方式的重點是要掌握同什麼資料對比，得出增減記錄。另外，對不不同的記錄(增/減記錄)是提供不同的檔案，還是在同一檔案内對于不同的記錄做上标記也是要定義的。此時可能就要在接口字段上定義更改辨別，更改單号，版本号等資訊。

2.13 接口調研背景知識(下)

2.13.1 接口内容

　　接口方式一旦确定，就需要确定接口的内容。

　　接口内容首先要确定接口入口，從哪裡開始彙總接口資料，接口資料每次包含多少對象，這些對象是如何聯系在一起的。例如接口資料每次都從一個完整的産品上開始彙總，或者從一個完整的工程任務上開始彙總，或者從任意零部件上都可以發起彙總。

　　第二接口内容要确定接口時機，要明确哪些字段由資料提供方(其它系統)寫，那些讀，在什麼時候進行。也就是約定當資料達到怎樣的規定後才可以啟動接口輸出，此時也可以約定接口輸出負責人員。例如當産品結構釋出，相關工藝資料也釋出後才能啟動接口，如果有明确接口時機要求，接口程式應适當做校驗性判斷，防止提供不正确的資料給下遊系統。

　　第三接口内容要确定接口格式。

　　接口格式包括明确資料交換送出的方式：是檔案級還是資料庫級，然後明确交換檔案的名字，存盤路徑。

　　明确檔案的格式，包括檔案或資料表包含的字段名，字段次序，字段類型，字段長度，分隔符(如是文本檔案)，是否必填，預設值，下遊系統對應含義，實際資料樣例，接口對應資料來源，該字段在實際操作中填寫規則。

　　第三接口内容要确定接口樣例。

　　接口技術協定附件必須包括使用者方提供的樣例資料，樣例資料必須具備典型特性，能夠覆寫企業各種可能的實際資料情況，保證驗證樣例資料對接口測試的完整性；

　　如果一個樣例不能覆寫可以提供足夠樣例資料，使用者方可提供多個樣例，直到可覆寫各種可能情況為止。

　　使用者方要保證樣例資料的規範性。此時可能還需要針對接口樣例提供資料規範性錄入操作說明。

　　依據所提供樣例最終得到的接口中間檔案将以完整執行個體作為驗證标準依據。如果有多個樣例，則需提供多個完整的接口中間檔案執行個體。準備接口樣例将大大加快驗證時間和接口程式調整反複時間，也有利于企業，供應商快速就接口協定達成一緻性了解，是看起來慢，實際上最快的有效接口方式。

　　2.13.2 接口資料一緻性握手方式

　　接口資料的一緻性通握手方式來保障。一緻性分為靜态一緻性，動态一緻性，雙向一緻性。

　　靜态一緻性：如物料編碼資訊，原始工藝設計資訊。

　　動态一緻性：如設計更改資訊，在一個系統内的資料更新後，要求另一個系統内的資料也要進行相應的處理。握手方式即明确如何讓對方系統得到要進行更改的資訊(也可能是依靠人員來進行手工操作)，這樣對方系統對接口檔案進行處理。

　　雙向一緻性：複雜的系統甚至要求，對方系統處理的資料結果要進行回報。進而更新本身系統的資料。這裡面也要對回報進行定義。

2.14 調研後續工作落實階段

2.14.1 如何寫業務調研報告

　　調研結束後第一個必須盡快整理出業務調研報告，業務調研報告主體内容可以在業務分析會上得到使用者确認。

　　寫業務調研報告應該結合軟體供應商特點形成一個比較統一的彙報目錄模闆，有了模闆整理起來就快，不同軟體關心業務内容不同，模闆也應該不一樣。

　　一般而言業務調研報告目錄可以分為三個大的部分，第一部分是業務基本情況介紹，第二部分是企業業務流程圖和資料流圖，第三部分是項目關鍵價值點。

　　凡是不設計業務流和資料流，但必須要描述的内容，例如企業的一些基礎資料情況，我們把其作為企業的基本情況介紹，例如企業概況，企業設計資料統計情況，企業工藝資料統計情況，企業标準化編碼規定等等，做基本情況介紹時要把握兩個原則：

　　第一是結構化，不要散亂，将相關性強的一組基本情況設計成表格填寫，這樣既友善填寫，又不容易遺漏。

　　第二是按照調研先後順序組織，和業務流順序盡量一緻。這樣不但層次清晰，而且可以直接将每天調研日志内容複制修改就可以得到最終結果，大大提高工作效率。

　　業務流程圖和資料流圖有大量标準工具和方法指導，建議這裡大家去找相關專門知識學習，本文不在這裡展開。

　　第三部分項目關鍵價值點是非常重要的，項目價值點組織也必須符合結構化層次，不要将很大的價值和很小的價值并列排放，應該将最大的價值，可以互相獨立做為一層，然後将小價值分别歸類到不同大價值下，形成一個價值支撐體系，這個支撐體系也是解決方案的實作思路。

　　2.14.2 業務調研報告完成後續工作

　　業務調研報告完成後必須趕緊去找後續工作同伴，按照約定的工作計劃把調研報告交給他們，如果有時間，還可以安排一個内部業務分析會議，做一個全面的介紹。

　　幫助團隊成員可以準确了解調研報告，啟動後續工作才是一個調研的工作結束。

　　如果你能按照以上方法進行調研，相信你的調研品質一定很棒，這樣的話，不管後續工作是什麼，我相信你都會得心應手的去完成，或者幫助你的團隊成員去完成。

　　這也就是調研最大樂趣所在。

3 如何寫解決方案？

3.1 解決方案難寫在哪裡？

3 如何寫解決方案？

　　3.1 解決方案難寫在哪裡？

　　很多人對寫方案非常沒有信心，一涉及到方案的事情，就束手無策，到處求人。

　　作為一個公認的方案打手，意思是寫方案就象打字員一樣，我覺得我在這方面确實是有絕活。

　　我基本上都是在方案送出前一兩天接到寫方案的任務，而我自己的事情一般又比别人多一點，也不能不做，隻好心裡大罵一句，罵完後就打電話搞清楚别人的要求，邊問就邊構思整個方案的推導思路和結構提綱。

　　因為你不敢讓你的同僚知道你隻能用很少的一點時間寫方案(基本上我真正動筆寫方案的時間都在2~4個小時以内)，讓他們擔心方案的品質和進度保證，進而對自己的後續工作品質沒有信心。是以我其實也特别緊張，注意力也特别集中，大腦也高速反應，基本上幾分鐘電話或面談完思路基本就有了，然後該幹嘛幹嘛，找一些零散的小時間把思路不斷推導一下，然後到了一個比較安靜和完整的時間段前才開始寫，這個時候基本上要寫的話都想清楚了，隻需要不斷敲字，敲字的時候也是注意力也特别集中，大腦也高速反應，越寫思路越開，很快也就完工了。

　　寫方案不難，知道怎麼寫才難。關于寫方案我隻總結一點，結構化地去組織你的思想。

　　有結構就有思路，有思路就有方案。

　　另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，隻有這樣，每次都會進步一點點，解決方案水準品質就會随公司能力不斷增長。

　　當然我曾經問過很多人，你到底為什麼寫不出好的方案呢？

　　基本上原因可以歸為四類：

　　3.1.1 第一種是沒有體系

　　一旦使用者要求提供關于PDM的方案，很多人大腦是一片空白，完全不知道從哪裡下手。很多人說起自己的産品來，好象知道不少賣點，不過真要寫出來，又覺得無從下筆。

　　這種情況一般是寫方案者不熟悉自己産品體系造成的，知道一兩個甚至更多的産品賣點不難，但難就難在成體系，知識就是成體系的點構成的，而不是一句一句離散的說法構成的。

　　因為我們這個行業從業人員說句不客氣的話，大部分對所銷售實施的管理系統并沒有很深入的研究，都是半路出家，從頭開始，在學習過程中熟悉，在熟悉過程中領悟。是以一下子去駕馭一個整體方案是很痛苦的。隻有當一個人對一個産品思路有體系以後，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。

　　是以一個人要想寫好一個方案，首先要把自己産品的來龍去脈，功能子產品，适應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然後逐漸補充競争對手知識和一些技術性知識，不斷深化自己的知識體系。

3.1.2 第二種是沒有思路

　　有很多使用者看多了模闆化的方案以後，想看一些針對他們自己的業務的個性化内容，這個時候有的人按照标準方案模闆修改還勉強能對付，但對于個性化内容針對性方案就速手無策了。

　　這種情況從根本上講還是寫方案者不熟悉企業業務造成的，寫方案，特别是針對性方案不僅僅要求了解企業的需求，而且要知道這些需求是在何種業務需求下産生的，使用者提出這樣的要求到底想解決什麼問題，把這個問題找出來，一般針對性解決思路就有了，有了思路，自然可以很好的寫方案。

　　是以一個人要寫好方案，還需要了解下遊客戶的業務，了解業務最有效的方法就是親自做幾次詳盡的業務調研，有了業務調研做基礎，在調研過程中把握使用者關注重難點問題，自然可以比較好的确定方案的個性化内容思路。

　　解決方案就是把客戶的利益和産品特性之間建立一個邏輯性的橋梁。

　　3.1.3 第三種是沒有素材

　　一般不經常寫方案的人，在寫一個方案的時候，即使有想法，有思路，但往往也會很累，就是因為缺少足夠的素材。很多項目現在都是投标，不同使用者可能有不同投标的要求，這樣很難用一個方案去适應所有的使用者，是以在每個方案中都有一些需要準備的内容。

　　這些内容基本上是通用的，但如果沒有足夠積累每次編制方案就需要花費大量時間去準備，造成方案完成周期過長。

　　是以寫好方案必須具備這三個條件，第一方案編制者對企業業務要很熟悉，或者有相關業務調研經驗，第二方案編制者對産品非常熟悉，至少對自己産品功能子產品作用很清楚，第三方案編制者手上有大量可公用的素材庫。

　　3.1.4 第四種是沒有層次

　　很多人剛和使用者接觸沒有多久，為了表現自己對客戶的重視，馬上表示要提供方案，當然有的客戶剛剛開始選型，也不知道到底要什麼搞，也要供應商馬上提供一個方案。

　　結果拍胸脯容易，寫方案難，自己寫不出來隻好求公司，公司沒有安排專人了解情況，隻好按模闆制作一個，使用者一看幾個供應商内容都差不多，覺得不好，又總結出一些個性化要求，于是大家有開始折騰第二輪方案。

　　其實方案編制在不同階段有不同政策，不要輕易提供方案。剛開始接觸是可以提供項目合作建議書，類似可行性報告，項目需要考察軟體技術，可以提供标準的産品技術白皮書，到了經過售前調研，有所準備，在示範前後階段和其它競争對手刺刀見紅的時候，才在知己知彼的基礎上提供解決方案或者投标書。

　　過早提供方案隻能匆匆了事，時間緊急，品質自然不高，自然也就覺得方案難寫。想急就又能解決問題的事情，本來就是一般人做不來的。

　　方案想要寫得好，一定要用心，用心就一定要耗時間，指望用幾個小時寫出一個高品質的方案是不可能的。如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，明白了這一點，大家都可以經過練習寫出好的方案。

3.2 壞的解決方案有哪些特征？(上)

3.2.1 第一個容易犯的錯誤：隻有論點，沒有論證

　　不好的解決方案粗看起來非常厚重，其實都是功能羅列，象産品手冊摘要版，不象方案書。

　　不好的方案是一大堆内容，淹沒在一堆紙裡面，也不知道想說什麼，給你一個厚度，證明我們的工作品質很高。我們國内許多的企業客戶特别是大型企業都很在乎這點，認為可以從方案厚薄中看出對項目重視程度。

　　如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，有個金字塔式的寫做原理，也就是說文章一定是有結構的。

　　是以真正好的方案，不一定厚，但能看出你用心，你認真。

　　現在的解決方案一個不好的傾向是“長、厚、全”，看起來面面俱到，其實對決策者沒有幫助。

　　所有的方案無差異性，每家供應商都說自己能解決這些問題，而且都有成功案例。

　　結果所有的方案都無法給決策者簡明的判斷依據，不得不費更大勁去做産品示範和使用者考察。

　　其實很少有企業高管不知道自己的毛病，在企業你随便去找一個人，對問題都能講一通，在企業你費很大勁可能都找不到一個人能告訴你這些問題可以怎樣去解決。

　　通觀這個方案并沒有研究為什麼企業會産生這麼多問題？問題是這些問題是什麼産生的？為什麼出這麼多問題？而是不斷說“我能！我能！選我，選我！”。

　　如果不能找到解決這些問題的原因，簡單地去解決這些現象，就象治病不能治根一樣。這樣一個模闆化，自我膨脹化的方案想打動使用者的心是非常困難的。

　　不好的解決方案最大的問題就象寫一篇議論文，能夠發現問題(這個也是模闆化的，可惜中國企業大部分沒有意識到自己很多問題并不少見，總以為自己是特殊的一類企業)，提出答案(搞資訊化)，但沒有論證(為什麼搞資訊化和企業管理進步有聯系呢？)。

　　沒有論證的東西不管内容陳列得多麼繁複，名詞多麼吓人，但是無法打動使用者，特别是那種理性的使用者。

　　看到方案時候，其實很多使用者下不決心，他會感覺每家都差不多。

　　如果從沒看過方案的人，突然看到這幾個方案，你為什麼會感覺某個方案寫得好呢，關鍵是有的方案圖畫的好，通過圖，通過表，會感覺這個公司還不錯，很規範。但對内容認可程度并不高，實際上沒看懂。

　　3.2.2 第二個容易犯的錯誤：業務解決方案成為功能清單

　　解決方案省事的一種方法就是将産品功能描述作為技術方案内容進行羅列，或者參照軟體使用者手冊羅列，這種解決方案不是按照使用者業務去準備的内容，而是按照軟體商自己的喜好去編制的解決方案是很難得到使用者認可的。

　　大凡按照功能清單組織的解決方案使用者會有一個體會，龐大而庸長，但要看到自己想看到的部分非常困難。

　　而且這種方案還有一個特點，一個問題反反複複的提，在業務背景中指出某個問題，講一通，在價值分析中又重點解釋一通，到了功能介紹時又将某個問題來龍去脈概要說明一下，給使用者感覺是一堆資料的堆積，哪裡展現出了方案的針對性呢？

　　按功能清單準備方案的做法在很長一段時間内不會消失，這和我們普遍是4P銷售人員，還缺少SPIN(顧問式)銷售人員有關，在資源不足的情況下，要保證效率就隻能提供功能清單方案了。

3.3 壞的解決方案有哪些特征？(中)

3.3.1 第三個容易犯的錯誤：結構不清晰

　　不好的解決方案最共性的毛病是結構不太好，沒有清晰的思路。

　　沒有思路的方案品質很低，使用者在審閱過程中也不會體會到和一個專人人士通過文字交流的樂趣，他不得不從供應商混亂的思路中發掘亮點，看看到底是誰能解決企業的問題，真是一件痛苦的工作。

　　一種常見的方案結構毛病就是重複的内容在不同的章節反複出現例如在第一章介紹了對某個問題的分析，提出企業的需求，這第二章介紹方案價值的時候又用不同語句組織類似内容，到第三章解決方案描述中還是要把問題描述一遍，給人感覺思路不連貫，結構臃腫。

　　這裡有一個方案提綱的提綱，我們以這個提綱為例子說明結構不清晰的方案。

　　1 公司簡介及資質檔案

　　1.1公司簡介

　　1.2 自有産品及代理産品情況

　　1.3 重點工程介紹

　　1.4 公司資質影印件

　　2 分項标價表

　　3 ***PDM系統技術解決方案

　　3.1 ***PDM系統技術解決方案

　　3.2 ***PDM系統具體功能子產品

　　3.3 報表及明細彙總

　　3.4 應用工具及封裝接口

　　3.5 使用者及權限管理

　　3.6 拼圖列印

　　3.7 編碼管理

　　4 實施計劃

　　4.1 實施步驟

　　4.2 實施計劃

　　5 教育訓練計劃

　　5.1 系統教育訓練對象

　　5.2 主要教育訓練内容

　　5.3 教育訓練方式

　　6 實施人員資質

　　6.1實施人員組成及工作職責

　　6.2實施人員資質說明

　　7 品質保證及售後服務

　　7.1 品質保證

　　7.1.1 工程技術力量的研發水準

　　7.1.2 工程技術力量的實踐經驗

　　7.1.3 管理水準

　　7.2 售後服務承諾

　　7.2.1 技術支援與服務的内容和承諾

　　7.2.2 技術支援與服務的保障

　　8 開目典型使用者

　　9 有關技術秘密的聲明

　　10 附件

　　這個方案第一部分、第二部分是使用者投标要求，必須如此，但第三部分技術解決方案應該是重點，這個部分結構就很奇怪。

　　一般好的方案結構标題就是論點，内容就是用事實進行論證，子目錄是上級總目錄論點的分論點，逐層論證下來，方案顯得邏輯性結構性很強，看看目錄就能看出方案的邏輯推導體系。這就是所謂金字塔文檔體系。

　　這個方案顯然不是這樣的，看起來一大堆内容，有經驗的人一看就知道是内容的羅列。

　　例如第三部分總标題是技術解決方案，結果第一個子标題還是技術解決方案，撞車！一定層次感都沒有。而且第一子章節技術解決方案後馬上是功能子產品，技術解決方案理論上包括功能子產品，不是一個層面的東西，技術解決方案應該和實施政策，服務政策平級的内容，是以一定要談談自己技術解決方案，不如用技術解決方案思路或者特色來表達，和功能子產品也就是一個層次分論點，統一支援技術解決方案這個大題目。

具體功能子產品後面跟着一大堆章節就更奇怪，裡面每個都是具體的功能子產品，為什麼成為和具體功能子產品平級的内容？應該設定為具體功能子產品子章節為妥。

　　很多人可能覺得使用者對這個點很關心，要重點突出，是以一定要單獨立一個章節，其實不必然，結構清晰的方案使用者看起來才不費心，反而想這個方案，将具體功能子產品，報表及明細彙總、應用工具及封裝接口、使用者及權限管理、拼圖列印、編碼管理列為同一層面内容，反而叫人看不出排列的思路，在厚厚一大學方案中尋找對應關心内容并不容易。

　　其實不如把技術解決方案分為兩大部分，一部分介紹整個方案的實作思路，對于工作比較忙的人可以看這塊中對企業業務和邏輯的分析是否到位，相當于整個方案的精華版；一部分介紹整個方案的技術支撐子產品，對于項目具體負責人就可以深入研究技術支撐和業務思路之間是否存在合理的組織關系。

　　在第二部分技術支撐子產品中根據業務邏輯或業務順序設計功能子產品的介紹。

　　例如一般企業是首先考慮靜态技術資料的受控管理，在受控的基礎上要求盡可能內建設計軟體中的資訊，然後要對設計過程建立嚴密的動态控制體系，此外還希望得到一些設計過程的專業支援，例如變型設計，二級工藝路線管理等等，最後要求提供一些編碼，企業資源庫等等輔助工具。這就是我們實作企業需求的一個大的業務思路，在這個業務思路下我們可以将技術支撐子產品分為相應的五個部分。

　　到這裡，整個方案大的架構就有了，我們需要設計一下分标題，使使用者一看就可以進入自己關心的内容，而且每個部分都是對所屬總标題的呼應支援，在業務環節上也是“互相獨立，彼此窮盡”的環節。

　　在标題的設計上不要過于簡單，例如技術資料管理，應該說有效的技術資料管理，因為有效才成為技術支撐子產品，進而呼應前面業務實作思路中的描述。

　　3.1 業務實作思路

　　3.2 技術支撐子產品

　　3.2.1有效的技術資料管理

　　3.2.2深入的資料內建

　　3.2.3嚴密的過程控制

　　3.2.4靈活的設計支援

　　3.2.5輔助設計工具

　　在上面這個思路基礎上，我們就開始結合企業業務和産品功能進行考慮分标題下級的結構，我們用第一有效的技術資料管理為例子。

　　有效的技術資料管理到底要解決哪些業務問題才算完整呢？我們現在就開始将企業管理技術資料的業務進行羅列，在業務思路中逐漸說明。

企業管理技術資料是以産品為線索區分的，是以第一要說清楚産品資料如何管理；

　　産品下所有零部件是以特征為線索區分的，是以第二要說清楚零部件資料如何管理；

　　有些零部件還具有共圖共工藝的特征，是以第三要說清楚系列零部件資料如何管理；

　　進一步有的企業還有系列産品，是以第四要說清楚系列産品資料如何管理；

　　系列産品可能存在大量配置關系，是以第五要說清楚各種規則下産品配置資料如何管理；

　　有的企業産品配置型号在生産中還存在批次關系，是以第六要說清楚不同産品批次資料如何管理；

　　有的企業已經存在了大量曆史設計資料，是以第七要說清楚曆史産品資料如何入庫管理；

　　在資料入庫時有個問題每個人管理資料習慣不太一樣，全部統一成一種管理方式是必要的，但可能失去一些靈活性，是以第八要說明為個人自組織資料提供哪些支援；

　　最後要說清楚産品資料為什麼入庫管理後是安全的；

　　我們現在總結一下，這些技術資料管理手段如果都提供了，應該是完整而且層次清晰的，這樣的話，第一個子标題下的分标題又有了。

　　3.2.1有效的技術資料管理

　　3.2.1.1 産品資料管理

　　3.2.1.2 零部件資料管理

　　3.2.1.3 系列零部件管理

　　3.2.1.4 系列産品管理

　　3.2.1.5 産品配置管理

　　3.2.1.6 産品批次管理

　　3.2.1.7 資料入庫管理

　　3.2.1.8 個人資料管理

　　3.2.1.9 資料安全管理

　　再看看這個标題和業務思路，這裡面展現的一個結構化方式恰恰是“一句話一個意思，一層意思推動一層意思”，到最後就象剝筍一樣，層層剝開，問題解決思路也就步步清晰了，企業看起來也就很明白。

　　那麼我們還可以繼續細分使用者提出的各種業務需求，把企業各種業務要求對号入座，例如下面有一組需求：

　　有的企業要求使用者通路控制；有的企業要求提供角色權限管理；有的企業希望按産品目錄授權；有的企業要求全部存放在伺服器的資料庫中；有的企業希望支援多資料庫獨立通路； 有的企業要求提供備份工具等等。

　　我們現在看看這些業務是否都應該是關心資料安全的？是以應該放在資料安全管理目錄下，而且這些需求也可以分為不同層次，一些是和權限有關的，一些是和存儲和備份有關的，這樣很快又可以把子标題和分子标題設計出來了。

　　同樣我們可以推導出如下另外幾個部分的提綱：

　　3.2.2深入的資料內建

　　3.2.2.1 主流CAD的內建

　　3.2.2.2 CAPP的內建

　　3.2.2.3 和其它常用工具軟體的內建

　　3.2.2.4 資料挖掘統計工具

　　3.2.2.5 和其它PDM/ERP系統的內建

　　3.2.3嚴密的過程控制

　　3.2.3.1稽核管理

　　3.2.3.2釋出管理

　　3.2.3.3更改管理

　　3.2.3.4項目管理

　　3.2.4靈活的設計支援

　　3.2.4.1 變型設計業務支援

　　3.2.4.2 二級工藝管理業務支援

　　… …

　　3.2.5輔助設計工具

　　3.2.5.1 編碼管理

　　3.2.5.2企業資料總管

　　… …

　　這個結構化體系一旦出來後，整個方案的思路是否清晰明了，下筆容易了呢？

　　結構化體系最大的好處是不亂，今後使用者提出任何業務需求，或者産品功能如何擴充，都很容易對号入座，或者擴充子标題。這也是展現了一種分類管理的思想。

　　當然這個分類思路根據不同業務特征允許存在多種可能，而且分類層次應不超過5級标題，否則文章的可讀性不佳。

　　如果一定要超過5層，就可以采取其它排版方式展現。

3.4 壞的解決方案有哪些特征？(下)

3.4.1 第四個容易犯的錯誤：口語書面語混雜，遣詞造句不嚴謹。

　　不好的解決方案還有一個毛病就是口語書面語混雜，遣詞造句不嚴謹。

　　有的人寫作時順着思路走，口語化成分很多，例如本人的行文基本是口語化的，也展現了這個毛病。當然大師級人物的确可以将文章寫得明白如話，但是對我們這些人而言方案是代表公司正式對外的文檔，一定不要出現口語和書面語混雜的情況。

　　例如太多的兒，的，我們，你們等等都是口語化語言，不應該大量出現在正式方案中。

　　有的人寫方案比較圖表現，喜歡指出使用者的不足，這個時候喜歡用很激烈的語言。例如缺少管理，業務失控，後果很嚴重等等語句，這樣的遣詞造句是不嚴謹的，方案用語不要追求“語不驚人誓不休”。而是理性分析，認真推導，句句講邏輯。

　　實在要用一些事實說明企業的問題，不要用刺激性強的語言，例如說企業業務存在問題，可以說業務有可改進的地方，例如說企業管理失控，可以說管理上存在很難受控的環節。

　　這樣的表達企業反而容易接受，不出問題。

　　3.4.2 第五個容易犯的錯誤：沒有認真檢查，存在大量硬傷。

　　不好的解決方案制造過程往往是找一個同類方案，然後主要工作是“CTRL+C”+“CTRL+V”。

　　很多人就圖快，省事，沒有很好的核對，結果往往容易出現如下幾種錯誤：

　　第一有些企業在一個方案中用了不同的稱呼(這個也要養成一個習慣在一篇方案中一個企業用一個簡稱和一個全稱)，替換不完整，結果在方案中出現了其它企業的名稱，非常不禮貌；

　　第二有時候替換過頭，把一些案例中類似的話也替換成為給使用者名稱，鬧出笑話。

　　第三隻注意了文字替換，不注意圖形中的替換，結果文字是一個使用者的，圖檔是另一個使用者的，感覺不尊重。

　　第四是隻注意了文字替換，忽視了頁眉頁腳的替換，特别是注意了首頁或目錄的頁眉頁腳，沒有注意正文的頁眉頁腳。

　　第五是案例不對，明明是汽車行業的使用者，案例全部都是其它行業的，感覺在這個行業沒有經驗。

　　第六是聯絡方式不對，很多時候将别的營銷區域方案拿過來用，服務資訊都沒有更正過來。

　　第七是存在大量技術硬傷，有時候為了突出軟體技術實力，将大量專家都不一定看得懂的詞彙大量堆砌，其實連軟體公司自己都搞不清楚采用了哪些。

　　企圖通過讓使用者對概念和名詞發暈進而對軟體産生信賴的方式已經過時，解決方案應該實事求是說明業務問題，不要在名詞上忽悠。.

3.4.3 第六個容易犯的錯誤：過于突出自我

　　很多人寫方案大量出現“**軟體公司”内容，甚至每個産品都恨不得加上自家辨別。在很多地方行文造句都是“我能，我行，我有…”等語氣。

　　這種方案很容易給使用者過度營銷的感覺。我們給使用者寫的方案在售前建議盡量用使用者做字首，例如說某某企業PDM項目，不要總在說某某供應商PDM的話，給使用者一種相對的針對性，感覺這個方案的确是為使用者準備的。

　　在售後實施方案中軟體公司的名字隻需要出現一次，後面就不需要反複出現，因為大家都知道是你的産品，何必反複展現，我們更應該把使用者的注意力集中到産品本身就應該具備的功能和支撐業務上，而不要形成某某可以，某某不可以的印象。

　　3.4.4 第七個容易犯的錯誤：沒有評審。

　　方案送出給客戶之前，一定要經過評審。

　　沒有開發點的方案，一般經過自評和互評即可，自評時，要重新審視整個方案的結構、問題描述、遣詞造句等方面，特别是用替換修改的企業名稱和營銷平台等方面的内容，盡量減少低級錯誤。

　　自己評審過的方案一定要給一個其它的人評審。

　　互評時，要重新審視整個方案的結構、遣詞造句等方面的内容。

　　對于有開發點的方案，要經過公司的評審。送出給公司評審的方案，一定是已經過自評和互評的方案，而且要注明主要看哪些部分，以及編寫這些部分的背景知識。

　　3.4.5 第八個容易犯的錯誤：沒有展現公司産品最新進展。

　　一般人寫解決方案首先不是想着如何說清楚使用者的業務，如何在公司産品中展現出對業務的支援，而是想趕緊找一個模闆，把這一關走過去再說，其實很多時候就是對每個階段工作沒有品質意識最後導緻工作處處被動。

　　是以寫解決方案一定要根據公司最新産品功能認真組合功能實作企業業務，甚至可以考慮利用未來半年内會釋出的功能認真組合，因為解決方案離正式實施往往需要半年甚至更長的周期。

　　很多時候解決方案一抄再抄，都是一兩年前的模闆，自然缺少競争力和說服力。

　　這個問題的核心是公司有沒有專人專崗負責對标準解決方案的維護和更新釋出機制，其實比較好的一種做法結合典型項目技術公關推動解決方案水準不斷完善和提高。

3.5 寫好方案心得(上)

3.5.1 動筆前先打一個電話

　　一般情況下方案撰寫人隻是按照别人要求提供方案，并非直接利用方案的人，是以在寫方案之前，問問需要方案的同僚，甚至是使用者，聽聽他們對方案的想法和建議，對自己寫方案會有很大幫助。

　　很多時候方案準備完成方案接受者并不滿意方案的組織，需要返工修改，是以動筆前先打幾個電話，問問别人要什麼，不但可以提高方案準備命中率，甚至可以獲得大量現成的思路建議，對自己寫方案大有好處。

　　3.5.2 一定要努力按業務邏輯去寫。

　　一般寫方案最簡單的方式就是按照軟體自己的思路和功能子產品組織，因為有大量現成的材料可用。但這樣方案對使用者并非是一種最佳選擇，因為客戶要轉換到供應商的思維才能看懂方案字句之間的含義。

　　如果從以客戶為中心角度出發，方案應盡量讓使用者容易看懂，好了解，自然也就取得了幾個印象分。

　　我們方案就是要先仔細探讨企業業務，不是将調研結論一羅列，而是從業務分析得出業務需求，最後描述技術實作手段。從這個意義上講，解決方案要按照簡明的操作手冊來準備。

　　3.5.3 按标準套路寫方案

　　不同類型的方案都有自己的套路，例如可行性報告，解決方案，建議書等等都有标準的套路，我們應盡量按照标準套路準備方案，不要自成體系，在套路下發揮，套路就展現了一種結構化體系化的思維模式。

　　關于常用套路我們另有一章說明。

　　3.5.4 先構思提綱，經過讨論，最後動筆

　　很多時候方案準備時間并不充分，很多人接到任務，壓力之下立即開始動手，這往往是不好的工作習慣，有時候有模闆，的确可以快速出活，但時間長了就養成一種惰性，替換方式抄方案還勉強，真要遇到有個個性化問題，因為在平時寫方案過程中思維始終不經過結構化思考的練習，真到方案模闆沒有覆寫的情況，就沒有辦法應付。

　好的方案特點是：标題就是論點。結論做為标題馬上拿出來。

　　好的方案是觀點鮮明，立場明确，有理有據，有血有肉。

　　是以有方案要寫，一定不要急着寫，而是想自己的提綱，這個完整提綱目錄之間的邏輯聯系和業務銜接自己在心裡面推導得比較有力和充分了，才開始動筆快速拿出提綱，有了提綱寫起來思路就不會斷電，寫起來才快。

　　好的方案一定是做了論點。

　　論點是假設的，例如說搞PDM有價值。

　　你說價值有三個方面，能降低成本，提高品質，能縮短交貨期。這都是你的假設。

　　你怎麼知道成立？就要找些事實去證明它。

　　我們現在都喜歡找什麼事實呢？你用了這個功能，是以你的論點就成立，因為你有這個功能，是以你的效率提高了。

　　這都是扯蛋！為什麼用了PDM企業就能做到這幾點。根本沒邏輯推導。

　　不是還有大把企業用了ERP，用了PDM還不是該咋的咋的，錢都打水漂了。

　　假如你有好多論點，論點怎麼組織呢？你比如我要搞資訊化，資訊化有大價值，小價值對不對？你要把它都列出來，列出後你還要想一想這個價值和那個價值是不是包容的關系？

　　好處一定是每個好處都是獨立，它是有層次，每層上的好處是平級的，大好處包含多個小好處，這些好處倒推出來就響應支援你的論點，這種方案看了以後别人就會了解并支援你。然後每個好處一定是在前一個好處的基礎上往前推動一步，最好得出一個強有力的論證過程。

　　是以好的方案必須是金字塔型的，論據論證最後構成堅實的基礎。

　　如果有條件的話，這個思路還應該和大家讨論，特别是一些重要方案，一定要先反複讨論提綱，大家各種意見和思路在提綱中統一了，再動手寫。這樣就不至于遇到寫了一半被人否定，推倒重來的痛苦了。

　　3.5.5 找一個安靜的地方和完整的時間段開始

　　寫方案最怕中間不停被人打斷，這樣思路連貫性會很差。是以我無論接到多麼緊急的方案編制任務，也不會急着去寫，而是把手頭該處理的小事情處理幹淨，然後保證開始後的時間相對安靜和完整，這樣才能保證方案的品質。

　　而且寫方案一定要保證在一個時間段内初步拿出完整的推導思路和結構提綱才能結束去幹别的事情，這樣以後就是逐漸補充和豐富内容，不至于還在為結構苦惱，不清楚從哪裡下筆，

3.6 寫好方案心得(下)

3.6.1 認真準備閱讀提示和摘要

　　一個方案往往厚厚一本，更多是充點門面，上司是不會真看的。萬一要看，也就是看看包裝是否精美，和頭幾頁文字。

　　是以方案可以單獨附一份摘要，這是關于整個方案業務分析和解決思路的精華部分，當然也可以帶一點實施方法和典型使用者的介紹。

　　這樣就可以讓自己方案思路在短短幾頁紙中清晰描述和表達出來，這種提煉過的語言和文字往往更能打動人心。

　　一般寫一份厚方案隻需要一天，寫一份薄方案需要一周，要求在三頁紙内說明問題需要一個月！能把書讀薄是能力的展現。

　　對于方案也一定要提供一份閱讀指引，告訴不同的人其關心的内容可以在哪些章節直接獲得，友善其閱讀。實際上我們觀察很多論文和書籍序言都有一段來說明這個文字的結構，其實這也是一個标準做法。

　　3.6.2 注意排版

　　方案一定要注意排版，印刷要幹淨，封面要隆重，裝訂要精美，方案就是一個公司的臉面，雖然不是說一份方案可以決定項目，但一份看上去都不好的方案一定很讓人懷疑公司的能力。

　　我們很多人見過外企的文字，一般都非常精美，排版很漂亮，大家一看就覺得是專業人士所為。

　　是以方案的文字和圖表内容最好請專門的美工設計一套标準的排版體系，對方案整體可讀效果會起到極大促進作用。

　　現在很多方案都是密密碼碼，内容是多，可以有什麼用？

　　不如取巧，少寫一些文字，多在排版上動腦筋，實在想不出好的排版是什麼回事的，去買基本暢銷書，你會發現可讀性好的書往往有一個技巧叫“留白”。

　　方案文字段落邊框之間保持适當距離，特别是邊框合理留白會讓一份方案可讀性大大提高。

　　象本文這樣的文字如果加上留白設計可讀性就會很不錯。

　　3.6.3 注意積累素材

　　寫方案無論如何按照企業業務組織，基本上90%内容是相同的，不過是根據不同思路進行組織而已，畢竟軟體功能不會在短期内發生巨大改變，方案涉及功能也沒有理由發生大的改變，是以方案中很多素材是可以通用的。

　　包括一些公司通用素材，更是要随時積累補充完善和歸類存檔，這樣在寫方案時才不會因為尋求這些基本素材浪費大量時間。

　　基本素材收集還要注意随時和公司公開宣傳口徑保持一緻，防止引用過期素材。當然标準素材最好由公司統一維護。

　　擷取其它素材的途徑比較多，主要有：

　　現場初步需求調研與交流

　　與熟悉類似項目的銷售經理、技術支援工程師、實施工程師溝通、了解

　　營銷平台交流

　　企業網站

　　相關行業資料介紹

　　書刊

　　……

　　一般可以從企業網站擷取企業介紹。從網站擷取的企業介紹需經“角色轉換”和“内容篩選”，角色轉換是指站在公司的立場描述該企業的情況介紹，要把第一人稱改為第三人稱。内容篩選是指主要介紹企業資訊化的基礎，包括企業的經濟實力、管理水準、已完成和正在進行的資訊化項目等内容。

3.7 方案分類及用途

3.7.1 方案的種類

　　目前，公司為客戶撰寫的方案分為：建議書、解決方案、投标書。技術白皮書應作為統一的資料提供。

　　建議書是用于動員客戶啟動項目，或者用于客戶初步選型階段的技術支援，以入圍；

　　解決方案是用于洽談技術協定和合同之前的技術交底，或者用于議标階段以技術和實施服務等優勢戰勝對手；

　　投标書是用于客戶招标的技術交底，以綜合實力戰勝對手。

　　3.7.2 方案的基本結構

　　3.7.2.1 建議書的基本結構

　　建議書的側重點是分析客戶實施某項目的宏觀和微觀形式、現存的諸多問題，提出實施該項目的必要性和緊迫性，再介紹相關産品和技術的發展現狀公司的産品特點和優勢，落腳點是公司已具備相當的實力，與公司合作成功率最大、風險最低。建議書的基本結構如下：

　　引言

　　現狀分析與診斷

　　相關技術的發展現狀

　　公司相關産品的特點

　　公司具備的實力和基礎

　　結束語

　　各個部分撰寫技巧如下：

　　引言部分

　　從全國、行業的資訊化現狀分析入手，說明資訊化是大勢所趨，再從本行業的産品特點出發分析資訊化需要注意的關鍵問題，最後介紹企業的情況，特别是資訊化的已有基礎，包括企業的經濟實力、管理水準、已完成和正在進行的資訊化項目等，說明該企業已具備實施本項目的基礎。

　　引言部分可分為：

　　制造業資訊化現狀

　　本行業資訊化特點分析

　　資訊化的基礎

　　現狀分析與診斷部分

　　從本項目所涉及部門的業務現狀描述和分析入手，找出問題，并提出相應的解決辦法。

　　現狀分析與診斷部分可分為：

　　業務現狀描述

　　問題分析與診斷

　　相關技術的發展現狀部分

　　主要介紹本項目所涉及的PDM/CAPP/CAD等技術産生背景、發展過程，以及發展趨勢等内容，并說明這些技術已是成熟的實用性技術。

　　相關技術的發展現狀部分可按軟體産品類别分别介紹，最後有一個小結。

　　公司相關産品的特點部分

　　主要介紹公司相關産品的主要特點，說明公司相關産品是符合其發展趨勢的先進和成熟的産品。

　　公司相關産品的特點部分可按軟體産品類别分别介紹，最後有一個小結。

　公司具備的實力和基礎部分

　　主要從公司簡介、完整産品線、研發能力、實施與服務體系等方面，說明公司已有足夠的能力承接本項目，并以成功案例證明與公司合作成功率高、風險最低。

　　公司的實力部分可分為：

　　公司簡介

　　完整産品線

　　雄厚的研發能力

　　科學的實施與服務保障體系

　　成功案例

　　結束語部分

　　闡明公司願與企業強強聯手，結為(戰略)合作夥伴關系，共同推進企業乃至本行業的資訊化建設。

　　在結束語部分要明确提出合作建議内容，對于一些戰略合作夥伴關系不能輕易宣講和承諾，一定要經報公司準許之後方可承諾。

　　建議書的要求是簡短緊湊，内容詳實，便于使用者決策，可以在一份建議書中形成幾個可選方案，推動使用者決策。

　　3.7.2.2 解決方案的基本結構

　　解決方案的側重點是分析現存問題，提出功能需求及相應技術實作手段，并輔以實施保障措施，說明使用者需求是可以實作的。解決方案的基本結構如下：

　　引言

　　現狀分析與診斷

　　系統規劃與設計

　　系統技術方案

　　系統實施方案

　　服務内容及措施

　　典型案例

　　結束語

　　引言部分

　　從全國、同行業的資訊化現狀分析入手，說明資訊化是大勢所趨。再從本行業的産品特點出發分析資訊化需要注意的地方。接着介紹企業的情況，特别是資訊化的已有基礎，包括企業的經濟實力、管理水準、已完成和正在進行的資訊化項目等，說明該企業已具備實施本項目的基礎。最後通過公司介紹說明有能力承擔該項目。

　　引言部分可分為：

　　制造業資訊化現狀

　　某行業資訊化特點分析

　　資訊化的已有基礎

　　公司介紹

　　現狀分析與診斷部分

　　從本項目所涉及部門的業務現狀描述入手，分析出問題，并提出改進建議，得出實施系統的必要性和緊迫性，以及需要解決的問題

　　現狀分析與診斷部分可分為：

　　業務現狀描述

　　問題分析與診斷

　　系統規劃與設計部分

　　根據現狀分析提出的需求，對本系統從總體目标、指導思想、總體架構等方面進行總體規劃與設計。總體目标，是從企業已有明确的總體目标中，結合使用者需求提煉出來的，不能簡單照抄，還需适當調整與補充。總體架構包括體系架構、運作模式，以及其它企業關心的問題等。

　　系統規劃與設計部分可分為：

　　總體目标

　　指導思想

　　總體架構

　　體系架構

　　運作模式

　　……

系統技術方案部分

　　從基本功能介紹、關鍵問題解決方案兩個層面介紹具體的技術方案。基本功能介紹是對本項目所涉及的産品，在标準子產品功能基礎上适當補充各子產品的新增功能或使用者的特殊功能。關鍵問題解決方案是就企業特别關心的問題(包括管理和技術兩個方面)、企業特殊需求中有一定難度的問題，以及管理方面需要改進的問題等提出解決方案和建議。

　　系統實施方案部分

　　從本項目的預期效益入手，分析項目實施存在的風險，接着介紹公司規避風險的實施保障措施，最後給出初步實施進度計劃和教育訓練計劃。實施規劃要結合使用者的實施打算，如果系統規模比較大，可以結合使用者的需求适當進行目标分解，分期完成。

　　系統實施方案部分可分為：

　　預期效益

　　風險分析及對策

　　指導思想

　　指導方法

　　實施管理

　　實施規劃

　　實施進度計劃

　　系統教育訓練

　　服務内容及措施部分

　　從公司能為客戶提供全方位服務承諾入手，闡述公司技術支援與服務的保障措施，讓客戶無後顧之憂。

　　服務内容及措施部分可分為：

　　服務内容及承諾

　　技術支援與服務保障

　　典型案例部分

　　用公司典型使用者的案例進一步證明，公司提供的技術方案是先進的、實用的，形成一套科學的、可操作的實施方案。典型案例選擇的針對性表現在：行業、特殊需求、項目類型等方面有相似之處。

　　結束語部分

　　闡明公司願與企業強強聯手，達成合作夥伴關系，共同推進企業乃至本行業的資訊化建設。

　　解決方案注意業務分析，系統規劃，技術方案三部分不要反複出現重複的内容，或者為了表達自己技術方案是扣着業務需求而在系統規劃和技術方案中再次反複描述需求，如果發現有這樣的問題就要精心去組織方案提綱。

　　此外解決方案要避免浮誇和務虛的内容，要盡量讓使用者看到可操作的内容，例如在實施方案中使用者最關心的是在實施分幾個階段？每個階段互相配合工作是什麼？誰去做合适？階段結束的标志是什麼？每階段工作需要多長時間？根據企業實際情況有哪些風險？如何規避？基礎資料如何準備？曆史資料如何錄入？工作流程應用前後有何變化？這些是使用者真正關心的内容。

　　所謂實施方法論，實施原則，實施指導思想，實施團隊結構等看起來飽滿，其實是務虛的内容少寫，寫得越多使用者越不得要領，實施方案的要害是具備不具備可操作性。這裡面的原則就是計劃越細化越具有可操作性。

　3.7.2.3 投标書的基本結構

　　投标書是針對标書的解決方案，包含解決方案的全部内容，再增加公司優勢和相關附件。投标書總是原則是按照使用者提供的招标書要求準備，使用者要求如何提供資料就如何提供，不要任意發揮。

　　常見投标書的基本結構如下：

　　引言

　　現狀分析與診斷

　　系統規劃與設計

　　系統技術方案

　　系統實施方案

　　服務内容及措施

　　開目公司的優勢

　　典型案例

　　結束語

　　相關附件

　　開目公司的優勢

　　相關附件

　　相關附件按照招标書的規定組織附件。

　　3.7.3 方案的針對性

　　為使方案具有鮮明的開目特色，方案必須具有一定的針對性。不同類别方案的針對性有不同的展現。

　　建議書的針對性展現在同行業的資訊化特點分析，本企業已有的資訊化基礎、本企業的現狀描述與問題分析等方面。

　　解決方案和投标書的針對性有相同的表現，主要展現在：同行業的資訊化特點分析、現狀分析與診斷、總體目标、關鍵問題解決方案、實施規劃與進度計劃、典型案例等。

　　現狀分析與診斷部分、實施規劃與進度計劃部分，不能簡單把客戶名稱更改就變成另外一家的情況。

　　總體目标部分，有企業的個性，如果需要可以分解成近期、長期、遠期目标。

　　解決方案中可單獨把企業關心的關鍵問題單列為一部分，緊密結合企業的需求特點，不能簡單套用标準說法，必要時可以通過定制配置實作。

　　解決方案中的關鍵問題與投标答辯PPT中的關鍵問題有差別。投标答辯PPT中的關鍵問題主要是展示我們優勢部分，以攻擊對手的劣勢部分，但一定要有絕對的把握。

4 如何做産品示範？

4.1 什麼是示範？

入行五年，售前售後示範最少也有兩百次，也算有一點經驗了，今天把我個人做做産品示範的體會做一總結，希望對所有想做好示範的人員提供一點幫助和指導。

　　産品示範不是演講，也不是答辯，更不是教育訓練。

　　盡管在很多表達和現場互動技巧上，演講，答辯，教育訓練和示範都有相通的地方。

　　演講更側重對某一個問題看法的陳述，主要是交換觀點，允許争鳴，聽衆可以不同意你的觀點，但一定會捍衛你發言的權利。

　　除了常見的演講比賽外，很多時候演講者是受邀請，以一種被尊重狀态出場，是處于一種比較從容的心态下開始的。

　　演講的過程一般也是比較連續，不會被随意打斷的。

　　答辯更側重對話雙方的互動，具有很強的考核目的，通過對答辯問題的反應答辯主持方來主動判斷他想擷取的資訊。

　　答辯的過程一般是不連續的，随時都可以中斷響應不同的問題，答辯的節奏和壓力也更為緊張，時間非常緊湊。

　　教育訓練更側重于傳授操作，此時被教育訓練者已經認可教育訓練者所在公司和産品，在過程中更多的是教學相長，形式可以多種多樣，根據不同教育訓練層次靈活組織。

　　示範不然，示範是有極強的目的性。示範往往是要在有限的時間内(比答辯要舒展)，面對一群不同心态或者不明心态的人快速把自己所在公司、公司産品和服務，包括自己最大範圍内推銷出去。示範過程中還要随時準備開始各種技術答辯，應付各種刁難。

　　示範是主動影響客戶(使用者)的過程，售前示範也是主動和競争對手競争的過程，示範更是個人魅力展現的過程。

　　整個示範就是一場複雜的腦力遊戲，看看我們有什麼辦法在短短1到2個小時内更能抓住使用者的心！

　　4.2 示範的目的：

　　4.2.1 售前示範的目的

　　介紹公司，通過自己的言行和産品介紹展示公司的形象；

　　強化自己的優勢，給競争對手設定一定的技術門檻；

　　講出自己能為使用者做什麼，解決什麼問題，愈是使用者關心的問題愈要主動溝通和交流，讓使用者對軟體産品技術和實施能力放心；

　　進一步判斷使用者關注的項目重難點，了解我們前期準備的不足，采取針對性後續對策。如果是這個項目一定要解決的問題，目前産品又無法實作的内容，必須盡快回報給公司決策。

　　4.2.2 售後示範的目的

　　介紹公司和産品，讓廣大具體使用者認可公司，取得最大範圍品牌認同，減少實施阻力；

　　宣講對企業問題的認識，提出自己的業務解決思路，主動控制項目邊界；

　　通過現場互動進一步判斷使用者關注的價值點是否在項目邊界内，确認是否要調整項目邊界，盡快回報給實施團隊或公司決策，

　　除了目的不同外，售前示範比售後示範更具有挑戰性，使用者更可能具備不合作性，示範沒有達到目的将可能導緻不可挽回的局面。

　　一般在管理軟體售前項目中，産品示範效果不佳和典型使用者考察效果不佳兩個因素可以導緻直接出局，沒有挽回的餘地。是以産品示範一定要解決使用者對我們技術能力上的顧慮，保證得到進入下一輪篩選的機會。

　　是以本文重點将放在對售前示範工作的說明上，以下内容基本上都針對售前示範說明，售後示範可以參考并簡化部分内容進行即可。

4.3 售前示範為什麼效果不好？(上)

坦率地說，我們業内大部分管理軟體示範總體來講不是特别理想，并沒有深入打動使用者。它為什麼不理想呢？我個人認為有六個大的原因。

　　4.3.1 第一是示範沒有整體策劃。

　　成功的示範絕對不僅僅是兩個小時的精彩發揮，要保證這個精彩發揮，必須做大量的基礎工作才行。好的示範一般都有一個人在精心進行整個示範活動的策劃，是整個項目商務活動中必要的一環，而不是一個在孤立準備的活動。

　　商務人員往往期望有一個“高”人，到現場做一個精彩絕倫的示範，讓競争對手甘拜下風，讓使用者眼前一亮，然後再四平八穩的把事情擺平，這種事情基本上不存在。

　　之是以某些人示範做的好一點，隻是因為他準備的比别人多得多，如果示範者平時每天花半小時去示範，三個月後水準将是非常厲害的。

　　而現在許多人因為有某個單子才想起要準備示範，這個時候自己能示範什麼呢？隻好先看看誰能搞定這個事。這樣必然會導緻某幾個人水準越來越厲害，而大家都不厲害，業務肯定做不好，都找這幾個人，這幾個人累死，而自己做業務總是束手束腳嘛，這不是一個很好的方法。

　　隻要做好準備，每個人都能成功的做示範。要做好示範就不要随意示範。

　　不要以為産品有幾個亮點，商務人員就想給使用者“鎮”一把。想這樣示範的，因為準備不足，或者沒有套路，結果使用者第一眼就看不中，會不斷的讓你示範，反反複複。

　　結果幹了一件什麼事呢？不斷給别人啟蒙，摘桃子的是别人。

　　即使在一次示範中效果很好也不意味着項目就是你的，而是在成功示範後安排大量後續工作。一般管理軟體項目周期很長，在短期之内，你不做太多投入把大單搞下來，但一定會有一個很密集的時間，投入了密集的資源做一系列的事，讓上上下下都認可你了，後面再按部就班進行。

　　這就要求要提前規劃示範，一般商務人員要提高半年或一年判斷大概在什麼時候示範比較合适。

策劃什麼呢？

　　第一要示範哪些東西讓使用者很接受。

　　如果要想知道這個事，首先要通過接觸對企業基本業務做個判斷，判斷以後安排技術工程師，或總部協調資源進行一次到位的調研，然後提前半年、一年準備，做一個相對來說比較和企業個性化特征吻合的配置，這叫技術準備。

　　第二，如果安排示範，一定要考慮示範達到目的了，後續最理想的工作安排是什麼？是不是可以馬上安排使用者和公司考察，這樣他會在一個很高的情緒下不斷認可公司實力。

　　一定要考慮，示範以後效果好怎麼，效果不好怎麼辦？我們往往是示範了就完了，其實這個事根本沒完。

　　第三，示範給誰看，一定要保證這個人到位。

　　示範的時間甯可推遲，一定要保證你希望來看的人一定要到場，如果不在場，就不要示範，沒有意義。

　　4.3.2 第二是示範沒有套路。

　　很多人對軟體了解不同，喜歡按照自己的思路去發揮，每個人都進行發揮，結果導緻整個公司的示範沒有統一的套路。

　　如果沒有統一示範套路，示範行為就無法标準化，沒有标準化的東西在管理上很難受控，也就很難保證品質，很可能某幾個人示範很不錯，大部分人示範不到位，那就趕緊把這幾個人的套路标準化并推廣。雖然企業有很多差異，但還是可以尋求共性，無非是針對不同類型多準備幾種統一的套路。

　　套路是一緻的，但并非是說所有的人都在背台詞，而是說所有的人用比較一緻的思路去讨論問題，談問題的實作方案，特别是一些共性的問題。

4.4 售前示範為什麼效果不好？

4.4.1 第三是套話理念太多。

　　在策劃示範套路時要更多考慮一個問題，不是我們有什麼功能，而是這些功能按業務能不能串起來。在考慮示範内容時，不要空談理念，在講到一個業務線的時候，把想法拔高一下，在合适的時候自然地帶出來。

　　如果大量在談理念，一是低估了使用者的知識面，二是提高了使用者的期望值，三是大量時間并沒有讓使用者看到實在的東西，誰也不會下決心購買概念，使用者特别是技術型使用者更願意看到實際的内容，對于高管，在交流時談談理念可能更合适。

　　示範不能單調的隻是将PPT的内容念出來而已，PPT的内容要簡單，主題明确，而演講者腦子裡的東西則一定要充分口語化表達。

　　4.4.2 第四是示範時機不好。

　　過早示範往往是示範效果不佳的一個重要原因，很多客戶經理其實缺乏銷售管理軟體的經驗和從容自信，也缺少業務内涵，是以當發現一個項目資訊後，他們往往不知道下一步可以做什麼，要麼被動地随着使用者要求走，要麼就積極主動創造調研和示範的機會，期望通過一次良好的示範或者使用者考察達到他們想要的目的。

　　實際上一個大的管理軟體項目售前周期是很長的，匆匆忙忙去調研示範，效果往往不好。我本人發現在長期跟蹤的項目上，往往是早起的鳥兒沒蟲吃。不要怕耽誤一個月兩個月時間，可以按部就班進行，當然那些客戶經理自己都沒有跟蹤，主動找上門來的緊急客戶項目例外。

　　為什麼呢？一般客戶不可能一開始就完整知道這個概念和自己的業務需求，經過很多供應商多輪次攻關後，客戶才能比較清楚一些概念和自己的業務需求關系，也就比較容易看懂示範，示範也能達到目的。

　　大項目上是不會有太多的示範機會的，特别是在多競争對手情況下，甯可等到公司準備就緒，确定示範策劃和實作計劃後，才能客戶預約，哪怕耽誤一些時間也不用擔心，給客戶解釋清楚，一般都會了解的。越是急着示範越可能成為使用者啟蒙者，而不是簽單者。

　　4.4.3 第五是示範人員能力不足。

　　示範這個工作不是誰都可以做的，它對人員綜合能力有極高的要求，顯然這種能力人員在任何一個公司都是稀缺資源，但是幾乎每個大項目都需要進行示範，在擁有能力的人員不能到位的情況下，隻好用能力不足的人員去做示範，自然效果不佳。

　　4.4.4 第六是示範準備周期太長

　　很多項目使用者提出要求示範，客戶經理為了表示對項目的重視，也為自己争取到一個表現的機會，一定是滿口應承。

　　應承過後很多客戶經理就會陷入困境，遲遲不能排程到示範人員去現場示範。如果讓自己或技術支援去講，肯定是講不清楚，達不到效果。

　　如果讓公司顧問來講，顧問太少，單子太多，都不知道什麼時候才能輪到自己這裡，即使來了一個顧問，也是沒有什麼準備，匆匆忙忙，效果也不一定好。

　　當使用者發現供應商對答應的示範時間一拖再拖，就容易懷疑供應商的組織能力和産品實際水準，最終示範時也不能足夠重視，結果參與人員不足，自然難以達到效果。

　　是以作為一個軟體企業要想辦法讓示範組織工作程式化，示範套路标準化，有一個團隊在全力支援示範各個環節工作。軟體企業讓可能要進行示範的人員不斷練習，保證每個人示範可以達到一個基本的品質，保證企業随時具備四到五個可排程，能清楚示範自己主導産品人員是非常重要的基礎工作。

4.5 售前示範工作應如何組織？(上)

一個好的示範是需要經過大量複雜精心準備的系統工程，是團隊合作的産物，是反複演練的産物。示範工作是有一定的内在規律的。

　　示範工作一般分為示範準備，示範，後續跟進三個環節，每個環節工作側重不同，但應該有一個總體示範工作組織策劃人。

　　示範策劃人未必一定就是示範者本人，但一定要是可以對項目可以長期跟蹤負責的人，而不是臨時的外部成員(例如從總部借調的咨詢顧問資源)。

　　很多時候總部顧問隻是策劃人達到示範目的可通過合理方式排程的資源，有了專人負責，示範過程才能有策劃，忙而不亂，進退有序。

　　很多項目跟進半年來，還沒有任何關于示範的策劃，一直要等到客戶通知才匆忙通知準備，一切都沒有計劃性，或者用客戶工作突發性強為借口回避自己工作不到位。

　　從這個角度出發，我個人認為示範策劃人應該是一名有經驗的商務人員，在整個售前項目生命周期内策劃一次或幾次(對于大型項目可能是必要的)成功的示範本來就是商務人員的本職工作。對于沒有經驗商務人員接手的項目，其直接主管上司需要負責，并同時傳授和指導相關操作經驗，以便下次其可以獨立操作。

　　一般售前示範工作準備包括以下幾個環節。

　　4.5.1 和客戶建立比較緊密的商務聯系

　　在進行示範工作之前，一般情況下應該建立了良好的商務工作基礎。

　　例如了解企業組織結構，決策模型，和決策層建立比較充分的聯系和良好的第一印象，為示範工作創造一個良好的認同氛圍，讓大家可以帶着認同和學習的心态去看示範。

　　也要了解是否有競争對手進行了示範，效果如何，使用者對哪些内容比較感興趣，哪些感覺不夠展開，以便我們進行針對性準備。

　　我們在商務上容易犯的一個錯誤是客戶經理不知道如何去打動使用者，面對使用者提出來的業務需求又無法滿足，隻好承諾先調研，後示範，通過這些工作驅動項目往有利于我們的方向進行。

　　其實客戶經理未必要有很好的技術背景，但在商言商，無論你賣什麼，讓客戶信任你所在公司才是商務工作的本質。客戶經理應該主動考慮我如何讓使用者建立對公司的信任，示範工作是整個信任工作中建立技術信任的一個環節。在此之前，客戶應該對客戶經理本人已經建立基本的認同，才能進行後續工作。

4.5.2 申請有能力的人進行業務調研

　　好的示範是針對重點(業務流)和難點(使用者極度關心的技術問題)示範，針對使用者的痛處示範，針對使用者的層次示範，而不是羅列我們功能的示範。

　　要做到這點，一定要安排時間做使用者的需求調研和業務分析，實際上大部分使用者也會主動要求我們做這個工作。

　　要得到能對示範起到指導作用的需求調研和業務分析，關鍵就在于示範策劃人一定要安排具有相應能力的人，或者調研者在有相應能力的人指導情況下去做業務調研。

　　一個能力或經驗不足的人調研結論對示範并沒有實際意義，這個時候使用者就會比較失望，花費了大量時間調研但居然示範内容針對性不強，這樣的示範效果可想而知。

　　是以成功示範前往往有一次比較到位的需求調研和業務分析過程。

　　業務調研有兩個可選擇的政策，如果客戶提供的時間很短，一定要協調派能力強的人，甚至就是示範者本人來調研；

　　如果時間比較充分，人力資源又比較緊張的情況下，可以派一般的技術工程師和實施工程師多花一點時間，按照公司調研套路和示範者要求将問題搞清楚，再讓示範者準備示範方案。

4.5.3 進行内部溝通

　　好的示範是團隊的産物，是群策群力的結晶。沒有人是全能和面面俱到的，每次成功的示範往往都經過了營銷人員，咨詢顧問、規劃經理、公司高管、還有實施項目經理的充分交流和讨論，形成對問題的共識後做到的。

　　一旦确定要給使用者進行示範，就有很多内部溝通工作要做，第一件事情是按公司流程申請到合适的資源進行示範準備，并安排足夠的時間準備，且保證客戶可以接受示範時間。

　　資源的協調和計劃的落實是示範策劃人的職責所在，這就是售前的項目管理重要内容。如果是賣産品，銷售經理能勝任，如果賣項目，就必須是懂項目管理和策劃的人才能勝任。

　　要協調的資源可能很多，包括示範人員，配置人員，開發人員，甚至高管。這些都必須在一個完整商務策劃中展現，形成一個攻擊波團，不要一下子來個示範，然後又沒有跟進工作安排，要在一個比較短的時間内給客戶一些組合拳有力地打動他們。

　　落實資源後示範策劃人要讓公司上下人員對示範思路和準備工作達成共識。

　　共識包括三個方面：

　　第一選擇怎樣的産品線或子產品組合，很多管理軟體系統是很複雜的，在短時間内全面示範是不現實的，是以一定要合理選擇産品線組合或功能子產品組合，争取在最短時間内讓使用者明白我們産品能力邊界。并準備對應産品線的示範思路和說辭，很多公司這些标準産品都有标準的示範套路可借鑒，适當調整即可。

　　第二建立對産品能力的信心，管理軟體實施成功率不高，很多客戶經理在銷售時心理是發毛的，底氣不足，這樣的狀态很難要求他充滿自信的示範，一旦在示範過程中遇到一些刁難，心理素質不過硬的人可能就提前崩潰。是以示範前要一定要讓示範者充分看到産品能力，建立共同的信心。

　　第三确定是否要協調資源快速開發某些功能點或者按照使用者資料建立示範環境。

　　大部分示範就是按照标準套路進行，畢竟很多企業存在共性的内容，并不需要一個企業準備一套東西，這樣成本很高。

　　但對于一些重要的項目，在示範前一定花費時間做定制配置，不做樣闆化的介紹。用使用者的資料，使用者的言語，使用者的報表示範，還是值得的。

　　定制配置的要害就是一定要在項目資金允許的情況下，公司決策層認可的情況下，規劃方向認同的情況下，開發資源接受的情況下(這些都内部溝通的内容)，示範出使用者最想看的内容，而不是我們最有心得的内容。

　　要達成這些共識，不經過大量溝通是不可能的，沒有溝通，很容易出現示範前後同一公司不同人員說法口徑不統一的情況，對項目并沒有好處。

4.6 售前示範工作應如何組織？(下)

4.6.1 編制示範方案

　　内部溝通完成，達成共識後就可以進行示範準備，示範準備這個環節就是要按照共識來準備一份示範方案。

　　有了示範方案，示範時才能心中有數，讓别人提意見時也有了一個參考的依據，今後示範方案也可以作為公司知識積累，和業務持續改進基礎。

　　完整的示範方案應包括三個部分：

　　第一是示範産品線和其它軟體環境，包括作業系統資料庫和示範時要調用的其它應用程式或各種資源(例如動畫，動态庫等等)；

　　第二是示範的思路，示範一定有一個整體思路貫穿，這個思路根據演講的内容、聽衆的特點和演講的環境而且盡可能按照企業業務準備，而且簡明扼要說明了自己是如何按照業務思路連串軟體功能子產品達到支撐業務子產品的目的。

　　示範思路要考慮你想告訴聽衆什麼？先要确定演講的目的。準備工作的每一個步驟始終要圍繞這個目的進行。隻有這樣，才能保證你的示範方案有針對性且高效率。

　　第三是演講詞和配套操作順序，要寫清楚什麼操作提供怎樣的說辭，操作的時間在哪裡，哪些需要提前操作或打開界面，提高示範效率，哪些操作可能需要較長時間等待(例如彙總)，需要準備更充分的說辭，操作進入界面和資料位置，哪些操作在示範時不能做，這些都要逐段落實寫明。

　　一般認真準備了詳細的示範方案，現場示範就不會失去思路，操作也不會零亂，往往可以達到很好的效果。

　　示範方案的準備應該是公司級的行為，經過長期積累完善的示範方案就是一份積累了全公司業務經驗和産品功能的解決方案，可以成為實施标準配置，産品規劃需求和理念來源(準備售前示範過程也經常可以發現軟體不足和可以改進的地方)；測試的标準業務測試大綱，教育訓練的标準軟體平台，咨詢顧問部也可以按照這個示範套路定制解決方案，形成幾個精練友好的業務解決方案範本。

　　這樣的話軟體公司可以通過示範方案把高管到基層員工，從外部業務部門到内部業務部門，從銷售前期到實施後期，通過這個售前示範技術準備活動達成了高度統一，大家的經驗和知識就有了一個共同的積累平台。

4.6.2 反複排練

　　如何在現場進行一個好的示範，我的建議隻有一條：練習，練習，再練習！

　　隻有這一條沒有别的捷徑。

　　成功的示範無論示範者經過多少實戰，必要的針對性練習還是非常重要的。

　　如果是理念演講為主，沒有太多的操作，排練1~2次，基本效果是有保障的，如果是産品示範，特别是需要多人配合的話，至少要練習3輪以上。

　　如果是産品示範經驗少于10次的人，建議至少在内部演練5次以上。

　　建議：為每小時的演講作10小時的準備，随着你的經驗日益豐富，你會發現所需準備時間會逐漸減少。

　　試講次數越多越好。如果你對自己有信心，聽衆就會相信你。

　　演講的時間包括使用視聽工具和回答聽衆提問的時間，是以試講中要留出這些時間。

　　每次試講都要逐漸脫離講稿。

　　試講過程可以對着鏡子練習，而且盡量大聲。

　　試講練習到一定時間可以安排錄音或旁聽，這樣可以發現很多自我感覺良好下無法發現的問題。

　　排練是一定要确認自己對所要介紹PPT的内容或者示範操作内容非常了解，起碼要做到看到一頁(步)就能想到其後三頁(步)所要示範的内容。

　　内部演練一定要有2個以上比較有經驗的人站在使用者角度上評點，讓他們充分提出改進意見，根據意見馬上調整。

　　内部評點還有一個工作是模拟真實使用者問題刁難示範者，對一些關鍵問題提前準備說辭也是排練時要完成的工作。

　　怎麼挑毛病呢？基本上你在講時下面坐的想打瞌睡這種示範肯定是失敗。坐在下面眼睛還能睜着，感覺你講的有一二點收獲，這種排練就比較有感覺了。

　　如果示範是定制配置，更由于可能存在新開發功能，産品穩定性還沒有完整測試，此時示範前一定要反複進行操作排練測試，確定不出意外。

内部排練有兩個經驗：第一經過排練一定比沒有經過排練強；第二排練過的人現場講演效果一般比練習效果強，沒有排練過的人現場講演效果一般比練習效果差。

　　一個人經過反複排練以後往往有種壓抑的欲望需要渲洩，把這種渲洩的欲望放到現場，效果一般都不錯。而不練習的人一到現場就畏懼感加重，最後也無法正常發揮。

　　如果一些相對示範經驗比較豐富的人都認為這個示範方案有說服力，示範效果沒有大的問題，對對手、企業各種情況都進行針對性預演答辯通過，就可以準備上戰場。

　　4.6.3 約好示範時機和使用者

　　産品示範是目的性極強的工作，就是要通過示範打動使用者，促成其選擇或實施我們的軟體。

　　産品示範一般也要經過大量時間準備，成本很高。如果參加示範的人不到位，示範再好成效也不大，将不得不再次安排示範，這種反複将導緻工作成本急劇增加，反複示範也未必也能保證示範資源和效果。

　　是以産品示範對象一般要追求參加人盡可能多，讓對軟體選型有影響的人員盡量參加，特别是技術類型人員，争取都能參加。

　　是以示範前示範策劃人一定要和使用者詳細約定，在商務工作做到一定基礎之上後，利用互相的信任關系使得使用者願意配合，調動一切應該來也可以來的人員參加産品示範會，保證示範的效果。

　　要做到這一點，就是在确定公司可安排的示範資源後，立即和使用者做大量溝通，确定應參加人員，可參加人員，比較合适的時間段，場地和裝置，在這些條件都具備情況下安排示範。

　　如果示範條件不具備，甯可和使用者反複解釋，也不輕易安排示範，示範講得就是“一擊必中”，如果沒有這個效果，就不如多花一些時間在預約工作上。

4.7 如何準備标準示範套路？(上)

4.7.1 售前示範工作要不要标準化？

　　有人認為示範時企業實際情況千變萬化，難有一定之規，自然也很難準備标準化的示範套路，而且企業業務情況不同，用标準化的套路去應對效果可能達不到，應該采取定制示範。

　　這個說法看起來有道理，但實際上無法操作，定制示範的前提是比較詳細的需求調研，如果每個項目都做如此投入的話，供應商根本無能力負擔，而且需求調研即使很到位也未必能保證産品示範就能準備到位。

　　其次定制示範對示範者個人能力要求很高，一個企業不可能大量存在這種強人能人，定制示範要麼人力資源響應不到位，隻能用比較低水準人員去示範，要麼示範準備周期過長，這兩種情況都是無法接受的。

　　從另外一個角度看，企業業務雖然千差萬别，但是以機械行業為例，生産模式也不過是單件、多品種小批量、大批量三類，設計模式往往也就是新産品研發、變型設計、系列化設計幾種常見類型，完全可以用統一的平台來支援，相應示範套路也可以針對不同企業類型标準化。可以說業務是标準化的，定制一般也不過是資料是個性化的。

　　如果精心準備了完全按照實際典型企業業務運作的标準化示範套路有很多好處：

　　可以結合準備标準化示範套路工作将一個公司在不同行業企業業務經驗有效總結和抽象出來，形成指導産品發展的業務規劃模型。

　　對營銷工作而言，我們業内的營銷人員是不會去總結研究産品細節的，也不太熟悉企業的運做模式，這樣推銷管理軟體時有很多困難。一旦公司層面準備一個條理分明，思路清晰，亮點突出，操作固定的示範套路，營銷人員将大大降低對公司産品學習和掌握的成本，并能夠培養出一批能夠按照公司要求介紹産品特色的人員，解決售前示範資源瓶頸問題。

　　售前示範準備必須根據企業業務走。示範套路内容應是從實際實施工作中總結出來的，一般能在企業實施得很好的業務示範效果也不錯，而且可以代表産品目前可實施的最高水準。那麼對實施工作而言，這樣的示範套路對實施人員打開思路，提高配置水準有很強的導向和示範作用。

　　對産品規劃工作而言，通過精心準備業務示範套路時就容易發現一般軟體産品不是功能過少，而是很難連續串起來支撐某一方面的完整的業務。在售前示範準備過程中由于按照完整企業内在業務邏輯準備，就可以提前發現産品在規劃方面的問題，可以及時和不斷改進我們産品中一些不足。

　　對産品測試工作而言，測試也可以按照售前示範套路準備實際業務測試大綱，提高功能測試外的業務測試覆寫率，可以解決很多實施人員抱怨測試人員不了解實際業務，測試工作和實際業務脫節的問題，而且可以在标準示範套路基礎上編制自動化測試腳本。

　　對于咨詢顧問部而言，定制解決方案時候可以按照标準示範套路支援的業務模式來準備，這樣售前方案和售後實施可以極大保持思路一緻性，不至于售前一套說法，售後一套說法，使用者感覺上當受騙。

　　對教育訓練工作而言，企業所有教育訓練也應圍繞标準示範套路，商務人員要能自如按照标準套路操作和示範，實施人員要能結合業務調研完成标準套路配置、實施和教育訓練，測試人員要能了解示範套路中展現企業業務邏輯，發現軟體不友好的地方，規劃人員可以通過示範套路判斷産品對企業業務模型支援是否足夠，應如何改進。這樣教育訓練平台就是全公司統一的。

　　這樣的話一個公司從高管到基層員工，從外部業務部門到内部業務部門，從銷售前期到實施後期，通過這個售前示範标準套路準備活動達成了高度統一，大家的經驗和知識就有了一個共同的積累平台，企業對使用者就真正具備了廣泛的一緻性。

　　有了這樣的平台企業才可以真正積累公司層面的知識管理，避免大量的發散性行為。很多公司并沒有認識到一個可教育訓練可操作的示範平台比大量繁複的文檔更有利于工作，更有利于教育訓練，更有利于産品進步，更有利于公司知識積累。

　　很多公司的政策是做産品，既然是産品就應該可以形成相對固定的套路去服務不同類型的客戶，也就意味着公司可以形成相對固化的套路，這個對公司形成統一的認識非常重要，公司往往不是缺想法，而是這些想法不系統，不深入，更多的是靈光一現，不能積累和繼承。

　　個人以為标準售前示範套路準備意義重大，需要一步步通過示範工作去強化公司層面的工作導向，将其意義最大化，效益最大化，工作協同價值最大化，積累成本最小化，專人專崗長期制度化負責。

4.8 如何準備标準示範套路？(下)(

4.8.1 如何準備标準示範？

　　準備标準化示範并不難，不同公司産品不一樣，示範套路和側重也不會一樣，但都可考慮按照以下思路進行。

　　第一要成立專人負責的崗位和相應制度，否則能準備一次不錯的示範，但總不能随着産品發展和實施業務創新而不斷更新示範套路。一般這個工作可以讓咨詢顧問兼任。

　　第二要清楚示範給誰看，不同人員關心重點不太一樣，是以建立可以準備側重政府上司，專家教授，企業高管，技術人員四個層面的示範體系。

　　第三要讓公司能力最強的人參與到标準示範套路中來，直接準備示範套路的人應該是對企業業務了解，配置水準最高的人，這樣才能最快有效把公司知識積累到标準示範套路中，并定期請規劃、開發、實施、測試、銷售、咨詢各方面精英人員參加内部組織的示範套路評估，提出基于各類業務的改進要求，不斷完善和改進産品功能和示範套路。

　　第四要形成和标準示範套路配套的标準示範方案和常見問題解答指南，示範方案要口語化，強調可操作性，類似于表演時的劇本。

　　第五要讓示範準備工作和規劃、開發、實施、測試、銷售、咨詢各個部門教育訓練工作主動銜接起來，定期根據标準示範套路進行不同側重點的部門教育訓練，快速把能力擴散出去。

　　第六要讓咨詢顧問和實施顧問根據标準套路準備标準解決方案和實施方案，形成一緻性。

　　個人以為完成以上六個方面的工作才是一個完整有品質可結束的标準示範工作。

　　4.8.2 不斷結合實際情況總結示範套路

　　實際進行示範的時候示範者臨場自由發揮成分還比較多，示範完全不發揮不可能。

　　首先應要求示範者能按照标準示範套路照本宣科進行，這樣可以保證最基本示範品質，然後在大量實際練習中把産品功能和企業業務能夠融會貫通，最後才能夠在現場高度自由發揮。這三個階段不能逾越，否則現場一人一個樣，總結标準套路的工作就會失去意義。

　　既然有發揮就有好也有不好，是以公司還必須總結每次實際項目，特别是售前示範效果，無論成敗總結得失，并将意見回報到示範準備部門，持續完善，持續改進，每天都能進步1%的對手才是最可怕的對手。

　　一般回報意見可以從以下幾個方面改進和考慮：

　　如果是功能上對手具有我們沒有的特色，應回報給産品規劃部門跟蹤業務規劃改進；

　　如果是操作過程示範層次不清晰，不連貫，應考慮如何結合業務形成更有效示範方式和表達語言；

　　如果是産品性能不足，導緻示範時拖泥帶水，應回報給測試部門作為缺陷加以改進；

　　如果是人員表達不到位，導緻産品特色沒有清楚講解出來，應考慮逐漸加強教育訓練，加快知識擴散周期。

4.9 如何進行現場示範(一)(

4.9.1 建立示範心态：

　　作為一個示範者，要有一個平和，自信，積極的心态。相信自己可以取得成功和得到使用者的認可。

　　好的示範心态天線在自我定位，重視和敢于挑戰對手，臨場發揮三個方面。

　　好的示範心态下示範者是不會心浮氣躁，上來就攻擊對手，指望一棍子打死别人，搞定客戶；

　　好的示範心态下示範者不會看到強手就害怕發虛，看見對手實力不強就輕視，是遇弱我強，遇強更強，勇于面對壓力和挑戰，正常甚至超常發揮；

　　好的示範心态下示範者在示範過程中不會遇到一點挫折就心灰意冷，會做好多次反複交流的準備，這個多次反複交流就是客戶對你還有興趣的一種表現；

　　好的示範心态下示範者對自己精心準備的套路和功能也不會過于自信，用一種平和的語調和對事業執作的激情感染使用者，打動使用者，讓客戶相信我們是一幫想做事，肯做事，會做事的人，示範時無論得分失分都不要高調，肚子沒有貨的人才喜歡炫耀；

　　好的示範心态下示範者在示範過程遇到裝置和軟體操作意外一定不會緊張，緊張就讓别人看笑話。即使是出現很嚴重地低級軟體錯誤，也會不慌不忙重新開始，不需要做太多沒有必要的解釋，一定要解釋也應該是幽默的方式。用自己的從容鎮定感染使用者，建立使用者對自己的信任，對公司的信心。

　　根據個人經驗一個好的心态示範者往往是哪些對自己的公司，對自己的團隊，對自己的産品，對自己的能力有充分自信的人才能上陣，不要用那種對公司沒有認同，對産品表示懷疑的人去示範，他們在示範過程中抗擊幹擾和打擊的能力往往不好。

　　很多人在第一次示範或者頭幾次示範時很難克服一種恐懼心理，這種心理誘因很多，但往往是越害怕越想，越想越害怕，還沒有開始講，自己就先崩潰了。

　　對于恐懼心理最有效的方法就是轉移注意力和積極的心理暗示。把注意力集中在示範内容本身上，而不是别人對于你示範品質的評價上，并不斷提醒自己一定可以做到比對手更好。

　　這裡有一些标準放松方法可以提供給大家使用：

　　對着鏡子試講，想象你面前是你的聽衆。

　　可能的話，在實際演講會場進行試講。

　　確定你一直可以清楚地看到你的筆記或小字條，讓自己覺得就算是忘詞也可以看到下一步該講什麼。

　　深呼吸，并保持微笑。

4.9.2 準備示範環境和檢查裝置

　　準備環境事先可考慮以下要點：

　　後勤方面：誰在組織者這次演講？(了解詳細情況)

　　交通如何安排？(計劃并檢查旅行安排)

　　會    場：會場大小和形狀如何？(向組織者索取一份樓面布置圖)

　　可用那些裝置？(弄清你要用什麼裝置，避免用不熟悉的裝置)

　　時 間 表：誰在你之前發言？(弄清你是否有機會聽他們發言)

　　誰将把你介紹給聽衆？(一定要事先向介紹人做簡要介紹)

　　實地檢查：在示範前最好能夠提前到示範場地檢查，并提前調試裝置。

　　場地和裝置檢查一般要注意這麼幾個環節，示範場地大小，座位分布，光線明亮度，由此确定自己示範時應站的方位和投影的方位。

　　如果有擴音系統要提前測試一下，确定自己發音大小。

　　測試投影系統和網絡連線是否正常，電源開關是否可用，線路長度是否足夠，如果有問題應提前解決。

　　如果現場有自己不熟悉的裝置，盡量不要在示範時使用，或者提前請人調整好。

　　演講位置光線是否充足，能友善為其它人所看到，沒有視線阻擋物。必要時要調整座位分布以有利于示範進行。

　　如果是有重要上司和專家檢查的大型彙報示範還要注意這麼幾個環節：

　　給上司和專家設定貴賓座和領座牌；

　　在示範場地内外布置歡迎牌和智語；

　　在演講桌上布置鮮花等修飾品，展現專業和隆重程度；

　　在主要就坐位提前放置飲料和相關資料，并且注意資料飲料排放前後左右一字對齊。

4.10 如何進行現場示範(二)(

4.10.1 示範時要注意的一些細節

　　4.10.1.1 如何注意示範姿勢

　　示範站位也有技巧，一定要正面面對大家，盡量看到最多的人。

　　如果圍着一個圓桌，你應該靠在最前面，你能看到所有人，但是你應該站在主要人物的對面。

　　聽衆的數量對你組織演講的方法有很大影響。聽衆人數少，你和聽衆就有充分機會進行交流。你可以邊演講邊回答聽衆提問，也可以就有關問題征求聽衆的意見。聽衆人數多，你與聽衆的溝通隻可能以單向交流為主，發言方式就應完全不同。

　　有時候示範隻來了二三個人，不一定要大張齊鼓的講，可以考慮一下，是不是大家坐在一個距離比較近的方式去溝通會更好一些。

　　人比較多的時候站起着講，人比較少的時候坐着講，站起來講的比較容易觀察每個人的反應。

　　如果是選擇站立姿勢身體站直，兩腳稍稍分開，體重均勻地分布在兩腳上，手臂在身體兩側自然下垂。這是最無明确表态的姿勢，是中性的身體語言。如果你了解不同姿勢的含義，你就可以在此基礎上創造不同的印象。例如，身體稍微前傾，顯得積極友好——好像你在邀請、鼓勵聽衆。反之，身體稍作後傾，就顯得消極，還可能有點挑釁意味。

　　示範過程中可以恰當使用手勢，一般人使用手勢最大問題是有一些不好習慣性動作會出現，解決這種不良動作最有效方法是看示範過程錄象。

　　4.10.1.2 要不要派發名片

　　示範前可以不派名片，要派就全部要派。

　　而且派發時由上司沿一定順序分發，不應跳過某人再分發，也不應先發普通人再發上司。

　　上司沒有入場之前可以先給其它人發，上司入場後根據情況決定是否分發名片。

4.10.1.3 示範前等待時間怎麼辦？

　　示範前等待時間是很尴尬的時間，是以一般示範者可以請其它人去檢查裝置，自己找一個安靜地方考慮思路，等到時間差不多時再入場，避免這段真空時間。

　　如果使用者沒有及時到場，主要示範者要展現一定專家身份，可以安靜等待，人數不多時可以适當交流。這個時候商務人員可以适當活躍氣氛，讓大家不覺得等待時間過于尴尬。

　　4.10.1.4 示範着裝

　　示範衣服最好是正式的，特别是正式示範，而且所有人着裝應該統一，最好是西裝。

　　西裝最好是一個顔色，灰色或者藍色，這是标準職業裝。

　　4.10.1.5 關閉手機

　　示範期間一定要保證無手機鈴聲，最好的方法是直接關機。是以應提前告訴你的同僚你的工作時間，防止幹擾。

　　如果确實有緊急事情不能關機，請其它同僚示範時間内代管。

　　4.10.2 演講開始時緊張什麼辦？

　　即使是很有經驗的演講者，每次開始演講的時候都有一些緊張，而且在演講的時候必要的緊張是需要的。必要的緊張會使人注意力高度集中，大腦在快速緊張地思考，進而可以更好的把演講思路搜尋出來，并根據使用者反應進行内容和言語上的調整。

　　但是有的演講者一緊張就忘詞，結果開始時就有一些不流暢，結果越來越緊張。這種情況就需要大量的進行示範練習和試講。練習和試講可以消除演講者由于對内容不熟悉造成的緊張，而且大量的試講會累積一個人的發表欲望，經過多次準備的人會逐漸對自己演講建立一些信心，并有發言的欲望，整個過程就容易有激情，不那麼畏懼。

　　很多時候緊張就是因為對自己講演的内容不熟悉，沒有信心，導緻擔心自己發揮不正常影響整個計劃，越怕鬼越鬧鬼。

　　此外演講開頭人總是有些緊張的，這個時候演講者可以多注意觀察會場，通過目光交流發現有興趣的使用者，看到使用者有興趣了，自己就逐漸有一些信心，慢慢就不緊張了。

　　此外設計一個輕快有趣的開場白也是一個有效的手段，如果在一開始使用者對你的開場白就有了興趣或者發出了笑聲，這個時候演講者一般都可以松弛下來，進入一種良性的演講狀态。

　　最後注意語速，用中等偏慢的語速介紹内容，也是逐漸釋放緊張的一種方式。很多人一緊張，講話就會無意識加快，一快聽衆就更不容易明白，不明白就沒有興趣，這種表現會回報到演講者身上，進而形成演講者的焦慮，焦慮的演講者這個時候往往不自覺越講越快，這個過程陷入高度緊張惡性循環不能自拔。

4.11 如何進行現場示範(三)(

4.11.1 示範過程中聽衆感覺厭煩或注意力不集中怎麼辦？

　　很多時候即使你做了精心準備，到了實際上陣卻發現好象感興趣的聽衆并不多，這個時候示範者往往比較受打擊，有的人就比較緊張，覺得使用者對自己的内容不感興趣，腦袋一緊張就不靈光，能把事先準備的内容講完就一頭大汗。

　　一旦發現使用者對内容不感興趣，演講者要緊急判斷是自己準備的内容對使用者的針對性不夠還是演講時間安排在一個比較容易疲憊的時間段，如果是前者演講者要立即改變演講的話題，逐漸将内容往使用者感興趣的方向上引，如果是後者演講者就要發揮語言技巧，增加互動，提供一些幽默的段子調動大家的興趣。

　　本人曾經參加了一次國産軟體鑒定會，來的都是企業的上司和資訊化負責人，整個上午上司和專家用學術性語言做了冗長的彙報，上午的會議一直12點半才開始吃飯，到了下午1點半就要開始我們的産品介紹會，這時來參加會議的人幾乎全部都昏昏欲睡，我們前一個介紹人員又座在椅子上講了半個小時的理念，一看大家幾乎都要睡了，也很機警，請我上來講。

　　我上來以後并沒有就坐，而是站在離大家比較近的地方開始，第一句話就是說：“各位上午開了一上午的會，肯定很疲勞了，我呢想結合我們實施工作講一些比較實際的東西，談談我實施工作中一些小故事”。

　　這裡我就使用了兩個技巧，第一是站立，當你近距離站立在别人面前的時候，由于别人是坐着，出于禮貌就不得不擡頭看你，一擡頭精神就不一樣了，一勾頭就肯定繼續睡下去了；第二一直在聽各種理念，肯定很厭煩，我主動說将一些實際的故事，大家就有了一些興趣，有了興趣，自然就容易進入聽演講的狀态。

　　在後面的演講中我就放棄了用技術語言介紹的原計劃，全部用一個又一個實施過程中的酸甜苦辣的小故事和使用者交流，在使用者一陣陣笑聲中交流就取得很好的效果，到了演講結束，使用者紛紛主動索要我們的名片。

　　要避免出現使用者厭煩的局面，第一在示範準備前弄清楚對象，確定你所講的内容切題且适合他們特點，不然就砍掉。

　　第二演講者整個演講過程要有激情，很多時候使用者并沒有記住太多内容，但記住了那個演講很不錯的人，和那個人所代表的公司。這個時候聽衆記住的可能隻是那個演講者的精神面貌狀态而已。

　　你積極的态度、活力和熱情将增強你演講的說服力。演講的具體内容或許會被忘記，然而你的态度、活力和激情将深深地印在聽衆的腦海中。

　　第三演講過程中語言要抑揚頓挫，千萬别隻有一個語調，并和聽衆保持目光接觸，目光接觸要注意随時看到整個會場所有人員，并保持微笑，讓他們感覺到你很重視他的表情回報。很多操作性示範者為了確定自己操作不失誤，往往花費大量時間看電腦進行操作，這是不對的，整個演講過程中聽衆注意的中心隻能是演講者本人，不是軟體操作，隻有當演講者覺得使用者需要看操作的時候才主動引導使用者注意觀看軟體操作。特别是在一些需要大量時間操作的環節，如果将注意力集中在操作上，會讓使用者産生軟體很慢的感覺，其實在實際操作中速度并不慢，但由于在這個特定的場合使用者往往會形成這樣一種心理印象。

　　第四示範過程中示範者不要經常無意識挪動滑鼠，來回拖動界面，分散使用者注意力。界面不應反複切換，應該一個界面一個界面把軟體思路和業務流程配合關系講透，再切換下一個界面或PPT。

　　第五控制一次示範的時間。成年人集中注意力的時間限度約為45分鐘。在這段時間内，他們隻能吸收演講内容中的三分之一，最多七個概念。将演講要點限制于三到四個，并在演講開始與演講中加以強調，最後再加以重複。盡量用一個有吸引力的标題來概括你的演講，但不要太概括或太含糊。

4.11.2 示範過程氣氛不積極怎麼辦？

　　示範者發現聽衆精神狀态不夠好的時候，首先要把自己精神狀态調整過來，不要受影響。我們許多人是很容易受打擊的，很容易受環境的影響。一定把這個勢氣調動起來。示範者有了精神狀态就有激情，有了激情就會感染别人，哪怕你講的不好，别人也認為這是個想做事的人，他對你的演講也會一定程度上認可。

　　此外為什麼示範效果不好呢？讓大家跟我互動的時候，示範者經常會問一些問題，很多問題并不需要聽衆回答，而是讓聽衆進入思考，讓聽衆跟着示範者思路去思考：“我們企業裡裡有沒有這個問題呢？這個事有沒有解決呢？”

　　然後示範者再告訴聽衆怎麼做，是以示範者不要光談功能，談概念，而是先談企業的常見問題是什麼，原因是什麼，如果解決了好處是什麼，然後告訴聽衆怎麼做，這時聽衆就會有興趣。要不斷地問問題調動他，然後不斷的講好處，你的業務線自然就串起來了，因為你是為了一個好處，解決一個問題，又帶一個問題，又解決了。這就叫完整的解決方案。

　　在成功的示範裡，好處太多就沒有重點，一般隻需要歸納出三個好處即可，多了記不住。

　　示範時，應該讓觀衆有一種參與感，就象講相聲一個吹、一個捧一樣。不要一個人唱戲。

　　應該适當地在示範時向觀衆提一些問題，比如企業的産品、任務情況，對軟體的了解情況，是否使用過相關軟體等。

　　也可以順便拉幾句家常，使氣氛活躍起來。講某些概念，比如對象、配置、參數化，要把概念講通俗一些，使觀衆能夠聽懂。

4.12 如何進行現場示範(四)(

4.12.1 投影儀連不上什麼辦

　　在做示範之前，一定要檢查好硬體設施。但即使這樣也會出現無法提前檢查或者意外發現示範廳裡的投影儀接不到筆記本上的情況。

　　此時關鍵是不能着急和冷場。在示範時應準備一些公司的簡介和客戶關心資訊，并進行口頭介紹，将時間拖到投影儀接好。

　　然後在随後正式介紹中弱化這一部分的介紹，将耽誤的時間趕回來。

　　本人就曾經遇到這麼一次情況，投影儀突然罷工，結果就按照業務思路不慌不忙一口氣在沒有電腦情況下做了一個小時交流，客戶聽得很深入，一個小時後投影儀修複，再看軟體，客戶了解得很快，對我們産品很認可。

　　4.12.2 示範中客戶的主要負責人總接電話怎麼辦？

　　上司接電話，一定要等，人少時直接停下來表示尊重，或者繼續用比較慢的速度講，然後等上司停下來說“某總，剛才我給大家介紹了一下什麼内容，”快速補過，給足面子又不冷場。

　　4.12.3 多個公司連續示範，你排在後面，此時客戶已經開始聽覺疲勞怎麼辦？

　　演講很多時候不是你最先講，那麼别人講得好的内容要能立即化入你的過程中，巧妙利用别人烘托自己，也無形中讓客戶将别人亮點記到你的頭上。

　　别人講得大家昏昏欲睡時，可以先準備一個笑話和有趣的PPT給大家刺激一下，用一個輕松的心态進入交流的氛圍。

　　有一個有趣的開場白是很不錯的選擇，不過如果講一個大家都知道的笑話或者和演講内容沒有關系的笑話卻不是一個好的主意。

　4.12.4 演講過程準備好的配置突然當機或者不能出來怎麼辦？

　　第一不要緊張，繼續進行你的陳述，就當操作是正常的。

　　第二馬上同時手工調整，如果正常，可以繼續說剛才我介紹的“***功能，現在大家可以看一下”

　　第三如果實在問題嚴重，無法快速解決，解釋一下原因，例如機器中毒了，很多突發問題。是以計算機安全很重要。

　　第四自我解嘲，進入下一個功能介紹，還是不當回事。你越緊張使用者越懷疑。

　　打動使用者更多的是你陳述，而不是一時半會無法領會的界面和操作，有點問題你不在乎，使用者也就不會認為是大問題，至少你的鎮靜可以為你撈回印象分

　　第五強調一下筆記本機器配置不好，或者裝了太多系統，我經常拿着3年前本子做示範，速度慢一點使用者反而了解。

　　4.12.5 示範時有人打叉怎麼辦？

　　當你在示範時，頻頻有人打叉，問出各種各樣的問題，有可能是某人非常迫切希望你跳躍性介紹他關心的内容。

　　也有可能是提出對示範者非常不利的問題，甚至是攻擊的問題。

　　是以在示範軟體時，要注意重點突出，不重要的例子可以根據觀衆的要求适當調整或者不示範。不管何種情況，您可以這樣回答“請允許我花20分鐘先介紹一下軟體的基本功能，再回答您關心的問題”來保持正常的示範順序。

　　對于觀衆提出的問題，可以表示贊許“您這個問題提得很好，我們開目軟體已經考慮到了”，“您的建議非常好，我會向公司上司彙報，考慮您的建議”，“您可能有些小小的誤會，其實這個功能是有的”。

　　對于确實是刁難性的問題，可以說“關于這方面的問題，我們可以在示範完以後再詳細讨論”，“這方面的情況我不太清楚”，“這方面您是專家”，“軟體的優勢不是絕對的，有些軟體确實在某些功能上比我們友善一點，但在與***有關的主要功能上，我們是非常友善的”等，再約私下進行讨論。

　　對于一些刁難的人，大多數情況他是想表現一下自己，多奉承一下，讓他獲得心理上的滿足即可，沒有必要與之争論太多。當然，對于少數确實是故意為難的人，也可以明确作出回答，争取大多數人的支援。對于關鍵的決策人，要始終保持溫和的态度。

　　4.12.6 示範時使用者臨時表示時間不夠怎麼辦？

　　“我沒有時間，你不用示範了，我們這兒對軟體熟悉的人很多，隻要留套軟體，留份資料，我們看一看就行了”

　　可以回答“我的示範很快，不會占用您太多的時間”，“我們這個軟體與其他軟體相比，有很多優點，值得您花一些時間看一下”，“我可以簡單地把功能和特點示範一下，相信您會大開眼界的”。

　　不過，給上司留一份詳細的資料的十分必要的。

4.13 如何進行現場示範(五)(

4.13.1 示範過程使用者要求改變主題怎麼辦？

　　示範者在示範的時候一定要有激情，有好的狀态，但是千萬别太自信，要能應變。

　　萬一聽衆聽着聽着說：“這些東西我不想聽，你直接講是什麼東西”，突然來這麼一下怎麼辦？可能聽衆裡就有對手的釘子，故意難看你一下。

　　這種事情無法避免，隻能預防，首先在排練的時候，自己人要給自己人發難，在内部排練時盡量模拟真實極端情況。應變也是練出來，多經過幾次實際示範也會積累很多經驗。

　　真正有經驗的示範者，在一個示範方案中可以從幾個地方作為開始，多設計幾條路，萬一客戶不願意聽還可以從其關心的點切入，等其接受了還是逐漸展開我們完整的解決方案思路。

　　4.13.2 示範過程如何答辯？

　　一般軟體産品示範完成後使用者會主動安排，或者臨時提出一些問題，這個時候就比較考驗示範者的快速反應能力，也能展現一個公司的綜合實力。

　　特别是在一些競争性項目上部分聽衆會帶有挑釁的口氣向你提出責問，這個時候如何有效應對，從容自如完成答辯也是非常重要的示範得分環節。

　　本人的經驗在示範過程中遇到疑問甚至是刁難都是正常的，不要畏懼，把這個工作當作示範工作中的一種常态。

　　使用者問得問題越多，是對你的産品有興趣的一種表現，大家應該高興的去解答問題，而且這個解答過程中無論使用者處于什麼心态，我們要保持微笑和認真聆聽的态度。

針對答辯有幾個重要的技巧：

　　第一對于一些比較複雜的問題，或者一個使用者提出了多個問題，首先不要急于解答，要先用筆快速記下來，邊記邊尋求最合理的解釋，也可以防止遺漏使用者的問題，以免使用者發現你遺漏後再提一次，感覺你在回避問題，我們畢竟不是外交場合，是技術交流，技術問題不應回避。

　　第二在回答問題前，可以把一些複雜問題或多個問題複述一遍，即請使用者确認，又為自己争取思考的時間，但對于有些很簡單或者明确的問題，要立即肯定積極自信的回答，例如使用者在示範時沒有注意到他關心的一個内容，這個功能有的确是軟體正常功能，我們可能就沒有重點介紹，這個時候要立即和肯定告訴他，這方面我們沒有問題，不能猶豫磨蹭。

　　第三回答問題反應要快，針對問題本身不做發揮，言簡意赅。一般答辯時間不會很長，時間寶貴，不要對于某一個問題長篇大論，用結構化思路或回答套路，快速扼要讓使用者聽到答複，并禮貌性問一問不知道這樣回複您覺得滿不滿意之類結束。如果對一個問題解釋過多，可能也不是一下子能解釋清楚的，反而會越解釋越懷疑，越覺得累。

　　第四有些使用者問的問題可能帶有惡意，或者的确是軟體的軟肋，此時不應回避，要迎着問題解答，可以通過介紹我們正在開發的産品或正在規劃的思路來肯定性回答，越是自己不強的内容，越是要在示範時講透我們的業務思路，反而使用者會少在答辯時提問題，越是在示範時回避越容易被提出來并刁難。

　　而且這個時候我們可以用：“你這個問題很好；你說出了很多使用者關心的問題；你這個問題的确很有難度，看來您對***很有了解？”之類開頭緩和氣氛，拉進距離，增加思考的時間。

　　第五如果企業内部有我們的支援者，不仿先設計一些有利于我們的問題讓他們提向我們和競争對手，這樣也是一個有力的武器。

　　最後對于一些純技術性問題可以要求使用者會後進一步單獨交流，避免出現不得不花費大量時間解釋一些大部分人不感興趣的問題。

　　如果有條件，是多人參加示範的話，可以就個人專長對問題回答提前做一分工，準備一些可能要回答問題清單并提前設計回複，這樣在示範現場時也可以互相配合，快速有序完成任務。

　　答辯考核的是一個公司和個人的綜合能力，是以真正答辯的精髓不在現場快速反應，而在平時對企業管理業務、産品規劃、業務知識、實施理念多個環節的知識積累，答辯優秀的人往往也是在知識面和深度上下工夫最多的人，這才是成功答辯的秘訣。

4.14 如何組織示範後工作

4.14.1 争取約見重要上司

　　示範結束後，如果有機會示範團隊一定要和參加示範主要上司，甚至是沒有參加的重要上司。

　　不要放過這個有利的時機和重要上司溝通的機會，建立印象分，在示範過程中可能更多用業務的思維講産品技術能力，但和上司溝通的時候更多的用管理的思維講産品技術能力，這兩種溝通往往不能在一次示範中兼顧到位，但可以主動創造機會在後續活動中實作。

　　當然和重要上司見面機會并非可以有軟體供應商控制，但和重要上司溝通的工作意識随時保留，飯桌上就是很好的場合。

　　4.14.2 提供備忘，後續跟進

　　示範無論實際效果如何，一定要留專業的備忘錄，一定要和使用者約定後續工作計劃，并按照備忘的承諾推進後續工作。

　　是以重要項目現場示範過程中應安排專人記錄，将示範過程和過程中大家提出的問題和回複逐一記錄，對于一些暫時無法清楚解釋的問題約定後續解釋工作安排。這種專業備忘整理能力是很能反映一個公司職業能力和職業水準的。

　　商務工作在示範達到目的的情況下，就可以更加良性的運做，包括馬上根據這次情況和對手回報準備解決方案，公司考察，使用者考察，選型方案，招投标方案和答标示範等等。

　　在沒有達到目的的情況下，更要進行權衡，是否進一步加大投入，扭轉局勢，還是無力回天，集中精力做其它項目。

　　4.14.3 總結示範得失，形成回報文檔

　　示範結束後，要針對示範實際效果形成回報評估文檔，針對示範者個人能力，針對标準套路組織水準，針對産品技術能力結合競争對手和使用者意見形成回報意見，這将形成有力的産品規劃動力和示範準備改進動力。

　　很多項目在一開始接觸時就可以發現一些現有産品無法滿足的部門，如果在售前系統示範後使用者還堅持要實作的功能，如果此時提前給公司評估和規劃，在未來實施時就赢得了時間的主動權。

　　永遠要比對手多走一步，才能赢得最終的勝利。

4.14.4 一流示範的效益

　　每次好的示範都可以培養出一個能戰鬥的領隊型，策劃型人才，每次都能讓客戶經理認識到公司強大實力和産品能力，對自己未來工作充滿信心。

　　每次通過售前充分的示範準備和排練可以培養團隊作戰的感覺，建立一個強有力的集體，這樣的項目售前示範最容易凝聚人心，建立信心。

　　示範工作最失敗的不是一個項目得失，而是内部成員對公司和産品信心喪失。

　　4.14.5 失敗示範的特征

　　沒有示範策劃

　　沒有進行需求調研，示範時無法用客戶能了解語言溝通

　　過早的進行了示範

　　沒有認真評估示範産品線或子產品

　　示範沒有套路

　　示範沒有就使用者可能的提問做準備

　　沒有後續工作跟進

　　4.14.6 一流示範人員應有哪些素質

　　實際項目實施經驗

　　良好的口頭和書面表達能力

　　表現欲

　　豐富的知識面

　　快速業務調研能力

　　快速學習能力

　　快速反應能力

4.15 示範方案準備經常考慮的問題

4.15.1 聽衆分析

　　會有多少人來聽示範講？

　　聽衆的平均年齡是多少？

　　聽衆的男女比例怎樣？

　　聽衆了解你的主題嗎？

　　聽衆是自願來的還是别人要求他們來的？

　　聽衆有何共同點？

　　聽衆有何先入之見？

　　聽衆有何文化特點？

　　所有的聽衆或某一些聽衆是否認識你？

　　評估聽衆的可能對問題反應情況。

　　4.15.2 根據聽衆人數，調整演講方法

　　4.15.3 演講的結構類型與材料相适應

　　4.15.4 使用叙述法

　　叙述的基本技巧在于使發言有一個明确的開始、中間部分和結束。這種技巧最常用于講故事。你要成功地示範，遵循這一基本格式來組織示範是很重要的，示範的引言就是開始部分，中間部分就是示範的中心主題和觀點(用你認為最适合的結構類型提出)，而結束部分則由你的結束語構成。在結束部分重提核心主題，如有必要，再回答聽衆的提問。記住：重要的是在示範各階段的開始時和結束時，向聽衆提供明确的有關線索。

4.15.5 編制簡化提綱

　　準備一份書面的示範提綱是很有幫助的。在書寫提綱的過程中，組織示範的方式會逐漸明朗起來。在演講過程中，帶可用提綱來提醒自己。将你的三四個要點标上“一”、“二”、“三”和“四”，然後在它們下面分别寫上二級标題(1、2、3)。如有三級标題，就用A、B、C标出；如此等等。提綱要寫得簡單，使之一目了然。

　　4.15.6 設計開場白

　　要想在示範一開始就給聽衆留下好印象，最好的辦法是你顯得堅定而自信。

　　有經驗的示範者總是每次設計開頭的兩句話，這樣就可以把注意力集中在如何打動聽衆上，而不必過于關注該說些什麼。

　　一個成功的開場白會概略地說明你将作的示範，簡要地告訴他們你将提出的觀點。講些趣聞轶事，以親切友好的方式來活躍氣氛，并吸引聽衆的注意力。但要牢牢記住：在示範剛開始時，聽衆的注意力并不最集中，是以要在演講開始幾分鐘之後再提出你最有力的觀點。

　　4.15.7 聽衆注意力的持續時間

　　以45分鐘的演講為例，聽衆在示範剛開始時注意力很集中，10分鐘後達到頂峰，到30~35分鐘，注意力消退。最後，當示範快結束時，注意力又增強。是以示範方案中要設計關鍵内容和聽衆注意力之間的對應關系。

　　4.15.8 設計過渡詞

　　用清晰的線索來貫串示範是很重要的。安排好觀點與主題思想的邏輯順序，讓聽衆輕松地跟上你的示範。當介紹新的内容時，要将前後觀點緊密地聯系起來。

　　是以不同示範點之間一定要設計易于接受的過渡詞，幫助聽衆把思路聯接起來。

4.15.9 運用重複

　　示範時作扼要的重述，是強調要點的有效方法。組織示範内容時，在每個要點的結束部分及在整個示範的結束部分安排一些重複。但是，簡單地重複你前面講過的話是不夠的。要用不同的措詞，使你的觀點聽起來既新鮮又熟悉。

　　4.15.10 難忘的結尾

　　一個好的結束的重要性不亞于一個好的開頭。示意聽衆示範已近尾聲，是十分重要的。用“我要講的最後一點是……”或“總而言之……”等使聽衆注意到你就要總結你所說的話了。他們會很高興有機會補聽他們可能漏聽的觀點。

　　4.15.11 強調觀點

　　強調示範的要點相當重要。強調要點的方法可以是：先向聽衆提供示範“目錄”資料，然後讨論你所提出的問題，最後通過作總結來結束。

　　4.15.12 撰寫口語化講稿

　　要注意，把書面材料以口頭方式告訴聽衆時，聽起來會有很大不同。要學習以自然的口語方式寫講稿，這樣，你的講稿就符合平時的說話習慣，并适合作口頭示範。

　　4.15.13 将演講方案濃縮為提示卡

　　如果你想使用提示來示範，首先要寫出完整的示範稿，包括所有要點和用來闡釋、說明這些要點的例子。以這個稿子為起點，你可以将演講内容濃縮為提示。将從稿子中選出的關鍵詞或短語清楚地寫在編過号的卡片的一面。一張卡片上不要寫得太多，要保證住處的簡潔和明确。

　　準備講稿：确定了示範的結構，而且組織好了收集到的材料後，将發言完整地寫出(或列印出)。編輯、修改這個稿子，直到讀起來覺得通順而有節奏時為止。

　　準備提示卡：從最後一稿中抽出要點，寫到編過号的卡片上。為清晰起見，每張卡片上的提示應不超過兩個。

　　可以用黑墨水寫絕對必要的内容，而可以删除的内容則用其他顔色的墨水寫。

　　4.15.14 注明演講的節奏

　　想一想是什麼因素促使演講成功，那通常是時間的安排。演講的無聲部分即停頓在傳達演講内容的過程中與說出來的話同樣重要，因為它們是聽覺上的标點符号。在撰寫講稿時，要考慮聽衆聽起來會感到怎樣。不管你演講時用提示卡還是完整的稿子，在你覺得必要的地方，例如在需要強調的觀點旁邊或在兩個完整的觀點之間，寫上“停頓”兩字。試講時也要使用這些停頓。使用沉默需要有勇氣：一個注明的停頓應持續三秒左右，這比平時說話時的停頓要長一些。

5 如何做使用者考察？

5.1 前言

5.1   前言

　　入行五年，做了一些相對成功的項目，而且所做項目離公司總部比較接近，是以經常有機會接待客戶提出的典型使用者考察請求。其實每個業内成功的項目經理都有一些售前的經驗，甚至在售後出色的人才會主動被抽調到售前，也許是有經曆的人的話更能打動客戶的心。今天把我個人做典型使用者考察接待的體會做一總結，希望給大家提供一點幫助。

　　5.2 典型使用者有什麼意義？

　　一個項目在技術上決定成敗有兩個重要環節，一是産品示範，二是使用者考察。兩個環節都很重要，而且往往在很短一個時間段内完成(相對整個項目跟蹤周期)，是以典型使用者考察工作不能不認真對待，甚至要作為售前售後最關鍵的工作來對待。

　　現在很多使用者非常怕被軟體供應商忽悠，對考察工作尤為重視，甚至不通過供應商引見，自己去打電話暗訪明查，有的擔心我們提供電話是經過事先聯系形成默契的，還主動多打電話問幾個人，了解軟體應用情況到底怎麼樣。

　　因為無相關行業使用者應用示範，或者因為典型使用者考察效果不好導緻項目無法拿下的情況是非常常見的。

　　好的典型使用者對售前項目有多大的輻射意義，并不需要去強調，做商務的人都明白這一點，但典型使用者不僅對售前有意義，對實施規劃都有更大的意義。

　　一般典型使用者應用比較深入，往往累積了很多成功的經驗，這些經驗往往是比較成熟的套路，可以總結推廣到其它相關類似使用者身上，獲得比較快的實施效益。應該說每個典型使用者身後都對應一套完整可推廣業務實作實施模型，值得很好總結。

　　典型使用者應用比較深入，往往能提出更多更有價值的需求，這些需求對産品發展有很好促進作用，典型使用者一般又願意和我們長期合作，通過詳細解剖典型使用者需求和業務模式，可以縮短軟體供應商了解行業業務的時間，形成有效産品規劃指導産品發展。

　　典型使用者還是一個公司營銷開發團隊是否有信心的關鍵，一般公司開發人員無法直接關心使用者，但營銷和實施不一樣，如果一個公司到處都找不到典型使用者的話，這個公司營銷和實施工作開展也不會順利，人員流動将非常頻繁，大家對公司也沒有足夠的信心。如果一個公司擁有一批成功使用者，所有員工基本上就會把精力更投入到業務中，因為大家會覺得既然别人能成功，我應該也有機會成功，而不是一緻責怪公司這裡不行，那裡不到位，導緻事情沒法做。

5.3 典型使用者應如何管理(上)(

和産品示範一樣，典型使用者管理也是一個系統工程，不是通過突擊就可以實作的。要想管理好典型使用者，就應該在公司層面有專人定崗定責進行管理，沒有專人管理典型使用者資訊，業務一定會出問題。

　　典型使用者管理應該經過三個層次：

　　5.3.1 典型使用者确認

　　首先要将對公司市場工作最有利的典型使用者篩選出來，這些使用者其實在售前跟蹤時就可以通過客戶ABC分類加以明确，這樣即使某些客戶在第一次合作時項目金額并不大，也可以在在項目實施過程重點保障資源，重點投入。

　　一般選擇典型使用者名單考慮以下七個因素：

　　1) 應用效果，有三類使用者可以做典型使用者。第一是成功進行了大量應用的使用者，最好的典型使用者是實際業務每天都要大量人員利用系統進行工作的使用者，而且在實施過程中有很好的參考作用的使用者，這樣有實際應用效果的使用者最能讓其它使用者相信軟體公司的能力；第二是一些應用面還不夠大，但基礎資料都基本錄入，典型業務流都可以實作的使用者，第三是非常有特色的使用者也可以作為典型使用者。當然實際應用效果是選擇典型使用者首要因素。

　　2) 商務關系，所謂典型使用者，就是希望能夠替公司提供宣傳的使用者，這些使用者論高管還是中層幹部或者基層操作人員應該認同軟體公司産品，願意推薦軟體公司的産品，如果沒有好的商務關系，使用者甚至對軟體公司還存在意見，即使應用情況不錯，也要考慮是否适合做典型使用者。典型使用者的商務關系應該一直有專人負責跟蹤和維護，僅僅靠客戶經理和實施經理維護是不夠可靠的。

　　3) 行業影響力，影響力越大越好，一般情況下行業影響力大的使用者公司應在商務和實施時差別對待，重點投入，而不要簡單受項目金額大小左右，否則可能造成服務資源不夠，做臭一個，丢掉一片。

　　4) 業務應用豐富，以技術資訊化軟體而言，要考慮典型使用者至少能覆寫有設計有工藝，無設計隻有工藝兩種研發模式，有設計無工藝的可以直接看有設計有工藝的類型。否則使用者考察時會提出感覺沒有看到自己想要的内容。有設計的使用者應該覆寫到一種三維軟體，一種二維軟體。這樣的考察效果才能達到全面完整，業務類型豐富，而不是一個使用者實施比較成功，參觀就一定有好的效果，要選擇一個業務應用盡量豐富的企業。一般随生産模式(單件，多品種小批量，大批量)不同，業務應用豐富的企業也要選擇幾種類型才能适應不同生産類型使用者考察需要。

　　5) 地域輻射力，典型使用者地理位置應該交通友善，不然會增加客戶交通成本，也增加公司接待成本，而且無法起到長期輻射作用。一個全國性公司一定要考慮在全國建立可參觀考察的典型使用者網絡，僅僅隻有幾個典型使用者參觀考察對使用者本身也是一種巨大的騷擾，而且對很多地域性使用者，不友善出省考察的客戶是很難做到有效輻射。

　　6) 服務資源，典型使用者并非一定是所有問題都解決了的使用者，往往是經常性需要服務的使用者，因為應用深入，需求比較多，而且系統不能停，一停就容易出問題，但很多時候典型使用者要協助軟體公司做一些參觀考察工作，這個時候往往需要提前解決一些軟體應用問題，以便讓典型使用者在考察前有一個好的狀态，這樣典型使用者如果完全沒有服務資源往往會出問題。

　　7) 介紹資源，典型使用者接待客戶參觀時效果一個重要因素是企業有無能交流，并把業務和資訊化實施過程問題介紹清楚的人員，如果有一個這樣業務能力比較突出，又全程參與項目實施過程的人員能介紹項目實際情況是最好不過。

　　典型使用者确認未必一定要以現在是否可以立即參考考察做依據，而是應該綜合以上因素以後确定名單，然後通過一系列工作努力讓這些使用者成為可以參觀考察的使用者。

5.3.2 典型使用者分級，确定服務模式

　　典型使用者名單确定後立即要根據典型使用者可考察參觀實際效果情況對典型使用者分級。

　　第一類典型使用者是可以随時安排參觀考察的典型使用者。

　　第二類典型使用者是可公開宣傳，但不友善或不願意接待參觀的典型使用者。

　　第三類是可以在售前非公開資料和口頭介紹的使用者。

　　第四類是千萬不能公開介紹和宣傳的使用者，一些典型應用不佳使用者。

　　第一類使用者應加強商務聯系，簽訂宣傳合作協定，保障定期走訪服務，讓典型使用者和我們長期合作，心情舒暢；

　　第三類、第二類典型使用者要根據情況确定是否可投入資源使其向第一類，第二類使用者逐漸轉化，一個公司第一類典型使用者多了，市場口碑就起來了，甚至服務價格就可以提高了。

　　一、二、三類使用者都要明确詳細的服務模式，并落實到具體實施部門或區域團隊管理，并定期檢查服務工作是否完成和品質，這樣才能形成一個閉環的管理體系，不至于口頭重視，實際上因為沒有利益(國内目前大部分項目服務是無法收費的)保障而無資源投入。

　　第四類使用者也很重要，有些使用者在業内或當地知名度極高，但軟體公司在這裡遭遇了滑鐵盧，是以公司一定要動态審查在方案、公司介紹、對外提供典型使用者名單上盡量不要出現此類使用者名單，避免被潛在客戶咨詢或提出參觀要求時被動。

5.4 典型使用者應如何管理(下)(

　5.4.1 宣傳模式規劃

　　典型使用者的輻射效力展現在四個領域：

　　售前主動介紹(文字和口頭介紹)

　　客戶現場參觀考察

　　媒介(新聞性媒介和專業期刊)

　　行業或政府主辦經驗交流會議

　　是以典型使用者分級後，應根據這四個輻射效力領域分别設計相應的套路，針對不同典型使用者提供組合管理方案。

　　首先要為典型使用者提供在公司網站介紹材料，公司宣傳手冊，公司各種方案材料，公司售前PPT，公司内部教育訓練材料保持一緻的宣傳介紹材料。

　　完整的典型使用者宣傳介紹材料應包括以下幾個内容：

　　企業LOGO

　　企業廠區或典型産品照片

　　企業概述(有地位突出地位，無地位突出業務特色)

　　企業應用軟體情況介紹

　　企業應用現場或鑒定現場照片

　　企業高管或項目負責人對項目一句簡短而經典的評價

　　企業應用效益

　　項目獲獎情況(是否獲得國家省部市級資訊化建設項目獎勵，或者進入863主題計劃)

　　其次典型使用者現場參觀考察工作需要組織的第二個方面，下文專門另文介紹。

　　第三典型使用者媒介報道也非常重要，第一種是商業性媒介報道，主要是重要客戶簽單，取得階段性驗收，最終結項，通過重要機構鑒定和獲獎應及時在公司網站，合作媒體上釋出新聞材料，這類消息軟體公司要有很強的主動宣傳意識。

除了直接商業報道外，還有一種軟媒介報道，就是和典型客戶項目負責人合作就項目實施特色應用或者實施經驗發表專業學術性文章在專業刊物上，擴大知名度同時也為很多企業項目負責人解決很多實際問題。

　　最後應用良好的典型使用者經常有機會參加政府行業或者集團内部主辦的經驗交流會或者鑒定會，軟體公司在申報項目的時候也經常需要請典型使用者合作作為項目使用者機關，并需要配合蓋章，是以我們應建立典型使用者的資料庫，随時備雙方做彙報材料準備用。

　　如果有，以下材料一般都應保留：

　　詳細的企業情況介紹(企業概況、行業地位、産品系列、人員組成、聯系方式)

　　企業資訊化總體規劃方案

　　企業項目招标書(選型評分表)

　　企業項目投标書或者項目售前解決方案

　　企業實施解決方案

　　企業對外項目實施經驗總結或成果彙報材料(文字和PPT)

　　軟體公司内部實施經驗總結(突出業務特點和功能應用特色)

　　項目雙方主要負責人員履歷(應每年保持更新)

　　其它值得管理的資料

　　完成這三個層次的工作，典型使用者管理應該說就是比較完整業務過程。

5.5 使用者現場考察應如何組織？(

一般資訊化項目使用者都會提出現場考察典型使用者的要求，那麼如何組織使用者現場考察工作呢？

　　典型使用者考察組織有三個層面：

　　5.5.1 第一是公司層面

　　軟體企業對于已明确可以現場考察的使用者應要求建立考察模式，并由專人負責維護，一般就是項目實施團隊負責設計項目現場考察行程地點，業務介紹套路，實施應用介紹套路和相關PPT，并和企業接待人員充分溝通，就交流必須向潛在客戶講到的亮點，保證前來參觀使用者可以看到項目實施過程中的功能特色或實施特色，不虛此行，也是對潛在客戶的一種尊重。

　　公司還要提前和典型使用者溝通，确認現場實施狀态，評估項目可考察性，确定是否需要一些服務資源投入或者請典型使用者進行專門準備。

　　公司還要注意和典型使用者約定考察參觀方式和考察頻率，了解典型使用者安排方式是現場參觀，還是投影集中介紹，還是在某個業務地點集中介紹；典型使用者一個月希望接待幾批考察對象，本月是否有重要任務，不友善接待考察等情況。這些情況要提前通知到各地客戶經理知情，友善對潛在使用者進行介紹。

　　公司還要收集整理不同考察使用者關注的針對性問題或者考察評分表，形成問題集和參考評分表備案，這些内容将可以成為公司規劃産品發展，了解使用者功能需求和實施要求的重要管道，也是向其它潛在使用者提供如何考察的素材資料，對于一些共性問題還可以形成公司級标準解決方案，有利于各個方面人員和客戶溝通。

　　最後公司要協調項目實際負責實施人員，或者對項目情況比較熟悉，業務能力很強的顧問型人員在考察期間全程陪同，至少要保證現場有軟體商的實施人員陪同。

　　這些工作一般有公司或者級别較高主管部門協調組織落實。

　　5.5.2 第二是客戶經理層面

　　具體到某個項目考察，這是客戶經理應該負責的工作。

　　首先客戶經理接觸到一個項目，應該要主動判斷是否安排使用者考察，使用者考察是否和公司考察放在一起進行，還是在本地典型客戶處安排考察，在什麼時候進行為妥。

　　根據這個判斷客戶經理再根據企業業務特點和需求和公司提前溝通，确定可參觀使用者對象，請公司相關典型使用者負責人員提供若幹典型使用者相關資料，以備使用者查問。

一旦客戶提出考察要求，要提前和典型使用者或通過公司和典型使用者預約時間。注意盡量避開使用者負責人不在，公司陪同參觀介紹人不在，企業休息日，或者拉閘限電(這個是近年中國特色)等情況，緊急響應，安排行程和場地，并把前來考察使用者詳細情況(人數，性别，級别，行程，關注點)形成文檔送出公司。

　　客戶經理還需要了解潛在客戶關注的問題，很多使用者會提前設計一系列針對性考察問題，這些問題要提前發送公司典型使用者負責人準備，并通過公司或親自和典型使用者溝通，介紹前來企業情況，前來人數和時間，希望考察内容，可能要問的問題，以便讓典型使用者自我介紹時更清楚情況，能夠達到較好的考察效果。

　　考察過程原則上客戶經理應全程陪同，客戶經理在陪同過程中要做三件事情：

　　1、随時和公司内部溝通，通報情況和提醒注意

　　一般前來考察的客戶需要通過客戶經理介紹給相關人員，并單獨和相關考察接待人員溝通，說明一些文字描述可能遺漏或者不容易寫清楚的情況。整個考察過程中要随時注意進行這類溝通，保持公司一緻性。

　　2、親自安排好客戶的衣食住行

　　客戶經理讓客戶感到親切認同就是成功，這些都是通過接待細節中展現，是以客戶經理要親自做好這些工作，為今後商務工作奠定感情基礎。

　　3、寫備忘錄

　　客戶經理全程陪同最重要目的是随時了解客戶在考察過程中交流思路，判斷項目技術或商務側重點應該是什麼，便于進行下一階段商務和技術公關策劃，很多交流内容不是當事人是無法清楚表達和了解的。是以一定要利用這個機會充分了解使用者想法，甚至趁熱打打邊鼓，促進客戶下決心。

　　考察完成後客戶經理要主動幫助使用者準備一份考察備忘錄。一般企業出來考察回去是要寫彙報材料的，但大部分人出來考察因為行程緊張并沒有立即組織材料，隻是簡單記錄，這樣一輪考察下來，再去組織準備工作量也不小，而且資訊遺忘可能很大。其實很多人并不擅長寫文檔，如果這個時候有一份可參考的資料對這些使用者該是多麼友善的事情。

　　是以客戶經理要主動在使用者考察完成後寫一份記錄考察過程的備忘錄，備忘錄可以分這麼幾個内容，考察日程安排，考察使用者情況介紹和應用情況介紹，考察過程交流關鍵内容及回複記錄。這樣的備忘錄将非常有利于我們後續工作，有這樣現成的素材在，難免使用者會直接引用，一引用彙報給上司就給我們增加了成功機率，特别是當競争對手都沒有做這個工作，就展現了我們的用心。

　　認真做事隻能把事做對，用心做事才能把事情做好，就是這個道理。

　　備忘錄展現了我們對考察後工作的間接控制，保證考察印象能有效傳遞，但備忘錄有一個原則，客觀中立，可以回避弱點，但不能誇大粉飾。

5.6 使用者現場考察應如何組織？(中) (連載四十)

5.6.1 第三是考察顧問層面

　　一般情況下客戶考察應安排一個顧問型人員在考察期間全程陪同，因為使用者在考察期間是最容易進入實際環境感受，容易看到别人實施過程，思索自己項目規劃的時機，如果能得到高水準咨詢顧問交流和指點的機會，會給軟體公司增加很多印象分。實際上考察走馬觀花能看到什麼？有的企業比較有經驗，能深入了解一些情況，大部分企業考察看不出太深的内容，隻能說在考察過程中誰能在短短幾個小時内了解到客戶的擔心和疑惑，并合理通過考察行程展現出來

　　此外很多典型使用者自己用得不錯，但缺少系統的總結，介紹時沒有層次，而且他們一般也不太清楚參考企業到底關注側重點是什麼，介紹時容易突出自己的特色，但沒有考慮參觀企業到底想看到什麼，這個時候顧問就要巧妙利用自己豐富實施經驗和判斷力，以及和典型使用者良好人際關系引導介紹交流思路，讓參觀使用者看到東西，學到東西。

　　無論能否成功合作，潛在使用者花費成本考察，我們就應該盡力讓他們了解項目實施效益和風險，以後他們在資訊化建設過程中可以少走一些彎路。

　　是以一個好的考察顧問往往是整個使用者考察的真正靈魂，有沒有一個這樣的高水準顧問對整個考察效果品質是兩個檔次，明白這一點客戶經理也應該清楚要讓自己的考察達到效果，有沒有這樣的一個人是非常重要的，一定要盡量協調好時間，讓考察顧問有充分時間陪同，如果公司沒有這樣的人員，考察過程就隻能聽天由命，讓典型使用者自己發揮。

　　但這樣的考察最大的可能問題是，很多項目業務和潛在使用者實際不一樣，潛在使用者總覺得和自己類型不相似，總是想看到一個和自己一樣的企業而且成功實施，這樣就比較放心。

　　且不論使用者這樣的認識是否正确，但的确一個軟體供應商也很難讓若幹典型客戶代表所有的企業業務情況。如果一個軟體商有如此足夠實力擁有全面可考察的典型使用者自然最好，但實際上這是理想情況，而且很多使用者行程安排又決定他們沒有足夠時間去考察其它類型使用者，是以很多使用者考察完後總有顧慮，覺得自己想看到内容沒有看到，這個問題如果有經驗豐富顧問彌補介紹是一個補救的辦法。

　　當然作為公司盡量在各個地區培養不同類型的使用者是非常重要的工作。

5.6.1.1 考察顧問應該注意的三個環節

　　考察顧問和客戶在一起一般要完成三陪工作，第一是陪交流，第二是陪考察，第三是陪吃飯。

　　客戶在去考察典型使用者之前，一般會先安排和公司顧問做一個交流，那麼這個時候顧問要充分介紹自己産品特點，回答使用者關心的問題，了解使用者關注問題，快速判斷是否可以在要考察的典型使用者裡看到和說明，如果看得到自然最好，如果看不到，就要考慮相應說辭，進而能夠很好地在考察時候讓使用者得到一個滿意的回複。

　　這個時候顧問要低調親切溝通，給客戶建立一種專業沉穩的可信賴印象，在現場考察的時候才容易發揮出彩。

　　顧問和使用者交流往往存在幾個難題，第一是原來不認識，比較陌生，如何快速讓客戶進入狀态；第二是顧問對企業往往也比較陌生，如何快速了解企業情況，進而合理提供建議。對于顧問應在使用者來之前做一些案頭工作，檢視售前相關資料和上網了解企業産品是很好的辦法。

　　能否快速讓客戶進入狀态一是顧問應有一定商務知識，善于制造溝通氣氛，最重要的是顧問能很快讓使用者覺得自己比較專業，進而有溝通的興趣。

　　要做到這點一般顧問應該也是一個實施經驗很豐富的人員，否則顧問隻是名義上的顧問而已。

　　一個有豐富經驗的顧問，在陪同考察和吃飯時才能有效說服使用者，建立信任。而且一個有豐富經驗的顧問，不僅僅是業務經驗豐富，還應該有一些雜的知識面，例如在行車路上，顧問就是一個導遊，講環境，講發展，講文化，讓使用者可以先輕松一下，也建立一個好的氣氛。

　　5.6.1.2 現場考察三原則

　　盡量讓使用者自己介紹，顧問隻在關鍵時候點題，或者在局面不利時候出馬，不要喧賓奪主；

　　介紹情況不可任意誇大，實事求是，不要怕客戶看到不好的方面，應該真誠和客戶戶探讨如何才能實施好項目，取得使用者的信任。甚至在客戶來到現場之前多鋪墊一些低調的話。

　　隻介紹功能，不介紹實施。有的使用者對技術非常感興趣，對實施難度不夠重視，這樣的使用者要在技術上讓其放心後，合理感覺到實施方面的難度，進而認同找到一家好的供應商合作才能成功的道理。

5.7 使用者現場考察應如何組織？(下)(連載四十一)

　5.7.1.1 現場考察介紹技巧

　　使用者用得不好，看功能。不好就是不好，可以不主動談，但可以通過功能介紹說明軟體應有的能力。

　　使用者用得好，看應用，看每天有多少人建立多少資料，事實比任何資料都有說服力。

　　介紹軟體功能要用講效益的方式去講，用比較精練的話去引發使用者的興趣。

　　例如我介紹一個使用者用KMCAPP編制工藝的好處用了一句話，在這個企業80%工藝資料不是手填的。很多使用者就很感興趣，這樣我就有充分時間展開如何合理規劃工藝資料，建庫查表自動計算廣播等等，通過實地示範讓使用者感受到資訊化的好處。

　　講實施過程要用講故事的方式去講，例如我介紹一個使用者實施過程，用了四上四下，說同志搞革命三上三下，本人做這個項目四上四下，通過介紹四上四下說明項目一把手作用如何展現，項目團隊應該有怎樣品質人組成，一個項目成功最重要的要素是什麼，這樣使用者在聽故事的同時就不知不覺接受了你的理念。

　　講故事還要追求輕松幽默。例如我和客戶講企業實施磨合痛苦的過程，就用了一個方輪的故事。

　　有一個使用者給我講，原來沒有用電腦，好象每天走路上班，感覺也很好；後來上了電腦，就象騎自行車，每天輕松了許多；現在機關上了這個先進的ERP/PDM，高興得不得了，因為開上汽車了，車型款式還特别漂亮，一看儀表系統就知道是進口貨，各種駕駛資訊一目了然，原來自行車是沒法比，但一摸方向盤，一踩油門，就是無法啟動，下車一看，天啊，咱們這車輪子是方的！

　　這樣客戶就很輕松在笑聲中明白就跟兩口子新婚一樣，所謂實施，關鍵在磨合。是以搞資訊化一定要做好長期磨合的心理準備，沒有這個準備，離婚率一定會大大上升。

　　再如我講實施上線的難度，就提了一個走不完的20米，說我們企業系統管理者，在項目上線最繁忙的時候，每天從辦公室走到廁所這20米是無法走完的，每次還沒有到廁所就被兩邊部門人員喊進去解決問題，隻能等别人下班吃飯趕緊沖到廁所去解決問題，這樣的故事在笑聲中就把很多不好說也不容易說清楚的事情和意思表達出來了。

　　但是講實施風險的話題要慎重，展現難度大的事情也可能打消使用者實施積極性，要慎重講，到了氣氛再講。

講故事還要将一些具體實施思路和做法展現出來，讓使用者對我們經驗和專業水準表示認可。有的使用者對資訊化軟體基礎資料錄入不夠重視，也不清楚如何推廣軟體，這個時候我就會講一個三毛錢的故事。

　　我講我們開始軟體安裝到位，大家都不願意用，說是軟體不能用，結果企業就下令3毛錢一條資料，結果就有人開始錄，還真得到了錢。這個時候我往往開玩笑說我們當時開發人員要求去現場實施，協助錄入資料，以我們水準一天錄入1000條資料很容易，這可就是300元的收入了！

　　大家一看有錢拿，就紛紛錄入資料，這個時候上司就把政策停了，大家剛想責問，上司說，原來各位說産品不能用，是以不能錄入資料，現在發現你們都可以錄入資料了，總不是各位給錢就配合資訊化工作，不給錢就不配合資訊化工作吧？

　　這樣在大家都掌握基本操作後進行一次考試，考試過90分的企業每人獎勵500，過80分獎勵300，這下子大家積極性都調動起來了，一個月後上司宣布進行第二次考試，這次80分以上都獎300，并宣布兩個月還要進行考試，不及格要處分。果然兩個月後再考試，90分以上獎300，不及格罰200。

　　通過三次考試，就達到了拔尖，鼓勁，鞭策的目的，而且将軟體操作和應用一層層擴散出去，最終形成大面積使用的不可逆轉的趨勢。

　　很多人聽了這個故事對項目管理，目标驅動，激勵效應就有了更深的認識，自然也對顧問，對顧問所在公司多了一份信任。

　　5.7.1.2 飯桌上再燒一把火

　　一個好的顧問在陪同考察完畢，一定記得如果安排一同就餐，在飯桌上還得根據客戶情況繼續燒一把火。

　　不過既然到了吃飯時間，工作就不應該是主題，這個時候比較好的方式是可以從介紹公司文化逸事或者發展思路方式嘗試用更高的思維層次和客戶溝通，不要再糾纏過多在技術細節上，這樣客戶可以比較輕松邊吃邊聊，将一些感興趣問題又提出來和我們交流，進而繼續獲得影響客戶的機會。

　　記住：客戶前來考察是最脫離自己企業環境可獨立思考的時間，也是最容易接受别人的時間，整個考察工作如果精心準備和規劃，自然能給客戶留下深刻的印象，對項目成功起到關鍵的作用。

6.1 前言(連載四十二)

入行五年，經常碰到需要和各種人等介紹公司的情況，特别是在公司總部接待重要貴賓考察，積累了一些經驗，今天把我個人做公司介紹的體會做一總結，希望對所有需要介紹公司人員提供一點幫助和指導。

　　6.2 哪些情況下需要公司介紹

　　公司介紹是用比較短時間内讓客戶對公司業務能力有一定了解，甚至是深刻印象，為今後合作開一個好頭。

　　一般公司介紹有這麼幾種類型：

　　第一是正式陳述，在重大招投标答辯場合，産品示範場合，一些公開會議上，這個需要很正式地介紹公司基本情況和實力。

　　第二是口頭介紹，在商務和實施工作中，碰到一些人關注或者不了解，在沒有特意安排的情況下進行口頭介紹。

　　第三是會面介紹，一般是和客戶約定會面時間，在會面的機會介紹自己的公司和産品。

　　第四是參觀介紹，客戶或客戶到總部來參觀，在參觀過程中介紹公司文化和發展等各方面情況。

　　不同情況下介紹公司的要求是不一樣的，是以下面我分開介紹。

　　6.3 正式陳述時常見錯誤？

　　6.3.1 反複介紹原來介紹過的内容

　　正式介紹是一個很正規和重要的場合，而且是在雙方進行各種接觸到了一定程度的時候才有機會進行的工作，是以可能有很多人對軟體公司已經有很多了解，因而來聽陳述的重點内容不是軟體公司基本情況，而是軟體功能或者項目實際情況。但對一部分人可能對軟體公司不太了解，是以在正式介紹時根據已經介紹過的内容确定取舍，不要反複講以前很多次介紹過的内容，而是要突出公司競争優勢點，其它内容在沒有明确要求的情況下盡量一帶而過，不要擠占重點内容介紹時間。

　　我個人經驗介紹内容一定要結合客戶關心部分強調幾個點，一般就是三點公司優勢，例如可以介紹的内容一般是規模，地位，實力，客戶數，行業經驗，規範性，服務能力，研發能力，完整的解決方案，自主版權，公司發展速度，最新情況通報等等内容，但不要面面俱到，效果反而不好，要選擇最能打動人的關鍵點組織。

　　把力量集中反而印象深刻。

　　6.3.2 介紹速度過快

　　正式介紹一般有時間限制，公司介紹又必須首先進行，有的人很想在正式介紹時把公司情況盡量完整進行說明，又擔心用時不夠，為了解決此問題，就用比較快的節奏介紹公司。

　　但參與正式介紹場合的人往往也是有一定級别的人，習慣用一種比較舒緩平穩節奏聽取彙報，而且用很快的語速開始會給人留下緊張，不夠大氣的印象，進而對公司印象也不佳，而且短時間内的灌輸也不見得有效果。

　　是以甯可裁剪内容，也不要介紹公司内容時過快。

　　6.3.3 一些細節用時過多

　　有的人在介紹公司時覺得有一些很重要的内容，例如公司曆年獲獎情況，一張張把證書慢慢放給客戶看，如果不是客戶要求的話，這樣的介紹方式并不好。

　　站在客戶的角度，這是一種包裝手段，不是實質性内容，這些内容介紹多了容易給人不實在印象。

　　此外大家可能都有一個經驗，看電影的時候片頭時間越長越煩，最終讓我們記住電影名字的還是電影本身内容。

　　在做公司介紹時沒有重點，把一些自認為重要的細節講得過多，都是對客戶時間的浪費。

　6.3.4 資料無更新

　　我經常看到很多人不注意和公司相關部門溝通，總是用自己習慣的PPT或者材料去介紹公司，到了2005年了，公司材料上的成就和案例還是停在2003年，這樣給使用者的感覺是不是這兩年你們公司沒有什麼發展了？

　　是以一定要注意資料更新，而且資料一定要保證所有公開資料的一緻性，特别是介紹内容和公司宣傳資料一緻性。

　　為了彌補資料不夠及時的問題，在介紹時可采用一個技巧，可以用通報方式補充說明，例如可以在介紹時非常自豪的講：“下面我向大家通報一個好消息，我們剛剛在***”，簡短說明意思即可。

　　6.3.5 介紹定位過于自戀

　　很多公司自我介紹一個典型感覺不象是寫給客戶的，倒象是寫給公司老總的自我陶醉的文字。

　　公司介紹材料充滿自我炫耀，自我膨脹，自我肯定，就是沒有站在公司能為客戶提供什麼産品和服務内容的角度去組織材料。

　　好的介紹是告訴客戶我能為你做什麼，不是因為我有多麼好，快來選擇我吧，同樣的内容用不同的方式組織介紹效果也自然不一樣。

　　6.3.6 沒有激情

　　特别是對于經常正式介紹公司的人，還有一種情況，可能因為講的次數過多，對重複的内容沒有感覺，缺少激情。

　　一個人介紹公司時沒有自信，沒有一種在此從業引以為榮的自豪，又如何讓客戶從你個人身上感覺到你所在公司的成就？

　　從容自信，充滿感情介紹公司是一個職業人必須能調整自己情緒做到的一點基本素質。

　　6.3.7 采用危險的表達

　　有的商務人員對一些内容不太清楚，在介紹時犯一些常識性錯誤，例如把CMM說成是通過三級認證，ISO存在認證，CMM沒有認證，隻有評估，對内行這是錯誤說法。

　　例如過于強調我們人員多，有360多人，可能現在正式提供給公司手冊上人員已經是260人了；

　　又例如習慣性強調我們的EAIP平台和電子政務等内容，其實這些部門或業務已經整合調整不再進行了。

　　這些介紹硬傷是一種危險表達，會讓使用者覺得我們不真誠或不專業。

　　另外就是為了獲得競争優勢，采用一些危險的提法，例如強調我們國内第一，我們實施成功率最高，我們最有行業經驗，我們可以現場開發等等說法。誰能證明你是第一或是最優秀呢？

　　在使用者沒有實際了解之前，不過是虛誇，使用者實際了解後，可能更認為你言過其實，更加不信任你。

　　我們有個項目例如強調我們某個産品發展曆史很悠久，但實際上發展時間隻有三年，版本更新很快，結果客戶私下打電話了解相關使用者，有的使用者告訴他用的版本很老，一直沒有更新，有的使用者告訴他用的是新版本，剛發行但不穩定，很快客戶決定放棄我們這家公司。

　　沒有誠信，不會長久。

　　6.3.8 沒有專人管理正式材料

　　有的商務人員說我也不想有介紹硬傷，我也想知道公司的最新進展，但哪裡去找呢？

　　是以随時更新公司介紹材料，提供标準說法并下發應該有專門人員負責和維護，否則很容易在細節上吃虧出問題。

　　6.3.9 着裝随意，不統一

　　參加正式介紹人員着裝正式統一應該是個很基本要求，也是對客戶的尊重。

　　一旦一個人要介紹公司，就一定要注意，不可在随意和過于放松情況下介紹自己的公司，因為過于放松狀态下介紹公司難免給人一種對公司不太認同的印象，既然談到公司，無論在什麼時候，都不是私事，就應該打起精神開始。

　　6.3.10 随時練習

　　有人以為自己介紹公司很多次，經驗一定很好，就不注意準備，但在現場就發現要麼容易沖口而出，要麼羅裡羅嗦講個沒完，又抓不住重點。

　　練習，練習，不斷改進，這才是真理。

6.4 口頭和會面介紹時常見技巧(連載四十三)

口頭和會面介紹一般都是在一種相對非正式場合進行，例如辦公室面對面進行一些彙報時寒暄内容之一。

　　這個時候介紹公司内容和正式介紹類似，但要注意時間不要太長，一般三分鐘内為佳，使用者有興趣再展開。

　　但這個時候交流往往有很多意外情況，是以我覺得自己事先一定要有準備幾個版本的說法，應付不同情況，同時保持自己的不卑不亢。

　　6.4.1 不知道型

　　例如有的時候你一講我是**公司某某某的時候，客戶來一句：“**公司，沒有聽說過，幹什麼的？”。

　　沒聽說型的客戶是很正常的，這個時候可以說：“*工，請允許我用三分鐘簡單給您介紹一下，具體内容略”。

　　6.4.2 反感型

　　比不知道的情況更糟糕的時候客戶會說“聽說你們在某某項目上很不成功，是不是這麼回事？”

　　面對這種使用者的挑戰，千萬不要急于否認，隻會增加反感，也不要緊張，失敗的案例大家都有，不要因為拿出一個不成功的例子就覺得沒有希望。

　　我們可以先承認，後化解，“看來*工了解過一些我們的情況，的确我們有一些項目沒有做到位，在很多行業，其它地區，我們還是有很多成功的合作，例如在某某，如果您不反對的話，我想介紹一下我們公司最近的一些情況。”

　　6.4.3 我知道型

　　有的使用者一聽我們公司名号就說你們不就是那個做CAD的嗎，這個時候我們就要順藤摸瓜，誇獎客戶：“看來*先生對我們公司很有一些了解，不如我給您介紹一點最新情況”，也可以用化解誤解方式進行“看來*先生對我們公司很有一些了解，其實我們不但CAD做得有很大影響，這幾年我們發展得還不錯，在CAPP/PDM領域我們也是國内最好的供應商之一，是以今天希望有機會給您詳細介紹一下”。

6.4.4 上司型：

　　有的使用者很忙，也很緊張，根本沒有時間聽你講太多東西，我們可以開門見山：“我們是國内最有經驗的CAD/CAPP/PDM供應商，聽說您的企業有****問題，我們正好有這方面的經驗，是以過來和您一起溝通一下，看看有什麼我們可以幫上忙的地方”不過這樣舉問題有一定風險，是以可能的話應有所調研了解。

　　6.5 在客戶處進行公司介紹三個要點

　　無論是正式陳述還是口頭介紹公司，有三點一定要講到：

　　業務講到：我們能為您提供什麼，做什麼，如何合作。

　　實力談到：和我們合作為什麼可以放心。

　　案例說到：我們不是在說大話，有很多使用者和我們一起取得了成功，并有案可查。

　　這三點沒有說到，就不是一個完整清晰的公司介紹，換句話說無論介紹時間長短和場合，都可以介紹完成這三點内容就是好的公司介紹。

　　建議公司介紹思路組織可以用以下順序組織：

　　1)公司業務面—2)産品體系—3)組織架構和服務體系—4)合作建議—5)成功案例—6)發展曆程和榮譽

　　對于公司業務面介紹可以設計一些具體問題，引發興趣；

　　對産品體系介紹要突出重點，強調完整解決方案，可以用案例說明我們在具體項目上給使用者成功的解決方案，包括自己的産品，也包括和别人産品的內建；

　　組織結構用圖說話，強調研發體系和服務體系的規範管理，可以列舉一些數字，例如我們軟體測試人員和開發人員比例關系，我們某些産品自動化測試覆寫率，我們每年一個工程師服務工作日等等。

　　合作建議關鍵是要有針對性，不要泛泛而談，讓客戶感覺客戶經理隻是在講套話。

　　成功案例一突出使用者多，二突出合作雙赢效益，三突出我們和使用者長期合作，共同發展的服務思路。

　　發展曆程介紹要快速精練，給人感覺蓬勃向上，富有朝氣，對于公司曆史榮譽重點顯示最新榮譽，其它一帶而過，可邀請客戶通路公司網站，了解公司最新動态和文化。

6.6 如何對在公司考察客戶做介紹(連載四十四)

　對來公司參觀考察型客戶介紹公司是有技巧的，一般這樣的客戶對公司基本情況都有所了解，而且都是公事公辦的正規介紹，來到公司，很多人又不清楚客戶的來路，别的不敢講，隻好把公司情況又熱情介紹一遍，甚至接待人，主管上司輪番轟炸，客戶礙于情面，心理上其實已經反感了。

　　其實客戶到總部來了，反而要少談公司，少介紹産品(一般技術問題還有專門交流時間)，多看特色。一般客戶對軟體公司是很好奇的，又不生産物質産品，很難和其産品線比較，是以沒有什麼考察經驗可以參照。要通過介紹讓使用者留下深刻印象并不容易。

　　我個人經驗這個時候介紹公司有三講：

　　第一是講故事，我們這個時候不要呆闆的介紹公司，而是要講故事，例如我們談公司人數可以請使用者看老照片，結合老照片講公司創業艱辛到發展壯大曆程，邊講邊和客戶互動，看着老照片，聽着開目人創業的故事，客戶就容易從心理上喜歡這個樸實認真的公司了，而不是簡單被一個漂亮裝潢的大樓打動。

　　第二是講特色，特色主要指公司管理上特點，一般管理上特色是結合組織機構介紹進行的，要給使用者生動介紹我們的組織機構，我們可以和企業類比的方法，一般我講研發部就和使用者說這是我們的生産工廠中的房間，請他們看源代碼管理工具，看安全保密條例，到測試組就和使用者說這是我們的質檢工廠中的房間，請他們看軟體自動測試工具，這些是客戶很少見到，但見到後有很容易認可軟體公司規範可靠的細節，而且有新鮮感。

　　第三是講文化，我們給客戶在公司做介紹，不僅僅要介紹公司經曆和管理特色，還要通過這些内容突出我們公司積極向上，勤懇努力的文化。

　　在發展上獲得使用者認可，在管理上獲得使用者贊賞，在文化上和客戶形成共鳴，這就是在總部進行公司介紹的目的。

　　6.7 做好總部公司介紹的三個訣竅

　　根據公司的發展曆程群組織布局設計标準套路的介紹詞，保證每次介紹品質。

　　精心設計介紹流程和路線，讓使用者在每個部門都可以看到他們關注的内容，例如在實施部看項目管理體系，在研發部看規範代碼控制過程，在質控部看軟體品質保障體系，在營銷部看公司獲獎榮譽。

　　找一個熟悉公司的人員專門接待，熟能生巧，并定期請其彙報介紹工作改進意見。

　　6.8 公司總部接待考察客戶要注意的細節

　　準備熱情的歡迎牌，注意歡迎牌一定不要把幾個客戶機關并在一起，甯可多寫幾張紙；

　　如果總部不能抽煙，提前告訴使用者，請求了解；

　　一定盡量安排高管接待，以表重視，高管如果忙，可以事先說明，接待時間短一點；

　　和客戶交流時準備精美的宣傳資料，記錄交流問題的紙和筆；

　　請客戶參觀我們的獲獎陳列室；

　　安排一次展現當地特色的餐飲；

　　如果時間充足，安排到旅遊點參觀；

　　臨走記得送使用者一些土特産禮品；

　　全程安排好用車計劃，不要出現使用者長時間等車的情況；

　　整體接待不要過于殷勤，要在使用者關心考察内容上下工夫，接待工作原則是得體大方親切，不犯低級錯誤。

7.1 教育訓練工作在項目實施中作用(上)(連載四十五)

7.1.1 教育訓練工作的目的

　　在IT管理軟體實施項目中，教育訓練是貫穿整個項目過程中，從一開始介入項目，就有教育訓練，在業務調研階段，我們可能要答複使用者一些概念性問題，在現場驗證推廣階段，可能我們要花費大量時間傳授軟體功能，在輔導上線階段，更是要随時解答使用者疑難問題。

　　好的教育訓練可以讓使用者熟練掌握實施方法，自主推動項目，增強對項目認同感，可以大大減少軟體公司現場服務難度和時間，效益十分顯著。

　　作為一個IT項目經理，一個很現實的問題就是，很難一個人在一段時間内隻負責有限個項目，越是商務能力強，單子越多的公司，這個問題越突出。

　　很多IT項目經理或實施人員不得不周旋于多個使用者，忙得焦頭爛額，疲于奔命，使用者并不領情，因為使用者覺得你對他不夠重視，服務品質并不高。

　　一個很有意思的情況就是，很多使用者強烈要求我們要保證項目的人力投入，要求派實施人員長駐現場，我們很多實施人員也的确長期在使用者現場蹲點，但事實上這樣效果好象也不明顯，很多項目推進依然并不順利。

　　要是一個人同時負責兩個在進行項目，蹲點必然是治一經損一經。往往因為不能經常性服務一個項目，導緻一些小問題會積累成大問題，最後即使去現場推動成本也很高。

　　一個項目經理或實施人員，應該強迫自己考慮這麼一個問題：一個人到底可不可以同時負責3~6個項目？到底有沒有辦法做到這一點？

　　如果一個人負責多個項目思路可行，而且服務品質還能被認可，大概在目前業内你才有可能獲得相對理想的收入，否則實施生涯就是一場痛苦混亂的經曆。

　　有的人說：當然可以，你給我配置3~6個人，我就可以同時負責3~6個項目。

　　沒錯！這個思路實質上是說如果你在一個項目中有替代者，通過替代者幫你行使一些相對容易的工作，你就可以集中精力多做一些複雜的工作。這幾乎是唯一的辦法，至于形成一個團隊，三個蓋子五個杯，通過排程讓每個杯子都能蓋一會隻是一種補救管理排程手段。

　　這種排程能力會随着蓋子和杯子絕對數量增加而變得脆弱不堪。而且一個項目人員如果經過不具備穩定性，資訊溝通失靈，資訊不對稱現象将非常突出。

　　如果軟體公司不能給你配置或排程替代者的話，怎麼辦？

　　答案就隻有一個出路，在企業培養替代者。

　　如果我們充分重視使用者教育訓練工作，讓使用者也成為可以獨立實施我們軟體的人，不也就一樣達到了配置人員進行實施的目的？這樣就象我僅僅隻需要給我的替代者一定時間指導，前期可能現場多一些，後期可能電話多一些，有了替代者，同樣可以達到管理項目的目的。

　　是以我個人經驗就是在項目中教育訓練工作的根本目的是讓使用者在很短時間内可以自己獨立實施項目，而不是僅僅會用某些操作。

　　如果僅僅是會用某些操作，當項目遇到大量困難的時候，使用者還是會找軟體公司，希望通過軟體公司的手推動很多事情，但是别忘了，當企業自己本身沒有或者找不到推動一件事情的動力的話，很難想象軟體公司有多大的作用。

　　不過有意思的就是，很多使用者高管非常贊同我的想法，教育訓練的目的就是讓企業可以自己推動資訊化工作，不能總是依賴軟體公司某個人或軟體公司。

　　一個實施人員和使用者系統管理者的差别到底是什麼？

　　我們強在軟體技術全面，而使用者系統管理者隻需要知道和他們相關内容部分維護即可；

　　我們強在靠體系化方法推進項目，而使用者系統管理者更善于利用企業實際潛規則推進項目；

　　我們強在一些思路理念比較清晰，但使用者系統管理者更了解企業實際情況和業務特點。

　　是以如果我們能把我們的技術、方法、理念傳遞給使用者核心成員，或者是系統管理者的話，我們就可以在企業培養一個有效的替代者，這個替代者如果有足夠動力被激發，能發揮作用和能量可能比我們自己都要大。

　　讓使用者控制項目，我們提供軟體工具和智力幫助，這将是現階段中國IT服務的有效生存之路，如果服務可以收費，使用者且願意外包，才可以主動替代使用者實施推進項目。

　　實施人員對教育訓練目的要有一個清楚的認識：幫别人就是幫自己。

　　要想少出差，就得讓使用者在現場能獨立工作。

　　實施工程師最好的選擇就是讓使用者可以自己實施正常功能，而且要灌輸一個重要理念軟體公司的工作隻是保障項目所運作業務需要的産品功能完整可用，而不是幫助企業利用軟體做業務錄入資料，那是企業自己的事情，而且隻有企業自己也可以獨立實施維護軟體了，軟體的實施才是真正成功和有保障。

7.2 教育訓練工作在項目實施中作用(中)(連載四十六)

7.2.1 使用者能不能培養成替代者？

　　有的人說，使用者怎麼可能在很短時間内就具有獨立實施項目的能力？

　　第一使用者不象我們有專門時間學習和教育訓練，第二使用者不象我們有足夠動力和壓力。

　　我自己個人在項目實施中體會是不要低估使用者的智力和毅力，的确不是所有項目使用者都具有被培養的潛力，但在很多項目中，從來就不缺乏能夠培養成為一個好的實施者的使用者，而且這樣的人隻要一個就足夠了，隻是我們自己并沒有花時間去找到一個大家認可這樣的一個人而已。

　　使用者雖然沒有太多時間學習教育訓練，但衡量我們教育訓練工作的品質标準，就是看教育訓練有沒有做到在很短時間内将一個人快速培養成材，可獨擋一面。

　　我們很多教育訓練并沒有達到這個目的，那說明我們還需要在教育訓練工作上想辦法，動腦筋，而不是簡單将事情歸結為複雜，隻會說一件事情複雜的人不如說自己無能更妥當一些。

　　更何況在單個項目上使用者對很多操作可以不必知道，學習工作量并不象完整教育訓練一個實施人員那麼大。

　　第二使用者也有業務上壓力，項目上壓力，也有自我突破，學習新技術的動力，未必不願意配合我們工作，何況我們隻是找一些核心的使用者，有心的使用者進行高強度教育訓練，不是要求所有的人都有同等能力。

　　我們再看一看一個軟體公司新進人員在多長時間内必須獨立去現場工作？最多三個月。短短三個月為什麼他就可以去現場工作呢？就是因為教育訓練。

　　另外再想一個問題，這三個月他一直在接受教育訓練嗎？顯然不是，好象隻是簡單教育訓練了一段時間，可以入門了，然後就通過查閱資料和請教方式去自我成長。

　　其實學習軟體很少有靠人手把手教出來的，基本上高手都是摸出來的。而且在摸的過程中往往是在一段時間内高密度的研究一個軟體，直到明白。以後即使這個軟體功能上有什麼擴充和發展，學習成本将非常低。

　　在最短的時間内做最大量的事情，這就是成功将使用者培養成替代者的秘訣。

　　成功的教育訓練周期一定不長，一定是在最短時間内不斷反複強化某些業務環節操作，形成習慣。

　　不要指望使用者自己會自動自發地在一段時間後掌握操作，而是在一段時間内大量練習，強化掌握後再逐漸琢磨如何應用，逐漸熟練後達到一個很高的境界。

　　很多使用者并不缺乏IT知識，隻是不太清楚具體軟體操作和對架構的了解，由于熟悉業務，對軟體和業務工作結合點價值點的認識和了解可能比我們自己還要強。

　　對這樣的使用者，換句話說我們已經弄懂的東西傳授給使用者恐怕并不需要三個月。我們一個項目實施周期短的話也要半年，長的話要兩三年，這麼長的一個周期内，居然一個實施人員安排不出來時間給使用者教育訓練，而且教育訓練到可以達到獨立實施的能力。

　　這種現場自我檢討，更多的是我們在工作意識上，工作方法，甚至我們自己對軟體了解操作熟練程度上有欠缺，是以導緻我們軟體能力無法傳遞給使用者，也得不到認可。

　　就我本人實施工作實際體會，無論是國營企業還是民營企業，無論是大企業還是小企業，絕大部分都可以培養使用者實施者。的确有的企業做這件事情難度大些，成本高些。

　　但無論怎麼樣，我們有無極強烈意識在企業建立一個項目團隊，讓項目團隊得到資源保障，讓項目團隊關鍵人員推動項目實施，一旦發現項目中這種情況和局面不存在，就想千方百計去做到這一點？

　　這就是我們能否培養替代者的關鍵意識。你認為可以，可行，你就會去做。

7.3 教育訓練工作在項目實施中作用(下)(連載四十七)

7.3.1 教育訓練工作為什麼品質不高？

　　坦率的說，我們現在整個行業教育訓練工作品質是不高的，至少是參絲不齊的。我個人認為主要原因有四：

　　第一缺少高品質的按業務組織的教育訓練教材。

　　很多軟體公司，特别是管理軟體公司并沒有一套完整的結合業務的教育訓練教程，更多的是功能手冊和配置手冊，這樣的内容很難了解，更不能傳授能力。

　　很多對軟體有興趣的人并不需要太多時間指導，但一定要給他很容易上手的教程。是以國内很多人都可以自學複雜的CAD軟體或三維設計軟體，坦率的說這些軟體操作比任何一個管理系統還要複雜，但很多人就是可以自學，和教材豐富有關。

　　第二教育訓練者的能力缺少驗證。

　　我們很多軟體實施工程師強在技術能力，弱在業務了解力和表達能力，到對得上一句俗語，茶壺煮餃子，有貨倒不出。對于技術型人員主動教育訓練使用者在心理上也是一種挑戰。

　　可能有的人是心裡明白，就是說不清楚，讓人看着着急。

　　心裡明白，表達能力不足還好，更糟糕的是很多人心裡也不明白，或者是半瓶醋，在那裡裝明白，典型的小黑蒙大黑，最後使用者說天下烏鴉一般黑。

　　在标準業務教程沒有到位的情況下，要對教育訓練者教育訓練工作進行主動考核和管理，才能保證教育訓練品質。

　　其實辦法很簡單，學校招老師是如何進行的？試講！如果你還沒有準備好手冊，并不等于不可以傳授知識，那麼就請你講内部公開課，沒有達到清晰明白講清楚軟體功能和業務的人員首先自己加強教育訓練。

　　第三不重視教育訓練工作。

　　很多實施人員總覺得教育訓練很多細節給使用者很麻煩，我把所有配置都調整到位，系統到了一個可用的狀态，然後你要掌握的操作就是那麼幾步，我把這些都教給你，不就完了？然後我再提供一個業務手冊，你參考看看，不就行了？幹嗎要花費大量時間和精力在現場教育訓練，又不是沒有事情做？

　　甚至有的人可能還在想，軟體還有問題，我精力應該放在解決問題上，而不是教育訓練。

　　結果無論人在現場不在現場，大量時間都是一個人在忙碌的配置調試，然後請使用者檢查驗證。然後好早點走人，去下一個現場解決問題。

　　欲速而不達，這樣的項目越是到了大規模推廣時實施人員越頭痛，根本不能走開，一走開就出問題，大量的出問題，别的項目要是同時推廣，實施人員的行程幾乎就是難以兼顧，自己就不要做任何休息了。

　　是否重視軟體教育訓練，千方百計想辦法讓使用者會用，好用，愛用軟體，是一個好的實施人員的價值。

　　第四忽視軟能力教育訓練。

　　很多軟體教育訓練工作，特别是管理軟體教育訓練工作不僅要教育訓練功能，還要傳授實施方法。

　　要告訴使用者遇到問題如何分析，是需求還是缺陷？分别如何處理？

　　要告訴使用者如何判斷實施阻力，軟體實施到哪一步可能會有什麼困難，如何化解？

　　要告訴使用者你應該如何教育訓練其它的同僚，如何将能力傳遞擴大？

　　如何界定一個項目邊界和近期目标，并逐漸實作，所有實施人員都應具備的軟能力，這都是要傳授給使用者的，這樣使用者才可以真正起到一個管理控制者的作用，這樣的使用者才能獨擋一面，也會通過項目實施得到在企業内部的肯定和認可，也就有實施的動力。

7.4 教育訓練工作應如何組織？(連載四十八)

要準備一次成功的教育訓練，要考慮一下幾個工作，首先是教育訓練内容策劃，然後教育訓練計劃編制和确認，然後是具體教育訓練組織工作，最後是教育訓練考核和回報。

　　7.4.1 教育訓練内容策劃

　　教育訓練前要根據不同教育訓練對象，不同教育訓練内容，不同教育訓練階段，不同教育訓練師資進行内容策劃。

　　要針對使用者層次，實施階段設計教育訓練主要内容。

　　想好每個階段目标使用者應掌握的内容，作為自己實施目标中一部分，并通過相關教育訓練活動達到。

　　一般教育訓練内容可分為：

　　業務調研教育訓練，重點在告訴使用者我們工作方法和互相溝通配合方式；

　　解決方案教育訓練，重點在告訴使用者我們軟體業務模型和整體實作思路；

　　功能驗證教育訓練，重點讓項目組或系統管理者掌握軟體基本操作，進行功能驗證；

　　輔導上線教育訓練，重點在讓一般使用者掌握相關部分業務操作，讓系統管理者可以掌握常見配置和維護工作。

　　教育訓練策劃還包括選擇教育訓練對象，不是企業每個使用者你都要教育訓練的，而是選擇一個或幾個重點使用者教育訓練，确定其掌握基本能力，然後輔導重點使用者教育訓練别的使用者，逐漸擴大影響。

　　如果企業比較大，還需要策劃分幾批教育訓練，分别教育訓練什麼内容。

　　教育訓練策劃還包括如果将教育訓練工作成果彙報給企業，并形成共識。

　　而且一旦有重點使用者可以在實施人員輔導下獨立培養别的使用者操作了，或者進行了大面積普及操作教育訓練并達到目的，要立即給企業上司彙報，除了彙報成績确定項目進入一個新的裡程碑外，彙報一方面要求企業主管上司表揚這樣的使用者，保護其積極性，一方面也要企業上司知道，我們是真的來做好項目，是以我們不但提供軟體，還在真正為企業培養自己的資訊化實施人才，别忘了這是很多項目招标時的要求。

　　這裡面通過彙報也對企業上司進行了教育訓練，灌輸了我們是工具，我們是智力支援者，不是實施主體的理念，如果軟體有問題，我們來解決，如果軟體沒有問題，企業要自己用軟體功能在我們指導下主動解決問題。

　　而且讓上司知道了如果遇到問題可以請企業自己中誰負責解決，實際上也幫重點使用者提高了在上司面前的曝光率，肯定有好處。

　　教育訓練策劃還要考慮教育訓練的地點和成本，包括人力成本和時間成本，一定要合理安排，高效緊湊。

　　7.4.2 教育訓練計劃

　　教育訓練策劃的階段成果是教育訓練計劃，教育訓練前要将教育訓練計劃制定好并通知到最終參加教育訓練的使用者，這是很重要的工作。

　　教育訓練計劃應該先在内部經過大家确認，落實資源後才能送出使用者。

　　一份完整的教育訓練計劃要确定教育訓練目标，詳細分解教育訓練時間、教育訓練内容、教育訓練師資，說明教育訓練地點、簽到方式和考核方式，讓使用者提前做到心中有數，友善準備。

7.4.3 教育訓練組織

　　教育訓練計劃編制前要和相關教育訓練資源進行溝通，确認是否可按時間進行教育訓練工作，同時要檢查教育訓練場地是否足夠，是否有足夠資源上機練習，是否有其它必要裝置，等這一切就位後還要和使用者确認最終教育訓練人數，時間安排和其它相關可能工作。

　　如果使用者是到軟體公司教育訓練，還要落實使用者的餐飲安排，住宿安排，接送安排，參觀安排，訂票安排，禮品安排，并列計劃報公司準許認可後執行，這些都是一次成功教育訓練組織中要考慮的工作。

　　教育訓練組織要特别重視教育訓練環境的品質，高品質的教育訓練環境應提前準備好相關軟體環境，并調試通過，不要等使用者開始上機才進行安裝。

　　教育訓練組織中最重要的工作是完成教育訓練教材的編制，并送出稽核或主動安排稽核。

　　稽核教育訓練教材的方法有兩點，一是确認教材思路是否清晰，細節是否完整，二是看教育訓練者講解是否易懂，和教材一緻。其中對講解能力的驗證要更強于教材的驗證，沒有教材一樣能做好教育訓練，沒有好的輔導講解能力，很難做好教育訓練。

　　基本上很多公司對這個工作是忽視的，也是沒有人負責的，這是一個很大的問題，這種事情驗證成本并不高，因為可以采用認證資格的方式進行，一個好的教育訓練人員，對其教育訓練能力的驗證在一段時間内隻需要驗證一次就行，而這個能力至少可以在一年内發揮巨大的作用。

　　本人親自檢查過很多對軟體的講解，說個不中聽的話，這樣的教育訓練能讓使用者明白我們是幹什麼的都難，别說讓他跟着你走，按共同的意圖推進項目。

　　此外教育訓練教材中資料錄入規範也是教育訓練重點内容，這個講解倒不難，實施人員要結合企業實際精心準備是關鍵。

　　資料錄入規範準備要點有三條：

　　1、 習慣填寫方式說明及樣例

　　2、 正确填寫約定及樣例

　　3、 常見問題處理方法

　　7.4.4 教育訓練考核和回報

　　教育訓練效果如何要從兩個方面去驗證，一是對使用者掌握程度的了解，這就要通過教育訓練考核去完成。

　　一方面要了解我們教育訓練的品質，這就要通過教育訓練學員的回報來了解。

　　任何集中完整教育訓練工作都要提前結合企業實際業務準備适當難度教育訓練考題，這也是教育訓練審查工作内容之一。

　　教育訓練成績原則上要回報給個人和企業相關組織機關，這樣才能形成一個回報激勵機制，我們可以采用“優秀鼓勵，落後不提，以先進示範帶動整體提高”的政策促進教育訓練深入開展。

　　第二教育訓練完成後，要請學員填寫教育訓練效果回報表，這樣對教育訓練老師形成一個反限制，為了讓教育訓練學員有一個好的效果回報，就不得不精心準備教育訓練工作，而不是敷衍了事。

　　考慮到實作成本和實際能力及企業情況，考核和效果回報表可能不太容易操作，但從長遠來看，有沒有教育訓練考核和回報的教育訓練工作品質一般是兩個檔次以上的差距，這也是一個客觀規律。

　　教育訓練效果回報表要送出給教育訓練老師和公司相關教育訓練管理部門，由其安排進行教育訓練改進工作。

　　7.4.5 好的教育訓練行為習慣

　　随時随地随人随事的教育訓練

　　教育訓練的工作并非一定要專門的時間專門的地點進行，實施人員要利用一切機會用各種易于接受的方式将思路、操作或配置傳遞給使用者，并随時從使用者處獲得回報，改進内容。

　　在教育訓練中互相學習

　　教育訓練過程一方面注意傳授内容給使用者，也要抓住一切機會向使用者學習業務知識，業務知識越多，今後教育訓練準備也就越到位，教育訓練内容也就越生動。

　　随時記錄教育訓練中發現的問題

　　教育訓練過程中會經常出現一些使用者提出的問題，很多都是很好的改進建議，要立即記錄，并回報給公司對軟體進行持續改進。

7.5 教育訓練注意事項(連載四十九)

　一定要事先準備好業務手冊或者教育訓練教材，沒有教材的教育訓練工作品質無法保障；

　　教育訓練過程中比較好的講解思路是：

　　先講業務後講思路

　　先講思路後講操作

　　先講操作後講配置

　　先講配置後講維護

　　教育訓練過程中如果沒有投影可以充分利用各種工具軟體實作同步教學，例如“NETMEETING”工具實作多台電腦同步放映。

　　上機輔導一定要有人陪同，主動答疑。

　　教育訓練操作要先手把手操作示範一次，示範後立即要求使用者練習幾次，确定使用者掌握後才能結束一次教育訓練輔導。

　　在教育訓練中要及時大膽誠懇鼓勵使用者的每一個進步，在教育訓練過程中完成軟體思路和管理理念灌輸和教育訓練方法的灌輸。

　　傳授使用者如何記錄軟體缺陷和分析缺陷的方法，讓使用者可以按照要求提供此類資料，減少自己為了一個小問題去現場的機率。

　　傳授使用者用各種遠端協助工具進行軟體輔導的方法，讓使用者适應線上輔導，減少出差成本。

　　7.6 總部教育訓練

　　7.6.1 為什麼要考慮到總部安排教育訓練？

　　有的時候現場教育訓練使用者經常受工作幹擾，無法連貫進行教育訓練活動，有的時候使用者主動希望到軟體公司進行教育訓練，總部教育訓練也是教育訓練策劃中一個内容，是安排到總部教育訓練還是在現場教育訓練，是要根據使用者重要程度和效益來評估的。

　　對于一些大型項目，特别是使用者執行力不夠，現場教育訓練效果不佳的項目，安排一次緊湊合理的總部教育訓練會收到很好的效果。比起在現場反複教育訓練，每次教育訓練效果都不到位，一次緊張有序的總部教育訓練往往成本更低。

　　而且在軟體公司教育訓練使用者換了環境，可以協調更多人和使用者交流，使用者此時更容易接受我們的管理思路，并達成一緻，有利于後續工作推進。

　　在總部教育訓練還可以和商務進行協同，搞好接待工作，有利于建立個人交情，使用者也願意在後續工作中配合我們開展工作，了解我們工作流程，按照我們制度配合，而不是簡單埋怨責怪。

　　是以總部教育訓練是很好的一個教育訓練組織方式。

　　7.6.2 總部教育訓練經驗

　　很多使用者要求到總部教育訓練，實施人員或者客戶經理隻給公司一個通知，人就送過來了，使用者到總部教育訓練，至少要做好三個準備工作：

　　和公司教育訓練負責人事先排好計劃，溝通資源，確定到位

　　和客戶經理一起安排好接待工作，盡管很多使用者我們不負責住宿餐飲遊玩，但從中國實際情況出發，在成本接受範圍内，适當安排一些招待遊玩，根據使用者報帳水準落實好使用者飯店和訂票，這些細節會極大提高使用者對我們認可程度。

　　確定教育訓練工作有實施項目組成員參加，總部教育訓練一個重要目的不是簡單讓使用者掌握操作，而是讓使用者變成項目主體實施者，也就是自己人，是以無論是現場教育訓練還是總部教育訓練，項目組一定要有人和使用者泡在一起，隻要使用者還沒有走，就必須時刻有人輔導和教育訓練。

　　我們有的項目教育訓練實施人員沒有親自參與，或者晚上使用者上機練習，自己因為遠就先回家，都是因小失大，你如何對待别人，将來在項目中使用者也是如何對待你。

　　總部教育訓練結束後，一定要做好教育訓練備忘錄，讓使用者回去對其公司負責人有個明确交代，至少要說明我們的工作品質是沒有問題的。

8.1 現場推廣工作可進行條件？(連載五十)

　如何通過現場推廣讓使用者項目快速上線，是很多實施工程時關注的問題。如果一個項目非常簡單，和以往工程基本類似，那麼輔導上線就非常輕松，根據企業業務和産品特點做好業務手冊和應用規範，直接安裝調試，驗證無誤就可以大面積推廣，實施周期可以大大縮短。但對于很多大型項目，有很多不确定性或個性的内容，要進入現場推廣階段需要做很艱苦的工作。

　　在一個項目實施過程中，如果要想讓現場推廣工作快速有效進行，其實是需要做大量高品質的前期工作，現場輔導系統上線應用不過是一個很自然的結果。

　　現場推廣工作可以進行在具備四個條件情況将非常順利：

　　1) 經過充分現場功能驗證，确定産品功能基本能連串起一個或幾個基本業務流，并得到使用者項目組書面認可；

　　2) 産品的穩定性和性能在可預見并發環境下性能能達到可使用要求；

　　3) 針對基本業務流的業務操作手冊全部編制完成，并對相關使用者完成教育訓練；

　　4) 使用者和軟體公司都可以投入一定資源，主要是使用者方有可獨立推廣資源。

　　軟體功能能不能支撐一個業務是進行現場推廣的最必要條件，很多人為了項目交差或者應付使用者，匆忙裝機、配置和輔導，最終使用者發現用起來不是很順利，經常出現BUG，或者對業務支援并不能達到要求，對軟體就失去信心，再來推廣，阻力就大，非常困難。

　　功能可以支援的情況産品穩定性和性能也很重要，如果産品穩定性和性能不足，項目往往也容易陷入停滞。

　　至于業務手冊和使用者推廣資源也是順利進行現場推廣的必要條件。

　　實際項目實施過程中，往往是這些條件都不能滿足的情況必須進行現場推廣，否則無法将項目推進到一個階段，得到使用者認可，以便驗收回款，但實際上效果并不見得容易達到。

我個人體會現場推廣順利不順利，其實不在現場時間長短，而是你為現場推廣準備工作細緻程度關聯性更強。要想出差少也能控制項目，就必須尋求合理的項目控制政策。

　　8.2 現場推廣工作為什麼進展慢？

　　很多項目在快速完成業務調研和基本配置之後，就好象進入了一個平淡期，業務已經似乎清楚了，配置也按要求完成了，但使用者好象就是沒有什麼用，大部分人也沒有積極性，項目進入了一個僵持期，為了推動項目企業項目組或資訊化負責人不斷催促我們實施人員進入現場，推動項目。

　　而我們的實施人員也非常努力地在現場推動，推動，再推動，直到推不動，項目成為一個胡子工程或者是拉面工程。

　　項目現場推廣時間無限延長對使用者，對軟體商，對實施人員都是一種極大的傷害和折磨，我們認為項目推廣時間無法确定或者确定後無法結束恰恰是一個項目失控的症狀。

　　泡現場其實是典型的項目失控特征之一。

　　我們可以分析為什麼經常出現使用者要求實施人員來泡現場？

　　從實施的角度來看，無非是以下幾種原因或原因的綜合。

8.2.1 軟體總是出問題

　　很多項目從一開始到現場推廣是一段痛苦的經曆，在推廣過程中簡直就是軟體捉蟲記。不斷往前進一步，不斷發現新的嚴重影響使用的BUG，導緻項目停滞，去解決BUG，往往要耗費大量時間，然後再費盡力氣再進一步，再發現BUG，再暫停，再去解決BUG，如此形成一個惡性循環，項目走走停停，周期不斷延長，使用者失去信心，而且覺得我們工作品質太低，慢慢不相信我們，對我們充滿抱怨。

　　軟體存在問題是客觀的，沒有不存在BUG的軟體，無非是多少嚴重程度的問題。這應該是一個理智實施人員開始工作的限定條件：用可能存在BUG的系統解決問題。

　　但是我們往往犯的一個錯誤，人總是有意識無意識假定軟體就應該是沒有問題的。無論是使用者還是實施人員都有這樣的心态。

　　如果軟體總是存在BUG，規劃在幹什麼？開發在幹什麼？測試在幹什麼？那麼多管理流程和制度為什麼不能保障？在我們的宣傳往往又是穩定可靠的情況下很多人對這些事情就有了一種反感和抵觸的情緒，進而認為自己現場工作不順利，都是公司的錯，都是軟體的問題，我是無能為力的，出現這樣的心态才是最大的問題。

　　其實我們現在已經明确了，軟體發現BUG是肯定，這是我們可以預見的項目風險。我們作為一個實際項目控制者，必須采取主動的項目控制對策，才能有效管理項目。

　　這個時候最有效的方法就是加強對軟體的驗證，根據自己項目業務過程，不斷測試，發現是否存在嚴重問題，并采取相應的對策解決。

　　如果不是嚴重問題，可以先尋求替代方案(尋求替代方案可以是群策群力的過程)，不影響項目實施進度，然後讓公司規劃部門将其納入可接受的版本規劃時間，如果公司響應能力不足，我們将要把其作為項目風險提前和使用者溝通，尋求支援和了解。

　　如果存在嚴重問題，肯定影響項目進展，就應該全力在公司推動解決BUG，然後再去現場更合适。

　　否則到了現場問題響應不及時，被使用者指責之下非常容易被動，失去對項目的控制權。這個時候實施人員要麼隻好無原則承諾我們開發會解決來轉移自己的壓力，然後讓公司承擔大量開發響應申請，要麼隻好表示我們一定來解決問題，大量時間在現場推動一些無關重要的細節。

　　真正明智的實施人員一定會自覺花費大量時間做業務流驗證，確定項目功能可用夠用，能夠支撐一個或幾個完整業務流，沒有重大程式隐患才會去現場推廣。

　　在軟體某些業務存在極大問題的時候項目團隊不應該去現場，而是推動這些問題解決完成才能去現場，去現場時間多少不會成為使用者是否認同我們的标準，去了能否解決問題才是使用者是否認同我們的最後标準。

　　可以少去不去，但是每次去之前一定很清楚自己能解決什麼問題，哪怕是很小的一個問題，解決問題完成教育訓練，落實使用者自我計劃就可以回來。

　　如果軟體發現還有問題卻一定要去現場，前提就是你還有其它可選擇的業務方案或管理行為要去解決，這些問題可以和發現的問題獨立存在，無關緊要。

　　有的實施人員可能抱怨，為什麼一定要我在公司推動這些事情，其實這倒未必，一個好的實施人員發現一個項目存在問題，可以及時反應到公司，通過軟體配置管理和開發流程解決，但一定要按照配置管理要求把項目情況反映到位，如果反映不清楚才需要到公司協助，多出來的時間就可以多響應一些項目，這樣一個實施人員同時響應兩到三個項目是很容易做到的。

8.2.2 要推廣的業務流不完整(連載五十一)

很多項目也做了一些驗證工作，到了現場随着業務的展開，還是不斷發現BUG。這就說明我們并沒有建立一套可獨立推廣的完整的業務流，隻能說在項目實施過程中我們隻就部分業務流進行了驗證，到了現場才發現實際業務情況并非如此，因而又陷入困局。

　　而能否拿出完整的可操作業務流推廣方案是項目調研品質緊密結合在一起的，項目調研完成後，一定要可以拿出完整實作的業務流實施思路和方案，這也是自我評判實施調研工作是否完成的一個尺度。如果調研完成了，隻有一堆細節資訊，卻沒有完整的業務流架構，這個調研對實施而言就不能算成功，這個階段工作也就不能算結束，還要花時間搞清楚為止。

　　但我們在調研過程中未必一定要搞清楚所有業務流和實作方案才能往下走，我們可以先解決完一個業務環節再往下走，把企業複雜的業務流程化整為零，形成相對完整的部分，用一個清晰效益目标牽引或做為願景，促成企業一個業務流程一個業務流程不斷前進。

　　但對于單個業務流程而言，配置一定要完整，一定可以看到用這個系統把企業實際中哪一件事情真正走完了，然後還比較友善，甚至是前期不友善，但可以完整實作。

　　如果實施不能得到這樣的幾個業務流方案，并反複站在使用者的角度推想可能存在哪些問題，驗證的品質就不會高，也不可能在現場順利推廣。

　　如果每個項目都能做成一個完整業務流，隻要有10個成功的項目，軟體在很多方面就會達到非常優化好用的狀态，再進行推廣經驗的移植效益将極大發揮。

　　8.2.3 和使用者就推廣實施方案沒有達成一緻

　　有的時候，實施工程師也拿出來一些業務實施方案，但一進入推廣，使用者并不認可，要求按自己的思路來，這樣經常是邊推廣，邊争論，然後不斷調整推廣目标，下面的人就等待觀望，我們不得不調整部署，重新開始實施過程，甚至是軟體配置和功能驗證過程。

　　這樣看來有清晰的業務實施方案也未必就能順利推廣，業務推廣還必須和使用者項目組達成一緻意見。要和使用者達成一緻，并非是某個業務可用不可用，而是我們是否可以找準使用者也可以認可的價值點。

　　舉一個例子，我們很多項目要求使用者入庫資料，以友善今後圖檔的管理和查詢。很多使用者一實施就不認同，反而要我們上工作流或項目管理。這樣就項目推廣目标沒有達成一緻，結果就容易反複，反複後使用者可能發現沒有基礎資料工作流和項目管理也跑不好，最後還是搞基礎資料錄入，但一上一下的折騰過程中，大部分使用者可能已經不看好項目實施。

　　為了讓使用者認可推廣目标對應的業務流，我們往往要想好關于業務價值的說辭，這個說辭推導要有力，而且有資料事實證明，而且有可清晰看到的價值，這樣的業務才可能有人跟着走。

　　換句話說，你想讓别人做什麼事情，一定要有一個可以看得到或者想象得到的效益可期待，否則業務推廣目标很難達成一緻，即使使用者同意按你的思路去做，最終也一定反悔。

　　就以我們說圖紙是否可以友善查詢是很重要價值點為例，如果僅僅強調這一點使用者開始可能還不覺得，一旦錄入資料開始就覺得怎麼資訊化盡是幹苦力活？積極性很快就會演變成阻力。

　　是以要推廣自己的業務流一定要和使用者項目組就推廣目标達成一緻，達成一緻才能快速推廣。

　　事實上我們要先和使用者分析如果圖紙不好找有什麼後果？能舉幾個真實的事例嗎？如果好找真的有效益嗎？為了這些效益值得我們投入這麼大成本去做嗎？如果遇到阻力上司會支援我們嗎？

　　這些效益和目标經過反複設身處地的換位思考，和使用者項目組達成一緻了，才能成為項目推廣順利進行創造條件。

　　目标明确了隻能說是大方向的事情落實了，和使用者項目組要達成一緻的事情還包括具體的政策，如何做才能保障這個目标實作？這個思路也要達成一緻。

　　還以圖檔管理為例子，原來的圖紙不好找，需要解決，這個目标認同了，不等于事情可以啟動了，還要和使用者組就如何管理的方案達成一緻。

　　那麼在系統如何管理圖紙呢？我們可以以産品結建構立樹狀視圖，我們可以根據各種特征建立分類視圖，我們可以根據階段建立項目階段輸入輸出視圖，我們可以根據檔案類型建立關聯視圖等等，這些思路也要先和使用者項目組達成一緻，讓他們覺得這些思路和方案不但能夠解決問題，而且以往管理上的一些優點也可以被繼承，這樣的方案才比較有推動力。

　　管理的思路明确了，如何去做也要考慮清楚，而不是走一步看一步。

　　我們是安排專人錄入資料，大家去利用，還是安排每個人都錄入一些資料，逐漸積累，我們是從新産品開始積累，還是把老産品資料也立即錄入系統，我們每個人每天可配置設定工作時間大概是多少，這個時間段經過教育訓練可以錄入的資料量是多少，這樣按一周資料錄入量計算全部圖紙錄入完成大概需要多長時間，能否在系統實施可接受周期内，如何保障每個人的資料錄入時間，如何組織教育訓練，確定每個人都可以掌握操作。

　　這些工作細節都需要溝通确認，而且計劃分解得越詳細，執行力越強。因為所有最複雜的事情都變成了很簡單很小的獨立工作，每個工作完成需要的技能都很單純、時間很小，在落實時阻力就小。

　　如果思路得到确認，我們就可以和使用者項目組一起建立一個計劃，落實我們的設想，再發動大家按計劃運作。

　　一旦計劃确定，要立即行動，我們應按計劃高品質完成工作，然後就是催促使用者項目組按照計劃完成他們的任務，并提供技術支援，這個階段我們要明确技術支援階段我們就不需要大面積現場工作，除非有系統不能解決的問題

　　如果使用者按計劃在執行，我們還需要不斷主動了解進度，形成一種進度回報，根據進度快慢采取适當措施保障項目目标在實施周期内實作。

　　實際上通過和使用者就實施方案達成一緻，我們也就傳授了一個很重要的項目管理套路：認同目标，明确政策，建立計劃，立即行動，不斷回報。可以說任何事情隻要這樣做，就很難失敗。

8.2.4 沒有激發使用者的主動性(連載五十二)

一般情況下現場推廣很多使用者認為主要是靠軟體公司來落實，的确在很多企業由于體制觀念的原因，在這些方面需要軟體公司多做很多工作。

　　但實際上一個項目大量依賴軟體公司人員推動，這個項目失敗機率會比較高，越是成功的項目，使用者主動性越強，使用者才應該是項目實施的主體。使用者自己的項目不是使用者自己實施，卻要依賴我們實施，這樣的項目我們如何成功？

　　我們之是以推廣失敗往往是我們把自己思路給使用者一描述，甚至沒有什麼描述，就悶頭大幹，使用者不知道如何參與我們工作，隻好去監督我們，成為項目的監工，而他們又不清楚系統的思路和實施套路，隻能按照上司意圖來給我們施加壓力，而不是和軟體公司一起分擔壓力，這樣進行的項目自然難以受控。是以我們這樣做的都是事倍功半的工作。

　　把使用者，至少是使用者項目組變成可實施的力量，并幫助他們推廣實施項目，而不是依賴個人力量推動實施，把他們由項目監工變成項目執行者，我們成為監工和顧問，這樣的實施才輕松有趣。

　　讓使用者真正參與項目實施工作，雖然使用者累一些，但大家有了團隊的感覺，心情反而更愉快，說個套話：往往在這個階段和使用者建立了戰鬥的情誼，為今後驗收回款參觀都奠定了牢固的基礎。

　　是以我們在項目推廣方案中要反複強調和貫徹這一思路，并得到使用者認可，在實際工作中落實，而且使用者掌握的技能要清晰寫進備忘錄，這樣就可以請他們中具有相關技能的人去解決問題。

　　例如軟體安裝，我們可以和使用者約定，我隻示範裝3台，然後安排使用者方面的人裝3台，我們在旁邊看，如果連續三次都成功，我們認為基本上問題不大，其它的都可以交給使用者處理，我們隻需要處理意外問題。

　　又例如進行某個業務操作教育訓練，我們先要經過講解示範，确定使用者項目組明白，立即請使用者項目組操作，确定他們掌握了操作，那麼後面的教育訓練可以主動邀請使用者項目組成員講解，我們提供技術咨詢，今後教育訓練工作策劃組織都可以逐漸傳授給使用者項目成員負責，最後一般問題基本不需要我們出馬，大面積基層使用者都習慣和自己人交流解決問題，我們隻負責解決軟體的疑難雜症，而且某個業務被大部分人熟練掌握後，我們的工作主要就是新的業務流推廣方案驗證設計規劃，還有保障項目進度的相關管理活動。

　　這樣一輪輪循環，就可以讓使用者項目組慢慢成為實施的主體，而且在這個過程中使用者項目組成員可以得到極大能力成長和進步，他們也會感謝我們的幫助。

　　一到現場工作，任何時候都要确定這個遊戲規則：

　　實施推廣以項目組為主，我們負責技術支援，負責推廣實施能力的傳幫帶；

　　一旦實施能力轉移了，我們并不需要經常來現場工作，因為我們來現場工作成本極高；

　　一般情況下我們隻需要在現場解決問題，教育訓練技能，達成後續工作計劃，完成本次業務目标就必須傳回。

　　我們不能解決問題的時候，我們會全力促成問題解決，一旦解決我們第一時間安排現場響應，但如果我們解決不及時不順利我們會第一時間通報，也請使用者了解支援。

　　不過坦率的說，很多實施工程師本身也不知道如何做這件事情，思路也是亂的，也不會做計劃，這樣的話去激發使用者就缺少個人魅力和行動能力，就隻好親力親為，被動響應，這個時候為自己能力不足付出代價也是沒有辦法的事情。

　　8.2.5 光打雷不下雨，缺少高管支援

　　很多時候僅僅和使用者項目組達成一緻意見還不夠，還要和使用者高管達成一緻。否則在項目遇到阻力的時候，得不到更多資源響應。

　　達成一緻的實施方案要給使用者高管彙報，彙報要點不在軟體功能實作和配置細節，而在于目标是否認同，資源投入計劃是否可行，可能會有哪些風險，采取了哪些措施保障，如果出現一些項目阻力，需要提前得到上司哪些授權或政策支援。

　　特别是要向上司彙報取得認同的工作就是，将和資訊化相關的基礎工作(例如資料錄入，業務執行)變成有制度保證的崗位要求和流程要求，這樣資訊化工作推進才有制度保障。

　　取得高管支援最有效手段是建立和高管的彙報機制，這樣才能夠讓高管清楚知道項目進展和需要給予的支援，項目組成員也會因為可以經常得到高管授權和肯定而努力推動項目。

　　給高管彙報要注意的是，每次彙報應該準備一些積極的内容，值得肯定的内容，的确有進步的内容為好，否則僅僅是訴苦彙報，是不用指望高管對一個無能的團隊給予更多的支援的。

8.2.6 邊界總在變更(連載五十三)

有的項目實施過程中，使用者不斷提出一些新的要求，希望我們能夠給予解決。

　　這個時候我們有的實施人員頂不住使用者的壓力，被迫承諾答應解決，結果就導緻項目的邊界總在變更，項目目标在一次次變更中不斷變形偏離遊離，最終模糊不清，項目也就陷入不斷開發，不斷提出新問題的循環之中。

　　使用者提出需求要進行分析，一般使用者需求有三種情況：

　　第一種的确是軟體規劃沒有合了解決的問題，而且無法繞過去，或者繞過去對使用者項目就沒有什麼合理的價值了。

　　這類需求在業務調研階段就要主動思考和确認，在功能内部驗證配置業務流時就要發現，并向公司回報，強力推動解決，不要等到現場推廣時讓使用者去發現，然後再去改，這樣可能浪費了好幾個月寶貴的時間。

　　第二種是軟體易用性和穩定性或者性能方面的問題，但的确有替代方案或者暫時可以接受。

　　對于這些需求我們應該給予解決，但要和使用者解釋這些需求必須納入統一版本規劃實作，不可能今天提出要求，明天就改好，這樣開發管理快是快，但長遠可維護性一定很差，是以在功能驗證階段要主動和使用者項目組提出項目推廣過程中哪些功能可能會産生問題，需要大家提前做好溝通工作和說辭，一旦出現應用者不滿意的情況，我們還可以想辦法提前打預防針，心裡有數的處理疑問，不至于被動響應，甚至自己都沒有發現使用者提出的缺陷或者種種問題。

　　如果處理得好，在一個長周期項目内(例如半年或者一年)，如果能夠提前識别這些需求，納入規劃開發響應，那麼最終項目驗收的時候這些問題也就比較順利地得到解決。

　　第三種是使用者應用後産生一些新的業務思想，希望也通過計算機加以解決，這些業務需求可能包含很有預見的需求，也可能是靈光一現，也可能是将其它系統需求要求我們系統也加以實作。

　　這類需求對内我們可以回報給公司相關規劃人員去合理讨論，但堅決不能給使用者任何承諾，超出合同邊界的需求在一個項目中是絕對不可以輕易響應的，否則開個一個口子，就無法拒絕使用者各種合理不合理，但都不在本項目邊界内的需求，項目也就越做越長，無法收場。

　　這種需求最簡單的方法是以合同為準，按合同辦事。

　　比較好的處理流程如下：

　　a) 先要詳細搞清楚使用者業務需求到底是什麼，核心要解決的問題是什麼？很多使用者表達的問題和要解決的手段往往是分離的，我們不要把解決問題的手段和問題混淆在一起，另外有時候要解決的問題是因為另一個問題不友善造成的，要先分析清楚；

　　b) 和使用者項目組溝通協調，确定問題的确存在，且需要解決，且能确定解決的需求；

　　c) 和項目經理溝通，判斷該問題是否在方案價值點覆寫範圍内，而且影響主導業務正常運作，如果是送出需求建議和缺陷報告給公司規劃評審；如果不是先要和使用者溝通，看其是否願意作為後續合作内容，或者另外追加費用解決，不和本項目目标混淆在一起；

　　d) 如果使用者堅持要開發，要及時向公司彙報，并堅決執行公司意志。

　　8.2.7 做人不好

　　有的項目存在嚴重人員溝通問題，使用者對我們不放心，甯可把我們關在現場不回來，生怕我們走了不再來了。

　　這種原因就是實施人員沒有建立足夠誠信，往往是一個階段工作沒有做完，沒有确定到應完成的裡程碑點，就不得不做其它工作，甚至就是不夠認真負責，敷衍了事。

　　使用者聽信實施人員下次來解決問題的承諾回家，結果實施人員在多個項目現場奔波中并沒有投入精力解決軟體問題，或者促進公司解決問題，下次不得不被迫過來又沒有真正解決問題，使用者并不滿意。

　　有的時候排程周轉不靈，版本釋出推遲，使用者不能看到我們按計劃兌現承諾，也會不相信我們的工作，采取要求派人現場長期遵點解決的要求。

　　其實如果問題不能解決，遵點是沒有用的，如果問題能夠解決，往往是雙方溝通協調後在軟體公司先解決然後再到現場解決的，軟體公司資源一般都很緊張，将人壓在現場，幾乎讓自己問題陷入無人催動的境地。

　　是以我們一定要做好最壞的打算，和使用者慎重承諾，說到做到，有問題全力保障問題及時解決，給使用者兩個印象，第一我們很認真守信，第二我們時間珍貴，我們每次隻能解決關鍵問題，實施還是靠使用者自己解決。

8.3 現場推廣工作如何才能做好？(連載五十四)

作好現場推廣工作關鍵在于前期各項工作品質。

　　8.3.1 第一要組織高品質的業務調研

　　業務調研階段在産品比較熟悉的情況下，可以邊調研邊建立原型測試，這樣在現場調研時對可推廣業務設計和驗證，構思業務流程操作手冊，資料規範手冊和各種樣例，到了真正推廣的時候思路早就經過反複推敲，非常可靠；

　　8.3.2 第二要對關鍵使用者組織成功的教育訓練

　　教育訓練就是讓使用者自我進行推廣，我們軟體公司協助配合，要相信使用者的積極性，主動性和能力，要不斷激發他們在這些方面的潛力。

　　a) 從一開始到現場工作就要反複安排大量精心組織的教育訓練活動，讓使用者了解我們的思路；

　　b) 項目解決方案或思路一定要組織各種類型會議在現場反複講解，達成一緻，非常關鍵問題不要回避或模糊化，例如産品管理的思路。但一些技術細節可以淡化，例如表格格式或者彙總時一些小要求，不要糾纏這些細節；

　　c) 教育訓練的時候在操作上應該準備執行個體化的内容，應該讓主導使用者操作後自我評價掌握程度，直到熟悉為止；

　　d) 教育訓練思路站在業務流的高度規劃，讓使用者相信你對他們業務了解和描述非常準确到位，打消使用者顧慮憂。

　　8.3.3 第三要提前做充分的内部業務驗證

　　内部業務驗證一定要自己親手測試，而不是等測試部門結論。

　　因為我們通過業務驗證推導我們業務流程實施思路是否可行的過程，這個工作别人是無法取代的。

　　測試部門隻能按照功能驗證，不能按照業務驗證，可能有一些業務上操作瓶頸無法覆寫，但我們到現場使用者一定會發現，是以造成使用者滿意度下降，進而要返工開發，導緻公司管理成本上升。

　　而且驗證過程中我們要發現軟體是否有易用性，性能和功能上問題，要盡快提供給公司相關部門，直到尋求到替代解決方案或者列入可接受的版本實作計劃中，這樣才能保證在現場出現任何我們心中有數，即使是承諾可實作周期也比較有底，不會亂跳水。

　　此外作為項目經理和實施工程師必須對自己拿到現場實施産品功能了如指掌才能說是在業務上合格，不可能想象一個對新功能，新版本不熟悉的人去現場指導使用者實施；這個隻能通過内部驗證來保證操作熟練程度，以及準備新功能教育訓練教材和更新資料等相關指導教材。

　　在内部驗證不是要讓産品沒有缺陷才能去現場，而是通過自己驗證充分評估産品對主要業務線的支援程度，有多少是可以通過溝通克服的，有多少是無法克服的，必須解決後才能去現場的，有多少是必須解決但可以暫時忍受的。并及時和規劃開發溝通，達成一緻的解決意見，才有面對使用者的智慧。

　　最終做到在現場使用者發現缺陷之前，我們心中有底，有對策，有替代方案，可以承諾使用者我們大緻解決時間，并按時間兌現，進而建立使用者對我們來現場工作的期待感和信任感，而不是抱怨我們拿着有問題的版本來，隻會引發新的麻煩，進而導緻項目失控。

　　8.3.4 第四要做現場驗證。

　　現場驗證就是讓使用者項目組充分評估新版本的好處和不足之處，确定是否更新，一旦更新出現使用者不滿就可以事先采取對策克服，而不是到處救火；

　　如果驗證結論是不能滿足要求，就千萬别到處裝機推廣，那是自尋死路，甯可回去改好再來，也不能強行壓。

　　現場驗證過程也就完成對使用者的教育訓練，讓使用者項目組承擔起實施責任，軟體功能是否滿足要求是軟體商的責任，通過驗證明施就是使用者的責任，這個工作要做得好還需要建立和使用者項目組充分信任的關系。

　　是以現場驗證要做好推廣風險評估，提前采取對策，此外要找到使用者實施推動人，協助他們推廣項目，最後驗證通過給上司彙報，取得支援，召開項目推廣啟動會，這個時候再進行推廣工作就很容易了。

　　8.3.5 選擇适當的推廣邊界

　　一般情況下推廣應用要考慮解決完一個業務環節再往下走，把繁複的企業業務化整為零，設計為相對完整的幾個部分，一個部分一個部分實作。

　　而且每個部分一定要有一個清晰效益牽引或做願景，這樣大家才有跟随實施的信心和熱情，并在一個台階達到以後，再上一個台階，逐漸擴大應用範圍，每個階段實施難度實際上就降低了。

　　記住：隻要某個業務流用起來了，往往就可以驗收了，此時項目推廣内容和合同邊界未必等同。

　　8.3.6 建立和使用者的個人友情

　　為了推廣順利實施人員也可以和使用者一起吃飯娛樂，增進感情，也是有效的團隊建立政策。

　　當然建立友情未必就是靠請客吃飯造就的，請客吃飯一般不會建立深厚的友情，友情是項目中同甘共苦中建立的。

9.1 驗收工作應如何組織？(連載五十五)

實施項目最快樂的事情就是項目驗收，可是經常是沒完沒了的資訊化，不見不散的項目組，驗收之路何其漫漫。

　　我在整個項目經理技巧中都反複強調任何工作達到成效，并不在一時一地事情做到位，而是在平時工作積累中将事情細節做完善，做到位，很多想要的結果就自然達到了。

　　項目驗收就是我們最想要達到的結果，一旦項目驗收對很多人還意味着一件現實的事情就是，我們可以回款了，可以獲得項目提成收入了，同樣項目驗收也是一系列細緻工作完成到位的結果，而不是某個點的成功或者個人能力就可以促成的事情。一個項目的驗收，未必是一次性活動，而是由一系列驗收準備工作組成的，在最終驗收之前，我們已經将很多階段工作細化并得到認可執行，項目驗收就是一個水到渠成的事情。

　　下面我們就一起讨論一下如何進行項目驗收。

　　9.1.1 項目驗收的條件

　　很多人會奇怪，這個問題還需要談嗎，肯定是按照合同和技術協定驗收。

　　其實在業内目前項目合同和技術協定現狀是一個項目，不管金額大小，個性化開發多少，軟體功能子產品，幾乎是一個不少，使用者要求我們承諾的服務内容也是一個不少，供應商在競争壓力下的營銷過渡承諾很難完全避免杜絕，如果要以完成合同和技術協定為标準進行驗收，業内的大部分項目個人以為達到預期要求的可能非常之少。

　　當然這和技術協定架構方式有關，一般最開始技術協定隻談服務内容和實作目标，很籠統，結果在實施過程中很容易出現業務需求爆炸的情況，軟體商難以應付。

　　這種情況下軟體商就開始逐漸細化産品功能點，按功能點确定軟體細節，隻要功能點滿足，理論上就應該滿足使用者業務需要，使用者就應該驗收，至于業務能否運作，更多的是使用者的責任，這裡面更多的展現了軟體商的自我保護。

　　實際運做時無論技術協定多細緻，對使用者而言根本沒有太大的參考價值，使用者隻會考慮其業務是否真的在運做，并以此作為檢驗我們項目是否可以驗收的标準，當然有的項目可以通過商務運做，在業務實作不太好的情況下也能驗收。

　　是以現在一般的模式管理軟體項目是按照服務内容分幾個業務目标，完成一個業務目标就完成一階段驗收，收取一部分實施費用。

　　是以項目驗收的最小條件是一個或某幾個基本業務面能夠開始大面積的應用。

　　這些基本業務面是不是很簡單，或者是不是很穩定，或者人員是不是一定全部都上線，或者業務面上功能是否存在可改進功能都不一定，但隻要使用者看到這些基本業務面可以運作并承認這個可預期的結果就可以了。

　9.1.2 确定裡程碑

　　我們現在知道如果要真做好一個項目，完成項目驗收條件，是以業務是否可用為考量角度。不是一定得實作所有使用者的需求，也不是隻有将一些所謂的技術難點解決使用者就可以用起來并驗收，而是我們可以完成一定的階段應用業務目标。

　　是以要想成功驗收，不是我們什麼都承諾，什麼技術問題都實作項目才能做好，而是和使用者溝通，代表公司和使用者就項目業務實施目标達成一緻。

　　是以我們從進行業務調研的時候就要主動控制項目的業務邊界，将一個一個業務流根據企業實際情況合理組織實施順序，形成我們項目實施計劃中的裡程碑點，明确達到裡程碑點的條件，并得到雙方一緻正式認可。

　　在中國管理軟體售前工作和使用者還無法建立長期合作關系，面對不是很成熟的使用者和瘋狂的競争對手，我們在生存壓力下可以先和使用者建立合作關系，一旦能合作，就相對容易和使用者建立信任關系，有了信任就可以慢慢教育使用者，使用者一旦了解很多事情的複雜性不是軟體單方面可以控制的，反而會理性地和我們一起解決問題。

　　是以我們要相信使用者是理性的，他一定會坐下來和我們一起談：那到底怎樣解決問題呢？最終可以達成合理的結果，然後我們全力去沖刺每個裡程碑。

　　裡程碑的好處第一是将複雜的業務目标分解為一系列簡單的目标，即降低了難度，又使每個階段實施重點突出，精力集中在一點上，自然可以更有效解決問題。第二裡程碑界定目标包含了一個一個相對獨立應用台階，可以促進使用者項目一個台階一個台階往上走，使用者隻要達到了一個裡程碑，項目在這個業務實作台階上就可以進入不可逆轉的狀态，不會走走停停，經常從頭開始。

　　在具體項目中，這些裡程碑内容都可以設計，在每個項目中成功設計裡程碑的關鍵就是最小化項目邊界，然後和使用者高管和中層幹部，甚至在某些項目上還要和基層達成一緻。

　　我們控制邊界的前提是我們自己要有可置換的因素，這就是用價值換邊界。

　　我們必須在深刻了解使用者業務基礎上提出我們的業務目标，闡明項目價值所在，讓使用者接受業務目标，并按照這個業務目标去實施，而不是糾纏在有什麼功能沒有什麼功能。

　　功能很重要，但考慮用功能如何支撐業務流程更重要。

　　是以一個人在項目中最大的力量往往源自對業務深刻而理性的把握。

　　成功項目驗收的核心就是邊界的确定。

　　沒有雙方高度達成一緻的裡程碑認可，也就是沒有項目目标約定，沒有目标約定的項目實施計劃一定會經常變更内容、變更初始設定目标，導緻計劃不可控制，更談不上驗收。

　　很多人希望通過詳細解決方案來定義項目要實作的内容和業務目标，這是很有必要的，但解決方案得到認可并非是通過使用者稽核就可以的結果，應該想辦法讓使用者一起參與解決方案思路思考，變成使用者自己推導出來的業務實施目标，未來才不容易變形。

　　是以我們建議在确定裡程碑的時候和不同層面人員大量溝通目标，确定達成一緻，在産品比較成熟的情況下，能否就項目邊界達成一緻是最關鍵的工作，一旦這個目标達成，就很容易制定計劃執行和落實。

　　确定每個裡程碑後續工作可以參考下面的标準流程。

9.1.3 主動溝通(連載五十六)

一般項目業務目标清晰後，就可以按照業務目标分解相應工作，逐漸落實，在落實過程中有一個很重要的工作是很多實施人員會忽視的，就是主動溝通。

　　項目中一定要有溝通政策，和高管如何彙報工作進展，取得支援？和中層如何就業務目标不斷确認，逐漸清晰？和基層如何就項目應用操作模式達成一緻，持續改進？都需要通過溝通回報完成。

　　溝通的作用對于高管是讓他們清楚我們一直按照項目目标前進，每個階段工作進展是否順利，影響項目正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的話，第一個好處高管經常聽彙報就知道項目進展程度，可以安排回報檢查，看是否具備象我們所說進展，這樣一旦認可了各個階段目标後，最終要求高管簽字結項也就順理成章。

　　第二個會哭的孩子有奶吃，一把手工程核心就是高管支援項目運作，而做到這一點關鍵就是通過合理彙報讓高管對一個逐漸前進的工作進行業績的承認，高管一旦認為某個事情比較容易成功了，反而容易追加資源保障完成，這就是資訊化的：“馬太效應”。

　　一個工作高管經常性不知道進展，怎麼會支援呢？當然誰去彙報可以在項目中界定是企業還是我們軟體實施商，但一定要和高管主動彙報。

　　給高管彙報技巧就是簡潔明了，真實客觀，有理有據分析問題，提出對策建議請其決策即可。

　　中層往往是項目主要的推動力量和實際執行者，也往往是對具體業務需求最主要要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且項目驗收與否沒有中層的同意往往也是不太容易做到的。

　　要達到項目的目标沒有中層的配合也是非常困難的，和中層的溝通往往是不斷動态調整項目目标，逐漸清晰化項目目标和細節的過程。

　　往往通過前期業務調研隻能對企業項目目标有一個大的，宏觀的認識，但如何細化并最終落實并非是一步到位的過程。是以在整個項目過程中，雙方項目組要不斷溝通，特别是企業中層溝通，才能逐漸認識越來越深刻，最終達成一緻。

　　和基層的溝通主要展現對最終使用者的關懷，定期主動和最終使用者溝通，消除一些怨氣，讓使用者能堅持用下去，這個時候我們往往發現很多使用者真的是非常可愛，盡管軟體還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動。

　　個人以為一般在項目中要堅持每個月到一個半月寫一份詳盡《情況簡報》，分别通報企業項目負責人，部門負責人，項目組成員。

　　《情況簡報》應先發郵件，然後一定電話落實收到并口頭簡要彙報，特别是高管層，千萬不要以為發了就等于别人會去看，一定要口頭跟進彙報一次，保證企業各方面負責人對項目進展做到心中有數。

　　另外實施工程師無論是否在現場，保證每周至少和操作使用者、系統管理者溝通一次，主動和使用者接觸，不要等到使用者有問題再來找我們解決。

　　這樣反而可以逐漸釋放使用者一些火氣，真要救火的時候我們反而有一些從容周轉的時間，一回生，二回熟，到了驗收的時候也好說話。

9.1.4 寫好備忘錄(連載五十七)

　在一個漫長項目周期中，很多工作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就翻出來重新要，這種事情很多人可能都經曆過，明明說得可以先不做的内容最終驗收的時候又成了必要條件。

　　是以在一個項目中要順利驗收，一定要寫好備忘錄，把平時項目過程中重要階段點雙方達成的共識詳細記錄下來，以備查詢。

　　項目組在每次現場工作都必須要寫備忘錄，備忘錄必須注明現場工作天數，按時間段寫清楚工作内容，性質和時間長度。

　　例如教育訓練工作要寫清楚教育訓練人員名稱，教育訓練内容，教育訓練小時數，教育訓練掌握效果；

　　例如裝機工作要寫清楚裝機軟體，裝機台數，是否可正常使用等等細節。

　　每次備忘錄要口頭交流認可後才列印簽字确定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障項目在每次工作基礎上不斷前進，并用備忘錄限制雙方的行為。

　　備忘錄标準的寫法是先簡要彙報階段工作中内容，要用積極肯定性的文字給自己前一段工作或者一些提法給出正面結論，這樣大家看了才有信心。

　　這個工作内容往往是上一階段約定要解決的内容，而且在這次現場工作中得到解決的内容，要考慮和上一次備忘錄約定工作内容的呼應，很多人寫備忘錄，純粹是為了備忘而備忘，備忘錄三大功能，第一是備忘，第二是繳功，第三是約定後續工作安排，推動事情繼續前進。

　　是以寫備忘錄首先要講上一次我們約定什麼工作，這次是否完成，完成品質如何，沒有完成是什麼原因造成的，是否納入下一次解決的内容，這樣的文檔才有體系，也能展現出一個人整個項目過程中的脈絡，否則寫這麼多備忘有什麼用？

　　結論出來後後備忘錄要較長的描述自己所做工作細節，細節越詳細越好，讓項目組彼此認可工作内容和品質，而且對服務工作量可以有一個客觀的評估。

　　而且在寫備忘錄時發現自己大量時間并非在有效溝通或者在推動項目實施上，那麼意味着項目已經是在失去控制路上，應該立即引起警覺并采取措施解決。

　　備忘錄最後還要約定下一階段雙方工作安排，在後續工作中嚴格按照備忘錄設計自己的工作計劃，了解企業項目組進展，如果企業項目組方面配合出現問題，在下次備忘錄中要明确指出責任承擔方，給使用者形成一定的壓力，進而更好推動項目走向前進。

　　一些重要的項目目标約定或者驗收意見可以單獨寫備忘錄，在最終驗收時可以作為依據。

　　這樣一個備忘錄一個腳印推動項目向目标前進，每個備忘錄都在前一階段工作上有一點點進步，最終項目驗收就是水到渠成的事情。

　　除了實施備忘錄外，實施人員最好給每天工作做詳細記錄，實施備忘錄個人認為隻是一個工作進度大概描述，而且可能會有水分，因而需要有一個每天工作的詳細記錄用于自己或者團隊成員準确把握項目脈搏，及時發現問題，個人也能随時做項目回顧，使用者的反複也能随時記錄在案，如果出現項目延誤，也能有理有節和使用者應對。

　　9.1.5 精心準備一次成功的彙報

　　如果項目準備驗收了，一般要安排一次驗收鑒定，這個鑒定可能是要請專家來看，可能是企業内部組織，也可能就是幾個人認可簽字即可。

　　是以如果要驗收，最後鑒定這個工作品質要高。

　　要準備好一套模拟現場環境的示範環境，要有足夠真實的資料，要設計一套展現應用特色介紹流程，要準備一套詳實彙報材料和相應PPT。

　　要保證驗收大會順利通過，其實是在驗收大會前将相關彙報工作和現場應用情況和企業上司做過彙報，并得到充分認可。

9.1.6 平時做人的積累

　　對于項目一個實施人員要為公司考慮節約成本，同時也兼顧客戶利益，是比較難以決策的。

　　特别是在一個多可能同時負責多個項目的時候，想每個項目都應該全力以赴是很困難的。這樣難免讓使用者覺得我們響應不及時，有問題不解決，特别有些問題不是我們一個個體能夠解決的，長期下來使用者可能會積累很多的怨氣。

　　是以實施人員平時做人要講誠信，講原則，無非是三條：

　　做不到的事情千萬别随意承諾；

　　承諾的事情一定要努力做到；

　　每次做到的事情都進步一點點。

　　有這三條使用者會慢慢接受稍微長一點的響應周期，也會用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。

　　我們很多人做項目遇到困難在公司内部沒有想盡辦法去解決，認為我自己這麼努力，承受這麼大的壓力，而别的同僚好象沒有什麼壓力，心理不平衡，就容易回避放棄。拖，拖，拖，拖到無法再拖的時候在使用者那裡就沒法擡頭，隻能被動挨打。

　　如果按照以上三條原則做事，反而簡單，不做做不到的，當然這個做到做不到不是個人判斷，而是和公司内部協調達成一緻後的意見，做得到的一定按承諾做好，項目就會簡單。

　　實施過程中可以留一手，有些好功能或者便利的地方，可以不全部告訴使用者，畢竟在合同邊界中沒有涉及，在驗收前可以作為條件和使用者去置換。

　　9.2 如何催款？

　　首先要主動提出回款要求，這是很多實施人員最難做到的一點，不知道如何開口，擔心開口後被動。

　　其實要錢這個事情最難的就是開口要，開口要了就簡單了，為公司催款是天經地意的事情，你是在為公司生存催款，也是為了有錢才能提供更好的服務，要理直氣壯的去要錢。

　　就象很多人催别人還自己借給他的錢一樣，難就難在自己的心理顧慮上。

　　不管項目實施地好不好，一開頭要錢，使用者馬上就會提出不合适，這個時候我們要趁機了解，現在不合适，具備什麼條件就是合适？立即和使用者約定回款條件，有了回款條件，等于給自己清晰約定了雙方工作目标，那麼這個回款條件馬上寫進備忘錄，達成一緻意見。

　　是以項目中隻要覺得具備一定條件，就要主動提出驗收，驗收速度取決于對驗收目标是否達成一緻。

　　不斷提出驗收要求，就可以不斷就項目目标進行清晰定位，反複三次後，驗收目标就清楚了，這個時候雙方項目組就該解決的問題就盡快解決，不能解決的就想辦法，例如進行價值置換，或者追加資源投入，或者緊急開發，或者變更合同等等。

　　回款條件也不要立即寫成備忘錄，先不斷提出各種可行回款條件，，逐漸選擇最合理的條件以加深印象，并不斷利用各種彙報的機會 明确，最終寫到備忘錄中成為未來驗收工作開展依據檔案。

　　一旦目标一緻清晰後，實施團隊要全力保障回款條件實作，一旦達到回款條件，還别忘了請商務人員做去商務工作，個人也不是萬能的，搞技術的可以催錢，但不要去要錢。

10.1 如何做項目團隊管理之前言(連載五十八)

入行五年，做了一些項目，現在最大的體會發現目前整個管理資訊化實施盡管每家公司都提供了很多方法去指導，提供了很多流程去限制，但效果不大。

　　為什麼呢？因為管理軟體實施需要一個人在四個方面都必須很強才能順利推動，這四個方面是企業業務，管理理念，軟體功能，人際溝通。實際上一個好的實施人員必須是一個能力非常強的知識複合型，精通項目管理技巧的人才。

　　在産品基本成熟後，一個成功的項目是靠個人能力去保障的，流程和方法論隻能給有潛力的人行動啟發，而不是指南。這就是目前的現狀。

　　而這種人才的獲得是非常偶然或者是需要長時間積累的，但整個IT行業是一個年輕人的事業，大量不足30歲又沒有多少行業經驗的人活躍在一線，項目服務整體品質不高在所難免。

　　IT人注定是奔波勞碌命，一個現場趕往另一個現場的奔波中，知識的更新和積累非常緩慢，不如說是吃老本更合适，而IT公司為了應付使用者需求也是招架不及，成本難以控制，更不可能在業務教育訓練上下功夫，結果就是一大批有潛力不職業的實施人員在IT業浪費了青春。

　　通過高薪吸引高水準的項目管理型人才或實施人員進入IT管理軟體實施工作，其實是一個僞命題。毫無疑問目前一個具備以上技能的人員在IT業可以獲得的回報是遠遠少于其它行業，是不可能吸引多少人才加盟的，可能每家公司都有一些高人，與其說是為利益最大化，不如說是和愛好重疊，在工作中有樂趣。

　　但一個公司高人是有限的，不可能讓這個高人去應付所有的工作，否則這個高人隻能給每個項目一點點精力，還不如一個花費大量精力在某個項目上的能力低一點的人的效果。我們在高度競争的情況下，不太可能引進高人去實施，成本無法承受，也不能讓一個高人去面對所有的項目，讓高人崩潰。

　　根據我的觀察業内很多忙人，共同的特點是售前售後一肩挑，幾乎是一個突發事件跟一個突發事件，沒有喘氣的機會，最終的結果隻能是黯然引退。

　　是以解決這個沖突必須尋求另外的出路。

　　我個人的建議是，公司第一要做好知識管理，并通過IT産品為核心整理自己的知識，将對企業業務和管理理念支援通過連貫的功能展現在産品中，并形成售前售後一緻的标準實施和示範方案，并不斷完善。

　　此外就是建立項目團隊，通過團隊能力組合去彌補個人能力不足，在團隊中建立學習型文化，通過親自示範傳遞很多軟能力技巧，也許是目前擺脫困境的辦法。

10.2 好的項目團隊建構要求

　　一個好的項目團隊絕對不是一種性格一種單一能力的人的組合。任何一個人想做項目經理，實際上從一開始就要考慮如何構造你的項目團隊。這些考慮包括如何建立實施能力的合集，形成共同的價值觀和行為模式等方面。

　　項目經理在建立項目團隊時容易發生兩種誤區，第一要求别人有團隊精神；第二是指望别人有為項目目标犧牲自己時間的精神。

　　這樣建立團隊隻能說是期望值過高，最終團隊很難一起長期合作。

　　個人有沒有團隊精神不是關鍵，而是你建立的團隊對不同的人是否有包容精神，發揮他們的長處，抑制他們的短處。

　　要做到這點就是通過合理的利益機制去保障，不要指望用什麼精神力量去長期維護一個團隊的鬥志。

　　要知道很少有能在半年内結束的管理軟體項目，是以也不要指望個人一開始就願意為了項目成功去犧牲自己的利益。

　　個人認為建立好的團隊把握住兩個方面就容易，第一是團隊成員價值觀接近；第二是團隊具有合理的利益配置設定機制。

　　一個能成功合作的團隊最好的方式是選擇具備同樣價值觀的人加入團隊。

　　國内項目很難做好的一個重要原因就是資訊化長期艱巨性和企業需要立竿見影的效益之間的沖突。

　　這個時候無論個人能力多麼強，恐怕都無法立即滿足很多使用者的期望值，是以團隊必須要有長期抗戰的心理準備，這個時候肯承擔責任的人非常适合加入團隊。

　　作為一個管理軟體實施項目，一定要選擇那些有耐心，有韌勁，有擔待的人去負責項目，這樣的人才能把項目做好。

　　因為一個人肯擔責任，就會努力去解決問題，在解決問題過程中其技能一定會在很短時間内得到很大提高，這個人業務能力怎麼樣是可以解決的問題。

　　但一個人不肯承擔責任，不肯努力解決問題，問題就永遠停留在原處不被解決，即使開始技能不錯，後來也不能适應項目需要。

很多項目往往因人而成，因人而廢。這個現實告訴我們很多時候我們必須花費足夠精力去選擇這樣的人。個人認為現在中國這麼大，選擇40~50個認同這樣價值觀，對待遇要求也可以接受的人員一定有，隻是我們沒有去發現，總是通過一大堆其它條件去選擇人員有關。

　　例如我們總是要求一個實施人員有計算機軟硬體知識，良好制造業背景，對資訊化管理軟體實施有深刻認識，對軟體功能熟練掌握。

　　這些都是對人硬能力硬名額的要求，但是無法衡量一個人的軟能力，而在項目實施中軟能力是最重要的。是以我們在選擇成員的時候要和人力資源部門有力協調，不要選擇大量硬名額的人，第一是難找，第二是不好管理，難以協調一緻和産生認同感。軟能力的衡量要考慮最大方面就是價值觀，而不是現成的業務技能。

　　根據個人觀察，能夠快速在項目中獨立擔負責任的人，從一開始他對這個行業一無所知到可以獨立完成任務，在有人指點的情況下一般隻需要半年，甚至更短。

　　是以完全不必擔心這些新員工能否成長，而是應該擔心新員工能否得到良好的指點。

　　選擇好團隊人員隻是一個開始，一個團隊一起協同工作一定是可以通過工作獲得相應的回報，這個回報一定要有一個大家認可的合理配置設定機制。沒有這個合理的機制，團隊也會因為失去激勵和公平而人心渙散。

　　做到合理的配置設定機制在項目控制過程中非常難，因為國内同樣規模和難度的項目，有的企業金額80萬，有的企業40萬，甚至有20萬，軟體公司為了解除現金流壓力，最後都會承諾去做。這些項目要做好都需要消耗同樣的項目人力資源。

　　如果一個人做了一個80萬的項目，一個人做40萬的項目，可能工作量差不多，但項目提成收入可能差距就是一倍。這個問題也就是存在所謂“肥單瘦單”的說法。

　　即使兩個人做的同樣是40萬的項目，項目複雜程度可能差别很大，工作量差距也是好幾倍，提成收入又差不多。

　　就算是兩個項目金額複雜程度差不多，付款條件不一樣也會對可預期收入産生直接影響。根據不同公司的政策往往實施人員更樂意或者不樂意選擇首期款比例高的項目。

　　還有一種常見情況，一個項目大家一起做才能完成，兩個人在項目中花費工作量不一樣，解決問題難度也不一樣，這個時候如何平衡兩個人的提成收入配置設定也很關鍵。

　　開始合作的時候大家往往比較容易齊心協力解決問題，但如果到了利益配置設定的時候大家覺得受到不公平待遇，估計你的團隊也就開始瓦解。

　　解決這個問題的辦法我覺得很難，從兩個方面入手也許容易做一點，一是在團隊内公平透明，優先獎勵符合我們價值導向的人，第二是必須認識到這個是一個項目經理管理團隊最需要花費精力的地方，必須保證時間去思考和解決這個問題。我們中國人一不缺智商，二不缺情商，但比較缺錢商，孟子說：民不患寡而患不勻，大概是我們可以參考的一個思路。

　　實際上我認為建立一個實施團隊不要照搬那些管理理論的理想描述去做，關鍵就是這兩個問題，有沒有一緻的人，有沒有合理的配置設定機制。

10.3 好團隊的兩個特征(連載五十九)

一個好的團隊一定是分工明确的團隊。

　　很多IT管理軟體項目，要麼是一堆人泡現場，要麼是孤膽英雄。

　　因為遇到事情的時候使用者的感覺是沒有人真的去負責，這就說明在項目中沒有真正的項目經理，

　　這就是在一個團隊中沒有明确誰對項目負責，如何負責，技術問題誰負責，商務問題誰負責，管理問題誰負責，到了真有事情，每個環節都忙，但響應和處理效率并不高。

　　實際上使用者願意選擇能夠解決問題的人，而且願意解決問題的人合作。但這個人往往是項目經理，因為項目經理一般實戰經驗豐富，技能不錯，而且對項目最終負責，壓力最大，結果項目經理就成為這樣的人。但項目經理一般要負責多個項目，每個使用者都喜歡他，他很快就在多個項目中變成每個使用者都不喜歡的人，這就象一個人的情人不能太多，太多也難應付。

　　是以合理分工的原則是幫助項目經理充分發揮自己價值，讓團隊成員能力能充分展現。一般項目經理應該強在對企業業務把握能力，能快速發現項目的價值點，進而通過良好的溝通技巧在團隊内和使用者處就項目目标達成一緻，并形成可執行的後續計劃。

　　這也就是所謂計劃，組織，控制三步曲。

　　項目經理不應該讓使用者認為是一個技術很強的人，當然項目經理技術可以很強，否則使用者會不認可實施人員的能力，反過來要求項目經理到位，而團隊成員技術能力也會因為沒有足夠實踐機會而成長緩慢。

　　不能成功讓使用者接受自己團隊成員能力的項目經理，注定是疲累不堪和失敗的項目經理。

　　此外項目經理技術性比較強，而且在管理軟體實施過程中要帶一些顧問的性質，這樣的角色最好不要和回款直接挂鈎，可以出面提醒使用者按期支付款項，但不應該直接去要錢，這些工作應該通過商務經理完成。一個人上來談目标，下來談收錢，會給使用者一種不真實的感覺，是否你為了回款而設定比較低的目标？

　　是以一般在一個團隊中應該有項目經理，實施經理，客戶經理三種角色。

　　項目經理，項目經理最大的作用是控制項目邊界，代表項目組和使用者就項目目标達成一緻，然後組織資源保障項目得以實作。項目經理要保證為了達到預定時間内的目标，可以配置資源和時間去完成這件事情，而不是到處救火，親自去解決問題。

　　實施經理主要是從技術上保障項目順利運作的配置實作，并保證讓使用者可以獨立應用并推廣軟體，在積累一定經驗後可以獨立完成解決方案編寫和産品完整示範。

　　客戶經理是當項目達到合同約定條件時，負責催款和回款相關的商務工作。

　　個人認為實施經理和項目經理最大差別不就在于一個同時隻能搞定一兩個項目，項目經理可以同時搞定5~6個項目。

項目中三種角色缺一不可，每個角色在自己能力範圍内發揮作用，互相協調配合一緻非常重要。而且項目經理要讓使用者清晰知道遇到何種問題可以如何和我們項目組聯系，我們會如何解決，大概需要多長的時間。

　　這樣的團隊最大的問題是是否遵守同樣的行動規則，也可以了解為對外是否具有一緻性。這也是一個好團隊的特征。

　　有的項目商務經理為了便于回款或者簽單，容易過度承諾，給後期實施制造極大障礙，有的實施人員在現場發現一些新的問題，容易犯個人英雄主義，自己去承諾解決，但并不先和項目經理溝通，有的實施人員如果不是特别安排，基本上不會去主動和使用者交流，有的實施人員幾乎每天都和使用者電話聯系，有的項目經理經常和使用者聯系，實施人員反而不去聯系，這些都是行動規則不一緻的表現。

　　在一個團隊是否遵守同樣的行動規則，首先是價值觀一緻。

　　例如我們是否都認為如果使用者現場出現各種問題，我們應該先全力促進解決問題，再來談問題的責任，而不是一開始就說這不是我的錯，這個不歸我管？

　　我們是否認為為了讓使用者滿意我們必須随時準備犧牲自己的時間和精力？

　　這些都是很重要的問題。

　　第二是養成事先溝通的習慣。不要自己去決定所有的事情，也許你的決定沒有錯，比别人去做也會效果更好，但是在沒有得到明确授權範圍内的事情，一定要先在内部達成一緻後行動，否則容易出現做了别人也不領情的情況。

　　很多事情也很難一開始就形成規範或者檔案指導，但隻要我們清楚這些事情應該先内部達成一緻，總是有辦法，對于一些規律性的東西就慢慢形成慣例，可以減少溝通的成本，這也就是所謂團隊默契的形成。

　　第三是每個人的溝通頻率在一個項目中各個階段保持一緻，關鍵溝通資訊應互相清楚，不同角色溝通頻率節奏要合理搭配。

　　第四是對項目邊界和不同角色責任承諾對使用者說法要一緻，這個是通過内部溝通達成一緻後要和使用者明确的。

　　10.4 如何看待項目經理在團隊中作用

　　IT業流動率高，做實施的流動率相對開發可能更高一些，一個項目最怕中途換人，但這種情況在業内非常常見，使用者非常擔心自己的項目出現這種情況，往往要求在合同前期指定項目實施人員，這是一種無奈也無用的做法。

　　是以軟體公司應該将自己業務上比較優秀的人提拔出來，給予項目經理的職責，培養其管理意識，而不僅僅是技術意識，給個人比較大的成長空間和較好的待遇，這樣有利于核心員工的穩定，再由核心員工帶領團隊去做一個項目，這樣項目因為人員流失造成項目中斷的風險就最低。

　　是以對于公司而言項目經理不能是一個一般性崗位，是一個具備能力核心員工才能擔任的崗位，這個崗位能讓核心員工在比較長時間内穩定開展工作，并通過項目經理帶領團隊實施，促進團隊能力提升，保持團隊隊伍穩定。這對于一個項目可能是非常重要的一點。

　　從項目實施角度來看努力去負責一件項目是很不容易的事情，特别是這種管理軟體實施，是以一個項目團隊中必須有一個項目經理。

　　項目經理就是無論是其責任心還是職責規定都是那種尋找努力促進事情發生，從不輕易放棄的人。

　　項目經理是一個團隊的精神領袖，他的言行直接對團隊起到一種示範作用。

　　一般認為項目經理未必一定是一個團隊的技術領袖，但實際在目前國内要想成功控制管理軟體項目項目經理至少得是一個業務精通者。

　　一個對企業業務不熟悉，對管理軟體不熟悉的人擔任項目經理更大的可能是造成一場災難，盡管也許他具備很好的項目控制能力。

　　總之項目經理要成為一個讓使用者和團隊成員都信任和放心的人，這種精神領袖的地位是靠項目經理能力和個人魅力逐漸得到大家認可後在一個集體中放大和加強的。

10.5 團隊建設心得和誤區(連載六十)

10.5.1 加強溝通保持一緻

　　項目管理強調團隊達成一緻再行動，但達成一緻的關鍵是先在内部廣泛達成一緻，再對外溝通。

　　這個原則有兩點在操作中很容易出現問題的地方，第一是項目經理事無巨細都需要了解和溝通，協商成本太高，導緻溝通效率很低。

　　内部溝通非常必要，但也沒有必要事事溝通，反而打擊團隊成員工作積極性。項目經理應該實作和團隊成員約定不同類型事件溝通方式和頻率，保護團隊成員工作主動性，同時保障項目始終受控。

　　第二項目經理自認為能力很強，按照一些項目管理理論說法項目經理先和客戶達成一緻目标，然後協調資源完成目标，内部資源不聽排程就非常惱火。

　　現在一個出色的項目經理一般都無法專心做一個項目，是以項目中主要實施工作還是要依賴其它團隊成員完成，是以在一個團隊中對于軟體實施有不同認識和意見是很正常的，項目經理一定要先多花一些時間在内部溝通，千萬不要以為内部一緻性很容易達成。

　　我們員工更習慣的思維模式是既然你都已經決定了，我照你的做就是，還問我意見幹什麼？如果員工覺得項目經理思路不對，他們可能不是優先考慮執行，而是想證明自己是對的，這也是知識型員工的特色。是以甯可先多花一些時間告訴項目經理自己的判斷，最後和使用者會談達成的結論會比較順利地傳遞成為團隊共同認識。

　　10.5.2 參與和顧問式上司方式

　　很多項目管理書籍告訴我們上司有方的項目經理從來不教人如何工作，由項目成員自己決定怎樣完成任務。

　　我個人認為項目經理工作恰恰是要給新員工示範正确的做事方式，隻要條件許可，還要親自示範，在項目需要受控的時候多一點獨斷專行，少一點成員自由發揮是非常重要的事情。

　　項目經理的示範隻需要一次，通過示範讓項目成員感覺到正确的做事方式可以有效達到目的，這也是項目經理建立權威的自然時機。

　　在中國缺少職業教育的高學曆人群比比皆是，如果相信這些擁有高智商的人能夠順利完成工作就大錯特錯，高學曆的人把很多簡單的事情搞得無比複雜的情況到處都是，很多人自以為是，自作聰明，最後還是要别人去開屁股。

　　也許在國内項目經理不需要過于精細的管理，但在國内不能确定團隊成員工作方式和能力之前，項目經理還是要多做示範，保證團隊成員工作方式是按照基本的職業方式進行後才能讓他們自主發揮。

　　10.5.3 控制過程還是目标管理

　　很多管理理論總是強調不要僅僅重視結果，要注意過程，沒有過程品質的保障，最終的結果輸出也是偶然的，不可靠的。

　　這個理論一點都沒錯，不過問題是實際上項目經理在過程控制上花費的時間越多，花費的精力越大，項目反而越難以控制。

　　因為管理軟體實施對人的綜合能力要求太高，當一個人的能力還不能達到業務要求的标準的時候，最需要的是教育訓練和示範，而不是責問為什麼你的工作不到位？

　　就象本人寫前八章一樣，能夠把這些事情正确執行方法知道的人都不多，有實際經驗的人更少，對能力不足的人去控制過程，還有控制的必要嗎？

　　這個時候最重要的是建立業務規範，在業務規範大家有能力執行的情況下，再去考察業務規範符合度，加強過程控制才有效。

　　我們很多軟體企業不斷強調自己的流程和方法論，但員工經常流失，很多新員工在現場工作的時候，什麼方法論都不管用，他們充滿恐懼的想：我到底該做什麼，我該什麼做。

　　過于強調過程管理最大的一個展現就是彙報多，層次複雜，增加了很多管理活動，但又看不出這些管理活動的價值。結果是很容易重複彙報或者多頭彙報。口頭彙報完成的工作還要書面彙報，日常彙報過的工作還要專門總結彙報，現場記錄的工作還要單獨彙報。

　　經常反複彙報在項目管理的理論中也有說明：這是打擊團隊士氣的有效方法。

　本人建議彙報突出兩點，壞消息先彙報，例如不能按照計劃完成的工作要彙報，需要緊急協調資源的消息要彙報，這些随時發生，随時搞清楚原因，随時彙報，随時采取行動。

　　第二與其反複了解進展，不如提供清晰的目标管理。

　　也就是說項目經理接受和交代任務的時候，一定要清楚自己任務的範圍，品質要求，進度要求。

　　對任務了解是否達成一緻的最簡單方法就是請任務接受人當場複述。任務接受人如果不清楚任務的内容，進度和品質要求，一定要問清楚才能去執行，如果不清楚怎麼做，也要立即溝通請教，不能先好好好，回頭告訴别人我搞不定。

　　本人曾經給一個員工布置一個修改方案的任務，電話裡說了6點修改意見，問他清楚了嗎，非常自信的回答，我知道了，放心。

　　本人很不放心的又問一句，給我複述一遍。很流利的說了四條，然後問我，哎呀，還有兩條呢？

　　是以在接受任務的時候還要一個職業習慣：好記性不如爛筆頭。

　　在國内目前項目實施水準現狀下，個人以為目标管理，嚴格的目标考核機制遠遠比過程控制更能達到管理目的，隻有當大面積的人可以按照目标完成項目的時候，過程管理才能發揮不可替代的優勢。

　　10.5.4 信任團隊成員

　　項目經理一般都是業務能手，很多時候看到項目成員做一些很簡單工作都做不好，馬上親自動手，先搞定問題，否則項目耽誤不起，但常此以往，項目經理就是眉毛胡子一把抓，活該累死。

　　項目經理要信任和授權成員獨立完成任務，既然都在一個團隊就要用人不疑，疑人不用。堅決大膽要求團隊成員努力學習獨立掌控局面，項目經理逐漸演變為對目标進度的控制者。

　　當然這個時候項目經理要加強對員工工作的指導，但項目成員往往分布在不同的現場，項目經理要結合不同項目拜訪計劃的時機采用走動式管理。在現場不斷并親自驗證成員的工作方式，立即指正和改進，加以示範。

　　信任不是放任自流，以信任的名義對團隊成員的工作放任自流是項目經理失職和偷懶。

　　而且項目經理要時時考慮讓讓使用者成為團隊中的一份子，從一開始就全力教育訓練使用者是減少實施成本的最有效方式。

　　團隊成員一個比較共性的問題就是：很多人會問沒有資源沒有人我怎麼開展工作。這樣的團隊成員可能會辜負項目經理的信任。

　　這是很大的一個誤區，一個人有能力的表現就是能做别人認為很難做到的事情，如果事事有資源你才能把工作做好能說明什麼？這種事情誰都能做。

　　而實施工作就是在各種縫隙裡尋求合理的答案，項目經理在信任團隊成員的時候也要讓團隊成員建立承受壓力，迎接挑戰的心态，也就是所謂情商吧。

　　10.5.5 建立向上的團隊文化

　　項目經理一般都是個性很強的人，不太可能用同樣的方式限制項目經理的做事方法，當然越是成功的項目經理，行事方法越具有共性。

　　而項目團隊成員和項目經理的互相認同對一個團隊成長非常重要，也是工作能否快速進展的關鍵。

　　項目經理要及時認可成員工作，随時用進展鼓舞團隊士氣。對很多人而言，物質獎勵的預期是很清楚的一件事情，國内的項目經理一般也沒有多大空間去對項目成員工作進行物質獎勵，是以在這樣的邊界條件下我們更要尋求利益機制以外的團隊合作方式。

　　對成員工作表示興趣；對成員的能力表示信任；和成員一起在工作中尋找樂趣；和成員一起建立非正式溝通方式(例

發表于

2009-02-27 16:59 

Patrick,Song 

閱讀(3404) 

評論(2) 

編輯 

收藏 

舉報