archivo

Archivos diarios: abril 14, 2012

Existen reglas en la organización en la que estamos trabajando y tenemos que cumplirlas, otra cosa es que se abra un debate interno sobre la necesidad de relajar ciertos aspectos que se controlan en los procesos y que dificultan un desarrollo ágil de los proyectos sin que exista un beneficio evidente en unos procesos tan rígidos.

Si ese debate interno no existe, se debería iniciar, siempre con un máximo respeto ante las personas que se encargan de supervisar el cumplimiento de los procesos y que también son los encargados de su actualización.

Con respeto se pueden cambiar las cosas, sin respeto tal vez también se consiga pero se abrirán brechas que tardarán mucho en cicatrizar y que afectará la relación entre personas, lo que a su vez impactará en los proyectos.

Dentro de esas reglas, se encuentran las relacionadas con la documentación de los proyectos. Por muy rígidas que sean siempre tendremos nuestro margen de maniobra en la revisión del contenido del documento, en aspectos formales o en el continente tengamos poco que hacer ya que probablemente sea revisado por terceros en base a una serie de reglas definidas. Mi consejo es que valores realmente si el contenido cumple el propósito que se pretende con él y no pierdas el tiempo en revisar aspectos formales adicionales a los definidos en las reglas (yo he hecho eso y es un error, ya que no aporta nada y supone un esfuerzo extra tanto para ti como para el desarrollador).

De por sí podemos hacer una fiesta si el cliente o el área usuaria nombra un responsable funcional o un dueño de producto y éste asume su rol en el proyecto y no hace lo que la mayoría: ser alguien que actúa de manera reactiva, que solo asiste a reuniones (en la mayoría con desgana y sin hacer sus deberes), para el que el proyecto es algo secundario (en el mejor de los casos) y que no se quiere responsabilizar de nada.

Asumir su rol es entender también que actúa como representante de todo el área usuaria por ese motivo las decisiones que tome no se deben centrar en la visión que tenga sobre el proceso o procesos que se quieren informatizar sino que también debe tener en cuenta otras visiones ya que lo mismo su visión de los procesos es muy sesgada o demasiado idílica.

Esa estrategia debería aplicarla en todos los casos, si bien cobra especial relevancia cuando buena parte de esos procesos no se ejecutan en la sede central de la organización sino en sus delegaciones. En las mismas siempre existe un gran recelo de todo lo que viene desde la sede central porque tienen la sensación (fundada en muchos casos) de que no se les tiene en cuenta para nada, lo que dificultará la implantación del producto, algo que todavía se agrava más si la ejecución informática del proceso no se ajusta a la realidad de su trabajo.

Llevar a cabo esta misión supondrá un esfuerzo y desgaste importante para el responsable funcional pero debe hacerlo y tiene que encargarse de proporcionar una visión común al equipo de desarrollo.

No hay agilidad sin intención.

Una actitud ágil requiere intención.

Nos podemos equivocar, claro que sí, de hecho nos equivocaremos, más pronto que tarde, pero que sea resultado de decisiones que tenían como objetivo solucionar problemas de manera eficiente.

La agilidad no consiste en estar continuamente apagando fuegos, la agilidad es adaptarse al cambio, adaptarse a las circunstancias precisamente para no tener que estar actuando siempre con actitud cortoplacista, sino con la visión de intentar desarrollar un sistema de información que satisfaga las expectativas del usuario y eso no se hace rascando continuamente sobre la superficie sino atacando los problemas de fondo que existen.

Podemos invertir todo el esfuerzo del mundo en intentar que los usuarios puedan entender cómo se van a materializar las especificaciones que nos están indicando, sin embargo realmente no van a saber si el resultado satisface sus expectativas hasta que utilicen el software.

Esta circunstancia es otra característica más que apoya el enfoque iterativo e incremental en el desarrollo de software.

Hay una cita de Ben Schneiderman que resulta muy ilustrativa: “Una imagen vale más que mil palabras. Un interfaz vale más que mil imágenes”.