基于产品制与项目制的视角，对企业DevOps平台工程侧建设的思考

从产品制/项目制说起

什么是产品制/项目制？

不是管理方面的专家，本文也不是为了介绍概念，直接上AI的回答～ （纯粹为了凑字数，了解的直接跳过问答看总结）问：简要介绍在软件开发中，什么是产品？什么是项目？

❝在软件开发中：

• 产品是最终交付给用户的软件或信息系统。它旨在满足特定的用户需求或解决某个问题，并且通常是长期存在的，随着用户反馈和技术进步会不断更新和优化。
• 项目则是为了实现某个产品或其他目标而进行的临时性、一次性活动。它涉及到具体的工作任务、时间限制和资源调配，以确保在预定时间内按照预算和质量要求完成。

问：说明产品制和项目制的区别，优点缺点?

❝产品制更注重产品的长期发展和持续优化，以用户需求和满意度为导向，通过不断迭代更新来适应市场变化。它的优点在于能够更好地把握市场趋势和用户需求，提供持续的价值和体验。然而，产品制也面临较高的市场风险和资源投入压力，需要长期稳定的投入和团队支持。 相比之下，项目制更侧重于短期目标的实现，通过明确的计划和任务分配来确保项目的顺利完成。它的优点在于目标明确、资源控制严格、风险可控，有助于提高工作效率和降低风险。然而，项目制可能在面对市场变化和用户需求变化时显得不够灵活，容易忽视产品的长期发展。 综上所述，产品制和项目制各有其适用的场景和优势。在选择时，需要根据项目需求、市场环境、团队能力等因素进行综合考量。

• 对于需要长期投入和持续优化的产品，产品制可能更为合适；
• 而对于有明确目标、短期完成的项目，项目制可能更为高效。

在实际应用中，可以根据具体情况灵活调整和优化，以充分发挥两种模式的优势，实现项目的成功和产品的长期发展。

产品迭代和项目迭代的区别？

问：产品迭代版本和项目迭代版本的区别？

❝产品迭代版本通常是基于长期的产品规划和战略，对产品的整体功能和性能进行持续的优化和升级。这些版本可能包括新功能的添加、用户界面的改进、性能优化等，以提升用户体验和产品的竞争力。 相比之下，项目迭代版本通常指的是在项目的不同开发阶段所交付的阶段性成果。每个迭代版本都代表项目在某一阶段所完成的工作，并可能包含部分功能的实现或修复。项目迭代版本通常与项目的开发计划和里程碑相关联，用于监控项目的进展和确保项目按时交付。 从时间周期的角度来看，产品迭代版本通常是长期的，涵盖产品整个生命周期内的多个升级和改进。而项目迭代版本则是短期的，与具体的项目开发周期相关，通常只涵盖项目的某一阶段或某一特定功能的开发。 此外，从目标的角度来看，产品迭代版本的目标是提升产品的整体质量和竞争力，满足市场和用户的长期需求。而项目迭代版本的目标则是确保项目按时交付，满足项目合同或计划中的要求。

简要的总结

回到探究的问题

产品、项目和研发过程的数据关联关系

我们知道DevOps解决的是端到端的IT交付，从需求一直到最终的交付运营。所以肯定希望尽可能多的获取过程数据，帮助组织改进。如下所示：

• 上层管理侧，产品和工程侧的活动/数据什么关系？
• 上层管理侧，项目和工程侧的活动/数据什么关系？

比如，

• 完全产品制的管理方式，一般会通过敏捷迭代方式，那么数据、活动自然都归属产品
• 如果传统的项目制，一般就是一次性的，通过某种方式控制范围，明确数据、活动归属

但是，在研发过程侧，所有的资产（代码、流水线、制品、环境）很难说清楚是一次性或阶段性的，因为这就是“固定资产”（需要一直持续优化，而不是用完即废弃的）。

从产品制的“长期存在”的特性来看，下面的研发过程和产品是一一对应的，不存在区间划分。可是，项目制就有点尴尬了，特别是传统的项目制还偏重于精细化管理（比如CMMI的要求，各种报告），那么就面临针对”固定资产“做不同阶段拆分的问题，明确划分哪些属于项目V1.0, 哪些属于项目V2.0. 如果碰到更加复杂的项目集，多团队协同，就更难以说清楚了。

项目制精细化管理和DevOps快速交付之间的矛盾与平衡

事实上，DevOps一直崇尚的是打通IT端到端，快速交付价值，通过“2个披萨”产品团队的形式，通过迭代方式进行产品的持续演进。在我看来，这个与传统的项目制（CMMI? 瀑布？）追去的精细化管控，其实是有点矛盾的。

现实中，确实还存在这很多“从项目制到产品制”的过度地带，既有产品，产品里又有项目，项目里还有计划开始、结束等。针对上述问题，只能制定规则，寻找平衡。

1. 考虑是否有必要“项目内”的精细化管理，一定要知道项目内的产出（比如代码质量，代码提交量，部署了多少次）吗？收益价值是什么？
2. DevOps和产品制追求的目标都是一样的，快速交付价值，优化迭代，即使是评估产出，也许从需求的交付时间评估更为合适
3. 如果说，我既要产品的数据，又要项目的数据，怎么办？建立规则
   1. 说清楚范围核算区间，比如按照项目周期，这个就对执行要求很高，不然数据也会有问题
   2. 或者，从需求出发，需求关联代码提交, 进行实际核算

切忌追求过于精准，否则就是跟自己过不去，也跟研发团队过不去，多几个少几个又能怎样？

产品制下的数据关系

产品制管理方式下，更看重的是产品和团队本身的“长期健康和活力”，更看重“成长过程”，或者说趋势变化。管理过程和工程过程是有机的融合在一起的，这也是目前大多数平台采用的，针对产品（也有叫项目，其实是产品），开展研发迭代活动。

项目制下的数据关系

项目制更看重过程的监控，追求的是短期的收入产出，所以项目要不就是“一次性”，要不就是做成了”大迭代“。这种情况下研发过程的“资产”最好就变成共享资源。就是麻烦点，团队需要首先“声明”，研发过程和项目之间的关系。

最后

业界都在推崇产品制，不过实际情况，组织短期内很难摆脱项目制，或者是“从项目制向产品制过度的中间状态”。

对于企业内部的平台建设而言，需要考虑上述因素。于此同时，管理方式也需要变化，与时俱进，”轻装上路“。

仅个人观点分享，欢迎参与讨论说说你们是产品制，还是项目制？是否也遇到类似的问题？