archivo

Archivo de la etiqueta: gestión

Interesante la siguiente reflexión de Steve McConnell en su libro “Rapid development”: “Un equipo existe cuando dos cabezas juntas son mejores que dos cabezas individualmente”.

Para llegar a esto es muy importante la actitud de las personas. Si se considera que gran parte de quienes trabajan contigo en el proyecto no son capaces de aportarte ideas estás perdiendo la posibilidad de descubrir nuevos puntos de vista y mejores soluciones que las que tenías pensadas inicialmente.

Trabajar en equipo no es fácil ya que los desarrolladores somos muy individualistas y muchas veces la presión dificulta todavía más este asunto, pero cuando se consigue funcionar de esa manera el rendimiento de las personas crece en gran medida, no solo porque todos sean capaces de aportar al colectivo sino porque se trabaja mucho más a gusto.

Peter Senge en su libro “The Fifth Discipline” realiza la siguiente reflexión: “No impulses el crecimiento, elimina los factores que limitan el crecimiento”.

Somos expertos en poner obstáculos, en crear resistencias, en hacer todo un poco más difícil. Muchas veces no se trata tanto de poner empeño en mejorar o de progresar (que efectivamente hay que ponerlo) sino de que te dejen hacerlo.

Como gestor de personas (y no hace falta estar muy arriba en una organización para que coordines el trabajo de otros) tienes la obligación de no empeorar su desempeño individual (en primera instancia, ya que además tienes que poner los medios para que puedan seguir creciendo) y hacer que funcionen de forma adecuada como colectivo. Esto parece fácil pero no lo es en absoluto.

Muchas veces los mimbres están ahí y solo hay que poner los medios oportunos para que puedan conseguir los resultados… o de eliminar las barreras o resistencias que los limiten.

Si empiezas a tomar decisiones sin escuchar a nadie llegará un momento donde los componentes de tu equipo dejarán de expresarte su opinión y se perderá con ello todo ese valor que pueden aportar al proyecto, porque muchas veces no se trata exclusivamente de que las personas realicen sus tareas habituales, sino de que puedan aportar su visión sobre otros aspectos o circunstancias (técnicas o no) que pueden ocurrir en el proyecto.

No sabes de todo, no entiendes todo, no lo ves todo. Más personas tienen más capacidad de interpretar un problema desde distintas perspectivas. No creas que tienes siempre la respuesta para todo y que no hay mejor solución que la que tienes en mente, puede que sea buena, pero con las aportaciones de tu equipo es muy probable que sea mejor.

Todas las personas del equipo de proyecto son importantes, demuéstralo, escúchales, de esta forma no solo consigues aprovechar mejor su potencial sino que también estarán más implicados en el proyecto.

Soy muy partidario de escuchar diferentes opiniones y si al final mi solución no es válida o es mejorable, no pasa nada, se rectifica. No se trata de tener siempre la solución sino de hacer que la mejor solución posible llegue al proyecto venga o no de ti.

Hay que tomar decisiones, lo fácil es que sea otro quien las tome por ti pero eso no siempre va a funcionar porque muchas veces serás el último eslabón de la cadena teniendo en cuenta, además, que estamos todo el día tomando decisiones.

A veces se tarda más de lo conveniente en tomar una decisión y cuando se toma, aunque sea acertada, resulta que es demasiado tarde y ya no sirve de nada. No tengo que daros ningún ejemplo porque cada uno de nosotros ha vivido esto en reiteradas ocasiones en primera persona.

Es cierto que no todas las decisiones son iguales y que en unas expones y arriesgas más que en otras y que las consecuencias tampoco son las mismas. En tu rol tendrás que tomarlas y asumir tus errores de la misma forma que te llenan tus éxitos. A veces los errores serán graves y tendrán consecuencias pero, ¿quién no ha tenido errores de este tipo? El desarrollo de software es complejo y no contamos con un mapa que nos guíe hasta el éxito del proyecto, en medio podremos equivocarnos y lo mismo nuestras acciones impactan en el resultado final del proyecto pero es parte del juego, parte de nuestra profesión.

Toma decisiones, equivócate, acierta, es parte de la vida misma y nuestro día a día personal y profesional.

Sobre esto Jerry Weinberg realiza la siguiente reflexión (traducción libre): “Si no puedes soportar ser un tonto público (quedar en ridículo), no vas a tener éxito en un rol en donde todas tus acciones son estudiadas al detalle”.

