En la parte 1 de esta serie , exploramos metodologías y marcos que encuentro útiles para construir y hacer crecer nuevas empresas de software. El propósito de esta publicación es ilustrar cómo puede aplicar estas técnicas para minimizar el esfuerzo desperdiciado y cómo la planificación de su negocio de software se traduce en su infraestructura en la nube.

Requisitos previos para seguir adelante

• Has leído la parte 1 de la serie .
• Está familiarizado con los marcos / metodologías que exploramos a continuación al ver los enlaces de video compartidos en la parte 1

El diagrama anterior ilustra los conceptos clave de las metodologías antes mencionadas. Para esta publicación, nos divertiremos inventando un inicio ficticio de citas en línea y "escalarlo". Ilustraremos la aplicación de estos principios y la relación entre la estrategia de la empresa, el producto y las necesidades de crecimiento, y cómo informan nuestro diseño de infraestructura en la nube.

Identificar el problema que estamos resolviendo y para quién

Suponga que usted y los demás están hartos de estar solos y que las soluciones existentes no son suficientes. Has estado en bodas, demasiadas en realidad, y has estado en bares, e incluso probaste aplicaciones populares, pero todavía sientes que falta algo. Te apasiona este problema y crees que eres el equipo para ayudar a resolver la soledad de las personas, incluida la tuya. Primero analicemos las posibles estrategias de otras soluciones.

Descargo de responsabilidad

Nunca he usado una aplicación de citas en línea, así que solo estoy "adivinando" qué características y funcionalidades incluyen. Usando lo que está en la televisión o en los titulares sobre varias aplicaciones populares, podemos pretender construir un competidor. Si mis suposiciones están muy lejos, o si no exploramos cada tipo de relación, les pido que suspendan la incredulidad con el fin de ilustrar estos conceptos .

eHarmony

Este servicio tenía la teoría de que al emparejar en base a un perfil científico de personalidad, las personas se sentirían menos intimidadas. Su estrategia es hacer de la personalidad el factor principal, atraerán a personas menos seguras de su apariencia que aún se sienten solas, capitalizando un mercado sin explotar.

Tinder

Este servicio tenía la teoría de que muchas personas se sentían solas, pero no buscaban relaciones a largo plazo. Su estrategia era convertirse en un reemplazo para las conexiones casuales y capturar esta porción del mercado.

Andar de forma vacilante

Este servicio tenía la teoría de que las mujeres se sentirían más cómodas en una plataforma si pudieran elegir con quién interactuar. Su estrategia era dejar que las mujeres decidieran enviar el primer mensaje después de un partido.

eTumble — ¡NUEVO!

Nuestra suposición es que las personas se sienten solas y que las soluciones en el mercado aún no han resuelto la soledad a escala global . Creemos que la solución ganadora es una combinación de las tres anteriores. Sospechamos que, en el fondo, los buscadores de conexiones casuales preferirían tener la oportunidad de una conexión personal más profunda a través de la combinación de personalidad inicial, pero las mujeres toman la decisión de interactuar o no.

Las prácticas Lean Startup aconsejan operar como un "gran experimento", haciendo suposiciones audaces y luego observar (no preguntar) los comportamientos de los usuarios, mientras se itera rápidamente. A menudo eliminamos ideas utilizando un lienzo "Lean" , pero asumiremos que nuestro equipo ya lo ha hecho anteriormente. ¡Empecemos!

Comenzando con una visión y una estrategia

análisis FODA

Al reconocer las fuerzas internas (fortalezas, debilidades) y externas (oportunidades, amenazas), puede aprovechar un análisis FODA para identificar mejor lo que debe ocurrir para tener éxito.

Este análisis informa el diseño de su producto a medida que prueba hipótesis para resolver los altibajos inevitables. Por ejemplo, si la alta rotación de usuarios es una amenaza, puede priorizar las funciones que hacen que las personas regresen a su plataforma. Dada una debilidad fue la falta de experiencia en psicología en el equipo, ya sabes, al contratar o atraer asesores, a quién apuntar. Si el equipo tiene una experiencia limitada con las aplicaciones de la competencia, entonces sabe que una tarea es usarlas y tener citas: ganar, ganar.

Definir plan estratégico inicial usando OGSM

En la etapa inicial, su objetivo será lanzar un producto mínimo viable (MVP) rápidamente para comenzar a observar el comportamiento del usuario y probar hipótesis de forma iterativa. En el mundo del software, solemos bromear diciendo que los prototipos siempre se convierten en producción, a pesar de nuestras mejores intenciones. Invertir unos días para intercambiar ideas con su equipo para documentar estrategias y medidas puede reducir la repetición del trabajo y acelerar el diseño y desarrollo de su producto; exploremos cómo a continuación.

