創(chuàng)業(yè)公司技術(shù)團隊如何組建？技術(shù)團隊管理過程會遇到哪些坑？如何填舊的坑，如何應(yīng)付互相傷害，如何不給自己挖坑？

以下經(jīng)驗不論是對創(chuàng)業(yè)團隊或小公司來說都有參考價值，尤其是對于一些非技術(shù)產(chǎn)品老板下的技術(shù)負責人，所謂早看早得利，誰用誰知道。

要成為創(chuàng)業(yè)公司的技術(shù) Leader 或技術(shù)合伙人，從自己心理上再不能只是一個單純的碼農(nóng)。

許多朋友和我吐槽，這些 CEO 們看見一個認識的程序員、工程師就會曉之以情動之以理說服來公司做 CTO，結(jié)果失敗率非常非常高。

不管是在大公司還是小公司，做產(chǎn)品一定是靠一個團隊，優(yōu)秀的技術(shù)團隊一定不能有個人主義的氛圍。

技術(shù) Leader 要思考的不是某個功能模塊的代碼如何實現(xiàn)，而是優(yōu)先考慮如果打造一支“短小而精悍”的核心技術(shù)團隊、如何搭建高可用的技術(shù)框架、如何高效打造出優(yōu)秀的互聯(lián)網(wǎng)產(chǎn)品。

[[217848]]

組建技術(shù)團隊的正確“姿勢”

如何建立初期技術(shù)團隊？以下的經(jīng)驗或許有參考意義：

***，根據(jù)技術(shù)解決方案和個人做事風格去挑選和掌控團隊

這點很重要，比如曾有一家拿了天使輪的團隊，CEO 是從阿里巴巴出來的“女神”，項目啟動不到半年，原技術(shù) Leader 因為各種原因走了，后來她急著想拉我替補進來。

我只提了一個條件：“阿里巴巴的文化我不懂，如果我進來，我可能需要按照我自己的風格去管理。” 

但是公司的負責人否認了我，說：“CEO 是從阿里巴巴出來的，團隊我們會自己去帶，你只負責寫代碼和解決技術(shù)問題就好了。” 于是我沒有繼續(xù)往下談了。

其實這種事情沒有對錯，這只是我個人的做事風格和原則。

第二，前期的技術(shù)團隊也許談不上管理

但是基本清晰的組織架構(gòu)和簡單的績效考核制度必須到位。

第三，前期的技術(shù)部門***用“彈性工作制”來管理

團隊越小越應(yīng)該實施這樣的制度，因為不拘小節(jié)、沒有時間概念的技術(shù)研發(fā)工作反而效率更高。

第四，發(fā)現(xiàn)“蛀蟲”立即砍掉

我之前帶過一支團隊，所有技術(shù)成員沒日沒夜的開展著開發(fā)工作，大家根本沒有時間考慮福利、節(jié)假日這些事情（當然、這些東西應(yīng)該是由公司主動做就可以了）。

有這么一個人，事情還沒做好就不斷跟我斤斤計較、談各種條件，多上一個小時都覺得自己委屈，工作緊急時候卻偷偷占用公司網(wǎng)絡(luò)資源下載電影，還經(jīng)常發(fā)出消極的言論、做事慢效率低下。

這種人就像一個“蛀蟲”時不時折騰得讓大家都不爽，負能量滿滿，影響他人不說，團隊破壞性極大，于是我立馬讓他工作交接對其勸退。

第五，技術(shù) Leader 要引入或者培養(yǎng)自己的左膀右臂

CEO 要有自己的軍師和大將，CTO 或技術(shù) Leader 也一樣。

第六，團隊成員要有責任心、人品好的，而不是要***秀的、浮躁的

令我感動的一段經(jīng)歷，團隊里有個工程師下班坐車回到一半，就突然給我發(fā)微信說，有個事情沒做好，問我在不在公司，他要坐車回來重新做一下。

他不是團隊技術(shù)***秀的，但他確實是最能吃苦和有責任心的，這是我喜歡的員工類型之一。

第七，技術(shù)團隊一定要有定期的一對一溝通

技術(shù)團隊不論大小，團隊里的直屬上司一定要有定期的溝通制度。

我也是程序員出身，我知道程序員是以“悶騷”的特點著稱。對于長期的低調(diào)、苦逼的 IT 技術(shù)宅男，沒有定期的心理疏導工作，會出現(xiàn)很多尷尬的問題，不信你認真觀察試試，這也是團隊磨合的一個重要工作。

[[217849]]

技術(shù)團隊管理應(yīng)該避免的九大“坑”

那么問題來了，初創(chuàng)技術(shù)團隊需要管理嗎？技術(shù)團隊如何做管理？

老夫掐指一算：當然需要！尤其是技術(shù)團隊，只要大于 3 個人，就必須有管理。這個管理包含：代碼管理、項目管理、團隊管理等角度。

見過太多失敗的案例了，大多數(shù)的技術(shù)團隊出現(xiàn)的效率低、團隊一盤散沙、開發(fā)沒有方向、團隊不穩(wěn)定等問題都是因為缺乏管理或者管理不到位引起的。

如何做好技術(shù)團隊管理？我沒事閑的時候，腦子里總在思考這個問題。將來有一天我成為一家創(chuàng)業(yè)公司的技術(shù)負責人，哪些錯誤應(yīng)該是避免犯的呢？

人從一種狀態(tài)到另一種狀態(tài)的時候，先思考的不應(yīng)該是如何快速去做，而是如何避免犯一些錯誤。

為了避免我太跑題，先設(shè)置一個限定，比方一個創(chuàng)業(yè)團隊近期融了一筆錢，需要快速的搶占市場。

這時需要有一個技術(shù)負責人（已談好全權(quán)負責）來帶領(lǐng)研發(fā)團隊更好的支持業(yè)務(wù)發(fā)展，這個團隊原來的技術(shù)人員沒有超過 5 個人。

善待原有技術(shù)團隊

這個產(chǎn)品能夠成功融資，原有技術(shù)團隊肯定付出了很多。也許他們技術(shù)能力并不突出，也聽不懂你的技術(shù)術(shù)語，還可能沒有做過高負載的網(wǎng)站。

但是他們肯定足夠辛苦，因為一直在默默付出，對待他們要抱著幫助的心態(tài)，不要一上去就提出批評或者質(zhì)疑，不要提擴展性、可維護性這樣很虛的概念。

而要了解目前遇到了什么難題，你能夠坐下來仔細和他們分析，并實實在在幫助解決問題，技術(shù)人員都很單純，你幫助了他們，就會服你，會尊重你。

假如技術(shù)負責人不能幫助他們，那就不要去添亂。比如用行政的命令要求他們遵守代碼規(guī)范，畫架構(gòu)圖，進行代碼審查，不要有高高在上的感覺，你過來是解決問題的，而不是來生產(chǎn)制度的。

就算你看到了技術(shù)團隊有很多問題，也要逐步的去優(yōu)化。因為在現(xiàn)階段，原有團隊是最了解目前的技術(shù)組成，不要試圖全部推翻，也不要用新來的人去替代他們，尊重他們，幫助他們，才是***的方式。

整鍋挖來一個團隊需要慎重

很多公司負責人找技術(shù)負責人的一個標準，就是看這個人的人脈，看他能不能找到很多技術(shù)人員，快速搭建技術(shù)團隊，整鍋拉來一個團隊。

這個思路是沒問題的，公司負責人需要放權(quán)，專業(yè)的事情交給專業(yè)的人去做。

可是假如技術(shù)負責人招的人都是原來的朋友、同事，形成家族式技術(shù)團隊，那么就要警惕了。

首先這個用人成本非常高。招來的人并不完全是因為技術(shù)負責人的個人魅力而來的，他需要平衡是否值得，所以高工資成為必然，當然假如確實是高水平的技術(shù)人才，這也是合理的。

其次以關(guān)系這種方式引進的員工，技術(shù)水平肯定良莠不齊，很多人因為和技術(shù)負責人良好的關(guān)系而進來的，更要命的是技術(shù)負責人引進人只是為了證明他的人脈那就危險了。

所以技術(shù)負責人只要覺得一個人聽話，這個人可能就會被引進，而不是以技術(shù)能力而衡量了。

另外，一般的技術(shù)負責人年齡可能都不小了，而必然原來的同事年齡也不小，他們原來可能是技術(shù)人才，可隨著年齡的提升，他們現(xiàn)在可能是個“技術(shù)管理者”，而失去了編碼能力。

對于創(chuàng)業(yè)團隊來說這是非常不好的事情，創(chuàng)業(yè)團隊其實更需要業(yè)務(wù)開發(fā)人員。

家族式管理的弊端

在特定的時間，家族式管理很有用。技術(shù)人員任何的行為都是建立在幫助技術(shù)負責人的角度，所以干勁會很足。

對于技術(shù)負責人來說就更好了，不用動員，不用講管理技巧，只要建立兄弟之間的關(guān)系就行了，任何事情都能搞定。

假如這些兄弟確實技術(shù)能力很強，那么技術(shù)體系可能會很好；假如技術(shù)能力不強，設(shè)計和開發(fā)出的東西沒有任何的審查，技術(shù)負債就會很多，而技術(shù)負責人本來的職責不就是掌控技術(shù)質(zhì)量嗎？你完全放開，要你有啥用？

