主动发起集中培训，避免时间被切碎

这两天做事的时候，隔三差五的来个开发同学咨询前端页面该如何使用，是不是设计组没有做好？js没法加载进来。开始的几波流，能瞬答的都一一解答或者告诉他们去咨询设计组前端专家，担多次之后，意识到这波的同志的开发能力，和之前磨合完毕的同学们的存在着差距，和组内前端专家一合计完，判断下来，确实是"前端白纸"开发，完全对于前端设计没有概念。

然后设计组内三人一合计，紧急拉了开发的负责人确认。果不其然，如判断一样，开发的同志们对于前端页面使用经验度为"0"，这样的情况下，为了提升设计落地的纯度，同时也为使提高设计组的办公效率，由我们发起，主动去给开发的同学去做集中培训，这样能避免设计组同事的时间被切碎。同时也介绍了之前合作的开发同事加入讲解，希望从开发的角度去给予解读，这样开发同志能够更方便理解背后的逻辑和使用方式。按照以往的经验，这样的强心剂能快速让项目正常运行起来。

用同理心解除误会

问题其实是关于计划中输出件的量和开发同学理解的不一致。开发的同事理解的是A场景中整个工作流的页面包括不同角色的都应输出，而其实按照之前他标记的表中模块落地的优先级中，有一列是关于角色的，可以看到应该是X角色A场景下的页面，现在的输出件种缺少了同一场景中其他角色的页面。

设计组给予解答时候给了两个理由，其一，设计组的输出计划是按照开发这边标记的输出的；其次，新的项目组磨合的时候势必会有些偏差，下次在对页面的时候设计组定会做的更细致，颗粒度核对到什么角色什么场景下什么页面，这样就不会出现偏差。沟通的整个过程都是在一定心平气和的状态下，拜托了初来咋到的莽撞，所以顺利的过渡了。其实哪种状态下，如果你闹着情绪去责怪对方，拿着邮件对峙，虽然确实是开发确认的时候自己没有仔细去看，但是本身研发同学身上的压力也是很大的，结果必然摩擦不断。那这个会议波及的层面会扩大上升，接下来必定会有一顿争吵接踵而来，浪费大把时间。

两则小事，其实主要是想告诫自己也分享给各位同学，各个环节大家有各自的压力，我们要从自己这个环节主动去帮助其他环节的同学去降低压力，能给自己节省大量的时间，提高工作效率，产品的落地质量也能提升，这个方法屡试不爽，还是老话说的好帮助他人其实在帮助自己。