现状：
- 现在很多的沟通，一直都是以RTX为中心。在RTX上沟通bug,没有mantis,jira等工具——如此，无法统计——无衡量无改进；相同bug重复讨论
- 有流程的问题，在RTX碎片化的沟通——如此，没有流程文档。
当某个人热心写了文档初稿后，用RTX传递，很多文档都很旧无更新了，然后用RTX提示——文档无法协作，彼此有各种版本的文档，彼此冲突不一致，彼此残缺。 - 项目管理在RTX，项目启动，监控，沟通，都是依靠RTX——项目文档无积累，监控沟通在RTX广播式发送，导致群发骚扰，不胜其扰而屏蔽，又导致重要消息无法周知——项目无需求、工作分解、人力管理、风险管理，结项总结，总之，没有组织过程资产。项目完成，只有一堆代码（而代码）
- 一个算法团队，有人偏重算法研究，看论文；有人偏向工程，优化流程。后者，离职留下了代码；但前者离职，没有文档，没有特征分析的记录，没有对算法的思考，没有经验的总结，离职带走了所有东西，只留下一堆参数配置—— 一个人可以走的很快，但走不远，因为无分享团队其他人跟不上，此时，他基本也就开始离职了。然后团队重新再招一个，如此循环。花公司的钱，为其他公司培养人才
- 代码无review，代码无需求文档，代码无测试，交接后的代码基本很难维护，很多项目如此——腐臭代码导致人员长期背负债务，2年左右逐渐陆续离职
分析：
公司运转：人才培养 + 执行力 + 战略
以上低效的沟通，导致团队执行力差；
从下图可看出：
现在沟通是n*n的，沟通复杂度，成本很高：
Paste_Image.png
目标是：不需要沟通，以wiki为中心的沟通。80%的沟通是重复的，只需要一个wiki链接，不需要在沟通：
Paste_Image.png
如何落地：
推动wiki 关键：leader问责制；
方法：不许频繁在RTX重复沟通，以wiki为中心；新人来更新文档；
——简单，粗暴有效，以便快速落地。
解释：
wiki能否提高沟通效率？
将频繁的沟通，这些都沉淀到wiki，例如：流程文档；FAQ
例如：xxx需要找谁；上线模型如何配置；这个bug是什么问题？wiki为何需要leader负责制？
知识库、使用习惯的冷启动问题。
----- 大多没有此习惯，21天可以建立习惯，需要leader快速推动;
----- 没有动力。新人初来，无法写文档；老人已熟，无动力写文档
从wiki系统统计看，两周，wiki更新很少，基本没有
注：代码即文档；bug记录也是文档；
- RTX 沟通会降低沟通效率？
- RTX上碎片化时间；模型上线的RTX沟通很频繁。例如：开uber拉活，但是没有地图导航，总是得问人，影响自己效率；问的还是其他uber司机，影响其他人，将他人的事件也碎片化，影响别人的效率。而wiki记录流程文档，就是地图，自己查即可，不需与他人沟通，不需要停车，继续工作。提高自己效率，提高整体效率。
- 信息不对称的沟通，是低效的沟通。经常收一个问题，先得说名背景信息。非常低效。
- 新人就职，接手效率非常低，无需求文档，代码无注释，全都依赖沟通。离职率高企的情况下，新人接手效率低下，老人被频繁骚扰碎片化。
- 无流程记录，无流程统计，导致TOC瓶颈分析不准。例如：样本生成花费时间长，但是有一周的接驳缓冲，而配置只需要2小时，但是没有接驳缓冲。谁是瓶颈？
- 管理是管理什么？是管理常性问题，对于大概率，经常出现的问题，汇总，统计，找到瓶颈，进行优化。
- 什么才是好的周报？——能促进PDCA的，有跟踪落地
