高效率工程团队大解密｜Pinkoi 团队协作与自动化实践提升工作效率

Click here to view the English version of this article.

點擊這裡查看本文章正體中文版本。

基于 SEO 考量，本文标题与描述经 AI 调整，原始版本请参考内文。

---

2021 Pinkoi Tech Career Talk — 高效率工程团队大解密

Pinkoi 高效率工程团队大解密 Tech Talk 分享

高效率工程团队大解密

2021/09/08 19:00 @ Pinkoi x Yourator

My Medium： ZhgChgLi

关于团队

Pinkoi 的工作方式是由多个 Squad (小队)组成：

• Buyer-Squad ：主攻买家端功能

• Seller-Squad ：主攻设计师端功能

• Exploring-Squad：主攻浏览探索

• Ad-Squad：主攻平台广告

• Out-Of-Squad：主要做支援、Infra 或 流程优化

每个 Squad 会由各 Function 队友共同组成，有 PM、Product Designer、Data、Frontend、Backend、iOS、Android…等等；长期、持续性的工作目标都会由 Squad 来完成。

除了 Squad 之外也会有些跨团队 Run 的 Project，多半时中短期的工作目标，可以是发起人或任何职务的队友担任 Project Owner，任务完成后即 Close。

文末还有 关于 Pinkoi 的文化是如何支持队友解决问题 ，如果 对实际做了什么内容不感兴趣的朋友，可直接到页底查看此章节 。

人数规模与效率关系

人数规模成长跟工作效率的关系，待过 10 个人的新创到百人的团队（还没挑战过千人）但是光从 10 跳到 100，10 倍的差距在很多事上就很有感了。

人少，沟通跟处理事情都很快，走过去讨论好，等下就可以马上给你了；因为「人与人的连结」相当强烈，彼此都能同步协作。

但在人多的情况，很难这样直接沟通，因为一起协作的人变多了，每个都走去讲一整个上午就没了；还有大家互相协作的人也很多，事情只能排优先顺序来处理，不是紧急的事不可能马上给你，这时候就要非同步的等待，去做其他事情。

更多职务的人加入，可以让工作分工更细致专业、提供更多产能或更好的品质、更快的产出。

但如同开头说的，相对的；会有更多与人的协作，协作相对的就是会有更多沟通时间。

还有小问题会被加倍放大，例如本来 1 个人每天都需要花 10 分钟贴报表，可以接受；但现在假设变 20 个人，乘下来每天都要多花 3 个多小时贴报表；这时候贴报表这件事的优化、自动化就会很有价值，每天省 3 小时，一年工作日抓 250 天，就要多浪费 750 小时。

人数规模成长，以 App Team 为例，会有比较密切协作的有这些职务。

Backend — API、Product Designer — UI 这不用讲，Pinkoi 是国际级的产品所以在功能上的文字都需要 Localization Team 帮我们翻译，还有因为我们有 Data Team 在做资料搜集分析，所以除了开发功能，还需要与 Data Team 讨论事件埋设点。

Customer Service 也是会经常与我们有互动关系的 Team，除了使用者有时会直接透过商城评价反应订单问题，更多的时候是使用者直接留下一颗星说遇到问题，这时候也需要请客服团队帮忙做深入的询问，是遇到什么问题？我们怎么帮助你？

有以上那么多的协作关系，意味著很多沟通机会。

但要记得，我们不是在逃避或是尽可能减少沟通，优秀的工程师沟通能力也很重要。

我们要做的事是聚焦在重要的沟通上，如创意发想、需求内容跟时程的讨论；不要浪费时间在重复问题的确认，或发散模糊的沟通，你问我问我他的情况也要避免。

尤其疫情时代，沟通时间宝贵，要放在更有价值的讨论上。

「我以为你以为的我以为的以为」 — 这句话完美诠释了模糊沟通的后果。

不要说工作了，日常生活上我们也很常会遇到因为双方认知不同导致的误会，生活上轻松自在靠的是彼此的默契；但工作上就不行了，双方认知不同如果没深入讨论，很容易到产出阶段才发现怎么跟想的都不一样。

介面沟通

这边引入的想法是透过一个共识的介面来做沟通，就类似我们工程物件导向程式设计中， SOLID 原则里的 依赖反转原则 Dependency inversion principle (不懂也没关系)；在沟通上也能应用相同的概念。

