以wiki为中心的知识创新 与 沟通管理

现状:

  1. 现在很多的沟通,一直都是以RTX为中心。在RTX上沟通bug,没有mantis,jira等工具——如此,无法统计——无衡量无改进;相同bug重复讨论
  2. 有流程的问题,在RTX碎片化的沟通——如此,没有流程文档。
    当某个人热心写了文档初稿后,用RTX传递,很多文档都很旧无更新了,然后用RTX提示——文档无法协作,彼此有各种版本的文档,彼此冲突不一致,彼此残缺。
  3. 项目管理在RTX,项目启动,监控,沟通,都是依靠RTX——项目文档无积累,监控沟通在RTX广播式发送,导致群发骚扰,不胜其扰而屏蔽,又导致重要消息无法周知——项目无需求、工作分解、人力管理、风险管理,结项总结,总之,没有组织过程资产。项目完成,只有一堆代码(而代码)
  4. 一个算法团队,有人偏重算法研究,看论文;有人偏向工程,优化流程。后者,离职留下了代码;但前者离职,没有文档,没有特征分析的记录,没有对算法的思考,没有经验的总结,离职带走了所有东西,只留下一堆参数配置—— 一个人可以走的很快,但走不远,因为无分享团队其他人跟不上,此时,他基本也就开始离职了。然后团队重新再招一个,如此循环。花公司的钱,为其他公司培养人才
  5. 代码无review,代码无需求文档,代码无测试,交接后的代码基本很难维护,很多项目如此——腐臭代码导致人员长期背负债务,2年左右逐渐陆续离职

分析:

公司运转:人才培养 + 执行力 + 战略
以上低效的沟通,导致团队执行力差;
从下图可看出:

现在沟通是n*n的,沟通复杂度,成本很高:


以wiki为中心的知识创新 与 沟通管理_第1张图片
Paste_Image.png

目标是:不需要沟通,以wiki为中心的沟通。80%的沟通是重复的,只需要一个wiki链接,不需要在沟通:

以wiki为中心的知识创新 与 沟通管理_第2张图片
Paste_Image.png

如何落地:

推动wiki 关键:leader问责制;
方法:不许频繁在RTX重复沟通,以wiki为中心;新人来更新文档;
——简单,粗暴有效,以便快速落地。
解释:

  1. wiki能否提高沟通效率?
    将频繁的沟通,这些都沉淀到wiki,例如:流程文档;FAQ
    例如:xxx需要找谁;上线模型如何配置;这个bug是什么问题?

  2. wiki为何需要leader负责制?
    知识库、使用习惯的冷启动问题。
    ----- 大多没有此习惯,21天可以建立习惯,需要leader快速推动;
    ----- 没有动力。新人初来,无法写文档;老人已熟,无动力写文档
    从wiki系统统计看,两周,wiki更新很少,基本没有

注:代码即文档;bug记录也是文档;


  • RTX 沟通会降低沟通效率?
  1. RTX上碎片化时间;模型上线的RTX沟通很频繁。例如:开uber拉活,但是没有地图导航,总是得问人,影响自己效率;问的还是其他uber司机,影响其他人,将他人的事件也碎片化,影响别人的效率。而wiki记录流程文档,就是地图,自己查即可,不需与他人沟通,不需要停车,继续工作。提高自己效率,提高整体效率。
  2. 信息不对称的沟通,是低效的沟通。经常收一个问题,先得说名背景信息。非常低效。
  3. 新人就职,接手效率非常低,无需求文档,代码无注释,全都依赖沟通。离职率高企的情况下,新人接手效率低下,老人被频繁骚扰碎片化。
  4. 无流程记录,无流程统计,导致TOC瓶颈分析不准。例如:样本生成花费时间长,但是有一周的接驳缓冲,而配置只需要2小时,但是没有接驳缓冲。谁是瓶颈?

  • 管理是管理什么?是管理常性问题,对于大概率,经常出现的问题,汇总,统计,找到瓶颈,进行优化。
  • 什么才是好的周报?——能促进PDCA的,有跟踪落地

你可能感兴趣的:(以wiki为中心的知识创新 与 沟通管理)