[原创]CTO思考之七-如何摆脱“消防式”的工作模式

如何摆脱“消防式”的工作模式

部门：总裁会

目的：交流对目前公司宏观问题及其解决办法的认识。

期望的读者：总裁会成员

作者：邱嘉文

时间：2001/1/8

反馈意见记录：

意见人	意见	提出时间

一． 何谓“消防式”的工作模式

我们经常听到、讲到和看到：“我们整天在忙于救火，这里还没灭掉，那里又着了。”不管是管理层还是执行层，整天忙手忙脚，但事情好象总是一团糟。决策层看到的是一潭混水，怎么也见不到底，对业务目标能否实现总是没有着落，只好走一步，看一步。产生这种现象的工作模式就叫“消防式”工作模式。

在CMM的描述中，“消防式”工作模式是不成熟软件企业最明显的特征之一。而且全世界绝大多数的软件企业处于这种不成熟状态[1]（插一句：这里蕴藏着极大的商机）。所以，我们在听到对自己如此评价时，完全不必产生被嘲笑的感觉。正如我们不会嘲笑一个婴儿不会说话，反而会不厌其烦地教他一样。试想，如果没有不厌其烦地教说话，我们的后代无论他长到什么年纪，在说话方面，他永远也将只是个婴儿——不会说话。软件企业在成立之初就象个婴儿，他只能利用先天的非条件反射作用来行动：发现问题—>做出反应行动—>发现新问题—>……。久而久之，企业便形成了“问题—反应”式的工作模式，也就是“消防式”的工作模式。一般来讲，不会有任何机构会主动来象父母教自己的婴儿说话一样来教这些不成熟的软件企业去形成一种主动的工作模式。而且不成熟的软件企业往往不会承认自己象婴儿一般的行为能力，从而不会乐意接受最基本的“说话训练”课的培训。这便是造成全世界绝大多数的软件企业处于不成熟状态的不幸的主要原因之一。幸运的是，全世界绝大多数的人都会讲话。

二． 摆脱“消防式”模式的方法存在怪圈

“消防式”工作模式并不是绝对的不好，当企业的业务类型单一，产品服务类型单一，业务量不大的时候。需要快速行动，强占先机，在行动中来发现一个问题，消灭一个问题。不失为一种高效、适宜的做法。但随着企业的发展壮大，多元化的引入，业务量的扩大，带来的问题数量自然也就会急剧膨胀。企业自然会发现自己的“消防能力”已经远远不能胜任了，于是企业就要想办法摆脱这种“消防式”的工作模式。

如何摆脱“消防式”的工作模式？多数人的第一反应可能是：把所有当前暴露的问题按轻重缓急给我列出来，然后找到问题应该归哪个部门，哪个岗位，哪个人来负责解决，责任一定要落实到人。只有责任落……。人手不够？好，把需要的人要解决什么问题报上来，立即加！待遇太低？好，看看左邻右舍的情况，果然低了点，加工资！这是在试图摆脱“消防式”的工作模式吗？是的，多数人的心里面是在努力摆脱“消防式”的工作模式；不是的，多数人的思路仍然在不折不扣的执行“消防式”的工作模式。不难发现，存在一个用“消防式”的工作模式来摆脱“消防式”的工作模式的怪圈。

既然企业已经进入了怪圈，要跳出来就不那么容易，困难在于：

1． 企业发展的动量已经非常大，不可能来个疾转弯，否则，必翻无疑。企业现实确实面临诸多的问题，如果不解决，会引起客户和员工的强烈不满，可能导致企业更大的损失。如果去解决，一个问题可能会牵扯出更多更大的问题又要解决，可能会引发更多的地方“着火”，可能导致企业陷入“消防式”的工作模式而不能自拔。企业确实进退两难。

2． 多数人的思维动量也已经非常大，即使企业发展的车转过来了，但思维的惯性比物质的惯性有时候更难扭转。由于企业确实面临企业发展中的上述问题，一方面，发展的速度使多数人根本来不及思考如何改变思路和观念；另一方面，侥幸心理和自负心理同时起作用，也使多数人凭添了一份“决不回头，要直捣黄龙”的可贵勇气。结果，多数人会保持“消防式”的工作模式不变，少数人冷静的思考和智慧的主意往往会被误解为消极的绊脚石和不现实的画饼而失去参考的使用价值。

