网上软件工程相关的书籍与文档已经有很多了，但是一般都存在一定的幸存者偏差，比如《人月神话》作者叙述如何在IBM带团队，而现实中反而大部分遇到的项目是领导拍脑袋决定几天搞定业务；或者给你一堆不是你面试的外包/新员工；或者临时给你交接一个锅

本文适用于

• 技术水平很高，同时更希望获得非技术成长的读者

本文限定的场景是

• 只在个人层面上自下而上效率改良，相当于打补丁，非管理者。无法影响项目这艘大船的全局航线
• 主要适用于大型软件项目

本文的内容是通过负向改进来识别不增值的工作，而不是一键升级软件质量的【特效药】

主要目的

• 提前发现/拒绝不增值业务
• 自动化/外包化重复劳动

其实这种效率提升与JVM优化有相似之处，比如JIT优化、代码记忆化、内联去掉无用代码

关键词: 方法论, 持续改进, 会议, 质量与流程

指导思想

基于业务连续性管理（Business Continuity Management，简称BCM），打造反脆弱的团队。

懂得拒绝

在代码中经常写各种防御代码，用于判断空或者业务校验。在开发中也是一样，第一件是就是拒绝/甩锅。拒绝主要有2种类型，一个是不要轻易承诺，另一个是不要把帮助当做理所当然。

• 不接受直接派来的人: 一定要自己再面一遍，否则后续就擦屁股吧。
• 不接受没有交接来的锅: 这种一般都找不到责任人，否则加班到晚上还找不到接口人。
• 他人挖坑导致的救火: 要求领导承诺事后进行AAR改进
• 不接受各种不增值杂活: 这样的活一般直接分一个非主力外包出去干(搞环境/冒烟/笔试对答案)。

总的来说，遇到上面问题我个人一般是拒绝的，硬要塞给我也会报风险。如果你个人不太习惯直接拒绝的话，你可以提一个比较高的条件，让对方知难而退；否则一旦接受，后面的锅就源源不断甩过来了。

记录每天的工作

识别不增值工作的第一步就是发现问题，最简单的方法就是无巨细地记录每天的工作内容。投资时间并不多，而且收益率非常高

实现方法

1. 使用场景: 当你感觉非常忙的时候才用，平时反而必要使用
2. 使用Excel/便签等工具，以小时为刻度，记录自己遇到了什么问题，最终如何解决的，责任人是谁要落地
3. 项目不紧张时，列出表格对时间，不是自己的责任要甩锅，是自己的责任要想出改进建议

举个例子，我在某项目开发中某用例执行时报错，责任主体不明确，涉及到: 自己开发的代码，其它组的代码，自动化用例，开发环境(Redis/Zk/DB)。而且这个定位及其复杂，搞了一天最终定位出是其它组代码导致的。众所周知，CI失败将影响整个组，因此通过记录定位过程，既可以方便甩锅，也可以后期进行持续改进

你可以把这个方法先用几天，然后把问题攒着再进行会议集中处理，具体流程如下

1
2
3
4
5
6
7

按照小时维度记录工作内容
	|
项目不紧张时统计分析工作是否增值
	|
将不增值工作自动化/外包化
	|
自己留下更多时间

这个方法也就是所谓的AAR事后回顾

无增值项目问题枚举

下面是在实际项目中通过上面“记录”遇到的问题与解决方法

模块责任不明确

在项目开发中，涉及到各种组件，出了问题经常会互相踢皮球，这种问题，需要建立求助Map

1
2
3
4
5
6
7
8
9
10
11
12
13

def map = [:]
def lookForHelp = {problem->
	//定位求助....
  	return person;
}
def person = map.get(problem)
if(person!= null){
  return person
}else{
  person = lookForHelp(problem)
  map.put(problem,person)
  return person
}

就是上面代码的意思，通过建立Map缓存，并分享求助信息(比如项目组内部主页)给成员，减少lookForHelp的时间

这个就是算法中的动态规划，保留计算结果供下次使用

忽视自动化工程投资

以常见的开发领域为例，许多人都遇到过下面的问题

• 生产环境与测试环境数据“污染”导致耗费大量精力定位问题
• 各个小组通过邮件、Word、Excel去定义协议，版本管理混乱，后期大量扯皮
• 客户/测试的问题通过邮件轰炸，开发手工用记事本核对是否解决

