用制度说话

原文地址：http://www.ceocio.com.cn/7/464/40533.html

就组织而言，真正可靠的还是制度、流程以及监控体系。

作者：周庆瑜 发布于：2009-1-20

人年轻的时候，可以依靠激情做事情，同样，组织“小”的时候，可以依靠老板本人的驱动力。不过，就组织而言，真正可靠的还是制度跟流程，而流程要可靠，重点在于流程中的监控体系。

我从事IT工作多年，在前面几年，我一直有个困惑——都说项目经理要负责一个项目的成败，这个思路大家都能理解并且认同，可是该如何确认一个项目经理是好是坏。靠培训？靠考试？拿到PMP 证书是一种象征，还是有实力的代表？一个现在表现不错的项目经理，会不会有一天状态持续下滑？

当然，面对上述问题，持续汰换不符合需要的项目经理是必要做法，但是不能只有这一招，因为这样无疑会面对另外一些问题：项目经理的培养周期一般较长，要汰换不太容易；一个项目不太成功后，通常我还会给项目负责人一些机会，如此一来二去，会有大半年的“投入”，而这期间所做的项目不但可能造成投资浪费、用户的满意度下降，还会使得机会成本浪费、整体效率无法体现等。这些都是困扰我很久的问题。

在接触ITIL之后，我发现它真是个好东西，困扰我的问题在 ITIL里都能找到答案。不过，想完全按照ITIL体系来运作一家企业的IT部门，难度的确很大。其他的不说，仅按照ITIL体系成立相关的变更管理、更新管理、配置管理单位，就是一笔大部分企业决策层不愿承担的人力支出。

于是，基于对ITIL精神的理解，以及考虑到现实环境，我们做出了一些调整。其实，所谓的ITIL精神就是所有的事情要依靠流程，而流程要稳定，重点依靠的是流程中持续的稽核制度。所以其关键就是如何在所有服务流程中，在主要控制点中加入考核项目，并由非项目经理进行持续有效的稽核。

我们先将服务台的建设优先提上日程。当然，如果没有相应的人力预算，外包也是不错的选择。在我们企业，服务台的建设最初是被当成费用节约项目提出的，所以很容易取得老板的支持。服务台是面向内部用户的唯一服务窗口。一方面，它可以较好控制对用户的友善度；另一方面，可以将常见的服务问题列出及持续追踪改善情况，这是因为期待负责服务的工程师主动说自己服务常常出问题，恐怕是不切实际的想法。

服务台建立以后，内部用户对IT服务问题的反映就有了较好的机制。接下来，我们开始考虑项目进行流程了，在项目的主要阶段，我们设置了不同的阶段控制重点。

1. 需求调研阶段：这个阶段的项目重点是用户访谈，重点产出是项目需求书。我将控制重点设为文件审核。以前，当项目经理完成需求书后，只要直接跟内部用户确认后就可以进入下一阶段。我们将这种做法改为先经过内部审核后才能进入下一阶段。部门内的审核是由部门同事们轮值，根据项目规模，动态成立项目审核小组，在需求书完成后两天内召开小组会议完成审查。这样最大程度降低了项目经理考虑问题不全面的情况。

2. 开发阶段：首先，我们把开发团队与项目经理团队区分开，项目经理基本上不参与开发，这样可以保障每个环节各自独立，同时也让资源得到最有效的运用。这个阶段的主要产出是开发完成后的测试环境，我们考核开发人员的KPI主要有两个重点——测试人员测出的项目问题数及注释情况。测试人员是由服务台员工在非服务高峰时间兼任，这样可以让服务台人员更有效地利用工作时间并提前了解未来要承接的服务项目。

3. 实施阶段：这个阶段的重点产出在正式上线的项目，我们的控制重点主要有：类用户测试，主要目的是测试使用界面的友好性，有时这个测试比功能还重要，因此我将上线后的用户问题反馈数量定为测试人员的KPI；发布管理，这是由IT部门的服务器管理人员兼任，因为他才有服务器的可写入权限。我将发布的前提条件设为两个——测试人员的签字认可、看到项目上线的回滚计划，以预防上线失败后服务的长时间中断；上线后的问题处理速度，这是考核项目经理及开发人员的 KPI。

4. 维护阶段：这个阶段的重点在将主要服务任务移交给服务台，主要产出是移交服务文档。这个阶段不会要求文档的完整性一步到位，而是将其作为持续改善的过程，每周根据内部用户的反馈情况定期审核知识项目的完整性及有效性。所有知识项目的上线之前，要先经过服务台人员的审核，才能正式移交。这个移交由于文件准备不全而导致的工作，是不被承认绩效的。

以上4个阶段，形成了完整的服务周期循环。此外，在2008年中，我们回收了所有项目经理对正式环境的可写权限（含数据库及程序发布），我觉得，唯有这么做才能规避很多弊病。