軟件產品開發，為什么失敗

轉自Liu Hang

軟件產品開發，為什么失?。吭谧隽怂哪甑能浖_發，親身經歷了幾個失敗案例之后，我不得不對這個問題進行反思。我所接觸到的朋友多半是做軟件開發的，他們和我一樣，經歷失敗的例子比成功的要多得多。從網上的各種文章、論壇得來的信息也一樣充滿著悲觀。為什么這么多的失??？對于這個問題，有著各種各樣的答案。諸如需求不明，不斷改變；項目管理混亂，時間一拖再拖；技術方案出錯，技術難題解決不了；人員流動頻繁；產品出來后沒有市場、沒有競爭力等等問題，不一而足。正是失敗的原因各種各樣，在產品開發的過程中要面臨一個又一個的險灘與暗礁，而每一個都有可能是致命的威脅。如何面對這些危險，繞過這些險灘？以下一些是我個人的思考。把軟件開發看作一個整體的流程，本文試圖從產品開發的整個流程來闡述我們會遇到的種種問題已及提出一些自己的見解。

?

一、軟件產品的立項

一個軟件產品的開發和項目有著許多不同，一般來說，軟件項目(project)都是因為有了明確的客戶，或者已經有了合同或意向而開始啟動的。軟件產品(product)則完全不一樣了。在一個產品沒有開發出來之前，基本上沒有客戶。當然也有人僅僅憑著一套大腦中的想法或概念就能找到客戶，對這些人我只有佩服。當然大多數公司只能先拿出一套自己的產品去推銷，才有可能找到定單。所以就有了做產品的想法。

在這些軟件公司中又可以分兩種情況。一種是在某個行業做了多個項目，也積累了一些行業、技術等經驗。每一個新的項目都要重復很多同樣的工作，效率自然不高了。這時公司很自然的想到要有自己的產品。于是開始產品的立項了。

另外一種公司則完全不是這樣。他們不是在某個行業做過多少項目，甚至根本沒有做過一個項目，就要雄心勃勃的去做產品。這種情況每天都在發生。他們以前可能做系統集成的，可能賣硬件的，或許根本就不是IT行業的，或者恰好做了一個項目，現在他們要進軍軟件行業了，所以急切的要做出自己的產品去打市場。于是他們在一番調查論證后，開始了產品的立項。

在這兩種情況下，可以明顯的看得出前一種公司的基礎要好得多，成功的幾率也要大多多。但這并不表明后一種就會失敗。在目前階段關鍵是看他有沒有全面的調查論證，進入這個軟件行業，做這個產品是否可行。很多產品的失敗，從一開始就注定的了。公司沒做過多少認真的論證就匆匆開始了。軟件行業，產品開發都有著自身的很多規律，如果公司的決策層、領導層沒有經驗，也沒有去學習，拿著別的行業的經驗去套用它，那失敗也就不遠了。舉個簡單的例子，軟件開發中人力資源是最重要的。軟件開發人員的薪水在各個行業中是算非常高的了，特別對于有豐富經驗的人才更是與此。從傳統行業過來的領導層如果不明白這點，也就找不到優秀的人才了。

無論哪種公司，他們在做產品立項時都要做好以下的心里準備：

??????? 軟件產品開發投資是很大的，特別是對哪些想做大型的、優秀產品的公司。

??????? 軟件產品開發周期也是比較長的。兩、三年做一個產品是很常見的。不要認為半年就可以做一個很好的產品

??????? 軟件產品是很容易失敗的。既有可能產品開發不出來，也有可能沒有市場。

?

如果一個公司沒有這些心里準備，那結果就很可能失敗。為什么這么說，以我的親身經歷來說吧。我曾經做過的一家公司，主要業務是做系統集成的。后來開始了一個物流軟件的產品開發。在2000年左右，物流行業軟件剛剛興起，也算是一個比較好的方向。公司組建了一個開發團隊，開始了長達兩年的曲折的研發過程。由于在研發過程中遇到的種種問題，無法給公司領導層一個明確的結果，在研發開始初見曙光的時候，公司高層終止了這個產品。公司的高層忍受不了大量的投資和過長的時間。任何想做產品的公司都一定要有這些心里準備，要充分估計投資額和研發周期。

