公司的運行方式有兩種：“產(chǎn)品驅動”和“技術驅動”。
國內甚至國際上絕大部分的公司都是“產(chǎn)品驅動”型，它的運作方式是這樣的：公司高層負責“戰(zhàn)略布局”，只提出需求“我要個什么東西，能實現(xiàn)什么功能”，然后給出一個時間點，要搶在什么什么時間點上線這個項目。如果有現(xiàn)成的團隊，那么由這個團隊去完成，如果沒有，那么招人或內部調整組織起來這么個隊伍。隊伍里會有產(chǎn)品經(jīng)理和項目經(jīng)理，產(chǎn)品經(jīng)理負責設計工作的把控和對產(chǎn)品的收益負責，也就是說，由他來對這個產(chǎn)品的經(jīng)濟效益扛KPI。項目經(jīng)理負責開發(fā)團隊的日常進度管理，協(xié)調資源分配開發(fā)任務什么的。產(chǎn)品經(jīng)理和項目經(jīng)理雖然同稱為“經(jīng)理”，但事實上，產(chǎn)品經(jīng)理是公司高層和開發(fā)團隊的扭帶，公司高層并不會關心開發(fā)工作的細節(jié)，他們只會跟產(chǎn)品經(jīng)理銜接，對于開發(fā)團隊來說，產(chǎn)品經(jīng)理是公司高層的代表，是項目需求方，而且他對產(chǎn)品的經(jīng)濟效益扛KPI，所以產(chǎn)品經(jīng)理其實權力非常大！
但產(chǎn)品經(jīng)理通常都沒有技術背景，他們不懂技術，也不懂工程師文化，不知道工程師對什么在意，他的思想集中在“商業(yè)”和“產(chǎn)品設計”上。項目經(jīng)理的職責是對項目的進度進行把控，他其實是很需要“軟件工程”方面的知識的，如果項目經(jīng)理靠譜的話，事情也好辦，但往往項目經(jīng)理大多數(shù)對“軟件工程”其實并不太了解，項目經(jīng)理往往是“技而優(yōu)則仕”提拔起來的，也許“開發(fā)”能力過得了關，但“開發(fā)”和“管理”是兩碼事，“軟件工程”之所以能獨立成為一個方向，正是因為其重要程度已經(jīng)達到了一個不可忽視的地步——上世紀六、七十年代的軟件危機，就是因為缺少“軟件工程”方面知識的指導而暴發(fā)的。
項目經(jīng)理對“軟件工程”的知識欠缺導致的問題就是：公司高層習慣了指定一個粗略的項目需求和一個時間點，而產(chǎn)品經(jīng)理接受這個任務，一方面對項目需求進行進一步的詳細設計并定時向高層反饋項目進展，另一方面對開發(fā)團隊提出詳細的產(chǎn)品需求。開發(fā)團隊接受開發(fā)需求，在項目經(jīng)理的帶領上進行實際的項目開發(fā)。這里有兩個問題需要重點關注：“時間點”和“產(chǎn)品需求的詳細度”?！皶r間點”是由公司高層決定的，他們習慣了這樣的方式，而“產(chǎn)品需求的詳細度”是由產(chǎn)品經(jīng)理控制的。我們知道軟件開發(fā)的幾個步驟應該是“提出需求-->概要設計-->詳細設計-->編碼-->測試-->發(fā)布”，理論上在工程師“編碼”之前，產(chǎn)品人員應該把“詳細設計”的工作做完，“項目需求的詳細度”應該非常高，項目進入編碼階段，需求就不應該再改動了。但稍有經(jīng)驗的工程師都知識，產(chǎn)品人員不會也不可能會在項目進入編碼階段前完成詳細的設計，他們總是會不停地進行修改。理想情況下，項目經(jīng)理應該會很懂“軟件工程”，為了保證項目進度，他們會對開發(fā)團隊做出一些保護，阻止產(chǎn)品人員在項目開發(fā)過程中修改需求，就算無法完全阻止，至少會做一些措施，提高產(chǎn)品人員修改需求的門檻——比如說，修改可以，但時間點要重新預估。也就是說，“時間點”確定的前提下，“需求的修改”就不能那么隨意，必須有一套合理的游戲規(guī)則平衡“高層管理”、“產(chǎn)品經(jīng)理”、“項目經(jīng)理”、“開發(fā)團隊”各種角色的責任和權利。但實際情況是，產(chǎn)品經(jīng)理權利過大，項目經(jīng)理往往無法保護開發(fā)團隊，更有些甚至不懂去保護開發(fā)團隊，只會“拿鞭子抽”，成了一個監(jiān)工的角色。開發(fā)團隊于是成了埋頭干活，卻幾乎完全沒有話語權的編碼機器人。時間點確定了，需求不停地改，監(jiān)工不停地催，代碼在一次次修改中越變越腐壞，只好不停地加班，期望通過延長工作時間這種原始的辦法來按時完成開發(fā)任務。結果就如大家所熟悉的那樣：開發(fā)人員抱怨產(chǎn)品人員需求老在變，代碼越變越糟糕滿是bug，產(chǎn)品人員抱怨開發(fā)團隊不能按時交付高質量沒bug的產(chǎn)品，開發(fā)團隊加班嚴重，人員流失嚴重，項目組成員不停地更替，交接工作不可能完美，新人且對歷史遺留代碼頭疼不已，項目開發(fā)前快后慢，維護成本越來越大直到某一天，某人實在受不了了，大喊一聲“重構吧”。。。
上面提到的畫面大家一定很熟悉吧，沒錯，這是“產(chǎn)品導向”的公司的基本行態(tài)。產(chǎn)品經(jīng)理權利過大，產(chǎn)品的原型完全是由產(chǎn)品人員和公司高層決定的，開發(fā)團隊完全是棋子，編碼機器人，開發(fā)壓力大，加班嚴重，生產(chǎn)的代碼質量差，很難在預計時間點交付高質量產(chǎn)品。所謂“兵熊熊一個，將熊熊一窩”，在這種體制下，整個產(chǎn)品線完全圍繞產(chǎn)品經(jīng)理轉，再牛B的工程師也扛不住不靠譜的產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理是如此之重要，以至于一個不靠譜的產(chǎn)品經(jīng)理很可能會毀了一整支團隊?！爱a(chǎn)品驅動”的體制大體上分產(chǎn)生兩類問題：1）產(chǎn)品創(chuàng)意來自非技術人員 2）軟件開發(fā)管理混亂。 對于第2點，通過推行好的軟件開發(fā)方法（比如scrum）可以解決，當然，推行起來會有它的困難，但這不是這篇博客想要探討的，后面有時間會再另寫一博文探討。對于第1點，完全無解，“產(chǎn)品驅動”的機制先天就無法解決這個問題。“創(chuàng)意”應該來自兩個層面，一個是脫離技術的純應用層面的創(chuàng)意，這是產(chǎn)品人員的長處，他們的靈感主要來自于用戶需求，發(fā)掘用戶所需，提供用戶所想但IT圈里還沒有做的產(chǎn)品，比如團購、sns都是;另一個層面應該來自技術層面的創(chuàng)意，比如說技術上出現(xiàn)了什么新的技術，這種技術如何合理應用，發(fā)揮一些創(chuàng)意，可以用它來做成什么的產(chǎn)品，它的靈感來自于各種技術api的創(chuàng)意用法，比如gmail的ajax，比如google地圖，這些都不可能由非技術人員去創(chuàng)意出來，他們壓根就不知道這能否實現(xiàn)，對這種類型的“創(chuàng)意”他們并不敏感。雖然任何產(chǎn)品最終最會落實到具體的技術實現(xiàn)上，但非技術人員對技術層面不了解，這是他們的短板，哪怕他們再也創(chuàng)造力，技術上的創(chuàng)意他們無能為力。
“技術驅動”型的運作模式非常罕見，google應該算是。如果在產(chǎn)品驅動型的公司，工程師們想到什么創(chuàng)意其實很難去實施，很難去啟動一個項目——大多數(shù)公司面對工程師的創(chuàng)意會去問“有其他公司在應用這個技術嗎？”，如果沒有，那么很難得到高層的支持去做。所以你可以看到國內大多數(shù)公司只會去抄一個國外的創(chuàng)意項目，迅速將其山寨化，拼的是山寨的速度，而不是創(chuàng)意。在技術驅動型的公司里，可以很好地發(fā)揮工程師們的創(chuàng)意，啟動一個項目的并不是公司高層，而是工程師自己，工程師自己有什么創(chuàng)意就可以動手去跑這個項目，項目沒有一個明確的上線的時間點，甚至不一定被要求要上線。項目開發(fā)到相對完善的程度了，可以請產(chǎn)品經(jīng)理參與進來，如果產(chǎn)品經(jīng)理對這個項目感興趣，可以從產(chǎn)品設計角度提出修改意見，并幫助工程師將項目運作起來向外發(fā)布。產(chǎn)品經(jīng)理的角色權力不會過大，他們在他們擅長的領域“產(chǎn)品設計”領域里可以發(fā)揮所長，但不會對“項目開發(fā)過程”有權力——他們并不在行這個，這方面他們沒權力反而更好，對技術層面負責的完全是工程師。產(chǎn)品經(jīng)理的KPI考核會有別的機制，并不像“產(chǎn)品驅動”型那樣，背負過重的壓力，導致有過大的權力，導致在他們不擅長的“管理”領域不得不過分關心。在“技術驅動”型的公司里，工程師有著非常高的權力，有著自由得多的時間，做著自己感興趣的事，他們的KPI考核機制也和“產(chǎn)品驅動型”公司完全不同。為什么google是工程師夢想的天堂？不是沒有原因的。
“技術驅動”型的公司竟然這么好，那么為什么這么多的公司都不用這種模式？因為他的成本很高，產(chǎn)品的原型完全是工程師去做的，也許他最終只能成為一個“技術成功”的項目，而無法帶來“商業(yè)價值”，因為這不是工程師們的興趣和長處所在。也就是說，也許100個項目里，最后有一個項目獲得了商業(yè)上的成功，其他99個也許掙不到錢，甚至有可能夭折。而且技術驅動的公司，對工程師的要求很高，不會讓一些能力很弱的工程師來公司混日子，公司相對很自由但相應的，進入門檻會很高——google和facebook的招聘條件大家都有所耳聞吧？門檻高意味著開出的薪水也會很高，而這些工程師開發(fā)的項目還有可能并不掙錢！“技術驅動”型的公司，必須有玩得起的資本，并不是什么公司都玩得起和有那個膽量去玩的。
聯(lián)系客服
