关于咨询团队的一些随想（by AMT 王玉荣 ）

整理文档时，注意到一篇三年多以前的文章，是写给加入咨询业不久的同事的，探讨作为咨询业从业者如何在很多工作细节上形成一支高效的团队。现在看来，有些问题虽然简单和细节，但仍有可以沟通的价值，毕竟：管理本身就在于细节。

因此，提交出来请AMT的编辑发布。

关于咨询团队的一些随想

by AMT 王玉荣

1、 咨询顾问的讨论会如何能高效？

在讨论环节，应充分地互相倾听，进行意见的融汇，而不是简单的“是否”二义判断或简单的累加。

因为，我们要承认这样的前提：
－项目成员的每个人是抱着认真的态度来提出问题的，他的角度是别人也许没有看到的。
－很多问题不是二义判断的问题，只有互相丰富，才能逼近最全面的认知；
－通过技术问题的融会贯通，实现项目组中人与人的合作融洽，在长期降低了交易费用。

所以，我们要采取这样的态度：
－首先由每个成员自由地发表意见，然后才进入归纳、断定的环节；
－A在对B的意见进行补充时，应注意到B对此问题的已有描述，把B的意见首先结合到A即将发表的意见中去，并通过在表达意见中确认B的意见，如“我同意B刚才提到的……..”“对于某问题，B已经阐述得很充分，我就不再重复了………”。这样就可以避免B产生这样的认识：虽然A的补充都是正确的，但无论B是否已经事先表述意见，A都会做出完全一样的补充，这也许会影响B对A正确意见的接收。
－认识到许多问题不是二义判断的问题，当A、B的意见不一致时，共同到实际中探求答案；
－整个氛围是建设性的，尊重主要项目成员的引导作用，同时最终在具体问题上其他项目成员的“引导”作用，形成在“统一”引导下的分阶段的“局部”引导。

2、 对于工作的反复修正，应如何认识？

在一个复杂项目中，尤其是不确定因素、干扰因素比较多的情况下，有时会出现工作反复、甚至工作方法要做调整的事情，这是正常现象。

对于这个问题，首先要承认这样的前提：
－这是在项目整套方法有待完善的情况下出现的，而不是某人的工作失误或者项目经理的领导不力；
－每个人都有对工作不断改进的责任，如果拒绝改进，那么整套方法的持续完善将不能实现。
－每个人都会对自己已经完成的工作产生依赖，如果要改变，增加工作反复，应有充分的理由。

所以，我们要采取这样的态度：
－当工作反复的情况一出现，应敦促项目成员对这种状况的正常性达成共识。
－工作反复的建议由提出人向项目经理提出，经项目经理确认，由项目经理公布。提出人不应在项目成员间散布对旧有方法的不满。
－项目经理在确认过程中，应区分问题是实质的还是形式的、频繁程度，以谨慎负责的态度做出决定。
－提出人应严格遵守改进后的方法及规范。
－项目经理在公布改进设想前，应阐明改进的理由。如果项目成员提出合理的重大反对理由，项目经理可以中止公布改进方案。
－其他项目成员应严格遵守改进后的方法和规范，有不同意见在公布前提出，而不应在公布后散布不满或者以怠工来表现不满。

3、 关于保证现场工作协同的问题

在客户处作跟踪调研时，曾经遇到这样的情况。客户针对某些顾问指出：有些顾问提出的有些问题是以前就解释过的。我们认为，

我们对于这个问题的认识是：
－随时记笔记是咨询顾问的基本素质，哪怕是细节问题，以减少工作的反复性，提高工作效率，同时也显示出业务水平。
－这种现象不是个人冒冒失失的问题，是应该努力规避的，从方法上、工具上、协同作业上来规避。

这种现象不是偶然的，在听取了客户的多次介绍以后，有时各顾问各自有自己的笔头记录，一是对自己的前后记录记不住，二是不了解其他人听到了哪些信息。这时，咨询公司的知识管理机制和知识管理平台就显得重要了。作为要长期发展的规范咨询公司，迟早要建立起知识管理的平台环境，而且越早越好，咨询顾问以及所有与公司知识积累有关的人员也应同步地熟悉这种工作方式，方便他人，方便自己，越早熟悉越好。

－在与客户交流时，注意方式方法。对客户方的关键管理人员，如有项目决策权的人物、项目组长，不应问及技术性的业务问题，而应把这些问题向相应的具体工作人员调研了解。
－建立与客户交流的“里程碑”。这也是我最近在“银湖计划”一书中同样验证到的体会。

在IBM研发AS/400时，传统做法是先完成各软件段的编写和测试，最后再汇总测试、调整、让客户使用、改进、再调整，但这种做法无疑耗时、耗力。

后来他们的做法是，首批编写并测试通过的软件段就先在机器上运行，未完成的软件段也留一个输入输出的通道在那里，一开始就让客户来使用，改进不足。客户从一开始就可以感受到整个设计的全面性和已完成局部的完备性，并对未完成的部分有了初步认识，只待逐步细化和深化。
所以，这就建立了研发中的一个个里程碑，从初始点开始，就可以运转；每当一部分工作完成，就是对前面所有工作的丰富和补充，于是运转得更好。一个雪球于是越滚越大，而不是先把所有需要的雪都先挖来，再一点一点地粘成一个雪球。

类似的道理，我们在工作中还是要多做客户“看不见”的工作，而不是把所有的精力放在会提交给用户、使用户看到的文档上面。与客户初步交流以后，就可以达成的共识进行确认，形成一个框架，那么以后这部分内容就不在继续了解和提问之列；以后与客户的进一步交流，都是对最初确认框架的丰富和深化，而不是想到哪里就问到哪里。

类似的道理，在紧张的项目工作中，也可以采用这种方法。如一个流程优化的咨询项目，在与客户初步交流后，可以形成流程优化方案的最初版本，随着项目的调研深化，逐步完善方案的内容和形式，到了相对全部的信息掌握了的时候，最终的文档自然就提交出来了。那种认为了解不清楚就不作文档，非要等到后期面对繁多的数据时才作整理的做法，一是头绪太多，一开始就作复杂的事情，往往想得到作不到，很容易失败，其实会严重延误项目时间。而是项目组成员之间缺乏交流的平台，所有的认识都在个人的脑子里，最终走向混乱和遗忘。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友