Siempre existe la posibilidad de que te toque la lotería (si la juegas) pero en el desarrollo de software lo mejor es no dejar cosas al azar.

Cuando de manera desestructurada “sueltas” a un conjunto de personas en un proyecto sin analizar si realmente tienen la capacidad para llevarlo a cabo, estás esperando prácticamente que el azar haga que las cosas vayan bien, para ello, sería necesario entre otras cosas que dicho grupo se autoorganizase de manera adecuada, fuera capaz de motivarse y ser más productivo y de tener la resistencia necesaria para hasta adquirir las habilidades requeridas (no solo técnicas) para sacar adelante el trabajo. Esa transformación es posible pero muy complicada.

Ese grupo, además, contará con muy poco apoyo de la organización, salvo que sus resultados sean lo suficientemente llamativos, ya que poco se puede esperar de quiénes han confiado de manera tan pobre en el proyecto y no le han dedicado lo que necesita.

En el caso de que ante tantos obstáculos se consiga el éxito hay algo de lo que no tendrá que preocuparse ese equipo y es el de levantarse temprano el día que repartan las medallas ya el día anterior los mismos que los pusieron en el disparadero se la habrán llevado todas.

Aplicar prácticas teóricas fundadas en procesos y procedimientos que quedan muy bien en los libros (cuando vienen de libros) sin tener en cuenta cuál es la realidad de la organización, su contexto, de las personas que tienen que participar en los mismos, de la realidad económica existente, no traerán resultados acordes a la inversión realizada, no solo para implantarlas y controlarlas, que lo mismo no es el mayor gasto, sino por el hecho de cumplirlas, por el sobreesfuerzo que hay que realizar y por la reducción de la flexibilidad a la hora de afrontar un determinado proyecto.

¿Qué aportan realmente esos procesos? No todo va a ser negativo, probablemente algunos de ellos sean muy beneficiosos, pero, ¿y todos los demás?. Generalmente, en lugar de entrar en un proceso de mejora continua en el que se de valor a lo que resulta útil y se modifique, descarte o cambie el enfoque de lo que no funciona, se tiende a mantener una línea continuista con cambios poco significativos, ya que la respuesta ante la crítica o las quejas por los procesos, será no tenerlas en cuenta, creando una brecha cada vez más amplia entre quienes definen esos procesos y quienes los tienen que trabajar.

De esta forma se seguirá de espaldas ante la realidad porque no se debe ignorar a quién trabaja con esos procesos ya que nadie mejor que ellos saben si se adaptan o no lo que le toca vivir todos los días y al cumplimiento de los compromisos adquiridos.

No siempre van a tener razón los desarrolladores, a veces, no tienen en cuenta determinadas necesidades organizativas. No se trata, por tanto, de decir a todo que sí, sino de tratar de buscar soluciones consensuadas, de esta forma sí será posible buscar una alternativa rentable, sostenible y que genere menos desgaste, que se siga adaptando con el paso del tiempo a los cambios de contexto y necesidades.

Es complicado tomar tanto a nivel personal como a nivel de una organización la decisión de cambiar porque todo cambio, aún necesario, no es sencillo, sabemos lo que cuesta asumir los errores y/o salir de la zona de confort. A veces también resulta difícil cambiar sobre todo cuando cuentas con pocas alternativas.

Pero hay algo todavía más complicado que eso, una vez tomada la decisión del cambio mantener en el tiempo la fuerza y consistencia necesaria para no volver a la situación anterior o dejarlo a medias. En muchos casos el impulso inicial termina al día, semana o mes siguiente (o al segundo siguiente de haberse tomado la decisión).

Para cambiar no basta con pulsar el interruptor sino que es necesario mantener el dedo encima el tiempo necesario para que el cambio realmente sea efectivo.

El cambio no es sencillo porque no sabes realmente qué te vas a encontrar por el camino pero, en ocasiones, no te queda otra posibilidad que asumir ese riesgo cuando si permaneces inmóvil en la situación actual ves que va a ser complicado cumplir tus objetivos.

C. S. Lewis realizó la siguiente reflexión sobre este tema: “El mero cambio no es crecimiento. El crecimiento es la síntesis del cambio y de la continuidad, y donde no hay continuidad, no hay crecimiento”.

