山维空间

分类： 管理

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

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

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

    职责

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

    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
    • 需求规范
    • 代码架构规范
    • 文档规范
    • 版本管理规范

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

    总结

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

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

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

  • 程序员副业闲聊：怎么领导一份副业

    程序员副业闲聊：怎么领导一份副业

    有位同学找我聊天，不知道是不是看了 聊聊我对接私单的看法：少接私单，多做 side project，想自己组个业余协作团队，一起做点事情。他问我，觉得是否可行，有没有哪些已知的坑？

    我：

    按我的经验，我们程序员最缺的是运营、增长、业务这些东西。即代码变现这个环节。正如很多老板会说“就差一个程序员了”，程序员团队也困于“就差个靠谱的老板了”。

    世间最难以琢磨的，就是缘分。双方都靠谱，能够互相理解、互相支持，在我们日常的种种关系中，都很难得。这里不同的是：双方组合为了搞钱，面对的压力更大、诱惑更多。

    某同学又问：

    嗯嗯 程序员团队 心目中 靠谱的老板 都包括什么呢？

    我：

    这里的老板不是雇你的人，是能把一整个业务跑起来的那种人。诚实可靠是基础，但远远不够。要能理解业务，找到业务瓶颈，找到合适的人填补空缺，说服所有人为这件事工作，能把业务跑起来，能把钱拿回来，知道怎么分配工作和所得。

    因为是 side project，不是有人出钱有人出力，大部分情况下都是集体出钱集体出力，所以更强调能力互补，而非督促、管理、下判断。程序员团队，大家都擅长需求落地，但是需求是什么，很多时候反而不清晰，这里就迫切需要一个能产出需求的人。

    某同学：

    嗯嗯 如果他不能真正懂得业务，但是懂得放权呢？ 会不会好一点？我想象中的 理想的团队 是彼此可以协同服务的，而不是等级化、权力化的组织 ……

    我：

    你的理解不太对。这里不存在放权的需要，这里的管理是说服力。你在公司里给老板干活儿，老板让你干什么，你就干什么，反正最后老板会给你钱。

    你自己拉个队伍，比如我们4、5个人组队，大家都是平等的，都出力出钱，那听谁的呢？你想做笔记软件，我想做在线简历，A 想做电子钱包，听谁的？谁来负责？谁来运营？这跟等级、权力其实没有关系。

    需要有一个做事的核心，能把方向定下来，能告诉大家钱从哪儿来，能找到团队的短板、能最后把钱拿回来。

    一般的企业里，老板出钱，承担风险，享受超额利润。程序员只负责干活儿，能交付合格的产品就可以，卖不卖得掉基本不管。如果组织成副业团队，又不想只是接外包挣辛苦钱，就需要做出真正有价值的产品，还要把产品卖出去，还要把钱拿回来。这就需要团队里要有人承担传统架构里老板的角色。

    这里的老板不是管人的老板，他当然应该根据团队需要安排大家的角色，但这不是他的首要目标，也完全无关放权。他安排协调所有人的目的，就是更好的产出、更好的产品、更好的变现。尊重大家的意见，在这里毫无意义，如果一个产品靠集体投票就能胜出，那现在的世界绝不是这个样子。

    程序员副业团队，必须由愿意负责的人说服其他人，相信他的产品判断。然后大家一起努力把产品做好，满足市场需求。最后再想办法把产品变现。如果最后不能变现，其他人也要学会从产品和市场上找问题，而不是从别人身上。

    后来我们又聊了些效率之类的话题，有些分散，就不往上写了。

    我是一个想法很多的人，大家看我的博客里有很多 idea 之类的文章。有些想法后来看，的确有一些实际价值，也有人做出来做得很好；但是有些想法的确不怎么样。

    我经常会找朋友讨论这些想法，我发现，想说服一个人非常困难，在我的诸多尝试中，成功说服别人的几率不超过 10%。每个人的视角不同、背景知识不同、经验不同、最终做出的判断就不同。作为老板，愿意出资，承担风险，别人当然愿意听你的；如果大家一起做预期不明的东西，那就需要更强的说服力和领导力。

    2022 年比较难过，2023 年会怎么样，谁也不知道。希望大家在新的一年里，都有新的收获。如果你想做一些副业，创造自己的资产，或者改善自己的财务状态，我都支持。但如果你是程序员，想组个团队搞些事情，我希望你考虑一下我上面的观点。

    有任何意见建议，均欢迎留言讨论。期待更好的一年。

  • 浅谈小型技术团队管理：问题篇

    浅谈小型技术团队管理：问题篇

    开篇先画一下范围：

    1. 针对小公司和小技术团队
    2. 技术团队地位中等偏上，作用比较重要，又不是那么重要
    3. 通常来说没有很核心的产品

    比如外包公司，客户当然期望你做出佳作，但实际上也做好了不行就换人的心理准备；或者老板本身不是做互联网的，拉起一支队伍想“赋能”一下自己的行业。总之就是资源不会太多，能做好当然皆大欢喜，做不好背锅走人也不要意外。

    这里我主要想和以技术研发为核心的纯互联网产品公司区分开。此时资源都会向研发倾斜，节奏也会跟着研发走，对于技术管理者来说，施展的空间要大得多。

    好，相信很多技术同学都有类似的经历：

    工作几年之后，自我感觉良好，大部分技术问题难不倒你。突然有一天，某位曾经合作愉快的前同事突然找到你，说有个改变世界的产品，需要一位足够出色的 CTO 来统领团队，想来想去你最合适。

    你觉得项目听起来靠谱，也觉得自己有能力接手，然而更重要的是：工作几年，想多接触些管理，但是现在的领导并不打算让贤，公司也没有那么多坑等着你填，这似乎的确是个好机会。

    于是你接受了对方的条件，成为这个小型技术团队的领导，公司非常需要你的团队做出好产品，但是你要面临很多不利因素：

    1. HC紧张，岗位设置很难做到面面俱到
    2. 业界知名度低，难以招幕到高级人才
    3. 资金压力大，要求快速迭代、变现，给研发部门自由发挥的空间不大
    4. 名义上“技术一小步，公司一大步”，但实际上技术并不是绝对核心，至少在几位合伙人的眼里不是。

    无论如何，先搭建团队，然后动手开发，活儿总是要干的嘛。大多数同学面临这种情况，会直觉性地选择俩眼一闭，先写代码。毕竟，写了代码才有产品，有了产品才有后面的其它工作。

    早期的开发一般会比较顺利，毕竟没有限制，只管做功能就好。但是，随着开发进行，踏踏实实写代码很快变成了奢求，一茬接一茬的问题出现，大家疲于奔命，到处救火，真正的产品优先级反而抛在后面。以我的经验，常见的问题有：

    1. 出了问题，前后端互相甩锅，前端说是后端的问题，后端说是前端的问题
    2. 测试人员高高兴兴的测出来一大堆问题，其中一多半可能不是问题，但是测试也需要职业成就感，所以他们宁可错杀一千不愿放掉一个
    3. 因为缺少回归，做新功能或者改 bug 的时候一不小心就把之前的代码改坏了
    4. 后端没做出接口，前端开始的时候要等后端，比较闲；后来接口出来了（多半延期），为了项目整体进度，又要赶时间，忙得要死
    5. 没有测试集，不敢重构，不敢升级依赖，不敢更换系统
    6. 没有压力测试，市场费用花出去，一波流量涌入，服务器挂了……
    7. 长期零和博弈导致团队内部关系紧张，内耗严重

    早年我也认为这个问题无解。大家只能夹缝中求生存，想方设法把产品搞出来弄上线，寄望产品成功，争取到足够多的时间旧代码，还技术债。用发展解决问题，或者至少延缓问题。

    但是我厂工作几年之后，我开始有新的想法。想要保证产品质量和代码质量，同时一点代价都不付出，当然不可能；但是，以优秀的技术产品、良好的流程，在保证产品质量和代码质量的同时，减少付出的成本，使得我们最终能够在项目进度、团队建设、产品质量之间找到平衡点，是绝对可能的。

    可惜的是，我暂时找不到能够立刻满足这套需求的产品，所以我决定在未来的一段时间把它整理开发出来，至少能够满足我自己的日常使用。希望这个坑能填上，能够真的派上用场。