archivo

Archivo de la etiqueta: bala de plata

En el artículo de ayer, la cita de Andy Hunt nos invitaba a rebelarnos contra las tendencias cuando entendemos que el camino debe ser otro.

Las tendencias y/o las buenas prácticas establecidas está claro que marcan un camino y tanto error es seguirlos a ciegas como no seguirlos por sistema.

El problema, por tanto, no son las tendencias sino la forma en que nos comportamos ante las mismas.

Otra reflexión de Andy Hunt que abunda en este tema es la siguiente: “Considera siempre el contexto”. No puedo estar más de acuerdo, no existen los martillos de oro o balas de plata en términos generales porque su validez se circunscribe a contextos concretos que dependen de muchas variables (si bien, en algunos casos el dominio de contextos donde podrían tener una aplicación válida puede ser proporcionalmente alto) y además los contextos varían, algo muy frecuente en los proyectos de desarrollo de software y que caracterizan su incertidumbre inherente.

Analiza el contexto, las circunstancias del proyecto, adapta tus prácticas a eso (no hablo de tu background porque ahí la capacidad de cambio es más limitada aunque tener una actitud abierta ayuda bastante) y prepárate para adaptarte al cambio porque lo más probable es que las condiciones de partida varíen a los largo del proyecto y no solo una vez.

Uno de los grandes problemas que me he encontrado en todos los niveles del desarrollo de software y de los Departamentos TIC es la falta de predisposición de muchas personas a escuchar opiniones de terceros, sobre todo si las mismas proceden de personas que se encuentran en niveles inferiores de la jerarquía o pertenecen a otros Departamentos.

Os puedo asegurar que cualquier persona, aunque tenga una experiencia laboral de un día puede tener una idea que sume al proyecto. Lo más fácil es no escuchar o tener un filtro por el que solo admitas opiniones de determinadas personas. Escuchar más implica también trabajar más pero los beneficios de ello superan al esfuerzo invertido porque incluso aún no siendo buena la propuesta, las personas valoran que se les escuche y sentirse implicadas.

No debemos olvidar que nuestro objetivo debe ser conseguir el éxito en el proyecto y no alimentar nuestro ego.

También debemos evitar antipatrones como el “No inventado aquí“. Hay una amplia experiencia pasada en la industria, ¿por qué dejarla en segundo plano sin ni siquiera analizar la conveniencia de su aplicación?.

En el lado opuesto tenemos la confianza ciega en determinadas prácticas procedan de la experiencia de otros o de la propia. Debemos dejar de lado la aplicación de martillos de oro y balas de plata sin analizar el proyecto y su contexto.

En resumen: todos los participantes en un proyecto tienen capacidad para aportar, para ello es necesario darles voz y tener la capacidad de escuchar, por otro lado existen las buenas prácticas de la industria en diferentes campos: programación, gestión de proyectos, etc… que no se deben descartar o admitir sin pasar por un proceso de análisis de las mismas en el contexto del proyecto y por último nuestras propias prácticas que también deben pasar por ese mismo análisis.

Como el contexto del proyecto varía se trata de un proceso de revisión continua, si bien, conforme vaya avanzando el mismo se reducirá el nivel de incertidumbre (por regla general) y por tanto los cambios en nuestra estrategia o prácticas serán menores.

Es un tema polémico, posiblemente con tantas opiniones como personas, probablemente muchas de estas opiniones, incluso encontradas, tendrán parte de razón.

Desde mi punto de vista la dirección de proyectos software no debe ser vista como un elemento independiente al tipo de producto que desarrollamos, es decir, hacemos software y sabemos que este proceso presenta a lo largo de su ciclo de vida una serie de particularidades que hacen que su proceso de desarrollo sea especial y distinto a otros procesos de construcción o en general a otro tipo de proyectos.

Por tanto, al menos en el desarrollo de software, la dirección de proyectos no debería ser contemplada como algo que está por encima de todo, sino que debe adaptarse, contextualizarse y personalizarse a nuestro negocio, eliminándose interfaces o elementos de proceso artificiales que en nada benefician al proyecto.