En el mundo del desarrollo de software el cambio resulta necesario porque el contexto tecnológico, clientes y competencia entre otras múltiples variables cambian, también muchos de tus objetivos.

Es evidente que es mejor partir de un contexto con recursos abundantes que de otro donde se sabe de partida que probablemente será un desastre.

En cualquiera de ambos casos no son infinitos. ¿Cuál es el problema? Cuando se parte de un proyecto con abundancia de recursos se tiende a perder el cuidado en optimizar el uso de los mismos, lo que provoca que llegado el momento se echen en falta todos aquellos que se han dedicado a tareas no prioritarias o que se han desperdiciado al perder el enfoque y la intención en el proyecto.

Su correcta administración no solo es necesaria cuando son muy ajustados respecto a las necesidades del proyecto sino que es igualmente importante cuando existe abundancia porque de lo contrario se tornará a una situación de precariedad que será mucho peor que si no se hubieran dispuesto de tantos recursos al principio ya que probablemente la envergadura del producto construido hasta esos momentos lo hará prácticamente inabordable.

Siempre tenemos que centrarnos en las prioridades y no extender la línea de desarrollo a otros subsistemas hasta que se empiece a apreciar que la estrategia de producto es la acertada. Es mejor esperar el tiempo suficiente a que uno de ellos esté en producción y se consiga un caso de éxito que trabajar con varias líneas en paralelo siguiendo una estrategia equivocada.

Centrarse en las prioridades, ser pragmático, pensar en soluciones simples, tener paciencia y también, ¿como no?, acertar, resultan esenciales para realizar una correcta administración de los recursos.

La gestión de un colectivo debe perseguir que la suma del esfuerzo común sea superior a la que se obtendría de cada elemento por separado ya que de esta forma los pasos para conseguir los objetivos serán más amplios y precisos.

Una mala gestión de un colectivo no solo no consigue eso sino que empequeñece el talento individual de cada componente del equipo, de manera que el resultado común es inferior al individual. Esta circunstancia en una actividad donde se requiere la interacción, cooperación y comunicación entre las personas resulta nefasta y lo peor de todo es que resulta demasiado frecuente.

Una base para una adecuada gestión de un colectivo es que el gestor crea en el trabajo en equipo (más allá de palabrería barata), crear espíritu de equipo, mantenerlo unido y gestionarlo de forma adecuada. Esto requiere de mucha aptitud pero sobre todo de actitud porque lo cómodo es mantener una distancia, no mancharse las manos y dejar que sean los integrantes del equipo los que se gestionen.

Sin embargo eso no funciona siempre ya que la autogestión necesita de liderazgo y, además, las decisiones del gestor (o las no decisiones) impactarán en el equipo y al ser menos precisas (cuanto más lejos te encuentres del objetivo más complicado será acertar en él) y no pensar en equipo serán una continua fuente de desequilibrio.

El liderazgo en una organización, en un departamento o en un proyecto proporciona la fuerza y constancia necesaria para superar los obstáculos, adaptarse al cambio y conseguir la mejora continua. La fuerza y la constancia no son condiciones suficientes pero sí necesarias.

El liderazgo requiere creer en los objetivos que se han marcado. Es fundamental. Su efectividad requiere también de que el resto de personas implicadas (o una gran mayoría de ellas) crean también en que la dirección que se va a tomar es correcta, teniendo en cuenta que lo mismo no es la solución más cómoda y que espera una dura tormenta antes de que empiecen a salir de entre las nubes los primeros rayos de sol.

Por tanto, el liderazgo requiere la creación de nuevos lideres que se sumen a la causa y que ayuden con su impulso a conseguir los objetivos y conseguir nuevos adeptos a la causa.

Mary y Tom Poppendieck precisamente entienden el liderazgo de esa manera: “Una organización tiene que evaluar el liderazgo como la capacidad de desarrollar líderes” y tiene su razón de ser, ya que es muy difícil que una sola persona por mucho carisma, capacidad de trabajo e insistencia que tenga pueda provocar el cambio (sí que puede ser el detonante pero se requerirá de una intensidad superior a la que esa persona puede aguantar y gestionar).

La palabra líder se dice muy pronto y muy fácil, después, en las trincheras, todo es más complicado y ahí es realmente donde se demuestra esa capacidad tanto cuando hay problemas como cuando las cosas vienen mejor dadas.