浅谈如何建设一支高效技术团队？

一、前言

这里的技术团队，包含且不限于产品，研发，测试等角色同学。

作为一名普通的开发同学（当然啦，也可以称呼我螺丝钉一枚），本文结合自己职业生涯的经历和感悟，谈一下如何建设一支高效的技术团队。 鉴于个人视野格局和经验有限，所以一定会有很多不足之处，欢迎多提建议，以后能多多交流，一起成长。

二、团队建设需要注意哪些方面？

1. 和用户保持紧密沟通

不知道屏幕前的你，可否遇到这样的团队：我在干什么？我在哪里？我要怎么做？啊哈，想这些干什么，完全浪费时间，听用户的就对了！ 那么问题来了，如果用户也仅是凭自己感觉呢？

I have an idea，下一秒，需求文档（甚至没有文档，直接口头交流）就出来了，且只有几句话。 然后下一分钟就和研发同学沟通好，当天安排开发，当前迭代上线，perfect! 刚上线完（不，甚至刚开发完或者测试完），又有一个 idea，觉得之前不完美，所以就又变更了，然后就重复以上步骤循环。 如此高效协作，且是常态化（非临时紧急需求，而是一直这样）的团队，你值得拥有！

可能你会问，怎会有这样的团队？可是对于在其中的成员来说，这样才是对的呀，我勤奋，我骄傲，我只管干活不问业绩，只为证明我还存在着。 所以，世界真是精彩，天下之大，无奇不有。

要建设一支高效的技术团队，首先要和用户（这里的用户，包含且不限于客户，产品，设计，研发，测试等角色）保持紧密沟通。

如果产品设计和需求开发，远离用户的话，那么就是闭门造车、自嗨式设计和实现了。 只有基于用户本身诉求，才能设计出不反人类设计的产品，同时也能解决一些用户的核心需求。

个人认为，产品设计的初衷，就是为了解决用户目前现有的问题。或者说，更进一步的，满足用户自身并没有认识到，但又确实存在的潜在需求。 如果是再进一步的话，那么就是解决现在社会存在问题，或者为了给社会服务更多价值而设计的双赢的产品。 而一个长久的为大众所接受的产品设计的内在驱动力，应该是基于企业文化和价值观以及企业所应承担的社会责任感，而不应该是基于不切实际的想法或者想挣快钱的浮躁理念。这样在遇到外在诱惑的时候，能够依然明确自己所在的位置和方向。

另外，个人理解，和用户保持紧密沟通，并不是无底线跪舔式的解决用户提出的问题，而是挖掘用户客观存在且真实的需求。 不能一叶蔽目，要有自己对产品的规划和价值定位。 否则的话，你会发现，加班产品实现后，并没有很多的收益，然而，时间和精力已经付出了，就这样的和时代风口完美错过。

产品的核心是把用户的具体问题，抽象为解决方案，而不是人云亦云，无底线的听从用户的诉求。

2. OKR 和 KPI 结合化管理

使用 OKR 的时候，我们的思维是“我们的目标是什么”；而使用 KPI 的时候，我们的思维第一反应是“我们的职责是什么”。

OKR 的思路是先制定目标，然后明确目标的结果，再对结果进行量化，最后考核完成情况。 本质上和 KPI 管理思路没有太大的不同。 任何一种绩效管理，都是先有目标，对目标进行分解，量化 KPI，然后考核。

以程序员为例：

• 如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是可以引入大数据来做精准推荐；
• 而如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、bug 数、单元测试覆盖率这些；
• 而 OKR 中的 KR，也许会和 KPI 中的某些结果指标重复。

OKR 相对于 KPI 而言，不是一个考核工具，它时刻提醒每一个人当前的任务是什么，这个季度工作完成的怎么样，下一阶段的工作重心是什么。 OKR 最重要的是目标，因此要求目标本身就是正确的，不能凭空捏造或者胡乱猜想，要求 团队 Leader 具备较强的业务理解能力和很强的专业能力。

OKR 主要用于绩效生产，KPI 可以作为绩效评价的工具；以 OKR 为主，KPI 作为辅助； 目标的本质是战略或者说策略，也就是怎么做，是绩效生产环节的核心。

OKR 的实行，能调起员工的主观能动性、创造性，并且能够更快提升职业道德素养和突出的专业技术能力。 OKR 体系下的目标，是由个人提出，然后由组织确定，这点与常规的 KPI 自上而下的方式不同。 因此，在 OKR 过程中，对员工和企业的要求更高一些。

如何制定 OKR 呢？可通过分治法先将问题的复杂度降低，然后根据每个层次得出未来的目标和规划，这个可以参考 SMART 原则来制定：

