Las nuevas empresas de software de hoy tienen una ventaja significativa sobre las de hace cinco o diez años, en parte debido a la proliferación de proveedores de alojamiento en la nube a hiperescala como Google Cloud Platform (GCP), Amazon Web Services (AWS) y Microsoft Azure. Con una plétora de servicios gestionados disponibles con solo hacer clic en un botón, pueden crear rápidamente un prototipo de su solución y llevarla al mercado en un tiempo récord y a una escala casi infinita. Si bien hoy puede parecer más simple, preparar una startup para escalar en la nube aún requiere una consideración cuidadosa.

Tengo la suerte de haber formado parte de varias organizaciones tecnológicas durante más de veinte años, desde empresas emergentes totalmente nuevas hasta empresas financiadas con fondos de riesgo y de capital privado, e incluso conglomerados globales con OPI. Aprendiendo de tantas personas talentosas y mentores en el camino, "selecciono" las lecciones aprendidas, las herramientas, las técnicas y los procesos para llevar a cabo.

En un esfuerzo por "devolver el favor", me gustaría compartir algunas lecciones aprendidas. Este primer artículo de la serie presentará conceptos y recursos que encuentro útiles para crear y escalar nuevas empresas de software. En el segundo artículo , diseñaremos un inicio ficticio de citas en línea para ilustrar cómo encajan estas piezas. En el tercer artículo , ilustramos cómo, en última instancia, informan su arquitectura en la nube mediante GCP.

• Parte 1: antecedentes e introducción a la metodología
• Parte 2: implementación de metodologías con startup ficticia
• Parte 3: diseñar y escalar la infraestructura de la nube

A principios de 2020 decidí probar algo nuevo; en lugar de construir y hacer crecer nuevas empresas de software, comencé a asesorarlas y apoyarlas uniéndome a un socio en la nube con raíces en Israel llamado DoiT International . Nuestra empresa es totalmente remota y desde entonces ha crecido de alrededor de 50 personas a casi 500 en todo el mundo en poco más de dos años, lo que respalda más de mil millones de dólares en consumo anual de la nube. Estoy constantemente asombrado de lo bien que hemos preservado nuestra cultura a través de un crecimiento tan rápido mientras atraíamos y reteníamos a tanta gente talentosa.

Miles de organizaciones eligen a DoiT como su socio de servicios en la nube. Se benefician de asesoramiento y soporte sin costo, y herramientas de software de última generación diseñadas para cumplir con la promesa original de la nube: concéntrese en su producto y clientes, y no se preocupe por el resto. Si bien nos encantaría pensar que es así de simple, generalmente está precedido por nuestros clientes que cuentan con equipos técnicos altamente capacitados.

Una tendencia que he notado recientemente es el crecimiento de nuevas empresas de software en etapa inicial que adoptan tecnología en la nube y que pueden no tener equipos grandes o una gran experiencia en la nube. Como empresario de software, espero que compartir las lecciones aprendidas tanto de mi "vida pasada" como en DoiT haga que su viaje sea aún más exitoso.

Los primeros días

Alejándonos un poco de la tecnología, primero exploremos el viaje desde la identificación de un problema hasta la creación de una empresa dedicada a resolverlo y más allá. Hay algunas metodologías y marcos populares más allá de las mejores prácticas en la nube que puede apreciar a medida que su organización madura.

Cada técnica ilustrada arriba es iterativa en sí misma, pero como veremos en el siguiente artículo de esta serie, el resultado de cada una informa a las demás.

TL;RD; Recursos útiles en línea

En lugar de explicar las técnicas y los conceptos anteriores, recomiendo ver estos videos para completar los espacios en blanco y servir como un manual para ponerlos en práctica.

• ¿Debería construir una startup (14 min)— Michael Seibel, Y Combinator
• Estrategia vs planificación (9 min) — HBR [use un plan de 1 página como OGSM]
• Resumen de Lean Startup (13 min)— Eric Ries
• Validación de su idea de negocio (9 min)— Eric Ries
• Lean UX (60 minutos)—Jeff Gothelf
• Uso del lienzo Lean UX (15 min)— Jeff Gothelf
• Producto de construcción (59 min)— Michael Seibel, Y Combinator
• Cómo planificar un MVP (13 min)— Michael Seibel, Y Combinator
• Mapeo de historias de usuario (50 min)— Jeff Patton
• Guía definitiva para el mapeo de historias de usuario : Nick Muldoon, Easy Agile
• Arquitectura de software con el modelo C4 (35 min)— Simon Brown
• Construyendo una cultura de experimentación en Spotify (47 min)— Ben Dressler
• DevOps frente a SRE (44 minutos): Seth Vargo, Google

