小白叨一叨：隨著互聯(lián)網(wǎng)的不斷發(fā)展，互聯(lián)網(wǎng)產(chǎn)品的日新月異，產(chǎn)品經(jīng)理也必須從老一套的思維中走出來，才能在現(xiàn)代的競爭中脫穎而出。在從舊到新的演化中，將會遇到哪些挑戰(zhàn)呢？來看看 Eric Ries 是怎么說的。
當(dāng)你處于一個(gè)傳統(tǒng)的“瀑布模式”工作流程中時(shí)，不論你在里面扮演的是什么角色，都會讓你有種無力感。特別是對那些在正將新產(chǎn)品推向新市場、大量工作的創(chuàng)業(yè)公司中工作的“產(chǎn)品經(jīng)理”來說，這種感覺是更強(qiáng)烈的。最近我見到了一個(gè)真正意義上的負(fù)責(zé)新產(chǎn)品的產(chǎn)品經(jīng)理，他和他的開發(fā)團(tuán)隊(duì)告訴我的故事讓我覺得無奈。很明顯，這個(gè)產(chǎn)品經(jīng)理努力想從團(tuán)隊(duì)中其他人那里獲得結(jié)果。這些聰明人保持著前進(jìn)的一致性。那么，為什么他們還會有那么多的困難呢？
讓我們從這個(gè)產(chǎn)品經(jīng)理做什么開始說起吧。按照常理來說，他是定義產(chǎn)品做什么的那個(gè)人。他編寫詳細(xì)的產(chǎn)品需求文檔，這些文檔詳細(xì)地說明了團(tuán)隊(duì)在下一個(gè)迭代中應(yīng)該構(gòu)建什么功能。將這些需求交給一個(gè)設(shè)計(jì)人員，讓他構(gòu)建所有主要功能點(diǎn)的排布和模型。然后把設(shè)計(jì)圖交給一個(gè)具有各種專業(yè)開發(fā)人員的團(tuán)隊(duì)。大家各自負(fù)責(zé)自己的部分（UI，中間件，后端），并進(jìn)行對應(yīng)的編碼。最后，QA團(tuán)隊(duì)基于規(guī)格說明構(gòu)建一個(gè)測試計(jì)劃，通過測試功能來評估它們是否能正常運(yùn)行。
這個(gè)系統(tǒng)本身是適合產(chǎn)品經(jīng)理組織的一般流程。盡管程序員不構(gòu)建下一個(gè)主要功能，但他將忙于編寫程序。如此一來，當(dāng)他們在開始下一個(gè)迭代之前時(shí)，就不會有任何的閑暇時(shí)間。如果程序員空閑，對產(chǎn)品經(jīng)理來說可不是件好事，因?yàn)樗揪蛻?yīng)該忙于構(gòu)建產(chǎn)品。否則，公司就是在浪費(fèi)大量的金錢。
當(dāng)我見到這個(gè)團(tuán)隊(duì)時(shí)，團(tuán)隊(duì)成員之間針鋒相對的局面已經(jīng)形成了。最后構(gòu)建出來的幾個(gè)功能跟最初定義的大有不同，需要花相當(dāng)長時(shí)間才能正常運(yùn)行。程序員一直詢問很多有關(guān)他們設(shè)計(jì)和方向上的問題。所以團(tuán)隊(duì)正在并已經(jīng)花越來越多的時(shí)間在討論需求和設(shè)計(jì)階段，試圖讓團(tuán)隊(duì)認(rèn)同正在構(gòu)建的東西。然而，由于某種原因，盡管團(tuán)隊(duì)增加了認(rèn)同感，最終的產(chǎn)品已經(jīng)看起來不像最初定義的那么一回事了。VP工程花了所有時(shí)間試圖確保程序員理解并實(shí)現(xiàn)規(guī)格要求了，每個(gè)迭代花費(fèi)的時(shí)間比之前的還長，各種沮喪負(fù)面的情緒不斷增加。
沒過多久發(fā)現(xiàn)產(chǎn)品經(jīng)理正被責(zé)令對每個(gè)需求說明書寫5次。第一次，他寫的工整清晰。接著他和設(shè)計(jì)人員構(gòu)建出設(shè)計(jì)規(guī)格，和QA構(gòu)建出測試計(jì)劃。當(dāng)開發(fā)人員拿到需求后，他們經(jīng)常和PM談判將構(gòu)建什么。他們交流了許多封的郵件，也因?yàn)檫@樣，產(chǎn)品經(jīng)理時(shí)常被打斷叫去闡明需求的精確含義。第四次，需求說明僅存在于郵件中，這些郵件會導(dǎo)致表達(dá)偏差。當(dāng)QA拿到功能的時(shí)候，他們的測試計(jì)劃已經(jīng)嚴(yán)重過時(shí)。所以，產(chǎn)品經(jīng)理上不得不使用該軟件、著手更新原型、幫助創(chuàng)建一個(gè)新的測試計(jì)劃。自然地，產(chǎn)出偏離得這么嚴(yán)重，以至于他必須重寫當(dāng)前正在進(jìn)行的需求（鋪墊下一個(gè)主要功能），并把它們一并考慮在內(nèi)。
諷刺的是，設(shè)計(jì)這個(gè)系統(tǒng)是保證每個(gè)職能都能得到100%利用，所以包括產(chǎn)品經(jīng)理在內(nèi)也沒人偷懶。但是隨著迭代次數(shù)的增加，產(chǎn)品經(jīng)理花越來越多的時(shí)間來回答問題。這些打岔的事情是這么的糟糕，以至于他得在凌晨3點(diǎn)起來寫他的新原型，這只是為了確保工作流程的完整。
這到底出了什么問題？每個(gè)人都全力以赴、投入110%的精力工作。但是團(tuán)隊(duì)卻越來越落后。
下面是我給這個(gè)團(tuán)隊(duì)的一些調(diào)整的建議：
首先，在跨職能團(tuán)隊(duì)中工作。每個(gè)團(tuán)隊(duì)有一名各職能代表。首先，我們嘗試一名產(chǎn)品經(jīng)理、一名設(shè)計(jì)人員、一名或兩名程序員、和一名QA。這個(gè)團(tuán)隊(duì)擁有一個(gè)完整的點(diǎn)對點(diǎn)特征。
其次，關(guān)注迭代速度而不是利用每個(gè)職能。如果不能幫助當(dāng)前迭代成功，就讓他們偷懶去吧。我一直驚訝究竟有多少人尚未開發(fā)他們的潛力。他們不想要空閑。通過讓他們關(guān)注自己團(tuán)隊(duì)的成功，你就可以授權(quán)他們做任何可讓團(tuán)隊(duì)成功的事情。那是否意味著設(shè)計(jì)組人員可以加入QA幫助測試認(rèn)證發(fā)布的版本呢？讓我們拭目以待吧。
最后，將需求過程的推動轉(zhuǎn)化為拉動。以一頁的規(guī)格開始，不要再多。接著，讓團(tuán)隊(duì)在他們需要闡明的任何時(shí)候詢問產(chǎn)品經(jīng)理問題。作為交換條件，團(tuán)隊(duì)成員統(tǒng)一展示每塊工作情況給產(chǎn)品經(jīng)理看，并獲得他的許可。他們發(fā)現(xiàn)差異點(diǎn)的速度將會快很多，并及時(shí)進(jìn)行解決。而且，團(tuán)隊(duì)將會越來越擅長解讀只需書寫一次的簡明規(guī)格說明。（最后，他們可能會一起取消規(guī)格說明書。）會有更多的方法讓這個(gè)團(tuán)隊(duì)來消除工作方式上的浪費(fèi)，因此達(dá)到迭代更快的目的。最終，我希望讓他們進(jìn)行全面的敏捷開發(fā)過程：帶有測試驅(qū)動開發(fā)、日常例會、沖刺、結(jié)對編程，等等。但是首先我覺得我們需要將產(chǎn)品經(jīng)理從老一套的“瀑布模式”的折磨中拯救出來。一旦團(tuán)隊(duì)中不同成員能再次互相信任，我們就有了啟動一個(gè)真正連續(xù)改進(jìn)反饋回路所需要的基礎(chǔ)。
本文由人人都是產(chǎn)品經(jīng)理@小白翻譯，轉(zhuǎn)載請注明出處并保留本文鏈接。
英文原文：http://www.startuplessonslearned.com/2008/10/product-managers-lament.html
-----人人譯客------
