A pesar de haber leído mucho sobre el tema e intentar hacerlo lo mejor posible, invariablemente los proyectos requieren muchos más recursos que los que valoro inicialmente.
También invariablemente, estas son las causas que he detectado:
Poca profundidad y claridad de los requerimientos iniciales. Los clientes envían un pliego técnico en el que expresan a muy grandes rasgos lo que desean. Basándose en ese documento es que se debe hacer la oferta.
La solución ideal sería "obligar" al cliente a que el documento que aporte sea más completo.
Esta solución no siempre se puede aplicar, que para eso el cliente es el cliente, y estoy seguro de que a mi empresa no le interesa perder de esos sólo porque el arquitecto se niega a hacer una valoración sin un documento de requerimientos más completo.
Por eso, una alternativa más viable sería separar mucho más tiempo, al menos 4 veces el tiempo que se reserva actualmente, para la discusión con el cliente. La mayor parte de este tiempo debería utilizarse antes de que haya más de una o dos personas en el equipo que puedan ir generando contenido inicial e ir haciendo pruebas para determinar la arquitectura final de la aplicación.
Otro aspecto importante es que la valoración debe hacerse en módulos que el cliente pueda entender. Por ejemplo, no se puede poner:
Acceso a base de datos -> 40 horas
sino que hay que adaptarse a la terminología del cliente, y poner
Módulo funcional 1 según documento -> 32 horas
aunque a la hora de implementar se genere primero la interacción con la base de datos de todos los "módulos" del cliente.
La solución obvia sería hacer una valoración interna utilizando las categorías y tareas que mejor reflejen el desarrollo real y después distribuyendo las horas entre los "módulos" del cliente. Pero, por algún motivo, este paso actúa como una lupa de gran aumento, y a todo el mundo le parece demasiado tiempo, incluso a mí mismo, y se comienzan los recortes. ERROR!! La valoración inicial es la correcta.
Debe existir una valoración interna utilizando las categorías y tareas que mejor representen el proceso real de desarrollo, y toda discusión, observación, reducción, etc, que afecte a la cantidad de horas debe hacerse sobre esta valoración. Para entregar al cliente se debe preparar un modelo más comprensible que requiera la misma cantidad de horas.
Por último, se debe reservar tiempo en la valoración para las pruebas de desarrollo que seguramente se harán, y para el "maquillaje" final de la aplicación, algo que el cliente ve como "sencillo" pero que siempre requiere un tiempo extra considerable.
No comments:
Post a Comment