三招七式教你搞定产品经理经常加需求、改需求_产品经理改需求


上篇分享了老板经常加需求改需求的四种情况和应对方法,这篇分享产品经理经常改需求、加需求的情况。


产品经理经常加需求、改需求,主要有四种因素决定:

1)老板的瞎指挥;

2)产品经理本身的能力不足;

3)程序员的能力不足;

4)项目流程不合理和管理方法存在缺陷。


这些因素要分开来分析,不同因素引起的问题要用不同的方法来解决,不能一概而论说产品经理经常改需求、加需求是产品经理的问题。


这部分我们分成两篇文章来分享,这篇分析“人”的能力不足而引起的经常改需求、加需求的情况,下篇分析项目流程和管理方法不合理而引起的改需求和加需求的情况。


1. 产品设计流程

我们要解决产品经理经常加需求改需求的问题,就要从产品设计的过程上来分析,从根源上找到引起问题的原因,才能从根本上解决这些问题。


三招七式教你搞定产品经理经常加需求、改需求_产品经理改需求_02

产品经理做产品设计的流程有三个步骤:

1)设计产品框架

2)用思维导图设计模块、功能及功能间的关系

3)设计产品原型或用户故事


这个是简化的流程,实际流程比这个复杂的多,这篇不是讲产品设计的文章,我们就不用完整的流程。这3个步骤,每个步骤出问题,都会给项目带来不同程度的问题,甚至是灾难。


2. 设计产品框架

这个步骤,主要的工作是做产品的顶层设计,产品针对哪些用户,解决用户的什么问题,商业模式、赢利模式是什么,产品的规划是什么,分多少步骤实现这个规划,每个步骤核心要解决什么问题,以及实现计划是什么等。


一般产品经理,没有3年以上的经验,产品框架是设计不完整的。很多中小公司,为了节省成本,请的产品经理没有多少经验,甚至是老板、技术经理或UI兼职做产品经理,就会出现产品框架设计不完整的情况。这会带来什么问题呢?


1) 产品经常整个模块的调整优先级

这步缺失,带来的第一个问题:在开发过程中,产品会做方向性的、模块级的大调整。

一个模块做好了,感觉可以喘口气了,产品经理突然跑过来跟你说,这个模块优先级放低,要增加一个新的模块,这个新模块更重要,或者本来不重要的模块要提高优先级。项目时间本来就紧张,这回好了,要用更多的加班来赶这些改动。


还有,一个模块跟你讲非常非常重要,团队加班加点赶进度,胜利在望的时候,突然跟你说这个模块不做了。


2)产品不停的加功能

这步缺失会带来另一个问题:不停的加功能。

运营型的产品,运营没有效果;销售型的产品,销售人员卖不动。拼命的加新功能,加更“高级”的功能。希望通过更好的功能,来达到运营或销售的目标。

最后,大家看到自己做的产品,好高级,什么先进的功能都有,觉得行业第一。结果运营不知道从哪里下手做推广,销售不知道怎么卖产品。然后公司就糊里糊涂的关门了。


中小型公司和创业公司,这种情况很多见吧!遇到这种情况,实际上P8及以下级别的程序员是搞不定的。而很多创业型公司喜欢从一线互联网公司挖P8级的程序员来当CTO,这种公司死得很快就在这里。

如果公司没有能搞定这个问题的人(懂得顶层设计),那这家公司存活时间,跟老板、员工的努力和梦想没有关系,只跟能烧的钱的多少有关系。

三招七式教你搞定产品经理经常加需求、改需求_项目管理_03

解决办法:

1)公司有能解决这个问题的人

如果你遇到这种情况,公司有能解决这个问题的人,那就把问题抛给老大,让老大从顶层去解决。


2)没有能解决这个问题的人

