archivo

Archivo de la etiqueta: enfoque

Comenta William Grosso que: “El código que aburre al programador es probable que contenga errores”. Esta reflexión es extensible a cualquier trabajo que no nos parezca lo suficientemente motivante como para centrar nuestro enfoque en él.

Cuando desviamos la atención de la tarea que estamos realizando se incrementan drásticamente las probabilidades de que cometamos errores.

La atención se desvía cuando encontramos una situación u otra tarea que nos parece más interesante y/o porque hay algo que nos preocupa o inquieta.

Cuanto más interesante (por el motivo que sea) nos parece una tarea más capacidad tenemos de mantener nuestro enfoque en la misma y menos errores tendremos como consecuencia de despistes, además de manera inconsciente le daremos más vueltas (productivas) a nuestro trabajo con el objeto de eliminar (o por lo menos reducir) posibles incidencias porque estaremos más implicados en que el resultado final sea lo más óptimo posible.

No siempre vamos a tener la oportunidad de que nos llegue trabajo interesante o motivante. En este caso si las tareas no lo son implícitamente tendremos que ser nosotros los que pongamos ese interés o esa motivación y si nos ponemos a buscar encontraremos motivos para ello y si aún así no lo conseguimos tendremos que tirar de profesionalidad para intentar que el trabajo salga de la mejor forma posible y mantener el enfoque en el mismo todo lo que se pueda.

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

– Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

– División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

– El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

– Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

El pasado ya fue, de él nos queda la experiencia adquirida que será más o menos en función de ese pasado y de la actitud que hayamos tomado ante nuestros aciertos y, sobre todo, ante nuestros errores.

El futuro es lo que construimos con el esfuerzo de hoy a partir del conocimiento adquirido en el pasado.

Es necesario marcarnos objetivos porque de lo contrario caminamos sin rumbo pero manteniendo el enfoque en el presente y no distrayéndonos con lo que puede o no puede ser.

En el desarrollo de software perdemos mucha energía y mucha motivación pensando en lo que no es o en lo que no tenemos que en intentar solucionar el problema que tenemos ahora.

Solo podremos pasar al siguiente nivel si pasamos este y para ello tenemos que mantener nuestra atención en el presente, en nuestro contexto. Esto no quiere decir que debamos cerrar los ojos ante lo que puede pasar o ante lo que nos vamos a encontrar, sino en enfocar nuestros esfuerzo en lo que hay ahora y en lo que podemos hacer dentro de esta situación actual.

Tal vez nos gustaría que el proyecto hubiera evolucionado de otra manera, que las circunstancias nos permitieran trabajar como nos gustaría y tener el producto en el estado en que quisiéramos. Es humano pensar en lo que no se tiene pero se convierte en un inconveniente cuando eso provoca una situación de bloqueo.

Sobre este tema Ken Schwaber realiza la siguiente reflexión: “Céntrate en lo que se puede hacer en lugar de frustrarte por lo que no se puede hacer”.

Muchos desarrolladores tenemos el defecto de ir a donde no nos llaman, a prestar atención a tareas que son ajenas o que no deberían ser prioritarias y como consecuencia de ello no ponemos todo nuestro enfoque, energía y atención en lo que debe ser nuestro trabajo.

El tiempo es limitado, si lo repartes mal lo prioritario se resiente.

El inconveniente de meterte donde no te llaman no es solo el tiempo perdido sino los líos en los que te terminas metiendo que a su vez requerirán más tiempo y te quitarán concentración en tu trabajo. Generalmente no sienta bien que te metas en los asuntos de otro como a ti tampoco te suele gustar que se metan en los tuyos.

Sé que es difícil estar ajeno a todo pero sabemos que tan importante es prestar atención a lo prioritario como no hacerlo en aquello que ni nos va ni nos viene. Quienes consiguen centrarse en lo suyo (o hacerlo más tiempo) tienen una gran ventaja sobre aquellos que no lo hacen ya que estos últimos tienen que recorrer más kilómetros para llegar al mismo destino.

