手记

需求背后程序员的辛酸—(由APP主题颜色随手机壳颜色变化需求带来的思考)

说说最近发生的一些事情

近日 某互联网公司就因为 '主题颜色随手机壳颜色变化'而发生了一次吵架事件,后来都被开除了!

作为一名程序员,大家都知道,产品经理是需要经常与研发人员打交道的一个职业,他们也有一定的技术常识,有相当一部分产品经理都曾经是程序员,他们也开发过很多优秀的产品,后来由于自己的职业规划就转产品经理了,因此这部分人与程序员沟通起来也是相当轻松的,当然也有一部分产品经理直接就是从产品经理做起,没有一定的技术基础,他们设计出的产品更多从用户角度出发,不会过多的去考虑技术实现的问题,最近就有这么一个互联网公司的产品经理提出了一个牛逼的需求,把程序员们难倒了!

后来看谷歌最近也出了这么一个设计,如图6所示,我估计产品经理应该要的是这种效果,另外查资料得知坚果手机,一加手机,还有三星s8都有这个功能,虽然并没什么卵用!

发生这种情况,也是我们不希望看到的。作为一个程序员,我知道,根据我之前开发过的相似的功能特征,我可以估计出现在的这些功能特征各自要多少开发时间。然后,我把总时间加起来,这就得到了完成整个项目需要的大致时间。然而,事实情况中,每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间,你在遇到它们之前根本不会有所预见。它们会拖住整个项目,致使工期延后数周甚至数月。

这些是没有经验的人在评估复杂度时不会理解的。他们不明白在其他事情上都很灵的方法,为什么放到软件开发上就不灵了。所以,下一次当你听到有人说“我想你几天时间就能把它开发出来”时,不管是谁说的,都不要懊恼。深呼吸一下,告诉他这篇文章的地址,《不懂技术的人不要对懂技术的人说这很容易实现》自己该干什么还干什么。

对于产品来说

产品提出的需求,一定要是经过需求评审会的,符合实际的一些场景的。 往往一些看似很简单的需求,实际上会遇到很多坑。

提需求要有节奏感。不要误会,这个节奏感不是啪啪啪的节奏感,而是说你提的需求,要跟着项目的版本周期和实际应用场景走。

需求的来源

老板提出的战略方向的需求:老板会站在战略层的事务,在确定了产品的方向之后,他会对产品的样子有个大致的想象,有些功能是必须要有的,这时候,他会和大家讨论哪些需求建议加上去。

一、谈需求前,先明确问题是什么

问题”不是“我要一个…功能”,而是“我在做…时,为了达到…的目的,需要通过产品完成”。

二、说需求时,先别讨论解决方案

三、聊需求后,明确边界和优先级

学会拒绝不合理需求,学会正确沟通需求,这是作为一个产品经理最基本的责任;

就像阿伟大佬说的那样,一定要开需求评审会,拿出原型图,设计图,或者一些参考资料,让大家讨论一下,尽量提让大家接受范围之内的合理的需求。不要盲目给开发者开一些脑洞大开的自以为是的“神创意”!也许你无意中的一句话就被打了还不知道怎么回事。 

对于程序开发者来说

1、开发人员有质疑这个需求不合理不合理的建议

(这里切记不要说这是xxx的需求,我也认为不合理,但是没有办法,这样只会让开发人员鄙视你,造成你后续的被动,工作越来越难开展)

2、开发人员在实现需求的过程要考虑其复杂程度,如果实现起来比较麻烦,也可以和产品经理进行商讨

(产品经理和开发人员是承上启下的关系,也是完成一个需求功能不可缺少的一部分,正确的沟通和理解会让你在以后的工作中得心应手)

在工作中我也会跟开发、UI等相关人员进行激烈的沟通和争吵,但是都是基于工作需求;任何一个需求的确认如果只是平平淡淡,没有一点问题和摩擦肯定会出现问题,只有大家一起沟通确认才能让需求正确的执行。

最后

最后忍不住吐个槽。有些产品经理动不动就拉老大来给程序员施压,我觉得这种是最low的。

总之我个人认为需求的确认需要大家一起来确认,不是老板的责任,不是某一个部门的责任,不是某一个角色的责任;要适当的学会拒绝,学会沟通,才能让需求更正确的执行。

开发者很辛苦,希望可以谅解一下。

相信自己,没有做不到的,只有想不到的

10人推荐
随时随地看视频
慕课网APP