archivo

Archivo de la etiqueta: no inventado aqui

Muchas veces cuando se decide desarrollar un nuevo sistema de información se quiere hacer tábula rasa y no tener en cuenta las aplicaciones o herramientas que venían utilizando hasta ahora. En alguna ocasiones la excusa es no dejarse contaminar por lo anterior en otros casos es que simplemente no interesa porque “no lo he inventado yo“.

Que el usuario te va a especificar lo que quiere no es suficiente para obviar lo que se venía utilizando hasta ahora. Es conveniente conocer los puntos fuertes y débiles de esas soluciones para evitar volver a caer en los mismos errores y para aprovechar todo lo positivo que tuvieran.

Los usuarios van a extrañar y mucho todo lo que en el anterior sistema les gustaba o les resolvía y el nuevo sistema no y hasta que dicha funcionalidades no las tenga el sistema o no estén ejecutadas acorde a sus expectativas, van a existir ciertas resistencias por parte de los usuarios sobre el nuevo sistema y que complicarán la puesta en marcha del mismo y el trabajo del equipo de desarrollo).

Otro aspecto positivo de tener en cuenta estos sistemas es que sabemos que al usuario le cuesta acertar con sus especificaciones (necesita iterar) por la diferencia que existe entre las expectativa que tiene y que están plasmadas en una imagen abstracta y la realidad del funcionamiento del sistema. Utilizando uno que está en funcionamiento y con años de feedback sobre el mismo tenemos un instrumento muy interesante que sirve de apoyo al usuario y a los desarrolladores.

En el desarrollo de software no existen verdades absolutas, ni tan siquiera esas que tienes tan arraigadas basadas en tu formación, conocimiento y experiencia.

A lo largo de la realización de un proyecto se parte de un contexto inicial que va a ir evolucionando y esos contextos probablemente serán diferentes a los de tu proyecto anterior y siguiente. Tenemos que adaptarnos a las circunstancias porque lo más probable es que las circunstancias no se puedan adaptar a nosotros.

Solo es posible la adaptación si estamos dispuesto a ello.

Si creemos que determinados procesos, metodologías y prácticas garantizan el éxito nos estamos creando una resistencia para la adaptación al cambio que nos condicionarán en el caso de que tengamos que aplicar estrategias que se salgan de esa norma.

No se trata de cambiar por cambiar, sino de hacerlo con intención y con sentido en el contexto del proyecto. Ambos factores (intención y sentido) lo son si analizamos y entendemos por qué es necesario salirnos del guión (siempre en relación a un contexto).

Y esta idea es extensible a ámbitos más allá de un proyecto por ejemplo al de la propia gestión de un departamento de desarrollo a la hora de eligir un framework o background base de funcionamiento, ¿debe funcionar una gestión de procesos que ha funcionado en otra organización?, ¿acaso su contexto es el mismo? No se trata de reinventar la rueda o aplicar de base el no inventado aquí, sino de interpretar esas estrategias acorde a la realidad de la organización, del Departamento, de los objetivos que se quieren lograr, del negocio y todos los factores que se consideren relevantes.

Tal vez la única verdad absoluta es que no hay verdades absolutas, o tal vez no.

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.

Este antipatrón podría considerse un caso particular del antipatrón “No inventado aquí“.

Se produce cuando a la hora de abordar un proyecto de desarrollo de software no se tiene en cuenta, ni tan siquiera para conocer cómo trabajaban los usuarios, las diferentes aplicaciones o soluciones que se venían utilizando hasta ahora.

Esto supone un gran error, ya que estos sistemas estén mejor o peor desarrollados proporcionan una síntesis muy interesante del negocio (facilitan su comprensión), permiten conocer a qué están acostumbrados los usuarios hasta ahora (para tenerlo muy en cuenta a la hora de realizar la gestión del cambio) y para saber qué aspectos de esas herramientas les gusta y cuáles no (muy interesante ya que son variables a tener en cuenta para conocer las expectativas del usuario y para determinar puntos de mejora relacionados con la productividad en el uso de las herramienta, así como en la experiencia de manejo de las mismas).

Antipatrón muy conocido y sin embargo muy presente en nuestro día a día.

Se trata de implementar o desarrollar una solución desde cero, ya sea de un producto, una metodología, de la definición de unos procesos, etc…, obviando la existencia de otras posibles soluciones ya disponibles.

Es cierto que a veces será necesario adaptar soluciones existentes en el mercado pero el esfuerzo será mucho menor que tener que empezar desde el principio y las probabilidades de éxito mucho mayores, ya que tenemos buena parte del trabajo hecho y más que probado por terceros.

Pese a esto, es frecuente encontrarnos con organizaciones, equipos de proyecto o desarrolladores que toman la decisión de que lo que está fuera no es bueno por el simple hecho de que no controlan su desarrollo, sus especificaciones, etc…, por el hecho de que no se les haya ocurrido a ellos hacerlo antes (ver antipatrón “No inventado aquí“) o bien puede ser provocado (también muy típico) de no haber estudiado diferentes alternativas de solución, antes de afrontar desde el principio una nueva.

Muchos de los productos que hoy conocemos de código abierto serían hoy infinitamente mejores de lo que son, si muchas organizaciones en lugar de intentar realizarlos ellas mismas desde cero, hubieran invertido en su desarrollo, con el beneficio añadido de que en la mayoría de los casos, dichas organizaciones además, hubieran obtenido un mejor rendimiento de su inversión.

Este antipatrón es reflejo del ego de una organización o del nuestro, negándonos a utilizar soluciones, metodologías, prácticas, herramientas, etc… procedentes de fuera por el simple hecho de que no se nos haya ocurrido a nosotros previamente.

Esto nos lleva a reinventar ruedas (intentar buscar una alternativa desde cero), reinventar ruedas cuadradas (crear una alternativa, inferior a otra ya existente) o bien a un rechazo al cambio.

Es el caso opuesto, por ejemplo a “Blowhard Jamboree” y es que generalmente a las soluciones le gustan más los tonos grises.