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

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

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

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

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

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

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

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

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

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

比如这个事例:

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

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

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

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

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

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

你可能感兴趣的:(不要把用户反馈当成是用户需求,深度挖掘用户的真实想法)