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
Cross from here

5 comentarios en “Regla Básica: Pensar en el QUE HACER y no en COMO HACERLO”

  1. Grandioso!!! genial!!! completamente de acuerdo!!! es tan importante en las primeras reuniones centrarse en el proceso de producción del cliente e intentar comprender el problema, que nos desviamos del objetivo aportando soluciones, como bien dices ¡¡error!!, yo añadiría una cosa mas, realizar un acta de reunión con todos los temas tratados.

  2. Hola, es cierto, olvidé poner lo del acta, que es un paso muy importante entre reunión y reunión.

    En algunos casos usamos grabadora, es a veces intimidante, pero vale la pena tener todo grabado, sobretodo cuando se busca repasar una conversación (o confirmar si es que con el tiempo hubieron cambios de opinión que ciertos usuarios ya no recuerdan)

    Un saludo.

  3. No puedo estar más de acuerdo con tus afirmaciones Jersson.

    Cuantas veces he discutido yo por el tema COMO-QUE y ¡CUANDO!.

    Lo de la grabadora como bien dices, intimida y no todo el mundo lo acepta. Lo de las actas sin embargo, siendo burocrático, es necesario para evitar malos entendidos.
    Y otra cosa muy útil, es dibujar en pizarras (me encanta) no solo en la toma de requerimientos, sino en cualquier fase o proceso. Por cada pizarra, zás, una foto y agregar esa fotografía a la documentación o al informe.

    Lo cierto es que tu entrada Jersson, se podría haber alargado con muchísimo detalle, pero lo has resumido muy bien.

    Un saludo.

  4. Hola Jorge,
    en realidad tambien uso las fotos y pizarra en todo lo que pueda!!!
    es una buena combinación, no?

    Dependiendo de los equipos, es mas rapido el trabajo. Me ha pasado tambien, que en ciertos equipos hay un pequeño gap que cubrir. En esos casos siempre me digo “cuestión de tiempo”

    Un Saludo y Gracias por la apreciación!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *