知识管理——如何做好软件团队的知识资产化

软件开发的困难

  • 质量要求高:
    • 汽车ECU对软件的质量要求非常高,因为召回成本非常高。召回成本大约是产品售价的3倍。而在生产过程中出现软件质量问题,对客户的赔款也是按分钟计算的。
  • 成本要求低:
    • 价格越来越低,功能越来越多
  • 人员流动大:
    • 一款产品通常开发周期为两年,软件、软件测试、软件质量参与人员10到15人,而人员流动性比较大,几乎没有一个项目是能够至始至终没有换人。
  • 知识密集型:
    • 一款汽车空调的软件开发需要涉及以下知识:
      • 基于Matlab建模的空调舒适度算法开发
      • 基于Matlab建模的嵌入式控制系统软件开发
      • 基于XCP协议的算法在线标定
      • 人机交互逻辑设计
      • 按键,旋钮输入检测
      • LCD段码显示屏控制
      • CAN总线通信
      • LIN总线通信
      • SPI总线通信
      • 车身在线诊断
      • 嵌入式实时操作系统
      • NVM数据存储
      • 直流电机,步进电机控制
      • PWM输出控制,输入检测
      • 单片机底层控制
      • Bootloader技术
      • 软件需求分析,架构设计,编码与单元测试,集成测试,动态架构验证,静态代码分析,可靠性验证,配置管理,持续集成,自动化测试

我们如何应对这些困难

  • 强化过程管控
  • 模块化和标准化
  • 稳定专家型人才
  • 知识资产化

我们的知识资产化故事

LLC

2014年刚刚加入这个团队,在正式开始开发工作前,公司给我组织了两个星期的技术培训。培训的内容主要是软件开发流程,开发方法,软件设计规则,软件质量管控等。当时对这些培训也没有完全吃透,但是后来发现这些培训还是很有用的。

那时候,我们正在为某个OEM准备一款产品的首次交样,要求不高,有基本的CAN通信,马达能动,鼓风机能转,就行。样件递交给客户后,反馈鼓风机调到最大档位时风速反而最小,调到最小档位时风速反而最大。

因为是第一版递交,有问题压力也不是很大,而且是必现的问题,容易排查。拿上工具,去客户现场测试ECU和鼓风机的输出,问题很快就解决了。

问题解决后,领导安排了个任务,要求分析root cause,写Lessons Learned。 root cause,这个词此后就成了我工作中的高频词汇。

这里的root cause不只是说我们代码哪里错了,而是为什么会错,是客户提供的鼓风机参数错了,还是硬件团队提供的硬件规格错了,还是我们工程师小手一抖写错了,还是我们没有看输入文档?这个分析也很简单,输入都没有错,也不是粗心,是我们理解错了。

到这里完了吗?还没完。继续追问,为什么工程师会理解错?这里有两次取反,逻辑上确实有点绕,容易出错。

到这里完了吗?还没。继续追问,错误为什么没有被发现?代码评审没有做。为什么不做代码评审?没有重视这个流程。那错误为什么没有被测试发现?开发人员自己测了,但是理解是错误的,所有没发现问题;测试人员早期的测试案例还没有完成;还没有获得客户的外围设备,无法用实际负载进行测试。

root cause 清楚了。到这里完了吗?还没有!

那么我们学到了什么?

  1. 需要提高大家对流程的重视程度,软件项目经理要严格执行开发流程;
  2. 对外围硬件接口按模块给新入组的同事进行培训;
  3. 测试团队和开发团队的协作不同步,需要调查第一版开发baseline
  4. 尽早安排真实负载

这样的 Lessons Learned 活动随时都可以出现,可以是因为软件bug,可以是因为递交延迟,也可以是因为over budget。而一次 Lessons Learned 的结果可能是改善管理,可能是完成流程,可能是完善检查清单,也可能是强化大家的意识。

检查清单

随着参与的开发越来越多,我发现了一类很重要的文档:Check List。Check List 以各种形式存在于我们软件开发的每个工序。譬如:

  • 项目报价
  • 项目计划
  • 需求分析
  • 架构设计
  • 模块设计
  • 代码编写(静态代码检查)
  • 单元测试
  • 集成测试
  • 验证测试
  • 功能测试
  • 软件递交

打开检查清单,你会发现很多检查项,每个检查项都是一个问句,而且这些文件是在从不同角度提出问题,你需要回答这个检查项是否使用于你的项目,你是怎么处理检查项中提出的问题。