假設公司經過了充分的論證，也有了一定的投資和時間預算，產品立項了。但這只是一個良好的開端，因為下面的任何一個過程的失敗，都有可能導致全盤皆輸。

?

二、團隊構建

產品立項后，就要開始組建研發團隊了。軟件開發是一個既要高度協作、又有獨立創造的智力活動。所以人的因素是關系到產品開發能否成功的一個重要方面。應該說產品能否研發成功，研發團隊的合理構建是關鍵性的。一個公司的領導層或許沒有多少軟件研發的經驗，但必須要保證能構建一個合理的研發團隊。就點很容易理解，就是讓合適的人去做合適的事。不過反過來說，如果領導層沒有軟件研發的經驗，那也很難構建一個合理的團隊。那怎樣構建一個好的團隊呢？這個問題沒有一個非常普遍的答案。各個產品的規模、技術難度都不相同，答案也不一樣。

我們時常看到的情況是，公司會任命一個研發經理或叫PM,負責整個研發過程。于是問題就出來了。這個PM是負責管理工作還是技術工作，或者兩個都一起負責？怎樣規定PM的職責權限？如果沒有對這個問題的明確答案，那危險就隨之而來的。就來我的經歷過的來說吧。

在離開上一家公司后，我來到另一家軟件公司做網上教育平臺的產品研發。前期階段可以說沒有一個專職的項目經理，管理工作基本上由一個做技術的Team Leader（架構師）負責，雖說也有不少問題，但大家基本上還是團結在一起安步就班的工作。后來公司為我們團隊招來一個PM，此君是海龜派，在國外、學習工作好幾年，也有技術背景。我們對他也充滿期待。沒想到過了不久，他居然把我們的Team Leader給開了，找了一些大家都不認可的理由。并自任技術負責人，對我們的大部分的技術方案都持否定態度，并嚴厲要求我們服從他的技術領導。如果他精通技術也就罷了，關鍵是他的技術一點也不怎樣，還自我感覺良好。那最終的結果可想而知了。產品基本上失敗，技術人員紛紛跳槽，最后，這個 PM也只得走人了。

這樣的故事每天都在發生，大量的技術人員在抱怨領導不懂技術，瞎指揮。在我的案例中，可以明顯的感覺到，公司對這個PM沒有明確的職責劃分，或者這個PM沒有擺正自己的位置。這個PM應該做做管理工作，而不是負責技術。

做軟件開發的都知道，一個團隊中一般都有一個技術領導，或者叫架構師（Architect）。 那他和PM怎樣劃分職責？

如果要開發的產品規模比較大，比如人員數達到10人以上。這時面臨的管理、組織工作比較多，公司應該考慮起用一位專職的PM來負責這方面的工作。他的主要工作包括人員招聘，提供開發團隊所需資源，制定計劃，監督實施等，同時，他應該是一個能夠鼓動士氣，懂得調動員工積極性的親善的領導人，對作為一個PM的職位來說，個人的素質和性格應該具有更決定性的意義，他主要工作是為研發團隊提供一切必要的服務，監督的作用應該包含其中。在這樣的團隊里，必須存在一位架構師來全面負責技術工作，他有權獨立決定技術方案，他與PM的關系是團結與合作，而不是領導和被領導，架構師應該得到PM應有的尊重，而這點在中國很難做到。很多PM干涉架構師的技術工作，甚至起而代之，造成團隊之間的混亂。上面的案例正是說明了這一點。架構師一般都是有一點完美主義，他總是希望看到產品做得更加出色，但這是否讓產品開發走向不可控制的地步？事實上，架構師要對現實情況作出妥協（如時間、資金的限制），也就是對PM作出妥協。如果說PM代表時間、資源的現實主義，那么架構師就代表著完美的理想主義，他們就是在不斷的合作、妥協中共同推動產品的發展。

