實(shí)戰(zhàn)：產(chǎn)品經(jīng)理常見問題解決方案

問：需求文檔都是以郵件模式出現(xiàn)，無歸檔備份，后期追溯難，怎么辦？答：拿到項(xiàng)目后，就算沒時(shí)間整理詳細(xì)需求，一定要整理需求的框架或者大綱，如下圖。不管是用word還是工具(禪道、confluence)，然后不分樣式，全部貼到對(duì)應(yīng)的目錄下，以備后期追溯。問：不能直接接觸客戶，需求反復(fù)，無法把控怎么辦？答：在互聯(lián)網(wǎng)項(xiàng)目中，這已經(jīng)是普遍存在的現(xiàn)象，很多公司已經(jīng)有了預(yù)先與用戶商量好管理方案，但是老板項(xiàng)目怎么辦？老板的突發(fā)靈感，往往是不容置疑的，而且是優(yōu)先級(jí)極高的。為此只能在有限的資源里，延緩之前的進(jìn)度安排。但是這樣的結(jié)果會(huì)導(dǎo)致，項(xiàng)目開發(fā)時(shí)間極長。為此跟很多大牛聊過以后，發(fā)現(xiàn)，項(xiàng)目的版本控制尤為重要，采用迭代式的方式管理，方可避免該類問題發(fā)生。一個(gè)版本限定最高優(yōu)先級(jí)，高優(yōu)先級(jí)，中等優(yōu)先級(jí)，低優(yōu)先級(jí)，并評(píng)定時(shí)間。如果突然有最高優(yōu)先級(jí)的任務(wù)，可以把低優(yōu)先級(jí)的放到下一個(gè)迭代版本。以此類推。問：不懂技術(shù)，被開發(fā)牽著鼻子走，怎么辦？答：開發(fā)經(jīng)常會(huì)說這個(gè)任務(wù)可能需求多點(diǎn)時(shí)間，不一定按時(shí)完成，你說的那種方式做不到，由于我們是QA轉(zhuǎn)產(chǎn)品經(jīng)理也是項(xiàng)目經(jīng)理的，經(jīng)常會(huì)被開發(fā)的闊論虎的一愣一愣的。無奈下只能妥協(xié)，因?yàn)闋幷摚粫?huì)讓開發(fā)覺得我們不信任他的技術(shù)，反而會(huì)產(chǎn)生逆反情緒。這在項(xiàng)目中是不可取的。遇到這樣的問題，就要應(yīng)用職權(quán)，組織會(huì)議了。邀請(qǐng)開發(fā)總監(jiān)或者技術(shù)大牛參加，一輪探討下來，往往會(huì)有意想不到的效果。開發(fā)不但更有斗志反而更完美的把你想要的東西呈現(xiàn)出來。其實(shí)根本不用擔(dān)心，整個(gè)產(chǎn)品流程，從前期的市場調(diào)研，競品分析，需求評(píng)審，項(xiàng)目提案，到中間的產(chǎn)品實(shí)體化，設(shè)計(jì)，交互體驗(yàn)考量，公司內(nèi)資源協(xié)調(diào)，公司外資源需求整合，項(xiàng)目考量，落實(shí)規(guī)劃到后期的運(yùn)營規(guī)劃，市場推廣，程序開發(fā)，用戶反饋，產(chǎn)品迭代，需求評(píng)審等等一系列的工作內(nèi)容中。你們覺得涉及到真正需要能跟你勾通這里代碼如何處理？這個(gè)存儲(chǔ)流程如何涉及，這個(gè)算法如何調(diào)整的環(huán)節(jié)有多少？占他們多少的時(shí)間和工作強(qiáng)度？沒錯(cuò)，產(chǎn)品經(jīng)理需要通才，懂得越多越好，但絕對(duì)不是需要他們?cè)诩夹g(shù)方面懂的越多越好，而是知識(shí)擴(kuò)展，行業(yè)深度的方面通才。程序員能夠和產(chǎn)品經(jīng)理在工作中接觸的無非是產(chǎn)品落實(shí)開發(fā)的那一小部分，就因?yàn)樗麄儾荒軌蚶斫庖粋€(gè)看起來簡單的需求為何需要較大的工時(shí)，于是就質(zhì)疑這個(gè)行業(yè)的普遍勝任力，這有點(diǎn)夸張了吧？問：開發(fā)、測試的時(shí)間沒有評(píng)審，到交付時(shí)間，發(fā)現(xiàn)一直無法交付，怎么辦？答：項(xiàng)目執(zhí)行前，一定要有時(shí)間的評(píng)審會(huì)議，并在這個(gè)結(jié)果下預(yù)留多點(diǎn)時(shí)間，保證自己許諾的時(shí)間下，可以有滿意的交付。需求不清晰，當(dāng)開發(fā)人員問PM需求的時(shí)候，發(fā)現(xiàn)PM也弄不清楚，這樣的問題是一定要杜絕也完全可以杜絕的，如果PM自己都不清楚需求，的考慮這樣的工作是否適合自己了。干預(yù)純技術(shù)問題，例如：這個(gè)code應(yīng)該這么寫。避免之道:對(duì)于純技術(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要對(duì)進(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í)，再完美的文檔也無法代替口頭上的直接交流。但頻繁的口(頭)交(流)可能會(huì)打斷工程師的思路，延緩進(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后