archivo

Archivo de la etiqueta: toma de decisiones

Lo que a corto plazo puede ser una buena decisión, es posible que no lo sea a nivel estratégico, a más largo plazo. También puede ser al revés, es decir, que olvidar el corto plazo sea un error, sobre todo si hay aspectos que es necesario abordar en breve y que puedan tener impacto en el proyecto o en la organización.

Por ese motivo hay que valorar el corto y el largo plazo y no centrarnos exclusivamente en un aspecto. Es cierto que tiene sentido que tengamos una perspectiva más estratégica pero también lo es que el momento actual también puede tener necesidades que deberían ser cubiertas.

En los proyectos de desarrollo de software a veces resulta importante elegir un determinado camino y para ello hay que valorar muchas cosas. Cuando existe impacto económico y éste es significativo, la decisión es complicada porque tiene más trascendencia y eso hace necesario que las diferentes opciones sean vistas no solo para resolver problemáticas puntuales sino para alcanzar objetivos concretos que lo mismo pueden ser diferentes o aconsejar una alternativa distinta.

Es cierto que el momento actual es acuciante porque las presiones que recibimos en el proyecto son consecuencia del mismo pero eso no debe condicionar la decisión salvo que la no atención de esa problemática pueda impactar sensiblemente en el proyecto.

Anuncios

Hay que tomar decisiones, lo fácil es que sea otro quien las tome por ti pero eso no siempre va a funcionar porque muchas veces serás el último eslabón de la cadena teniendo en cuenta, además, que estamos todo el día tomando decisiones.

A veces se tarda más de lo conveniente en tomar una decisión y cuando se toma, aunque sea acertada, resulta que es demasiado tarde y ya no sirve de nada. No tengo que daros ningún ejemplo porque cada uno de nosotros ha vivido esto en reiteradas ocasiones en primera persona.

Es cierto que no todas las decisiones son iguales y que en unas expones y arriesgas más que en otras y que las consecuencias tampoco son las mismas. En tu rol tendrás que tomarlas y asumir tus errores de la misma forma que te llenan tus éxitos. A veces los errores serán graves y tendrán consecuencias pero, ¿quién no ha tenido errores de este tipo? El desarrollo de software es complejo y no contamos con un mapa que nos guíe hasta el éxito del proyecto, en medio podremos equivocarnos y lo mismo nuestras acciones impactan en el resultado final del proyecto pero es parte del juego, parte de nuestra profesión.

Toma decisiones, equivócate, acierta, es parte de la vida misma y nuestro día a día personal y profesional.

Sobre esto Jerry Weinberg realiza la siguiente reflexión (traducción libre): “Si no puedes soportar ser un tonto público (quedar en ridículo), no vas a tener éxito en un rol en donde todas tus acciones son estudiadas al detalle”.

Decía el actor americano Bill Cosby que: “No sé cuál es la clave del éxito pero la clave del fracaso es intentar agradar a todo el mundo”.

Podrás empeñarte en tomar decisiones que gusten a todo el mundo o que no molesten a nadie, a veces conseguirás ese objetivo, pero en la mayoría de los casos habrá alguien que no esté de acuerdo con algo.

Y eso pese a que has filtrado tus actuaciones de manera que no has aplicado la estrategia idónea sino una edulcorada que será menos efectiva, por lo que al final es posible que no tengas ni una cosa (la finalidad que perseguías con tu actuación) ni la otra (que todo el mundo esté conforme con las decisiones que has tomado).

Se trata de ser pragmático. A veces la solución edulcorada será más positiva (que no más efectiva) y en otras ocasiones será un gran error. Hay que analizar todas las perspectivas posibles, desde el convencimiento de que no somos infalibles y que entre los extremos del vale todo y no vale nada encontraremos una solución adecuada.

Si no has probado a hacer un seguimiento del sprint utilizando un gráfico de burndown te recomiendo que lo hagas porque te permitirá detectar desviaciones de manera temprana y poder tomar decisiones que permitan eliminarlas o paliarlas en el caso de que se considere necesario (y se pueda).

El concepto es igualmente aplicable a ciclos más largos o a otras estrategias de desarrollo, si bien, resulta maś efectiva en contextos donde el nivel de acierto en las estimaciones sea más alto.

El burndown por otra parte no puede ser más simple, en el eje X tenemos la división en días del sprint (puedes poner día 1, día 2, etc… o fechas reales) y en el eje Y el esfuerzo restante para terminarlo, en la unidad de medida que se considere (horas, jornadas, puntos por historia, etc…). Sobre esa gráfica se dibuja una recta que representaría la proporción entre el esfuerzo restante en el proyecto con respecto al día de desarrollo suponiendo que el nivel de avance es lineal.

Lo realmente importante es la segunda línea, la que representa el avance real y que se calcula a partir del tiempo que resta para la finalización de cada tarea o historia de usuario (en función del grado de desagregación que hayas decidido utilizar). Los momentos en que esta segunda línea esta por encima de la recta representa retraso respecto a lo previsto y cuando está por debajo representa un adelanto.

Como podéis ver su mantenimiento es muy simple y los desarrolladores no tienen que realizar ningún esfuerzo significativo para ir actualizando estos datos, si bien deben ser objetivos a la hora de estimar el esfuerzo restante ya que de lo contrario se estarán tomando decisiones a partir de datos incorrectos.

Cuando nos encontramos trabajando en un proyecto de desarrollo de software nos encontraremos con todo tipo de opiniones procedentes de diversos niveles.

Si no se gestiona este asunto de manera adecuada resulta muy negativo: si no se escuchan las opiniones seguro que estamos prescindiendo de puntos de vista que van a aportar valor al proyecto, si nos dejamos influir por ellas sin hacer un análisis de las mismas, estaremos dejando el proyecto en manos de terceros que pueden o no tener una visión global del mismo.

Me gusta mucho la siguiente cita de Sócrates porque refleja realmente lo que tenemos que tener en cuenta en las opiniones: “Pesa las opiniones, no las cuentes”.

No importa el número de personas que piensen lo mismo (sí que debe ser objeto de análisis esa coincidencia de puntos de vistas) lo que importa realmente es el valor de esa opinión, su fundamento, su planteamiento y su objetividad.

Puede importar la experiencia de quién te la plantea pero debe importar tanto o más, la visión de personas que están cerca del objeto sobre el que se plantea, ya que serán ellos muy probablemente los que se tengan que enfrentar al problema.

Decía Séneca que: “Escucha aún a los pequeños, porque nada es despreciable en ellos”.

Me encuentro en muchas ocasiones donde no existe diálogo entre los diferentes niveles de una organización. Solo se escucha (si es que se escucha) al estrato inmediatamente inferior, confiando ciegamente en que la información que éstos transmiten es la correcta.

Eso supone un riesgo importante porque aunque no lo haga con mala intención es muy posible que su conocimiento real de lo que pasa por debajo suya no sea bueno. ¿Qué es su trabajo conocerlo? Sí, pero para llegar al detalle no te puedes quedar solo con lo que ves en primera línea, también hay que mancharse las manos y bajar a las trincheras.

Os puedo asegurar que en las trincheras se ven las cosas de otra manera y quienes están allí tienen opiniones muy valiosas que por lo menos deben ser escuchadas y analizadas. Si no lo haces te estás perdiendo una fuente de información muy importante para la toma de decisiones.