931 판독값

비디오 게임 회사에서 Slack의 탄생은 우연이 아니었습니다.

~에 의해 Grant Magdanz7m2023/07/04

너무 오래; 읽다

2009년, 공동 창업자인 Stewart Butterfield, Cal Henderson, Eric Costello, Serguei Mourachov는 이전에 제작에 실패했던 비디오 게임 제작에 착수했습니다.

featured image - 비디오 게임 회사에서 Slack의 탄생은 우연이 아니었습니다.

Slack은 소개가 필요 없으므로 바로 시작하겠습니다. 도움을 주신 Cal Henderson , Keith Adams 및 Ali Rayl 에게 감사드립니다.

이것은 내 무료 뉴스레터 인 Monolith 의 문제입니다. 나는 성공적인 회사들이 제품 시장에 적합하기 전에 어떻게 제품을 구축하고 규칙을 어겼는지에 대해 글을 씁니다.

간략한 역사: 실패한 비디오 게임 회사에서 Slack이 탄생했다는 이야기는 현재 Valley의 전설입니다. 모든 전설과 마찬가지로 일반적인 이야기도 선정적입니다.

2009년, 공동 창업자인 Stewart Butterfield, Cal Henderson, Eric Costello 및 Serguei Mourachov는 이전에 2002년에 제작에 실패했던 비디오 게임을 만들기 시작했습니다. 2010년 컨퍼런스에서 Stewart와 Cal: (대본):

우리는 이전에 실패했기 때문에 성공할 가능성이 매우 높습니다. 같은 일에 두 번 실패할 확률은 매우 낮습니다. 예, 천문학적입니다. 2002년에 우리는 Ludicorp라는 회사를 시작했고 Game Neverending이라는 게임을 만들려고 했습니다. 같은 것입니다. 2002년이라는 점을 제외하면 웹 기반의 대규모 멀티플레이어 게임입니다. 많은 것이 달랐습니다. 그 중 가장 중요한 것은 닷컴 붕괴 이후, 9월 11일 WorldCom, Enron 이후로 소비자 대면 인터넷 스타트업을 위한 자금 조달이 불가능했기 때문입니다. 사실 자금 조달이 훨씬 더 어려운 시기였기 때문에 자금이 부족했습니다. 우리가 게임을 만드는 도중에 기술이라는 다른 일을 하려고 했을 때요. 그 또 다른 것이 Flickr였습니다. Flickr는 Yahoo에 인수되었고 우리는 그 일을 하는 데 몇 년을 보냈습니다. Flickr 팀의 우리 4명은 Tiny Speck이라는 새로운 회사를 시작했고 Glitch를 만들고 있습니다.

성공적인 퇴장과 다른 모금 환경 덕분에 돈을 모으는 것은 쉬웠습니다: (대본):

우리는 원하는 만큼 많은 돈을 모을 수 있었습니다. 그래서 그것은 쉬웠습니다. 우리는 데크도 만들지 않았습니다. 우리는 단지 “돈이 좀 필요해요”라고 말했고 사람들은 우리에게 돈을 주었습니다.

팀은 2010년에 Accel로부터 500만 달러를, 2011년에 Accel과 a16z로부터 1,000만 달러를 추가로 모금했습니다. Glitch는 2011년 9월에 출시되었습니다. 2012년 말에 게임이 작동하지 않을 것이 분명해졌습니다. 그들은 글리치를 폐쇄했습니다. 그들에게는 500만 달러가 남았고 내부 커뮤니케이션 도구도 있었습니다.

Tiny Speck 팀은 처음부터 다음과 같이 배포되었습니다 .

Tiny Speck의 경영진은 북미 전역의 여러 도시에 기반을 두고 있었습니다. Butterfield와 Mourachov는 밴쿠버에 살았고 Henderson은 샌프란시스코에 캠프를 세웠으며 Costello는 뉴욕시에서 클라이언트 개발을 관리했습니다.

더 쉽게 의사소통하기 위해 그들은 IRC를 중심으로 내부 시스템을 구축했습니다: (대본):

천천히 우리는 회사가 의사소통하는 모든 방식의 기초가 되는 시스템을 개발했으며 정말 유익하고 깨달았습니다. 허, 우리 중 누구도 다시는 이런 것이 없이는 일하지 않을 것이며 8명의 소프트웨어 개발자로 구성된 다른 팀도 아마 좋아할 것입니다. . 그래서 우리는 그것이 우리가 할 일이라고 결정했습니다.

다음 2년은 로켓 같았습니다.