Una vez que haya reconocido un problema que se siente obligado a resolver, ayuda a pintar una imagen de hacia dónde se dirige y algunos indicadores clave de que está en camino de generar valor. Esto es similar a cómo Amazon requirió que los equipos redactaran el comunicado de prensa que describía lo que estaban construyendo en el futuro, antes de que fueran aprobados para construirlo.

Hace aproximadamente 10 años, durante una sesión de planificación de un día, un mentor que había hecho pública su empresa y luego la había vendido a Oracle por casi $ 2 mil millones, me presentó el Marco OGSM . Significa Objetivos, Metas, Estrategias y Medidas. Lo obliga a pintar una imagen concisa de dónde estará dentro de 3 a 5 años en el futuro, algunos objetivos medibles en el camino, mientras profundiza en estrategias y tácticas a corto plazo para lograrlos.

Termina con un plan de negocios de una sola página, un documento vivo que revisa y refina, que todo el equipo puede reunir y alinear el enfoque de todas las actividades. Por ejemplo, si alguna actividad no se corresponde con una estrategia definida para lograr un objetivo, se cuestiona si realmente vale la pena realizarla o si debe actualizar su estrategia.

Algunos pueden preguntarse cuál es la diferencia con otros objetivos de marco populares y resultados clave (OKR). OGSM mira hacia el futuro, mientras que OKR se enfoca principalmente en objetivos a corto plazo. Dependiendo de la etapa de su empresa, la introducción de OKR puede tener sentido, pero a menudo una sola visión a largo plazo que todos pueden respaldar es la "Estrella del Norte" necesaria.

Existen muchas otras técnicas, como el análisis FODA, las 5 fuerzas de Porter, el cuadro de mando integral o los 3 horizontes de McKinsey, que pueden contribuir a su plan estratégico general, pero OGSM sigue siendo mi herramienta personal para reducir el enfoque de un equipo en lo que importa y compartir el visión más grande.

Ideación

Los principios y procesos rectores al principio de su viaje pueden ayudar a alinear a los equipos a medida que crece. Creo que una cultura basada en datos y una mentalidad de medir todo deben ser parte de su cultura y venir desde arriba, y ser evidente en cada interacción.

Un par de mis recursos favoritos que refuerzan esta cultura experimental incluyen Lean Startup (y Lean Canvas) de Eric Ries y Lean UX de Jeff Gothelf. Casi todos los asesores e incubadoras de startups aconsejan a los fundadores que midan todo, iteren rápidamente y construyan un producto mínimo viable (MVP) para probar su idea en el mercado. Todos estos resuenan con los principios "Lean".

Jeff Gothelf lleva los principios "Lean" en una dirección que me encanta porque se aplica a todos los equipos, departamentos e ideas en organizaciones de cualquier tamaño. La premisa es "no sabemos nada" y para aprender [lo que los clientes quieren] y lo que realmente resuelve un problema, aplicamos el método científico: formulamos una declaración de hipótesis, la probamos mientras medimos, analizamos los resultados y corregimos el curso según sea necesario. . El valor de este enfoque es minimizar el esfuerzo desperdiciado y validar que está resolviendo los problemas correctos más rápido.

Diseño

Cuando observo a las personas que se niegan a documentar sus sistemas y arquitectura de software, me recuerda a alguien que intenta construir una casa con una pila de madera. Seguro que eventualmente puedes resolverlo, pero serías mucho más rápido con menos errores si tuvieras un plan. Dos de mis técnicas favoritas para el diseño de productos incluyen el mapeo de historias de usuario y el modelo C4 .

Al escribir las cosas, asegura un entendimiento compartido y responsabiliza a todos por cumplir con lo acordado.

Hace algunos años fui invitado como orador a la cumbre anual de CTO para la firma de capital privado (PE), Francisco Partners . Asistí a otras sesiones y una de las más intrigantes fue uno de los socios que asesoraba a otros CTO y ejecutivos de cartera sobre el seguimiento de métricas en sus organizaciones de productos. Una de las métricas que me sorprendió, pero que ahora tiene mucho sentido, es medir la cantidad de reelaboración para evaluar la efectividad de los gerentes de producto. Le he preguntado a otros líderes de ingeniería si miden el retrabajo, y la mayoría lo aprecia, pero todavía no.

