archivo

Archivo de la etiqueta: desgaste

El desarrollo de software es una disciplina complicada y que generalmente es poco generosa con las personas que día a día trabajan en ella.

Construir un producto, ladrillo a ladrillo, línea a línea (por mucho que nos podamos apoyar en frameworks, generadores de código y librerías) es una actividad compleja, sobre todo teniendo en cuenta que el desarrollo de software no es solo programación. Para ejecutar (programar) es necesario haber llegado antes a la determinación y conocimiento de qué es lo que se va a hacer y eso resulta complejo y puede ocasiones desgaste entre las partes sobre todo si los contextos no son favorables y/o las personas no ponen de su parte.

A los desarrolladores nos cuesta mucho trabajo desconectar cuando salimos del trabajo sobre todo cuando hay problemas y desgraciadamente nos encontramos con problemas con demasiada frecuencia.

Y dentro de trabajo si nos encontramos motivados o si el propio reto o problema nos motiva toda nuestra atención se dirigirá a la resolución del mismo independientemente de que la misma nos lleve días (o semanas). Cuando entramos en lo que los expertos en productividad llaman “la zona” parece que no existe el tiempo y de existir siempre nos va a aparecer que avanza demasiado deprisa (no es sencillo gestionar esto cuando tenemos otras tareas que también están pendientes de nuestra atención).

Creo que es interesante reflexionar sobre la siguiente cita de Orson Scott Card (traducción libre): “La programación (el desarrollo de software) es el gran juego. Te consume a ti, tu cuerpo y tu alma. Cuando estás atrapado en él, nada importa”.

Cuando un proyecto entra en una espiral en la que el equipo de proyecto tiene que enfrentarse continuamente a una horda de problemas que dificulta, sin duda, su avance y el cumplimiento en los compromisos en las diferentes iteraciones es que algo se ha hecho mal o que la situación de partida no era buena o, tal vez, ambas cosas.

También es cierto que si el equipo no se deja vencer por esta situación, va respondiendo, va ganando la batalla aunque parezca que nunca termina y se cumplen buena parte de los compromisos, es que algo se está haciendo bien.

La verdadera naturaleza de un equipo de proyecto, como en la vida, sale en los momentos malos, ahí es donde no solo vale la capacidad técnica o los conocimientos, sino la intención y las ganas de luchar por tratar de cumplir unos objetivos. Cuando el desgaste, la presión y los nervios te van haciendo más pequeño, solo te quedan dos opciones, dejarte vencer o tratar de enfrentarte a la situación, ahí es donde te haces grande y en donde demostrarás que no solo puedes ganar cuando el viento sopla a favor.

Si los problemas no dejan de aparecer, llegado el momento adecuado (porque una solución aplicada en mal momento por muy buena intención que lleve, puede empeorarlo), es necesario actuar.

Muchos de esos problemas (más de lo que se piensan) son el resultado de someter a los equipos a una carga de trabajo superior a la que pueden admitir, lo que provoca que cualquier contingencia se convierta prácticamente en un obstáculo insalvable. Si a eso le sumamos otros riesgos como un entorno tecnológico inestable, un código con mala deuda técnica, la participación de diferentes equipos que tienen que sincronizar desarrollos, etc…, la aparición de problemas, uno tras otro, será inevitable, mientras pasan los días y es necesario cumplir lo pactado.

Hablo de solución y debería hacerlo en plural porque generalmente e independientemente de que haya algún problema principal hay otros secundarios que por si mismos o por alimentar a terceros, también deben ser tratados.

El triángulo de hierro delimita la calidad final del producto software siempre y cuando las variables que lo componen den la oportunidad de que por lo menos el proyecto tenga alguna oportunidad.

Los enfoques clásicos de desarrollo están orientados al cumplimiento de una agenda, lo que no quita que en los enfoques ágiles se tengan en cuenta también esos parámetros, la diferencia se encuentra principalmente en el grado de flexibilidad que se aplica a los mismos.

Una de las variables es el alcance. Conforme se va avanzando en el proceso de desarrollo, el usuario se empezará a dar cuenta de especificaciones que ha realizado y que son incorrectas o mejorables, así como de nuevas funcionalidades que entienden que serán necesarias. El usuario presionará para que se incorporen todas, incluso en aquellos casos en los que se tenga que “tirar” desarrollo ya realizado.

