archivo

Citas

Es complicado tomar tanto a nivel personal como a nivel de una organización la decisión de cambiar porque todo cambio, aún necesario, no es sencillo, sabemos lo que cuesta asumir los errores y/o salir de la zona de confort. A veces también resulta difícil cambiar sobre todo cuando cuentas con pocas alternativas.

Pero hay algo todavía más complicado que eso, una vez tomada la decisión del cambio mantener en el tiempo la fuerza y consistencia necesaria para no volver a la situación anterior o dejarlo a medias. En muchos casos el impulso inicial termina al día, semana o mes siguiente (o al segundo siguiente de haberse tomado la decisión).

Para cambiar no basta con pulsar el interruptor sino que es necesario mantener el dedo encima el tiempo necesario para que el cambio realmente sea efectivo.

El cambio no es sencillo porque no sabes realmente qué te vas a encontrar por el camino pero, en ocasiones, no te queda otra posibilidad que asumir ese riesgo cuando si permaneces inmóvil en la situación actual ves que va a ser complicado cumplir tus objetivos.

C. S. Lewis realizó la siguiente reflexión sobre este tema: “El mero cambio no es crecimiento. El crecimiento es la síntesis del cambio y de la continuidad, y donde no hay continuidad, no hay crecimiento”.

En el mundo del desarrollo de software el cambio resulta necesario porque el contexto tecnológico, clientes y competencia entre otras múltiples variables cambian, también muchos de tus objetivos.

Anuncios

La escritora americana Madeleine L’Engle realizó la siguiente reflexión (traducción libre): “Nuestro talento por sí solo no vale nada, lo que cuenta es cómo lo utilizamos”.

Y es así, aptitud sin actitud es talento desaprovechado. De nada vale tener la capacidad de correr deprisa si no te quieres mover o correr deprisa sin tener ningún tipo de control y sin saber a dónde ir.

Además, en el mundo del desarrollo de software no se trabaja solo, por lo que tu aptitud se tiene que poner a servicio del colectivo con el objeto no solo de hacer que los demás trabajen mejor sino para que las aportaciones de tus compañeros te permitan conseguir mejores resultados.

Talentos individuales pueden conseguir grandes resultados, hay muchos ejemplos, pero todavía hay muchísimos más, sobre todo cuando centramos el enfoque en servicios de desarrollo de software, en los que el talento sin una orientación adecuada y sin un deseo de colaboración con el resto de personas que participan en el proyecto no consigue solventar los múltiples problemas de diversa índole que se presentan.

El talento es importante pero también lo es la capacidad de trabajo individual y en equipo, la capacidad de comunicación y la capacidad de poder discernir entre objetivos individuales y objetivos el colectivo, ambos compatibles pero que tiene cada uno su momento.

Abrir la mente es fundamental, no basta solo con poner los oídos sino que hay que estar dispuesto a escuchar y a poner en tela de juicio tus opiniones y tu punto de vista sobre los temas que se están tratando. Si de entrada crees que tienes la razón, la solución o la respuesta y que los demás, digan lo que digan, no la tienen, no hay forma de poder enriquecerse con las aportaciones que te hagan.

Si todo el equipo tuviera esa actitud solo quedaría como salida el “ordeno y mando” y eso limita mucho su capacidad porque se desaprovecha el talento individual y el colectivo y no se crea el contexto necesario para tener un equipo de proyecto dinámico y colaborativo en el que todos se sientan importantes, algo fundamental para un desarrollo ágil y generalizando, para cualquier enfoque que se vaya a utilizar.

Eso de considerar que mis ideas o mi código son los mejores son una resistencia al proyecto y no por el hecho de serlo, sino por la actitud que se toma con respecto a ellas ya que si se consideran como la verdad absoluta pueden provocar el descarte o minusvaloración del trabajo, apreciaciones, visiones u opiniones de otros componentes del equipo de trabajo y/o de otras personas que colaboran en el proyecto.

He mantenido muchísimas conversaciones con defensores de enfoques clásicos de desarrollo de software sobre este asunto y siempre es lo mismo, que se basan casi siempre en que no hay motivos por los cuales un sistema de software deba seguir una metodología o unos procesos diferentes que para construir un edificio y que no pensar eso es no creer en la ingeniería del software.

Prácticamente toda mi experiencia laboral se ha centrado en enfoques clásicos por lo que tengo criterio para tener una opinión totalmente contraria a eso. No hablo de teorías, hablo de realidades.

Y la realidad es que el software es flexible, es adaptable, es evolucionable y para que funcione tienes que programar hasta el más mínimo detalle. Un edificio no es flexible por lo que su posible adaptación (estructural) es mucho más compleja y costosa y no requiere tanto nivel de detalle para poder ser utilizado.

Precisamente por eso los procesos para la construcción son más rígidos y los cambios sobre las especificaciones iniciales son más por motivos técnicos que funcionales.

Si el software tiene esas características, ¿por qué ignorarlas?, ¿por qué aplicar un planteamiento predictivo (planos) cuando es posible aplicar un planteamiento evolutivo?, es más, ¿por qué utilizar un enfoque predictivo si la propia realidad del proyecto aconseja el incremento y la iteración?.