像前面说的,根本解决这种问题,级别要求是比较高的。如果没有能解决这个问题的人,可以开始考虑换地方了。不过,我在《程序员为什么技术这么厉害,赚得钱却不多?》这篇中,跟大家分享如何选择职业跑道,如果你选择了这种类型公司,你可能以后的职业生涯都会在这一级别的公司上换,所以要想办法换更好的跑道

而这种类型的公司,工作实际上很累。经常要加班,身体很累;而且,你发现自己做的很多是无用功,心也很累。如果想过得轻松一点,还是有办法的。


3)治标不治本,死得舒服一点

和项目负责人(正常是产品经理)沟通版本的发布节奏,把这个节奏调快,比如2个月的版本时间,调到1个月左右。然后和负责人达成共识,这个版本要发布哪些模块和功能,评估工作量和做好计划。因为版本的发布时间很短,模块和功能不多,正常负责人不会打乱节奏。

如果还是出现要强加模块或功能的情况呢?这样肯定会影响这个版本的进度,那怎么办?比如这个版本做了一半,要强给你加一堆有的没的功能。这个时候可以和负责人谈,给一两天时间,把做好的功能产品化,提前把做好的功能上线。再重新起一个版本,新功能在新的版本开发,重新排进度。

如果负责人不同意,前面做的工作量评估和计划就派上用场了,给负责人二选一,要么用新功能替换原来安排的功能,要么延长项目时间。


这个方法有两个好处:一、快速出成果,老板或产品经理等可以快速的验证他们的想法,精力就不会放在猜加哪些功能,才能让产品更有杀伤力,然后给产品加一堆的功能。二、我们都有经验,版本与版本之间,会有空档时间,程序员可以得到休息和调整,而不是没有尽头的加班赶进度。

这个方法是很有效的,只是和负责人沟通的时候,自己的方案是要可行的。还有这个方法,只能给程序员的工作带来好处,解决不了产品核心的问题,要根本解决这个问题,是要有顶层设计能力的人来解决的。

三招七式教你搞定产品经理经常加需求、改需求_项目管理_04

3. 用思维导图设计模块、功能及功能间的关系

产品经理设计产品的步骤中,是没有这个步骤的。很多产品经理的习惯,设计完产品的框架之后,做产品原型的产品经理,就会开始设计产品原型;做用户故事的产品经理,就会开始设计用户故事。这样会带来什么问题呢?


1)实现某项业务的功能缺失

2)功能的完整性不够

3)功能间的关系不正确。


而这些问题,在项目中的表现,就是在开发的过程中,产品经理会时不时的添加小功能,或者是给功能添加步骤,还有就是调整功能关系。


三招七式教你搞定产品经理经常加需求、改需求_项目流程_05


不知大家对用例(Use Case)熟不熟悉,实际上这步做的就是用例分析。我们做用例分析,简单的讲就是分析用户与功能的关系,功能间的关系,功能与存储之间的关系。而产品经理在设计产品原型之前,通过思维导图,从容易就找出用户需要哪些功能,功能间有什么关系。不会造成功能的缺失和功能间的关系遗漏。


如果是用用户故事,在做故事路线图的时候,有点类似在做这件事,它也是在找功能间的关系,及优先级。但是用户故事已经有它自己的内容描述了,就像产品原型一样,已经不能单纯的去看功能和关系。效果没有像这样单独拉出来做好。


而且,这步做的好,程序员的需求分析都可以不做,而且评估工时,可以直接用这张图来评估。可以简化很多的工作,效率也会大有提升。


如果遇到项目过程中,产品经理经常添加功能,给功能添加步骤和调整功能关系,要怎么解决?


解决方法:

1)吊产品经理,让他把业务考虑清楚

如果你自己工作年限不长,产品经理年限长,就可以直接吊他,他没有把业务考虑清楚。虽然,团队合作精神很重要,但是,我们该表达自己不爽的时候还是要表达,不然这个问题不会引起重视,就没办法解决。

如果你有四五年的工作经验,就不能吊产品经理了,是自己的能力没有达到,也就是第二点,要学会做需求分析。


