archivo

Archivo de la etiqueta: martillo de oro

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un “martillo de oro” que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

Es posible que a lo largo de tu experiencia en proyectos de desarrollo de software hayas encontrado una serie de estrategias, prácticas, fórmulas, comportamientos, etc… que suelen producir buenos resultados.

Esa experiencia acumulada es positiva siempre y cuando se tenga presente que no se tratan de soluciones mágicas que funcionan siempre, independientemente de cualquier proyecto y de cualquier contexto.

Si se cree que se ha descubierto la piedra filosofal del desarrollo de software se corre un riesgo importante porque se deja de lado un análisis en profundidad de la realidad del proyecto en el que hay que trabajar y por otro se empieza a dejar de escuchar a los demás porque, ¿para qué? si ya sé todo lo que tengo que hacer para que el proyecto vaya hacia adelante.

Esto no solo desmotiva a tu equipo sino que te pone una distancia con respecto a él porque al fin y al cabo llegas a la conclusión de que tu eres el director de orquesta y autor de la partitura y ellos solo ejecutan y por supuesto si la música suena mal será porque los músicos no la saben tocar bien y/o porque el público no era el adecuado.

Lo realmente importante es la capacidad de analizar la situación de un proyecto, que puede ser la inicial o cualquier momento de su desarrollo, y saber elegir la mejor estrategia posible que podrá coincidir o no con las que ya conoces. Si te encierras en tirar de manual estás acotando innecesariamente las posibilidades que se te ofrecen para aplicar una soluciones que se adaptan mejor al momento actual del proyecto.

Eso implica, a su vez, escuchar la opinión de terceras personas que aporten su conocimiento y experiencia.

Decía René Descartes que: “Divide las dificultades que examinas en tantas partes como sea posible para su mejor solución”.

El divide y vencerás funciona y es la base en que se desarrolla software independientemente de la metodología o tecnología utilidad.

En las metodologías, estrategias o prácticas ágiles la división del problema en partes por ejemplo, historias de usuario, tiene un matiz muy potente y se trata no solo de simplificar la solución mediante su fragmentación en partes más manejables sino de que en cada iteración, se va aprendiendo tanto para mejor y evolucionar lo que se ha desarrollado sino para abordar los siguientes trabajos.

Como os he comentado en numerosas ocasiones, no hay martillos de oro, somos desarrolladores y no alquimistas, por lo que siempre hay que analizar el contexto antes de tomar una decisión. No obstante, mi experiencia me ha demostrado que cuando veas que un determinado producto o una evolución del mismo se complica, no se ve clara o se tiene comprometido alcanzar los objetivos mínimos al estar el presupuesto demasiado ajustado, lo mejor es seguir reduciendo el ámbito de trabajo con el objetivo de obtener poco que funcione bien por encima de mucho que funcione regular o que no se ajuste a lo que los usuarios esperan o necesitan.

Los proyectos de desarrollo de software se ejecutan en un contexto de incertidumbre. Hay muchísimas variables que pueden influir en el resultado final, tantas que resulta prácticamente imposible controlarlas todas.

El éxito no depende de tirar una moneda al aire, no quiero decir eso, para conseguirlo se requiere haber colaborado con tu trabajo, tus conocimientos y tu experiencia (así como la de todas las personas que participan en él), saber reponerte cuando las cosas van mal y no dejarte ir si se van consiguiendo los diferentes hitos que se van marcando.

Trabajar en esta profesión requiere tener conciencia en que todos los proyectos no van a salir bien y que no existe un martillo de oro que asegure nada. Un éxito no te asegura otro éxito y un fracaso tampoco te asegura otro. Siempre hay que evaluar los contextos en que se dieron cada uno.

Trabajar en esta profesión supone asumir que, a veces, vas a fracasar. Y muy probablemente adquieras mucho conocimiento porque poca cosas ayudan más a evolucionar que darte cuenta de cuáles han sido tus propios errores. Pero eso no viene solo, requiere que asumas tus errores y eso no es fácil, ya que la primera reacción suele ser mirar a todos lados menos a ti mismo.

Y, a veces, vas a tener éxito y tenerlo puede provocar el efecto contrario al fracaso asumido y aprovechado, porque si crees que has descubierto una receta mágica y que ya lo sabes todo, lo más probable es que termines involucionando porque en este caso te centras en mirar lo guapo que eres y no miras a tu alrededor.

Para esto, Séneca tenía la siguiente reflexión: “Una persona inteligente se repone pronto de un fracaso. Un mediocre jamás se recupera de un éxito”

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

No ayuda nada obviar el contexto en que se realiza el proyecto bien puede ser por falta de experiencia o por el contrario por pensar que se tiene la solución para derribar todas las puertas (martillo de oro) lo primero se cura con el tiempo (una vez que te recuperas de las caídas que has tenido y si realmente haces retrospección de tus actuaciones y decisiones) de lo segundo también, si bien, resulta algo más complicado ya que supone bajar de las nubes en la que estemos instalados… y es que se está tan bien allí arriba.

Jim McCarthy realizó la siguiente reflexión: “Decir que quieres algo implica que estás dispuesto a cambiar para conseguirlo. De lo contrario, realmente no lo quieres”.

Me parece interesante ya que representa el cambio de actitud necesario cuando con la actual no consigues nada (o incluso empeoras la situación) y por extensión la necesidad de adaptarte al cambio porque no siempre te va a caer todo en las manos (por mucho que pienses que sabes colocarte bien).

Nuestro conocimiento y nuestra experiencia constituyen nuestro verdadero background a la hora de afrontar un proyecto de desarrollo de software y las diferentes contingencias y cambios de contexto que se van a producir en el mismo. Todo lo demás: metodología, procesos, buenas prácticas, herramientas, etc… son instrumentos que utilizaremos según convenga y que en el caso de que haya alguno de carácter obligatorio (por si se quiere armonizar algún aspecto del desarrollo entre proyectos diferentes) debe ser lo suficientemente flexible para ofrecernos el margen de maniobra necesario para poder adaptarnos a la nueva situación e incluso prever la posible existencia de excepciones cuando exista una circunstancia que lo justifique.

La repetibilidad es algo deseable, ¿por qué no querer industrializar una manera de hacer las cosas que nos permita alcanzar el éxito con una alta probabilidad?, sin embargo en el desarrollo de software donde cada proyecto es algo singular y en donde los contextos cambian es buscar una quimera.

Por tanto, la repetibilidad basada en términos absolutos es algo que deberíamos descartar de base, lo cual no quiere decir que en función de las características de un proyecto apliquemos unas estrategias de fondo que nos puedan resultar de utilidad (pero como instrumento no como un martillo de oro).

Sobre esto, Jim Highsmith opina lo siguiente: “Los agilistas creen que las buenas prácticas y procesos puede mejorar la consistencia pero que la repetibilidad es una fantasía”.