第一步是找出什么地方是模糊的、每次都要重复确认的沟通，或是需要什么沟通才能更聚焦有效，甚至只需要这个交付就不需要额外沟通的事。

找出问题后就能定义出「介面」，介面就是媒介的意思，可以是一份问件、流程、check list 或工具…等等

使用这个「介面」作为彼此沟通的桥梁，介面可以有多个，什么场景就用什么介面；遇到相同场景优先使用这个介面来做初步沟通；如果还有需求要沟通，可以基于这个介面深入聚焦的讨论问题。

App Team 与外部协作关系

以下以 App Team 协作为例举 4 个介面沟通的例子：

第一个是与 Backend 协作在没有任何介面共识前可能会有上图情况。

对于 API 怎么用，如果单纯地将 API Response String 给 App Team 容易有模糊地带，例如 date 我们怎们知道是 Register Date? 还是 Birthday?，还有范围很广，很多栏位需要确认。

这个沟通也是重复的，每次有新的 Endpoint 都要再确认一次。

这就是很经典的无效沟通案例。

App 与 Backend 彼此缺少的就是一个沟通介面，Solution 有很多种，也不一定要用工具；可以只是一份人工维护的文件。

这块 2020 Pinkoi 开发者之夜有跟大家分享过 — by Toki

Pinkoi 使用的是 Python (FastAPI) 从 API Code 自动产生文件，PHP 可以用 Swagger (之前公司做法)；优点是文件的大框架、资料格式都能从 Code 自动产生出来，降低维护成本，只需处理好栏位说明即可。

p.s. 目前新的 Python 3 都会使用 FastAPI，旧的部分会逐步更新，暂时先用 PostMan 做为沟通介面。

第二个是与 Product Designer 的协作，其实道理上与 Backend 类似，只是问题换成是确认 UI Spec、确认 Flow。

色码、字型如果零散，我们 App 也会很痛苦，撇开需求本来就是这样，我们不想要有同个 Title 有明明颜色一样但色码跑掉或同个位置 UI 不统一的状况。

Solution 最基本的就是要先请设计大大整理好 UI 的元件库、建立好 Design System (Guideline)，并在出 UI 时做好标记。

我们在 Code Base 上根据 Design System (Guideline) 去建立相应的 Font、Color、根据元件库建立出 Button、View。

套版的时候统一使用这些已建立好的元件来套版，方便我们直接看 UI 设计稿就能快速对齐。

但这个很容易乱掉，要动态的调整；不能涵盖太多特例，也不能固守都不扩充。

p.s. 在 Pinkoi 与 Product Designer 的协作是互相的，Developer 也能提出更好的做法与 Product Designer 讨论。

第三个是和 Customer Service 的介面，商城的评价对产品很重要但他却是一个非常人工跟重复转介沟通的事。

因为要时不时人工上去看一下新评价，如过有客服问题再将问题转发给客服协助处理，很重复、人工。

这个最佳解就是让商城评价能自动同步到我们的工作平台，可以花 $ 买现有的服务，或是用我开发的 ZhgChgLi / ZReviewTender (2022 新)。

部署方式、教学及技术细节可参考： ZReviewTender — 免费开源的 App Reviews 监控机器人

这个机器人就是我们的沟通介面，他会将评价自动转发到 Slack Channel，大家能快速收到最新评价资讯，并在上面追踪、沟通讨论。

最后一个例子，是与 Localization Team 的工作依赖；不管是新功能或修改旧翻译，都需要等 Localization Team 完成工作交给我们后续协助处理。

这个自行开发工具的成本太高，所以直接使用第三方服务来协助我们解除依赖关系。

所有翻译、Key 都由第三方工具管理，我们只要事先定好 Key 就能分头行动，双方只要在 Deadline 打包前完成工作即可，不用互相依赖；Localization Team 完成翻译后，工具会自动触发 git pull 更新最新的文字档到专案内。

p.s Pinkoi 因很早期就有这流程，当时选用的是 Onesky 不过这几年有更多优秀的工具可用，可以参考采用其他的。

App Team 团队内互相协作关系

刚说的是外部，现在来说内部。

在人少或是说一个开发者维护一个专案的时候；你想做什么就做什么，你对专案的掌握度、了解程度都很高，问题不大；当然你如果有好的 Sense 就算是一人专案也能做到这边要提的所有事。

但在互相协作的队友越来越多的情况下，大家都在同个专案底下做事，如果还是各做各的将会是场灾难。

