archivo

Archivos diarios: diciembre 18, 2011

“Estamos perdiendo una gran cantidad de dinero con el proyecto, dado que comentas que no es posible pagarnos más, te proponemos reducir algunas funcionalidades, como por ejemplo la gestión de determinadas tablas maestras. Si te parece te documentamos cómo se puede realizar el mantenimiento de las mismas a partir de un software que te permita acceder al modelo de datos. Otra punto a tratar son los listados, entendemos que con hacer un par de ellos basta, el resto se pueden obtener mediante consultas a base de datos, si te parece te indicaremos sobre qué tablas o vistas puedes extraer esos datos.”.

Nunca aceptes esto, nunca. Al final te tocará a ti hacerlo y ese no es tu trabajo. Tu trabajo no es gestionar tablas maestras en aplicaciones, hacerles listados al usuario (por lo menos no aquellos que son de ejecución cotidiana por los mismos e incluso otros más complejos, salvo que tu jefe te lo indique) o suplir mediante acciones externas al sistema, comportamientos y funcionalidades que se deberían haber implementado en el mismo.

Eso es la desfactorización, eliminar del producto final funcionalidad necesaria proporcionándote medios alternativos al propio sistema para poder realizarse. Aplicando este antipatrón, la dependencia de los usuarios respecto al área informática crece, lo que ocasiona un esfuerzo innecesario que se podía haber evitado implementando esas funcionalidades, de manera que todo lo que se ahorra el proveedor, te toca pagarlo a ti.

Presenta el mismo objetivo que el antipatrón ancla de barco, simplificar el sistema de manera que a nivel funcional, a nivel de código o a nivel documental, nos quedemos exclusivamente en cada momento con lo que representa al sistema.

Este antipatrón está orientado básicamente a esos trozos de software que dejan de tener utilidad y que no terminamos de eliminar (métodos o clases que no se utilizan, dependencias con librerías que ya no se usan, trozos de código comentados, objetos de bases de datos que ya no sirven, etc…).

Las ventajas las tendremos en una reducción de la deuda técnica, código más limpio e inteligible, reducción de efectos colaterales, etc…

Conforme va evolucionando un sistema de información, existen determinadas funcionalidades que dejan de tener utilidad y no se utilizan. Lo más normal es que estos módulos se sigan transportando entre una evolución y otra del sistema de información, como además, no paran de crecer las funcionalidades nuevas, que se retocan y que terminan quedando obsoleta tenemos cada vez una mayor carga en la espalda.

Se considera este comportamiento como un antipatrón, ya que además va en contra del principio de conseguir la mayor simplicidad posible en el software. Es como comprar muebles nuevos en casa y no tirar los antiguos.

Eliminando esos módulos liberarás deuda técnica, evitarás posibles incidencias debida a los mismos, no ya por su uso, sino por su posible relación con otros módulos, además de tener que continuar cargando con ellos a nivel de gestión de la configuración.

En tu trabajo dentro de un proveedor de servicios de desarrollo de software o como parte del departamento de informática de una organización, te tienes que relacionar con multitud de personas de diferentes responsabilidades y en lo posible, resulta recomendable mantener una buena relación profesional.

Si por tu carácter o por no saber controlar determinados momentos de stress empiezas a tratar mal a las personas, no debes esperar a que éstas te traten a ti de forma distinta. Si tratas a las personas de manera caprichosa, ellas también lo harán contigo.

Nuestro trabajo no es una carrera en solitario, necesitamos la ayuda de muchos, así como muchos requieren nuestra ayuda, por lo que es conveniente intentar tener un equilibrio en las relaciones.

El problema lo encontramos cuando se entiende de manera incorrecta ese equilibrio, de manera que se interpreta que para conseguir que los demás te den un trato preferente o simplemente para no tener problemas, requiere que seas un Mr. Nice Guy o un amigo de todos.

En los años que llevo en este negocio puedo decir que sí es posible tener un equilibrio profesional y que ese otro equilibrio ficticio basado en el todos somos felices, solo es posible si haces dejación de responsabilidades y no exiges cuando tienes que hacerlo.

Es decir, habrá veces donde tengas que tomar decisiones, donde tengas que apretar a terceros y eso no sienta bien a todo el mundo. Lo importante es que cuando hayas actuado de esa manera sea debido a circunstancias objetivas (aunque sean erróneas) y con un trato profesional. De esta forma, la mayor parte de las marejadas terminarán siendo comprendidas y las que no, no serán tu problema, sino el de la otra persona.

En muchas ocasiones me he encontrado con propuestas metodológicas que, teniendo la oportunidad de conocer el funcionamiento y características de nuestra organización, no se han molestado en adaptar, con la falsa creencia de que determinadas soluciones funcionan en todos sitios.

Ese es el antipatrón del martillo de oro, el intento de aplicar soluciones a problemas concretos creyendo que en todos los casos se van a obtener resultados positivos.

Lo peor de todo eso es que están tan convencidos de que va a funcionar que no presentan el más mínimo margen a su adaptación.

No se trata de querer reinventar algo que funciona (que por otra parte y en muchos casos, estaría por ver), sino de adaptarlo a la cultura de la organización y/o características concretas del problema con el que se va a trabajar.

Otra cosa bien diferente sería realizar una propuesta, indicar las referencias donde ha tenido éxito (a ser posible con datos de contacto de personas a las que se les pueda preguntar) y especificar qué aspectos de la misma sería necesario estudiar con el cliente para terminar de darle forma (explicando también cómo se va a realizar esa tarea, qué recursos necesitaría, qué tiempo requiere, etc…).

Básicamente este antipatrón lo traté en el artículo: “El amiguismo como enemigo de la productividad.

Este antipatrón se produce cuando el único filtro (o, al menos, el más importante) que se aplica a la hora de reconocer méritos en el trabajo es la relación personal que existe con una persona o con una serie de personas.

Y lo es, tanto para dar méritos que no corresponden con la realidad, para darlos en mayor grado de lo que realmente eran merecidos o para obviar trabajos mal hechos.

La incidencia de todo esto en la productividad y en la convivencia de la organización, de obvia, casi no merece ser analizada.

Tener dobles varas de medir, perder la objetividad, crear clases sociales en la organización (mis amigos y los demás) no trae nada bueno.