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

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

职责

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

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

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

核心:提升短板

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

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

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

工具

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

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

Git

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

自动化测试

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

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

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

代码静态分析

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

故障收集

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

流程

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

立会

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

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

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

需求评审会

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

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

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

技术评审会

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

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

Code Review

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

规范

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

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

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

总结

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

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

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

如果您觉得文章内容对您有用,不妨支持我创作更多有价值的分享:


已发布

分类

来自

评论

《 “如何做在创业小厂里做技术领导” 》 有 2 条评论

  1. Jim Zhai 的头像
    Jim Zhai

    需求评审会的第二条和第三条值得讨论一下。我相信需求不应该包括设计。设计应该由UX designer和Engineer提供。理由见https://youtu.be/KP0U3I-f9-Y

    1. meathill 的头像

      这里要看怎么定义“需求”,和怎么设计“需求评审的粒度”。

      1. 在很小的公司里,设计可能直接由产品经理提供,给出低保真模型,由前端按照既有前端框架实现即可。
      2. 此时,产品经理可以直接处理整个需求,那么交付的需求里就应该包含设计。
      3. 如果开发链条很长,设计师也要加入到需求评审,需求评审可能分为多个阶段,那么交付物就可以不包含设计稿。
      4. 我们讨论创业小厂,我就尽量按照大家身兼多职,岗位职责大家分担来设计。

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据