archivo

Archivos Mensuales: enero 2013

Comenta Stephen Hawking que: “La inteligencia es la habilidad de adaptarse a los cambios”. Y es así, si no lo haces, estás abocado a no evolucionar, a esperar sentado a que otros (personas y circunstancias) decidan tu suerte.

Adaptarse al cambio requiere tener mentalidad abierta, no estar atado a prejuicios y contemplar más posibilidades que las que nos pueden parecer, a priori, más válidas.

En los proyectos de desarrollo de software trabajamos en un entorno de incertidumbre, en el que las condiciones cambian, en donde se pasan de situaciones supuestamente bajo control a otras que se nos escapan de las manos, en donde las que eran las mejores decisiones la semana pasada requieren ser revisadas.

Adaptarse al cambio no es improvisación sino entender la propia naturaleza del desarrollo de software. Ahora bien, la línea que la separa ambos conceptos es muy delgada, de ahí que sea una habilidad la adaptación al cambio, primero por la detección de la necesidad (y la inteligencia y el valor para darnos cuenta de que tenemos que actuar en consecuencia) y en segundo lugar porque todo se debe tratar de hacer con intención, no vale cualquier respuesta, la que tomemos, pese a estar equivocada, no debe basarse en un prueba y error, salvo que no seamos capaces de detectar que una de las opciones sea la mejor.

Este antipatrón surge cuando en una organización existen departamentos o grupos de trabajo que funcionan sin tener en cuenta la existencia de otros, provocando que no se puedan aprovechar sinergias, trabajos o estrategias y no solo eso, ya que cuando funcionan de esa forma pierden la visión de organización y de conjunto, entendiendo que sus fines son los únicos que existen, lo que puede afectar negativamente a los demás.

Es posible que el funcionamiento de esos departamentos sea óptimo en términos de colaboración y comunicación interna y que incluso tengan una relación fluida, correcta y eficiente con la dirección, pero al entender que sus objetivos son los más legítimos, prioritarios y valiosos no consideran necesario la colaboración con otros departamentos, salvo que sea (muy) estrictamente necesario.

El día a día nos hace egoistas y sentir que nuestros problemas son los más importantes. Si hay un grupo de personas que lo comparten, tienen los mismos objetivos y sienten que se tienen que centrar en ellos, olvidándose de todo lo demás y la organización lo permite, nos encontramos ante un caldo de cultivo ideal para este antipatrón.

Y sí, el principal culpable de que lleguemos a él es la propia organización que lo consiente y no solo en estos casos, sino en aquellos en los que directamente por su propio organigrama o división funcional han creado de serie las barreras o muros, sin prever o fomentar la necesidad de colaborar o comunicarse.

Es muy frecuente encontrarnos con personas no solo que no sean productivas sino que su productividad neta sea negativa. ¿Por qué negativa? Porque el daño que hacen a la producción es mayor que lo que aportan y esto no es solo provocado por lo que pueden estropear, eso es casi lo de menos, sino por el impacto que tienen en la productividad de los demás.

Este antipatrón surge cuando conociéndose ese problema no se hace nada al respecto, lo que es lo mismo que admitir que tu capacidad de producción tiene una resistencia que no vas a eliminar. Lo peor de todo esto es que esta resistencia generará nuevas resistencias (teoría de las ventanas rotas) porque la cultura del nunca pasa nada es de lo peor que le puede pasar a una organización.

No se trata de generar una cultura de miedo (que es totalmente negativa) sino una cultura de responsabilidad, que es algo totalmente diferente.

El principio de Dilbert como solución a este problema es una huida hacia adelante porque lo que haces es desplazar el problema, ya que aunque lo separes de la línea de producción y lo coloques en un puesto donde sea inocuo, el mensaje sigue estando ahí: “no importa lo mal que lo hagas, que incluso te recompensaremos con ello” y eso termina calando en la organización, hasta tal punto que termina convirtiéndose en parte de la cultura de la misma.

Guy Kawasaki, es en la actualidad director de una de las empresas de capital riesgo más importante de los Estados Unidos, es experto en marketing y en mercados tecnológicos y ha sido consejero de Apple.

Tan extendido está el antipatrón que Guy Kawasaki llegó a decir que: “Hay dos tipos de compañías, las que reconocen que son exactamente como la de Dilbert y las que también lo son pero aún no lo saben”.

Es cierto que hay muchas personas que consideran que es muy exagerado decir que estas malas prácticas están extendidas ya que son totalmente contrarias a una política racional de recursos humanos y de desarrollo de la carrera profesional, pero también son muchísimas las que consideran que es una práctica habitual. Todo dependerá de nuestras experiencias personales y de nuestra objetividad.

El principio de Peter es consecuencia de la existencia de un solo sentido en la promoción profesional dentro de una organización, sin embargo, el principio de Dilbert, expuesto por Scott Adams, sí que tiene una base consciente por parte de la persona o personas que toman las decisiones y consiste en promocionar a empleados poco competentes a puestos en los que esté mucho más limitado y controlado el daño o pérdidas que son capaces de realizar.

¿Por qué es un antipatrón?, ¿no es está acaso salvaguardando la línea productiva y minimizando riesgos?. Desde luego que es una solución mucho mejor que no hacer nada, pero alimenta la cultura del “nunca pasa nada” (además de los costes adicionales de tener puestos vacíos o prácticamente vacíos de contenido), lo haces mal o pasas de todo y encima te ascienden a un puesto, en el que tal vez te aburras, pero en donde incluso vas a cobrar más.

