archivo

Archivo de la etiqueta: priorizar

Cuanto más se parezca el sistema de información que se está desarrollando a un mando a distancia más esfuerzo requerirá su desarrollo, más complicado será de mantener y probablemente las funcionalidades más críticas sean muy mejorables por no haber dedicado a las mismas el esfuerzo que se necesita, debido a que se ha tenido que repartir en el desarrollo de funcionalidades menos críticas o absolutamente imprescindibles.

Este mantra se tiene que quedar grabado en los desarrolladores y en el Product Owner: “Lo más crítico y lo más importante lo primero. Después, si se puede, se tratará todo lo demás”.

A esto hay que sumarle la necesidad de buscar la solución más simple que resuelva el problema. No siempre daremos con la tecla pero por lo menos hay que intentarlo, ya que si hay intención la solución adoptada será menos compleja que sin hacer ese esfuerzo.

Desarrollar funcionalidades innecesarias es muy problemático conforme el sistema crece y no se termina de poner en producción porque complicará sobre manera la puesta en marcha ya que los usuarios se encontrarán con un sistema muy complejo y pondrán resistencia a su utilización.

Sobre este asunto, Mary y Tom Poppendieck realizan la siguiente reflexión: “El terreno más fértil para la mejora de la productividad en el desarrollo de software radica en no llevar a cabo funcionalidades que no son necesarias”.

Hay un aspecto importante a tener en cuenta, un software que no tiene prevista una evolución ya sea porque el proceso o procesos que informatiza ya están consolidados en la herramienta o porque no merece la pena ya que la tecnología está obsoleta (y resulta más adecuado, por tanto, hacer un nuevo desarrollo) no debería ser tenido en cuenta a la hora de plantear un programa progresivo de reducción de la deuda técnica en una aplicación.

Que no se tenga prevista una evolución no quiere decir que no vaya a surgir nunca esa necesidad, ya que basta con que lo pienses como para que mañana mismo te vengan con una petición de cambio. Ahora bien, se trata de sacar el mayor provecho posible a los medios que tengamos y para ello es necesario priorizar dónde realizar este tipo de actuaciones.

Lo normal es que si tienes previsto un plan de evolución de un producto y el mismo presenta una deuda técnica inadecuada se intente dedicar parte del esfuerzo a mejorar la misma de manera que vaya mejorando la mantenibilidad del sistema. Lo mismo no hay posibilidad de hacer un cambio en profundidad del sistema ya sea porque el esfuerzo que se puede invertir esté bastante limitado y/o porque existen fuertes restricciones temporales pero siembre cualquier mejora que se pueda aplicar se agradecerá después.

Nuestro trabajo no es conseguir imposibles.

Trabajamos con un presupuesto y tiempo limitado, es decir, trabajamos con unas restricciones. Se pueden y se deben ajustar si es necesario pero teniendo en cuenta que el chicle no se puede estirar indefinidamente.

También es frecuente que en el desarrollo normal de un proyecto nos encontremos en un momento dado con más tareas que las que podemos llevar a cabo ya sea a título individual o a nivel de equipo de proyecto.

Esto nos lleva tanto a nivel general del proyecto como a nivel de un momento determinado del mismo a una priorización de las tareas. Para ello es necesario que el área usuaria decida con criterio qué es lo más importante (teniendo en cuenta que todo tiene un coste) hasta que la dinámica de trabajo esté consolidada considerarán que todo es importante, crítico y urgente y aunque así sea (que no lo es) no tendrán más remedio que hacerlo (a veces cuesta que lo entiendan pero mejor así que darles unas expectativas que no vamos a poder cumplir). Una buena estrategia para la asignación de prioridades es la asignación por parte del usuario de un grado de importancia a la tarea del cero en adelante (la menor importancia es el cero) y sin tener la posibilidad de repetir un valor.

Hay que tener en cuenta que si aplicamos un enfoque evolutivo en el desarrollo de software el usuario irá poco a poco dándole forma a la idea general que tenía en la cabeza, la importancia de empezar por lo más prioritario permite que no se invierta el tiempo en realizar tareas secundarias dependientes de otras primarias y que podrían ser desechadas o modificadas si cambia la principal.

