按，前天參與了一次Podcast的錄音座談節目，其中聊到如何推進團隊的執行力，略有心得分享，整理以記之：
1、產品經理首要確定的工作原則：戰略決策產品，產品驅動開發；
2、結合實際情況，設計可執行的工作流程，明確各職能環節的工作成果輸出（原型/界面設計，需求文檔/思維導圖或流程圖）；
P線：產品管理，產品設計，界面設計，交互設計，及其它
T線：項目管理，技術架構，技術Leader，開發人員（前端，頁面，後端，服務端，數據端，運維等）
3、盡可能的明確可度量的工作成果標準，由P線經理提供需求要點綱要，表明要做到什麼，不用做到什麼，T線經理根據需求與相關人員共同設定工作目標和標準；
虛擬示例：某功能模塊，進行V2版本優化，2週為一次迭代周期，共2個週期
需求要點是：功能性流程與V1版本相比無增加點，重點是實踐前後端分離的開發模式重構該功能模塊的實現代碼，交付給用戶更有驚艷效果的操作流程，強化每個操作環節的引導或提示體驗
第一個週期的關鍵是：需求明確，各職能角色的充分交流
第1週目標是：P線成員完成產品細節需求策劃，T線成員相關技術架構的預研
第2週目標是：需求策劃完成交付，二個關鍵展示頁面的技術功能性開發完成
第二個週期的關鍵是：保證質量，在進度內完成既定目標
第1週目標是：所有技術功能性開發完成，關鍵業務流程可以走通無誤
第2週目標是：所有需求策劃細節開發完成，重點是用驗設計、界面設計無損實現
此產品開發組團隊共4人：責任產品經理1人，技術骨幹兼項目經理1人，相關技術開發人員2人；周邊支撐資源：界面設計、、交互設計、頁面製作，約6人/天
4、抓住一切機會點，在團隊內告知及說明工作原則和流程標準的重要性，特別關注對老闆的告知；
5、對於執行過程中的各職能環節協調問題，保持高度的敏感，最及時的處理此類問題；
6、對不同職能角色的溝通技巧，產品經理本身需要在思考上有相當的彈性來去適應不同的角色思維模式，老闆，技術Leader、成員，界面設計、用戶體驗、前端開發、客戶等
在和P線角色溝通時，要適當的講解技術實現相關原理，能做為什麼，不能做更要為什麼，並在滿足需求本質的前提基礎上，提出妥協或更合理的解決方案；
在和T線角色溝通時，盡可能說明該功能需求的來源，用戶反饋次數和態度，分析其合理性，以具體案例和模擬用例來推演出合理性；
虛擬實例：項目管理=》項目成員管理與授權功能=》產品提出需要可以增加部門為項目成員
已有功能流程：進入項目成員管理，可選擇部門下拉框=》員工下拉框，點加入成員
產品的思路：選定部門後，即可直接將該部門加入項目成員，讓項目經理操作減少，當部門員工離職後也無需再取消該員項目成員身份
技術的思路：該需求技術可行，需要涉及到的功能點有，項目成員管理界面可增加部門，部門綁定的權限角色被授權，3個其它功能模塊中類似的人員選擇區做同樣的處理，約2-4人/日工作量。
我的分析：能理解該需求思路，選部門的出發點在於減少項目經理操作次數，這個能認同，但一個項目經理在此項目裡選了部門為成員以後，如果該部門有人員增加而又正好不是參與該項目的，豈不是還要再回來把這個項目的成員裡去掉這個部門，再加上原有的員工；其二，這個漏洞雖然很小，用戶實際操作中碰到的機率很低，但既然我們提供出這個功能，就一定會有用戶使用到出現問題，那豈不是違反了我們做這個修改的目的：改善用戶操作，獲取用戶認可。須知，對於用戶而言，我們做的更好是應該的，大部分用戶未必感知到，感知到的用戶也未必會傳播；但如果我們做了一個會出某問題的產品，大部分沒出現該問題的還是沉默狀態，出現問題的就一定會進行傳播反饋（抱怨不爽投訴。。。），影響到本來沒此問題的用戶群體了。
結論：需求決策的原則：產品環節對沒有問題的解決方案進行判斷或優先級選擇時，可以按關注用戶機率的多少來進行，但如果有問題的方案，就不能按用戶關注機率來判斷，哪怕只有百分之1的用戶有可能出現問題，就是致命。該需求應該尋求其它解決方案。
我的方案：項目經理選擇部門後，人員下拉框裡第一項是“加入該部門所有員工”，產品認為可以滿足需求的出發點，技術認為需要投入的工作量約0.5人/日，達成共識；
7、以合理的方式展現團隊的各階段工作成果，一則收集需求反饋，二則收穫公司及客戶的認可提升團隊士氣；
綜上，主體的思路是：確定原則，明確戰略，設定標準，統一思想，持續溝通，修煉技巧，展現成果。此次主要是對設定標準和溝通技巧分享兩個例子，其它的環節有機會再談談。
來源：http://user.qzone.qq.com/312950/blog/1280751839
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy