paint-brush
La naissance de Slack d'une société de jeux vidéo n'était pas une coïncidencepar@grant
920 lectures
920 lectures

La naissance de Slack d'une société de jeux vidéo n'était pas une coïncidence

par Grant Magdanz7m2023/07/04
Read on Terminal Reader

Trop long; Pour lire

En 2009, les cofondateurs Stewart Butterfield, Cal Henderson, Eric Costello et Serguei Mourachov ont entrepris de créer un jeu vidéo qu'ils n'avaient pas réussi à créer auparavant.
featured image - La naissance de Slack d'une société de jeux vidéo n'était pas une coïncidence
Grant Magdanz HackerNoon profile picture
0-item


Slack n'a pas besoin d'être présenté, je vais donc plonger directement. Merci à Cal Henderson , Keith Adams et Ali Rayl pour leur aide.


Ceci est un numéro de ma newsletter gratuite, Monolith . J'écris sur la façon dont les entreprises prospères ont construit leurs produits (et enfreint les règles) avant qu'elles ne soient adaptées au marché des produits.


Bref historique : La naissance de Slack à partir d'une société de jeux vidéo en faillite fait partie de la tradition de la vallée à ce stade. Le récit commun, comme toutes les traditions, est sensationnel.


En 2009, les cofondateurs Stewart Butterfield, Cal Henderson, Eric Costello et Serguei Mourachov ont entrepris de créer un jeu vidéo qu'ils n'avaient pas réussi à créer en 2002. Stewart et Cal lors d'une conférence en 2010 : (transcription):


Nous avons d'excellentes chances de réussir car nous avons échoué auparavant et les chances d'échouer deux fois à la même chose sont assez faibles, ouais astronomiques. En 2002, nous avons lancé une société appelée Ludicorp et nous essayions de créer un jeu appelé Game Neverending. Même chose : un jeu massivement multijoueur basé sur le Web, sauf que c'était en 2002. Beaucoup de choses étaient différentes. Le principal d'entre eux, il était impossible de collecter des fonds pour les startups Internet confrontées aux consommateurs, car c'était après le crash des dot-com, après le 11 septembre, WorldCom, Enron, vous savez, en fait une période beaucoup plus difficile pour collecter des fonds, nous avons donc manqué d'argent quand nous étions à mi-chemin de la création du jeu et avons essayé de faire autre chose que la technologie. Ce quelque chose d'autre était Flickr. Flickr a été racheté par Yahoo et nous avons passé plusieurs années à le faire. Nous sommes quatre de l'équipe Flickr à lancer une nouvelle société, Tiny Speck, et nous réalisons Glitch.


Glitch, image de TechCrunch

Avec une sortie réussie à leur actif et un environnement de collecte de fonds différent, l'argent était facile : (transcription) :


Nous pouvions récolter autant d'argent que nous le voulions. C'était donc facile. Nous n'avons même pas fait de deck. Nous avons juste dit « nous voudrions de l'argent » et les gens nous ont donné de l'argent.


L'équipe a levé 5 millions de dollars auprès d'Accel en 2010 et 10 millions de dollars supplémentaires auprès d'Accel et d'a16z en 2011. Glitch a été lancé en septembre 2011. À la fin de 2012, il était clair que le jeu n'allait pas fonctionner. Ils ont fermé Glitch. Il leur restait 5 millions de dollars et un outil de communication interne.


Dès le début, l'équipe de Tiny Speck s'est répartie :


L'équipe de direction de Tiny Speck était basée dans différentes villes d'Amérique du Nord. Butterfield et Mourachov vivaient à Vancouver, Henderson avait installé son camp à San Francisco et Costello gérait le développement de la clientèle depuis New York.


Pour communiquer plus facilement ils ont construit un système interne autour d'IRC : (transcription) :


Lentement, nous avons développé un système qui était à la base de toutes les façons dont l'entreprise communiquait et qui était vraiment bénéfique et réalisé, hein, aucun d'entre nous ne travaillera plus jamais sans quelque chose comme ça et d'autres équipes de 8 développeurs de logiciels aimeraient probablement aussi . Nous avons donc décidé que c'est ce que nous allions faire.

Site Web de Slack pour l'aperçu public


Les deux années suivantes ont été une fusée:


Slack est devenu public en 2019 à une valorisation de 15,7 milliards de dollars.

Développement

La version interne initiale de Slack n'était qu'un wrapper autour d'IRC : Internet Relay Chat (IRC) est un protocole de la fin des années 80. L'équipe de Tiny Speck a utilisé IRC, mais il avait quelques défauts majeurs. Le protocole ne prenant pas en charge les messages persistants, la recherche ou les téléchargements de fichiers, l'équipe a donc construit les fonctionnalités dont elle avait besoin autour d'un serveur IRC standard. De Stewart : (transcription) :


Nous avions développé un système qui était le proto-Slack. Encore une fois, en 1992, l'un des outils réseau que j'avais utilisés était IRC ou Internet Relay Chat. Nous avons utilisé IRC chez Tiny Speck, et c'est une technologie très ancienne.

Avec la plupart des systèmes de messagerie, il existe un concept de stockage et retransmission. Si je veux vous envoyer un message mais qu'il n'y a pas de connexion avec votre client, il sera simplement mis en attente puis vous sera transmis la prochaine fois que vous vous connecterez. IRC n'avait pas ça. Si vous n'étiez pas connecté au moment où j'ai envoyé le message, vous ne le recevriez jamais. Nous avons donc construit un système pour enregistrer les messages. Mais une fois que nous avions les messages dans une base de données, nous voulions pouvoir les rechercher. Nous avons donc construit la recherche. Et puis, petit à petit, fonctionnalité par fonctionnalité, nous avons construit des éléments à intégrer à notre serveur de fichiers. Ainsi, lorsque quelqu'un téléchargeait un fichier, il était annoncé dans IRC ou si une alerte se déclenchait dans le centre de données, elle serait placée dans IRC.


Au fur et à mesure que l'équipe développait Glitch, elle expédiait périodiquement une fonctionnalité indispensable pour améliorer IRC. Encore une fois de Stewart : (transcription) :


Lorsqu'il y avait une opportunité si évidente que nous ne pouvions pas ne pas en profiter, nous passions le minimum de minutes dessus, puis nous y revenions (développer Glitch). À la fin de ce processus, nous avions ce produit entièrement conçu que nous utilisions et qui était une implémentation terrible, pas ce que vous feriez si vous partiez de zéro, mais il était évident que c'était quelque chose qui avait une valeur énorme.


Lorsque l'équipe a pivoté fin 2012, elle a continué à utiliser la version IRC interne pendant deux mois pendant qu'elle construisait Slack à partir de zéro. Ils se sont déplacés une fois que le produit était prêt à être utilisé en interne.


Le MVP avait des problèmes d'expérience utilisateur pour les équipes de plus de 10 personnes : au début, ils "suppliaient et cajolaient" leurs amis d'autres entreprises pour qu'ils l'essaient et donnent leur avis. Ils ont commencé avec six à dix entreprises. Rdio étant le plus grand avec environ 120 employés. Il était immédiatement clair que le produit fonctionnait très différemment pour les équipes plus grandes que celles de Slack.


De Cal : (transcription) :

Ces premiers jours d'utilisation par d'autres personnes ont été une période de retours immenses et riches. Il y avait tellement de choses auxquelles nous n'avions tout simplement pas pensé parce que nous connaissions tellement la façon dont nous travaillions, mais aussi des choses vraiment stupides. Si vous aviez deux personnes dans votre entreprise appelées "Matt", il n'y avait aucun moyen de lever l'ambiguïté entre eux, ou si vous aviez 20 personnes dans votre équipe, il n'y avait pas de listes déroulantes parce que nous étions une équipe de 8 personnes.


