archivo

Archivo de la etiqueta: autonomía

Jerry Weinberg considera que: “Cualquiera que haya visto a un programador trabajando… sabe lo que es la programación en sí, si al programador se le da la oportunidad de hacerlo a su manera, es la mayor motivación que puede tener el programador”.

Podemos extender la reflexión de Weinberg al concepto de desarrollador.

Estoy de acuerdo si bien es importante diferenciar autonomía de anarquía. Trabajas de manera autónoma si se te indican cuáles son tus objetivos (o bien desde tu rol en el proyecto o en la organización te los defines tu) y conociendo y respetando las reglas del juego (procesos, enfoques, metodologías, estrategias de diseño, herramientas, etc…) además de tener siempre presente que trabajas en equipo tienes libertad para realizar la solución.

Para que exista autonomía es necesario que las reglas del juego den el suficiente margen de maniobra. También es necesario entender que lo mismo todos los roles (y dentro de cada rol las personas que lo componen) no tienen la misma autonomía para realizar su trabajo ya que dependerá del tipo de proyecto, del tipo de sistema que se desarrolla, de las propias reglas del juego y de la experiencia y conocimientos del desarrollador.

El trabajo que se realiza de forma autónoma motiva y por eso es importante desarrollar este esquema de trabajo. Es cierto que al principio costará un poco que la maquinaria funcione ya que será necesario que cada uno entienda que la autonomía implica responsabilidad contigo mismo, con tus compañeros y con el proyecto y para que se pueda trabajar de manera adecuada hay que respetar las reglas el juego.

Hay quien se pierde trabajando de esa manera pero principalmente es provocado por el hecho de no entender o eludir esa responsabilidad y por la falta de una visión colaborativa en el desarrollo de software. Como es lógico implantar este esquema de trabajo requiere de personas que funcionen en él.

Llegado a un punto el esfuerzo necesario para mejorar el control que se tiene de un proyecto crece exponencialmente. Esto es así porque hay todo un universo de detalles dentro y fuera del proyecto que inciden en él.

El deseo de control lleva a la microgestión y ésta a su vez a una pérdida importante de la capacidad de autogestión del equipo, ya que todos los pasos se miden milimétricamente.

Otra consecuencia es que se tienden a centralizar muchas tareas, para ser ejecutadas directamente o, al menos, supervisadas por quien controla. Al ser la capacidad de trabajo mayor que la que puede asumir esa persona, su deseo de control se termina convirtiendo en un problema ya que se convierte en un cuello de botella y, además, su tasa de fallos se incrementa.

Las consecuencias de lo anterior son las siguientes:

– Falta de flexibilidad a la hora de adaptarse al cambio provocado por la pérdida de autonomía (llevado a un extremo, sus colaboradores dejarán de tomar decisiones incluso en aspectos de poca importancia, ante el temor de la reacción que pueda tener el controlador o por el escaso interés que muestra por opiniones de terceros), los cuellos de botella y por las normas estrictas de control que se han establecido.

– El equipo de proyecto al reducirse su margen de toma de decisiones, pierde implicación en el proyecto.

– Coste adicional en tareas, hitos o entregables relacionados con el control del proyecto y que no aportan un valor real al mismo.

La mayoría de nosotros ha caído en mayor o menor medida en este antipatrón, empujado generalmente por la presión externa y por el deseo de sacar adelante el proyecto. Es cierto que hay proyectos y equipos que requieren una gran implicación pero eso no debe confundirse con un control que sea nocivo para el proyecto.

Saber cuál es el punto exacto de control que requiere un proyecto no es fácil, porque en cada uno es diferente y es más que posible que a lo largo del proceso de desarrollo, cambie, incluso más de una vez. Una vez más, la experiencia te permitirá equivocarte menos (si es que has aprendido de los errores anteriores).

La rigidez en los procesos afectan por regla general a la autonomía de las personas que trabajan con los mismos. Tiene su lógica, más procedimientos y mayor nivel de detalle suele ser equivalente a un menor margen de maniobra.

