鲁达 单兵作战只能胜任分发到自己的模块,团队协作才能让产品快速而高质量上线.
有正必有反
想要提升团队协作的效率,先分析哪些事物阻碍了开发进度.
一般情况下,项目预估的时间相对的紧凑,如果发挥正常,则上线时间不会相差太远,中途有什么变化,也会根据反馈实时调整进度.
但有时候,代码能够稳定的发挥其固定的作用,人就不一定了,不同的行为会导致差别极大的影响.
负面作用
全局干扰
最近的一个项目中,进入到提测阶段的时候,一些新版的功能都已经通过第一轮测试.
但是在代码没有改动的情况下,测试忽然提出了一堆的bug,一些以前的功能部分都不能正常使用了.
请注意,一旦遇到类似的情况,几乎没有改动主要功能代码的前提下,忽然发生大面积的bug,于前端而言,不是后台挂了,就是某个兼容性问题,特定手机机型或者系统版本等.
还有一种不应该发生的错误,就是团队的其他分支代码影响到整个项目的全局,从而导致你的功能异常,如css样式覆盖,js变量覆盖等操作.
现在回顾一下,当时我的操作是先排查功能异常的原因,发现是vuex和vue-router传参parmas失效,但是为什么莫名失效,google了好久,定位到怀疑人生.
由于之前已经有过协作导致错误类似的经验,加上对自己代码机制还残留一点点信心(技术的熟练度决定排查问题的思维和方式),转而开始查看gitlab的日志记录
在查看同事的日志中,发现一段才提交不久的代码,这段代码的定义就是在全局路由做了一些操作.
在这里,我也犯了一个错误,看到对方的注释写的是仅在第一次登录xxx,然后就没有往下看代码的作用了,然后又开始怀疑人生.
当时间耗时超过半小时后,就应该想办法解决当下无法解决的问题,和同事交流或者稍稍放松,换个思维方式等,当排查超过一个小时,于是去问了同事.
同事说前不久是在ios上进行了全局操作,因为需要开发一个新功能,所以在ios上每次页面切换时,把vuex和vue-router传参parmas给重置了.
在这里,先不提排查和定位问题的能力,只能提醒在座的各位,如果明知道自己的代码会对全局有着影响甚至是颠覆的作用,请一定要在群里声明,或者至少和同事口头声明.
当然,尽可能不要产生对全局不可控的代码,没有谁能保证自己的代码不会对以前的功能或者同事的模块造成影响,解耦是一种能力,声明是一种态度,也是协作的方式.
tips:
有一些团队会进行codeReview,一个是提交时review,一个是提交后review.
不论哪一种,都是对代码的质量负责,像上述这种错误,如果进行了review,在发布测试前就会被发现和拦截,这种错误不应当出现.
团队没有review的流程,也没关系,大多数时候不要养成别人定了规则才会去执行的习惯,一定要有自己的独立思维,要有自己的优秀习惯,团队没有,但是不妨碍自己定期的review.
前几期讲了提升效率的方法和技巧还可以加上一条,加班时或者定期review,及时看看自己的代码和同事的代码,查漏补缺.
协作时间
前一段时间,测试在没有任何告知的情况下,周六加班冒烟测试,前后端的都不加班,也不知道要测试.
于是产生了几个严重的影响,同样也是人为的不该犯的问题.
一是由于没有邮件或者群里正式声明周六提测,导致前端没有发布最新的测试版本,周六测试的是上上个不知道什么时候打包的版本.
这种情况几乎可以说测试是白测了,所幸测试的版本恰好功能上都符合,只有一些样式没有跟上进度,所以没有造成极大的时间浪费,影响不大.
二是正常工作期间,前后端每次发版的时候,很少有人会主动在群里提起或者正式邮件声明(虽然有时候不需要太正式)
导致测试测着侧着就提示网络错误,或者用旧的标准在测试新的代码(如忽然改一个新需求和ui,但是测试不知道),导致提出bug或者被中断测试流程(如下单)
其实在发版前群里告知一下是基本的沟通义务,也是最起码的工作态度,就效率而言,能避免很多不应该出现的问题,仅仅是一句话的事情.
其次,与人方便也是为自己方便,发版时也可以注明当前版本,发布内容(更新了哪些功能等),以及一些其他说明,让事物有据可查,有别人更容易理解.
但是在好几家公司发现,不论是刚入职的小白,还是混久的老油条,都不会去过多的关注一些团队和沟通的细节,或者说懒得操作,宁愿事后甩锅也不愿事前留心.
tips:
国内没有倾向于使用邮件的习惯,即使是重度有工作属性的职场.
如果不强制要求,别说邮件了,连聊天软件都懒得回复,如非需要,甚至口头内容都不会有.
建议大家多使用邮件,最少也应该使用有聊天记录的群或者沟通工具.
其实说到底,首先是一个工作态度的问题,愿不愿意协作和配合,其次才是工具的使用.
其次,要注意的事,最好的工作时间是全员都在的时候,有问题一定要及时处理.
不可能等到别人下班再去解决,这样也解决不了,事情要分轻重疾缓.(很重要,思维方式)
建议上班的时候解决要和人协作的问题,个人不太紧急和重要的问题可以留到临近下班或者加班或者解决合作问题之后.
权限问题
测试的过程常常需要反复去操作一个流程.
但是一个流程往往操作后就固定了数据状态,再次操作不可能再创建一个账户或者每次叫后台清空数据(仅前端).
虽然假数据也可以,但是有些逻辑仍然需要真实的反馈,如登录,短信验证,身份识别,提交订单等等等.
一般开发,有本地环境,测试环境,正式环境,至少在本地环境和测试环境,数据是可以临时操作的.
如果有管理后台建议获取操作测试环境后台面板,针对自己开发的模块做一些流程设定操作,如更改用户状态等.
如果没有管理后台,使用sql等直接操作数据库也行(前提是要会一点点数据库和对表结构了解~具体可以问后端)
前提是避免一个功能测试需要很多遍,但每次都要找别人来重置数据,别人也可能一直在忙,没有时间帮忙或者留意到你的需要.
其次是,直接操作数据库是一个很大权限的事物,哪怕只是本地环境,一定要尽可能避免产生脏数据,影响其他流程.
有的时候需要去复现一个bug,必须走完一些流程,操作繁琐且很难定位,通过后台和修改数据库会快很多.
总的来说,就是测试有的权限,你尽量也要有,如管理后台,数据库等,没有,就只能让相关模块的人尽量配合.
避免有时间但是流程卡住无法操作的情况,这种现象是真正的极大浪费时间,而且一废就是大半天.
tips:
当然还会有一些其他权限,如代码合并的权限,发布测试和线上的权限.
这就涉及到技术和态度意外的因素,要留心那些你有时间有技术但是你无法操作的事物.
正面作用
正面的方法可以简单概括为
- 分工合理,责任明确,模块化
- 高效的沟通机制(聊天软件,任务面板,邮件等)
- 定期检查,及时调整(codeReview,日报,周报,大小会议)
比起正面作用,更倾向于排除负面作用,哪怕正面作用不大,但至少不会影响效率和进度.
要知道吖,大大小小的公司,其实最混乱的,最致命的,也最为核心的.
从来不是技术和能力,而是团队管理和协作,是人与人之间的沟通和行为.
tips:
正面作用下一期文章再细说.