大公司一般都有专人负责项目管理，但小公司基本上都是产品直接负责了。这种情况怎么破？本文从项目立项准备到跟进到结项三个环节，和大家分享项目管理的实战经验，供大家参考。

越来越多的公司对于公司内部的产研流程，不仅仅是敏捷流程管理，开始以项目制+敏捷进行运作了。中大型需求走项目管理，日常需求走敏捷组迭代。而并不是所有公司都会配备专业的项目经理，产品在一定程度上会承担项目经理的工作。在我司，就是产品不止是Product Manager，也是Project Manager。那么接下来就分享作为一个“非专业”的项目经理做项目管理工作的一些经验和心得。

以下以“账务集成项目”为举例说明，作为产品经理和项目经理，不止承担了主产品的职责，也承担了项目管理的职责，所以接下来分别从立项准备、项目过程跟进、项目结项三个环节来介绍项目管理的实战经验。

一、项目立项准备

立项前的时间范围，从接到需求或项目开始，到正式项目委员会立项完成。

1.1 前期需求调研

（1）针对目标用户，调研使用场景，了解业务流程，明确需要解决的问题，对应当前业务的现状需要以数据进行呈现，如处理一个流程需要经过步骤。以下并不是作为产品设计，所以如实了解和整理即可：

目标用户：财务核算

业务场景：线下入账需要经过的流程，包括但不限于从哪里获取原数据，经过哪些筛选，如何将业务匹配至会计科目，如何导入表格去用友入账。以及除了主链路，在入账过程中财务还需要做哪些工作

用户痛点：明确核心用户的痛点，在哪些环节上耗费的时间久，哪些可能造成数据准确度问题等

（2）初步明确业务目标，一般要明确业务方希望什么时候支持哪些范围的能力，以何作为验证，但这个只是从需求方的诉求来看，非最终项目目标

1.2 明确项目范围和项目目标

从业务方的角度上，肯定是希望项目能达成的目标越多越好，需求都囊括进来才好。而从项目管理的角度：需要确保项目在范围、时间和成本三个方面达到平衡（项目管理三角形：范围、时间、成本）。

1.2.1 项目目标制定

需要注意的业务目标不等于项目目标：

业务目标：是从业务发展角度出发所设定的目标。从缩短账期的诉求来看，是为更好的进行财务规划和决策。财务的角度是希望全部的会计科目的入账都能够自动化实现，并能直接输出财务报表和分析看板

项目目标：针对特定项目而设定的具体目标。它明确了项目要达成的成果、时间节点、预算范围等。项目目标制定需要满足smart原则，必须是具体的、可度量的、可实现的、有时限的、相关的。比如本项目的目标可以表示为：为缩短结账周期，满足公司结账要求，由现有每月20-25日结账缩短至每月7日。

1.2.2 项目范围定义

需要结合时间、资源、技术、成本等情况，以及项目目标，来确定项目范围，明确哪些是系统支持的，比如仅支持to B，还是to C也包括，比如是集团的所有的收入，还是某个公司收入

项目范围要定义清楚，才能拆解任务，评估项目完成情况（但是在做产品架构设计时又要考虑好平台化、扩展性）。比如账务集成项目：24年H2支持A公司资金类的账务自动化集成由现有每月20-25日结账缩短至每月7日。范围就包括完成时间、业务范围等。

考虑限制条件，针对时间、资源、技术、成本限制的情况下，可能需要有针对性的控制项目范围，优先完成关键功能。比如账务集成项目，所覆盖支持的业务场景仅现有现有业务系统支持的范围，针对业务系统暂未支持的业务场景，不包括在本项目范围之内。

1.3 任务分拆及初步估时

1.3.1 粗略版的产品结构图

为完成项目目标，涉及到的业务领域和功能，可以输出初步的产品架构图，只是为了知道涉及到的敏捷组、产品负责人，一方面减少遗漏，降低有关联方没有考虑到；另一方面便于各域的产品初步知道涉及到的功能改造，便于拉齐研发进行估时。注意，立项之初还没确定本项目后续是否要做，以及项目优先级，所以不需要到非常准确的不需要制作非常精准和完善的业务架构图和产品结构图。

1.3.2 各域产品拆解功能

一般公司的立项是需要评估工作量的，所以各域产品大致知悉涉及本领域的改造之后，需要初步盘点需要改造的功能点，因为研发和测试的估时一般都需要按功能点进行评估。这里颗粒度不用特别细，不用到原型图。并研发和测试进行每个领域的预计估时，一般按人天进行估计。

1.3.3 梳理依赖关系及里程碑

项目的完成不是每个域的估时之和，而是需要评估哪些领域是可以独立开发的，哪些领域有强依赖，哪些功能是可以分拆推进，哪些功能是不同敏捷组负责所以可以同步，考虑了以上的几个问题之后，就可以依据估时和依赖关系，初步知道项目预计完成时间了。

“账务集成项目”，作为财务专业的项目，少不了财务的专业知识输入和参与验收，所以在依赖关系的同时，可以梳理需要财务在何时完成什么任务，也需要提供清单。以下是以简化版的“账务集成项目”的任务分拆和估时：

1.4 制作立项书

前面部分都是准备工作，到这里，就需要正式产出项目的立项书了。项目立项书一方面是为了从公司层立项，另一方面也是后面项目推进和执行的重要指导文件

内容包括：项目背景、用户痛点、项目目标、核心项目范围、项目规模预估、ROADMAP、风险&依赖

在痛点、目标模块，要简洁、直接

