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

這個世界上寫給項目經理的書不少，寫給IT項目經理的書也很多，但寫給從事管理軟件實施的項目管理書籍並很少。
　　 而筆者在從事項目經理工做中感到一個很苦惱的問題是，不少書其實很是經典，但都有一個缺點：理論正確，實戰指導做用不足。
　　 不是親身親歷的人是很難領悟到那些理論的精髓，而每一個剛剛入行又立志成爲一個IT實施的新人每每不是一開始就能從理論上武裝本身，在他們起步的時候，天天要面臨着各類具體工做任務，例如作調研，寫計劃，寫方案，寫備忘錄，作項目彙報，作演示，這些活動與其說是項目管理髮揮做用大，不如說這是具體業務技能的領域。html

一個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個方面：

　　一、若是有的話，必定要認真閱讀商務合同和技術協議。

　　二、閱讀前期技術方案和各種備忘錄。

　　此點很是重要，不只僅要閱讀，還要保證本身工做質量和規範和前期保持一致，一個行爲高度一致性的公司是核心競爭力很強的公司。

　　此處有一個很重要的工做必定要向前期參加工做人員瞭解是否已經收集了一些資料，並想辦法得到，已經蒐集的資料和問題儘可能避免重複詢問，這對用戶會形成巨大不滿。若是萬一前期資料不能得到，也要另外提早準備好說法避免這種狀況出現。

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

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

　　四、熟悉公司已實施的相近項目的狀況。

　　他們企業業務調研報告和解決方案將對咱們如今工做頗有幫助，甚至在調研過程當中給咱們不少思路上的啓發。

　　五、熟悉相關軟件產品的功能及發展方向。

　　不少人在工做中不注意和規劃人員的溝通，其實在調研前確認本身瞭解產品的發展方向，現有和近期可實現的功能對調研時遇到一些很難迴避的技術問題就能夠作到心中有數，提早想好說法。固然最好的說法是這個功能咱們已經實現了，在某某項目上也是這樣要求的。

　　六、瞭解企業所處行業的行業特色、競爭態勢、產品研發特色。

　　這些要從公司，特別是網上查詢資料分析，創建一個基本的業務原型，這樣在調研時能夠讓用戶感受到咱們仍是作了不少工做，對項目很認真。

　　七、準備同用戶交流時的軟件原型或交流PPT。

　　有的時候用戶在調研過程當中提出要咱們作一個培訓和軟件演示的要求，通常狀況下咱們應該避免在售前調研階段作這個工做，由於這些要通過精心調研仔細準備後再進行質量更高。

　　但在售後實施調研時咱們可能要先主動作這個軟件演示和理念培訓工做，收斂用戶的思路，引導項目邊界，因此調研者也應提早對這些方面工做作一準備。即便是售前也很難徹底避免這個狀況，不但要準備，並且在語氣上還要有所區分。

　　八、準備企業業務調研問卷。不必定要給用戶，但必定能夠讓本身不遺漏該問的問題。

　　九、設計業務調研方案。業務調研方案能夠將本身調研經驗不斷積累，造成體系化的經驗，你們如今看到的文字就是我不斷完善業務調研方案的結果。

　　十、設計業務調研計劃。計劃必定要用心，用心才能作好。

　　十一、準備業務調研培訓材料。

　　到現場調研時須要讓用戶知道咱們的調研方法和思路，用戶纔好配合，也承認咱們的專業化程度，這個應該結合公司流程和本身體會進行準備。

　　十二、軟件安裝盤和加密狗。有備無患。

　　1三、電腦筆記本。IT農民的必備勞做工具，若是沒有就用筆記本解決問題，沒有電腦前麥肯錫一直是手記錄問題，如今他們仍是提倡手記錄，由於方便。

　　1四、WINDOWS2000/SQL SERVER/ORACLE安裝盤等經常使用工具軟件安裝盤。有時候頗有用。

　　1五、別的項目經常使用樣例及標準配置，用戶很難提供明確需求的時候，讓他們看看咱們在別的企業成功樣例，有助打開思路，也體現咱們給用戶帶去先進管理方式和成功經驗的合做初衷。

　　1六、公司各類流程管理文檔。對於一些用戶瞭解咱們公司內部問題的時候，若是搞不清楚該什麼講的時候不要信口開河，翻翻資料再說。

　　1七、可能涉及業務難點培訓資料和問題集。

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

　　1八、公司小禮品。

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

　　實際上咱們每一個作過調研的人捫心自問，調研準備18條咱們到底作了幾條？

