初级项目经理巨坑之范围篇：需求和期望管理

李强~ 2023-07-25 13:03:11

今天看到小伙伴一脸痛苦，出于对小伙伴的关怀上前问了下情况，小伙伴跟我说他很痛苦，项目的需求控制不住了；详细了解之后才知道：小伙伴只对接了信息部门的文员，接到的需求也都是从业务部门调研到的，也没有经过签字确认；在对小伙伴表示慰问和同情后我陷入了沉思。

软件交付行业近年来业务增长很快，对人员的需求量也大，导致大量非项目管理专业的互联网软件人才进入到软件项目管理岗位，虽然他们的基础能力很强，但是缺乏项目管理的基础导致前期疯狂踩坑，不得不说，确实很难受。

针对小伙伴这种情况，来聊聊软件交付中的需求和期望管理。

一、期望——没有写下来的高层级客户需求

被互联网行业大潮影响，现在从业人员总会把“需求”和“痛点”挂在嘴边，项目管理从业人员也开始这么叫了；当然这么叫也没错，只不过是把范围这个概念换了个称呼而已，但是换完称呼后少了一部分内容就不对了，没有人关注客户期望了。

回头想想，为什么我们在做这个项目——不就是领导们冒出了个想法，想让我们实现嘛。

举个例子，领导有一天突然把小张叫过去说：“我们要做个电商功能，满足商家可以上传商品，用户可以查看和购买，跟淘宝差不多就行”这个时候小张马上列出需求功能清单，找到产品经理开始研究淘宝，两个月之后项目还没上线，小张被领导一顿骂：“就一个上传商品和购买功能做这么久，你们团队平常在干嘛，发呆么！”小张抱着抄了一个多星期淘宝的PRD躲在角落里哭泣。

小张做错了么？

错了，从一开始就错了，他错误的理解了领导的期望，本以为领导想要个淘宝的功能，但实际上领导只想要个淘宝的UI，满足上传商品和购买就行了。

这种情况就会导致项目延期以及出现功能冗余。

当然，错误理解客户或领导期望的情况不只这一种，但无论是哪一种，如果出现了，就会对项目造成伤害。

Tips：各个层级的客户或领导沟通，了解清楚他们真实的期望，是想早点上线，还是想界面美观、还是功能完善，了解清楚再动手，毕竟有了方向后，不管走哪条路都一定是对的路。

二、确认——容易被忽略的过程

需求的确认简直是一件太常见的事了，无论是纯做互联网产品的公司还是做软件交付的公司中，每天都能听到几次需求确认的信息，但是能把需求确认这件事做好的不超过一半。

在互联网公司中，由于需求太多，提出方也太多，可能是老板提的、用户提的、运营提的、商务提的，这种确认就很难做；一些做的比较好的公司，会定期发布版本更新计划，但会不会按照更新计划来执行就又另说了。

确认环节分为两个重要的点——确认和执行

1. 确认

小的互联网公司或者多数软件公司都存在的一个现象就是：接到客户/用户的需求之后马上行动，最后导致客户不满意，并且反悔说类似“我没说过这个”“这不是我想要的”云云。

正确的做法麻烦一些，增加一个确认的步骤：

比如，如果你是产品经理，接到了大量的用户反馈，说“我希望食堂的门可以换个更鲜亮一些的颜色”；这时候你需要做的不是去调研哪些颜色是鲜亮的，而是准备好你的方案后找用户沟通“为什么你希望换鲜亮的颜色呢？”“如果换成这个颜色是不是可以呢？”在得到大部分抽样用户的肯定后再执行；

再比如，如果你是软件交付的项目经理，客户说“我希望在这里加一个XXX功能”，你需要做的同样不是直接找产品经理和工程师们去执行，而是跟客户沟通好需求的细节后，出一份写明功能点的确认单据，让客户签字。

2. 执行

其实需求确认不是一件难事，难得是确认后的执行——完完整整地按照已确认的需求执行任务。

中国社会是一个人情社会，很多事情有时候按照规章制度执行会被人情往来给阻断，这是很正常的一件事，但往往就因为XXX的项目特别紧急、XX总的需求优先级比较高，就把已经确认的计划打乱。

这里给初级项目经理或者是产品管理者一个建议——强硬一些！

从规章制度确立到执行，是要有一个适应的过程的，如果项目管理者或者产品管理者都没有执行规章制度，只会让同事们更加肆无忌惮的无视这些制度；但这些制度却是保护我们的，所以拒绝他们你没有做错。

Tips：需求确认过程是比较麻烦且没什么技术含量的一个过程，但是却是实实在在保护项目/产品管理者在管理进度工作的重要法宝；多数项目经理和产品经理没有意识到它是在保护自己，所以才不去执行；如果你是项目经理或者产品经理，谨记你有这个隐形法宝傍身，一定要好好使用！

三、控制——保证双方利益的方法

