Authing | 如何打造一个高效的分布式研发团队

开发者群体是个与其余工种不一样的群体，他们热爱创造，工做是为了知足本身的创造欲，是彻底自驱的；而优秀的开发者，彻底不受地理位置限制。

这就是咱们要建设分布式研发团队的缘由 —— 一个多样化的团队是更好的团队。

咱们成功建设了一个分布在中国五个省市的高效研发团队，咱们构建的产品，服务全球七个国家和地区的用户。当来自各个地区，拥有不一样背景的人联合起来后，极大的拓展了咱们的力量。本篇文章将总结咱们在建设一个分布式研发团队时所面临的问题和解决方案。

分布式研发团队相比坐在一个办公室里的团队，存在着更多问题，好比工做时间不重叠、团队融合和激励，但实践来看，最须要解决的是如下三个问题：

1. 协做问题；
2. 项目管理问题；
3. 价值观和文化的传递问题；

协做问题

当你和同事坐在同一间办公室时，吼一嗓子就能获得回应。但在一个分布式团队中，常常会出现消息未读、电话没人接的状况，分布式协做是一个自由的环境，这种状况是容许出现的。固然，这种事情并不说明项目会获得延期，由于某个模块的开发者会在其余时间完成该作的事情。但这样的状况每每会使得不到回应的人抓狂，软件系统变复杂后，模块之间每每相互关联，若是没有获得及时回应有可能会致使工程出现问题。

沟通上的另外一个问题是团队之间可能没有见过，不过这在开发者群体中不是什么大问题，开发者已经习惯了在 Github 上向陌生人提 Issues 或者帮助陌生人修复 BUG。

从实践中来看，协做主要包含两点：沟通和信息同步。为了保证高效的分布式协做，咱们制定了如下基本的协做原则：

1. 由一我的来起草月计划，其余人一块儿作修改和补充，周计划围绕月计划进行；
2. 每周一上午一次视频周会，同步上周的进展和本周的计划；
3. 每一个人以去中心化的方式（非项目组织者统一指挥）制定本身的计划，每一个计划必须激进（猛跳可以到的目标）和有明确的 Deadline；
4. 产品开发容许延期和变更，如有延期或变更，在群内同步缘由和后续计划，作到每件事必有 Deadline；
5. 内部测试不追求完美，如有可预览的进展，及时在群内同步并请你们测试（咱们没有专门的 QA，遵循的原则是由非模块开发者来进行测试）；
6. 使用高效的工具作即时推送，对信息进行最大限度的同步；

这须要给每一个人一点时间来适应，一旦适应好以后，协做效率会和和同事在一间办公室同样甚至更高。

项目管理问题

分布式协做另外一个大的问题是项目管理，咱们由开发者本身决定每个月每周天天要作什么，并按计划进行，这一点基本上没有什么问题，参与分布式协做的人必须是可以自我管理的人。出问题的环节也不在这里，而是需求质量。

咱们出现过至少两次需求不合理致使返工的问题，这对开发者本人和项目自己都是很大的损耗，每当出现这种状况时，团队便会出现抱怨的声音。这类问题每每有以下几种场景：

1. 产品经理在提需求时没有想清楚，开发者 review 时也没有思考彻底，作了一半后发现技术上是不符合逻辑的；
2. 开发者在写方案时没有将方案对齐到具体的参数、返回结果和报错信息，同时也没有其余人及时留意到这个问题，致使实际使用时须要进行二次修改；

这个问题的解决方案也很简单粗暴，就是由每个干系人仔细讨论，所以咱们制定了一个流程：

1. 模块负责人在能够在线编写和协做的文档中起草方案；
2. 相关干系人在文档中评论，提出问题和疑惑，将解决方案对齐；
3. 全部疑问和边缘条件都解决后，咱们将全部需求细化到任务管理工具上并开始开发；

这个流程虽然看上去多了些扯皮的工做，可是能显著提升需求质量。

项目管理上另一个很重要的点是使用「高效的生产力工具」。你可能会想「生产力工具」原本就是高效的，前面再加个「高效」，是否是重复了。其实否则，生产力工具不少，选择最好用的工具将事半功倍 ——工欲善其事，必先利其器。

咱们核心只使用了两款工具：

1. Tower —— 用来作具体的项目执行；
2. Lark 飞书 —— 用来作即时沟通、文档协做和 ChatOps；

除了这两款，还有邮箱用来和海外用户交流、Git 用来管理代码，不过这属于基础工具了。

工具链保持简洁很重要。前段时间，咱们在 Tower、倍洽、企业微信、Notion、石墨和Google Docs 之间处处切换，直到有一天团队再也受不了，咱们争执了一番后将即时沟通、文档协做和 ChatOps 换到了 Lark 上，Tower 不变依然用来作项目执行。咱们本有换掉 Tower 的打算，不过鉴于更换成本，咱们仍是选择了留在 Tower 上，想换掉 Tower 的缘由是 Tower 不提供 API 让咱们能在群聊内即时将任务同步到看板中，它只能单向推送，这不符合 ChatOps 的设计理念，有时也会耽误咱们的生产效率，由于咱们还要在网页和聊天窗口中切换。

