累鬥累---走出軟件作坊：三五個人十來條槍 如何成爲開發正規軍（二十）
http://blog.csdn.net/david_lv/archive/2008/06/18/2561986.aspx 讀後感：都說程序員是IT民工。其實是我們自己願意做民工也不願意與客戶交往。客戶是上帝，客戶是中心，一點不假。你讓上帝滿意了，還可能繼續作民工麼？ 原文：有時候，我感覺事情就好像大螃蟹，總是一串一串的。
我剛聊過新項目如何收集需求，就有人跟我提老產品升級需求的管理。
有人說：老師，我看了許多IT項目管理的書籍，也講到需求管理。但他們是需求調研、需求分析、需求確認，好像都是針對新項目的，我們是老產品維護， 老闆隨便打一個電話就讓我們添加一個需求功能，我們哪裏去做需求調研、需求分析、需求確認這些環節啊。老闆說我們一天坐到家裏面編程序，根本不瞭解客戶需 求。最瞭解客戶的是每天和客戶待在一起的實施人員，所以要讓實施人員來給我們軟件提需求加功能。但是，實施人員那叫什麼需求啊，比如說XXX功能不好用， 比如說建議更易用一些。老闆不相信我們，怕我們把實施人員反映的需求給屏蔽了，專門派了一個人每天收集各個渠道來的需求，每天還要上報給老闆，而且還每天 向老闆要報告，今天修改了多少需求，還有多少需求沒有改，沒有改的需求什麼時候能改完，都要我們開發部給答覆。而且，隔幾個月，老闆就把全公司人員都召集 在一起，爲軟件提需求。一羣人坐在一個會議室，每個人都可以提，一個模塊一個模塊的提。當場打開軟件功能，演示，說明，闡述軟件應該做成什麼樣。我們開發 人員就跟開批鬥會一樣，這個標題不要這樣叫，那個對齊不對，這裏不夠明顯應該加粗字體或者給一段紅色的提示。唉，活得真窩囊，天天修改這些亂七八糟的所謂 需求，還要被人追着趕着問進度，還要忍受被所有人都罵開發的什麼爛軟件。老闆也覺得我們水平不行，需求也怠工不修改，兩天才修改了3個需求。而且越修改需 求越多，軟件越不穩定。我們哪還敢提漲工資啊。
我說：你這種情況很普遍。現在很多軟件公司都是老闆開店，三五個人十來條槍，他有客戶關係，賣個軟件做個實施賺點錢。公司也不大，如果軟件做不好， 實施做不好，多年積累的客戶關係就以後不好再銷售了，這就等於把老闆的命根斷了。所以老闆肯定會盯死軟件開發和軟件實施。客戶使用效果好才能以後有更多的 單子做。而且你們作爲開發人員，又不接觸客戶，怎麼能理解某個需求的真正意圖呢？當然老闆的思維邏輯對，你們這樣，怎麼能理解客戶需求呢？當然實施人員最 瞭解，提的需求最有權威。換你做老闆都這麼想。
我也經歷過這段日子。人和人的信任，都是在做事中不斷看人試人品人，才能取得信任，才能放權。我的老闆也如此。
如何比實施人員更瞭解客戶需求？如何讓老闆相信我比實施人員更瞭解客戶需求？這也是擺在我面前的一個問題。
我是把產品放在一個產業中看。看競爭對手，看業界標杆，看業內管理專家，所以我對產品的升級完善，是基於產品戰略的，是基於盈利模式和競爭力構建的。如何引出更多的盈利增值產品，如何保證產品更有競爭力，是我思考的重點。
而實施人員提的需求，都是和他實施的客戶具體業務流程有關。客戶就是這樣，咱們軟件不滿足客戶這樣做，就要改。不改，客戶就不滿意，實施就推進不下 去，實施項目就延期，自己的實施就不力。所以，實施人員爲了保護自己的利益，也要開發部必須改。而且一開口就是你從來沒有去過現場，你根本不瞭解客戶。
老闆信誰？
我不是業界知名管理專家，我也不是業界明星CTO。老闆怎麼能信我對業界產品競爭的判斷呢？
而實施人員，天天真實的和客戶待在一起，他們反映的肯定是真實的。
第一輪迴合，以開發部門老老實實修改需求爲結束。
我開始在網上寫對行業的觀點。因此也有幸結交了許多知名的行業內管理專家。他們稱讚我的觀點獨到，思考有遠見。文章也受到不少網友的追捧。
我會把一些我寫的文章鏈接適機轉給老闆，轉給喜歡思考提升的實施顧問。我也會經常把和我思想觀點相似的文章鏈接轉發給老闆。
老闆繼續組織全體人員需求討論大會，但這次他有了轉機。雖然仍然是讓人統計未完成需求數，老追問什麼時候才能完成，但顯然他不像過去那樣主導與控制整個過程了。他說：你也要跑跑客戶，不能老待在家裏。
於是，我跟着實施顧問也跑了一些客戶，有時候，還帶上主力開發一起走訪。
過去，開發和實施衝突很大。開發覺得沒必要改，實施覺得必須改，最後實在不行就拿出老闆來壓。而且，客戶有自己特殊的業務地方，有能人者還自己想解 決方法。而實施人員呢，在現場實施，陷於此境此客戶，也覺得客戶的解決方法有道理。於是非要開發人員按照那樣的方法修改。但開發人員知道，按照那樣的方法 修改軟件，那軟件就死住了，這個功能只能給這家客戶用了，其他客戶沒法用。於是開發人員罵實施人員胳膊往外拐，就站在客戶那方對付自己公司的同事。
但是一走訪，開發人員也才認識到客戶原來面臨這樣的問題，客戶那樣提需求其實是爲了解決這樣的問題。但很可惜，客戶的想法太侷限，只爲自己這個問題 想解決方法。如果開發人員當時在現場，就能明白客戶面臨的問題根源，就能設計出更好的軟件功能來滿足。唉，都怪實施人員不分析問題根源，只看表面問題現 象，還自以爲是提最佳解決方法，還讓開發部實現。應該是，你提出你的需求問題，怎麼解決是我們開發部自己的事，我們會綜合考慮平衡。
我走訪客戶的目的，主要目的有三：
1改善一下老闆和實施人員對開發部的認知。他們都認爲開發部只是一羣不懂客戶需求整天做在電腦跟前不用出差說話神叨鬍子拉碴的敲代碼者。“你們不懂需求”，讓這個理由去一邊去。
2改善一下開發人員和實施人員的衝突。讓開發人員也理解理解客戶的現狀。有些事情是不可改變的，有些事情是人爲故意的，我們作爲開發，不應該去把軟 件假設在一個理想的工作環境下，那樣的軟件是不適合現實使用的。該委曲求全還得做。罵客戶管理水平太次，罵客戶都是白癡都毫無意義。我對開發內部老說：人 家是白癡嗎？難道人家買你的軟件也是白癡。那豈不是反過來說你的軟件誰買誰就是白癡？那豈不是說明你的軟件很爛毫無價值麼？咱們每個月的工資從哪裏來？是 老闆發給咱們的嗎？老闆又不是白癡，發錢給咱們？老闆的錢也是從客戶口袋裏掏來的。
3瞭解客戶現狀，想方法如何去引導與影響客戶。客戶面臨最急需的問題是什麼？客戶對軟件的認知程度如何？客戶把軟件價值認爲成什麼樣？客戶認爲這套 軟件應該是幹什麼的？（有的客戶認爲我們的軟件應該帶上QQ）。實施人員是怎麼給客戶講解軟件中的管理思想的？實施人員是如何培訓客戶的？
走訪回來之後，我做了兩件事情：
1發表了一篇我的走訪感受。發到網上，也發給老闆，也發給實施人員。老闆看了以後說了一句話：“看來走訪走訪很有必要，以後要多做”。老闆、實施、開發，之間的關係改善了許多。
2把走訪過程中確實應該改進的需求安排給開發人員。由於開發人員也是切身體會，很快就改了出來。實施人員說這個功能做的不錯，很實用。
第二回合，開發、實施，平手。
然後，我又把業界知名專家的一篇文章中提到的評價模型內嵌到軟件中。過去，我們雖然在產品PPT中老是宣稱自己的管理思想，但在軟件中很難看到落 實。所以，實施人員在實施過程中只能講操作。而操作，客戶覺得還不如一個EXCEL好輸入好修改好查詢好統計，所以客戶希望軟件修改成這樣修改成那樣。反 正，客戶現有系統解決不了的問題就都提出來。而現在，終於有了一個可以講可以量化的管理模型。這套評價模型成了這個軟件的核心亮點。客戶爲了應用這套評價 模型，也樂意錄入數據，維護數據。
第三回合，開發勝出。
然後我提出了需求管理系統，WEB型。不管誰在外面實施，或者是老闆突然提出，或者是銷售提出，都錄入到需求管理系統中。把需求分類，分優先級，量化安排開發計劃，有的放矢吸收需求改進軟件。
我還提出，每年召開用戶需求會議。邀請有思路有積極改進想法的客戶參會。大家面對面交流共同問題，共同需求，共同探討未來改進。
引領客戶，引領老闆和實施人員對產品，對業界，對未來，對競爭的認知提高。
這就是開發部。
OO、設計模式、接口？！和客戶一點無關？那客戶爲什麼要給我們錢？那老闆爲什麼要給開發部錢呢？那開發部存在的意義在哪裏？翻譯成代碼？就這點意義？還要月薪上萬？憑什麼？
你的價值在哪裏？
