这是芃篙君的第【337】篇原创
本文适合在软件行业发展的朋友。大概2600字，阅读需要9分钟。
你好呀，我是芃（péng）篙，一个相信思考和努力能够拿到结果的家伙。
今天我们开始第一部分，”更高效“。
软件本身就是围绕效率的东西。社交软件提高了人与人之间沟通的效率；企业软件提高了企业管理的效率；各种工具平台提高了软件开发的效率。
直到 AI 这种软件出现，甚至产生了一种革掉搞软件生产的程序员的命的趋势。
所以，从中年程序员的视角来看，效率确实是第一要命的东西，也是突破现在所处阶段的基本要素。
01
可能不同的人，对自己关于效率的状态的感受是不一样的。
有些人会觉得自己的工作就是一团乱麻似的，根本没有提效的空间；
有些人会觉得自己目前的状态就是最高效的，没有必要去做什么提效。
但是，如何衡量效率，是一个麻烦事。
我们先把效率放到一边，因为提效并不一定是目标，而是一种路径。
芃篙曾经讨论过一位大佬讲的 6-4-2 法则。
这个方法的最大用处是给出了一个时间应用的指引。如果你想更进一步，那么你的时间分配应该是有规划的。
用 60% 的时间完成日常 100% 的工作 用 40% 的时间完成对普通工作来说，具备突破性质的事务 用额外的 20% 的时间，完成探索性的事务
所以，以突破阶层为目的的话，提高效率是一个必要的手段。因为我们至少需要以 60% 的精力去完成 100% 的常规事务。
我们且不提另外的 4 和 2 怎么做，首先面对的就是这个效率问题。
而 6-4-2 这个方法的第二个重大作用，就是指引我们发现日常的时间到底都投到了哪个方向。
参考芃篙之前的文章，定义好你的普通、突破和探索型事务——这里可能就是一个难关，再老老实实记录一个月。回头看一下这组数据，你会非常有收获。
02
每个人的背景不一样，所处的环境也不一样，所以，大概率大家的问题与解法也不一样。
这部分，我们就聊一聊典型的提效点。
说到典型，我们不妨把日常的工作事务分成两个维度。
第一个分类维度，是事务的独立性。也就是说，这件事是你自己就能搞定的事，还是需要其他人配合才能搞定的事；
显然，做事的效能跟参与这件事的人数，是有必然联系的。
从程序员的角度来举例的话，可能也需要考虑事务的粒度。
比如，常规来讲，编码这件事理论上程序员自己应该能搞定，但是粒度比较大的话：你要不要考虑需求细节的定义？或者，你要不要依赖其他端的 API？所以，编码本身也有独立的，也有依赖其他同事的。
第二个分类维度，是事务的突发性。也就是说，这件事是你原本计划就是这个时间来干的，还是临时插进来的高优先级的事。
显然，突发事件会打乱大家原本的工作计划，是大多数人效率方面的绊脚石。
对程序员来说，可能是痛点中的痛点了。临时拉你去开个什么会；突然蹦出来的紧急需求；火急火燎的客户问题；老板忽然发了一条信息，要帮他看个什么事情……
我们尝试把这两个维度，画成四个象限，事情就会比较清楚了。
第一象限，自己就能搞定的计划中事务。 纵享丝滑的意思，其实只是这件事自己有绝对的掌控权。具体事情效能可以做到多厉害，还是得看自己的能力。
第二象限，团队搞定的计划中事务。 旱的旱死，涝的涝死，就是说这种事得看情况。协作链路上磨合的很好、配合很默契，自然也是爽歪歪；但是，更多情况可能是，协同链路上存在一个陌生人，就得看运气。
第三象限，需要多人参与完成的突发事务。 效能地狱非常好理解，突发的紧急事务，还需要协调多人去解决，最大的问题就是，对你来说的紧急事务，对协同链路中的某些人来说，并不紧急。
第四象限，自己就能搞定的突发事务。 最近比较烦，是指事情都在掌控之中，只不过自己原本的计划被打乱了。
这样一看，效能要怎么提升？规则看起来很简单，一共就两条。
规则一，所有的事务，想各种办法往第一象限去流动。
规则二，提高个人节点上，处理计划中事务的能力及效率。
换句话说，既然多人协同再怎么厉害，都不如一个人效率高，那么就在任何维度尝试消除不必要的协同；
既然突发事务总是会影响到计划事务，那就在任何维度尝试去降低突发事务的发生。
规则看起来只有几句话，不复杂，但是真正做到位，并不简单。
03
聊到这里，芃篙发现有三个问题。
第一个问题，你会发现，我们在讨论这些规则时，搞得多少有点抽象。
抽象的典型表现就是，听起来很有道理，但是具体咋做，好像还是搞不明白。
所以，在关于效率的后续内容里，我们尽量从各个象限的典型场景出发，聊一些具体细节事务，以及对应的处理方式。
抽象的理论，通过细节的补充，才会更加实事求是。
第二个问题，你会发现，转移象限这个事情，可能并不在我的”能力“范围之内。
这里的”能力“，可能是职位，可能是职责，也可能是个人影响力。
比如，我想把一个需要四个部门协同的事务，搞成三个部门的人来就行了。但是我就是一个普通员工，我们有流程定义权限啊，怎么办。
这里对应的是一个视角的问题，我们在全盘看效率问题时，其实并不是在个人视角来看问题。
如果是基层员工，那么就至少需要以基层管理者的视角看问题；如果是基层管理者，那么就至少需要以中层管理者的视角看问题；如果是中层管理者，那么就至少需要以高管的视角看问题。
虽然，跨级思考未见得想得正确，但是是必要的。谁来帮你去矫正，谁来帮你去落实，当然是你的上级。在好的组织里，支持型的管理者有义务帮下属解决这类问题，特别是结构型的问题。
并且更重要的是，组织内的效率提升，关乎所有人的利益。
在这里，反二极管思维的灰度思维很有作用。也就是说，你不一定需要百分百的解决所有问题，哪怕你只是让你的老板，帮你斧正了你从他视角看问题的思路，就是一大收获了。问题能解决多少，是多少。
第三个问题，你会发现，我们讨论了两个维度，分析了半天，最终需要解决很复杂的象限转移的问题，才轮到讲个人能力的问题。难道不应该是先提升个人能力吗？
这其实只是分析的思路，跟具体实践的先后没有关系。如果你是一个中年程序员，芃篙默认你的能力是 OK 的；如果你是刚刚入行的新手，可能先把技术和经验搞上去，整体的提升效率会更高。
无论在哪个阶段，抱着良好的心态，去对待任何一件麻烦事，才是提升能力的基础。
后面的内容，我们重点对待第一个问题，来细化每个象限具体的场景。
相关链接
关注芃篙君⬇️，每日获取思考与践行的认知更新...
可获取软考备考资料；
亦可加微信探讨开发者、职场与管理、IoT行业等话题；
共同成长，穿越周期！
