需求把握
1.PM对需求的理解和拆解能力
面对大需求和复杂需求时还是要在充分理解的基础上进行拆解，拆解的越清楚会让你对整体更清晰，也便于对整个项目开发的把控，具体拆解什么东西，以团购迁移项目涉及到C端的部分为例（如果看团购迁移整体更是一个需求拆解的过程）：
1）用户的操作流程梳理（主要流程）---团购流程的状态机，其中涉及到用户操作和各种状态
2）主流程中涉及到的用户操作界面，拆解出流程中的模块或页面---一共有哪几个页面，页面间的关系
3）补充其他涉及到的模块，以及相互关联—抵用券模块与哪些页面相关，与上下游的关系，是否有涉及页面
4）来源与入口的梳理---哪些入口会进入到团购这套流程
2.分清楚需求的主次，在力所能及的条件下注重优化细节体验
需求完成拆解后接下来就是评估各模块的优先级，抓住主次关系，在保证基本流程的基础上注重细节的体验，细节可优化较多的情况下评估优化收益和开发成本，坚持该坚持的，争取可争取的，放弃不合理的执着
3.产品需求的目的和形式根据需求类型的不同有所差异
团购迁移的需求和之前的其他需求不同，它并不是一个要求创新的需求，更多的是要去溯源老团购系统和逻辑，能够达到无缝切换的要求，同时老团购系统运行这么长时间后已经没有人完全了解其中的设计与逻辑......
面对这样的需求，产品文档的内容是不断在梳理逻辑，确认逻辑和修正逻辑，有很多部分是RD和PM共同协作的结果，这一点上与之前的需求也是差别很大
需求文档也是PM工作价值和专业度的体现，需要根据不同类型的需求来设计文档内容，关注受众对文档的期望和文档的表达：UI层面上的变动设计稿比文字描述更简单明了，系统逻辑层面的需求PM需要抽练成大家能看懂的语言或形式进行表达，后台变动类的需求重点描述哪些接口或字段内容发生了变更...
项目把控
1.项目初期需明确各部分的主要负责人（产品、技术、测试）
因为涉及到的系统和模块太多，更需要在项目初期就明确各部分的主要负责人，这几个负责人需要：
1）需要了解项目的全貌与进度安排，各方明确
2）明确对项目的责任，职责的边界和合作方式
3）较长期的项目需要负责人之间建立良好的沟通与反馈机制，负责人之间也需要磨合
这三点上我们都没有做的很好，很晚才把测试负责人involve进来，没有一个完整的测试方案与计划，测试方面沟通和推动的成本高，而且最后也确实暴露出来了较严重的测试风险；产品负责人和技术负责人对对方职责的期望也不同，很多问题的沟通效率较低...
2.项目计划和时间点越细化越好，保证重要信息各方信息对称
项目计划和时间点在初期就应该定的比较细，并且要把重要的时间节点周知到每个人，让大家达成共识
较长期的项目可能中间会发现时间点变动，要Review项目计划，同时要把重要信息更新到所有人，信息保持对称
3.对项目的把控应该也有主次，关键节点提高关注程度
一个项目不可能面面俱到，所以对项目的关注也应该有主次，把需求拆解清楚后，自然很清楚哪些是关键节点：重点关注关键节点–与多方有交互的、影响关键时间点的，安排专门的人保证关键节点的进度；对于其他部分，给出明确时间点，按时间计划进行，有问题解决问题
以团购迁移为例，订单中心是项目的关键节点，它承上启下与很多系统都有关联，所以它这一块的计划需要更详细也要多次Review，需要理清楚哪些地方依赖它，依赖的时间点来倒推开发计划，回头看订单中心的RD非常不容易，既写代码又把握进度，感谢订单中心RD和后期承担很多项目管理职责的@徐娟
4.项目例会既要注意节奏又要保证效率
3个月的项目，每天都要开例会，从中也积累了一点开会的要诀：
1）不要开长会、不要一直开长会、特别是每天都会开的会
2）开会的时间尽量控制在15分钟内
3）开会的人尽量控制，每个方向各自收集进度后再开会
4）根据需要及时调整开会方式，关键时刻：每天开两次会，早上明确目标，晚上对进度
团队合作
1.PM帮助合作方找到项目中的责任感和成就感
PM在项目中往往被看做是最核心的角色，大家有什么问题都来找PM推动，小需求还好，大需求PM真的想歇菜···
我们的合作方大多是RD、QA和设计，个人认为现在合作方们在业务需求中并没有很好的找到属于自己的责任感和成就感，就会出现一遇到问题就希望PM来解决的情况...诚实的讲，业务高速发展的现状下，我们可能忽视了对人的关注，但是作为团队来看，我们还是应该多和合作方交流，了解对方的期望与诉求，大家一起往前走才会更快
说几点我觉得可以做的：
1）不要忽视技术需求，而是更多的考虑技术需求能否与业务需求结合
2）重视需求的开发质量，重视QA的工作，让QA在前期就involve进来，更多的在项目中承担
3）产品和设计间多组织交流，交流比较好的产品和设计案例，互相提升对产品和设计的感觉
4）PM当好鼓励师，培养自己能驱动大家的能力
2.技术方案由技术负责人和各方RD讨论后确认，PM应该学习、理解技术方案，但不应该为技术方案拍板
在项目过程中有很多技术方案需要确认，当时就跟着RD一直开会，可能最后出来的可选的技术方案，RD希望由PM来定，这一点上我认为是有风险的，PM这时根据RD的描述，评估对业务的影响，但是方案的选择一定要交给专业的人，由技术负责人来确认
3.将测试素材也纳入测试方案内提前准备
测试需要的条件和素材以项目为单位单独维护一套，提前准备好，避免后期因为测试素材问题block住测试，QA的测试方案能否把这部分也包括进