最近接二連三有做傳統(tǒng)生意、制造業(yè)、貿(mào)易公司的老板來問我同一個問題公司想開發(fā)自己的系統(tǒng)或產(chǎn)品是不是該組建一支軟件開發(fā)團隊這個問題我能感受到背后的糾結(jié)——一邊是數(shù)字化轉(zhuǎn)型的焦慮怕自己不動就被同行甩開一邊是完全看不懂技術(shù)行業(yè)不知道招來的人靠不靠譜、錢花得值不值。這篇文章我就用一個在軟件行業(yè)待了十多年、長期跟不懂技術(shù)的老板打交道的從業(yè)者視角把組建軟件開發(fā)團隊這件事拆開聊。全程說大白話盡量不給老板們上技術(shù)課只講能落地的東西。什么情況下該自建、團隊怎么搭、人怎么招、活怎么管、坑怎么躲這些都會講到。這內(nèi)容適合兩類人看一類是有穩(wěn)定主業(yè)、年營收幾千萬到幾個億、想自建團隊做內(nèi)部系統(tǒng)或?qū)ν猱a(chǎn)品的老板另一類是被老板任命去牽頭搭團隊的準技術(shù)負責人?？赐昴隳軐φ麄€事情有一個完整的認知框架知道每一步該干什么、不該干什么不至于花了大錢還走彎路。1. 先算賬再談自建什么情況下組建軟件團隊才劃算1.1 自建團隊、外包、買現(xiàn)成產(chǎn)品三選一怎么判斷先說結(jié)論不是所有公司都該自建軟件開發(fā)團隊。我見過太多老板在還沒想清楚業(yè)務目標時就拍板要招人結(jié)果團隊建起來了做出來的東西沒人用一年燒掉幾百萬然后反過來怪程序員不行。其實一個公司的軟件需求本質(zhì)上只有三種解法買現(xiàn)成的產(chǎn)品、找外包定制、自建團隊開發(fā)。三者的選擇邏輯并不復雜核心就看三點業(yè)務是否依賴這套系統(tǒng)、需求是否頻繁變化、這套系統(tǒng)是不是公司的核心競爭力。如果這套系統(tǒng)只是標準化的管理工具比如財務軟件、考勤系統(tǒng)、郵件系統(tǒng)那就直接買現(xiàn)成的市面上有成熟方案買了就能用千萬別自己造輪子。這個道理很多老板明白但到了實際操作就會陷入我們業(yè)務特殊需要深度定制的誤區(qū)。這里我勸你先問自己一句你特殊的地方真的能帶來額外收入嗎如果不能就別折騰。如果業(yè)務確實有一些個性化需求但系統(tǒng)本身不是核心競爭壁壘比如企業(yè)官網(wǎng)、內(nèi)部審批流程、簡單的客戶管理系統(tǒng)外包是劃算的選擇。外包公司有現(xiàn)成的組件庫和人力池一次性項目交付速度快成本也相對可控。但外包有它的致命弱點后續(xù)迭代依賴外包公司的檔期。你有新需求提過去對方排期排到兩三個月以后是常事這種失控感會讓很多老板抓狂。自建團隊的適用場景其實很明確這套系統(tǒng)要跟你的業(yè)務深度融合要隨著業(yè)務快速變化數(shù)據(jù)資產(chǎn)必須掌握在自己手里或者你準備把系統(tǒng)做成對外銷售的產(chǎn)品。自建不是省錢方案而是省心加搶速度方案。你想在軟件這個環(huán)節(jié)建立自己的節(jié)奏才需要自建團隊?？剂烤S度買現(xiàn)成產(chǎn)品外包定制自建團隊適合場景標準化管理工具個性化需求但非核心業(yè)務核心業(yè)務深度依賴、快速迭代初始成本低按年訂閱中一次性項目報價高持續(xù)人力加管理成本上線速度最快較快慢需要招人磨合后續(xù)迭代受第三方限制依賴外包檔期完全可控數(shù)據(jù)資產(chǎn)歸屬留在第三方平臺協(xié)商約定完全自有我再給一個更直觀的判斷方法如果你的業(yè)務模式在未來三年里基本不變系統(tǒng)需求也相對固定那就別自建如果連你自己都說不好明年業(yè)務會變成什么樣需求十天半個月就要改一次那自建幾乎是唯一的選擇。最后必須算清楚這筆賬。自建一支5人的開發(fā)團隊按二線城市中等偏上的薪資水平一年人力成本至少在150萬到250萬之間這是把工資、社保公積金、團建、辦公設備、管理成本全部算進去的數(shù)字。如果在一線城市同樣5個人輕松超過300萬。這還只是起步配置想做稍微像樣一點的產(chǎn)品10個人的團隊都很正常。所以自建團隊本質(zhì)是一筆重資產(chǎn)投入必須當成一項有回報預期的投資來看而不是簡單雇幾個干活的。1.2 老板最容易踩的三個認知誤區(qū)誤區(qū)一招到幾個程序員就等于有團隊了。很多老板覺得組團隊就是招人結(jié)果招了三個只會寫代碼、沒有協(xié)作經(jīng)驗的程序員連個帶頭的都沒有。需求來了沒人拆解任務分不下去代碼寫到一半互相看不懂。程序員不是不想干活是沒人告訴他們干什么、怎么做、做到什么標準算完。團隊和幾個程序員之間差一個技術(shù)負責人差一套流程還差一個需求管理機制。這三樣東西不補上招再多人都是一盤散沙。誤區(qū)二外包做得不順心就以為自建能解決一切。我見過一個老板外包做了一年半覺得對方進度拖沓、溝通費勁一怒之下決定自建。結(jié)果自建團隊從招人到磨合又花了將近一年項目整個推倒重來最后算下來比外包多花了兩倍的錢。外包和自建各有各的坑外包的問題往往不是模式本身而是甲方不會管理供應商、需求一改再改、驗收標準含糊。這些問題如果不改自建照樣會踩。誤區(qū)三把研發(fā)當成純成本部門恨不得一分錢掰成兩半花。軟件開發(fā)是有前期投入、后期回報的資產(chǎn)型投入不是流水線上的耗材成本。如果老板對團隊的態(tài)度永遠是你們花錢最多、產(chǎn)出我看不見那么優(yōu)秀的人很快會走留下來的人也不會給你好好干活。這個行業(yè)信息很透明人往高處走不給空間不給信任的團隊留不住人才最后招進來的都是別人篩剩下的。這不是危言聳聽是我見過太多相似結(jié)局之后的真實總結(jié)。2. 搭班子一個可運行的最小軟件團隊該怎么配2.1 最小可用團隊的人員搭配和成本估算確定了要自建之后第二個問題就是團隊怎么配。很多老板一上來就想到我要招十個開發(fā)這是典型的沒有理解軟件開發(fā)的結(jié)構(gòu)。一個能真正跑起來的最小軟件開發(fā)團隊標配通常是5個人左右一個技術(shù)負責人兼任后端主力開發(fā)、一個前端開發(fā)、一個后端開發(fā)、一個測試、一個產(chǎn)品經(jīng)理。運氣好的話前端的活UI也能兼職做但如果你對界面要求高后續(xù)還需要一個設計師。有人可能覺得產(chǎn)品經(jīng)理和測試是多余的開發(fā)寫代碼不就完了嗎這里我要多解釋兩句。產(chǎn)品經(jīng)理負責把你腦子里那個模糊的想法翻譯成技術(shù)人員能看懂的文檔沒有這個角色技術(shù)人員做出來的東西大概率跟你想的不是一回事。測試負責在正式上線前攔住各種低級錯誤沒有測試系統(tǒng)動不動出Bug你的客戶口碑就全毀了。這兩個角色看著不寫代碼但決定了團隊的整體產(chǎn)出質(zhì)量省不掉。如果預算確實緊張最小最小也要4個人技術(shù)負責人加前后端各一名加產(chǎn)品經(jīng)理。測試可以先由技術(shù)負責人兼職等產(chǎn)品上線跑一段時間、出過幾次事故之后再補。但要注意這只是權(quán)宜之計不能長期如此。長期沒有專職測試就是拿用戶當免費測試員代價往往是口碑損失比一個測試的工資貴得多。崗位二線城市年薪參考區(qū)間主要職責技術(shù)負責人50-80萬技術(shù)決策、系統(tǒng)架構(gòu)、核心模塊開發(fā)前端開發(fā)30-45萬用戶界面開發(fā)、交互實現(xiàn)后端開發(fā)30-45萬業(yè)務邏輯、數(shù)據(jù)接口、底層服務產(chǎn)品經(jīng)理25-40萬需求梳理、項目推進、業(yè)務方溝通測試20-30萬質(zhì)量保障、用例設計、缺陷管理二線城市一個5人團隊人工成本加起來就是155到240萬加上社保公積金、招聘成本、辦公管理開銷一年燒掉200萬上下是非常正常的數(shù)字。老板心里要提前有這個數(shù)不要招完人再后悔那才是最被動的局面。2.2 技術(shù)負責人是整個團隊成敗的關(guān)鍵這個位置重要到什么程度給你一個最直白的說法技術(shù)負責人選對了這個團隊就成了60%選錯了后面全白搭。技術(shù)負責人不一定是技術(shù)最強的那個人他必須具備三個核心能力。第一技術(shù)上能服眾哪怕不是全棧最強至少能在關(guān)鍵決策上一錘定音告訴團隊哪個方案能行、哪個方案不行。第二跟老板和業(yè)務方溝通的能力能把老板隨口說的我隨便想想翻譯成可執(zhí)行的任務也能把技術(shù)團隊的困惑翻譯成老板聽得懂的話。第三有責任心和扛事能力項目延期了、系統(tǒng)出故障了他不能躲要能站出來協(xié)調(diào)解決。那么從哪里找這樣一個人最高效的渠道是身邊朋友推薦尤其是那些在軟件行業(yè)做得久、口碑好的朋友。技術(shù)負責人這種崗位靠譜程度比能力還重要市場上簡歷過來說我精通全棧的人太多了真正能扛起一個團隊的人很少。通過行業(yè)內(nèi)熟人介紹至少能過濾掉一半不靠譜的。其次是通過獵頭和招聘平臺。但一定要看他過去實際帶團隊的經(jīng)歷不能只看學歷和公司名氣。大廠出來的人不一定適合你的小團隊很多大廠的人習慣了成熟的平臺和完善的流程到了小公司面對什么都沒有、從零開始的現(xiàn)狀反而會水土不服。我見過一個挺成功的案例一家做物流的老板通過朋友介紹找了一個在知名電商平臺干了六年的后端工程師這人沒帶過很大的團隊但在創(chuàng)業(yè)公司完整經(jīng)歷過從0到1的過程。老板把技術(shù)負責人的位置交給他半年之內(nèi)就把一套出入庫管理系統(tǒng)從無到有做出來了。為什么能成因為這個人懂小團隊的生存法則知道在資源有限的情況下什么先做、什么后做。技術(shù)負責人定了之后其他技術(shù)崗位的招聘可以讓負責人去把關(guān)專業(yè)技能老板主要負責考察軟素質(zhì)——價值觀、穩(wěn)定性、溝通習慣。這個分工模式我后面會詳細講。3. 招對人不懂技術(shù)的老板照樣能面試好程序員3.1 簡歷篩選的四個實操技巧很多老板跟HR說幫我招幾個程序員然后HR推了一堆簡歷過來老板一看全是專業(yè)術(shù)語頭皮發(fā)麻最后只能看學歷、看公司名氣碰運氣。這里我給你幾個不用懂技術(shù)也能篩掉一大半不合適者的方法。第一個技巧看候選人的跳槽頻率。程序員這個行業(yè)正常跳槽周期是兩到三年如果一個人每家公司都只待了不到一年大概率不是公司不行就是他不行。這里說的是大概率不是絕對但作為初篩標準很值得參考。反過來如果一個人在一家公司待了五年以上說明穩(wěn)定性好但也要多問一句過去幾年有沒有持續(xù)學新東西有些人在一家公司待久了就廢了技能停在五年前這種也不能要。第二個技巧看項目經(jīng)歷描述的細節(jié)程度。一個真正參與過項目的人寫出來的經(jīng)歷是有血有肉的會具體說到自己負責哪個模塊、用了什么技術(shù)、解決了什么難題、帶來了什么結(jié)果。如果項目經(jīng)歷寫得很空全是負責系統(tǒng)開發(fā)參與需求分析這種套話說明他要么沒真正做過事要么表達能力很差兩個都不是好選擇。第三個技巧看有沒有主動學習的痕跡?？此袥]有寫技術(shù)博客、參與開源項目、在技術(shù)社區(qū)回答問題。這些不是必須項但如果一個人什么學習痕跡都沒有只靠日常工作那點積累發(fā)展?jié)摿容^有限。軟件開發(fā)這個行業(yè)技術(shù)更新速度極快沒有自主學習能力的人三五年就會掉隊。第四個技巧看離職原因是否含糊。簡歷上寫著尋求更好的發(fā)展個人原因沒關(guān)系面試時一定要追著問具體原因。判斷標準很簡單候選人說為了做更有挑戰(zhàn)的事情、為了更大的平臺這種算正常如果一味指責前公司這里不好那里不好、抱怨前同事都是混蛋這種人的協(xié)作能力通常要打個問號。一個人在你面前怎么評價前東家往往就是他以后在別人面前怎么評價你的方式。3.2 老板該親自問的五類問題簡歷看完了、技術(shù)面試也安排完了到了終面環(huán)節(jié)老板親自出馬。這時候你問的問題不應該是你會用哪個框架這種連你自己都不懂的技術(shù)題而應該問那些能看出一個人本質(zhì)的問題。我整理了五類每一類背后都有明確的考察邏輯。第一類請他說說上一個完整交付的項目。讓他從頭到尾描述從需求怎么來、怎么拆解、怎么分工、做到什么時候上線、中間遇到什么困難、最后怎么解決。你不懂技術(shù)沒關(guān)系你聽的是邏輯性和真實性。一個真正做過事的人講起來會非常流暢、有細節(jié)、有轉(zhuǎn)折沒做過事的人東拼西湊很快會露餡。第二類問他工作上最有成就感的一件事以及最失敗的一件事。成就感那題看他看重什么——是解決了技術(shù)難題是幫業(yè)務方省了時間還是帶新人成長。失敗那題看他的復盤能力——能不能冷靜地講出原因而不是全程怪別人。這兩題的答案組合起來基本能拼出一個人的工作價值觀。第三類問他怎么跟業(yè)務方溝通需求。程序員這個崗位最怕的不是代碼寫不出來而是跟業(yè)務方溝通不暢?？梢詥査绻麡I(yè)務方提了一個你覺得不合理的需求你會怎么處理看他回答里有沒有先問需求背后的原因用簡單方案先驗證給出替代方案這類答案。只會說我照做就行或者我會直接懟回去的都算不上靠譜。第四類問他未來三到五年的規(guī)劃。別只聽嘴上說了什么看他怎么解釋。一個在意技術(shù)成長的人會說希望深入某個領(lǐng)域一個在意生活平衡的人會說希望穩(wěn)定這些都沒問題關(guān)鍵是跟你們公司的狀態(tài)是否匹配。如果公司現(xiàn)階段要敏捷快跑結(jié)果招來一個想朝九晚五混日子的雙方都難受。第五類問他期望薪資和到崗時間。這是最實際的問題很多老板在這里扭扭捏捏不敢談錢結(jié)果后期出現(xiàn)薪資糾紛。大方一點直接問看看預期是否在同一水平線上。薪資談不攏就沒必要硬湊強扭的瓜不甜硬湊進來后續(xù)一定會出問題。3.3 薪資談判的實用策略關(guān)于薪資老板們最容易犯兩個錯誤一個是不懂行情瞎砍價砍到候選人直接走了或者來了以后發(fā)現(xiàn)外面同樣水平的人拿得多得多待不住另一個是只談基本工資不知道怎么設計薪酬結(jié)構(gòu)。薪資策略我建議分三步走。第一步面試之前先定一個薪資帶寬不用精確到具體數(shù)字但心里要有市場行情這個概念。怎么摸行情把技術(shù)負責人給的參考、獵頭報價、招聘平臺上同等崗位的薪資范圍放在一起對一下心里就有數(shù)了。第二步在帶寬之內(nèi)給出一個有競爭力的數(shù)字寧可略高于市場價也不要打七折招人。招聘的隱性成本遠比你想象的高——崗位空著、業(yè)務沒人做、團隊等米下鍋這些加起來非常驚人。第三步設計合理的薪酬結(jié)構(gòu)常規(guī)操作是基本工資加年終獎加福利條件允許可以加項目獎金或期權(quán)。期權(quán)這個事要謹慎不要許空頭支票要給就落到紙面上并且約定明確的兌現(xiàn)條件。還有一個細節(jié)經(jīng)常被忽略程序員的晉升空間。寫代碼這個崗位到了一定年齡如果在職位和薪資上看不到上升通道一定會走。老板組建團隊的時候就應該想清楚這個技術(shù)團隊將來怎么成長。技術(shù)負責人之外要不要設置技術(shù)專家路線、管理路線、項目管理路線哪怕現(xiàn)在人少也要在制度上留出空間這是留住核心人才的關(guān)鍵底牌。4. 管好活從需求到上線的完整流程怎么設計4.1 需求管理先給老板的需求管理上規(guī)矩團隊搭起來了人招齊了真正的考驗才開始。我可以直說90%的軟件開發(fā)項目失敗不是敗在技術(shù)上而是敗在需求管理上。而且這里有一個很扎心的真相最大的需求黑洞往往來自老板自己。老板提需求有個共同特點想一出是一出。看到別人家上了新功能馬上回來跟團隊說我們也做一個而且要求很快上線。今天加一個功能明天改一個界面后天覺得方向不對要推翻重來。每一次改動對開發(fā)團隊來說都是實實在在的工作量一兩次無所謂頻繁變更就會讓團隊疲于奔命進度一拖再拖最后老板反過來怪團隊效率低。這不是老板壞是老板不懂軟件開發(fā)的基本規(guī)律。所以組建團隊時第一件事不是開發(fā)產(chǎn)品而是給老板自己的需求管理立規(guī)矩。規(guī)矩很簡單就三條。第一條所有需求必須書面提不能口頭說了就開工。哪怕吃飯時你說了一句團隊也會記錄下來回到公司確認之后再排期。第二條需求要按優(yōu)先級排每周跟團隊過一遍這個月最重要的三件事是什么明確資源只夠做一到兩件事其他事項進待辦池排隊。第三條接受一個現(xiàn)實提需求很容易開發(fā)需求有成本。你對團隊說這個功能很簡單就像廚師聽客人說就炒個菜很快的——你看著簡單背后的工序只有干活的人知道。尊重這個現(xiàn)實溝通就會順暢很多。需求管理里還有一個容易忽略的環(huán)節(jié)業(yè)務方和技術(shù)團隊的信息對齊。老板腦子里有完整的業(yè)務圖景但技術(shù)人員看不到。所以每次立項的時候老板或產(chǎn)品經(jīng)理應該花時間把業(yè)務背景、目標用戶、這個功能為什么做、期望達到什么效果講給整個開發(fā)團隊聽。別嫌麻煩這個環(huán)節(jié)省了后面返工的成本會讓你后悔。4.2 迭代節(jié)奏與每日協(xié)作的落地方法軟件開發(fā)團隊的管理業(yè)界跑了很多年最后發(fā)現(xiàn)最實用的還是敏捷開發(fā)的思路。但別被敏捷這個聽起來很學術(shù)的詞嚇住落到地上本質(zhì)就三條小步快跑、頻繁交付、及時反饋。首先把大項目拆成小版本。不要指望團隊悶頭開發(fā)三個月然后一次性給你一個大驚喜。正確做法是每兩到三周上一個迭代每個迭代做一小批功能做完就讓真實用戶試用。這樣做有一個非常大的好處即使中間走錯了方向最多損失兩到三周而不是三個月。我常給老板打一個比方做軟件就像裝修房子你要水電工做完一個房間給你看一眼再繼續(xù)而不是等所有房間都裝完了再驗收。到時候想改墻體砸掉的成本會讓你想哭。其次建立一個簡單的節(jié)奏。每天上午花15分鐘開個站會每個人簡短說三件事昨天做了什么、今天打算做什么、有沒有卡住的問題。這個會不是為了匯報是為了讓問題及時暴露。卡住的地方技術(shù)負責人當天就得想辦法解決不能拖。再次每個迭代結(jié)束做一次演示。讓開發(fā)團隊把做好的功能當著老板和業(yè)務方的面演示一遍老板當場提意見。這個環(huán)節(jié)一方面給團隊建立成就感另一方面讓老板對進度建立真實感知。很多老板常年不知道團隊在忙什么就是因為沒有這個固定的演示環(huán)節(jié)。這里要提醒一點迭代節(jié)奏不要貪快。剛組建的團隊前一到兩個月是磨合期先跑三周一個迭代等團隊配合熟練了再縮到兩周。不要一上來就按兩周迭代硬逼搞到最后團隊為了趕工瘋狂加班代碼質(zhì)量下滑后面全是技術(shù)債這筆賬將來還得還。4.3 驗收、測試和上線的邊界最后說一個所有老板都容易犯的錯以為功能做出來了就等于可以上線了。在軟件開發(fā)里開發(fā)完成和交付上線之間隔著一整條專業(yè)分工鏈。一個功能開發(fā)完成后至少要做三件事自測、聯(lián)調(diào)、驗收。自測是開發(fā)自己檢查自己寫的東西有沒有問題聯(lián)調(diào)是跟相關(guān)的模塊一起跑一遍看會不會互相干擾驗收是根據(jù)最初定義的需求一條一條對確認該做的都做了。這三步做完質(zhì)量才基本有保障。很多小團隊為了趕進度會跳過這些環(huán)節(jié)我勸你別省。你要是吃過虧就知道一個看似很小的Bug比如用戶訂單金額小數(shù)點第二位算錯了可能就夠你賠掉一個月的利潤。測試和驗收不是一個可選的步驟是一項必須的投資。上線發(fā)布也有一套講究大版本上線最好選在業(yè)務低峰期比如周一凌晨。萬一出了問題有足夠時間回滾修復不會影響白天正常營業(yè)。另外剛上線的系統(tǒng)一定要盯緊日志和用戶反饋前48小時是出問題的高峰期。我見過太多團隊上線完就開慶功宴去了結(jié)果第二天客戶打電話來投訴系統(tǒng)崩潰等他們從宿醉狀態(tài)清醒過來損失已經(jīng)造成了。5. 避坑實錄我身邊真實發(fā)生過的五類團隊事故5.1 事故一外包轉(zhuǎn)自建的過渡期失控有個做教育培訓的客戶系統(tǒng)一直依賴外包開發(fā)。某天他跟外包方鬧了矛盾決定全部收回來自建。他把正在外包開發(fā)的項目直接砍掉讓新招的團隊從零開始重做。結(jié)果自建團隊用了八個月才做出原系統(tǒng)的基本功能這段時間業(yè)務增長完全停滯還流失了不少客戶。事后復盤正確做法是什么過渡期應該是并行期自建團隊先接手維護現(xiàn)有系統(tǒng)的Bug和小的功能優(yōu)化同時慢慢把核心模塊重構(gòu)移植過來。等自建團隊對業(yè)務和技術(shù)架構(gòu)都熟悉了再徹底切過來。一口吃不成胖子切換技術(shù)供應商和切換團隊一樣都得留緩沖帶。5.2 事故二團隊還沒磨合就急著擴張一家做跨境電商的老板第一年招了6個人產(chǎn)品做得還行老板信心爆棚第二年一口氣把團隊擴到20多人還分成了三個小組。結(jié)果三個小組各自為政底層數(shù)據(jù)規(guī)范都不統(tǒng)一后期花了巨大力氣做數(shù)據(jù)清洗和系統(tǒng)整合。更慘的是因為大量招人管理成本和溝通成本急劇上升產(chǎn)品迭代速度反而比6個人的時候還慢了。軟件開發(fā)有個著名的原則叫康威定律大意是團隊的結(jié)構(gòu)會直接影響產(chǎn)品的架構(gòu)。擴張本身不是問題問題是沒有統(tǒng)一的規(guī)范和負責人就盲目擴張。正確的擴張姿勢是先讓核心團隊跑順沉淀出一套代碼規(guī)范和協(xié)作流程再以小組為單位逐步擴。每擴一組負責人必須明確職責邊界必須清楚。5.3 事故三進了平臺期開始瞎折騰還有一類事故特別普遍產(chǎn)品上線跑了一年多業(yè)務穩(wěn)定了老板開始覺得團隊是不是太閑了于是今天讓開發(fā)做個數(shù)據(jù)分析后臺明天讓規(guī)劃一個完全沒人用的新功能。團隊表面上忙得很實際產(chǎn)出幾乎為零。這種階段正確的做法是把精力用在優(yōu)化現(xiàn)有系統(tǒng)和償還技術(shù)債上。穩(wěn)定期是給系統(tǒng)做減脂增肌的好時候把之前趕工留下的爛代碼收拾干凈把系統(tǒng)性能瓶頸調(diào)一調(diào)把用戶體驗摳一摳。這些工作看起來不熱鬧但對系統(tǒng)的長期健康極其重要。折騰新方向之前先問自己一句這真的是業(yè)務需要還是我單純覺得團隊該找點事干5.4 事故四把技術(shù)負責人當成萬能項目經(jīng)理這個坑很多老板都在踩。技術(shù)負責人本來就背著系統(tǒng)架構(gòu)和核心開發(fā)的擔子老板又把所有項目管理的事都壓給他跟蹤進度、協(xié)調(diào)資源、對接業(yè)務方、甚至處理團隊情緒問題。半年下來技術(shù)負責人每天開不完的會、回不完的消息寫代碼的時間被壓縮到幾乎為零。一個人同時做架構(gòu)師、項目經(jīng)理、代碼主力三份工作再強的人也撐不住最后不是辭職就是身體垮掉。我自己帶團隊的時候就深有體會項目管理和技術(shù)管理完全是兩種能力技術(shù)負責人的價值應該放在技術(shù)判斷和攻關(guān)上。團隊一旦超過五個人就應該安排一個產(chǎn)品經(jīng)理或項目經(jīng)理來專門管進度和溝通讓技術(shù)負責人回歸代碼。這個分工看起來多花了錢實際上是在保護你最重要的人力資產(chǎn)。5.5 事故五績效考核指標設計失誤最后說一個最容易被忽視的雷給程序員定不合理的KPI。有的老板用代碼行數(shù)考核開發(fā)逼得程序員專門寫冗余代碼有的老板用Bug數(shù)量考核結(jié)果測試發(fā)現(xiàn)Bug都不敢報了都在私底下消化還有的老板用上線時間考核團隊為了趕節(jié)點什么質(zhì)量都顧不上。給軟件開發(fā)團隊定考核方向我的經(jīng)驗是看三個維度。考核維度關(guān)鍵關(guān)注點常見反面示例交付質(zhì)量線上故障數(shù)、Bug率、返工率代碼行數(shù)業(yè)務結(jié)果功能上線后是否達到業(yè)務目標上線時間協(xié)作健康度團隊穩(wěn)定性和配合狀態(tài)個人工時排名這三個方向性的維度比任何復雜的量化公式都靠譜。記住一句話你考核什么團隊就會變成什么?？己藱C制設計錯了整個團隊的行為都會跟著扭曲。寫到這里我想起自己剛帶團隊那幾年踩過的坑也是交了不少學費才總結(jié)出這些經(jīng)驗。組建軟件開發(fā)團隊這件事表面上看是在招人、管項目本質(zhì)上是在建立一套讓技術(shù)人員高效工作的環(huán)境和機制。老板不需要變成技術(shù)專家但需要理解技術(shù)工作的規(guī)律尊重技術(shù)人員的專業(yè)性給他們清晰的目標和足夠的空間。給正在猶豫要不要自建團隊的老板一個真心建議先花兩到三個月跟行業(yè)里懂技術(shù)的人深入聊幾次把需求、預算、期望值都想透了再動手。想清楚一件事的道理往往比馬上動手做成一件事重要得多。等你想明白了你的軟件開發(fā)團隊就已經(jīng)成功一半了。