El Extraño caso del Líder Jekyll y Mr. Hyde

Esta es la historia de un líder de proyecto llamado Jekyll, el cual alegremente —al menos al comienzo—  lideraba un nuevo proyecto de desarrollo de software como tantos otros que existen, han existido y existirán.

Nuestro líder Jekyll era un caso típico de trayectoria profesional en nuestra industria. Después de estudiar una carrera afín al mundo de sistemas, inició como programador becario en alguna tecnología de moda para luego desempeñar durante algunos años diferentes roles de ingeniería de software en diferentes proyectos —a veces varios de manera simultánea—. En el transcurso tomó uno que otro curso, normalmente relacionado con lenguajes de programación o herramientas de desarrollo. Finalmente, en aras de su probada capacidad técnica y organización personal, su jefe tomó la decisión de convertirlo en "líder de proyecto" (entendiendo como tal lo que el rol significara para el jefe), y para "foguearlo" lo asignó a dirigir un nuevo proyecto.

Acostumbrado a afrontar nuevos retos con optimismo, Jekyll aceptó su nuevo rol poniéndose al frente del equipo de trabajo que le fue asignado, el cual estaba compuesto principalmente por recursos de poca experiencia junto con un par de "lobos de mar". El proyecto, según le explicó su jefe, había sido ganado "con mucho esfuerzo", para lo cual había sido necesario realizar ajustes en las tarifas y recortes en los tiempos. Al preguntar quién había calculado los tiempos, recibió como respuesta que “el equipo de ventas” (sin más detalles de quiénes o cómo). Sin embargo, para tranquilizarlo su jefe añadió que tenía la ventaja de que el levantamiento de requerimientos ya estaba hecho (lo había hecho otra consultoría), y que la arquitectura base ya estaba definida (la había definido el cliente), por lo que “únicamente” le iba a tocar dirigir el desarrollo.

De manera previsora, nuestro Jekyll solicitó a sus "lobos de mar" asignados que le echaran un vistazo a la arquitectura base. Para su sorpresa, los lobos le manifestaron que, a pesar de contar con varios años de experiencia y un largo recorrido en desarrollo de sistemas, desconocían por completo las tecnologías que la componían. Dado que el resto del equipo estaba compuesto por programadores novatos, lo más que pudo obtener fue un par de "leí algo, alguna vez, en un sitio de Internet...". Por tanto, Jekyll acudió con su jefe para solicitar que se le asignara algún recurso con experiencia en la tecnología, a lo que recibió una negativa con el argumento de falta de personal y comentarios respecto a problemas con las tarifas. Sin embargo, el jefe recordó que Jekyll había participado como desarrollador en algo parecido en el pasado, por lo que aseveró que seguramente no tendría ningún problema para implementar el proyecto. Un poco intranquilo, Jekyll hizo "de tripas corazón" y en aras del cumplimiento del proyecto aceptó la responsabilidad técnica del mismo (es decir, desempeñar también el rol de arquitecto).

Requerimientos difusos

Continuando con el proyecto, Jekyll solicitó una vez más el apoyo de los lobos de mar para dimensionar el alcance a partir del análisis de los documentos de requerimientos. Consternados, detectaron varios problemas:

A pesar de que la consultora que realizó el levantamiento de requerimientos se anunciaba como “experta en análisis de negocio”, no existía ningún documento de un análisis del negocio como tal. Los únicos documentos disponibles eran especificaciones de casos de uso. El estilo de redacción de los casos de uso variaba desde vagas descripciones hasta verdadero pseudocódigo, y en ocasiones se apreciaba que eran un mero “copy-paste”.

Muchos de los términos y procedimientos del negocio eran completamente desconocidos para el equipo de trabajo, y no existía documentación disponible al respecto.

Se hacía mención a la necesidad del cumplimiento de legislaciones y estándares, pero no había ninguna información que los explicara.

Los casos de uso no tenían ningún tipo de agrupación o secuencia, ni venía documentada su alineación con los flujos de operación del negocio.

Se indicaban decenas de validaciones y cálculos, pero en ningún lugar se describían. Las reglas de negocio no estaban documentadas en ningún otro lado.

Las relaciones entre casos de uso eran inconsistentes o incorrectas, y los actores participantes no eran homogéneos ni se describían en ninguna parte de la documentación. De hecho, tampoco casaban con roles de los empleados de la empresa.

Procesos batch y reportes venían especificados usando los mismos formatos usados para documentar casos de uso. Sin embargo, los “layouts” de los reportes no estaban indicados.

Los requerimientos no funcionales no eran explícitos, además en ocasiones chocaban con notas y comentarios desperdigados en los casos de uso.

