产品经理该如何做项目管理?

做产品切忌“交付”心理,要有主人翁的心态。

从年初负责产品以来,我虽然有在做项目管理,但总是做得不好。 

一方面是因为个人跟进不到位,另一方面是公司也没这方面的规范和流程,而且产品话语权也弱。

总之,我个人在这方面还是有很大提升空间的。

为了精进自己这方面的技能,同时也希望自己在未来能做得更好,趁着周末向大厂的朋友请教了一下。

下面,我会结合工作中的实践和请教的内容两方面做梳理,希望能给你一些启发。

一、什么是项目管理 

在有限的时间周期内,配置合理的资源完成开发任务,并保证质量的交付产出。 

借用唐大之前提到的图,用公式来理解:资源 × 时间 × 质量 = 产出 

而产品经理要做的,就是平衡这 3 点因素,完成符合老板预期的产出。

说起来,其实项目管理也分好多种,比如运营、产品。 

接下来的描述都是基于产品,也就是开发流程做分析阐述。 

二、开发流程下,看项目管理 

先来看产品全流程,其中开发项目管理,涉及到红色框内的部分。 

01 、技术评审和定排期

在大公司里,由于产品成熟,以及代码复杂,需要开发讨论如何以低风险、低成本实现需求。

而拿我所在的小公司,这一步就简单太多了。 

通常是在需求评审上提出问题,与技术 leader 讨论实现方案,产品只需要做到这几点。

(1)实现方案不能偏离需求本身; 

(2)补充说明未来可能出现的情况;

(3)控场,避免过多的技术讨论,会后再一起讨论; 

回到项目管理,一般会给技术 1 天的时间讨论,然后同步排期时间,如下图。 

在拿到这张表之后,产品经理就需要进一步判断时间是否符合预期。

要知道,每个版本都有个大致的时间,比如两个周一个小版本,1 个月一个大版本。 

按上面这张图推算,9 天的开发 + 3天的测试(预估) = 12 个工作日。 

预估跟预期差不多,那就这样来。但如果你觉得时间长,那就要砍需求了,毕竟时间和产出是成

正比的。

当开发和产品达成一致后,需要录入比如禅道这样的内部系统里,保证项目公开透明的进展。 

02、功能开发 

在这个阶段,产品主要就是扮演“监工”和答疑者的角色。 

很多细节问题,都会在这个阶段暴露,有的需要开发内部沟通,有的需要产品拿主意。

比如开发闷头找接口找了好久,自己硬抗又不问。 

再比如之前的逻辑跟产品这个版本定的不一样,要怎么改。

当然,这些细节都会影响开发进度,而产品需要做到每日的把控:

(1)下班前开 5-15 分钟的站会,进度正常就散会,有没完成的就要说明原因了。 

PS:有点“有事启奏,无事退朝”的既视感。

(2)如果是技术难题,站会内部的开发可以先讨论,解决不了的就得叫技术 leader 来看看了。

说起来,如果是懂技术的产品,这一步还是很吃香的。

这一步的核心是:提早暴露问题,提早解决。

(3)产品发邮件同步进度给上级或老板,做到项目管理中的向上预期管理。

这一步的关键在于让上级或老板知道,你对这个项目尽心尽力的推进。

以上这些,是我从大公司的朋友那里学到的方式。

那么回到我所在的小公司,能否也这样做呢? 

我试了一段时间,风险太高了,不能做到这么细。 

至于原因,不仅是我们公司没有这种规范制度,更重要的是上级也不原因推这种伤人情的事。 

因此,我也只能退而求其次的每 2-3 天去开发那骚扰一下,问问进度和目前的问题,尽可能的掌控开发进度。 

03 、测试

到了这个阶段,更多的精力会放在统一细节逻辑上。 

要知道,开发会凭着主观意识做东西,有时候会忽略需求方案上的要求。

同时如果是 App 端,还会有两人细节做得不一样的地方。 

如果方案上写明了,开发对着改就行。 

但如果不一样,就需要产品再定逻辑,同步开发和测试了。 

回到项目管理这部分,产品经理依然可以用上面提的站会 → 讨论 → 邮件的这种方式。 

但在我们公司,测试内部会按上线时间倒逼开发赶紧改 bug,同时也会限定我们的验收时间。

其实这种方式也挺好的,毕竟项目管理不是一个人的事,而是整个团队的事情。

04、 上线

那我们公司来说,这部分是测试邮件通知所有人,说明上线时间。

当然,其中版本说明部分是由产品来写。 

到这里,整个项目管理的部分就结束了。 

写在最后 

对于管理,我一直的态度是“没有最优,只有最合适。” 

当然,还是要有一套自己的方式方法,能够达到「问题跟进」和「预期管理」的目的。 

让一切变得可控,遇到情况可解决,这也是产品经理的价值所在。

