在創業型軟體公司的收穫

　　我在兩家創業公司工作過。A公司，由3人發展到20人；B公司，由20人發展到60人。這兩家公司都不算成功，因此，要講收穫，更多的是經驗與教訓。就如同教材一樣，反面教材更加有教育意義。我針對創業公司面臨的重要問題，談談我的想法。

　靈活性

　　相對於大公司，小公司的靈活性是核心競爭優勢。小公司的靈活性，是指小公司船小好調頭，能夠快速地響應使用者。我在B公司時，公司剛好處於創業擴張期（20→60人）。公司也就是在這個時候失去它的核心競爭優勢的。

　　初到B公司，公司的情況是：已經做出了產品，有一些鐵桿使用者，有投資者表示願意入股，希望在兩三年能夠上市。上市，則要求公司在人數上，管理上發生一些改變。我們公司實施瞭如下舉措：

　　一、將技術部細分為各個小組。如Android組、iOS組、Web組、通訊組、架構組等。為了讓公司的整體技術實力提升，公司花重金為每個組都招來工作經驗豐富的人帶隊。在之前，兩三個人通過簡單的溝通就可以完成包含 Android, iOS, Web 前端以及後臺服務的整個軟體。現在，要完成這樣的軟體，需要各個組的組長相互討論，得到一個相互妥協的結果。

　　得到妥協的結果存在三個問題：（一）花費的時間長；（二）各個開發組長更多會採取各為其組的策略，而不站在全域性考慮問題。各個組長所花費的力氣不是共同的產品目標上，而是各組的區域性利益上；（三）因為結果由多個人共同決定，這樣會導致沒有承擔責任的人，大家會相互推責任。

　　三個問題直接的結果就是，公司處於船大難調頭的局面。這個時候更需要的是一個能夠站在全域性進行快速決斷的人，並且這個決斷的人能夠說服各個小組接受已經決定的方案。因為此時的公司還是一個小公司，還需要保持靈活性，保持快速反應能力。

　　二、成立專案部和產品部。也許是為了讓公司看起來更加有規模，公司需要新招一些員工，並給這些員工安插一些事情。專案部與產品部就招了很多員工，用來計劃和管理開發部的工作流程。新招來的員工有兩個問題：（一）經驗不足，很多是剛畢業沒多久；（二）缺少技術背景，無法管理技術研發。與此同時，各開發小組組長都是工作經驗豐富的人，本身就具備一定的管理能力。當被其它部門的人管理的時候，會存在不配合的情況。

　　比如，專案部要管控進度，開發組會盡可能多要時間，專案部無法評估時間的合理性。小組與小組之間推責任的時候，專案部也無法決斷應該由誰來擔當起相應的責任。產品部做出來的產品設計，往往不考慮開發實現的代價，結果導致開發的時候，花大量的時候來滿足產品的非核心功能。這些情況使得專案部與產品部不得不間接地管理。

　　所謂間接的管理，就是，專案部招集所有的開發組成員給自己評估時間，然後與開發組在時間上進行討價還價。比如，Web組評估時間需要1個月，專案部就會說，1個月太長了，我們半個月就要提交給客戶演示……產品部則通過開發組（而不是使用者）來找產品設計的缺陷。比如，Android組發現按照產品的設計實現程式碼會與Web端不一致，這反過來促使產品部重新考慮如何保持產品的一致性。

　　間接管理使得整個公司在內部不斷地消耗人力資源。一個把產品做出來的部門不僅僅要把產品做出來，還要應付專案部、產品部的管理。這樣的組織形式很難適應快速變化。

　　在公司度過創業初期，準備擴大規模的時候（20→100人），往往重視的是單純地擴大規模，而忽視了繼續保持創業初期的優勢——靈活性。使得響應使用者的時間拉長，使用者的增長速度減緩。一個企業的價值高與不高取決於使用者，而不是公司的管理水平和技術水平。只有快速地響應使用者，才能不斷地提升公司的價值。

　確實存在的使用者

　　我在A公司的時候，公司只有7人。兩位創業老大和5個剛畢業的學生。我就是學生中的一個。當時老大剛從大公司出來，有一定的業務關係，可以容易地拿到客戶訂單。我們初期就是針對一個客戶做專案，做了兩年。在這兩年內，公司還是有些營利的。這正是因為有確實存在的使用者。

　　公司為了發展，轉做了一個網際網路產品。做產品的時候，公司往往容易忽略實際使用者，更多的是自己去想像出一些使用者，然後按照想像的使用者需求去設計產品。我們公司就是這麼做的，結果產品的實際使用者量比較少，並且難以增長。這使得我所在的A公司陷入被動的位置。

