archivo

Archivo de la etiqueta: antipatrón

¿Qué significa que un proyecto tengo éxito?.

Para muchos lo único que importa es que los beneficios conseguidos sean iguales o superiores que los esperados. Que el producto satisfaga o no las expectativas que se hayan puesto en él, pasa a un segundo plano.

Desgraciadamente hay mucha gente que piensa así, para los cuales los proyectos son solo números que analizan desde la lejanía de su despacho.

El daño que esto ha provocado a nuestro sector va a costar repararlo, entre otras cosas, porque hay muchos, muchísimos que siguen teniendo esa visión.

Más allá de esa actitud, existen proyectos que se ponen tan cuesta arriba que todas las partes integrantes, lo único que quieren es terminar de ejecutarlo y consideran un éxito situar el producto en un entorno de producción. Esa es una visión “cumplidora” del desarrollo de software en la que probablemente se hayan tomado todas las precauciones (burocratización del proyecto, cumplimiento de procesos, búsqueda de aprobación en decisiones críticas por parte de superiores, etc…), para que nadie pueda echar en cara malas decisiones o malas prácticas.

Ese éxito efímero se torna en fracaso cuando la aplicación que se ha puesto en producción solo da problemas y ocasiona nuevos gastos. En estos casos, lo que suele pasar es que cuando todo esto termina saliendo a la luz, sus responsables se encontrarán ya lejos, muy lejos.

La siguiente reflexión de Jeff Patton, consultor y coach en desarrollo de software siguiendo enfoques ágiles pone en diferentes niveles lo que supone el éxito de un proyecto o el éxito de un producto: “el éxito del proyecto no es el éxito del producto”.

Tenemos un guest star principalmente cuando se producen una de las siguientes circunstancias:

– Cuando tenemos a una o varias personas que deberían formar parte del equipo de proyecto, aunque sea en un área concreta o especializada, y que no sienten que el proyecto sea cosa suya, lo que provoca que no atiendan a compromisos o que su participación sea intermitente y generalmente para dar más problemas que soluciones.

– Cuando tenemos a una o varias personas que no forman parte del equipo de proyecto pero que en determinadas circunstancias intervienen en el mismo (llamados o no) para dar una serie de directrices o instrucciones que generalmente suponen una resistencia al proyecto.

El problema de este antipatrón es que es muy complicado de contrarrestar.

En el primer caso se puede intentar implicar en el proyecto a los guest stars dialogando con ellos, intentando que el proyecto esté más presente en su día a día pero al final será su decisión formar parte activa del proyecto o no. ¿Se puede intentar por las malas haciendo que su superior le obligue a estar implicado en el proyecto? Sí, pero salvo que su superior esté muy encima la participación seguirá siendo insuficiente o con malos resultados (porque a la falta de implicación se le sumará ahora su enfado) y en el caso de que sea aceptable será cortoplacista porque entenderá que la llamada de atención es injusta y provocada por los responsables del equipo de proyecto y a las primeras de cambio volverán a poner las mismas trabas que antes.

En el segundo caso la solución pasa por tener identificados a priori los posibles guest stars e impedir su participación en el proyecto. El problema lo tenemos cuando tienen que intervenir al ser una parte interesada, en esos casos nos tocará dialogar y razonar para intentar reducir (eliminar va a ser complicado) las resistencias que pongan.

Se llega a este antipatrón por la creencia de que si se retrasa la entrega, se llegará a producción con un mayor número de funcionalidades y de más calidad.

Es posible que quien haga esta planteamiento lleve razón pero un retraso en la entrega debe sustentarse en bases más sólidas, ¿más solidas que esa? Sí, porque, ¿quién te dice que cuando termine ese mes no se va a hacer de nuevo el mismo planteamiento? y así sucesivamente, no se terminará de entregar el producto.

La búsqueda de la perfección en el desarrollo de software no suele dar buenos resultados porque llegado a un punto el esfuerzo necesario para producir una mejora crece exponencialmente respecto a la mejora conseguida, a eso súmale que se sigue trabajando sobre un producto que no está en producción y aunque tengamos versiones sobre las que se pueden hacer pruebas y obtener feedback, seguiremos trabajando con fogueo y no con fuego real por lo que lo mismo se está invirtiendo esfuerzo en evolucionar un producto que cuando se utilice realmente se deba orientar de otra manera.

