尋找技術合夥人的那些坑

對于非技術出身的創業者，往往有一種幻覺，比如：我們創業就差一個CTO了，再或者，就差一個程式員了。如果你是那個CTO或程式員，你會去嗎？如果一開始就給你很豐厚的報酬呢？我的建議是：最好别去，因為不多久你就會出局。

創始人的不成熟，以及在團隊的強勢地位，會讓一位優秀的技術合夥人也無所适從。

[b]銷售出身的創始人[/b]

這類人的幾個典型特征：

業績導向，工作成果和薪水挂鈎，低底薪；

對技術認知度低，對工作量和技術難度缺乏判斷能力；

對人缺乏信任，更相信博弈和制衡，而不是信任和合作；

做事沒計劃，一天一個點子；

和這類人合作，太考驗情商了。

先說業績導向吧，這個在技術領域基本上行不通。因為從技術到銷售業績有一個很長鍊條，中間有營運、營銷、推廣等環節。技術人員即使很有主人翁意識，也往往愛莫能助，搞不好還會被說成：多管閑事。

現在很多網際網路項目，開始幾年都不掙錢的(走管道模式-積累使用者的項目都是這樣)，更不好和業績、營收挂鈎。

技術人員的考核，我一般傾向于以按時按質按量完成配置設定的任務，而這個任務往往可能細化到一天或一周：随時溝通和跟進，而不需要一個明确的量化名額。

因為創始人是規則的制定者，技術人員隻得去适應，技術人員的不滿積累到一定程度就會撒手不管走人。

對技術認知度低，這個是普遍現象，我一開始舉的那個例子：就差一個CTO，主要指這種人。

比如，電商的訂單管理系統，如果按訂單價格區間查詢很容易，但如果按訂單所屬使用者的等級查詢，技術難度就陡增；再比如，在商品數20萬以下時，商品展示和搜尋很簡單，但如果超過100萬，這塊得全部重寫，原來隻需2天的工作任務，可能變為2個月。

還有像秒殺活動這種促銷，如果不考慮負載，技術難度和工作量隻有考慮負載時的10%都不到。

不懂技術的老闆，可能會這樣和技術溝通，你看這個優惠券功能，電商網站都有了，你們怎麼兩周還沒搞定？對技術人員的缺乏尊重和信任，是很多年輕創業者容易犯的緻命錯誤。

你讓老闆無條件信任你？除非你當雷鋒。

如果一味去滿足老闆的進度要求，加班加點，很可能欠下一推技術債務，過不了一年，系統就維護不動了，沒有人敢對系統動刀，整個系統得全部重來。這時候，老闆可能想換一批人了，開發2.0版。

對于那種一天一個點子的銷售人員，與其說是快速的市場反應能力，不如說是對市場缺乏前瞻性。因為這種拍腦袋導緻的需求變更，技術人員往往也是怨聲載道。在IT行業，聽說離職的幾大原因之一，就是業務需求的反複變更。

我再來批駁下技術人員吧。

[b]技術人員出身[/b]

可以按公司類型劃分：

來自外企的；

來自大型民企的；

來自中小型民企的；

來自國企的；

還可以分，來自網際網路技術公司的，來自傳統行業IT部門的。

先說外企吧。

很多外企都說自己是設在中的研究院、研發中心。就像IBM幾年前在成都雙流機場打了幾年的廣告：智慧的地球，不過是一種營銷手段。其實，他們也就是忽悠下那些畢業生。

外企在中國的開發中心，一般主要是三種：海外外包(客戶是歐美日)、國内外包(做項目)、企業内包(比如IBM内部的OA系統，非公司核心産品)。

如果是海外外包，這種活一般是從詳細設計開始做，也就是說架構設計和概要設計這種有技術含量的别人都做完了。

如果是碰上對日項目，就直接編碼了，包括方法命名别人都寫好了，純粹淪為軟體工廠-代碼勞工。當時，我見到一個日本項目，檔案命名是201.jsp、202.jsp，我頓時石化了。

