archivo

Archivo de la etiqueta: Peter Drucker

Para Peter Drucker: “No hay nada tan inútil como hacer eficientemente algo que no debería haberse hecho”.

El desperdicio de esfuerzo, en muchas ocasiones, tal vez la mayoría, realizado con la mejor de la intenciones, hace mucho daño a los proyectos de desarrollo de software.

Querer avanzar demasiado deprisa, desarrollando nuevas funcionalidades cuando hay otras que todavía no están maduras y que dependen entre sí, querer abarcar más de lo que se puede, trabajar con demasiadas hipótesis no validadas. Todo ello es susceptible y, de manera muy probable, de generar desperdicio.

Y no se trata de falta de interés, esfuerzo o competencia, sino de no saber administrar adecuadamente los tiempos, de no priorizar bien y de no saber decir que no.

Para Peter Drucker: “El emprendedor siempre busca el cambio, responde a él y lo explota como una oportunidad”, es curioso, porque precisamente es ese cambio el que asusta a la mayor parte de los gestores.

Asusta porque en la situación actual se sientes cómodos, se encuentran en su zona de seguridad, y eso es así, por mucho que los números empiecen a indicar que si se sigue actuando de la misma manera, la organización se va a ver más y más perjudicada.

La solución no es esperar a que amaine el temporal porque con independencia del contexto económico en el que nos encontremos, las condiciones, las reglas del juego varían: aparecen nuevas necesidades por parte de los consumidores, surge nueva competencia perfectamente adaptada al contexto actual (y con capacidad de poder adaptarse a cambio) a la que hay que sumar a la competencia tradicional que ha sabido reaccionar y ajustarse a la nueva situación.

Porque como también decía Peter Drucker: “La única cosa que sabemos sobre el futuro es que será diferente”.

Ante esa situación, no resulta recomendable centrarse en un negocio, cliente o producto exitoso, es decir, sí, sácale todo el partido que puedas pero no te olvides que si no sigues trabajando en innovación, en entender qué quiere el mercado y si tu organización no está estructurada para adaptarse al cambio que, sin duda, aparecerá, todo lo que hoy es ventaja, mañana no te servirá para nada.

Principio 3: Para gestionar la calidad los desarrolladores deben medirla.

Ya lo dice también Peter Ducker: “Lo que se puede medir se puede mejorar” o lo que es lo mismo “lo que no se puede medir (o no se mide) no se puede mejorar”.

Si no mides (y no solo vale con eso, también hay que revisar, contrastar y analizar) no puedes saber si el trabajo está siendo efectivo y si realmente se está produciendo una mejora de la calidad del producto y si estamos, además, cumpliendo con las condiciones específicas que está imponiendo el cliente.

Con las métricas obtenidas tenemos la capacidad de poder realizar acciones correctivas y mejorar nuestros propios procedimientos y prácticas.

Obtener valores numéricos es muy útil para medir aspectos relacionados con el análisis estático de código (acoplamiento, cohesión, en general, deuda técnica y buenas prácticas de programación) y otros que tienen que ver con el número de defectos del producto o entregas que resultan fallidas.

Sin embargo deben complementarse con métricas cualitativas (que si se quiere también se pueden cuantificar) como, por ejemplo, el nivel de satisfacción que están teniendo los usuarios con el trabajo realizado y el producto resultante.

Pero además, y esto lo añado yo, quien propone las métricas y los hitos de calidad, en este caso, el cliente, también debe medir si la aplicación de las mismas realmente proporciona una mejora para la organización, porque lo mismo las normas que se están solicitando y aplicando no son buenas y/o no se adaptan a la realidad de los proyectos y presupuestaria.

Esto es importante porque la calidad tiene un coste tanto relacionado con el desarrollo (imputable a cada proveedor y que afecta a las cuentas de cada proyecto) como con el control que realiza el cliente. Hay que tener en cuenta que unos objetivos de calidad equivocados pueden tener un doble efecto negativo: no se mejora la calidad en muchos aspectos que son realmente importantes (porque se enfoca la atención a otros hitos) y además se genera un sobrecoste que podría ser aprovechado para conseguir unas aplicaciones que estén mejor rematadas.

Una situación muy común en las organizaciones o a menor escala en los departamentos de las mismas consiste en no tener definidos cuáles son sus objetivos. Esto provoca que el funcionamiento de los mismos esté a la deriva porque realmente no saben a dónde quieren ir y aprovechan, eso que abominan, que es estar apagando continuamente fuegos para evitar tratar este asunto incómodo.

¿Incómodo? Sí, porque definir objetivos implica tener una referencia y eso puede quitar muchas caretas.

