Slack no necesita presentación, así que me sumergiré directamente. Gracias a Cal Henderson , Keith Adams y Ali Rayl por ayudar con esto.
Este es un número de mi boletín gratuito, Monolith . Escribo sobre cómo las empresas exitosas construyeron sus productos (y rompieron las reglas) antes de que su producto encajara en el mercado.
Breve historia: el nacimiento de Slack de una compañía de videojuegos fallida es la tradición de Valley en este momento. La narración común, como ocurre con todas las tradiciones, es sensacionalista.
En 2009, los cofundadores Stewart Butterfield, Cal Henderson, Eric Costello y Serguei Mourachov se propusieron desarrollar un videojuego que no habían podido desarrollar en 2002. Stewart y Cal en una conferencia en 2010: (transcripción):
Tenemos una excelente oportunidad de tener éxito porque fallamos en eso antes y las probabilidades de fallar dos veces en lo mismo son bastante bajas, sí, astronómicas. En 2002 creamos una empresa llamada Ludicorp y estábamos tratando de hacer un juego llamado Game Neverending. Lo mismo: un juego multijugador masivo basado en la web, excepto que era de 2002. Muchas cosas eran diferentes. El principal de ellos era que era imposible recaudar dinero para las nuevas empresas de Internet orientadas al consumidor porque fue después del colapso de las puntocom, después del 11 de septiembre, WorldCom, Enron, ya sabes, en realidad era un momento mucho más difícil para recaudar dinero, así que nos quedamos sin dinero. cuando estábamos a medio camino de hacer el juego e intentamos hacer algo más con la tecnología. Ese algo más era Flickr. Flickr fue comprado por Yahoo y pasamos varios años haciéndolo. Cuatro de nosotros del equipo de Flickr empezamos una nueva compañía, Tiny Speck, y estamos haciendo Glitch.
Con una salida exitosa en su haber y un entorno de recaudación de fondos diferente, el dinero fue fácil: (transcripción):
Podríamos recaudar tanto dinero como quisiéramos. Así que eso fue fácil. Ni siquiera hicimos una baraja. Simplemente dijimos “nos gustaría algo de dinero” y la gente nos dio dinero.
El equipo recaudó $5 millones de Accel en 2010 y otros $10 millones de Accel y a16z en 2011. Glitch se lanzó en septiembre de 2011. A finales de 2012 estaba claro que el juego no iba a funcionar. Cerraron Glitch. Les quedaban $5 millones y una herramienta de comunicación interna.
Desde el principio, el equipo de Tiny Speck estuvo repartido :
El equipo ejecutivo de Tiny Speck se había basado en diferentes ciudades de América del Norte. Butterfield y Mourachov vivían en Vancouver, Henderson se había instalado en San Francisco y Costello gestionaba el desarrollo de clientes desde la ciudad de Nueva York.
Para comunicarse más fácilmente, crearon un sistema interno en torno a IRC: (transcripción):
Lentamente, desarrollamos un sistema que fue la base de todas las formas en que la empresa se comunicaba y fue realmente beneficioso y se dio cuenta, eh, ninguno de nosotros va a trabajar sin algo como esto nunca más y a otros equipos de 8 desarrolladores de software probablemente también les gustaría . Así que decidimos que eso era lo que íbamos a hacer.
Los siguientes dos años fueron un cohete:
Slack salió a bolsa en 2019 con una valoración de 15.700 millones de dólares.
La versión interna inicial de Slack era solo una envoltura alrededor de IRC: Internet Relay Chat (IRC) es un protocolo de finales de los años 80. El equipo de Tiny Speck usó IRC, pero tenía algunas fallas importantes. El protocolo no admitía mensajes persistentes, búsqueda o carga de archivos, por lo que el equipo creó las funciones que necesitaban en torno a un servidor IRC estándar. De Stewart: (transcripción):
Habíamos desarrollado un sistema que era el proto-Slack. Nuevamente, en el 92, una de las herramientas de red que usé fue IRC o Internet Relay Chat. Usamos IRC en Tiny Speck, y es una tecnología muy antigua.
Con la mayoría de los sistemas de mensajería, existe un concepto de almacenamiento y reenvío. Si quiero enviarle un mensaje pero no hay conexión con su cliente, simplemente se retendrá y luego se le reenviará la próxima vez que se conecte. IRC no tenía eso. Si no estuvieras conectado en el momento en que envié el mensaje, nunca lo recibirías. Así que construimos un sistema para registrar los mensajes. Pero una vez que teníamos los mensajes en una base de datos, queríamos poder buscarlos. Así que construimos la búsqueda. Y luego, poco a poco, característica por característica, construimos cosas para integrar con nuestro servidor de archivos, de modo que cuando alguien cargaba un archivo, se anunciaba en IRC o si se disparaba una alerta en el centro de datos, se ponía en IRC.
A medida que el equipo desarrollaba Glitch, lanzaban periódicamente una función muy necesaria para mejorar el IRC. Nuevamente de Stewart: (transcripción):
Cuando había una oportunidad que era tan obvia que no podíamos dejar de aprovecharla, dedicábamos la mínima cantidad de minutos a eso y luego volvíamos a ella (desarrollando Glitch). Al final de ese proceso, teníamos este producto completamente diseñado que estábamos usando, que era una implementación terrible, no lo que harías si comenzaras desde cero, pero era obvio que esto era algo que tenía un valor enorme.
Cuando el equipo cambió de rumbo a fines de 2012, continuaron usando la versión interna de IRC durante dos meses mientras creaban Slack desde cero. Se mudaron una vez que el producto estuvo listo para usarse internamente.
El MVP tuvo problemas de UX para equipos de más de ~10: al principio, "rogaron y engatusaron" a sus amigos en otras compañías para que lo probaran y dieran su opinión. Comenzaron con seis a diez empresas. Rdio es el más grande con alrededor de 120 empleados. Inmediatamente quedó claro que el producto funcionaba de manera muy diferente para equipos más grandes que el de Slack.
De Cal: (transcripción):
Esos primeros días de ser utilizado por otras personas fue un período de comentarios inmensos y ricos. Había tantas cosas en las que simplemente no habíamos pensado porque estábamos muy familiarizados con la forma en que estábamos trabajando, pero también cosas realmente tontas. Si tenía dos personas en su empresa llamadas "Matt", no había forma de eliminar la ambigüedad entre ellos, o si tenía 20 personas en su equipo, no había listas de desplazamiento porque éramos un equipo de 8 personas.
El equipo de Slack incorporó esos comentarios al producto, incorporó más equipos y continuó incorporándolos al producto. Este ciclo iterativo de productos es algo que aprendieron de Flickr.
Nuevamente de Cal: (transcripción):
Una lección obvia que aprendimos de Flickr fue que cuando observas productos de software excelentes, los que son excelentes no comenzaron de esa manera. Comenzaron de una manera muy diferente, el producto se presentó de manera muy diferente, los usuarios interactuaron de diferentes maneras y el equipo iteró a veces masivamente para llegar a donde están hoy. Se trata de ese circuito de retroalimentación de comprender lo que están haciendo sus clientes, los problemas que tienen, lo que están tratando de lograr y plegar eso nuevamente en el diseño de su software e iterar hacia un producto que puede ser excelente y que a la gente le puede encantar. .
La arquitectura de Slack se asemeja a la de un juego en línea: los clientes de Slack almacenan todo en caché. En el inicio, harían una sola solicitud de API, llamada rtm start. Esto descargaría todo sobre el espacio de trabajo de un usuario, incluidos los canales, los miembros y la membresía del canal. Luego, el cliente abriría una conexión WebSocket para enviar y recibir actualizaciones en el caché local.
De Keith Adams, arquitecto jefe de Slack de 2016 a 2020, hablando sobre cómo a los medios les gusta contar la historia del pivote de Slack desde un juego en línea: (transcripción):
Por lo general, las personas solo mencionan esto como algo divertido: "oh, eran una compañía de juegos, ¿no es divertido cómo las galletas se desmoronan a veces?". Eso es cierto, pero en realidad regresa de ciertas maneras. Si entrecierras los ojos e inclinas la cabeza, la arquitectura real de Slack se asemeja a la arquitectura de un juego en línea multijugador masivo. Tienes tu "mundo" en el que operas, que es tu equipo, y para hacer que ese mundo parezca persistente e interactivamente mutable con otras cosas en el mundo, terminas haciendo un caché bastante grueso de lo que está pasando en ese mundo y luego tienes una forma de obtener actualizaciones de baja latencia para los cambios en ese mundo. Ese tipo de paradigma mental de "oh, es como un juego en línea" explica mucho sobre Slack. Es por eso que tenemos pantallas de carga, por ejemplo. Es la misma razón por la que los videojuegos tienden a tener pantallas de carga.
Slack se creó para resolver su propio problema. Similar a Nomad List , la versión inicial del producto surgió de una necesidad genuina de los creadores.
Las cosas simples pueden proporcionar un valor inmenso. Slack era simplemente una extensión de un protocolo abierto, pero brindaba un valor inmenso a los usuarios correctos. Este es otro caso en el que no se requirió ninguna innovación técnica para crear algo enormemente valioso.
No es solo una coincidencia que Slack haya nacido de una empresa de juegos. Esto es relevante más allá de la arquitectura técnica. Slack no se siente como un trabajo. Es una de las razones por las que a la gente le encanta. MetaLab diseñó gran parte de la interfaz de usuario inicial de Slack. Del fundador de MetaLab, Andrew Wilkinson :
Para llamar la atención en un mercado abarrotado, teníamos que encontrar una manera de llamar la atención de la gente. La mayoría del software empresarial parece un traje de fiesta barato de los años 70 (azules y grises apagados por todas partes), así que, empezando por el logotipo, hicimos que Slack pareciera que se hubiera disparado un cañón de confeti. Azul eléctrico, amarillos, morados y verdes por todas partes. Le dimos el esquema de color de un videojuego, no un producto de colaboración empresarial.
También publicado aquí .