En eso consiste desarrollar con intención.

La visión de este problema por parte de Ken Beck y Martin Fowler la reflejan en el libro “Planning Extreme Programming” y es la siguiente (traducción libre): “Cuando estás saturado, no lo veas como que no tienes suficiente tiempo sino como si tuvieras demasiadas cosas que hacer. No podemos conseguir más tiempo pero sí tenemos la posibilidad de hacer menos, al menos por el momento”.

Si un sistema de información requiere importantes ajustes sin los cuales los usuarios no pueden trabajar de manera adecuada es necesario dar una respuesta lo más rápido posible, no solo para ir solucionando esos problemas sino para que los usuarios vayan ganando confianza y pongan menos reparos a utilizar una aplicación en esas condiciones.

Hay que actuar rápido pero con cabeza, apagar fuegos pero con intención, de lo contrario estaremos condenados a seguir apagándolos durante mucho tiempo con todo el coste que eso tiene consigo, no solo por la pérdida de productividad de los usuarios (que es lo más importante), sino también por el esfuerzo invertido en tareas de desarrollo que no terminan de arreglar los problemas (o lo hace demasiado lento).

Este tipo de problemas se puede producir en sistemas de cualquier tamaño pero son muy característicos en sistemas de información de gran tamaño en los cuales no será posible actuar, desgraciadamente, con tanta rapidez: demasiados frentes abiertos, tiempos de desarrollo más elevados (mayor complejidad funcional y mayor deuda técnica), pasos a producción más complejos y más stakeholders implicados.

¿Qué hacer en estos casos? Intentar concentrar los esfuerzos en los frentes más prioritarios (obligará a abandonar determinados módulos del sistema de información para tratar de salvar a otros y en consecuencia a la propia aplicación), orientar el mayor esfuerzo posible del proyecto en realizar el mantenimiento del sistema intentando desviar las tareas de asistencia a usuarios a proyectos especializados en la organización que se dediquen a eso (si es que existen), intentar minimizar el número de errores (ya ha habido demasiados, aunque no sean culpa tuya), involucrar a los responsables funcionales en la toma de decisiones (todos ganamos o todos perdemos) e intentar reducir en lo posible los tiempos de paso a producción.

La priorización de funcionalidades permite que las primeras versiones del software contengan aquellos módulos que el área usuaria considera que va a tener más utilidad para ellos, de esta manera, además se obtiene el feedback para terminar de realizar los ajustes necesarios, los cuales se van insertando en las siguientes versiones que se van liberando.

En el caso de que haya problemas presupuestarios en el proyecto nos aseguramos de esta forma que las funcionalidades más necesarias y críticas se habrán puesto en marcha y con las diferentes iteraciones se habrá conseguido una mayor alineación entre las mismas y las expectativas del usuario.

Dejando para el principio lo más importante y para el final lo más accesorio, reduciremos también el porcentaje de funcionalidades de la aplicación que se implementan pero que no se utilizan o se usan de manera residual, ya que por un lado los usuarios enfocarán la mayor parte de sus peticiones en mejorar lo que hay ya desarrollado y en otras tareas prioritarias todavía no implementadas.

Llevo unos cuantos artículos haciendo reflexiones sobre el hecho de que el desarrollo de software tiene un precio y que cuando se oferta (y se acepta) hacerlo por menos del mismo sin que exista una justificación para esa reducción del importe o que cuando se pone un presupuesto de ejecución inferior al que debería ser, el proyecto entra en una situación de alto riesgo para que se desarrolle con unos niveles de calidad aceptables o para que simplemente se ejecute. Hay que huir, por tanto, de ofertas imposibles y presupuestos insuficientes.

Esa situación ha hecho y está haciendo mucho daño a nuestra profesión porque al final todos pagamos justo por pecadores cuando un proyecto y otro también no alcanza unos niveles mínimos de calidad.