例如打 API 一下这边这样做一下那边那样做、很常重造轮子浪费时间或什么都不 Care 直接随便弄一弄上线，都会对未来的维护跟可扩充性增加巨大的成本。

团队内与其说是介面，我觉得太见外了；应该要说共识、共鸣更有团队意识感。

最基本的老生常谈就是 Coding Style，命名的习惯、位置怎么放、Delegate 怎么用…之类；可以以入业界常用的 realm / SwiftLint 进行约束，多国语系语句可以用 freshOS / Localize 整理 (当然，如果你已经是用前文提到的统一由第三方工具管理，就可以不用这个)。

第二个是 App 架构，不管是 MVC/MVVM/VIPER/Clean Architecture 都可以，核心重点是干净、统一；不用追求一定要潮，统一就好。

Pinkoi App Team 使用的 Clean Architecture 。

之前在 StreetVoice 只是纯 MVC 但是是干净统一的，协作起来也很顺畅。

还有 UnitTest，人多很难避免你现在做的逻辑哪一天不小心被改坏；有多写测试能多一份保障。

最后就是文件的部分，关于团队做事的流程、规格或操作手册，方便队友忘记的时候快速翻阅、新人快速上手。

除了 Code Level 的介面之外，协作上还有其他介面协助我们提高效率。

第一是在需求实作前有一个 Request for comments 的阶段，负责开发的人大概说明一下这个需求会怎么做，然后其他人可以留意见想法。

除了可以防止重造轮子之外，还可以集思广益，例如之后其他人要扩充别人要怎么用、或日后可能有什么需求可以列入考量…等等，当局者迷旁观者清啊。

第二是做好 Code Review，把关我们的介面共识有没有落实，例如：Naming 方式、UI Layout 方法、Delegate 用法、Protocol/Class 宣告…等等 还有架构有没有乱用或赶时间乱写、发展方向假设要朝全面 Swift 发展，有没有还在送 OC 的 Code…等等

主要是 Review 这些，其次才是功能正不正常…之类的协助。

p.s. RFC 的目的是提升工作效率，所以不应该太冗长，甚至严重拖累工作进度；可以想成单纯的开工前讨论环节。

统整一下团队内介面共识的功能，最后提到一个 坠机理论 的 Mindset 我觉得是个不错的行为基准点。

摘录自 MBA 智库

运用在团队上就是假设今天所有人都突然消失了，现存的 Code、流程、制度能不能让新的人快速上手？

Recap 介面意义，团队内的介面是用来增加彼此的共识，团队外的协作是降低彼此的无效沟通，用介面作为沟通没截，专注于需求讨论。

再次重申「介面沟通」不是什么特别的专有名词或是工具、工程的东西，他只是个概念，适用于任何职务场景的协作，可以单纯只是份文件或流程，顺序上要先有这个东西然后才来沟通。

这边假设每次多花的沟通时间是 10 分，团队 60 人，每个月发生 10 次，一年就浪费了 1,200 小时在无谓的沟通上。

提升效率 — 自动化重复性工作

第二章节想要跟大家分享一下关于自动化重复工作对于提升工作效率的效果，一样会以 iOS 为例，但 Android 也是相同的方式。

不会提到技术实作细节，单讲原理上的可行性。

整理一下我们有用到的服务，包括但不限于：

• Slack：沟通软体

• Fastlane：iOS 自动化脚本工具

• Github：Git Provider

• Github Action：Github 的 CI/CD 服务，后面会介绍

• Firebase：Crashlytics、Event、App Distribution (后面会介绍)、Remote Config…

• Google Apps Script：Google Apps 的外挂脚本程式，后面会介绍

• Bitrise：CI/CD Server

• Onesky：前面有说到，Localization 的第三方工具

• Testflight：iOS App 内测平台

• Google Calendar：Google 行事历，后面会介绍用在哪

• Asana：专案管理工具

释出测试版的问题

第一个要说的重复性问题，是当我们 App 在开发阶段想要给其他队友抢先测试的时候，传统就是直接借手机来 Build；如果只有 1~2 人问题不大，但是团队有 20~30 人要测，光帮忙安装测试版那天就不用工作了，而且若有更新，整个就都要重新来过。

另一个方法是使用 TestFlight 作为测试版发布媒介，我觉得也不错；但有两个问题，第一个是 Testflight 等同 Production 环境，不是 Debug；第二是当同时开发的需求、同事要测不同需求的队友很多，Testflight 就会大乱，包版的 Build 也会狂改，但也不是不行。

