“程序猿”不明白你一定要这么设计的原因，因为在他看来用另外的方式做也达成了一样的效果。
一大早听到群里一个惊恐的消息：
我的需求昨天晚上开会又被开发砍了，整个产品一共就两个模块，再这么砍就什么都没有了。
什么？！这年头还有开发砍产品的需求？表示不能理解。我觉得如果是市场和实施运营人员表示要“砍需求”，还有点说法，但是开发人员什么时候也能决定需求的生死了？WHY？
但是仔细回忆一下，在笔者的BA生涯中，貌似还真的发生过“砍需求”的事情。不过是BA“砍”了产品经理的需求。
那个时候我是一名小兵，对于产品经理说的所有需求，全盘接受，乖乖地去写需求规格。有一年，我们谋划要开发一个新的模块。产品经理列了一张Backlog，里面大概有100来个需求。然后我的Leader就召集了产品经理、研发经理和我这个小兵开会讨论。不到两个小时，砍掉了2/3的需求。重点是产品经理没有表示不满，大家皆大欢喜。
我们先来分析下，需求为什么会被？特别是被研发团队“砍”。原因八成是：
项目时间紧
技术有难度
笔者之前遇到的那个情况就是项目时间紧。其实也不紧，只是我们的流程要求我们每一个内部版本都要保证质量可验证演示。所以，我们的每个版本都基本上是0缺陷的提交。而且还要留给开发做单元测试，Code Review，定期的重构等等。
而现在很多情况下，大家都对工作量评估呈现一种乐观的态度，并且对于加班这件事情习以为常。“程序猿”砍需求凭借的应该就是觉得自己很理解需求，而且觉得自己能用最小的工作量达成要求吧！毕竟谁都不想加班。
但是今天我想说的是，这里有一部分我们的责任。
首先，你的需求是否有分优先级？
我们在做一个产品，一个模块，一个功能时，会分析这个对象的BackBone，就是组成的躯干是什么。这些需求的优先级肯定是标明“高”。这些需求绝对不能砍，砍了就会影响到用户使用，影响到产品价值和卖点，影响到产品整体业务架构。 你要知道，全都是“高”优先级的需求等同于优先级都是“低”。
其次，你是否有自己的一个对计划进度的判断？
这个主要是基于经验了。有的时候一句话的需求，开发要做很长时间；相反，有的需求原型、规格描述了一大堆，开发只要半天就搞定了。而你可以根据你对于这个功能实现所需要用到的控件、接口的复杂度进行一个判断。
另外，多和项目经理、开发经理沟通。如果你无法做出判断，就需要先和开发负责人以及项目经理做好沟通。
让他们先判断哪些可能会存在技术难点，哪些需要进行架构统一规划的。
最后，要多和团队成员宣贯产品价值和理念。
这是最重要的一点。很多沟通的点在于，“程序猿”不明白你一定要这么设计的原因，因为在他看来用另外的方式做也达成了一样的效果。
因此，你需要在做分析的时候一方面需要考虑全面了，最好是“程序猿”提到的那个方案当初就被你否了，而且理由很充分；另外一方面，你需要和大家讲清楚了自己为什么这么设计，会给用户带来什么样的美好体验和不可替代的价值。
写在最后：
最可怕的是，有些程序猿GG为了省事，你怎么说他就怎么硬编码到产品里。你验收也看不出来，纯粹挖了坑给后面改BUG和做增强的人了。这可比当着你的面砍你的需求可怕多了。
好的代码是有设计感的，所谓代码之美。代码是设计出来的，不是写出来的。
