上海漫索计算机科技有限公司
http://www.mansuo.com
产品管理流程如图6-1所示，主要活动有：产品策划，调研分析，产品立项与开发，产品销售与服务。该流程的主要工作成果和责任人见表1-1。
图1-1 产品管理流程
表1-1 产品管理流程的成果清单和责任人
1.1.1 产品策划
产品经理负责产品策划活动。产品经理应主动寻求研发部门的帮助，由产品经理牵头，撰写《产品建议书》，模板见表1-2。
提示：本产品立项之后，项目团队将进一步细化产品需求、设计方案和开发计划等。
表1-2 产品建议书
1.1.2 调研分析
产品经理在做产品策划时，应同步进行调研分析。产品经理撰写《产品调研分析报告》，模板见表1-3，目的是为公司决策提供充分的、有价值的信息。
提示：如果不做调研分析的话，那么产品建议和立项管理都建立在空想之上。
调研者应当客观地对待被调查的事物，不可有意往“好处”或者“坏处”设想。所获取的数据、图表等信息要真实并且有据可查，不可凭空捏造。
调研分析的主要内容有：
✧ 消费者（购买者，使用者，影响者）调研；
✧ 竞争对手和同类产品调研；
✧ 政策调研；
✧ 技术可行性分析；
✧ 知识产权分析；
✧ 成本—收益分析；
表1-3 产品调研分析报告
1.1.3 产品立项与开发
产品经理负责立项申请，撰写《立项申请书》，提交给PMO，进入立项管理流程。
如果本产品被批准立项，则：
✧ 项目经理将管理本产品的开发过程，对产品的质量和进度负责。
✧ 产品经理要跟踪开发过程，及时了解产品的开发进度和工作成果质量。如果产品经理发现开发工作偏离了产品需求和预定的计划，应当及时和项目经理沟通，纠正偏差。
建议开发团队采用增量模式来开发产品，每次发布新的版本，既要请测试人员进行测试，又要请产品经理来体验（试用）。
产品经理应当站在客户的角度来体验（试用）当前产品：
✧ 如果发现产品中的缺陷，则向开发人员报告缺陷，开发人员及时消除缺陷。
✧ 若产品经理向项目经理提出改进建议，双方应先就需求和改进措施达成共识，然后开发人员执行相应的改进措施。
1.1.4 产品销售与服务
产品开发完成之后，产品经理负责：
✧ 撰写产品介绍文件（如ppt文件）。
✧ 制作本产品的宣传网页，设法在更多的网站发布产品信息。
✧ 可能需要设计和制作宣传页（印刷品）。
✧ 产品经理对本公司销售人员进行产品培训，使销售人员充分了解本产品的特性。
上述工作完成之后，进入销售管理流程和客户服务流程。产品经理跟踪销售和客服过程，收集并分析客户意见，及时改进产品策划。
销售管理流程如图1-2所示，主要活动有：营销策划，销售跟踪，合同管理。该流程的主要工作成果和责任人见表1-4。
图1-2 销售管理流程
表1-4 销售管理流程的成果清单和责任人
1.2.1 营销策划
销售部门商议营销方案，销售经理分配任务给执行人（可以多人）。每个执行人填写执行情况，模板见表1-5。
表1-5 营销方案
1.2.2 销售跟踪
销售人员负责：（1）销售本公司的产品；（2）从客户那里承接项目。
第一步，接触潜在客户。销售人员通过各种途径接触潜在客户，了解客户（公司）信息和客户的需求。
第二步，客户分析。销售人员应当撰写《客户分析报告》，为公司提供充分的客户信息（同时也记录了自己的工作业绩），格式参见表1-6。
由于售前服务会消耗公司的资源（人力、金钱、时间），如果客户最终不签订采购合同，那么无效的售前服务将给公司增加成本。为了避免浪费公司的资源，节约成本，销售部门需商议是否为潜在客户提供进一步的售前服务，以及服务的程度。
表1-6 客户分析报告
第三步，售前服务与跟踪。销售人员根据潜在客户需求，提供产品演示、讲解、答疑等服务。如果承接客户的招标项目，则按客户规定的程序进行“投标、答辩、商务谈判”。如果需要，销售人员应主动向研发部门申请技术支持。
销售人员填写销售跟踪表，模板见表1-7。
表1-7 销售跟踪表
第四步，签订合同。如果客户确定采购，可能有2种方式：
（1）商务谈判结束后，双方责任人将签订正式的合同。双方责任人仔细审查合同中的每个条款，确保合同没有错误和隐患，然后签字、盖章，使合同生效。
（2）客户承诺采购，但是目前不能签订合同。遇此情况，销售部门需请示公司领导，决定做还是不做。
提示：如果公司销售产品，则需制定《产品销售合同》模板。如果公司承接客户项目，则需制定《项目销售合同》模板。
1.2.3 合同管理
销售人员根据合同信息，制定实施计划、付款计划、收款计划，并跟踪这些计划的执行情况，模板见表1-8。
表1-8 合同管理表（实施、收款、付款）
客户服务流程如图1-3所示，主要活动有：受理，处理，审核关闭，客户反馈。该流程的主要工作成果和责任人见表1-9。
图1-1 客户服务流程
表1-9 客户服务流程的成果清单和责任人
1.3.1 受理
客户通过各种途径报告问题（包括问题、需求、建议等）。客服人员记录客户问题，并指定处理人，模板见表1-10。
1.3.2 处理
如果处理人能够直接解决客户问题，则填写处理说明，把状态置为“解决待关闭”。如果问题比较复杂，可以生成“项目任务、项目缺陷、项目需求”等。若“任务、缺陷、需求”都已经完成，再把客户问题的状态置为“解决待关闭”。
1.3.3 审核关闭
当客户问题的状态为“解决待关闭”时，客服人员验证这个问题，如果的确已经解决，则把状态置为“关闭”，并填写关闭说明。
1.3.4 客户反馈
客服人员告知客户其问题已经解决，并获取客户的反馈意见。
表1-10 客服跟踪表
营销人员和客服人员均可填写客户公司信息和客户联系人信息（模板见表1-11）。
表1-11 客户信息
立项管理的流程如图7-1所示，主要活动有：立项申请、PMO受理、立项评审和项目启动。该流程的主要工作成果和责任人见表2-1。
图2-1 立项管理流程
表2-1 立项管理流程的主要工作成果和责任人
2.1.1 立项申请
对于自主产品，产品经理撰写《立项申请书》，并将相关附件（主要是产品建议书，产品调研分析报告）一起提交给PMO。
对于合同项目，销售人员撰写《立项申请书》，并将相关附件（主要是合同文件）一起提交给PMO。
《立项申请书》的格式见表2-2。
表2-2 立项申请书的格式
2.1.2 PMO受理
PMO受理人审阅《立项申请书》和相关附件，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。之后，PMO受理人将文件转交给研发总监。提示：这样做的目的是提高立项评审的效率。
研发总监根据项目的特征，选定“立项评审委员会”，确定评审时间。
PMO受理人发起立项评审通知，格式见表2-3。提示：如果项目涉及面很广，难以一次性在立项评审会议上决定，那么研发总监可以先召开“预评审”会议，之后再进行正式的立项评审。
表2-3 立项评审通知
2.1.3 立项评审
PMO通知相关人员在既定的时间参加立项评审会议，《立项评审报告》格式见2-4。
评审负责人主持评审会议，把控会议进程。
立项申请人陈述《立项申请书》和相关文件的主要内容。评审委员提出疑问，立项申请人解答。双方应当对有争议的内容提出处理意见、达成共识。
每个评委发表（填写）自己的评审意见。
评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意立项”或者“不同意立项”。提示：评审期间应当商议“项目人力资源计划”，避免立项之后人员不能到位的问题。
记录员（PMO受理人）填写会议记录。
评审结束后，公司级的项目由公司领导（研发总监）给出“终审结论和意见”，部门级项目由部门经理给出“终审结论和意见”。
表2-4 立项评审报告
2.1.4 项目启动
第1步 确定项目团队
部门经理根据项目特征和立项评审报告，任命合适的项目经理，并确定该项目的主要成员。
项目经理对立项之后的项目进度和质量负责。项目成员向项目经理汇报工作。项目经理向部门经理汇报工作。
第2步 确定项目总体计划
项目经理和项目成员共同商议，制定初步的《项目总体计划》，格式参见表2-5。部门经理审批该《项目总体计划》，如果有修改意见，请项目经理及时修正。
提示：在项目开发过程中，项目经理可以不断细化项目计划和修改项目计划，详见“项目规划与监控”过程域。
表2-5 项目总体计划
第3步 初始化管理平台
（1）PMO受理人或部门经理在管理平台中创建该项目。
（2）项目经理登录管理平台，进入该项目，执行初始化操作：
初始化项目成员表（含角色职责）。
把立项会议的相关文件上传到本项目的文档库中。
根据《项目总体计划》初始化任务进度表。
第4步 初始化软件配置管理工具
（1）部门经理（或指定配置管理员）创建该项目的配置库，授予项目经理控制本项目的权限。
（2）项目经理再分配权限给其他项目成员。
结项管理的流程如图7-2所示，主要活动有：结项申请、PMO受理、结项评审、遗留问题跟踪和项目工作总结。该流程的主要工作成果和责任人见表2-6。
图2-2 结项管理流程
表2-6 结项管理流程的主要工作成果和责任人
2.2.1 结项申请
正常情况下，当项目开发工作结束时，项目经理撰写《结项申请书》，递交给PMO。《结项申请书》的格式见表2-6。
对于异常结束的项目，部门经理应当明确指示项目经理，确定何时结束项目。部门经理应当向员工们解释为什么要异常终止项目。异常中止项目的结项流程与正常结项流程相同。
2.2.2 PMO受理
PMO受理人审阅《结项申请书》和相关附件，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。之后，PMO受理人将文件转交给研发总监。提示：这样做的目的是提高立项评审的效率。
研发总监根据项目的特征，选定“结项评审委员会”，确定评审时间。PMO受理人发起结项评审通知，格式和立项评审通知相同（见表2-3）。
表2-6 结项申请书
2.2.3 结项评审
PMO通知相关人员在既定的时间参加结项评审会议。
评审负责人主持评审会议，把控会议进程。
立项申请人陈述《结项申请书》的主要内容。评审委员提出疑问，立项申请人解答。双方应当对有争议的内容提出处理意见、达成共识。
每个评委发表（填写）自己的评审意见。
评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意结项”或者“不同意结项”。
记录员（PMO受理人）填写会议记录。《结项评审报告》的格式见表2-7。
表2-7 结项评审报告
提示：项目结项后，该项目的人力资源和设备资源将被释放，应用于新的项目。项目成员有义务维护自己参与的项目。
2.2.4 遗留问题跟踪
项目结项后，尚有一些遗留问题，项目经理填写“问题表”，PMO人员跟踪该问题表，确保所有问题得到妥善处理。详见“问题跟踪”过程域。
2.2.5 项目工作总结
第1步。所有项目成员都要撰写《个人工作总结》，格式见表2-8，在公司范围内共享经验教训。
第2步。项目经理召集所有项目成员，讨论每个人的工作总结，提炼出知识财富。
第3步。把知识财富按照一定的格式保存在集成化管理平台中。
表2-8 个人工作总结
项目规划（Project Planning）是指对本项目的人力资源、任务进度、成本等做出合适的安排，制定出一些计划（包括宏观的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
项目监控是将项目实际情况与项目计划进行对比，如果发现某些因素（如人力资源、任务进度、成本等）的偏差比较大，那么及时分析原因，给出纠正措施。项目监控至少有两个好处：（1）避免原本合理的计划在实施过程时落空；（2）避免“执迷不悟”地按照原本不合理的计划行事。
项目规划与监控的重点是：“人员角色”、“任务进度”、“项目成本”、“项目评审”。
2.3.1 项目人员角色
项目经理向部门争取“完成本项目充分必要的人员”，项目人员到位后，项目经理确定每个人员在本项目的角色、工作内容和时间，格式见表2-9。
表2-9 项目人员角色表
2.3.2 任务进度管理
项目经理根据“本项目需求和人力资源”分解任务，和项目成员协商后，把任务交给最合适的人员去执行。简而言之，就是要“知人善用”。“知人”是指领导者应当非常了解他的团队成员，包括知识技能和性格爱好等等。“善用”是指让团队各成员扬长避短，使团队战斗力达到最强。
项目经理还要有意识地锻炼、提升成员们全局开发的能力，要保证至少有一人可以替换别人的工作。否则万一某人缺席（如离职、休假等），将导致工作被中断。
任务进度管理的流程如图2-3所示，主要活动和步骤如下：
图2-3 任务进度管理的流程
第1步. 制定任务进度计划
项目经理和项目成员们共同协商任务，大家达成共识后制定任务进度计划，每个任务的主要数据如下：
任务名称，任务描述，预计工作成果
开始日期，计划完成日期
任务执行人（可以多个），计划工作量
第2步. 填写执行信息
每个任务的执行人（可以多个）填写执行信息，主要数据如下：
执行人，填写日期
任务状态（进行中，已完成）
当前进度（百分比）
实际工作量，执行说明
第3步. 纠正偏差
如果任务的执行情况和计划之间的偏差比较大（例如工作量、完成日期的误差超过20％），项目经理应当和执行人交流，分析原因并给出解决措施：（1）若原计划太乐观了，那么适当修改原计划；（2）若执行人工作不得力，那么要求执行人加班追赶进度。
2.3.3 项目成本管理
项目经理应当懂得“非财务人员”的项目成本管理。项目成本管理的流程如图2-4所示，主要活动和步骤如下：
图2-4 项目成本管理的流程图
第1步. 制定项目预算
项目经理制定项目预算表，每条记录的主要数据有：
金额；
预算类型（例如硬件、软件、办公消耗等）；
用途说明。
第2步. 记录实际开支
项目经理和项目成员记录实际开支，每条记录的主要数据有：
经办人，开支时间；
金额；
预算类型（例如硬件、软件、办公消耗等）；
用途说明。
第3步. 对比分析、控制成本
项目经理随时对比分析“成本预算表”和“实际开支表”，尽量避免超支。项目经理应当向上级领导解释为什么超支。
2.3.4 项目评审（决策评审和技术评审）
项目评审分两类：决策评审和技术评审，两者的流程相同，但是目的不同。
决策评审的目的是利用集体（所有评审人员）的智慧，做出正确的决策，决定项目工作继续进行还是终止。
技术评审的目的是及时发现工作成果中问题，提出改进建议，使工作成果变得更好。
第1步. 发起评审通知
发起人根据项目计划（或者项目经理的指示）发出评审通知，明确评审会议的内容、参加人员、时间、地点等信息，《评审通知》的格式参见表2-3。一般地，默认的评审负责人是项目经理，如果项目经理不能做出决定，可以重新指定其他人担任评审负责人。
第2步. 评审负责人召开评审会议
（1）发起人讲解待评审的成果。
（2）评审人员现场提问和讨论，发起人解答疑问。
（3）所有评审人员给出评审意见。
（4）评审负责人汇总评审意见，给出评审结论。
（5）记录员输入会议记录。
《评审报告》的格式参见表2-4。
项目开发过程中发生变更是司空见惯的事情。这里“变更”是指改变已经发布的工作成果（如文档、代码或者计划等），修改草稿不叫变更。变更控制的目的不是为了“预防变更”，而是为了“防止变更失去控制产生坏的后果”。变更控制的最大困难在于“如何拒绝客户或上级领导提出的不合理变更要求”。
变更控制的流程如图2-5所示，主要活动有：变更申请、评审和审批和执行变更。
图2-5 变更控制流程
提示：一般情况下，先申请，审批通过后，再执行变更。在实际工作中，由于时间紧迫，对于低风险的变更，允许先执行变更，后补写变更申请。
《变更控制报告》的参考格式如表2-10所示。
第1步. 变更申请
项目开发过程中，所有人员（包括销售人员、项目成员和上级领导）提出的变更申请，必须说明“变更内容和原因”。由项目经理受理，指定多个评审人和一位“审批负责人”，一般情况下，项目经理担任审批负责人。
如果对项目的技术方案、进度、质量、成本产生重大影响的变更，项目经理做不了决定，那么可以指定上级领导担任审批负责人。
第2步. 评审和审批
每个评审人都可以发表意见（但是不做决定）。由“审批负责人”做决定：“同意变更”或者“拒绝变更”，并给出指示。
第3步. 执行变更
审批负责人同意变更后，由项目经理安排人员执行具体的变更工作，调整相应的任务进度计划，通知给受变更影响的相关人员。
表2-10 变更控制报告
沟通管理包括项目内部沟通、跨部门沟通、与上级领导沟通、与客户沟通等，要及时记录重要的沟通信息，避免遗忘，模板见表2-11。
表2-11 沟通记录
项目开发过程中存在各种各样的风险，需要项目经理（和销售人员）及时地和客户沟通。“客户沟通”主要目的是“消除摩擦、增进关系”、“处理不合理的变更”和“发掘新的商机”。
一、消除摩擦、增进关系
项目经理（和销售人员）应经常和客户沟通，尽可能地消除客户对需求、进度、质量的不满。如果双方工作人员之间发生摩擦，项目经理（和销售人员）应及时消除摩擦。
为了不断改善开发方和客户方的人际关系，项目经理（和销售人员）在时间、经费允许的前提下，主动邀请客户方人员参加友谊活动，例如运动、聚餐、娱乐等等。
二、 处理不合理的变更
项目经理（和销售人员）要设法“拒绝客户提出的不合理变更”。
所谓“不合理的变更”是指：客户提出的变更不是由于开发方的过错引起的，此变更造成开发方承担了额外的成本，但是客户不愿意支付相应的费用。
客户会想当然地以为变更是他的权利，通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发团队陷入困境。这里建议了三种应对方法：
方法1：依据合同处理变更
如果客户是很有信誉、严格按照合同办事的企业，那么双方应当依据合同中的条款处理变更纠纷。这就要求双方在签订合同的时候，要在合同中写明“变更处理协议”。例如：
当《需求规格说明书》被双方确认之后，如果再发生需求变更的话，那么按照“变更申请－审批－执行”的变更管理流程执行。
如果客户（或者开发方）提出的变更对项目进度、成本的影响超过10%，那么双方要重新协商成本、资源和进度，否则开发方（或者客户）可以拒绝变更请求。
方法2：设法拖延到下个版本
如果双方签订的合同中没有“变更协议”，或者有变更协议但是客户找出很多理由来搪塞，只要双方还没有完全闹僵的话，项目经理（和销售人员）需要一些社交技巧来减缓矛盾：
首先承认客户提出的需求变更请求是合理的（让客户面子上过得去）；再阐述己方的难处和变更对客户造成的不利影响，例如质量问题等等，让客户明白随意变更对他自己也没有好处；最后建议在开发新版本的时候实现客户提出的变更。
这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。拖延到下个版本实现客户的变更，有可能让客户支付升级费用。即使升级是免费的，也不会延误当前项目的进度和客户验收，让开发方及时拿到合同经费。
方法3：让客户欠下人情
如果客户提出重大的变更请求，既不愿意支付变更的费用，也不愿意延缓到下个版本中实现，而且客户也知道自己理亏，但是现实环境迫使客户必须那样做。开发方没有办法拒绝，因为倘若拒绝的话，就得不到合同余款，怎么办？
在这种情况下，开发方只能接受让自己吃亏的变更，但是还有办法减少损失，这个办法就是“让客户欠下人情”。
销售人员（和项目经理）应当真诚地和客户沟通，让客户明白“开发方为了客户的利益付出了额外的代价”。只要客户是个讲道理的正常人，那么客户会感激开发方的帮助，觉得自己欠下了“人情”，可以约定在后面恰当的机会回报开发方。例如，在客户验收的时候，适当地放松要求，及时地向开发方支付合同费用等，这些回报对开发方而言都是隐形的收益。
三、发掘新的商机
项目经理（和销售人员）和客户交往的过程中，不仅要关注已经签订合同的项目进展情况，还要不断发掘新的商机，例如：
发掘客户更深层次的需求，吸引客户继续采购（例如不断升级）。
将合同项目的成果转化成为通用的产品或构件，卖给其它客户。
请老客户推荐其新客户。
问题跟踪的范围包括：开发过程中的各种问题、风险和建议，以及结项后遗留的问题。问题跟踪的一般步骤如图2-6所示，问题跟踪表见表2-12。
第1步。报告者创建问题，指定接收者，此时状态为“新的”。
第2步。接受者处理问题，状态为“正在处理”。
第3步。如果已经解决了问题，则把状态置为“解决待关闭”。
第4步。报告者审核这个问题，如果确定该问题已经解决，则把状态设置为“关闭”。如果发现问题没有解决，则可以“重新打开”问题，回到第2步。
图2-6 问题跟踪示意图
表2-12 问题跟踪表
需求开发与管理是指通过“调研、分析、定义、评审、跟踪”等活动，使开发方和委托方（客户或本公司领导）对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。
项目经理根据本项目的人力资源来确定需求分析员（可以多人）。需求分析员负责开展调研、分析、定义、评审、跟踪等活动。
3.1.1 需求调研
需求分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得漫无边际。
需求分析员确定需求调研的方式，例如：
✧ 与用户交谈，向用户提问题。
✧ 参观用户的工作流程，观察用户的操作。
✧ 向用户群体发调查问卷。
✧ 与同行、专家交谈，听取他们的意见。
✧ 分析已经存在的同类软件产品，提取需求。
✧ 从行业标准、规则中提取需求。
✧ 从Internet上搜查相关资料。
需求分析员在调研过程中随时填写“客户需求记录”，参考格式如表3-1所示。
表3-1 客户需求记录
需求分析员整理所有客户需求记录，归纳与总结共性的需求，为撰写详细的《需求规格说明书》作准备。调研过程中获取的需求信息可以作为《需求规格说明书》的附件。
3.1.2 需求分析
需求分析是对各种来源的需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。
对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。
现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
世上不存在一个包罗万象的图用以完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。
3.1.3 需求定义
需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，撰写《需求规格说明书》，模板见表3-2。提示：若有其它类型的需求规格说明书，请另定义模板。
表3-2 软件需求规格说明书
3.1.4 需求评审
需求分析员邀请项目成员（包括项目经理）和客户代表共同评审《需求规格说明书》，大家尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。
需求评审的流程见“项目评审流程”。一般地，需求分析员为申请人，项目经理为评审负责人，项目成员和客户代表可以担任评审员。所有评审人员认真检查需求文档，力求使需求文档达到正确、清楚、无二义性、一致、必要、完备、可实现、可验证。
3.1.5 需求跟踪
第1步。需求分析员创建需求的目录结构，便于人们阅读。
第2步。需求分析员输入每条需求的详细内容，可以多次细化修改，每次修改后应通知相关项目成员。
第3步。需求分析员跟踪每条需求的进展状况，填写需求跟踪记录（当前状态和情况说明），需求跟踪表的格式见表3-3。
表3-3 需求跟踪表
3.2.1 软件系统设计
软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计等，在需求与代码之间建立桥梁，指导工作人员开发能够满足用户需求的软件系统。
项目经理根据本项目的人力资源来确定软件设计师（可以多人）。
软件设计师撰写《软件系统设计说明书》，并构造可运行的软件系统框架，所有的模块都是在该系统框架上开发和运行。《软件系统设计说明书》的模板参见表3-4。
表3-4 软件系统设计说明书
3.2.2 设计评审
设计评审的目的是在同行专家的帮助下，尽早地发现本系统中存在的设计缺陷，及时消除设计缺陷。
当软件设计师撰写完成《软件系统设计说明书》，并构建可运行的系统框架之后，邀请项目成员（包括项目经理）和本公司技术专家开展设计评审。
设计评审的流程见“项目评审流程”。
项目经理分配合适的模块开发任务给开发人员，开发人员对自己承担模块的质量和开发进度负责。
开发人员阅读《需求规格说明书》和《系统设计说明书》，分析并细化自己承担的模块需求，并且进行模块细节设计，撰写《模板需求和设计文档》，见表3-5。
所有开发人员按照既定的规范（如编程规范）来实现自己承担的模块，并在系统框架中和其它模块集成一起。
开发人员完成模块开发后，必须先进行自我测试，必须走通模块的所有功能，消除自己已经发现的缺陷，然后交付给下个环节。
表3-5 模块需求和设计文档
测试与缺陷跟踪的流程见下图3-1。
图3-1 测试与缺陷跟踪的流程
3.4.1 提交测试
开发负责人把待测试物品（如软件包）交付给测试组之前，必须完成以下工作（否则测试人员可以拒绝接受）：
（1）在配置库中打标记（Label），这个Label就是待测试物品（如软件包）的版本号（建议包含年月日时分的信息）。
（2）说明该版本要测试什么，注意事项等。
（3）开发人员必须测试自己开发的功能，通过后才可以交付给测试人员。
3.4.2 测试准备
测试准备主要有三件事情：分配测试任务，设计测试用例，构建测试环境。
一、分配测试任务
测试负责人和测试人员商议测试计划，安排合适的测试人员执行测试任务。
二、设计测试用例
测试用例是用于检验目标系统是否符合需求的一种“示例”，基本要素有：前提条件、输入数据或动作、期望的响应。《测试用例》就是描述各种测试用例的文档，相当于一本“测试操作手册”。关于测试用例的一些常识如下：
（1）设计测试用例的目的是找出需求、设计、代码中的毛病，因此最好尽可能早地设计测试用例。
（2）不同的测试用例其用途应当不一样，不要累赘。
（3）显而易见的测试用例不必完整地用文字描述，因为此时文字描述的价值不大、反而消耗时间。
测试人员根据模块的需求和设计说明书，撰写《测试用例》，格式见表3-6。最好由开发人员审阅《测试用例》，提出改进建议，双方达成共识。
表3-6 测试用例
三、构建测试环境
测试人员（和开发工程师）构建测试环境，注意测试环境要尽可能接近用户的实际运行环境。
3.4.3 执行测试
测试人员执行测试，填写测试报告，见表3-7。
表3-7 测试报告
3.4.4 缺陷跟踪
缺陷跟踪如图3-2所示，缺陷跟踪表见表3-8。一般步骤如下：
第1步。测试人员（报告者）如果发现缺陷，则记录缺陷的详细信息，报告给开发人员（接受者）。此时缺陷的状态是“新的”。
第2步。开发人员处理缺陷，此时缺陷的状态是“正在处理”。提示：如果开发人员把缺陷状态设置为“不做处理或延后处理”，则项目经理召集相关人员评审那些“不做处理或延后处理”的缺陷，给出“处理”还是“不处理”决定。
第3步。如果开发人员消除了缺陷，则把缺陷的状态设置为“解决待关闭”。
第4步。测试人员重新测试该缺陷对应的功能，如果确定缺陷已经消除，则把状态设置为“关闭”。如果发现该缺陷没有解决，则可以“重新打开”缺陷，回到第2步。
图3-2 缺陷跟踪的流程
表3-8 缺陷跟踪表
3.4.5 消除缺陷
消除缺陷的第一步是找出缺陷的根源，如同医生治病，必须先找出病因才能“对症下药”。开发人员必须从结果出发，逆向思考。一旦找到了根源，开发人员通常知道如何消除缺陷。
查找缺陷的基本方法是“粗分细找”。对于隐藏得很深的Bug，应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。
开发人员在改错时，要注意以下事项：
（1）找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？如果没有问题，可以放心修改。如果有问题，可能要改动程序结构，而不止一行代码。
（2）有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。好不容易逮住一个，应当乘胜追击，全部歼灭。
（3）在改错之后一定要马上重新测试，以免引入新的错误。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原先程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要重新测试。
（4）上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。
如果是合同项目，那么由客户方负责人指定“试用人员和验收人员”。如果是自主研发产品，那么由产品经理（或公司领导）指定“试用人员和验收人员”。
交付与验收的流程见图3-3。
图3-3 交付与验收的流程
3.5.1 撰写文档
当项目开发完成并通过测试之后，项目经理指定项目成员及时撰写《安装手册》、《使用手册》、《软件部署说明书》等必需文档。
3.5.2 软件部署
项目经理审阅《软件部署说明书》，模板见表3-9，如果发现问题，则及时指正。项目经理确认无误后，再指定项目成员为客户（或者本公司）部署软件系统：
✧ 安装（或更新）软件系统，迁移数据；
✧ 初始化业务数据，确保软件能够正常运行；
注意：部署的软件系统必须是从配置库中提取已经测试通过的软件包。最好通过Internet进行远程部署，节省交通费用和时间。
表3-9 软件部署说明书
3.5.3 用户培训
项目经理指定项目成员（即讲师）负责给用户培训。讲师和用户商定培训计划（确定时间、地点、人员批次等）。
讲师按照计划给客户培训，并填写《客户培训记录》，模板见表3-10，作为培训服务的依据。
表3-10 客户培训记录
3.5.4 试用和验收
项目成员把软件部署到用户指定的机器上，用户试用软件。
在试用期间内，如果用户发现软件中存在严重的Bug（如死机、数据丢失、无法运行等），则开发方应当在24小时之内给出解决问题的措施。如果超过试用期，开发方仍然没有完全消除用户报告的Bug，那么试用期顺延，直到开发方完全消除用户报告的Bug为止。
如果用户在试用期间内没有报告严重Bug，那么试用期结束时，视为顺利通过试用。
如果试用期间，用户提出改进需求、以及报告了一些不严重的缺陷，开发方作为正常维护工作来处理，不延误用户验收产品。
用户在试用软件的过程中，将发现的Bug以及对软件的建议及时告知开发方。项目经理和开发人员及时处理用户反馈来的Bug和建议。
✧ 对于用户发现的Bug，开发方应当立即纠正。
✧ 对于一些难以马上实现的有益建议，由项目经理（或上级领导）决定如何处理。
✧ 开发方应当及时把处理结果回复给用户，否则用户可能因得不到开发方的重视而降低试用的积极性。
软件维护可以划分为两大类：
✧ 纠错性维护。由于前期的测试不可能揭露软件系统中所有潜伏的Bug，用户在使用软件时仍将会遇到Bug，诊断和改正这些Bug的过程称为纠错性维护。
✧ 完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。如果需求变更很大，那么完善性维护将转变为软件新版本的开发（即新的项目）。
软件维护的一般流程见图3-4，主要活动有“接受维护请求”、“分析维护请求”和“执行软件维护”。
图3-4 软件维护的一般流程
3.6.1 接受维护请求
公司应当建立通畅的软件维护通信渠道，包括网站、电话、Email等手段。
客户通过各种渠道向公司的客服人员提出软件维护请求。本公司客服人员记录这些维护请求，然后指定维护负责人：
✧ 如果公司有专门的维护小组，那么客服人员把维护请求转发给维护小组负责人。
✧ 如果公司没有专门的维护小组，那么客服人员把维护请求转发给该软件的项目经理，如果项目已经结束，则转交给开发部门的领导。
3.6.2 分析维护请求
维护负责人接受到维护请求后，进行分析：
（1）对于“纠错性维护”，首先确认Bug的真实情况，然后指定维护人员，协商安排修改Bug的任务进度。然后告知客户相应的维护计划。
（2）对于“完善性维护”，负责人要综合分析“客户需求建议”的价值，以及本公司的开发资源，然后决定“何人、何时”修改软件。
3.6.3 执行维护
维护人员根据商定的计划执行维护（修改Bug或改进软件）。注意事项：
（1）维护人员修改软件后，必须通过测试，确保没有引入新的错误之后，再去更新那些受影响的客户的软件，例如发行“软件补丁”。
（2）维护人员必须严格遵循“软件配置管理”规范，避免软件代码版本发生混乱。
（3）维护人员及时填写“维护记录”，说明自己做了什么事情和相应的工作量，不仅便于对维护工作进行统计分析，将来在业绩考核时候也用得上。格式见表3-11。
表3-11 维护记录
4.1.1 软件配置管理的概念
软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
软件开发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item），配置项主要有两大类：软件代码（包括源代码和二进制代码）和文档。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。
基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（即变更控制）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
4.1.2 软件代码管理的一般规则
软件代码管理的特征：
✧ 开发人员可能在一天之内多次更新代码，可能对整个目录进行“检出/检入”（checkout/checkin）操作，文件数量多，对实时性要求比较高。
✧ 软件代码的版本结构可能比较复杂（例如产生分支），对代码管理工具的功能要求比较高。
✧ 一般地只有开发人员可以“检出/检入”代码，非开发人员不必（也不该）访问代码库。
开发人员应当采用专业配置管理工具来管理所有的软件代码，常见配置管理工具有CVS、SVN、VSS、ClearCase等。软件代码管理的一般规则如下：
✧ 项目经理（或上级领导）指定项目的配置管理员。
✧ 配置管理员创建本项目对应的配置库，其目录结构与开发环境的目录结构保持一致。
✧ 配置管理员为每个项目成员分配配置库的操作权限。一般地，项目成员拥有“检出/检入”等权限，但是不能拥有“删除”权限。具体操作视所采用的配置管理工具而定。
✧ 项目成员根据自己的权限操作代码，建议时间间隔不能超过1天。
✧ 如果要修改已经发布了的代码，必须遵循 “申请－审批－执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许省略“变更控制报告”，但是至少要得到项目经理的口头批准，并告知受影响的相关人员。
✧ 有关责任人定期备份代码库。
4.2.1 文档管理的特征
文档管理的特征：
✧ 文档的主要用途是交流，交流越充分则文档的价值就越高。所以除了开发人员，不少相关人员（例如领导、营销客服人员等）都可能访问文档库。
✧ 人们一般不会频繁地修改文档，文档的版本结构很简单（一般不会产生版本分支），对文档管理工具的功能要求不高。
✧ 人们并不局限在办公室里使用文档，可能出差在外地、也可能在家里使用文档。
✧ 一般地，企业领导和营销客服人员不会使用CVS、SVN、VSS、ClearCase查看文档（对他们而言这些工具都太复杂了），使用Web方式对他们而言最方便。
尽管专业的配置管理工具既可以管理软件代码也可以管理文档，由于软件代码和文档有比较大的差异，业界倾向于将软件代码和文档分开管理：
✧ 采用专业配置管理工具（如CVS、SVN、ClearCase等）来管理软件代码。
✧ 采用基于Web的文档管理工具来管理文档，文档管理工具通常和本公司的网站链接。这样人们可以在任何地方通过 Web 方式访问他需要的文档（前提条件是拥有访问权限），非常方便。
4.2.2 项目文档管理的一般规则
项目文档管理的一般规则如下：
✧ 项目经理创建项目文档库，至少确定文档库的第一级目录。
✧ 项目经理为每个项目成员分配文档库的操作权限。一般地，项目成员拥有上传、下载、更新等权限，但是不能拥有“删除”权限。具体操作视所采用的文档管理工具而定。
✧ 项目成员根据自己的权限操作文档（建议时间间隔不超过1周）。
✧ 项目经理用文件袋或文件柜妥善保管纸质文档（例如客户提供的纸质文件）。
✧ 如果要修改已经发布了的重要文档（例如需求文档、设计文档、项目计划），必须遵循“申请－审批－执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许省略“变更控制报告”，但是至少要得到项目经理的口头批准，并告知受影响的相关人员。
✧ 有关责任人定期备份文档库。
质量保证（QA）是指检查项目的“工作过程和工作成果”是否符合既定的规范。
符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果极可能是不合格的。例如开发人员没有使用配置管理工具，开发人员没有写需求文档就开始编程等，这些问题可以在过程检查中发现。质量保证的要点是：找出明显不符合规范的工作过程和工作成果，及时督促相关人员纠正问题。
公司指定QA人员（也可以是PMO人员）检查所有项目的过程质量和成果质量。QA人员根据项目特征，制定“质量保证检查表”，格式见表4-1。每个检查点的检查结论有3种：通过，未通过，免检。
QA人员在检查的时候，如果发现问题，应该立即记录下来。QA人员首先设法在项目内部解决已经发现的质量问题，与项目经理协商，给出解决措施。在项目内难以解决的问题，由上级领导给出解决措施。
表4-1 质量保证检查表格式
项目成员应每天撰写工作日志，记录每天的主要工作内容，格式见表4-2。
表4-2 工作日志的格式
项目经理撰写《项目周报》，抄送给领导和项目成员，格式见表4-3。
表4-3 项目周报的格式
4.5.1 定义绩效体系
绩效体系的构成要素如下（见表4-4）：
（1） 绩效评估类型。企业里不同的岗位可能要采用不同的绩效评估方法，先要确定有多少种绩效评估类型。
（2） 每个绩效评估类型细分为若干个绩效指标。
（3） 每个绩效指标限定了最高分值（体现了权重），并给出详细的评分标准。
（4） 将业绩分数划分若干等级，每个等级对应某个分数范围。
表4-4 绩效体系的格式
4.5.2 填写绩效表格
绩效评估的一般流程：按照指定的绩效评估表，员工先自我评估，再由上级领导评估（可以多级评估），格式见表4-5。
表4-5 绩效评估表
第1步。知识库分类，例如流程制度、缺陷知识、可复用模块、经验教训等。
第2步。任何员工都可以填写“知识入库申请单”，见表4-6。
第3步。知识库管理员审批“入库申请单”（挑选有价值的知识，避免信息泛滥）。
第4步。凡是应用了知识库的人员，都要填写应用记录。
第5步。对知识库的学习、应用情况和员工贡献，进行统计分析。
表4-6 知识库表格
本文来源：https://www.2haoxitong.net/k/doc/417a83c789eb172ded63b754.html
文档为doc格式