开始阅读这本书的时候，我对项目管理实际上处于懵懵懂懂的状态。读完以后，发现自己真的是提升了不少，明白了不少，受益匪浅。此书表面上是将网易杭研项目管理部的各个项目经理对业务对项目相关的经验、感悟整理成册，每人负责几篇文章，看起来零零散散，非常繁琐。实际上却是干货满满，字字都是实战中得来。看完这本书，我对网易的印象又加深了几分。
现将此书中的精华整理再整理，列举如下。不过还是推荐大家去阅读原书，不会令你失望的。
项目经理新手的建议
- 多想想项目需要什么
每个项目都有它独特的需要，时间、成本、质量到底哪个因素更重要，各个角色目前的痛点在哪里，哪些是最先需要解决的，哪些是隐藏的积弊。大家对项目管理的认知和接收程度怎么样，我要通过怎样的途径，全面推进，还是一步步改造，从哪个角度切入，这个蓝图是否清晰，是否与项目负责人沟通到位并判断一致。 - 不要凡事恨不得事必躬亲
成功地施加影响有三个要素：获知、动力、能力。获取理解及认同，激发动力是项目经理努力的关键。同时也要确保他有相应的能力做好这件事情。 - 不要追在别人屁股后面做监工
建立一套对应的流程规则，明确各个角色在过程中的职责。应该是规则在约束大景的行为。变赶为引。 - 言必信，行必果
建立自己的可信度，打造个人品牌。信任的获取，靠的是一件件事情中一点一滴的积累，没有捷径可走。 - 不一定要强势，但一定要内心足够强大
沟通中要求同存异。 - 不是要把自己变得有趣，而是要对别人感兴趣。保持好奇心。
项目管理的三重境界：做项目、懂业务、懂人
- 项目铁三角：范围，时间，成本和质量，再加上对业务部门的持续发展的理解
- 理解业务：为什么立项，业务价值是什么，外部环境有什么制约，最大的风险是公司内部风险还是外部市场、政策风险
- 项目交付中结合个人的诉求。使项目成员轮番参加重点项目。
水因地而制流，兵因敌而制胜。兵无常态，水无常形，能因敌变化而取胜者，谓之神。
这才是项目管理的最高境界。
估算
为什么要做估算
- 用户需要一个预期
- 管理层需要可预测性
- 团队需要了解如何相互协作
估算的三种方法
- 理想人日：指成员在不受干扰的情况下，全部时间都用于开发需求所需的天数。缺点在于成员对技术和项目的熟悉程度，个人的经验和能力不同。优点在于对团队外部的人来说，理想人日更容易被理解，无须解释。
- 理想人时：在充分理解需求的情况下，能做到更靠近真实值的估算。然而对一些大的需求，无法做到如此细的程度。
- 故事点：是对任务规模的估计，一种相对概念。由所需时间+所需什么样技术熟练度的人员，估算出来。
如何估算
- 自下而上的估算
- 专家判断
- 扑克估算
估算中要注意的点
- 估算仅仅是一个预测，最好提供一个日期范围
- 将任务分成更细粒度总是有利于估算的
- 估算需要反复进行。即行进中调整。
- 估算中故事点的数值，不需要再转化成人天。工作以迭代为周期进行增量交付。周期是事先约定好的，每个迭代的计划不需要确定日期，只需要估算下一个迭代我们能完成多少工作。
计划
计划的本质，是团队对何时完成任务的承诺。
- 越有太多不确定，越应该给出计划。如果在混乱不清的情况下，根据仅有的少量信息就给出了期望值，就好比挖了个坑。项目经理应该做第一个挖坑的人。当然，挖坑了以后，就会带领大家一起去填坑。
- 计划是市场需求和高层期望，与团队生产力两者之间平衡的结果。
- 建立时间表，横轴表示计划的时间进度。
- 指定计划必须是项集体活动。必须让项目成员参与进来。
- 把里程碑分割成一个个小的阶段。
- 持续一个两月的功能开发期，须拆分成多次迭代进行管理。
- 好的计划必须有持续的跟进。
项目计划本身就是一个渐进明细的过程。最重要的是做好时间调整评估、决策、通知和记录机制，保证相关干系人能及时获得时间变更信息，评估影响，确保变更公开透明，有据可查。
项目中的会
每日站会不是汇报会，解决的是团队协同的问题，是出于团队的自组织需要。
跨团队的、涉及整体计划性或者协同配合型的问题、或者中期改进型问题，适合放在周会上
周会不是讨论细节性问题的地方。周报不能只是单纯的记录，需要精炼易懂，突出重点，起到效果。
周会上确认当前任务的完成情况、所存在的问题和风险，对当前计划的可行性进行评估。
回顾会议：发现问题，分析问题，解决问题
结果落地：持续改善的检查表；为每个行动事项指的一位负责人。做到问题的闭环跟踪。
问题的根源：80%以上来自团队和过程，而不是个人
每周一次的需求沟通会：当一件事情被提上议程，它的进度往往会比较快。会给需求人员带来更多的思路，有利于及时的调整需求，增加研发对需求的认同度。
有的时候你不去问，别人是不会主动来告诉你他的想法的。
