archivo

Archivo de la etiqueta: prioridades

Si hay disponibilidad presupuestaria en el proyecto o en el futuro se quiere seguir invirtiendo en el mismo siempre tendremos la posibilidad de desarrollar nuevas funcionalidades o herramientas dentro del sistema o seguir sacando brillo a las ya existentes.

Eso tiene sentido si hay un producto que funciona. Si el producto no funciona como debiera, invertir esfuerzo en lo que no es importante deja sin arreglar lo realmente significativo dejándonos con menos presupuesto y con un sistema más grande que costará más dinero corregir y evolucionar.

Es necesario que el usuario tome decisiones sobre lo que considera más prioritario. A muchos les costará porque ese miedo que existe a tomar decisiones y equivocarse pero no hay más remedio hacerlo porque es un error que sea el desarrollador el que elija ya que el sistema es para el usuario y él es quien sabe lo que necesita (al principio del proyecto una idea más general y conforme vaya avanzando irá despejando las mismas).

Tanto usuarios en lo funcional como desarrolladores en lo técnico deben tener los pies en el suelo y no hacer castillos en el aire. Es necesario que lo fundamental funcione muy bien porque a partir de ahí se construye lo demás, si pensamos en lo no trascendente y dedicamos atención y esfuerzo a ello comprometeremos las posibilidades de éxito del proyecto.

En el artículo anterior vimos las actividades que definían al proceso de implantación y de las consecuencias de que el tiempo necesario para realizar esa actividad superasen unos umbrales admisibles para el proyecto de desarrollo de software en cuestión.

La aplicación de una metodología o enfoque ágil o la utilización, en general, de alternativas iterativas e incrementales suponen por su propia naturaleza una disminución de los tiempos de implantación, sobre todo, una vez que ya se han realizado varias evoluciones del sistema.

Sin embargo, si el tiempo necesario para realizar las implantaciones resulta superior al tiempo de iteración definido tenemos un problema ya que provoca una acumulación de las entregas y que buena parte del tiempo invertido en el proceso de implantación se pierda. Esta situación no debería mantenerse mucho tiempo y para solucionarla sería necesario retrasar una entrega hasta que se pueda subir una acumulación de evoluciones a producción.

Estas situaciones pueden producirse en más ocasiones de las que podemos pensar, ya que lo mismo los trabajos siguiendo metodologías ágiles, parten de una versión del producto avanzada y que no ha sido implantada todavía (o no se han implantado con éxito), los equipos encargados de testing y de paso a producción tienen una carga de trabajo elevada, otras prioridades, etc…

Soy de la opinión de que para poder trabajar de manera adecuada hay que estabilizar la situación, es decir, si la implantación de un producto resulta compleja o está dando problemas, hay que centrar los esfuerzos en ella y adaptar los desarrollos que se están haciendo a esa circunstancia.

Además de la aplicación de enfoques ágiles, ayuda mucho la existencia de unos entornos de integración y de preproducción los más parecidos posibles a los de reales, la aplicación de la integración continua, la utilización de técnicas de desarrollo guiadas por las pruebas (TDD) o al menos la aplicación de una estrategia adecuada de aplicación de pruebas unitarias, para reducir de esta forma la aparición de efectos colaterales y disminuir los tiempos necesarios para las pruebas de regresión y la corrección de este tipo de incidencias.

Además de lo anterior es importante que con carácter previo a la entrega el producto haya sido probado de manera adecuada por el equipo de proyecto (nada de entregas a ciegas o de pruebas superficiales).

También resulta muy adecuado el establecimiento de itinerarios de testing (todas las aplicaciones no requieren el mismo nivel de testing, ni todas las circunstancias son similares), la aplicación de testing ágil, proporcionar a los proveedores información detallada sobre las características de nuestro entorno de producción, la aplicación de una política de prioridades a los equipos encargados del paso a producción acorde a la problemática existente en cada momento, etc…

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.