反思：项目开发中的语言沟通与文档沟通

 

反思：项目开发中的语言沟通与文档沟通

 

        问题引出：刚进入公司试用期，有导师安排开发实现一些功能模块或者小的应用。毕竟需要在整个产品的框架下添加代码，看了下整个产品近1G的源代码，相当浩瀚。虽然是不需要我们新人统筹全局，但是至少需要了解当前模块所处的位置，以及其与上层模块、下层模块的接口、调用关系等。我的目前任务是导师口头安排的，因为对产品框架、模块接口等不很熟悉，这样就导致了语言沟通的问题，导师认为每次已经说得非常明白了，需求是什么，需要实现什么功能，我需要稍微了解背景去实现就是了。因为项目紧，沟通完毕我也就很快构思写代码，没有列举下思路，没有形成简洁文档给导师反馈确认，于是工作中就有了反复，走了弯路。

 

        反思：项目中除了口头交流外，必要的文档交流确认是耽误了时间还是能提高效率？

 

       个人思考：4年前曾参加过一个管理培训课程，讲师是MIT的“海龟”，他举了个案例，测试了大家团队的沟通能力和理解能力。例子是这样的，他自己在纸上画了不规则的图形（当然不是特别乱，语言肯定能说清楚的），然后选择听众一人上台用语言描述这个图形，其余人在下面根据台上人的描述去勾勒图形。最后大家提交所画图形“作品”。验证自己所画和讲师原始图差距有多大？

 

       选择上台的都是沟通能力极强的人事总监等管理人才。结果怎么样？真是每个人画的都不一样，从图形的位置、比例、形状等都有很大的差异。但是那个被选上去去描述图形的同事感觉“已经说的非常清楚了，应该不能有这么大的差异吧”。

       是的，这可能就是沟通、不同的人理解力不同等导致的问题吧。也就是说，每个人对同一件事情的表述形式、言语表达能力、理解能力是不同的。

 

        没有反馈的单项沟通其实是很可怕的，结果不可预知。大家都以为自己说的很清楚了，但由于沟通方式、表述形式、重心把握等的不同，导致听者的思路有可能出现偏差甚至背道而驰。

 

       个人总结：如果上述的沟通在每个关键点，如图形在整张纸的位置、图的大小、拐点等几个细节上与讲者有个互动的反向确认沟通，图的差异就不会那么大。

 

       这也就是自己在项目开发中，时间紧迫、任务繁重的情况下，沟通是很必要的。通过沟通确认任务、要达成的目标、以及如何分解任务等。但是，如果不将这些东西写下来，除非讲者的思路非常明确，除非他以前做过实现过该功能，已经“轻车熟路”，否则，很容易出现偏差。等你过段时间去反馈，你会发现怎么讲者的思路也有变化了，你理解的怎么也有问题了。

 

        相信以下的反馈沟通是必要的：语言沟通(分配任务) -->接收到任务后确立大致的流程，形成简洁的思路文档，思考标注几个可能的核心点 --> 与讲者沟通、就文档核心点确认 -->待确认后（也就是讲者已经认可了听者的思路、方案后）再去实施，动手写代码。

 

       当然这其间可能还有反复，但至少比单项的沟通要好很多，提高的效率不止是一点点。

 

      还有一点，转正后的开发中，会有软件工程里的所有“需求分析-->总体概要设计-->详细设计-->编码-->测试-->维护”等全的过程，作为编程人员，会写概要设计、详细设计的文档，或者会参考别人的文档完成编码，并且上述文档都应该是团队沟通、反馈、协商好的文档方案，可能就不会有上述的弯路。

 

       你遇到过类似的问题吗？你们团队是怎么解决的，有没有好的方法？期待与大家互通沟通下,谢谢！

 

        2013/8/4 am8:07于床上（一直纠结于这个问题，写下来理一理，后续工作会更流畅！）