不要把用户反馈当成是用户需求，深度挖掘用户的真实想法

研发团队管理者很多时候还要承担项目需求调研、分析以及系统设计工作，相当于参与了项目全生命周期流程。

如果所在公司团队工作内容分工精细，按照有专门的产品团队，需求团队和研发团队，研发团队管理者只需要负责系统功能落地设计确认评审，开发计划制定，系统实现进度以及质量监控。如果所在公司规模所限，一个软件团队也许就要承担多种软件开发角色，就像开篇所说，很可能要成为一个”全能管理者“。

实际上，作为软件研发团队的管理者，要想在职位和专业能力上获得进一步提升，不能只局限于软件研发项目管理范围内，还要对团队所负责的产品和商业方向有一定的了解。如果是项目型软件，还需要和具体的行业和客户有沟通，才能对最终软件产出有更深度的认知，产出的结果才会被市场和客户所认可。

作为团队管理者，最主要的工作是项目管理。包括项目的计划，执行监控以及最后的检查等。除了这些，还需要对上游的工作主动参与，不论是被动的（公司环境条件所限），还是主动的（主动与产品部门沟通，获得更多的信息，用于团队管理依据）。

上游工作中，最重要的一项就是需求调研和分析。团队管理者应该有这样的体验，在作为普通的研发岗位成员时，软件开发任务开始前，拿到手的就是一份详细的开发设计说明，就像照着图纸盖房子，工作结果要保证与设计一致，质量保证。当随着你的工作能力和认知能力得到提升后，你会逐渐参与到图纸的设计当中去，最初可能是局部的对全局影响不大的部分，慢慢就是核心的设计， 比如框架技术，组件选型等等。等到你成长为团队的管理者，就要对整个项目负责，不仅要清楚怎么做，还要清楚做什么，以及为什么这么做。

要想搞清楚做什么，就需要从用户那里去获知。如果是产品型软件项目，就需要针对产品的用户群体，进行市场调研，搜集需求，整理分析，最终获得产品需求，在此基础上，就可以进行产品设计，实施开发，以及最后投入市场进行运营。如果是定制型软件项目，就需要进行客户实地调研，深度获取客户需求。

客户调研中，要注意的是，不要把客户反馈当成客户需求，然后落地成产品需求。最终的软件产品，貌似是客户想要的，可结果往往不是客户实际想要的，与客户心里面的真实需求会有很大的出入。

遇到这种情况，自己还会很委屈，这是你说的，怎么又不认了么？

这个问题就是把用户的反馈当成了用户需求的结果。

比如这个事例：

客户用固话打电话，反馈电话线影响了移动便利性，只能在很小的范围里面活动，最后用户的反馈是，把电话线延长，方便接电话时候自由活动。

如果把用户反馈直接当成需求来进行后续产品的研发，用户得到的会是一个超长电话线的电话，也许行动能自由点，但是电话线容易打结，不好收纳整理，后续会有更多的问题，对于通过延长电话线获得行动自由的好处，缺点更无法忍受。

现在我们知道了，这个问题更好的解决方案是无线通信，就是手机。如果在得到用户反馈后，不做进一步的分析挖掘，得到的就是我们常说的“伪需求”。

还有一个经典的案例，就是如何提高交通运输效率，用户提出的需求是我要一匹更快的马，而实际上，用户的真实需求，以及最合适的解决方式，是造一辆汽车。

为什么会发生这种情况？这是因为用户的认知局限决定的。他们只会在自己已知的范围内提出自己想象的合适的解决方案，我们要做的，就是从这些反馈入手，挖掘客户真实的想法和需求。

得到真正的用户需求后，后续的产品需求才会建立在一个正确坚实的基础之上。