一年前,我還在新浪時,寫了一篇文章叫做《關(guān)于“產(chǎn)品驅(qū)動”和“技術(shù)驅(qū)動”》。我在雅虎、淘寶和新浪都待過,這些公司都是產(chǎn)品驅(qū)動型的公司,我很熟悉,而關(guān)于技術(shù)驅(qū)動,我只聽之前的一位同事談過,他去過美國google參觀,了解過那邊的文化,我是從他那兒聽說的“技術(shù)驅(qū)動”。
那時的我,特別信奉技術(shù)驅(qū)動的工程師文化,技術(shù)驅(qū)動除了公司老板要擔相當?shù)娘L險之外,基本沒什么壞處,是一種非常好的IT公司文化,懂得尊重工程師,工程師的忠誠度和滿意度一定非常高,人員流失少,而且能技術(shù)創(chuàng)新出很多精彩的產(chǎn)品出來。那時我很憧憬技術(shù)驅(qū)動型的公司,覺得那一定是工程師的天堂。我在新浪的級別還挺高的,領(lǐng)導(dǎo)們很器重我,給了我不少機會,帶重要的產(chǎn)品團隊、內(nèi)部培訓(xùn)講師、校園網(wǎng)絡(luò)學(xué)院講師等等,還在一年后給我漲了50%的薪水??墒羌幢闳绱?,我還是離開了新浪,去了國內(nèi)某家技術(shù)驅(qū)動型的公司S,因為我對技術(shù)驅(qū)動型的公司實在是太向往了。想來,對新浪至今仍有愧疚,希望以后能有機會以別的方式來回報新浪。
一年多以后的現(xiàn)在,我在S公司感受了一整年的技術(shù)驅(qū)動文化,作為一個扮演多重角色的員工(產(chǎn)品經(jīng)理、項目經(jīng)理、架構(gòu)師、工程師、策劃),我對技術(shù)驅(qū)動的利弊有了較深的感悟,想來細說一下“技術(shù)驅(qū)動”文化中的各種問題。
S公司的確是家技術(shù)驅(qū)動型的公司,公司管理非常扁平,從一線工程師,到項目經(jīng)理,再到公司高層G,共起來只有三層。G特別忙碌,所有的事都要到他那里匯總,由他本人處理并反饋。苦了他一人,卻給公司的溝通機制、架構(gòu)扁平化帶來了實實在在的好處,是S公司得以有效運作的幕后功臣。S公司的招聘很嚴格,所有招聘都要過G這一關(guān),G很重視工程師的能力,寧愿招不到人,也不招能力普通的人,而S公司對招聘人才很舍得花錢,能力不錯的人,一般都能以高于行內(nèi)平均水平的薪資入職,所以這里其實是有不少高手的。這點和我在《關(guān)于“產(chǎn)品驅(qū)動”和“技術(shù)驅(qū)動”》中描述一致?!?,你懂的,會說的人比會做的人占便宜,而且G也不可能對所有人的判斷都正解,所以S公司里也有些實力一般但薪水較高的人,哪個公司都一樣,S公司也不例外。瑕不掩玉,總的來說,S公司的工程師們平均水平是很高的。
公司員工的水平高,而且個個都是通過G進來的,而公司的管理而極其扁平,對于工程師來說,是非常理想的。但其實這樣的機制也會有相應(yīng)的問題,如果管理不善,就會像孟嘗君的門客了,吃吃喝喝行,搞的聲勢也很浩大,但實際產(chǎn)出卻并不怎么理想。后文我會就自己的經(jīng)歷詳述。
進入S公司前,我跟G談過,我想來S公司建什么項目,入職以后,果然沒有給我安排某個現(xiàn)有的項目,從我入職第一天開始,就可以開始設(shè)計自己的項目了。我自己一個人又做產(chǎn)品設(shè)計,又做進度管理,花了兩個月時間,開發(fā)出了產(chǎn)品的原型。拿著產(chǎn)品原型,我參加了公司內(nèi)部的立項會議——公司每個月會舉行一次立項會議,想立項的工程師們可以準備一份ppt,在這個會議上進行講解,產(chǎn)品的形態(tài)、目標、受眾、開發(fā)周期、人物力估算等等。如果立項成功,就可以正式立項,提交里程碑給項管辦,然后招人開工。
我對這種立項的形式非常滿意,這是自下而上的立項方式,和產(chǎn)品驅(qū)動型公司,自上而下的立項方式不同,一線的工程師們不再只是項目的執(zhí)行者,他們也可以發(fā)揮自己的創(chuàng)意,憑借對技術(shù)的敏銳的嗅覺,技術(shù)驅(qū)動立項。在立項前他們可以很自由地去專心開發(fā)原型,因為工程師的質(zhì)量比較有保障,所以原型失敗的風險還是比較小的。這樣的文化的確可以孕育出不少精彩的火花。
我的項目很順利地立項成功了。但人員配給并沒有按我預(yù)期的那樣有11人,包括我在內(nèi),項目只有三個人。三個全都是工程師出身。另外兩位也都是有六、七年工作經(jīng)驗的老手,技術(shù)能力過硬,是圈子里有名氣的"牛人"。人是少了點兒,但人少有人少的做法,人多有人多的做法。我想一邊推進項目進展,一邊招人吧。但事實上,后來事情的發(fā)展和我預(yù)期相差較遠。不知道是公司對產(chǎn)品不是太重視的原因,還是因為要嚴格控制招聘人員的質(zhì)量,所以S公司其實人手并不足夠的原因,后來給我加的人也只有一個實習生和一個美術(shù)設(shè)計師。而我的項目其實是個不小甚至很有點大的項目,為了保證項目順利推進,我不得不扛起產(chǎn)品經(jīng)理、項目經(jīng)理、架構(gòu)師和工程師諸個不同的角色。
這樣是好事,也是壞事,好的是可以減少各環(huán)節(jié)溝通的成本,有技術(shù)背景的產(chǎn)品經(jīng)理會非常懂得產(chǎn)品的各個特性性價比如何(功能重要性和實現(xiàn)成本),而有產(chǎn)品經(jīng)理title的項目經(jīng)理可以更自主地確定各個功能的優(yōu)先級,以及砍哪些特性留哪些特性。壞的是,產(chǎn)品經(jīng)理和項目經(jīng)理在決定產(chǎn)品開發(fā)周期和保留哪些性價比不高的特性時,會站在不同的角度進行PK,而產(chǎn)品經(jīng)理和項目經(jīng)理如果由同一人擔任,很可能會出現(xiàn)“產(chǎn)品經(jīng)理和項目經(jīng)理聯(lián)合起來砍特性,對工程師友好,但對產(chǎn)品不利”的情況,特別是像我這樣技術(shù)出身的產(chǎn)品經(jīng)理,會更加偏袒工程師。而S公司的一把手也是技術(shù)出身,所以也會較偏袒工程師,S公司的專職產(chǎn)品經(jīng)理比較少,大部分成員是工程師,而這里由項目經(jīng)理兼任產(chǎn)品經(jīng)理的情況還是比較普遍的。近來S公司也意識到這個問題了,在逐漸加大產(chǎn)品人員的比例。
雖然產(chǎn)品經(jīng)理和項目經(jīng)理讓一人兼任是利大于弊還是弊大于利有待商榷,但我個人是比較喜歡這種方式的。我對專職的產(chǎn)品經(jīng)理印象不太好,可能我眼界比較小吧,我見到的大部分專職產(chǎn)品經(jīng)理其實1對技術(shù)沒有基礎(chǔ),2對產(chǎn)品認識并不深刻和有獨到見解,基本上還處在一個到處抄抄,重排一下UI就叫微創(chuàng)新的階段,門檻其實非常低,工作量不大,只會發(fā)號施令的催進度,提修改。而大部分工程師是非常勤奮的,看了很多的書,做了很多的研究,卻因為崗位的原因淪為碼農(nóng)。再牛B的一群工程師,也扛不住一個不靠譜的產(chǎn)品經(jīng)理。我還聽到一個很荒謬卻又現(xiàn)實的說法,“產(chǎn)品經(jīng)理一個非常重要的本事就是吵架,不會吵架的產(chǎn)品經(jīng)理不是個合格的產(chǎn)品經(jīng)理”。這其實很病態(tài)。S公司讓項目經(jīng)理兼任產(chǎn)品經(jīng)理,一方面有利于“技術(shù)驅(qū)動”,提高工程師們對產(chǎn)品的把控能力,另一方面,也有利于架構(gòu)扁平。
但有好的一面,就有壞的一面。產(chǎn)品驅(qū)動型的公司,架構(gòu)不扁平,工程師能力也普遍中庸一點,雖然工程師會感覺像個螺絲釘,不怎么受到重視,滿意度欠佳,但同樣的會降低他們對自己的”心理預(yù)期“,提高執(zhí)行力。雖然架構(gòu)不夠扁平,有KPI機制制約工程師,是會官本位一些,遇到個糟糕的直接領(lǐng)導(dǎo),很可能除了離職沒有其他辦法了,但對于產(chǎn)品經(jīng)理來說,這樣的團隊比較好帶,團隊成員的執(zhí)行力會比較高。而技術(shù)驅(qū)動型的公司,因為工程師們的職級都普遍較高——例如我?guī)У膱F隊,兩位資深的工程師,一位和我職級相同,另一位職級比我高,而這些人又都是通過G招進來的”專家“,入職也好、分配到我的項目中來也好,都并沒有通過我。以前我會覺得這樣很好,產(chǎn)品經(jīng)理應(yīng)該只負責產(chǎn)品設(shè)計和功能優(yōu)先級選擇,項目經(jīng)理只負責風險控制和進度控制,”管理“和”技術(shù)“應(yīng)該是兩條線并行的,工程師的級別并不需要比經(jīng)理的級別低,國外的大公司似乎都是這樣的,這樣才是健康合理,非官本位的。當我剛進S公司,看到幾個項目都是低級別工程師在帶著一群高級別工程師做項目時,我覺得特別美好,這才是一個正常的團隊,崗位和職級是分開的。
可是,我錯了,我嚴重低估了技術(shù)專家們的”個性“。雖然在立項環(huán)節(jié),技術(shù)驅(qū)動有著非常好的效果,但那只是對立項的工程師本人來說非常好。項目立項成功后,會需要加入其他工程師進入團隊,其他工程師們又是如何看待項目的呢?他們并不一定喜歡這項目,只是他們沒有立項,被公司安排進來的。特別是有了好幾年工作經(jīng)驗,而且在業(yè)界較有名氣的”牛人“,會特別有自己的想法和自己想做的事,加上公司并沒有KPI機制約束,而他們又是G高薪招進來的,在某個層面上來,他們的虛榮得到了極大的滿足,以“搞研究”的心態(tài)進入了公司。但其實我想任何公司其實應(yīng)該都不會想招一些人進來純“搞研究”,一定會需要他們有所產(chǎn)出的,“搞研究”和“做項目”之間應(yīng)該是有個比例的,比如說前者只能占20%左右的時間,大部分時間應(yīng)該還是在為公司“直接”產(chǎn)出有價值的東西。
但“牛人”們似乎并不這么想,這應(yīng)該是個判斷誤差。這個美麗的誤差就只能由項目負責人來承擔和消化了——一個沒有實權(quán)的產(chǎn)品經(jīng)理來帶幾個心氣高的 “牛人”做項目,簡直就是惡夢,你總不能什么事都往G那里告狀吧?這只會顯得你管理無方,不會團隊合作,不懂團隊管理的藝術(shù)??墒?,如果不往G那兒求助,又靠什么來讓這幫牛人專心工作呢?無論從級別上,還是行政管理上,或者是招聘上,沒有一關(guān)是由我來把的,這樣的機制我拿什么時候來帶領(lǐng)團隊?這樣的機制,真心管不住人,不好把控進度。而項目進度控制不好,項目失敗的風險無疑是由產(chǎn)品負責人買單的。這很病態(tài)!不只是我的團隊是這樣,我認識的別的團隊也有相同的情況,這是這種機制的難以避免的弊端。
我的項目是做一個平臺,項目本身可以分為“平臺”和“應(yīng)用”兩個大方向。平臺 + 應(yīng)用 * N = 我的項目。我們團隊的工程師們喜歡做應(yīng)用,所以平臺我就一個人來做了,讓工程師們都去做應(yīng)用。我關(guān)注軟件工程知識快三年了,深知軟件項目管理應(yīng)該重人性,不要靠施壓的方式進行管理,這樣的做法非常原始,而且效果不好,很可能團隊氣氛壓抑,員工離職率高。特別是系統(tǒng)學(xué)習過xp和scrum之后,我對團隊自管理,scrum master幫助團隊對抗外界壓力,同時對團隊進行輔助的模式非常喜歡。在新浪的時候,我很好地實踐過scrum,scrum的威力也著實讓我見識到了。
本著人性管理的精神,有scrum作為支撐,我在項目開始的初期是這么設(shè)定項目的開發(fā)方式的:我本人做為“平臺”的產(chǎn)品經(jīng)理、項目經(jīng)理和工程師,獨立負責平臺的開發(fā),并提供平臺和應(yīng)用的接口文檔和技術(shù)支持,但每輪scrum都會和團隊一起分享我的原型設(shè)計圖和開發(fā)進展。而其他工程師每人做一個“應(yīng)用”,自己做自己應(yīng)用的產(chǎn)品經(jīng)理項目經(jīng)理和開發(fā)工程師,同樣每個輪次進行進度分享。我的初衷很簡單,對幾位資深工程師充分信任,團隊自管理,我只負責把握大方向,應(yīng)用做什么,只需要跟我溝通一下就可以,設(shè)計和開發(fā)的過程都交由工程師自己把握。我本人非常喜歡這種模式,我認為這是對一個工程師最大的信任和尊重,同時能讓他們按照自己喜歡的方式做自己喜歡做的應(yīng)用。但兩位工程師給我的反應(yīng)卻是不斷地對項目質(zhì)疑,要把項目改造成他們本人喜歡的方向。這是我在帶這支團隊時遇到的第一個問題,牛人有自己喜歡做的事,自己沒有立項去做,而是要將我的項目改造成他們喜歡的方向,和原本立的項完全不同。這當然不行!!立項是要負相應(yīng)的責任的,我立了個項目A,卻完全做了一個不相干的B出來,這怎么行。人員不是我自己的招進團隊的,這點無疑成了日后一個巨大的隱患。
我否決了這個提議,然后發(fā)現(xiàn)工程師之后特別消極。這是我遇到的第二個問題,牛人有自己想做的事情,如果不是自己想做的事情,執(zhí)行力就特別差,還經(jīng)常在會議上特意唱反調(diào)。我特別頭疼,卻又拿不出有效的辦法來解決,我還算是個口才不錯的人,所以就事論事對一定不能松口的地方會詳細解釋理由,本著尊重對方的態(tài)度,希望能得到同樣的尊重。也不是說沒有效果,堅持這么做下來,效果還是不錯的,但抵觸情緒還是一直都有,始終難以完全化解掉。
再之后遇到了第三個問題,工程師們對“一人開發(fā)一個應(yīng)用,多線并行”的開發(fā)方式不太滿意,希望能集全組之力,合力開發(fā)一個重量級應(yīng)用。因為我很清楚人多口雜,每個人想法都不同,特別是幾個人都是“牛人”的時候,誰也很難服誰的道理,因為人手不多,而項目進度需要趕得緊,而我本人要開發(fā)平臺,精力有限,與其讓團隊陷入合作時無盡的激烈溝通,不如每人完整負責一個應(yīng)用,自己做自己的。但既然工程師們希望合力做一個項目,我就合他們心意吧。但合全隊之力去開發(fā)應(yīng)用時,牛人們跟我說“我們需要策劃,我不做策劃,我只負責執(zhí)行”。無奈,我本意是希望位能自管理,自己挑自己喜歡的應(yīng)用做,給予最大的自由度,但似乎兩人并不喜歡這樣,也許是他們的完美主義傾向決定了“他們無法挑出讓自己滿意的應(yīng)用”,也許是對項目沒有按他們希望的方向改變,而做的抵觸反應(yīng),我不清楚。
但我沒有后援,我雖是個項目負責人,要對項目責任,但我沒有實權(quán)扣他們KPI,因為S公司壓根就沒有KPI。無奈只好我自己兼任策劃。我來把東西規(guī)劃清楚。但我預(yù)料的問題果然避不開,團隊合作之后,開發(fā)進度并沒有快多少,牛人們似乎并不怎么愛溝通,所以在分工之初,沒有出現(xiàn)scrum說的團隊自管理,自己溝通,確定接口什么的,只是分開寫模塊,然后集成時遇到問題。然后跟我說,一個人來做這個,我去做別的,兩個人一起做速度只是1.2個人的速度,不快。我去,你早干嘛了?為什么一開始要多人一起做“大”應(yīng)用?那做大應(yīng)用吧,你得一開始商量好如何合作再分頭行動啊,不,一開始自己做自己的,最后才告訴你只是1.2個人的速度。這是哪門子的多人合作?會合作嗎?這像是資深工程師的做事風格嗎?說到底,還是沒拿進度當回事,沒壓力。
然后是第四個問題,公司的態(tài)度。公司的策略是放養(yǎng)策略,對立項的各個項目并不做過多干涉,甚至不怎么過問。項目缺人手,很難給你配,就我知道的,很多項目都嚴重缺人。這和產(chǎn)品驅(qū)動的公司又是截然相反的做法,產(chǎn)品驅(qū)動的公司對產(chǎn)品的開發(fā)周期,上線時間有非常嚴格的預(yù)期,高層會催,會問。很多時候給出的時間很不靠譜,而且時間點一旦定下來了,工程師們就是加班加點也要趕出來,時間和任務(wù)量基本都是定死的。以前我會特別反感這樣的方式,特別是scrum提出的,只對當前輪次做清晰且明確的規(guī)劃和預(yù)期,而對未來則保持一個粗略的預(yù)期,這樣的開發(fā)方式才是靠譜的,才是能保證產(chǎn)品質(zhì)量,才是保證工程師不會因為疲勞過度而離職的。
但后來我發(fā)現(xiàn),對于產(chǎn)品驅(qū)動的文化,對時間有比較強烈預(yù)期的開發(fā)方式使用scrum才是特別有效的,因為這樣的文化工程師長期處于緊張的節(jié)奏中,scrum對他們來說是恩賜。而對于技術(shù)驅(qū)動的公司來說,特別是放養(yǎng)策略來說,工程師往往是比較懶散的,特別是定位于“我來搞研究”的牛人來說,主觀上就不會給自己上弦,客觀上公司又不給壓力的話,其實會對產(chǎn)品非常的不重視。再加上公司對產(chǎn)品不怎么過問,也不配充足人手的話,更會讓牛人們覺得“公司根本不關(guān)心這個產(chǎn)品,進不進度的沒所謂”,“這是項目負責人個人的項目,不是公司的項目”。這大大加大了項目負責人對執(zhí)行力控制的難度。
我的團隊就是這樣,牛人經(jīng)常出席各種公司外的活動,回到公司后也大量工作時間做自己感興趣的事,“搞研究”而不是開發(fā)項目。我對這樣的牛人非常反感,你喜歡搞些研究很好,你很喜歡參加公司外活動很好,可是應(yīng)該分得清公事私事,如果公事對你有需要,請在工作時間之外再去做你的研究。工程師不關(guān)心項目的進度,認為那是“項目負責人的項目”不是公司的項目,公司對產(chǎn)品的態(tài)度有不可推卸的責任。以前我覺得能采取放養(yǎng)策略的公司,是特別偉大的,但現(xiàn)在我發(fā)現(xiàn)這其實給項目負責人帶來了極大的麻煩。即使放養(yǎng),也應(yīng)該有套機制進行約束才好,就當是讓項目負責人有個可以“狐假虎威”的依靠也好。不然,項目執(zhí)行力低,責任歸到負責人不懂管理上,其實是不公平的。
第五個問題,scrum和加班問題。scrum是不提倡加班的,希望工程師們能夠在一個合適的強度下工作,盡量反映出真實的開發(fā)速度。但其實 scrum應(yīng)該是用來解救那些被“時間點”折騰的工程師的。在技術(shù)驅(qū)動的公司里,工程師很可能并不勞累,相反相當松散,使用scrum反而是種約束,而不是解救了。因為第四點的原因,我不得以使用scrum來強制工程師們提高執(zhí)行力了,但這里又迎來了新的問題,就是scrum周期結(jié)束時,任務(wù)完成不了怎么辦?按照scrum的做法,如果沒有特殊原因,scrum結(jié)束時應(yīng)該盡量全部完成,如果實在完成不了,只要理由是合理的,不做什么責難。我也是本著這樣的思想去處理的,可是,這里有個前提是你在開發(fā)的過程中,要全部投入到項目中來啊。如果中間你去做別的自己感興趣的東西,最后周期結(jié)束了說完成不了,那 scrum還用來干嘛?scrum的寬松態(tài)度不是為了滿足“不責難”這一點才存在的吧?如果寬松態(tài)度換來的是消極待工的話,那還有什么可以約束工程師干活了?完成不了就加班?靠這種原始且惡劣的做法來約束你上班時間干項目需要你干的活嗎?項目經(jīng)理被工程師逼著反敏捷,這估計也只有這種文化下才會出現(xiàn)的奇觀。
第六個問題,情緒控制和吵架的問題。我是個很能控制情緒的人,一般情況下很難發(fā)脾氣,我一直覺得軟件項目管理應(yīng)該采用一種合適的態(tài)度,能讓全團隊保持一種輕松愉快的工作氛圍,活不是壓下來的,正常情況下,能讓自己按70%狀態(tài)持續(xù)開發(fā)就行,按100%甚至120要求團隊開發(fā)進度是不合適且無法長久的。和團隊成員沒有管理,沒有上下級關(guān)系,大家按一個科學(xué)的軟件工程方法,就事論事,按照合適的方法推進,所謂“管理”不過是指引方向和輔助團隊排除問題的公仆,技術(shù)和管理兩條線并行,各司其職。
可是我發(fā)現(xiàn)在某些情況下,你對事不對人,你控制情緒,你尊重人并不能換來同等的回報,很多時候反而慣著牛人越來越離譜和不負責任?;氐截撠熑螁栴}上來,項目是誰的項目?是團隊共同的項目,是公司的項目,不是某個人的項目!你不是為我工作,是為公司,只要公司支持這個項目,哪怕策略是放養(yǎng),那也是公司的項目,是公事。我再會控制情緒也會有控制不了的時候,如果不想干,如果覺得你腕大,如果不看好項目,請公開的提出來,申請離開項目沒問題。如果待在某個項目里,卻又不把項目當做自己的事,那么請離開,專心去做你的研究,專心去業(yè)內(nèi)發(fā)揚光大你個人的名聲去。人有時候是犯賤的,一直禮遇,只會慣著對方,并不會因此換來對方的理解和回報,這是我以前天真的地方,最有效的方法,還是該吵的時候要吵,不能一味慣著,特別是對牛人,特別是在技術(shù)驅(qū)動公司放養(yǎng)的公司里,管理還真不能過于人性化??傆腥艘鰫喝?,如果公司高層不做,那么只能由項目負責人來做了,最后項目被砍,負責的是牛人們嗎?不是,是項目負責人。如果不反敏捷,不給團隊壓力的話,那執(zhí)行力會低到令人發(fā)指的地步!可是這壓力,還是需要公司給權(quán)的呀,不然的話,拿什么壓?
就是因為公司扁平,技術(shù)人員腕大,項目負責人沒有實權(quán),公司放養(yǎng),慣得工程師一身的毛病。項目負責人夾在中間,特別難受。就是因為有這樣的問題,牛人才會跟你說“完不成能怎么滴,你能去跟G說讓我離職啊”。很多人僅僅看到我要做的項目和公司配的人員數(shù)量,就跟我說,“我要是你,就不做了”。要是他們知道就這幾個人,還有這么多軟件項目管理的問題,更是有多遠逃多遠了。
技術(shù)驅(qū)動型的公司,對工程師來說,很好,但對項目負責人來說,卻是惡夢。我聽說google雖然是技術(shù)驅(qū)動的,但其實是有KPI考核的,只是考核機制有點特殊:每個工程師有一張成績單,這張成績單會由其他工程師來給他打分(不是產(chǎn)品驅(qū)動型那樣,由他的直接領(lǐng)導(dǎo)打分),分數(shù)越高,漲薪越快,薪水越高。如果成績單差,薪水也會低。所以google的工程師對別人會特別熱情,因為這和他的利益相關(guān)。
公司也并非沒有覺察到工程師中很多人混日子,執(zhí)行力低的問題。于是采取了項目末位淘汰,淘汰項目人員重組或直接遣散的策略。借此來淘汰掉懶散的員工,讓優(yōu)質(zhì)資源保留下來重組。這樣倒是也的確可以刺激團隊的執(zhí)行力,但效果并不明顯,而且其實受到最大影響的不是執(zhí)行力低的牛人,而是各位無辜且無奈的項目負責人。揚湯止沸不如釜底抽薪,這樣下去,恐怕最直接的結(jié)果不是提高了工程師的執(zhí)行力,而是打擊了工程師立項的積極性,應(yīng)該采用更好的方式來解決這個問題。
說這么多,我倒不是對牛人們意見大,其實我意見更大的是公司策略?,F(xiàn)在這樣過于寬松的策略其實是助長甚至培養(yǎng)了工程師的懶散、隨意和不負責任。我想同樣的這幫人,換個氛圍不同的環(huán)境,也許表現(xiàn)會截然不同,什么水養(yǎng)什么樣的人,是時候改改水質(zhì)了。
S公司有勇氣和膽量玩技術(shù)驅(qū)動,我很欣賞,可是S公司也應(yīng)該想一套機制對工程師進行一下約束,一點約束也沒有是會壞事的。理論上一群牛人在一起工作,全明星陣容,技術(shù)驅(qū)動加上放養(yǎng)策略,該產(chǎn)生多么另人期待的奇跡啊??墒乾F(xiàn)實卻是,團隊合作、個人追求與項目需要、執(zhí)行力等到多個方面困難重重,如果沒有一套行之有效的方法改善這種局面,未來堪憂。
更多信息請查看IT技術(shù)專欄