《产品研发过程实践》 34 谈谈活动发起能力

作者:asky 日期:2007-04-29

字体大小: 小中大

这里说的活动发起能力，说的是当你需要推进一个新的事情的时候，你会如何推进这件事情，使得团队能够接收？这一点是如此的重要，因为，这个能力决定了你是否能够把你的想法落实在实际操作中。

最简单的活动发起能力，无非是强制执行，对一个颁布的新的做法，给予一个公开的解释，然后安排人员进行Check，对于不按照此流程操作的人员，给予强烈的负面反馈，使得团队按照自己的想法来往前走。如果你希望尽快地落实一件事情，这种看起来非常粗暴的做法，也能获得比较不错的结果。但是这种做法未必是最有效的，他看起来有效仅仅是因为这是最容易进行操作的，管理者也相对来说更省心。但是，说他不是最有效的原因是，这种做法依赖于强烈的压力，使得团队成员按照自己的做法来做。支持他的观点认为：依靠着团队执行某一个流程，然后发现流程的好处，把这个流程转换为自身执行的流程，那时候将不需要过于多的监控。但是从现实工作的情况上来看，这种现象似乎并不是很多。如果你所有的流程都是如此来监控，一方面使得管理成本急剧上升，另外一方面，压制了团队自我的创造力，因为团队已经习惯于在一种高压下进行工作，并且使得他们觉得任何对现在流程提出改进的做法，都面临一个风险，那就是你企图不执行流程。这一点如果扩展开以后，将使得事情很难操作。管理者过于忙碌，而且觉得团队很难管理，同时团队觉得自己象一个小小螺丝钉，没有太多的主观能动性。这是一个必然的后果。而且，相对的来说，这种做法是不能持久的，当压力被慢慢消除的时候，团队会放弃这种做法。

其实，我们来想一想，为什么某一些做法能够得到团队成员几乎全部成员的支持（比如尽量好一些的版本控制方式），但是某一些过程不是呢（比如强制需要团队做出尽可能详细的设计文档，然后再进行编码）？这一般来说有两个原因，第一，目标本身就存在着问题，这种目标并不能解决关键性问题；其次，做法是存在问题，推动能力不够，使得这种做法，包括价值观和具体的操作方式没有落实到整个团队的核心中，将一个相对Lone-team的时段中，团队自动排斥了这种做法。

那么，我们举一个例子，我们希望达到这样一种做法，项目经理尽量详细地制定一个任务所要达成的目标，而允许团队成员对自己的工作分配提出异议。这种做法一方面强化了项目经理的工作，因为他再也无法通过一种若有若无的，以及临时性的任务分配，来完成对于团队成员的工作安排；另外一方面，需要加大项目经理的沟通难度。如果某一些人员对分配给自己的任务表示不满，项目经理需要有说服能力，以及任务的一些修改，来达到双方之间的认同；同时，他将使得团队成员真正认可自己的工作目标；并且需要项目经理对于工作任务无法完成的人员进行一些反馈等等。这看起来执行起来，会加大很多项目经理管理上的难度，但是他的优点是：过于慷慨的承诺将将被小心的承诺所取代，工作更加有序化，团队之间工作的关联性，将在其中得到了强化，团队成员对于项目的进展更清晰等等。同时，项目的模模糊糊的进展将被一种相对来说更明晰方式表现出来，使得我们对于项目进程更可控一些。

那么OK，也许我们会发现，这种做法上事实上面临几个压力源，比如项目经理是一个压力源，因为这将削弱项目经理的权威，并且加大项目经理的工作强度；对于团队成员来说，他们相对地来说会比较喜欢这种做法，因为这强化了他们对于工作的控制性，并且使得自己的工作相对来说更加清晰。

如果我面临这个流程的推进，我将会采取以下一些做法，来推进这项工作：

首先，我需要摘取一些历史数据，通过一个能够让全员知道的方式，公布出来。说明我们任务目标不明确，所面临的一些困境，说明这个问题，到了需要我们改变的时候。而如果我们达到了任务目标明确性的做法以后，将会获得好处等等；如果我有部分时间来推进这个流程的话，我不会抛出我的观点，因为我不希望自己的观点来影响其他的人员。而且，未必我现在的做法就一定是最好的做法，我们仅仅是为了达到这个目标而已。如果大家能够提出更好的解决方案，我有很大的动力，来采取别人的意见；

其次，我会寻找部门中的PM以及一些核心员工进行一些私下里的沟通，我相信一点，大多数人的看法大多数都是类似的。所以，我相信我们的PM和核心开发人员一定也会提出和我类似的，甚至更好的解决方案。OK，我不希望出现一点情况：认为这个方案是管理者想出来的，大家都不敢批评或者提出异议。如果他们认为这个想法是自己提出的，一来他们会更容易执行，第二，他们发现流程中有不完善的地方，也没有太多后顾之忧进行改进（呵呵，改改自己的说法，总比修改老板的要求要简单一些吧）。好了，进行这个步骤，主要有两个目的：群策群力，找到一个更好的解决方式；第二，让员工参与决策，便于将来的操作。这个阶段产出的主要内容是操作方式，和考核方式；