對于開發的產品規模較小，也可以完全不設置專職的PM。設置一位Team Leader，他既負責整個技術、也同時負責團隊的管理工作。如果認為負擔較重的話，可以為Team Leader配置一位秘書（項目管理人員），他的主要功能是輔助Team Leader做一些管理方便的工作。如人員招聘的準備工作、開發計劃的監督等等。

當團隊合理的構建之后，下面的就進入了產品研發的核心流程了。

?

三、業務建模&需求分析

前面的過程更多的是由企業領導層決定的，當我們技術人員進入這個團隊時，只能祈討已經有了一個好的開始：公司下定決心要研發這個產品，有一個優秀的、明白自己職責的PM?，F在已及下面的所有流程都和技術人員（包括需求人員）密切相關，是技術人員決定著產品成敗與否的時候了。

無論做產品還是項目，第一步做需求分析，這一點無須置疑。幾乎每一個做軟件的都知道，需求的重要性。可是為什么那么多的產品或項目最后失敗的主要原因是需求問題呢？

在軟件研發中，產品的業務需求比項目的業務需求更難以確定。產品一般面對的是某個行業的通用需求，涉及的客戶面更廣，合理的提取這些需求以形成更通用的產品本身就是一件很困難的工作。對于一些以前沒有這些行業經驗的軟件公司來說，這就更困難了。很多公司真因為沒有很好去做需求分析的工作而導致產品的失敗。在我以前做物流的那家公司里，也是犯了這樣嚴重的錯誤。我們當時對物流行業并不熟悉，也不能很好的把握業務需求，產品研發在來回反復的過程中消耗了大量的時間與精力。

對于這個問題的解決，幾乎所有的軟件工程方法都提出了好的方案：引入領域業務專家（Domain Expert）。我們的研發團隊中，一定要有這樣的角色，即使我們沒有這樣一個專職人員，但一定要有人扮演類似的角色（例如架構師）。業務專家可以和架構師一起進行業務建模的工作，而架構師則偏重于技術方面，把業務模型轉化成系統需求，按照RUP的流程來說，就是最終變成一個個Use Case。而一個好的業務專家是非常難得的，這就是為什么很多公司有這個意識而沒有做好需求工作的重要原因：由于資金、時間等各方面的限制，他們最終放棄了這一步，而把希望寄托在架構師或其他開發人員身上，而這其中的風險就可想而知了。

也有很多公司沒有業務專家，而把這個角色附加給架構師了。他們要求架構師既要精通業務，也要精通技術。而現實中，這樣的人鳳毛麟角，屬于可遇而不可求的那一類。所以在這類角色沒有很明確分開的產品研發中，得到的東西要么是需求方面做得不夠好，要么在軟件架構方面不令人滿意。

怎樣最大程度保證需求的合理？我個人認為做一個產品的界面原型是一個好的方法。這一點在做一個基于browser的應用系統時更可行：根據業務需求做出整個的頁面原型，這樣的頁面也許很粗糙，后臺也不需要任何的程序運行，但可以根據這些頁面元素及之間的流程來驗證業務需求是否合理、正確。這種方法應用到項目開發（相對于產品）中，可以和客戶一起驗證需求，經過幾次反復，可以比較準確的理解、把握客戶的真實需求。這樣的工作耗費時間不多，但卻能起到很大的作用。

?

四、架構設計

如果需求做好的話，可以說這個產品基本上能夠得以出籠，但是否稱得上品質優秀，則看架構設計工作做的怎樣了。一個好的產品除了滿足客戶的業務功能外，還要滿足一些非功能性的需求：系統性能、可用性、可管理性、可靠性、可擴展性、安全性等等。

正是因為面對這些眾多問題，在這一過程中，架構師很容易走向極端。最常見的兩種極端情況：（1）過分追求完美。（2）做出來就行，不考慮軟件品質。