家族式團隊很有可能和原有團隊產(chǎn)生摩擦。比如原有團隊感覺受到了排擠，很有可能處處不配合，而新進團隊可能為了有更多的話語權(quán)，會搶班奪權(quán)，所以這兩個團隊就為了私利，不會專注于技術(shù)，內(nèi)耗就會很嚴重。

這種事情就很多，比如某個知名互聯(lián)網(wǎng)公司，新來的技術(shù)負責人帶來了自己的團隊，并且都是級別很高的職位，而老同事感覺這些人啥都不懂，什么也解決不了，而新來的團隊又各種的變革，導致互相利益不平衡，很多老同事就走了。

請先進行技術(shù)方案的設(shè)計

對于一個剛來的技術(shù)負責人來說，有許多工作要做，比如組建團隊、了解產(chǎn)品，但更重要的是設(shè)計靠譜的技術(shù)方案。

首先要了解系統(tǒng)存在的問題、要了解產(chǎn)品未來的走向、要了解技術(shù)團隊的現(xiàn)狀。針對這三點，你需要親自操刀，設(shè)計一個針對目前***的技術(shù)方案。

為什么要親自上呢？因為你是技術(shù)負責人，不了解技術(shù)問題，就無法進行技術(shù)管理。

只有親自設(shè)計了，你才能有針對性的去解決問題，將來系統(tǒng)遇到瓶頸，你就能更好的優(yōu)化或者重新設(shè)計。不要用各種理由不去做這個事情，這在早期很重要。

不要過度追求專業(yè)化

在互聯(lián)網(wǎng)創(chuàng)業(yè)公司，一般追求小而快的概念。但是很多從大公司出來的技術(shù)負責人充滿激情，任何事情都想追求專業(yè)化，這可能會出現(xiàn)很多問題。舉幾個栗子。

沒意義的技術(shù)崗位

比如現(xiàn)在很多產(chǎn)品并沒有多少用戶，可非要搞數(shù)據(jù)挖掘，很多數(shù)據(jù)通過簡單的 Shell 腳本就能解決，可專業(yè)的數(shù)據(jù)挖掘崗位要求并不低，從成本和效益看，并不建議設(shè)置這樣的崗位。

重復(fù)造輪子

重復(fù)相同的開發(fā)工作，應(yīng)該多用開源的解決方案?，F(xiàn)在發(fā)現(xiàn)很多公司喜歡自己實現(xiàn)或?qū)υ熊浖鰯U展，假如沒有特殊原因，應(yīng)該用成熟的解決方案，原因***就是研發(fā)成本，第二就是這個開發(fā)成本會很長，第三就是穩(wěn)定性有待考量。

系統(tǒng)設(shè)計過度

另外，很多創(chuàng)業(yè)公司存在大量的系統(tǒng)過度設(shè)計。即設(shè)計的方案不結(jié)合目前的實際情況，考慮的太復(fù)雜，所以實現(xiàn)的也特別復(fù)雜。

這和造輪子一樣，也存在同樣的浪費，其實過度設(shè)計到還好，就怕錯誤設(shè)計。

比如我原來的公司，覺得 MySQL 性能不好，非要加一層 Memcached 或Redis緩存，***設(shè)計并線上使用發(fā)現(xiàn)后，緩存***率非常低，白白浪費了大量服務(wù)器，損耗了性能，并增加了系統(tǒng)的復(fù)雜性。

根本原因是代碼寫的爛，為了 Redis 而 Redis，復(fù)雜會顯得很牛嘛！所以這個行為非常不值得提倡。

技術(shù)債

不要有開發(fā)語言歧視，比如某些公司搞的前端業(yè)務(wù)層用 PHP，后端數(shù)據(jù)層用 Java，性能沒有想象的那么夸張，這也是細分崗位的一種缺陷。

專業(yè)化的反面就是技術(shù)負債，上面也只是簡單的說下，有很多的***實踐指導，想表明的就是太專業(yè)化是對效率的***打擊（時間、成本等）。

我原來也遇到很多類似的情況，這個傷害分為兩個階段：

***階段就是短期的一錘子傷害，比如說技術(shù)方案上線了，浪費了一些時間和成本，但是這個浪費是固定的，可衡量的。

第二階段就非常難衡量了，為早期的決策還債，比如說原來的技術(shù)方案上線后，后期開發(fā)特別難擴展，維護也非常困難，累計起來是對生產(chǎn)力的極大打擊，成本就非常昂貴。

招人要慎重

