在創業型軟體公司的收獲

我在兩家創業公司工作過。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. 有黑客的特點：好玩、高智商、探索精神（摘自《黑客與畫家》）

轉載于:https://www.cnblogs.com/1si2/p/startup.html