八部衆---走出軟件做坊：三五我的十來條槍 如何成爲開發正規軍（二十三）[轉]

這幾天在規劃新產品，新產品要作什麼，兩個來源：

      1看看業界最新的產品，先來個海闊天空的頭腦風暴。從ipod模式談到金山與google的合做，從android談到百度的電子商務，從孫正義的投資校內網到汽車GPS、車載充電、車載MP3。但這些只是引新思路，真正還要落回到本身所在的行業所在的客戶。正規的幹，和如今業界的標杆比，咱們水平差，和他們用正規的方法交鋒，只有輸的份兒。因此，從來以少勝多，都是以奇取勝。咱們做爲中小企業，把金庸+古龍，或者王朔+魯迅這樣來個改良菜，把其餘行業或領域的新產品新模式引進來，或許才能突破現有大佬制定的遊戲規則。

      2踏踏實實，仍是要去檢索咱們的需求庫。歷年來，全國客戶提出來的數以幾千條的需求都記錄在其中。小說，就是來源於生活而高於生活。因此，需求就是現實生活，咱們的新產品必須從現實需求中提煉出來。不然就是空談新產品，而根本沒法落實。

      我常常看到很多內地程序員拿Google的開發和國內的開發比。在Google，軟件是藝術，你們閱讀源代碼也閱讀的賞心悅目，大罵國內軟件業毫無創新。我我的覺得，咱們的積累仍是過短，從業者年齡和經驗結構偏低，還沒法從現狀而創新。另外咱們面臨的資金、客戶的限制，咱們更是沒有多少發揮空地。因此我認同軟件工廠作法，大批量高質量低價格快速度的生產。可是，現狀是，連能把這種生產模式作的好的軟件企業都寥寥無幾。大量的軟件企業沒法實現高質量大批量快速度，低價格也是下降質量剋扣員工得來，勢必引發客戶和員工的反抗而終結低價格。因此，咱們作新產品，也不能抱着科學家研究的思路，而更應該是在資金、時間、人的素質、人的數量、競爭壓力、客戶現狀的框架下的量化可控的研發，有階段，有目的，有重點的研發。

      要有控制的研發，就要有需求管理工具來管理需求庫，能夠分類查詢、檢索、統計。就須要老老實實去回顧需求庫。若是須要調研，就須要有方法的調研，從組織結構、過程、考覈、優化這幾方面來梳理需求，而不是開討論會。

      有了這麼多需求收集回來，你們估計會很暈。由於需求來自全國客戶七嘴八舌，有來自豪放的東北，有來自細膩的華東，有的來自客戶老闆，有的來自部門小經理，有的來自部門小組長，有的來自IT人員，有的來自最終操做者。因此，真是林子大了，什麼鳥都能飛出來。我記得我在2000年實施的一家客戶，最終用戶年齡大，打字不靈，但願有個語音輸入。這就是需求。若是咱們面對這樣的需求，咱們確定會說不可能完成。但咱們每每不仔細想如何去解決問題，反而恥笑客戶傻瓜，怎麼不把年輕的換上崗位。但咱們瞭解到那位最終用戶是一位專業經驗很高的人員，崗位沒法代替，咱們都閉嘴了，咱們最終仍是解決了問題，但確定不是語音輸入。因此，咱們整理分析需求，不能恥笑這條需求確定是用戶拍腦門想出來的，那條需求是客戶本身笨。到最後，仍是咱們本身愚弄了咱們本身。就如同遇到BUG，總是有程序員說不可能，我機器就不報錯，或者說確定不是個人問題，我都檢查過了。但最終最終，仍是代碼問題。這種現象家常便飯。

      一個軟件，對於不一樣的人來講有不一樣的要求。若是你把這些需求歸類，你每每會獲得這些要求特徵。

      對於銷售來講，演示的時候穩定、易用、好看、速度快就是關鍵。

      不少銷售並不懂軟件，但要買軟件，這就是現狀（別笑）。咱們要就問題解決問題，恥笑問題也解決不了問題。原本就不懂軟件，還不易用，銷售根本無法給客戶講清楚本身賣的這個東西到底有什麼用。

      若是還不穩定，忽然報出一個英文錯誤，銷售在那麼多客戶面前更是漏了臉，吹的那麼大現實倒是如此，讓銷售的誠信損失了，必然會到老闆那裏告一狀，以挽回本身打單不利的面子，錯全是研發部的問題，那時研發部只有吃不了兜着走了。

      若是軟件作的灰不啦嘰的，本身都以爲沒什麼出彩的，客戶也以爲很普通，在價格上就沒法提高。而銷售，最重要的就是賣一個好價格。軟件也實用，也先進，但打單過程當中，給客戶演示也就那麼短的時間，並且來聽的人大可能是之後不實際操做軟件的人，對軟件到底功能作的多細膩，處理各類複雜業務多麼靈活，都根本沒法看出來，就看到這個軟件很差看。就如同咱們遇到一個女孩，很漂亮，到底心靈如何，尚未那麼多時間和機會去了解，但首先感受就不錯，願意去接近。若是遇到一個女孩很普通，從內心一開始就有坎，不是抱着主動去了解的心態，而是懷疑和旁觀的心態，就不容易瞭解一個女孩子。軟件，和女孩同樣，都一樣的道理。

      演示的時候，我每每會看到這樣的情形，點下一個查詢按鈕，10秒鐘出不來結果。客戶和銷售都在等，會議室很靜，你們都在盯着屏幕都在等待，但就是不出來結果。銷售急了，拼命亂點，更加重了不穩定和性能約束，最終報錯不斷，或者乾脆銷售很尷尬的按下Ctrl+Alt+Del。

      對於實施來講，最重要的就是軟件穩定。軟件不穩定，客戶怕軟件使用過程當中出現問題，就不敢放實施人員走。而實施人員上面還有實施總監在管，有項目進度和經費的控制，因此實施總監老催實施人員爲何還不回來。實施人員也急呀，今天查報表，明天改數據，老是按下葫蘆起了瓢。

     軟件穩定的基礎上，最令實施人員頭疼的就是客戶需求的事情。若是每遇到一個需求都須要讓程序員搞定，而程序員又少，就把實施人員晾到現場了。實施人員原本就想和客戶搞好關係，以但願可以把項目順利進行下去。這下，長時間解決不了客戶需求，實施人員就交待不下去，固然要給程序員施加壓力。這就是開發部每每是軟件公司最受攻擊的一個部門，銷售、實施、支持都攻擊開發部。因此，爲了能讓實施人員現場知足客戶需求，開發人員每每想了不少辦法。最常想到的就是開發平臺。但我見到許多開發平臺，簡直就是面向開發人員的（什麼XML、SQL、流程編輯）。實施人員只懂業務，對計算機軟件操做並不嫺熟。因此，開發人員必需要給實施人員提供實施人員能用的起來的實施工具。不少軟件系統沒有實施工具，只有一個光桿軟件，孤立無援。

      對於培訓來講，軟件易用最關鍵。你幫助寫的再詳細，相信看的人都很少（只有咱們可愛的程序員纔去勤奮的鑽研那些詳細的WINDOWS API幫助）。軟件易用，培訓的工做就輕。

      有不少軟件，沒有演示版，沒有操做視頻錄像，沒有最新版本幫助文件，沒有新版本更新說明。就憑一張嘴對着電腦屏幕講。出了新版本，還不知道哪些功能發生了改變，還照着過去學習的知識講。客戶親手一操做，發現講的和看到的不同就有了疑問。培訓人員都臉紅，本身都不知道怎麼使用，也解釋不了。因此培訓文檔對於培訓人員來講也很重要。

      對於支持來講，軟件穩定是第一位的。不然本身的支持電話非打爆不可，那樣，支持的工做又累、錢又少還成天鬱悶解決不了，還不如不幹支持。軟件若是不穩定，那麼軟件必須可跟蹤。最怕軟件出了問題，客戶打來電話就說：軟件很差用。這個很差用怎麼查問題啊。到底怎麼個很差用，報錯的界面截圖是什麼樣的，在哪一個模塊，怎麼操做的，錄入了什麼數據，報的內部英文錯誤是什麼，版本號是多少，軟件打了多少補丁，操做系統是什麼版本，操做系統打補丁沒，數據庫打補丁沒，防火牆是怎麼設置的，年月日和貨幣符號設置對不對，打印機設置對不對，本身的IP網絡設置對不對。這些內容，最好像WINDOWS同樣，出了錯，把全部須要跟蹤的信息都自動收集起來，而後報出一個提示框，能夠發送報告給微軟。因此，咱們作了一個日誌模塊，能夠自動截圖，自動發送日誌，自動記錄當時操做的SQL語句，自動記錄當時的客戶輸入數據和點擊操做流程。給軟件跟蹤解決問題加快了許多效率。若是一個個去問用戶，用戶都不知道這些信息到哪裏去收集，再一頓反覆解釋尋找，解決問題就很慢了。有不少時候，用戶因爲時間太長有其餘事在身，就放棄瞭解決這個問題，長此以往，因爲問題越積累越多，就漸漸不用這個軟件了。

      對於支持來講，軟件自動升級也很是重要。咱們每每遇到不少問題都是軟件沒有打某個漏洞補丁形成的。並且還有不少問題是因爲客戶端版本不統一形成的。如何能自動的、所有客戶端一塊兒升級，一發布補丁就自動全國升級，不少問題客戶還沒來得及發現就被解決了，滿意度就上來了。

      對於後續版本開發維護人員來講，代碼容易看懂，代碼好修改纔是最關鍵的。程序員想了不少方法：業務開發平臺，有意義命名，小函數分割，函數接口靈活，面向對象，設計模式、重構等等。可是，代碼仍然愈來愈複雜，愈來愈不容易看懂，愈來愈很差修改。其緣由就是因爲每一個客戶都提出各類各樣的需求，有時不一樣客戶之間的需求仍是矛盾的，大量的代碼實際上是爲了處理客戶異常業務，還有的是爲了堵某個特殊操做發生的BUG，還有的是爲了兼容不一樣版本之間。這纔是代碼難閱讀難修改的根源。

      對於數據量大性能要求高的應用，性能是很關鍵的持續改進方面。

      對於安全性要求強的應用，設計安全的方案，編寫安全的代碼，安全的測試覆蓋是很重要的工做。

      對於測試人員來說，軟件必須具備可測試性。軟件代碼寫完了，什麼樣的操做或結果是正確的，什麼樣的操做和結果是不正確的，沒有人告訴他，也沒有文檔，這就不具備可測試性。這就要求有設計文檔，詳細寫明什麼樣的操做和結果是正確的。這樣就有了可測試可驗證的標準。不少軟件不穩定，最後加了專職的測試人員也不穩定，其根源不在於測試人員測試方法不對，測試經驗不豐富，而在於根本沒有測試依據，測試人員只能本身憑經驗亂點亂試，根據經驗來判斷這個結果是正確仍是錯誤。尤爲一些報表，輸入條件，數據都出來了，可是數據之間是有關聯關係的。但這個關聯關係並無設計文檔說明，測試人員並不知道，就認爲這個功能是好用的。其實這個報表數據是錯誤的，雖然能正常顯示。

      對於文案人員來講，軟件必須能讓文案人員編寫文檔。許多軟件沒有設計文檔，代碼開發完畢，讓文案人員本身邊學習操做邊輔助測試邊編寫文檔。文案人員不是設計人員，不是代碼編寫人員，不是測試人員，是對軟件作陌生的人。他自己都對軟件不瞭解，可想他本身寫的幫助文檔有多大的可幫助性。軟件沒有幫助文檔，其根源就在於沒有設計文檔。而沒有設計文檔的根源，在於根本沒有編寫設計文檔的人。誰來編寫設計文檔？程序員？程序員再寫代碼。測試人員？文案人員？實施人員？培訓人員？到底誰來寫這個設計文檔。

      我看過許多網友在討論怎樣一個軟件纔算一個好軟件，說了不少方面。可是從現實來講，咱們真的須要那麼多方面嗎？

      每每現實一開發，什麼好軟件的標準都丟了，程序員單槍匹立刻手。還有一些開發團隊，但願能作一個好軟件，因而但願把這些好軟件的標準都實現了，最後週期長，在有限的人力和開發時間內沒法完成，只好有始無終，最終仍是個爛軟件。

      業界有個笑話，就是說微軟的軟件，從第三個版本才能使用。

      這說明，一個好軟件，應該具有好軟件的標準，但一個好軟件，不是在一個版本就把這些標準所有實現。而是有步驟有重點的實現，逐步達到一個好軟件。

      那麼，這些好軟件的標準就必然須要排個順序。

      編軟件，是爲了什麼？

      是爲了賣。

      怎麼才能賣個好價格呢？

      嗯，包裝成漂亮的就能賣個好價格。鞏俐穿上棉襖也就是個秋菊，村姑化完妝也是個靚女。韓國整容你們有目共睹。

      就是這個思路。

      因此，我並無把軟件實用放成第一位。由於新軟件研發，你並無很深入理解客戶，你假設認定這個需求很實用，到了現實使用發現沒法執行下去，這就廢了。並且實用不實用，每一個客戶的理解是不同的。有人以爲電子郵箱很實用，有人以爲電子郵箱沒有用。就這個狀況。因此，我設計軟件，每每只設計不超過3個實用亮點，實用亮點多了，咱們開發也週期長成本高難度大客戶可能還接受不了，並且過於複雜銷售和實施人員沒法給客戶講明白。因此有1-2個宣傳亮點就OK。在不斷銷售不斷實施過程當中，客戶會天然提出來需求，軟件就會不斷實用起來。

      而後，我就會把軟件包裝漂亮。專業的銷售方案PPT，專業的幫助文檔，專業的軟件界面，專業的圖標，統一的操做，統一的字體，統一的專業詞條，統一的對齊，專業的提示（不少軟件提示竟然是：「很差意思，出錯啦」。真汗~）。這須要美工、文案、界面開發人員三者配合。

     漂亮事後，就是穩定。穩定就須要軟件具有可測試性。

     這樣，軟件就能夠出去銷售初版了。

     到了軟件第二版，客戶簽單量就上來了。實施工具就要提上開發日程，不然多個項目並行提出來的需求能把程序員的工做排到明年。

      到了軟件第三版，這是很關鍵的階段。不少軟件，生或死就在這個階段，就看能不能過去這個檻。這個檻正值有部分客戶和影響力，但還須要大規模高速擴展的時期，把握不住產品發展策略重點，極可能就漸漸的無聲無息了。因此這一階段主要是在加強現有功能和穩定性的基礎上，儘可能使軟件易用、易維護。軟件必須可跟蹤可自動升級，這樣才能支持日益擴張的客戶羣，才能使問題迅速解決，而不是大規模擴散。在這一階段，不主張多增長功能，這樣會使軟件複雜性加大，阻礙了大量客戶的理解，而大部分客戶都是通常客戶，而非理念先進的燈塔客戶，能讓大量的通常客戶快速理解到軟件的好處和應用操做上手，是很重要的階段任務。

      到了軟件第四版，軟件愈來愈複雜，如何兼容，如何容錯，如何容易閱讀，如何容易修改就成了首要問題。這個版本，重點就是內部代碼重構優化。

      到了軟件第五版，性能是個問題。過去3-4年積累的數據使系統愈來愈慢。優化性能成爲第五版的重點。

      到了軟件第六版，因爲這麼多版本的升級，功能非常複雜了，使本來易用的軟件如今變的愈來愈難懂了，究竟是特殊處理的業務。把經常使用功能和很是用功能分開，把正常業務處理和異常業務處理分開，作到組合裁減，一部份不經常使用的功能就漸漸萎縮掉，一部份經常使用的功能作加強。在這一版本，重構易用性成爲重點。

      軟件到了第七版，就幾乎在打補丁了，再也不投入大量人去維護了。軟件進入大銷售大實施大維護的收割階段，維護本版本的開發團隊在萎縮，下一代產品在醞釀。

      這就是一個軟件生命週期中，不一樣時期的不一樣開發重點。把握好節奏，合適的時機作合適的事情，一點都不浪費投入人力。

      可是咱們要注意，性能是一個結構性的問題。因此雖然在第五版才調整性能，但對於企業管理軟件來講，必須在基礎設計的時候就強烈關注數據庫設計。由於數據庫結構一旦固定就沒法更改。從過去的經驗來看，只要數據庫沒有設計缺陷，性能的瓶頸主要在代碼上，只要改進代碼和功能設計（有些功能設計自己就性能很低，大量的功能集成在一個界面上豈能不慢？），性能是很好解決的。

      對於代碼的重構和優化，若是從始到終遵循着函數封裝，小函數分割（我曾經碰見過一個3000行的大流水函數，不敢下手，怕一旦修改不知會發生哪些BUG），優化和重構也是很容易作到的。

      網友們討論了許多，有實用性、穩定性、容錯性、性能、可測試、可理解、可修改、可實施、可支持、靈活性、移植性、兼容性、安全性、易用性....。

      但這麼多要求，咱們都要有目的分階段的一步步達到。並且，每每咱們不斷補齊上一階段留下的遺憾，咱們此階段的努力又會造成下一階段的遺憾，老是沒法達到一個賞心悅目能夠笑看江波的軟件。可能，世事輪迴皆此規律。

      後注：

      八部衆爲佛經故事。八部分別爲八種似人非人，似神非神，似鬼非鬼，似善非善，似惡非惡的種類組成，他們散落在佛界三十三重天，或喜或嗔或怒或思或樂，但種類之間老是互相關聯互相矛盾又互相共生，層層迷障沒法拈花微笑。

      一個好軟件，也是如此多的標準特性，也是如此共生又如此矛盾，頗爲神似。