您的位置: 漯河信息港 > 生活

45天时间Buffer给自己的远程团队开

发布时间:2019-03-21 13:12:03

Buffer 是一个分布式团队,每隔一段时间,他们都要在某个度假胜地见面待上一段时间。这段时间会召开无数大大小小的会议,半休假半工作的状态反而极大的提升了团队

创见干货:

Buffer 是一个分布式团队,成员全都是远程工作者。每隔一段时间,他们都要在某个度假胜地见面待上一段时间。这段时间会召开无数大大小小的会议,半休假半工作的状态反而极大的提升了团队文化。但是,随着 Buffer 团队人数越来越多,再加上大家从未见过面,这时候急需要一款内部的应用将大家更好的联系起来。

于是,45 天的时间,Buffer 拿出来了一款内部工具。本文就是讲述它诞生的来龙去脉。Buffer 的开发团队分布在世界各个角落,每隔一段时间大家约定在世界的某个度假胜地聚一下,这个时候团队成员需要回顾总结过去的工作,落实目前项目所处的阶段,以及团队中长期的目标和各自接下来的具体工作任务都是什么。

在过去,我们是用 Facebook Messenger 来分享计划、地点、和某些工作提醒。但是现在我们的团队已经超过 70 人了,Messenger 对这么一个庞大的团队有点儿应付不来了。所以我们需要全新的解决方案。

于是,Buffer Rereat 应用应运而生。仅仅花了 45 天的时间,这样一个想法得到快速的落地执行,开花结果。这就是我们的故事。

为一款 App 确认需求 Buffer 团队逐渐壮大,远程工作者越来越多。当一切都在规模化扩张,如何让交流变得快速、高效、简单就成为横亘在工作中的一个问题。

Patrik 是我们客户调研团队中远程工作者,他非常清楚的捕捉到了团队成员目前需要怎样一款 App,并在下面的邮件中给出了他的解决方案。 我们都同意 Patrik 在邮件里的观点,这也是有关 App 开发的想法正式成型的时刻。

保持精益:专注开发一些核心功能

你估计能猜到一开始,我们在设想有多少功能上面有多大的野心。 但是,我们必须现实,确认用户需要的功能是什么 ,因为时间有限,精力有限,我们不能在这个产品上耽搁太长时间。 我们所有人都同意「保持精益」是这款 App 的首要开发原则。

以邮件形式进行沟通,再加上 Slack 平台上的一些交流,我们终于确认了一些核心想法和产品需求。产品开发的主要目标如下所示:

* 能很清楚地将一名远程工作者的工作计划全部展现出来

* 跟远程工作者的各项工作展开互动,比如将自己标注成「参与中」状态,又或者能给它进行留言等等。

* 在获得用户许可的前提下,在 App 上现实每一个人的地理位置

* 在 iOS 和 Andorid 两种环境下发布两个版本

App 上有两种「环境」,一个是向所有人开放的平台;一个是给 Buffer 的全职雇员以及其他一些重要角色开放的会议环境 有了这样一份清单,我们就能够避免不必要的开发进程,将精力放在核心的任务上。

设计和理顺我们的想法 我们很幸运,有 Marcus 这样经验老道的程序员在队伍中。一个星期,他就把草图文件全部整理完毕,这些东西成为 App 开发一路上的指引。

它让我们更加清楚的发现这款 App 核心的功能是什么,还有一些之前在我们眼中重要的功能其实可以从优先项目列表中摘除出来了。 例如,一旦草图出来之后,我们才意识到其实没有「」这个栏目完全是可以接受的。

另外的一些改变是针对不同的系统平台逐一优化实现的,在 Skecth 文件中「Add Acitivity」这个视觉效果似乎更适合 Android,而在 iOS 环境下,我刻意在上面添加了一下原生应用的感觉。

面向用户的工作流和主题,这两个东西在各个平台上是保持一致的。,

在设计上做出的变动是 icon 图标。Marcus 想出来了好几个版本,版草稿只是将 Buffer 在 iOS 环境下的 icon 做了稍许的调整。 我们还是否决了这个方案,因为 Retreat 这款应用很容易和 Buffer 的官方应用而混淆起来。而且用户很容易就在自己的上把这两个图标并排放置,这样他们分辨起来就更加困难了。

终的方案是什么呢?Marcus 很聪明的把上述的图标颜色进行了反转,这样既能和 Buffer 保持统一,又能一眼识别出来两者的不同。

开发:为了速度,直接从我们的代码库中提取有用代码 上述的工作完成之后,App 进入到了实质性开发阶段。我和 Marcus 分别负责 iOS 和 Android 版本的开发。

我们都知道,如果想要按时地将 App 交付出来,这意味着我们必须采取一些捷径,也就是从现有的代码和框架中抽取有用的内容,这会大大节省我们的开发时间。

在 App 末端和 API 上,我们使用 Parse。移动团队中几乎每一个人之前都使用过这款软件。 移动团队的所有成员都可以提出自己的意见,做出自己的贡献,尽管其实就和 Marcus 两个人负责开发这款 App,其他的人建言献策,保证我们在既定的轨道上。

的冲刺 几个星期过去了,每个星期我和 Marcus 都会专门抽出一两天时间来专注于开发这款 App,而到了 12 月,我有一个长达 2 个星期的大假,而 Marcus 当时正在进行横穿美国的旅行。当 Retreat 这款 App 即将完工,每个星期我们拿出来的时间更多了一些。

在这个过程中,我们在 Zoom 这个平台上分享自己目前的工作进展,因为我们是在不同的环境中开发软件,要保证功能和使用体验上的一致性,这一点至关重要。

当然,召开一次很短的视频会议,又或者在 Slack 这个平台上做一些简单的交流,这些方式都有助于快速达成共识。

测试:属于 Retreat 的时间来了!1 月 23 日逐渐临近,Buffer 团队中几乎每一个人的上都安装了 Retreat 这款 App!

在使用过程中,我们几乎同时发现了这款 App 的亮点:团队成员目录页!因为我们是一个遍布全世界的分布式团队,很多人都是我们次见。这时的目录能够很方便地熟络彼此的关系,在上面能够知道他在 Buffer 做过什么,他的合作伙伴或者家人是谁。

事实上,每天早上醒来,拿起看 App 上有哪些会议,已经成为了一天开始的正常程序。 你还可以在上看成员们现在都在哪里,方便找到他们。

我们的收获:尽可能快速的行动,但是不要为了速度而牺牲产品的质量

鉴于出于有限的时间,我所开发的功能仅仅是为了「能用」,并没有考虑到未来这款产品的用户多了之后怎么办。

就比如说,当用户创建了一个「事件」,只要有新的「事件」储存在了 Parse 上,我都会为了刷新整个用户界面而将 App 中所有的「事件」重新读取一次。这在目前不算什么事儿,

45天时间Buffer给自己的远程团队开

因为我们多也就应付 20 到 30 个「事件」。

但是未来呢?如果 Buffer 继续壮大下来,这种方法就不得不转向本地缓存了。

我们很清楚这款 App 在开发时保持的原则,目的,借此形成一个成功评判的标准:

它是给公司内部目前有限人数的员工使用的工具,而非数百万用户的规模化产品。所以在此基础上,我们借鉴了代码库中的工作成果,按时的发布了产品。 这就是 Buffer 团队在极短时间内开发一款内部工具的全部过程。由此你可以看出:它有明确的指导思路,开发办法,以及成功评估标准。

本文来源:Medium 译文创见首发 由 TECH2IPO / 创见 花满楼 编译 转载请注明出处

猜你会喜欢的
猜你会喜欢的