我在兩家創業公司工作過。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 需要具備以下的能力：
說服別人，讓別人接受自己
遇事能夠沉著冷靜處理
強有力的整合統一能力
pa(programming artist) 需要具備以下的能力：
掌握軟體從需求、設計、實現、測試、運維的各個生命週期所需要技術
有黑客的特點：好玩、高智商、探索精神（摘自《黑客與畫家》）
在創業型軟體公司的收穫
我在兩家創業公司工作過。a公司，由3人發展到20人 b公司，由20人發展到60人。這兩家公司都不算成功，因此，要講收穫，更多的是經驗與教訓。就如同教材一樣，反面教材更加有教育意義。我針對創業公司面臨的重要問題，談談我的想法。相對於大公司，小公司的靈活性是核心競爭優勢。小公司的靈活性，是指小公司船小好...
專案型軟體公司將死？
軟體企業最終的競爭在於技術，目前由於各個公司都是同質化競爭，由於大家的生產率是一致的，因此在大家都在 競爭時，低價就只能意味著低質。因此如果某個公司，其能夠用更低的成本製作更高質量的產品，那麼意味著這家公司就有足夠的競爭力去打敗其他的企業，最終占領市場。感覺這種說法確實有點道理，但是在實際情況下，我...
專案型軟體公司將死？
這幾天，一直在看je上的各種文章，確實有好多人的討論挺深入的，也學習了不少。看到o6z說的關於軟體企業的技術核心競爭力的問題，也著實讓我興奮了一會，不過很快又歸於了平靜。因為很多東西看上去容易，但實際做起來卻有很多困難，落實到自己頭上，能不能成功又有了很多的變數。o6z說的，軟體企業最終的競爭在於技...