在 Pinkoi 的解法是，首先将「由 App Team 来安装测试版」这件事拆开，用 Slack WorkFlow 做为 Input UI 来达成，输入完成后会触发 Bitrise 跑 Fastlane 脚本去打包上传测试版 ipa 到 Firebase App Distribution。

Slack Workflow 应用可参考此篇文章： Slack 打造全自动 WFH 员工健康状况回报系统

Firebase App Distribution

要测试的队友，只要照著 Firebase App Distribution 的步骤安装完凭证、注册完装置，就能在上面选择安装想要的测试版，或直接回去点信的连结安装。

但这边要注意，iOS Firebase App Distribution 占用的是 Development Device，上限只能只能注册 100 个装置，看装置不看人。

所以可能要跟 TestFlight (by 人，外部测试 1,000 人) 的解法做个权衡。

但至少前面的 Slack WorkFlow UI Input 是可以考虑采用的。

如果要做的进阶可以开发 Slack Bot，能有更完整更客制化的流程、表单可用。

Recap 释出测试版自动化的成效，最有感的是把整个步骤都搬到云端上执行，App Team 不需要插手，完全自助式。

打包正式版的问题

第二个也是 App Team 很常要做的事，打包、送审正式版 App。

团队小的时候，只有单线开发，App 版本更新问题不大，可以很自由也可以很规律。

但团队大，同时有多线的需求在开发跟迭代，就会遇到如上图的状况，没有做好前文说的「介面沟通」就会大家各自上各自的，这会导致 App Team 疲于奔命，因 App 更新的成本比网页高、过程繁琐，另一方面频繁零乱的更新也很干扰使用者。

最后是管理问题，如果没有固定的流程、日期，很难去对每个步骤该做什么事进行优化。

问题如上。

解决办法是导入 Release Train 到开发流程中，核心概念是把版本更新跟专案开发这两件事分开。

我们将日程固定下来，每个阶段会做什么事也定下来：

• 固定周一早上更新新版

• 固定周三 Code Freeze (不再 Merge Feature PR)

• 固定周四开始 QA

• 固定周五打包正式

实际时程(QA 多久)、发版周期(每周、每两周、每个月)依照各公司状况可自行调整， 核心就是确定什么固定什么时间点做什么事 。

这是国外推友发的版更周期调查，大多是 2 周一次。

以每周更新 & 我们多团队为例，就会如上图。

Release Train 顾名思义就像火车站一样，每个版本都是一班列车

如果错过就要等下一班， 各个 Squad 团队跟专案自己选择要上车的时间

这是一个很好的沟通介面，大家只要有共识并遵守规定就能有条不紊的更新版本。

更多 Release Train 的技术细节可参考：

• Mobile release trains — Travelperk

• Agile Release Train

• Release Quality and Mobile Trains

流程、日程确定后，我们就可以对每个阶段做的事进行优化。

像是打包正式版，传统手动方式费时费力，从打包、上传、送审整个流程大概要花 1 个小时，这时间内工作状态要一直切换，很难做其他事；每次的打包都会重复这个过程，很浪费工作效率。

既然我们已经固定日程了，这边直接引入 Google Calendar，将预计日程要做的事加到行事历上，时间到的时候会透过 Google Apps Script 去呼叫 Bitrise 执行 Fastlane 打包正式版和送审的脚本完成全部工作。

使用 Google Calendar 串接还有个好处，如果遇到突发状况需要延后、提早，直接上去更改日期即可。

Google Apps Script 若要直接在 Google Calendar 事件时间到时自动执行，目前只能自己 on 服务来做，如果要快速解决可以使用 IFTTT 做为 Google Calendar <-> Bitrise/Google Apps Script 的桥梁，做法可 参考此篇文章 。

p.s.

1. 目前 Pinkoi iOS Team 是采用 Gitflow 工作流程。
2. 原则上这个共识是所有团队都要遵守，所以不希望有需求是打破这个规则的 (EX: 特别周三要上)，但如果是与外部合作的项目，如果真的没办法还是要保持弹性，毕竟这个共识是团队内的。
3. HotFix 严重问题，是随时可更新的，不受 Release Train 规范。

这边多提了 Google App Scripts 的应用，详情可参考： 运用 Google Apps Script 转发 Gmail 信件到 Slack 。

最后一个是使用 Github Action 提升协作效率 (PR Review)。

