archivo

Archivo de la etiqueta: enfoque

Enfoque y perspectiva o lo que es lo mismo dónde estamos aplicando nuestro esfuerzo y hacia donde queremos ir teniendo en cuenta el contexto en el que nos encontramos.

En el momento en que el enfoque no está orientado según la perspectiva o la misma no es adecuada (pueden existir diferentes causas: no se tiene en cuenta las expectativas del cliente o de los usuarios o no se han comprendido, no se interpreta correctamente o se ignora el contexto del proyecto, clientes o usuarios presionan para conseguir ciertos hitos en plazos muy complicados de conseguir, etc…), estamos llevando el proyecto hacia un final alternativo que no es válido (de ahí el nombre del antipatrón), ya que se aleja de los objetivos y expectativas reales.

Las circunstancias que pueden dar lugar a este antipatrón son diferentes, como distintas son también sus consecuencias (si bien, tienen en común el hecho de que llegará un punto donde no se verá el final del proyecto, no tanto porque esté lejos sino por el esfuerzo dedicado a llegar a supuestos finales que no lo eran):

– No cumplir con las expectativas del cliente o de los usuarios, trae problemas sobre todo si se ha actuado de manera irresponsable (acotación no pactada del alcance, calidad del software deficiente, múltiples bugs, etc…), por lo que la entrega del producto no es el final, ahora tocará una larga travesía en el desierto haciendo todo aquello que no se hizo cuando se debía.

– Ignorar el contexto o circunstancias que rodean al proyecto puede dar lugar a decisiones incorrectas o falsas expectativas del desarrollador. Si no te quieres dar cuenta de lo que hay, si no reaccionas, probablemente lleves al proyecto a un lugar equivocado.

– El cortoplacismo es agotador, hace perder cualquier perspectiva (para recoger en el futuro hay que sembrar en el presente y eso es complicado cuando todas tu esfuerzo está dirigido a cumplir con hitos intermedios) y crea la sensación de que nunca se va a llegar al final porque por cada obstáculo que se supera llega a continuación otro igual o peor.

En este caso nos encontramos con que resulta muy complicado adquirir un ritmo de trabajo aceptable ya que estaremos condicionados a la visión cortoplacista de estar continuamente apagando fuegos o atendiendo a caprichos que desvían el enfoque de nuestro trabajo a otras tareas.

Estamos trabajando en nuestro proyecto cuando de pronto, nuestro superior, el superior del superior (o en general, a alguien que manda) necesita para ya, que hagamos una tarea, dentro o fuera del ámbito de nuestro proyecto y que rompe con nuestra planificación.

Es posible que en ocasiones exista una justificación, sin embargo el problema no es ese, el problema es que se cae en la dinámica de interrumpir periódicamente el núcleo central de trabajo de un equipo, sometiéndolo a picos de trabajo con alta presión, muy exigentes y que probablemente requieran overtime, de manera que a la pérdida de productividad por los cambios de contexto hay que sumar la propia del desgaste y cansancio.

No es algo que sea exclusivo del desarrollo de software. Resulta fundamental mantener el enfoque en los objetivos para llegar a conseguirlos. En el momento en que distraemos nuestra visión en lo que no importa (o importa menos) perdemos la perspectiva en lo que importa y dedicamos tiempo y esfuerzo a tareas que pudiendo ser más o menos interesantes no permiten avanzar, a través de las mismas, en la consecución de nuestras metas.

Esto en el desarrollo de software es complicado y todavía lo es más si estás trabajando en diferentes proyectos a la vez. Sin embargo que sea difícil o las circunstancias no acompañen no deben impedir en que nos centremos, en lo posible, en los objetivos que tengamos marcados tanto en conjunto como en los distintos proyectos individuales. En el momento en que bajemos los brazos o nos dejemos llevar por una deriva negativa en el proyecto lo que es muy complicado se convertirá en imposible y eso impactará en los resultados del proyecto.

En este artículo querría destacar unos de los aspectos que con más frecuencia provoca la pérdida del enfoque en los objetivos y no es otro que los bandazos funcionales de un sistema. ¿Qué quiero decir con bandazos funcionales? No me refiero a cambios funcionales en la aplicación algo que es inherente dentro de un proceso evolutivo como es el desarrollo de software sino a cambios en el alcance y a cambios funcionales bruscos y con relativa frecuencia.

Cuando el testing rompe la fluidez en los entregables de los proyectos de desarrollo de software en una organización es necesario estudiar las causas.

Puede ser debido a que el trabajo de los equipos de proyecto son de calidad deficiente y/o que el testing impone unos procedimientos que no van de la mano con la metodología de desarrollo elegida en los proyectos.

Por regla general la culpa está repartida, es más, incluso si se analiza la situación en profundidad las causas se encuentran en la no existencia de una política de desarrollo de software en la organización que permita adoptar la solución más adecuada en los proyectos (se adoptan métodos o procesos rígidos) y en una mala orientación y comunicación de los objetivos a las diferentes partes, ya que el fin no debe ser el proceso sino la entrega de productos de calidad (evitando las causas que originan la crisis del software).