El retrabajo es una métrica clave en la que puede influir si se toma el tiempo para comprender al cliente y priorizar la entrega del valor más inmediato. Esto es exactamente lo que el ejercicio de mapeo de historias de usuario ayuda a facilitar mientras fuerza la colaboración entre varias partes interesadas. Mi argumento a favor, en cualquier etapa de la empresa, es que es mucho más barato y rápido mover unas pocas cajas en una pizarra compartida que iniciar ciclos de desarrollo que luego resultan en reelaboración.

Soy el primero en admitir que he tenido algunos diagramas de arquitectura feos en mi época; He sido testigo de más. Es importante tomarse el tiempo para escribir su arquitectura y su relación con otros sistemas. El modelo C4 es una de las mejores formas de hacerlo de forma estándar sin necesidad de conocimientos de UML. Como se describe en los enlaces de video anteriores, la práctica estándar es diseñar hasta 3 niveles de profundidad (vista de componentes). Hay productos como IcePanel que facilitan esto, o varios complementos o herramientas en otras plataformas. Es más rápido de lo que piensa, y lo ilustramos en el siguiente artículo de esta serie.

Construir

Supongamos que su equipo está bien versado en esta fase. A medida que crece, la adopción de un marco bien definido para implementar ideologías ágiles puede ayudarlo a escalar. Si sigue los principios "Lean" y cambia sus prioridades en función del aprendizaje, ya está en el buen camino. A medida que el enfoque de la organización cambia de la velocidad y la innovación al crecimiento y la estabilidad, tenga en cuenta los puntos de inflexión y la composición del equipo a lo largo del camino.

Operacionalizar

Además de madurar sus prácticas de desarrollo de productos, también querrá mantener una cultura de responsabilidad compartida. Aquí es donde entran en juego los principios de DevOps. Google ha compartido su implementación de DevOps llamada Ingeniería de confiabilidad del sitio (SRE), y muchas organizaciones han adoptado estas prácticas.

Si bien puede no ser necesario tener un equipo o una función separados, los equipos con un mínimo de ingenieros que tengan la propensión a las operaciones, el monitoreo y la automatización darán sus frutos. Exploraremos estos conceptos con más detalle cuando profundicemos en el inicio de ejemplo y definamos su arquitectura e infraestructura en la nube.

Planificación para el crecimiento

A medida que una startup crece más allá del pequeño equipo fundador, también lo hace la complejidad de la comunicación y la gobernanza, como se ilustra a continuación.

Las empresas han resuelto estos desafíos de escalamiento reconociendo los puntos de inflexión de su negocio y formando equipos dedicados, en su mayoría autónomos, para abordar desafíos específicos.

Un gran recurso para escalar su equipo de software, por ejemplo, es esta publicación de blog de Seth Blank , que recomiendo leer. Blank advierte que los procesos y, en algunos casos, incluso las personas que ayudaron a que la empresa despegara pueden en algún momento convertirse en un obstáculo para su crecimiento y escalabilidad futuros, o es mejor orientarlos hacia "lo siguiente". Aquí es donde los 3 Horizontes de McKinsey se vuelven relevantes para la planificación estratégica futura. Por el contrario, un Blank diferente, Steve Blank, argumenta por qué ya no es válido hoy .

Hay otro recurso llamado " Topologías de equipos " que proporciona un modelo adaptable, práctico y paso a paso para el diseño de organizaciones y la interacción de equipos. La atención se centra en optimizar la organización y la plataforma, con lo que ellos denominan la plataforma viable más delgada (TVP).

Otro concepto que encuentro útil para escalar una organización o un producto es AKF Partners Scale Cube . Supe de esto por primera vez hace muchos años cuando se mencionó en un libro titulado " El arte de la escalabilidad " que compré para los líderes de mi equipo en un inicio anterior; también es otra referencia útil en cualquier momento, saltando a capítulos relevantes según sea necesario.

Casi todos pueden estar de acuerdo, sin embargo, a medida que su empresa continúa creciendo y forma equipos dedicados, la necesidad de gobernanza y procesos bien definidos, documentación, tutoría y capacitación crece con ella. He sido testigo de muchas organizaciones en esta etapa recientemente que también buscan orientación sobre la mejor manera de estructurar su infraestructura en la nube para acomodar de manera eficiente a sus múltiples equipos. Abordaremos eso más adelante en esta serie.

En la parte 2 de esta serie , exploramos cómo unir estas piezas para diseñar, construir y escalar un inicio ficticio de software de citas en línea.

Gracias por leer hasta aquí, y espero que disfruten la segunda parte .