2012년 11월 - Slack 프로덕션화 시작
2013년 5월 - 약 45개 회사가 비공개 베타 버전으로 Slack을 사용하고 있었습니다.
2013년 8월 - 공개 미리보기 발표 및 24시간 만에 8,000명이 등록
2014년 4월 - 시리즈 C에서 DAU 60,000명, 유료 시트 15,000개로 4,275만 달러를 모금했습니다 .
2014년 10월 - 200,000개의 활성 팀과 73,000개의 유료 시트를 통해 11억 2천만 달러 가치 평가에서 1억 2천만 달러를 모금했습니다 .

Slack은 2019년에 157억 달러의 가치로 상장되었습니다 .

개발

Slack의 초기 내부 버전은 IRC를 둘러싼 래퍼였습니다. IRC( Internet Relay Chat )는 80년대 후반의 프로토콜입니다. Tiny Speck 팀은 IRC를 사용했지만 몇 가지 심각한 결함이 있었습니다. 프로토콜은 지속적인 메시지, 검색 또는 파일 업로드를 지원하지 않았기 때문에 팀은 기성 IRC 서버에 필요한 기능을 구축했습니다. 스튜어트에서: (대본):

우리는 proto-Slack이라는 시스템을 개발했습니다. 다시 말하지만, 92년에 제가 사용한 네트워크 도구 중 하나는 IRC 또는 인터넷 릴레이 채팅이었습니다. Tiny Speck에서는 IRC를 사용했는데 이는 매우 오래된 기술입니다.

대부분의 메시징 시스템에는 저장 후 전달이라는 개념이 있습니다. 귀하에게 메시지를 보내고 싶지만 귀하의 클라이언트와 연결이 없으면 메시지는 그대로 보관되었다가 다음에 연결될 때 전달됩니다. IRC에는 그런 것이 없었습니다. 내가 메시지를 보낸 순간 당신이 연결되어 있지 않았다면 당신은 결코 메시지를 받지 못했을 것입니다. 그래서 우리는 메시지를 기록하는 시스템을 구축했습니다. 하지만 데이터베이스에 메시지가 있으면 이를 검색할 수 있기를 원했습니다. 그래서 우리는 검색을 구축했습니다. 그런 다음 비트 단위, 기능 단위로 파일 서버와 통합할 수 있는 장치를 구축하여 누군가 파일을 업로드하면 IRC에 알리거나 데이터 센터에서 경고가 발생하면 IRC에 전달되도록 했습니다.

팀은 Glitch를 개발하면서 IRC를 향상시키는 데 꼭 필요한 기능을 주기적으로 출시했습니다. Stewart가 다시 한 번: (대본):

너무나 명백해서 활용하지 않을 수 없는 기회가 있을 때, 우리는 그것에 최소한의 시간을 투자한 다음 다시 그 기회로 돌아갔습니다(글리치 개발). 그 과정이 끝나면 우리가 사용하고 있던 완전히 설계된 제품이 탄생했는데, 이는 끔찍한 구현이었습니다. 처음부터 시작했다면 할 수 있는 일이 아니었지만 이것이 엄청난 가치를 지닌 제품임은 분명했습니다.

팀이 2012년 후반에 전환했을 때 처음부터 Slack을 구축하는 동안 두 달 동안 내부 IRC 버전을 계속 사용했습니다. 제품이 내부적으로 사용될 준비가 된 후에 그들은 이동했습니다.

MVP는 10명 이상의 팀에 대해 UX 문제를 안고 있었습니다. 처음에는 다른 회사의 친구들에게 시험해보고 피드백을 달라고 “간청하고 회유”했습니다. 그들은 6~10개의 회사로 시작했습니다. Rdio는 약 120명의 직원으로 가장 큰 회사입니다. Slack보다 규모가 큰 팀에서는 이 제품이 매우 다르게 작동한다는 것이 즉시 분명해졌습니다.

Cal에서: (대본):

다른 사람들이 사용한 처음 며칠은 엄청나게 풍부하고 피드백이 많은 기간이었습니다. 우리가 일하는 방식에 너무 익숙하기 때문에 생각하지 못했던 것들도 많았지만 정말 멍청한 것들도 있었습니다. 회사에 "Matt"라는 사람이 두 명 있는 경우 둘 사이를 구분할 방법이 없었습니다. 또는 팀에 20명이 있는 경우 우리는 8명으로 구성된 팀이므로 목록을 스크롤할 수 없었습니다.