Puede resultar razonable procesos rígidos en contextos donde el trabajo sea mecánico, de hecho el siguiente paso a eso sería la cadena de montaje donde cada secuencia en el desarrollo de un producto está mecanizada y si hay intervención humano está tremendamente reglada.

Trabajar en un contexto de este tipo donde la autonomía y la creatividad están limitadas o son inexistentes no resulta sencillo, al menos, para mi no lo es. En estos casos el trabajo se convierte en un automatismo en el que hay que tener el aguante suficiente para hacer lo mismo un día sí y otro también.

Sé que hay quienes se sienten cómodos con este tipo de trabajos: se ha adquirido un conocimiento y/o una habilidad y se pone en práctica todos los días, no hay que ir más allá ni tener otro tipo de preocupación que producir en cantidad y en calidad lo que tu organización te haya marcado. Se termina la jornada laboral y mañana será otro día.

Incluso quienes se sienten cómodo con estos trabajos no encuentran más aliciente en el mismo que el propio sueldo, es decir, el trabajo en sí no les supone ningún aliciente más.

El desarrollo de software es diferente siempre y cuando no estés encorsetado en el proceso.

Los procesos son necesarios, proporcionan un background común a los proyectos, ahora bien, deben ser flexibles y no meterse en demasiado nivel de detalle. Armonizar los trabajos resulta interesante pero no debe condicionar los proyectos si hay circunstancias que justifican una desviación de los procesos establecidos (circunstancias objetivas y no caprichos personales).

Procesos rígidos además de afectar a la propia adaptación al cambio afectan a la autonomía que los desarrolladores necesitan para hacer su trabajo con un mayor nivel de motivación y con un mayor enfoque en el problema o problemas con los que se está trabajando: la atención está en el producto y no en el proceso.

¿En qué circunstancias sueles entrar con más frecuencia en lo que los estudiosos de la productividad llaman “la zona”?, ¿suele coincidir con la resolución de problemas en los que te han dado un cierto grado de autonomía y que suponen un reto personal superarlos?, ¿suele coincidir con aquellos momentos en los que aplicas tu creatividad para dar solución a un problema o a una tarea?.

Cuando en el artículo anterior hablaba de entornos que te llenasen profesionalmente estaba refiriéndome precisamente a aquellos en los que se fomente la autonomía y la creatividad (dentro de los límites del trabajo que estás desarrollando, ya que como en otros muchos campos el exceso, en este caso, de creatividad puede dar lugar a muchos problemas).

Esa mayor autonomía hay que ganársela (y mantenerla) y eso se consigue a base de conseguir resultados dentro de los márgenes de responsabilidad que te vayan asignando.

Te pedirán unos resultados, existirán unas ciertas reglas del juego (procesos, condiciones contractuales con el cliente, etc…) y unos ciertos puntos de control (que serán más frecuentes y con más detalle en función de la naturaleza de los trabajos y del grado de autonomía que te hayas ganado).

¿No prefieres trabajar en un entorno así?, ¿no te importa eso y sí el sueldo que recibes? Cada cual tiene en la vida unas prioridades y las respeto, este artículo y el anterior los publico con el objetivo de que reflexionemos sobre esto.

Nuestro primer instinto puede ser intentar conseguir el mayor sueldo posible pero pasado un tiempo se empiezan a valorar más otras cosas si estás en un trabajo en el que no progresas (y no me refiero necesariamente a conseguir ascensos), en el que todos los días hay una crisis o en el que estás encorsetado y no tienes prácticamente margen de maniobra no es precisamente el sueldo lo que tiene más importancia. Es posible que el salario que cobres, la situación del mercado laboral o tu situación personal te tengan atado a tu organización pero probablemente si tuvieras la oportunidad aceptarías irte a otro entorno laboral que te llenase más profesionalmente incluso cobrando menos (siempre y cuando se supere el umbral de lo que consideras necesario para vivir).