需要强调的是：“消防式”的工作模式本身不是怪圈，而是当“消防式”的工作模式出现问题而又需要摆脱“消防式”的工作模式时，才出现了摆脱行为的怪圈。

三． 把握过渡的最佳时机

企业一旦进入摆脱“消防式”的工作模式的怪圈，要跳出来就比较困难了。因此，避免必须想方设法摆脱“消防式”的工作模式的最佳办法，就是在企业尚未进入怪圈或刚刚进入的时候，就马上过渡到积极的工作模式上来。使用这一办法要解决的两个关键问题是：

1． 什么是积极的工作模式；

2． 如何把握过渡的最佳时机。

先讨论如何把握过度时机的问题。企业初创时，必然选择“消防式”的工作模式。此时的企业，不需要建立和维护客户数据库，不需要完整的产品开发流程，不需要严格的质量保证措施，不需要周详的计划和控制，只需要一两个绝顶聪明的人迅速开发出一个有特色价值的产品，迅速投放到市场，然后几双眼睛紧盯着少数几个用户使用产品的过程，一旦发现问题，立即修改程序，重新编译，马上升级。此时在这种模式下，一方面节省了企业的管理成本，另一方面由于服务及时，客户满意度还满高的。在软件企业，这一时期一般在一到三年之间。正因为软件初创企业存在以上的竞争优势，如果企业市场机遇把握得好的话，企业经营业绩在该段时期里面会有较大的飙升；又如果企业能够和愿意保持单一产品经营模式的话，产品会越做越精，产品本身的问题就会越来越少。虽然用户数量可能增加很大，但问题的类型仍然会越来越少，解决的难度也就不会剧增。在这种情况下，企业可以长期保持“消防式”的工作模式不变，而不用担心自己的消防能力会不够。实际情况往往是当企业单一产品进入销售稳定期后，由于在企业看来，竞争对手的介入，市场容量的逐渐饱和，还有企业对自身的发展速度不满意等作用驱使下，企业会寻求多元化的发展。作为软件企业，首先会考虑和原有产品相关的新产品进行开发，试图利用已有的客户资源，迅速的开出第二朵、第三朵金花。由于第一朵金花的成功经验给企业的印象实在是太深刻。企业在启动其他产品开发时往往会认为重复以往的经验就够了，我们既然能做成A1，就肯定能做成A2,A3…..。于是，对困难的估计不足和急于求成的缺陷很可能就此产生。

消灭缺陷的最佳时机就是在它将要产生，又没有产生或刚刚产生的时候，即所谓“把问题解决在萌芽状态”和“枪打出头鸟”的原理。所以，企业准备工作模式过渡的最佳时机，就是企业启动多元化产品发展的时候。

四． “探险式”的工作模式

积极的工作模式应该是引入了预测、预计和预防的工作模式。积极的工作模式需要向过去的经验教训学习，要根据以往的经验来预计未来采取的工作方式和方法，根据以往的教训来采取预防问题发生的措施，以尽力保证在未来的工作中不出错或少出错。如果没有自己以往的经验教训学习，就要学习他人以往的经验教训，如果连他人的经验教训都没有，是不是就没有积极的工作模式了呢？不是，还可以采用预测的手段来掌握未来发展可能出现的情况，再凭直觉进行预计和预防，即所谓“摸着石头过河”，也是积极的工作模式。所有这些预测、预计和预防的手段，在人类的探险活动中是采用得最多的，可以称这种工作模式为“探险式”的工作模式。

建立“探险式”的工作模式要做以下三个方面的准备工作：

1. 要记忆，软件企业要记下自己和熟悉的同行做过什么项目，什么人，用什么方法，在什么情况下，花了多长时间，做出来过什么样的产品，有什么优点和缺陷，买给过谁，谁用过，有什么意见等等，更重要的是要记住企业做砸过什么产品，什么人，用什么方法，在什么情况下，花了多长时间，为什么会做砸等等。至于采用什么形式来记是另一个问题：是记在脑海里，还是写在文字里，还是记载在数据中等，可任意组合使用。这项准备工作其实不难做到，要克服的唯一困难就是懒惰。