• S: Specific，指标一定是具体明确的；
• M: Measurable，指标一定是可衡量的；
• A: Attainable， 指标一定是可达成的；
• R: Relevant，指标和目标是有相关性的；
• T: Time bound，一定要有明确的截止期限；

综上：KPI 有其局限性，OKR 也不是万能的，二者结合作用于团队管理的不同方面，才能够发挥更大的价值。

3. 分工明确

不会写代码的测试不是好产品，不想做架构师的螺丝钉不是好骑手。最后，离自己想象的样子越来越远。

在自己工作技能认知的深度基础上，增加认知的广度，是符合 VUCA【 复杂性【Complexity）、模糊性（Ambiguity）、不确定性（Uncertainty）、波动性（Volatility）的缩写】时代的需要的。 但，如果团队内推崇人人都是产品经理，人人都是程序员，那么，这人人都能做的工作，能有什么难度和深度呢？请品一下，请细细品。

所有人都对同一件事情的结果负责，其实也意味着当这件事情结果不符预期的时候，是找不到人对结果负责的。

只有明确各自工作职责和负责事项，那么无论是跟进项目进度还是事情完成情况，就容易得到清晰的反馈。 如果是一个大项目，就拆分细项，每人负责一块，虽然会增加沟通成本，但也会提升团队间的协作能力，以便为将来的大项目做更多成熟的铺垫。

但是，这里的分工明确，虽然是独立负责某项事情，但不能和专断独行混为一谈。 涉及到团队未来一起维护的方案，还是需要和团队内人员一起沟通确认下的。不能一味迎合别人，但同样的，也不能固执己见，仅考虑当下需求就作出未来难以维护的临时方案。

4. 健全的工作流程

可能我们常听一句话，效率最大的敌人就是流程。可是如果我们去掉了流程，那么就会变得更好吗？会不会是流程本身还有需要优化的空间？

工作流程应该考虑哪些方面呢？结合个人经验，暂时只能想到以下几点。

• 明确需求从提出到上线的每个阶段，涉及到哪些部门的协作，每个部门分别做哪些事情。
• 如果研发过程中涉及到需求变更，变更确认流程是怎么样的？比如：确认变更放在当前迭代版本还是下个迭代版本有没客观上的依据可以遵循？
  • 理想情况下，基于团队各成员都有良好的素质的情况下，会针对变更有统一的意见，那么这种情况当然是最好的，但我们知道，这样的情况是很少存在的。
  • 现实中，如果没有有效的变更流程处理机制，那就可能会有两种极端：产品同学无底线的迎合研发同学，或者，研发同学无底线的跪舔产品同学。
    • 前者的话，研发就会滞后业务的发展，这个是确定的。
    • 但如果是后者的话，就会好吗？无论做什么，都是临时迭代和方案，最后做出来的东西呢？对业务同学来说，要之无用，弃之可惜，那种情景可以尽情想象下。
• 对于产品团队来说，有没对产品短期且清晰的规划？长期且方向确定的规划？对于社会需求或法律监管变动有没做预防处理？如果口头上说有，那么有没完整且清晰的文档落地？指的可不是 PPT 哦，PPT 是用来汇报、管理、规划方向的，不是用来实施落地的。
• 对于研发团队来说，除了技术支撑业务以外，有没规范的开发，测试和发布流程？有没线上告警机制？对于研发人力安排情况有没一个清晰且明确的文档可以作为需求迭代排期的依据？还是安排人力看最近加班情况，安排需求排期看产品催的急不急？

等等，还有很多方面，我们就不一一列举。

当然啦，这样的流程随每个团队管理不同而不同，但明确的流程还是需要的。 否则，你会发现，小迭代小项目，还能扛得住。但如果大迭代大项目，简直是洪水猛兽。 可能你会说，我们团队做的就是小项目，别得意哦，只要小项目做的久，你会发现，哪怕一个小迭代，也会让你们疲惫不堪。

5. 重视团队成员的提升

很欣赏一句话：一流的领导者，有一流的员工。二流的领导者，只会有三流的员工。 可能你会说，二流的领导者，招个一流的员工就好了呀。神奇之处恰在于此。一流的员工过来，也会慢慢演变为只能做三流员工的工作。 正可谓是，橘生淮南则为橘，橘生淮北则为枳呀。

