公司按產(chǎn)品劃分團(tuán)隊(duì)初期，大家還是沒有意識產(chǎn)品經(jīng)理到底需要做什么。只是在職責(zé)上賦予全權(quán)負(fù)責(zé)產(chǎn)品項(xiàng)目的權(quán)力，能不能勝任還是個(gè)迷？跟個(gè)人的工作經(jīng)驗(yàn)有很大的關(guān)系，雖然之前我司是QA把控進(jìn)度，保證質(zhì)量，驅(qū)動開發(fā)，屬于在一定程度上有些許的管理項(xiàng)目的經(jīng)驗(yàn)，但是遇到問題都是測試總監(jiān)和開發(fā)總監(jiān)出面解決，自己在之前的項(xiàng)目中并沒有全權(quán)把控的能力與機(jī)會。導(dǎo)致初任職時(shí)，各種問題層出不窮。

問：需求文檔都是以郵件模式出現(xiàn)，無歸檔備份，后期追溯難，怎么辦？

答：拿到項(xiàng)目后，就算沒時(shí)間整理詳細(xì)需求，一定要整理需求的框架或者大綱，如下圖。不管是用word還是工具（禪道、confluence），然后不分樣式，全部貼到對應(yīng)的目錄下，以備后期追溯。

問：不能直接接觸客戶，需求反復(fù)，無法把控怎么辦？

答：在互聯(lián)網(wǎng)項(xiàng)目中，這已經(jīng)是普遍存在的現(xiàn)象，很多公司已經(jīng)有了預(yù)先與用戶商量好管理方案，但是老板項(xiàng)目怎么辦？老板的突發(fā)靈感，往往是不容置疑的，而且是優(yōu)先級極高的。為此只能在有限的資源里，延緩之前的進(jìn)度安排。但是這樣的結(jié)果會導(dǎo)致，項(xiàng)目開發(fā)時(shí)間極長。為此跟很多大牛聊過以后，發(fā)現(xiàn)，項(xiàng)目的版本控制尤為重要，采用迭代式的方式管理，方可避免該類問題發(fā)生。一個(gè)版本限定最高優(yōu)先級，高優(yōu)先級，中等優(yōu)先級，低優(yōu)先級，并評定時(shí)間。如果突然有最高優(yōu)先級的任務(wù)，可以把低優(yōu)先級的放到下一個(gè)迭代版本。以此類推。

問：不懂技術(shù)，被開發(fā)牽著鼻子走，怎么辦？

答：開發(fā)經(jīng)常會說這個(gè)任務(wù)可能需求多點(diǎn)時(shí)間，不一定按時(shí)完成，你說的那種方式做不到，由于我們是QA轉(zhuǎn)產(chǎn)品經(jīng)理也是項(xiàng)目經(jīng)理的，經(jīng)常會被開發(fā)的闊論虎的一愣一愣的。無奈下只能妥協(xié)，因?yàn)闋幷摚粫岄_發(fā)覺得我們不信任他的技術(shù)，反而會產(chǎn)生逆反情緒。這在項(xiàng)目中是不可取的。遇到這樣的問題，就要應(yīng)用職權(quán)，組織會議了。邀請開發(fā)總監(jiān)或者技術(shù)大牛參加，一輪探討下來，往往會有意想不到的效果。開發(fā)不但更有斗志反而更完美的把你想要的東西呈現(xiàn)出來。

其實(shí)根本不用擔(dān)心，整個(gè)產(chǎn)品流程，從前期的市場調(diào)研，競品分析，需求評審，項(xiàng)目提案，到中間的產(chǎn)品實(shí)體化，設(shè)計(jì)，交互體驗(yàn)考量，公司內(nèi)資源協(xié)調(diào)，公司外資源需求整合，項(xiàng)目考量，落實(shí)規(guī)劃到后期的運(yùn)營規(guī)劃，市場推廣，程序開發(fā)，用戶反饋，產(chǎn)品迭代，需求評審等等一系列的工作內(nèi)容中。你們覺得涉及到真正需要能跟你勾通這里代碼如何處理？這個(gè)存儲流程如何涉及，這個(gè)算法如何調(diào)整的環(huán)節(jié)有多少？占他們多少的時(shí)間和工作強(qiáng)度？