但你不得不佩服日本人在軟體工程領域的造詣：能夠将工作分解到大學畢業生就可以做，而且項目進度控制到10%以内，目前隻有制造業可以做到啊。

而這些項目經理，每天主要工作職責就是更新Excel進度表，然後郵件送出到客戶方。

你說，要是遇到這些頂着光環的技術人員或項目經理，你還能抵制住誘惑？而且對方還是名校出身哦，因為這些外企一般隻去名校校招。

想想國内的軟體項目外包，甲方告訴你，我要xx功能，你yy周給我做出來，要多少銀子？雙方價格勾兌好後，乙方開工，其間不過問，yy周後甲方驗收，傻眼了吧？

軟體本質上是對業務的一種抽象，如果甲方對業務都不梳理，乙方如何抽象(轉化為軟體模型)，更不要說後面的技術實作了。

很多甲方(創業公司)，就以為軟體外包和做SPA一樣，交錢後躺在那裡，就可以爽歪歪了。如果這樣，基本上失敗機率在90%以上。

一般軟體開發報價有兩種模式：

按軟體開發過程報價：需求文檔＋效果圖＋功能開發量

按功能需求報價：功能開發量＊2

一般來說，前一種要穩妥些：通過分階段傳遞來化解項目風險。

但問題是，沒有看到可運作的程式，甲方一般把需求文檔和效果圖不當回事；

另外，有些乙方，将需求文檔寫得很抽象(找一個普适的需求文檔模版抄)，核心需求都散落在巨幅備援文字中，甲方也很難判斷文檔中需求是自己想要的。

按功能需求報價＝功能量＊2，這也表明了，開發隻占工作量的50%左右，另外50%是業務調研、需求分析、産品設計、測試等。

上面還說到一種：軟體内包，以及外企的國内外包，而做好它，除了有優秀的技術人員，還需要優秀的技術管理人員：精通軟體過程管理。

下面我多啰嗦點軟體過程管理，因為它就是軟體管理的孫子兵法。

CMM5(軟體開發能力成熟度模型)，以及和CMM3比對的RUP軟體過程管理方法論。這種業外人不好了解，你就當成制造業的SOP(标準操作流程)吧。

國内軟體外包巨頭，一般要花錢做這種認證，就像現在的農産品要搞個有機食品認證，才能賣個好價錢。

先不說CMM5規範吧，它的規範文檔大概可以列印成幾本教材。RUP流程是IBM的一套軟體開發SOP，也是恢弘巨制，反正我研究了3年還沒有完全摸透。後來IBM在推Agile RUP，也就是剪裁過的RUP。問題是，有幾個人有能力剪裁。

RUP我還是很喜歡的，對于某些傳統行業的複雜業務，目前我沒有看到更有效的方法學(不要和我談SCRUM，這個不是用來管理需求的)。

軟體工程的成熟度，比起建築業差遠了，每年估計提升不到3%。我從業10年來，沒有感覺到開發一個子產品以前10天現在5天。軟體生産力的瓶頸，在于業務需求的非标準化。

還有一種人，說自己會靈活過程，其實還是在用瀑布開發過程。

是不是用靈活過程，看他發版時是不是追求完美主義：必須等這個功能開發完畢才能上線。很多人有這種類似情結：沒有線上支付、沒有退款功能、沒有線上客服，怎麼算一個電商系統呢？

靈活講究的是疊代開發，但這種人一看就懂，一做就忘。會站立晨會、紙貼todo，那不叫靈活。

靈活過程建立在信任、合作的基礎上，否則晨會就成了批鬥會。

還有，團隊1個進階，2個中級，10個初級，就别強調靈活了，那些新人會逼得吐血。

我談了這麼多的軟體過程管理(注意：不是項目管理)，其實就是想說，一直在用這種重型軟體開發方法學的，或是專業軟體公司那一套方法學，你讓這種技術管理人員來到創業型公司就自廢武功，放棄飛機加大炮，換成小米加步槍的作戰方式，容易嗎？

