走出軟體作坊（二十）

二十、累鬥累

　　有時候，我感覺事情就好像大螃蟹，總是一串一串的。

　　我剛聊過新項目如何收集需求，就有人跟我提老產品升級需求的管理。

　　有人說：老師，我看了許多IT專案管理的書籍，也講到需求管理。但他們是需求調研、需求分析、需求確認，好像都是針對新項目的，我們是老產品維護，老闆隨便打一個電話就讓我們添加一個需求功能，我們哪裡去做需求調研、需求分析、需求確認這些環節啊。老闆說我們一天坐到家裡面編程式，根本不瞭解客戶需求。最瞭解客戶的是每天和客戶待在一起的實施人員，所以要讓實施人員來給我們軟體提需求加功能。但是，實施人員那叫什麼需求啊，比如說XXX功能不好用，比如說建議更易用一些。老闆不相信我們，怕我們把實施人員反映的需求給屏蔽了，專門派了一個人每天收集各個渠道來的需求，每天還要上報給老闆，而且還每天向老闆要報告，今天修改了多少需求，還有多少需求沒有改，沒有改的需求什麼時候能改完，都要我們開發部給回覆。而且，隔幾個月，老闆就把全公司人員都召集在一起，為軟體提需求。一群人坐在一個會議室，每個人都可以提，一個模組一個模組的提。當場開啟軟體功能，示範，說明，闡述軟體應該做成什麼樣。我們開發人員就跟開批鬥會一樣，這個標題不要這樣叫，那個對齊不對，這裡不夠明顯應該加粗字型或者給一段紅色的提示。唉，活得真窩囊，天天修改這些亂七八糟的所謂需求，還要被人追著趕著問進度，還要忍受被所有人都罵開發的什麼爛軟體。老闆也覺得我們水平不行，需求也怠工不修改，兩天才修改了3個需求。而且越修改需求越多，軟體越不穩定。我們哪還敢提漲工資啊。

　　我說：你這種情況很普遍。現在很多軟體公司都是老闆開店，三五個人十來條槍，他有客戶關係，賣個軟體做個實施賺點錢。公司也不大，如果軟體做不好，實施做不好，多年積累的客戶關係就以後不好再銷售了，這就等於把老闆的命根斷了。所以老闆肯定會盯死軟體開發和軟體實施。客戶使用效果好才能以後有更多的單子做。而且你們作為開發人員，又不接觸客戶，怎麼能理解某個需求的真正意圖呢？當然老闆的思維邏輯對，你們這樣，怎麼能理解客戶需求呢？當然實施人員最瞭解，提的需求最有權威。換你做老闆都這麼想。

　　我也經曆過這段日子。人和人的信任，都是在做事中不斷看人試人品人，才能取得信任，才能放權。我的老闆也如此。

　　如何比實施人員更瞭解客戶需求？如何讓老闆相信我比實施人員更瞭解客戶需求？這也是擺在我面前的一個問題。

　　我是把產品放在一個產業中看。看競爭者，看業界標杆，看業內管理專家，所以我對產品的升級完善，是基於產品戰略的，是基於盈利模式和競爭力構建的。如何引出更多的盈利增值產品，如何保證產品更有競爭力，是我思考的重點。

　　而實施人員提的需求，都是和他實施的客戶具體商務程序有關。客戶就是這樣，咱們軟體不滿足客戶這樣做，就要改。不改，客戶就不滿意，實施就推進不下去，實施項目就延期，自己的實施就不力。所以，實施人員為了保護自己的利益，也要開發部必須改。而且一開口就是你從來沒有去過現場，你根本不瞭解客戶。

　　老闆信誰？

　　我不是業界知名管理專家，我也不是業界明星CTO。老闆怎麼能信我對業界產品競爭的判斷呢？

　　而實施人員，天天真實的和客戶待在一起，他們反映的肯定是真實的。

　　第一輪迴合，以開發部門老老實實修改需求為結束。

　　後來，老闆又親自主導組織了幾次實施人員需求會議，什麼都可以提，都記下來，讓開發人員改，讓實施人員監督開發人員修改，確認修改的符合實施人員的要求，並且實施人員負責測試。每次大約都能記個上百條，從要求簡化SQLSERVER資料庫安裝（因為實施顧問都非技術出身，沒接觸過SQLSERVER之類的產品，用的最多的是EXCEL和WORD，因此用報表設計師給報表格式挪挪位置大部分人都不會）到把介面都換成綠顏色背景（說符合公司形象）。這種局面直到我在各個部門各個環節各個層次應用了多種策略才改變。

　　過了一段時間，老闆看著實施人員都沒有事情可幹，很奇怪，就問為什麼不測試軟體？實施人員回答說：開發人員沒有改多少需求，我們正在等待他們開發呢。

　　然後老闆就找我，為什麼不修改？

　　我說：程式員一直在修改，但另一方面，我們已經修改了多次，滿足需求300多條，但是我們的產品競爭力增強了嗎？我們的特點在哪裡？我們的亮點在哪裡？我們的競爭力在哪裡？

　　老闆說：不管怎麼說，這是客戶的需求，客戶買了我們的產品，我們就有義務為他們滿足需求。

　　我說：看這條需求，客戶要求我們做一套視頻會議在我們的管理軟體中。

　　老闆說：那你找找網上有沒有免費開源的。

　　我不再爭辯。因為我知道，在他心中，做什麼產品，叫什麼企業管理軟體都無所謂，客戶需要在ERP中加入遊戲，如果理由充分也是可以的。重要的是客戶不能得罪。客戶關係是他的生存之本，而非產品。