• 比如，可以先跟着导师承担项目的一部分功能，后面根据成长情况，逐渐独立负责项目。
• 也可以随着项目的迭代，安排下总结和分享，让团队成员随着项目发展而成长。
• 更好的方式，个人认为是因材施教。根据团队成员感兴趣或者擅长的方向不同，分别做不同的积累和探索。若都不突出，那么能够高质量的完成工作内容，也是很让人期待的事情。要能够发现和挖掘每个人身上的亮点或潜质，并放大他们（并不仅是口头夸赞哦，而是让他们展现出来他们应有的风采）。
• 另外，技术和架构是随业务不断发展而是不停更新和迭代的，所以，可以针对现有框架存留的问题，单独排期（不应该是加班驱动）重构或完善现有的项目，也同样能让团队成员创造价值的同时，自身后面做项目的时候，也会有更好的质量把控。

由于公司或者团队的文化不同，这一点上可能有较大的差异，但还是要有一个良好的团队成员提升机制，对团队未来的壮大提前储备人才，也是很有必要的。 另外优秀的团队成员，也自然会有一些优秀的 idea，和产品的发展就会有良好的互补。即便不是如此，一些优秀的素质也会让团队从长期发展中受益。

6. 良好的工作环境

环境造就人，环境影响人。如果一个人在一个积极向上、团结拼搏的群体里，受到周围人的感染，他也会努力勤奋起来，并且做得到自己的最好。 相反，如果一个人工作在一个工作散慢、不思进取的群体里，同样也会让一个优秀的人变成一个庸人。 因此，建设良好的工作环境，用良好的工作环境来激发人的工作积极性和创造力，是我们提高团队成员工作效率，改进工作作风一个有效的措施之一。

工作环境是指公司员工周围的人和物体。周围的人指自己的同事，老板，以及合作伙伴。周围的物体指的是办公设施，公司福利等。 所以，工作的环境包括自然环境、作业环境和团队环境。

• 自然环境当然就是指你工作时所处的地理环境，包括地理位置、空气条件等。
• 作业环境是指你工作时所处的人为布置的与工作相关的环境，包括设施、设备、工具、周边交通企业、企业福利等。
• 团队环境是指你所处的工作团队的自然人组成的工作氛围，包括团队精神、团队沟通、团队技能等。

公司所在的自然环境和公司提供的作业环境，短期内是很难改变的。 但作为团队 Leader，能为团队成员提供哪些更好的团队环境呢？目前能想到的，有以下几方面：

当然啦，健全的薪酬制度也很重要，但这属于公司层面的文化，这里就不做讨论了。

• 良好的沟通氛围。通过文档，会议，团建等，提升沟通效率。
• 良好的协作氛围。通过明确职责，完善的工作流程等，提升协作效率。
• 良好的晋升制度。透明公平的晋升制度，明确接下来个人技术能力提升的方向并为之努力。
• 公正的绩效考核。透明公平的绩效考核，降低裙带关系的影响，让干活多或者出产质量高的人享受到应有的待遇和认可。
• 良好的技术氛围。定期做技术分享，CodeReview，问题回顾总结等，调动每个团队成员的积极性和参与感。
• 良好的个人发展。部门的发展，也能带动团队成员的发展。而团队成员的自身发展，也能对部门的发展起到积极作用。这样就形成了良性循环。
• 良性的竞争机制。促进团队或者业务健康发展的竞争机制，如统计高质量的分享次数，CodeReview 的亮点梳理等，而不是造成团队成员互不信任的竞争机制，如无规则的争抢名额等。

7. 注重提效工具

工欲善其事，必先利其器。也有一句话叫，磨刀不误砍柴工。

目前能想到的，有以下这些：

• 需求文档跟进工具。如 Tapd 等，便于在线维护需求文档变更管理、跨部门协作、上线部署进度等。
• 企业自建 gitlab。对代码进行统一管理，便于团队协作和代码可追溯。
• 代码规范和语法检查工具。保证开发风格统一，如引入 Eslint，typescript 等。
• 自动化测试平台。基于一些常规的用例和接口，可根据测试用例生成自动化测试脚本，从源头上保证需求的完成质量。
• 基于 gitflow 的自动化部署。减少人为干预，保证上线效率和质量。
• 线上执行报错、接口异常、资源使用完毕等监控告警。便于及时发现问题。
• 基于 docker 的独立测试环境自动部署。便于自测，联调和测试。
• 日志上报平台。可实时在线查看控制台打印的日志，不需手动打开终端或者开通机器访问权限（当然啦，线上要注意日志脱敏，不能打印用户名密码等敏感信息）。
• API 文档管理平台。可进行 API 和数据字典统一管理维护。
• 项目说明文档。可基于 git 仓库里面的 markdown 文件自动生成，这样就保证文档和 git 一起维护，同时保证了没有 git 仓库权限的也可以在线查看文档。
• mock 平台。前后端协作开发过程中，可基于 API 文档平台，自动生成 mock 接口返回数据，提升前后端协作效率。
• 引入构建工作流等工具。如 Vite, gulp, webpack 等，对手动操作的步骤进行自动化处理，如图片压缩，资源文件自动更新等。
• 埋点数据上报平台。包括无埋点和有埋点上报数据统计等，便于统计上线后转化率情况，也可作为后期体验优化的一个重要依据项。
• 流程审批平台。如果有共性的审批操作或者流程的话，那么就需要有一套成熟的流程审批系统，权限和数据统一管理和控制。
• 统一的登录系统。如支持 SSO 登录，多业务系统接入。这样用户信息可以统一管理，避免敏感信息泄露。

