產(chǎn)品經(jīng)理如何推進(jìn)團(tuán)隊(duì)執(zhí)行力

按，前天參與了一次Podcast的錄音座談節(jié)目，其中聊到如何推進(jìn)團(tuán)隊(duì)的執(zhí)行力，略有心得分享，整理以記之：

1、產(chǎn)品經(jīng)理首要確定的工作原則：戰(zhàn)略決策產(chǎn)品，產(chǎn)品驅(qū)動(dòng)開發(fā)；

2、結(jié)合實(shí)際情況，設(shè)計(jì)可執(zhí)行的工作流程，明確各職能環(huán)節(jié)的工作成果輸出（原型/界面設(shè)計(jì)，需求文檔/思維導(dǎo)圖或流程圖）；

P線：產(chǎn)品管理，產(chǎn)品設(shè)計(jì)，界面設(shè)計(jì)，交互設(shè)計(jì)，及其它
T線：項(xiàng)目管理，技術(shù)架構(gòu)，技術(shù)Leader，開發(fā)人員（前端，頁面，后端，服務(wù)端，數(shù)據(jù)端，運(yùn)維等）

3、盡可能的明確可度量的工作成果標(biāo)準(zhǔn)，由P線經(jīng)理提供需求要點(diǎn)綱要，表明要做到什么，不用做到什么，T線經(jīng)理根據(jù)需求與相關(guān)人員共同設(shè)定工作目標(biāo)和標(biāo)準(zhǔn)；

虛擬示例：某功能模塊，進(jìn)行V2版本優(yōu)化，2周為一次迭代周期，共2個(gè)周期

需求要點(diǎn)是：功能性流程與V1版本相比無增加點(diǎn)，重點(diǎn)是實(shí)踐前后端分離的開發(fā)模式重構(gòu)該功能模塊的實(shí)現(xiàn)代碼，交付給用戶更有驚艷效果的操作流程，強(qiáng)化每個(gè)操作環(huán)節(jié)的引導(dǎo)或提示體驗(yàn)

第一個(gè)周期的關(guān)鍵是：需求明確，各職能角色的充分交流

第1周目標(biāo)是：P線成員完成產(chǎn)品細(xì)節(jié)需求策劃，T線成員相關(guān)技術(shù)架構(gòu)的預(yù)研
第2周目標(biāo)是：需求策劃完成交付，二個(gè)關(guān)鍵展示頁面的技術(shù)功能性開發(fā)完成

第二個(gè)周期的關(guān)鍵是：保證質(zhì)量，在進(jìn)度內(nèi)完成既定目標(biāo)

第1周目標(biāo)是：所有技術(shù)功能性開發(fā)完成，關(guān)鍵業(yè)務(wù)流程可以走通無誤

第2周目標(biāo)是：所有需求策劃細(xì)節(jié)開發(fā)完成，重點(diǎn)是用驗(yàn)設(shè)計(jì)、界面設(shè)計(jì)無損實(shí)現(xiàn)

此產(chǎn)品開發(fā)組團(tuán)隊(duì)共4人：責(zé)任產(chǎn)品經(jīng)理1人，技術(shù)骨干兼項(xiàng)目經(jīng)理1人，相關(guān)技術(shù)開發(fā)人員2人；周邊支撐資源：界面設(shè)計(jì)、、交互設(shè)計(jì)、頁面制作，約6人/天

4、抓住一切機(jī)會(huì)點(diǎn)，在團(tuán)隊(duì)內(nèi)告知及說明工作原則和流程標(biāo)準(zhǔn)的重要性，特別關(guān)注對老板的告知；

5、對于執(zhí)行過程中的各職能環(huán)節(jié)協(xié)調(diào)問題，保持高度的敏感，最及時(shí)的處理此類問題；

6、對不同職能角色的溝通技巧，產(chǎn)品經(jīng)理本身需要在思考上有相當(dāng)?shù)膹椥詠砣ミm應(yīng)不同的角色思維模式，老板，技術(shù)Leader、成員，界面設(shè)計(jì)、用戶體驗(yàn)、前端開發(fā)、客戶等

在和P線角色溝通時(shí)，要適當(dāng)?shù)闹v解技術(shù)實(shí)現(xiàn)相關(guān)原理，能做為什么，不能做更要為什么，并在滿足需求本質(zhì)的前提基礎(chǔ)上，提出妥協(xié)或更合理的解決方案；

在和T線角色溝通時(shí)，盡可能說明該功能需求的來源，用戶反饋次數(shù)和態(tài)度，分析其合理性，以具體案例和模擬用例來推演出合理性；

虛擬實(shí)例：項(xiàng)目管理=》項(xiàng)目成員管理與授權(quán)功能=》產(chǎn)品提出需要可以增加部門為項(xiàng)目成員

已有功能流程：進(jìn)入項(xiàng)目成員管理，可選擇部門下拉框=》員工下拉框，點(diǎn)加入成員

產(chǎn)品的思路：選定部門后，即可直接將該部門加入項(xiàng)目成員，讓項(xiàng)目經(jīng)理操作減少，當(dāng)部門員工離職后也無需再取消該員項(xiàng)目成員身份

技術(shù)的思路：該需求技術(shù)可行，需要涉及到的功能點(diǎn)有，項(xiàng)目成員管理界面可增加部門，部門綁定的權(quán)限角色被授權(quán)，3個(gè)其它功能模塊中類似的人員選擇區(qū)做同樣的處理，約2-4人/日工作量。

我的分析：能理解該需求思路，選部門的出發(fā)點(diǎn)在于減少項(xiàng)目經(jīng)理操作次數(shù)，這個(gè)能認(rèn)同，但一個(gè)項(xiàng)目經(jīng)理在此項(xiàng)目里選了部門為成員以后，如果該部門有人員增加而又正好不是參與該項(xiàng)目的，豈不是還要再回來把這個(gè)項(xiàng)目的成員里去掉這個(gè)部門，再加上原有的員工；其二，這個(gè)漏洞雖然很小，用戶實(shí)際操作中碰到的幾率很低，但既然我們提供出這個(gè)功能，就一定會(huì)有用戶使用到出現(xiàn)問題，那豈不是違反了我們做這個(gè)修改的目的：改善用戶操作，獲取用戶認(rèn)可。須知，對于用戶而言，我們做的更好是應(yīng)該的，大部分用戶未必感知到，感知到的用戶也未必會(huì)傳播；但如果我們做了一個(gè)會(huì)出某問題的產(chǎn)品，大部分沒出現(xiàn)該問題的還是沉默狀態(tài)，出現(xiàn)問題的就一定會(huì)進(jìn)行傳播反饋（抱怨不爽投訴。。。），影響到本來沒此問題的用戶群體了。

結(jié)論：需求決策的原則：產(chǎn)品環(huán)節(jié)對沒有問題的解決方案進(jìn)行判斷或優(yōu)先級(jí)選擇時(shí)，可以按關(guān)注用戶幾率的多少來進(jìn)行，但如果有問題的方案，就不能按用戶關(guān)注幾率來判斷，哪怕只有百分之1的用戶有可能出現(xiàn)問題，就是致命。該需求應(yīng)該尋求其它解決方案。

我的方案：項(xiàng)目經(jīng)理選擇部門后，人員下拉框里第一項(xiàng)是“加入該部門所有員工”，產(chǎn)品認(rèn)為可以滿足需求的出發(fā)點(diǎn)，技術(shù)認(rèn)為需要投入的工作量約0.5人/日，達(dá)成共識(shí)；

7、以合理的方式展現(xiàn)團(tuán)隊(duì)的各階段工作成果，一則收集需求反饋，二則收獲公司及客戶的認(rèn)可提升團(tuán)隊(duì)士氣；

綜上，主體的思路是：確定原則，明確戰(zhàn)略，設(shè)定標(biāo)準(zhǔn)，統(tǒng)一思想，持續(xù)溝通，修煉技巧，展現(xiàn)成果。此次主要是對設(shè)定標(biāo)準(zhǔn)和溝通技巧分享兩個(gè)例子，其它的環(huán)節(jié)有機(jī)會(huì)再談?wù)劇?/P>

 

作者： 佚名 ；資料來源: UCD大社區(qū) ；錄入時(shí)間： 2011年5月15日