一年前，我還在新浪時，寫了一篇文章叫做《關于“產品驅動”和“技術驅動”》。我在雅虎、淘寶和新浪都待過，這些公司都是產品驅動型的公司，我很熟悉，而關于技術驅動，我只聽之前的一位同事談過，他去過美國google參觀，了解過那邊的文化，我是從他那兒聽說的“技術驅動”。

那時的我，特別信奉技術驅動的工程師文化，技術驅動除了公司老板要擔相當的風險之外，基本沒什么壞處，是一種非常好的IT公司文化，懂得尊重工程師，工程師的忠誠度和滿意度一定非常高，人員流失少，而且能技術創新出很多精彩的產品出來。那時我很憧憬技術驅動型的公司，覺得那一定是工程師的天堂。我在新浪的級別還挺高的，領導們很器重我，給了我不少機會，帶重要的產品團隊、內部培訓講師、校園網絡學院講師等等，還在一年后給我漲了50%的薪水?？墒羌幢闳绱耍疫€是離開了新浪，去了國內某家技術驅動型的公司S，因為我對技術驅動型的公司實在是太向往了。想來，對新浪至今仍有愧疚，希望以后能有機會以別的方式來回報新浪。

一年多以后的現在，我在S公司感受了一整年的技術驅動文化，作為一個扮演多重角色的員工(產品經理、項目經理、架構師、工程師、策劃)，我對技術驅動的利弊有了較深的感悟，想來細說一下“技術驅動”文化中的各種問題。

S公司的確是家技術驅動型的公司，公司管理非常扁平，從一線工程師，到項目經理，再到公司高層G，共起來只有三層。G特別忙碌，所有的事都要到他那里匯總，由他本人處理并反饋?？嗔怂蝗?，卻給公司的溝通機制、架構扁平化帶來了實實在在的好處，是S公司得以有效運作的幕后功臣。S公司的招聘很嚴格，所有招聘都要過G這一關，G很重視工程師的能力，寧愿招不到人，也不招能力普通的人，而S公司對招聘人才很舍得花錢，能力不錯的人，一般都能以高于行內平均水平的薪資入職，所以這里其實是有不少高手的。這點和我在《關于“產品驅動”和“技術驅動”》中描述一致?！?，你懂的，會說的人比會做的人占便宜，而且G也不可能對所有人的判斷都正解，所以S公司里也有些實力一般但薪水較高的人，哪個公司都一樣，S公司也不例外。瑕不掩玉，總的來說，S公司的工程師們平均水平是很高的。

公司員工的水平高，而且個個都是通過G進來的，而公司的管理而極其扁平，對于工程師來說，是非常理想的。但其實這樣的機制也會有相應的問題，如果管理不善，就會像孟嘗君的門客了，吃吃喝喝行，搞的聲勢也很浩大，但實際產出卻并不怎么理想。后文我會就自己的經歷詳述。

進入S公司前，我跟G談過，我想來S公司建什么項目，入職以后，果然沒有給我安排某個現有的項目，從我入職第一天開始，就可以開始設計自己的項目了。我自己一個人又做產品設計，又做進度管理，花了兩個月時間，開發出了產品的原型。拿著產品原型，我參加了公司內部的立項會議——公司每個月會舉行一次立項會議，想立項的工程師們可以準備一份ppt，在這個會議上進行講解，產品的形態、目標、受眾、開發周期、人物力估算等等。如果立項成功，就可以正式立項，提交里程碑給項管辦，然后招人開工。

我對這種立項的形式非常滿意，這是自下而上的立項方式，和產品驅動型公司，自上而下的立項方式不同，一線的工程師們不再只是項目的執行者，他們也可以發揮自己的創意，憑借對技術的敏銳的嗅覺，技術驅動立項。在立項前他們可以很自由地去專心開發原型，因為工程師的質量比較有保障，所以原型失敗的風險還是比較小的。這樣的文化的確可以孕育出不少精彩的火花。

我的項目很順利地立項成功了。但人員配給并沒有按我預期的那樣有11人，包括我在內，項目只有三個人。三個全都是工程師出身。另外兩位也都是有六、七年工作經驗的老手，技術能力過硬，是圈子里有名氣的"牛人"。人是少了點兒，但人少有人少的做法，人多有人多的做法。我想一邊推進項目進展，一邊招人吧。但事實上，后來事情的發展和我預期相差較遠。不知道是公司對產品不是太重視的原因，還是因為要嚴格控制招聘人員的質量，所以S公司其實人手并不足夠的原因，后來給我加的人也只有一個實習生和一個美術設計師。而我的項目其實是個不小甚至很有點大的項目，為了保證項目順利推進，我不得不扛起產品經理、項目經理、架構師和工程師諸個不同的角色。