Para Ken Auer y Roy Miller: “Cuando se utiliza un proceso destinado a la construcción de cosas inflexibles como puentes para construir cosas flexibles como el software, no debe sorprender que más tarde el coste del cambio sea mayor”.

Los procesos y herramientas son instrumentos que utilizados de manera adecuada pueden ayudarnos a conseguir los objetivos. El problema lo tenemos cuando se cree que los objetivos se consiguen, sobre todo, por su aplicación, lo que provoca que pasen a la categoría de fines en lugar de la de instrumentos: “si cumplo con los procesos y hago un buen uso de las herramientas que lo acompañan el proyecto saldrá bien”.

Si centras tu atención en el proceso pierdes tu enfoque en el producto y se tiende a ignorar el contexto. Todo ello por la idea de que la solución la proporciona el proceso y que eso está por encima de cualquier contingencia que se pueda producir.

Robert C. Martin realiza la siguiente reflexión: “El exceso de confianza en las herramientas y procedimientos y la falta de confianza en la inteligencia y en la experiencia son recetas para el desastre”.

A veces es la propia organización la que empuja a los desarrolladores a centrarse en el proceso, independientemente de la importancia que ellos piensen que pueda tener en el desarrollo de software. Cuando esto ocurre habrá personas que por comodidad y también por pragmatismo (hacia ellos y no hacia el proyecto y el producto) caigan en la cultura del cumplimiento: “yo he seguido los procesos de manera escrupulosa, ahí tienes todos los entregables, si el proyecto no ha salido bien no soy el responsable”.

Si el desarrollo de software fuera solo cuestión de procesos (ágiles o no) la mayoría de los proyectos no tendrían problemas y serían rentables tanto para clientes como para proveedores, ¿es esa la realidad?, se necesita algo más y eso lo ponen las personas que trabajan en ellos.

El liderazgo en una organización, en un departamento o en un proyecto proporciona la fuerza y constancia necesaria para superar los obstáculos, adaptarse al cambio y conseguir la mejora continua. La fuerza y la constancia no son condiciones suficientes pero sí necesarias.

El liderazgo requiere creer en los objetivos que se han marcado. Es fundamental. Su efectividad requiere también de que el resto de personas implicadas (o una gran mayoría de ellas) crean también en que la dirección que se va a tomar es correcta, teniendo en cuenta que lo mismo no es la solución más cómoda y que espera una dura tormenta antes de que empiecen a salir de entre las nubes los primeros rayos de sol.

Por tanto, el liderazgo requiere la creación de nuevos lideres que se sumen a la causa y que ayuden con su impulso a conseguir los objetivos y conseguir nuevos adeptos a la causa.

Mary y Tom Poppendieck precisamente entienden el liderazgo de esa manera: “Una organización tiene que evaluar el liderazgo como la capacidad de desarrollar líderes” y tiene su razón de ser, ya que es muy difícil que una sola persona por mucho carisma, capacidad de trabajo e insistencia que tenga pueda provocar el cambio (sí que puede ser el detonante pero se requerirá de una intensidad superior a la que esa persona puede aguantar y gestionar).

La palabra líder se dice muy pronto y muy fácil, después, en las trincheras, todo es más complicado y ahí es realmente donde se demuestra esa capacidad tanto cuando hay problemas como cuando las cosas vienen mejor dadas.

Como desarrolladores somos reacios a la realización de cambios y no es que seamos así genéticamente sino por el hecho de que se nos ha formado y después hemos trabajado en proyectos en donde nuestra capacidad de ser flexibles estaba muy limitada por el cumplimiento de una agenda de costes y plazos (mucho más lo primero que lo segundo).

Cuando se enfoca un proyecto con presupuestos inmovilistas y sobre todo, carentes de toda aproximación a la realidad no se puede pretender que acojamos los cambios dando aplausos porque lo que el presupuesto no cubre (hasta cierto límite, claro está) lo tendremos que cubrir con nuestro trabajo.

No se trata de trabajar con presupuestos ilimitados, sino de desarrollar con intención (que es lo mismo que tratar de desarrollar de manera eficiente) y de determinar cuándo el valor del producto es suficiente y cuándo deja de ser rentable el crecimiento del valor con respecto a la inversión que se está realizando.

Con esta visión del desarrollo del software el cambio resulta bienvenido ya que se entiende que a través de él se consigue dotar al producto de un mayor valor (como consecuencia de que cada vez se ajustará más al contexto existente y a las expectativas de los usuarios).

Ahora bien, el cambio debe hacerse con intención (evitando en lo posible las circunstancias de prueba y error) y con un sistema en los que los cambios se puedan realizar con agilidad (deuda técnica acorde a las características del sistema que se desarrolla, arquitectura y modelo de datos escalable, etc…).

Cuando uno se acostumbra a este esquema de trabajo se acepta el cambio como una parte más del proceso de desarrollo de software y efectivamente se cumple la siguiente reflexión de Ken Auer y Roy Miller: “La única manera de deshacerte de tu miedo a los cambios en el código es hacerlos una y otra vez”.