　　在公司創業初期（2→20人），一定要做有確實存在的使用者使用的產品。產品雖不完美，但如果確實能夠解決使用者的問題，使用者也會有比較大的容忍度。並且這個時候的使用者都是專業級的使用者，所提出的建議對完善產品有著巨大意義。在產品完善之後，這些使用者還能夠通過口碑將產品推廣出去。因此，有著確實存在的使用者是創業使用者成功的必要條件。

　定義產品版本

　　對於做一個產品，我建議的版本管理如下：

版本號	版本名稱	版本描述
v0.1	開發版	針對於鐵桿專業使用者，解決他們的實際問題，並且根據使用者的建議不斷對產品進行完善
v1.0	正式版	能夠系統地解決所在行業的問題，程式碼可能不容易維護，效率可能不高
v2.0	升級正式版	針對第一版程式碼問題進行徹底重寫，解決維護性及效率不高等問題
vx.0	後續版本	這個時候公司已經運作起來，後續版本根據公司的運營進行調整

　　對於創業初期到擴張期，所需要關注的主要就是前三個版本。

　　開發版(v0.1)。可以快速出來一個可用的產品，能夠確實解決某個領域的使用者的實際問題。這裡強調一點，如果出來的版本過早，導致並不能解決使用者的核心問題，會讓使用者失去信心。但又要防止想開發出來一個完美無缺的系統的行為。簡單來講，就是開發出來一個具有核心功能的產品，讓使用者在使用的過程中對產品完善。在完善的過程中，可以進一步推出 v0.2、v0.3 等版本。

　　正式版(v1.0)。這個版本出來的時候，使用者已經能夠系統地解決所在領域的問題了。比如，一個銷售系統，核心功能是進銷存功能，使用者在使用的過程中會產生如：報表生成，工資管理，人員管理等功能。這些功能在 v0.x 中進行不斷地完善。到 v1.0 時，使用者已經可以使用這個軟體解決整個銷售環節的問題了。

　　升級正式版(v2.0)。v1.0 是通過程式碼的修修補補不斷地積累而成的。程式碼不容易維護，在初期也無從知曉效能的瓶頸會出現在什麼地方。在使用者在實際生產中使用 v1.0 的時候，效能問題就會出現。這就是升級正式版要解決的問題：一、重新設計整個軟體，讓程式碼易於維護；二、解決 v1.0 出現的效能等問題。

　招的人越多越好嗎？

　　創業公司要儘可能降低運營成本。在公司選址，人員招聘，費用支出方面，都可以想辦法節約。對於軟體創業公司，最大的支出項就是人力成本。公司支出了高昂的人力成本，是否能夠達到預期的效果，這就是我接下來要說明的問題。

　　軟體行業有一本20年前的著作——《人月神話》，裡面所講的內容到現在還非常適用。書中提到軟體開發的核心：保持概念的統一性。開發人員多了，為了保持概念的統一性，可能需要花費更多的時候去交流，進而造成時間上的浪費。即， 第一、人多並不能使得開發速度變快 。同時，因為交流當中會產生歧義的理解，會造成概念不統一。即， 第二、人多會更加有可能在軟體中引入BUG 。

　　所謂保持概念的統一性，就是指，一個軟體的各個部分和諧地統一在一個軟體當中。軟體的各個模組相互配合，完成軟體的整體功能。打破概念的統一的情況是，開發人員只看到區域性，並不理解全域性。做好區域性的同時給其它區域性引入問題（引入BUG）。這需要各個區域性的開發人員一起解決衝突，這就會產生交流的時間浪費。

　　因此，一位月工資 1W 的程式設計師的工作效率並不會比總工資 1W 的三位程式設計師低。特別是在創業性的公司，程式設計師是為自己而工作的時候，會更加有效率。

　　當然，並非人越少越好。一個創業公司，主要的問題是：一、將產品做出來；二、將產品賣出去。人的多少依賴於這兩點。要招的人要麼是能夠將產品做出來的人，要麼是能夠將產品賣出去的人。

　　招人之後，是以合作的方式，還是其它的方式來發揮人的積極性，也是需要考慮的。讓一個人有積極性容易，讓十個人都有積極性非常難。

　軟體創業對人的要求

　　一個軟體創業公司至少需要兩個人，一個負責將產品推出去(CEO)，一個負責將產品做出來(PA)。如果 CEO 對技術有所瞭解的話，會更加有優勢。

　　CEO 需要具備以下的能力：

1. 說服別人，讓別人接受自己
2. 遇事能夠沉著冷靜處理
3. 強有力的整合統一能力

　　PA(Programming Artist) 需要具備以下的能力：

1. 掌握軟體從需求、設計、實現、測試、運維的各個生命週期所需要技術
2. 有黑客的特點：好玩、高智商、探索精神（摘自《黑客與畫家》）