Slack no necesita presentación, así que me sumergiré directamente. Gracias a   ,   y   por ayudar con esto. Cal Henderson Keith Adams Ali Rayl  Este es un número de mi boletín gratuito,   . Escribo sobre cómo las empresas exitosas construyeron sus productos (y rompieron las reglas) antes de que su producto encajara en el mercado. Monolith    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. Breve historia:  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): https://youtu.be/KxGm5i9lQao ?t=52     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): https://youtu.be/zsBjAuexPq4?t=1370   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): https://youtu.be/EhxX06-LsZs?t=1962     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:  Noviembre de 2012: comenzó la producción de Slack  Mayo de 2013: unas 45 empresas usaban Slack en una versión beta privada  Agosto de 2013: se anunció una vista previa pública y 8000 personas se registraron en 24 horas  Abril de 2014:   con 60 000 DAU y 15 000 asientos pagados. recaudó $42,75 millones en un Serie C  Octubre de 2014:   con 200 000 equipos activos y 73 000 asientos pagados. recaudó $120 millones con una valoración de $1120 millones  Slack   con una valoración de 15.700 millones de dólares. salió a bolsa en 2019  Desarrollo      (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): La versión interna inicial de Slack era solo una envoltura alrededor de IRC: Internet Relay Chat https://youtu.be/EhxX06-LsZs?t=1902   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): https://youtu.be/zsBjAuexPq4?t=374   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.    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. El MVP tuvo problemas de UX para equipos de más de ~10:  De Cal:   (transcripción): https://youtu.be/TpVIeP3BIVY?t=1080   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): https://youtu.be/TpVIeP3BIVY?t=1125   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. .    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. La arquitectura de Slack se asemeja a la de un juego en línea:  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): https://youtu.be/WE9c9AZe-DY?t=445     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.  Mi toma    Similar a   , la versión inicial del producto surgió de una necesidad genuina de los creadores. Slack se creó para resolver su propio problema. Nomad List    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. Las cosas simples pueden proporcionar un valor inmenso.    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.   : No es solo una coincidencia que Slack haya nacido de una empresa de juegos. 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.  Enlaces / Recursos   Cómo funciona Slack   La historia del origen de Slack   De 0 a 1.000 millones de dólares: el fundador de Slack comparte su estrategia de lanzamiento épica   La arquitectura de Slack con Keith Adams   Salsa secreta de $ 25B de Slack   Cómo obtener ideas y medir   Stewart Butterfield, cofundador y director ejecutivo de Slack   Pivotes, producto y futuro con Cal Henderson   Web 2.0 Expo SF 2010: Stewart Butterfield y Cal Henderson, "El enfoque de un nerd web..."  También publicado   . aquí

This story contains new, firsthand information uncovered by the writer.

Learn how startup engineers broke the rules

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Download free Tech Leaders Productivity Report!

El nacimiento de Slack de una empresa de videojuegos no fue una coincidencia

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps