archivo

Archivo de la etiqueta: management

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.