archivo

Archivos diarios: mayo 3, 2012

Desarrollar software requiere una cierta estabilidad, todavía más si cabe cuando el proyecto es complejo e intervienen diferentes equipos de trabajo.

Estabilidad no es renunciar a la adaptación al cambio, sino es mantener una línea de trabajo y una coherencia. Claro que es posible elegir lo que se va a desarrollar en la próxima iteración, aunque eso suponga rehacer funcionalidades ya implementadas. Lo importante es que el responsable funcional conozca las consecuencias y el coste y asuma sus responsabilidades como también debe hacerlo el equipo de desarrollo en caso de que se equivoque.

Los bandazos son el resultado de que se produzcan con frecuencia: cambios de prioridades o parones dentro de un sprint, parones entre iteraciones, cambios de interlocutores, cambios de enfoque radicales en las expectativas u objetivos del proyecto, cambios en capacidad de esfuerzo que puede asumir el equipo, etc…

No se trata, insisto, de eludir o rechazar la adaptación al cambio, se trata de que los cambios sean razonados y no fruto de caprichos o negligencias.

Los equipos para poder rendir de manera adecuada necesitan tener un ritmo. Las paradas y arranques, los continuos cambios de criterio, no benefician en nada a la capacidad de producción de los equipos y al proyecto e inciden en costes evitables ya que todo camino iniciado y no culminado requiere de nuevo volver al punto de origen y eso no es gratis.

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.