工作效率提升，是所有企业组织都追求的一个目标。高效率意味着用更少到人可以做更多的活儿，赚取更多的利润。员工收入也会有较大提升，有面子；管理层的收 入就更水长船高了。但说起来容易，做起来难。工作效率低下一直是让各个组织的管理者头疼的问题，组织无论大小，无论中外，皆如此。

从大的方面来看，提高效率的策略不会很多，万变不离其中，关键是落实，措施要与自己的组织实际情况匹配。两年前自己曾经写过一篇博文“提升效率不是口 号”，个人觉得那时的观点依旧不过时，长期适用。两年过去了，我们虽然取得了一些成绩，但还远远不够，尤其是当组织情况在持续发生变化的情况下。这里再对 观点做些诠释，plus一些新的想法。

* 领导不彷徨

各级员工都要有明确的目标和方向，领导尤甚。组织的最高领导一级要有明确的业务方向、目标以及组织发展策略。领导是主心骨，如果领导都彷徨，那么下面自然 也跟着彷徨，整个组织就不会有战斗力，效率就更无从谈起。尤其是在大环境不好，业务低迷期，领导更应该作出正确的策略和方向方面的决策。

领导要将方向、目标和策略明确的告知一线Leader，让leader们明确重点投入的方向以及可以投入的方向，以便一线leader可以有的放矢，有计划有节奏的去做，也便于一线leader评估各种人和技术的储备，提前做好准备。

* 适当的紧迫感

如果员工已知的工作只有一项，那很可能出现帕金森现象：在工作中，工作会自动地膨胀，占满一个人所有可用的时间，如果时间充裕，他就会放慢工作节奏或是增添其他事情以便用掉所有的时间。看起来每个人都很忙，但组织效率是低下的。

因此务必要做到让每个员工已知的工作保持在3项左右。当员工意识到三项任务摆在面前时，心中自然会有一定的紧迫感，让员工始终绷紧神经，即便是闲遐时刻也会考虑下一个工作任务中用到的技术我是否做好了准备，从而主动学习和准备。

* 基础设施建设上不能太小气

"基础设施"这个字眼常常出现在新闻报端，中国社会目前依旧出于大规模基础设施建设的阶段中。百度百科里说：“基础设施是指为社会生产和居民生活提供公共 服务的物质工程设施，是用于保证国家或地区社会经济活动正常进行的公共服务系统。基础设施建设具有所谓“乘数效应”，即能带来几倍于投资额的社会总需求和 国民收入。一个国家或地区的基础设施是否完善，是其经济是否可以长期持续稳定发展的重要基础”。在组织个人能力无法快速提升的情况下，适当的基础设施建设 会带来可观的组织效率提升，比如统一的服务器管理、自动化测试基础设施、持续交付工具的开发、体验良好内容丰富的知识管理系统等，让组织人员的工作环境上 了一个“档次”，就好比从中国到美国所感受到的一样，或者从印度到中国所感受到的类似。印度和中国差在哪里？都是50年代建国，人口红利相差不多，但目前 中国却要比印度先进若干年，基础设施水平绝对是一个因素。外商投资除了看重中国的低价劳动力之外，更多是中国的基础设施的完备，据说印度的德里现在还经常 停电呢。同样水平的人在印度和在中国的工作效率显然是不同的，同样的工作在中国一天就完成了，而在印度那边可能还在等啥时候能来电呢^_^。类比组织内， 具有自动化测试环境的前提下，一个项目的验收测试可能在2个小时内就跑完了，而相反，在没有自动化测试基础设施的情况下，可能一个人要做两天，效率高低立 见。

*后勤部门也能诞生将军

现代的工作多是团体作战，这就好比军队：要军事过硬的同时，保障也要给力。也就是说一个军事任务的完成，除了依靠一线冲锋陷阵的将士外，后勤子弟兵的努力一样不可缺少，甚至于在如今的现代战争中，后勤保障直接决定了战争的最后结果。

任何一个公司都有核心业务部门，有从事核心业务研发的同事，也有从事基础设施方面（后勤保证）的人员。要想激发工作热情，提升效率，就要对这些人的工作一 视同仁。工作只有分工不同，没有高低贵贱。其实在很多公司，做基础设施其实更是对能力方面要求很高，更有甚者在一些公司只有一流的程序员才有资格参与基础 设施的设计与开发。因此不要因为基础设施没有带来直接效益而忽视对参与基础设施工作人员的重视。