-END-

从年初负责产品以来,我虽然有在做项目管理,但总是做得不好。 

一方面是因为个人跟进不到位,另一方面是公司也没这方面的规范和流程,而且产品话语权也弱。

总之,我个人在这方面还是有很大提升空间的。

为了精进自己这方面的技能,同时也希望自己在未来能做得更好,趁着周末向大厂的朋友请教了一下。

下面,我会结合工作中的实践和请教的内容两方面做梳理,希望能给你一些启发。

一、什么是项目管理 

在有限的时间周期内,配置合理的资源完成开发任务,并保证质量的交付产出。 

借用唐大之前提到的图,用公式来理解:资源 × 时间 × 质量 = 产出 

而产品经理要做的,就是平衡这 3 点因素,完成符合老板预期的产出。

说起来,其实项目管理也分好多种,比如运营、产品。 

接下来的描述都是基于产品,也就是开发流程做分析阐述。 

二、开发流程下,看项目管理 

先来看产品全流程,其中开发项目管理,涉及到红色框内的部分。 

01 、技术评审和定排期

在大公司里,由于产品成熟,以及代码复杂,需要开发讨论如何以低风险、低成本实现需求。

而拿我所在的小公司,这一步就简单太多了。 

通常是在需求评审上提出问题,与技术 leader 讨论实现方案,产品只需要做到这几点。

(1)实现方案不能偏离需求本身; 

(2)补充说明未来可能出现的情况;

(3)控场,避免过多的技术讨论,会后再一起讨论; 

回到项目管理,一般会给技术 1 天的时间讨论,然后同步排期时间,如下图。 

在拿到这张表之后,产品经理就需要进一步判断时间是否符合预期。

要知道,每个版本都有个大致的时间,比如两个周一个小版本,1 个月一个大版本。 

按上面这张图推算,9 天的开发 + 3天的测试(预估) = 12 个工作日。 

预估跟预期差不多,那就这样来。但如果你觉得时间长,那就要砍需求了,毕竟时间和产出是成

正比的。

当开发和产品达成一致后,需要录入比如禅道这样的内部系统里,保证项目公开透明的进展。 

02、功能开发 

在这个阶段,产品主要就是扮演“监工”和答疑者的角色。 

很多细节问题,都会在这个阶段暴露,有的需要开发内部沟通,有的需要产品拿主意。

比如开发闷头找接口找了好久,自己硬抗又不问。 

再比如之前的逻辑跟产品这个版本定的不一样,要怎么改。

当然,这些细节都会影响开发进度,而产品需要做到每日的把控:

(1)下班前开 5-15 分钟的站会,进度正常就散会,有没完成的就要说明原因了。 

PS:有点“有事启奏,无事退朝”的既视感。

(2)如果是技术难题,站会内部的开发可以先讨论,解决不了的就得叫技术 leader 来看看了。

说起来,如果是懂技术的产品,这一步还是很吃香的。

这一步的核心是:提早暴露问题,提早解决。

(3)产品发邮件同步进度给上级或老板,做到项目管理中的向上预期管理。

这一步的关键在于让上级或老板知道,你对这个项目尽心尽力的推进。

以上这些,是我从大公司的朋友那里学到的方式。

那么回到我所在的小公司,能否也这样做呢? 

我试了一段时间,风险太高了,不能做到这么细。 

至于原因,不仅是我们公司没有这种规范制度,更重要的是上级也不原因推这种伤人情的事。 

因此,我也只能退而求其次的每 2-3 天去开发那骚扰一下,问问进度和目前的问题,尽可能的掌控开发进度。 

03 、测试

到了这个阶段,更多的精力会放在统一细节逻辑上。 

要知道,开发会凭着主观意识做东西,有时候会忽略需求方案上的要求。

同时如果是 App 端,还会有两人细节做得不一样的地方。 

如果方案上写明了,开发对着改就行。 

但如果不一样,就需要产品再定逻辑,同步开发和测试了。 

回到项目管理这部分,产品经理依然可以用上面提的站会 → 讨论 → 邮件的这种方式。 

但在我们公司,测试内部会按上线时间倒逼开发赶紧改 bug,同时也会限定我们的验收时间。

其实这种方式也挺好的,毕竟项目管理不是一个人的事,而是整个团队的事情。

04、 上线

那我们公司来说,这部分是测试邮件通知所有人,说明上线时间。

当然,其中版本说明部分是由产品来写。 

到这里,整个项目管理的部分就结束了。 

写在最后 

对于管理,我一直的态度是“没有最优,只有最合适。” 

当然,还是要有一套自己的方式方法,能够达到「问题跟进」和「预期管理」的目的。 

让一切变得可控,遇到情况可解决,这也是产品经理的价值所在。

-END-

发表评论

相关文章