Desarrollando el problema con la metodología de Sistemas Blandos y estableciendo las relaciones entre los actores involucrados, proponemos el siguiente "Manual de Buenas Prácticas" que debe considerar todo Ingeniero Civil o Ejecución en Informático que se desenvuelva en la toma de requisitos en su lugar de trabajo.
1.- Siempre tener presente que la captura de requisitos es la etapa básica en el desarrollo de un proyecto, errores en ella pueden llevas a extensión en los plazos e incluso a cancelación del proyecto.
2.- Siempre escuchar al usuario, jamás imaginarse las soluciones o implementaciones mientras se conversa con el cliente.
3.- Hablar con el usuario en el idioma del negocio (si es necesario aprenderlo) y el idioma del cliente, evitar el uso de tecnicismos propios de los ingenieros.
4.- Evitar la confrontación con el clientes, "él siempre tiene la razón" dentro de los límites de aplicabilidad del proyecto.
5.- Documentar cada uno de los acuerdos que se logren en las reuniones con el cliente, ello permitirá tener respaldo sobre todo lo que el cliente pidió durante el proceso de captura.
6.- Considerando el punto anterior, ser capaz de visualizar el negocio más alla de lo que el cliente explique de él, muchos proyectos fracasan por la incapacidad del Ingeniero de visualizar los posibles problemas que puede presentar el proyecto.
7.- Si tus primeras experiencias capturando requisitos no son alentadoras, no decaigas, el aprendizaje y la experiencia hacen el mejor trabajo construyendo un buen capturado de requerimientos.
Esta es la v1.0 de nuestro Manual de las Buena Prácticas para un Ingeniero que se está iniciando en el mundo del desarrollo de proyectos informáticos.
lunes, 12 de noviembre de 2007
Manual de Buenas Prácticas
Suscribirse a:
Enviar comentarios (Atom)
4 comentarios:
Buen manual, pero discrepo en el punto 2: "Siempre escuchar al usuario, jamás imaginarse las soluciones o implementaciones mientras se conversa con el cliente", debido a que concuerdo con ustedes en que se debe escuchar al cliente, pero SI se debe imaginar solucins o implementaciones a lo que propone el cliente,debido a que se plasmar inmediatamente como solucionaria alguna vicisitud y si esta soluciona las necesidades requeridas por el cliente. Además, por lo que he leido no han considerado el hecho de que existen clientes que no conocen muy bien el proceso de negocio, como lo harian en este caso?. Otra cosa muy importante, en el proceso actual existe un problema que muchas veces la toma de requerimientos no se lleva a cabo en los plazos establecidos, como solucionan esto?. Creo que para disminuir iteraciones innecesarias es bueno que el ingeniero conosca bien el proceso de negocio y lleve propuesta al cliente, de este modo el dira si le gustan o no, y en el caso que no le gusten se corrigen de inmediato
Buen manual.
Discrepo de la opinión de patricio y los apoyo a ustedes.
Ustedes dicen : "Siempre escuchar al usuario, jamás imaginarse las soluciones o implementaciones mientras se conversa con el cliente."
Eso es muy importante ya que no llegar con una idea preconcebida es fundamental, ya que limita otros aspectos planteados por el usuario.
Al tener un predialogal establecido, la solución tendrá altas probabilidades de de coincidir mayormente con dicho predialogal, dejando fuera aspectos nuevos que porponga el usuario, debido a que la mente del ingeniero inconcientemente hará coincidir la problemática del cliente con la idea preconcebida.
Siempre es bueno escuchar al cliente desde cero, siempre existen nuevos aportes o requerimientos que sean necesarios.
Saludos
Hola patricio, es cierto que los clientes muchas veces no conocen bien el negocio, pero finalmente son los que deciden sobre un sistema y generalmente es lo contrario "lo conocen" o al menos creen conocerlo.
El punto 2 indica que muchas veces como Ingenieros (incluso como personas) no escuchamos. Recuerda cuando se propone algún laboratorio en la Universidad, lo priero que haces mientras lo explican es empezar a imaginarte soluciones, lo que te lleva a perder detalles importantes de la explicación sobre la tarea. En el mundo del trabajo es similar, eso es lo que concluimos a través de las entrevistas que realizamos.
El proceso de toma de requerimientos lleva tiempo, generalmente el Ingeniero tiene que reunirse varias veces con el cliente y para conocer el negocio utilizar técnicas de Ingenieria de Software.
Este Manual va enfocado a ¿cómo? establecer esa comunicación con el cliente, dar el primer paso siempre es es lo más díficil y es en lo que queremos aportar.
Gracias por postear.
Al igual que el grupo 2, me parece un buen manual. Creo que es fundamental establecer una buena comunicación con el cliente, es este sentido, al parecer, estamos todo de acuerdo, no sirve mucho saber tecnicismos sino sabemos comunicarnos .
Publicar un comentario