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

写在前面

去年在一个项目上，甲方的CTO问了一个问题：项目与产品有什么区别？

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

但是，为什么要转？项目与产品有什么区别？

却没什么人能说得清楚。

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

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

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

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

时间框架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小结

项目

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

产品

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