编辑导读：产品经理的日常主要工作就是与需求打交道，如何能够快速准确地厘清产品需求，让功能直击用户痛点是很多产品经理的愿望。对于ToB行业产品来说，由于和C端产品的差异性较大，需求需要根据其特殊性进行管理。本文作者对ToB行业需求的特点进行了梳理分析，对具体的需求落实展开了讨论，供大家一同参考学习。

事情源于一个优化方案的实现。

（当时那把剑离我的喉咙只有0.01公分，但是四分之一炷香之后，那把剑的开发将会彻底地信任我，因为我决定说一个谎话。虽然本人生平说过无数的谎话，但是这一个我认为是最完美的…）

“最后一次改需求。”

卒，全剧终。

一、ToB行业需求的特殊性

人们常说猫狗大战，鱼鸟大战，星球大战，但不知什么时候开始，产品经理和开发成了一对冤家，路窄到约架脱口秀互联网专场撕逼。外行看热闹，内行也看热闹，只有当事人拽紧拳头咬着牙，在如今太平盛世，竭尽全力压抑自己绘写暴力美学的冲动。

究竟是什么让原本善良纯真的双方彼此成为了令人哭笑不得的欢喜冤家？

答案是需求。互联网行业，需求真可谓无处不在。排除某些无理取闹的要求，我们把所有对产品未来的美好期望统称为需求。有所求，有所解，一个需求的生命周期里，必然同时存在有需求方和解决者。

从事ToB行业，产品经理很容易被当作一个传话筒，仅仅作为需求对接的管道，连沟通的桥梁都懒得搭建。没有经过产品思考分析，直接把需求原材料扔给开发，注定是项目团队的灾难。

理清需求的前提，即双方均得理解需求。ToB行业需求的特殊性主要体现在以下几点：

1. 需求关系链比较复杂，需求被每个角色层层筛选或包装

这个关系链有点类似供应链的上下游关系，按照需求的流向：客户——>项目——>产品——>研发传递。

对于项目而言，客户就是需求方，项目团队就是解决者；对于产品而言，项目团队就是需求方，产品团队是解决者；对于研发而言，产品团队是需求方，开发是解决者。需求就像水流一样，每经过一个站点，其有可能被中途截断，也可能分支细流，更可能被额外汇流。

开发总是吐槽产品需求多，但殊不知这条链路波涛汹涌而来的10个需求，产品已经砍掉5个，暂缓2个，剩下3个择优选择1个交给开发……如果此时没有产品做一座舍身取义的大坝，其后果，开发可以通过小数据演算一下……

2. 需求可信度同样有些复杂，每个角色对需求的优先级和重视程度不同

当需求的河流流向最终的研发，途经的需求方没有一个是无辜的。客户有可能无心之说，项目有可能在添油加醋，产品经理需要根据目前客户、项目、产品进展和研发资源的情况作出合理的需求分析，最后才能落实到开发实现。

判断需求的真实诉求，才能找到需求方的核心想法。

客户的有些需求可能聊着聊着就消失了，这种就属于典型的“莫须有”需求；还有别看项目热血沸腾地描述产品的伟大蓝图，但其需求的目的可能仅仅只是为了维护项目和客户之间的友好关系；而作为产品的“亲爹”，子不教，父之过，孩子有啥毛病家长最清楚，但一切问题的完善都需要时间，而开发资源的博弈抉择问题一时半会是急不来的。

开发总是责怪产品需求多变，但需求的优先级和重要性是跟随着项目的进度走的。一般情况下，产品前期就已经把一切都规划好，但如果客户正常使用产品的过程都能碰见个bug，就不要怪这个bug缺陷为何成为重要又紧急的需求了吧。

3. 需求实现难度预估较为复杂，每个角色对需求的可行性评估不同

抛开“手写一个百度”、“手写一个淘宝”这种傻大粗门外汉的伪需求，ToB行业因为很多需求在确定做之前需要先给个预估结果，涉及到的知识可能深入系统底层，这时候产品需要开发以专家的角度进行需求的刨析并提供宝贵的建议。

需求实现难度预估分析，这点开发一定最有话语权，但不一定最有决策权。一旦开发掌握了需求的生死大权，那么产品的需求就只有“做”和“做不了”这两条道路，所以产品经理的可贵/可恨之处就在于从大局观思考整个需求的存在主义，并指明了第三条路：“必须做”。