这些问题看起来可大可小，都可以通过堆加班，招外包来解决问题，因此很多人，包括开发人员也不重视，最多也就是每次到了deadline时开始抱怨加班多，而deadline结束后再也没有想办法如何去改进问题。这个是拖延症，得治。按照【二八定律】，可能有80%的人都默默地被动忍受，10%的人可能发个帖/邮件抱怨一下，剩下的10%可能才提出问题后并解决问题。

解决方法

• 求助领导推动问题: 请领导给自己时间去专门优化流程，甚至大的项目组可以成立专门的工具开发组
• 投入专有人力/时间开发工具: 将重复需要做的事情封装为【流程函数】，并进行版本与文档维护
• 所有的流程/文档全部版本化: 比如Url协议可以通过Postman/Swagger以外部文本DSL的形式进行保存，而不是使用Word这样的二进制格式，这个好处就是支持Git版本管理，同时有大量的工具方便生成测试用例或者MockStub
• 自动处理任务: 使用脚本，机器学习，AI来处理各种任务，这个是未来的趋势。

其实还有很多自动化方法，具体的发展方向就是IT/流程与工具，这个涉及到跨领域问题，做自动化需要与内部客户对齐

过早进行公共下沉

在某些企业项目中，为了降低成本，公司想尽量复制，去除定制。因此总是有各种趋势把代码放到公共中，想节省开发时间。

不过事与愿违，真正项目中却是这样的

• 代码下沉到公共后，多人修改后(加入各种if)，最终成为了大麻花，没人再敢修改或者重构
• 有人代码质量差，有人离职跑路了，而这个公共每个人不得不用，苦了后面的开发去定位问题
• 项目后期，开发宁可用黑科技绕开公共，或者再写一道适配器，反而浪费了更多的时间

这里面最重要的原因是为了项目层面上为了【重复率】指标而公共，用行政命令控制项目代码

对于此类问题，有如下方法

• 及时报延期风险，并证明收益比是多么低
• 转换、查表、补全等CURD操作不适合放到公共
• 真的有场景需要才下沉到公共，平时尽可能使用开源/有积累的公共库

谈程序的“通用性”

过早进行联调

在交付类软件项目中，就算《人月神话》在公司推广得再多，实际项目还是给一个deadline，然后算出人天，最后再加权除法计算到某一个人，因此项目的时间总是不够。

当项目进度由于各种原因落后，此时为了发版本而强行进行过早联调，这样看起来“准点了”，实际上问题更大

• 部分代码没有测试就直接联调，出现问题难以通过排除法定位出责任人
• 所有人挤在一台机器上，日志多/重启多，最终效率反而更低

对于此类问题，大船已经快沉了，任何改进都是在浪费时间，我建议跑路

忽视合作人员质量控制

在很多软件公司中，包括BAT都招聘了大量的合作方员工，如果给你分几个水货，那么你就是给他们擦屁股的；如果来了几个高手，你就可以当包工头啦。总体来说，我个人建议

• 严格要求面试(特别是自学能力)，否则最后加班的是你自己
• 反复筛选淘汰(时间可能长达数月)，最终选出符合要求而且稳定的人员
• 尽可能不要远程办公，而是要通过晨会等面对面的方式对齐目标

详见如何在两周内带起一个小团队？

无时不在的墨菲定律

墨菲定律指，也就是说在项目中忽视的小问题，最终一定会发生。举个例子

• 没有审阅过的代码一定会出错
• 没有维护的开发环境一定会挂掉

这类小问题，发现一个记录一个，找出对应责任人，并建立文档化的Wiki，以解决此问题。

总结

本文其实就是一篇自下而上的改良方法论。各位在项目中遇到类似问题时，首先不要有抵触心理(不要敌视，也不要闷着不说)，而是要通过上面的方法论进行总结反馈，并向上给出改进建议

• 改进成功: 当然是皆大欢喜的事情了
• 改进失败: 如果上级是一个二传手，那么问题将很难推动，请赶紧逃离

总的来说，任何改良都不如“跟对人”，这个就是靠运气了

扩展阅读

• 《软件开发践行路-ThoughtWorks中国区文集》
• 《图解CIO工作指南》