以上（或者更多）工具平台的搭建和生成，不是一蹴而就的，所以不能急于求成，而是项目迭代的过程中，慢慢补充和完善的，所以是一件长期迭代和维护的重要事项。

另外，团队不同，项目不同，工作方式不同，那么自然也就有仅适用于当前团队项目的工具。如何生成这些工具呢？这里谈下个人的经验： 从手工繁琐的重复性劳动，通过技术的手段（包括且不限于 gulp 等构建工具，shell 执行脚本，linux 定时执行任务等）抽象出共性的部分，通过不同命令或者配置入口文件等，实现自动化工具。

8. 注重技术沉淀

大家都在口头上说技术沉淀重要，那到底什么是技术沉淀呢？ 个人认为就是对某项或某些技术知识日积月累的学习，逐渐在潜意识里得到系统化的组织、升华，进而可以做到灵活运用、触类旁通。 所以，技术沉淀，不应该局限于应付或者形式总结，而应该从本心出发，输出高质量的文档或项目，直接目的是为了自身提升和总结，正好也方便了他人阅读和借鉴，所以尽量有丰富的实操内容，或根据实际情况可落地的方案。

首先，要清楚一点。别把自己当成圣人，同样的，也别把别人当成圣人。 所以，如果每天被临时需求频繁的插入打扰，如果考虑什么都图快而仅仅考虑临时方案，那么这样的氛围自然就难有什么技术沉淀了。 别期望这样的节奏能培养出好习惯的研发人员，自然也就别期望有高质量的代码。最后你会发现，临时需求变成了永久实现，临时方案变成了永久方案。 世界是公平的，时间和精力放在哪里，哪里自然就会符合预期。一直图快，最后反而怪它不稳，何苦来哉？ 因为这个是团队氛围层面的问题，请参考其他方面的简单梳理，这里仅讨论技术沉淀方面的内容。

技术沉淀，应该关注哪些方面呢？这里梳理下自己的一些浅见。

• 基于业务项目做技术沉淀

  • 首先，我们平时工作中，大多技术沉淀，还是来源于业务项目，所以平时做业务的时候，需要多些思考。
  • 不仅要说明优化方案的思路或者实现，还要描述清楚业务项目的背景，现状，遇到的问题等。
  • 业务发展中经历了怎么样的架构变更，若有必要，也可以描述出来。这样就有逻辑清晰的前因后果。
  • 采用了哪些技术栈，甚至如有必要，也可以描述下为何要采用此技术栈。是为了早日上线，还是为了新技术探索，或者是有稳定前例可以借鉴等。
  • 遇到问题的原因是什么？早期没考虑到，还是后期业务发展暴露了这个问题，或者是架构之初就有了这个考虑，只是人力有限，没有来得及支持等。
  • 问题是如何发现的？客户投诉，还是线上告警，或者是服务器崩溃等。
  • 问题是如何定位的？测试环境复现，线上日志排查，代码提交异常发现等。
  • 问题性质是什么？bug，系统优化，服务器资源不够，还是功能支持等。
  • 问题是如何解决的？浏览器兼容，执行异常处理，性能优化，增加缓存机制，数据库优化，定时任务，临时方案解决等。
  • 最后，总结和展望。这个问题后面是否还会发生？如果会发生，那么如何从源头解决，或者如何更快的时间定位到问题，长期方案跟进等。

• 基于系统优化做技术沉淀

  • 首先，系统优化是长期跟进的事情，不是一蹴而就的事情。所以要从长期和短期的角度去分析和看待遇到的问题。
  • 要描述清楚系统设计变更的来龙去脉，而不仅仅是一笔带过，或者仅用几句话描述做了哪些方面。想象下，自己站在一个新人的视角，是否能清晰的捕捉到所要表达的内容，所以，首先从逻辑上先让自己能够信服很重要。
  • 内容不局限，只要对自己有提升或对他人可借鉴，都可分享。UI 兼容性，性能优化，算法优化，运行部署，环境搭建，实现原理，提效工具，甚至代码规范等，多多益善。
  • 记录下自己实现或者理解的过程中，有哪些耗时耗力或者让人费解的地方，这些可以在沉淀的过程中重点说明。因为有的时候，思维方式或解决方案胜过具体实现。
  • 如果涉及点较多，一篇分享不完，那么就需要建一个大纲，先汇总归纳总结，然后再对单个知识点进行详细解析。