而且，項目開始時，你一看到那些高大上的文檔，可能還會有這種錯覺：我終于找到技術大牛了，雖然你基本上看不懂。

還有一點不能忽略的，就是大型軟體公司出身的，以前面對的是一批既懂業務又懂技術的需求分析師，他們負責将客戶需求收集整理回來。現在面對的各部門同僚都是電腦盲，而且對業務基本上沒有軟體抽象能力，溝通會非常考驗技術合夥人的智商和情商，如果缺乏同理心，技術人員會在心裡抱怨：這群SB。久而久之，部門冷戰一觸即發。之是以我特别提出來，是因為技術大牛普遍情商都不高。

把技術牛人提升為技術管理者是創始人最容易犯的嚴重錯誤之一。

還有，對軟體公司這種知識型員工，如果用傳統行業普遍采用的泰勒管理方法(工業管理)，如嚴格的考勤、請假制度，會嚴重挫傷技術人員的工作熱情和創造性，要知道很多技術大牛就是夜貓子。如果創始人不了解技術型公司文化，很容易和技術合夥人産生溝通隔閡。

還有一種人，比較受創業公司歡迎，就是BAT出身的。

聽說前兩年，隻要是BAT的，投資人就會追着問，我先給你300萬，你出來創業吧。大家當個笑話就行了。

現在BAT的技術人員都是多少萬了，随便一個産品線就是幾百人，除了幾個總監、進階經理、技術經理，大多數人都是螺絲釘，對某塊可能确實鑽得很深，但技術廣度不夠。

這些技術大牛習慣于技術實作思維(執行者)，而不是解決方案思維(管理者)。如果不搞出點有技術含量的，或是用别人現成的雲服務，那是一件多麼沒成就感的事情。

我前段時間看到一個獵聘上成都地區履歷，裡面一位25k的CTO，上個創業項目是社群O2O，其中有一個功能是小區交友，在談到技術可行性時寫道(原話)：論證移動即時通訊、文字、圖檔、語音、視訊方案；論證LVS在項目中的作用，确定伺服器數量和成本。

要是我們Boss遇到這種技術負責人，估計要哭了。幸好别人隻是論證了，而不是開發了。反正這些功能，我用10萬就可以搞定(有對應的SAAS和IAAS雲服務)。

我估計這就是BAT那種高端人才：做過大型高負載、高可用、海量使用者的即時通訊解決方案。

小型作坊式的民企，我就不吐槽了。這類企業不乏技術大拿，但都是草莽英雄。如果還在大公司呆過，那就完美了：能屈能伸。

國企我就不談了，技術人員受國企官僚影響應該不算嚴重。但有這種習慣：啥屁點需求都要把營運、市場、客服部門拉在一起，看起來是群策群力，實則推卸責任。

其實有一種破局方法：做了再說，錯了再改；在關鍵需求上主動征求相關部門建議，注意是當面，不是郵件＋CC。

大家知道，國企生存法則是，不求無功但求無過，說白了還是怕有人整你。

我上面說的似乎有些專業性，再談幾個比較通俗易懂的坑。

[b]獵頭推薦[/b]

獵頭推薦，對于一些成熟企業可能是最好的選擇。如果是給創業型企業推薦CTO，小心他會把你帶到坑裡。

獵頭能夠做的，就是推薦一批候選人，能否從中找到真正适合的那一位，前提是創業者對CTO的合理定位，然後才是比對識别。就像知名企業的HR，能做的隻是搜集履歷，還得需要面試官來甄别。

如果一個創業者在早期，也讓獵頭找一位高大上的CTO，可能會讓公司死的更快：成本超支，進度超期。

做三年後1000萬使用者的規劃，但公司第一年10萬使用者、能否存活還是一個問題。

我暫時還不談找到一位自認為适合的CTO後，所可能出現的問題：

産品開發期，CTO的技術視野和管理能力有限，進而沒法在有限的資金、人力、時間下達成實作産品目标；