　　我開始在網上寫對行業的觀點。因此也有幸結交了許多知名的行業內管理專家。他們稱讚我的觀點獨到，思考有遠見。文章也受到不少網友的追捧。

　　我會把一些我寫的文章連結適機轉給老闆，轉給喜歡思考提升的實施顧問。我也會經常把和我思想觀點相似的文章連結轉寄給老闆。

　　老闆繼續組織全體人員需求討論大會，但這次他有了轉機。雖然仍然是讓人統計未完成需求數，老追問什麼時候才能完成，但顯然他不像過去那樣主導與控制整個過程了。他說：你也要跑跑客戶，不能老待在家裡。

　　於是，我跟著實施顧問也跑了一些客戶，有時候，還帶上主力開發一起走訪。

　　過去，開發和實施衝突很大。開發覺得沒必要改，實施覺得必須改，最後實在不行就拿出老闆來壓。而且，客戶有自己特殊的業務地方，有能人者還自己想解決方案。而實施人員呢，在現場實施，陷於此境此客戶，也覺得客戶的解決方案有道理。於是非要開發人員按照那樣的方法修改。但開發人員知道，按照那樣的方法修改軟體，那軟體就死住了，這個功能只能給這家客戶用了，其他客戶沒法用。於是開發人員罵實施人員胳膊往外拐，站在客戶那方對付自己公司的同事。

　　但是一走訪，開發人員也才認識到客戶原來面臨這樣的問題，客戶那樣提需求其實是為瞭解決這樣的問題。但很可惜，客戶的想法太局限，只為自己這個問題想解決方案。如果開發人員當時在現場，就能明白客戶面臨的問題根源，就能設計出更好的軟體功能來滿足。唉，都怪實施人員不分析問題根源，只看錶面問題現象，還自以為是提最佳解決方案，還讓開發部實現。應該是，你提出你的需求問題，怎麼解決是我們開發部自己的事，我們會綜合考慮平衡。

　　我走訪客戶的目的，主要目的有三：

　　1.改善一下老闆和實施人員對開發部的認知。他們都認為開發部只是一群不懂客戶需求整天做在電腦跟前不用出差說話神叨鬍子拉碴的敲代碼者。“你們不懂需求”，讓這個理由去一邊去。

　　2.改善一下開發人員和實施人員的衝突。讓開發人員也理解理解客戶的現狀。有些事情是不可改變的，有些事情是人為故意的，我們作為開發，不應該去把軟體假設在一個理想的工作環境下，那樣的軟體是不適合現實使用的。該委曲求全還得做。罵客戶管理水平太次，罵客戶都是白癡都毫無意義。我對開發內部老說：人家是白癡嗎？難道人家買你的軟體也是白癡。那豈不是反過來說你的軟體誰買誰就是白癡？那豈不是說明你的軟體很爛毫無價值嗎？咱們每個月的工資從哪裡來？是老闆發給咱們的嗎？老闆又不是白癡，發錢給咱們？老闆的錢也是從客戶口袋裡掏來的。

　　3.瞭解客戶現狀，想方法如何去引導與影響客戶。客戶面臨最急需的問題是什嗎？客戶對軟體的認知程度如何？客戶把軟體價值認為成什麼樣？客戶認為這套軟體應該是幹什麼的？（有的客戶認為我們的軟體應該帶上QQ）。實施人員是怎麼給客戶講解軟體中的管理思想的？實施人員是如何培訓客戶的？

　　走訪回來之後，我做了兩件事情：

　　1.發表了一篇我的走訪感受。發到網上，也發給老闆，也發給實施人員。老闆看了以後說了一句話：“看來走訪走訪很有必要，以後要多做”。老闆、實施、開發，之間的關係改善了許多。

　　2.把走訪過程中確實應該改進的需求安排給開發人員。由於開發人員也是切身體會，很快就改了出來。實施人員說這個功能做的不錯，很實用。

　　 第二回合，開發、實施，平手。

　　然後，我又把業界知名專家的一篇文章中提到的評價模型內嵌到軟體中。過去，我們雖然在產品PPT中老是宣稱自己的管理思想，但在軟體中很難看到落實。所以，實施人員在實施過程中只能講操作。而操作，客戶覺得還不如一個EXCEL好輸入好修改好查詢好統計，所以客戶希望軟體修改成這樣修改成那樣。反正，客戶現有系統解決不了的問題就都提出來。而現在，終於有了一個可以講可以量化的管理模型。這套評價模型成了這個軟體的核心亮點。客戶為了應用這套評價模型，也樂意錄入資料，維護資料。

　　第三回合，開發勝出。

　　然後我提出了需求管理系統，WEB型。不管誰在外面實施，或者是老闆突然提出，或者是銷售提出，都錄入到需求管理系統中。把需求分類，分優先順序，量化安排開發計劃，有的放矢吸收需求改進軟體。

　　我還提出，每年召開使用者需求會議。邀請有思路有積極改進想法的客戶參會。大家面對面交流共同問題，共同需求，共同探討未來行業機遇挑戰，共同尋找解決方案。

　　引領客戶，引領老闆和實施人員對產品，對業界，對未來，對競爭的認知提高。

　　在我的影響下，公司的IT諮詢業務、IT教育業務、IT服務業務、IT整合業務、IT產品發展戰略、整合夥伴，都逐漸專業化的發展了起來，給公司提供了越來越的盈利模式與收入渠道。

　　OO、設計模式、介面？！和客戶一點無關？那客戶為什麼要給我們錢？那老闆為什麼要給開發部錢呢？那開發部存在的意義在哪裡？翻譯成代碼？就這點意義？還要月薪上萬？憑什嗎？

　　你的價值在哪裡？