• 以开源项目形式做技术沉淀

  • 首先，开源项目应该基于前面两者来搭建和实现，否则就会缺少长期维护，那么也就达不到开源项目的初衷。另外也是对前面两者的抽象，站在一个更高的高度去重新设计和解决已存在的问题，让自己和团队都得到升华。
  • 和业务逻辑解耦。这样才会跳出业务的局限性，从全局和整体去重新认识一下项目。
  • 减少依赖。如果有项目强依赖，应该提前说明。以及如何引入和协作运行。
  • 支持选项做成可配置。减少写死的情况，比如支持的功能选项通过外部参数来传递，而不是通过修改源码的方式。
  • 文档说明。从部署到使用，以及一些常见问题的解答。
  • 开放的社区。开源项目涉及的生态打通，比如引入官方推荐模板，脚手架，或者用到哪些开源组件库，可跳转到对应的官网，便于查询，而不需要到处查资料了解如何使用。

综上，个体技术沉淀服务于团队，而团队技术沉淀也同样正向反馈于个体，个体间也能相互学习和借鉴，这样就形成了正向反馈。

9. 做好技术规划

技术是为业务服务的，但不应该仅仅满足于为业务服务，还应该想办法如何用科技的手段促进业务的发展。 技术规划是基于业务规划和业务今后所要达到的未来愿景的。但如果没有业务规划，那么就免谈技术规划了。 如何做业务规划呢？这个就超出本篇范围了，所以这里不做讨论。 但如果抱侥幸心理，觉得不需要业务规划，照样能做出前瞻性的系统来，那本篇就可以略过了，请恕我才能有限，无法给出可实施性的建议。

如何做技术规划呢？从以下几方面给些浅见。

• 清晰业务规划

  • 清楚业务场景。如果是新业务线，需要清楚业务场景需要包含哪些，如是否有短信推送，邮件通知，流程审批等。这样做技术决策的时候，就会判断有哪些是可复用现有的设施。以免做出重复的产品，造成资源浪费。
  • 确定终端类型。根据目标客户和产品的使用性质，如：H5、小程序、公众号，APP 等其中一端或者多端并存。或者循序渐进，先支持其中一端，再根据迭代情况支持多端。
  • 按需分配人力资源，确定排期。产品是不断迭代的过程。所以不能一蹴而就，要有规划的排期实现，尽量避免未上线就花太多的时间和精力想做一个终极版本出来。
  • 确定需要的硬件资源。根据已有业务或者已有统计，预估上线后的访问量，以免上线后多申请浪费，少申请宕机的情况。
  • 技术方案确定。比如有刷脸的场景，那么就需要提前调研稳定的刷脸识别方案，自研还是第三方。技术方案决策提前，以免开发过程中发现实现不了，而造成产品延期或者临时架构调整的情况。
  • 技术栈储备，比如：
    • 业务项目未来会有发短信营销产品的场景，那么就需要提前有稳妥的方案，进行短信跳转 APP 或者小程序的实现。
    • 业务项目偏数据分析方面的话，那么就需要提前储备大数据分析相关的技术了，比如指标如何生成和维护，数据怎样实时和按需汇总统计等。

• 明确架构设计

  • 首先，高可用高并发高稳定性的系统设计，并不是一定就适合当前项目或者产品当前阶段。所以适合的才是最好的，要视情况进行取舍。且其完善也是一个长期优化的过程，不会一下子就支撑未来几年的业务，但也要随业务的发展不停的做调整。但前期还是要做好基础工作，以便更好支持长期的业务发展和迭代维护。
  • 明确数据从前端到数据库处理，数据流是怎样的。这样就知道在哪个环节可以提前投入人力进行环境的部署，哪个环节开发阶段需要做好注意事项等。
  • 确定后台技术栈。比如涉及到 Java，go，redis，mysql，nginx，node 等。已有的基础设施或者业务框架是否支持业务实现，如果不支持的话，是否在目前现有基础上扩展，还是启动一个新的项目。
  • 确定数据库和表结构。根据需求和业务场景，确定数据库是申请一个还是基于已有的。表结构设计，如用户表，权限表，账户表等，明确各个表的职责和功能。
  • 确定缓存设计。如果预期用户访问量不大，或者排期比较紧，那么可以先不用考虑。如果考虑的话，那么对于配置信息和不常更新但查询又频繁的表数据，是否有完善的缓存同步和缓存更新的机制。另外也确定下缓存方案所采用哪种技术方案，如 redis，memcached 等。
  • 确定前端技术栈。比如 vue，react。也确定 UI 组件库，自研还是第三方，如 element-ui，vant 等。引入插件等也需要提前调研和确认。
  • 复用已有或者建设提效工具，具体参考注重提效工具章节。

