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.

Si algo ha fallado, ¿dónde queda tu responsabilidad?, ¿seguro que no has tenido nada que ver?, ¿nada de nada?. No nos gusta mirarnos al espejo cuando no nos sentimos guapos, es así.

No eres el culpable de todo lo malo que pasa en el proyecto, tampoco eres el responsable de todo lo bueno. Solo te digo que reflexiones sobre tu responsabilidad en lo que ha pasado porque si realmente has tenido algo que ver tendrás la posibilidad de corregir el problema de cara a un futuro.

Y para ser responsable no necesariamente has tenido que ser tú el que ha metido la pata, la ha podido meter otro pero lo mismo lo ha hecho porque no existían medidas de control en su trabajo o faltaba supervisión, las instrucciones no le fueron dadas de manera adecuada o porque se te pasó darle unas indicaciones que les hubiera resultado de mucha utilidad.

Esto requiere ser muy exigente con uno mismo y hay que ser muy fuerte para aguantarlo porque no somos infalibles, no somos perfectos y no somos omniscientes, por más que queramos tapar todas las vías de agua, siempre entrará agua a nuestro barco. Esta autoexigencia, esta asunción de responsabilidad no es para que cojamos un látigo y empecemos a destrozarnos la espalda, sino que es una medida de crecimiento personal y profesional, que pasa por asumir nuestros errores y en aprender de ellos tanto para nuestro presente como para nuestro futuro, todo ello desde la perspectiva de entender que somos humanos y como tal nos equivocamos y nos equivocaremos.

¿Por qué la necesidad de la figura de un responsable funcional, de un Product Owner o de un Product Manager? Pues porque incluso teniendo la organización unos objetivos bien definidos, en diferentes departamentos se tendrán prioridades distintas en cada momento no necesariamente incompatibles con los objetivos de la organización.

Si la situación de partida es el de una organización sin objetivos definidos (entiéndase objetivos definidos si están por escrito y son conocidos por el conjunto de la organización) resulta más complicado todavía armonizar las tareas de los diferentes departamentos.

Ken Schwaber describe perfectamente esta situación en la siguiente reflexión: “Ventas y marketing quieren respuestas rápidas a cada oportunidad que llama a la puerta. Los desarrolladores necesitan centrarse en el desarrollo del producto. El caos en una empresa es a menudo causada por la incapacidad de resolver estos conflictos”.

Tomando como base ese ejemplo, cada departamento se centra en sus objetivos: ventas y marketing quieren conseguir ventajas competitivas, desarrollo llevar a cabo de manera adecuada el producto. ¿Cuándo se produce el conflicto? Cuando son varias las personas de ventas y marketing la que llaman a la puerta de desarrollo, para cada una de las cuales lo suyo es lo más urgente y prioritario.

Por ese motivo cada producto debe tener un responsable que establezca las prioridades en la evolución del mismo (haciendo las consultas pertinentes dentro de su departamento) y si existen varias líneas de producto y la capacidad del departamento de desarrollo no puede satisfacer todas las necesidades que se plantean, se necesita un responsable que priorice las actuaciones a realizar sobre el conjunto de productos.

Otro de los grandes problemas que nos encontramos en este negocio es el miedo que existe a asumir responsabilidades o errores lo que puede provocar todo tipo de situaciones:

– Inacción o parálisis. El proyecto queda bloqueado ya sea porque no se toman decisiones que permitan resolver los problemas que provocan esta circunstancia (el área usuaria se desentiende del proyecto o no participa con la dedicación que se requiere, enfrentamientos personales, existen problemas relacionados con el alcance del proyecto, la calidad de los trabajos, etc…), porque no se tiene claro hacia donde tirar y para que parezca que hay movimiento se opta por enfocar el trabajo a perfeccionar una situación que no lo requiere o a tareas de poco impacto, sin atacar el problema de fondo o porque se teme que tras la realización de una tarea el proyecto entre en una fase que sea complicada de controlar (por ejemplo que tras un paso a producción serio que afecte al núcleo de la funcionalidad del sistema, que la acogida no sea la deseada, que aparezcan infinidad de errores, que el rendimiento no sea aceptable, etc…).

Esta situación no solo afecta a los proyectos sino a los propios procesos de la organización o a las relaciones entre departamentos o equipos de trabajo. En lugar de mejorar aquellos procesos que no terminan de funcionar bien, implantar un proceso que cubra un área que hasta ahora no estaba organizada o resolver problemas entre personas o entre equipos, se decide no hacer nada no vaya a ser que la solución ponga la cosa aún peor o por el simple hecho de evitar la circunstancia de asumir decisiones que provoquen un desgaste personal.

Algunos antipatrones asociados: “Parálisis del análisis“, “miedo al éxito“, “requisitos esparcidos por la pared“, “arquitectura o programación orientada a obstáculos“, “morir planificando“, “tirita“, “chivo expiatorio“, “otra reunión más lo resolverá“, “la disputa familiar“, “caballero de tres cabezas“, “corncob“, “proyecto del día de la marmota“, “callejón sin salida“, “responsable ausente“, “rodeos improductivos

– Yo no he sido (versión activa). Una persona o un grupo de personas, toman una decisión, se realiza un trabajo en base a la misma y una vez ejecutado no se hacen responsables de los resultados. Esto sucede si los mismos no han sido buenos. Si hubiera sido al revés, faltaría metal para construir tantas medallas.

Lo peor de todo es que en más ocasiones de las que sería deseable los “yo no he sido” se aprovechan de que muchos de los acuerdos son verbales y lo que queda es la palabra de uno contra la de otro (y ya sabemos lo que se valora nuestra palabra).

– Yo no he sido (versión pasiva). A una persona o un grupo de personas, se les comunica que se van a llevar a cabo una serie de actuaciones. Después, una vez realizadas, si el resultado no es satisfactorio, empiezan a decir que quién ha autorizado esa actuación.

Es pasivo, porque en este caso, pese a que se les informó y tenían la oportunidad de interrumpir los trabajos, no lo hicieron y ahora piden explicaciones.