Github Action 是 Github 的 CI/CD 服务，可以直接与 Github 事件作绑定，触发时机从 open issue、open pr 到 merge pr…等等都有。

Github Action 只要是 Github 托管的 Git 专案都能使用，Public Repo 没有限制，Private 每个月有 2,000 分钟的免费额度可以用。

这边举两个功能：

• (左)是 PR Review 完之后会自动打上 reviewer name Label，让我们能快速 summary pr review 的状况。

• (右)是每天会在固定时间整理＆发送讯息到 Slack Channel，提醒队友有哪些 PR 正在等待 Review（ 仿造 Pull Reminders 的功能 ）。

Github Action 还有很多可以做的自动化项目，大家可以发挥想像。

像是在开源专案常看到的 issue bot：

fastlane / fastlane

或自动关闭太久没 Merge 的 pr 都能用 Github Action 来自动完成。

Recap 自动化打包正式版的成效，一样直接使用现有工具串接；除了 自动化之外还加入固定流程达到加倍提升工作效率

原本除了手动打包时间，其实还有额外沟通上版时间的成本，现在直接归 0；只要确保在时程内 上车 就可以把时间都专注在「讨论」跟「开发」上。

总计算一下这两个自动化带来的成效，一年可节省 216 工作时数。

自动化加上前面提到的沟通介面，我们来看一下做这些事总共能提升多少效率。

除了刚做的项目，我们还需要多评估 心流切换成本 ，当我们持续投入工作一段时间后就会进入「心流」状态，此时的思绪、生产力都达到巅峰，能提供做好最有效的产出；但如果被无谓的事(EX: 多余的沟通、重复性工作)打断，要重新回到心流，又会再需要一段时间，这边以 30 分钟为例。

被无谓的事打断的心流切换成本也应该列入计算，这边抓 30 分钟每次，一个月发生 10 次，60 人一年就多浪费 3,600 小时。

心流切换成本 (3,600) + 沟通介面不好的情况下多余的沟通 (1,200) + 自动化解决的重复性工作 (216) = 一年多损失了 5,016 小时。

原本浪费的工作时间，节省起来后可以投入其他更有价值的事，所以实际换成产能应该还要再 X 200%。

尤其随著团队规模不断成长，对工作效率的影响也随之放大。

早优化早享受，晚优化没折扣！！

Recap 高效率工作团队的内幕，我们主要做了什么事。

No Code/Low Code First 优先选择现有工具串接（如本篇范例）如果没有现有工具可用再来评估投入自动化的成本，跟实际节省的收入。

关于文化的支持

在 Pinkoi 人人都可以是解决问题的领导者

对于问题的解决，事情的改变；绝大多数都需要很多很多团队一起努力才有可能更好，这部分就很需要公司文化的支持鼓励，不然只有自已在推动会非常辛苦。

在 Pinkoi 人人都可以是解决问题的领导者，不一定要是 Lead or PM 才能解决问题，前面介绍的沟通介面、工具或自动化项目很多都是队友发现问题，提出解法，大家一起努力完成的。

关于团队文化是如何支持推动改变的，解决问题的四个阶段都可以连结到 Pinkoi 的 Core Values。

第一步 Grow Beyond Yesterday

• 好还要更好，如果有发现问题，不管是大小，前面有说到随团队规模成长，小问题也会有放大效果

• 调查、归纳问题，避免过早优化(有的问题可能只是暂时过渡而已)

再来是 Build Partnerships

• 积极的沟通各面向搜集建议

• 保持换位思考(因为有的问题可能是对方的最佳解，要做好权衡)

第三步 Impact Beyond Your Role

• 发挥自身影响力

• 提出问题解决计划

• 如果跟重复工作有关则优先使用自动化方案

• 记得保持弹性跟可扩充性，避免 Over Engineering

最后 Dare to Fail！

• 勇敢实践

• 持续追踪、动态调整解决方案

• 取得成功后，记得与团队分享成果，以促成跨部门资源整合 (因为同个问题可能同时存在在多个部门)

以上是 Pinkoi 高效率工程团队大解密的分享，谢谢大家。

立即加入 Pinkoi >>> https://www.pinkoi.com/about/careers

有任何问题及指教欢迎 与我联络 。

---

本文首次发表于 Medium (点击查看原始版本)，由 ZMediumToMarkdown 提供自动转换与同步技术。

Improve this page on Github.

Follow Me on Medium 1K+ Followers