本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客
1、方法主题
描述了一个在开发项目中,提高沟通效率的方法,该方法以减少沟通内容为主。使用者是组织或参与项目开发的人,作用是提高沟通效率
2、适用场景
适用于项目方向明确,主要成员是研发人员,且沟通的目的是“为了保障项目顺利落地”
3、解题方法
3.1、首先减少需要沟通的场景。“不需要沟通才是最高效的沟通”。在架构设计阶段,减少需要关联的模块,就减少了开发内容的耦合,也就减少了沟通。实践中,如果每个服务都是一个人开发,那图1的沟通关系就有4对,而图2只有3对。越少的沟通,意味着越高的开发效率,特别是涉及到跨部门,甚至公司沟通时
图1
图2
3.2、在必须沟通的场景,沟通前明确沟通的背景和限制条件,从而减少不必要的沟通内容。项目相关会议讨论的时候,讨论目标“服务1如何能够低延迟”是模糊且复杂的,讨论目标“服务1在计算资源为32核CPU,需求为平均返回延迟2ms,top99 5ms,单个请求的计算时间需要在多少ms内”是简单且清晰的。也就是说要减少沟通内容,需要拆分沟通内容,并对背景条件有明确的定义,将具体问题量化。拆分清晰的程度,取决于会议组织者对该问题的认知
3.3、不要忽略向上沟通。我对参与项目的人员角色进行如下图拆分,以A1项目一号位为例子,A1除了负责自己的子项目,它也是A的子节点,A1需要及时同步自己项目进度,风险,并理解A项目的变化。否则,如果需要A高频向A1轮询进度和风险,那必然会增加无效沟通的内容:
图3
3.4、对影响面广的单点问题的沟通需要花大量的精力,甚至可以“啰嗦”一点。如项目的量化目标,模块间接口,架构逻辑。以得到大家认知相同的统一结论。这里有几点需要注意:
- 沟通效率也取决于个人业务能力,如两个绘画专业的人,来讨论内存占用阈值1G还是10G,必然是低效的。所以项目一号位,要选择参与沟通的人,而不是每个问题都拉上所有人沟通。我就遇到过一个项目负责人,所有的会都尽量拉上所有人,浪费了特别多的不需要参加讨论的人的时间。根本原因就是负责人水平不够,对项目没有深入思考,总是想着依赖别人解决自己的问题,最终的结果是既浪费了大家的时间,也减少了大家对其项目支持的热情和信心
- 沟通不应过于限于细节,满足业务要求的解是一个范围,不是一个不可撼动的精准值,如花时间讨论阈值是1G,还是0.999G,大概率是在浪费时间
- 在接口讨论时,除了详细的接口描述,有实际的demo数据来确保大家理解一致,也能减少后期返工成本
4、方法的局限
- 仅适用于大方向确定的场景下的项目管理。不适用于讨论新方向、复盘,或者头脑风暴等等
- 此方法聚焦在沟通内容的取舍,不讨论高效沟通的具体方式的选择,如口述、文本、图像、视屏等