Desarrollo de software. Antipatrones

Las buenas prácticas recogen actividades de gestión general, de gestión de proyectos, de diseño, de gestión de la configuración, de programación, etc… que son el resultado de experiencias recogidas a lo largo de años en proyectos de desarrollo de software.

Estas buenas prácticas, son instrumentos, los puedes utilizar o no, evaluando su aplicación y utilidad en el proyecto en el que estás trabajando o en el proceso que quieres implantar.

Como he comentado, son el resultado de experiencias aplicadas en proyectos reales, por eso resulta más interesante que utilices aquellas que sean adecuadas, en lugar de intentar redefinirlas u obviarlas.

Pero también existen un conjunto de actividades que también resultan de utilidad reconocer y son precisamente aquellas que no se recomienda realizar porque la práctica indica que no ayudan a conseguir buenos resultados. Esto es lo que se conoce con el nombre de antipatrones.

Por tanto, el conocimiento de las buenas prácticas debe complementarse con el de las malas prácticas. No aprovechar las experiencias de otros, cuando éstas puedan ser convenientes aplicarlas, es condenarnos a volver a repetir los mismos errores que tuvieron ellos y no salir de la espiral de la crisis del software.

Desarrollo de software. La tiranía del área usuaria

El área usuaria condiciona en gran medida el éxito o el fracaso de un proyecto de desarrollo de software. Su actitud es fundamental, si ellos no quieren el proyecto probablemente fracasará y si quieren, existirá un mayor número de posibilidades de que termine con éxito.

Es muy importante, como he comentado ya en infinidad de artículos, que al director usuario, si es el que finalmente sufraga la inversión del proyecto, hay que dejarle muy claro lo que el proyecto necesita a nivel de medios y también dejarle muy claro cuál va a ser la metodología de trabajo y lo necesario que resulta que todos los stakeholders estén implicados en el proyecto, buscando un mismo fin, que no es otro que el producto final satisfaga las expectativas planteadas.

Y todo eso debe recogerse documentalmente y a ser posible, además con una aceptación de dicho documento por parte del director usuario.

De esta forma, sirva para más o sirva para menos, tenemos una primera barrera de protección, porque no olvidemos que cuando un proyecto empieza a ir mal, las miradas siempre van dirigidas a los mismos.

Después, cuando se trabaje ya de manera efectiva en el proyecto, independientemente de la metodología que se utilice, todo acuerdo en materia de requisitos funcionales y no funcionales entre el equipo de desarrollo y el área usuaria, así como cualquier modificación de los mismos, debe ser recogido documentalmente y ser aceptado por el director usuario o por la persona o personas en quien haya delegado determinadas decisiones.

Esto no es burocracia, solo se trata de dar un carácter más formal a nuestra forma de aceptar trabajos, ya que estas serán nuestras siguientes barreras de defensa.

Sin lo anterior, estamos a expensas de ser sometidos a la tiranía del área usuaria, donde todo, según ellos, se puede realizar de manera fácil y rápida, donde todo debe estar prácticamente perfecto y donde se pueden permitir cambiar las decisiones tomadas en cualquier momento y en muchos casos achacar al equipo de proyecto que no han recogido de manera adecuada lo que ellos querían.

Es necesario el feedback del área usuaria para poder acercar el proyecto cada vez más a sus objetivos, sin embargo, el feedback debe estar controlado por una metodología de trabajo y por la necesidad de asumir todas aquellas decisiones que se hayan tomado previamente.

Desarrollo de software. Diversificación y equilibrio entre clientes y proveedores

Diversificar siempre se ha considerado una práctica recomendable si se quiere tener más controlado el riesgo de una inversión. Esta práctica resulta igualmente recomendable en el negocio del desarrollo de software, ya que no solo puedes evitar los males relacionados con la tiranía del cliente o la tiranía del proveedor, sino que también te puedes reponer a pérdidas de clientes o a la pérdida de confianza de un determinado proveedor ya que el edificio se seguirá sosteniendo por el resto de columnas.

La diversificación permite modular situaciones que puedan ser utilizadas para imponer condiciones abusivas, sin embargo se trata de un esquema general de funcionamiento y no asegura, ni de lejos, que esa situación de equilibrio llegue al proyecto de desarrollo de software.

He pasado por muchas etapas en cuanto a cuál debería ser la relación de poder entre clientes y proveedores y he llegado a la conclusión de que el modelo del ganar-ganar resulta el más adecuado, pero no solo entre ellos, sino entre el conjunto de stakeholders de un proyecto.

