解析沟通中的几层障碍

newmaker

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 摘要：他们总是很喜欢把事情搞得很复杂，所以他们会说这一切的过程有个专用名词， “嗯…这叫需求建模”他们很专业地说。比如我们的项目经理，以及那个被调来充当调研角色的程序员，他们就不会什么“需求建模”。如果客户精通UML，那么我想愚公采用的项目沟通方式将会是‘‘聚室而论UML'’。 第一节客户不会用C，难道就会用UML吗 我们总是要先接触客户的。是的，如果不这样，我们将无法确知要做什么。 作为开发人员，你可能更希望客户能学习或者精通C语言。这样客户就知道开发人员正在做什么，以及他们有多么地勤劳。或者，这样的客户还能以C语言的方式告诉开发人员他们究竟想要什么。 然而，要求客户学习C语言明显是自杀式的行为。在客户(的代表)学会用C语言来向开发人员描述他们的需求之前，可能就已经被老板开掉了。因此没有客户会笨到愿意用C语言来描述他们的需求。 C语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。 因此在前面所提到的R模型中，开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流(比如说汉语)。 或者你更愿意开发人员尽早地进入状态，那么，你可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研”，如果他不能适应这种转变，那就别让他去——那会是灾难的开始。 要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉及的业务。但这往往是我们所做不到的，因为我们是电子商务软件公司，而不是做这些(客户的)业务的公司。这时惯常的做法是聘请行业咨询公司(或者个人)来介入需求阶段，以协助了解和分析需求。 他们总是很喜欢把事情搞得很复杂，所以他们会说这一切的过程有个专用名词， “嗯…这叫需求建模”他们很专业地说。 现在你应该发现了差距。比如我们的项目经理，以及那个被调来充当调研角色的程序员，他们就不会什么“需求建模”。 接下来咨询公司会与我们的客户一起做业务建模，然后再做业务到需求的映射，再抽取需求并完成需求建模。他们做业务建模的时候，可能使用一些客户业务范畴内的符号和标识；而在做需求建模时，则需要使用一些软件行业中(的设计和分析人员)习惯的符号和标识。 这些符号和标识也有个专用名称， “嗯…这个叫建模语言(ML)。”他们无时无刻不在向你展现他们的专业(这已经是他们还存在的唯一原因了)。如果他们更加专业，他们会告诉你他们用的是UML。向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将会大放异彩。 UML是模型世界里的世界语。到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：如何与客户交流? 他们的解决之道是建模语言。 有什么差别吗? 程序员不能要求客户会C，难道需求分析师们就能要求客户会UML吗?! 第二节项目文档真的可以用甲骨文来写 台湾的项目管理顾问独孤木先生曾经在一篇UML，OOADandRUP中讨论到UML实际应用中的问题。其中的两个问题是： 1、大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件“User Case'’的正确性与完整性。 2、除了客户不了解UML、OOAD跟RUP以外，另外一个更糟糕的现象就是projectteam里面的人也不懂。 这实在是一件很有趣的事。 看来在一些情况下，在项目中使用UML只是完全不懂的老板，以及什么都懂的博士的主意，而真实的场景中去做事的那些客户与项目成员，其实是未见得就能用好UML的。 仅以UML的UserCase来说，它由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如何去实作。图则很简单，就是几个图形符号来描述零售系统边界和角色关系。 显然甲骨文也能描述范围与关系。例如甲骨文中的“家”这个字，就是上有房子下有猪，这个边界就定义得很好；在古文中， “三”通常是泛指，跟UML图中的线条上标注的那个“。”是同义的；而甲骨文中“众”这个字，就是“日”字的下面立有三个人，也就是用“在同一个日头下做事的很多人”来表示“众”，这个关系也描述得很确切。 所以只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。同样的，只要约定一套“语法”，你同样可以用甲骨文来做活动图、类图、构件图……以及与这些图相关的规约。相比来说，古巴比伦人使用的楔形文字“象形性”差一些，因此我不建议用它来画用例图。 既然甲骨文可以用来做为一种模型语言(同时它也是一种文字和口头的语言)，那么，如果你的项目面对的对象是商周文化的考古学家，以及你的项目组都由精通这种语言的成员构成，这时你就可以用甲骨文来做项目文档，以及画各种模型图例。 你要明白，要让考古学家看懂用例图，难度远大于看懂甲骨文。与其要求他们学一种语言，不如使用他们那个世界的通用语(当然，前提是你的项目组也懂得这种语言)。 在韩愈的《答陈生书》中，他因自己不会“速化之术”，所以说陈生是“求道于盲”。然而他用了一个不恰当的比喻：要知道盲人并非不知道路如何走，只是他不能像常人一样描述他所知道的路。因此“问道于盲”是没有错误的，真正的错误是你睁着眼睛问。 我们需要在正常人与盲人之间建立一种沟通的方式，既然盲人不能睁开眼睛，那么你就闭上眼睛好了。 UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及……更深入的交谈。 你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及你用UML表达得是否正确。客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML图画得是否精准。 现在来思考：为什么非要让客户看UML图呢?如果有能够满足“极限编程”所要求的“现场客户”，那当然可以不画用例图；相反，如果客户雇了一个专家组来评审需求，那么你就老老实实地画用例图好了。 需要留意的是，专家组还要有一种方式与客户沟通，这有可能不是UML。当然，客户愿意增加沟通成本，那是他们的事。一旦源头确定，接下来，你就可以约定在项目组中要使用的沟通方式。愚公——这个伟大的项目经理——所使用的“聚室而谋白”，就是很好的沟通方式。当然，如果客户精通UML，那么我想愚公采用的项目沟通方式将会是‘‘聚室而论UML'’。我想一定会这样，因为愚公是很懂得沟通的、伟大的项目经理。 第三节沟通的三层障碍 我们坐在一起“聚室而谋曰”，只是解决了“沟通渠道”的问题。但沟通的双方被找来坐在一起，相互间都没有想过怎样跟别人阐述他的想法和道理，这样表述的内容当然让人难以理解。又或者是不同的人总在转述着相同的内容(例如你发现在会议中A多数时候都在重述B的言论)——显然，这是因为新的沟通或讨论必须在一种共识的基础上进行，所以每个人都在试图要求对方确认“我的理解是否正确”。 这些其实都是“沟通质量”的问题。 我不是语言学家或考古学家，因此坦白地说，我并不知道甲骨文的读音。然而这些未经组织的语言就好比是一种我们不知道读音的甲骨文：我们能大概地看懂文字的表面，却不知道讲述者在表述什么内容，或者他为什么要这样表述。 所以沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是“不知所云”。这种情况下，你需要‘‘组织语言、学会说话”。 现在假设你花了半个小时在一家商店选购，结果你对店员小姐拿出的每一件物品都不满意。在你离开的时候，她可能会这样对你表达歉意： ‘‘对不起，先生，我们这里没有您想要的东西……，’ 在第一次听到这句话的时候，我就在想，她为什么不说“对不起，先生，您想要的东西我们这里没有”呢?这两句话到底有什么差异呢? 仔细理解这两句话，前者在说的是“我们没有”，因而责任在我；后者在说的是“您想要的”，因而责任在您。看起来这两句话是在表述同一件事，但因为语言组织得不同，前一句的语气是在“致歉”，后一句则是在“推诿”。 接下来又会发生什么呢?如果店员小姐说“对不起，我们没有……”，那么可能三天后这个商场就会有货了，因为她会有更主动的意识去解决问题；但如果她说“你想要的……我们没有”，那么你就不要指望在这家店里还能买到你想要的商品，因为在她看来， “你要什么东西”只是你自己的事情。 因此，即使抛开这两句话是否舒适悦耳的比较，我们在潜意识中也在希望从这两句话中看到事件的后续发展。由此看来，从叙述中揣度结果，是人们在交流沟通过程中潜在的意识和行为：如果两个人在努力地交流，那么他们都一定会像分析这两句话的差异一样，无比细致地去分析对方的描述。因此， (注意!)他们事实上都会关注对方的措词、语气、句法，或者分析表达的前后逻辑与关联。而这样做，通常有两个目的： 》找到对方表达的潜在含义与目的； 》找到对方叙述中的逻辑错误。 第一个是支持者的心态，第二个则是反对者的心态。然而你应该知道，这两种心态就是一个会议的全部内容。 所以你会发现，重要的人很少说话，而重要的会议所需要的发言也很少。这样的角色，或者这样的场合下的言论都是经过充分组织的。——只有这样的表达，才会更有效。 我的老朋友Soul有一句名言：“对于两个聪明人来说，正确的结论通常只有一个。因此如果出现了争执，那么讨论的一定不是同一问题。” 这句名言最关键之处，是在于它首先设定了“两个聪明人”为前提。然而实际交流中，事实上我们经常会主动地让这个前提不成立：我们通常会把对方当成白痴，试图说服对方支持你的“聪明观点”。 所以我经常会读到一种文档，这种文档没有前提，没有概要，开始就说“我们如何做”或者“为什么我们要这样做”。你大概得在翻很多页后，才能找到一个结论：哦，原来那个家伙在说这件事。 通常，如果一件事正确，那它就是正确的。无论你分析的过程如何，结论也‘‘不过如此”。所以你应该把结论放在文档的前面，把指导性的原则放在更前面，把事件的前因与目标以概要的形式放在最前面。一个聪明人只需要200字就可以说完的一件事，同样另一个聪明人也只需要这200字就能理解。。 对于一件事来说，起因、目标、结论和原则都已经确定了，剩下来的过程控制还需要“聚室而谋曰”吗?——哦，如果是这样，愚公的团队每天的工作流就只剩下开会了。 所以沟通的第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下，你应当预设前提，并尽早阐述结论。 关于用甲骨文写文档或者说话，最初的设定是“大家都懂甲骨文”，最终的要求是“说(或写)清楚”。但你可能已经发现这样设定存在一个荒谬的前提：我们总能把一件事讨论清楚。 这个前提之所以“荒谬”，是因为它忽略了成本。如果一件事要足够长的时间才能讨论清楚，那么等它讨论清楚了，这件事本身也就失去了意义。讨论清楚事件A，与实施事件A之间的确是存在前后逻辑的，但如果“维持这个逻辑的成本”使得事件A不能被实施，那维持它的前提也就不存在了。 除了时间这种沟通成本之外，沟通消耗的人力成本也是关键。事情A需要两个人沟通来解决，与需要10个人(或整个团队)沟通来解决，所消耗的成本显然是不一样的——人多并不仅仅使“沟通变得更复杂”。所以，一个结论是需要在“大多数人之间做出”，还是只需要“在一两个人之间做出”，是在一开始就要被确定下来的。 用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键。正是因为有了人和时间这些成本因素的约束，所以“我们讨论清楚再做”这个设定可能就会很荒谬。所以第三层障碍的主要表现是：不知缓急。解决之道，则是不要把沟通目标设定为“让对方认同”。 在我们的确没有办法把一件事情“讨论清楚”的时候，就是“旁观的人最重要”了。——作为管理者，应当去观察、理解和发现问题(或者由专人向你汇报)。你要尽量去听、去思考。因为作为这个角色，你总是有机会纠正问题的。 但是，不要急于去纠正——在一个会议上即使某种想法有问题，也决不是在你发言的三分钟里就能纠正的，而是在最后你做出的决策里去纠正的。这种决策通常有两种： 》给出明确的答案； 》 存而不论。 看起来，让你“给出明确的答案”是职责所在。反过来说， “存而不论'’就似乎是在推卸责任了。但是可能在某些情况下， “存而不论”才是最好的决策。 项目经理不是理论家，所以并不是“一定”要把一件事理论清楚才能实作。“论理”是要以沟通成本(人力和时间)为代价的，也可能以牺牲“事件”本体来做代价。因此作为管理者，你应该“适时地终止讨论”。 沟通不过是手段、是工具之一种，管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人(而不是整个团队)继续去讨论。于你而言、于项目而言、于整体而言，“有的‘异’无关宏旨，无碍大局，可以存而不论”。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (7/1/2009)