我在中關(guān)村的小巷子里開了一家茶館,但生意甚是冷清。每天太陽一下山我都會關(guān)店回家,偏巧要關(guān)張時進來了兩個儒雅的中年人。我給兩人泡了一壺茶,順耳就聽他們聊起了開發(fā)管理,聽他們說的倒也有理,就記在了自己的小本本兒上。
這兩個茶客,一個叫大志,一個叫李錚。大志是個十年開發(fā)經(jīng)驗的老工程師,現(xiàn)在管理一個50人的開發(fā)團隊。李錚也是類似的工作經(jīng)歷,但兩年不見,他已經(jīng)是某個知名公司的CTO了。
兩人似乎幾年沒見,但男人的交情跟見不見面關(guān)系不大。雙方通報了一下自己的現(xiàn)狀,李錚恭喜大志有了個兒子,大志祝賀李錚步步高升。
本來我聽著這些俗套想趕他們離開好休業(yè)走人,但大志接下來的抱怨讓我又有了興趣。
大志說帶50人的開發(fā)團隊好累,自己一直在努力但總感覺有缺憾。李錚自然要問,現(xiàn)在帶團隊累在哪里。大志說來自產(chǎn)品部門的需求多的堆積如山,而且做出來的效果和產(chǎn)品需求相差甚遠,部門內(nèi)部也不好管理,每個員工都很尊重自己,但干活的速度忽快忽慢,質(zhì)量也參差不齊。
李錚又讓泡了一壺碧螺春,品著香茗開始和老朋友探討問題了。
“首先說,活干不完是沒搞定需求方,活干不好是沒搞好內(nèi)部”,李錚開宗明義的列出大綱,“接下來的事情很復雜,讓我們來畫一個流程簡圖。”

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