Ahora bien, las dificultades de alcanzar un funcionamiento basado en el win-win, son importantes, y tiene que ver mucho con la dificultad de alinear objetivos.

Y es que el contexto de partida de muchos proyectos suponen un verdadero muro para conseguir que el enfoque de los objetivos entre stakeholders coincida a nivel de mayor prioridad con el éxito del proyecto: presupuestos insuficientes, plazos muy complicados, metodologías no acertadas, falta de directrices por parte de la alta dirección para que los stakeholders estén implicados de verdad (no solo en los papeles), etc…

Diversificación, equilibrio, buenas condiciones de partida, aseguran unos buenos ingredientes al plato, ahora toca que los cocineros trabajen de manera adecuada y las contingencias que se produzcan en la cocina no afecten al acabado del plato.

Desarrollo de software. La tiranía del proveedor

En un artículo anterior hice referencia a la tiranía del cliente, cuando este aprovecha de forma abusiva la posición de dependencia de una proveedor respecto de los ingresos que le proporcionan sus contratos, ya que una buena parte de la facturación procede del mismo.

Esta tiranía también la podemos encontrar al revés, cuando un proveedor se encarga del desarrollo y mantenimiento de sistemas de información críticos para el negocio o para un aspecto concreto del mismo y el conocimiento necesario para poder cambiar de proveedor no está debidamente transferido al cliente y/o no está documentado (todo esto se ve agravado exponencialmente si en el caso de un desarrollo a medida no hay un control adecuado de versiones y del código fuente).

Como en el caso de la tiranía del cliente, el principal responsable no es quien ejerce la posición de poder sino quién ha propiciado las condiciones para que esa posición de poder exista. Es cómodo para un cliente depender de pocos clientes que te aseguren ingresos fijos y también lo es para un cliente trabajar con una serie de proveedores fijos que cumplen con su cometido y no te dan problemas.

Pero este ambiente idílico, funciona si todo va bien, pero ya sabemos de voluble es el mercado y nuestro negocio. Puede haber relaciones de años que se terminen degradando y se rompa el equilibrio en el que todo parece marchar, ahí es cuando empiezan los problemas, ahí es cuando pueden aparecer este tipo de situaciones.

Si un proveedor se siente fuerte, podrá empezar a exigir precios superiores a los que venía percibiendo, sin más justificación (real) que la de ganar más dinero, podrá empezar a reducir su nivel de calidad, a reducir su nivel de compromiso y lo peor de todo es que se termina tragando más y más porque te tienen bien agarrado por donde todos sabemos.

Llegado el momento tendrás que plantearte seriamente continuar con el proveedor. Lo mismo no lo puedes hacer de manera inmediata porque se puede resentir tu negocio, pero sí que se tienen que establecer los mecanismos para que el conocimiento no se encuentre exclusivamente en él.

Desarrollo de software. Los formularios y las unidades de medida asociadas a diversos campos

Es muy común que un formulario se puedan grabar magnitudes de determinados atributos y no se permita seleccionar la unidad de medida a utilizar o no se indique en el literal del campo.

De esta manera, los usuarios grabarán cifras sin indicar la unidad de medida, lo que dará lugar a serios quebraderos de cabeza si se quiere realizar una explotación mediante la realización de operaciones sobre los datos agregados.

Pese a que es algo que se debería considerar obvio y que es muy sencillo de poder ser revisado tanto en el propio proceso de desarrollo como con carácter previo a la entrega es demasiado común con encontrarnos con formularios que llegan así al entorno de producción.

Desarrollo de software. Tom DeMarco. Timothy R. Lister. Documentación, parte de la solución o parte del problema

La documentación es un instrumento para el desarrollo de software. Instrumento que si toca unas notas que no se ajustan a lo que requiere el proyecto provocará ruido y no una melodía.

No creo en un proyecto sin documentación pero tampoco creo en un proyecto donde la documentación se convierta en parte del objetivo.

Habrá proyectos que puede que fracasen porque entre otros factores no se ha realizado un uso adecuado de la documentación, pero eso no solo es aplicable a su defecto, también a su exceso.

¿Más vale que sobre y no que falte? Yo respondo con otra pregunta, ¿con tanto margen contamos como para malgastar esfuerzo?.

Sobre esto, Tom DeMarco y Tim Lister realizan la siguiente reflexión: “La documentación voluminosa es parte del problema, no parte de la solución”.