大型软件交付项目注意事项 53 条
多年前，从事信息技术行业流行自嘲“挨踢”，对于不同的受众，也可以说是“整电脑”或者“做软件”的。后来“互联网”火了，渐渐就变成了“搞互联网”的，尽管最近国内互联网有些颓，中概互联成了中丐互联，但暂时还没有新的替代词汇。如果用英文就很直接，信息技术是“IT”，计算机科学是“CS”，软件工程师是“SE”。我们常说的系统、应用、APP、程序都是“软件”，与硬件相对应。
软件分类有好几种方法，2B 还是 2C，工具还是业务，通用还是垂直。我入行时做的是电信软件集成，当时工具软件之外的业务软件有四大领域——电信、金融、政府（税务）和 ERP。当年神州数码搞三级火箭战略，在软件服务方向多路出击，都覆盖全了。
国产企业级软件产品化道路十分坎坷，一度号称没有成功案例，但凭着灵活的定制化服务和廉价密集型劳动力加持，在各行业中摸爬滚打出来一些强者，跟外国厂商差异化竞争，在艰难的市场里抢到了蛋糕。活下来的公司都有真本事，要么是客户关系，要么是工程质量，要么是成本控制，或者哪样都不弱。比如我的老东家亚信，专注电信行业超过 20 年，工程师上万，大型项目动辄数百人参与，项目管理能力非常强悍——传统软件的项目管理涵盖多方面，不仅仅是研发流程。
云计算时代来临，2B 软件进化到了 SAAS 阶段，希望产品化平台化快速扩展做好企业服务，成为国内的 Salesforce。然而国内行情特殊，企业客户被伺候得太好，花了钱要按自己想法定制服务，于是许多名义上的 SAAS 公司不得不接定制需求，得能支持私有化部署，还要适配原有接口对接其他系统，大版本上线后还可能有更多定制需求持续迭代升级，衍生出二期、三期……N 期。面对标准化还是定制化的抉择，搞公有云的大厂为了深入企业服务体系上游，也纷纷投身其中，动用自己的宝贵资源或者外包、合作伙伴来堆人头。如今大型的软件定制实施交付项目依然广泛存在，彰显着大团队作战的别样光辉，而且随着“下半场”、“产业互联网”、“数字化转型”的深入，在新时代里还将再创辉煌。
收集整理了大型定制软件项目实施交付各阶段技术团队的注意事项，共计 6 个阶段、28 项主要任务、48 种交付物、53 条注意事项，包含实践教训，也借鉴了一些同行的宝贵经验。如同 CMMI 一样，未必通用，可根据实际情况取舍。
行业兴衰，成败起落，屹立不倒者，自有其光，难掩其华。
项目特点
需定制或实施、私有部署，有线下商务流程，需专门投入较多技术资源，具有临时性和唯一性，需有完善的项目管理体系保障交付。
乙方提供实施服务，可能包含第三方集成选型，一般由乙方自行选择，也可能由甲方招标或者选型。
项目可能涉及其他供应商，都面向甲方，协作较为复杂。
有明确的预算、项目周期、里程碑和回款条款，一般合同签订后，收首付款，上线验收后收尾款。
甲乙方成立项目组进行对接，有明确的职能角色，有统一的对接人和沟通、决策机制。
有清晰的责任要求，严格的交付标准，违约机制。
项目过程
参照 PMBOK 项目管理过程控制方法论划分项目阶段。
项目过程总体概述
售前阶段
阶段目标
客户经理主导销售，参与招投标或者与甲方谈判，签订合同，或者在需要的情况下提前内部立项，最终确定项目经理。
主要任务
售前技术交流，确定可行性技术方案。
提供实施方案，粗估项目成本。
准备合同，签订合同，或者提前立项。
任命项目经理。
交付物
工作量清单（报价清单）
中标合同及附件
提前立项申请表
项目经理任命书
注意事项
工作量粗估，误差需要控制，对于难以评估的，要进行声明。
避免过度承诺，如有困难，客观表达出来。
启动阶段
阶段目标
完成项目准备工作，内部立项，主要负责人转换为项目经理，实施项目组正式成立。
主要任务
内部立项、细化预算、资源。
明确项目工作范围、里程碑。
明确项目干系人。
组建项目团队，明确项目组成员、组织架构、规章制度。
召开项目启动会。
收取首款。
交付物
项目交接备忘录
项目章程
项目组组织结构、规章制度、通讯录
项目组启动会材料
注意事项
立项后需关注合同签订及收款情况。
尽量邀请公司高层领导参加启动会。
关注核心成员的资源投入情况。
明确甲乙双方主要角色及职责，明确诉求，对干系人进行分级。
明确甲乙双方主要角色对接关系，确保专人专岗，明确后备人员及授权机制。
明确持续沟通机制，对于影响项目的重要事件，与客户沟通之前需上报。
所有正式沟通过程通过邮件或者项目管理工具记录、审核，可追溯。
项目组成员职责或投入比例发生变更，需第一时间同步双方。
解决不了问题或者达不成共识，第一时间升级。
不允许私下接需求，包括 bug 修复。
不允许私下评估反馈工作量，包括其他环节工作量。
不允许私下承诺交付时间。
不允许超出角色职能边界沟通。
规划阶段
阶段目标
制定可执行的项目管理计划，得到公司批准。
主要任务
制定管理计划。
制定产研计划。
风险识别和分析。
与客户召开项目启动会。
交付物
管理计划：
变更管理流程
团队建设计划
沟通管理计划
风险管理计划
质量管理计划
会议管理机制
文档管理机制
产研计划：
需求调研计划
设计、开发、测试计划
培训计划
上线计划
验收计划
项目启动会会议纪要
注意事项
尽量邀请客户方高层领导参加启动会。
对于未达成一致的待定事项，充分沟通。
需明确项目层面的激励办法。
任务拆分原则：100%、穷尽、合理。
对于公共模块，要明确与其他模块的交互关系，避免遗漏。
对于协作方的评估，切忌过于乐观，务必尽可能细致到位，以对方正式口径为准，避免主观臆测。
建立文档管理机制，沉淀项目所有文档。
对于周期较长的项目，应考虑到人员流动，做好新人加入快速上手的指引，并持续迭代。
分工应人尽其才充分发挥长处，同时尊重项目成员意愿，给予选择空间。
倡导高效会议，进行全员培训，避免过多低效会议。
提前了解客户方流程、规范，包括不限于现场工作的衣着要求、远程工作的网络权限。
项目组团队成立后，尽早进行团建，以便快速熟悉，增进了解。
实施阶段（执行 &监控）
阶段目标
完成并交付合同约定的产品或服务，确保经过测试、可运行、如期交付、成功上线。
主要任务
需求调研、分析。
方案详细设计、评审。
研发。
测试。
培训。
上线。
交付物
需求规格说明书、功能列表、需求评审报告
UX、UI 设计稿、评审报告
总体设计规格说明书、评审报告
详细设计规格说明书、数据字典、评审报告
测试用例、评审报告
详细开发计划、测试计划
变更记录表
代码、代码检查报告
单元测试报告
缺陷记录
测试报告（集成测试、性能压力、外部接口、UAT 等）
培训计划、课件、培训确认书
用户使用手册（包括管理员手册）、业务词典
上线方案、评审报告，上线申请、上线验证测试报告、数据对比报告、上线完成报告
注意事项
需求应有统一对接人，与内外部对接，掌握整体情况。
做好客户期望值管理，识别关键人员，充分沟通。
保持良好稳定的客户沟通机制，定期向双方高层汇报项目状态。
监控项目风险，及时上报，做好各环节评审、CodeReview、明确提测标准。
客户验收前，产品经理先进行内部验收。
整理业务词典，拉齐业务认知和理解，可以进行培训。
有计划进行团队建设，活跃团队气氛，可适当邀请客户接口人参加。
使用项目管理工具进行有效管理，包括每日站会、周会，周会可区分产研测试维度及与客户的商务维度。
技术选型确定的基础设施、组件应有统一使用规范。
项目组内外部交接务必正式邮件通知，有交接周期，有交接启动邮件及附件，交接完毕发邮件确认。
上线前应有充分准备，并召开上线动员会，必要时进行模拟演练，上线验证后发出上线完成报告。
上线应有详细的操作步骤，并且细化到文档，包括命令，避免人为失误，任务明确到每个责任人和操作时间，包括客户方，并预留问题解决的时间。
上线方案中应包含问题处理的手册、脚本，以及上线失败的回退预案。
上线同时应具备监控能力和故障响应机制，包括 C 端和 B 端。
上线后，可适当调整工作节奏，缓解团队疲劳紧张状态。
收尾阶段
阶段目标
上线后协调客户进行初验，并线上支持、解决遗留问题，完成项目验收，协调干系人进行项目总结。
主要任务
初验。
线上支持，解决遗留问题。
终验，移交项目维护责任，回收尾款。
项目总结，复盘会，兑现激励，评估绩效。
结项，财务结算，项目组解散。
交付物
初验报告、遗留问题清单、问题跟踪解决报告。
用户使用手册（更新版）
终验报告
交付文档清单
项目总结报告（内部）
注意事项
交付物需符合客户的管理规范。
涉及第三方服务或产品，需提供相关文档，管理账号、密码、使用许可等。
关注上线报告中的问题，并及时与高层领导沟通，获得理解和支持。
部分遗留问题可能属于需求变更，加强沟通，控制项目不超范围。
对于终验时间点，双方应达成共识，终验后交付给客户维护部门，需要提前进行沟通，维护好关系。
项目总结报告需总结经验、心得体会，汇总项目可沉淀资产。
及时进行奖励，组织庆功会。
服务运营阶段（维护）
阶段目标
完成合同约定的维护期服务。
主要任务
制定维护计划
执行维护工作
定期报告
交付物
维护计划
维护日志
故障报告
维护总结报告
考核报告
客户使用报告
注意事项
区分 bug 和需求，bug 需及时处理修复。
重大疑难问题及时上报。
注意信息安全风险，遵守内控规范。
合同可能会有维护考核扣款条款，对于故障损失，需及时复盘，明确责任。
版权声明: 本文为 InfoQ 作者【IT民工大叔】的原创文章。
原文链接:【http://xie.infoq.cn/article/29b1019a5943b304de1b4f695】。文章转载请联系作者。
还未添加个人签名 2012.07.16 加入
还未添加个人简介
评论