我是一名从事互联网的工程师，主要工作内容为: 研发管理、产品原型图、系统架构设计。

所属团队负责公司内部「研发测试流程」相关产品。我在团队中兼具「产品经理」「架构师」「Scrum Master」三个角色。

在此我分享工作中得益于信息论的知识点，分别从向上申请资源、技术选型、我曾经在系统设计中犯的错误进行描述。

向上申请资源

由于是研发测试流程产品，多数想法来自我与研发团队。我需要将团队的想法「编码&压缩」为「产品原型图&投入与产出价值表」汇总成Confluence文档。

通过「图形、文字、语言」的方式进行沟通，上级常常能快速准确理解团队意图、产品价值、投入人力。而不是白话描述“我有个想法 …… 您觉得如何?”。

(当然也能快速准确的发现其中的问题，信息中的缺陷并不能通过编码掩盖)

从信息论解释

  1. 将产品想法汇总输出产品原型图文档，可称之为：编码&压缩。
  2. 图文并貌沟通顺利，是因为文档精简后，适当去掉冗余的信息，并利用「视觉、听觉」两条信道传输，因此更有效率，接收更快。
  3. 上级可根据「产品原型图-视觉信息」「语言描述-听觉信息」两个维度交叉校验自己是否理解准确，也更容易理解。

技术选型

  1. 技术资料首先必须通过官方网站获取（信息源），避免中间人传播时引入「噪音」或「失真」影响判断甚至误导。
  2. 技术官方文档介绍都称自己是高性能、高可用、简洁优雅的。但选型时需考虑「使用场景」以及「文档时间」（信息是有上下文和时效性的）
  3. 同时从多个维度比较不同的技术方案。如：Github活跃度、Google Search 查看讨论文章、Google Trends 查看趋势使用占比、技术评审从多个维度验证技术选型是否正确。数据需要参照对比才有意义。

从信息论解释

  1. 获取信息时，需从信息源（官方）获取，避免传播过程中被引入噪音或失真，导致解读错误。
  2. 信息是有上下文的（使用场景），是具备时效性的，过期的信息等于无效信息。
  3. 从信息源获取（官方）能保证信息不失真，但完整的信息不一定正确或最优，所以需要对比多个方案，多维度交叉校验信息。
  4. 技术类官方文档通常是英文编码，英文解码能力越强，接收就会很顺畅。

我曾经系统设计中犯的错误

我曾经试图用一张设计图描述全部系统设计，当时我认为一张图“简洁”，所以就将：「系统之间轮廓」「各系统业务模块」「各系统依赖中间件」「技术细节」尽量合并成一张设计图。 在讲解过程中，每个工程师疑问点常常不一样，并且「提问顺序」与我「讲解顺序」不一致，是乱序的，容易打乱思路（小王先问技术细节、小张再问系统之间轮廓、小李最后问业务模块）。虽然讲解结束后，工程师们都表示理解了，可能因为想着可以通过文档回顾。但是在后续工作进行中，仍会丢失一些「信息细节」导致反复沟通或返工。

这其实是我违背了香农第二定律「试图将超过工程师带宽的信息，一次性打包全部传输」。信息接收过程中有疑问（接收人局部信息错误）需要不断解答纠错。意识到这个问题后，我将合并的设计图，自顶向下拆分为多张，以循序渐进的方式组织。在后续的讲解中发现工程师们的疑问明显少了很多，工作进展也比较顺利。

当时我总结为：永远不要用一张图描述过多内容，若内容太多，就需要自顶向下拆分，循序渐进组织。否则不容易理解。

从信息论解释

  1. 人的「信道容量」是有限的，一次性打包传输全部信息，传输过程中就容易出错（提出疑问），信息错误需要纠错（解答疑问）。即便信息被编码压缩成「图形、文字、语音」文档，一次性传输信息量仍然超过「信道容量」，由于没有其他可用的信道（视觉、听觉已占用），唯一办法就拆分整块信息，降低传输率。

  2. 在全部合并的设计图上讲解「系统之间轮廓」职责时，图上的其他内容「各系统业务模块」「技术中间件」「技术细节」的内容其实是噪音，会对工程师视觉信道造成干扰，视线不聚焦，给工程师提供了乱序提问的“机会”。

  3. 面向不同的角色传播信息时，需要进行不同的编码，这样接收方解码才更容易理解。上级偏向投入产出比多一点，工程师偏向技术实现多一点。

  4. 我本人其实也是一条「上级」与「工程师」之间的信道。兼具「产品思维」和「研发技术」编解码能力，由于没有产品思维与研发思维之间断层阻碍，研发团队效率自然就会很高。

心得总结

  1. 从信息源（官方）获取原始信息，避免中间人传播过程中的引入噪音或失真。
  2. 信息源仅能保证信息完整，不能保证正确，需要通过多维度交叉校验。
  3. 传播信息时，信息量过大就需要拆分，当听众“乱序提问”时，就得注意编码方式是否与听众对齐、信息量是否过大、是否具备连贯性，如:自顶向下。
  4. 若想获取更多信息，就需“培养”建立多个信道。
  5. 信道过多，信息量较大，个人解码能力恐怕不够。需要借助值得信任的人和工具进行过滤和解读，这样能事半功倍。如吴军老师、得到App、Google Search

除了信息论，系统论、控制论对工程师也有很大帮助。

系统论

让我从整体去考虑问题。在做系统优化时会考虑整个系统生态，而非局部某个系统或某个功能最优。诉话说钱要花在刀刃上，最短木桶理论。其实都属于系统论范畴。

配合吴军老师在《谷歌方法论》中讲解的阿姆达尔公式，可量化单个系统性能提升倍数，对于整体提升占比。若将各部门看成一个子系统，又可量化单个部门效率提升倍数，对于公司整体提升占比。若将省份看成子系统，又可量化某个省份提升倍数，对于国家整体提升占比。以此类推，这样的思维太酷了，为投入产出提供了强而有力的数据支撑。

控制论

Scrum敏捷开发模式: 设定一个阶段目标，拆分为小的任务分配，每日站会反馈任务进度或阻塞情况，以便及时调整。从而避免长远目标计划在临近交付日期时，才发现方向有问题导致崩盘

科学三论它们对现代影响甚广，虽然它们可能穿上新的外衣，但是随处可看见他们的身影。

这或许这就是IT行业比传统行业进步快的秘密吧。

贺亚东

2019.06.25