专栏首页QB杂货铺公司内部技术积累的一些思考

公司内部技术积累的一些思考

围绕一个模块一个主题,准备材料,做一场专门的完整的培训或分享,是很有用的。其视频和文档也是重要的技术积累。此处主要想讨论的是,对日常研发过程的零碎问题和解决手段的积累,没有那么完整和重量级,但确实很难做好。

现状

问题一:很多问题没有积累。

很多小问题是大家习惯直接找到对应的负责人解决。对这个具体问题来说,当面沟通确实是最高效的,但没有形成积累,只有直接参与这个问题的人知道问题的存在和解法。一旦人员调动就没人知道了,或者时间久了连参与者自己都忘了。 当然,问题本身是否需要被记录,也是需要评判的。有些问题,确实参考意义不大。

问题二:有积累的问题过于简单

内部的研发系统上,很多问题,只有问题和简单的解决结果。对客户的系统好一点点,会有跟客户的一些交互,对客户的解释也会更加完整清晰一些,但基本也是停留在结果上。对客户是足够了,但对内部其他人员的借鉴学习,我觉得还是不够的。

问题三:不够开放

不同部门各自有积累,但未能互联互通。今年公司也在做一些这方面的工作,统一平台,加强知识库建设,希望能真正起作用。

好的例子

看到做的最好的,是以前遗留下来的一些问题解决的总结文档,会描述问题的现象,复现方式,然后进行初步分析,制定方案对可能的原因进行逐一排查,完整地写出解决的思路,用到的工具和方法。一步步逼近根本原因,最后才得出结论。看这种文档,除了学到一个知识点,更多的是学到了一些思路和方法。相当于别人手把手教你解问题,你会发现,哦,还能这么干,长见识了。下次你可能碰到的是一个完全不同的问题,但思路和方法是可以借鉴的。正所谓授人以鱼不如授人以渔,直接丢出一个问题和结果,那就只是一个知识点,读者完全不知道如何从问题自行推导出结果,但如果写出从问题到结果的过程,包括其中走的弯路,那对读者来说,就是又掌握了一种解决问题的方法。前人花十天半月解决的问题,一篇文档就掌握了重要部分,再举一反三,水平自然能迅速提高。 可惜这种文档太少了,而且写一篇也不容易,估计只有疑难杂症或重要项目才能享有如此待遇。

个人实践

知识总结放wiki

当他人问问题时,判断下是否是共性问题,是否其他人也会再问类似的问题。如果是共性的问题,且没有现成的说明文档,那么此时比起直接给对方解释清楚,更好的做法是,先在wiki上形成一个简单的说明。再将这个链接发给对方。如果对方还有不明白的,再直接沟通,沟通清楚后,再针对刚刚沟通的内容,整理整合到wiki上,如此重复,不断修改完善。等到这份文档确实够完整清晰,再有其他人需要的时候,就可以一个链接搞定,无需多费口舌,节约了大家的时间。

问题解决放论坛

搭建了一个部门内部论坛,用于记录问题和解决方式。原本的期望是,每个问题报出来就可开一帖,描述问题,不要等到问题被解决掉再总结,而是随着问题的进展,不停跟帖更新,直播解bug过程。中途其他人也可以给出意见建议。

实践效果

效果是wiki很有用,总结过的问题,有人问的话,发个链接就可以解决。论坛的话,对个人回溯问题很有用,但没有达到设想中的交互作用,仅作为另一种记录问题的方式。且个人执行程度也不高,很多问题并没有发到论坛上。

几点思考

素材收集

要形成总结,我觉得首先需要能把素材积累下来。一个问题解决完毕后,很多中间的log,测试数据,问题现象是没有保存和截图的,且关联的材料可能散布在邮件,聊天记录,口头交流等。巧妇难为无米之炊。如果要在总结文档中说清楚,那收集材料都是个问题,甚至必须重新做一遍测试。如果能让大家在解决问题的过程中,方便快捷地把所有的分析和尝试(包括无效的尝试),以及关联的材料(如问题描述,邮件往来,钉钉/微信记录)都记录下来。那起码有了一份原始记录。 一个设想是,设立一个公共邮箱,对于某个问题的邮件全部抄送该邮箱,那么,即使没有后续的进一步整理总结,其中的信息也有很大的价值。在其中搜索到关键信息,看看邮件往来,可能就能搞定一个问题,避免重复开发,重复解bug。

引入交互

最好能有交互,反馈,完善补充。有些问题和解决思路方法,你记录下来的时候,可能自己觉得讲得很明白了,但别人看到就不一定了。如果能有人在这个过程中积极参与讨论,提出疑问和建议作为反馈,那么对于这个问题的解决和后续其他人的借鉴,都会很有意义。脑补下大概类似于开源社区的邮件列表,或者技术论坛上的讨论帖,或者博客下方的一些留言探讨。

积极性

首先机制肯定是要有的,各种研发管理系统能解决部分问题,完善的流程,起码保证问题和解决方式被记录下来。但如果大家只是完成任务,那么内容肯定质量高不到哪里去,容易流于形式。如何调动大家的分享的积极性,这才是最大的问题。要打造良好的团队技术氛围,让大家都愿意分享,习惯分享和讨论。如果能引入一些激励,那就更好了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 日常开发技巧:x11-forward,使用远程机器的gui程序

    日常用过ssh登录服务器进行工作,尽管大部分时间,都只需要终端操作,编辑源码也是vim就够用了。

    zqb_all
  • 【swupdate文档 一】嵌入式系统的软件管理

    嵌入式系统变得越来越复杂, 它们的软件也反映了这种复杂性的增加。 为了支持新的特性和修复,很有必要让嵌入式系统上的软件 能够以绝对可靠的方式更新。 在基于...

    zqb_all
  • 记一个bootloader的cache问题

    最近往一个armv7板子的bootloader中移植了解压算法,移植本身还比较顺利,但移植完了发现,功能是正常的,但效率大打折扣。解压同样的数据,耗时大约是ub...

    zqb_all
  • 读《麦肯锡工作法》有感:4个步骤高效解决问题

    在我们的身边,每天都会遇到很多问题。“工作不顺利”、“上级制定的KPI无法完成”、“上司不同意自己的提案”等等。

    1480
  • Android程序员的救赎之路(二)

    上回说到要举一个例子来说明,在看例子前,我们先来说说问题,有时我们会在工作中遇到很难的专业问题,如设计一个业务算法或用OpenGL做3D特效,这类的问题虽然不简...

    企鹅号小编
  • 架构漫谈(三):如何做好架构之识别问题

    按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决了80%了。这个能力基本上就决定了架构师的水...

    Java高级架构
  • 【转】架构漫谈(三):如何做好架构之识别问题

    按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平...

    YG
  • 笔记与随想 — 解决问题

    捷义
  • 一件运维小事的祸根

    今天处理了一个PostgreSQL的复制异常问题,但是限于时间和精力情况,尝试了个把小时,就直接重做了从库,问题迎刃而解,看似是一件小事,其实这是一个祸根。

    jeanron100
  • 问问题也是需要技巧的, 别让回答者 "太难了"

    被问问题是经常的事情, 但有些问题是在是让人想起一个著名的包子品牌, 具体是那个,估计中国人都知道,那个是一个坑.

    AustinDatabases

扫码关注云+社区

领取腾讯云代金券