以上话有些糙，但理不糙，希望能给大家在组织效率提升方面带来些启发。

BTW，这两年自己也持续在组织整体能力和效率提升方面做了些工作：先后推动了组织内部知识管理系统、持续集成、自动代码检查、自动化集成和验收测试、打包与交付以及代码评审流程改进等工作的落地。

最近闲暇时间在策划实施两件事儿：一是产品的自动化回归测试；二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事，对提升产品质量，提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到：现在做有些晚，正确的事要趁早做。

去年自动化测试组发布了自动化测试框架的第一个版本，我们的产品参加了试点。但经过自动化测试组大半年的投入，效果十分有限，根本没有达到我的预期。最主 要的问题是使用他们提供的框架编写和维护test case都十分困难，工作量投入很大，这很打击大家的积极性。今年大家决定将自动化测试框架换成nokia开源的robotframework。经过预 研，robotframework完全可以满足我们的测试需求，并且robotframework的用例编写和维护效率太高了，编写门槛却很低。

虽然换成了robotframework，但我们应用的时机还是有些晚了。试点项目已经接近开发尾声，这时候如果要加上自动化测试，势必就要在短时间进行 大量测试用例开发。如果在项目初期，增量的用例添加相信会达到更好的效果。但即便是“亡羊补牢”，我们也还是要做的，还好这个产品版本的生命周期才刚刚开 始，后续可能还会持续很多年，加上自动化回归测试还是有重大意义的。

不过鉴于之前的教训，我们调整了自动化测试的切入点。之前自动化测试组只是闷头写用例，并未太多考虑自动化测试框架与被测目标如何配合的问题：比如没有考 虑自动化测试在哪个环节应用、谁来驱动、谁来执行以及测试环境如何生成等。这次我们先绕过用例编写，先从“基础设施”搭建开始。我们的目标是将自动化测试 与我们的持续集成流程集成在一起，也就是说我们将通过jenkins这样的ci平台来作为自动化回归测试的驱动。我们首先就是要将这个驱动流程run起 来，即便测试用例库中一条用例也没有。一旦run起来后，我们再将关注点集中在用例的编写和调试上，我想这才是正确的思路。

第二件感觉做得有些晚的正确的事儿就是为项目增加静态代码检查环节。之前项目静态代码检查仅停留在打开GCC编译器的-Wall选项这个层次。就是否有必 要引入第三方静态代码分析工具对代码进行缺陷检查，大家一直没有统一意见。质量部门希望我们引入，但关键问题是我们没有找到一款适合的开源工具(for C)，在维基提供的C语言静态分析工具列表中，我感觉似乎只有splint符合我们的要求 – 开源、功能强大且支持linux/unix。不过splint似乎已经停止开发了，最新版本停留在3.1.2。

使用类似splint这样的工具对代码进行检查时总是能给出大量的warning，如果不加以控制，那么屏幕就会被warning淹没。因此正式使用之 前，需要一个“磨合期”。先确定打开或关闭哪些检查规则开关，原则只有一个，即尽量避免误警告，又不能漏掉真实的隐患。splint对C99新增语法的支 持不是很好。splint碰到下面这种语法时会提示parse error，并且无法recover：

struct foo {
    int a;
    int b;
};

int main() {
    struct foo f = {.a = 1, .b = 2};  /* Parse Error */
    printf("%d %d\n",  f.a,  f.b);
    return 0;
}

这类静态代码检查的基础设施在项目初期搭建起来是最佳的，开发人员可以增量的对代码进行语义检查，并修正缺陷。但如果在代码开发即将结束的阶段加入，即使 是设置了一套合理的检查规则组合，你也可能困惑于工具产生的大量Warning。不过“有胜于无”，在没有找到更好的工具前，我将splint加入到工程 中，建议组员适当时机使用，并随时对check rules组合开关进行调整和优化。也许经过一段时间的磨合后，可以实现在ci job中加入自动代码静态检查这个环节，当然目前肯定不是适宜时间。

正确的事，你会发现早做和晚做效果是截然不同的。但“亡羊补牢“的工作也不能不做。既然是你认为正确的事，从长远来看，还是能带来很大价值的。