七步思考法 解决你项目中的问题「项目管理七步法」

互联网 2023-03-22 15:29:07

今天给大家普及一下七步思考法 解决你项目中的问题「项目管理七步法」相关知识,最近很多在问七步思考法 解决你项目中的问题「项目管理七步法」,希望能帮助到您。

互联网行业发展的这些年,培育了一批又一批产品经理。

起初大家都统称为“产品经理”,后来进一步分成了app产品经理、网页产品经理、后端产品经理、桌面软件产品经理。到了现在,分得就更细了,可以结合类型(如社交、游戏、电商、金融),可结合模块(如消息推送、支付、订单等),也可以结合业务(招聘网站上常常出现XX业务产品经理)。

但是这些都是各个公司根据业务和发展的需求进行的区分,并不能体现出产品经理在能力上本质的差别。

甚至,很多所谓的高级产品经理和产品总监也名不副实——不过是在一家公司的一个岗位上的时间久而已,和同行优秀者相比并不具备竞争力。

那么,产品经理的竞争力体现在什么地方呢?

笔者私以为:产品经理竞争力上的差别,很大的程度上取决于其能否发现问题和解决问题,也就是是否做正确的事和正确地做事,这才是体现思维能力和思维层次的地方。

见过不少同行工作了多年还是不具备独立思考的能力,对于做过的项目还能正常推进,但是一遇到不熟悉的项目就懵逼不知道怎么入手。

笔者也经历过这样的阶段,即使到现在也不能保证项目交到手里、在没有指导的情况下也能完成。

不过,在经历过多次磨练后小有心得,形成了自己的方法论。

在此把它概括成七步:

面临的问题是什么(只能有一个)?

问题的背景是什么,利益相关方有哪些?

导致问题出现的原因是什么?

用什么方法可以解决问题?

目前欠缺什么资源和条件?

如何搞定资源?

怎样进行任务排序,时间规划如何?

以下结合案例来说明(纯属虚构)。

第一步:思考问题是什么?

S是活动产品经理,主要对接用户运营部门,跟进各类活动项目的需求-开发-上线,工作中涉及的系统有运营平台的活动管理模块及app端的活动banner位。

时间是周五下午3点,S在wiki上写完周报。虽然为了赶下周上线的排期,RD周六要来公司加班一天,自己作为负责任的PM也要来,但是最近项目进展还比较顺利,心情大好。

这时上级T在内部通讯工具里@S让她过去一趟。

T:老板刚刚组织了一个电话会议,要求下周一上线一个预约活动,运营部门已经制定好活动规则,现在开始协调库存。你出一个产品方案,找研发协调人力,明天加班赶一下,下周一晚上就上线。

相信多数PM都有经历过类似的情况,如果S是菜鸟,可能不问三七二十一就按上级吩咐的做了,毕竟有这张免死金牌也能把项目推起来。

但是结果不一定尽如人意,在研发超负荷工作的上线关键阶段,突然插进紧急的新需求,将使两个项目的质量都受到影响。

如果S是老鸟,她可能会这样思考:为什么要做这个项目?

今天是周五,虽然老板不靠谱(员工多少会有这种想法),但是现在人力超负荷的情况他是知道的。

而且开发中的项目也是一个大型活动,早就规划好了,是不论如何都不能延期的,在这种情况下还有新增一个活动,是出于什么考虑呢?

运营制定好活动规则一般会先同步给PM,为什么这次跳过PM直接汇报到老板那?运营方案才通过就开始协调库存,这个节奏也不正常,是什么原因需要做的这么匆忙?

S:我们做这个项目要达到什么目的和目标呢?

T:老板听说对手Q想要做一个与我们对标的活动,而且有可能先于我们上线,所以紧急批了预算并且找运营新加了预约的活动,目的是狙击对手和给大型活动预热,并没有具体的目标。

到这里,情况相对比较清晰了,S分析目前的情况:

有一个高优先级的项目紧急插入;

(不用协调也知道)RD资源不足,可能会顾此失彼;

以现在的资源情况,不能完全开发好活动并且按时上线。

1是问题吗?

第一感觉好像是,但是类似情况到处都有,而且没有说明危害性如何,所以这只是问题的表象。

2呢,资源不足是问题吗?

有道理,但是在互联网公司资源不足是常态,没见哪家公司因为这个原因挂掉的。

3才是问题!在项目管理里,时间、质量、成本是“不可能三角”,强行提高其中一个指标都会对其余两个指标造成影响。

现在的情况是要在短时间内以有限的资源完成项目,那么只能牺牲一部分质量。

这样问题就明确了。

第二步:分析背景和利益相关方

外部背景:

Q是公司的死对头,在过去几个月一直打得不分上下,一方有动静另一方马上跟进。现在S的公司稍占上风,目前集中全公司的力量都在设法保证优势能持续下去。

内部背景:

大家连续几个星期周六加班,已经有些疲惫,而且早就安排了研发任务,也不可能抽调更多人力投入新任务。

利益相关:

老板和上级自不用说,这个项目必须要能在他们预期的时间上线;运营方面需要尽快去了解他们的活动规则是什么,这样才能出方案;

研发方面,研发leader已经知道情况,表示后端人力都在项目上,前端有一个人力可以支持;既然做活动,肯定需要UI的支持,虽然她们在项目上,但是调整一下优先级是OK的。

第三步:分析产生问题的原因

这一点上面已经说过,是因为时间和资源没有什么调整空间,但是还要尽量保证质量。

第四步:用演绎法列举出所有可能的解决办法

用归纳法得出每个解决办法的优点和缺点。

我们假设S有这三种选择,而且很清楚地知道每个方案的优缺点。

实际上,任何一个方案都可能是个好方案,也可能是个错误,关键是需要根据实际的情况进行拿捏,选择投入小收益大的方案,这里所说的收益不单是短期的收益而且还是长期的,不单是个人的收益而且是所有利益相关方的。

比如:S可以狐假虎威、威逼利诱让RD同学加班完成项目,但是这种方案不能常用,特别是这样做对公司没有带来什么好处的时候,因为这既伤害了长期利益也伤害的别人的利益。

第五步:分析现在还欠缺的资源和条件

假设S和上司、老板、运营都沟通完毕,确定了选择第三套方案。现在S需要需求文档、前端、UI、QA资源,还需要使用公司统一的外部表单账号,所有这些到现在为止都没有确定。

第六步:搞定欠缺的资源

需求文档S自己写就行,因为是项目组的组织形式,所以前端、UI、QA都挂在一个leader下面,而且他已经得到了新项目的消息,S和这个leader沟通一下方案即可。

表单工具的账号还未注册,而注册表单账号需要使用公司的对外邮箱,邮箱由项目组内的一位同事负责。

第七步:要做的事情清楚了

S罗列出先后顺序(创业公司的节奏)。

这样整个方案就出来了,之后按照计划执行即可。

很多情况下,当PM对配合的团队和流程熟悉后,对于简单的项目,在无意识中就可以完成思考。

但是对于复杂的情况,特别是涉及面广、牵扯的团队多、项目流程长、不可控因素多的时候,是很有必要进行方案拆解的。

拆解的能力非常考验PM的功力,也是很多招聘者在面试中喜欢考的问题。

而且不止于此,在日常生活中,如果好好培养和运用这一能力,很多问题将迎刃而解,生活效率也将得到提高,这里就不具体举例了,读者感兴趣的话可以试试。