archivo

Archivo de la etiqueta: contexto

Para Bill Langley: “El plan de proyecto perfecto es posible si uno primeros documentos es una lista de todas las incógnitas”.

Quien no es consciente de eso realmente no es consciente de la realidad de un proyecto de desarrollo de software, ni.

Tampoco serán conscientes de que el objetivo final es conseguir el mayor valor posible del producto dentro del contexto en el que se ha desarrollado porque lo mismo el plan inicial impone restricciones que suponen una limitación o una resistencia si no se adapta a la realidad que nos estamos encontrando en el proyecto.

Y no solo se trata de que el contexto cambie y/o imponga una atmósfera diferente a la esperada, sino que también estamos las personas y no somos infalibles, los desarrolladores no lo son, los usuarios tampoco. Nos vamos a equivocar y por mucho que se pretenda prever eso, será muy complicado acertar cuándo, cuánto y cómo.

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).

El desarrollo de software es cuestión de contextos. Los proyectos se desarrollan en contextos que pueden variar a lo largo de su ejecución. Trabajas en el contexto de una organización, en el contexto de un tipo concreto de clientes, etc…

Una cualidad muy importante que debemos tener los desarrolladores de software es la humildad. Nos cuesta ser humildes, tal vez consigamos dar esa imagen hacia afuera pero en nuestro foro interno pensamos otra cosa. Generalmente cuando nos falta humildad la realidad está ahí fuera para darnos fuerte y cuanto más alto pensemos que estamos más dura será la caída.

Puedes ser muy bueno pero no serás muy bueno en todos los contextos o por lo menos tardarás años en alcanzar ese nivel (si tienes la oportunidad de adquirir experiencia en esos contextos) y por supuesto nada te garantiza el éxito.

Es importante tener eso presente porque cuanto más conscientes seamos de eso más centrados estaremos en el proyecto. El exceso de confianza no es bueno (como tampoco lo es su falta) ya que pierdes el enfoque en el proyecto y tomas decisiones sin contar con toda información (en muchos casos, la opinión de tus compañeros que viven más de cerca el proyecto o que llevan más tiempo trabajando en ese contexto).

No lo olvides, ser bueno en un contexto no te garantiza serlo en otro. Las condiciones no son las mismas aunque existan determinados elementos en común. Necesitarás adaptarte a ese nuevo entorno y eso requiere tiempo.

Un error muy común en los planes de sistemas es que solo tienen en cuenta el contexto actual (hay muchos que ni siquiera eso, se basan en un modelo general o en un modelo que se han utilizado en otras organizaciones similares y se tratan de ajustar) y muy poco la posible tendencia de la organización.

Incluso teniendo en cuenta esa tendencia, no tienen en cuenta la necesidad de revisarlo cada cierto tiempo (se puede establecer un período fijo, nunca más de un año y abriendo la puerta a actuaciones de urgencia en caso de modificaciones sensibles de contexto).

Una organización que no tenga como objetivo racionalizar los sistemas de información (y en general las TIC) tendrá la pesada carga de mantener un parque de aplicaciones superior al necesario (con tecnologías diferentes) y muchos datos incoherentes lo que complica, cuando no hace casi imposible, la explotación global de esa información, algo que puede ser fundamental para tomar decisiones tácticas y estratégicas en la organización.

Es fundamental, por tanto, tener una estrategia que vaya hacia la racionalización, yo a esto lo denomino plan de sistemas (no hace falta generar una enciclopedia para llevarlo a cabo, lo importante es tener claro hacia donde se quiere ir) y que tenga en cuenta los contextos. Si es necesario tenerlo en cuenta en un determinado proyecto de desarrollo de software, ¿cómo no tenerlo en cuenta en una estrategia que tiene un mayor recorrido?.

Tom DeMarco realizó la siguiente reflexión en su libro “The Deadline: A Novel About Project Management” (1997): “El problema de los procesos estándar es que la gente pierde la oportunidad de tomar importantes atajos”.

Cuando los procesos son tan rígidos y parece que lo único importante es cumplir con ellos se pierde la visión de que no se trabaja para el proceso sino para realizar un software de calidad.

Esta visión negativa del autor de lo que supone una gestión balanceada hacia el proceso donde las personas pasan a ser algo con menos importancia ha sido una constante en DeMarco desde que en el año 1987 publicase junto a Timothy Lister el libro “Peopleware: Productive Projects and Teams” que extendió precisamente el concepto de Peopleware en el que sitúa a las personas como elemento principal en el desarrollo de software (el concepto fue utilizado inicialmente por otros autores, datándose su origen en el año 1977).

Es bien sabido que los fundamentos del Manifiesto Ágil son anteriores a su publicación, en el caso de la publicación indicada nos encontramos catorce años antes (y veinticuatro si consideramos el origen del concepto).

Es normal que entonces se tuviera problemas con una orientación a procesos descompensada y desgraciadamente sigue siendo normal ahora, entre otras cosas por la dificultad que tenemos los seres humanos de aprender de nuestros errores y porque en entornos académicos durante muchos años se ha hablado mucho de procesos y poco o nada de las personas.

El proceso debe establecer un marco general de trabajo con la suficiente flexibilidad para permitir una adaptación a los diferentes contexto que nos encontramos en los proyectos de desarrollo de software y a los cambios que se producen en los mismos y se tienen que definir con la finalidad de cumplir una serie de objetivos establecidos por la organización, entre los que nunca estará el propio proceso en sí.

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.

Mientras un proceso esté implantado hay que respetarlo y solo aplicar excepciones cuando sea absolutamente necesario. La solución no es entrar en una situación de conflicto cada vez que se quiera pasar por encima de los procesos, sino de si no funcionan, cambiarlos.

En caso contrario se entra en una espiral de desgaste que no lleva a nada bueno, ya que frente a los procesos habrá siempre un conjunto de personas encargadas de que se respeten y otro conjunto de personas que tendrán que sufrirlos.

Los procesos no son de nadie en concreto sino que son de todos, por tanto, no se deben defender como algo propio sino que se debe buscar una versión de los mismos que se ajuste a las necesidades y contexto real de la organización, siendo lo suficientemente flexibles a las casuísticas que se pueden producir en el día a día y en los proyectos y dejando una puerta abierta a su modificación ya sea por el objetivo de la mejora continua o porque el proceso deba adaptarse a un cambio de contexto.

Por tanto, los procesos son instrumentos, no lo olvidemos, si son demasiado rígidos o si no cumplen su propósito deben cambiarse, en caso contrario suponen un lastre y consiguen precisamente el objetivo contrario al que se persigue, es decir, en lugar de conseguirse un orden y una armonización en las actuaciones se llega a un orden y armonización prácticamente ficticios (se buscará cumplir con el proceso independientemente de la calidad de los trabajos) y a una reducción de la calidad final y/o de la productividad.