這幾天在規劃新產品，新產品要做什麼，兩個來源：
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），優化和重構也是很容易做到的。
網友們討論了許多，有實用性、穩定性、容錯性、性能、可測試、可理解、可修改、可實施、可支持、靈活性、移植性、兼容性、安全性、易用性....。
但這麼多要求，我們都要有目的分階段的一步步達到。而且，往往我們不斷補齊上一階段留下的遺憾，我們此階段的努力又會形成下一階段的遺憾，總是無法達到一個賞心悅目可以笑看江波的軟件。可能，世事輪迴皆此規律。
後注：
八部衆爲佛經故事。八部分別爲八種似人非人，似神非神，似鬼非鬼，似善非善，似惡非惡的種類組成，他們散落在佛界三十三重天，或喜或嗔或怒或思或樂，但種類之間總是互相關聯互相矛盾又互相共生，層層迷障無法拈花微笑。
一個好軟件，也是如此多的標準特性，也是如此共生又如此矛盾，頗爲神似。