https://blog.51cto.com/zhouyulu/4043374
上次我们总结执行的最小单位：活动或任务；本次我们总结下执行中的异常跟踪记录：日志。
1 定义
前面提到了需求跟踪矩阵，用来跟踪“从需求到交付物”之间的各个过程活动和成果。一个项目是比较复杂的，在实际执行中，会拆分为执行任务（常规开发、测试），执行中肯定会出现各种异常，这些异常也需要跟踪解决。一个关联示意图所示：
对异常日志的一些关键定义：
假设日志（Assumption Log）：在整个项目生命周期中用来记录所有假设条件和制约因素的项目文件。
问题（Issue）：可能对项目目标产生影响的当前条件或情形。
问题日志（Issue Log）：记录和监督问题信息的项目文件。
变更（Change）：对任何正式受控的可交付成果、项目管理计划组成部分或项目文件的修改。
变更请求（Change Request）：关于修改文档、可交付成果或基准的正式提议。
变更日志（Change Log）：项目过程中所做变更及其当前状态的综合清单。
风险（Risk）：一旦发生，会对一个或多个项目目标产生积极或消极影响的不确定事件或条件。
风险登记册（Risk Register）：就是风险日志（Risk Log），记录风险管理过程输出的文件。
2 说明
异常跟踪常规使用各类异常日志，日志中的记录往往超过上百条，在执行中，每周例会的一个常规日程，就是过各种日志。使用日志，要特别注意几个点：
日志属性
- 要首先定义出日志模板，比如包含哪些属性，每个属性的填写规范。
- 常规的属性如“ID、类型、描述，状态，提出人，提出日期，责任人，计划解决日期，实际解决日期”等。
- 特殊的属性，如问题日志中有“发生概率、重要程度、异常现象等”，风险日志中有“处理前概率、处理前影响程度，处理前优先级，处理措施，处理后概率、处理后影响程度，处理后优先级等”，变更日志中有“变更请求编号，变更原因，变更执行责任人等”。
- 填写规范中，ID要唯一编号，类型、日期、人员等能从源数据中选择，状态能有逻辑状态，优先级能自动计算等。
-
关键属性
状态。异常记录只是过程，最终目的是解决掉，能支持可交付成果，所以使用某种状态值标明这个异常非常重要，能够让团队成员决策是否还要关注。常规状态有：新建->处理中->已处理->已验收->已关闭。
- 优先级。常规异常记录条数会很多，分派到某个责任人手上如果超过10条，就需要有某种规则的优先级排序，按照从高到底来处理，同等资源，优先处理投资回报比高的。
- 责任人。每个异常记录后，必须找到责任人来解决，责任人只能有一位，解决异常是这个责任人的责任和义务，他没有任何接口不解决；参与人可以有多位。
- 计划完成日期。和任务活动要嵌入到日程中一样，异常也需要嵌入到日程表，否则无法有效按时间跟踪。
3 修行
在日常工作中，我们对最常见的问题做个总结（其他类型的后续总结）。工作中我们最先接触到的是问题，因为问题往往说明出现了偏差，必须要及时解决，否则内部无法推行到下一阶段、或无法对上对外交付产品。
问题又会细分产品类Bug和项目类问题，最先被管理的是产品类Bug，因为产品的用户是客户，不解决不给钱，产品类Bug管理的越规范，对产品的质量保证和控制会做的越好。其次才是项目类问题，这类问题主要体现在项目的非产品Bug上，如任务优先级、资源限制、进度延期上，但客户不清楚开发的内部阶段，所以对客户而言，这种影响没有产品质量直接。
问题常用跟踪表来跟进，而且有可能会是Excel或系统工具形式（乙方实施、或对外沟通一般会用Excel管理，因为上手快，不用搭建系统和培训；甲方自己一段时间后会引入某种工具，如Mantis、Bugzilla，提高内部执行效率）；Excel一般是每周更新，在项目周会上逐条验证确认，比较适合人少、集中办公、项目经理主控的场景；系统工具可以随时更新，也会在项目周会上统计分析，适合人多、跨部门、跨楼层的场景。
问题管理，特别要注意问题状态的逻辑转换关系，不允许状态之间自由转换。实际使用时，要定要好状态、哪些状态之间可以转换、转换的条件是什么、状态转换时对应的负责角色是什么等等；而且一定要通过各种方式宣导培训，和各类用户及用户的管理者达成一致，用某种系统工具固化下来，以提高问题的管理效率，让开发人员减少职责讨论，聚焦在具体问题解决上。一个示意如下：
如果能把问题按规范解决好，你就进阶成了合格的工程师；如果能把问题跟踪好，你就进阶成了资深工程师或部门长；如果能把预防类的假设、风险，历史类的变更跟踪管理好，你就成了合格的项目经理。
若有收获，就点个赞吧
0 人点赞
