集成化软件研发流程

文件标识：集成化软件研发流程 IDP 当前版本：7.0 作 者： 审 核： 文件状态： 草稿 正式发布 正在修改 完成日期： 集成化软件研发流程集成化软件研发流程 IDPIDP 7.07.0 1 目 录 A. 集成化软件研发流程图5 B. 过程域和主要成果清单6 C. 研发组织结构模型7 D. 角色职责表8 第 1 章 营销客服过程10 1.1 产品管理.10 1.1.1 产品策划10 1.1.2 调研分析11 1.1.3 产品立项与开发12 1.1.4 产品销售与服务13 1.2 销售管理.13 1.2.1 营销策划13 1.2.2 销售跟踪14 1.2.3 合同管理15 1.3 客户服务.16 1.3.1 受理17 1.3.2 处理17 1.3.3 审核关闭17 1.3.4 客户反馈17 1.4 客户信息管理.18 第 2 章 项目管理过程19 2.1 立项管理.19 2.1.1 立项申请19 2 2.1.2 PMO受理20 2.1.3 立项评审21 2.1.4 项目启动22 2.2 结项管理.23 2.2.1 结项申请23 2.2.2 PMO受理24 2.2.3 结项评审25 2.2.4 遗留问题跟踪.25 2.2.5 项目工作总结.26 2.3 项目规划与监控.26 2.3.1 项目人员角色.26 2.3.2 任务进度管理.27 2.3.3 项目成本管理.28 2.3.4 项目评审（决策评审和技术评审）.28 2.4 变更控制.29 2.5 沟通管理.31 2.6 问题跟踪.33 第 3 章 项目研发过程34 3.1 需求开发与管理.34 3.1.1 需求调研34 3.1.2 需求分析35 3.1.3 需求定义35 3.1.4 需求评审36 3.1.5 需求跟踪36 3.2 系统设计.36 3.2.1 软件系统设计.36 3 3.2.2 设计评审37 3.3 模块开发与集成.37 3.4 测试与缺陷跟踪.38 3.4.1 提交测试39 3.4.2 测试准备39 3.4.3 执行测试40 3.4.4 缺陷跟踪40 3.4.5 消除缺陷41 3.5 交付与验收.42 3.5.1 撰写文档42 3.5.2 软件部署42 3.5.3 用户培训43 3.5.4 试用和验收.43 3.6 软件维护.44 3.6.1 接受维护请求.44 3.6.2 分析维护请求.45 3.6.3 执行维护45 第 4 章 支持过程46 4.1 软件配置管理.46 4.1.1 软件配置管理的概念46 4.1.2 软件代码管理的一般规则.46 4.2 文档管理.47 4.2.1 文档管理的特征47 4.2.2 项目文档管理的一般规则.48 4.3 质量保证.48 9.4 日志和周报.49 4 4.5 绩效评估.49 4.5.1 定义绩效体系.49 4.5.2 填写绩效表格.50 4.6 知识库管理.51 A. 集成化软件研发流程图 B. 过程域和主要成果清单 过程域主要工作成果 产品管理（产品策划，调研分析，立项）产品建议书，产品调研报告，立项申请书 销售管理（营销策划，销售跟踪，合同管理）营销方案，销售跟踪表，合同管理表 客户服务（受理，处理，关闭，反馈）客服跟踪表 营销 客服 过程 客户信息管理客户信息表 立项管理（立项申请，PMO 受理，立项评审， 项目启动） 立项申请书，立项评审报告，项目总体计划 结项管理（结项申请，PMO 受理，结项评审， 遗留问题跟踪，项目工作总结） 结项申请书，结项评审报告，项目工作总结 项目规划与监控（人员角色，任务进度，项目 成本，项目评审） 人员角色表，任务进度表，成本表，评审报告 变更控制变更控制报告 沟通管理沟通记录 项目 管理 过程 问题跟踪问题跟踪表 需求开发与管理需求规格说明书，需求跟踪表 系统设计系统设计说明书 模块开发与集成模块文档（需求和设计） ，软件代码 测试与缺陷跟踪测试用例，测试报告，缺陷跟踪表 交付与验收安装手册，使用手册，验收报告 项目 研发 过程 维护维护记录 软件配置管理，文档管理，知识管理软件配置库，文档库，知识库 质量保证质量保证检查表，问题跟踪表 日志和周报工作日志，周报 支持 过程 绩效分析绩效报表 1 C. 研发组织结构模型 营销和客服角色 项目成员角色 支持角色 管理角色 研发总监 销售人员 产品经理 需求分析员 系统设计师 PMO 项目经理 决策委员会 开发工程师 测试人员 质量保证员 各部门经理 配置管理员 客服人员 2 D. 角色职责表 角色该角色在研发流程中的主要职责 研发总监 （1）参与立项评审，为项目分配合适的人力资源。 （2）及时了解所有项目的人力资源、进度、质量情况，协商处理问题。 （3）在项目结束时，对项目进行综合评估。 决策委员会 决策委员会一般由部门经理以上职位的人员组成，主要职责是参与决策评审（如立项 评审） 。 部门经理人力资源分配和协调，提升人员的能力，考核人员绩效。 PMO受理立项申请，受理结项申请，项目过程检查。 产品经理 （1）通过调研分析，进行产品策划，撰写产品建议书，申请立项。 （2）跟踪产品开发过程，及时试用产品，纠正偏差，给出优化建议。 （3）帮助销售人员宣传、销售该产品，及时获取客户的反馈，改进产品。 销售员（1）负责本公司产品的销售，鉴定合同，跟踪合同执行过程。 （2）撰写合同项目的立项申请书。 客服人员集中受理客户问题需求，指定合适的处理人，审核关闭问题，获取客户反馈。 项目经理 项目经理是立项之后的项目主要责任人，主要职责是带领团队在预定的时间和成本之 内，开发并交付质量合格的项目（产品） 。项目经理对本项目的进度、质量负主要责 任。 （1）负责本项目的日常管理（如任务进度管理，项目评审，变更控制，沟通管理， 问题跟踪等） ，以及可能存在的跨项目、跨部门协调。 （2）如果本项目没有专门的需求分析员，那么项目经理承担需求分析工作。如果本 项目缺乏足够的开发工程师，那么项目经理应当承担某些模块开发。 （3）在项目结束时，总结知识财富和经验教训，完善文档。对项目成员的业绩进行 评估。 需求分析员 （1）负责本项目需求调研、分析、定义，撰写详细的需求文档。 （2）将需求准确地传达给相关人员（如开发、测试、客户等） ，随着项目进展，及时 完善需求文档。 系统设计师 （1）根据需求开展系统设计，包括构架设计、数据库设计、用户界面设计等。 （2）撰写设计文档，并将设计成果准确地传达给其他项目成员。 开发人员 （1）按照项目经理分配的任务执行开发工作，并清楚地交付给测试人员（准备测试） 。 如果测试人员报告缺陷，应及时消除缺陷。对自己工作成果的质量负最大责任。 （2）对自己的源代码进行配置管理，撰写自己承担的模块文档。 3 测试人员 （1）了解项目需求，和项目经理商议测试计划，设计测试用例。 （2）根据计划执行测试，找出尽可能多的缺陷。使用缺陷跟踪工具，及时将测试信 息反馈给相关责任人。 质量保证员 （1）跟踪每个项目的开发过程，重点检查需求文档、设计文档、变更记录、用户文 档是否符合规范。 （2）参加需求评审和设计评审。 （3）如果发现项目问题，先和责任人沟通，如果难以解决，则由上级领导协调。 配置管理员 （1）为所有项目创建配置库，为用户分配合适的权限，负责信息安全和备份。 （2）指导开发人员使用配置管理软件。 4 第 1 章 营销客服过程 1.1 产品管理 产品管理流程如图 6-1 所示，主要活动有：产品策划，调研分析，产品立项与开发，产 品销售与服务。该流程的主要工作成果和责任人见表 1-1。 图 1-1 产品管理流程 主要活动主要工作成果主要责任人 产品策划产品建议书产品经理 调研分析产品调研分析报告产品经理 产品立项与开发立项申请书，最终产品产品经理，项目经理 产品销售与服务产品宣传材料，销售合同，客服单产品经理，销售人员，客服人员 表 1-1 产品管理流程的成果清单和责任人 1.1.1 产品策划 产品经理负责产品策划活动。产品经理应主动寻求研发部门的帮助，由产品经理牵头， 撰写产品建议书 ，模板见表 1-2。 提示：本产品立项之后，项目团队将进一步细化产品需求、设计方案和开发计划等。 产品建议书 1. 产品概述产品概述 用简练的语言说明本产品“是什么”， “什么用途”。 2. 产品开发背景产品开发背景 从内因、外因两方面阐述产品开发背景，重点说明“为什么”要开发本产品。 （1）内因方面着重考虑：开发方的短期、长期发展战略；开发方的当前实力。 企业 战略 调研分析 产品策划 产品经理 产品立项 与开发产品销售与服务 项目经理销售和客服人员 5 （2）外因方面着重考虑：市场需求及发展趋势；技术状况及发展趋势。 3. 消费群体特征消费群体特征 （1）阐述本产品消费群体的特征； （2）说明消费者对产品的功能性需求和非功能性需求； （3）说明本产品如何满足消费者的需求，以及给消费者带来什么好处。 4. 产品主要功能和特色产品主要功能和特色 （1）产品的主要功能列表； （2）说明本产品的特色。 5. 产品设计方案和关键技术产品设计方案和关键技术 （1）阐述设计方案及原理，如果有多种方案，需比较优缺点。 （2）阐述本产品的一些关键技术，评价技术实现的难易程度。 （3）确定哪些产品部件应当采购、外包开发或者自主研发，说明理由，分析相应的风险。 6. 产品开发和上市计划产品开发和上市计划 如果产品有多个版本，估算各版本的开发时间和上市时间，以及人员和资金。 表 1-2 产品建议书 1.1.2 调研分析 产品经理在做产品策划时，应同步进行调研分析。产品经理撰写产品调研分析报告 ， 模板见表 1-3，目的是为公司决策提供充分的、有价值的信息。 提示：如果不做调研分析的话，那么产品建议和立项管理都建立在空想之上。 调研者应当客观地对待被调查的事物，不可有意往“好处”或者“坏处”设想。所获取的数 据、图表等信息要真实并且有据可查，不可凭空捏造。 调研分析的主要内容有： 消费者（购买者，使用者，影响者）调研； 竞争对手和同类产品调研； 政策调研； 技术可行性分析； 知识产权分析； 成本收益分析； 产品调研分析报告 1. 消费者调研消费者调研 （1）购买者的特征和需求。 （2）使用者的特征和需求。 （3）影响者的特征和需求。 6 2. 竞争对手与同类产品调研竞争对手与同类产品调研 （1）各竞争对手在研发、销售、资金、品牌等方面的实力。 （2）同类产品的功能、质量、价格，以及主要优点和主要缺点。 3. 政策调研政策调研 （1）有无政策“支持”或者“限制”。 （2）有无地方政府（或其它机构）的“扶持”或者“干扰”。 （3）如何利用（应对）政策。 4. 技术和时间可行性分析技术和时间可行性分析 （1）本产品“做得了吗？”、 “做得好吗？”。 （2）按照正常的运作方式，能及时开发完成本产品吗？投入市场的时间合适吗？ 5. 知识产权分析知识产权分析 （1）分析是否已经存在某些专利将妨碍本产品的开发与推广； （2）分析本产品能否得到知识产权保护，如何获得？ 6. 成本成本效益分析效益分析 （1）估算总成本。 （2）估算总收益。 表 1-3 产品调研分析报告 1.1.3 产品立项与开发 产品经理负责立项申请，撰写立项申请书 ，提交给 PMO，进入立项管理流程。 如果本产品被批准立项，则： 项目经理将管理本产品的开发过程，对产品的质量和进度负责。 产品经理要跟踪开发过程，及时了解产品的开发进度和工作成果质量。如果产品经 理发现开发工作偏离了产品需求和预定的计划，应当及时和项目经理沟通，纠正偏 差。 建议开发团队采用增量模式来开发产品，每次发布新的版本，既要请测试人员进行测试， 又要请产品经理来体验（试用） 。 产品经理应当站在客户的角度来体验（试用）当前产品：产品经理应当站在客户的角度来体验（试用）当前产品： 如果发现产品中的缺陷，则向开发人员报告缺陷，开发人员及时消除缺陷。 若产品经理向项目经理提出改进建议，双方应先就需求和改进措施达成共识，然后 开发人员执行相应的改进措施。 7 1.1.4 产品销售与服务 产品开发完成之后，产品经理负责： 撰写产品介绍文件（如 ppt 文件） 。 制作本产品的宣传网页，设法在更多的网站发布产品信息。 可能需要设计和制作宣传页（印刷品） 。 产品经理对本公司销售人员进行产品培训，使销售人员充分了解本产品的特性。 上述工作完成之后，进入销售管理流程和客户服务流程。产品经理跟踪销售和客服过程，产品经理跟踪销售和客服过程， 收集并分析客户意见，及时改进产品策划。收集并分析客户意见，及时改进产品策划。 1.2 销售管理 销售管理流程如图 1-2 所示，主要活动有：营销策划，销售跟踪，合同管理。该流程的 主要工作成果和责任人见表 1-4。 图 1-2 销售管理流程 主要活动主要工作成果主要责任人 营销策划营销方案销售经理 销售跟踪销售跟踪表，销售合同销售人员 合同管理合同实施、收款、付款跟踪表销售人员 表 1-4 销售管理流程的成果清单和责任人 1.2.1 营销策划 销售部门商议营销方案，销售经理分配任务给执行人（可以多人） 。每个执行人填写执 产品或项目 营销策划 销售人员 - 合同管理 - 实施计划与跟踪 收款计划与跟踪 付款计划与跟踪 销售经理 销售人员 - 销售跟踪 - 接触客户 客户分析 售前服务与跟踪 签订合同 8 行情况，模板见表 1-5。 营销方案 方案名称制定人 起止日期执行人A, B 销售计划内容 执行人执行情况状态日期 A未开始，进行中，完成 B 表 1-5 营销方案 1.2.2 销售跟踪 销售人员负责：（1）销售本公司的产品；（2）从客户那里承接项目。 第一步，接触潜在客户。第一步，接触潜在客户。销售人员通过各种途径接触潜在客户，了解客户（公司）信息 和客户的需求。 第二步，客户分析。第二步，客户分析。销售人员应当撰写客户分析报告 ，为公司提供充分的客户信息 （同时也记录了自己的工作业绩） ，格式参见表 1-6。 由于售前服务会消耗公司的资源（人力、金钱、时间） ，如果客户最终不签订采购合同， 那么无效的售前服务将给公司增加成本。为了避免浪费公司的资源，节约成本，销售部门需为了避免浪费公司的资源，节约成本，销售部门需 商议是否为潜在客户提供进一步的售前服务，以及服务的程度。商议是否为潜在客户提供进一步的售前服务，以及服务的程度。 客户分析报告 客户分析 1. 客户介绍 2. 客户需求 3. 采购可能性 4. 成本效益分析 5. 风险分析 部门意见说明是否为潜在客户提供进一步的售前服务，以及服务的程度。 9 表 1-6 客户分析报告 第三步，售前服务与跟踪。第三步，售前服务与跟踪。销售人员根据潜在客户需求，提供产品演示、讲解、答疑等 服务。如果承接客户的招标项目，则按客户规定的程序进行“投标、答辩、商务谈判” 。如果 需要，销售人员应主动向研发部门申请技术支持。 销售人员填写销售跟踪表，模板见表 1-7。 销售跟踪表 客户 销售单内容 对客户的承诺 跟踪人销售单状态跟踪说明跟踪日期 表 1-7 销售跟踪表 第四步，签订合同。第四步，签订合同。如果客户确定采购，可能有 2 种方式： （1）商务谈判结束后，双方责任人将签订正式的合同。双方责任人仔细审查 合同中的每 个条款，确保合同没有错误和隐患，然后签字、盖章，使合同生效。 （2）客户承诺采购，但是目前不能签订合同。遇此情况，销售部门需请示公司领导， 决定做还是不做。 提示：如果公司销售产品，则需制定产品销售合同模板。如果公司承接客户项目， 则需制定项目销售合同模板。 1.2.3 合同管理 销售人员根据合同信息，制定实施计划、付款计划、收款计划，并跟踪这些计划的执行 情况，模板见表 1-8。 合同管理 客户名称客户方负责人 合同名称我方负责人 10 合同签订日期计划完成日期 合同摘要 计划实施日期计划说明执行人执行状态/情况说明 计划收款日期金额及用途说明执行人执行状态/情况说明 计划付款日期金额及用途说明执行人执行状态/情况说明 表 1-8 合同管理表（实施、收款、付款） 1.3 客户服务 客户服务流程如图 1-3 所示，主要活动有：受理，处理，审核关闭，客户反馈。该流程 的主要工作成果和责任人见表 1-9。 图 1-1 客户服务流程 主要活动主要工作成果主要责任人 受理客服人员 处理指定处理人 审核关闭 客服跟踪表 客服人员 客户报告 问题需求 审核关闭受理 客服人员 处理客户反馈 指定处理人客服人员客户 生成项目缺陷，项目任务，项目需求等 11 客户反馈客户 表 1-9 客户服务流程的成果清单和责任人 1.3.1 受理 客户通过各种途径报告问题（包括问题、需求、建议等） 。客服人员记录客户问题，并 指定处理人，模板见表 1-10。 1.3.2 处理 如果处理人能够直接解决客户问题，则填写处理说明，把状态置为“解决待关闭” 。如果 问题比较复杂，可以生成“项目任务、项目缺陷、项目需求”等。若“任务、缺陷、需求” 都已经完成，再把客户问题的状态置为“解决待关闭” 。 1.3.3 审核关闭 当客户问题的状态为“解决待关闭”时，客服人员验证这个问题，如果的确已经解决， 则把状态置为“关闭” ，并填写关闭说明。 1.3.4 客户反馈 客服人员告知客户其问题已经解决，并获取客户的反馈意见。 客服跟踪表 标题编号 客户/联系人客服类型 内容 受理人受理时间 受理说明 处理人处理时间 处理说明 关闭人关闭时间 12 关闭说明 客户反馈 表 1-10 客服跟踪表 1.4 客户信息管理 营销人员和客服人员均可填写客户公司信息和客户联系人信息（模板见表 1-11） 。 客户信息表 客户公司简称客户状态 客户公司全称客户类型 电话所属区域 传真所属行业 邮政编码所属城市 地址 客户公司简介 客户分析 联系人姓名部门/职务联系电话Email /即时通信 表 1-11 客户信息 13 第 2 章 项目管理过程 2.1 立项管理 立项管理的流程如图 7-1 所示，主要活动有：立项申请、PMO 受理、立项评审和项目启 动。该流程的主要工作成果和责任人见表 2-1。 图 2-1 立项管理流程 关键活动主要工作成果主要责任人 自主产品立项申请立项申请书，产品建议书，调研分析报告产品经理 合同项目立项申请立项申请书，相关合同文件合同项目的销售人员 PMO 受理立项评审通知PMO 立项评审立项评审结论立项评审委员会 项目启动项目总体计划项目经理 表 2-1 立项管理流程的主要工作成果和责任人 2.1.1 立项申请 对于自主产品，产品经理撰写立项申请书 ，并将相关附件（主要是产品建议书，产品 调研分析报告）一起提交给 PMO。 对于合同项目，销售人员撰写立项申请书 ，并将相关附件（主要是合同文件）一起提 交给 PMO。 立项申请书的格式见表 2-2。 合同项目立项申请 自主产品立项申请 项目启动 产品经理 项目团队 销售人员 PMO 受理 立项 评审 14 立项申请书 项目名称项目类型合同项目 / 自主产品 申请人申请日期 1. 项目介绍 2. 本项目对公司的价值 3. 项目进度要求 4. 项目所需人力资源 5. 项目成本估算 6. 立项可行性分析 6.1 技术可行性分析 6.2 成本-效益分析 6.3 竞争分析 6.4 风险分析 6.5 SWOT 分析 表 2-2 立项申请书的格式 2.1.2 PMO 受理 PMO 受理人审阅立项申请书和相关附件，如果发现文件内容不合流程要求或者质量 不合格，则退还给申请人重新改进，直到文件合格为止。之后，PMO 受理人将文件转交给研 发总监。提示：这样做的目的是提高立项评审的效率。 研发总监根据项目的特征，选定“立项评审委员会” ，确定评审时间。 PMO 受理人发起立项评审通知，格式见表 2-3。提示：如果项目涉及面很广，难以一次 性在立项评审会议上决定，那么研发总监可以先召开“预评审”会议，之后再进行正式的立 项评审。 立项评审通知 项目名称申请人 评审文件 评审时间地点 评审人员部门和职务 评审负责人 评委 其他参加人员 评审内容 表 2-3 立项评审通知 15 2.1.3 立项评审 PMO 通知相关人员在既定的时间参加立项评审会议， 立项评审报告格式见 2-4。 评审负责人主持评审会议，把控会议进程。 立项申请人陈述立项申请书和相关文件的主要内容。评审委员提出疑问，立项申请 人解答。双方应当对有争议的内容提出处理意见、达成共识。 每个评委发表（填写）自己的评审意见。 评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意立项”或者“不同意 立项” 。提示：评审期间应当商议“项目人力资源计划” ，避免立项之后人员不能到位的问题。 记录员（PMO 受理人）填写会议记录。 评审结束后，公司级的项目由公司领导（研发总监）给出“终审结论和意见” ，部门级项 目由部门经理给出“终审结论和意见” 。 XXX 立项评审报告 评委姓名评审意见 说明同意或者不同意的理由 评审负责人评审结论、汇总意见和人力资源计划 评审结论： 同意立项 不同意 汇总意见和人力资源计划： 记录员会议记录 领导终审结论和意见 评审结论： 同意立项 不同意 意见： 表 2-4 立项评审报告 16 2.1.4 项目启动 第第 1 步步 确定项目团队确定项目团队 部门经理根据项目特征和立项评审报告，任命合适的项目经理，并确定该项目的主要成 员。 项目经理对立项之后的项目进度和质量负责。项目成员向项目经理汇报工作。项目经理 向部门经理汇报工作。 第第 2 步步 确定项目总体计划确定项目总体计划 项目经理和项目成员共同商议，制定初步的项目总体计划 ，格式参见表 2-5。部门经 理审批该项目总体计划 ，如果有修改意见，请项目经理及时修正。 提示：在项目开发过程中，项目经理可以不断细化项目计划和修改项目计划，详见“项 目规划与监控”过程域。 项目总体计划 项目名称计划开始日期 项目经理计划结束日期 1.项目介绍 说明项目目标、关键因素及优先级 2.项目成员表 姓名角色说明（主要职责和工作时间） 3.任务进度表 名称（ 阶段 / 任务 / 评审点） 执行人计划起止日期 4.部门经理审批 审批意见 表 2-5 项目总体计划 第第 3 步步 初始化管理平台初始化管理平台 （1）PMO受理人或部门经理在管理平台中创建该项目。 17 （2）项目经理登录管理平台，进入该项目，执行初始化操作： 初始化项目成员表（含角色职责）。 把立项会议的相关文件上传到本项目的文档库中。 根据项目总体计划初始化任务进度表。 第第 4 步步 初始化软件配置管理工具初始化软件配置管理工具 （1）部门经理（或指定配置管理员）创建该项目的配置库，授予项目经理控制本项目的 权限。 （2）项目经理再分配权限给其他项目成员。 2.2 结项管理 结项管理的流程如图 7-2 所示，主要活动有：结项申请、PMO 受理、结项评审、遗留问 题跟踪和项目工作总结。该流程的主要工作成果和责任人见表 2-6。 图 2-2 结项管理流程 关键活动主要工作成果主要责任人 结项申请结项申请书项目经理 PMO 受理 结项评审 结项评估报告PMO，结项评审委员会 遗留问题跟踪问题跟踪表项目经理，PMO 项目工作总结个人工作总结，知识库所有项目成员 表 2-6 结项管理流程的主要工作成果和责任人 结项申请 项目经理 PMO 受理结项评审遗留问题跟踪 项目工作总结：个人工作总结 分析提炼 知识入库 所有项目成员 18 2.2.1 结项申请 正常情况下，当项目开发工作结束时，项目经理撰写结项申请书 ，递交给 PMO。 结 项申请书的格式见表 2-6。 对于异常结束的项目，部门经理应当明确指示项目经理，确定何时结束项目。部门经理 应当向员工们解释为什么要异常终止项目。异常中止项目的结项流程与正常结项流程相同。 2.2.2 PMO 受理 PMO受理人审阅结项申请书和相关附件，如果发现文件内容不合流程要求或者质量 不合格，则退还给申请人重新改进，直到文件合格为止。之后，PMO受理人将文件转交给研 发总监。提示：这样做的目的是提高立项评审的效率。 研发总监根据项目的特征，选定“结项评审委员会” ，确定评审时间。PMO受理人发起结 项评审通知，格式和立项评审通知相同（见表2-3） 。 结项申请书 项目名称项目经理 1. 项目完成情况计划情况实际情况 主要功能 项目起止日期 人员和工作量 项目成本 应递交的成果 2. 资产清单（资金和设备，软件等）说明、处理建议 3. 专利和版权 4. 项目价值体现阐述：项目质量，市场价值，成本效益，对机构的贡献 5. 人员业绩工作业绩描述评价人 人员 A 人员 B 项目经理签字 19 表 2-6 结项申请书 2.2.3 结项评审 PMO 通知相关人员在既定的时间参加结项评审会议。 评审负责人主持评审会议，把控会议进程。 立项申请人陈述结项申请书的主要内容。评审委员提出疑问，立项申请人解答。双 方应当对有争议的内容提出处理意见、达成共识。 每个评委发表（填写）自己的评审意见。 评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意结项”或者“不同意 结项” 。 记录员（PMO 受理人）填写会议记录。 结项评审报告的格式见表 2-7。 XXX 结项评审报告 评委姓名评审意见 评审负责人评审结论和汇总意见 评审结论： 同意结项 不同意 汇总意见： （1）项目任务完成情况。 （2）项目资产处理意见。 （3）发掘可以重复利用的知识财富，给出应用建议。 （4）项目的价值：市场价值、成本效益、技术积累等 记录员会议记录 表 2-7 结项评审报告 提示：项目结项后，该项目的人力资源和设备资源将被释放，应用于新的项目。项目成 员有义务维护自己参与的项目。 20 2.2.4 遗留问题跟踪 项目结项后，尚有一些遗留问题，项目经理填写“问题表” ，PMO 人员跟踪该问题表， 确保所有问题得到妥善处理。详见“问题跟踪”过程域。 2.2.5 项目工作总结 第 1 步。所有项目成员都要撰写个人工作总结 ，格式见表 2-8，在公司范围内共享经 验教训。 第 2 步。项目经理召集所有项目成员，讨论每个人的工作总结，提炼出知识财富。 第 3 步。把知识财富按照一定的格式保存在集成化管理平台中。 项目名称 个人工作总结 撰写人日期 工作总结 1. 本人在项目中的主要任务 2. 遇到哪些问题，如何解决 3. 经验教训和建议 表 2-8 个人工作总结 2.3 项目规划与监控 项目规划（Project Planning）是指对本项目的人力资源、任务进度、成本等做出合适的 安排，制定出一些计划（包括宏观的和细节的） ，使大家按照计划行事，最终顺利地达到预定 的目标。 项目监控是将项目实际情况与项目计划进行对比，如果发现某些因素（如人力资源、任 务进度、成本等）的偏差比较大，那么及时分析原因，给出纠正措施。项目监控至少有两个 好处：（1）避免原本合理的计划在实施过程时落空；（2）避免“执迷不悟”地按照原本不 合理的计划行事。 项目规划与监控的重点是：“人员角色” 、 “任务进度” 、 “项目成本” 、 “项目评审” 。 2.3.1 项目人员角色 项目经理向部门争取“完成本项目充分必要的人员” ，项目人员到位后，项目经理确定每 21 个人员在本项目的角色、工作内容和时间，格式见表 2-9。 姓名角色工作描述（简要说明工作内容和时间） 表 2-9 项目人员角色表 2.3.2 任务进度管理 项目经理根据“本项目需求和人力资源”分解任务，和项目成员协商后，把任务交给最 合适的人员去执行。简而言之，就是要“知人善用” 。 “知人”是指领导者应当非常了解他的 团队成员，包括知识技能和性格爱好等等。 “善用”是指让团队各成员扬长避短，使团队战斗 力达到最强。 项目经理还要有意识地锻炼、提升成员们全局开发的能力，要保证至少有一人可以替换 别人的工作。否则万一某人缺席（如离职、休假等） ，将导致工作被中断。 任务进度管理的流程如图 2-3 所示，主要活动和步骤如下： 图 2-3 任务进度管理的流程 第第 1 步步. 制定任务进度计划制定任务进度计划 项目经理和项目成员们共同协商任务，大家达成共识后制定任务进度计划，每个任务的 主要数据如下： 任务名称，任务描述，预计工作成果 开始日期，计划完成日期 任务执行人（可以多个） ，计划工作量 第第 2 步步. 填写执行信息填写执行信息 每个任务的执行人（可以多个）填写执行信息，主要数据如下： 执行人，填写日期 1. 制定任务计划2. 填写执行信息 调整 3. 纠正偏差 22 任务状态（进行中，已完成） 当前进度（百分比） 实际工作量，执行说明 第第 3 步步. 纠正偏差纠正偏差 如果任务的执行情况和计划之间的偏差比较大（例如工作量、完成日期的误差超过 20） ，项目经理应当和执行人交流，分析原因并给出解决措施：（1）若原计划太乐观了， 那么适当修改原计划；（2）若执行人工作不得力，那么要求执行人加班追赶进度。 2.3.3 项目成本管理 项目经理应当懂得“非财务人员”的项目成本管理。项目成本管理的流程如图 2-4 所示， 主要活动和步骤如下： 图 2-4 项目成本管理的流程图 第第 1 步步. 制定项目预算制定项目预算 项目经理制定项目预算表，每条记录的主要数据有： 金额； 预算类型（例如硬件、软件、办公消耗等） ； 用途说明。 第第 2 步步. 记录实际开支记录实际开支 项目经理和项目成员记录实际开支，每条记录的主要数据有： 经办人，开支时间； 金额； 预算类型（例如硬件、软件、办公消耗等） ； 用途说明。 第第 3 步步. 对比分析、控制成本对比分析、控制成本 项目经理随时对比分析“成本预算表”和“实际开支表”，尽量避免超支。项目经理应当向 1. 制定项目预算2. 记录实际开支 调整 3.对比分析、控制成本 23 上级领导解释为什么超支。 2.3.4 项目评审（决策评审和技术评审） 项目评审分两类：决策评审和技术评审，两者的流程相同，但是目的不同。 决策评审的目的是利用集体（所有评审人员）的智慧，做出正确的决策，决定项目工作 继续进行还是终止。 技术评审的目的是及时发现工作成果中问题，提出改进建议，使工作成果变得更好。 第第1 1步步. . 发起评审通知发起评审通知 发起人根据项目计划（或者项目经理的指示）发出评审通知，明确评审会议的内容、参 加人员、时间、地点等信息，评审通知的格式参见表2-3。一般地，默认的评审负责人是 项目经理，如果项目经理不能做出决定，可以重新指定其他人担任评审负责人。 第第2 2步步. . 评审负责人召开评审会议评审负责人召开评审会议 （1）发起人讲解待评审的成果。 （2）评审人员现场提问和讨论，发起人解答疑问。 （3）所有评审人员给出评审意见。 （4）评审负责人汇总评审意见，给出评审结论。 （5）记录员输入会议记录。 评审报告的格式参见表 2-4。 2.4 变更控制 项目开发过程中发生变更是司空见惯的事情。这里“变更”是指改变已经发布的工作成 果（如文档、代码或者计划等） ，修改草稿不叫变更。变更控制的目的不是为了“预防变更” ， 而是为了“防止变更失去控制产生坏的后果” 。变更控制的最大困难在于变更控制的最大困难在于“如何拒绝客户或上如何拒绝客户或上 级领导提出的不合理变更要求级领导提出的不合理变更要求” 。 变更控制的流程如图 2-5 所示，主要活动有：变更申请、评审和审批和执行变更。 变更申请 拒绝变更拒绝变更 同意变更 执行变更 申请人评审人和审批人执行人 评审和审批 24 图 2-5 变更控制流程 提示：一般情况下，先申请，审批通过后，再执行变更。在实际工作中，由于时间紧迫， 对于低风险的变更，允许先执行变更，后补写变更申请。 变更控制报告的参考格式如表 2-10 所示。 第第 1 步步. 变更申请变更申请 项目开发过程中，所有人员（包括销售人员、项目成员和上级领导）提出的变更申请， 必须说明“变更内容和原因” 。由项目经理受理，指定多个评审人和一位“审批负责人” ，一 般情况下，项目经理担任审批负责人。 如果对项目的技术方案、进度、质量、成本产生重大影响的变更，项目经理做不了决定， 那么可以指定上级领导担任审批负责人。 第第 2 步步. 评审和审批评审和审批 每个评审人都可以发表意见（但是不做决定） 。由“审批负责人”做决定：“同意变更” 或者“拒绝变更” ，并给出指示。 第第 3 步步. 执行变更执行变更 审批负责人同意变更后，由项目经理安排人员执行具体的变更工作，调整相应的任务进度 计划，通知给受变更影响的相关人员。 1. 变更申请 项目名称 变更原因和内容 说明变更原因和变更内容，估计此变更对项目造成的影响。 变更申请人 评审人可以多人 审批负责人可以逐级审批 2. 变更审批 评审人评审意见 同意变更 拒绝变更 审批负责人 指示： 25 3. 执行变更 执行人说明 表 2-10 变更控制报告 2.5 沟通管理 沟通管理包括项目内部沟通、跨部门沟通、与上级领导沟通、与客户沟通等，要及时记 录重要的沟通信息，避免遗忘，模板见表 2-11。 沟通记录 标题沟通日期 沟通对象客户或公司内部人员填写人 沟通方式面谈 / 电话 / email / 网络交流 沟通结果达成共识 / 存在异议 / 搁置 详细信息 表 2-11 沟通记录 项目开发过程中存在各种各样的风险，需要项目经理（和销售人员）及时地和客户沟通。 “客户沟通”主要目的是“消除摩擦、增进关系” 、 “处理不合理的变更”和“发掘新的商机” 。 一、消除摩擦、增进关系一、消除摩擦、增进关系 项目经理（和销售人员）应经常和客户沟通，尽可能地消除客户对需求、进度、质量的 不满。如果双方工作人员之间发生摩擦，项目经理（和销售人员）应及时消除摩擦。 为了不断改善开发方和客户方的人际关系，项目经理（和销售人员）在时间、经费允许 的前提下，主动邀请客户方人员参加友谊活动，例如运动、聚餐、娱乐等等。 二、二、 处理不合理的变更处理不合理的变更 项目经理（和销售人员）要设法“拒绝客户提出的不合理变更” 。 所谓“不合理的变更”是指：客户提出的变更不是由于开发方的过错引起的，此变更造 成开发方承担了额外的成本，但是客户不愿意支付相应的费用。 客户会想当然地以为变更是他的权利，通常情况下开发方是不敢得罪客户的，但是无原 则地退让将使开发团队陷入困境。这里建议了三种应对方法： 26 方法方法 1：依据合同处理变更：依据合同处理变更 如果客户是很有信誉、严格按照合同办事的企业，那么双方应当依据合同中的条款处理 变更纠纷。这就要求双方在签订合同的时候，要在合同中写明“变更处理协议” 。例如： 当需求规格说明书被双方确认之后，如果再发生需求变更的话，那么按照“变 更申请审批执行”的变更管理流程执行。 如果客户（或者开发方）提出的变更对项目进度、成本的影响超过 10%，那么双方 要重新协商成本、资源和进度，否则开发方（或者客户）可以拒绝变更请求。 方法方法 2：设法拖延到下个版本：设法拖延到下个版本 如果双方签订的合同中没有“变更协议” ，或者有变更协议但是客户找出很多理由来搪塞， 只要双方还没有完全闹僵的话，项目经理（和销售人员）需要一些社交技巧来减缓矛盾： 首先承认客户提出的需求变更请求是合理的（让客户面子上过得去） ；再阐述己方的 难处和变更对客户造成的不利影响，例如质量问题等等，让客户明白随意变更对他自己 也没有好处；最后建议在开发新版本的时候实现客户提出的变更。 这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。拖延到下个 版本实现客户的变更，有可能让客户支付升级费用。即使升级是免费的，也不会延误当 前项目的进度和客户验收，让开发方及时拿到合同经费。 方法方法 3：让客户欠下人情：让客户欠下人情 如果客户提出重大的变更请求，既不愿意支付变更的费用，也不愿意延缓到下个版本中 实现，而且客户也知道自己理亏，但是现实环境迫使客户必须那样做。开发方没有办法拒绝， 因为倘若拒绝的话，就得不到合同余款，怎么办？ 在这种情况下，开发方只能接受让自己吃亏的变更，但是还有办法减少损失，这个办法 就是“让客户欠下人情” 。 销售人员（和项目经理）应当真诚地和客户沟通，让客户明白“开发方为了客户的 利益付出了额外的代价” 。只要客户是个讲道理的正常人，那么客户会感激开发方的帮助， 觉得自己欠下了“人情” ，可以约定在后面恰当的机会回报开发方。例如，在客户验收的 时候，适当地放松要求，及时地向开发方支付合同费用等，这些回报对开发方而言都是 隐形的收益。 三、发掘新的商机三、发掘新的商机 项目经理（和销售人员）和客户交往的过程中，不仅要关注已经签订合同的项目进展情 况，还要不断发掘新的商机，例如： 发掘客户更深层次的需求，吸引客户继续采购（例如不断升级） 。 27 将合同项目的成果转化成为通用的产品或构件，卖给其它客户。 请老客户推荐其新客户。 2.6 问题跟踪 问题跟踪的范围包括：开发过程中的各种问题、风险和建议，以及结项后遗留的问题。开发过程中的各种问题、风险和建议，以及结项后遗留的问题。 问题跟踪的一般步骤如图 2-6 所示，问题跟踪表见表 2-12。 第 1 步。报告者创建问题，指定接收者，此时状态为“新的” 。 第 2 步。接受者处理问题，状态为“正在处理” 。 第 3 步。如果已经解决了问题，则把状态置为“解决待关闭” 。 第 4 步。报告者审核这个问题，如果确定该问题已经解决，则把状态设置为“关闭” 。如 果发现问题没有解决，则可以“重新打开”问题，回到第 2 步。 图 2-6 问题跟踪示意图 问题跟踪表 问题编号问题类型 重要性紧急程度 问题描述 报告者报告时间 接受者期望完成日期 问题处理方案 当前状态实际完全日期 报告问题 报告者接受者报告者 处理问题解决待关闭审核关闭 接受者 重新打开 28 审核关闭意见 表 2-12 问题跟踪表 29 第 3 章 项目研发过程 3.1 需求开发与管理 需求开发与管理是指通过“调研、分析、定义、评审、跟踪”等活动，使开发方和委托 方（客户或本公司领导）对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发 工作（如设计、编程、测试等） 。 项目经理根据本项目的人力资源来确定需求分析员（可以多人） 。需求分析员负责开展调 研、分析、定义、评审、跟踪等活动。 3.1.1 需求调研 需求分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得漫无 边际。 需求分析员确定需求调研的方式，例如： 与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操作。 向用户群体发调查问卷。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求。 从行业标准、规则中提取需求。 从 Internet 上搜查相关资料。 需求分析员在调研过程中随时填写“客户需求记录” ，参考格式如表 3-1 所示。 项目名称需求分析员 调研方式被调研者 时间、地点 需求标题客户需求记录 表 3-1 客户需求记录 需求分析员整理所有客户需求记录，归纳与总结共性的需求，为撰写详细的需求规格 说明书作准备。调研过程中获取的需求信息可以作为需求规格说明书的附件。 30 3.1.2 需求分析 需求分析是对各种来源的需求信息进行分析，消除错误，刻画细节等。常见的需求分析 方法有“问答分析法”和“建模分析法”两类。 问答分析最重要的问题是：“是什么”和“为什么” 。每个需求都应当用陈述句说明“是 什么” ，如果“是什么”的内涵不够清晰，则应补充说明“不是什么” 。如果“是什么”和 “不是什么”并不是“理所当然”的，那么应当解释“为什么” ，以便加深读者的理解。追究 “是什么”和“为什么”的目的是获得正确、清楚的需求。 对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来 描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。 现代建模工具如 Rose 有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要 注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人 员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图用以完整地描述需求。需求建模不可能取代文字描述。在在 需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需 求文档的附录中，便于正文引用。 3.1.3 需求定义 需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，撰写需求 规格说明书 ，模板见表 3-2。提示：若有其它类型的需求规格说明书，请另定义模板。 软件需求规格说明书 1. 背景介绍 2. 软件系统的用户介绍 2.1 用户类型和角色职责 2.2 用户组织结构图（可选） 2.3 用户的信息化情况 3. 用户业务流程介绍 4. 软件系统的约束 5. 软件系统当前版本的范围 6. 软件系统的功能清单 7. 模块需求说明（可以写在单独的模块文档中） 8. 其它需求 9. 签字确认 31 表 3-2 软件需求规格说明书 3.1.4 需求评审 需求分析员邀请项目成员（包括项目经理）和客户代表共同评审需求规格说明书 ，大 家尽最大努力使需求规格说明书能够正确无误地反映用户的真实意愿。 需求评审的流程见“项目评审流程” 。一般地，需求分析员为申请人，项目经理为评审负 责人，项目成员和客户代表可以担任评审员。所有评审人员认真检查需求文档，力求使需求 文档达到正确、清楚、无二义性、一致、必要、完备、可实现、可验证。 3.1.5 需求跟踪 第第 1 1 步。步。需求分析员创建需求的目录结构，便于人们阅读。 第第 2 2 步。步。需求分析员输入每条需求的详细内容，可以多次细化修改，每次修改后应通知 相关项目成员。 第第 3 3 步。步。需求分析员跟踪每条需求的进展状况，填写需求跟踪记录（当前状态和情况说 明），需求跟踪表的格式见表 3-3。 需求跟踪表 需求目录/名称优先级状态责任人关联信息（文档，任务，缺陷等） 表 3-3 需求跟踪表 3.2 系统设计 3.2.1 软件系统设计 软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计等，在需求与代 码之间建立桥梁，指导工作人员开发能够满足用户需求的软件系统。 项目经理根据本项目的人力资源来确定软件设计师（可以多人） 。 软件设计师撰写软件设计师撰写软件系统设计说明书软件系统设计说明书 ，并构造可运行的软件系统框架，所有的模块都，并构造可运行的软件系统框架，所有的模块都 32 是在该系统框架上开发和运行。是在该系统框架上开发和运行。 软件系统设计说