0°

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

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


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



嗯。。。。什么?这年头还有开发砍产品的需求?

理解不能。

我觉得如果是市场和实施运营人员表示要砍需求,还有点说法,但是开发人员什么时候也能决定需求的生死了?


但是仔细回忆一下,在小婧的BA生涯中,貌似还真的发生过砍需求的事情。

不过是BA砍了产品经理的需求。


有一年,我们谋划要开发一个新的模块。产品经理列了一张Backlog,里面大概有100来个需求。

然后我的Leader就召集了产品经理、研发经理和我这个小兵开会讨论。不到两个小时,砍掉了2/3的需求。

重点是,产品经理没有表示不满,大家皆大欢喜。



我们先来分析下,需求为什么会被砍,特别是被研发团队砍。

原因八成是:

1.项目时间紧

2.技术有难度


我之前遇到的那个情况就是项目时间紧。

其实严格来说也不紧,只是我们的流程要求我们每一个内部版本都要保证质量可验证演示。

所以,我们的每个版本都基本上是0缺陷的提交,而且还要留给开发做单元测试,Code Review,定期的重构等等。



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

而现在很多情况下,大家都对工作量评估呈现一种乐观的态度,并且对于加班这件事情习以为常。

程序猿砍需求凭借的应该就是觉得自己很理解需求,而且觉得自己能用最小的工作量达成要求吧!

毕竟谁都不想加班。



但是今天我想说的是,造成这种状况有我们的一部分责任。


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


我们在做一个产品,一个模块,一个功能时,会分析这个对象的BackBone,就是组成的躯干是什么。

这些需求的优先级肯定是标明“高”。

这些需求绝对不能砍,砍了就会影响到用户使用,影响到产品价值和卖点,影响到产品整体业务架构。


你要知道,全都是“高”优先级的需求等同于优先级都是“低”。




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


这个主要是基于经验了。

有的时候一句话的需求,开发要做很长时间;相反,有的需求原型、规格描述了一大堆,开发只要半天就搞定了。

而你可以根据你对于这个功能实现所需要用到的控件、接口的复杂度进行一个判断。



另外,多和项目经理、开发经理沟通


如果你无法做出判断,就需要先和开发负责人以及项目经理做好沟通

让他们先判断哪些可能会存在技术难点,哪些需要进行架构统一规划的。



最后,也是最重要的一点:要多和团队成员宣贯产品价值和理念


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

所以,你需要在做分析的时候一方面需要考虑全面了,最好是程序猿提到的那个方案当初就被你否了,而且理由很充分。

另外一方面,你需要和大家讲清楚了自己为什么这么设计,会给用户带来什么样的美好体验和不可替代的价值







写在最后

最可怕的是,有些程序猿GG为了省事,你怎么说他就怎么硬编码到产品里

你验收也看不出来,纯粹挖了坑给后面改BUG和做增强的人了。

这可比当着你的面砍你的需求可怕多了。


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





小婧是一名行走在产品路上的资深业务分析师(BA),想和小婧一起同行,就请关注“与小婧同行”吧!

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


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论