archivo

Archivo de la etiqueta: coste

Aunque resulte paradójico, la agenda es una de las principales causantes de la pérdida de control del proyecto porque en el momento en que se rompen sus premisas: estabilidad de las especificaciones, del contexto y acierto en las predicciones de coste y plazos y no se trata esta situación de manera natural ajustando la misma a la nueva realidad, estaremos trabajando en una condiciones fundamentadas en unas hipótesis erróneas y de esa situación no se puede esperar nada bueno.

La crisis del software se asoció al no cumplimiento de las agendas porque efectivamente los proyectos no cumplían objetivos de costes, plazos, alcance y calidad y a partir de ahí se constituyó la gestión predictiva de proyectos generando con las experiencias pasadas y con el paso del tiempo todo un cuerpo de conocimiento.

Precisamente este problema es el que sufren los desarrollos que siguen el enfoque clásico pero perfectamente son extrapolables a enfoques pretendidamente ágiles si los mismos están condicionados por agendas rígidas (digo pretendidamente porque agenda rígida y agilidad son conceptos contrapuestos).

Como es lógico, se mejoraron los resultados del pasado porque hay que tener en cuenta que se pasó del caos a un cierto orden, pero seguían sin ser satisfactorios a lo que había que sumar el desgaste que tiene este tipo de gestión entre todas las partes implicadas en el proyecto.

El culto a la agenda no es la solución porque pretende estabilidad y predicción en un contexto de incertidumbre que es inherente al desarrollo de software. Por eso, el centro no debe ser el triángulo de hierro sino el valor del producto de manera que costes, plazos y alcances supongan referencias y no límites.

La gestión de la capacidad, velocidad o carga de trabajo del equipo resulta esencial. Uno de los factores que más influyen en la pérdida de control es precisamente el intento de cumplir agendas imposibles.

Con mucho esfuerzo, siempre y cuando, exista posibilidad material de cumplir unos plazos, se pueden llegar a ofrecer unos resultados, pero, ¿a costa de qué?, ¿a costa de quién? Del producto y del equipo, ya que probablemente el sistema resultante tenga funcionalidades que no estén bien rematadas, tenga incorrecciones funcionales, numerosos bugs y la factura técnica sea francamente mejorable, a lo que hay que añadir el desgaste de las personas debido a la presión y al overtime.

Esto impacta en la entrega pero también en lo que queda de proyecto porque será necesario dedicar esfuerzo a “barrer” o “pulir” lo que fue mal mientras se está trabajando en lo nuevo.

Si no se ha reajustado la capacidad de trabajo asumible por el equipo, seguirá desbordado y lo más probable es que no cumpla con la mayoría de los compromisos y los que cumpla presenten deficiencias similares a los de la anterior entrega y se sigan acumulando flecos pendientes. Como una bola de nieve esto irá a más y más durante el transcurso del proyecto y si además se acumulan modificaciones funcionales serias sobre elementos ya desarrollados o hay cambios sensibles en el contexto del proyecto, se volverá absolutamente inmanejable.

Incluso con la intención de ajustar el trabajo a la capacidad del equipo podemos caer en la situación descrita si nos equivocamos a la hora de hacer ese ajuste, si bien, es posible a corto/medio plazo volver a una situación más equilibrada ya que gracias a este enfoque tendremos en cuenta ese esfuerzo de más que vamos a necesitar en cada iteración para lograr ese objetivo.

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

– La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

– Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

– Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

– Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

– No estima quien va a realizar el trabajo.

– La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

Partamos de una base cierta, cuanto más próximo se corrija un defecto desde el punto en que se originó menor será su impacto y menos costosa será su corrección.

Ante eso, podríamos tomar la decisión de que todo defecto se corrija en el momento en que se detecte y hacerla extensiva a todo el conjunto de desarrolladores.

De hecho esa práctica es acertada, si bien, habrá veces donde tocará decidir.

Supongamos que se detectan una serie de defectos en el proceso de paso a producción de un producto y que las vueltas a atrás son costosas, en tiempo y en esfuerzo, ¿decidimos siempre dar marcha a atrás?, pues depende, tocará evaluar el impacto del defecto y el coste que tiene volver a hacer una nueva entrega (que nadie garantiza que sea limpia y que no lleve consigo nuevos defectos), de esta forma, habrá veces que convenga seguir hacia adelante (lo cual no significa ignorar los defectos detectados) y otras en donde la versión no alcance el mínimo necesario para llegar a producción.

La decisión de si el defecto se debe corregir o no debe quedar en manos del responsable de definir la línea de desarrollo del producto que no es otro que el Product Owner, el cual debe asesorarse por personal técnico con el objeto de obtener información suficiente para tomar la decisión que mejor convenga al producto.

Si eres el responsable de una determinada infraestructura tecnológica que sabes que funciona, en la que tienes un soporte de calidad y en la que cualquier incidencia de cierta gravedad (y a veces no hace falta ni eso) con la misma te puede costar tu puesto de trabajo o incluso problemas mayores, ¿te arriesgarías al cambio?.

