Cada grupo de personas, cada organización, cada empresa… es un mundo. Cada lugar tiene sus reglas, la llamada cultura corporativa (Cultura organizativa, aquello que nadie te explica pero que marcará tu devenir profesional), su manera de ver las cosas, su herencia de años y años haciendo las cosas de una manera, traspasando esa manera de hacer de “padres a hijos”.
Y en toda organización siempre hay varios roles típicos: los que quieren mejorar siempre y los que ven mal cualquier cambio, que nada va a funcionar, todo está mal (la cuestión es la proporción de positivos frente negativos). Pues bien, esta breve historia va sobre estos últimos.
El otro día (quien dice el otro día dice hace meses), estaba con un grupo de personas que me invitaron para hablar de “cambio”. Vamos, para concretar, de cómo empezar a hacer las cosas de otra manera. Para concretar más, ellos le llamaban “empezar con gestión ágil” (al menos no hablaron de transformación digital), a mi mente llegaba un “dejar de hacer uso de practicas de gestión antiguas y que rara vez dan buenos resultados”.
El caso es que, hablando de unas cosas y otras, que si aquello de enfocarse más en equipos que en proyectos, que si menos requisitos cerrados antes de empezar y más empezar e ir adaptándose, que si tal y que sin cual, con estas le llegó el turno, cómo no, a la estimación.
Siempre que sale el tema de la estimación en un grupo que ha estimado siempre de la misma manera, en base a derivados del cascada, siempre…. surge algo “curioso”.
El caso es que de entre tantas cosas que hablamos sobre estimación, y la no estimación, le llegó el turno al reparto de responsabilidades, que si la gente de negocio debería decir qué hacer y en qué orden, priorización por valor, y que si aquellos que van a hacer el trabajo, que deben tener mayores conocimientos sobre lo que esto implica, deberían ser quienes estimasen… Y ahí pasó, sí, ahí se montó el lío, pasamos a hablar del si «estimar es timar, o no», y yo ahí, de oyente, asistiendo al espectáculo.
El lío se montó porque alguien de negocio dijo:
—Pero, entonces, si son los técnicos los que estiman… ¿De qué dispongo yo para fiarme de esas estimaciones? ¿Cómo sé que no me están engañando?
No veas a lo que puede derivar una frase como la anterior. ¿Qué has pesado tú al leerla?
¿”Desconfianza” entre técnicos y negocio puede ser una palabra que resuma todo?
Desconfianza, justificada o sin justificar. Desconfianza porque quizá alguien infló tiempos durante años, quizá lo hizo para vivir mejor, para cobrar de más a sus clientes. O quizá infló tiempos porque sabía que una vez que hiciera su propuesta de tiempos a negocio… se la iban a recortar hasta niveles imposibles de cumplir, que tendría que compensar todo con excesos de horas, fines de semana, etc.
No hace falta que me extienda más, sé que con lo anterior ya sabes a qué me refiero, y ya te habrán venido a la cabeza dos o tres malos recuerdos sobre situaciones similares.
Sólo una cosa. Si quieres cambiar, mejorar, llámalo ser ágil, modernizar tus prácticas de desarrollo, no quedarte atrás, etc., antes de meterte en frameworks, lo que algunos llaman metodologías, etc., resuelve los problemas de desconfianza, cómo sea, sí, cómo sea, sino… olvídate.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Yo lo primero que pienso cuando escucho eso es que tiene un problema mucho más serio: un equipo con poca implicación en los proyectos o que él no ha sabido cómo implicar.
Saludos
En mi experiencia personal Negocio estima de dos formas en funcion de sus intereses.
La primera forma seria subestimar para conseguir un trabajo o meter cabeza en un cliente importante con el consiguiente quemazon de los programadores y/o trabajando a perdidas.
La otra forma es sobreestimar para fuera y facturar mas pero subestimar para dentro. Si no llegas a los tiempos y no pasa nada es que estas en este caso.
Luego vino la moda de preguntar al programador su estimacion.
Si es menos de lo que se espera se añaden poyaques.
Si es mas se discute hasta que rebajas el tiempo o se acepta y luego en el dia a dia te van metiendo poyaques.
A mi lo que mas me agrada del tema Scrum es que alguien prioriza el backlog y se trabaja en consecuencia y ahi es donde mas problemas he visto. Para Negocio/Cliente todo es importante. Luego descubres que hay cosas que ni las necesitan. Este negocio es asi (o lo que yo he vivido)
Un saludo
Creo que esa desconfianza viene motivada por la percepción de la pérdida de poder que tienen los departamentos de negocio, que solo conocen la gestión clásica de producción directa, y donde los proyectos tienen características concretas para ser entregadas en fechas determinadas, como si fuera un producto fabricado en masa.
La naturaleza, el funcionamiento y el trabajo de los departamentos de tecnología o desarrollo, se escapan de la capacidad de compresión o de la mentalidad de estos gestores. Al no tener dominio sobre un modelo donde el número de horas trabajadas no repercute en uan producción directa, se tiende a pensar se está indefenso en manos de los técnicos, y que estos abusan con tiempos que están inflados para poder trabajar lo menos posible.
Jugar con información privilegiada siempre ha sido potestad de los estratos más altos en las organizaciones. Poseer la información, administrar a quien darla y en qué cuantía suministrarla, es algo con lo que se asientan las bases de poder. Al no disponer de esa potestad, y como dice el refrán, cree el ladrón que todos son de su condición, el gestor tiene a pensar, que si él tuviera cierta información sobre la producción, obviamente la manejaría en su beneficio sin dudarlo, entonces ¿Porqué otros en su misma situación no habrían de hacer lo mismo?
Por desgracia, con estos gestores las estimaciones se suelen considerar fechas de entrega. Pero estas pueden estar sujetas a cambios, y que deben revisarse en cada iteración de un desarrollo ágil. Por lo que no solo pueden cambiar, sino que es seguro que van a cambiar.
Para ilustrar esto con un ejemplo, yo estuve trabajando en un proyecto en el cual ya habían firmado con el cliente un contrato cerrado con todas las características del proyecto y una fecha de entrega incluso antes de contratarme para iniciar el desarrollo del proyecto, obviamente fue un proyecto muy problemático, ya que la empresa no tenía ninguna experiencia en desarrollos de software y siempre pensó que la estábamos tomando el pelo cuando con los tiempos.
Todo esto en realidad no es una consecuencia de lo explicado, sino más bien un síntoma que suele ir ligado a otras señales que identifican una mala gestión.
Un cambio viene primero de la mentalidad y de la cultura de empresa, no de los métodos. Cualquier tipo de intento de gestión ágil fracasará sino va a acompañado de un cambio del modelo mental de la producción.
El asunto de la estimación es peliagudo, en general los estimadores por «juico experto» o por herramientas fallan más que una escopeta de feria (hacia arriba y hacia abajo), eso sin necesidad de añadir intereses de Negocio para que se haga antes, del desarrollador para que se alargue el tiempo, o del Comercial para facturar más.
En mi experiencia, lo mejor es buscar una métrica objetiva no basada en opiniones («a mí me parece que esto va a ser grande»), ni en cosas que se pueden estirar o comprimir (LoC, COCOMO…).
«En mi experiencia, lo mejor es buscar una métrica objetiva no basada en opiniones»
Cuenta, cuenta, …
Hugo Becerra no podía haberlo explicado mejor.
Desde luego es un tema peliagudo y bastante común por mi experiencia, he estado en dos clientes donde se dudaba de las estimaciones de desarrollo y siempre que no se han tenido en cuenta a terminado en desastre.
También creo que las estimaciones que se realizan por todo el equipo de desarrollo son mucho mejores que las que realiza solamente el desarrollador implicado.
Sin olvidar que sin algo de «presión» no hay rendimiento.
Scrum funciona porque en el desarrollo de software no se sabe lo que uno quiere hasta que lo ves, y todo puede cambiar y mejorarse con el paso del tiempo. Si ya les cuesta estimar a los que saben cómo construir, ¿Cómo pretenden estimar los que no tienen ni idea?