Una vez sentadas las bases, sí que se debe exigir a todas las partes implicadas en el proyecto que realicen su trabajo adecuadamente y acorde a lo que se espera del mismo. Si los desarrolladores actúan negligentemente, van en contra de la calidad, si el equipo de testing rompe la fluidez del desarrollo por circunstancias no justificadas (exceso de formalismo, celo, solicitando información que puede resultar costosa de obtener, etc…), se rompe el ritmo de desarrollo y entregas, lo cual hace perder enfoque, retrasa planificaciones y provoca la inversión de esfuerzo en tareas prescindibles (o lo que es lo mismo resta esfuerzo en tareas de mayor importancia en el proyecto), lo cual al final también va en contra de la calidad.

El testing es una ayuda muy importante en el desarrollo de software, ya que tiene como objetivo minimizar el número de errores que pasan a una etapa posterior en el desarrollo o que llegan a producción. Estas incidencias detectadas a tiempo suponen un impulso en la calidad del software y ahorran tiempo y esfuerzo. El testing es necesario, pero debe caminar de manera fluida con el proceso de desarrollo de software.

Hasta ahora se habían analizado las bondades del desarrollo iterativo incremental desde el punto de vista de su adecuación a la naturaleza adaptativa del proceso de desarrollo de software. De esta forma se podían ir realizando los oportunos cambios del producto que se está desarrollando de manera que los usuarios puedan disponer cuanto antes de unas funcionalidades que se ajusten a sus necesidades, teniendo en cuenta que el producto software se va a ir obteniendo poco a poco y que aquellas funcionalidades menos prioritarias, aún siendo importantes, tendrán que esperar a que les llegue su turno, el cual dependerá de las tareas que se hayan declarado más prioritarias y de la cantidad de cambios sobre funcionalidades ya implementadas.

Otra ventaja que tiene el desarrollo iterativo incremental, siempre y cuando establezca una estrategia de entregas frecuentes (algo que comparten las metodologías ágiles) es que permite a los participantes en el proyecto: equipo de proyecto, usuarios, responsables técnicos del cliente, mantener la atención en el proyecto, lo que viene a denominarse enfoque.

Cuando en proyectos desarrollados con metodologías clásicas tenemos períodos de análisis de meses, se termina perdiendo en muchas ocasiones la orientación en el proyecto, sobre todo por parte de aquellas personas que no tienen una dedicación mayoritaria al mismo. Esta pérdida de enfoque se traduce al final en tiempo perdido y prisas, muchas prisas, por intentar hacer en menos tiempo lo que se debería haber realizado de una manera más continua.

El área usuaria no soporta bien proyectos con largos períodos de análisis, diseño y construcción sin ver resultados. Pierden la conciencia del trabajo que está realizando el área técnica, por eso junto a la naturaleza evolutiva del proceso de desarrollo y de requisitos que realmente han cambiado respecto a su definición inicial, existe una importante tasa de cambios en las especificaciones.

Todavía resulta peor el hecho de que los usuarios pierdan el interés en el proyecto, ahí si que entrará en un riesgo importante el sistema de información. Tal vez el proyecto siga hacia adelante y se entregue un producto que se pase a producción, pero será un extraño para los usuarios que salvo que se vean obligados por sus superiores no lo utilizarán. Si al final lo terminan usando comenzará el verdadero proceso iterativo e incremental, pero con las urgencias y problemas que tiene retocar un producto en producción que más que probablemente se aleja de lo que esperaban los usuarios.

Paul Hawken es un emprendedor, consultor, autor, conferenciante y activista medioambiental americano. Su principal materia de trabajo y estudio es la sostenibilidad mediante el cambio en las relaciones entre los negocios y el medio ambiente.

Una cita significativa de Paul Kawken es la siguiente: “Una buena gestión es el arte de hacer los problemas tan interesantes y sus soluciones tan constructivas que todo el mundo quiera trabajar y tratar con ellas”.

Y no le falta razón, sobre todo teniendo en cuenta que en el día a día laboral si hay algo que suele estar presente son los problemas y si hay algo que puede afectar a una marcha correcta y fluida de un equipo de trabajo son aquellas problemas que no se tratan y gestionan de la manera adecuada.

Convertir los problemas en retos, las soluciones en oportunidades, deben ser una de las misiones del gestor, ya que de esta forma conseguirá mejorar la motivación y la productividad de los que intervienen en los mismos.

Los problemas van a seguir viniendo, pero la clave es el enfoque y el tratamiento que se les da. Si lo único que hace el gestor es despachar los problemas y no transformarlos en un trabajo interesante (no solo para el que los realiza, sino también para el que los solicita) o, al menos, en un trabajo normal (si no es posible hacer milagros), los resultados que se obtendrán con el mismo serán negativos, tanto en el corto plazo del mismo, como en el medio y largo plazo (por el desgaste de las personas que han intervenido en el mismo y también por los más que posibles malos resultados económicos que se hayan podido obtener).