Es lo que digo muchas veces: el talento es importante pero la actitud y la forma en que se emplea es lo que realmente marca la diferencia. El talento solo, es fuerza bruta que a veces puede dar resultados y otras no conseguir nada o incluso empeorar la situación ya que hay que tener en cuenta que esto es un trabajo en equipo y dentro de ese equipo, si no funcionas no quiere decir que sumes cero sino que lo más probable es que restes.

Es cierto que está haciendo daño a la extensión de los enfoques, prácticas y metodologías ágiles el hecho de que se considere la aplicación de estas estrategias como el martillo de oro que resuelve todos los problemas relacionados con el desarrollo de software y que permite conseguir que todos los proyectos terminen con éxito.

Nada asegura de antemano el éxito, la agilidad tampoco. Todos hemos tenido éxitos y fracasos con enfoques clásicos en el desarrollo de software y también los tendremos con enfoques ágiles.

Entonces, ¿qué aporta la agilidad? una aproximación más natural a las características inherentes al proceso de desarrollo de software y por tanto, proporcionarán unas soluciones más acordes a la problemática que nos encontraremos en los proyectos. Siempre será más fácil alcanzar una meta remando a favor de corriente, siguiendo un recorrido natural que aplicando enfoques o metodologías que no se adaptan a la naturaleza del desarrollo de software.

Es importante, desde mi punto de vista, que en las tareas de difusión de los enfoques ágiles de desarrollo de software se incida precisamente en lo que aporta al proceso de desarrollo como consecuencia de asumir que éste se realiza bajo un contexto de incertidumbre y dejando claro que la misma puede acabar con el proyecto y el producto incluso habiendo aplicando principios o metodologías ágiles de manera adecuada y que la propia aplicación de los mismos no significa nada si el contexto no acompaña o si la ejecución de sus prácticas o del propio producto no se realiza de manera adecuada. Son muchos puntos donde se puede romper la cuerda.

Agilidad, sí, realidad, también.

El enfoque consiste en concentrarse en una serie de objetivos que pueden ser abarcados de manera efectiva (que se le pueda dedicar la atención que realmente necesitan) y simultánea dentro de un contexto real, es decir, teniendo en cuenta la cantidad de esfuerzo que se le puede dedicar a ellos tanto de manera individual por cada una de las personas que participan directamente en los diferentes proyectos como del colectivo de la organización.

Esto implica seleccionar unas líneas de actuación y desechar otras, ya que por la propia definición del párrafo anterior, se trata de dedicar el tiempo que realmente necesitan cada una de ellas. Si se reparte el tiempo individual y del colectivo en un mayor número de tareas que las que pueden soportar, no se le podrá dedicar a cada una de ellas el tiempo que necesitan.

Por tanto, hay que elegir y no siempre será sencillo porque en muchas ocasiones habrá que seleccionar varias alternativas dentro de un conjunto de ellas que también podrían resultar válidas o producir buenos resultados.

Steve Jobs, resumía perfectamente en una cita lo que era el enfoque (de hecho el enfoque era esencial en el método de trabajo de Apple y de Jobs, sobre todo tras su vuelta a la compañía en 1997) y lo que implicaba: “La gente piensa que enfocarse significa decir sí a aquello en lo que te enfocas, pero no es así. Significa decir no a otras cientos de ideas buenas que hay”.

Hay una cita de Steve Jobs que me parece rotunda: “Estoy tan orgulloso de lo que no hacemos como de lo que hacemos”.

Enfocar los esfuerzos hacia lo realmente importante, hacia aquellas tareas y proyectos que sabemos que podemos hacer bien, que nos pueden proporcionar un beneficio y eliminar todas aquellas que son una carga permitirá optimizar el rendimiento y los resultados.

Saber a qué decir que sí y saber a qué decir que no, es tan importante tanto a nivel de decisiones tácticas o estratégicas a nivel organizativo como dentro de un proyecto.

Eliminar lo intrascendente, lo que requiere un gran esfuerzo a cambio de resultados mediocres, permitirá que nos centremos en hacer mejor lo que realmente resulta importante.

Menos es más si sabemos donde orientar nuestra dedicación.