浅析项目与产品的区别(时间框架篇)

发布时间:2020-04-20

以下文章来源于与小婧同行 ,作者小婧

写在前面

去年在一个项目上,甲方的CTO问了一个问题:项目与产品有什么区别?

现在很多企业在谈数字化转型,其中有一件事情就是要将项目制转成产品制。

1.jpg

但是,为什么要转?项目与产品有什么区别?

却没什么人能说得清楚。

最近在读一本书《Project to Product》刚好有提到这方面的问题。

作者从预算、时间窗、定义成功、风险、团队、优先级和可视化几个角度来说明项目和产品的区别。

我结合自己的一些心得和理解来和大家聊聊这个话题吧。

因为内容比较多,这依旧是一个系列文。

时间框架

项目管理有很明确的时间开始和结束时间,而且资源的投入会随着时间的发展而变化。

在盖房子这类工程的时候,这种项目制的时间框架是很有意义的。

2.jpg

因为项目有一个明确的、众所周知的结尾:房子建成后,项目进入维护期。

然而产品,无论是软件还是硬件,都有一个生命周期,而不是一个确定的终点。

3.jpg

产品可能会退市,就像谷歌已经下架了数十种产品,包括谷歌阅读器和谷歌wave。

但只要产品是可用的,我们就需要不断的进行缺陷修复和开发新的功能。

毕竟围绕软件产品的生态系统是不断发展的。

我们聊回软件项目,一般来说BA和项目经理会从头到尾的跟着项目,然后开发陆续进场,最后是测试。

接着是开发陆续离开项目,接着是需求和测试。

4.jpg

这就存在一个人可能会在同一个时间内被分配在不同的项目上。

比如作为开发在项目后期的时候,工作并不会特别多,于是可能会被book50%到另外一个项目上。

而当你在两个项目都不是很忙的时候,又会再book你25%到第三个项目上……

即便是项目结束了,你可能还需要时不时的花一些时间来support运维。

曾经有人做过调查,一个开发在一年中被分配到的项目数量平均从6个到12个不等。

研究发现,当一个人被分配到一个以上的价值流时,生产力急剧下降。

5.jpg

上面提到的一个人多个项目的可行性其实是基于两个前提假设的:一个是假设每年我们需要给项目分配这么多的人员,另一个是假设项目在维护期间不需要太多工作。

所以呢,人们会觉得每个项目只占用任何特定人员的一小部分时间。

而现实情况是:只要是产品就会需要定期进行修复。

正如我所看到的那样,这种方式成为了幸福感和生产力的主要阻力。

打个比方,有两个项目号称共用一个测试人员,分别50%。

但是只有那名测试知道,自己的工作总量肯定超过100%的,两个项目都着急的时候,没办法做到一半一半。

6.jpg

产品项目制的时间框架还有个非常大的问题就是“项目结束谬论”。

7.jpg

一般在项目研发结束后就会转交给运维。

如果软件是业务的核心,那么对于持续交付的业务结果来说,项目就没有结束一说。

而正是有了这种“项目结束谬论”,组织就看不到软件交付经济性的关键方面,比如解决技术债。

8.jpg

因为项目结束了,所以技术债也就由接盘的团队来继承了。

所以在以项目为导向的管理中,没有减少技术债务的动机。

因为解决技术债是要占用项目资源的,而反正现在系统还可以运行,我们只要保证在交付给运维团队的时候是运行正常的就好了。

9.jpg

至于技术债嘛,欠得多了才会反映出来,那会儿运维团队早就接手了,项目已经结束了,项目资源也解散释放了。

这对于企业来说是非常不利的,会导致更多遗留系统和代码的不断积累。

小结

项目

有明确的范围和开始结束时间,要在deadline之前完成项目范围,至于质量(比如技术债),呵呵(先欠着吧)。

产品

没有明确的结束时间,是一个持续交付的过程,现在在做的一切工作都是从产品的整体角度出发的。


Copyright O 2020 All Rights Reseverd Designed by Sthspace.net PICPE150170198-1