程序员相互之间的沟通一般发生在项目组内部，可想而知，绝大部分的沟通发生在开发的场景下，这个场景可不仅限于技术讨论，还包括接口讨论，code review，业务讨论，甚至相互不服的撕逼。
发生在程序员之间的沟通场景很多，但我想换个角度归纳一下，大致分为3类：学习场景、合作场景和竞争场景。
-
学习场景
这种情况下，施教的一方需明白自己的目的，是授人以渔还是授人以鱼，二者都是可行，并不见得渔比鱼要高尚，因为在工作中我们得考虑到时间成本。但在沟通过程中，施教者切忌抬高自身优越感，甚至不妨有意的降低姿态，因为学习的沟通，其最本质是让受教一方明白你所讲述的东西，这才对得起花掉的时间不是吗！ -
合作场景
分析问题我习惯从时间成本出发，因为一旦目的清晰后，所用的时间就能反映出参与者的效率。程序员间顺利合作的前提也就是清晰的目的，而获得这个结果往往需要不止一次的沟通，这样一来岂不是时间成本无法控制？其实不然，任何程序员都有面对问题的下意识行为，比如：小王在一个扁平的环境里，他对于合作时出现的问题愿意直接发问；而小赵则会通过自己的方式先尝试收集答案，如若不理想再寻求帮助；小李则不爱交流，更愿意自己把问题弄明白。这三种情况在我们工作经历中都有遇见。我不敢说哪种方式最优，虽然很多团队推荐小赵的做法。但我觉得一切的出发点，可以从目的和时间成本来考虑：如果从独立思考或深入理解方面看，小李可能得到的更多；从快速完成任务，推进项目来说，小王可能有更好的效果。正因为有不同的目的，在合作时处理沟通的方式上没有标准答案，除非团队的目的是清晰的。但我不想这样泛泛地谈论这个问题，我较为推荐的方式是团队成员需要达成一种默契，这种默契也可视为团队文化的一部分，对于复杂问题或者耗时讨论，我们可以在开发周期中固定一个频段进行沟通，比如前后端调试接口放在每天午休之后，这样不至于打断任何一方的开发思路。再比如，程序员下意识的后置开发过程中发现的疑点或问题，将问题向相关人做归纳和集中反馈…… -
竞争场景
这一类情况往往是对于某一技术或实现方式有不同理解，首先要说的是，这是程序员工作中再正常不过的事情，千万不要把这个事情放到“维护面子”的角度，那就走偏了，技术的讨论是一次难得的学习机会，他会将各方的思考角度和路径展现出来，如果大家已经过了学习基础理论的阶段，那么学习思考方式则是更难且更必须的事情。当我们发现讨论到无法收敛时，请及时跳出来，先讲清楚这个事情决定的最终方式（多方都接受），比如：leader出来拍板、举手表决、AB test……总之变着法的将事情向前推进。
在团队中，任何一个成员都应该尽量的扩大团队影响力，这里的影响力并不是指有上令下达的power，而是能让其他人感觉到你可以被依靠，我们可能需要做一些本身跟自己无关的事：主动帮产品分析实现难度，真诚的给予开发人员建议，把产品做的让QA放心……这对你的影响在实施的过程中就能体现。
让人喜欢 || 让人羡慕，我选择前者。
网友评论