En el entorno industrial existe la clásica pelea entre el área de ventas y el área de producción: “No están cumpliendo con el plazo que le hemos ofrecido al cliente” “Los de ventas ponen plazos y metas imposibles”, dilema que casi sin variantes se traslada al desarrollo de software, y muchas veces creemos que es un callejón sin salida, pero escarbar un poco lo que paso podría ayudarnos a reducir esta clase de situaciones.
Parte del problema viene de la teoría de “si a los programadores les damos la especificación bien detallada, las cosas saldrá en tiempo y reduciremos problemas” , pero claro, por mas que se  detalle, al momento de construir pasan cosas y vemos que esta idea no es tan simple como parece, y si le añades conceptos como “pool de programadores”… desastre garantizado, en ese sentido es conveniente citar a lo que afirma Rodrigo Corral:

Habitualmente, la réplica suele ser del estilo: "eh!!! Pero si el desarrollador solo tiene que ‘poner ladrillos’ nuestros analistas se lo darán mascado’. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados’. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que ‘poner ladrillos’. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Pude comprobar en carne propia cuando tuve mi primera responsabilidad de gestión técnica, el equipo de análisis nos había dejado especificaciones bien detalladas sobre la funcionalidad de las pantallas a desarrollar, y así emprendimos el camino con mi equipo de programadores, el problema llego cuando nos topamos con dos pantallas en que no nos poníamos de acuerdo sobre como implementar el flujo de acciones de usuario, así que las conversaciones fueron a mas con la analista, resultando que al final llego una contraorden, las 2 pantallas se cancelaban (teniendo que tirar todo el trabajo avanzado) y se reemplazaban por una completamente nueva, mas aun siendo que había dudas sobre lo escrito en la (nueva y detallada) especificación hubo que dedicarle tiempo de conversación de lado a lado con la analista. Así que en este caso bien podríamos haber intentado ajustarnos a la especificación y entregar “algo” que evidentemente luego seria rehecho, pero no, nos correspondía avisar que esa especificación no era consistente y alertar a tiempo (es mas, visto en retrospectiva debimos avisar días antes).

La misma sensación la tuve hace unos meses cuando en una sesión de planeamiento, la Analista/Product Owner propuso un cambio de funcionalidad que entre otras cosas involucraba hacer severos ajustes a la integridad referencial de algunas tablas, el equipo estaba dispuesto a acometer la tarea, pero preferí indicar que los cambios tenían potenciales consecuencias que debían determinarse por anticipado, por lo que cancele la sesión de planeamiento y nos derivamos a una sesión de brainstorming para ir cubriendo las posibles implicancias, para de esta manera ofrecer dos alternativas, con sus pros y sus contras. Para la siguiente semana con ese documento y el apoyo de otro analista técnico la PO pudo decidir totalmente informada y asimismo ser consciente de que el tiempo no era tan corto como ella suponía.

Es que de eso se trata, si como desarrolladores percibimos que la especificación no esta clara o tiene implicancias no previstas, no debemos callarnos, debemos avisar antes de que sea tarde, y por lo mismo reconocer que esa comunicación e interacción de ida y vuelta se va a dar, y no esperar que todo se haga siguiendo ciegamente la especificación.

¿Y tu? ¿Alertas de los riesgos de una especificación a tiempo?