Archivos por Etiqueta: éxito y fracaso en los proyectos

Cómo hacer que las estimaciones digan lo que quieras

domingo, 16 febrero 2014 18:43

antoniomartel

0 Comentarios

Tu cliente te ha pedido una estimación. Tiene una idea en la cabeza y quiere saber cuánto le costará y en cuanto tiempo lo tendrá. Él ha hecho sus propios cálculos y te comenta brevemente las cifras que tiene en la cabeza.

Llegas a la oficina y te reúnes con los técnicos más expertos en este tipo de proyectos. Después de darle unas cuantas vueltas llegas a un acuerdo con ellos sobre el tiempo y la dificultad en realizar este tipo de trabajo. Has tenido que convencerlos un poco para que no sean tan precavidos, después de todo no parece un proyecto difícil.

Aún así la cifra obtenida es muy superior a lo que el cliente había previsto. Además, si esa previsión fuese cierta no podrían cumplirse las fechas en las que se necesita el proyecto terminado. Necesitarás reducir esta estimación en al menos un 50%. Aquí tienes cómo hacerlo en 5 fáciles pasos:

Ya lo has hecho antes. Ahora vas a tardar menos. Has hecho proyectos parecidos en otras ocasiones, seguro que se ha aprendido de los errores cometidos y los problemas que surgieron en otras ocasiones no tienen por qué pasar ahora (10% menos) ¿seguro que no ocurrirán otros problemas nuevos?
El cliente ha dicho que quiere algo sencillo. No será tan difícil de hacer. Podremos hacer algo básico eliminando complejidades (10% menos). El cliente conoce bien su negocio y le parece fácil pero ¿y tú? ¿tienes todo el conocimiento del negocio del cliente?
Vigilaremos mucho los costes. En otras ocasiones el proyecto no se ha supervisado correctamente pero esta vez estarás especialmente atento a cada hora empleada y no dejarás que se te vaya de las manos (10% menos)
Pondremos a los mejores técnicos. Es un proyecto relevante para un cliente importante. Habrá que asignar a los mejores técnicos para el trabajo (10% menos) aunque aún no sabes si estarán disponibles en las fechas que los necesitas.
Se hará un esfuerzo extra. Si fuese necesario y comprobásemos que no podemos cumplir con el tiempo previsto se pedirá a todos los implicados que hagan un esfuerzo adicional durante unas semanas. Si fuese necesario añadiremos incluso algún técnico adicional a mitad del proyecto para así acabar en plazos. (10% menos) Recuerda la Ley de Brooks: ‘Añadir personal a un proyecto retrasado sólo hará que se retrase aún más‘

Ya lo tenemos. Con solo un poco de trabajo hemos conseguido reducir la estimación inicial en un 50%. En realidad, para hacer que la estimación encaje en un presupuesto, nos hemos autoconvencido de que podemos hacer el trabajo en la mitad de tiempo. Lamentablemente las estadísticas muestran que los proyectos software tardan, en promedio, un 120% más del tiempo previsto inicialmente y que el costo final resulta ser un 100% más elevado que el que se calculó en la primera estimación.

Puedes ver más sobre estimaciones en:

Referencias: Estimaciones: errores comunes (Carlos Fontela)

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

El ingeniero y el puente

domingo, 12 enero 2014 21:34

antoniomartel

0 Comentarios

En el siglo V antes de Cristo cierto ingeniero romano fue designado para dirigir la construcción de un puente sobre el río Leza. El puente era importante para la zona, permitiría el paso de personas y mercancías ahorrando tiempo en recorrer largas distancias buscando un paso llano por el que cruzar el río.

El ingeniero acogió su nombramiento con entusiasmo y se lanzó a planificar y estimar todo lo que sería necesario para su construcción. Calculó con exactitud cuantos albañiles, grúas, poleas, andamios y cimbras necesitaría y pudo ver claramente que contando con 50 trabajadores podría terminar un puente como aquel en 4,7 años de trabajo.

Con los 600.000 sestercios que recibió para ejecutar este encargo se apresuró a comprar todo el material que había calculado y ordenó depositarlo a pie de obra. Reclutó los 50 albañiles que había estimado y los envió a orillas del río para empezar los trabajos cuanto antes. No había tiempo que perder, cuanto antes se comience, antes se podrá acabar.

Pronto los trabajadores le dijeron que no eran necesarias tantas poleas y grúas pero que los picos y sierras eran claramente muy pocos para el trabajo que había que hacer. No puedo hacer nada, dijo el ingeniero, ya se ha gastado la mayor parte del presupuesto y no queda gran cosa para comprar nuevo material. Tendrán que adaptarse a lo que hay.

