Regla Básica: Pensar en el QUE HACER y no en COMO HACERLO

Este es un tema de conversación que he tenido muchas veces, claro, on algunos miembros de diferentes equipos.
Pues es alli, cuando conversamos, sobre la importacia de tomar requerimientos o de como tomarlos.

Pensar en ciertos aspectos de diseño que muchas veces nos quitan demasiado tiempo por entrar en detalle cuando todavia no es necesario hacerlo (pues nunca deja de ser necesario, solo que hay momentos para hacerlo a a detalle)

A veces, cuando converso con algunos chicos, sale el comentario que notan algo aburrido al usuario al que estan entrevistando.
El silencio llega si es que les pregunto "Qué tal la primera vez que se reunieron, de qué tipo eran tus preguntas, qué tanto ahondaste?"

Quizá demasiado, no?

Lo que sucede es que muchas veces pecamos de entusiastas, y de esa forma es que a pesar que caemos en el hecho de que no cubriremos toda la información necesaria en una sola entrevista, queremos seguir preguntando y preguntando al usuario detalles que de primera mano no vienen al asunto.

Es mas importante para el usuario, entrar a comprender las necesidades básicas que desea satisfacer.
Cierto, los requerimientos principales, funcionales del sistema.

Aunque, algunos recomiendan tener todavia, menos detalle, llamándoles "Requerimientos Macro" o simplemente "Características" (algo asi como matricular, vender, comprar, grabar).
Lamentablemente esto a veces logra confundir, asi que lo recomendable es comenzar a comprender, o al menos tomar en cuenta aquello QUE debe cumplir el proyecto, es decir el QUE del proyecto.

El problema es que, mientras vamos comprendiendo aquellas cosas QUE deben hacerse en nuestro proyecto (en este caso, nuestro sistema), vienen interrogantes que hacen nos desviemos del objetivo.
Asi es, nos preguntamos como es que vamos hacer esas cosas de las cuales, seguimos tomando nota.

Error! eso nos desenfoca demasiado del problema a resolver, en estos casos, el COMO nos cambia la dirección del problema, y mientras mas vamos ahondado en como cubrir esas duda, vamos perdiendo la hilación y el objetivo de las primeras reuniones.

Lo mismo sucede en la fase de diseño, he notado el problema en la preocupacion sobre el nombre de un método (lo cual, tambien a veces me concierne, pues sigo creyendo que el nombre de las cosas es muy importante para un correcto desenvolvimiento), que ademas de pensar en los parámetros a recibirse, hay integrantes del equipo que comienzan a hurgar en COMO hacer el método, cuando el objetivo de algunas tareas que son solo, la definición del objeto, el QUE del objeto, no el COMO cumplir con ciertas actividades.

Es gracioso, pero, la palabra clave siempre termina siendo "No Desenfoques, estamos averiguando el QUE, luego veremos el COMO", o simplemente "NO Desenfoques!!!"

Ahora, como es que vamos convirtiendo el QUE en muchos COMOs? pues iterando. o no?

Saludos[at]Cama