Los nuevos features, productos y desarrollos, podían venir de dos lugares: negocio/producto o internamente desde el equipo de tecnología.
Como es de esperar, la gran mayoría de estos venian como iniciativas de negocio, a fin de cuentas, sin negocio, no hay empresa. Sin embargo, siempre estuvo la puerta abierta para el equipo de tecnología, para cualquier iniciativa que pudiera beneficiar el negocio, o facilitar nuestro trabajo, y esto incluye deuda técnica.
Regresando al hecho que el desarrollo de software es un proceso complejo y caótico, definir y planear nuevas funcionalidades tampoco es un ejercicio trivial, y entre más grande sea tu equipo y más especialidades tenga, más difícil será coordinarlos a todos hacia un mismo entendimiento de lo que se quiere lograr. Si llevas suficiente tiempo en esto, seguro has te has enfrentado con que el backend hizo una cosa, el frontend otra, al final nada funciona junto, toca pegarlo con “babas”, sigues incrementado tu deuda técnica, el tiempo de entrega se alarga cada vez más, y en el peor de los casos, lo que se termina entregando, no cumple con el objetivo inicial.
Con el fin de solventar estos problemas, definimos el siguiente proceso:
Esto se trata de hacer el “que”, más claro a todo los involucrados.
Quienes normalmente ejecutaban este proceso eran los product owners, apoyados por el equipo de diseño para la visualización de sus ideas, y el equipo de tecnología, normalmente los líderes técnicos, para consultas previas sobre funcionamiento actual o viabilidad de las cosas.
De este proceso normalmente salían los dos entregables:
Con los wireframes y memo en mano, el equipo de producto y diseño, presentan a el equipo que estará involucrado en el desarrollo del feature, y cualquier otra persona que pudiera estar interesada, el “que” y “porque” de la nueva funcionalidad.
El primer objetivo de esta intro, era que todos los involucrados entendieran que se espera lograr, cuáles eran las expectativas de tiempo, y alcance del desarrollo.
El segundo, era recibir feedback del equipo que construirá el feature, no solo a nivel de viabilidad, tamaño según nuestra experiencia (XS, S, M, L, XL), y que tan realistas pueden ser las expectativas de tiempo, sino también, a nivel de la solución que se le esta dando al problema que se busca solucionar.
Dependiendo de las discusiones que se daban en esta etapa, usualmente aterrizamos el alcance a los más MVP posible, el equipo técnico se empezaba a dar una idea del “cómo” podíamos hacer esto, e incluso, en ocasiones, nos dabamos cuenta que la solución al problema tan “simple” como ajustar algún proceso de negocio, servicio al cliente, o ajustes pequeños a algún producto o feature existente.
Este tipo de documentos, fue algo que empecé a refinar durante mis tiempos en Grability, y que en Blackboard, es parte del proceso para cualquier desarrollo, de hecho, fue de esta empresa donde me obtuve el nombre.
Este es un documento principalmente técnico donde, una vez es claro lo que queremos lograr, especificamos, sin entrar en detalles de implementación, el cómo vamos a construir la funcionalidad esperada.
Este documento incluye cosas como, cuales serían los cambios a la estructura en las base de datos, firmas de los API a construir, flujo de comunicación y puntos de interacción entre el backend y el frontend, si vamos a construir nuevos micro servicios, que NO vamos a construir, etc…
El definir el “cómo”, antes de escribir la primera línea de código, facilitaba el entendimiento de todo el equipo sobre el alcance de lo que se iba construir, y dejaba claro los acuerdo que las diferentes especialidades deben cumplir para llegar al fin, sin mayores contratiempos.