Desarrollando "in situ" (II)
Uno de los aspectos negativos de trabajar en casa del cliente, es que este, al final, te toma como un empleado más, y si es una empresa poco (o nada) organizada, tu trabajo se ve afectado. Y eso en el desarrollo de software todos sabemos que significa, poca calidad, muchos errores. Por eso, hay que tener mucha "mano izquierda" para saber en todo momento como "capear" al cliente para "marcarle" los límites, que no se olvide que eres un profesional que le está haciendo un trabajo, con la particularidad que se lo haces en sus instalaciones. La gestión del tiempo es primordial, porque como te tienen "a mano", continuamente te están interrumpiendo, por ello, se deben marcar unas pautas para tener reuniones en las que tratar los temas de situación del desarrollo, quejas de los usuarios, nuevas necesidades, etc...
En el mayorista de informática para el que trabajé (ver artículo anterior), utilizábamos un método, creo que bueno, para mantener la comunicación con los usuarios y con los jefes sin que tuvieran que interrumpir el trabajo. Se utilizaba el Outlook contra un servidor Exchange para mantener una lista de tareas de desarrollo, separada por catergorías en las que se indicaba si era un error, si era una cosa nueva, la prioridad, etc...
A los usuarios les instruimos para que si encontraban un problema, hicieran una captura de pantalla (con el mensaje de error o con la pantalla donde estaba el problema) y lo enviaran junto con una explicación a una lista de correo donde lo recibíamos los desarrolladores, el responsable la gente de pruebas y los jefes, para que todo el mundo estuviera enterado. A muchos de esos mensajes se les respondía indicándo que se tomaba nota del error y se añadía a la lista, y a otros con la solución o explicación del problema.
Funcionar así fue muy bueno para todos, sobre todo por el asincronismo que proporciona el correo electrónico y el utilizar unas listas de tareas, cada implicado podía hacer su trabajo sin necesidad que los otros estuvieran presentes. Muchos de los que leais esto pensareis: "Vaya chorrada, así es como se trabaja en muchos proyectos!!!", pues aunque sea tan evidente, se de muchas empresas de "desarrollo" que no utilizan nada de esto, que funcionan a base de reuniones, de horas y horas de aislamiento. Lo que proporcionaba este sistema era un flujo de comunicación permanente con los usuarios, de esta forma ellos no se sentían "solos" y nosotros conocíamos los problemas reales.
Hoy en día, seguramente, montaría en el cliente algo como el bugzilla o como el FogBUGZ para mantener la base de errores, mejoras, comentarios, etc... Esto permite al cliente (al personal del cliente) formar parte del equipo de desarrollo de su propia solución, y eso es bueno, muy bueno.
Continuará ...
En el mayorista de informática para el que trabajé (ver artículo anterior), utilizábamos un método, creo que bueno, para mantener la comunicación con los usuarios y con los jefes sin que tuvieran que interrumpir el trabajo. Se utilizaba el Outlook contra un servidor Exchange para mantener una lista de tareas de desarrollo, separada por catergorías en las que se indicaba si era un error, si era una cosa nueva, la prioridad, etc...
A los usuarios les instruimos para que si encontraban un problema, hicieran una captura de pantalla (con el mensaje de error o con la pantalla donde estaba el problema) y lo enviaran junto con una explicación a una lista de correo donde lo recibíamos los desarrolladores, el responsable la gente de pruebas y los jefes, para que todo el mundo estuviera enterado. A muchos de esos mensajes se les respondía indicándo que se tomaba nota del error y se añadía a la lista, y a otros con la solución o explicación del problema.
Funcionar así fue muy bueno para todos, sobre todo por el asincronismo que proporciona el correo electrónico y el utilizar unas listas de tareas, cada implicado podía hacer su trabajo sin necesidad que los otros estuvieran presentes. Muchos de los que leais esto pensareis: "Vaya chorrada, así es como se trabaja en muchos proyectos!!!", pues aunque sea tan evidente, se de muchas empresas de "desarrollo" que no utilizan nada de esto, que funcionan a base de reuniones, de horas y horas de aislamiento. Lo que proporcionaba este sistema era un flujo de comunicación permanente con los usuarios, de esta forma ellos no se sentían "solos" y nosotros conocíamos los problemas reales.
Hoy en día, seguramente, montaría en el cliente algo como el bugzilla o como el FogBUGZ para mantener la base de errores, mejoras, comentarios, etc... Esto permite al cliente (al personal del cliente) formar parte del equipo de desarrollo de su propia solución, y eso es bueno, muy bueno.
Continuará ...
1 comentario
abel -