Qué aprendimos desarrollando un producto para una empresa real

Cada proyecto de desarrollo de software deja lecciones. Algunas son técnicas —un framework que funcionó mejor de lo esperado, una decisión de arquitectura que hubo que revertir—. Pero las que más pesan a largo plazo no tienen que ver con la tecnología. Tienen que ver con lo que ocurre en la intersección entre lo que la empresa necesita, lo que el equipo entiende que necesita, y lo que efectivamente se construye.

Este artículo comparte lo que aprendimos en un proyecto de desarrollo de un producto digital para una empresa que ya operaba, con procesos establecidos, clientes reales y restricciones de tiempo y presupuesto que no eran negociables. No es un caso de estudio con nombres: es una reflexión sobre patrones que se repiten en proyectos similares, independientemente de la industria o la tecnología.

Lección 1: El alcance inicial es una hipótesis, no un contrato

El proyecto arrancó con un documento de alcance que todos los involucrados revisaron y aprobaron. Tenía funcionalidades priorizadas, criterios de aceptación, estimaciones de esfuerzo. Parecía sólido. Cuatro semanas después, aproximadamente un treinta por ciento de ese alcance había cambiado: funcionalidades que parecían imprescindibles resultaron ser secundarias cuando los primeros usuarios reales interactuaron con el sistema; necesidades que no estaban en el documento original aparecieron como bloqueantes apenas el producto empezó a usarse en el contexto real de la operación.

Esto no fue un error de planificación. Fue una consecuencia inevitable de desarrollar software para un entorno que ya existe. A diferencia de un producto nuevo que se lanza a un mercado que todavía no tiene expectativas formadas, el software para una empresa en operación debe convivir con procesos que ya están funcionando, personas que ya tienen su forma de trabajar, y sistemas que ya están en uso. El documento de alcance describe lo que creemos que va a pasar. La realidad, invariablemente, lo corrige.

Lo que aprendimos no fue a hacer mejores documentos de alcance. Fue a tratarlos como hipótesis que se validan en iteraciones cortas, y a construir el producto de manera que cambiar de dirección no implique tirar todo y empezar de nuevo. Esto requiere una arquitectura que permita modificaciones sin colapsar, y requiere sobre todo un acuerdo explícito con la empresa: el alcance va a cambiar, y eso no es un problema si el cambio se gestiona con criterio y transparencia.

El artículo sobre cómo organizar la comunicación con un equipo de desarrollo profundiza en las prácticas que hacen que esos cambios de alcance no descarrilen el proyecto ni la relación entre las partes.

Lección 2: La persona que hace de puente vale más que cualquier herramienta

En este proyecto, había una persona del lado de la empresa que entendía el negocio con profundidad —sabía cómo funcionaba cada proceso, por qué se hacía de esa manera, qué dolores generaba— y que además tenía la capacidad de traducir ese conocimiento a un lenguaje que el equipo técnico podía entender. No era programadora, pero sabía explicar qué datos entraban, qué transformación debía ocurrir y qué resultado se esperaba, sin perderse en detalles de implementación.

Esa persona fue, sin exagerar, la diferencia entre un proyecto que avanzaba y uno que se habría estancado en reuniones interminables. Cuando el equipo técnico tenía dudas sobre cómo debía comportarse una funcionalidad en un escenario específico, no necesitaba esperar a una reunión formal con tres gerentes: le preguntaba a esta persona, que entendía el contexto y podía decidir en minutos.

La lección no es que toda empresa necesita contratar a alguien con ese perfil —aunque ayuda—. Es que el proyecto necesita al menos una persona del lado de la empresa que tenga la autoridad para tomar decisiones operativas y el conocimiento para tomarlas con criterio. Sin ese rol, cada duda se escala, cada definición demora, y el proyecto avanza a la velocidad de la agenda de los tomadores de decisión, no a la velocidad del equipo técnico. Las preguntas que hay que responder antes de construir cualquier software son un buen punto de partida para que esa persona —o quien haga ese rol— tenga claro qué necesita definir antes de que el equipo empiece a trabajar.

