type
status
date
slug
summary
tags
category
icon
password
敏捷开发十二原则的第二条：“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。”
首先要明确，需求是肯定会变动的。“期望产品在写PRD的时候思考到滴水不漏的逻辑、整理全部闭包的需求”本身就是一个不现实的期望。如果这一点不共识，后面的内容就不用看了。
其次，从敏捷宣言“客户合作高于合同谈判”和“响应变化高于遵循计划”来说，如果是为了提供更好的用户价值，需求变更是可接受的。在研发流程的不同阶段，接受变更的成本不一样，需要协商Trade Off。
如果产品需求有逻辑不完备，在研发过程中大概率就能发现，一定要在研发过程中沟通确认，而不要等产品自己发现。当程序员陷入写代码的心流中时，就会忘记沟通，自己设定默认逻辑，甚至不愿意沟通。很多变更其实在研发过程中就已经发现了，但是并没有被沟通到，直到后面变更的成本越来越高。强调的是面向用户价值，协作和沟通。
Show Case之后允许产品做需求变更，提测之后也允许变更。出发点是 用户价值 和 敏捷应对需求。唯一的不变是变化，需求不可能不变，只能通过需求流程，让变化在前面尽早暴露出来，风险左移，比如PRD的1稿、5稿、9稿评审。
不同阶段、什么大小的变更是可以准入的，什么大小的变更是不可以准入的，我觉得没有标准答案，一切都还是要看产品成本、研发成本、测试成本、设计成本、协作成本、需求上线时间、对后续需求的影响等多种方面的权衡。
如果一个产品的需求总是会变更，就应该在需求评审的前置流程中加强评审，风险前置，同时此产品在工程师心中的Credit会降低。作为需求方，也应该理解，工程师build自己的优美代码build了好几天，还没有上线就变更了，工程师有怨言也是情有可原的，从协作的角度讲，咱们该好好说就好好说。产品和工程师绝对不是对立的两个角色，而是协作和双赢的角色。工程师都是很温柔很好说话很open的，好好沟通好好说话就行。同样，对于研发来说，如果搞了一个不对应用户价值的需求，即使你build的代码再优美，价值也大打折扣。
研发对于需求变更的应对
- 有需求变更时，重要的是和产品、测试、设计一起评估变更成本，在多方评估下衡量是否可以接受变更。研发周期越往后，成本越高，越需要控制变更。从用户价值出发，多方共同评估；
- 简单的变更，有可能顺手就改了；
- 中等大小的变更：
- 如果有必须上线的承诺交付时间(比如toB场景)，可以先在team内看下其他同学的吞吐能不能接受此变更，否则就先上线再追补充需求，先保障承诺的交付时间；
- 如果没有必须上线的承诺交付时间，可以协商是先上线再加补充需求，或者接受需求变更但是修改提测时间和上线时间，或者在team内寻求其他同学协助；
- 不应该因为需求变更而让研发同学加班，这是可耻行为。首先，真的需要deadline吗？不能修改上线时间吗？很多需求，长期来看，首先价值没那么大，其次晚上线几天真的会有很大的影响吗？作为研发leader，这些是需要争取的。敏捷不仅仅强调及早交付用户价值，也强调持续交付用户价值。长期加班，用户价值的交付无法可持续，质量也难以保证。
- 彻底推翻的变更或者是很大的变更，需要拉着产品一起对清楚原因，以后如何避免类似的研发浪费。以及，会影响产品自己的credit，需要给到负反馈。PRD有1稿 5稿 9稿评审的流程，一般不会出现这么大的变更。
其实，只要产研保持“交付用户价值”的第一性标准，研发、产品、测试、设计一起好好说话，好好评估，不要固化为“研发加班”是问题的终极解法，需求变更根本就不需要什么复杂的应对方案。互联网也是一个需要好好协作的行业。
相关文章