L'équipe Slack a intégré ces commentaires dans le produit, a intégré d'autres équipes et a continué à les intégrer au produit. Ce cycle de produit itératif est quelque chose qu'ils ont appris de Flickr.


Encore de Cal : (transcription) :

Une leçon évidente que nous avons tirée de Flickr est que lorsque vous regardez d'excellents produits logiciels, ceux qui sont excellents n'ont pas commencé de cette façon. Ils ont commencé d'une manière très différente, le produit a été présenté très différemment, les utilisateurs ont interagi de différentes manières et l'équipe a parfois itéré massivement pour arriver là où elle en est aujourd'hui. Il s'agit de cette boucle de rétroaction consistant à comprendre ce que font vos clients, les problèmes qu'ils rencontrent, ce qu'ils essaient d'accomplir et à intégrer cela dans la conception de votre logiciel et à itérer vers un produit qui peut être génial et que les gens peuvent aimer .


L'architecture de Slack ressemble à celle d'un jeu en ligne : les clients Slack ont tout mis en cache. Au démarrage, ils feraient une seule requête API, appelée rtm start. Cela téléchargerait tout ce qui concerne l'espace de travail d'un utilisateur, y compris les chaînes, les membres et l'adhésion à la chaîne. Le client ouvrirait alors une connexion WebSocket pour envoyer et recevoir des mises à jour vers le cache local.

De Keith Adams, architecte en chef de Slack de 2016 à 2020, parlant de la façon dont les médias aiment raconter l'histoire du pivot de Slack à partir d'un jeu en ligne : (transcription) :


Habituellement, les gens mentionnent simplement cela comme une chose amusante : "oh, c'était une société de jeux, n'est-ce pas drôle comme les cookies s'effritent parfois ?". C'est vrai, mais cela revient en fait de certaines façons. Si vous plissez les yeux et inclinez la tête, l'architecture réelle de Slack ressemble à l'architecture d'un jeu en ligne massivement multijoueur. Vous avez en quelque sorte votre «monde» dans lequel vous opérez, qui est votre équipe, et afin de rendre ce monde à la fois persistant et interactivement modifiable avec d'autres choses dans le monde, vous finissez par créer un cache assez épais de ce qui se passe dans ce monde, puis vous avez un moyen d'obtenir des mises à jour à faible latence pour les changements dans ce monde. Ce genre de paradigme mental du « oh, c'est un peu comme un jeu en ligne » explique beaucoup de choses sur Slack. C'est pourquoi nous avons des écrans de chargement par exemple. C'est la même raison pour laquelle les jeux vidéo ont tendance à avoir des écrans de chargement.


Ma prise

Slack a été conçu pour résoudre leur propre problème. Semblable à Nomad List , la version initiale du produit est née d'un véritable besoin du ou des créateurs.


Des choses simples peuvent apporter une immense valeur. Slack n'était qu'une extension d'un protocole ouvert, mais il offrait une immense valeur aux bons utilisateurs. C'est un autre cas où aucune innovation technique n'était nécessaire pour créer quelque chose de très précieux.


Ce n'est pas une coïncidence si Slack est né d'une société de jeux. Ceci est pertinent au-delà de l'architecture technique. Slack n'a pas l'air de travailler. C'est l'une des raisons pour lesquelles les gens l'aiment. MetaLab a conçu une grande partie de l'interface utilisateur initiale de Slack. Du fondateur de MetaLab, Andrew Wilkinson :


Pour attirer l'attention sur un marché bondé, nous devions trouver un moyen d'attirer l'attention des gens. La plupart des logiciels d'entreprise ressemblent à un costume de bal bon marché des années 70 - des bleus et des gris en sourdine partout - donc, en commençant par le logo, nous avons fait ressembler Slack à un canon à confettis. Bleu électrique, jaunes, violets et verts partout. Nous lui avons donné la palette de couleurs d'un jeu vidéo, pas un produit de collaboration d'entreprise.

Liens / Ressources


Également publié ici .