“程序猿”不明白你一定要这么设计的原因，因为在他看来用另外的方式做也达成了一样的效果。

一大早听到群里一个惊恐的消息：

我的需求昨天晚上开会又被开发砍了，整个产品一共就两个模块，再这么砍就什么都没有了。

什么？！这年头还有开发砍产品的需求？表示不能理解。我觉得如果是市场和实施运营人员表示要“砍需求”，还有点说法，但是开发人员什么时候也能决定需求的生死了？WHY？

但是仔细回忆一下，在笔者的BA生涯中，貌似还真的发生过“砍需求”的事情。不过是BA“砍”了产品经理的需求。

那个时候我是一名小兵，对于产品经理说的所有需求，全盘接受，乖乖地去写需求规格。有一年，我们谋划要开发一个新的模块。产品经理列了一张Backlog，里面大概有100来个需求。然后我的Leader就召集了产品经理、研发经理和我这个小兵开会讨论。不到两个小时，砍掉了2/3的需求。重点是产品经理没有表示不满，大家皆大欢喜。

我们先来分析下，需求为什么会被？特别是被研发团队“砍”。原因八成是：

1. 项目时间紧
2. 技术有难度

笔者之前遇到的那个情况就是项目时间紧。其实也不紧，只是我们的流程要求我们每一个内部版本都要保证质量可验证演示。所以，我们的每个版本都基本上是0缺陷的提交。而且还要留给开发做单元测试，Code Review，定期的重构等等。

而现在很多情况下，大家都对工作量评估呈现一种乐观的态度，并且对于加班这件事情习以为常。“程序猿”砍需求凭借的应该就是觉得自己很理解需求，而且觉得自己能用最小的工作量达成要求吧！毕竟谁都不想加班。

但是今天我想说的是，这里有一部分我们的责任。

首先，你的需求是否有分优先级？

我们在做一个产品，一个模块，一个功能时，会分析这个对象的BackBone，就是组成的躯干是什么。这些需求的优先级肯定是标明“高”。这些需求绝对不能砍，砍了就会影响到用户使用，影响到产品价值和卖点，影响到产品整体业务架构。你要知道，全都是“高”优先级的需求等同于优先级都是“低”。

其次，你是否有自己的一个对计划进度的判断？

这个主要是基于经验了。有的时候一句话的需求，开发要做很长时间；相反，有的需求原型、规格描述了一大堆，开发只要半天就搞定了。而你可以根据你对于这个功能实现所需要用到的控件、接口的复杂度进行一个判断。

另外，多和项目经理、开发经理沟通。如果你无法做出判断，就需要先和开发负责人以及项目经理做好沟通。
让他们先判断哪些可能会存在技术难点，哪些需要进行架构统一规划的。

最后，要多和团队成员宣贯产品价值和理念。

这是最重要的一点。很多沟通的点在于，“程序猿”不明白你一定要这么设计的原因，因为在他看来用另外的方式做也达成了一样的效果。

因此，你需要在做分析的时候一方面需要考虑全面了，最好是“程序猿”提到的那个方案当初就被你否了，而且理由很充分；另外一方面，你需要和大家讲清楚了自己为什么这么设计，会给用户带来什么样的美好体验和不可替代的价值。

写在最后：

最可怕的是，有些程序猿GG为了省事，你怎么说他就怎么硬编码到产品里。你验收也看不出来，纯粹挖了坑给后面改BUG和做增强的人了。这可比当着你的面砍你的需求可怕多了。

好的代码是有设计感的，所谓代码之美。代码是设计出来的，不是写出来的。

作者：颜小婧，微信公众号【xiaojing-jessieyj】，与小婧同行。

来源：http://www.jianshu.com/p/40a1a107eeee

本文由 @颜小婧 授权发布于人人都是产品经理，未经作者许可，禁止转载。