archivo

Archivo de la etiqueta: adaptación al cambio

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

Keynes comentó: “Cuando los hechos cambian, yo cambio de opinión ¿Qué hace usted, señor?”. Si el contexto ha cambiado lo suficiente, es necesario adaptarse, no hacerlo es ir en la dirección incorrecta.

Precisamente, por ese motivo, el desarrollo de software es de naturaleza adaptativa y los proyectos deben tener en cuenta que los hechos cambian de manera externa al desarrollo y también por los mismos trabajos que se están haciendo porque en cada iteración, los usuarios se darán cuenta de que algunas de sus especificaciones no han tenido en cuenta todos los detalles, sobraba alguno o incluso que el planteamiento debe cambiar por completo.

Adaptarse no es reconocer un error, no adaptarse es dirigirse directamente a él.

Hay una reflexión de Jerry Weinberg que es conveniente tener muy en cuenta: “Cuanto más adaptado te encuentres menos adaptable tenderás a ser”.

Esta cita se refiere a la especialización. Puedes ser el rey en un ecosistema concreto, pero como cambie, si no estás preparado, puede ser un desastre para tu organización, porque implicará cambios que deberán ser ejecutados en un tiempo razonable para los cuales no estarán preparadas ni las estructuras ni la mentalidad de la organización y de muchas de las personas, sobre todo los directivos, que forman parte de ella.

La especialización no es mala, no lo entendamos de ese modo, lo que sí es negativo es tener los ojos cerrados a posibles cambios en el contexto, a no tratar de adelantarse a ellos, a pensar que el mercado siempre va a ser el mismo, que la competencia no va a evolucionar lo suficiente y que nosotros siempre vamos a ser los mejores.

Es difícil hacerlo cuando las cosas vienen bien dadas, ¿para qué cambiar si todo va bien?. No se trata de cambiar por cambiar, se trata de hacerlo con cabeza, se trata de mirar alrededor y no solo dentro de uno mismo.

En el mundo actual todo se mueve a un ritmo vertiginoso, de cualquier sitio puede salir un nuevo competidor o una nueva tecnología que puede ser adquirida o desarrollada por tus competidores tradicionales, por ese motivo, no solo debes centrarte en desarrollar tu negocio, sino también estar alerta a riesgos que pueden poner en peligro a tu posición en el mercado.

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

– Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

– División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

– El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

– Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

Comparto la visión de Deming de que las personas son la clave para conseguir un determinado nivel de calidad en los resultados de una organización y su evolución continua: “la transformación sólo puede llevarse a cabo por las personas. Una empresa no puede comprar su camino hacia la calidad”.

Por eso, muchas iniciativas que tratan de que las organizaciones den un paso hacia adelante y evolucionen, fracasan, bien porque las personas que las impulsan, bien porque las personas que las tienen que ejecutar o bien por ambas, no están por la labor de hacer el esfuerzo necesario para pasar a una nueva fase en la que las cosas funcionan de otra manera y se obtienen otros resultados.

¿Y por qué? Tal vez nadie se ha esforzado en explicar los beneficios que tiene adaptarse al cambio y la necesidad de hacerlo cuando el contexto no te deja otra opción: o evolucionas o desapareces.

Por tanto, puedes hacer consultorías, planes estratégicos y cualquier otra actividad por el estilo, que si no empiezas a trabajar con las personas y a darle la importancia real que tienen, lo más probable es que no consigas nada o que los resultados no sean todo lo satisfactorios que se esperan y se necesitan.

Es necesario adaptarse al cambio cuando surge un nuevo contexto. Cambiar es casi siempre posible pero el tiempo y esfuerzo que se invierte en ello puede provocar que lleguemos demasiado tarde y/o que hayamos gastado gran parte o casi todo el esfuerzo disponible en ese cambio dejándonos sin posibilidades ante futuros cambios o ante la propia evolución del sistema.

No todos los cambios son iguales ya que hay contextos tan radicalmente diferentes al anterior que no hay proyecto que lo pueda sostener salvo que se redefinan las restricciones del mismo (principalmente el presupuesto).

Sin embargo cuando el cambio sea “más suave” sí que resulta necesario estar preparado para ello y no supone realmente una inversión adicional al proyecto sino que el esfuerzo destinado a ello empieza a amortizarse prácticamente desde el principio.

Sí, hablo de una arquitectura y un código que favorezcan la mantenibilidad del producto a través de una deuda técnica acorde a las características del proyecto y los recursos disponibles pero no solo se tratan de aspectos técnicos ya que un equipo (y no hablo solo del equipo de desarrollo, sino que lo extiendo también a los responsables funciones o al Product Owner y al conjunto de personas que intervienen de manera más o menos directa en la construcción del producto) que se entiende, que se comunica, en el que hay confianza y que es consciente de que puede haber cambios de contextos tomará decisiones más acertadas, de manera más rápida y pensando en el bien general.

También hablo de una adecuada gestión de riesgos. Hay cambios de contexto que suceden y es complicado tener una previsión de los mismos, sin embargo, hay otros cambios de contexto que son el resultado de la materialización de riesgos (en algunos casos pueden ser evitables y en otros caso 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.