2)学习做需求分析

中级程序员有个能力,是对产品有一定的理解能力,能把模块分解成功能级。要有这个能力,就应该要懂得做需求分析。而到高级程序员,需要有产品有把控能力,能把产品分解成不同的模块,能根据不同的程序员的能力分配模块或功能,能做好这件事,本来就是靠需求分析能力。

但是我见过太多工作很多年都不会做需求分析的人,这个跟行业的发展也有关系。现在要找本像样的项目管理或开发方法的书都很难,能找到的还都是十年前的。所以,现在的程序员只关注框架、技术、工具,是情有可原的。

但是,想在这个行业混的好,需求分析能力是需要的。所以,我们经常在抱怨产品经理改需求、加功能,实际上是自己应该掌握的技能没有掌握。自己在骂产品经理的时候,是在骂自己。


3)从项目流程上来解决这个问题

程序员会需求分析,是要来帮产品经理做这个步骤吗?

不是的,这个步骤是产品经理的活,程序员在做产品评审和需求分析的时候应用这个能力,这个在下一篇项目流程和管理方法不合理引起的改需求、加需求中分享。


三招七式教你搞定产品经理经常加需求、改需求_产品经理改需求_06


4. 产品原型设计

很多小公司和创业公司,是不做产品原型设计的,可能只是几句话,去参考某某应用,就完事了。


采用用户故事的团队,很多也是不做产品原型设计。

很多敏捷团队有发现用户故事不管怎么做,在开发的时候都会有问题,解决方法往往是招更厉害的程序员,希望高手自带解决方法,还有就是把用户故事做的更重型。这些解决方案,问题会有好转,但不能根本解决。


为什么会这样呢?实际上我们从敏捷开发的历史就能发现问题:

1)敏捷开发是谁提出来的?一群技术高手。

2)敏捷开发是什么年代提出来的?90年代。

那个年代的产品,基本上没有界面上的要求,只要把字段往界面上一铺就很好了。而现在对界面的交互体验要求很高,所以出问题是再正常不过了。


我来举个例子:

作为一名程序员,我想要买一个价格在80元左右、手感好的杯子,以便于我可以用来在办公室喝水,也可以用来喝茶。


这个是按用户故事三要素来写的用户故事,基本满足3C原则和INVEST原则。

现在,让你来买这个杯子,你会买什么杯子?


三招七式教你搞定产品经理经常加需求、改需求_产品经理改需求_07


你看,不同的人,买回来的是不同的。人之间的信息传递,过程中会有20%以上的损失,所以一个需求,从用户到产品经理再到程序员,理解上的偏差就很可观了,如果没有一个统一的参考标准,不管程序员的理解能力有多强,最后做出来的和用户理解的都会相去甚远。


没有做产品原型设计,或者产品原型设计做的不好,会带来什么问题?

我们在做项目过程中,经常遇到改界面、功能微调,基本上就是这种问题引起的。


解决办法:

要有统一的验收标准。最好是有产品原型,或者有比较完整的UI交互设计。如果是用用户故事,故事要直观,理解上有歧义的地方,一定要和产品经理沟通清楚,不然就等着改需求。


对于有做产品原型,但是做的不好的团队,就需要程序员有产品理解能力(需求分析能力),在做产品评审或用户故事讨论的时候,发现产品设计上的问题。这部分的细节,我们在下一篇讨论。


作者介绍

陈华祥

18年全栈工程师,8年集团公司CTO;

项目管理、职业成长、研发系统建设专家;

《艾米视频聊天》,装机量3亿,注册用户4000万;

腾讯学院《腾学汇》项目负责人;

锐思克网络创始人

项目管理、程序员职业成长企业内训讲师和教练;

《程序员职场第1课》、《职业规划:程序员百万年薪修炼之道》、《高级程序员进阶修炼》、《项目管理从入门到精通》,作者、讲师。