作為一個系統架構師，很多人具有完美主義的傾向。他們不斷的考慮系統的性能、可擴展性、安全性，技術的先進性等等。他們最喜歡說的的詞：組件性、通用性、擴展性等等。所以他們不斷的修改架構，不斷的冒出新的思想，采用新的技術。而這一切走向極端就會讓研發陷入不可控制的地步。在我做物流和教育平臺產品的時候，都遇到了這樣的問題。架構師希望產品做得更大，滿足更多的業務需求，同時又希望幾乎每個業務模塊組件化，具有更多的通用性，采用盡可能新的技術。最終造成計劃的一拖再拖，讓公司領導層喪失信心。

第二種情況在一些規模較小的產品研發中也很常見。技術領導人在時間、資金或PM的壓力下基本上放棄了軟件品質的追求。他們只希望在規定的時間內盡快做出一個東西就行。他們基本上不太考慮組件性、擴展性等等。這樣做出來的產品和項目也就差不多了，因為他的通用性、擴充性太差。

可以看出，這兩種情況都可能導致產品的失敗。第一種總是想一口吃成一個胖子，他們忽略了軟件開發的跌代性，軟件總是在不斷的跌代、更新中，螺旋式上升發展的。而第二種則是技術人員的悲哀，他們沒有條件去追求軟件的品質，只能寄希望于產品的下一個版本。事實上，沒有前一個版本良好的框架，新的版本要想做好，幾乎是重新開發。

所以一個優秀的架構師，既要不放棄心中的完美主義的理想，又要對現實做一定程度的妥協，在這種平衡中，領導團隊進行技術開發。事實上，在中國軟件產業的現階段，急功近利的公司太多了，他們不會提供更多的條件、更多的空間讓架構師去實現一個優秀的產品。這是我們所有做軟件技術人員的悲哀，這是所有想走向、或正在架構師崗位上的人員的悲哀。

在軟件產品開發的這一階段，除了以上的情況，還有許多問題同樣會導致產品的失敗。

例如公司對軟件工程的理解和掌握。軟件工程強調使用過程來保證項目的成功，一般都會提出一整套的理論，如一些核心流程、步驟、方法、規則等等，例如RUP,XP。有很多項目經理、架構師和軟件公司的高層都希望去使用這些方法，以保證項目、產品的成功。特別是公司的上層領導，他們只能通過這種方法來保證對項目的控制，所以特別熱衷于實施這些方法。然而事實上呢？。大家都常有這樣的經歷：為了文檔而寫文檔，寫出來的文檔基本上可以扔進垃圾箱，沒有任何作用了。我這樣說，并不認為軟件工程有什么不好，關鍵在于你怎么去使用它。軟件工程是一門實踐性很強的學科，需要我們根據不同的現實情況不斷的調整、實施，而不是照本宣科的一些教條。最怕遇到這種情況：一些領導或項目經理讀了幾本軟件工程的書，自以為找到了靈丹妙藥，就開始在項目中強力實施。比如制訂一些步驟、計劃，在什么什么時間，達到什么什么成果，要寫什么什么樣的文檔等等。在我以前做教育軟件產品中就充滿了這種傾向。了在某為一時間交出架構設計文檔，我們大部分時間不是去考慮、驗證架構，而是為了寫出這份文檔。結果是，到我們要去實現時，發現根本行不通，整個架構存在嚴重的問題，到這個時候再回頭重做設計，代價太大了。個人感覺是，要合理的使用一些軟件工程理論，需要項目經理、架構師有豐富的實踐經驗，能夠根據不同的產品研發情況，制訂自己的一些確實可行的方法。軟件工程是一些通用的理論，從來而且應該是可以靈活裁減的。

四、其他步驟

? 如果說上面的步驟都很好的做到了，那產品應該說基本上成功了。有了一個合理的的架構設計，那么詳細設計和編碼應該不是一個問題，這只需要我們的軟件工程師的努力就可以了。當然測試是很重要的，但基本上不會導致產品的研發失敗。

作者后記：在做過幾個項目，經歷過一些失敗之后，我把自己的一些想法寫下來。這篇文章文字比較亂，基本上想到哪寫到哪。我所碰到的問題，很多做軟件的朋友也時常碰到，在抱怨了太多之后，我決定把它寫下來。在國內做軟件太困難了，如果你對軟件還有一些理想主義的話，那你就太痛苦了。