如何在高速发展的同时，保持工程师文化

原文链接：How to keep your engineering culture while scaling your business

一个成功的科技创业公司始于强大的公司文化。如果有一群人你特别想保持激励，那就是建立你的产品的人。

强大的工程师文化不是创业界的乒乓球桌、免费午餐和休闲星期五的形象。建立产品的好处并不在于流程。对我们而言，工程师文化意味着积极的团队成员始终如一地创建和维护高质量。

强大的工程文化需要建立一定的系统，使开发人员对他们交出的代码负责，同时利用团队成员的独特技能和个性。有哪些框架可以开始？以下是我们的一些方法。

大小很重要，只是不符合你的想法。

作为一家拥有40多名开发人员和设计人员处理多个客户项目的公司，我们拥有自主团队，其中包括项目经理（PM），技术主管，拥有 1-3 人的开发团队以及指定设计师来跟踪项目。使用基线标准的开发人员，您应该能够计算客户想要构建的产品所需的天数 - 如果他们想要更快，那么您可以让更多人使用它。在较小的范围内，允许我们的开发人员对他们正在构建的内容拥有所有权，而不是来回处理（即使使用 Github）。 Pull Request 由技术主管合并，因此其他人将始终检查代码。合并完成后，我们的项目经理将测试并批准该功能。当我们说大小时，我们指的是制作出色产品的最低可行团队成员。小团队结构有助于改善：

重点：小型团队有一个固定的目标和截止日期，高级团队成员可以花更多的时间来支持每个人
凝聚力：拥有 3-5 人团队，每个人都可以随时了解所有工作部分
互动：小型团队可以更好地协调面对面会议，并分享临时信息
可见性：小型团队可以更轻松地捕捉路障，冲突和潜在问题
管理：小型团队允许一个人成为联络点，减少文档、文书工作和官僚作风
清晰度：团队能够跟踪所有成功、期望、失败和状态变化（即通过每日站立）

无论谁想到它，一个好主意都是个好主意。

正如 Intuit 的联合创始人 Scott Cook 所解释的那样，“传统管理优先考虑项目，并将人员分配给他们。但是，越来越多的人认为，管理者并不是这个想法的源泉。“ 在辩论想法和解决方案时，资历应该无关紧要。开发中的许多任务非常简单，但您如何决定使用一个框架而不是另一个框架呢？我们应该使用更新的库来更好地满足项目要求还是更好的文档库？虽然技术负责人经常根据经验提出这些问题的解决方案，但应该积极鼓励整个团队做出贡献。我们的项目经理将在当天浏览每个开发人员的项目，开发人员会概述他们将要做的事情。团队的其他成员可以提供其他想法或资源，例如有用的库。这种基于任务的报告使每个人都有机会每天做出贡献，无论他们是新的初级开发人员还是技术主管。结论并记录在 Waffle.io 上，它跟踪 GitHub 上的问题。

不要找借口不分享。

公开辩论对于汇集想法至关重要，无论它们是否会变得激烈。在 Oursky，错误传达通常是一种破坏的来源，而不是争论性的行为。这种做法的形式是人们没有说出由于感知到的资历，人们没有要求澄清，和、或开发人员没有在他们知道没有意义的请求上挑战 PM。透明度有助于在上述情况下做出贡献。每日站立会议中的面对面交流减少了个人冲突的可能性。明确记录 GitHub 上的辩论，问题和解决方案可以帮助团队成员专注于问题，而不是人。当整个团队都可以贡献并获取信息时，每个人都有更好的机会被听到，从而得出结论。该文档对于分布式团队尤为重要，因此远程同事可以了解全局。通过满足您的团队成员的独特需求，并为他们提供多种渠道，在公共渠道中表达他们的贡献，您可以显着降低个人冲突的可能性。而不是人们需要彼此相处，你创造了一种热衷于向同龄人学习的人的文化。

告别代码所有权。

虽然代码所有权肯定有它的特权（控制和信用到期），但成功的小团队文化并不适合它。放弃代码所有权可以让开发人员考虑可读性和长期可维护性。以下是 Oursky 的典型开发流程，以确保代码质量：

1）PM 分配任务，开发人员总结他们在站立会议上会做些什么。
2）开发人员在 2 天内完成任务（更长的任务进一步细分）。
3）开发人员在需要时咨询团队成员（特别是 Tech Lead）。
4）开发人员在问题结束时发送拉取请求。
5）技术主管检查并合并拉取请求。
6）PM 检查功能是否实际有效，然后更新客户端。

作为一个团队的思考鼓励开发人员在他们去的时候互相咨询，即使他们认为这会产生长期影响的细节也是如此。我们的一位开发人员询问 “设置” 或 “设置” 是否应该是正确的术语，并决定重构他的代码，因为他希望确保其他人在将来能够理解。开发人员从 6 个月前完全忘记了她 /他的代码的逻辑和上下文，这是很常见的，因此，作为一个团队的思考，可以执行命名等最佳实践。

优化迭代速度。

快速迭代有两种形式。第一个是官僚主义，或者在整个公司内部执行快速有效的流程，第二个是实际的产品开发。缓慢的官僚程序，例如让每个级别的管理层批准新的代码或功能都是一个瓶颈，可能会严重降低启动速度。它还使远离产品的人（即高级管理人员）掌握决策权，这意味着如果存在分歧，需要召开更多会议以加快速度。此外，具有长周期和大修的产品，意味着工程师无法看到他们的进展结果（即用户正在使用他们的产品）。如果项目落后，两者都是时间投资风险和心理消耗。我们建议使用与 GitHub 集成的 Waffle 来帮助团队每天查看需要解决的问题。PM 负责帮助团队确定优先级并委派（包括外包）任务，以便开发团队保持专注。PM 接收新的功能请求，并通过以下过程完成：

流程：

1-2 周 Sprint：由客户端引入的一系列功能和/或错误定义
如果是请求的功能，请确保有足够的详细信息可供使用。如果没有，请首先引入设计团队以提供其他 UX 和 UI 支持。
如果是肤浅的功能，比如复制内容，则委托给作家。
如果问题是 bug，请在将其分配给开发人员进行修复之前，确保它是可重现的。
如果问题变得太大，请将其分解为不到 2 天。

虽然我们是一家数字产品代理商，但是这个流程的准系统可以被提升并放置在任何工程环境中。快乐的建筑！

techlead