[原创]从TOC的观点看“项目实施阶段”存在的问题

三、冲出泥沼

让我们用TOC的观点和方法来分析这混乱的状况，并找出解决方法。

冲突。

[TOC观点]：发现冲突是解决问题的第一步。TOC认为，如果一个问题未能以两个必备条件之间的冲突来表达，那么这个问题就没有清晰的定义。

从成本世界出发，各步骤所用的时间越短越好，所进行的循环次数越少越好；

从有效产出世界出发，各步骤所做的准备工作越充分越好，所进行的循环次数越多，则有效产出的质量和效果越好。

错误的假设。

[TOC观点]：TOC认为，冲突实际上是不存在的，当我们遇到一个冲突，那其实是一个清晰的信号，显示有人做了一个错误的假设，而这个错误的假设是可以纠正的，一旦纠正了，冲突就不存在了。

在实施阶段存在的错误假设是，越早将软件交到用户手上，实施阶段就可以越早结束。这个假设忽视了由于没有经过充分测试的软件缺陷所造成的混乱和延误。

制约因素。

[TOC观点]：对企业来说，改造最弱的环节才会提升整体的能力，任何时候最弱的一环都只有一个，这就是制约因素。

对于整个实施阶段来说，制约因素是软件在交付时应该达到的质量标准。如果标准过高，可能会造成交付日期的延误；如果标准过低，则会造成修改缺陷和重新发布过程的多次重复，造成整个实施阶段的延误。

解决方法。

[TOC观点]：任何问题都可以用聚焦五步骤来解决：找出、挖尽、迁就、松绑、回头。

我们就用聚焦五步骤来解决实施阶段所面临的麻烦：

第一步，找出。从实际情况来看，软件的质量标准是我们最应该关注的，是整个实施过程的制约因素。不断出现的错误、频繁的修改、无休止的测试和培训，都是由此产生的。

第二步，挖尽。挖尽质量标准的潜力，也就是找出一个最符合项目具体情况的标准，既不会因质量要求过高影响软件按时交付，也不会因质量标准过低导致上线后问题频发。

第三步，迁就。质量标准制定出来以后，其它各方面都要配合这个标准，这样才能使制约因素不再是瓶颈。比如，软件需要进行充分的测试以保证满足质量标准的要求，软件交付必须在测试通过之后，并且在重新发布之前也要进行测试。

第四步，松绑。做到前面三步之后，软件只有达到一定的质量标准后才会发布，对软件的修改也必须经过测试后才能发布新版本，因此不会再出现BUG满天飞的情况，用户培训也可以有条不紊的进行，系统试运行不再是怨声载道，瓶颈也不再是瓶颈了。

第五步，回头。原有的瓶颈消失了，必然会有新的步骤成为最弱的一环，接下来就是我们去发现并解决它的时候了。
      

TOC背景

TOC（Theory Of Constraints）是高德拉特(Eliyahu M．Tolerate)创立的“制约法”，是一套独特的管理方法论，将之应用到软件项目管理中也一样适用。TOC致力于找出管理链条中的薄弱环节，然后通过各种手段加强它，当它不再是最弱的一环时，再去寻找新的薄弱环节，如此往复，整个管理链条都得以加强了。