一、整体策略思考
1. 理解问题
首先，面对问题需要理解这个问题的场景，搞清问题背后的原因到底是什么，这对于解决问题来说是关键前提条件。那么就需要对问题相关的干系人进行沟通，换位思考，以寻求最优解决方案。
2. 明确目的
遇到问题不可怕，可怕的是并不知道这个问题到底带来什么影响，只是主观上认为这是问题，那就无从评估其严重性，结果就是很大可能花了大精力只解决了一个很小的问题，没有带来实际的价值。所以，也要在解决问题之前，思考清楚目的是什么，为什么要这么做，成本和收益关系如何，再做下一步执行决策。
3. 沟通引导
出现问题往往是因为双方立场不同、目标不一致而导致的，所以想要更好地解决问题，就要从目标一致的视角出发去与当事人沟通，在相互尊重、尽可能说清双方的困难并引导相互理解的基础上，使双方能够达成共赢的目标，再去交流解决方案直到达成协议会更加高效。
4. 赋能组织
将遇到过的问题总结经验，举一反三，从点到面去形成可复制的方法论，在团队内外进行分享与交流，帮助更多的团队解决实际问题。
二、问题解法及实施
上面讲的是一些面对问题时思考的通用方法，在理清思路后，下面就来看看那几个常见问题的解法吧！
1. 明确业务规划
当团队反馈不太了解业务规划时，这是一个需要特别警示的信息，因为当一个团队没有明确方向的时候，后续的执行也会出现很大偏差，导致组织的低效。其背后的原因可能是管理层信息下达不够，也可能是团队之间的目标并没有横向拉通只局限于关注自己这部分事情而导致。
解决方案可以是通过定期召开业务规划会，聚焦季度或半年内核心事件、目标及资源分配原则，各团队TL在会上充分达成一致，会后坚决执行，将策略拆解成产品需求迭代进行规范化管理。建议可与BI团队协同，在团队定期会议上反馈业务目标进展及近期上线的核心产品功能数据效果，做到有规划、有反馈，这是建立团队间信任的一个非常好的方式。此外，也可以通过OKR目标管理的方式，使上下游协同的团队在目标层面进行横向拉通，彼此在共同的目标下制定策略方案，定期回顾或调整目标以确保团队整体方向在主线上正常运行。
2. 客户交付周期提效
客户交付周期是指产品需求从评审到发布的周期时间。一般提出“客户交付周期比较长”的问题时，可能并不是周期长短的问题，而是在整个产品迭代生命周期过程中协同不顺畅的问题导致了体感上觉得周期长，所以也需要具体问题具体分析。
常见的解决方案是通过梳理产品需求评审到发布的关键里程碑，定义里程碑的标准，制定版本迭代的计划与节奏，界定职责分工，让各团队养成相对稳定的节奏，步调一致，以此来帮助上下游更高效地协同。产品迭代生命周期关键里程碑通常为评审、设计、开发、测试、集成（代码冻结封版）、发布，可根据团队现状和具体问题进行更加细化的标准制定。
需要注意的是，当一个产品迭代的里程碑规划好后，同时也要关注前后迭代的上下并行情况，不合理的并行会导致更加低效的交付，可以参考以下两个关键逻辑来减轻并行对团队的影响：
1）当前迭代启动开发时，下一个迭代可启动评审（这里的评审指的是只需TL层参加的初次评审会，明确需求价值及技术可行性，不需一线同学参加。经过初次评审会的需求则进入设计阶段，在召开细节评审会后确定需求排期）。
2）当前迭代完成集成（代码冻结封板）时，下一个迭代可启动开发。
迭代并行里程碑规划示意图
所以，当多个产品迭代里程碑规划好后，各团队会明确自己在不同阶段要做的事情，养成迭代节奏感，再通过制定协同机制，监督执行过程，记录关键效能数据及分析问题的手段来不断提升客户交付周期效率。
3. 维护协同秩序
针对前面讲到关键里程碑的规划，那么问题来了，里程碑规划后，如何使团队很好地执行而不是多次被延期呢？举个例子，大家都知道高铁的乘车规则，提前10-15分钟集中进站检票，按时发车，迟到的人只能承担退改签的成本。同理，为了能够保障关键里程碑按时完成交付，除了制定规则机制外，还需要借助平台去进行系统化管理，以确保机制是可执行、可落地的。
常见的工具有：
1）产品需求管理平台
主要用于需求管理及缺陷管理，可通过冻结需求池来管理变更，也可配合看板建立开发任务跟进研发测试过程，并自动生成数据报表。
2）研发集成与发布平台
主要用于APP开发项目管理、版本集成管理及发布管理，通过平台卡口管理质量及过程效率，对于质量不达标或晚于集成冻结时间的需求，触发上级审批流程加以管控，同时度量大盘可生成版本维度的数据报告。
三、效果提升
通过机制和平台组合拳，统一团队阶段性目标，以上在团队试行二至三个产品迭代后，上述问题得到了很大的改善效果，以近期赋能的大麦网APP客户端为例，经过改进，可在产品规划的方向上明确每个版本迭代的需求范围，APP版本固定在每三周发布一次，同时也改善了集成质量，模块一次集成成功率从50%提升至80%，团队整体对问题影响面的评估意识有所提升，不再一有问题就阻碍发布，连续多个版本紧急集成次数为零，灰度发布周期也从3天下降到0.5天。
四、关键沉淀
最后，简单整理了产品迭代生命周期的关键里程碑目的及主要标准，细节之处可以根据不同的组织进行个性化定制，关键在于从问题出发，通过有数据支撑的不断过程改进，使团队之间更加信任彼此，高效协同，切实帮助组织提效。
产品迭代生命周期关键里程碑目标及标准：
启动
| 需求规划 | |
|---|---|
| 目的 | 明确业务近期重点、核心目标及资源分配原则 |
| 工具 | 产品规划会议（各团队TL层参加） |
| 准入 | 产品规划文档 |
| 准出 | 结论明确的会议纪要 |
| 产品内审 | |
|---|---|
| 目的 | 明确单个产品迭代内的需求及优先级 |
| 工具 | 产品需求管理平台 |
| 准入 | 需求与规划方向一致，目标或价值明确 |
| 准出 | 由产品负责人负责审核及输出需求优先级 |
计划
| 需求初评 | |
|---|---|
| 目的 | 对需求价值各团队TL达成一致，初步评估技术可行性 |
| 工具 | 初评会议（各团队TL参加） |
| 准入 | 需求目标或价值明确，具备Demo或线框图 |
| 准出 | 价值及可行性达成一致的会议纪要 |
| 交互设计 | |
|---|---|
| 目的 | 按需求初评范围完成交互及视觉设计 |
可行性
| 需求细评 | |
|---|---|
| 目的 | 对需求实现各团队达成一致 |
| 工具 | 细评会议（相关团队一线同学参加） |
| 准入 | 需求交互及视觉稿，完整的PRD文档 |
| 准出 | 通过细评的需求列表及完善的会议纪要 |
| 确定排期 | |
|---|---|
| 目的 | 细评后由技术TL在1-2个工作日反馈确认排期 |
执行
| 需求研发 | |
|---|---|
| 目的 | 按排期完成指定需求的研发，确保自测质量，按时提测 |
| 需求测试 | |
|---|---|
| 目的 | 按排期完成指定需求的测试，确保需求质量 |
| 集成（代码）冻结 | |
|---|---|
| 目的 | 对代码变更提交集成限期完成，以保证按时发布 |
| 灰度发布 | |
|---|---|
| 目的 | 用于少量用户更新升级，收集问题后快速修复 |
| 正式发布 | |
|---|---|
| 目的 | 将通过灰度发布验证的安装包，交付至全量用户进行更新升级 |
监控
| 目标进展 | |
|---|---|
| 目的 | 针对每个需求进行上线后的目标追踪及反馈，引导业务调整策略 |
| 关键里程碑 | |
|---|---|
| 目的 | 对关键里程碑进展及效果进行过程监控，确保按时、按质交付 |
| 过程质量及效率 | |
|---|---|
| 目的 | 对过程质量及效率监控，记录问题，指引改进 |
收尾
| 度量报告 | |
|---|---|
| 目的 | 用数据反馈结果目标趋势及过程问题，分析原因，指引改进 |
| 复盘改进 | |
|---|---|
| 目的 | 聚焦问题，改进过程 |
| 工具 | 复盘会议（各团队TL参加） |
| 准入 | 阶段性度量报告 |
| 准出 | 改进措施、期限及责任人 |
