如何做在创业小厂里做技术领导

今天有位老板朋友问我：他在创业，融资、推广、运营、内容都没问题，唯独缺少技术研发带头人，应该怎么去找这类人才，或者将来面试招聘的时候应该注重哪些方面？我简单帮他总结了一下，趁着还能记得，写下来分享给大家。

职责

一般来说，在创业小厂里做技术领导，要负责的事情如下：

1. 技术攻关。不要让技术问题阻碍公司发展。
2. 技术团队管理。保证技术团队能稳定可靠高效的输出技术产品。
3. 基础设施建设。公司所需要的各种网站、网络服务，等。

这里面，技术攻关比较难，可能不容易出结果，但反而比较好操作，因为只需要读文档、查文献、向人请教、写代码就能解决。基础设施大部分是体力活，也不会有太大问题。所以我们今天就来重点讨论第二点：技术团队管理。

核心：提升短板

我的经验，创业小厂的技术领导，大家的首要工作，就是要提升团队的短板。

通常来说，创业公司的钱包都不会太鼓，一方面很难招到行业里最好的那部分开发者，另一方面岗位设置上往往也是能省则省，需要大家互相填补空白。

所以作为技术领导，我们必须要通过工具、流程、规范等手段，提升团队短板，确保即使团队能力有限、即使团队岗位有缺失，也能保证产品质量。

工具

工具是死的，所以用工具提升短板是最可靠的方案，因为它可以无差别、全天候地守护我们的产品代码。可惜目前工具很难独立完成工作，往往需要流程、规范来配合。希望随着 AI 的发展，工具能越来越好用，越来越能独立生效。

下面是我推荐的必备工具：

Git

版本管理工具，妥善使用可以很好的帮助团队并行开发，提升代码质量。推荐大家看下我之前写的系列文章：

• 2023 Git 必备知识（一）：常用团队规范
• 2023 Git 必备知识（二）：常见问题解决
• 2023 Git 必备知识（三）：小知识推荐配置与小技巧

自动化测试

测试对产品质量的提升非常明显。人工测试存在一些问题，主要是回归测试又累又无聊，自动化测试可以很好的弥补。不过，自动化测试需要开发团队投入时间维护，往往缺乏群众基础，需要管理者权衡。

建议在项目初期就建立测试框架，然后随着开发、debug 不断增加测试用例。我最反对的是极端化：不需要追求测试覆盖率；更不要因为测试需要花费时间就彻底拒绝测试自动化测试。在时间、精力允许的前提下，尽量多准备测试用例；bug 修复要带上测试用例；测试用例可以不覆盖所有特殊情况，但完全没有测试用例也很要不得。

函数、API 的测试工具比较多，大家按需选用；UI 自动化推荐 Cypress。

代码静态分析

静态分析可以提升代码质量、减少安全隐患。相比于自动化测试，这方面推进的难度比较低。代表工具是 ESLint，建议大家使用配合 Sonarqube 等安全软件使用。

故障收集

收集线上故障有助于我们提前发现问题、解决问题。目前最流行的工具是 Sentry，大家可以考虑使用公共服务，或者自行搭建。我的经验供参考：

• Ubuntu 22.04 部署 Sentry 笔记
• 升级 Sentry 自主部署实例

流程

流程执行的好，对提升短板的效果也是立竿见影。经验告诉我，一般创业小团队较多采用敏捷或类敏捷的开发过程，所以我的流程推荐也基于敏捷开发方法。

立会

我会要求团队每天开立会。我不要求每天都有具体的产出，但是有没有都得报告一下。立会的内容很简单，每人几分钟：

• 总结自己前一天的工作结果
• 公开自己今天的计划
• 如果遇到无法解决的问题，寻求帮助
• 如果需要他人协作，预约时间

每日立会会给团队带来不小的心理压力，对于远程或者混合远程的公司来说，这个压力是必须的。每日立会对远程公司非常重要。

需求评审会

公司每天都会产生大量需求，但不是所有需求都能做，也不是所有需求都要做。需求交付给研发之前，需要经过评审：

1. 是否有必要？
2. 是否已完成设计？
3. 是否包含数据预期与验证标准？

这里大家要记得，按照紧急重要四象限法，优先级：重要>紧急。

技术评审会

开发人员开始做需求的时候，也不能太随意，我会要求针对每个需求做技术评审。当然，技术评审会也可以简化，这个过程只为保证开发人员进行了足够的思考。

1. 开发人员要说明自己解决问题的思路
2. 开发人员要介绍自己选择的技术方案，选择此方案的原因、潜在风险、其它备选方案、优劣对比
3. 大需求要组织会议，小需求可以直接发在研发群里备案

Code Review

Code Review 的重要性不需赘述，大家直接看我另一系列的分享吧：

• 在 Code.fun 做 Code Review
• 在 Code.fun 做 Code Review（二）
• 在 Code.fun 做 Code Review（三）：聊聊 Promise 的错误处理、如何真正学到技术
• 在 Code.fun 做 Code Review（四）

规范

规范的目的是让大家更好的使用工具，更严格的推进流程。今天不讨论具体规范，简单列一下常见的规范范围吧。

• Code Style
• 需求规范
• 代码架构规范
• 文档规范
• 版本管理规范

一般来说，规范都不会差太多，关键在于执行，以及执行中尺度的把握。建议大家随便抄一些，然后根据公司、团队特性修改后执行。并保持开放的心态，边做边修正，最后通常都能有不错的结果。

总结

创业要看命，我们要做的，则是尽人事。希望这些经验对大家有帮助。

不过限于个人能力和眼界，上面这些也未必都对。各位老板也可以在面试的时候跟候选人聊聊这些话题，看看对方能否给出逻辑清晰、有启发性的答案，我觉得，只要是勤奋思考，积极寻证，哪怕有出入也不是问题。

大家有问题、意见和建议，欢迎留言讨论。