Entiendo que, en una empresa con producto propio es diferente pero, aún así, si es producto con margen de mejora, cómo es posible que no haya nada más que hacer?
Hacer en un contexto de tiempo y espacio. Dinámico.
El 1 de enero de 2023 se decide que se va a desarrollar un producto que va a costar 12 meses de desarrollo. ¡Que los proyectos grandes de los arquitectos de software (R) y CTOs de turno suelen ser años! Pero pongamos 1 año de proyecto. Esta decisión está basada en un tiempo y un espacio concretos. Y bajo este contexto se ha visto que es una buena decisión aprobada por management.
La realidad es que a los 3 meses, cambia el tiempo, el espacio será distinto. En el nuevo espacio habrá nuevas prioridades en la gestión, habrá nuevas oportunidades/debilidades/amenazas de negocio que antes no se habían identificado o han evolucionado. La realidad es que tanto el tiempo como el espacio son complejos y cambiantes. Lo que se conoce como dinámicos. Aquí hay que darse cuenta de que el problema no es el famoso "cambio de requerimientos" que se vende, sino el "cambio de opinión de los managers" sobre los requerimientos. El problema es la jerarquía de decisión empresarial. Lo de los "cambios de requerimientos de negocios" es una falacia que se inventaron los managers para justificar su incompetencia.
Es nuestra responsabilidad como ingenieros tapar las malas decisiones de los managers y directivos que tenemos por encima y no saben nada de lo que deciden. Tener alguien por encima decidiendo, en lugar de la toma de decisiones de abajo hacia arriba, es lo peor que puede pasar en una empresa. Cuando el jefe toma las decisiones en lugar del equipo de producto que implementa... Huye. Volvamos al ejemplo. Por estos motivos, malas decisiones y muchas excusas, el proyecto inicial que estimaron en 1 año de dedicación y esfuerzo no se podrá lograr. Y nosotros sabemos cómo dividirlo en pequeños entregables de semanas o meses, y trabajamos para lograr estas pequeñas entregas para que cuando el CTO de turno decida cambiar toda la arquitectura de CLOUD a IN-HOUSE porque SÍ, el equipo esté listo.
Entonces, nuestro trabajo no consiste en hacer lo que se supone que debemos hacer en 8 horas al día, esto es una cortina de humo empresarial para managers y demás personas no productivas, sino en prever lo que va a ocurrir, las malas decisiones que el jefecito de turno tomará y además, implementar la mejor solución posible bajo todos los impedimentos que las empresas ponen a sus empleados productivos. Por este motivo, la carga real de trabajo de implementación es menor, porque se espera a que el tiempo pase y los requerimientos cambien para adaptarse. Cambiamos trabajo real espacial por trabajo especulativo temporal. La planificación que un arquitecto de software o un CTO hará con su equipo de supermanagers y superarquitectos nunca se desarrollará en ningún proyecto. La energía se transforma. El trabajo real que no se hace es trabajo especulativo de planificación y preparación que se realiza y TIEMPO de espera.
Conclusión. La ingeniería de software consiste en solucionar las malas decisiones de los managers que no tienen ni idea y adaptarse al tejido empresarial interno. Ley de Conway. Una solución que se ha demostrado que da resultado es quitar capas intermedias que no aportan nada salvo ruido y dar ownership a los equipos de producto que producen beneficios a la empresa.
La única ley en software, la ley de Conway.
