从上海某资产管理公司需求调研回来已经快两周了，先说说需求调研的情况。
参与此次需求有评级组长（男）和评级分析师（女）两个人，决定权在评级组长，评级分析师提需求。
有些需求评级分析师认为应该这样做，但评级组长认为应该那样做，如果出现这样的分歧，需求分析师应该怎么办？
假如评级分析师提出的需求比较复杂，评级组长提出的同个需求比较简单，需求分析师该站谁？
我当时的第一想法是他们两个人提出的需求哪个开发起来简单？哪个最容易实现？然后我帮着哪个人说话。
其实这样的想法可以有，但都得遵守一个原则：需求合不合理。
如果需求合理，做起来复杂，需要的开发时间多，合理的需求还是要做。
如果需求不合理，做起来虽然简单，但这样的需求就算做了，客户最后真正使用的时候也不会满意。
其次，判断完需求合不合理之后，再根据开发周期，实施难度，以及其他客户同样需求的解决方案给客户一个建议。
”招商证券也提了这样一个需求，当时他们的做法是......“，客户其实也很愿意听听别人的做法是什么样，就像同年级的第一名和第二名，第二名学霸早读是先读英语再度语文，如果别人跟他讲第一名学霸早读是读什么怎么读的，他会很乐意倾听并尝试。
其实这样和客户讨论需求是很......low的，比如以下场景：
客户：“我想要一个功能，这个功能可以实现债券的评级取主体的评级。”
需求分析师：“哦......债券的评级取主体的评级（迅速做笔记）”
客户：“我想要在评级的时候，只看定性的数据，财务数据不需要展示。”
需求分析师：“评级的时候不展示财务数据（迅速做笔记）”
......
有没有发现这样的沟通虽然是双向的沟通，但实际上是客户说什么，你记什么，单向的一个交流。
要记住，客户虽然懂业务，但他说的不一定全都是对的，你需要问为什么，反驳，给建议。
重新看刚刚那个场景：
场景1：
客户：“我想要一个功能，这个功能可以实现债券的评级取主体的评级。”
需求分析师：“那是不是可以在你审核完的时候，增加一个流程环节，把债券的等级也展示出来，让你确认下？”
客户：“规则既然已经明确了，系统按照规则给债券等级就好了，不需要再增加一个确认环节。”
需求分析师：“那这样评级分析师就不能很直观的看到债券的评级了，没有问题吗？”
客户：“哦......也是，我想想......那还是增加一个流程确认的环节吧，反正操作也简单。”
场景2：
客户：“我想要在评级的时候，只看定性的数据，财报数据不需要展示。”
需求分析师：“为什么呀？”
客户：“财报数据没有必要在这看。”
需求分析师：“为什么财报数据没必要在这看？”
客户：“因为评级的时候，要调整数据的话，直接调整指标值。”
需求分析师：“为什么要直接调整指标值，而不是调整原始的财报数据？”
客户：“因为有些财报科目计算的公式，我们会调整。”
需求分析师：“财报科目的计算公式不是固定的吗？为什么你们会调整？”
......
多问几个为什么，层层深入，就能找到客户提这个需求的真正原因。
前几天听公司一个开发说他不愿意给某个需求分析师做一个需求，因为他不知道为什么要做这个需求，那个需求分析师也不知道为什么客户要做这个需求，所以开发不愿意去做这个需求，除非你弄清楚为什么。
你看，弄懂客户为什么做这个需求，不仅是对自己、客户负责，还是对开发负责，因为开发很怕返工，很不想做一些没有意义的需求。
我现在回想上次的需求调研，可能是我太自信了，很多东西没有及时与开发和测试沟通。
现在导致的一个情况就是和客户确认过的需求，开发那边提出不同的解决方案，然后这就尴尬了，又得再和客户去确认开发提的解决方案是否OK。
客户都会被烦死，从侧面也反映出我的不专业，这点我已经想好解决办法了，让客户不烦，又能确认需求。
但这种反反复复确认需求的情况一定得避免，不仅让客户烦，让自己也会很烦。
如果让我重新做，客户白天和我讨论好的解决方案，晚上我就找开发测试讨论交流，如果有问题，第二天白天再把问题抛给客户，重新给解决方案。
以上，谢谢
网友评论