沟通时项目管理的手段之一

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第一节客户不会用C，难道就会用UML吗
    我们总是要先接触客户的。是的，如果不这样，我们将无法确知要做什么。
    作为开发人员，你可能更希望客户能学习或者精通C语言。这样客户就知道开发人员正在做什么，以及他们有多么地勤劳。或者，这样的客户还能以C语言的方式告诉开发人员他们究竟想要什么。
    然而，要求客户学习C语言明显是自杀式的行为。在客户(的代表)学会用C语言来向开发人员描述他们的需求之前，可能就已经被老板开掉了。因此没有客户会笨到愿意用C语言来描述他们的需求。
    C语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。
    因此在前面所提到的R模型中，开发人员较好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流(比如说汉语)。
或者你更愿意开发人员尽早地进入状态，那么，你可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研”，如果他不能适应这种转变，那就别让他去——那会是灾难的开始。
要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉及的业务。但这往往是我们所做不到的，因为我们是软件公司，而不是做这些(客户的)业务的公司。这时惯常的做法是聘请行业咨询公司(或者个人)来介入需求阶段，以协助了解和分析需求。
他们总是很喜欢把事情搞得很复杂，所以他们会说这一切的过程有个专用名词， “嗯…这叫需求建模”他们很专业地说。
现在你应该发现了差距。比如我们的项目经理，以及那个被调来充当调研角色的程序员，他们就不会什么“需求建模”。接下来咨询公司会与我们的客户一起做业务建模，然后再做业务到需求的映射，再抽取需求并完成需求建模。他们做业务建模的时候，可能使用一些客户业务范畴内的符号和标识；而在做需求建模时，则需要使用一些OA软件行业中(的设计和分析人员)习惯的符号和标识。
    这些符号和标识也有个专用名称， “嗯…这个叫建模语言(ML)。”他们无时无刻不在向你展现他们的专业(这已经是他们还存在的唯一原因了)。
    如果他们更加专业，他们会告诉你他们用的是UML。向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将会大放异彩。
    UML是模型世界里的世界语。到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们
仍然需要面对较直接的问题：如何与客户交流?
他们的解决之道是建模语言。
有什么差别吗?
程序员不能要求客户会C，难道需求分析师们就能要求客户会UML吗?!
第二节项目文档真的可以用甲骨文来写
    台湾的项目管理顾问独孤木先生(http：//www．wretch．cc/blog/phopicking)曾经在一篇“UML，OOADandRUP"’中讨论到UML实际应用中的问题。其中的两个问题是：
    》    “大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件“UserCase"’的正确性与完整性。”
》    “除了客户不了解UML、OOAD跟RUP以外，另外一个更糟糕的现象就是projectteam里面的人也不懂。”
    这实在是一件很有趣的事。
    看来在一些情况下，在项目中使用UML只是完全不懂的老板，以及什么都懂的博士的主意，而真实的场景中去做事的那些客户与项目成员，其实是未见得就能用好UML的。
    仅以UML的UserCase来说，它由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如何去实作。图则很简单，就是几个图形符号来描述系统边界和角色关系。
    显然甲骨文也能描述范围与关系。例如甲骨文中的“家”这个字，就是上有房子下有猪，这个边界就定义得很好；在古文中， “三”通常是泛指，跟UML图中的线条上标注的那个“。”是同义的；而甲骨文中“众”这个字，就是“日”字的下面立有三个人，也就是用“在同一个日头下做事的很多人”来表示“众”，这个关系也描述得很确切。
    所以只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。同样的，只要约定一套“语法”，你同样可以用甲骨文来做活动图、类图、构件图……以及与这些图相关的规约。相比来说，古巴比伦人使用的楔形文字“象形性”差一些，因此我不建议用它来画用例图。
    既然甲骨文可以用来做为一种模型语言(同时它也是一种文字和口头的语言)，那么，如果你的项目面对的对象是商周文化的考古学家，以及你的项目组都由精通这种语言的成员构成，这时你就可以用甲骨文来做项目文档，以及画各种模型图例。
    你要明白，要让考古学家看懂用例图，难度远大于看懂甲骨文。与其要求他们学一种语言，不如使用他们那个世界的通用语(当然，前提是你的项目组也懂得这种语言)。
    在韩愈的《答陈生书》中，他因自己不会“速化之术”，所以说陈生是“求道于盲”。然而他用了一个不恰当的比喻：要知道盲人并非不知道路如何走，只是他不能像常人一样描述他所知道的路。因此“问道于盲”是没有错误的，真正的错误是你睁着眼睛问-。
    我们需要在正常人与盲人之间建立一种沟通的方式，既然盲人不能睁开眼睛，那么你就闭上眼睛好了。
    UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、工作流程图以及……更深入的交谈。
    你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及你用UML表达得是否正确。客户是因为他认为你理解了他们的需求，而在
“需求确认书”上签字，而不是因为你的UML图画得是否精准。
    现在来思考：为什么非要让客户看UML图呢?如果有能够满足“极限编程”所要求的“现场客户”，那当然可以不画用例图；相反，如果客户雇了一个专家组来评审需求，那么你就老老实实地画用例图好了。
    需要留意的是，专家组还要有一种方式与客户沟通，这有可能不是UML。当然，客户愿意增加沟通成本，那是他们的事。一旦源头确定，接下来，你就可以约定在项目组中要使用的沟通方式。愚公——这个伟大的项目经理——所使用的“聚室而谋白”，就是很好的沟通方式。当然，如果客户精通UML，那么我想愚公采用的项目沟通方式将会是‘‘聚室而论UML"’。我想一定会这样，因为愚公是很懂得沟通的、伟大的项目经
理。
第三节沟通的三层障碍
    我们坐在一起“聚室而谋曰”，只是解决了“沟通渠道”的问题。但沟通的双方被找来坐在一起，相互间都没有想过怎样跟别人阐述他的想法和道理，这样表述的内容当然让人难以理解。又或者是不同的人总在转述着相同的内容(例如你发现在会议中A多数时候都在重述B的言论)——显然，这是因为新的沟通或讨论必须在一种共识的基础上进行，所以每个人都在试图要求对方确认“我的理解是否正确”。
    这些其实都是“沟通质量”的问题。
    我不是语言学家或考古学家，因此坦白地说，我并不知道甲骨文的读音。然而这些未经组织的语言就好比是一种我们不知道读音的甲骨文：我们能大概地看懂文字的表面，却不知道讲述者在表述什么内容，或者他为什么要这样表述。
    所以沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是“不知所云”。这种情况下，你需要‘‘组织语言、学会说话”。
    现在假设你花了半个小时在一家商店选购，结果你对店员小姐拿出的每一件物品都不满意。在你离开的时候，她可能会这样对你表达歉意： ‘‘对不起，先生，我们这里没有您想要的东西……，’
    在第一次听到这句话的时候，我就在想，她为什么不说“对不起，先生，您想要的东西我们这里没有”呢?这两句话到底有什么差异呢?
    仔细理解这两句话，前者在说的是“我们没有”，因而责任在我；后者在说的是“您想要的”，因而责任在您。看起来这两句话是在表述同一件事，但因为语言组织得不同，前一句的语气是在“致歉”，后一句则是在“推诿”。
    接下来又会发生什么呢?如果店员小姐说“对不起，我们没有……”，那么可能三天后这个商场就会有货了，因为她会有更主动的意识去解决问题；但如果她说“你想要的……我们没有&rdqu