Observe que en el ejemplo anterior de OGSM, ya comenzamos a identificar nuestras necesidades futuras de equipo, producto, métricas e infraestructura. Necesitaremos experiencia en aplicaciones móviles, aprendizaje automático y desarrollo de API. También necesitaremos traducción de idiomas, ofuscación de texto e imágenes y aceptación de pagos en línea. Para audiencias globales, debemos cumplir con los requisitos normativos y de privacidad, especialmente en la Unión Europea.

Experiencia de usuario optimizada

Lean UX es más conocido entre los equipos de productos, que es donde el autor Jeff Gothelf tuvo sus humildes comienzos. Creo que la efectividad de comunicar cualquier idea a través de declaraciones de hipótesis garantiza la conciencia en toda la organización y no solo en los equipos de productos. Creo que Lean UX pertenece a la estrategia y la visión y se usa en todas partes.

Cada estrategia, y subsecuentemente táctica (característica), en el plan OGSM anterior es esencialmente una hipótesis. Cuanto más expresamos nuestras ideas en esta estructura, más procesables y enfocadas se vuelven. Por ejemplo, la estrategia de que lograremos nuestros objetivos “brindando un lugar más seguro para interactuar” podría formularse como:

“Creemos que [millones de usuarios] se unirán a nuestro servicio si [las mujeres] [se sienten más seguras para interactuar] con [solo ellas eligen iniciar una conversación después de los partidos]”.

Esto se traduce vagamente como "Creemos que [resultado comercial] se logrará si [usuario] obtiene [beneficio] con [función]". como se describe en el lienzo Lean UX. A veces intercambio este formato con otro definido en los principios ágiles de "Descubrimiento de productos", pero la premisa es la misma: comunicación estructurada .

Puede ver la naturaleza iterativa de estas metodologías a medida que las combina. Si aún no lo ha hecho, lo animo a revisar los videos sobre Lean UX en la parte 1 de esta serie .

Diseño de producto

Volviendo a los principios "Lean", una vez que tenga suposiciones o hipótesis audaces sobre el problema que está resolviendo, para quién lo está resolviendo y cómo pretende resolverlo, debe repetirlas y probarlas rápidamente.

En lugar de preguntar a los usuarios, siempre es mejor observar su comportamiento para validar sus suposiciones, por lo que se recomienda lanzar un MVP. En un producto en vivo, puede aprovechar las herramientas de prueba A/B o las banderas/toggles de funciones también.

No necesitamos todas las características eludidas en nuestro OGSM inmediatamente para probar nuestras teorías, pero ahora tenemos una comprensión holística de hacia dónde nos dirigimos. A continuación, priorizamos lo que nuestro MVP debe ofrecer para maximizar el valor del usuario a medida que iteramos rápidamente a partir de entonces. Para ello, aprovecharemos el mapeo de historias de usuario .

Mapeo de historias de usuario

¡Lo que ves arriba ya es la versión seis! Comenzando con una vista holística, tracé rápidamente el recorrido general del usuario. Luego mezclé las casillas y volví a priorizar las historias de los usuarios para identificar la cantidad más pequeña que podíamos entregar para probar los resultados deseados para el público objetivo.

A medida que prueba hipótesis en el camino, aplica sus descubrimientos y continúa editando estos "documentos vivos" de manera ágil, en lugar de perder el tiempo en especificaciones detalladas estancadas.

Arquitectura del modelo C4

Ahora tenemos información que nos ayuda a definir la arquitectura de nuestro software y sistema, pero a menudo se pasa por alto hacerlo de una manera estandarizada. Asegúrese de tener un plan (o plano) de lo que está construyendo para comunicarse de manera eficiente con otras partes interesadas. Si bien UML sigue siendo un estándar desde hace mucho tiempo, el modelo C4 más liviano es lo que recomiendo hoy.

Para abreviar este artículo, ilustraremos un ejemplo parcial de nuestra arquitectura para eTumble. Aunque hay 4 niveles para C 4 , la práctica estándar es ilustrar solo con la profundidad requerida; el nivel de "Código" que efectivamente sería notación UML generalmente se omite.

Como se indicó en mi descargo de responsabilidad anterior, esta es una aplicación ficticia y nunca he usado un servicio de citas en línea, por lo que estas son conjeturas para ilustrar el proceso.

A menudo empiezo a esbozar ideas en papel para pensar en el diseño. Una vez que tengo una idea general de lo que se necesita, enumero los elementos de la arquitectura para aclarar los detalles. Por ejemplo, sabemos que necesitaremos una base de datos, pero nuestra estrategia implica un juego global. Necesitamos decidir si podemos comenzar con Postgres o MySQL para el lanzamiento, y qué tan difícil puede ser luego migrar a un sistema distribuido como Cockroach DB o Cloud Spanner de GCP.

