一年前，我還在新浪時，寫瞭一篇文章叫做《關於產物驅動和技巧驅動》。我在雅虎、淘寶和新浪都待過，這些公司都是產物驅動型的公司，我很熟習，而關於技巧驅動，我隻聽之前的一名同事談過，他去過美國谷歌觀光，懂得過那裡的文明，我是從他那兒據說的技巧驅動。

　　當時的我，特殊信仰技巧驅動的工程師文明，技巧驅動除公司老板要擔相稱的風險以外，根本沒甚麼弊端，是一種異常好的IT公司文明，理解尊敬工程師，工程師的忠實度和滿足度必定異常高，職員流掉少，並且能技巧立異出許多出色的產物出來。當時我很向往技巧驅動型的公司，認為那必定是工程師的天國。我在新浪的級別還挺高的，引導們很重視我，給瞭我很多機遇，帶主要的產物團隊、內部培訓講師、校園收集學院講師等等，還在一年後給我漲瞭50%的薪水。但是即使如斯，我照樣分開瞭新浪，去瞭海內某傢技巧驅動型的公司S，由於我對技巧驅動型的公司其實是太神往瞭。想來，對新浪至今仍有內疚，願望今後能有機遇以其餘方法往返報新浪。

　　一年多今後的如今，我在S公司感觸感染瞭一全年的技巧驅動文明，作為一個飾演多重腳色的員工(產物司理、項目司理、架構師、工程師、謀劃)，我對技巧驅動的利弊有瞭較深的感悟，想來細說一下技巧驅動文明中的各類題目。

　　S公司切實其實是傢技巧驅動型的公司，公司治理異常扁平，從一線工程師，到項目司理，再到公司高層G，共起來隻要三層。G特殊勞碌，全部的事都要到他那邊匯總，由他本人處置並反應。苦瞭他一人，卻給公司的相同機制、架構扁平化帶來瞭實其實在的利益，是S公司得以有用運作的幕後元勛。S公司的雇用很嚴厲，全部雇用都要過G這一關，G很看重工程師的才能，情願招沒有到人，也沒有招才能通俗的人，而S公司對雇用人材很舍得費錢，才能沒有錯的人，一樣平常都能以高於行內均勻程度的薪資入職，以是這裡實在是有很多妙手的。這點和我在《關於產物驅動和技巧驅動》中描寫同等。但，你懂的，會說的人比會做的人占廉價，並且G也弗成能對全部人的斷定都正解，以是S公司裡也有些氣力一樣平常但薪水較高的人，哪一個公司都一樣，S公司也沒有破例。瑕沒有掩玉，總的來講，S公司的工程師們均勻程度是很高的。

　　公司員工的程度高，並且個個都是經由過程G出去的，而公司的治理而極為扁平，對付工程師來講，長短常幻想的。但實在如許的機制也會有響應的題目，假如治理沒有善，就會像孟嘗君的食客瞭，吃吃喝喝行，弄的陣容也很浩蕩，但現實產出卻其實不怎樣幻想。後文我會就本身的閱歷臚陳。

　　進入S公司前，我跟G談過，我想來S公司建甚麼項目，入職今後，果真沒有給我支配某個現有的項目，從我入職第一天開端，便可以開端計劃本身的項目瞭。我本身一小我又做產物計劃，又做進度治理，花瞭兩個月時光，開辟出瞭產物的原型。拿著產物原型，我加入瞭公司內部的立項集會公司每一個月會舉辦一次立項集會，想立項的工程師們能夠預備一份ppt，在這個集會長進行講授，產物的形狀、目的、受眾、開辟周期、人物力預算等等。假如立項勝利，便可以正式立項，提交裡程碑給項管辦，然後招人完工。

　　我對這類立項的情勢異常滿足，這是自下而上的立項方法，和產物驅動型公司，自上而下的立項方法分歧，一線的工程師們沒有再隻是項目標履行者，他們也能夠施展本身的創意，依附對技巧的靈敏的嗅覺，技巧驅動立項。在立項前他們能夠很自在地去用心開辟原型，由於工程師的質量比擬有保證，以是原型掉敗的風險照樣比擬小的。如許的文明切實其實能夠孕育出很多出色的火花。

　　我的項目很順遂地立項勝利瞭。但職員配給並沒有按我預期的那樣有11人，包含我在內，項目隻要三小我。三個全都是工程師出生。別的兩位也都是有6、七年事情履歷的熟手在行，技巧才能過硬，是圈子裡著名氣的牛人。人是少瞭點兒，但人少有人少的做法，人多有人多的做法。我想一邊推動項目希望，一邊招人吧。但究竟上，厥後工作的成長和我預期相差較遠。沒有曉得是公司對產物沒有是太看重的緣故原由，照樣由於要嚴厲掌握雇用職員的質量，以是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說讓我去職啊。許多人僅僅看到我要做的項目和公司配的職員數目，就跟我說，我如果你，就沒有做瞭。如果他們曉得就這幾小我，另有這麼多軟件項目治理的題目，更是有多遠逃多遠瞭。

　　技巧驅動型的公司，對工程師來講，很好，但對項目賣力人來講，倒是噩夢。我據說谷歌固然是技巧驅動的，但實在是有KPI考察的，隻是考察機制有點特別：每一個工程師有一張成就單，這張成就單會由其他工程師來給他打分(沒有是產物驅動型那樣，由他的間接引導打分)，分數越高，漲薪越快，薪水越高。假如成就單差，薪水也會低。以是谷歌的工程師對他人會特殊熱忱，由於這和他的好處相幹。

　　公司也並不是沒有發覺到工程師中許多人混日子，履行力低的題目。因而采用瞭項目末位鐫汰，鐫汰項目職員重組或間接解散的計謀。借此來鐫汰失落懶惰的員工，讓優良資本保存下來重組。如許卻是也切實其實能夠刺激團隊的履行力，但後果其實不顯著，並且實在遭到最大影響的沒有是履行力低的牛人，而是列位無辜且無法的項目賣力人。救火投薪沒有如釜底抽薪，如許下去，生怕最間接的成果沒有是進步瞭工程師的履行力，而是襲擊瞭工程師立項的主動性，應當采取更好的方法來辦理這個題目。

　　說這麼多，我倒沒有是對牛人們看法大，實在我看法更大的是公司計謀。如今如許過於寬松的計謀實在是滋長乃至造就瞭工程師的懶惰、隨便和沒有賣力任。我想一樣的這幫人，換個氣氛分歧的情況，大概表示會判然不同，甚麼水養甚麼樣的人，是時刻改改水質瞭。

　　S公司有勇氣和膽子玩技巧驅動，我很觀賞，但是S公司也應當想一套機制對工程師舉行一下束縛，一點束縛也沒有是會好事的。實際上一群牛人在一路事情，全明星聲威，技巧驅動加上放養計謀，該發生何等另人等待的事業啊。但是實際倒是，團隊互助、小我尋求與項目須要、履行力比及多個方面艱苦重重，假如沒有一套行之有用的辦法改良這類局勢，將來堪憂。