产品读书《网易一千零一夜：互联网产品项目管理实战》
最近想了解一下如何进行项目管理，虽然不是100%纯项目管理人员，但是作为产品经理，我认为了解项目管理对自己的工作也有推动作用，和技术同志沟通也更加顺畅，想人所想急人所急~~本书主要写的是网易杭州研究院三年多的敏捷转型的项目故事，然后特意上网找了曹智清老师早年的scrum gathering 的分享视频，其中提到的诸多概念在书本中都能找到。
书中写的互联网产品项目管理实战，共分为四个部分：
第一章，我是项目经理，主要讨论了估算、计划、站会、白板、报告、回顾、风险、沟通怎么做，还有新手项目经理注意的问题和修炼之路。
第二章，高度延伸，从有效管理和提升的角度，对实操工作背后的深层原则和思路进行了思考和典型问题的完整解题思路。
第三章，宽度拓展，项目管理与业务结合的实战过程的实际问题和实践方式，包括跨部门沟通，项目管理工具。
第四章，深度修炼，自我修炼和管理能力提升，管理好团队，提高核心竞争力。
项目经理新手的建议
- 多想想项目需要什么
每个项目都有它独特的需要，时间、成本、质量到底哪个因素更重要，各个角色目前的痛点在哪里，哪些是最先需要解决的，哪些是隐藏的积弊。大家对项目管理的认知和接收程度怎么样，我要通过怎样的途径，全面推进，还是一步步改造，从哪个角度切入，这个蓝图是否清晰，是否与项目负责人沟通到位并判断一致。- 不要凡事恨不得事必躬亲。成功地施加影响有三个要素：获知、动力、能力。获取理解及认同，激发动力是项目经理努力的关键。同时也要确保他有相应的能力做好这件事情。
- 不要追在别人屁股后面做监工，建立一套对应的流程规则，明确各个角色在过程中的职责。应该是规则在约束大家的行为。变赶为引。
- 言必信，行必果，建立自己的可信度，打造个人品牌。信任的获取，靠的是一件件事情中一点一滴的积累，没有捷径可走。
- 不一定要强势，但一定要内心足够强大，沟通中要求同存异。
- 不是要把自己变得有趣，而是要对别人感兴趣。保持好奇心。
一.项目管理基础
1. 项目管理的三重境界：做项目、懂业务、懂人
- 境界一 做项目
用项目管理专业术语讲就是需要在满足项目铁三角（范围、时间、成本和质量）的情况下交付项目。范围，时间，成本和质量，再加上对业务部门的持续发展的理解
- 境界二 懂业务
懂业务不仅是指对业务领域熟悉，还包括对实现其业务需求的产品方案的了解，知道使用哪些技术来实现，以及对技术实现过程中的难点和重点需要有清晰的把握。为什么立项，业务价值是什么，外部环境有什么制约，最大的风险是公司内部风险还是外部市场、政策风险。
- 境界三 懂人
项目经理要活儿好、让人满意、及时进行“上下左右”不同对象的汇报沟通，从做项目到关注业务的发展、再到对人的关注。项目交付中结合个人的诉求。使项目成员轮番参加重点项目。
这才是项目管理的最高境界。
项目管理境界的铁三角
2. 项目估算
2.1 为什么要做估算？
- 用户需要一个预期
- 管理层需要可预测性
- 团队需要了解如何相互协作
估算的过程，强化和深化了团队对需求和任务的理解，将任务考虑的更细致，降低了不确定性给计划带来的冲击。
估算准确度和投入工作量之间的关系
2.2 估算的三种方法：结合团队根据自身情况、项目现状来进行选择。团队需要不断练习估算的方式并且收集反馈。
- 理想人日：指成员在不受干扰的情况下，全部时间都用于开发需求所需的天数。缺点在于成员对技术和项目的熟悉程度，个人的经验和能力不同。优点在于对团队外部的人来说，理想人日更容易被理解，无须解释。
- 理想人时：在充分理解需求的情况下，能做到更靠近真实值的估算。然而对一些大的需求，无法做到如此细的程度。
- 故事点：是对任务规模的估计，一种相对概念。由所需时间+所需什么样技术熟练度的人员，估算出来。
商业模式画布
2.3 如何估算
- 自下而上的估算
- 专家判断
- 扑克估算
2.4 估算中要注意的点
- 估算仅仅是一个预测，最好提供一个日期范围
- 将任务分成更细粒度总是有利于估算的
- 估算需要反复进行。即行进中调整。
- 估算中故事点的数值，不需要再转化成人天。工作以迭代为周期进行增量交付。周期是事先约定好的，每个迭代的计划不需要确定日期，只需要估算下一个迭代我们能完成多少工作。
3. 项目计划
项目经理应该做第一个挖坑的人，引导团队拨开重重迷雾，将不确定一一落地。计划的本质，是团队对何时完成任务的承诺。
- 越有太多不确定，越应该给出计划。如果在混乱不清的情况下，根据仅有的少量信息就给出了期望值，就好比挖了个坑。项目经理应该做第一个挖坑的人。当然，挖坑了以后，就会带领大家一起去填坑。
- 计划是市场需求和高层期望，与团队生产力两者之间平衡的结果。
- 建立时间表，横轴表示计划的时间进度。
- 指定计划必须是项集体活动。必须让项目成员参与进来。
- 把里程碑分割成一个个小的阶段。
- 持续一个两月的功能开发期，须拆分成多次迭代进行管理。
- 好的计划必须有持续的跟进。
项目计划本身就是一个渐进明细的过程。最重要的是做好时间调整评估、决策、通知和记录机制，保证相关干系人能及时获得时间变更信息，评估影响，确保变更公开透明，有据可查。
日程安排示例
立项前时间表
立项后时间表
需求确认后时间表
计划的本质是承诺，想要让承诺更加有效，它必须得是当事人积极的、公开的、且经过一番努力后自由的选择。每一个迭代都需要单独的计划和完成标准。
4. 白板艺术
用白板代表电子化工具，增加互动，统一方向、聚焦核心、发现和解决问题。
（1）白板分布
5行代表5种任务：运维上线相关任务（日常更新、线上缺陷）、开发（普通开发任务，含前端、测试等）、测试（独立的测试任务，如测试用例完善、测试代码完善等）、前端（独立的前端任务，如页面优化）、分享（内部技术分享等）。
4列分别为：还未开始的任务（Open），进行中的任务（In progress），开发完成待验。
（2）燃尽图--直观了解项目进度风险
5. 项目工作报告
（1）个人工作报告
（2）项目工作报告
项目概括和细节
月度项目汇报
项目集甘特图
（3）项目会议
会议意味着解决问题、做出决策、建立信任。错误的会议安排导致团队效率降低和抵触，应该尽最大努力使会议更有效、更有价值。
项目评审会议
主要项目会议
每日站会不是汇报会，解决的是团队协同的问题，是出于团队的自组织需要。
跨团队的、涉及整体计划性或者协同配合型的问题、或者中期改进型问题，适合放在周会上
周会不是讨论细节性问题的地方。周报不能只是单纯的记录，需要精炼易懂，突出重点，起到效果。
周会上确认当前任务的完成情况、所存在的问题和风险，对当前计划的可行性进行评估。
回顾会议：发现问题，分析问题，解决问题
结果落地：持续改善的检查表；为每个行动事项指的一位负责人。做到问题的闭环跟踪。
问题的根源：80%以上来自团队和过程，而不是个人每周一次的需求沟通会：当一件事情被提上议程，它的进度往往会比较快。会给需求人员带来更多的思路，有利于及时的调整需求，增加研发对需求的认同度。有的时候你不去问，别人是不会主动来告诉你他的想法的。
开会之前，首先要想清楚
1）会上达到什么目标、解决什么问题。
2） 需要得到哪些人的帮助 （
3）会议表？主持人？时间？地点？方式？（
4）会议纪要？跟进？
评审会议流程
会议检查表
4）风险识别
项目管理中的风险管理是极其重要的一个环节。广义来讲未来的不确定性就是风险，识别风险可以从项目不同的阶段（需求、视觉交互、开发测试、上线过程、线上运营等）、不同的领域（运营、客服、策划、技术等）通过头脑风暴的形式而收集到初始风险列表，进而通过概率影响矩阵分析法，选出那些出现概率较高和影响较大的风险，与之制定相应的风险应对措施和并定期监控。
风险需要被持续监测，风险的具体影响需要被明确体现。常见风险列表可以辅助风险排查。如下。
对于风险应有一种更积极的态度，以便找到更好的产品方向。
业务风险识别
技术风险识别
后勤风险
（5）项目回顾
回顾，也是检视过程缺陷，持续改进的过程。
（6）沟通
沟通的关键在于少聚焦“小我”，多从对方、从全局来思考问题，不纠缠于表面利益是非，用双赢的思维与对方多探讨、共进退。
理解冲突
冲突的界线
了解项目生命周期中不同阶段冲突强度
项目生命周期中不同阶段冲突强度
各种沟通模式优劣对比
各种沟通模式优劣对比
在时间维度和沟通对象维度有计划拓展沟通：
二.高度延展
如何启动项目？初创阶段应该如何开展项目？怎样面对冲突？如何用Srum推进项目？
关于敏捷教练
敏捷管理的4个仪式：计划、站会、评审、回顾。
敏捷的3个关键：目标、人和过程。
敏捷5步修炼法：唤醒内心的能量、用问题代替答案、耐心倾听，用问题代替答案、用信任代替担心、放下自我，保持好奇。
三.宽度延展
1.数据埋点
2.避免原地转圈
仅埋头做事，较少获得反馈，就容易陷入原地转圈。如何持续寻求反馈？（1）确定目标（2）有效度量（3）持续跟踪。
工作量燃尽图
Bug修复趋势图
产品关键指标图
设定好目标，有效地度量目标，并且及时从中获得反馈，才能够敏锐地感知产品脉搏的每次跳动。
3.跨部门合作
跨部门的项目与普通项目的不同点主要在于整个团队完全是由于项目的原因形成的一个虚拟团队，人事上汇报关系的约束力不存在了，人员关系、部门利益的复杂性增加了项目管理的难度，因此更要依靠管理的技能来保证项目的成功交付。
合作流程举例
如何让多个团队接受你的项目管理方式？如何让整个项目的计划和决策机制公开透明？如何在计划执行中两个团队之间出现问题时去及时化解？
4.持续集成
持续集成（Continue Integration，CI）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
两个要点：
（1）过程的关键词：高频率、自动化。
（2）结果关键语句：能尽早地发现问题，从而避免问题拖到后期而导致巨额成本。
持续集成
引入和实施持续集成顺应了目前快速交付的节奏。自动化、高频率地进行使得问题尽早暴露和解决，从而有效减少了后期整体修复时间，避免了项目延期，有助于提高项目的交付能力。
更重要的是在实施过程中让团队建立一种意识，一种持续提高和改进的意识。
四.深度修炼
如何做到自我修炼与管理能力提升？如何管理好一个团队？遇到困境时该如何突破自己？
这本书是作为网易项目的亲历者的学习、记录、比较、反思和分享。正如丁磊说，网易在这19年的探索中，既快速应变市场，又坚持着自己“有态度”的工匠精神，不停地创新和打磨自己的产品。产品的背后，工匠精神并不是灵光乍现，而是凝聚着艰苦而科学的工作、多团队的协同以及不断地快速版本迭代。
总结：
1. 不要追在别人屁股后面做监工。PMBOK说项目经理要对项目过程进行监控，不仅管好人同时也要管好事，对过程细节太过于执着势必容易引发逆反及压迫心理，而更应当和大家一起把事情从头到尾各个环节旅捋顺乐，建立一套对应的流程规则，明确各个角色在过程中的职责，并获得大家的认同，让这个机制自行运转起来。
2.循序渐进的项目管理三重境界：做项目，懂业务，懂人。做项目是让项目进行下去，懂业务是知其然知其所以然，懂人事能够在利益相关人满意的基础上交付项目。除了范围、时间、成本外，在中间还有质量和业务发展和利益相关人满意度。
3. 做估算是帮助我们找到一个合理的计划，给用户、管理层以及团队自己的一个稳定的预期。有稳定的团队开发速率并实现预期，需要项目每一次迭代后经验总结和改进。
4. 敏捷扑克，可能刚开始有新鲜劲，但过了之后又走回老路，怎么简单怎么来，所以慢慢将招式内化，让团队渐渐不需要扑克了，自行建立起对话机智。
5. 计划的本质是团队对何时完成任务的承诺。越有太多不确定，越应该给出计划。
6.三张牌站会，红黄绿，黄牌进行提问题，红牌打断谈话，绿牌发言。
7.看板，除了Story外，还可以填写上任务概要，估算工作量、负责人、实际工作量。在看板旁边还可以加上燃尽图、倒计时、目标、信心指数（5，4，3，2，1）和计划。
8. 轻量化工具，书中用的是有道云协作+ JIRA，有道云协作表格每一行做为功能点，格子颜色表示任务状态。Bug 统计采用JIRA，使用dashboard.
9 .项目管理的本质，是激发团队内在的思考力，培养和统一这个团队对于基本问题的看法以及应对思路。培养团队对探求变更价值和必要性深究而非变更流程本身。
10. 跨部门合作项目，做好时间调整评估、决策、通知和记录机制，保证相关干系人能及时获得时间变更信息，评估影响，确保变更公开同名，保证以后如果有异议，有据可查。
11.Bug bash ,产品版本发布前，一起集中精力来找Bug, 好处有：团队集体试用，发现需求；理清发布前还有什么没做好； 游戏化激励团队。
12. 持续集成，包含：代码提交后自动构建，构建成功后自动运行已集成上去的单元测试用例，接下来进行静态代码走查、接口测试、回归用例集。Jenkins(Java)、Sonar(数据分析和展示)、Maven(项目构建管理)、XUnit家族（单元测试）、静态代码分析工具（PMD 、CheckStyle、FindBugs、Splint、Klocwork、Coverity）.
13. 上线精神，态度很重要，对此事重视、谨慎、细心的程度。
14. 项目经理核心竞争力“体、机、用”，体是本体、用是效用，机指时机、环境、条件。
写在最后，花了较长的时间在地铁上读完了第一遍《网易一千零一夜》，给我最大的体会是：项目开始敏捷转型时，问题肯定会层出不穷，当然出现问题也是一种选择，一次发现问题、持续改进的过程，在回顾后得到的是团队共同经历的成长结果，作为项目经理，首先对团队要有信心，激励大家一起拥抱变化、走出舒适区，从守到破再到离，看透本质、大道至简、从而达到无招胜有招。敏捷扑克也好，看板也好，一方面作为工具使用，切记在过程中发现团队“人”的因素，共情和同理非常重要。杭研院的一千零一夜，非常有意思，后面我还会再精读第二遍，在我们目前敏捷新项目中更多思考和实践。
参考阅读：
- 《网易一千零一夜：互联网产品项目管理实战》总结 五
- 《网易一千零一夜：互联网产品项目管理实战》总结 四
- 《网易一千零一夜：互联网产品项目管理实战》总结 三
- 《网易一千零一夜：互联网产品项目管理实战》总结 二
- 《网易一千零一夜：互联网产品项目管理实战》总结 一
- 腾讯终于说出了自己的产品心法
-
为什么梁宁说产品力是人的底层能力？