《大道至简》第四章内容总结

   这一章主要讲的是沟通问题，再做一个项目时，最重要的就是理解用户的要求，而实现这一目标的方法，就是沟通。

   而在现实中，其实真正与客户面对面沟通的机会是非常少的，所以，要想办法在最短的时间，最有效率的理解客户的意图。理解客户的最直接方法就是提问，把自己不明白的需求提出。提问也是有技巧的：

   首先调查客户在公司层面的外在表现、内部机制和运营管 理手段。 客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求。这样我们就了解了客户项目中所有会产生需求的信息点。之后就设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设。我们把这些做成项目概要用 mail 提交给客户，并在第二天电话回访他。他以口头的形式回复了这封mail，这让我们尽可能地得到了项目在方向上修正。 

   这只是前期的不见面的沟通，而真正的重头戏则是面对面的沟通。但由于客户的时间问题这样的机会是很稀少的。所以，面对面沟通也是最需要珍惜的沟通机会。得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。 

   沟通也不只涵盖与客户的沟通，也涵盖与“后人”沟通。我们做项目的时候，如果也不留下历史记录 (History)，那么以后别人来看这个项目，也会是两眼一抹黑，要么就象司马迁一样“存而不论”，项目便就此中止；要么就象“夏商周断代工程”一样，花大量的人力物力来攻关。

   一般来说，维护旧项目比做出新项目更难。所以，我们要在做新项目的时候就要为以后维护时的方便做准备。要为“项目维护”这种还不存在的角色，留下一个沟通、对话的渠道。

   这种东西与我们现在编程所用的注释听起来简直一摸一样，然而历史记录(History)与注释(Comment)不是一回事。代码中的注释是为阅读代码而留备的，而History 是为整个项目而记录的。书上有相关记录的例子，如：

             需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；

             设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更    

     导致项目结构上的变化(有助于了解构架的可扩充性)；

             开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘

     引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一

     个设计和构架变更所导致的影响； 

             测试阶段：还记得测试用例和测试报告吗？那是 最好的 history 之一。

 

    最后，沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目⋯⋯最末了， 才是交流感情。

转载于:https://www.cnblogs.com/hehejeson/articles/4899042.html