Lección 3: El contexto operativo es más complejo que cualquier requerimiento

Uno de los momentos más reveladores del proyecto ocurrió cuando una funcionalidad que funcionaba perfectamente en el entorno de pruebas falló apenas se expuso a los datos reales de la empresa. El problema no era un bug: era que los datos reales tenían inconsistencias que nadie había documentado. Clientes con dos identificadores distintos según el sistema de origen. Productos que en un sistema se llamaban de una manera y en otro de otra. Registros históricos con formatos de fecha que variaban según el año en que se habían creado.

Ninguno de estos problemas aparecía en los requerimientos porque, para la empresa, eran parte del paisaje: estaban tan acostumbrados a convivir con esas inconsistencias que no las veían como un problema hasta que el software nuevo las hizo evidentes.

La lección fue que el relevamiento de requerimientos tradicional —sentarse a preguntar qué necesita el sistema— es insuficiente. Hay que complementarlo con una inmersión en los datos reales y en los procesos reales lo antes posible en el proyecto. No para documentar cada inconsistencia —sería interminable—, sino para dimensionar cuánta limpieza y normalización de datos va a hacer falta antes de que el software nuevo pueda operar con información confiable.

Lección 4: El valor se mide en uso, no en funcionalidades entregadas

Durante las primeras semanas posteriores a la puesta en producción, el equipo hizo algo que no siempre se hace: observar cómo los usuarios reales usaban el producto. No preguntarles si les gustaba —las respuestas a esa pregunta suelen ser corteses y poco informativas—, sino mirar qué hacían.

Lo que vimos fue que varias funcionalidades que habían costado semanas de desarrollo se usaban poco o nada. No porque estuvieran mal hechas, sino porque resolvían problemas que los usuarios no tenían —o que resolvían de otra manera que les resultaba más natural—. En cambio, funcionalidades menores que se habían construido en horas —un filtro, un atajo de teclado, una vista resumida— se usaban intensivamente y generaban comentarios positivos espontáneos.

La lección es incómoda pero útil: el equipo de desarrollo —incluyéndonos— tiende a valorar las funcionalidades por la complejidad técnica que requirieron, no por el valor que generan. El usuario valora exactamente lo contrario: funcionalidades simples que le ahorran pasos o le dan información que antes no tenía. Cerrar esa brecha requiere medir el uso real y estar dispuesto a aceptar que algunas de las cosas que más costaron construir son las que menos valor generan.

Lección 5: La documentación que importa es la que usa el que viene después

El proyecto generó documentación técnica, como cualquier desarrollo. Pero la documentación que resultó más valiosa no fue la descripción de la arquitectura ni el diagrama de componentes: fue un documento de una página que explicaba, en lenguaje no técnico, qué hacía el sistema, cómo se relacionaba con los otros sistemas de la empresa, y qué había que verificar si algo fallaba.

Ese documento no lo pidió nadie. Lo escribió una persona del equipo que había estado en situaciones donde retomar un proyecto desarrollado por otro equipo era un infierno porque no existía una explicación de cómo funcionaba nada. La lección es que la documentación más valiosa no es la que describe cómo se construyó el sistema —eso está en el código— sino la que permite que alguien que no participó del desarrollo entienda qué hace el sistema y cómo mantenerlo.

Desarrollar software para una empresa real enseña más en seis meses que años de teoría. Pero las lecciones no son transferibles automáticamente: cada empresa, cada equipo, cada contexto tiene sus particularidades. Lo que sí es transferible es la actitud de tratar cada proyecto como una oportunidad para aprender, documentar lo aprendido, y aplicar esas lecciones en el siguiente. Porque el siguiente proyecto siempre llega, y llegar con las lecciones del anterior ya incorporadas es lo que separa a los equipos que mejoran de los que repiten los mismos errores.