¿Te suena lo de {tenemos que entrar en este cliente como sea} ? - Parte II
[ver Parte 1]
En la primera parte de este post comentábamos los problemas que provoca llevar proyectos siguiendo dos directrices que tanto estamos acostumbrados a escuchar:
...¿o deberíamos llamarles anti-directrices? También analizamos los beneficios de realizar un proyecto que no se vea condicionado por estos puntos.
En esta segunda parte daremos algunas pistas sobre cómo eliminar esta forma de pensar.
La formación por sí sola no propiciará el cambio, pero el participar en un proyecto en el que la mejora en los resultados esté asociada con cambios en determinadas partes de la gestión hará que quienes participen en el proyecto difundan qué se ha hecho para mejorar, y querrán que el siguiente proyecto en el que participen se lleve de igual manera.
La mejora en los resultados no quiere decir que el proyecto tendrá mayores beneficios, sino que tendrá los beneficios acordados desde un inicio, positivos o negativos, las personas que participan en el proyecto y los interesados en él estarán más tranquilos durante la vida del proyecto y el producto final tendrá mejor calidad, traduciéndose en satisfacción del equipo de desarrollo y del cliente.
¿Que en qué hay que formarse? - En habilidades de comunicación, gestión del tiempo y motivación más que nada. También se puede estudiar sobre planificación de proyectos, pero el problema del que hablamos no es de planificación de proyectos, sino de habilidades.
No es recomendable intentar aplicarlo en todos los proyectos a la vez si al menos un integrante del equipo de cada proyecto no ha participado en algún proyecto en el que la comunicación sea fluida, no se oculte información relevante para la planificación del proyecto y no se integre al equipo de desarrollo en la toma de decisiones de planificación o de resolución de problemas. Lo ideal es comenzar con un proyecto y trasladar la experiencia al resto de proyectos.
Analizar los resultados al final de cada ciclo de desarrollo hará que el siguiente ciclo de desarrollo vaya mejor, ya que en caso de retrasos se podrán determinar las causas y cómo resolverlas. Las retrospectivas tienen una utilidad inmensa en la mejora continua.
Una última recomendación, muy importante, es que al firmar un proyecto sobre una planificación estimada, todas las partes tienen que tener muy claro que la planificación puede variar una vez que se realice un análisis en profundidad de cada parte del proyecto. Deberá quedar pactado desde un inicio como será negociada esa variación de la planificación, si sobre presupuesto o sobre funcionalidades.
¿Dudas que esto puede resolver el problema de “tenemos que terminarlo como sea”? Pruébalo y nos cuentas tu experiencia.
¿No quieres probarlo porque estás seguro/a de que no funcionará? Eso es porque conoces otra forma de resolver el problema. Cuéntanosla.
Tampoco esperes que todos los clientes sean tan receptivos como para aceptar que un retraso es por causas que van más allá de tu voluntad o que quien vende los proyectos acepte que se termine fuera del tiempo que él o ella vendieron, a pesar de haberles dado desde el principio una estimación más realista.
El arma más potente para todo esto es la información. Si desde el principio se comunica a las partes interesadas en la empresa sobre la estimación obtenida por de un análisis preliminar y no por un proceso de adivinación, al final del proyecto no se podrá decir que no lo había sido advertido, a pesar de lo que se le haya escrito al cliente en la oferta. Que no queden en el aire esas palabras que tanto has dicho “no lo terminamos en ese tiempo ni de coña”. Envíalas por correo electrónico, comunícalas, publícalas.
Por más que se reduzcan las estimaciones en tiempo, el desarrollo tardará lo que tiene que tardar; si tarda mucho menos de lo estimado habrá que analizar las causas al igual que si tarda mucho más de lo estimado, así la siguiente vez se podrá realizar una estimación más acertada.
Comunicar a tiempo permite corregir a tiempo.
Todavía me considero programador a pesar de no haber programado casi nada desde hace un tiempo – y no es un sentimiento que sólo tengo yo, sino que más de un gestor de proyectos me ha expresado lo mismo – porque a pesar de mi tarea ahora es gestionar los proyectos, estuve pegándome con el código durante más de diez años y pasé por todas las etapas de la vida de un programador.
Hoy entiendo que una parte muy importante de una empresa que se dedica a vender software son las personas que programan y que por muy bien (o muy mal) que se gestione un proyecto, sin esas personas no hay qué vender. Y otra parte también muy importante son los clientes, que contratan los proyectos, los usan y difunden lo bien o lo mal que funcionan. Cada día vuelvo a intentar poner en sintonía al equipo de desarrollo y al cliente e intento que manejen la misma información; esa acción es el lubricante para el engranaje de nuestra empresa. No queremos que se pare ¿no?, pues desecha los malos hábitos. Manos a la obra.
En la primera parte de este post comentábamos los problemas que provoca llevar proyectos siguiendo dos directrices que tanto estamos acostumbrados a escuchar:
- Vender el proyecto a cualquier precio
- Terminar el proyecto a cualquier precio
...¿o deberíamos llamarles anti-directrices? También analizamos los beneficios de realizar un proyecto que no se vea condicionado por estos puntos.
En esta segunda parte daremos algunas pistas sobre cómo eliminar esta forma de pensar.
Cómo eliminar el problema de forma poco traumática
Teniendo en cuenta que esas dos son ideas del pasado, es claro que eliminar estos puntos pasa por formar a todas las personas que intervienen en un proyecto, desde la venta hasta el desarrollo.La formación por sí sola no propiciará el cambio, pero el participar en un proyecto en el que la mejora en los resultados esté asociada con cambios en determinadas partes de la gestión hará que quienes participen en el proyecto difundan qué se ha hecho para mejorar, y querrán que el siguiente proyecto en el que participen se lleve de igual manera.
La mejora en los resultados no quiere decir que el proyecto tendrá mayores beneficios, sino que tendrá los beneficios acordados desde un inicio, positivos o negativos, las personas que participan en el proyecto y los interesados en él estarán más tranquilos durante la vida del proyecto y el producto final tendrá mejor calidad, traduciéndose en satisfacción del equipo de desarrollo y del cliente.
¿Que en qué hay que formarse? - En habilidades de comunicación, gestión del tiempo y motivación más que nada. También se puede estudiar sobre planificación de proyectos, pero el problema del que hablamos no es de planificación de proyectos, sino de habilidades.
No es recomendable intentar aplicarlo en todos los proyectos a la vez si al menos un integrante del equipo de cada proyecto no ha participado en algún proyecto en el que la comunicación sea fluida, no se oculte información relevante para la planificación del proyecto y no se integre al equipo de desarrollo en la toma de decisiones de planificación o de resolución de problemas. Lo ideal es comenzar con un proyecto y trasladar la experiencia al resto de proyectos.
Analizar los resultados al final de cada ciclo de desarrollo hará que el siguiente ciclo de desarrollo vaya mejor, ya que en caso de retrasos se podrán determinar las causas y cómo resolverlas. Las retrospectivas tienen una utilidad inmensa en la mejora continua.
Una última recomendación, muy importante, es que al firmar un proyecto sobre una planificación estimada, todas las partes tienen que tener muy claro que la planificación puede variar una vez que se realice un análisis en profundidad de cada parte del proyecto. Deberá quedar pactado desde un inicio como será negociada esa variación de la planificación, si sobre presupuesto o sobre funcionalidades.
Cuál es el siguiente paso
Estudiar y aplicar. No hay más.¿Dudas que esto puede resolver el problema de “tenemos que terminarlo como sea”? Pruébalo y nos cuentas tu experiencia.
¿No quieres probarlo porque estás seguro/a de que no funcionará? Eso es porque conoces otra forma de resolver el problema. Cuéntanosla.
Tampoco esperes que todos los clientes sean tan receptivos como para aceptar que un retraso es por causas que van más allá de tu voluntad o que quien vende los proyectos acepte que se termine fuera del tiempo que él o ella vendieron, a pesar de haberles dado desde el principio una estimación más realista.
El arma más potente para todo esto es la información. Si desde el principio se comunica a las partes interesadas en la empresa sobre la estimación obtenida por de un análisis preliminar y no por un proceso de adivinación, al final del proyecto no se podrá decir que no lo había sido advertido, a pesar de lo que se le haya escrito al cliente en la oferta. Que no queden en el aire esas palabras que tanto has dicho “no lo terminamos en ese tiempo ni de coña”. Envíalas por correo electrónico, comunícalas, publícalas.
Conclusiones
Por más que se oculten los problemas siempre van a salir a relucir, si no el problema mismo, sus consecuencias: retrasos, errores, personas incómodas, prisas, pérdida de rendimiento y de confianza en la empresa.Por más que se reduzcan las estimaciones en tiempo, el desarrollo tardará lo que tiene que tardar; si tarda mucho menos de lo estimado habrá que analizar las causas al igual que si tarda mucho más de lo estimado, así la siguiente vez se podrá realizar una estimación más acertada.
Comunicar a tiempo permite corregir a tiempo.
Post Data: Todavía me considero programador
Hoy entiendo que una parte muy importante de una empresa que se dedica a vender software son las personas que programan y que por muy bien (o muy mal) que se gestione un proyecto, sin esas personas no hay qué vender. Y otra parte también muy importante son los clientes, que contratan los proyectos, los usan y difunden lo bien o lo mal que funcionan. Cada día vuelvo a intentar poner en sintonía al equipo de desarrollo y al cliente e intento que manejen la misma información; esa acción es el lubricante para el engranaje de nuestra empresa. No queremos que se pare ¿no?, pues desecha los malos hábitos. Manos a la obra.
Material de lectura recomendado
Post a Comment: