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