archivo

Archivos Mensuales: enero 2012

Es frecuente encontrarnos en proyectos de desarrollo de software con obstáculos que de alguna y otra forma impiden la correcta ejecución del mismo.

Algunos de ellos se pueden sortear o solventar de manera más o menos rápida pero existen otros que persisten en el proyecto y cuya solución requiere en muchos casos de bastante diplomacia, en otros de la intervención de niveles superiores en la organización.

En otros casos una solución no es viable, ya sea por el tiempo o esfuerzo que requeriría, porque otra parte implicada no quiere que haya solución, etc…

Algunos ejemplos de obstáculos que pueden complicar el desarrollo de un proyecto y soluciones que se suelen aplicar:

– El área usuaria no participa, no lo hace en el tiempo que sería necesario o no terminan de implicarse.

Una solución que se suele aplicar es que todos los demás tiren para adelante con lo que hay.

– Se necesita la integración con un tercer sistema y los responsables del mismo no quieren proporcionar la interfaz de comunicación necesaria o no lo consideran prioritario y lo planifican en un plazo no compatible con los plazos en el proyecto.

En este caso salvo que sea una integración imprescindible, en cuyo caso bloquearía el proyecto, se obvia la funcionalidad que puede proporcionar ese componente o se reinventa la rueda.

¿Cuándo tenemos este antipatrón? Pues cuando ante un problema de estas características se decide rodearlo sin intentar encontrar una solución.

Claro que habrá veces que no sea posible (aunque si el inconveniente es grave, habría que pensarse muy seriamente dar por finalizado el proyecto y resolver el contrato, antes de que todos pierdan más dinero) y no tendremos más remedio que buscar una alternativa que permita continuar los trabajos. Procura que todos estos problemas sean conocidos cuanto antes a nivel de dirección y que tengan constancia escrita.

Pero en muchos casos llegar a terminar un proyecto a través de esa alternativa puede requerir mucho esfuerzo (y disgustos), no solo por el necesario para sortear el obstáculo y buscar la solución tal vez por un camino más largo, sino porque el resultado final puede que se aleje de las expectativas del usuario.

Anuncios

Enfoque y perspectiva o lo que es lo mismo dónde estamos aplicando nuestro esfuerzo y hacia donde queremos ir teniendo en cuenta el contexto en el que nos encontramos.

En el momento en que el enfoque no está orientado según la perspectiva o la misma no es adecuada (pueden existir diferentes causas: no se tiene en cuenta las expectativas del cliente o de los usuarios o no se han comprendido, no se interpreta correctamente o se ignora el contexto del proyecto, clientes o usuarios presionan para conseguir ciertos hitos en plazos muy complicados de conseguir, etc…), estamos llevando el proyecto hacia un final alternativo que no es válido (de ahí el nombre del antipatrón), ya que se aleja de los objetivos y expectativas reales.

Las circunstancias que pueden dar lugar a este antipatrón son diferentes, como distintas son también sus consecuencias (si bien, tienen en común el hecho de que llegará un punto donde no se verá el final del proyecto, no tanto porque esté lejos sino por el esfuerzo dedicado a llegar a supuestos finales que no lo eran):

– No cumplir con las expectativas del cliente o de los usuarios, trae problemas sobre todo si se ha actuado de manera irresponsable (acotación no pactada del alcance, calidad del software deficiente, múltiples bugs, etc…), por lo que la entrega del producto no es el final, ahora tocará una larga travesía en el desierto haciendo todo aquello que no se hizo cuando se debía.

– Ignorar el contexto o circunstancias que rodean al proyecto puede dar lugar a decisiones incorrectas o falsas expectativas del desarrollador. Si no te quieres dar cuenta de lo que hay, si no reaccionas, probablemente lleves al proyecto a un lugar equivocado.

– El cortoplacismo es agotador, hace perder cualquier perspectiva (para recoger en el futuro hay que sembrar en el presente y eso es complicado cuando todas tu esfuerzo está dirigido a cumplir con hitos intermedios) y crea la sensación de que nunca se va a llegar al final porque por cada obstáculo que se supera llega a continuación otro igual o peor.

Otro de los puntos débiles de los desarrolladores es que somos muy cabezotas, lo que nos hace que en determinadas ocasiones creamos que lo tenemos tan claro, que todo está tan alineado con lo que nosotros pensamos que es la lógica, que se parece tanto a situaciones similares que tratamos en otros proyectos en el pasado, que directamente no pasamos a analizar si un posible problema que se presenta lo es realmente o no escuchemos al resto del equipo para saber cuál es su opinión al respecto, sino que directamente aplicamos nuestra decisión.