Si no se gestiona adecuadamente el alcance y en consecuencias, las expectativas, del usuario, el proyecto correrá un riesgo importante. Si se dice a todo que sí y no se ajusta la carga de trabajo a la capacidad que se puede asumir: tanto en tiempo como en presupuesto, el producto se resentirá (reducción de la calidad) y las relaciones entre las partes también (desgaste como consecuencia de condiciones impuestas sin negociación, como consecuencia de expectativas insatisfechas, como consecuencia de la presión, etc…).

De tanto tensar la cuerda termina por romperse lo que puede dar lugar a un proyecto que se quede a medias en el que funcionalidades importantes se han quedado fuera o sin rematar, motivado principalmente por el hecho de no haberse realizado una adecuada gestión de prioridades, ya que el cliente daba por hecho de que todo lo que estaba pidiendo iba a entrar.

Este es un antipatrón para clientes y proveedores. Ambos pierden, los primeros por no buscar un equilibrio entre lo que se quiere y lo que se puede y los segundos por no saber o querer gestionar estas situaciones.

Desarrollar software es muy complicado, no solo por su componente técnico y por el hecho de que errores muy pequeños en el código puedan provocar incidentes graves, sino porque el proyecto se realiza en un contexto en el que interactúan personas, equipos e incluso organizaciones diferentes, cada una con sus objetivos e intereses.

Los proyectos entran en conflicto cuando alguna de las partes decide abandonar el objetivo general del proyecto (satisfacer las expectativas del usuario) para poner por delante sus objetivos individuales (como por ejemplo ganar o no perder dinero en el proyecto, dedicar más atención a otras tareas que entiende más prioritarias, etc…).

Es cierto que a veces se llega a estas situaciones por no respetar las condiciones de partida del proyecto y que eso provoque que una de las partes quiera imponer en un momento dado sus propias reglas. También es posible que desde fuera del ámbito del proyecto, personas o departamentos con un nivel superior en la jerarquía organizativa den instrucciones para que determinados trabajos tengan una mayor prioridad que el que se está realizando en el proyecto.

Pero también lo es que muchas veces se llega a esto por no haber gestionado de manera adecuada tu rol en el proyecto y los recursos que tienes a tu disposición y se llegue a una situación donde para salvar unos resultados pongas en riesgo el propio proyecto.

Es frecuente que este tipo de situaciones de lugar a un enfrentamiento de desgaste, del tipo de la guerra de guerrillas, donde el objetivo no es tanto ganar, como no perder. Para ello, se tiene que llegar a un punto donde al resto de stakeholders no le compense seguir con la situación y tengan que buscar una vía para continuar con el trabajo. A ese extremo se llega tras mucho desgaste.

Y efectivamente, no se ha ganado aunque el resultado parezca indicar que sí, ya que la actuación que ha tenido en el proyecto ha fracasado (independientemente de que se pueda reconducir posteriormente y terminar con un cierto éxito) y el resto de implicados ha perdido su confianza.

¿Qué te queda entonces? Solo el balance económico del proyecto (visión cortoplacista), pero si levantas la vista, en ese campo solo te queda desierto.

En el ciclo de vida en cascada, por su naturaleza, por el hecho de que el usuario empieza a ver las funcionalidades implementadas muy tarde (poco antes de la entrega) existe la tendencia a querer abrir puertas que ya se consideraban cerradas, es decir, a retocar especificaciones, en algunos casos serán cosas menores e incluso asumibles y en otros casos, se requerirá un trabajo muy importante realizar su implementación.

Y eso sucederá por muchos prototipos con los que hayas trabajado con el usuario. Es cierto, que el uso de prototipos disminuye el riesgo de posibles discrepancias entre el producto final y las expectativas del usuario, pero también lo es que durante el proceso de desarrollo pueden pasar muchas cosas que hagan que algunas (siendo generoso) especificaciones iniciales ya no valgan, que el usuario que te las haya definido se haya ido de la organización o se haya cambiado de departamento y sobre todo que hasta que no se trabaja con el producto el usuario no termina de ver claro lo que necesita (e incluso requerirá varias iteraciones hasta alcanzar con una solución que empiece a satisfacerle).

