是什么原因导致了技术团队对需求理解的不到位

近日，阴雨连绵，影响到人的精气神。

于是，老板接连两天召开了两次运营和技术的会议，希望解决两个中心在日常工作中出现的沟通不畅问题。

是什么原因导致了沟通不畅，技术团队对需求理解的不到位呢？

在作者看来，可以简单归为三个因素

• 业务流程
• 职责范围
• 人

先来看看流程

在会议中，项目总监列出了当前的研发工作流程，没记错的话步骤如下：

聪明的你，可能发现了什么问题吧。

没错，在提出需求与技术评估之间，缺了一个重要环节——需求分析和评审。

在作者看来，合乎正义的研发流程，应该是这样的：

具体到不同公司，可能会根据实际情况对流程做出删减。

但需求分析和评审，无论在哪里都应该是不能省略或轻易带过的。因为这关系到往后整个技术团队对需求的理解是否充分，整个开发过程对需求的执行是否顺畅，乃至整个功能和产品的落地是否能按需完成。

那么该如何进行需求分析呢？

一是获取需求

可以分为“定性和定量，说和做”两种维度来获取，定性的说即用户访谈，定性的做即可用性测试，定量的说即问卷调查，定量的做即数据分析（可参阅苏杰的《需求采集的“Z方法”》）。除此以外，产品经理还可以通过竞品分析，了解市场对手对用户需求的满足情况，以及制作简单的产品需求收集表，对外来需求进行规范化获取。

二是将获取到的外在需求转化为内在需求

很多时候需求方都是以直接提供解决方案的方式，将需求传达到产品经理处的。产品经理应该从需求提出的原因、场景、实现成本和可获价值等维度进行分析，才能为内在需求提供更优的解决方案。

譬如，运营人员提出“想在App增加一个红包功能”，这时产品经理就不能简单照做，因为这只是一种解决方案，而不是内在需求。通过分析，得知内在的需求是，运营人员想通过一个活动或功能来提升App的用户活跃度和粘度。而要达到这个目的，其实还有多种方案，将不同方案的开发成本与产出价值进行比较估算，再择优而选。

三是对不同的需求排列优先级

较为常用的方法是四象限法则，即根据重要和紧急两个维度，划分为既重要又紧急、重要但不紧急、紧急但不重要、既不紧急也不重要四个象限，将不同的需求归入到相应的级别当中。至于如何判断哪种程度属于重要，哪种程度程度属于紧急，就需要产品经理通过与老板和各个部门沟通，以取得一个获得多方共识的判断标准。

最后是对需求进行整理归档。建立起产品经理自己的需求管理文档，便于需求实现过程的跟踪和日后回溯。

在进行需求分析后，还应该组织相关的部门和人员进行需求评审。

有时候，产品经理完成需求分析，没有经过评审就直接动手做原型，到了原型评审，才连需求一同过审，这样就极容易出现在评原型时由于需求大幅变动，导致功夫白费的情况，吃力不讨好。

因此保险的做法是，在需求分析后就组织需求评审。通过需求评审，确定本次策划需要完成的功能点一二三四，避免到原型评审时再回头讨论需求，而只对原型是否满足之前确认的功能点进行评审。这里有一个技巧，就是在需求评审（或原型评审）前就与相关人员进行沟通，争取在会议前就对需求（或原型）达成接近意见，降低在评审中遇到阻力的几率。

正因为没有重视需求分析和评审的流程环节，才导致了运营和技术在事后经常围绕需求发生扯皮的情况，明明我们运营提的需求很重要，你们技术为什么总没满足？

再来看看职责

你可能会说，需求分析没做好，沟通协调没到位，那肯定是产品经理的责任了。

也没错，因为产品经理要做的事，首先就是分析需求合理性，如果觉得需求靠谱，就应该组织相关部门进行需求评审和技术评估，如果评审有争议，还应该继续往上汇报。

我问产品小伙伴：你之前没有组织需求评审的？小伙伴说没有。

我问为什么？小伙伴说：我们产品部，是属于技术中心下面的，比技术和运营中心低级，技术中心Boss是项目总监，总监都没组织需求评审，我去越级组织不好啦。

我说那技术和运营对需求出现分歧，你也没有继续往上级的产品决策者汇报咯？小伙伴说：越级上报更不好了，运营提的需求，已经和项目总监说过，他决定做不做就行了。

旁边的运营经理听到说：那我们还不如直接找项目和技术谈，都不用找你们产品了。

嗯，真有道理啊。

从以上的对话中，可以引申出关于职责范围的几个问题。

一是需求评审要不要有？

很明显，如前文所述，这是产品研发流程中必不可少的一环，必须要有。

二是由谁来组织需求评审，项目经理还是产品经理？

要回答这个问题，必须先弄清楚项目经理和产品经理的职责分别是什么。

项目经理（Project Manager），在于将目标转化为可量化可实现的项目进度计划，关键词是项目的范围、时间、质量、成本——通过资源管理对项目的开发过程和按预期完成计划负责，偏重于执行。

产品经理（Product Manager），在于将可行的用户需求转化为可用的产品功能，关键词是产品的需求、用户、价值——通过需求管理对产品诞生后是否受用户认可负责，偏重于策划。

因此不难看出，只要是涉及到产品需求的讨论或评审，都应该由产品经理组织，而不应该碍于职位高低，将需求评审的发起权假手于人。

三是由谁来决定需求做还是不做以及需求优先级

理想的情况是，一个产品从0到1到N，产品经理全程参与。从初期的产品理念定位到往后的需求推动，产品经理都能根据自己对产品全局的理解做出判断和把控，决定做什么，不做什么。

现实的情况是，很多产品经理都是在产品研发中段（0.X）乃至产品成型后（1.X，2.x，3.x）才加入团队的。因而产品经理对产品全局的了解和把控不可能比团队早期成员更清楚，这时最佳的工作方式就是把自己定位为需求接收者，通过时间不断加深对产品的认识，再逐渐过渡到需求推动者的角色。

更现实的情况是，在中小型公司，最大的产品经理其实是公司老板。当产品经理无法或无权决定某个需求做还不是不做，哪个先做哪个后做时，就应该去找更高级的产品决策者来沟通决定，而不应该让更偏重开发排期的项目人员来决定。因为从上面对项目经理的职责描述可以看出，项目工作的重点本身就不在于需求调研分析，而在于根据产品经理给出的需求优先级，调配资源去排期实施。

要一人同时兼顾产品需求调研和项目计划执行，无异于让其左右互搏，难免顾此失彼。所以才会出现本文开始，老板抱怨项目总监对需求理解不充分的情况，所谓术业有专攻，要其透彻理解需求，还不如让其转职产品。

最后，所有问题其实都可以归结为人的问题。

规则是死人是活，不同人在不同情况，对事情往往会有不同的处理方法。但在此就不展开讨论了，遇到问题想办法解决就是。

如果你是文中的产品经理、项目总监或者老板，会如何解决呢？

作者：pmsky（微信公众号：pmskywx），互联网产品经理，曾涉足在线教育、物联网等领域，目前从事跨境电商。