archivo

Archivos diarios: diciembre 31, 2011

Este antipatrón se puede relacionar con todos aquellos en los que se trata la introducción de complejidad innecesaria en el desarrollo o en el producto final (por ejemplo “funcionalitis acechante” o “complejidad no indispensable“) y con aquellos donde una solución base que resuelve en determinados casos problemáticas concretas o que son aptas para proyectos concretos, se entienden que valen para cualquier problemática o concepto que se encuentra dentro de ese dominio de actuación (obviando otros factores) e incluso se extienden fuera de ese ámbito (por ejemplo, los antipatrones “todo lo que tienes es un martillo” o “bala de plata“).

En este caso la complejidad adicional al sistema se incluye al intentar hacer una analogía del mismo con otro que tiene alguna o algunas características comunes (ámbito de negocio parecido, funcionalidades semejantes, mismo tipo de cliente, mismo cliente, idéntico entorno tecnológico, etc…), es decir, se toma como base otro y en lugar de profundizar en las expectativas reales del usuario o en la complejidad del problema o del proyecto que tenemos ante nosotros, se pone la atención en intentar adaptar esa idea o esa solución.

Esto, además de poder estar alejado a lo que los usuarios quieren realmente, pueden incorporar una mayor complejidad al proceso de desarrollo y/o al propio sistema de información, haciendo necesario un mayor esfuerzo, dificultando su posterior mantenimiento y empeorando la experiencia del usuario (cuando no el cumplimiento de sus expectativas).

Hay que entender que una organización quiera normalizar los desarrollos que se realizan para la misma, con el objeto de tener un control sobre las tecnologías y soluciones utilizadas en los trabajos y de esta forma reducir el riesgo de cautividad del proveedor (aunque en muchos casos, este riesgo viene dado por su conocimiento funcional) y disminuir los costes de mantenimiento.

De hecho, considero una buena práctica que una organización tienda a eso porque de lo contrario lo que se tiene es un caos tecnológico muy complicado y caro de gestionar.

Ahora bien, cualquier medida llevada al extremo no suele ser positiva. Puede que exista algún tipo de desarrollo que requiera (para ser mucho más óptimo) que la arquitectura, tecnología, metodología de desarrollo o procedimientos de testing, sean distintos a los establecidos.

La aceptación de esa alternativa no debe quedar a expensas de un capricho o de una decisión de carácter individual sino que debe ser expuesta dentro de las posibles alternativas de solución al conjunto de personas que dirijan el desarrollo y mantenimiento de sistemas de información dentro de la organización.

La cultura del miedo es una mala estrategia, por un lado afecta a la iniciativa de los empleados que buscarán siempre que sea posible la aprobación de un superior antes de realizar una acción o de entregar un trabajo (incluso por encima de los que marquen los procesos establecidos en la organización, si es que existen).

También afectará a su productividad porque saltarán siempre más dudas de las necesarias antes de ejecutar cualquier acción.

La creatividad también se verá afectada ya que existirá temor por salirse de la línea establecida.

Y yo destacaría, sobre todo, que va a afectar a la propia comunicación dentro de la organización y la credibilidad de los datos que se manejan. En un cultura del miedo, donde por cada acción que se entienda incorrecta puede dar lugar a consecuencias severas, quien quiera conservar su posición o su puesto de trabajo, tenderá a maquillar resultados y a ocultar información, haciendo todavía más daño tanto a él como a su propia organización (ver, por ejemplo, el antipatrón “migración de coste“).

Es lógico que si alguien comete errores y los mismos tienen impacto, que estos tengan consecuencias, pero tras un análisis objetivo de qué es lo que ha pasado, conociéndose previamente qué tipo de actuaciones pueden dar lugar a acciones por parte de la organización (que no necesariamente pasan por el despido o por tocarte el variable).

Por tanto, el personal de la organización debe saber que si actúa de manera positiva tendrá recompensas y si actúa de manera negativa (sobre todo negligente), todo lo contrario y también ser consciente de que no se está trabajando en un entorno donde cualquier error, sea del tipo que sea, provocará una reacción en su contra que además será desproporcionada en la mayoría de los casos.

Tan negativo como la cultura del miedo es la cultura de la tranquilidad o la cultura del nunca pasa nada, es decir, pase lo que pase o haga lo que se haga prácticamente nunca tendrá consecuencias ya sea al conjunto de empleados de la organización o a un grupo de empleados concretos de la misma (ver, por ejemplo, el antipatrón “el niñito de oro“).

Hace más de un año que publiqué la lista de los 25 artículos que hasta entonces habían sido los más visitados en mi blog. Hoy os lo actualizo y os pongo los enlaces de acceso, por si hay alguno que no hayáis leído y os interesa hacerlo.

1.-Ahora más que nunca hay que mirar al software libre.
2.-Desarrollo de software. Ciclo de vida RUP (Rational Unified Process)
3.-Orientación al producto
4.-Mantenimiento adaptativo
5.-La importancia de un buen análisis funcional
6.-Desarrollo de software. El analista funcional y el analista orgánico
7.-Mantenimiento correctivo y mantenimiento evolutivo
8.-LCOM4 y la falta de cohesión en las clases
9.-Empresas de desarrollo de software: ¿estructura vertical u horizontal?
10.-La crisis del software
11.-Desarrollo de software. Programación extrema (eXtreme Programming: XP)
12.-Complejidad ciclomática
13.-Un proyecto de construcción de Datamart para la explotación de indicadores de gestión y de estado III
14.-Proyectos de desarrollo de software: La importancia de las métricas y de la documentación
15.-Desarrollo de software. Ciclo de vida iterativo incremental
16.-Certificaciones personales
17.-El paso a producción
18.-PMD: Security – Array is stored directly
19.-Un buen entorno de preproducción
20.-Un proyecto de construcción de Datamart para la explotación de indicadores de gestión y de estado II
21.-¿Cuál es el objetivo de tu empresa este año?
22.-Reducción de tiempos muertos
23.-El papel de los usuarios en un proyecto de desarrollo de software
24.- Lo importante de las Metodologías de desarrollo en un proyecto de desarrollo de software
25.-Desarrollo de software. Método de desarrollo de sistemas dinámicos (DSDM) III