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