你就掌握了团队协作的效率利器"/>
会用辩证思维法,你就掌握了团队协作的效率利器
我们技术团队在讨论技术方案的时候,经常会有不同的意见,据我观察,75% 的情况下,很多人思考解决方案的角度有待优化,总结下就是没能站在一个正确的角度去运用辩证思维。
举例子:业务系统的代码中有常量,其中有些是平台级的常量,有些是少数系统的公共变量,我们是用 common 包呢, 还是各自写各自的?
答案是什么?老实说我没有标准答案。如果一定要给个结论,那我的结论是:
在不同的阶段、不同的背景下,我们的选择是不同的。
例如一个人维护两个系统的时候,我主张两个系统代码中共用的代码分开写, 各自写各自的,哪怕是完全一样的 DTO 也不要写 common module,因为写 module 增加了代码模块,放项目里简单不用多想,复制粘贴麻烦点, 但是思维清晰,而且符合项目解耦原则,将来有人接手了,也不用特意叮嘱什么, 一切有接口文档约束就好。
再例如每个人维护一个子系统,遇到多数人会用公共变量的时候 , 应由大家坐一起讨论,最终由专人维护比如基础组或者是架构组去维护统一版本。
我一向主张在讨论解决方案的时候,要想说服其他人,那么首先你得先说服自己, 自己把自己辩明白了,跟别人讨论的时候才更有说服力,而且沟通效率高
其实任意一个解决方案一定是有优点有缺点的, 突出自己方案的优点, 贬低别人方案的缺点这对于解决问题是不利的,决定取舍的是我们思考问题的角度而已,假如你把自己放到团队协作的角度上来,如何做到两个团队在物理上不会相互影响?这就有很多点可以去讨论了了, 很多问题在不同的阶段不同的背景下,答案是不同的:
假如你是一个 coder,你可能会想,这样干我的麻烦就多了, 能甩就甩出去,挖坑了也是别人跳(其实有时候挖的坑也会是自己跳),我必需要把我的常量写在 common 里面,这样别人就不用一直来烦我问我了,看代码就能看到。
假如你是一个团队的 leader,你一定会思考这些问题:
迭代效率、版本管理、团队解耦、协作方式 、工作效率、沟通、消除信息屏障等等。
这就是角度的不同。
举个例子:我写了 common 如果没发版,那别人合了项目代码的时候,会拉不到 common 里面的最新变量,然后发版就报错了。再找人发 common ,人家说 common 发了呀,再查哦原来是 common 分支没合又哐哐哐的去合代码,发 common 。万一包仓库还有多个环境,那简直就是悲剧。
总结:辩证思维法、解决方案是阶段性的、效率工具
更多推荐
会用辩证思维法,你就掌握了团队协作的效率利器
发布评论