archivo

Archivo de la etiqueta: responsabilidad

La responsabilidad y actitud (suelen ir de la mano) son dos ingredientes fundamentales para ser un buen desarrollador de software. Encuentra personas así y tendrás mucho ganado, ¿qué son técnicamente mejores o peores? Creedme, eso es secundario, esos conocimientos lo adquirirán con el tiempo pero la responsabilidad y actitud no son tan fáciles de aprender porque requieren un cambio en los esquemas mentales para aquellos que no la poseen y eso solo se consigue a través de un proceso de introspección personal que requiere bastante tiempo porque se trata de un cambio de percepción de lo que debe ser su día a día como profesional.

Como os suelo decir, no hay fórmulas mágicas, son dos virtudes importantes pero no dejan de ser dos variables más para hacerte un buen profesional y para asegurarte un equipo de personas que sabes que no te van a fallar, por lo que tampoco serán suficientes por sí mismas. Ahora bien e insistiendo en lo que indiqué en el primer párrafo, si no poseen esas cualidades, difícilmente vas a encontrar en esas personas lo que estás buscando que simplificando mucho son personas en las que puedes confiar en que van a tratar de hacer sus tareas de la mejor forma posible (independientemente de que a veces tengan mayor o menor éxito) y más si miramos sus resultados reales y comportamiento con más perspectiva, más a medio y largo plazo.

Hay una cita del novelista y dramaturgo británico William Somerset Maugham que resume perfectamente en qué consiste la responsabilidad: “Puedes hacer cualquier cosa en este mundo si estás preparado para asumir sus consecuencias”.

Precisamente de eso trata esto, de responsabilidad y consecuencias. Responsabilidad por las decisiones que tomas y responsabilidad por las decisiones que no tomas. Lo que pasa en muchos casos es que las consecuencias de la responsabilidad se tratan de esquivar, desviar a otros o si no es posible lo anterior, al menos, compartirla. Lo de compartirla es justo si la decisión ha sido tomada por varias personas cada una dentro de su ámbito de actuación y modulada a su responsabilidad dentro de él.

La autocrítica pasa por asumir la responsabilidad y consecuencias de tus decisiones, acciones y actuaciones. Ejercer una crítica eficaz sobre uno mismo implica reconocer errores y hay que tener un grado de madurez importante para que sea algo sincero y por lo tanto provechoso para seguir creciendo personal y profesionalmente.

Pero las consecuencias no pasan solo por la medición que hagas del resultado de tus actos. Si te equivocas en tu trabajo debes asumir las consecuencias, lo mismo que cuando aciertas. Muchas organizaciones han creado la cultura del nunca pasa nada ya sea a nivel general o a un grupo reducido de personas que por el motivo que sea han alcanzado ese estatus, ante eso solo se puede esperar que la situación vaya a peor (ver teoría de las ventanas rotas).

Limitarte en un rol puede llegar a ser cómodo, pero no es ágil. Tampoco es ágil ser en cada momento un comodín porque probablemente no termines de hacer de manera adecuada todas tus tareas ya que se puede ser un buen hombre orquesta pero es imposible tocar a la vez todos los instrumentos.

Es conveniente que los equipos ágiles estén formados por personas polivalentes pero teniendo en cuenta que si alguien es muy bueno en algo es conveniente que enfoque su esfuerzo en donde más provechoso puede ser su trabajo.

Conocer qué rol tiene cada uno es importante, encasillar a cada persona en su rol, un lastre. Para evitar eso es conveniente definir responsabilidades como elementos que trascienden al rol, de manera que personas con roles distintos podrían compartir determinadas responsabilidades.

Sin embargo para que esto funcione es fundamental la actitud de las personas ya que sin ella el rol tenderá a prevalecer sobre las responsabilidades porque siempre se podrá encontrar una buena excusa para ello.

Es cierto que es necesario medir bien qué responsabilidades se le asigna a cada persona, no vale todo porque eso va en contra de la persona, del equipo y del proyecto. Eso te obliga a conocer bien a todos los que participan en el proyecto, algo que no siempre se sabe al principio pero en donde hay que tener en cuenta que la asignación de responsabilidades tampoco tiene que realizarse al detalle o de manera completa al comienzo y que posteriormente se pueden realizar todos los ajustes que sean necesarios.

Un proyecto coral es aquel en el que muchos opinan y muchos toman decisiones tanto en lado de los desarrolladores como en el lado de los usuarios. En este tipo de proyectos sobran las palabras y falta responsabilidad porque cuando tantos intervienen cuesta que alguien asuma el papel de coordinador de su área.

Mi opinión es que se deben evitar este tipo de situaciones porque por intentar contentar a muchos se abre demasiado el sistema implementando funcionalidades innecesarias e incrementando su complejidad, todo esto en un contexto de falta de liderazgo y si eso se produce en el área usuaria y/o en el equipo de desarrollo tenemos un problema muy serio.

El área usuaria debe tener un Product Owner y el equipo de desarrollo un coordinador. ¿Qué dentro de cada área se quieren tomar decisiones por consenso?, ¿qué se quiere que participe y opine mucha gente? Me parece perfecto, pero el responsable de cada una de ellas lo es también de las decisiones que se toman y de las consecuencias de las mismas.

