需求岗如何为实施团队赋能

原创王掌柜的大排档不想延期

收录于合集

上一篇推文中提到，前阵子有个朋友跟我吐槽说：

在项目制的团队里，需求做的好与不好，对结果的影响大与不大，是很难用客观数据或感受来衡量的。

需求做得好，项目不一定能做好；需求做的不好，项目不一定不能做好。那你说需求算什么？

对此我也能感同身受。所以今天想聊一聊项目制中的需求人员如何能更好的体现自身价值？如何更多的为团队赋能？

如果有平行时空，同一个项目不同的需求人员可横向对比，能直观体现出优秀者的效率与价值。

但是在项目制的管理中，节点就在那里，功能多少及质量高低都可能浮动。项目最终都会上线，功能的完整性及严谨性从各方角度看，也不容易被明显察觉。即便项目延期了，大家也不会觉得需求要承担主要责任。

但是作为项目的源头，我们通过自身的专业性能够为团队带来很多需求内外的帮助，从一个个细节入手进行提升，最终可能汇聚出不一样的结果。

1、需求边界你不一定能做主（尽量控制、快速接纳）

抛开前期对现状的熟悉、了解过程，需求人员在开始执行需求分析时，首要任务是确认需求的边界在哪。但是需求的边界总会不可控的产生蔓延。

关于需求蔓延，即便此人非常有经验、有话语权，也会经常遇到无法拒绝的新功能，最终导致边界不可控，团队工作量超标。自己难免会失落，或受到团队质疑。但是这个问题要从两方面来考虑。

首先，蔓延是相对的。如果换个经验相对少些的人，蔓延的可能会更多。因为我相信每位需求人员都会尽己所能控制边界，我的价值也许就体现在回绝了几个别人无法回绝的蔓延需求（关于如何控制需求蔓延的一些方法和应变技巧，最近我也在总结，后面会单独展开探讨）。

其次，有一些蔓延是我们没有办法控制的。比如政治任务，比如客户的强烈要求，即便我们拦住了，需求提出方也会找到我们的领导来协调这件事。我们能做的，是在有限的范围内减少蔓延，同时更快的形成方案，形成最小化可执行方案。

同样的需求别人的方案需要100人月，我的方案需要99人月，这一个人月就是我的价值。

2、需求细节你一定能做主（结构化思考、合理化执行）

需求边界确认之后，才是详细需求的分析，以及最优解决方案的形成。也是最常规体现一位需求人员水平的阶段。

同样完成一个功能，你的页面设计更合理，对功能之间的连接、交互更清晰，所需开发的任务更少，这都是需求人员能够结合自身经验体现出来的价值。

而且我们在分析需求时，能够更快速洞察真实诉求（关于需求洞察可看底部的往期推文），能够结合结构化思维设计出更合理的解决方案，能够结合团队实际能力，做出最小化可行性方案，这都是需求人员的价值所在。

3、做好需求讲解（由浅至深、代入场景）

同样的需求，你给人讲明白需要一天，换个人讲明白只需要半天，差距自然就出来了。

而且好的需求讲解能够让客户、团队成员对你形成很好的初始印象，后续的很多工作都能更容易开展。

关于如何做好需求讲解，有很多方法和细节，要根据受众的不同、知识背景的不同、功能范围的不同、关注重点不同等，制定不同的讲解思路，同时还要有场景代入感让听众更能理解等等。最近一年我也在团队中和大家一起实践如何更好的讲需求。今天就不展开阐述了，计划下一篇再单独总结。

4、如何为开发岗赋能（业务逻辑是“大头儿”）

我们大部分业务型产品/项目，开发人员更多的是在编写“业务代码”，业务处理逻辑是否准确，直接影响到开发质量。

所以需求人员除了给开发讲明白需求，还要针对关键的业务逻辑进行讲解。比如做A功能需要从B功能拿到b数据，传给C功能的c模块进行D规则的处理，最后返回到A页面进行展示。这样一波流程图画下来，开发的设计思路就完成了一大半，设计阶段、开发阶段的效率自然会得到很大提升。

同时有机会的话可以多听一听内部的设计评审，看看开发画的流程图对不对、对功能的理解对不对，把问题提前暴露出来必定是极好的。

5、如何为测试岗赋能（需求测试不分家）

针对测试人员在需求讲解、细节确认等方面和上述的方法类似，不再赘述。测试岗更重要的是参与测试用例的评审，配合测试在写用例过程中所发现的细节性问题尽快给出合理的解决方案。

针对测试发现的某些需求未考虑的极端场景或小概率场景，现有需求不满足时，是否要“伤筋动骨”进行改造，这种权衡性问题对需求人员的决策力也是一个很大的考验。我们要基于改造的工作量、时间周期、场景频率、业务影响范围、客户舆情等多方面进行综合考量。

在测试阶段进度紧张时，需求人员也可以协助测试进行功能测试，或配合测试进行组内验收测试，或与甲方/第三方测试团队沟通细节，解释问题等。

6、如何为项目经理赋能（能多做就多做）

需求人员可以帮助项目经理完成“需求跟踪矩阵”的编写，将需求文档中的功能转化为可执行任务，再由项目经理进行分配。

可协助项目经理进行质量跟踪、进度跟踪、资源协调、客户沟通、其他项目文档编写等，也可以通过本身的沟通优势，帮助项目经理“稳定军心”，做团队内部的“润滑剂”。

7、如何为运营岗赋能（让业务更有温度）

如果团队中有运营岗位，可以协助运营更好的完成推广方案、调研方案、操作手册、常见问题答疑等相关物料（当然有些团队中这些物料产出本就属于需求岗的职责范围）。

如果涉及到运营活动、数据分析等事项，需求人员也可以站在自身对用户、功能的理解，给予相应建议。

8、总结

一句话概括：通过自身专业能力节省各个环节的时间。

而且这些事项能让我们更快速、更全面的成长、积累、突破瓶颈，从而得到共赢的成果。

需要注意的是，需求的工作没有非常统一的标准，即使是同一个公司内部、同一个团队面对不同境遇，在标准和执行层面都会有差异。在此只是根据常规情况总结了一些常见的内容。我们真正在执行阶段，还是要根据项目情况和人员情况灵活处理。只要符合自身境遇需要即可。

当我们真正得到很好的工作成果时，能力提升了，成就感收获了，外在的表彰与认可还会那么在意吗？

写在最后

需求人员到了新的团队，或者面对新的客户时，第一印象、前期印象非常重要。我们要通过日常的修炼、积累、总结，让自己能够通过专业性快速得到客户的认可、团队的认可。

被认可后，后面的工作就顺滑多了。因为你说的，别人会听，而不是不管你对不对都会先被质疑一波，那样后面再扭转局面就更难了。

所以，想给大家一个靠谱的印象，就要付出比他人更多的努力。“岁寒，然后知松柏之后凋也”。只要我们坚持，总会被觉察，被认可。

即便你已不在这个团队，他们还是会时不时怀念你。而不是看着你曾经的文档“问候你的家人”...

Ps：下一篇计划把今天没有展开的“如何做好需求讲解”结合自己的经验和团队的试验进行总结。

最近越来越感觉持续输出是一件非常困难的事，很多想法不知从何写起，写出来的内容重新审视时总会发现不足，各位如果有好的方法感谢与我分享。

欢迎各位同行关注“不想延期了”公众号

往期回顾：

如何提升测试阶段的工作效率

从收到需求到明确需求——需求洞察

开篇：真的不想延期了