Las arquitecturas sin servidor afectan fundamentalmente los factores limitantes que limitan el desarrollo de productos.Los gerentes de producto en la organización actúan en una variedad de roles. A veces se les llama la "voz del cliente", a veces desempeñan el papel de
"peligro de gato corporativo" . Son hermanos de piel grasa, personas que inexorablemente lo llevan a entregar el producto, a pesar de cualquier ética o excusa. Un buen gerente de producto rara vez se convierte en el ídolo de alguien, pero es gracias al trabajo de tales personas que la mayoría de las soluciones tecnológicas que alguna vez ha utilizado están incorporadas.
PM siempre está buscando herramientas de la más alta calidad para resolver el problema. Sabemos que los competidores pisan los talones constantemente, los clientes están cansados de esperar, por lo que constantemente tenemos que actuar de manera más inteligente, rápida y eficiente. Con el advenimiento de las tecnologías sin servidor, no quedó claro de inmediato cómo encajarían en la lista de deseos de gestión de productos. Sin embargo, después de trabajar con estas tecnologías durante un año, veo que resuelven algunos problemas de desarrollo de software que nos parecieron para siempre.
Paradoja: tamaño del equipo y rendimiento
La primera regla de gestión de productos dice: la cantidad de trabajo a realizar está en constante crecimiento. La acumulación de pedidos continúa aumentando y se desploma a cero en un solo caso: cuando se elimina el producto. Lo más difícil es convertir los elementos más importantes de su cartera de pedidos en un producto listo para su entrega. En igualdad de condiciones, se cree que se debe observar la siguiente relación:
Si una excavadora puede reciclar 1 tonelada de tierra por día, se supone que 10 excavadoras pueden reciclar 10 toneladas. Como regla general, la gestión de recursos en las empresas se basa en este principio: si desea aumentar las ventas, contrate más personal de ventas. Cuando se desarrolla software, cuando crece la cartera de pedidos, la tentación es simplemente aumentar el equipo. Sin embargo, en casos con productos y servicios complejos, aproximadamente el siguiente cronograma generalmente se perfila con el tiempo:
Es raro ver cómo funciona un gran equipo al ritmo de Stakhanov; pero a menudo sucede que un equipo pequeño con una constancia envidiable progresa a pasos agigantados.
Muchas startups tienen el siguiente error: tan pronto como el producto se vuelve exitoso, se agregan más nuevos desarrolladores y gerentes al personal. Pronto, de repente resulta que la velocidad comienza a caer. Cual es el problema ¿Que los primeros desarrolladores tenían más talento, que la burocracia creció en la empresa y cómo se planificó la arquitectura?
Creo que todos estos son solo síntomas, no la raíz del problema. El problema en sí se reduce a la interacción de tres factores críticos, de los cuales solo dos pueden controlarse directamente:
- La fragilidad es el efecto de nuevos cambios. Si una nueva función afecta solo a una parte de la máquina, entonces es fácil de probar e implementar. Si afecta a todos los elementos de la máquina, las pruebas se vuelven más difíciles y al mismo tiempo más importantes, y la implementación requiere un orden de magnitud más tiempo.
- El volumen de trabajo es el trabajo más pequeño que puede realizar un equipo y ofrece una característica productiva en la salida. Por ejemplo, el resultado es "Pagar con Alexa" en lugar de "reunirse y discutir cómo hacer pagos con Alexa".
- Complejidad: cuánto conocimiento se requiere para implementar una característica. ¿Es un desarrollador que sabe cómo escribir una función capaz de hacer lo mismo dentro de la organización? ¿Qué cambios adicionales deben ocurrir para que el progreso se ralentice gradualmente y el producto deje de crecer con características que son valiosas desde el punto de vista del cliente?
Estoy especialmente interesado en por qué, en los albores de la existencia, todos estos factores están equilibrados de manera óptima: no hay nada frágil, la cantidad de trabajo no es particularmente grande (y generalmente puede estar de acuerdo con el cliente), y la complejidad está prácticamente ausente. Entonces, si un equipo necesita crear un sitio que cumpla con GDPR, entonces tendrá tiempo para estudiar este problema, se tomará una decisión rápidamente y el equipo se asegurará de que el sitio funcione exactamente como se planeó.
En las empresas más grandes, estos factores se combinan, lo que resulta en un tamaño de equipo creciente y el volumen de trabajo realizado se reduce. Para crear un sitio web compatible con GDPR en dicha empresa, necesitará la firma de un abogado, la aprobación de los especialistas en marketing, la aprobación del proyecto a nivel de la junta directiva, las pruebas A / B de la implementación menos disruptiva, la coordinación de las interrupciones de desarrollo con el equipo de administradores, la coordinación con los planes de implementación adoptados por otros equipos - La lista continúa. Incluso con esta cantidad de control y la cantidad de procesos, el equipo tiene mucha menos confianza en que tendrá éxito, debido a la fragilidad de todo el sistema y muchas incógnitas en el ecosistema.
Ampliando este ejemplo al tamaño de un proyecto real, en el que puede haber docenas de características y cientos de cambios, es fácil entender cómo, debido a la influencia de estos factores, el gráfico de la relación "tamaño del equipo / volumen de trabajo" cambia del primero al segundo. A medida que el equipo crece, estás condenado a hacer menos trabajo por unidad de tiempo, sin importar cómo trates de burlar al coloso organizacional. O parece que sí, pero ¿qué se debe hacer entonces?
Cómo hackear los tres factores
Este problema me ha perseguido durante muchos años, lo que me llevó a estudiar sus posibles causas. ¿Es posible que las startups progresen rápidamente? Por un tiempo, pensé que sí, frente a las dificultades de la gestión de productos en grandes organizaciones. Sin embargo, luego miré los tres factores más de cerca.
La fragilidad siempre es en detrimento de usted: provoca una deuda técnica cada vez mayor en cualquier proyecto de cualquier tamaño. La situación recuerda a la "vida media por el contrario": cualquier elemento del programa crece con el tiempo y debido a esto (durante el desarrollo) se vuelve más frágil, y todo esto se agrava con cada nueva línea de código.
La cantidad de trabajo no está asociada con una característica específica del producto ("Pagar con Alexa"), sino con diferencias en los contornos de la infraestructura, si comparamos los estados "antes" y "después". Cuanto más difícil se vuelve el "después", más se reduce la cantidad de trabajo realizado. Es por eso que en muchas empresas, cuando se planifica el trabajo, el énfasis se desplaza de las necesidades del cliente ("Pagar con Alexa") a las necesidades de la organización ("Conocer y discutir quién debe participar en la implementación de la función" Pagar con Alexa ").
La complejidad es una combinación de factores sociales, organizativos y técnicos que afectan directamente la duración de la búsqueda de un desarrollador adecuado, la capacidad de tratar a los programadores como personas multitarea a las que se les puede confiar cualquier trabajo. Además, es la complejidad, el aspecto que probablemente permanecerá invisible, indocumentado e incomprendido. Un desarrollador puede escribir una aplicación React en casa y lanzarla él mismo, pero en la organización tendrá que tomar una docena de pasos adicionales que le tomarán su tiempo, y las características interesantes para el usuario no cambiarán en absoluto. El programador pasará la mayor parte del día en ellos.
Juntos, estos tres factores forman un círculo vicioso, de modo que la cantidad de trabajo realizado disminuye, la fragilidad aumenta, el desarrollador logra completar cada vez menos funciones, y su producto está cubierto de complejidad como un lodo invisible. En consecuencia, el crecimiento del equipo no ayuda, y la velocidad solo se puede aumentar conscientemente mediante la astucia con números e indicadores. Un síntoma clásico: la posición de "reunión celebrada" aparece en los informes de sprint.
En las grandes empresas, tuve que observar un par de enfoques defectuosos diseñados para romper este ciclo. El primero es "Ágil a gran escala", lo que resulta en grandes reuniones en las que participan absolutamente todos los participantes en el desarrollo de una característica particular y se hacen intentos para coordinar el trabajo. Así que trate de coordinar el trabajo y comprenda la complejidad. Tal enfoque es bueno para las empresas de distribución de alimentos que ofrecen almuerzos encantadores, pero en nuestro caso no funciona. El hecho es que a medida que aumenta el tamaño del grupo de proyectos prioritarios, se vuelve más y más, y ellos mismos disminuyen. Por lo tanto, no es posible resolver fundamentalmente los problemas de fragilidad y complejidad. Con el tiempo, Agile a gran escala ofrece una lista táctica de tareas que se asemeja a una lista de compras, y se parece cada vez menos a un camino holístico de una característica reflexiva a otra.
En segundo lugar, los "grupos de innovación" corporativos internos a menudo intentan impulsar cambios periféricos con la esperanza de que este trabajo arraigue en una máquina frágil y que toda la estructura cambie para mejor. Este enfoque tiene un efecto secundario extraño: se consolida la creencia de que solo esos "grupos de innovadores" tienen derecho a realizar cambios en el proceso. Por lo tanto, un método similar tampoco resuelve problemas con la complejidad organizacional.
Después de haber visto muchos años de varios fracasos, llegué a la conclusión de que es necesario piratear los tres factores para evitar su efecto combinado en el trabajo realizado y hacer frente a la inercia:
- La fragilidad no debe aumentar en futuras versiones o a medida que el producto envejece.
- El trabajo no debe ser inferior al requerido para crear una característica significativa desde el punto de vista del usuario.
- La complejidad no debería afectar el trabajo de un solo desarrollador.
Si logra adoptar estas ideas, estará protegido contra el rock, que busca todos los productos de software en la historia de la humanidad. Suena genial, pero ¿cómo se puede lograr esto?
Si logra adoptar estas ideas, estará protegido contra el rock, que busca todos los productos de software en la historia de la humanidad. Suena genial, pero ¿cómo se puede lograr esto?
Limitaciones de ruptura de tecnologías sin servidor
Gracias al advenimiento de la tecnología en la nube, fue posible pavimentar senderos importantes hacia un nuevo estado "pirateado". En general, con la llegada de las nubes, el proceso de entrega de un producto de software se hizo más compacto, ya que un proveedor comenzó a hacer muchas cosas de rutina por usted. Antes de que aparecieran las nubes, si necesitaba implementar una nueva función de usuario, tenía que pedir un servidor, instalar equipos en bastidores, ponerse de acuerdo en instalar redes en un centro de datos y luego mantener este equipo, que se desgasta con el tiempo. En la nube, todo esto se puede alquilar, eliminando así docenas de elementos organizativos y ahorrando meses completos.
Además, al eliminar la necesidad de actualizar el equipo en un centro de datos y proporcionar acceso al hardware a pedido, reducimos la fragilidad y la complejidad. Poner programas en uso es mucho más fácil que en los viejos tiempos. Sin embargo, con el tiempo, la carga de administrar una infraestructura virtual extensa ha aumentado significativamente, y muchos métodos de entrega obsoletos no han cambiado. Al usar las nubes, el equipo puede aumentar significativamente antes de que el trabajo comience a disminuir, sin embargo, comienza a disminuir, de una forma u otra.
Las tecnologías sin servidor cambian radicalmente esta dinámica. La aplicación sin servidor consta de pequeñas piezas de código escritas por su equipo (el llamado "pegamento") y "cuadros negros" funcionales que son administrados por el proveedor de la nube. El cuadro negro simplemente acepta una configuración y reacciona a los cambios. En una aplicación con una arquitectura de alta calidad, una parte estándar del trabajo operativo asociado con el funcionamiento de la aplicación recae en las cajas negras estándar. La aplicación en sí ya no es una función monolítica, sino una estructura federal de funciones y cuadros negros.
En la práctica, esto afecta dramáticamente los tres factores que mencioné anteriormente:
- La fragilidad se reduce debido a los costos de administración de infraestructura cero y la unión débil. En nuestros propios proyectos, se observó que la base del código como resultado de tales cambios a veces se puede reducir diez veces.
- El tamaño de la "pieza de trabajo" generalmente es comparable al costo de crear una nueva característica, ya que resulta trivial crear nuevas versiones de funciones o funciones completamente nuevas que no se requerían previamente.
- La complejidad no afecta al desarrollador: si puede escribir una función que procese pagos con tarjeta de crédito, entonces prácticamente no hay nada que hacer además de este código en la aplicación sin servidor, sin envoltorios organizacionales y sin consideración del ecosistema, por lo que el trabajo podría ralentizarse.
Al administrar incluso aplicaciones sin servidor muy grandes, es fácil para el gerente de producto observar más de cerca los muy pocos elementos que se vieron afectados por los cambios realizados. Además, es fácil lanzar dos versiones de manera competitiva colocando banderas de características. Además, generalmente ni siquiera es necesario demoler versiones antiguas de código.
En aplicaciones sin servidor, la infraestructura siempre se construye en la periferia, y usted escribe solo el código mínimo necesario que combina servicios totalmente administrados. Nunca tiene que pensar en ellos desde un punto de vista operativo. No estamos tratando de controlar el monolito, limpiar el código antiguo o ver todo el sistema desde una vista de pájaro.
¿Por qué es inmensamente importante?
A medida que aumenta el ritmo del cambio, se hace cada vez más difícil predecir cómo se verá su programa en el futuro o qué querrán los usuarios de usted. Por lo tanto, los intentos de escribir código "durante siglos", de modo que debe funcionar en el futuro, a pesar de cualquier cambio, se vuelven cada vez más inútiles. Hemos visto cuán mala es la reutilización de código en la mayoría de las empresas y cómo la adherencia a plataformas obsoletas ralentiza el progreso.
Ahora todo está organizado para que el sistema antiguo se desarrolle y se mantenga durante el mayor tiempo posible, hasta que su soporte comience a quitarle al programador casi todo el tiempo. Después de eso, la compañía comienza de nuevo con el nuevo sistema, prometiendo solemnemente no repetir los errores cometidos en el anterior. Cuando tres factores tarde o temprano estrangulan el nuevo sistema, hay un "incendio forestal" tecnológico, después del cual nuevamente debe comenzar de nuevo.
Nos enfocamos en la lucha contra los síntomas de la complejidad, razón por la cual tantos paradigmas van y vienen, sin dejar rastro significativo en la historia de la gestión de productos. El desarrollo sin servidor, a su vez, permite al equipo minimizar el aumento de la complejidad y continuar entregando un producto valioso a un ritmo bastante uniforme, sin caer en trampas clásicas que durante décadas han sido el azote de cualquier desarrollo de software.
El paradigma sin servidor apenas comienza a desarrollarse, pero ya parece extremadamente prometedor. En un momento en que el cliente requiere que tenga nuevas funciones como nunca antes, los gerentes de producto finalmente pueden adquirir una plataforma que le permite pensar con precisión basándose en la preparación de nuevas funciones. Este proceso no se ve obstaculizado por el aumento de la complejidad organizacional, y tampoco se detiene debido a la fragilidad excesiva.