这一章讲的就是需求的事情了。最开始的这部分内容有一个观点非常重要: 开发人员要和提出需求的人一起探索。
如治疗般编程
这一小结讲的就是这样一件事。我们的开发模式就是BA报出Story，里面会提出解决需求的Solution，我们只需要用代码实现他们的Solution就好。他们也会被要求写Story的Background，但其实这部分内容，就算到现在我也只是简单扫一下，不会太关注。事实上实际开发中这可能比他们的Solution更加重要，这部分内容会更加让我们直观的明白，我们在做的Story具体是为了做一件什么样的事。
之前有一个Story，用户想在费用明细审批页面和应收应付页面加一个限制: 如果查询条件里有包含只有T charge才会使用的查询条件，则不能查出来其它的Nt以及车辆日志等费用。这个Story如果真的做的话会是一个非常麻烦而且很容易出问题的Story，最后在我们整理除了这两个页面所有的查询条件的作用范围之后，我们提供的思路是，这两个页面本身也支持通过费用类型查找，如果用户填了只能应用于一种类型的charge的查询条件的话，就把费用类型的查询条件也加上就好了，这样其实不需要开发也就满足了用户的需求。如果这个Story真的做了的话，感觉非常容易出TT。
需求是一个过程
我们的工作是帮助客户理解他们提出的需求的后果，我们在做Story前都会去先看一遍已有代码的逻辑，然后分析出新的需求对已有功能的影响。这是一件有可能比较花时间的事情，如果需求是改一个调用点非常多的函数，我们就需要看看每一个函数都是哪个功能调用到这里的，然后罗列出影响。很有可能做一个Story会有6，7个甚至10几个影响点。但是这一点也是必需要做到的，产品的稳定永远是首位。
我们的反馈有时候很难用语言表达。design中经常会用到很多图表，我就是从来不会相信其他人会很理解我说的以及我文字写的内容，图表是最直观的描述方式。
带入客户的立场
其实我们在support或者使用QA的时候，也会觉得有些功能操作起来非常复杂。比如这一轮正在做的招投标，我自己都需要看一遍操作流程介绍的PPT，BA带着我给我演示一遍流程才会造测试数据。正式因为这样的流程太复杂了，所以这部分功能才会被重构。
网友评论