Hay una situación todavía peor que no tener objetivos y es pensar que los hay. El ejercicio es muy sencillo, pide a varias personas de tu departamento o de tu organización que pongan en orden de prioridad cuáles entienden ellos que son los objetivos… Suerte.

Me parece muy interesante la siguiente cita de Peter Drucker: “La gestión por objetivos funciona… si conoces los objetivos. El 90% de las veces, no los sabes”.

Me parece muy sabia la siguiente reflexión de Peter Drucker: “El aspecto más importante de la comunicación es escuchar lo que no se dice”. Y no se refiere a lenguaje no verbal, sino a interpretar realmente lo que nos están comentando porque no debemos olvidar que somos personas, estamos llenos de emociones, también de miedos y no siempre trasladamos la realidad de una situación o de un problema a palabras bien porque no queremos, no sabemos o no podemos.

El objetivo de las relaciones entre las personas en un ámbito profesional y colaborativo debe ser la transparencia, pero no deja de ser un fin, no digo una quimera, pero sí algo que es más complicado de lo que parece porque hay que ser muy valiente para no guardarte nada y exponerlo todo. Además de valentía se requiere confiar en la otra parte y la confianza cuesta mucho construirla y consolidarla.

Pero hay que intentarlo. En un contexto como el del desarrollo de software en el que la comunicación y la interacción entre las personas es esencial, es la base para establecer una relación de confianza entre todas las partes, algo que resulta fundamental para que el proyecto se desarrolle sobre un contexto propicia (independientemente de que después las cosas salgan mejor o peor).

Poco a poco, mientras tanto tocará interpretar lo que se dice pero también lo que no.

Planificar a largo plazo puede ser esfuerzo invertido en vano. Sí que me parece interesante tener marcados objetivos e hitos, pero no me lo parece tanto, tener un nivel de detalle importante más allá de lo que se considere el corto/medio plazo (que sea uno u otro dependerá del nivel de incertidumbre que exista).

Es importante saber y poder reaccionar ante el cambio y no cerrarnos en un guión preestablecido ya que la película es otra.

Para Peter Drucker: “Tratar de predecir el futuro es como intentar conducir de noche por un camino rural con las luces apagadas mientras miras por la ventana de atrás”.

Una planificación detallada a largo plazo pretende dar una sensación de control: “si doy todos estos pasos conseguiré los objetivos”, pero en realidad es una falsa sensación de control porque para empezar no sabes si tu plan es bueno o no (por mucho que confíes en él) y tampoco si se van a mantener constantes en el tiempo el contexto o condiciones en las que se ha realizado el mismo (pero es importante tener en cuenta que el problema no suele ser fallar en la planificación, sino como dije antes, ser poco flexible a los cambios cuando resulta necesario).

Precisamente por eso los enfoques predictivos o clásicos en el desarrollo de software no suelen dar buenos resultados porque se especula con una solución basada en un conocimiento limitado de los usuarios del producto que quieren (el conocimiento real se obtiene con el tiempo conforme ellos vayan viendo materializadas sus ideas a lo largo del proceso de desarrollo), dado que estas estrategias prevén estabilidad en las especificaciones, todo empieza a desmoronarse cuando se rompe ese requisito y es demasiado tarde para que los cambios en las especificaciones tengan un impacto leve en el esfuerzo disponible del proyecto.

Llegado a ese punto solo se podrá salvar la situación si cliente y proveedor entienden el problema y tratan de buscar una solución flexibilizando el objeto del contrato, intercambiando tareas y aportando más presupuesto por parte del cliente en el caso de que sea necesario.

No se trata de saltar al vacío, no se trata de perder la cabeza. A veces hay que arriesgar porque no siempre contamos a priori con todas las respuestas.

La adaptación al cambio tiene riesgos porque sueles introducirte en terreno desconocido, tienes que tomar decisiones para pasar de una situación que controlas o que has empezado a controlar a otra totalmente nueva.

Se asociar error a riesgo y es algo comprensible, pero también nos equivocamos muchas veces por esperar demasiado o por mantener una posición dentro de nuestra zona de seguridad. Y probablemente si lo ponemos en la balanza tengamos más o menos nivelados nuestros errores por actuar como por no hacerlo.

Ya lo dice Peter Drucker: “Las personas que no toman riesgos suelen hacer sobre dos grandes errores al año. Las personas que hacen correr riesgos suelen hacer sobre dos grandes errores al año”.

La diferencia entre arriesgar o no es que en el primer caso lo haces con intención y en el segundo eres sujeto pasivo esperando a que el problema pase o que se encargue otro de él.