• 满足业务需要

  • 避免过度设计。基础设施搭建好后，依据当前业务的实际情况，按需进行业务系统设计和实现。比如：
    • 产品提了需求是用户能够问题反馈。那么技术方案就是给用户增加一个提交的入口，管理端能够进行汇总和查询即可。这时候就不必要做一套 IM 实时在线客服聊天系统出来。
    • 两者的系统复杂性是不一个维度的。且维护成本也是不一个数量级的。
  • 避免临时方案。研发前要先确认下需求的背景和目的，进而明确需求下一步要做什么。这样：
    • 就可以做一个长期的方案，满足需求未来的设计。如果只看到现阶段的需求或者为了紧急上线，那么就会容易做出一个临时方案出来。
    • 如果临时方案只是涉及到逻辑部分，那么后面迭代做好优化工作和持续跟进也是可以的。
    • 但如果临时方案涉及到数据的存储和处理，那么就确实需要想一个长期的方案来代替。因为后期的数据兼容和迁移工作，本身也是一件耗人力和有风险的事情。
  • 保证产品质量和运行稳定性。
    • 接口参数校验。前端传参，后台要做数据校验，不要完全信任前端传过来的数据。如果发现数据异常，要做告警处理。或者格式化处理后再存储到数据库。
    • 常规的安全防御。如预防 XSS 和 CRSF 等常规的安全攻击。
    • 越权校验。比如 A 用户访问 B 用户的订单，这种情况要告警处理，看下是返回数据异常还是被攻击。
    • 接口返回数据校验。对应接口返回的数据，如果明确要返回，那么前端要做下异常兼容和报错上报，以尽快发现接口逻辑层面的问题。
    • 常量做到配置化，别各个地方写死。以防逻辑修改的时候，漏掉的情况。
    • 公共方法的封装和公共组件的抽象。以便模块化维护和调用。
    • 对于复杂的逻辑和重要的方案和参数说明，要增加注释，便于团队协作和维护。另外，修改的时候，别仅修改代码，记得把注释也一同修改。保证代码逻辑和注释是一致的。

• 促进业务发展

  • 探索新技术在新业务场景下的应用。关注最新的技术进展，如微信小程序支持短信跳转，那么就可以提前尝试是否在生产环境中应用。
  • 通过工具或者自动化的手段，代替重复性劳动。解放劳动力的目的，不是让员工无事做，而是把劳力释放出来，将精力和时间投入到更有意义的事情上。
  • 通过匹配规则的方式，代替人工决策。比如只要满足指定的一些规则，那么就触发系统自动执行，触发不到的情况再转到人工处理，提升服务效率。
  • 通过数据分析的方式，优化产品设计或体验。比如通过埋点上报，统计交互转化率，优化产品设计流程和用户体验。

10. 提倡有效加班，减少无效加班

表白是胜利的凯歌，而不是冲锋的号角。 既然表白可以区分有效表白和无效表白，那么我认为，加班也应该可以这样理解，是可以区分有效加班和无效加班的。

有效的加班，应该是为了确定方向的产品或技术需求的早日上线而努力。 而不应该是天天疲于到处填坑和救灾。如果是这样，那么就考虑下是不是单独迭代做下系统优化工作了。 也不应该是天天疲于临时需求的变更。如果是这样，那么就考虑下是不是产品规划环节出了问题，是否如同无头苍蝇般的乱飞？或者是否命中了研发无底线跪舔产品的情况。抑或是两者皆有。

作为团队 Leader，不能因为下面的产品团队或者研发团队归自己管，所以就恨不能让他们一天工作二十四小时，如果团队成员有按点下班的，就觉得公司好像亏大了似的，因为他们本来还能多梳理一个文案，或者多写一行代码的。 有这样的想法，个人认为无可厚非，但通过不断的低质量的需求让团队成员忙绿的方式，来满足自己的控制欲，就有些说不过去了。 这种情况，要首先反思下，自己是不是应该要多做下产品或者技术的短期梳理和长期规划。 如果偶尔加班，可以理解，但若长期这样，和压榨员工何异？

