燈塔客戶---走出軟件作坊：三五個人十來條槍 如何成爲開發正規軍（三十三）
http://blog.csdn.net/david_lv/archive/2008/07/14/2649438.aspx讀後感：萬事開頭難，產品銷售不好做。不做就永遠做不來。
原文：
過去一直做項目，也就是說，沒有東西，先有方案，方案客戶同意簽單，纔開始調研、設計、開發、測試、安裝、培訓、支持。營銷部對這種模式也是很熟悉了。
但從前年開始做產品。也就是說，沒有明確的客戶，也沒有特定的客戶調研，開發出來客戶到底需要不需要不知道，客戶買不買單不知道，客戶希望多少錢購買也不知道。這就讓營銷部沒有底兒了。
不能讓產品悶死在研發部啊。我得想轍。老闆和營銷部也都認可公司應該由做項目提升到賣產品，但誰也沒有經驗，都是做大客戶大項目出身的。而且現在的 項目也做的不錯，有軟件單子都逮住，客戶關係也不錯，客戶朋友都主動介紹單子過來，公司收入和增長髮展也不錯，於是研發產品就成了一個大家都認可的理想， 但銷售就是另外一碼事。幹嗎費那勁呢？
人對自己不熟悉的東西是天生拒絕的，就如同我們黑夜走一條從來沒有走過的路一樣總以爲會碰見鬼一樣。
雖然我也內部寫了不少文章來闡述新產品，但到底有多少人看，到底大家想法如何，都不得知。我每逢中午喫飯的時候，我還故意旁敲側擊問，但回答幾乎相似：看過了，寫的不錯。或者是看了，但太忙，沒細看。
我也忍不住向老闆建議了多次，希望給營銷部講一次新產品。老闆嗯了好幾次。開季度會議的時候，我在全體高管會議上又提了出來，這才大家達成一個共識：星期一下午研發部給營銷部培訓新產品。
培訓也做了，大家也都討論了一下午，營銷部對產品也提出來一些建議，我們都記了下來。但我們也修改完了，還是沒有下文。大家可想一個新產品的推廣有 多難。所以說，一個好產品，研發階段其實是非常簡單的，也是非常短的時間的，設計、編碼、測試都不是具有挑戰性的工作。而一個好產品，要獲得營銷人員認 同、老闆認同、實施部門認同、支持部門認同，更要獲得客戶的認同，是需要非常多的運營和各環節的人員的支持。不少新做開發主管的網友也曾經和我反應過他們 的鬱悶，我說這些都是很普通的事情，完成產品研發，只佔產品成功的10%而已。一個產品死在公司裏無人知曉，很普遍。想讓大家都支持你，憑什麼？就憑你是 研發他是營銷，他必須配合？
到了新年度會議了，我又把新產品的推廣銷售提了出來。在年度會議期間，我給全體員工又做了一次培訓。老闆也參加了培訓，感覺產品已經做了這麼久還是 做的不錯的，是時候銷售了。於是，開營銷部會議的時候，就給營銷部下了一個任務，新產品的銷售必須加入新年度的銷售計劃，並且有銷售任務，還要落實到具體 人，還要有銷售考覈。
這下可捅了馬蜂窩。營銷部也算是客戶打單風裏來浪裏去，什麼人沒見過什麼陣勢沒見過什麼突然詰問沒見過，衆多營銷部人員羣起攻之，藉助他們的營銷經 驗和客戶經驗，啪啪啪，提出的產品缺陷句句在理。老闆也不置可否了，但仍然下了句話：我們肯定要今年推新產品，不過，可以不作爲銷售任務，但具體的負責人 要明確。
銷售部有了具體產品負責人。但負責人只是個銷售新手，跑銷售項目還只是個助手而已，更沒做過產品銷售（可想銷售部的打算）。產品負責人新人沒見過多大世面很是緊張，忙着安裝軟件學習軟件。
但該產品負責銷售人辦了一些下面的事情：
1他試用軟件，他感覺不太易用。他認爲自己是一個普通的用戶，自己感覺變扭客戶也應該不舒服。就建議讓開發人員修改。我也沒大重視，我也不能說人家 啥也不懂瞎胡鬧。就這樣，開發人員開始改動。從界面的顏色、圖標、字體大小、文字命名、操作方法、說明文檔，都按照他的要求改動了一遍。
2這個認真負責的銷售人員，感覺軟件不穩定，就召集了銷售部一些人員來測試。估計連說明書也沒有看，就開始測試。BUG倒是沒有找到，銷售部內部開 始PK。他說他的操作方式更符合客戶，他說他理解的流程更正確符合現實。這個銷售人員一開始還和其他銷售人員PK，畢竟這個軟件的前期修改都是在他的思路 框架下修改的，這次其他銷售人員又提出不同的意見，這不就和他不一致了麼。既然他負責這個產品，他就認爲自己對這個產品理解更深透。但其他的銷售人員的客 戶經驗比他足，有時候別人說出來的理由他也不知道客戶是不是那樣想的。於是達成一些協議：都有理，先記下來，能改的讓開發人員都改了。
開發人員問我怎麼辦？我說靜觀其變，先讓他們內部PK。
兩個月過去，啥銷售動靜都沒有，就在家裏悶頭修改、測試。銷售新手成了產品設計師、項目經理，控制了新產品的功能設計、進度、質量。這真是個奇怪的 角色。我曾經在QQ羣中也見過這種現象，有的網友說他們的組織形式就是這樣，產品的定義歸產品部。這個組織形式本來是沒有問題的，就連微軟的軟件設計也是 由程序經理提出的。而微軟的程序經理就相當於產品經理，大多爲MBA出身。但問題在於，微軟的程序經理都是非常深刻理解軟件的，也是非常深刻軟件營銷的。 我曾經很驚訝微軟的一個管理崗位出身的人居然對微軟的開發工具的具體技術有如此深的瞭解。而國內，往往是劃分了類似的組織結構，卻無法配齊相應的人。做產 品設計的，往往不懂軟件。做軟件的人，往往卻只會編寫代碼。而一個既會做軟件，又懂產品的人，如果沒有可見的成功案例，也是被別人看作不懂軟件不懂產品的 人。
我給老闆提了個建議：可以先去客戶處調研一下。別老悶在家裏，先聽聽客戶怎麼說。
於是這位銷售聽從老闆指令，聯繫自己熟悉的客戶去調研。
但調研過程讓人大跌眼鏡。我聽我的開發人員回來反映說簡直不是去調研了，而是去銷售去了。
這就是一個銷售的思維慣性。
當然，最後的結果是客戶留下了演示版答應嘗試使用。但仍然沒有了下文。
季度會議，我提了出來：咱們的軟件產品並不是在屋子裏閉門造車，咱們的軟件設計前期也是借鑑了多家客戶的現有系統，並且在網上和客戶交流了很久，也 借鑑了很多其他同類的軟件。咱們是騾子是馬就拉出去遛遛。會不會游泳，在池子邊是學不會的。一腳踢下水，嗆幾口，死不了，但會很快就學會游泳。
老闆也詢問了調研情況，但銷售新手說不出多少重要的理由，老闆於是親自換人操盤。
新換的負責人是個典型銷售型。軟件有BUG？微軟還有BUG。軟件不完善？完善了怎麼升級呀。
上來就是不斷給他的客戶打電話，寒暄過後問問現有系統的使用情況，然後根據客戶現狀引出現在這套產品。客戶一聽，好啊，我們正想有這樣的功能。老銷售說我們這套系統已經好多家試用了，都反響不錯，而且能跟現在我們的系統無縫連接。
電話是打完了，演示版、說明書都給了客戶。老銷售的三把斧也玩完了。但誰也沒做過產品銷售，不知道怎麼推新產品。問我接下來該怎麼辦？
我說，做燈塔客戶。他們客戶之間都互相走動，消息特靈通。先讓他們中的有影響的客戶先用起來，咱們給其他客戶宣傳推廣的時候就容易的多。而且燈塔客 戶用的好，咱們的影響力就大的多。如果一開始怕失敗怕困難，先做些小客戶，反而費了半天努力起不了多大的水花。還不如咬咬牙頂一頂，成了也就成了。我想起 了我9年前在其他公司做燈塔客戶時的情景，那時候就是尋找了一家小客戶，上線倒是挺快，也沒修改多少，但也沒有給軟件的成熟帶來啥提升，在業界的影響力也 沒有多大，金額單子也籤的少，但最後的支持服務沒少打電話，而且客戶的IT能力有限有時還需要去出現場。唉，一切都歸結於是第一個客戶。客戶處處拿這個拿 捏我們，說我們拿他們做的實驗小白鼠，就得送佛送到西。而且籤的時候就故意找的當地的客戶，就是爲了做實施的時候成本低。但從此也形成了一種壞的實施毛 病，就是程序員去實施，當場改程序的實施模式。這種模式的形成就在於做燈塔客戶是程序員親自去的，誰寫的代碼就誰去做燈塔客戶實施，客戶有什麼需求就當場 立即改掉，希望能很快把軟件完善起來。但這樣做就形成了慣性了，實施第二家燈塔客戶仍然照舊如此，最後燈塔客戶都做了好幾家還無法交付給實施部門去做。差 點把開發部變成開發、實施、支持全功能的部門。費了好大的勁做過渡轉換，如今後遺症還不小。
他問我怎麼選擇燈塔客戶？
我說，首先找喜歡創新的客戶。產品，也是有生命週期的。一開始，不能找大的客戶，也不能找小的客戶。咱們的系統還算初出茅廬，大的客戶會控制咱們， 影響咱們未來的發展。而小的客戶，做完了影響力也不大。所以，我們要從中不溜的客戶中間挑選喜歡創新的客戶。不喜歡嚐鮮的客戶是沒有應用的積極性的，反而 對新事物天生產生懷疑和拒絕。
這個創新的客戶還需要系統建設方面有影響力。有些客戶很喜歡業務創新，但天馬行空的，不去想系統能不能實現，最後反而想的多說的多，系統方面卻無法 落實。這類客戶也經常會看見。所以，我們要找的就是喜歡創新、系統建設重視的客戶，而且這個客戶需要規模在中等。這就是典型的燈塔客戶。
只有燈塔客戶做起了標杆，有影響力的有分量的大客戶在推廣的時候才能關注起來。這就好比江湖，江湖老大並不關注那些小嘍囉，而他最關注的人恰恰是第二第三名，因爲一不小心這些人就會超過。
燈塔客戶爲生命週期的第一撥，大客戶爲第二撥，第三撥就是看着創新激進派和大客戶們都應用的不錯，那些抱着懷疑的客戶纔會蜂擁而至。這類客戶就如同企鵝一樣，誰也不下水，怕水中有海豹。等其他的企鵝下水了沒有事了才紛紛下水。
這位銷售老手果然重點關注了幾個喜歡創新又系統建設的不錯的客戶。啥也別說了，肯定能搞定，能不能借我一個星期開發人員，我要領到現場去給他們修改開發，肯定簽單回來。
我有些猶豫，我怕重蹈覆轍。但第一個客戶的單子又是如此的珍貴，畢竟要走出第一步。
我說去一個星期，但說好了，必須只能是一個星期，不管完成沒完成，就一個星期。而且這次去了，還需要跟一位實施經理。你做項目經理，但你不能越位做 產品設計。你負責好客戶溝通、協調，上線推動，實施經理和開發人員調度就行。而開發人員不能直接面對客戶，所有的客戶需求必須由實施人員收集整理，按照咱 們正規的實施流程走。
於是，三人上路了。在此過程中，銷售擔任項目經理、實施經理、開發人員作爲組員。我還儘量控制，但仍然沒有避免客戶和每個人都談需求。我嚴厲警告開發人員：沒有我的確認，你不能開發。即使一個很小的改動，都必須給我報告回來。哪怕是MSN報告或電話報告都行。
我還不斷讓他們各自堅守各自角色。那一個星期，我花了大量的精力在不斷區分他們的懼色，在客戶要求和他們三人之間達到平衡，不要讓他們三個人都變成需求人員和實施人員。
一個星期到了，銷售說他已經簽了單子，能不能讓開發人員再留一個星期，讓開發人員開發利索了再回去。
我說我要看看還剩下多少活兒。於是我讓開發人員報了一下工作列表和工作量估計。我也聽取了實施經理的實施效果和進度的報告。我也拿開發人員的工作列 表找銷售去確認了一下看看是否是這樣子。三個人都確定好後，我又把期限寬了三天。三天內，開發人員要完成什麼工作我都安排好，做完後離開。實施人員按照正 規實施流程走，不能無限期在現場實施，否則客戶永遠會說自己不會。要在三天後安排培訓、考試，不能實行目前的一對一培訓。
那三天，真是很累的三天。銷售要說服客戶三天後離開，實施要編寫培訓課程和考試內容，開發要保證按時完成任務，誰都不輕鬆，每個人的壓力都很大。
終於開發人員和銷售回來了。實施經理留在現場，我又派了一位實施培訓人員跟進。終於，實施流程和過去又保持一致了。雖然，銷售回來後仍然被客戶當作 項目經理，但銷售儘量的傾聽客戶，不過實施執行卻轉給了在現場的實施經理。開發人員仍然在按照實施流程中產生的需求列表修改着，和以往開發流程、實施流程 一致。並沒有因爲這次的特殊性而改變。當然，實施經理幾次着急上火直接給開發人員打電話，但我都讓開發人員自己記錄下來，排進需求管理工具中。這個過程當 然痛苦，稍不加管理，開發人員就成了實施人員和支持人員，說不定爲了救火還需要衝到現場。
好不容易，第一家燈塔客戶上線驗收了。第二家燈塔客戶，就是這位實施經理帶領培訓專員去了，沒有跟銷售，也沒有跟開發。和過去的實施一樣。
我說：你還需要帶一名實施經理和培訓專員。
實施經理問我爲什麼？如果再多去人，那兩個實施經理怎麼分工。
我說：另外一組實施團隊，只管培訓課程課件製作、培訓、考試。你管理好項目進度、需求協調。
於是，四人上路了。
第二家燈塔客戶順利了許多，實施時間也縮短了許多。正規的實施文檔、課件都製作了出來，新產品的實施人員也帶了出來。開發人員在辦公室，有我做管理指導，有專業測試在每日測試，軟件質量也得到保證。
現在，這個產品已經銷售的很正常的，開發流程、實施流程仍然很流暢。
走出第一步，千萬要把型塑好，千萬不要特殊事情特殊處理，否則特殊處理很容易變成習慣處理，最後再也無法回到正常的流程上來了。
想讓開發部不變成實施部，第一步很重要。