【分享吧】将需求“挖”出来、“转”出去

  你是否遇到过这样的场景：面对客户不停修改的需求，一遍又一遍的重构代码，叫苦不堪；面对客户的“多变”需求，而束手无策。
  遇到这种情况大概是出了这两个方面的问题：

1、始终跟着客户走，没挖出真正的需求。
2、把业务照搬到设计，没有“业务建模”。
  比如，某天客户说，我要查一下最大学号的学生信息。你一想，这个简单啊，代码信手拈来：

  第二天，客户说，我要查一下第二大学号的学生信息。你一想，按照昨天的思路，稍加改动就能实现：

  第三天，客户说，我要查一下第三大学号的学生信息。
  你眉头一皱，默念：休怪我恶心，大笔一挥，“套了三层”。
  。。。。。。
  第四天，客户刚要开口，你抢答道，你要原本就是要查第N大学号对应的学生信息吧？客户点点头。

  你眉头紧锁，这太变态了吧，我总不能一直“套下去”吧。百度了一下，还好有“开窗函数”救命：

  第五天，客户说，我们系统要迁移到mysql上，你的“开窗函数”用不了了。
  你身心疲惫，抱怨客户不一次把需求说清楚，抱怨业务实现难度太大。

  ①客户自身的想法从来没变过：根据学号的大小来找学生信息。但由于客户对IT领域的不了解或者是业务本身存在的一些变化，导致我们接收到的信息都是具体的，杂乱的，不成体系的。如果完全跟着客户的想法，说一做一，虽然可以在初期快速响应，但当客户说出其“真正的想法”时，我们发现前三天的工作白费了。

  当客户提出“取第二大学号的信息”时，我们是否能意识到客户的真实想法。如果我们意识到了这点就应该尽快与客户进行沟通，梳理出其真实的需求，给客户提供完整的解决方案。尽早统一认识，确定具体的IT解决方案，一方面有利于让客户对我们的IT能力产生足够的信心，便于后期与客户对细节问题讨论。另一方面可以尽量减少设计人员、开发人员在实施过程中，由于所谓的客户“变更”，而频繁重构代码，降低工作效率。

  ②“查指定第N大的学生信息，可以在不同数据库上执行”，其实对于这个问题也是计较“棘手”的。按照客户描述的处理逻辑：先排序，然后从第一个开始数，直到N为止，将其返回。按这个逻辑写标准SQL也是比较难实现的。
  这就需要我们对问题与客户进行重新的梳理，转换思路：将“取第N大的学生信息”转化为“某条学生信息是否能被查出来，是与他前面有几个人有关系”。如果与客户就这个转换达成一致，那么处理就方便了：什么是第N大？第N大就是前面有N-1个人嘛。这样就可以将参数N与大于这条记录的个数作为查询的条件，而得到以下的解决方案：

  过程中，如果完全按照客户说描述的处理方法来实施是很难的。这需要我们在充分了解客户需求后，要对其进行转化。转化成可实施的，高效的，符合IT标准的解决方案，保证开发效率。当然转化的过程和结果要与客户进行充分的沟通，以便于客户理解整体的实施方案，便于后期的验收，变更。
  客户懂业务，我们懂得IT，我们的价值在于做“业务”与IT之间的转化器。
  与开发的兄弟姐妹们坚守，共勉。

END

【分享吧】将需求“挖”出来、“转”出去

浏览过的版块