archivo

Archivos diarios: abril 22, 2011

La metodología de desarrollo, la arquitectura del software, la selección de un buen equipo de trabajo, la existencia de unos plazos y presupuestos razonables, todo eso influye en gran medida en que un proyecto de desarrollo de software salga de la mejor manera posible (nunca conseguirá la perfección y es un error buscarla).

Sin embargo el factor que desequilibra la balanza son los usuarios encargados de realizar la definición del sistema. Si sus responsables no les permiten dedicar tiempo suficiente o no les hacen ver la importancia que tiene su participación en el proyecto (si es que no se dan cuenta por ellos mismos) nos encontraremos con el caso de que muchas funcionalidades no estarán definidas de manera adecuada y tampoco la forma en que el usuario interactúa con ellas.

A lo anterior hay que sumarle un factor que se produce en muchas ocasiones cuando el usuario está obligado a participar pero no entiende su rol en el proyecto (como muchos de ellos piensan: “esto es cosa de los informáticos”) y es que tampoco se sienten implicados con las decisiones que toman, lo que hará que errores propios lo trasladen al equipo de desarrollo y que no defiendan ante sus compañeros y organización determinadas decisiones adoptadas.

Otro aspecto de interés es la selección de los usuarios por parte del cliente. Supongamos que se seleccionan usuarios que están comprometidos en el proyecto y se les permite dedicar el tiempo necesario. Si todo ha ido bien en el proceso de desarrollo, tendremos un producto de calidad razonable en producción, pero, ¿estaban todos los que tienen que estar?

Me explico: Muchas organizaciones tienen sedes que en diversas zonas geográficas, incluso algunas de ellas fuera del país donde está la sede central.

Cuando se desarrolla un producto horizontal para la misma, el resultado del producto final puede afectar prácticamente a todas las sedes. Si antes del nuevo sistema, cada una de ellas utilizaba soluciones particulares para cubrir informáticamente el área o áreas de negocio que ahora contempla el nuevo sistema es posible que exista un rechazo por el nuevo producto, si este no ha tenido en cuenta necesidades que el anterior sí tenía implementadas.

Si se produce esta situación, el rechazo puede poner en peligro la viabilidad del sistema (que no se use o se utilice en paralelo con la solución antigua o basadas en productos ofimáticos), puede tener impacto en la productividad de los departamentos que utilicen la herramienta y también se verá afectada la calidad del dato, al querer en muchos casos suplir carencias de la aplicación con la grabación de datos en secciones donde no deben ir o simplemente dejando de grabar otros que resultan de interés.

La sede central de la organización debe imponer el uso de la nueva solución si no quiere que quede en desuso y establecer unos estándares de calidad respecto a los datos y documentos que se incluyen en la misma. Esto permitirá que con el tiempo y si se establece un control de la utilización que se hace de la herramienta la situación se normalice (lo hará antes si se tienen en cuenta las demandas de los usuarios de los otros centros que estén orientadas a la mejora del sistema).

Todo este problema se hubiera reducido de manera considerable si de entrada se hubiera contado con la participación de usuarios de otros centros (no será posible, salvo que sean muy pocas sedes que todas estén representadas) ya sea para el día a día de la definición del proyecto o para recibir su opinión de las decisiones que se han ido adoptando.

Un desarrollo iterativo incremental no asegura que si en un proyecto de desarrollo de software se produce alguno de los problemas descritos el sistema no vaya a ser impactado. Lo será, pero el efecto será menor que con metodologías donde el producto se entregue prácticamente completo y mucho después de haberse definido las funcionalidades.