Desarrollo de software. Antipatrón. Trampas evitables

Los desarrolladores somos auténticos expertos en meternos en charcos. Muchas veces nos empujan a ellos, en otras somos nosotros los que nos metemos hasta el fondo.

De eso trata este antipatrón, de nuestra tendencia a complicar proyectos sin necesidad, veamos algunos ejemplos:

– Con el objeto de superar las expectativas del usuario o sorprenderle, se deciden afrontar funcionalidades con prioridad muy baja que se consideran poco complejas, aprovechando los remanentes de tiempo en el desarrollo normal del proyecto.

En muchos casos, lo que parecía simple no lo es tanto y se terminan desechando (muchas veces de manera poco limpia, antipatrón “lava seca“), lo que ha supuesto un esfuerzo que no ha servido para nada, además de una pérdida de enfoque en los objetivos principales del proyecto

– Se aplican soluciones experimentales (prueba de una nueva tecnología, un nuevo framework, unos nuevos componentes) en lugar de aplicar soluciones conocidas.

– Sin entrar en un análisis riguroso del sistema o de determinadas funcionalidades, nos aventuramos a dar unos plazos muy exigentes (sin que nadie no los haya impuesto).

Desarrollo de software. La agilidad no es dar bandazos

Alguna que otra vez he escuchado decir que la aplicación de principios ágiles no es más que dar bandazos.

No es así, es adaptarse al cambio, que es algo absolutamente diferente.

Los bandazos los pueden dar los directores usuarios o las propias contingencias que afecten al proceso de desarrollo y que están por encima de éste: cambios normativos, cambios en los procesos, etc… y eso es inevitable sea cual sea la metodología que utilices y forma parte de la propia incertidumbre de este tipo de trabajos.

Lo que sí permite la agilidad es reaccionar más rápido ante estas situaciones ya sean más o menos bruscas.

La agilidad no es una generadora de milagros por lo que si el proyecto tiene bandazos significativos, el proyecto, los resultados y todos los participantes sufrirán por ellos pero las posibilidades de supervivencia serán mayores que en contextos menos flexibles.

Desarrollo de software. Antipatrón. Job Keeper

Una estrategia clásica para intentar hacerte imprescindible dentro de una organización es que ciertos detalles relevantes de tu trabajo o de tus proyectos los conozcas exclusivamente tu, de manera que si se les ocurriese en algún momento echarte esa información se iría contigo, lo mismo que si decides irte a otra empresa (en este caso el objetivo no es mantener tu puesto de trabajo sino ir consiguiendo cada vez, unas mejores condiciones laborales).

Por ese motivo, existe mucha reticencia en estas personas a documentar lo que hacen o a compartir con otros sus conocimientos.

Este antipatrón se produce cuando una organización siendo consciente de que esta problemática existe no toma medidas para evitar o por lo menos reducir esta cautividad o dependencia con determinados trabajadores.

Hay que tener en cuenta que el problema no es solo que determinadas tareas o proyectos queden desprotegidos, sino que la actitud de los Job Keeper resulta absolutamente negativa dentro de las actividades diarias dentro de una organización, porque esta persona no colaborará con otros compañeros cuando esto suponga compartir parte de la información o conocimientos que él considera valiosos y puede comprometer el funcionamiento de la misma cuando no estén presentes en su puesto de trabajo (vacaciones, visitas a clientes, etc…).

Desarrollo de software. Funcionalidades, solo las necesarias

No hace mucho, estuve conversando con un usuario que quería hacer modificaciones significativas en un sistema de información, algunas de ellas eran totalmente razonables y otras, las más complicadas, se trataban de situaciones que se podían dar, pero que tras analizar la situación se podían producir una o dos veces al año (si acaso) y que en el caso de que se produjeran su no tratamiento en el sistema de la manera más óptima, no tendría consecuencias significativas.

Después de analizar con el usuario, los pros y los contras (incremento de la complejidad del sistema, esfuerzo (dinero) necesario para llevarlo a cabo, etc…), dijo finalmente “es cierto que si estos casos se producen se van dar en contadas ocasiones y no merece la pena hacer los cambios en la aplicación”.

Por tanto, en este caso, lo más productivo fue tomar la decisión de no implementar funcionalidades que no eran absolutamente necesarias (y no caer en antipatrones como por ejemplo “funcionalitis acechante“) y dedicar la atención y esfuerzo a aquellas que sí eran importantes.

Existe mucho respeto en entrar a valorar con los usuarios sus propias peticiones, pero es algo que es necesario y que el mismo usuario o cliente agradecerá en la mayoría de los casos (le ahorrarás dinero y tendrá un producto de mayor calidad). Es cierto que muchas veces no te harán caso, incluso en otras les podrá sentar mal, pero poniendo en una balanza beneficios y riesgos, merece mucho la pena intentarlo.

Desarrollo de software. Antipatrón. Fuego amigo

Otro error muy típico consiste en criticar ante el cliente o ante la competencia el trabajo o la actitud de otros compañeros de tu organización o el resultado de determinados proyectos de tu empresa.

Es cierto que todos podemos tener momentos de debilidad en los que de alguna u otra forma necesitamos desahogarnos, pero hay que tener mucho cuidado con quién se hace y qué es lo que se dice, porque puede ser que más adelante nos tengamos que arrepentir.