archivo

Archivos Mensuales: junio 2012

Cuando empiezas en esto normalmente piensas que lo realmente complicado es la programación, conforme vas asumiendo más responsabilidad y se empiezan a gestionar equipos de trabajo muchos empiezan a pensar que lo realmente complicado es eso.

No se trata de determinar qué es más fácil o qué más difícil sino de dar a cada tarea que se realiza en un proyecto su valor e importancia adecuada porque al final el éxito o el fracaso es una suma de circunstancias y cuando una de las partes es débil todo se resiente por ese punto.

Por tanto, en un proyecto todos deben sumar y dentro de su marco de actuación hacer el mejor trabajo posible.

La experiencia me ha demostrado que la promoción vertical de los trabajadores es un problema para la organización y para los trabajadores. Desde mi punto de vista se deben combinar las promociones horizontales-diagonales con las promociones verticales.

¿Por qué? Hay personas que donde realmente pueden explotar todo su talento es en una tarea especializada como puede ser la programación o la arquitectura de sistemas y que en el momento en que le sacas de ese hábitat no funcionan porque entran en juego otros factores (desgaste en las relaciones con clientes, con tu propio equipo u otros equipos de tu organización, etc…) donde no se sienten cómodos y como tal no terminan de actuar cómo deben en el puesto que tienen asignado, con lo cual hay dos problemas, estamos desaprovechando un técnico excelente y tenemos un mal gestor.

Después hay otras personas que lo mismo no son tan brillantes en tareas de índole más técnica y sí que lo son en la gestión.

Es difícil encajar cada persona en el lugar donde pueda desarrollar mejor su trabajo porque hay que entender que el contexto de una organización no es estable, a veces hay más negocio, otras veces menos y es necesario adecuar el personal a la realidad. Pero una cosa es que no debamos ser ajenos a esa circunstancia y otra que se piense que el único camino posible es la promoción vertical.

Comenta Andy Hunt que (traducción libre): “La capacidad de adaptarse al cambio rápidamente es algo que los equipos pequeños tienen por defecto que los equipos grandes nunca van a tener. Aquí es donde los grandes envidian a los pequeños. Lo que puede tardar semanas en cambiar en una organización grande puede que solo lleve un día en una organización pequeña. Esa ventaja no tiene precio”.

La capacidad de adaptación al cambio es la base de las teorías evolucionistas de Darwin y uno de los fundamentos de los enfoques ágiles de los proyectos de desarrollo de software. O cambias rápido y bien o tal vez sea demasiado tarde.

La lógica es aplastamente: algo grande y complejo requiere más tiempo para adaptarse a una nueva circunstancia ya que resulta complejo vencer a la inercia y requiere mucho esfuerzo realinear los objetivos y la acción en la dirección adecuada.

Esto lo podemos ver, por ejemplo, cuando estamos tratando con sistemas de información complejos y otros más simples. A veces por las características del proceso o procesos que se informatizan o por la estrategia de sistemas de información a emplear (sistemas integrados) nos encontramos con sistemas complejos y/o de gran tamaño, en estos casos lo importante es analizar si todo lo desarrollado tiene utilidad real o no(el ejemplo que pongo siempre del mando a distancia: de los cuarenta botones que tiene el mando, ¿cuáles son los que realmente utilizo?) con el objeto de buscar la solución más simple dentro de ese contexto (en el camino hacia la simplicidad casi siempre hay margen de mejora independientemente de la situación de partida).

En el mundo empresarial los gigantes caminan poderosos cuando se encuentran en un contexto en el que se han adaptado perfectamente y ahí pueden lucir y aprovechar su musculatura en la lucha contra otras organizaciones más pequeñas, sin embargo si estos gigantes no han consolidado engranajes que mejoren la eficiencia en el tiempo de adaptación al cambio y/o no han sabido adelantarse a él sufren mucho y se desmoronan como un castillo de arena. Ahí son fuertes las organizaciones pequeñas y de cómo utilicen esa ventaja inicial condicionará mucho sus resultados en ese nuevo contexto económico o de negocio.

No siempre todo sucede como queremos, hay circunstancias que están por encima de nosotros y que impiden conseguir los objetivos, que no trabajemos como nos gusta o que simplemente nos hagan sentirnos incómodos.

No se trata de bajar los brazos o de quedarte sentado, la paciencia no es eso o al menos yo no la veo así, sino de saber esperar sin perder de vista nuestro trabajo y sin renunciar a nuestro deseo de cambiar las cosas.

