“程序猿”,你凭什么砍我的需求?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

chengxuyaun

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

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

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

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

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

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

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

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

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

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

首先,你的需求是否有分优先级?

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

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

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

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

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

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

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

写在最后:

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

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

 

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

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

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

您的赞赏,是对我创作的最大鼓励。
4人打赏

评论( 0

登录后参与评论
加载中