什么是草台班子?

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

小公司必然缺钱缺人,技术团队几乎没有美,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)计划和展望:除了产品提出的需求,下一步的工作计划是什么,哪些项目可以优化,哪些提升效率的内部工具可以开发。

 7 total views,  1 views today

页面下部广告