|
過節(jié)前看到一篇文章，講產(chǎn)品項(xiàng)目就應(yīng)該由工程師來主導(dǎo)，但國(guó)內(nèi)讓PM去驅(qū)動(dòng)項(xiàng)目，搞得亂七八糟，很惱火，怎么可能做出一款好產(chǎn)品來呢？
很顯然，寫這篇文章的是一位憤怒的工程師，Angry Engineer！我跟他至少有兩點(diǎn)共鳴：
1、國(guó)內(nèi)的PM確實(shí)常常折騰工程師，甚至不乏“把工程師當(dāng)工具對(duì)待”的情況。
2、如果工程師有開闊的產(chǎn)品視野與全面的設(shè)計(jì)素養(yǎng)，知行合一，由工程師來驅(qū)動(dòng)項(xiàng)目是一個(gè)完美的選擇。
可惜由于教育環(huán)境的問題，國(guó)內(nèi)通才太少。一個(gè)優(yōu)秀的工程師，同時(shí)又是一個(gè)優(yōu)秀的PM，鳳毛麟角，只能人任其長(zhǎng)，各自做自己拿手的活兒。這時(shí)候更擅長(zhǎng)需求分析與產(chǎn)品設(shè)計(jì)的PM來驅(qū)動(dòng)項(xiàng)目，也是不得已的選擇。
說來慚愧。需求不靠譜，或是來來回回修改，折騰工程師的事兒我也做過不少，直到最近一年多才算是大有好轉(zhuǎn)。我應(yīng)該懺悔……雖然能做好PM的工程師極少，靠譜的PM其實(shí)也不算多，最后大家都得寫周報(bào)對(duì)不對(duì)？
在產(chǎn)品行業(yè)遠(yuǎn)遠(yuǎn)不夠成熟的現(xiàn)階段，痛苦的來回折騰難以避免。但最起碼，PM應(yīng)該把工程師作為伙伴而不是工具，想法設(shè)法地站到一條戰(zhàn)壕里去，爭(zhēng)取他們的理解。因此拋開難以鑒定的需求的對(duì)錯(cuò)，僅僅從協(xié)作流程的改進(jìn)上，我積累了以下的經(jīng)驗(yàn)。
首先要得到工程師對(duì)整個(gè)項(xiàng)目的認(rèn)同。每個(gè)月都有一場(chǎng)一小時(shí)的部門月會(huì)，對(duì)著PPT，我來講下個(gè)月乃至下個(gè)階段，我們的任務(wù)規(guī)劃是什么，目標(biāo)設(shè)置又是什么，詳細(xì)解釋制定規(guī)劃與目標(biāo)的原因，近景與遠(yuǎn)景分析，為咩做這件事情為咩這樣去設(shè)計(jì)等等。希望工程師能認(rèn)可他即將做的事情是有價(jià)值的，值得為之而努力的。為接下來PM與工程師的溝通做好鋪墊。
月會(huì)上還有一個(gè)環(huán)節(jié)，詳細(xì)分析本月發(fā)生的所有數(shù)據(jù)，尤其是最近發(fā)布的新功能的數(shù)據(jù)。這個(gè)環(huán)節(jié)也是為工程師準(zhǔn)備的，使他們了解自己的工作能產(chǎn)生多少實(shí)際效果。
至于月會(huì)上送出的新功能禮品（以前講過許多次），最開始是為工程師專設(shè)的彩蛋，再后來才將PM與運(yùn)營(yíng)包括了進(jìn)來。我得承認(rèn)自己對(duì)工程師偏心眼，因?yàn)橛行判哪芗?lì)PM與運(yùn)營(yíng)，卻出于溝通深度不足，需要借助更多的手段來激勵(lì)工程師投入項(xiàng)目。
項(xiàng)目任務(wù)分兩種，大版本與小模塊。對(duì)于大版本，在基本框架定下來之后，PM提前向工程師講解，聽取技術(shù)視角對(duì)設(shè)計(jì)方向的建議。整個(gè)設(shè)計(jì)過程中還會(huì)反復(fù)討論三五次，為技術(shù)上的合理性征求意見。小模塊則在策劃案基本敲定之后，與工程師共同確認(rèn)一次，視覺稿出來后再通報(bào)一次。（所以PM與工程師坐得近是很有必要的）
我曾經(jīng)在部門月會(huì)上公開承諾說，任何一個(gè)需求，只要工程師認(rèn)為是不合理的，都可以停下來不做。直到PM能說服工程師為止。如果死活談不下來，才由我和技術(shù)經(jīng)理出面來協(xié)調(diào)。強(qiáng)硬要求服從的情況在我這里基本上沒有，被工程師說服倒是時(shí)有發(fā)生，按工程師提出的意見來改方案。我也常常跟PM講，小分歧你們都聽工程師的，沒有必要堅(jiān)持己見。你讓他爽一點(diǎn)，開發(fā)速度就快一點(diǎn)，大家都獲益。再說你多聽聽技術(shù)伙伴的意見有什么不好呢？幫助你轉(zhuǎn)換思考的角度，共同找到提高開發(fā)效率的方法。
最后方案定下來了，PM說OK，工程師也覺得方向大致沒錯(cuò)，細(xì)節(jié)基本合理；進(jìn)度方面則由工程師進(jìn)行評(píng)估。PM覺得時(shí)間太長(zhǎng)接受不了，再找到我和技術(shù)經(jīng)理一起商量，看是分階段砍需求呢，還是加把力加點(diǎn)班。除了極少數(shù)緊急修復(fù)任務(wù)外，不會(huì)由PM單方面確定開發(fā)時(shí)間安排。包括一系列任務(wù)的優(yōu)先級(jí)安排，也由PM先提草案，工程師根據(jù)開發(fā)情況來調(diào)整順序，再共同確認(rèn)。
在PM提出需求的整個(gè)流程里，始終在進(jìn)行不斷的協(xié)商，保證工程師對(duì)任務(wù)是理解并且接受的，不會(huì)出現(xiàn)抗拒，或者是麻木的心態(tài)。如果遇到突發(fā)性的需求變更，更加會(huì)向工程師反復(fù)解釋，請(qǐng)求諒解，因?yàn)槔速M(fèi)了他們的工作成果而心存歉意。為此而花費(fèi)的時(shí)間對(duì)比更高的開發(fā)效率，穩(wěn)賺不賠。雖說具體協(xié)作時(shí)還有一些不到位的地方，但態(tài)度總歸是好的，基本的效果也是有的。
當(dāng)然，這套流程的實(shí)施得具備兩個(gè)前提。第一是有穩(wěn)定的團(tuán)隊(duì)，如果變成提單協(xié)作，這個(gè)月一起干下個(gè)月分道揚(yáng)鑣，那就不可能實(shí)現(xiàn)共同的項(xiàng)目歸屬感。第二是工程師的個(gè)人素質(zhì)基本靠譜，溝通順暢；尤其是技術(shù)經(jīng)理可以服眾，協(xié)調(diào)好分歧而不護(hù)短。比如說一個(gè)功能能不能做，至少開發(fā)多久，我和PM都搞不掂，主要靠技術(shù)經(jīng)理來做最終判斷；如果出現(xiàn)開發(fā)過程中的失誤，或是不按照約定好的方案進(jìn)行開發(fā)，則由技術(shù)經(jīng)理進(jìn)行處罰。我對(duì)開發(fā)組更多作行政管理，全靠這位技術(shù)核心伙伴來負(fù)責(zé)業(yè)務(wù)管理，他也會(huì)更深入地參與到產(chǎn)品的結(jié)構(gòu)設(shè)計(jì)，任務(wù)規(guī)劃里來。
這樣做，也就撇開了把工程師當(dāng)工具對(duì)待的嫌疑。我覺得把任何同事當(dāng)工具都挺可恥。怎樣才算是伙伴呢？比如交流必要的信息，理解對(duì)方；比如能站在對(duì)方立場(chǎng)去換位思考；比如多一點(diǎn)點(diǎn)鼓勵(lì)與幫助。
換個(gè)角度看，我這邊曾經(jīng)出現(xiàn)過由工程師來提出大致構(gòu)思，PM認(rèn)可并負(fù)責(zé)細(xì)節(jié)設(shè)計(jì)，再由這位工程師來實(shí)現(xiàn)的情況。結(jié)果皆大歡喜。我后來多次在月會(huì)或別的場(chǎng)合征求工程師的創(chuàng)意，換一換視角，引入新鮮的想法與靈感。即便想法不一致，也會(huì)非常溫和地解釋反對(duì)原因，絕不可能一口否決。唯恐工程師們默不出聲悶頭干活——聽不到技術(shù)伙伴的意見是多大的損失啊。
今上有敕云：“科學(xué)發(fā)展觀的核心是和諧發(fā)展�！�
原文：http://firecacada.blog.163.com/blog/static/70743762011117114451722/
本文鏈接：http://www.95time.cn/tech/site/2011/8399.asp 
出處：純銀
責(zé)任編輯：bluehearts
◎進(jìn)入論壇網(wǎng)站綜合、網(wǎng)頁制作版塊參加討論
|
