敏捷开发如何改变了产品管理
翻译自Roman Pichler《HOW AGILE HAS CHANGED PRODUCT MANAGEMENT》[1]
敏捷开发宣言[2]诞生20周年之际，我想来回顾一下敏捷开发给产品管理带来了什么变化。我会梳理它给产品管理带来的优点，和仍在面临的挑战
过去的瀑布开发时代
在敏捷开发比如Scrum诞生之前，产品经理需要调研市场、收集市场需求、写项目分析、结合产品规划、写产品文档，才能把产品原型转交给项目经理。产品经理会和至少一个开发团队合作，最终产品落地。
开发过程里产品经理很少介入，他们应该期待产品和原型一样被实现。在整个开发周期里，产品经理在项目指导会、需求变更、产品上线前介入。在产品需求变更、创新型需求不多的情况下，这种方法很不错，前提是产品经理能够很好地预测用户需要什么、然后准确地事先写下所有开发过程涉及的细节。但是这种方法很难应用在复杂的数字化产品上。
勇敢的敏捷开发
随着敏捷开发方法的普及，产品管理的方法迎来重大变革。产品和开发如今合作更紧密，整个产品开发团队包括了UX设计师、产品架构师、测试等等角色。产品开发周期运用例如Scrum的方法，产品文档不在需要覆盖所有细节，开发开始后产品仍然可以修改需求。越来越多的公司开始从项目推动转变为产品推动。这些改变极大地推动了产品管理。以下是敏捷开发给产品管理带来的七个优势。其中不少，现在看来已经是习以为常。
更早的用户反馈，和更频繁的解决方案制定。出发点是通过正确的产品方向提供更好的用户体验，现在我们能更早、更频繁地获取用户反馈，从而验证和调整产品设计。
缩短面市时间。更快的产品或功能迭代速度。这点得益于多种角色介入产品开发，从细枝末节的产品文档转变为面对面的沟通，例如用户故事，避免空中楼阁。
产品质量和适用性提升。因为能够实现快速迭代，实验性发布，因此能够对户反馈快速反应，让产品更好适应市场。
更好的需求。产品经理不再是产品唯一的负责人。开发团队里的所有角色都能够看到产品需求表，能够从自己角度出发提出新需求，或者给已有需求提供见解。因此团队里的每个人对事项建立了主人翁意识，最终开发出更好的产品。
透明的开发过程。开发过程中，所有成员能够在软件里清楚看到进度，而不是静态死板的甘特图，因此团队能够及时发现延期风险，或者产品没有以正确的方式被实现。
统一意见。业务方和开发团队一起参加产品同步会，让每个人达成一致的理解，从而各方对目标更加坚定。邀请所有人参与决策制定，能够更好地在之后让人们支持这个决定。
调动成员积极性。自组织的团队比传统团队都更好的积极性，他们可以决定自己要花多少时间、每个人都有自己负责的部分。
当前的挑战
这些优点听上去有些过于好了，但是其实产品管理中还有很多挑战。这些挑战并不是敏捷开发带来的，但是我认为敏捷开发让这些挑战暴露地更加明显。我们来看一下当前存在的五大挑战
权利的削弱。Ken和Jeff，Scrum的两位创始人选择了产品所有人而不是产品经理，因为他们想强调产品的权利——特别是在敏捷开发里，合作具有很大价值，所有角色都可以发声影响产品决策。但是，缺乏权利仍然是一个问题，产品通常没有必要的权利，去制定战略性的产品规划，影响战略，制定产品规划。由此，产品经理倾向于变成产品代办项管理人、用户故事写手，而不是真正全面地拥有产品、去最大化产品效益。
角色和职能的模糊。即使是敏捷开发提出20年后的今天，产品在其中的职能依然很模糊，更别说正确应用了。Scrum创始人说，产品经理经常被视为产品代办项管理人或业务方讨好者，而不是一个对产品负责的个人、更不是全公司应该尊重他的决定的产品所有者。
缺少对用户的感知。虽然上文提到敏捷开发的优势之一是能够更好地将用户反馈落地到产品里。但是我接触过的很多产品经理，依然不会直接面对用户，他们的用户信息大多来自定性的用户调研或销售和管理团队。这一点从我的经验来说，让人很难完全理解用户或顾客的需求。因此，产品可能不足以很好的满足目标用户，或者达成商业目标。
产品发现和产品战略制定不能很好地被实现。如果最好的用户故事没有清楚地说明用户是谁，为什么使用，这种故事然并卵。要能写出这样的用户故事，要求清晰的产品发现和产品战略。然而，在我的经验里，它们两者不能被很好地实践。因为敏捷开发方法例如Scrum没有提供工具或技巧，教产品经理某个产品应该做还是不做。这里并不是说Scrum不好，它是一个很好的让团队专注在重要的事情上的方法框架，帮助团队搭建复杂的产品。只是它完全没有涉及产品愿景、产品战略、产品规划，以至于产品经理不知道如何将这些产品工具和Scrum结合运用。幸运的是，现在已经有一些成熟的工具，把产品发现和战略与敏捷开发结合起来，我的 Product vision board[3] 和 Go product roadmap[4] 也是其中之一。
不能很好地把握迭代节奏。特别是在敏捷开发里，产品经理很少能够持续健康地把握迭代节奏，因为要关注用户反馈、确认冲刺目标、回答问题等等。过劳工作对效率和心理健康都有负面影响。其实已经有最佳实践，避免产品陷入过劳，保持可持续的迭代节奏。产品应该专注在自己的核心职能上，不要试图代替别人干活，产品往往容易倾向于成为scrum的主导人，不要这样，也不要去讨好业务方，至少不要持续这样做。专注在一致的目标上就可以了。
未来
到这里为止，对于敏捷开发未来二十年会怎么发展，我并不十分清晰。但是我相信上面的五个问题会逐步得到解决。我真心希望二十年内产品所有者能够得到必要的权利，被公司更好地理解和应用，产品所有者能够真正去实践产品发现和战略。我也相信敏捷开发，以及过去几年看到的新提出的精益创业方法会持续赋能产品管理。
References
[1] 《HOW AGILE HAS CHANGED PRODUCT MANAGEMENT》: https://www.romanpichler.com/blog/how-agile-has-changed-product-management/[2] 敏捷开发宣言: https://agilemanifesto.org/[3] Product vision board: https://www.romanpichler.com/blog/the-product-vision-board/[4] Go product roadmap: https://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/