但问题来了，怎样的规划叫长期，怎样的规划叫短期？根据过往情况，应该是很少人愿意主动承认的吧（毕竟谁也不会觉得自己是一个缺少规划或者过于有主见的人）。 那么能否通过其他的方式来判断什么是有效加班呢？根据自己的观察和经历，其实也是有一些规律可以体现的。

暂能想到的，是用统计法来分析和体现。 我是这么思考的：既然特定时间单个个体行为不具有代表性，那么就时间段拉长了再去看，那么平时很难注意到的细节就会展现出来。 以后有其他更好方式再继续补充吧。

• 闲忙平稳有度

  • 产品需求分阶段，不同阶段有不同的重点和目标。同一阶段，需求有优先级，根据当前人力安排情况，进行取舍。紧急且重要的，优先排期；不紧急或者不重要的就延后排期。
  • 增加研发需求池管理。在需求池里面的需求，必须是确定的需求。有明确的文档，有确定要解决的问题，有完善的交互和视觉等研发必须的基础条件。进而根据人力安排情况，对已确定的需求进行排期。
  • 增加评估需求池管理。对于未完善的需求，比如需求评审阶段，需要多方参与评估的，或者需要待技术方案确定后才明确需求设计的，就需要在单独的评估需求池中统一管理和维护。
  • 增加技术需求池管理。研发团队对于代码重构和技术优化的工作，也需要确定优先级和确认排期。和研发需求池同步管理。尽量避免夹带发布或者纯靠加班时间来做这样的事情。
  • 这样，已确定的需求、未确定的需求还有团队内部的技术需求，就进度可控，一目了然。不管什么时候，都要保证需求池里面的需求不能断。这样才能保证研发进度的平稳进行。避免忙的时候忙死，闲的时候闲死的奇葩现象。
  • 如果需求池里面的需求确定排期后，有紧急又重要的需求临时插入进来，那么就更新需求池里面需求的排期。把不紧急或者不重要的需求延后，当前需求排期提前。
  • 根据研发人力加班情况，可以对需求池里面需求排期情况动态调整。产品同学也要提前做好需求的准备和确认工作。
  • 这样责任划分就比较明确了。
    • 避免了研发天天找产品要不确定的需求，还吐槽需求文档不清晰，最后一堆临时方案就上线了。结果造成架构不是设计出来的，而是改 bug 改出来的。
    • 也避免了产品同学常常吐槽：我都没梳理清楚就找我要需求，结果我最后把需求梳理好了，你们为了早日上线，又没实现我想要的效果，难道我需求不梳理出来，你们就没活干了吗？我可是不止一次听你们团队成员说代码目前很乱，也是需要优化的呀。

• 加班收益相近（大于更好）加班成本

  • 以一个月或者两个月为维度，统计这段时间的加班情况，另外也同步统计加班对应的需求情况。
  • 评估下加班做的需求是否带来了访问量收益、业务量收益、投诉量减少、转化率增高等正向指标的增加。
  • 如果这一两个月经常加班，但以上指标没有一个是增加的，那么实在是不应该了。这个时候要反思下是不是需求质量有待提高，或者业务方向有待调整？
  • 如果业务实际情况所致，短期内确实难以统计以上指标，那么也是可以理解的。毕竟谁也不是一开始就知道路往哪里走的，都有一个探索的过程。那么就需要再统计下是否有以下情况发生了。
  • 加班一两个月，支持的需求，变更的频次和幅度情况。频次指的是朝令夕改，幅度指的是逻辑变更。如果偶尔几次，可以理解，毕竟政策和现状都非一成不变。但变得频繁的话，就要反思下是不是需求前期没有梳理好的缘故。
  • 如果以上统计结果是消极的，你会发现，百分之八十的时间和精力，仅做了百分之二十的事情。其实是很不划算的。并不是说螺丝钉不能往死里面干，而是往死里面干也要干的值才行呀。
  • 最后，想为广大螺丝钉表达一句心声。如果方向是对的，哪怕慢一些稳一些，依然是进步的。但如果方向不确定的情况下，为了急于求成，就无头苍蝇般乱飞，那就...（还想螺丝钉对你么么哒，那估计是不太现实的。）

11. 对事不对人

个人感受: battle 的过程，也是其乐无穷的过程。当然啦，前提是，自己的观点能够先把自己说服。

