Cuando desarrollamos un software a la medida, es común encontrar que el usuario (la empresa o persona) a quien se le desarrolla la aplicación, no tiene ni la más remota idea de cómo es el proceso de desarrollo de software; es más, muchos no saben ni como copiar archivos de una carpeta a otra en una PC, pero bueno, eso ya es otro tema.
Lo que yo he optado por hacer y hasta ahora me ha funcionado, es explicarles que el proceso de desarrollo de una aplicación es parecido al proceso de construcción de una casa. Primero le decimos al arquitecto lo que tenemos en mente para que el haga el plano, nos lo muestre y nosotros lo aprobemos o le indiquemos si queremos que le haga algunos cambios.
En el caso de que le hayamos indicado que haga cambios al plano, el arquitecto debe hacer un nuevo plano con los cambios y volver a mostrarnoslo para que lo aprobemos. Este proceso se repite hasta que nosotros aprobemos el plano. Es hasta que el plano (arquitectónico) está aprobado por nosotros que el arquitecto empieza a crear los demás planos que se requieren (eléctrico, hidráulico, etc.)
De igual forma, después de que el usuario nos dice que tiene en mente, lo que debemos hacer es la especificación de requisitos, que será la base para el desarrollo de la aplicación. En este documento se describe la funcionalidad que tendrá la aplicación y debe ser aprobado por el usuario. Una vez que la especificación de requisitos es aprobada por el usuario, empezamos a hacer el diagrama entidad-relación de la base de datos, etc.
El que el usuario espere ver la primer pantalla de la aplicación un dia después de que nos dijo cuáles son sus necesidades, es tanto como esperar que el arquitecto levante la primera barda inmediatamente después de que le dijimos lo que tenemos en mente, sin que haga un plano que nos muestre para que lo aprobemos, es ilógico ¿no creen?
Así como en el proceso de construcción de una casa, no le preguntamos al arquitecto a la mitad de la obra “¿en dónde va a estar ubicada la cancha de tenis?”, siendo que en el plano que nos mostró y que nosotros aprobamos no aparece ninguna cancha de tenis, está por demás explicarle al usuario que no esperamos que a la mitad del desarrollo de la aplicación nos pregunte “¿En qué menú estará la opción de facturación?”, cuando en la especificación de requisitos que le mostramos y que aprobó no se habla en ningún momento de un módulo de facturación.
Otra analogía entre el desarrollo de una aplicación y la construcción de una casa que utilizo es para hacerles entender que cuesta mas agregar funcionalidad a un módulo ya hecho que incluir dicha funcionalidad en el módulo desde un principio.
Supongamos que el arquitecto ya terminó la planta baja de nuestra casa, está construyendo la planta alta y le decimos que queremos que el medio baño de la planta baja, que está junto a la sala, ahora sea baño completo. “¿Se puede hacer esa modificación?”, probablemente si, pero desde luego costará más de lo que hubiera costado si desde que nos mostró el plano para que lo aprobaramos le hubieramos pedido esto, cuesta más porque ahora hay que instalar más tubería para que llegue agua caliente a la regadera que se instalaŕa en ese baño, y probablemente habrá que tirar algún muro para que haya espacio para la ducha en ese baño.
De igual forma, generalmente el agregar a un módulo ya hecho funcionalidad que no se contempló desde un inicio, cuesta más porque implica más trabajo. Así de simple.
En conclusión, debemos hacer entender al usuario que no debe asumir que la aplicación tendrá funcionalidad que en la especificación de requisitos no se dijo que tendría. Nada de que “yo pensé”, “es que es obvio”, y otras frases por el estilo.
Si desarrollas software a medida, te recomiendo hacer la especificación de requisitos y que el usuario la firme como aprobada antes de empezar con el desarrollo. Evitarás malos entendidos y problemas posteriores.
Y si tu eres usuario final, desconfia de la capacidad de cualquier “profesional de sistemas” que te prometa mostrarte avances de la aplicación sin antes haber hecho la especificación de requisitos y sobre todo, antes de haber construido el diagrama entidad-relación de la base de datos y demás “planos”. Es equivalente a que el arquitecto que construirá tu casa te diga que verás la primera barda sin antes haberte mostrado el plano.
Etiquetas: desarrollo de software a medida, educar al usuario final, especificación de requisitos
Lo que yo he optado por hacer y hasta ahora me ha funcionado, es explicarles que el proceso de desarrollo de una aplicación es parecido al proceso de construcción de una casa. Primero le decimos al arquitecto lo que tenemos en mente para que el haga el plano, nos lo muestre y nosotros lo aprobemos o le indiquemos si queremos que le haga algunos cambios.
En el caso de que le hayamos indicado que haga cambios al plano, el arquitecto debe hacer un nuevo plano con los cambios y volver a mostrarnoslo para que lo aprobemos. Este proceso se repite hasta que nosotros aprobemos el plano. Es hasta que el plano (arquitectónico) está aprobado por nosotros que el arquitecto empieza a crear los demás planos que se requieren (eléctrico, hidráulico, etc.)
De igual forma, después de que el usuario nos dice que tiene en mente, lo que debemos hacer es la especificación de requisitos, que será la base para el desarrollo de la aplicación. En este documento se describe la funcionalidad que tendrá la aplicación y debe ser aprobado por el usuario. Una vez que la especificación de requisitos es aprobada por el usuario, empezamos a hacer el diagrama entidad-relación de la base de datos, etc.
El que el usuario espere ver la primer pantalla de la aplicación un dia después de que nos dijo cuáles son sus necesidades, es tanto como esperar que el arquitecto levante la primera barda inmediatamente después de que le dijimos lo que tenemos en mente, sin que haga un plano que nos muestre para que lo aprobemos, es ilógico ¿no creen?
Así como en el proceso de construcción de una casa, no le preguntamos al arquitecto a la mitad de la obra “¿en dónde va a estar ubicada la cancha de tenis?”, siendo que en el plano que nos mostró y que nosotros aprobamos no aparece ninguna cancha de tenis, está por demás explicarle al usuario que no esperamos que a la mitad del desarrollo de la aplicación nos pregunte “¿En qué menú estará la opción de facturación?”, cuando en la especificación de requisitos que le mostramos y que aprobó no se habla en ningún momento de un módulo de facturación.
Otra analogía entre el desarrollo de una aplicación y la construcción de una casa que utilizo es para hacerles entender que cuesta mas agregar funcionalidad a un módulo ya hecho que incluir dicha funcionalidad en el módulo desde un principio.
Supongamos que el arquitecto ya terminó la planta baja de nuestra casa, está construyendo la planta alta y le decimos que queremos que el medio baño de la planta baja, que está junto a la sala, ahora sea baño completo. “¿Se puede hacer esa modificación?”, probablemente si, pero desde luego costará más de lo que hubiera costado si desde que nos mostró el plano para que lo aprobaramos le hubieramos pedido esto, cuesta más porque ahora hay que instalar más tubería para que llegue agua caliente a la regadera que se instalaŕa en ese baño, y probablemente habrá que tirar algún muro para que haya espacio para la ducha en ese baño.
De igual forma, generalmente el agregar a un módulo ya hecho funcionalidad que no se contempló desde un inicio, cuesta más porque implica más trabajo. Así de simple.
En conclusión, debemos hacer entender al usuario que no debe asumir que la aplicación tendrá funcionalidad que en la especificación de requisitos no se dijo que tendría. Nada de que “yo pensé”, “es que es obvio”, y otras frases por el estilo.
Si desarrollas software a medida, te recomiendo hacer la especificación de requisitos y que el usuario la firme como aprobada antes de empezar con el desarrollo. Evitarás malos entendidos y problemas posteriores.
Y si tu eres usuario final, desconfia de la capacidad de cualquier “profesional de sistemas” que te prometa mostrarte avances de la aplicación sin antes haber hecho la especificación de requisitos y sobre todo, antes de haber construido el diagrama entidad-relación de la base de datos y demás “planos”. Es equivalente a que el arquitecto que construirá tu casa te diga que verás la primera barda sin antes haberte mostrado el plano.
Etiquetas: desarrollo de software a medida, educar al usuario final, especificación de requisitos