　　也許認真不認真就是咱們一個工做到底有沒有質量的根本緣由。

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

調研計劃確認，抵達現場就須要進行調研工做。在調研工做階段咱們經常容易犯如下錯誤。

　　2.5.1 常見錯誤一：當即進入調研狀態

　　不少人很是努力，一到現場，就開始按計劃進行調研工做。

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

　　這樣作的理由有三點：

　　第一雖然不少企業和你電話口頭認同了計劃，但只有調研者到現場了纔會真的重視，因此咱們必需要從新確認計劃，保證咱們的計劃須要的調研配合資源已經落實；

　　第二確認調研計劃每每不是和協調人確認，要主動經過這個機會見一見企業負責的高管，不少時候企業也會安排這個一次見面。和高管見面要作好三件很是重要的事情：

　　1、彙報咱們的計劃，請其再次確認，並請其協調資源安排人員配合。

　　記住給領導溝通最有效方式之一就是「多請示，多彙報」。根據我我的的經驗，通常領導看過的東西不如口頭彙報的東西印象深入，彙報也是創建領導對咱們認同的手段。

　　不少時候被調研人員不肯意配合咱們進行調研，由於這樣可能會影響他們正常工做或者有其它顧慮，因此當調研工做是領導的工做任務安排，他們配合積極性就高了。

　　不少時候領導也不能當即協調完全部的工做，特別是這個時候能夠要求領導配置一個專門的聯絡人，由他出進行聯絡工做，可能的話，也要求其全程參與調研，這樣的人會給調研帶來極大方便。

　　2、彙報咱們的調研工做方法，讓高管以爲咱們作事頗有套路，同時請其提出意見，作相應客戶化調整。

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

　　領導明白你思路了，也就知道咱們這些天工做量都會很飽滿，頗有組織性，也就對調研工做有信心並積極支持。

　　此外領導可能提出一些要求，例如進行培訓或者其它要求，咱們能夠根據實際狀況肯定是否要進行或者不進行。此時就有可能須要調整計劃內容和時間。

3、借彙報機會領導瞭解他們上項目的初衷。

　　不少時候領導看待一個項目角度和高度和咱們進行下層調研人員理解是不一樣的，這個時候和領導交流其對項目的想法，是有助於咱們在調研工做進行時判斷一些業務需求是否真的符合企業領導的構思，並能夠尋求更好的方案。

　　從調研的角度，瞭解不一樣人員對同一個項目的需求也是調研工做的一個內容。領導層每每是管理性思惟，業務層每每是技術性思惟，兩種思惟達成一致才能設計一個好的方案。這些都須要經過調研得到。

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

　　調研若是有一段時期，不可能每天找領導彙報，也不能不彙報，那麼這個時候就能夠請示領導每幾天安排一次當面彙報仍是書面彙報。

　　多和領導見面，多用確定語氣溝通，就會讓領導不斷強化對咱們積極的印象，逐步將感情的天平傾斜到對咱們有利的方面。

　　不過有一點，首次和高管彙報工做原則必定要言簡意賅，不要表現本身。

　　讓領導創建對本身我的專業認同感就能夠說達到目的了，對於一個領導認爲有專業技巧的人，見面的機會他是必定會繼續提供的，因此不要追求一次搞定，這都是極爲有害的冒進思想。

　　低調切入，等調研過程當中收集足夠事實了再根據狀況肯定是否逐步擡高調門，表現本身的思路，是更穩妥和合理的策略。

　　和高管見面可能存在一個時間不肯定因素。因此在調研準備階段計劃確認時儘可能先保證這個時間，若是到現場時間不能保證，必須留機動調整的可能，通常狀況下能夠進行企業歷史，企業現狀，網絡硬件，組織機構等方面的業務調研，也能夠爲領導見面提供溝通的素材。

　　此外高管並不是必定是企業的最高領導，高管是依據企業規模和項目規模動態肯定的，通常選擇彙報高管對象的原則是對項目直接負責的人上級或以上級別的人。

　　企業大了，高管並不是只有一位，有的彙報必要時該重複就重複，不要給別人不尊重的感受。

　　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 常見錯誤十二：調研工做表現不職業

　　有的調研人員工做很努力，但在現場很可貴到用戶的承認，就是由於常常表現出一些職業不成熟的緣故，甚至有的表現是不道德的。

　　常見不成熟職業表現有：

　　一、 不徵求用戶贊成就翻看其資料(若是有的競爭對手敏感資料想得到，也必定不要給別人看到)；

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

