如何解决项目开发过程频繁发生的需求变更？

01

在开始之前，先插播一段花絮：

公司竞标拿下一个水泥厂项目，该水泥厂为响应号召，计划在2023年底实现数字化转型，需要采购一个管理平台，来帮助企业更好地经营管理。

作为这个项目的产品负责人，我们应该怎么办？

需求就一句话，很虚、很笼统。有同学说，别管那么多，先干起来，去客户现场和客户去沟通交流，先收集一波需求出个方案再说。

没毛病！

和客户确认方案无误后，带领项目团队热火朝天地投入到后续开发当中。

产品上线后，A用户使用后发现产品不好用，不是我想要的，又提出了这样那样修改意见和新的需求；B用户说，我想XXX，你们给加一个呗？

大的小的需求、意见，一天十几条就够你喝一壶了。响应慢了投诉你，尾款不结；积极响应，改吧，项目成员diss你，怎么做的项目管理，整体变变变，客户说什么就是什么，没一点主见...

这一幕熟不熟悉？眼不眼熟？每天都在发生着，有你有我，一个都不能少~

难不难？！

02

不论是B端项目还是C端项目，在项目实际开发过程中，都避免不了需求变更这个问题。今天蜗牛就来聊聊这个话题。

从项目的全生命周期来看，一个项目可以划分这么几个阶段：

当前产品/项目开发模式不论是采用瀑布还是敏捷模式，整体流程是一样的，区别在于迭代节奏和迭代目标。

从这个流程上可以看出，一旦项目进入开发阶段，再进行项目变更代价是很大的，甚至是推倒重来。

在我刚开始做产品经理的那两年，和很多朋友一样，接到需求就是一顿操作：沟通需求、设计原型、方案评审、项目启动、迭代上线。潜意识里认为需求就是对的，作为一个工具人很少去主动思考需求的真伪和全面性。

最近这几年换到B端赛道后，发现这套工作方法有点行不通了。

03

首先，我们很难接触到B端用户和竞品。这也是B端产品的一个特点，有很强的行业属性，与企业业务强关联。

其次，B端产品的业务很复杂，正常一个B端产品会有多个业务子系统、多个角色构成。

最后，我们应该明白一个事实：客户是很难清晰、准确地说出他们的诉求。通常，我们在沟通需求的时候，他们更多地是站在自身角度给你反馈一些在以往工作中所遇到的问题，希望你帮他解决。

以流程工业水泥行业为例，水泥生产工艺流程是这样的：

石料破碎及预均化--生料制备--生料均化--预热分解--熟料烧成--水泥粉磨--水泥包装

这条完整的生产线背后是有多个部门组成：安全部、环保部、生产部（爆破车间、生料车间、烧成车间、制成车间、包装车间）、质量控制部、工艺部、维修部、电气自动化部、采购部、财务部、销售部等。

水泥厂有这么多工艺线、这么多部门、N多用户，需要怎么做才能保证这个项目可以圆满落地？

先别往下看，仔细想2分钟。

04

直接说答案：问题出现在产品设计阶段，需求管理没有做好。

产品设计阶段又可以细分为4个阶段，如下图所示。

前面花絮中，我们也做了市场调研、用户访谈、demo设计和方案沟通，和客户确认无误才往下开展的啊？怎么上线后还有这么多要求，还不满意呢？

问题的症结在于用户需求管理不到位。

这里就考验我们的业务抽象能力。用户的上一层是什么？角色。

什么是角色？角色是一群有共同需求的用户，就是用户集。

面对这么大一个平台，如此复杂的业务场景，如此多的部门和用户，先别急着画原型。该怎么做呢？我是这么做的？

1、干系人管理。

这里的干系人是指水泥厂用户。我是按照纵横维度进行干系人管理。纵向上，划分为高层、中层和基层干系人；横向上，按照生产工艺线和部门建立干系人名单。

接着和相关干系人进行频繁沟通，了解清楚干系人对这个项目的态度和期望目标。这个项目总投资过千万，背后牵涉的利益很复杂，不同干系人对项目的态度和支持程度差别很大，可以说这一步很关键，一定要做好干系人管理。

2、角色管理

干系人是用户代表，接下来需要按照业务抽象角色，这一步需要回答清楚这个平台有几个角色，各个角色是如何定义的？每个角色的期望是什么？他们有什么核心诉求？

这时候可以尝试以用例图来梳理。这里的角色务必要全，必须覆盖到所有用户，缺一不可。

进行需求设计时，我们就要先管理好产品的相关干系人，这里主要说的是企业角色。

3、选取典型用户访谈，摸清业务流程

在搞定干系人并确定清楚平台角色后，接下来就需要深入业务现场，摸清企业的业务流程、存在的问题/痛点。

在这一环节，前面的干系人管理好处就体现出来了。干系人会为你协调资源，安排人员和你对接沟通，在条件允许情况的下，最好深入到客户现场。

4、组织跨部门沟通，敲定方案

在摸清各个角色的需求之后，有时候还需要召集各方一块坐下来，整体过下方案，看看有没有遗漏的、需要调整的。

05

这里有三个关键点：

1）原型demo：这里不要求高保真，目的只有一个：作为与客户沟通的一个载体，能清晰表达彼此的理解即可，避免理解偏差

2）用户故事：就一个原则：应收尽收。尽可能把所有角色用户的需求收集过来。可以按照高层、中层和一线基层这种维度，也可以按照部门、工艺线这种方式，前提是覆盖面要全。用户故事也是后面所有迭代的输入物，非常关键

3）用例图：用例图是帮助项目团队梳理各个角色的业务关系，后面会和具体页面关联

在完成这一步之后，最大程度上保证了产品的主线业务不会跑偏，不至于做出一个用户不认账的产品，是能够给企业带来真正帮助的一个产品。

06

后面的概要设计、详细设计和原型设计，还是需要我们不断地和客户沟通，但不会像前期那么频繁了。

在这一阶段，有2个关键点：

1）业务流程。它关系到产品各个系统、模块、页面之间的业务流转和数据流转。在这一步确认清楚之后，可以说这个产品的框架已经出来了，后面再变的只是表单内容和页面布局、页面交互这些展现层面的东西，这些不会伤筋动骨。

2）数据库设计：这块一般是由开发完成，产品只是打辅助。这块经常出现的问题在于数据库的扩展性。数据库设计时考虑的不全面，后面客户新增一个表单、字段都需要调整很多，很显然这块是不合格的，这是我们的基本工作没有做好。

07

完成了这些工作之后，剩下的我们就熟悉了，原型设计-方案评审-客户确认-开发-测试-交付部署-上线-验收。

项目实际开发过程中频繁发生需求变更，抛开商务关系没到位这个因素，大概率是前期设计工作没有做好。

唠哩唠叨的说了这么多，都是泪。就说这么多吧，写PPT去了。

作者：小声哔哔

链接：https://www.jianshu.com/p/5e231f455e8c

来源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。