八部眾---走出軟件作坊:三五個人十來條槍 如何成為開發正規軍(二十三)


      這幾天在規划新產品,新產品要做什么,兩個來源:

      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),優化和重構也是很容易做到的。

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

      但這么多要求,我們都要有目的分階段的一步步達到。而且,往往我們不斷補齊上一階段留下的遺憾,我們此階段的努力又會形成下一階段的遺憾,總是無法達到一個賞心悅目可以笑看江波的軟件。可能,世事輪回皆此規律。

      后注:

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

      一個好軟件,也是如此多的標准特性,也是如此共生又如此矛盾,頗為神似。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com