Sin embargo, por encima del Departamento TIC de una organización se encuentra la dirección de la misma que es la que hace el reparto de presupuesto entre los diferentes departamentos de la misma. Si al Departamento TIC se le asigna X y en realidad necesita 2*X o 3*X para poder ejecutar sus competencias, es necesario hacer ajustes y ese ajuste llega también a los presupuestos de los proyectos porque lo que suele suceder es que el recorte económico no suele ir acompañado por una rebaja de competencias, es más, en algunos casos va de la mano incluso con más tareas.

Ante esto, ¿qué se puede hacer?

1) Pelear hasta donde se pueda porque el presupuesto que te asignen sea el máximo posible acorde a las tareas que tienes que realizar. El éxito de esto dependerá muy mucho de la consideración y posición que tenga el Departamento TIC en la organización. Si no está bien posicionado, será complicado conseguir algo, pero por lo menos, hasta donde se pueda hay que intentarlo.

En uno de los primeros artículos que escribí comenté lo necesario que resulta que el responsable TIC de una organización ocupe un puesto directivo en la misma, de lo contrario está vendido. También he comentado que el presupuesto TIC debe ser gestionado integramente por el Departamento TIC ya que así se conseguirá un mejor rendimiento de la inversión económica y una mejor planificación.

2) Gastar mejor.

Esto empieza por priorizar ya que no todo es igual de importante ni todo es igual de urgente. La priorización implica prescindir de tareas que no son necesarias. Si nos ponemos a analizar hay muchas modificaciones en sistemas de información (generalmente evoluciones funcionales), alcances de muchos desarrollos u otras tareas dentro del Departamento TIC que son prescindibles. En todos estos casos, menos es más.

Si hay una solución que funciona, ¿para qué sustituirla por otra? (salvo que su coste total de propiedad sea superior al que tendría si se desarrollase de nuevo).

3) Mejorar la productividad de los propios equipos. Siempre es posible afrontar esta mejora y en estas situaciones donde el presupuesto y el trabajo es el que es es cuando hay que intentar mejorar la eficiencia del trabajo desarrollado. No se trata de trabajar más, sino de trabajar mejor.

4) Adaptar los procesos a la realidad presupuestaria.

5) Elegir el proveedor más adecuado para cada trabajo. No hay un proveedor universal que sea el mejor en todo, hay especialistas que hacen mejor una serie de tareas que otros. La elección de un proveedor que sea especialista en un área probablemente te pueda proporcionar mejores condiciones económicas con un nivel de calidad aceptable que otros. Como puede haber diversos especialistas sobre una materia, lo mejor es ir hacia una concurrencia competitiva y que gane el que mejor solución proponga, sin que el precio sea el factor principal para realizar la elección.

6) Tender al producto sobre el desarrollo a medida, cuando las condiciones sean mejores, que lo serán en la mayoría de los casos. Si además, la solución es libre, mejor (siempre y cuando el servicio que se te ofrezca sea competitivo frente a la alternativa propietaria).

7) Aplicación de estrategias ágiles en el desarrollo y mantenimiento de software.

Estas son algunas posibilidades que se pueden aplicar y permitirán optimizar tu presupuesto, sin embargo, no son los ingredientes de una receta que te permitan conseguir imposibles, si el desequilibrio entre lo que se puede gastar y los servicios a ofrecer son importantes, la calidad de los mismos se verá mermada.

Para mi son dos conceptos distintos. Si se prioriza es porque existen unos objetivos que dan sentido a esas prioridades.

La situación contraria, en la que las prioridades condicionan los objetivos provoca una desviación de sus propósitos, ya que estarán supeditados a decisiones provocadas por el día a día, por el corto plazo, por las limitaciones del presente.

Es fundamental tener en cuenta cómo estamos para plantearnos a dónde queremos llegar, pero si antes de marcar el mapa con una X condicionamos nuestras actuaciones con prioridades del presente, nos quedaremos a mucha distancia de nuestro objetivo, en el caso además de que hayamos tenido la fortuna de elegir el rumbo adecuado.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.211 seguidores