Quien sabe esperar suele tener su premio, el contexto cambia, a veces a peor pero otras muchas a mejor. En un contexto favorable generalmente todo está cuesta abajo y se consigue de manera más sencilla lo que en contextos desfavorables requiere un esfuerzo muy grande.

¿Cuántas veces el que más resiste gana? Conozco muchos casos en los que es así.

Todo tiene un límite, la paciencia también. Al fin y al cabo la paciencia es una apuesta y se gana o se pierde, por eso hay que saber cuándo abandonar y escrutar otras opciones. Bajo esta perspectiva la paciencia es la capacidad de esperar el tiempo suficiente a que surja la oportunidad o cambie la situación y la habilidad de saber cuándo se ha esperado demasiado.

La paciencia no se debe asociar a grandes períodos de tiempo. En algunos casos esperar unas horas o unos días puede considerarse paciencia, en otros casos pueden ser meses o años.

Andy Hunt considera que “Paciencia y amabilidad es poder”, creo que no se equivoca.

La suerte está ahí a veces te llega sin buscarla, otras veces nunca te llega por más que trates de alcanzarla. La suerte es un recurso que no depende de ti por lo que si realmente quieres conseguir tus metas tienes que pasar a la acción.

Y la acción requiere un esfuerzo, un sacrificio. ¿Hasta dónde estás dispuesto a llegar?.

Andy Hunt realiza la siguiente reflexión: “Decide que quieres, decide que estás dispuesto a pagar por ello. Establece tus prioridades y pasa a la acción”.

Muchas veces perdemos el ánimo cuando vemos que otros consiguen objetivos similares a los nuestros sin exponer tanto como nosotros, sin tanto sacrificio. En muchos casos nuestra percepción no es real, ya que no conocemos de manera cierta el esfuerzo que han dedicado esas otras personas. En el caso de que realmente les haya resultado más fácil será consecuencia de un contexto que en este caso ha jugado a su favor, en estas situaciones hay que entender que la vida es una sucesión de contextos en el que se suceden cimas y valles y en donde un día el viento corre a favor y otro en contra.

Todos debemos tener sueños que sean nuestros guías invisibles en el día a día. No tener sueños es conformarte con lo que tienes y rendirte realmente a la rutina.

Los sueños deben abstraerse a objetivos y estos deben enmarcarse en un marco temporal. Es una forma de acotar algo que en esencia no tiene límites pero que de no hacerlo así corremos el riesgo de que siempre se queden en eso, en sueños.

Así lo ve Andy Hunt: “Los objetivos son sueños con fechas límite”.

Alcanzar los sueños implica cumplir todos los objetivos necesarios para ello y eso requiere pasar a la acción y la misma debe sustentarse en un marco temporal aunque solo sea para controlar si efectivamente estamos más cerca o no de alcanzar los objetivos.

Al final todo se reduce a la acción, a no esperar impasibles a que otros nos pongan en bandeja lo que queremos porque probablemente eso nunca pasará.

El desarrollo de software es acción, en el día a día, en la adaptación al cambio, en las relaciones con los demás, en el tratamiento de los problemas y todo ello para alcanzar unos objetivos. Estos objetivos a veces coincidirán o no con el sueño de alguien pero lo que sí es cierto que de manera directa o indirecta afectará a los tuyos porque un factor común a muchos de nosotros es querer evolucionar como persona y como profesional.

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.

Hay momentos donde se siente muchísima frustración, normalmente cuando la visión sobre cómo deberían funcionar las cosas no coincide con la realidad que se está viviendo y de la frustración se pasa al desasosiego cuando se intuye que la situación no tiene visos de cambiar.

Ante esto existen dos posibilidades, bajar los brazos o seguir apostando por lo que uno cree. Lo fácil es lo primero, pero lo fácil se convierte en caro cuando eso supone abandonar aquello en lo que se cree, porque cuando hacemos eso, ¿qué nos queda realmente?.

Hay una reflexión de Andy Hunt que comparto absolutamente: “Solo los peces muertos van con la corriente”.

Esta cita es un lema para todos aquellos que sentimos que queremos mejorar y que nos resistimos al resultado más probable.

También debe ser un lema para los que creen que el progreso es el resultado de disrupciones sobre las tendencias, es decir, de construir nuevos contextos o nuevas tendencias como resultado de haber ido por un camino diferente (Steve Jobs fue un gran ejemplo de esto).

La cita también es extensible a la aplicación de prácticas o técnicas sin tener en cuenta el contexto, solo por el hecho de que el resto hace uso de ellas. Soy un defensor de de las mismas pero nunca defenderé su uso a ciegas, sin tener en cuenta las circunstancias sobre las que se aplica.