Una buena actitud para un gestor es contribuir a la creación de un ambiente en el que las decisiones se tomen por consenso, entre otras cosas porque de esta manera, se tienen en cuenta más puntos de vista, más opiniones, más experiencias, lo que hace que la probabilidad de acierto sea mayor y que las personas estén más comprometidas, porque se sienten parte y responsables de la solución.

Es importante tener en cuenta que actuando de esta manera no se reparte la responsabilidad, ya que la misma sigue siendo de la persona que tiene la última palabra (y que cobra por ello). La excepción la tendríamos en órganos colegiados donde la decisión se hace bien por consensos o por mayorías.

Este buena práctica se convierte en antipatrón en el momento que se producen alguna de las siguientes circunstancias:

– Se quiere hacer copartícipe de la responsabilidad a otras personas por si la decisión que se toma no ha sido la más adecuada. Es decir, la búsqueda del consenso se hace como mecanismo de defensa, pensando en uno mismo y no pensando en los beneficios reales que tiene para el proyecto. Esto termina degenerando, generalmente, en que solo se termina recurriendo al consenso en situaciones que pueden ser conflictivas en el caso de que salgan mal y pasando de él en el resto de los casos.

– Cuando incluso con la mejor de las intenciones, se trata de someter a consenso decisiones de carácter operativo, provocando un bloqueo en el día a día del proyecto, invirtiendo esfuerzo innecesario por parte de terceras personas que pudiera ser mejor aprovechado en las tareas u objetivos que tienen encomendado.

– Cuando teniendo que tomar una decisión en ese momento, no se toma (siendo esta la peor solución), por no haberse conseguido un consenso entre las personas implicadas.

Es muy frecuente encontrarnos con personas no solo que no sean productivas sino que su productividad neta sea negativa. ¿Por qué negativa? Porque el daño que hacen a la producción es mayor que lo que aportan y esto no es solo provocado por lo que pueden estropear, eso es casi lo de menos, sino por el impacto que tienen en la productividad de los demás.

Este antipatrón surge cuando conociéndose ese problema no se hace nada al respecto, lo que es lo mismo que admitir que tu capacidad de producción tiene una resistencia que no vas a eliminar. Lo peor de todo esto es que esta resistencia generará nuevas resistencias (teoría de las ventanas rotas) porque la cultura del nunca pasa nada es de lo peor que le puede pasar a una organización.

No se trata de generar una cultura de miedo (que es totalmente negativa) sino una cultura de responsabilidad, que es algo totalmente diferente.

El principio de Dilbert como solución a este problema es una huida hacia adelante porque lo que haces es desplazar el problema, ya que aunque lo separes de la línea de producción y lo coloques en un puesto donde sea inocuo, el mensaje sigue estando ahí: “no importa lo mal que lo hagas, que incluso te recompensaremos con ello” y eso termina calando en la organización, hasta tal punto que termina convirtiéndose en parte de la cultura de la misma.

Cuando asumes una responsabilidad lo tienes que hacer con todas sus consecuencias.

Este antipatrón surge cuando se dan las siguientes circunstancias:

– Tratan de evitar decisiones que pueden ser comprometidas, evitando el riesgo y aquellas que pueden provocar conflictos con los componentes de tu equipo y con los compañeros. Se prefiere no hacer nada o dejar que sean otros los que se muevan, de esta forma, si algo sale mal no es culpa suya (ya tratará de demostrar que no ha tenido nada que ver y que sus planes eran otros) y si sale bien, seguro que saca beneficios de la situación.

La inacción como norma no funciona porque la mayoría de las veces los problemas no se arreglan solos. Por otro lado, si tienes una responsabilidad no debes dejar que otros se quemen por ti. Puedes delegar, pero cuando delegas sigues siendo el máximo responsable.

– Cuando se equivocan, no suelen asumir su error, o solo lo hacen cuando saben que el impacto ha sido mínimo. Para ello se intenta esconder el error y dejar que sea el paso del tiempo quien lo termine de ocultar definitivamente (es la práctica más habitual porque es la que menos ruido causa). Si el fallo no se puede esconder tienden a minimizarlo y a achacarlo a causas externas, generalmente al entorno o al contexto, porque de esta forma no encontrará quién rebata sus argumentos. En última instancia, si no tienen otra posibilidad, tratarán de echar la culpa directamente (o compartiendo la responsabilidad) a una persona o a un equipo, por lo general, más débil y con pocas posibilidades de defensa.

– Pocas veces dan la cara por su equipo cuando es necesario (no de cara a la galería), ya que hay que tener en cuenta que estos conflictos serán a veces con un tercero (un cliente o un proveedor) y otras con personas o equipos dentro de la organización, que incluso se pueden encontrar en un orden jerárquico superior.

El desarrollo de software es una continua toma de decisiones, en las que se acierta y se falla, y en las que los errores a veces son graves. Intervienen personas, organizaciones distintas, en situaciones además en la que puede existir mucha presión y desgaste, además de intereses contrapuestos, en este contexto, los malentendidos y conflictos salen a la luz tarde o temprano. No aceptar esto, es no aceptar la realidad de nuestro día a día, si no estás dispuesto a asumir la responsabilidad que te van a encomendar, lo mejor para ti y para la organización es que no la asumas.