截图来自TOG官方文档《Architecture Project Management》
在我的微咨询项目中也会写一些项目章程，例如下图来自我的一个项目文件扫描档
要执行企业架构项目，就需要懂一些项目管理知识，这对架构师来说是必备的。下面摘录一些PMP中关于项目管理的内容。
在PMP的知识体系中，一个完整的项目管理流程分为五大过程组和十大知识领域。
五大过程组：启动->规划->执行->监控->收尾；
十大知识领域：项目整合管理、范围管理、进度管理、成本管理、质量管理、资源管理、沟通管理、风险管理、采购管理和相关方管理。
这五大过程组和十大知识领域，交叉形成49个过程如下图：
但并不是所有的项目都会采用这49个过程，不同的项目，会根据实际情况裁剪使用部分过程和知识领域。下面以我参与的项目为例，结合实际情况梳理项目管理流程。
1、启动阶段
项目启动过程的目标是：获得项目批准，并就项目愿景与团队成员达成共识。该阶段一般需要完成两个关键过程：制定项目章程和识别相关方。
（1） 制定项目章程
项目章程是获得项目正式批准的依据，我们的项目如何获得项目批准？项目立项评审。
立项的过程建议从以下几个维度去思考：
a、What：该项目做什么？主要可交付物是什么？（可测量）
b、Why：为什么要做这个项目？能带来什么样的收益？合同额还是战略布局？企业不是公益组织，不会做无价值收益的项目。
c、How：怎么做？顶层设计方案是什么？（可行性）
d、How long：做多久？项目的整体里程碑计划。
e、风险：是否存在技术风险、市场风险或其他风险？
在立项通过之后，方可正式投入大量人力去执行项目。
（2）识别相关方
识别相关方的目的：提前了解项目对各相关方的影响，以及相关方对项目的需求和期望。我们项目所涉及到的相关方一般包括：外部客户、内部的商务、产品、项目、研发、测试、大数据组等。
在项目获得批准，且完成相关方识别后，需召集相关方参与项目启动大会，会议不需要过多讨论项目实现细节，主要就项目目标以及组织愿景达成共识，鼓舞士气。会议结束后，项目进入规划阶段。
2、规划阶段
规划阶段的主要目标：明确项目范围，制定实现目标的执行路径与计划。通俗的讲，即规划在什么样的项目范围下，使用多少成本、时间和资源，达到什么样的项目质量标准，在这个过程中，有哪些风险，如何处理等。
在我们的项目中，规划阶段一般重点涉及到以下6个过程：
（1）定义范围
该过程主要是通过与客户沟通，明确项目有哪些功能、性能等要求，以及项目的验收标准，形成产品规格文档。比如在AI项目中，主要有静态场景检测以及动态行为识别功能，对产品的体积、CPU和内存占用、AI模型大小等都有一个验收指标。
（2）创建WBS
WBS即工作分解结构（Work Breakdown Structure），将项目的阶段可交付成果工作分解为较小的工作包，比如项目中的静态场景检测功能，可细分为底层引擎开发和java层的功能开发。
（3）排列活动顺序
判断WBS分解的工作包之间的依赖关系，并根据依赖关系对工作包的实现进行优先级排序，比如引擎开发、java开发、模型训练可以同步进行，然后进行终端功能联调；而后端与终端的联调依赖于终端的功能实现，而终端开发的周期长，所以后端的开发优先级可以往后排，待终端开发进度快完成时，再开始后端开发。
（4）估算活动资源
一般是由团队成员给出工作量的评估，比如引擎开发5人天、java开发3人天等。
（5）制定进度计划
根据活动顺序、持续时间的评估以及投入的开发资源、后期的测试时间等，制定进度计划，一般是以里程碑的形式呈现。
（6）识别风险
整个项目生命周期的各个阶段都需要有识别风险的意识，如何识别风险？即在哪些过程中，存在哪些不确定事件，带来什么样的影响。比如，在AI模型训练过程中，依赖于客户的训练数据，我们不确定客户训练数据的体量和质量，会直接影响AI模型的识别率，这就是一个很大的风险，需要提前准备应对措施，比如通过内部自己产出训练数据来规避风险。
项目规划阶段所制定的各种计划是项目执行的“指南针”，只有先保证方向明确，才能正确的执行，达成项目目标。
3、执行阶段
执行阶段的目标是：根据规划阶段制定的各种项目管理计划，分配工作任务并执行，在实际的项目中，重点涉及到以下两个过程：
（1）指导与管理项目工作
该过程主要是依据需求、范围、项目管理计划等，与团队成员确认规划的合理性，并一起开展项目工作。
（2）管理沟通
管理沟通的主要目的是：保持项目信息在各相关方之间的一致性，避免出现信息不对称。重要的项目，建议以半月或月度为单位，跟相关方同步项目进展情况；当出现项目变更时，也需要及时以邮件的形式同步给相关方关于项目的变更信息。
4、监控阶段
监控阶段的目的是：跟踪、审查和调整项目进展，识别必要的计划变更，确保项目按时保质的完成。这个过程也是我们经常说到的“项目跟进”，主要包括监控进度、质量以及处理在控制过程中出现的变更过程，即以下三个过程：
（1）控制进度
依据进度计划，监督项目各事项的进度。这个过程可能会由于技术实现等问题，可能有进度延期的风险。一般的解决措施是有两种：加资源协同解决；或者变更技术方案。
（2）控制质量
此过程一般是产品测试的过程，依据产品规格、需求文档等，测试产品质量是否符合标准。
（3）实施整体变更控制
在项目执行的过程中，可能会因为范围、进度、质量、成本等各种问题而产生变更，实施整体变更控制，建立一套正确的流程对项目的变更进行控制，能有效的降低项目风险。一个完整的变更控制流程分为四步：变更请求提出->变更请求审核->变更请求执行->总结。
在实际的项目管理过程中，一般影响较小的变更，为了提升工作效率，会省略这个流程；但是一些影响较大的变更，比如涉及的开发周期长、影响范围大、涉及相关方多的变更，需要严格的实施变更控制流程，只凭产品或者项目经理一个人决策，风险太大，最后一定会由风险转变成问题。（已采坑两次）
5、收尾阶段
该阶段主要是对产品进行验收，包括内部验收以及外部客户验收，并将项目过程中的相关文档进行归档，总结经验教训，撰写项目结项报告。将项目移交给运营团队，后期由他们主导跟进项目的问题反馈，产品参与解决问题。
而在我实际的工作中，收尾过程往往在产品验收之后就算完成了，会忽略文件归档以及总结经验教训的过程，其实这两个过程也是必不可少的。
（1）文件归档
在我参与的上个项目中，我们产品这边维护了需求文档、项目管理计划文档等，开发那边维护详细方案设计文档；测试那边维护测试文档；最后发现，当后面其他相关方想找我了解项目时，我需要到处找文档，效率很低，可能还会有部分研发文档缺失等问题。所以，在项目收尾阶段，建议一定要对所有文档进行归档整理，包括各个功能模块的研发设计文档，以及产品测试报告等，保证项目的完整性。
（2）总结经验教训
在项目执行的过程中，一定会遇到很多问题，比如沟通过程信息不对称、需求变更未评审、风险识别不足等等，这些已知的并以解决的问题一定要避免下次再出现。所以总结经验教训建议是一定要做的，在这个过程中，将需要改进的地方总结下来，后面定期监控反馈自己的复盘效果，是否真的改进了。既能提供自己的工作效率，同时也可作为一份组织过程资产，供其他同学参考，利人又利己。
（内容摘自微信公众平台架构师修炼之道，如有内容侵权请联系删除）
