《网易一千零一夜：互联网产品项目管理实战》总结 四

风险管理

墨菲定律：有可能出错的事情，往往就会出错

• 只相信我们有权相信的，质疑我们应该质疑的，说出我们的质疑，观察并应对我们的质疑，这就是风险管理。
• 未来的不确定性就是风险。
• 初期可以通过头脑风暴的形式收集到初始风险列表，进而通过概率影响矩阵分析法，选出哪些出现概率较高和影响较大的风险，与之制定相应的风险应对措施和并定期监控。
• 任何人只要认为某任务或者bug可能会无法控制和有效解决，可能会成为项目的风险，都可以打上风险的标签，以表明这已经是一个内部风险。
• 打上风险的工作，意味着需要更高级别的人关注，或者需要更多资源支持。项目经理可以通过一个过滤器，同时加入项目的仪表盘dashboard中。
• 风险最重要的是有人跟进，有人处理。
• 除了有效的风险识别和应对以为，还有项目内部人员间的种种问题，这些信息片段构成来项目的潜在问题集，需要从中区判断重要性，去分辨这些是事实问题还是信任问题。
• 真正的里程碑目标，应该是一张风险图，包括了最早交付日期、最可能交付日期以及最晚交付日期。

研发资源协调表：

比对目前的实际进展状态，思考时间是否足够，人力是否协调得开，需求的细节是否有待确认，各研发人员是否对需求有了认可和一致的理解，上线时间是否符合产品用户群的使用习惯，发布后运营时间上是否匹配来可借力的大规模推广。。。每一行都涉及至少2～3个风险点，需要找到对应人员做协调沟通，确保信息对称透明，能及时纠正刚刚发生的偏差。
这就是项目经理的风险管理，理论上看似乎就是一张表，但实际上包含来对当前以及未来一段时期内的项目演变分析，更包括来因预见到问题而做出的积极响应。

---

持续集成CI

• 持续集成CI是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少一次。每次集成都通过自动化的构建（编译，发布，自动化测试）来验证，从而尽快的发现集成错误。

• 为什么要CI：
  多人对同一模块并行开发；快速交付的要求，试的团队需要及时提交，快速响应，解决冲突。

• 持续集成能否成功的关键，在于团队能否坚持编写与维护高质量单元测试用例，能否第一时间修复发现的问题。

• 持续集成CI最重要的是完善相关的自动化测试脚本，能够做到回归测试交由机器来完成。

• 相关指标公式：

    总体完成率=迭代总完成工作量/迭代总工作量
    计划完成率=完成计划工作量/计划工作量
    蔓延率=新增工作量/迭代总工作量
    
    bug生产率 = 迭代新增bug工作量/迭代总完成工作量
    单纯的呈现单位工作量会产出多少bug工作量
    bug一定是一种浪费且不具有任务价值

---

上线精神：

• 原则的事情不能碰。
  • 流量最低时间点上线原则。半夜两点
  • 一次上线不允许软硬件一起升，并且不允许太多模块一起升。
  • 上线过程中出现问题及时上报。让更合适的人来做决定。
  • 节假日前不要做上线操作。
• 万事皆谨慎。重视上线前的演练。

---

沟通

谈判技巧：

• 人的因素决定了一切。在谈判中，你自己应该是无足轻重的，最重要的人是对方。对方的感受，看法，想法都是什么。
• 争论对错毫无意义。谈判前你要明确这次谈判你要达成的目标是什么，目标是你要努力实现的东西。
• 谈判要对目标做到心里有数。为昨天发生的事情而争斗永远不会让你取得任务进展。要努力让双放分清主次。
• 在谈判中要控制情绪。
• 步子太大会“扯到蛋”。首先会考虑把自己的谈判目标进行拆分，分成多个步骤，每一步都要停靠一下并进行确认。

冲突

• 应对冲突时，开场列出事实，不用包含个人的判断，看起来像人身攻击，容易激化矛盾。
• 说出你的推理逻辑，从事实出发，告诉对方你的分析思路，是如何得出你的个人观点的，便于让对方理解你的观点。
• 征求对方的意见。目的不是证明你自己的正确，而是让大家能够自由得交流观点，作出最佳决策。

在真正的对话中，并不存在说服与被说服，只有真诚朴素的想了解和倾听对方的愿望。

---

项目管理

• 一个典型的互联网项目需要有产品经理、交互视觉设计师、开发工程师、测试工程师、运维人员、运营推广员。交付时间长度应该是1~2个月。
• 一般预留20%的项目规模作为缓存时间。
• 项目管理是为业务部门解决问题、提高效率的。
• 项目初创阶段，尽量缩短迭代，尽快交付成果；建立通畅的反馈渠道，每周用户反馈报告；工具轻量化。
• 要重视完成。
• 行为，产生结果；结果，调整认知；认知，决定行为。
• 打破项目原地转圈的魔咒：确定目的和预期目标；有效度量；持续跟踪。
• 项目组中，新老员工比例不应超过1:1，其中新员工包括正职/借调+实习生。
• 研发效率/产能，不是团队负荷度，而是产能吞吐量。要关注相同时间内完成了多少需求量，或者需求的平均响应时间。
• 版本中是否出现过技术优化需求。没有不欠债的技术团队。整体的架构优化要排计划。
• 要统计线上事故频率及严重度，修复速度。
• 项目排期经多次会议沟通后分阶段确定，先确认内部分批次联调及基本主流程打通的完成时间点，然后再项目中期确认最终版发布时间。
• 项目组中的要懂得平衡，但是其中的强势弱势往往是动态变化的。
• 项目管理的主要任务是风险管理，问题协调，团队感知。
• 项目过程中的经验：
  • 策划和交互搞最好在开发开始前完成。
  • 详细设计最好有。
  • 一周至少两次沟通。
  • 重视代码评审。