El problema no es tanto acertar o equivocarse en la decisión, sino en el hecho de haberla aplicado sin entrar en un análisis objetivo de la misma.

Es decir, ante una circunstancia en un proyecto podemos tomar la decisión de que realmente no es un problema o que la probabilidad de ocurrencia es muy baja como para ser tenida en cuenta y que después la realidad nos demuestre que estábamos equivocados, es decir, se puede producir un error, pero es algo con lo que tenemos que convivir, nadie es infalible, pero lo que multiplica el error (y no porque se multiplique su impacto) es haber tomado una decisión sin haber realizado el más mínimo análisis (y todavía peor resulta, si después de todo, no se termina de aprender la lección).

Cada vez más muchas organizaciones están dirigiendo sus miradas a la adquisición de productos software o a la adaptación de los mismos a sus necesidades, dejando de lado el desarrollo a medida.

Motivos:

– Coste. Será más barato hacerse con la licencia de un producto (o todavía más si es gratuito) o contratar servicios para adaptarlo a tus necesidades (es un desarrollo a medida pero partiendo de un producto, es decir, de una base sólida a partir de la cual realizar las adaptaciones y evoluciones que se necesiten) que desarrollar desde cero una solución que hace lo mismo o prácticamente lo mismo.

Existen muchas empresas que han ganado mucho dinero con el desarrollo a medida, en unos casos aplicando internamente políticas orientadas a productos (esto que hemos hecho allí, lo aplicamos aquí haciendo un par de retoques y lo vendemos como si lo hubiéramos desarrollado desde cero), en otros sobredimensionando costes (que después no se correspondían a la calidad de los resultados) y en otros rehaciendo lo que deberían haber hecho bien antes (mantenimientos perpetuos).

Sin embargo, la crisis del software pasa factura y los clientes de estos servicios están cansados de no obtener unos resultados acordes con el dinero que pagan. Si a esto le sumamos la crisis económica actual donde no se pueden (o no se deben) cometer los dispendios de antaño, el impacto sobre el desarrollo a medida resulta evidente.

– Riesgo. Embarcarse en un proyecto de desarrollo de software presenta riesgos, porque desde que se contratan los servicios hasta que se obtiene la versión definitiva del producto, pueden pasar muchas contingencias que supongan un incremento de los costes, un retraso en la planificación o incluso que finalmente el proyecto termine en un cajón.

Con la que está cayendo, tener certeza de que lo que necesito lo voy a tener prácticamente de inmediato y con un presupuesto controlado, es un argumento de mucho peso a la hora de elegir entre un producto o un desarrollo a medida.

Los desarrollos a medida seguirán existiendo, tanto en la vertiente de adaptación de productos como en la de desarrollos de soluciones desde cero, ya que existirán necesidades no cubiertas por soluciones ya existentes o se quiera tener un control total sobre el proceso de desarrollo del producto.

Un nombre más apropiado me parecería el de “Aceleración con dirección al precipicio”.

Este antipatrón se produce cuando ante la presión del área usuaria o del cliente se toma la decisión de aplicar medidas desesperadas para intentar cumplir plazos prácticamente imposibles:

– Reducir los controles de calidad del software tanto en testing como en la propia calidad del código (deuda técnica), priorizando la ejecución de los trabajos por encima de todo. Esta circunstancia es la que da nombre al antipatrón.

En este caso, en el caso de que se lleguen a cumplir los plazos no será más que un espejismo porque probablemente el producto se encuentre inestable durante un tiempo, sea necesario seguir trabajando en el mismo y lo que se quería tener con tanta urgencia siga sin estar al 100% disponible.

– A lo anterior se le suma en la mayoría de los casos el overtime al que se someterá al equipo de proyecto, que en muchos casos no se tratará de un pico de trabajo puntual, sino que será sostenido durante bastante tiempo. Esto impactará también en la calidad de los resultados y la productividad del equipo, dando lugar a que en ocasiones, algunos de ellos, decidan buscarse otras opciones fuera de la empresa, impactando su marcha en la evolución de los trabajos.

– En otros casos, se recurrirá a meter más personal en el proyecto, produciéndose antipatrones como el de “programador con productividad neta negativa“, “otro programador más“.

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).

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.