La construcción continuó su curso haciéndose pronto evidente que todo no marchaba según lo previsto. El capataz explicó al ingeniero que la cantera de donde se traía la piedra estaba demasiado lejos y que la calzada estaba llena de baches y socavones desde la riada del pasado invierno. Se tardaba mucho en traer la piedra en carretas hasta el puente. Tendrán que hacer un esfuerzo extra, dijo el ingeniero, no hay tiempo ahora para arreglar la calzada.

El capataz también hizo saber al ingeniero que era necesario construir arcos entre los pilares del puente para reducir los materiales utilizados y, sobre todo, para mejorar la resistencia del puente. No hay tiempo ahora para florituras, dijo el ingeniero, vamos retrasados. Pondremos algo más de mortero en los pilares, con eso será suficiente.

Las noticias sobre la marcha del puente llegaban a oídos del Prefecto que desesperaba por la lentitud de las obras por lo que mandó llamar al ingeniero. El Prefecto necesitaba justificarse ante Roma y exigía que el puente estuviese acabado para las próximas fiestas saturnales. El ingeniero explicó que para conseguir tal cosa necesitaría al menos otros 50 trabajadores adicionales. Ante la presión, el Prefecto accedió y se comprometió a enviar los nuevos trabajadores en el plazo de 1 mes.

De vuelta en el puente, el ingeniero reunió a todos los trabajadores y les pidió un esfuerzo adicional para cumplir los compromisos. Los trabajadores no entendían cómo podían trabajar el doble de rápido si no tenían suficiente piedra para continuar y en cualquier caso siempre debían esperar a que el mortero secase.

Ni siquiera con los nuevos trabajadores pudo terminarse el puente a tiempo. No había herramientas para todos, la piedra seguía llegando con lentitud a la obra y los desmoronamientos eran habituales por las prisas en la construcción.

En la antigua Roma, los constructores de un puente debían colocarse debajo mientras la primera legión lo cruzaba. Es un buen aliciente para construir puentes firmes y sólidos ¿no crees?

Si te interesa saber más sobre gestión ágil de proyectos, estimaciones, ventajas y desventajas de Scrum quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

5 errores gestionando proyectos

domingo, 15 diciembre 2013 19:41

antoniomartel

0 Comentarios

Gestionando proyectos se comenten errores continuamente, yo por lo menos he cometido unos cuantos. Publico aquí sólo cinco de ellos, los más importantes o los más confesables según se mire. He metido la pata de muchas otras formas pero había que ponerle algún límite a esta entrada en el blog. Ahí van:

Primero el problema, después la solución

Ese es el orden, primero se identifica un problema y luego se le aplica una solución, no al revés: Es habitual oir hablar de una solución muy guay que luego aplicamos entusiasmados al proyecto. Haya problema previo que solucionar o no. ¿De qué sirve implantar en el trabajo diario el nuevo y sofisticado software para hacer Test Driven Development si realmente estás teniendo un problema mucho más básico con ese proyecto que te trae de cabeza?

Contar los pasos en lugar de mirar el camino

Todos sabemos que en los proyectos se suelen disparar las horas empleadas y que rara vez se cumplen los cálculos hechos en las estimaciones. Nuestra primera reacción suele ser la de supervisar cada hora registrada y hacer complejas gráficas que nos muestren lo bien o mal que vamos con respecto a la estimación pero ¿nos ayuda ésto a terminar antes el proyecto?

Si nos contratasen para llevar una carga desde el punto A hasta el punto B e hiciésemos una estimación según la cual haremos ese trabajo dando 10.000 pasos ¿en qué nos va a ayudar saber que ya hemos dado 5.000? ¿Sabemos dónde estamos o si hemos estado dando vueltas en círculo? ¿No será mejor levantar la vista, mirar cuánto hemos recorrido ya, si el camino realmente lleva a B o si hay algún modo más fácil de llegar allí?

Requisitos fantasma

En ocasiones le pedimos a los miembros del equipo de trabajo que cambien lo que ya han hecho porque ‘así no lo va a aceptar el cliente‘ o porque nosotros pensamos que el producto debe funcionar de otra manera. Nuestro compañero ya hizo una propuesta que ha costado tiempo y esfuerzo. Es mejor que la vea el cliente y dé su opinión. Él decidirá si está bien o está mal. Invertir tiempo en correcciones o mejoras no solicitadas sólo nos va a retrasar la entrega (con esto no quiero decir que no se revise lo que se ha hecho o que no se compruebe si tiene la calidad suficiente antes de mostrarlo al cliente)