沒錯(cuò)，產(chǎn)品經(jīng)理需要通才，懂得越多越好，但絕對不是需要他們在技術(shù)方面懂的越多越好，而是知識擴(kuò)展，行業(yè)深度的方面通才。程序員能夠和產(chǎn)品經(jīng)理在工作中接觸的無非是產(chǎn)品落實(shí)開發(fā)的那一小部分，就因?yàn)樗麄儾荒軌蚶斫庖粋€(gè)看起來簡單的需求為何需要較大的工時(shí)，于是就質(zhì)疑這個(gè)行業(yè)的普遍勝任力，這有點(diǎn)夸張了吧？

問：開發(fā)、測試的時(shí)間沒有評審，到交付時(shí)間，發(fā)現(xiàn)一直無法交付，怎么辦？

答：項(xiàng)目執(zhí)行前，一定要有時(shí)間的評審會議，并在這個(gè)結(jié)果下預(yù)留多點(diǎn)時(shí)間，保證自己許諾的時(shí)間下，可以有滿意的交付。

需求不清晰，當(dāng)開發(fā)人員問PM需求的時(shí)候，發(fā)現(xiàn)PM也弄不清楚，這樣的問題是一定要杜絕也完全可以杜絕的，如果PM自己都不清楚需求，的考慮這樣的工作是否適合自己了。

干預(yù)純技術(shù)問題，例如：這個(gè)code應(yīng)該這么寫。避免之道:對于純技術(shù)的問題不要干預(yù)，如果他的技術(shù)實(shí)現(xiàn)真的有問題，自有相關(guān)的人去負(fù)責(zé)，產(chǎn)品只需關(guān)注他最終是否實(shí)現(xiàn)了預(yù)期的功能。

交付的方案不確定，開發(fā)人員討厭“其實(shí)這樣也可以”，“要不就這樣吧”的言論，他們需要的是一個(gè)明確的方案。在多種方案猶豫不決需要思考的時(shí)候，PM最好只是將這樣的猶豫不決體現(xiàn)在自己的思考中。除非工程師無力實(shí)現(xiàn)你的第一種方案時(shí)，再將備選方說出來。

沒有必要的預(yù)留時(shí)間,”這個(gè)我們修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是僅僅是修改。coder真的不是神，增加的功能是需要測試的。pm給自己留時(shí)間同時(shí)，可憐可憐攻城濕，留點(diǎn)時(shí)間思考吧?！边@是一位工程師的原話。Pm要對進(jìn)度負(fù)責(zé)，壓力很大，但是預(yù)留時(shí)間是一定要的。

不能完全避免但短期內(nèi)可以改善的：

需求變更，這是回答中出現(xiàn)平率最高的一個(gè)詞匯。但是，要讓開發(fā)人員失望的是，因?yàn)榉N種原因，這個(gè)問題并不能完全避免，PM能做的就是盡量在交付開發(fā)之前將盡可能多的問題都考慮到，使可能發(fā)生改變的需求講到最少;另外一個(gè)就是要杜絕需求的往復(fù)性變更，不要讓從方案A改為方案B之后覺得不行，又改回方案A。

口交次數(shù)太多：要避免口頭交代，顯然不現(xiàn)實(shí)，再完美的文檔也無法代替口頭上的直接交流。但頻繁的口(頭)交(流)可能會打斷工程師的思路，延緩進(jìn)度。PM可以做一是盡量完善你的文檔，第二個(gè)就是盡量在一次口頭交流中集中講完盡可能能多的事情，從而減少次數(shù)。

問：調(diào)研不徹底，開發(fā)測試后，才發(fā)現(xiàn)問題，費(fèi)時(shí)費(fèi)力

答：做一些大家都無經(jīng)驗(yàn)的項(xiàng)目時(shí)，在需求調(diào)研階段不能想的全面，導(dǎo)致開發(fā)做無用功。我記得很清楚的是，我們有個(gè)使用Docusign來跟客戶簽約的功能。需求階段，我們只考慮技術(shù)實(shí)現(xiàn)，沒有考慮成本問題。開發(fā)做完測試后才發(fā)現(xiàn)，這個(gè)功能是要按簽名的合約進(jìn)行收費(fèi)的，告訴boss后，直接被砍掉了。當(dāng)時(shí)我們花了2個(gè)周期的工作成果，就這樣無端浪費(fèi)了，想想都覺得心里不舒服。之后，我們在做需求的時(shí)候，就考慮全面了，成本、風(fēng)險(xiǎn)，資源一定是必填項(xiàng)。

作者：Lisa，某外匯外企公司產(chǎn)品經(jīng)理。3年測試經(jīng)驗(yàn)，2年產(chǎn)品管理經(jīng)驗(yàn)。

來源：http://blog.sina.com.cn/s/articlelist_2477511650_0_1.html