项目启动会准备
俗话讲，良好的开端是成功的一半。召开一个漂亮的项目启动会对于整个项目开展意义重大。
通过启动会这种全员公开的方式确认项目正式启动，达到聚拢干系人期望、达成统一愿景与里程碑事件、明确责任分工与沟通机制、关键角色获得公开授权等目的。
可见，项目启动会不仅仅是把周围熟悉或不熟悉的同事叫过来一起传达指令，是要做好开端，盘活造就一只有高效战力的团队。
启动会的核心目标是识别干系人与制定项目章程，这需要在启动会结束后整个项目团队达成一致。
识别干系人也就是组建团队与划定职责的过程，干系人管理成效直接决定了沟通与进度顺利与否；而项目章程就是将约定留档，约束项目边界，统一运作规则。
眼下正在实施一个具有省级战略意义的政府行业项目，作为技术负责人，就系统梳理下项目管理的基本框架，实践出真知。计算机行业摸爬几年，也算小有认识——成事对于个人及团队意义非凡，而能否成事只靠技术是不能完全满足的，通过观察与业界数据参考，那些具备「技术-业务-管理」能力模型的工程师更能成事。看到许多工程师被抬上去做基层管理而各种不适的故事，我想作为项目或产品的研发责任人，这种虚线管理方式可能会是一个很好的切入口。
从研发出身，到能够站在全局负责项目或产品成败，这本身也是在突破边界。
启动会议程
高效会议的议题不能发散，提前准备好议题议案发给与会者，有助于会议快速推进。
我心目中的理想会议时长是一小时内，信息同步较之开展讨论可大幅提高会议效果。那些莫名其妙多出来的无头群组与拉出来的临时会议、一言堂滔滔不绝的会议、不知所以无边界漫游的会议真是时间杀手，当然，所反映的企业文化与管理风格又是另一回事了。
启动会开什么，还是围绕干系人与项目章程来，开个好头，分工协作，开工大吉。
确认项目章程
项目章程确定了项目整体方向，下面会分别讲到这些：项目背景介绍、团队构成与职责划分、里程碑事件、信息传递机制、基本原则等。
介绍初步方案
按需，前期如果做了充分的调研与方案设计，可以将整体架构介绍出来，这也是启动会后下一步重要项目活动。
关键风险识别
对应项目领域中的风险管理，对于政府行业而言，政策风险、商务关系、本土竞争、国产化要求等都应予以考量。
下一步计划
启动会后就会逐步开展用户调研、系统调研、负偏离梳理、总体设计等，先行识别干系人的目的也是为下一步项目推进做好准备，简单说就是定人定事定时间。
Q & A
最后留一点时间给大家提问，得到一些反馈看是否在其他没有参与前期项目筹备也能基本了解项目现状。
项目章程
最开始确认的项目章程总领整个项目，是需要认真准备的，人们习惯于思考一切顺利的情形，但是项目是一定不会的（感谢 Brooks，人月神话至今仍然还是神话），章程一部分功用就是来兜底的。
项目介绍
项目名称（记得独占篇幅）。
项目背景，还是先介绍外部干系人，除了最终使用用户或目标群体外，在政府行业还会涉及客户（中标方）、集成商、各个有依赖的三方厂商等，其他的如中标金额、中标范围也很重要。
项目目标与建设内容，这块要写上对内对外两部分的，对用户而言，他们的建设期望是什么，可以简要摘录招标文件内容；对项目团队而言，这个项目对于部门乃至公司的意义是什么。
项目里程碑，结合客用户期望、团队交付能力多方面评估项目里程碑事件，也就是什么时间完成什么项目活动的多个节点，一旦产生变更都是项目的重大决策。比如：启动会、用户调研和系统调研、总体设计和负偏离评估、开发活动开始、运行环境准备、产品部署、集成测试、系统测试、试运行和用户培训、初验与改进、终验与结项、维保等。
项目团队与职责
明确项目成员角色与职责，可以分为：
领导组，负责整体工作方向、重大决策、资源统筹、进度把控等；
市场或售前组，负责合同签订与回款、客情关系维系、商务风险处理、产品出货；
业务分析师，负责需求调研、需求管理、对标及验收；
技术负责人，负责最终交付、资源整合、沟通管理、架构设计与决策、总体设计；
解决方案或产品经理，负责方案设计、可行性评估、负偏离梳理；
研发组，负责软件分析与实现、技术疑难问题攻克、开发文档编写；
交付与 QA 组，负责系统集成测试、过程与质量保障。
信息传递机制
对于项目管理中的沟通管理，沟通效率直接决定了团队协作效率，制定有效的沟通机制可以大幅减少信息传递衰减与信息孤岛。
比如汇报沟通机制：
项目周报，汇报项目进展、风险点、需要协调资源等，汇报对象包括项目团队与客用户；
特殊事项汇报，涉及项目重大决策事件，影响项目里程碑的事件汇报机制；
例会，项目团队内部沟通会议制度，站会、周会、双周会、组会等（能少开就少开）。
项目团队基本原则
对应项目管理中的整合管理，包括范围、质量、进度、沟通等多个维度，建立团队基本共识，避免无上限承诺用户诉求、问题散落各处没有体系化处置、人员交接责任旁落等问题发生。
这里提供几种原则：
建设范围，需求尤其是标外需求归口到技术负责人，并经专家组评审才能执行实施与交付流程；
沟通管理，对用户、对客户、对三方厂商，划定沟通接口人、沟通渠道与沟通范围，避免商业机密、敏感技术外泄；项目目标、实施方案、技术选型、人员变更等及时做内部同步，对应信息传递机制。
计划变更，尤其是里程碑变更，影响项目整体进展的处置流程；
问题管理，风险尽早识别与汇报，归口技术负责人，禁止问题与风险私吞；
需求管理，属于需求工程，按照公司项目管理要求，或针对项目制定特定管理规范；
人员变更管理，项目团队成员可根据项目状况动态调整，能上能下，制定交接流程规范。
小结
项目管理从来不是一件容易的事情，在进度、质量、成本、范围等诸多条件约束下，要做到全局最优，就如同架构设计一样要做取舍（trade-off）。软件工程的项目管理走向标准化也就是上世纪 90 代开始，相对土木、水利这些古老的工程科学，工程管理或项目管理有太多可演进、可量化的地方。这也是我们当今有如此多机会的原因，互联网革命、数字化浪潮、AIGC 的兴起，对于传统的软件工程师而言，能力要求一定会更加多元。可以不做管理，但是不能不会管理。项目管理中对风险、质量、干系人等管理方法论是有哲学意义的，共勉。