“需求越做越多，做不完了”“客户又要新增加功能”“销售又承诺客户俩功能，这项目没法做了”

做项目管理这几年，类似的话从产品、项目、研发同事口中听到了太多次了，最开始还老好人一般的上前安慰两句，沟通一下出现这种问题的原因及解决方案；现在已经不管了，一个是没有人听，一个是自己已经习惯了这种被迫加班的情况，改变太麻烦（说实话这个理由我真心接受不了）。

无论是做项目管理还是产品管理，需求的控制一定是重中之重，常见的需求控制场景主要分为三种：减少、新增和替换，其中需求减少的情况太过少见，而且属于比较良性的变更，不做讨论，主要聊聊新增和替换：

1. 新增

需求的新增是几乎所有项目经理和产品经理在工作过程中一定会遇到的场景，我们针对敏捷开发方式和瀑布式开发方式分别聊一聊新增需求的处理方法：

在敏捷开发方式中，工程师们按照产品负责人写好的故事点进行有稳定的迭代，在突然接到新增的需求后，产品负责人需要去判断这个新增的需求对于产品架构的影响——是否影响已完成的迭代，或者对后续的迭代计划有很大的冲突；

如果没有很大的影响，那么直接更新到后面的迭代中就好；

如果是对当前故事点有影响，最好能拒绝就拒绝，拒绝不了尝试在本故事点后插入一个新的故事点来满足这个新增需求，最坏的办法才是加班满足，毕竟这样对测试的压力还是很大的；

如果是对整体很大的影响或者冲突，那么建议产品负责人反思一下产品架构的设计，并跟高层商量一下重构；

在敏捷开发环境中，需求的控制方法并不是直接控制需求，而是是否遵守“敏捷”规则，如果不完全使用“敏捷”规则，而是敏捷与瀑布式集合，那么就比较容易出现很多问题，其中无法控制需求就是一个比较严重的问题。

在瀑布式开发方式中，需求的提出方大多数是由客户来扮演的，所以控制需求相对比较容易一些，比如可以尝试这些方法：

①谈钱：商业行为中最合适的就是谈钱了，如果客户提出新需求，作为项目经理分析之后给出报价，双方开开心心地签合同执行，这是最好的结果；

②谈影响：多数情况下遇到的麻烦事就是客户突然找到你，说必须在这个月上线XXX功能，否则不给签验收；初级项目经理很容易就被客户吓到连夜组织工程师赶工，拼命把新需求上线，最后因为严重压缩开发和测试时间，质量一塌糊涂；

其实遇到这种情况的时候，安心跟客户谈影响就好了（你吓我，我也吓你），首先你需要掌握客户的角色以及想要新增需求的原因，然后跟客户一起坐下来讨论一下强行新增的影响：质量无法保证、进度无法保证、成本严重超支；而你和客户都是无法承担这些后果的，讨论之后的事情多数就会对你有利了，比如客户被吓倒了，收回了新需求，再比如客户确实急，然后去协调你的领导给你增派资源解决当前问题。

2. 替换

需求的替换，其实就是先减掉某个需求，再新增某个需求，控制好成本和资源就好了。

Tips：需求控制是在生产环节最重要的一环，项目经理与产品经理都需要有足够的控制力，来掌控生产工作的范围；

而提升自己控制力的最好方法就是严格执行制度，公司有相关制度就要带领伙伴们一起执行；公司没有相关制度就自己制定一个制度，来约束伙伴们的行为；

另外，如果你能自己制定制度，那么这个制度就可以成为你的方法论，甚至可以升级成为公司级别的方法论，大家加油！

四、识别——影响需求的因素早知道

这里的识别主要指的是针对影响需求和期望的风险进行识别；

其实针对需求的管理，讲完识别需求和期望、确认需求和控制需求后基本就结束了，但是作为一个经常被客户折磨的项目经理，还是想多唠叨点关于识别风险的事情；

对项目经理群体来说，识别风险这件事就是日常工作；这边想要提醒的是初级项目经理，因为多数初级项目经理是不会习惯于去主动识别风险的，而是风险已经发生，甚至风险已经升级到问题的时候，才去着手处理问题，这是很不好的习惯；

针对需求和期望的管理，建议多与客户沟通，及时识别能够影响客户需求和期望的因素；举个相对应景的例子，如果你做的是一个社区管理软件，当疫情刚刚爆发的时候，是不是就会有健康情况上报的隐形需求存在，而疫情爆发这件事就一定会影响社区的管理者，这就是一个对于项目有影响的风险，其他同理，需要多交流，多识别，多想；

对于产品经理群体来说，多数产品在识别风险这个方面做的并不多；建议产品经理们也培养一下识别风险的习惯；高阶的产品经理其实已经在做这件事了，而他们把识别风险称作“掌握市场动态”；

这边建议初级产品经理也经常关注一下市场动态，了解了解当前的市场环境与经济环境，带入自己的产品思考一下：这个热点会不会对我的产品有影响等等。