¿Qué hacemos entonces?, ¿dejamos las puertas abiertas o cerradas?. Probablemente si se dejan cerradas el producto desarrollado fracase porque por muy bien que se haya hecho, no hará o funcionará como el usuario quiere que lo haga.

Ahora bien, lo que no puede ser es que el proveedor asuma con la carga. ¿Se han desarrollado todas las funcionalidades pactadas de la manera en que está recogida en los diferentes items documentales del proyecto que a su vez ya han sido aprobados por sus responsables? Sí, pues entonces el proveedor no puede, ni debe asumir esa carga.

Debe asumir lo que no haya hecho y los errores de lo que haya hecho, pero no debe asumir errores de terceros.

El problema de todo esto es que cuando esto ocurre, en lugar de asumir lo que hay, de responsabilizarse de lo hecho y de aplicar un mayor presupuesto al proyecto, se recurre al desgaste cliente (área técnica)/proveedor para intentar que esas funcionalidades se hagan, mientras que el área usuaria, suele salir impune, actuando como un espectador que ve una película en la mejor localidad, con palomitas y refresco gratis y que actúa como un crítico implacable.

Estas situaciones son demasiado frecuentes y dan lugar a proyectos que no dejan satisfechos a nadie, que no producen buenos resultados económicos y que han originado un gran desgaste entre las partes. Por motivos como este, es necesario huir de las cascadas como metodología y por otro hace necesario un proceso de educación importante en el área usuaria antes de iniciar el proyecto para que entiendan cuál es su papel en el mismo y la responsabilidad de las decisiones que toman.

Puede parecer que todo vale por ganar contratos en tiempos de crisis (y en tiempos de no crisis). Se tiran los precios, se ofrece lo posible y lo imposible y nada parece lo suficientemente difícil.

¿Qué pasa después? Desgaste y más desgaste, tijeretazos al alcance, la calidad por los suelos y cuando no un montón de código que no se comporta como quiere el usuario.

Los proyectos de desarrollo de software valen lo que valen, todo es optimizable, lo mismo el alcance de los trabajos se adapta a otros desarrollos previos y basta con hacer adaptaciones, todo eso es analizable, ahora bien, cuando lo que se ofrece es a todas luces imposible, lo más probable es que realmente lo sea.

Si no hay dinero para hacer un desarrollo, busca si existe un producto que se ajusta a tus posibilidades, si no hay ni una cosa ni la otra, lo mejor es que se espere a disponer de presupuesto suficiente, siempre será mejor eso que tirar el dinero o invertir una cantidad que se te multiplicará después en tareas de mantenimiento correctivo y evolutivo con una deuda técnica importante.

Si yo fuera proveedor de servicios de software intentaría tener invertido una buena parte de mis proyectos en plazo fijo, es decir, en proyectos donde facture por horas. En este tipo de trabajos, salvo que se gestionen muy mal o la calidad del servicio sea deficiente, se ganará dinero, tal vez no tanto como en otros, pero la seguridad de tener cubierto una buena parte de tu presupuesto, también tiene su valor.

Tanto se ha trabajado así entre clientes y proveedores que incluso en los proyectos orientados a cumplir un servicio, los proveedores siempre ponen sobre la mesa las horas cuando ven que existe una desviación en el presupuesto.

Si se contrata un servicio, debe estar por encima del esfuerzo ejecutado, ya que eso es lo que se ha contratado, un presupuesto cerrado.

El adjudicatario del servicio medirá internamente los costes del proyecto basado en las horas y el avance del mismo y también puede expresar al cliente su preocupación por las desviaciones en el presupuesto y ese es el límite al que se puede llegar.

Si las desviaciones son consecuencia de que el proyecto no va sobre las líneas especificadas en el contrato, sí que resulta razonable negociar y tal vez intercambiar unas tareas por otras o cambiar presupuesto de los trabajos.

Sin embargo poner sobre la mesa las horas y ser esa la base para una nueva negociación es un error. Si están justificadas plantea las causas y no tengas problemas en intentar que se te escuche. Si no hay una justificación en el proyecto, mi recomendación es que se asuman los errores y no se intenten compartir con el cliente, ya que al desgaste que se produce en el desarrollo normal del proyecto, se le añadirá otro que puede hacer muy complicadas las relaciones en el mismo y hará más difícil alcanzar los objetivos y si estos no se consiguen nadie terminará contento, nadie gana, aunque se consigan beneficios económicos.