沟通避免流于形式

文：鼎捷ERP

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

第四节较简沟通
    在D项目中，我向我的项目组员提出在需求阶段与客户的沟通计划。这个计划只有三条：
    》    在一个月中，只能跟客户进行三次联系；
    》    三次联系中，较多只能有一次面谈的机会；
    》    一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划。
    D项目并不大，所以从主观上来讲，客户(代表)并不会为这个项目投入太多的精力。重要的是，我们在前期交涉中已经发现：这个客户代表为大量其他的项目和工作所困扰，他不会有时间来处理我们的问题。因此，减少沟通和保障沟通质量的问题就显得非常突出。
    在大多数的项目中，这样的问题都是存在的。真正能满足极限编程所提出的“现场客户”的情形并不经常出现。即使能将程序员送到客户现场中去，沟通问题仍然是不可避免的。
    因此在D项目中我提出了“较简沟通”。
    我们开始在网络上查看相关的协同软件系统的特征，以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手在做什么和在关心什么……
    较后，我们开始综合以下两个方面的因素：
    》    客户在公司层面的外在表现、内部机制和运营管理手段；
    》    客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求。
    这样我们就了解了客户项目中所有会产生需求的信息点。
    我们开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能地具有发散性以便形成更多的推论和假设。
    我们把这些做成项目概要用E-mail提交给客户，并在第二天电话回访他。他以口头的形式回复了这封E-mail，这让我们尽可能多地得到了项目在方向上的修正。
    我们确定了项目的实际目标，以及远期的方向。接下来就是设计需求条目。
    客户已经先期提供了一些关于项目的文档、报表和工作数据。因此基于这些数据的需求分析，将是下一个沟通前所进行的较艰苦的工作。项目组员被要求：
    》    分析用户的每一个表格，以构建基础数据库；
    》    分析每一条数据的含义以确定它的上下限，以及数据间的相关性；
    》    从工作文档中去了解客户的组织机构及其相互关系，同时确定了每一类使用该系统的角色；
    》    从报表中去了解客户关注的数据信息，以及被他们所忽略掉的数据信息。
    我们从数百条的需求条目中，整理出系统结构和模块，需求条目被映射到各个模块。我们很快就画出了模块间的相互关系图，并通过这个图分析了数据的交叉关系，设计了相应的数据索引并增加了一些新的关系性数据。
    我们对用户角色、原始数据和系统结构进行了梳理之后，我们花了很短的时间实现了第一个系统模型。当然，很多的功能项目，我们都只是简单show adialog。但我们优化了每一个操作流程，以保证不同的用户(角色)在使用时都尽可能流畅。
这一次的沟通我们使用了面对面的模式。我们很庆幸地得到了与这个供应链管理系统的每一类用户(角色)接触的机会。而正好我们有一个模型，我们便让他们来操作并提出意见。这一次我们终于有了一份详尽的调研报告。

接下来的分析设计是顺理成章的事。我们在一个月后完成了这个项目的需求分析报告，以及在这个分析上的一些框架型的设计。还有，一个被用户所接受的原始模型。

尽管，第三次的沟通中还发现了一些问题。但我们终于有了一个好的开端。

应该清楚的是，保障每一次沟通的有效性都是较重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此较好在见到客户之前，你就已经设计了所有的问题和提问方式。
    吃饭并不是有效的沟通。大多数时候，那将以醉酒收场。
第五节为不存在的角色留下沟通的渠道
    大多数人不会知道，我们中国的‘‘五千年文明史”实际上仅有三千年“有史可查”。
    司马迁在史记中写道： ‘‘维三代尚矣，年纪不可考，……于是略推，作三代世表”。也就是说，他在写史记时“(夏商周)三代”的年代已经不可考丁．因此只能做“世表”；而其后十二诸候国的年代才町考证，因而有“(十二诸侯)年表”。
    世表和年表的准确性和可靠性有明显的差异，因此我国古代编年史能追溯到的上限，就成了《史记·十二诸侯年表》中记载的西周共和元年，亦即公元前841年。
    司马迁无法做夏商周三代的年表是因为其年代不可考，这是因为自黄帝以来的许多文献材料中，一部分虽有年数，但比较模糊且不一致，所以他只能弃而不用。
    现在国家在“夏商周断代工程”中再次推算和考证编年史，这些相关资料也同样只做参考，实际采用的方法是更有可信度的金文(金属器物铭文)、历史学、天文学、碳—14测年等。
资料的缺失、及其有效性的缺乏，给中国编年史撰写带来了莫大的困难。
项目的中断和中止，与历史产生断层的内囚是一致的。——我发现很多的项目(尤其是产品计划)在负责人员离开后，就自然而然地死掉了。我把这—-的切原因归咎于“没有History”。在先人写“谱牒” (简、册)的时候，想必是没有考虑过有后人要读的，或者更为远古的先人可能根本没想过要留下他们的生活和部落的汜录，再加上有像秦始皇这样的人在前面放火烧东西，所以司马迁拿不到夏商周三代的确切史料，也是情理之中的事了。
    远古的先人不知道司马迁这一号角色的存在，司马迁也没有办法跟古人约定一下要留点记录给他写《史记》。
    我们做项目的时候，如果也不留下历史记录(History)，那么以后别人来看这个项目，也会是两眼一抹黑，要么就像司马迁一样“存而不论”，项目便就此中止；要么就像“夏商周断代下程”一样，花大量的人力物力来攻关。

    维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟通、对话的渠道呢?

我把项目的History作为跟这种“不存在的角色”沟通的一种方式。Hist0ry的丰富和准确为项目的后继开发、维护提供丁可能。

历史记录(History)与注释(Comment)不是一同事。代码中的注释是为阅读代码而留备的，而Hist017是为整个项目而记录的。一些参考的记录内容有：

    需求阶段：与谁联系、联系方式、过程、结果以及由此引发的需求或变更；
》    设计阶段：如何进行设计、较初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性)；
    》    开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；
    》 ·测试阶段：还记得测试用例和测试报告吗?那是较好的History之一。
    当然，另一件较重要的事，是记得在每一笔记录后写下时间和你的名字。你的每一笔记录都是打算留给一些根本不了解这个项目的人看的，之所以要记下你的名字，是便于那些人能够再找到你并溯源到问题的源头。——当然，这得赶在你和古人一样“与天地共存”之前。
    我们知道，大多数的工具都有历史记录的功能。在开发丁具和测试工具中尤为突出。此外，版本管理工具也留下了每个阶段的印迹。然而，我建议不要过于信任它们。如果不明确要求项目组员写下详细的History，那么他们可能在每一次版本签人时都只写下两个字的备注： “完成”。
第六节流于形式的沟通
    在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或者打
回访电话。
    其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目……较未了，才是交流感情。然而大多数的情况下，它仅仅被看成是交流感情。这便成了形式，且往往是客户所讨厌的一种形式。
    沟通问题不仅仅存在于你跟客户交流之中，还存在于项目的各个角色之间。项目的分析报告为设计人

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

下一页：做软件工程不是做过程