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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

        2013/8/4 am8:07于床上(一直纠结于这个问题,写下来理一理,后续工作会更流畅!)

©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页