在规模预估模块，要留有一定的buffer应对不确定情况

在ROADMAP模块，对于任务之间有强依赖的要特别注意，要定好关键的里程碑节点

在风险&依赖模块，要写清楚有哪些不可控或者已知风险，如何规避风险

二、项目过程跟进

2.1 KICK OFF 会议

立项通过后，有时会需要根据立项委员会的结果，新增或调整项目目标，并且针对立项的级别（是P0或P1），也决定了项目资源投入和与其他项目的优先级，这个时候就需要调整及确认目标、范围、项目优先级及产研资源情况。以此，对项目立项书进行略微的调整，调整确认之后，需要组织KICK OFF会议。

为什么要组织KICK OFF会议？

介绍团队：项目成员、职责的介绍。特别是跨团队的情况下，了解彼此的工作

统一认知：为全体项目成员、利益相关者，能够对项目目标、范围、里程碑等有统一的认知。消除大家对项目目标和范围的不同理解

激发动力：通过强调项目对公司、团队的重要性和价值，让团队成员明白自己的工作对组织的贡献

协同机制：建立项目的同步机制，比如群、周会、需求管理和变更、风险管理和措施

在KICK OFF上需要同步的内容：

项目的基本信息：项目目标、项目范围、ROADMAP、团队成本等

信息同步机制：项目交流群、例会机制等

风险管理策略：针对已识别的风险进行讨论，包括风险描述、风险等级、风险发生概率、应对策略等

2.3 过程把控

2.3.1 项目沟通机制

周会同步机制，按周主要负责人来同步项目进度和风险。并将周会的会议交易及时同步项目组成员和相关领导。并还需要建立即时沟通和风险同步机制。

即时沟通机制，除了周会以外，项目组成员通过拉群等方式实现即时沟通。即时沟通可以帮助解决突发问题，提高项目的响应速度。

风险同步机制，对于不同程度风险，不同的措施。如果存在重大风险，需要上升到一定层级进行推进或决策，可多寻求外部、领导协助，而不是一味硬推；并能及时制定策略（可以是plan B，可以是短期方案后续改造，可以是保核心路径舍非必须路径等）

2.3.2 任务分拆及识别关键路径

在立项之初已经初步分拆了任务和负责人。到项目推进阶段，就不能是初步的方案了，需要将各项任务的分拆到人，细化需求的颗粒度及完成时间。

从过程中重视进度把控，对于每个事项的里程碑节点，一定要跟踪到细颗粒度，不能等里程碑时间快到了就来不及；

对上下游改造尽可能减少依赖，非一定的依赖一定要提底线要求

不要仅由项目经理和主产品来包括进度，而是每一个领域的改造都需要有一个负责人，这个人需要对她所依赖的上游进度进行推进和要求

在项目具体分拆上，一般采用WBS的工作分解结构（Work Breakdown Structure）就是通过把任务进行一层一层的分拆，分拆到分拆不下去为止，并将每一项分拆到具体的负责人，产品功能一般就会包括业务方、产品、后端、前端、测试等

任务分拆之后，需要识别关键路径。这个在前面也有提到，只有任务中最后的任务完成之后，项目才能结束。这个前面也有提到，需要将任务之间的事项依赖关系，资源依赖关系等进行评估，才能知道最长的路线，即关键路径（Critical Path），组成关键路径的活动称为关键活动。

2.3.3 项目具体跟进

项目的跟进可以建立如下的表格，包括详细的分拆、进度跟进、风险同步等。这里需要注意原定的任务分拆时间不要删除，可以在原有基础上进行标注，这样在整个项目过程中知道哪些模块是有延期的

对于一个复杂的项目，可以选择功能强大的项目管理软件，如 JIRA、Microsoft Project、Trello等；对于一个小型项目，可以使用简单的在线表格或文档工具。以下是用在线表格的进度跟进示意：

2.3.4 定期项目进度复盘

针对项目周期比较长的，需要定期进行复盘，针对项目过程中遇到的问题和风险及时调整目标、策略、行动计划。定期复盘也不需要过于频繁，可以在关键里程碑节点，或月度的时候组织

2.3.5 项目范围变更

针对在项目开发过程中，涉及到的未盘点到的范围、新增的目标变更的目标等要及时进行项目范围变更，并且及时同步到项目组成员，并以此及时调整项目分拆的任务和里程碑节点

三、项目结项

3.1 项目目标验证

回顾项目立项时的目标和范围，进行项目最终的验证，确定项目的最终结果有实现项目目标。

作为财务项目，基于严谨性的要求，财务会需要1-3个月的时间进行线上线下同步产出数据，进行对比，保证数据无误之后再进行切换。而项目时间不会包括这部分时间，所以在第一个的时候，就需要以财务线下与线上的数据进行对比，评估准确度，并产出优化列表。在数据准确度达到一定程度之后，后续的优化按敏捷进行推进，不作为项目的一部分。

在完成财务验收后，产研也可以产出部分系统化的指标数据，来辅助验证项目的价值，如提高人效，原来需要多久现在需要多久；如减少退回率，指标如何计算，数据如何变化

3.2 项目结项报告

根据团队内部总结和与利益相关者交流的结果，撰写项目总结报告。包括项目目标完成情况、项目结果、价值阐述、问题分析及举措、下一步计划等。也可以包括项目经验教训、对未来项目的建议等内容。

最后就是组织线下复盘，回顾项目的整个过程，分享项目中的经验和教训。鼓励团队成员畅所欲言，提出对项目的改进建议。