這樣是好事，也是壞事，好的是可以減少各環節溝通的成本，有技術背景的產品經理會非常懂得產品的各個特性性價比如何(功能重要性和實現成本)，而有產品經理title的項目經理可以更自主地確定各個功能的優先級，以及砍哪些特性留哪些特性。壞的是，產品經理和項目經理在決定產品開發周期和保留哪些性價比不高的特性時，會站在不同的角度進行PK，而產品經理和項目經理如果由同一人擔任，很可能會出現“產品經理和項目經理聯合起來砍特性，對工程師友好，但對產品不利”的情況，特別是像我這樣技術出身的產品經理，會更加偏袒工程師。而S公司的一把手也是技術出身，所以也會較偏袒工程師，S公司的專職產品經理比較少，大部分成員是工程師，而這里由項目經理兼任產品經理的情況還是比較普遍的。近來S公司也意識到這個問題了，在逐漸加大產品人員的比例。

雖然產品經理和項目經理讓一人兼任是利大于弊還是弊大于利有待商榷，但我個人是比較喜歡這種方式的。我對專職的產品經理印象不太好，可能我眼界比較小吧，我見到的大部分專職產品經理其實1對技術沒有基礎，2對產品認識并不深刻和有獨到見解，基本上還處在一個到處抄抄，重排一下UI就叫微創新的階段，門檻其實非常低，工作量不大，只會發號施令的催進度，提修改。而大部分工程師是非常勤奮的，看了很多的書，做了很多的研究，卻因為崗位的原因淪為碼農。再牛B的一群工程師，也扛不住一個不靠譜的產品經理。我還聽到一個很荒謬卻又現實的說法，“產品經理一個非常重要的本事就是吵架，不會吵架的產品經理不是個合格的產品經理”。這其實很病態。S公司讓項目經理兼任產品經理，一方面有利于“技術驅動”，提高工程師們對產品的把控能力，另一方面，也有利于架構扁平。

但有好的一面，就有壞的一面。產品驅動型的公司，架構不扁平，工程師能力也普遍中庸一點，雖然工程師會感覺像個螺絲釘，不怎么受到重視，滿意度欠佳，但同樣的會降低他們對自己的”心理預期“，提高執行力。雖然架構不夠扁平，有KPI機制制約工程師，是會官本位一些，遇到個糟糕的直接領導，很可能除了離職沒有其他辦法了，但對于產品經理來說，這樣的團隊比較好帶，團隊成員的執行力會比較高。而技術驅動型的公司，因為工程師們的職級都普遍較高——例如我帶的團隊，兩位資深的工程師，一位和我職級相同，另一位職級比我高，而這些人又都是通過G招進來的”專家“，入職也好、分配到我的項目中來也好，都并沒有通過我。以前我會覺得這樣很好，產品經理應該只負責產品設計和功能優先級選擇，項目經理只負責風險控制和進度控制，”管理“和”技術“應該是兩條線并行的，工程師的級別并不需要比經理的級別低，國外的大公司似乎都是這樣的，這樣才是健康合理，非官本位的。當我剛進S公司，看到幾個項目都是低級別工程師在帶著一群高級別工程師做項目時，我覺得特別美好，這才是一個正常的團隊，崗位和職級是分開的。

可是，我錯了，我嚴重低估了技術專家們的”個性“。雖然在立項環節，技術驅動有著非常好的效果，但那只是對立項的工程師本人來說非常好。項目立項成功后，會需要加入其他工程師進入團隊，其他工程師們又是如何看待項目的呢?他們并不一定喜歡這項目，只是他們沒有立項，被公司安排進來的。特別是有了好幾年工作經驗，而且在業界較有名氣的”牛人“，會特別有自己的想法和自己想做的事，加上公司并沒有KPI機制約束，而他們又是G高薪招進來的，在某個層面上來，他們的虛榮得到了極大的滿足，以“搞研究”的心態進入了公司。但其實我想任何公司其實應該都不會想招一些人進來純“搞研究”，一定會需要他們有所產出的，“搞研究”和“做項目”之間應該是有個比例的，比如說前者只能占20%左右的時間，大部分時間應該還是在為公司“直接”產出有價值的東西。