Imagina que la decisión depende, al menos, en primera instancia de tí. Delante tuya tienes la posibilidad de ahorrar entre un 50 y un 75% los costes pero también tienes la incertidumbre de que se trata de una tecnología nueva. En ese momento puedes poner encima de una balanza el ahorro y en la otra el coste que tendría para tu organización un fallo de la nueva tecnología (que probablemente sea muy superior al ahorro) y el deterioro que sufriría tu carrera profesional. ¿Hacia que lado crees que se inclinará la balanza?.

Incluso si se decantase por el lado de la innovación, es muy posible que el siguiente paso sea exponer los cambios ante otro grupo de personas que solo ven y entienden de números, ¿en qué porcentaje de casos crees que decidirán asumir el riesgo?.

La innovación llega al mundo empresarial porque hay personas, ya sea el responsable de un departamento, un comité ejecutivo o un consejo de administración que deciden asumir riesgos. En aquellos casos en los que la relación coste/beneficio/riesgo sea favorable y evidente el viento soplará a favor, en aquellos otros casos donde la incertidumbre sea mayor el viento soplará en contra, a lo que se sumará probablemente el hecho de que los proveedores de la solución actual, viendo amenazada su posición, no te pondrán las cosas fáciles.

Es muy probable que te soliciten casos de éxito y referencias y eso requiere un cierto tiempo y una inversión importante porque esos primeros pilotos es posible que te cuesten dinero porque si el cliente tiene una cierta entidad minimizará su riesgo en el sentido de que no querrá hacer un desembolso importante por algo que lo mismo no implanta, comenzará con una implantación paulatina en áreas no críticas y/o que estén muy controladas, querrá un soporte de una calidad similar a la que tuviera ya contratada con su proveedor habitual de servicios y una corrección pŕacticamente inmediata de las incidencias.

Incluso podrás encontrarte con situaciones en las que incluso te soliciten determinado tipo de certificaciones antes de hacer el piloto y/o contratarte tu tecnología.

Pero también existirán posibles clientes que encuentren tu solución como una oportunidad o como una salida (ante, por ejemplo, la imposibilidad de mantener determinados costes), poniéndote las cosas más sencillas y siendo más tolerantes, teniendo en cuenta que el tiempo y las oportunidades no serán ilimitadas.

Te puedes esforzar en un proyecto para cumplir una planificación y ceñirte a unos costes y sin embargo no conseguir nada, incluso desarrollando todas y cada de las funcionalidades tal y cual se especificaron en un principio.

¿Por qué? La idea inicial no tiene por qué funcionar, de hecho todos sabemos que es muy difícil acertar a la primera y todavía más conforme se incrementa el tamaño y/o complejidad de la solución. Esto es extensible tanto para el desarrollo de un producto propio como para el desarrollo de software para terceros.

Por tanto, afirmar que un producto que va acorde a unos plazos, unos costes y unas determinadas funcionalidades va bien, es mucho suponer si no se mide realmente el valor que se está obteniendo, de ahí el riesgo que supone, por ejemplo, un desarrollo en cascada cuando los desarrolladores y usuarios viven separados desde la finalización del análisis hasta etapas próximas a la entrega.

En los desarrollos iterativos incrementales, con entregas más frecuentes y con versiones en producción desde etapas tempranas el feedback permite evaluar el valor real que se está obteniendo y adoptar decisiones encaminadas a incrementarlo.

Otra cosa, es que pese a trabajar de esta forma se quiera seguir con el guión inicial prácticamente sin variaciones, en ese caso, poco importará la metodología porque predominará el seguimiento de un plan y esto es consecuencia muchas veces no de confiar ciegamente en él, sino por el afan de cumplir, de cubrir el expediente: “si al final se fracasa, la culpa no es nuestra, sino del plan”.

¿Quién expone más con esta estrategia?, ¿el cliente?, ¿el proveedor? De entrada podría pensarse que el cliente porque no cierra un alcance definido, solo lo esboza y puede darse el caso de que se acabe con el presupuesto y no se consigan los objetivos generales que se han marcado.

Es posible que esto suceda, como también es posible que suceda con una visión opuesta, la de la llave en mano, en donde se pretende mantener fijo el alcance, ya que en el momento en que las cuentas no cuadran para el proveedor y supera el umbral de las pérdidas admisibles, querrá empezar a querer recortar ese alcance y/o solicitar más dinero, todo eso en un contexto de desgaste en el que además, la productividad y calidad de los trabajos se verá afectada, impactando a su vez en los costes. Esto que cuento no es ciencia ficción, quiénes hayáis trabajado en este tipo de contratos sabéis de lo que estoy hablando.

La clave está en definir unas condiciones contractuales en las que ambas partes compartan el riesgo, pero para llegar a eso es importante que en el cliente se entienda que con la incertidumbre que es inherente a todo proyecto de desarrollo de software, cualquier estimación inicial terminará siendo papel mojado conforme vayan avanzando los trabajos y que lo realmente importante es ir trabajando de la mano del proveedor (y el proveedor de la mano del cliente) para ir incrementando el valor del producto en cada iteración, de manera coherente a la inversión que se está realizando.