好的讨论氛围，应该是有不同角色的同学进行相互 battle 的。甚至是相同角色的同学，也建议若有不同异议的情况，也可以进行 battle。 不应该因为对方职级比自己高，或者来的比自己早，就对自己所坚信的理念或者理解让步。 但是，battle 的过程中，也要学会倾听他人。倾听他人的逻辑和思维，尽量减少情绪上的影响。 最后，你会发现，battle 的过程，会让你得到成长。 而成长的过程中，刚开始，可能是他人带着你成长，但我相信，终有那么一刻或者有一天，你的阅历和理解会帮助到业务发展或者团队氛围。

那么，疑问来了，battle 明明影响了讨论进度，为什么还会建议呢？

当然啦，成也萧何，败也萧何。可能这也是为什么，有些为了追求快和高效的同学不喜欢其他人表达异议甚至也不接受异议的原因吧。（具体就不做评论了，要不然我怕被掐死。哈哈，开个玩笑，没这么夸张啦。）

首先，学海无涯，认知的过程，是一天天积累而来的，不会短期内产生质的改变，我更相信是从量变到质变的过程。 但，知识亦无界，看的书不完全同，经历的事不完全同，每天的思考也不同，所以不同人所以认知的范围和侧重点自然也就不同。 综合来说，就是每个人的认知都有其局限性。

更何况而今不同角色又来自五湖四海的同学同聚一堂了，交流起来能碰撞出怎样的火花，这是多么让人期待呀！

根据个人感受和经历，拿产品和研发同学的 battle 为例，这里来做下分析。

这里的产品，是指产品策划、交互、视觉的综合体，不做区分讨论。

• 产品同学做事的时候往往是先局部再整体堆砌的过程，因为不管是汇报的时候单页来讲解，还是考虑到客户进入一个页面的时候可以做哪些事情等因素，那么设计一个页面的时候，自然就希望：

  • 一个页面能展示的信息越充分越好；
  • 希望一个页面可做更多的操作；
  • 考虑单个页面如何组合比较好，如何视觉搭配比较好；
  • 之前刷脸页面展示信息不够，这次我要定制一套有个性化的刷脸页面。
  • 等等；

• 但研发同学具体开发的时候恰是先整体再局部拆分的过程，因为需要抽离出公共页面，公共组件，哪些判断逻辑需要封装，哪些展示需要抽象等，那么梳理业务逻辑的时候，就会发现：

  • 多个页面有同样类型信息展示，其实是可以用相同布局和按钮样式的；
  • 同样内容的组件其实之前已经实现了一个，本次复用即可，不需要两套并存。不过要确认下样式以新的为准还是旧的为准；
  • 有页面信息比较冗余。因为有前面入口页面已经有同样风格和内容的信息了。且如果有多个地方的话，那么后面迭代的时候，就需要考虑多个地方；
  • 刷脸页面已经有一套了，复用即可，不需要再定制一套新的刷脸页面。可以在原有基础上增加些文案展示即可。
  • 等等；

综上，因为各有各的考虑，所以结果自然不会面面俱到。那么就需要有一个 battle 的过程，进行取舍和沟通。 那么，后面再做类似工作的时候，自然也会把之前未考虑到的因素考虑在内。 而如果一开始就没有 battle 的过程，那么一些潜在的问题就一直会保留在那里，等待有缘人处理。但有缘人在哪里呢？没有人提，那就谁也不知道。

所以呢，工作中我们如果遇到 battle 的情况，请给予多些理解和支持，因为他们的初衷是为了产品变的更好。 而对于 battle 双方来说，请给予对方多些倾听和尊重，因为在自己看不到的地方，也是有一些对方的思考在内的。

12. 关注业务发展

业务发展，人人有责。一荣俱荣，一损俱损。覆巢之下，安有完卵。

不管各自角色是怎样的，都要关注下业务的逻辑和发展趋势，这样就更能找到自己的定位和努力的方向。 学到用时方恨少。经常反思下，在一个不断发展的业务团队中，自己的能力还需要哪方面的提升，更好的为业务服务。 不能因为自己是个螺丝钉，就觉得业务和自己无关，只要听从就行了。自己对行业趋势或竞品业务模式多了解一些，那么决策的时候，自然就会多稳一分。

比如业务同学想开发一个营销页，那么作为技术人员，就要知道 H5、小程序等技术方案在各场景下各有什么优缺。 比如 H5 是无法绑定登录态的，每次需要重新登录。小程序是微信小程序，还是头条小程序，面向的投放渠道不同，自然登录态体系也会不同。等等。 和业务同学多多探讨，认知相互补充，在各因素综合评估下，那么才会有一个稳妥的方案。

综上，作为技术人员，要是能从技术的角度提前发现潜在一些存在的问题，或者为业务的决策贡献一些有价值的建议，那也是一件让人期待的事情。

三、参考

• 如何打造一支低效技术团队？