2. 要回忆，软件企业在进行新的项目开发时，先要好好回忆一下企业是否做过类似的项目开发，其他企业是否做过类似的项目开发？过程怎么样？数据在哪里？结果怎么样？等等。如果企业记录了不少历史资料和信息，在该用的时候不用，不仅浪费资源，而且打击士气。非常遗憾的是，大部份的软件企业就是在这个最容易做到的环节没有做好。要克服的困难是：新项目的管理者要知道有这么回事，然后克服懒惰和自负心理去做这件事。

3. 要分析，这是在建立“探险式”工作模式时唯一有技术困难的工作。对于非形式化的记忆（记在脑海里或文字里），要有严密的逻辑思维和丰富的形象思维能力才能分析异同、分辨是非。这种能力不是一朝一夕就能拥有的。实际上，在所有影响软件质量、进度和成本的因素组成的“木桶”中，这块板是起决定作用而又往往是最低的。对于形式化的记忆（记录在数据中），要掌握一些数值分析的方法，如回归分析方法等，来从数据中找出令人信服的证据。

以上仅仅是准备工作而已，虽然说的较多，但基本上都属于动脑的工作。真正要做的工作是建立项目工作计划、项目预算计划、项目风险管理计划等三项工作。只有这三项工作实实在在地做起来了，积极的工作模式才算真正建立起来了。如何进行这三项工作有专门的理论和技术支持[2]。

“探险式”的工作模式也并不是绝对地比“消防式”的工作模式好。首先，“探险式”工作模式较难建立；其次，建立“探险式”工作模式代价较高。在进行业务本身并不复杂，牵涉业务范围小的产品开发情况下，“探险式”工作模式就有明显的画蛇添足之嫌。“探险式”工作模式用于简单、小规模项目的开发的情况一般是在进行“试点”：目的是积累工作模式运作本身的经验。

作为一个想长盛不衰的软件企业，不可能只凭简单、小规模项目立足于这个激烈竞争的IT行业。因为简单、小规模的项目产品太容易被竞争对手“克隆”，太容易陷入激烈竞争，太容易使市场饱和了。因此，想长盛不衰的软件企业一定要有自己满足用户复杂业务需求的长期主打产品，令竞争对手难以模仿，从而使自己长期立于不败之地。企业因而必须具备承担日益复杂的应用程序开发的能力。这种能力只能来源于“探险式”的工作模式，也正是软件工程引入项目管理的工作模式。

五． 如何跳出“怪圈”

每个软件企业，都不会期望自己陷入到要摆脱“消防式”工作模式的怪圈中。遗憾的是，把握工作模式的过渡的时机是如此的困难，陷入这个怪圈又是如此的容易，很少有软件企业在陷入怪圈之前会有所警觉。他们事业在腾飞，客户很满意，天下太平，谁会想到还要花那么多精力去改变看上去好好的工作模式？可当他们发现自己不得不东奔西走，到处救火的时候，一切已经太晚了。

虽然，从这个怪圈中跳出来很困难，但还是有很多企业成功地从这个怪圈中跳了出来，所以，他们的企业也获得了成功。

跳出怪圈的方法之一是打破怪圈：不是单一产品的经营不容易形成工作模式的怪圈吗？很多精明的企业利用了这点。把企业划整为零，组成多个小企业的松散联合体，每个个体只独立经营一个产品。虽然这种方法肯定会带来资源的重复投入，造成一些“浪费”，但“浪费”的结果是使“大火”变成了“小火”，“多火”变成了“少火”，“乱火”变成了“序火”，有效分解和降低了企业问题的规模、数量和关联。往往通过“减灾”减少的损失会远远大于资源重复投入造成的“浪费”。从自然界的“分形学”原理的角度上看，这种方法是非常有科学根据的。采用该种方法的优点是：可以继续保持“消防式”的工作模式，从而保持企业在各个产品方面的高速有效运转；缺点是加大了企业作为整体运作的难度。

跳出怪圈的方法之二是改变到“探险式”的工作模式。企业首先必须减缓发展速度，适当缩小规模，使问题解决的速度高于问题产生的速度，逐渐使企业回到最佳过度点。然后企业的各级人员必须逐级转变观念，接受新工作模式的培训，并在实际工作中逐渐运用新的工作模式。使用这一方法的关键是高级管理人员要首先转变观念，身体力行。很多企业甚至不惜采用“空降部队”的做法，通过直接引进具有新工作模式经验的高管人员接替那些“顽固不化”的元老。这种方法的优点是，可以形成较高的整体运作效率；缺点是容易滋生官僚和形式主义的工作作风。