Lark 的 Notice Bot 颇有用，咱们的 ChatOps 都是依赖 Lark 的 Notice Bot，咱们在内部打造了一个「推送」的世界。

Git 消息推送

响应时间过长或服务不可用推送

用户反馈推送

小程序反馈推送

SDK 需求推送

这些都属于一个研发团队中比较基础的操做，但当你处于一个分布式协做团队中时，由于看不到彼此在干什么，所以当全部信息即时推送、即时同步时，会让团队每一个人都有安全感。咱们的研发团队是一个紧密型小组，咱们紧密合做，构建并交付解决方案。这种推送让分散的小组对他们正在构建的东西、什么能提升效率有清晰的认识，并具备主人翁精神，这让它很是适合于团队的分布式性质。

价值观和文化的传递问题

最后一个问题是价值观和文化的传递问题，这是最难的问题。不管是沟通问题仍是项目管理问题都能用流程和工具来解决，而价值观光和文化只靠这些是不够的。

首先说一下咱们团队的组建过程，早期的开发者是大学同窗，后来有从用户转化过来的开发者，咱们的用户爱咱们的产品，从用户变成了这款产品的创造者和维护者。此外，全部不涉及商业核心的代码，咱们都是开源的，由此也吸引了一批开发者为咱们维护各语言的 SDK。

固然，咱们仍是要依靠一些现代工具。

首先是视频会议，咱们使用的 Lark 会同步每一个人的日历（咱们但愿每一个人都能将本身的日程信息化，这样会很是便于管理），这样会议协调会很容易，同时咱们保证每次会议你们都能露脸，这让每一个人都能见到其余人的神情、动做，虽然隔着屏幕，也比看着聊天框里的文字和表情要亲近一些。

除了这样的工具外，就是天天的具体细节。尊重和信任是对人最大的激励、鼓励每一个人分享的团队文化才是正向的。同时还要鼓励每一个人把本身的能力贡献给项目和组织，并得到事业上的发展。鼓励每一个人互帮互助，没有等级，团队的工程师能够直接开喷领导者（我不是说开喷是好事，而是容许这种状况发生）。

这些都是经过线上交流得到的，线下活动也是必不可少的。好比每月邀请你们聚到一块儿娱乐、一块儿喝酒、一块儿打游戏、每一个节日互送礼物。

总之，让你们成功，让项目成功，是构建组织文化和价值观的根本目标。

最后，请容许我介绍下咱们在作的事情

咱们的组织名称叫「蒸汽记忆」，英文名为 Steamory，这个名字是「Steam」 + 「Memeory」的合成词。咱们在开发下一代云原生操做系统，咱们的计算平台以用户身份为中心，旨在让用户拥有本身的数据，控制本身的数据，同时数据能够在多个平台重复流转使用。咱们计划中的三大产品线为「身份认证云」、「开放关联数据云」和配套的「开发者工具」。

目前已经上线的产品为「身份认证云」，开发者遍及全球七个国家和地区，客户覆盖教育、出版社、知识图谱、聊天机器人、金融、云计算、物联网和营销自动化等多个领域。

Authing 身份认证云的用户分布图

最后的最后，若是你对咱们的工做方式或者产品感兴趣，欢迎扫描下面的二维码和咱们聊聊～

相关阅读

• Authing 是什么以及为何须要 Authing
• 咱们为何坚持作 ToB 的慢生意
• Authing 知识库

欢迎关注 Authing 技术专栏

什么是 Authing？

Authing 提供专业的身份认证和受权服务。
咱们为开发者和企业提供用以保证应用程序安全所需的认证模块，这让开发人员无需成为安全专家。
你能够将任意平台的应用接入到 Authing（不管是新开发的应用仍是老应用均可以），同时你还能够自定义应用程序的登陆方式（如：邮箱/密码、短信/验证码、扫码登陆等）。
你能够根据你使用的技术，来选择咱们的 SDK 或调用相关 API 来接入你的应用。当用户发起受权请求时，Authing 会帮助你认证他们的身份和返回必要的用户信息到你的应用中。

Authing 在应用交互中的位置

• 官网：http://authing.cn
• 小登陆：https://wxapp.authing.cn/#/
• 仓库： 欢迎 Star，欢迎 PR
  • https://gitee.com/Authi_ng
  • https://github.com/authing
• Demo：
  • https://sample.authing.cn
  • https://github.com/Authing/qrcode-sample
• 文档：https://docs.authing.cn/authing/

欢迎关注 Authing 技术专栏