推进方式出来了以后，我们会找一个项目（而不是所有的项目）进行试验，在某个时间段中，推进这个流程，然后，按照我们当初确定的考核方式进行考核，看看流程推进得如何。

推进了一段时间（一般来说是1个月到一个半月的时间），然后我们进行一次汇总。从操作者身上来了解一些反馈。针对这个例子，我们可以从PM身上来了解工作量增加的程度，可以了解对于目标推进的作用；从开发人员身上，主要了解这种做法，对于工作是否有一定的帮助作用。然后我们综合考虑利益和成本，看看这件事情是否值得去做。如果值得做，那么成本方面是否有可以削减的地方？因为不管我们干什么，毕竟我们只是为了解决一个问题而已，没有必要把所有的问题，都企图在一个解决方案中解决掉。这样容易导致过于繁杂的流程。

然后，了解了情况以后，写一个介绍情况的PPT，让几个典型人员进行介绍。我的推荐是是让各个利益体方面都来说一说，比如开发人员会赞成这种做法，毕竟这种做法不会增大自己的工作量，而且明晰了自己的目标，但是对于PM来说，他会关注这件事情的价值和成本的关系。对于大型的项目来说，也许成本会增加到一种不可操作的层面，我们需要进行组织结构分层来支持这种流程（但是如果仅仅是为了推进这个流程，是否有必要进行组织结构的分层管理，也许那样做成本太高了，而且未必效果就一定好，风险也很大）。类似的，我们的PM和开发人员会为此进行一个讨论，并且修整一下流程；再投入多一些的项目推进。

在整个流程推进过程中，我们会尽量多得采用正向激励，当某一人完成这项工作比较出色，我们需要尽快得给予反馈，并且给予奖励。如果完成得不是很好，我们会推进一下，但是不会因此去批评得太多。

当整个流程稳定下来以后，我们会更多的使用负向激励。只要一个规章制度在那里，就是需要执行的。如果效果不好，随时反馈，我们会按照需要进行修改（绝大多数人都自认为是这样的，但是请大家想想一点，在去年一年的时间中，你采纳了多少别人的建议并且修改了流程？如果这一点很少很少，那么你说让大家反馈，实际上就是一句空话了）。

在推进的时候，我不喜欢一开始就非常复杂，徒劳地增加了很多工作量。因为那时候，我们也许有很多事情根本看不清楚。一件事情要开始做，最重要的是：我们需要起步，然后再改进。如果一开始就有一个很高的门槛，会使得起步很困难。这样的话，推进真的很困难啊。

而且，我喜欢一种讨论方式，不是那种纯粹学术上的。比如理论上说来，任何决定和任何信息，都记录在文档中，是一种最为保险的做法。因为他至少从理论上，能够提供任何回溯。但是这种事情绝大多数不可操作。是因为成本太高，以及实际上产出很少（大家可以去想想大家看见的需求文档，有多少是符合现在项目的？）。而且，这些成本在执行过程中，被流程制定人员大大低估了，我们总是认为，如果你每做一个改动，就修改一下文档，那么工作量不会很大。只有你一次性修改的时候，成本才会很高。

可以比较明确地说明一点，这种观点是错误的！在开发过程中，发现一些改变，然后对其中内在逻辑联系是依靠人员来维护的文档体系来说，这种做法的成本是极其高昂的。因为你打乱了开发者的思路。而且你认为提笔就修改的地方，有时候实在是太多了，以至于我们淹没在文档体系中。逐步修改，并不是能够极大的降低成本，只是把一次性成本投入分散在整个过程中去做而已。当然好处是，这使得开发人员能够真正去重视和有信心去维护一份文档。老是阶段性的大修改，使得人员对维护一份文档的正确性越来越失去信心。

软件管理流程，说白了最大的一个问题是：我们总是提出一整套的理念和解决方案，但是没有辅助手段去进行操作。说要什么文档很简单，但是有多少PM能够告诉我，某一份文档，在项目中维护，需要多少时间？至少我直到现在没有在一个Project的人时规划中，看见过一个项目经理，去留下足够的人力和时间去修改这些设计文档和需求文档，仿佛这些文档是可以自己更新完毕的（在CR过程中，倒是有的）。

所以，多听听手下人的抱怨，并且想办法去改变。而不是一切都归咎在他们的执行能力上，在实际工作中，总是比较有效的。