No se trata de negarnos a retrasar una entrega, negarnos a eso de base sin analizar la situación es un error, sino de evitar que ese retraso sea consecuencia del miedo (lógico) que existe a dar el paso final de tener el producto (o una nueva versión del mismo) en producción.

Comenta Jeff Patton que: “No necesitamos una documentación precisa, sino un conocimiento compartido”.

Esa reflexión no descarta la documentación si bien no le da el monopolio sobre el conocimiento porque la documentación es eminentemente estática y el conocimiento es dinámico, porque la documentación presenta como límite la habilidad del redactor y la comprensión del lector y el conocimiento se basa más en la comunicación y en la interacción, si algo no lo he entendido lo consulto, si en algo no estoy de acuerdo trato de fundamentar otra posible solución (sin menospreciar la base teórica o informativa de los documentos escritos).

Los documentos se pueden utilizar como interfaz entre diferentes grupos de trabajo (siempre y cuando sus actividades no requieran una interacción continua o frecuente o la misma no sea posible, independientemente de que sea deseable), sin embargo, no se debe cometer el error de restringirlo como único canal de comunicación, precisamente por el hecho de que resulta prácticamente imposible que toda la información se haya plasmado adecuadamente y que el propio lector consiga interpretarlo con la misma intención que la persona que lo redactó (todos sabemos que existen tantas percepciones o visiones sobre un determinado asunto como observadores haya).

Por mucho tiempo que se dedique a la redacción del documento, siempre se va a perder información y se van a alimentar los malos entendidos. Cuando se requiere la colaboración continua entre personas o entre equipos, este modelo no funciona.

No hace mucho un amigo me hizo referencia a un proyecto de hace ya algunos años en el que la comunicación entre usuarios y desarrolladores se basaba principalmente en documentos (también existía diálogo, pero la pieza fundamental, eran encuestas, formularios, etc…), ¿podéis imaginaros cuál fue el resultado del proyecto?.

Por otro lado si la interfaz se basa en documentos, se alimenta la distancia entre los equipos, propiciando la aparición del antipatrón “arrojar al otro lado del muro“, en el que el proyecto queda en segundo plano, ante la actitud defensiva que toman los diversos implicados.

Estoy de acuerdo en que dependerá de cómo se enfoque, pero considero peligroso que el proceso esté en primer plano porque se puede terminar pervirtiendo el modelo de manera que lo principal sea definir un procedimiento de trabajo, hacer algunos ajustes adaptados al proyecto y hacer que se cumplan.

Esto puede dar lugar a la creación de un cultura de cumplidores que traten de utilizar el proceso no como herramienta sino como escudo en el caso de que los proyectos no salgan bien. Al ser considerado un salvoconducto para escurrir responsabilidades, los cumplidores se convierten, más allá incluso de los QA, en fanáticos del procedimiento establecido. Y no porque crean en él, insisto, sino como actitud defensiva.

En el momento en que el procedimiento, el proceso o la metodología pasa de ser una herramienta (que debería estar bien calibrada a la realidad de la organización, de sus proyectos y del proyecto en el que se está trabajando) a un fin se ha elegido el camino equivocado porque independientemente de que sea más o menos efectivo, el modelo en lugar de ser proactivo se termina convirtiendo en reactivo. Y no solo es cuestión de que en lugar de buscar soluciones se verifiquen listas de comprobación, sino de entender algo que es conocido por la mayoría de lo que nos dedicamos a esto: el proceso no asegura nada.

Pese a todo, la forma más común en la que nos vamos a encontrar el QA será orientado al procedimiento y las metodologías, considerando a los proyectos como algo genérico o en el mejor de los casos, definiendo distintos itinerarios en función de una categorización que se haga de los mismos. De hecho esa será la definición de QA que encontraréis en la mayor parte de sitios.

Personalmente (y solo es una valoración personal), me niego a llamar a eso aseguramiento de la calidad.

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.