什么是草台班子？

有个朋友最近想跳槽，他对管理的兴趣不大，而且认为自己的性格也不适合做管理，更想成为技术专家。基于这些考虑，他希望能进入知名大厂，如果面试不顺利，去小而美公司也行。他的面试经验不多，就向我咨询了一下如何选择公司的问题。

小公司必然缺钱缺人，技术团队几乎没有美，99%都是草台班子。有一些上万职员的大公司，运营着很多业务线，每条线又有多个技术团队，这些技术团队的水平良莠不齐，也存在部分草台班子。无论公司大小，造成技术团队是草台班子的根本原因都是一样的：

• 不重视技术投入

公司就是一辆车，让车跑起来的要素太多了，技术只相当于半个轮子。任何公司都是资源不足的，管理层总是把资源投在产出最高、最快的地方。在很多传统企业里面，技术只是辅助业务自动化运转，不直接创造价值，自然不受到重视。

• 轻视研发质量

并不是线上没重大BUG，研发质量就算高了，还要兼顾工程质量、研发效率、团队可持续发展等方面。许多草台班子只关注了BUG和研发效率（这个效率也是加班加出来），其他方面做得一塌糊涂。公司要想提高研发质量，首先要建设一个有技术范的管理队伍；其次对管理人员进行360环评，所谓“兵熊熊一个，将熊熊一窝”。360环评的特点是，被评估者从自己、上司、下属、同事获得多个角度的反馈，从这些反馈知道自己的缺点、优点与发展需求。

在面试的时候如何判断技术团队是不是草台班子呢？我的建议是在面试的尾声，问面试官一个问题：你们团队的技术文档质量怎么样？如果面试官说“还可以”，就继续追问他“哪些方面还可以，哪些方面待改善？”。如果它是个草台班子，技术文档一定没做好，面试官会心虚。

什么是草台班子？它有三个共同特征：

1.缺乏工作流程

一个需求从提出到上线要经历至少七个流程：

• 1）需求评审：产品经理给出需求文档，邀请技术参与需求评审，目的是扫清需求疑点，排除技术上无法实现的需求。
• 2）技术评审：技术人员内部评审需求，确定详细的技术方案。
• 3）开发排期：技术人员根据技术方案拆解任务，输出开发排期文档，并告知产品和测试，以便他们协调测试时间。
• 4）开发阶段：技术人员用代码实现需求，如果有需求疑点，继续找产品核实；在开发尾声，技术团队内部评审该需求的代码。
• 5）测试用例评审：测试人员根据需求文档拆分测试用例，并给出测试工作排期，确定需求最终上线日期。
• 6）测试阶段：测试人员根据测试用例分别在测试、预发布、灰度、生产环境测试。
• 7）产品验收：测试人员确认测试通过，邀请产品人员验收。

很多团队制定了研发流程，实际工作起来却跳过一些流程或者执行不到位，原因有两个：

• 1）产品经理希望早点上线：想需求早点上线，必然压缩开发周期，有时甚至跳过测试阶段，完全由开发人员自测。这种情况技术Leader要据理力争为开发人员争取更多的时间。
• 2）开发人员专业能力不足：以代码评审为例，不能让专业能力差的人去做，因为他看什么代码都觉得还行。日常工作中优先让技术好的人做代码评审，并且进行内部技术分享，尽快提高每个人的专业能力。

2.技术文档匮乏

团队工作中最容易忽视技术文档，因为编写文档是个苦力活，而且短期内看不到效果。常用的技术文档包括下面六类：

• 1）新人入职指引文档

新人入职后需要配置开发环境、申请内部账号等等。通过入职指引文档，新人不需要找老人打听，显著提高工作效率。

• 2）系统架构文档

系统架构文档帮助新人迅速了解技术栈、整体系统结构、微服务分类和调用情况。由于开发的不断迭代，可能加入新的微服务或者调整存储层，系统架构文档要及时更新。

• 3）团队研发规范文档

研发规范文档至少要涵盖：数据库建库建表规范、开发语言代码规范、应用工程结构规范。配合代码审查，严格执行研发规范。

• 4）日常技术方案文档

开发重要的、周期长的需求，一定要编写技术方案文档。这类文档帮助开发人员理清思路，日后其他成员也更容易接手。技术方案文档的内容包括：业务流程图、接口设计与改造、数据表设计、灰度方案、回滚方案、发布计划与工程配置。

• 5）重大故障复盘文档

如果不进行故障复盘，必然再次出现故障，交了学费却没有学到东西。故障复盘文档包括：故障发生和持续的时间；解决故障的具体方案和时间段；故障造成的损失是什么；发生故障的根本原因是什么；如何避免故障再次出现。

• 6）通用组件优化文档

开发团队通常积累一些常用工具库，解决工程的基础问题，比如对象属性拷贝、IO处理、网络请求等等。这些库的使用很广泛，如果有些方法获得优化，收益是很大的。改动了工具库，要编写相应的文档，将优化措施和风险写清楚，避免给使用者留坑。

3.不做工作总结

许多技术团队从来不做工作总结，每个月做几个需求，每个季度聚个餐，年底再聚个餐，一年就结束了。长此以往，只低头做事不抬头看路，团队成员的能力提升非常有限。

工作总结的执行方式是每个团队成员根据自己的情况做PPT，然后讲述给其他人听，PPT的主要内容有三个：

• 1）创造的价值：这一阶段的开发的需求创造了什么价值，有没有降本增效。
• 2）收获和感想：这一阶段的收获是什么，哪些能力得以提升，哪些缺点需要改正。
• 3）计划和展望：除了产品提出的需求，下一步的工作计划是什么，哪些项目可以优化，哪些提升效率的内部工具可以开发。