我在中關村的小巷子里開了一家茶館，但生意甚是冷清。每天太陽一下山我都會關店回家，偏巧要關張時進來了兩個儒雅的中年人。我給兩人泡了一壺茶，順耳就聽他們聊起了開發管理，聽他們說的倒也有理，就記在了自己的小本本兒上。
這兩個茶客，一個叫大志，一個叫李錚。大志是個十年開發經驗的老工程師，現在管理一個50人的開發團隊。李錚也是類似的工作經歷，但兩年不見，他已經是某個知名公司的CTO了。
兩人似乎幾年沒見，但男人的交情跟見不見面關系不大。雙方通報了一下自己的現狀，李錚恭喜大志有了個兒子，大志祝賀李錚步步高升。
本來我聽著這些俗套想趕他們離開好休業走人，但大志接下來的抱怨讓我又有了興趣。
大志說帶50人的開發團隊好累，自己一直在努力但總感覺有缺憾。李錚自然要問，現在帶團隊累在哪里。大志說來自產品部門的需求多的堆積如山，而且做出來的效果和產品需求相差甚遠，部門內部也不好管理，每個員工都很尊重自己，但干活的速度忽快忽慢，質量也參差不齊。
李錚又讓泡了一壺碧螺春，品著香茗開始和老朋友探討問題了。
“首先說，活干不完是沒搞定需求方，活干不好是沒搞好內部”，李錚開宗明義的列出大綱，“接下來的事情很復雜，讓我們來畫一個流程簡圖。”
首先，我們來看看需求確認。
大志不是那種強硬的開發經理，于是他的問題就是對產品部門的需求有求必應，好似一個活菩薩了。但大志畢竟不是千手觀音，當他手頭有一千個需求的時候，他就抓不過來了。所以開發總監第一個要做的是確認產品需求是否合理，合理性包括方案自身的可行性，以及技術團隊有沒有能力執行這個計劃。
先說從可行性上拒絕需求，這個時候我們的角色不是一個開發者，而一個冷靜的旁觀者。如果沒有用戶會用這種產品，或者這個產品是一個災難性設計，那我們應該請產品總監或者公司高管把這個創意直接斃掉。
再就是從本部門的角度拒絕需求。你是開發經理，你最了解本團隊能勝任什么工作。如果公司的需求過于苛刻，讓我們在資源/規劃上無法完成工作，那我們也必須將需求頂回去。
比如說你帶領一個通訊開發團隊，某天有個客戶有需求要求在語音通話過程中混入電子提示音，比如說“您的電話已經撥打了20分鐘，請注意休息”。在產品和銷售看來，你可以把電話想接通就接通，想掛斷就掛斷，想監聽就監聽，想降噪就降噪，這應該不是難事吧。
但你自己知道，接通掛斷都是事件性操作，監聽是單向復制語音內容，降噪已經有很成熟的技術方案。偏偏這個插入語音提示的需求，看起來很簡單，卻會涉及事件觸發、雙方通話變三方通話再切回雙方通話、錄音合成時去除電子提示音等多個復雜而且生僻的操作。
最后我們拒掉這個需求的理由是技術實現復雜、沒足夠的人手、會改變現有的穩定結構、市場需求暫不強烈，然后專心致志的去完成那些更迫切的需求了。
第二，我們來看看溝通環節
李錚又提到，就算合理的、在處理中的需求，也經常因為雙方溝通不到位而發生南轅北轍的情況。產品人員經常和開發人員說的一句話就是“這不是我想要的”，這話并不是刁難人，我們應該想辦法解決這個溝通問題。
首先，我們要讓需求提出有一個合理和可靠的流程。如果一個產品經理QQ上一個留言就可以直接調動一個開發小組埋頭干活，或者某個開發小組自己就能代表開發部門推掉一個產品需求，那這個公司的管理就太亂了。我們應該讓產品部門提交需求時堅持走一套審核流程，保證產品總監、公司高層（可選）、開發總監都審核過才能進行開發；而這個開發需求經過開發總監審核和分配工作以后開發人員就必須能按時保質量的完成。
流程上正確了，剩下的就算溝通問題了。首先產品經理們提的需求要先自己想的清楚寫的明白，就是審核需求時能跟公司寫清楚這個產品的目的和特點，實施需求的時候能盡量詳細的寫清楚自己要實現的每個小細節。通篇必須用寫作來完成，因為下筆之時人能三思，而脫口而出是不會思考且容易淡忘的。
產品人員寫個百萬字的說明文檔，然后開發照著文檔做就行了？開玩笑，新華字典上所有字都是對的，你背過字典就算學會中文了？產品寫的說明文檔是對自己思路的文字呈現，但他寫的東西并不能保證別人能不誤解。最常見的舉例就算“舟已行二日即到”這個電報了。我們甚至可以說，產品的設計說明我們讀的時候必然會有誤解！
要避免單項溝通的信息丟失，我們就做信息校驗吧。在正式開發之前，開發人員和產品人員要反復開兩次碰頭會，既要做開發工期規劃，也要讓產品有時間精修產品計劃。最重要的就是雙方要相互向對方說明自己聽到了什么，開發人員要把產品的需求復述給產品人員去聽，雙方肯定能發現彼此認知的分歧。
這樣的溝通可能要往返三五次，雖然會消耗一兩周的時間，但開發能徹底弄清除了產品的需求，產品也認可了開發人員的溝通習慣和職業態度，這樣可以節省下好幾周給產品修復bug的時間。
大志連聲收佩服，原先自己總是想節省時間盡快搞定產品需求，結果每次不是開發方向錯了耽擱了工期，就是一周趕工做項目，倆月不停修漏洞。
第三，實施過程中的內部管理
接下來李錚又說起了部門內部管理。李錚認為研發分為三種員工：開發組長、技術牛人和普通開發人員，三類人員的使用方法完全不同。
| 員工類型 | 技術水平 | 責任心 | 執行力 | 溝通能力 | 管理難度 | 支持他人能力 | 對工作要求 | 代表團隊負責 |
| 普通開發 | 差 | 待定 | 高 | 未知 | 態度好但能力差 | 無 | 學習機會/團隊氛圍 | 無需求 |
| 技術牛人 | 高 | 中 | 中 | 未知 | 能力好但有性格 | 中等 | 尊嚴/待遇/個人價值 | 無需求 |
| 開發組長 | 中 | 高 | 中 | 高 | 既是管理也是被管理者 | 高 | 升遷機會 | 必須 |
現在最大的問題是這些開發組長沒當小隊長的覺悟，卻更愿意當排頭兵，經常親自上陣寫大量的代碼，結果把普通開發甚至是技術牛人都晾起來了。最后牛人覺得自己不被重視，新員工覺得沒什么提升，他自己也在繁雜的開發工作和小隊內部管理上累的焦頭爛額。我們要引導這些技術帶頭人將大部分工作量交出去，重點做小團隊的負責人。
有了工作分派，我們還要有制度來督促和獎懲員工，監督員工很容易存在公平性疑慮，我們都喜歡正向激勵員工但經常苦于權限不夠，懲罰員工則大多抹不開面子。
李錚的建議是做一個巨大的白板，上面寫上每個員工要在幾月幾日完成什么工作，能完成就算合格，完不成工作也是任何人都看到的。這個監督機制是公開透明的，是該獎勵還是懲罰是顯而易見的。
接 下來要獎勵員工，李錚和大志都申請到了季度獎金，但大志手下鮮有拿不到全額獎金的職工，個別職工拿不到獎金立刻就會認為自己受到了歧視；而李錚的團隊只有 七成的人能拿到季度獎，還只有少數幾個人是全額獎金，整個團隊反而沒有抱怨獎金的多少。除了季度獎之外，培訓、職位升遷、正式表彰、組織業余活動都能很有 效的激勵員工。
做 管理的可以寬容但不可以和稀泥，盲目的一團和氣并不會讓懈怠的員工心存感激，反而會讓積極的員工心懷不滿。每個公司可以制定不同的管理制度，但記住有時候 懲罰壞員工是為了給好員工一個交代。無論是獎懲都要切記不能做濫好人，獎懲力度太輕會讓大家看輕獎懲制度，人人有獎或法不責眾也會讓制度變成笑話。
第四，不要忽視運維
說到這里大志恍然大悟，激動的要以茶代酒敬李錚三杯，李錚卻沒著急，他說“我還沒說完哪，你們公司的運維人員現在怎么樣？”
大志對運維很滿意，他說：“我們現在的運維人員就五個人，歸我統一管理，有故障總能及時處理，對開發工作也很配合，基本沒有提過什么需求……”
“沒提過什么需求，那你們的運維也做不了什么事情吧。”李錚搶過話頭，“運維太弱勢的公司是沒有多少運維能力的。”
大志想了想也對，貌似現在的運維只能檢查監控、處理硬件和網絡故障，真要是應用服務器有什么問題還要靠開發人員提供解決方案。
李 錚又談起了運維和開發的關系，運維人員要對平臺穩定性負責，開發人員的每次變更程序都會影響平臺穩定性。如果運維太過弱勢沒有話語權，那就像一個膽怯的衛 兵不敢查訪客證件一樣，根本無法勝任工作。因開發的程序變動導致平臺宕機，因程序生僻導致無法監控或很難恢復，因新手程序員的不規范操作導致意外……這些平臺穩定性事件一旦出現，運維都可以把責任推給研發，公司也可能會原諒運維和開發。
但是，你是一個管理人員，必須想到在公司看來業務已經中斷了。要讓運維把工作做好，只有讓他們變得強勢，這樣他們才能擔當起自己的責任來；在開發陰影下的運維人員只能做監控值班人員，無法為自己的工作負責。
兩個人又聊了一會風月瑣事，再也沒提和部門管理的事情。等到他們離開茶館以后，我就把他們說的話都記下來了，原來帶好開發團隊是這么簡單，明天我就把茶館關了，我也去應聘開發總監去。