在創業型軟體公司的收穫

2021-06-19 08:53:36 字數 3795 閱讀 6437

我在兩家創業公司工作過。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說的,軟體企業最終的競爭在於技...