A pesar de las barreras idiomáticas que el video impone para nosotros, podemos darnos cuenta observando las imágenes que éste proceso de captura de requerimiento es muy tradicional.
Dos personas se entrevistan con un cliente y obtienen los requerimientos, luego estos ingenieros informáticos (supuestamente), llegan e interactúan con su equipo de trabajo. Lo que se puede deducir de esto, es que cualquier solución que emerja de los diseñadores, será una solución originada sin una participación presencial activa del cliente en dicha interacción.
La solución no nace en el cerebro del o los diseñadores, sino nace en la interacción de los diseñadores con el cliente. Ésta es una buena práctica que queremos potenciar.
Sin embargo, no siempre debido a las diferentes naturalezas del negocio, las empresas, las magnitudes del proyecto o el marco tecnológico existente, esta práctica podría ser inaplicable.
Uno de los principales inconveniente es justamente requerir de la disposición del cliente a involucrarse en trabajos o actividades que no son propias de su trabajo para que los ingenieros puedan desarrollar mejor el suyo. Se necesitaría una mentalidad abierta para que los clientes aceptaran involucrar su tiempo en una interacción así, dejando la comodidad del sillón de la sala de reuniones que tradicionalmente utiliza.
Sabiendo éstas dificultades, aún queremos establecerlo cómo una buena práctica siempre y cuándo las condiciones de entorno lo permitan, ya que una buena captura de requerimientos bien realizada disminuye los errores consecuentemente los retrasos en el desarrollo de un software.
¿Qué es más conveniente, que el cliente pierda algunas horas por cada día de interacción o que pierda meses de atrasos por tener que rehacer módulos o funciones debido a fallas en la captura de requisitos?
0 comentarios:
Publicar un comentario