不论采用那种方法来跳出所谓的怪圈，最终目标都是使企业能对自己发展过程中的问题进行控制和管理。对于已经身陷怪圈的企业而言。困难的根源在于克服企业发展的惯性。根据牛顿动力学原理：

动量（惯性）=质量X速度。

上述第一种方法是保持企业发展速度不变，分解企业的质量使企业惯性得到分解，使每个分解单位的惯性处于可控范围。第二种方法是保持企业质量不变，降低企业发展速度，使整个企业惯性回到可控范围。

不论采用那种方法来跳出所谓的怪圈，企业都会面临剧烈的痛楚，这是企业早期高速发展的代价。上述第一种方法带来的是企业肉体分裂的痛楚，第二种则是精神洗礼的痛楚。

上述两种方法是两种极端的做法，实际上，企业可以采用两种方法同时使用的第三种方法。根据企业的实际情况决定对企业产品分解的粒度，对不同分解部分发展速度的不同降低程度，对不同经营者观念和方法的不同转变程度等，使企业在精神和肉体两方面的痛楚得到均衡，而不至于某方面太强使企业难以承受。

六． 同望企业现状

从同望的长远目标规划中，我们可以看到一个雄心勃勃的提供多元化软件产品和服务的企业。这些目标的价值确实让公司大股东和高级管理人员深受鼓舞。公司各级领导和员工在近年中为实现这些目标也付出了不懈的努力，并取得了卓有成效和令人满意的进步。如果要“居安思危”的话，从同望发展的历程上看，同望现在已经是一个错过工作模式过渡期，而在试图从“消防式”工作模式中摆脱出来的软件企业。

虽然在公司产品和规模高速发展的同时，同望领导层也时刻提醒了自己管理实力的差距问题。遗憾的是，并未能在工作模式上取得突破性进展。结果是公司利润确实也得到高速增长，但主要还不是产品和规模高速发展所带来的。产品和规模高速发展带来了一定的经验积累，遗憾的是也带来了成本的浪费。如果工作模式得不到有效改进，同望所期望的产品和规模高速发展带来利润的高速增长将会是竹篮打水。如今，同望在“消防式”工作模式下的质量越来越大，速度越来越高。从“消防式”工作模式中摆脱出来的难度也就越来越大。如果同望还不能试图建立“探险式”的工作模式，那么，同望每新开一个产品项目，每成立一个新的部门，每向市场推出一个新的产品，就等于制造一个“火灾”隐患。

同望未能建立“探险式”的工作模式的主要原因是（马后炮）：

1． 产品品种发展速度过快；

2． 人员规模发展速度过快；

3． 软件工程、产品工程理论（合格的产品经理应该知晓）未能在产品策划中发挥作用。

其中，第一、二条原因已经无法消除，第三条原因暂时也无法消除，因此同望在短期内是无法建立“探险式”的工作模式的。既然发展速度无法降低，精神观念暂时无法转变，看来，同望必须经历一场肉体分裂的痛楚了。现在想来（又是马后炮），总裁会关于从产品服务和部门机构的重大变革是唯一选择：必须尽快把项目服务从产品服务中分离出来，必须尽快把项目服务的人员从产品服务的人员中分离出来，必须尽快建立相对独立的项目服务和产品服务的组织机构。而且，从Proj2000和MP2000市场反应的情况看，项目服务还应该是重头。看来，2000年年末讨论中，占了上峰的来自谨慎地变革方面的观点值得反思。

参考文献

[1]:《软件能力成熟度模型》 清华大学出版社 何新贵等编著

[2]：《软件工程—实践者的研究方法》 机械工业出版社 (美)Roger S.Pressman著，黄柏素 梅宏译

注：全部的系列文章在我的blog的“旧作分享”中，这些虽然是旧作，但对很多发展中的软件企业而言，未必是陈词滥调，也未必是空洞的理论。
推荐到鲜果： 查阅更多相关主题的帖子: 企业变革 变革管理