Ante lo anterior, Jekyll solicitó el apoyo de su jefe, el cual para tranquilizarlo procedió a negociar con el cliente un periodo "extraordinario" para aclaración de dudas del equipo (no quedando claro quién absorbería el impacto en costo y calendario). Como había que designar un responsable del lado del equipo, una vez más Jekyll aceptó la responsabilidad y se constituyó en el "líder de análisis" del proyecto.

Arquitectura incongruente

Recordando Jekyll que tenía también el rol de arquitecto, para aprovechar el tiempo procedió a revisar más a fondo la arquitectura base establecida por el cliente. Resultó ser un documento largo y pomposo el cual:

A todas luces se veía que había sido generado haciendo una mezcla de documentación proveniente de otros sistemas. Incluso el nombre de los mismos aparecía en varios lugares donde se les había pasado reemplazarlos por el nombre del sistema actual.

Incluía una combinación de tecnologías sin justificar la razón de su elección.

Sin ton ni son mezclaba vistas, modelos y conceptos de diferentes metodologías y marcos de descripción de arquitecturas.

Sus diagramas adolecían del “síndrome del rompecabezas abstracto”, es decir diagramas que encajan bien y se ven bonitos pero no es claro lo que representan las piezas. Esto ocurría porque los autores no acompañaron a los diagramas con descripciones de cada una de las partes que los componían, asumiendo que las etiquetas de nombres transmitían perfectamente el objetivo y características de cada parte.

Hacía referencia a funcionalidad no incluida en las especificaciones.

En ningún lugar se explicaba como la “arquitectura base” abordaba el cumplimiento de los requerimientos no funcionales.

Al preguntar Jekyll al cliente si esa arquitectura base ya se estaba utilizando en algún sistema que estuviera en operación de la empresa, recibió la respuesta de que "no, pero hay uno que casi la utiliza". Después de realizar diversas gestiones en diferentes frentes, Jekyll consiguió que se le mandara una versión "triple I" (incompilable, incompleta e ininteligible) de la arquitectura base. Al preguntar si era posible realizarle cambios, le contestaron que no porque la había definido el comité de arquitectura de la empresa (cuyos miembros no tenían participación ni responsabilidad alguna en el proyecto, ni tampoco era posible consultarles), y porque su uso estaba establecido por contrato.

Bajo involucramiento del cliente

Ante esto, Jekyll (que a estas alturas del partido aún no había leído el contrato de servicio), solicitó a su jefe una copia del mismo y procedió a leerla con detenimiento. Al hacerlo, entre otras cosas encontró que venían cláusulas leoninas de penalización por incumplimiento por parte del equipo de desarrollo, pero no se había incluido ninguna que tocara al cliente por incumplimiento de acuerdos o por períodos de espera atribuibles al cliente. Una vez más Jekyll acudió con su jefe para exponer estos puntos. Resultó que de muchos de ellos el jefe no estaba enterado, pero intentó tranquilizarlo con la indicación de que no se preocupara, porque contaba con todo el apoyo de la empresa y porque el cliente estaba comprometido.

Francamente alarmado, Jekyll comenzó a acudir a las sesiones de "aclaración de dudas", en donde los participantes del lado del cliente con frecuencia no acudían, llegaban tarde o se iban antes (porque no podían descuidar sus actividades normales), no sabían de qué se les estaba hablando (porque la consultora anterior jamás les había presentado los casos de uso), disentían de su contenido (porque la operación “no era” como la indicaban los casos de uso), planteaban sobre la marcha cambios y "mejoras" (discutiendo arduamente entre ellos por cuestiones triviales sin llegar a ningún acuerdo), o con una sonrisa comentaban que lo contenido en los casos de uso "ya no aplicaba" (porque en el inter habían ocurrido cambios en el negocio, en un sistema externo o en alguna legislación). Al acudir por enésima vez con el jefe a plantear los problemas, recibió una palmadita en la espalda y una vez más la recomendación de que no se preocupara, porque el proyecto "iba a salir".

¿Y todavía se preguntan de dónde sale el Mr. Hyde de esta historia?

Conclusión

Para los lobos marinos que todavía se hacen a la mar, sirva el presente cuento para provocarles sonrisas al reconocer escollos y monstruos marinos atemorizantes. Para aquellos que ya no se hacen a la mar y que viven en los puertos despachando navíos, sirva para revivirles sensaciones casi olvidadas de sus épocas marineras y crearles conciencia no sólo de la crueldad de designar a marinos jóvenes como capitanes para mandarlos inmediatamente a navegar en aguas tormentosas, sino de la más que probable posibilidad de que al hacerlo se vayan a pique los barcos que comandan.