招人的關(guān)鍵詞就是數(shù)量和質(zhì)量，沒有合適的寧愿不招。在創(chuàng)業(yè)團隊，項目一個接著一個，很容易造成一個假象，開發(fā)人員不夠，所以就大量的去招人，這是非常不成熟的行為。

尤其是假如這個技術(shù)團隊沒有太強的***開發(fā)實踐，新來的人員可能會很茫然，各有各的開發(fā)習慣和模式，會導致 1+1 < 2 的現(xiàn)象產(chǎn)生。

人一多，分工就要細化，一細化協(xié)作就會產(chǎn)生一定的問題，所以招人要控制數(shù)量。

第二就是重視質(zhì)量，質(zhì)量這個詞每個人都有自己的標準，我核心的觀點就是寧愿使用一個技術(shù)底子扎實的畢業(yè)生，也不愿意使用一個有多年開發(fā)經(jīng)驗但無技術(shù)底蘊的人。

一個沒有技術(shù)體系的開發(fā)人員總有一些瓶頸和不好的習慣，會有很多累。

不了解公司負責人

很多公司負責人找技術(shù)負責人的時候，都是求才若渴，目標就是希望這個人去搞定技術(shù)事宜，可他們在頭腦中一切都是變化的，并沒有一個衡量標準。

對于一個技術(shù)負責人來說，可以天天和他聊，告訴他架構(gòu)的重要性，人員的重要性。

這些確實很重要，但并非必要性，對于公司負責人來說他其實就關(guān)注開發(fā)速度、穩(wěn)定性、產(chǎn)出，他并不關(guān)心深層次的技術(shù)內(nèi)部是如何運轉(zhuǎn)的。

舉個我遇到的情況，原來一個同事去一個公司做負責人，他天天搭基礎(chǔ)，優(yōu)化系統(tǒng)，后來不知道什么原因走了，而產(chǎn)品負責人這么評價他“來這么久一個產(chǎn)品也沒上線”。這個例子對技術(shù)人員應(yīng)該很具有打擊性。

不要有求必應(yīng)

和技術(shù)合作最多的就是產(chǎn)品人員，個人覺得產(chǎn)品人員思維有點發(fā)散，做任何事情都比較著急，天天思考這個功能，那個功能。

一個簡單的數(shù)據(jù)需求就問技術(shù)要不要弄個后臺出來，反正一刻也不會讓你閑著。

對于一個成熟的技術(shù)負責人來說，不能什么都快速答應(yīng)——因為這是對自己的傷害。

***，開發(fā)人員就算多一倍也會不夠，需求會源源不斷的來。

第二，產(chǎn)品人員很多情況會考慮不成熟，假如你完全按照他們說的去設(shè)計，方案會非常復(fù)雜，有的時候邏輯性也會顯得有問題，會讓系統(tǒng)很難有效的持續(xù)運轉(zhuǎn)。

第三，有時候人工完成的時間比開發(fā)一個系統(tǒng)完成的時間少得多。

因此，少開發(fā)一些無意義的腳本或后臺，比如剛開始產(chǎn)品人員覺得這個數(shù)據(jù)很重要，過了幾天就會突然覺得沒用了。

這樣的例子有很多很多，我的意思并不是不去配合產(chǎn)品人員，而是從自己專業(yè)角度出發(fā)，給出合理的意見，當然需要避免激化矛盾。

不要依賴測試

在創(chuàng)業(yè)團隊，由于對開發(fā)時間要求特別高，開發(fā)人員在評估時間的時候，特別喜歡加上測試時間，著等同于拿測試時間完成其開發(fā)時間，這是一種非常不好的行為。

比如說一個項目開發(fā)時間要 5 天，測試時間要 5 天。看上去好像開發(fā)時間只占一半（開發(fā)人員好像很高效），但實際上測試時間里開發(fā)人員肯定還在開發(fā)，他們給測試人員的只是一個半成品。

另外開發(fā)人員知道測試人員會測試出問題、會把關(guān)。所以初期的開發(fā)質(zhì)量肯定不高，這種案例也見過很多。

所以，不要變相的用測試時間彌補開發(fā)時間。有可能的話，開發(fā)人員自己負責測試，當然這個實際操作起來開始有一些困難，有了開始就能夠適應(yīng)。

小結(jié)

每家互聯(lián)網(wǎng)創(chuàng)業(yè)公司都有自己特殊的情況，我要表達的中心思想就是先考慮不犯錯，然后再考慮更好的改進。

尤其在互聯(lián)網(wǎng)創(chuàng)業(yè)早期，追求輕量而不是重量，技術(shù)成本非常昂貴，要效率。