Claro que existen buenas prácticas que pueden extender a proyectos software y no software, eso es indudable y no aprovechar el conocimiento existente puede suponer errores perfectamente evitables, ahora bien, también es un error pensar que se dispone de un martillo de oro o de una bala de plata que sirve independientemente del contexto (esto puede pasar con algunas buenas prácticas, pero desde luego no con todas).

El desarrollo de software requiere especialización y la gestión o dirección de proyectos no puede mantenerse al margen.

Tal vez sea más conocido por “Esto no es la NASA”.

Alcanzar el justo medio en el análisis de una solución (ya sean requisitos, modelado de datos, arquitectura, etc…) no es sencillo, tanto es así que lo más normal es que en la mayoría de los casos nos aproximemos al mismo y exista una desviación en defecto o en exceso.

Este antipatrón se produce cuando ante una situación que requiere un análisis y en la que hay que dedicar un tiempo y esfuerzo para realizarla de manera adecuada se decide prescindir del mismo, ya que al fin y al cabo “esto no es la NASA” y tampoco es necesario una solución prácticamente perfecta.

Tan malo es intentar alcanzar algo que no se puede conseguir (la perfección) como prescindir del estudio de un problema, asumiendo que las diferentes contingencias que nos vayamos encontrando las iremos superando y que cualquier aspecto que no se haya definido tendremos conocimientos y bagaje suficiente como para completarlos por nosotros mismos (aplicando por ejemplo otros antipatrones como “el martillo de oro“, “bala de plata” o “introducción de dificultad por analogía“).

Este antipatrón se puede relacionar con todos aquellos en los que se trata la introducción de complejidad innecesaria en el desarrollo o en el producto final (por ejemplo “funcionalitis acechante” o “complejidad no indispensable“) y con aquellos donde una solución base que resuelve en determinados casos problemáticas concretas o que son aptas para proyectos concretos, se entienden que valen para cualquier problemática o concepto que se encuentra dentro de ese dominio de actuación (obviando otros factores) e incluso se extienden fuera de ese ámbito (por ejemplo, los antipatrones “todo lo que tienes es un martillo” o “bala de plata“).

En este caso la complejidad adicional al sistema se incluye al intentar hacer una analogía del mismo con otro que tiene alguna o algunas características comunes (ámbito de negocio parecido, funcionalidades semejantes, mismo tipo de cliente, mismo cliente, idéntico entorno tecnológico, etc…), es decir, se toma como base otro y en lugar de profundizar en las expectativas reales del usuario o en la complejidad del problema o del proyecto que tenemos ante nosotros, se pone la atención en intentar adaptar esa idea o esa solución.

Esto, además de poder estar alejado a lo que los usuarios quieren realmente, pueden incorporar una mayor complejidad al proceso de desarrollo y/o al propio sistema de información, haciendo necesario un mayor esfuerzo, dificultando su posterior mantenimiento y empeorando la experiencia del usuario (cuando no el cumplimiento de sus expectativas).

La mayoría de nosotros, independientemente de la experiencia que tengamos, pensamos que tenemos el remedio a cualquier problema que se nos pueda presentar en un proyecto (afortunadamente esto se cura cuando te pegas unos cuantos tortazos), ya sea porque nos ha funcionado bien en el proyecto anterior o porque lo acabamos de aprender en un curso.

Todo ello sin reparar en que no hay dos proyectos iguales y que todo lo que ocurre entre su inicio y su fin está repleto de incertidumbre.

La diferencia con el martillo de oro es que ese antipatrón se basa en una solución metodológica completa, la bala de plata trata de soluciones más concretas, de buenas prácticas que pensamos que funcionan siempre, sin pararnos a pensar dónde nos ha funcionado, por qué nos ha funcionado (si realmente nos ha funcionado) y dónde nos encontramos ahora.

Es posible que con un serrucho cortes un tronco, pero ¿puedes cortar una roca?.