El principio de Peter fue popularizado por los canadienses Laurence Johnston Peter y Raymond Hull en un libro homónimo publicado en 1969, con la famosa cita: “En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia… con el tiempo todos los puestos tienden a ser ocupados por un empleado que es incompetente para desempeñar sus funciones… El trabajo es realizado por aquellos empleados que todavía no han alcanzado su nivel de incompetencia”.

En ella trata de exponer uno de los principales inconvenientes de las organizaciones con promoción profesional vertical, en las que personas que son altamente competentes en unos puestos concretos, dejan de serlo en el momento en que ascienden a un puesto para que el que se requieren otras aptitudes.

De por sí, por típico en nuestro sector, podría ser considerado un antipatrón más. Sin embargo, en este artículo vamos a ver una versión de dicho principio directamente aplicada al desarrollo de software.

¿En qué consiste? Pues en el deterioro progresivo que sufre un software como consecuencia de su evolución y mantenimiento. Esto es una circunstancia que de manera general se produce en el desarrollo de software si bien puede ser contenida con buenas prácticas o acelerada en el caso contrario.

El antipatrón surge cuando un sistema está en continua evolución y no se toman medidas para mantener bajo control la deuda técnica y para seguir simplificando en lo posible su arquitectura y sus funcionalidades, de manera que si el sistema fue alguna vez útil, dejará de serlo poco a poco.

Como es algo que se suele producir lentamente y que tarda en detectarse, sobre todo si no estás acostumbrado a tener en cuenta estos aspectos, muchas personas consideran que es una forma de muerte silenciosa del sistema de información.

El principal motivo es la falta de cultura de producto por parte de los desarrolladores centrados principalmente en una cultura de proyecto orientada a la agenda y, por encima de ellos, de las organizaciones proveedoras y clientas de este tipo de servicios, que dejan en un segundo plano la calidad del software para centrarse en costes y beneficios.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.

Este antipatrón surge cuando se ha llegado a un punto en el que la mejoras a realizar en un determinado producto software o tarea requieren un esfuerzo mucho mayor que el valor que se obtiene con las mismas.

Las causas que pueden dar lugar a esto son muy variadas:

– Tareas sobreestimadas en las que los desarrolladores deciden ocupar todo el tiempo disponible en la misma (ver Ley de Parkinson).

– El intento de mejorar ciertos aspectos del producto o de los entregables del proceso que tienen un buen nivel de acabado y en donde introducir mejoras resulta complejo (ver Ley de Pareto).

– Inclusión de funcionalidades por parte de los desarrolladores o perfeccionamiento de las ya existentes, sin haber consultado con el área usuaria y que lo mismo no resultan necesarias o tienen un efecto negativo sobre las ya desarrolladas.

– Tratar de seguir realizando tareas sobre el proyecto para continuar facturando o para demostrar que se está ocupado: creación de necesidades inexistentes, inclusión de funcionalidades que se utilizan en muy contadas ocasiones y por un grupo reducido de usuarios, refactorización sin efecto o prácticamente sin efecto sobre la deuda técnica, etc…

Los efectos de este antipatrón no solo se centran en un mal aprovechamiento de los recursos disponibles (que de por sí ya es importante), sino en la inclusión de una mayor complejidad en el sistema, de nuevos posibles errores, de la modificación o creación de elementos documentales, etc…, cada uno de los cuales añade un coste adicional innecesario al sistema.

Es un caso particular del antipatrón “software inflado“, en el que se invierte más esfuerzo del necesario en hacer los productos más robustos, seguros y complejos de lo que realmente necesitan.

Pero, ¿es malo que un software sea más robusto o más seguro? En absoluto, siempre y cuando no olvidemos cuáles son sus prioridades, es decir, si hacerlo más robusto o seguro de lo que necesita implica que tengamos que invertir esfuerzo en estas actividades y restarlo de la adecuada evolución del producto, no solo no estamos haciendo un uso eficiente del presupuesto, ya que lo invertimos en actividades que proporcionan menos valor, sino que además podemos poner en riesgo la propia línea de desarrollo del sistema, si es que nos quedamos sin dinero y no hemos cubierto las necesidades funcionales más prioritarias.

A lo anterior, hay que sumarle el riesgo de que se produzca un incremento de la complejidad del producto, ya que querer hacer el sistema más robusto o más seguro, no implica que se acierte con la estrategia, técnica o programación utilizada, lo que implica que aunque se consiga ese objetivo es posible que el producto sea más complicado de evolucionar (mayor deuda técnica) o que incluso se haya invertido un esfuerzo y que el sistema se haya quedado más o menos como estaba.

Otro aspecto que no hay que perder de vista, es que llega a un momento en el que no es posible mejorar la robustez, seguridad o complejidad del sistema, ya que lo que se termina mejorando en un punto, se termina estropeando en otro (ver Ley de Tesler).

El principio de Pareto no suele fallar, el 80% del objetivo se consigue con el 20% del esfuerzo. Saber donde parar es importante, no solo por el ahorro económico sino también por la propia calidad del producto.

En cualquier caso, el producto final que satisface las expectativas del usuario estará por encima de ese 80% y ahí es donde el peso de los detalles crece exponencialmente.

Y si algo tiene el desarrollo de software son detalles, si algo marca la diferencia son los detalles. Un solo detalle, una sola instrucción mal codificada puede dar al traste con la implantación de un sistema en los plazos marcados y esto puede suponer mucho dinero y pérdida de confianza.

Charles Eames, en otro campo donde los detalles son importantes, como la arquitectura y el diseño, tuvo un gran acierto con la siguiente reflexión, perfectamente aplicable al desarrollo de software y a otros muchos ámbitos: “Los detalles son los detalles. Ellos hacen el producto”.