但“牛人”們似乎并不這么想，這應該是個判斷誤差。這個美麗的誤差就只能由項目負責人來承擔和消化了——一個沒有實權的產品經理來帶幾個心氣高的 “牛人”做項目，簡直就是惡夢，你總不能什么事都往G那里告狀吧?這只會顯得你管理無方，不會團隊合作，不懂團隊管理的藝術?？墒?，如果不往G那兒求助，又靠什么來讓這幫牛人專心工作呢?無論從級別上，還是行政管理上，或者是招聘上，沒有一關是由我來把的，這樣的機制我拿什么時候來帶領團隊?這樣的機制，真心管不住人，不好把控進度。而項目進度控制不好，項目失敗的風險無疑是由產品負責人買單的。這很病態!不只是我的團隊是這樣，我認識的別的團隊也有相同的情況，這是這種機制的難以避免的弊端。

我的項目是做一個平臺，項目本身可以分為“平臺”和“應用”兩個大方向。平臺 + 應用 * N = 我的項目。我們團隊的工程師們喜歡做應用，所以平臺我就一個人來做了，讓工程師們都去做應用。我關注軟件工程知識快三年了，深知軟件項目管理應該重人性，不要靠施壓的方式進行管理，這樣的做法非常原始，而且效果不好，很可能團隊氣氛壓抑，員工離職率高。特別是系統學習過xp和scrum之后，我對團隊自管理，scrum master幫助團隊對抗外界壓力，同時對團隊進行輔助的模式非常喜歡。在新浪的時候，我很好地實踐過scrum，scrum的威力也著實讓我見識到了。

本著人性管理的精神，有scrum作為支撐，我在項目開始的初期是這么設定項目的開發方式的：我本人做為“平臺”的產品經理、項目經理和工程師，獨立負責平臺的開發，并提供平臺和應用的接口文檔和技術支持，但每輪scrum都會和團隊一起分享我的原型設計圖和開發進展。而其他工程師每人做一個“應用”，自己做自己應用的產品經理項目經理和開發工程師，同樣每個輪次進行進度分享。我的初衷很簡單，對幾位資深工程師充分信任，團隊自管理，我只負責把握大方向，應用做什么，只需要跟我溝通一下就可以，設計和開發的過程都交由工程師自己把握。我本人非常喜歡這種模式，我認為這是對一個工程師最大的信任和尊重，同時能讓他們按照自己喜歡的方式做自己喜歡做的應用。但兩位工程師給我的反應卻是不斷地對項目質疑，要把項目改造成他們本人喜歡的方向。這是我在帶這支團隊時遇到的第一個問題，牛人有自己喜歡做的事，自己沒有立項去做，而是要將我的項目改造成他們喜歡的方向，和原本立的項完全不同。這當然不行!!立項是要負相應的責任的，我立了個項目A，卻完全做了一個不相干的B出來，這怎么行。人員不是我自己的招進團隊的，這點無疑成了日后一個巨大的隱患。

我否決了這個提議，然后發現工程師之后特別消極。這是我遇到的第二個問題，牛人有自己想做的事情，如果不是自己想做的事情，執行力就特別差，還經常在會議上特意唱反調。我特別頭疼，卻又拿不出有效的辦法來解決，我還算是個口才不錯的人，所以就事論事對一定不能松口的地方會詳細解釋理由，本著尊重對方的態度，希望能得到同樣的尊重。也不是說沒有效果，堅持這么做下來，效果還是不錯的，但抵觸情緒還是一直都有，始終難以完全化解掉。

再之后遇到了第三個問題，工程師們對“一人開發一個應用，多線并行”的開發方式不太滿意，希望能集全組之力，合力開發一個重量級應用。因為我很清楚人多口雜，每個人想法都不同，特別是幾個人都是“牛人”的時候，誰也很難服誰的道理，因為人手不多，而項目進度需要趕得緊，而我本人要開發平臺，精力有限，與其讓團隊陷入合作時無盡的激烈溝通，不如每人完整負責一個應用，自己做自己的。但既然工程師們希望合力做一個項目，我就合他們心意吧。但合全隊之力去開發應用時，牛人們跟我說“我們需要策劃，我不做策劃，我只負責執行”。無奈，我本意是希望位能自管理，自己挑自己喜歡的應用做，給予最大的自由度，但似乎兩人并不喜歡這樣，也許是他們的完美主義傾向決定了“他們無法挑出讓自己滿意的應用”，也許是對項目沒有按他們希望的方向改變，而做的抵觸反應，我不清楚。

