Cuando hablamos de Ingeniería de software hablamos de arquitectura, hablamos de desarrollo, hablamos de equipos, hablamos de infraestructura, en definitiva hablamos de todo lo que se necesita para desarrollar y proveer la tecnología necesaria a una empresa.
La estrategia sin proceso es poco más que una lista de deseos
La estrategia de ingeniería de software es el diseño e implementación de los procesos necesarios para producir y gestionar el software de forma alineada con la estrategia de la empresa u organización. Más concretamente se trata de alinear la arquitectura tecnológica, modelo organizativo y operativo con los objetivos de la compañía.
Una buena estrategia comienza con tener el objetivo correcto
La arquitectura tecnológica es la base tecnológica en la que se construirá y se desarrollará el producto. Al final se trata de establecer cuales son las reglas del juego que mejor se adaptan a las necesidades del proyecto. Esto incluye tanto definir cuales son los patrones de implementación como los parámetros de desarrollo que definirán el software que vamos a crear desde el primer momento.
En este ámbito hay que tomar decisiones que no nos limiten la escalabilidad del equipo pero que tampoco nos limiten la escalabilidad del producto. Algunos ejemplos de errores que he visto a lo largo de mi carrera han sido:
- Escoger un leguaje de programación poco extendido en el mercado (Ruby) para implementar un core de producto he visto como en el momento de pasar a ser convertirse en unicornio ha limitado el crecimiento del equipo teniendo a perfiles de desarrollo cobrando más del 200% de su precio real en el mercado. Esto obligó a hacer crecer los equipos con una estrategia de M&A de empresas de ingeniería o producto e implicó el despido de personal de no tecnología (afectando a la reputación de la empresa).
- La implementación un producto complejo sobre un CMS (Joomla!) le permitió a la empresa crear un primer prototipo rápido (hasta aquí bien), pero cuando se notó la tracción del negocio no se inició una migración rápida y se fue tirando hacia adelante y eso les impidió la expansión internacional. Finalmente se tuvo que hacer una migración tecnológica de todo el producto en una arquitectura de microservicios retrasando 2 años la expansión internacional.
- Subcontratar la implementación de una app mobil a un proveedor por parte de una entidad bancaria sin una arquitectura tecnológica definida, generó retrasos en el despliegue de la app por saturación del proveedor, generó multitud de reviews negativas i imposibilitó a la entidad bancaria el uso de otros proveedores para dar soporte. Finalmente se diseñó una arquitectura de desarrollo multiproveedor y se implementó de nuevo la app.
Como vemos, un error en la selección de la arquitectura acabará impactando directamente al negocio ya sea por la escalabilidad, por los costes o por la satisfacción del cliente.
Establece el modelo organizativo es posiblemente el aspecto más global de la estrategia de ingeniería. En este punto hay que pensar cómo vamos a escalar nuestros equipos de desarrollo para maximizar la performance. Con la estrategia de personas o de equipos daremos respuesta a preguntas como ¿dónde se ubica el equipo? ¿Qué roles del equipo serán necesarios? ¿Qué especialistas necesitaremos? ¿Cuales serán las unidades organizativas? ¿Cómo mediremos la performance? ¿Cómo evitaremos los silos?
Con todo esto definiremos una estrategia de hiring y una estrategia de organización de equipos que nos permitirá montar un roadmap de expansión de equipos. Este roadmap deberá estar 100% alienado con la estrategia de inversión de la compañía y deberá ser flexible a posibles cambios en dicha estrategia. Esta flexibilidad se puede conseguir de diversas formas, en mi experiencia una buena manera de conseguir esta flexibilidad es empezar encontrando a perfiles más flexibles y con más experiencia primero e ir incorporando perfiles especialistas y más junior en fases posteriores. Otras estrategias flexibles pueden ser incorporar a personas en modelo de subcontrata, aunque esto no es demasiado eficaz cuando estas montando un producto y quieres quedarte con el know how en casa.
Cuando incorporemos una estrategia de internacionalización de los equipos, tendremos que pensar ¿dónde están ubicados los diferentes roles el equipo? para ello tendremos que tener en cuenta temas como ¿quién toma las decisiones técnicas? ¿dónde se define el producto? ¿cuánta autonomía le damos a los hubs? ¿quién valida las soluciones del hub y como? cuando tengamos respuesta a todos estos puntos tendremos que montar los procedimientos e implementar los mecanismos necesarios para poder resolver los pain points que puedan tener los diferentes interlocutores.
En mi carrera he conseguido montado hubs de tecnología para consultoras y para startups y sin duda cada caso ha sido diferente. Después de concluir mi experiencia creando un hub de desarrollo de software offshore para una consultora de Barcelona escribí algunas de las Lecciones aprendidas haciendo SCRUM en diferentes zonas horarias.
El modelo operativo hace referencia a la parte organizativa desde el nivel más micro (metodología organizativa de cada uno de los equipos) como a nivel más macro organización intra equipos (por squads, chapters y tribus). También incluye tanto a la parte más de conceptualización y desarrollo de producto (típicamente con SCRUM o Kanban) como a la parte más de operaciones (que típicamente se involucra con el desarrollo implementando una filosofía DevOps)
En el siguiente video se explica cómo las operaciones se incorporan al equipo gracias a un cambio organizativo llamado generado por la filosofía DevOps.
En los procesos que se definen en esta etapa también es importante establecer cuál es el modelo de control de calidad y de flujo de datos que tendremos.
La estrategia de ingeniería de software define la estrategia e implementa los procedimientos para que el desarrollo de productos digitales pueda alinearse a los objetivos de la organización superando las resistencias del mercado.