Contagiar las prisas

Como jefe de proyecto suelo trabajar en varios a la vez, lo que suele implicar a varios clientes, cada uno con sus necesidades, múltiples fechas de entrega, tensión y mucho estrés. Intento no contagiar este estrés a los miembros del equipo de trabajo y aportar la tranquilidad que pueda. Por supuesto, todos los miembros del equipo deben conocer las fechas de entrega y el trabajo comprometido en cada una de ellas. Añadir prisas al trabajo diario sólo suele traer problemas en la calidad del producto final o cosas que quedan a medio resolver.

¿Puedes hacerlo más fácil?

Uno de los principales errores que se comete en un proyecto es el de comenzar cuanto antes cada tarea sin pararse a planificar los pasos a dar en esa tarea, si realmente es necesaria y, sobre todo, si puede simplificarse de algún modo. Me refiero no solo a implementarla del modo más fácil posible sino a simplificar la tarea en sí. Para ese complejo sistema de interconexión entre múltiples ordenadores ¿no existe ya algún estándar predefinido? Para ese analizador sintáctico ¿es necesario que sepa resolver ecuaciones de tercer grado? No hay tiempo mejor invertido que el utilizado para reducir la complejidad del trabajo a hacer.

Estos son los errores de los que me he dado cuenta hasta ahora. A algunos ya les he aplicado alguna solución, en otros todavía tengo que encontrarla. Seguro que me quedan aún errores nuevos por cometer. En los siguientes enlaces pueden encontrar algunas de las lecciones aprendidas de estos errores:

¿Por qué fallan los proyectos?

domingo, 25 agosto 2013 19:12

antoniomartel

0 Comentarios

Razones hay muchas, seguro que parándonos a pensar un poco se nos ocurren unas cuantas, pero hay una que no siempre es tan obvia. Las estadísticas parecen indicar que si reducimos el tamaño de nuestro proyecto podemos aumentar en un 50% su probabilidad de éxito.

Un estudio indica que los proyectos de más de 1 millón de dólares tienen un 50% más de probabilidades de fallar que los proyectos de menos de 350.000 dólares. ¿Cómo no se nos había ocurrido antes? Los proyectos pequeños son más fáciles de gestionar y ejecutar que los grandes.

En proyectos grandes con duraciones superiores a un año tendemos a establecer las reuniones, hitos y revisiones con una periodicidad mayor, mensuales, bimensuales o incluso trimestrales. No es suficiente para tomar el pulso al coste del proyecto y comprobar si se está trabajando en la línea correcta, si se entrega lo que se necesita o si nos estamos desviando mucho de lo previsto.

Por otro lado, con proyectos de duración superior a un año o incluso menos se corre el riesgo de que hacia la finalización del proyecto, los objetivos y necesidades del negocio del cliente hayan cambiado con respecto a lo que le motivó a contratarlo. Si desarrollamos una aplicación para móviles ¿el mercado será el mismo dentro de 1 año cuando queramos venderla? Si quisiéramos hacer una aplicación basada en la legislación laboral actual ¿será útil dentro de uno o dos años cuando vea la luz nuestro producto? Parece mejor ver los grandes proyectos como ‘programas de actuación’ divididos en proyectos más pequeños, en los que con cada uno de ellos se entrega una parte del resultado global.

Yo añadiría un aspecto más: los proyectos grandes suelen planificarse y presupuestarse de ese modo porque con ellos se trata de conseguir objetivos complejos. Lamentablemente, con cada orden de complejidad adicional se multiplica el tiempo necesario para resolverla.

Si nos fijamos atentamente, el mundo IT parece ir en una línea muy distinta a ésta y trata de mantener los productos a desarrollar tan simples como sea posible. Hace unos años, los productos software más populares tenían menús llenos de características, funcionalidades y opciones de configuración (recordemos cada versión de MS Office o MS Outlook) En cambio, la mayoría de los productos actuales, los que residen en la nube o en nuestros dispositivos móviles, son mucho más simples: un par de casillas de texto y un botón para aceptar ¡no hay más!

David Karp, fundador de Tumblr, dijo acerca de esto: «Every feature has some maintenance cost, and having fewer features lets us focus on the ones we care about and make sure they work very well»

Me parece un gran planteamiento ¡Cuántas funcionalidades no habré desarrollado que me parecían muy útiles inicialmente pero que nunca fueron usadas!

Fuentes: thisiswhatgoodlookslike y startupquote.

Página 2 de 2