而每个“做不了”的需求，不是因为需求可行性就一定差，可能因为其他原因，比如排期来不及，人员突然请假缺失，需求的拆解不到位等。如果产品经理没有一点自己的判断力，那开发说做不了，这个需求就不做了，岂不如同尸位素餐。因此我更喜欢问清楚有关需求的问题，这时候只要不是滥竽充数的开发，都会尽心尽力为你解答。

这种现象也就是开发常说的“帮产品解决了问题，结果手里剩一堆活”。但如果开发不答惑解疑，产品稀里糊涂确定了需求，恐怕到时手里就不仅仅是剩一堆活那么简单了。

我听过开发对我说过最霸气的话：“没有什么需求是做不了的，只要给足足够的时间（和money）。”早已写惯了业务的CRUD，也想挑战一下自己能力的开发，需求可行性就是个伪命题。

但对于整个产品迭代周期，项目周期而已，需求可行性不仅仅是包括实现可行性，还包括时间可行性和成本可控性。因此产品需要更多维度的考虑问题，如果开发都能够get到这些点，团队的执行力势如破竹。

二、如何把实现需求落实到整个研发团队的项目管理中？

在理清楚了ToB需求的特殊性，以及掌握了和开发沟通需求的技巧之后，接下来就要思考如何把需求的实现落实到整个研发团队的项目管理中。

目前我经手的项目研发模式比较特殊，介于敏捷开发和传统瀑布之间，各有其长，同时也有其短。

存在即合理，任何公司的研发模式必然符合其公司的业务发展；也正如其公司的人员必然符合其公司的业务要求。所以我曾见过很多很美好很完善的产品培训知识结构，但至于适不适合其从业的公司情况，恐怕就不得而知了。

我也曾有段时间也在努力探索追求产品行业的标准，但实践才是检验真理的唯一标准，有时候研发的进度就是容不下你写完一份标准的产品文档。

所以我现在很能够理解很多同行人心中的那份焦虑：既感受不到行业顶尖大厂的标准化流程，有看不惯部分创业公司的所谓扁平化管理，而在自己的公司里整天浑浑噩噩，迷茫痛苦。

我坚信一个最基本的经济学道理：任何公司，都不会养一个没有价值的员工。所以能够找到一份工作并且做下去，就证明其实员工和公司双方在现阶段是合适的。而如果我们要追求更高的方向，就必须不断提高自己，让自己兼容更强更好的公司的岗位要求，也就是在合适的时间，努力做一个合适的人，而非最优秀的人，这样也许内心的痛苦挣扎就会少些。

话说回来，如何做好需求的项目管理，同样因公司而异。我目前的产品工作模式，其实还是比较接近敏捷开发的Scrum模型。

通过JIRA这个项目与事物跟踪工具，追踪自己所提的每个需求。

一个需求单的结构体大致如下：

需求名称：【产品】XX需求

需求类型：故事/任务/缺陷

需求描述：

（1）问题/需求：简单描述产品的问题/升级点。

（2）实现目标：详细描述该需求最后完成的结果。

（3）（问题分析）：产品如果知道问题所在，可以写下自己的分析，仅供开发参考。

（4）图+文字说明

需求执行者：某开发/测试

需求Sprint：XX

备注：……

基本翻译过来就是在什么时间内，需要什么人实现什么样的需求，并且记录下来整个需求的生命周期。

而产品的项目管理能力不仅仅依赖工具的使用，而是对每个有明确deadline的需求进行有效的跟踪，避免实现需求的开发误入歧途。开发可能只负责需求的实现，但产品经理需要负责需求的验收和交付，因为开发最后可以义正言辞的声明：“需求我就是按照产品说的做的。”所以与其在最后关头互相撕逼，不如在早期就把不稳定因素扼杀在摇篮里。

（曾经有一份真实的需求放在我面前，我没有珍惜，等我失去的时候我才后悔莫及，人世间最痛苦的事莫过于此。 如果上天能够给我一个再来一次的机会，我会对那个开发说三个字：我懂你。 如果非要在这份责任上加上一个期限，我希望是……Deadline）

欲戴其冠，必承其重。戴上金箍儿，产品研发九九八十一难，其实，我们都是悟空……

作者：涛痕，公众号：一两语

本文由 @涛痕 原创于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议