17 | 程序员也可以“砍”需求吗？

需求管理中印象最深的是刚进入开发行业时的一段经历。当时要显现某种单据，单据本身还嵌套子单据，原始需求是单据按层次显示，但某变量等于某个值时，某层次的单据就隐藏，但它的再下一层子单据需要显示。解决方案简单可以理解成页面要用递归方式才能正确显示。当时一心想显示自己牛鼻，因为无法用通常的页面模版机制，就自己写工具递归生成页面代码，看起来代码很巧妙，但别人难以维护。后来有段小插曲，若干年后项目移交到另外一个研发中心时，还需要有人专门去讲这段代码，否则接手人很难理解。再说回到之前，开发完后有一次和业务分析员再次聊起，说这个很不好实现但我啃下来了等等，他说那可以不用隐藏，显示空白层也可以，真如果这样实现就简单多了，也好理解多了。事不大，但在职业生涯里印象深刻。需求不光是拆解，更可以讨论后寻找简单解决方案，而不是用自以为牛鼻的代码实现。以更合理的成本实现需求交付价值，这其实是用户故事里Negotiable的意义所在

工作中，我也砍过不少的需求，和老师的思路类似，就是拆细需求，一个个地去砍。 比如，上节课的登录注册。我会这样说，如果完全按着这个需求来的话，肯定是完不成的，即使加班加点，最后也是一堆bug。 不如这样，图像验证码前期就够用了，短信验证码放到后一个版本吧？还有前期用户量不多，分布式也就放到下一个版本吧？ 这样的话，我们的工作就是XXX，在这个时间内，还是能赶出来的。

愿上帝赐予我能拆分需求的智慧……

我对需求的理解分两个层面：用户需求和开发需求。在尽可能全面了解客户意图的基础上突出价值，通过开发需求框定范围。以往会形成两份不同的文档，主要是考虑到双方的知识背景不同而有针对性的准备，至于开发需求的误差程度往往得不到客户的有效确认，因为客户不习惯以程序员思维和工作模式去阅读开发文档，常常会给基本上是这样、差不多吧、先这么着看看这样的反馈。所以我在想应该可以用一种更“活泼”的方式去提高双方的沟通效率，如果能够以故事的方式去撰写用户故事，把问题拆分說透，用一个个能让对方身临其境界的场景故事去沟通，而非格式化的冷冰冰的文档去消除双方认知上的不足与分歧，这样除了可测试之外其他方面应该都能兼顾了吧。

进行开发之前先把需求理解好，也就是要做什么，然后进行需求的拆分，也就是怎么做，到这时候有些用户故事肯定会由于某些原因做不了，就砍掉，再然后对需求进行排期。所以拆分需求的过程也是梳理项目的过程。

要看公司，很多公司很多需求是老板提的，老板和产品都是强势方，这种情况是没法砍需求的

拆分业务需求有3个好处：砍掉实现成本高及体验不合理及价值不高的小点；方便后面的开发任务的排期；加深对需求的理解

砍需求非常不错，扩展我的知识的广度。谢谢！

“很简单，把它拆分成多个小任务，这样一来，每个小任务都可以在一个迭代中完成了。”这句话没看太懂，拆分完之后需求并没有减少，为什么说小任务可以在一个迭代中完成呢？

老师，今天的内容，能不能理解为需要先将用户故事切分的足够小，然后以此来做需求合理性、工时评估、需求的降低标准等事情呢？