Experimentando el "bloqueo del escritor" a veces mientras miro los cuadros y las líneas en una pantalla, encuentro que usar una hoja de cálculo como la que se muestra a continuación facilita mover cosas o insertar filas a medida que pienso en más cosas, antes de diagramar.

En algunas aplicaciones, simplemente puede copiar/pegar como dentro de IcePanel , como se muestra a continuación. Hay soporte para Markdown, que es aún más rápido una vez que estás familiarizado.

Esperemos que esto demuestre lo rápido que puede transferir lo que escribió a una herramienta de diagramación: tardará menos de una hora en producir hermosos diagramas. Imagínese interactuar con diseñadores e ingenieros con los diseños anteriores y lo rápidos (y baratos) que serían.

Escalando las cosas

Las sugerencias anteriores de que "lo escalaríamos" significaban que anticipamos nuestras necesidades futuras en función de nuestro plan estratégico y nuestra visión general ilustrada en el mapa de la historia. Anteriormente mencioné el AKF Scale Cube y, al aplicar sus principios de ejes xyz, concluí que nuestra escala global y decenas de millones de usuarios necesitarán un diseño sin estado, un sistema basado en eventos, una arquitectura de microservicios y, finalmente, varios equipos, con alojamiento que abarca múltiples regiones geográficas en una plataforma de nube pública.

• Nuestro eje x ( duplicado y escalabilidad horizontal ) se adapta a aplicaciones en contenedores sin estado y alojamiento en la nube pública.
• Nuestro eje y ( especializarse ) se adapta a microservicios creados específicamente, activados por HTTP/RPC o por mensajes Pub/Sub. Estos también ayudan a definir cómo es probable que crezcan sus equipos, permitiendo la autonomía y el acoplamiento flexible para poseer una pieza clave de valor en el sistema; esto a menudo se alinea con la UX de referencia ilustrada en el mapa de la historia.
• Nuestro eje z ( dividir cosas similares ) se adapta a la regionalización. No abordamos esto completamente en nuestro ejemplo ficticio. Supongamos, dada una estrategia global, que las restricciones jurisdiccionales sobre los sistemas y la soberanía de los datos, las monedas extranjeras, los idiomas y las futuras estrategias de lanzamiento al mercado (GTM) de las ventas del canal pueden influir en la forma en que ampliamos este eje. Incluso podría basarse en dónde encontramos/permitimos talento para nuestro equipo, o incluso como se describe en "Topologías de equipo", la carga cognitiva del equipo.

Lo que hemos aprendido y construido hasta ahora:

Tiempo invertido hasta ahora en el diseño de eTumble, nuestro inicio ficticio de citas en línea:

• Esbelta [Inicio | UX] lienzo : no lo ilustramos, pero normalmente este es el punto en el que comienza a escribir qué problema está resolviendo, para quién lo está resolviendo y los beneficios/valor que ofrece. Puede validar su idea con un "MVP de cortina de humo" y una página de destino, por ejemplo. Mire los videos en la parte 1 para obtener más información.
• Análisis FODA : identificamos los aspectos positivos que queríamos explotar y los negativos que debemos resolver, informando nuestro plan OGSM. (30 min; esperar varias horas)
• Plan OGSM : identificamos las características clave, las tecnologías, las métricas y el equipo que necesitaremos para implementar nuestra estrategia, informando nuestro story map. (1 hora; esperar 1–2 días)
• Story map : organizamos y priorizamos las historias de los usuarios, identificamos a nuestro candidato MVP e informamos nuestraarquitectura holística como se ilustra arriba. (3 h; esperar 1–2 días)
• Arquitectura del modelo C4 : identificamos los sistemas, las bases de datos y los componentes necesarios, informando nuestra infraestructura requerida. (3 h; esperar 2–5 días)

Impulsados ​​con estos "documentos vivos", nuestro equipo y las partes interesadas ahora tienen una comprensión compartida de por qué estamos haciendo lo que estamos haciendo, cómo planeamos ganar (o al menos teorías para probar) y qué vamos a construir para resolver el problema del panorama general.

Invertir este tiempo para colaborar y anotar las cosas también simplifica el proceso de diseño de la infraestructura de la nube, los repositorios de código fuente y el monitoreo/métricas que necesitaremos para eventualmente admitir eTumble. Exploraremos esto y más en la parte 3 de esta serie .

Gracias por leer hasta ahora y espero que disfruten de una inmersión más técnica en la parte 3 .