El dolor de cabeza para todos los que sufrimos ese gran momento en que “alguien” te viene y te dice:
“pues valoramelo” y “valoramelo hecho así y hecho de la otra manera”
1 – SOYS UNOS TOCACOJONES, que valorar no son 5 minutos!!!!!!!!
Dicho esto, ya me he desahogado, hablaremos de las valoraciones de proyectos.
Lo que muchos hacen por exceso de confianza es al recibir la petición, ponerse a pensar cuanto tardarían mas o menos en hacerlo. Y dicen una cifra, 100% erronea por varios motivos:
- la mayoria de las veces no sabes exactamente que quieren hacer. Te imaginas lo que quieren, pero de lo que te imaginas, de lo que te han dicho y de lo que realmente necesitan hay un abismo.
- necesitas tiempo. Una vez sabes lo que quieren, necesitas saber como implementar la solución global, troceándola en soluciones más pequeñas, que estudiarás y valorarás una a una.
- somos demasiado optimistas. Confiamos que todo irá bien y que lo tendremos en un ratillo de nada. Y como todos sabemos, las buenas soluciones requieren su tiempo (ver post y comentario de manuel anterior) y hay ese factor imprevistos que solemos olvidar.
Hay muchas metodologías para hacer valoraciones, dividiendo por tareas, grados de dificultad, factores de error… etc. Muchas que ni conozco. Supongo que depende que estés valorando quizás sea mejor valorar de una manera u otra.
Para el desarrollo web que es donde yo me muevo, yo lo hacía de una manera bastante simple. Del analisis que hacía dividía todo en tareas lo suficientemente pequeñas (sin pasarse) y así valorarlas pensando en lo que creía que iba a tardar más o menos. Casi nunca ponía tareas de 15 minutos y no miraba los minutos, nada de 50 minutos, o 45 min o 1 hora.
Esta sumao me daba el total de horas sin contratiempos, sin bloqueos… vamos super optimista todo, muy bonito pero irreal. Siempre hay algo que no tenias previsto, algo que se te cruza…
Pues sencillamente, al acabar le aplicaba mi factor de error. Todos tenemos un factor de error haciendo las valoraciones. Lo ideal es que sea factor 1 o inferior, pero suele ser al revés. Es un dato que varia según tu experiencia, según el conocimiento del proyecto y que hay que actualizar al acabar el proyecto, momento que sabes el desfase real.
Yo empecé a hacerlo con un factor 2, pero viendo que me sobraban horas fui bajando a un 1,5 que me iba bastante bien.
Ex: Si valoraba una tarea en 10 horas, le ponía que tardaría 15 horas.
Ahora valoran otros y a pesar de que no paro de repetir “sed realistas”… hay cada desfase que sinceramente no sé como lo justifican… 
Una valoración no realista no sirve para nada.
Posts relacionados:
Doncs mira jo tinc un projecte al cap per el qual tinc calculat 1 any per tenir alguna cosa realment operativa.
Pero com que encara no he fet mes que esbosos sobre paper de l’estructura dels diferents fitxers, ja fa mes de 3 anys que dura!
Es desilusionante mirar lejos como objetivo. Solo pensar que hay un año de faena hecha para atrás. Proponte objetivos alcansables facilmente en el tiempo. Tu mente lo agradecera.
Y, un poquito cada día hace milagros.
Planificar y valorar el trabajo, es de las partes más sensibles y complejas de cualquier proyecto.
De entrada, cada proyecto es distinto, distintos requisitos y distintas arquitecturas… por lo que no se puede generalizar alegremente.
Luego entran en juego factores ingobernables, como el factor humano o lo claro que estén los requisitos.
La experiencia, en este caso, es al final la mejor consejera y la que nos hace dar aproximaciones válidas.
Lo malo, es que como en este país no existe una cultura informática, hasta ahora las cosas se planifican tal y como se hacen procesos industriales… es decir, si en hacer una ventana tardo 4h, en hacer 100, tardo 400h, y si las hacen 10 personas, son 40h…
Lamentablemente, en Informática las cosas no son así de simples, por lo que es habitual ver cómo proyectos mal planificados y mal cuantificados, acaban volviéndose enormes ogros de 10 cabezas que devoran tiempos y recursos…
Una vez, a un gurú que nos dio un curso, un jefe de proyecto (por llamarle algo) le preguntó… ‘¿y tú cómo planificas?’…. y este hombre, con mucha calma le dijo… ‘yo no planifico… lo que hago es propornerle al cliente el hacerle una auditoría a precio pactado, para saber exactamente qué es lo que necesita y a posteriori, poder ofrecerle una planificación real… si la acepta, le descuento del precio final del desarrollo el precio de la auditoría… y si no, pues ya tiene algo con lo que buscar mejor quién le de una solución’
Claro, esto, dicho en una empresa donde los proyectos se planificaban al estilo… ‘¿cuántas pantallas tiene? ¿qué tecnología es?, pues X pantallas web de JAVA, a Y horas por pantalla… son X*Y en total’… pues les sentó bastante mal, porque esperaban algún tipo de fórmula mágina.
Genial tu visión y ejemplos
Y el de la auditoria me ha encantado 
Desde aquí brindo una cerveza por ese chaval.
Y por curiosidad ya que por desgracia nunca he visto auditorias, ni he participado en proyectos bien llevados, ni sé lo que se hace realmente en esos casos… que le entregas al final? El técnico del proyecto que quieren hacer? El funcional? O es un estudio para saber que necesitan realmente, que en base a esto se haría después el funcional y el técnico?
Pues lo que debería de entregarse en la Auditoría debería ser un resumen de la funcionalidad a implementar, y de las necesidades reales de la empresa, así como posibles aspectos que podrían resultar interesante para la empresa.
Por ejemplo… una empresa dedicada al negocio de la madera, actualmente recibe todos sus pedidos por FAX y teléfono, se recogen en un bloc a mano y luego se apilan hasta que alguien los baja al taller para preparar los pedidos. En el taller el responsable los recoge y los reparte entre los curritos, que una vez finalizados los dejan en la zona de entrega y le dan la hoja de pedido a un administrativo que prepara las órdenes de repartos…
La auditoría debería de recoger los aspectos funcionales más importantes (entrada de pedidos, validación y tramitación, comunicación al taller, reparto tareas y preparación de albaranes de entrega). Se haría hincapie sobre cuáles son las necesidades de la empresa, qué procesos se podrían automatizar y simplificar (p.e. tomar los pedidos sobre un aplicativo que automáticamente pasara la orden al taller) y un esbozo de una posible solución técnica.
Y como añadido, se podría indicar que se podría habilitar un aplicativo web para que los clientes hicieran los pedidos vía web, y que se podría implementar una solución para gestionar los repartos y el cálculo de las rutas de reparto más eficientes.
Aunque sinceramente no veo manera que de una auditoría se pueda hacer una valoración bastante exacta de un proyecto a realizar sin pasar por un estudio técnico de la solución a realizar.
Aunque está claro que te permite saber realmente lo que necesita el cliente y no encontrarte sorpresas posteriormente.
Aunque me ha gustado esa estratégia de intentar hacer las cosas bien.