我举一个例子，说明一下某一项工作的工作量。当然，以下的情况也许绝大多数开发团队没有碰到的。我们都知道，需要在系统运营过程中，根据实际情况，去做数据库优化，以及数据库索引的建立等等类似的抉择。我们一般来说，对于这项任务分配的人时大约是100-200人时就很不错了。但是，如果一个真正需要认真进行这项工作的团队来说，需要10多个优秀的DBA持续进行监控和调优工作。如果你没有这个觉悟，那么就不要提出太理想化的流程，真的很难操作的。

在考虑流程和推进的时候，考虑考虑成本！考虑考虑执行可能性！

最后，我想说两个例子，来说明另外一种理想情况，当然这是另外一种理想情况，暂时几乎还不可能达到。但是这里写下来，只是为了让大家多一些其他的思路。有时候，简单的做法收到的效果要好的多。一次性成功的做法，在面临越来越严厉的环境下，将变得越来越不实际。

第一个例子：我们有一片很大的草坪，他如此地大，以至于我们必然要在里面设立几条道路，让别人走。但是我们不希望大家从草皮上走过去。粗暴一些的做法是：每隔20M设立一条路，然后在每个路口都设立一个牌子“禁止践踏草皮，违者罚款5元”。但是我们常常发现，很多人还是从草皮上走。于是我们就觉得：唉，这些人的素质为什么如此地差啊。只有20M的间隔，为什么就不能走上一小段呢？为了解决这个问题，我们设立不定时的检察员，去抓这些人员，但是仿佛总是抓不胜抓啊。这一点很讨厌（也很常见吧！想想为什么城市里面有那么多人翻越道路栏杆？因为两个能够给行人通过的路口之间有2站路，不然你去走走？恐怕自己都做不到吧！）。理想一些的做法是什么呢？我们先铺一整块草皮，然后让大家在上面走，经过1个月时间，上面自然会留下一些道路，这些道路是最多人踩的路。然后我们就知道，大家通过这个草皮，在最多情况下，是要到哪里去，然后我们就在自然形成的路上，开辟几条固定的道路出来，让大家去走。其他地方被禁止。虽然这种做法还是无法最终避免有人践踏草皮，但是相对的来说，我们需要监控的人就少了很多。一个流程应该是一个大部分人群能够执行的流程，我们去改进少部分人的做法而已。如果一个流程，需要管理者监控几乎所有人的工作，这实在有点过于难受了。

第二个例子是蚂蚁寻找食物的路线形成。蚂蚁一开始不知道食品在哪里，然后他们就外出四处寻找，这走过的路线将是很乱的，蚂蚁会在走过的道路上留下一个嗅觉的痕迹，然后他会沿着原路返回。并且告知其他蚂蚁：“跟我来，我找到大个的屎壳郎了！”。其他蚂蚁会沿着这条嗅觉去进行搬运。同样的，他们也会留下嗅觉痕迹。如果到那个屎壳郎的距离比较长，那么那条路上的蚂蚁就会回来得比较慢。如果距离比较短，就会回来得比较快，相同时间中，走过这条路的蚂蚁往返的次数就比较多，留下的痕迹也就比较浓。更多的蚂蚁将会吸引到这条路线上来，于是一条相对来说比较短的道路就形成了。这个过程仅仅依靠一个最简单的规则“寻找一条味道最浓的道路”。仅此而已，我们就能找到最短的道路。而如果我们企图依靠命令-控制这种方式，那么我们将使得问题复杂很多很多了。其实，这个例子在现实生活中也很常见，比如在公司升迁制度。公司的高层通过升迁制度，挑选适合自己企业的人员来进入中层，同时中层也使用同样的做法来挑选底层管理者。员工通过观察管理者为什么会得到晋升来衡量自己的做事方式，逐渐使得整个企业都具有一个很深厚的价值观和文化。但是，相对得来说，我们在公司升迁过程中的观察，并不是那么明确，因为很多东西在里面，你需要判断，到底哪些是关键点。这一点相对来说，就比较复杂了。但是，无论如何，这也是类似的。同样的，这就是为什么我们在流程初期大量使用正面激励的一个原因。因为这会明确告知大家一个信息，这是一条得到大家赞赏的路线。

呵呵，说到这一点，MPA的案例中，倒是有不少例子，来说明在政务中的一些做法，对我的启发还是比较大的。得空，大家可以去看看，的确还是不错的。你能够更多地从一种“命令－控制”方式，转移到一个“领导-反馈”的模式中来。而后一种模式更适合于将来。

好了，说了不少了，之所以指出一些流程本身的问题，是因为如果你需要增强你的活动发起能力，你需要首先保证你发起的不是一个烂东西。比如你发起一个活动“让大家把月薪的10%交给直属管理者”。你认为发起这个活动的结果是什么？我不看好！

OK，有意识地去锻炼这些能力，将使得你的工作事半功倍，不然，你就等着忙碌吧。