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.
Thursday, October 30, 2008
Análisis de mi desempeño actual en la ejecución de proyectos
¿Qué NO hago suficientemente bien? (según mi propio criterio)
1. Valoraciones.
2. Control de las tareas asignadas a los subordinados.
3. Orientación al resto de miembros del equipo de trabajo sobre las tareas a realizar.
4. Selección de las tecnologías, frameworks, metodologías, etc, a utilizar durante el proyecto.
5. Mantener visión global del proyecto.
1. Valoraciones.
2. Control de las tareas asignadas a los subordinados.
3. Orientación al resto de miembros del equipo de trabajo sobre las tareas a realizar.
4. Selección de las tecnologías, frameworks, metodologías, etc, a utilizar durante el proyecto.
5. Mantener visión global del proyecto.
Mi gestión de proyectos informáticos
Estoy muy inconforme con la manera en que se van desarrollando las cosas en lo referente a los proyectos de desarrollo de aplicaciones informáticas en los que he participado y participo. Es una actividad que me gusta, y además, es mi trabajo, así que este es el primer aspecto en el que intentaré mejorar.
Nota: Hay más cosas que quisiera mejorar, pero no están relacionadas con la informática ni mi con vida profesional, así que no aparecerán en este blog :-)
La ejecución de un proyecto es algo que no depende solamente de mí, pero creo que hay muchas cosas en las que debo mejorar. Publicaré una entrada para el análisis de cada uno de los aspectos.
Nota: Hay más cosas que quisiera mejorar, pero no están relacionadas con la informática ni mi con vida profesional, así que no aparecerán en este blog :-)
La ejecución de un proyecto es algo que no depende solamente de mí, pero creo que hay muchas cosas en las que debo mejorar. Publicaré una entrada para el análisis de cada uno de los aspectos.
¿Cómo mejorar?
Para mejorar es necesario determinar:
1. Lo que ya haces suficientemente bien.
2. Lo que NO haces suficientemente bien.
3. En cual de las cosas que NO haces suficientemente bien deseas mejorar.
Se puede hacer un autoanálisis o se puede pedir ayuda a una o varias personas. Casi siempre es una buena idea pedir el criterio de los demás e incluirlo en el autoanálisis, siempre que "los demás" sea gente cuyo criterio valores.
También es una buena idea no perder el tiempo explicando a "los demás" lo que pretendes hacer sino extraer sutilmente la información que deseas.
1. Lo que ya haces suficientemente bien.
2. Lo que NO haces suficientemente bien.
3. En cual de las cosas que NO haces suficientemente bien deseas mejorar.
Se puede hacer un autoanálisis o se puede pedir ayuda a una o varias personas. Casi siempre es una buena idea pedir el criterio de los demás e incluirlo en el autoanálisis, siempre que "los demás" sea gente cuyo criterio valores.
También es una buena idea no perder el tiempo explicando a "los demás" lo que pretendes hacer sino extraer sutilmente la información que deseas.
Subscribe to:
Posts (Atom)