按，前天参与了一次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、以合理的方式展现团队的各阶段工作成果，一则收集需求反馈，二则收获公司及客户的认可提升团队士气；
综上，主体的思路是：确定原则，明确战略，设定标准，统一思想，持续沟通，修炼技巧，展现成果。此次主要是对设定标准和沟通技巧分享两个例子，其它的环节有机会再谈谈。
