[转帖]从TOC看“项目实施阶段”存在的问题

阿懒

转贴自:http://cio.ccw.com.cn/research/qiye/htm2007/20071107_339555.asp

一、泥足深陷

M项目自实施以来已经过去了1个半月，目前该项目还在;试用-修改-再试用-再修改”的泥沼中苦苦挣扎，4名开发人员已经人困马乏，疲于应付，但系统的问题清单仍然越来越长，似乎没有 
尽头......

这个项目是为生产部门开发的生产线的管理系统。去年，由于生产工艺和流程变化，已经使用了几年的管理系统无法继续使用了，因此生产部门购买了一套外国公司的生产管理软件，花费不菲，试运行的时候却发现系统响应速度非常慢，几乎造成5条生产线全部停工，无奈之下只好提前结束合同，当然，首付款也打了水漂。目前，生产线完全依靠人工管理，生产效率低下，生产部门迫切希望于信息部门能够尽快开发出新系统，以缓解生产制造的混乱局面。

系统的上线时间，生产部门的要求近乎苛刻，信息部在接到任务后，只好将项目计划紧缩、再紧缩。开发部的工程师非常努力，只用了3个月就完成了需求调研和代码开发，并于1个半月前开始试运行。但是问题很快出现了，本来预计只要2周的系统实施阶段一拖再拖，问题不断，眼看三个2周都过去了，距正式上线仍遥遥无期，对此各方面都非常着急，却搞不清楚为何如此。

二、原因何在？

实施受阻，原因何在？

信息部为了按时交付系统，不得不一再的压缩开发和测试的时间，软件质量因此大打折扣。在开发过程中，系统集成测试基本属于奢望，开发人员甚至没有时间对自己的代码做充分的单元测试，就匆忙发布了，这种做法大大降低了软件的质量，也正是不断降低的质量标准导致了试运行时铺天盖地的错误和缺陷。更麻烦的是，由于不断的对软件功能进行修改，只好不断的对修改的代码进行测试，不断的对修改过的功能进行用户培训，造成实施时间一延再延。

“实施阶段”指的是指软件拿到用户的实际工作场所进行部属和使用的阶段。一般来说，系统实施要经过“软件交付——〉发布——〉用户培训——〉用户试用——〉发现问题——〉软件修改——〉软件测试——〉重新发布”这样一个螺旋式前进的过程，这个过程将不断的重复，直到系统没有问题或者存在的问题用户可以接受为止。不要怀疑这个过程的复杂和繁琐，因为这才是事实，像那种理想化的、一帆风顺的实施过程通常只会在教科书上出现，我们必须充分认识到系统实施阶段存在的风险。

在这样一个循序渐进的过程中，每个环节都可能引发混乱，造成延误，并在各步骤间传递和放大这些延误，导致实施阶段的延期。比如：开发过程的延误，造成交付的推迟；用户培训的拖后，造成试用的推迟；问题发现的缓慢，造成软件修改的推迟；软件修改的频繁，造成测试的推迟；软件测试的延误，造成再次发布的推迟。

三、冲出泥沼

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

冲突。

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

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

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

错误的假设。

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

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

制约因素。

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

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

解决方法。

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

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

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

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

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

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

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

TOC背景

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

该贴来自群组：TOC约束理论

[此贴子已经被作者于2007-11-13 10:07:12编辑过]

changqing

这里使用5 focuing steps 是不对的，挑战的假设也有问题。

这是一个CCPM的问题，应用项目管理的方法来分析问题。挑战的假设类似“所有子项目都准时完工，整个项目就会准时完工”。

阿懒

看了changqing兄的回复，才回头细看这个案例，
确实如changqing兄所言，这个案例明显是套了下TOC的概念，未用到点子上。

另外我有个新想法:
案例中的公司软件质量标准居然还可以商量，公司实际上还是一个"不稳定的系统"。
一个不稳定的系统可以通过系统改善的方法直接改善吗?
是不是要先稳定系统，然后做改善?

南华学童

TOC的实践可以比方为一群人系着一根绳子（关键链）过河，以相互协作支持的方式成功过河的可能性大。

[此贴子已经被作者于2007-12-2 16:26:24编辑过]

williamjen

楼主的分析有一定道理，但只限于工作开展前期，即项目的商谈、定义阶段，一旦项目开始，那就如常青兄所说，是一个CCPM问题。

楼主的案例中,在项目开始前，应该运用TOC分析，为什么生产部门如此急着上线，哪些功能是必须的，对生产部门的有效产出是至关重要的，而哪些是可以延后的，这样，就不是在“质量标准”上讨价还价，而是在项目范围上讨论。（你能在类似“软件平均一天崩溃几次”这个质量标准问题上与客户讨价还价吗？）也就避免承诺一个无法实现的期限。也就是，楼主的分析、找冲突还是不够深入。而其它所有涉及项目进度问题，比如需求分析、开发、测试的配合、时间分配，都是CCPM问题。