業務營運期，技術處于維持狀态，因為前期對技術不合理的定位導緻股權比例授予不當，一直尋思怎麼讓CTO出局；

很多創始人過了很久才想明白，自己公司原來不是技術驅動的；

同時，因為業務穩定，原來的技術團隊成本過高，想開始對技術部動手，而缺乏團隊支撐和技術挑戰的CTO，職業發展就到盡頭了。

[b]技術合夥人的經濟狀況[/b]

技術做得好的，大多數都來自農村，家境貧寒。而且，因為自己的圈子和社會階層，找的對象家境也不會好到哪裡去。工作5年後一般到了買房的年齡，存款買房或月供都是實實在在的壓力。

而創業者這種勵志男，一般經濟狀況也好不到哪裡。王健林做電商時是說過自己在創業嗎？。創業者給的也就是一個空頭支票－股權，這個套現的幾率大概5%都不到，技術合夥人平時也就拿着1/3到1/2的薪水。如果項目半年一年都看不到希望，就要開始考驗技術合夥人的人性了。

再說，别人挪個地方，可能薪水翻三倍，又穩定又有身份，馬上可以解決現在的燃眉之急。另外，你怎麼知道别人當職業經理人就一定不能獲得股權或期權呢？

很多技術合夥人，在看不到項目前景或經濟壓力過大，都有過退卻的打算。

是以，找技術合夥人，如果主要目标是擁有優秀技術資源，而不是降低成本，我建議錢給夠，别讓他分心。

如果資金充裕，而合夥人也樂意不要股份，就給高工資、當雇員好了。

[b]把技術合夥人當産品經理用[/b]

從軟體開發過程角度，業務調研、需求分析、原型設計，以及其傳遞件概要設計和原型文檔，都是産品經理應該幹的活。技術人員拿到這些傳遞件開始開發功能。而完成這些傳遞件，大概要占去項目工時30%以上。

應該有80%以上的技術合夥人不具備産品設計能力，這不是問題，問題是沒有意識到自己的能力短闆，導緻想不到或不願意去招一位産品經理。

我非常不建議CEO去找一位和技術合夥人平級的産品總監，溝通和協作會是一個大問題。另外，因為産品和技術很難合理分工，産品決策權之争會導緻嚴重内耗。比如，UI設計師是屬于産品部還是技術部？還有，大資料分析師呢？

如果創始人是産品出身，産品定義後，可以暫時不找技術合夥人，找個程式員幹活就行了。

[b]技術合夥人的能力瓶頸[/b]

并不是所有技術人員都能跟上公司的成長，在公司發展的不同階段，對技術合夥人的能力要求不同。

在初創階段，技術合夥人是個會寫代碼的就夠了。随着使用者的快速增長，對其軟體架構設計能力開始有要求；

随着公司業務的壯大，對其技術前瞻性，以及中型技術團隊管理能力有要求，這時候姑且稱為技術總監吧；

當公司發展到需要一位真正的技術副總裁時，需要對行業格局有前瞻性，比如在什麼時間點投入怎樣的資源強化哪塊技術，以及優秀的商業/技術平衡能力，可能原來的CTO/CIO角色也無法勝任；

當然，每個階段，技術合夥人可以去物色比自己更優秀的技術人員，但管理工作還是無法找人替代的，難道指望他讓賢？

在引入技術合夥人時，創始人就應該意識到可能會有這種問題，并制定雙赢的技術退出機制。否則出現那種CTO走後，代碼被删、資料庫被銷毀、伺服器被格式化，那就悲劇了。

如果對技術合夥人能力沒有把握，并且在退出機制上比較顧慮，找一個臨時技術團隊-提供技術孵化服務的公司，可能更靠譜。

在釋出産品初版，并且引入資本後，你有足夠的籌碼吸引到優秀的技術合夥人。

當公司還是一個屌絲時，不要期望引來白富美；當你成長為參天大樹時，鳳凰自飛來。

轉載請注明作者：

陳志武 [url]http://weibo.com/zwchen[/url]

個人微信号：zhiwuchen