但我沒有后援，我雖是個項目負責人，要對項目責任，但我沒有實權扣他們KPI，因為S公司壓根就沒有KPI。無奈只好我自己兼任策劃。我來把東西規劃清楚。但我預料的問題果然避不開，團隊合作之后，開發進度并沒有快多少，牛人們似乎并不怎么愛溝通，所以在分工之初，沒有出現scrum說的團隊自管理，自己溝通，確定接口什么的，只是分開寫模塊，然后集成時遇到問題。然后跟我說，一個人來做這個，我去做別的，兩個人一起做速度只是1.2個人的速度，不快。我去，你早干嘛了?為什么一開始要多人一起做“大”應用?那做大應用吧，你得一開始商量好如何合作再分頭行動啊，不，一開始自己做自己的，最后才告訴你只是1.2個人的速度。這是哪門子的多人合作?會合作嗎?這像是資深工程師的做事風格嗎?說到底，還是沒拿進度當回事，沒壓力。

然后是第四個問題，公司的態度。公司的策略是放養策略，對立項的各個項目并不做過多干涉，甚至不怎么過問。項目缺人手，很難給你配，就我知道的，很多項目都嚴重缺人。這和產品驅動的公司又是截然相反的做法，產品驅動的公司對產品的開發周期，上線時間有非常嚴格的預期，高層會催，會問。很多時候給出的時間很不靠譜，而且時間點一旦定下來了，工程師們就是加班加點也要趕出來，時間和任務量基本都是定死的。以前我會特別反感這樣的方式，特別是scrum提出的，只對當前輪次做清晰且明確的規劃和預期，而對未來則保持一個粗略的預期，這樣的開發方式才是靠譜的，才是能保證產品質量，才是保證工程師不會因為疲勞過度而離職的。

但后來我發現，對于產品驅動的文化，對時間有比較強烈預期的開發方式使用scrum才是特別有效的，因為這樣的文化工程師長期處于緊張的節奏中，scrum對他們來說是恩賜。而對于技術驅動的公司來說，特別是放養策略來說，工程師往往是比較懶散的，特別是定位于“我來搞研究”的牛人來說，主觀上就不會給自己上弦，客觀上公司又不給壓力的話，其實會對產品非常的不重視。再加上公司對產品不怎么過問，也不配充足人手的話，更會讓牛人們覺得“公司根本不關心這個產品，進不進度的沒所謂”，“這是項目負責人個人的項目，不是公司的項目”。這大大加大了項目負責人對執行力控制的難度。

我的團隊就是這樣，牛人經常出席各種公司外的活動，回到公司后也大量工作時間做自己感興趣的事，“搞研究”而不是開發項目。我對這樣的牛人非常反感，你喜歡搞些研究很好，你很喜歡參加公司外活動很好，可是應該分得清公事私事，如果公事對你有需要，請在工作時間之外再去做你的研究。工程師不關心項目的進度，認為那是“項目負責人的項目”不是公司的項目，公司對產品的態度有不可推卸的責任。以前我覺得能采取放養策略的公司，是特別偉大的，但現在我發現這其實給項目負責人帶來了極大的麻煩。即使放養，也應該有套機制進行約束才好，就當是讓項目負責人有個可以“狐假虎威”的依靠也好。不然，項目執行力低，責任歸到負責人不懂管理上，其實是不公平的。

第五個問題，scrum和加班問題。scrum是不提倡加班的，希望工程師們能夠在一個合適的強度下工作，盡量反映出真實的開發速度。但其實 scrum應該是用來解救那些被“時間點”折騰的工程師的。在技術驅動的公司里，工程師很可能并不勞累，相反相當松散，使用scrum反而是種約束，而不是解救了。因為第四點的原因，我不得以使用scrum來強制工程師們提高執行力了，但這里又迎來了新的問題，就是scrum周期結束時，任務完成不了怎么辦?按照scrum的做法，如果沒有特殊原因，scrum結束時應該盡量全部完成，如果實在完成不了，只要理由是合理的，不做什么責難。我也是本著這樣的思想去處理的，可是，這里有個前提是你在開發的過程中，要全部投入到項目中來啊。如果中間你去做別的自己感興趣的東西，最后周期結束了說完成不了，那 scrum還用來干嘛?scrum的寬松態度不是為了滿足“不責難”這一點才存在的吧?如果寬松態度換來的是消極待工的話，那還有什么可以約束工程師干活了?完成不了就加班?靠這種原始且惡劣的做法來約束你上班時間干項目需要你干的活嗎?項目經理被工程師逼著反敏捷,這估計也只有這種文化下才會出現的奇觀。