Slack 팀은 해당 피드백을 제품에 통합하고 더 많은 팀을 온보딩했으며 이를 계속해서 제품에 통합했습니다. 이러한 반복적인 제품 주기는 Flickr에서 배운 것입니다.

다시 Cal에서: (대본):

Flickr에서 우리가 얻은 분명한 교훈은 훌륭한 소프트웨어 제품을 볼 때 훌륭한 제품은 그런 식으로 시작되지 않았다는 것입니다. 그들은 매우 다른 방식으로 시작했고 제품은 매우 다르게 제시되었으며 사용자는 다른 방식으로 상호 작용했으며 팀은 오늘날의 위치에 도달하기 위해 때때로 대규모 반복을 수행했습니다. 고객이 무엇을 하고 있는지, 고객이 겪고 있는 문제, 고객이 달성하려는 것이 무엇인지 이해하고 이를 소프트웨어 설계에 다시 적용하고 훌륭하고 사람들이 좋아할 수 있는 제품을 향해 반복하는 피드백 루프에 관한 것입니다. .

Slack의 아키텍처는 온라인 게임의 아키텍처와 유사합니다. Slack 클라이언트는 모든 것을 캐시했습니다. 시작 시 rtm start라는 단일 API 요청을 수행합니다. 그러면 채널, 멤버, 채널 멤버십을 포함하여 사용자의 워크스페이스에 대한 모든 것이 다운로드됩니다. 그런 다음 클라이언트는 WebSocket 연결을 열어 로컬 캐시에 대한 업데이트를 보내고 받습니다.

2016년부터 2020년까지 Slack의 수석 설계자인 Keith Adams는 미디어가 온라인 게임에서 Slack의 전환점에 대한 이야기를 어떻게 좋아하는지에 대해 이야기합니다: (대본):

보통 사람들은 이것을 재미있는 일로 언급합니다. "아, 그 회사는 게임 회사였죠. 쿠키가 가끔 무너지는 게 웃기지 않나요?" 그것은 사실이지만 실제로는 어떤 방식으로든 다시 돌아옵니다. 눈을 가늘게 뜨고 고개를 기울이면 Slack의 실제 아키텍처는 대규모 멀티플레이어 온라인 게임의 아키텍처와 유사합니다. 당신은 당신이 운영하는 "세계", 즉 당신의 팀을 가지고 있으며, 그 세계가 지속적이고 세계의 다른 것들과 대화식으로 변경 가능하게 보이도록 만들기 위해 결국에는 무슨 일이 일어나고 있는지에 대한 꽤 두꺼운 캐시를 만들게 됩니다. 그러면 그 세계의 변화에 대해 지연 시간이 짧은 업데이트를 얻을 수 있는 방법이 있습니다. "아, 일종의 온라인 게임 같구나"라는 정신적 패러다임이 Slack에 대해 많은 것을 설명해줍니다. 예를 들어 로딩 화면이 있는 이유도 바로 여기에 있습니다. 비디오 게임에 로딩 화면이 있는 것과 같은 이유입니다.

내 생각

Slack은 자체 문제를 해결하기 위해 만들어졌습니다. Nomad List 와 유사하게 제품의 초기 버전은 제작자의 진정한 요구에서 나왔습니다.

단순한 것이 엄청난 가치를 제공할 수 있습니다. Slack은 단순히 개방형 프로토콜의 확장이었지만 적합한 사용자에게 엄청난 가치를 제공했습니다. 이는 엄청난 가치를 창출하는 데 기술 혁신이 전혀 필요하지 않은 또 다른 사례입니다.

Slack이 게임 회사에서 탄생한 것은 단순한 우연이 아닙니다. 이는 기술 아키텍처 이상의 의미를 갖습니다. Slack은 일처럼 느껴지지 않습니다. 사람들이 좋아하는 이유 중 하나죠. MetaLab은 Slack의 초기 UI 대부분을 디자인했습니다. MetaLab 창립자 Andrew Wilkinson의 말 :

혼잡한 시장에서 관심을 끌기 위해서는 사람들의 관심을 끌 수 있는 방법을 찾아야 했습니다. 대부분의 기업용 소프트웨어는 파란색과 회색이 전체적으로 음소거된 값싼 70년대 무도회복처럼 보입니다. 그래서 우리는 로고부터 Slack을 색종이 대포가 터진 것처럼 보이도록 만들었습니다. 온통 일렉트릭 블루, 노란색, 보라색, 녹색입니다. 기업 협업 제품이 아닌 비디오 게임의 색상 구성을 부여했습니다.