|
围绕一个模块一个主题,准备材料,做一场专门的完整的培训或分享,是很有用的。其视频和文档也是重要的技术积累。此处主要想讨论的是,对日常研发过程的零碎问题和解决手段的积累,没有那么完整和重量级,但确实很难做好。
现状
问题一:很多问题没有积累。
很多小问题是大家习惯直接找到对应的负责人解决。对这个具体问题来说,当面沟通确实是最高效的,但没有形成积累,只有直接参与这个问题的人知道问题的存在和解法。一旦人员调动就没人知道了,或者时间久了连参与者自己都忘了。
当然,问题本身是否需要被记录,也是需要评判的。有些问题,确实参考意义不大。
问题二:有积累的问题过于简单
内部的研发系统上,很多问题,只有问题和简单的解决结果。对客户的系统好一点点,会有跟客户的一些交互,对客户的解释也会更加完整清晰一些,但基本也是停留在结果上。对客户是足够了,但对内部其他人员的借鉴学习,我觉得还是不够的。
问题三:不够开放
不同部门各自有积累,但未能互联互通。今年公司也在做一些这方面的工作,统一平台,加强知识库建设,希望能真正起作用。
好的例子
看到做的最好的,是以前遗留下来的一些问题解决的总结文档,会描述问题的现象,复现方式,然后进行初步分析,制定方案对可能的原因进行逐一排查,完整地写出解决的思路,用到的工具和方法。一步步逼近根本原因,最后才得出结论。看这种文档,除了学到一个知识点,更多的是学到了一些思路和方法。相当于别人手把手教你解问题,你会发现,哦,还能这么干,长见识了。下次你可能碰到的是一个完全不同的问题,但思路和方法是可以借鉴的。正所谓授人以鱼不如授人以渔,直接丢出一个问题和结果,那就只是一个知识点,读者完全不知道如何从问题自行推导出结果,但如果写出从问题到结果的过程,包括其中走的弯路,那对读者来说,就是又掌握了一种解决问题的方法。前人花十天半月解决的问题,一篇文档就掌握了重要部分,再举一反三,水平自然能迅速提高。
可惜这种文档太少了,而且写一篇也不容易,估计只有疑难杂症或重要项目才能享有如此待遇。
个人实践
知识总结放wiki
当他人问问题时,判断下是否是共性问题,是否其他人也会再问类似的问题。如果是共性的问题,且没有现成的说明文档,那么此时比起直接给对方解释清楚,更好的做法是,先在wiki上形成一个简单的说明。再将这个链接发给对方。如果对方还有不明白的,再直接沟通,沟通清楚后,再针对刚刚沟通的内容,整理整合到wiki上,如此重复,不断修改完善。等到这份文档确实够完整清晰,再有其他人需要的时候,就可以一个链接搞定,无需多费口舌,节约了大家的时间。
问题解决放论坛
搭建了一个部门内部论坛,用于记录问题和解决方式。原本的期望是,每个问题报出来就可开一帖,描述问题,不要等到问题被解决掉再总结,而是随着问题的进展,不停跟帖更新,直播解bug过程。中途其他人也可以给出意见建议。
实践效果
效果是wiki很有用,总结过的问题,有人问的话,发个链接就可以解决。论坛的话,对个人回溯问题很有用,但没有达到设想中的交互作用,仅作为另一种记录问题的方式。且个人执行程度也不高,很多问题并没有发到论坛上。
几点思考
素材收集
要形成总结,我觉得首先需要能把素材积累下来。一个问题解决完毕后,很多中间的log,测试数据,问题现象是没有保存和截图的,且关联的材料可能散布在邮件,聊天记录,口头交流等。巧妇难为无米之炊。如果要在总结文档中说清楚,那收集材料都是个问题,甚至必须重新做一遍测试。如果能让大家在解决问题的过程中,方便快捷地把所有的分析和尝试(包括无效的尝试),以及关联的材料(如问题描述,邮件往来,钉钉/微信记录)都记录下来。那起码有了一份原始记录。
一个设想是,设立一个公共邮箱,对于某个问题的邮件全部抄送该邮箱,那么,即使没有后续的进一步整理总结,其中的信息也有很大的价值。在其中搜索到关键信息,看看邮件往来,可能就能搞定一个问题,避免重复开发,重复解bug。
引入交互
最好能有交互,反馈,完善补充。有些问题和解决思路方法,你记录下来的时候,可能自己觉得讲得很明白了,但别人看到就不一定了。如果能有人在这个过程中积极参与讨论,提出疑问和建议作为反馈,那么对于这个问题的解决和后续其他人的借鉴,都会很有意义。脑补下大概类似于开源社区的邮件列表,或者技术论坛上的讨论帖,或者博客下方的一些留言探讨。
积极性
首先机制肯定是要有的,各种研发管理系统能解决部分问题,完善的流程,起码保证问题和解决方式被记录下来。但如果大家只是完成任务,那么内容肯定质量高不到哪里去,容易流于形式。如何调动大家的分享的积极性,这才是最大的问题。要打造良好的团队技术氛围,让大家都愿意分享,习惯分享和讨论。如果能引入一些激励,那就更好了。
|
|