产品研发的过程一般是以项目形式进行的,企业决策层决定要进行某个产品的研发后,通常会正式立项,从各职能部门抽调资源组建项目团队,根据产品需求制定项目计划,组织项目资源按计划推进研发工作。
这个过程涵盖了企业研发部门主要工作内容,包括产品需求、资源团队、工作计划、项目质量、问题风险、成本预算和项目交付件等内容。如何保障项目工作有序开展,研发以外的职能部门资源拉通,让资源得到合理利用,是所有科技研发企业需要思考的内容。

项目不只是研发工作推进组织形式,也是企业研发资产沉淀的过程。不管项目规模大小,单纯依靠项目经理个人能力来管理项目是非常困难的,一个好的项目管理工具可以给项目管理起到非常大的帮助。
科技型研发企业能够生存下来,应该都有几款成功的产品,但这些产品的成功,是偶发的个案,还是能够被成功过复制的经验?如何确保成功的经验能够被复制?这是大部分研发企业在思考的问题。
然而,没有合适的项目管理工具,项目的管理人员各师各法,没有统一的平台跟进项目过程,是科技型研发企业的困惑。不像ERP,只要提到ERP大家就能想到SAP和Oracle。
在研发项目管理的细分领域中,没有一个能让所有企业都高度认可的产品。究其原因,项目管理终归不是一个工具软件,没有类似会计准则这样的标准,一个系统无法全面覆盖各个企业的不同管理思路。所以会出现某个项目管理系统在一些企业用得很好,但在其他企业却总被诟病。
不是这个项目管理系统不够好,而是不同的企业的管理思路,甚至同一个企业中不同的项目管理人员的管理思路都可能不一样,导致大家对项目管理系统有不同的意见。
我们之前文中讲到的IPD就是一个很好的管理思想,它把研发当成一种投资来管理,依靠企业中的重量级团队来对投资进行决策,避免企业过度依赖个人英雄主义。所以,如果我们能将具备可复制成功经验的IPD思想,融入到一个项目管理系统中,理论上就可以统一企业中项目管理思路,让各项目都按照系统中固化好的先进管理思路来跟进项目,或许能够解开研发项目管理的困局。

从前面的章节中可以看出,产品集成开发更多的是从产品角度进行研发业务管理的,而实际的研发过程中,都是以项目的形式跟进产品研发过程,所以项目是产品研发的过程管理,产品是项目的产出成果。
产品和项目的关系并不完全是一一对应的,比如企业可以以产品平台来立项,然后根据市场差异化的需求,从成熟的产品平台衍生出多个产品;也可能把一个复杂的产品研发拆分为各自相对独立的多个项目并行推进,从而缩短产品研发周期。

如上图所示,IPD是一套完整集成产品开发方法论,涵盖了产品从规划到退市整个生命周期管理。大部分的项目管理工作,是从Charter Development开始,到Launch Phase结束的。项目过程中生产的产品、Part、BOM、图文档等,会随着项目推进,不断的更新、迭代,当产品到达量产状态,这些数据也最终得以定稿。
所以,我们可以简单理解,项目管理就是研发过程管理,管理研发过程的进度、交付物,本质是由交付物驱动的研发项目管理过程,是PLM系统中非常重要的一环。

因为接下来要聊的内容会和项目的管理方式有关系,所以先讲讲我们常用的瀑布和敏捷管理。根据项目情况和团队习惯,不同的项目可能会选择不同的项目管理方式。

例如软件类项目,选择敏捷管理的可能性会大些,如果软硬件结合的项目,选择瀑布方式可能会更合适些,当然也可以混合使用。

这样就要求项目管理系统有足够的灵活性,因为瀑布依赖传统的完整计划管理,而敏捷通常需要支持scrum、Kanban等。从根本上讲,不管是传统的计划还是敏捷的backlog,都是组织项目工作的容器。
项目团队可以将工作项全部加入到计划中,按时间、资源、依赖关系等制定瀑布式的计划;也可以使用scrum,将工作从backlog中,按需拖到sprint中管理。这样,在同一个项目中,可以让不同的团队按照自己习惯的方式进行工作跟进。
根据实践经验,我们建议将计划、scrum、Kanban等用来组织项目中工作项的容器做成系统组件,这些组件可以提供选配能力,让项目管理人员可以根据项目特点按需配置,选择需要启用的管理组件,这样虽然系统实现层面相对会复杂不少,但从用户使用角度会方便很多。

在大部分的企业中,研发项目的立项工作都是线下进行的,项目管理系统只管理立项后的工作内容。但实际业务中,立项过程却非常复杂,需要项目发起人提前做市场调研、需求分析、技术风险分析、成本分析、制定资源计划等,这些工作需要协调市场、研发、财务、采购、计划、销售等部门提供支持。这些复杂的工作应该有项目管理工具给予支持,让项目发起人能够通过系统跟进整个过程,协调各领域参与人完成立项准备工作。

项目发起人在启动上述的具体工作前,可以使用系统中的项目创建功能,创建一个研发项目,立项和后续的管理工作就基于这个系统上的项目开展。立项只是项目开始的第一项工作,最终这些项目能否立起来,还要看企业高层对项目投入产出的风险评估,所以,项目在系统中刚创建出来,需要通过待评审的状态来标识,待完成前期的立项准备工作,通过立项评审流程后,项目状态通过流程驱动,自动变成已立项,否则状态更新为废弃。

在立项阶段,外部主要的输入为市场需求,管理好市场需求有利于企业端到端跟进需求到产品实现的整个过程追溯。系统提供需求管理的功能,记录需求来源、优先级、领域等基本信息,并建立需求评审流程,规范需求管理过程。系统需要能够对需求进行分类,并支持不同分类之间的转化或分解,比如,从市场部门、客户处获取的需求,为市场需求,这些需求往往比较简洁、概要,未梳理出详细的需求规格和价值点,产品经理在立项工作中,需要组织团队对这些市场需求进行分析,梳理出需求价值、规格、优先级等信息,从而判断市场需求是否纳入到产品规划中。被纳入到产品规划中的市场需求,通过系统的转化功能,变成产品需求。这个转化或分解的过程,逐步标准化后,可以在项目管理系统中形成固化的需求评审流程,从而规范团队的需求管理。
除了需求管理,立项工作中技术风险分析、成本分析、资源计划等工作通常是以文档的方式进行交付,项目发起人可以通过任务的方式跟进。待各领域工作完成后,由项目发起人在系统中发起立项评审流程,流程中最主要的内容是由项目发起人输出的立项报告,立项报告汇总了项目需求、风险、计划等前期各领域工作的主要成果,并关联各领域的交付内容,给参与流程审批的研发领导和高层查阅。
在项目管理过程中,把关键阶段定义为里程碑点,每个里程碑点需要完成哪些工作,需要在什么时间完成,这样一系列的里程碑点组成完整的项目里程碑。通过项目里程碑,能够清晰的知道当前项目所处阶段,帮助项目管理人员判断风险,管控进度。关于项目里程碑点的定义,我们可以参考IPD中的决策评审点(DCP)和技术评审点(TR),将他们作为项目的标准里程碑。如下图是某企业DCP和TR:

里程碑点可以关联计划中的关键任务,通过任务进度来驱动里程碑。例如,我们可以创建一个Charter评审的任务给到项目经理,当项目经理完成该任务后,里程碑就进入下一个阶段。因为各项目的复杂程度不一样,系统要允许项目管理人员可以对标准里程碑进行删减,形成符合自己项目要求的里程碑。里程碑可以看成项目计划的一部分,当里程碑延迟了,系统需要自动告警。