譬如,对于软件项目报价,会有这样的问题:

软件项目团队组织架构定义了吗? 相关的约束条件考虑在预算评估里了吗?考虑了组织架构的复杂程度了吗?

可能你会有疑问,项目报价为什么要考虑这些,这有必要吗。一开始我也是这么想的。

注意,当你说“有必要吗”的时候,实际上你是在说你不打算做这个。

但当我负责软件团队管理后,我觉得考虑这些都是很自然的。为什么?

  1. 如果我们没有定义团队组织架构,我们就不知道拿到项目后有没有足够的人力去做项目,要不要提前招聘人力,要不要协调其他研发中心的人力资源。
  2. 虽然定义了组织架构,但是多site开发的组织复杂度有没有考虑进去呢?譬如武汉团队刚刚成立,项目由深圳团队主导,任务分配和跟踪怎么做?最好让武汉同事来深圳和深圳同事一起开发一段时间,相关的差旅费也要考虑到项目报价中。

检查清单最大的好处是能够直接指导我们的工作,清晰定义了我们工作输出应该达到的标准,让我知道事情该做成什么样。

所以, 检查清单既应该在你动手做之前用:知道你要去哪里;也应该在过程中用:知道你在哪里;还应该在你认为做好了用:达到目标了没有。

检查清单看起来都是问你有没有按照要求做某事,而实际上它背后就是知识的积累。

检查清单的作用是把摸不着的知识转化为清晰的可执行的动作。

专家评审

检查清单虽好,但是我get不到检查项的要点怎么办?

光有《圣经》还不够,还需要有给教众解释《圣经》的人。

同样,我们需要专家评审,确保我们正确理解了检查清单,正确按照检查清单的要求执行了。

所以,当我们做完每一个工序,对照检查清单,认为自己已经把事情做好了的时候,我们可以邀请同行专家进行评审。

小结:多样化的知识资产化活动和知识资产化的载体

知识资产化活动 知识资产化的载体
知识体系化 流程文档,作业指导书,培训课程, 经验学习卡,检查清单
知识传播 培训培训,技术笔记,技术分享
知识运用 检查清单,同行评审
知识更新 经验学习卡,检查清单,流程文档,作业指导书,培训课程

如何实现知识资产化

精神基础

  • 开放的团队氛围,对事不对人 => 让大家消除被否定的疑虑
  • 允许犯错,首先关注根本原因,重点关注如何改善(避免再次发生)=> 形成包容的团队氛围,让大家勇于公布问题,勇于就问题分享分析和总结 (这个问题很基础,我分享出来是不是会被大家笑话。每个人都有自己擅长的地方。)
  • 合适的工作量 => 学而不思则罔(要低头拉车抬头看路,还要坐下来思考),就像Google等大公司给员工创新时间一样,要给员工留有总结的时间(譬如周末)
  • 热爱工作,热爱分享的核心成员 => 种子选手

物质基础

  • 基础的团队协作工具:所有人能在同一个地方拿到所有知识文档
  • 统一的沟通语言:所有人都知道ta需要的知识应该在哪个文档中找

制度基础

  • 教会徒弟饿死师傅?
    • 师傅有没有向上成长的空间?
    • 能否对知识进行过程化拆分?
    • 利益分配上师傅和徒弟是否可以绑定?
  • 公司的薪酬是否合理,晋升通道是否畅通留下难以维护的代码,公司离不开这个人,关键时刻要挟老板涨薪
  • 组织标准化委员会,负责标准化和文档编写、审核
  • 设立内部讲师制度和专家制度

行动

  • 改造思想:思想 => 行动 => 结果
    • 讲重要性:一个人强还是一群人强
    • 讲好处:教学相长,锻炼沟通表达,提升成就感,提升在团队中的影响力,增进团队之间的相互了解
  • 改造行动
    • 督促团队思考总结并形成书面输出
    • 鼓励各种类型的分享
    • 鼓励对技术细节的思考和探索
    • 定义固定周期的分享会议,并保证按周期举行,养成习惯
    • 考虑不同形式的分享,让大家轻松就可以尝试
      • 比较轻松的,十五分钟到一个小时,直接拿工作内容来分享;
    • 帮助把控分享的质量,保证团队体验
      • 比较正式的,需要单独归纳总结形成PPT;

发表评论

电子邮件地址不会被公开。 必填项已用*标注