第六個問題，情緒控制和吵架的問題。我是個很能控制情緒的人，一般情況下很難發脾氣，我一直覺得軟件項目管理應該采用一種合適的態度，能讓全團隊保持一種輕松愉快的工作氛圍，活不是壓下來的，正常情況下，能讓自己按70%狀態持續開發就行，按100%甚至120要求團隊開發進度是不合適且無法長久的。和團隊成員沒有管理，沒有上下級關系，大家按一個科學的軟件工程方法，就事論事，按照合適的方法推進，所謂“管理”不過是指引方向和輔助團隊排除問題的公仆，技術和管理兩條線并行，各司其職。

可是我發現在某些情況下，你對事不對人，你控制情緒，你尊重人并不能換來同等的回報，很多時候反而慣著牛人越來越離譜和不負責任?；氐截撠熑螁栴}上來，項目是誰的項目?是團隊共同的項目，是公司的項目，不是某個人的項目!你不是為我工作，是為公司，只要公司支持這個項目，哪怕策略是放養，那也是公司的項目，是公事。我再會控制情緒也會有控制不了的時候，如果不想干，如果覺得你腕大，如果不看好項目，請公開的提出來，申請離開項目沒問題。如果待在某個項目里，卻又不把項目當做自己的事，那么請離開，專心去做你的研究，專心去業內發揚光大你個人的名聲去。人有時候是犯賤的，一直禮遇，只會慣著對方，并不會因此換來對方的理解和回報，這是我以前天真的地方，最有效的方法，還是該吵的時候要吵，不能一味慣著，特別是對牛人，特別是在技術驅動公司放養的公司里，管理還真不能過于人性化?？傆腥艘鰫喝?，如果公司高層不做，那么只能由項目負責人來做了，最后項目被砍，負責的是牛人們嗎?不是，是項目負責人。如果不反敏捷，不給團隊壓力的話，那執行力會低到令人發指的地步!可是這壓力，還是需要公司給權的呀，不然的話，拿什么壓?

就是因為公司扁平，技術人員腕大，項目負責人沒有實權，公司放養，慣得工程師一身的毛病。項目負責人夾在中間，特別難受。就是因為有這樣的問題，牛人才會跟你說“完不成能怎么滴，你能去跟G說讓我離職啊”。很多人僅僅看到我要做的項目和公司配的人員數量，就跟我說，“我要是你，就不做了”。要是他們知道就這幾個人，還有這么多軟件項目管理的問題，更是有多遠逃多遠了。

技術驅動型的公司，對工程師來說，很好，但對項目負責人來說，卻是惡夢。我聽說google雖然是技術驅動的，但其實是有KPI考核的，只是考核機制有點特殊：每個工程師有一張成績單，這張成績單會由其他工程師來給他打分(不是產品驅動型那樣，由他的直接領導打分)，分數越高，漲薪越快，薪水越高。如果成績單差，薪水也會低。所以google的工程師對別人會特別熱情，因為這和他的利益相關。

公司也并非沒有覺察到工程師中很多人混日子，執行力低的問題。于是采取了項目末位淘汰，淘汰項目人員重組或直接遣散的策略。借此來淘汰掉懶散的員工，讓優質資源保留下來重組。這樣倒是也的確可以刺激團隊的執行力，但效果并不明顯，而且其實受到最大影響的不是執行力低的牛人，而是各位無辜且無奈的項目負責人。揚湯止沸不如釜底抽薪，這樣下去，恐怕最直接的結果不是提高了工程師的執行力，而是打擊了工程師立項的積極性，應該采用更好的方式來解決這個問題。

說這么多，我倒不是對牛人們意見大，其實我意見更大的是公司策略?，F在這樣過于寬松的策略其實是助長甚至培養了工程師的懶散、隨意和不負責任。我想同樣的這幫人，換個氛圍不同的環境，也許表現會截然不同，什么水養什么樣的人，是時候改改水質了。

S公司有勇氣和膽量玩技術驅動，我很欣賞，可是S公司也應該想一套機制對工程師進行一下約束，一點約束也沒有是會壞事的。理論上一群牛人在一起工作，全明星陣容，技術驅動加上放養策略，該產生多么另人期待的奇跡啊?？墒乾F實卻是，團隊合作、個人追求與項目需要、執行力等到多個方面困難重重，如果沒有一套行之有效的方法改善這種局面，未來堪憂。

更多信息請查看IT技術專欄