　　三、 在用戶現場上網工做時順便聊天看和工做無關的內容；

　　四、 沒有徵求用戶贊成使用用戶電話；

　　五、 用戶贊成使用電話講起來沒完沒了；

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

2.11 調研工做方法推薦

2.11.1 每日調研流程

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

　　二、訪談

　　三、當場複述內容，確認理解對方表達的問題

　　四、當即將整理訪談結果造成文檔記錄，確認須要繼續瞭解的內容和未清楚的內容

　　五、若是須要，安排時間請被訪談對象確認訪談文檔記錄，特別是一些關鍵名詞定義部分

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

　　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 編制簡化提綱

　　準備一份書面的演示提綱是頗有幫助的。在書寫提綱的過程當中，組織演示的方式會逐步明朗起來。在演講過程當中，帶可用提綱來提醒本身。將你的三四個要點標上「一」、「二」、「三」和「四」，而後在它們下面分別寫上二級標題(一、二、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 典型用戶分級，肯定服務模式

　　典型用戶名單肯定後當即要根據典型用戶可考察參觀實際效果狀況對典型用戶分級。

　　第一類典型用戶是能夠隨時安排參觀考察的典型用戶。

　　第二類典型用戶是可公開宣傳，但不方便或不肯意接待參觀的典型用戶。

　　第三類是能夠在售前非公開資料和口頭介紹的用戶。

　　第四類是千萬不能公開介紹和宣傳的用戶，一些典型應用不佳用戶。

　　第一類用戶應增強商務聯繫，簽定宣傳合做協議，保障按期走訪服務，讓典型用戶和咱們長期合做，心情舒暢；

　　第三類、第二類典型用戶要根據狀況肯定是否可投入資源使其向第一類，第二類用戶逐步轉化，一個公司第一類典型用戶多了，市場口碑就起來了，甚至服務價格就能夠提升了。

　　1、2、三類用戶都要明確詳細的服務模式，並落實到具體實施部門或區域團隊管理，並按期檢查服務工做是否完成和質量，這樣才能造成一個閉環的管理體系，不至於口頭重視，實際上由於沒有利益(國內目前大部分項目服務是沒法收費的)保障而無資源投入。

　　第四類用戶也很重要，有些用戶在業內或當地知名度極高，但軟件公司在這裏遭遇了滑鐵盧，因此公司必定要動態審查在方案、公司介紹、對外提供典型用戶名單上儘可能不要出現此類用戶名單，避免被潛在客戶諮詢或提出參觀要求時被動。

5.4 典型用戶應如何管理(下)(

　5.4.1 宣傳模式規劃

　　典型用戶的輻射效力體如今四個領域：

　　售前主動介紹(文字和口頭介紹)

　　客戶現場參觀考察

　　媒介(新聞性媒介和專業期刊)

　　行業或政府主辦經驗交流會議

　　因此典型用戶分級後，應根據這四個輻射效力領域分別設計相應的套路，針對不一樣典型用戶提供組合管理方案。

　　首先要爲典型用戶提供在公司網站介紹材料，公司宣傳手冊，公司各類方案材料，公司售前PPT，公司內部培訓材料保持一致的宣傳介紹材料。

　　完整的典型用戶宣傳介紹材料應包括如下幾個內容：

　　企業LOGO

　　企業廠區或典型產品照片

　　企業概述(有地位突出地位，無地位突出業務特點)

　　企業應用軟件狀況介紹

　　企業應用現場或鑑定現場照片

　　企業高管或項目負責人對項目一句簡短而經典的評價

　　企業應用效益

　　項目獲獎狀況(是否得到國家省部市級信息化建設項目獎勵，或者進入863主題計劃)

　　其次典型用戶現場參觀考察工做須要組織的第二個方面，下文專門另文介紹。

　　第三典型用戶媒介報道也很是重要，第一種是商業性媒介報道，主要是重要客戶簽單，取得階段性驗收，最終結項，經過重要機構鑑定和獲獎應及時在公司網站，合做媒體上發佈新聞材料，這類消息軟件公司要有很強的主動宣傳意識。

除了直接商業報道外，還有一種軟媒介報道，就是和典型客戶項目負責人合做就項目實施特點應用或者實施經驗發表專業學術性文章在專業刊物上，擴大知名度同時也爲不少企業項目負責人解決不少實際問題。

　　最後應用良好的典型用戶常常有機會參加政府行業或者集團內部主辦的經驗交流會或者鑑定會，軟件公司在申報項目的時候也常常須要請典型用戶合做做爲項目用戶單位，並須要配合蓋章，所以咱們應創建典型用戶的資料庫，隨時備雙方作彙報材料準備用。

　　若是有，如下材料通常都應保留：

　　詳細的企業狀況介紹(企業概況、行業地位、產品系列、人員組成、聯繫方式)

　　企業信息化整體規劃方案

　　企業項目招標書(選型評分表)

　　企業項目投標書或者項目售前解決方案

　　企業實施解決方案

　　企業對外項目實施經驗總結或成果彙報材料(文字和PPT)

　　軟件公司內部實施經驗總結(突出業務特色和功能應用特點)

　　項目雙方主要負責人員簡歷(應每一年保持更新)

　　其它值得管理的資料

　　完成這三個層次的工做，典型用戶管理應該說就是比較完整業務過程。

5.5 用戶現場考察應如何組織？(

通常信息化項目用戶都會提出現場考察典型用戶的要求，那麼如何組織用戶現場考察工做呢？

　　典型用戶考察組織有三個層面：

　　5.5.1 第一是公司層面

　　軟件企業對於已明確能夠現場考察的用戶應要求創建考察模式，並由專人負責維護，通常就是項目實施團隊負責設計項目現場考察行程地點，業務介紹套路，實施應用介紹套路和相關PPT，並和企業接待人員充分溝通，就交流必須向潛在客戶講到的亮點，保證前來參觀用戶能夠看到項目實施過程當中的功能特點或實施特點，不枉此行，也是對潛在客戶的一種尊重。

　　公司還要提早和典型用戶溝通，確認現場實施狀態，評估項目可考察性，肯定是否須要一些服務資源投入或者請典型用戶進行專門準備。

　　公司還要注意和典型用戶約定考察參觀方式和考察頻率，瞭解典型用戶安排方式是現場參觀，仍是投影集中介紹，仍是在某個業務地點集中介紹；典型用戶一個月但願接待幾批考察對象，本月是否有重要任務，不方便接待考察等狀況。這些狀況要提早通知到各地客戶經理知情，方便對潛在用戶進行介紹。

　　公司還要收集整理不一樣考察用戶關注的針對性問題或者考察評分表，造成問題集和參考評分表備案，這些內容將能夠成爲公司規劃產品發展，瞭解用戶功能需求和實施要求的重要渠道，也是向其它潛在用戶提供如何考察的素材資料，對於一些共性問題還能夠造成公司級標準解決方案，有利於各個方面人員和客戶溝通。

　　最後公司要協調項目實際負責實施人員，或者對項目狀況比較熟悉，業務能力很強的顧問型人員在考察期間全程陪同，至少要保證現場有軟件商的實施人員陪同。

　　這些工做通常有公司或者級別較高主管部門協調組織落實。

　　5.5.2 第二是客戶經理層面

　　具體到某個項目考察，這是客戶經理應該負責的工做。

　　首先客戶經理接觸到一個項目，應該要主動判斷是否安排用戶考察，用戶考察是否和公司考察放在一塊兒進行，仍是在本地典型客戶處安排考察，在何時進行爲妥。

　　根據這個判斷客戶經理再根據企業業務特色和需求和公司提早溝通，肯定可參觀用戶對象，請公司相關典型用戶負責人員提供若干典型用戶相關資料，以備用戶查問。

一旦客戶提出考察要求，要提早和典型用戶或經過公司和典型用戶預定時間。注意儘可能避開用戶負責人不在，公司陪同參觀介紹人不在，企業休息日，或者拉閘限電(這個是近年中國特點)等狀況，緊急響應，安排行程和場地，並把前來考察用戶詳細狀況(人數，性別，級別，行程，關注點)造成文檔提交公司。

　　客戶經理還須要瞭解潛在客戶關注的問題，不少用戶會提早設計一系列針對性考察問題，這些問題要提早發送公司典型用戶負責人準備，並經過公司或親自和典型用戶溝通，介紹前來企業狀況，前來人數和時間，但願考察內容，可能要問的問題，以便讓典型用戶自我介紹時更清楚狀況，可以達到較好的考察效果。

　　考察過程原則上客戶經理應全程陪同，客戶經理在陪同過程當中要作三件事情：

　　一、隨時和公司內部溝通，通報狀況和提醒注意

　　通常前來考察的客戶須要經過客戶經理介紹給相關人員，並單獨和相關考察接待人員溝通，說明一些文字描述可能遺漏或者不容易寫清楚的狀況。整個考察過程當中要隨時注意進行這類溝通，保持公司一致性。

　　二、親自安排好客戶的衣食住行

　　客戶經理讓客戶感到親切認同就是成功，這些都是經過接待細節中體現，因此客戶經理要親自作好這些工做，爲從此商務工做奠基感情基礎。

　　三、寫備忘錄

　　客戶經理全程陪同最重要目的是隨時瞭解客戶在考察過程當中交流思路，判斷項目技術或商務側重點應該是什麼，便於進行下一階段商務和技術公關策劃，不少交流內容不是當事人是沒法清楚表達和了解的。所以必定要利用這個機會充分了解用戶想法，甚至趁熱打打邊鼓，促進客戶下決心。

　　考察完成後客戶經理要主動幫助用戶準備一份考察備忘錄。通常企業出來考察回去是要寫彙報材料的，但大部分人出來考察由於行程緊張並無當即組織材料，只是簡單記錄，這樣一輪考察下來，再去組織準備工做量也不小，並且信息遺忘可能很大。其實不少人並不擅長寫文檔，若是這個時候有一份可參考的資料對這些用戶該是多麼方便的事情。

　　因此客戶經理要主動在用戶考察完成後寫一份記錄考察過程的備忘錄，備忘錄能夠分這麼幾個內容，考察日程安排，考察用戶狀況介紹和應用狀況介紹，考察過程交流關鍵內容及回覆記錄。這樣的備忘錄將很是有利於咱們後續工做，有這樣現成的素材在，不免用戶會直接引用，一引用匯報給領導就給咱們增長了成功機率，特別是當競爭對手都沒有作這個工做，就體現了咱們的用心。

　　認真作事只能把事作對，用心作事才能把事情作好，就是這個道理。

　　備忘錄體現了咱們對考察後工做的間接控制，保證考察印象能有效傳遞，但備忘錄有一個原則，客觀中立，能夠迴避弱點，但不能誇大粉飾。

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 培訓組織

　　培訓計劃編制前要和相關培訓資源進行溝通，確認是否可按時間進行培訓工做，同時要檢查培訓場地是否足夠，是否有足夠資源上機練習，是否有其它必要設備，等這一切就位後還要和用戶確認最終培訓人數，時間安排和其它相關可能工做。

　　若是用戶是到軟件公司培訓，還要落實用戶的餐飲安排，住宿安排，接送安排，參觀安排，訂票安排，禮品安排，並列計劃報公司批准承認後執行，這些都是一次成功培訓組織中要考慮的工做。

　　培訓組織要特別重視培訓環境的質量，高質量的培訓環境應提早準備好相關軟件環境，並調試經過，不要等用戶開始上機才進行安裝。

　　培訓組織中最重要的工做是完成培訓教材的編制，並提交審覈或主動安排審覈。

　　審覈培訓教材的方法有兩點，一是確認教材思路是否清晰，細節是否完整，二是看培訓者講解是否易懂，和教材一致。其中對講解能力的驗證要更強於教材的驗證，沒有教材同樣能作好培訓，沒有好的輔導講解能力，很難作好培訓。

　　基本上不少公司對這個工做是忽視的，也是沒有人負責的，這是一個很大的問題，這種事情驗證成本並不高，由於能夠採用認證資格的方式進行，一個好的培訓人員，對其培訓能力的驗證在一段時間內只須要驗證一次就行，而這個能力至少能夠在一年內發揮巨大的做用。

　　本人親自檢查過不少對軟件的講解，說個不中聽的話，這樣的培訓能讓用戶明白咱們是幹什麼的都難，別說讓他跟着你走，按共同的意圖推動項目。

　　此外培訓教材中數據錄入規範也是培訓重點內容，這個講解倒不難，實施人員要結合企業實際精心準備是關鍵。

　　數據錄入規範準備要點有三條：

　　一、 習慣填寫方式說明及樣例

　　二、 正確填寫約定及樣例

　　三、 常見問題處理方法

　　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 創建向上的團隊文化

 

　　項目經理通常都是個性很強的人，不太可能用一樣的方式約束項目經理的作事方法，固然越是成功的項目經理，行事方法越具備共性。

 

　　而項目團隊成員和項目經理的互相認同對一個團隊成長很是重要，也是工做可否快速進展的關鍵。

 

　　項目經理要及時承認成員工做，隨時用進展鼓舞團隊士氣。對不少人而言，物質獎勵的預期是很清楚的一件事情，國內的項目經理通常也沒有多大空間去對項目成員工做進行物質獎勵，所以在這樣的邊界條件下咱們更要尋求利益機制之外的團隊合做方式。