Optimización de equipos de desarrollo
Mentoring. Un concepto bastante confuso y que a priori no parece que tenga relación con la optimización de equipos de desarrollo.
Podemos optimizar al máximo nuestra cadena de suministro de software para llevar rápidamente el software a producción. Podemos tener la arquitectura óptima de nuestra aplicación.
Pero las aplicaciones las construyen personas, las cuales muchas veces tiene muy poca experiencia. Así que se pueden convertir en el eslabón mas débil de la cadena.
Es imposible o en el mejor de los casos muy difícil montar un sistema que evite los errores humanos ya que la construcción de software es un proceso creativo.
Ayudar a los compañeros del equipo con menos experiencia a que puedan aprender más rápidamente. No solo la parte técnica de tal o cual lenguaje de programación, sino que casi mas, a como trabajar.
Es decir las lecciones que aprendes trabajando. Los errores y aciertos que ha tenido las personas con mas experiencia.
Aqui seguido encontraras todas las entradas que tengo publicadas referidas al mentoring.
Este es un tema delicado, ya que cada persona probablemente tenga una experiencia diferentes sobre que características comparten los equipos ineficientes.
En este vídeo os cuento la experiencia que he tenido yo.
En otro vídeo os contaba las conclusiones a las que había llegado Google sobre cuales eran las características de los equipos mas eficientes que tenían. Os podréis dar cuenta que lo que os cuento viene a ser la antítesis de lo que Google había encontrado como eficiente.
Hoy traigo una reflexión sobre las categorías profesionales. No tanto en el aspecto legal sino en el ámbito de las redes sociales.
Os dejo el vídeo
Esta es una de las cosas que he aprendido con los diferentes jefes que he tenido, que siempre agradecen ir con alguna solución cuando tienes que contarles un problema.
Os dejo el vídeo en el que desarrollo un poco mas esta idea.
En este video os explico una nueva lista que he creado en el canal para contener una serie de vídeos sobre mentoring para un informático. Es decir vídeos que tienen una intención de ayudar a otros informáticos, sobre todo los más noveles.
Es una serie que me hace especial ilusión, porque creo que es importante el conseguir que las personas que tenemos a nuestro cargo y que normalmente no tienen experiencia sean capaces de crecer profesionalmente.
He tenido la suerte de contar con compañeros y jefes que me han ayudado mucho, sobre todo al principio y creo que tambien es bueno devolver algo a las generaciones más jóvenes.
Os quiero hablar de un libro que me ha encantado. Para que os hagáis una idea es el primer libro en el que subrayo cosas en el Kindle. El libro es Creatividad S.A.
Es un libro del presidente de Pixar y Disney Animation, en el que cuenta como se gestó Pixar y cual es la cultura de trabajo. Una cultura destinada a fomentar la creatividad.
Aplican planteamientos muy originales, que les funcionan muy bien.
No me gusta destripar los libros y este mucho menos, creo que para cualquier persona que esté en el mundillo de gestión de equipos es una lectura muy recomendada.
Lo compré por menos de dos euros en Amazon y lo he recomendado a todos los amigos, conocidos y compañeros de trabajo a los que he tenido oportunidad.
A los profesionales con inquietudes nos suele gustar innovar en nuestro trabajo, pero cuando trabajas para terceros no siempre es fácil. Debemos tener muy presente que toda mejora supone un cambio, pero no todo cambio supone una mejora. Lo importante de la innovación es aportar valor al cliente.
Cuando te encuentras trabajando para una organización que ya tiene establecidas sus herramientas y metodologías es complicado poder innovar, porque si quieres hacerlo sobre algún área ya definida por la organización vas a tener que proponer algo que realmente les aporte una sustancial mejora, ya que sino acabamos cambiando y no mejorando. Y no es fácil salvo que te encuentres trabajando para una organización con planteamientos y herramientas obsoletas.
Para matar el gusanillo suele ser más útil el buscar algún reducto donde la organización no se haya desarrollado. De esta forma con no mucho trabajo puedes conseguir proporcionar mucho valor al cliente. Es una tarea no precisamente fácil, sobre todo cuanto más organizada y moderna sea la organización, ya que tendrá cubiertos las principales áreas.
El otro día encontré, en esa fuente inagotable de conocimiento que es el blog de Javier Garzás una entrada con la que me siento totalmente identificado.
Habla de una persona que entró en una empresa como programador y sus intentos de cambiarla de un modelo en cascada a un modelo ágil.
No tiene desperdicio y da recomendaciones que subscribo totalmente, sobre todo la primera parte en la que habla de lo difícil que es. De esto puedo dar fe, no ya para alguien que entra en la organización sin ese cometido, sino incluso cuando entras con el, como me ha pasado a mi.
Las resistencias puede llegar a ser Numantinas, incluso en sitios en los que los problemas son más que evidentes y de una magnitud muy considerable.
En resumen una lectura corta y muy recomendable para todo aquel que quiera cambiar la forma de trabajo de su organización, independientemente de que sea un peón o no.
En la entrada anterior comentaba sobre los equipos autogestionados que propugna scrum y la dificultad de pasar de un equipo gestionado de forma tradicional a un equipo autogestionado.
Hay una forma que, aunque reconozco que nunca he tenido la oportunidad de poner en práctica, me parece muy indicada para conseguir que el equipo avance en la autogestión. Me refiero al Planning Poker.
El motivo es que el planning poker implica que todo el equipo debe estimar las tareas. Esto obliga a que cada integrante del equipo se implique y entienda cada tarea por lo menos de una forma básica. En el manifiesto de Extremme Programming Kent Beck comentaba que la mayor parte de los problemas en un proyecto provenían de alguien que no había contado algo a otro.
Con las técnicas de estimación tradicionales en las que el jefe estima, el equipo no va a poder desarrollar esa faceta, así que nunca va a aprender a tomar decisiones y luego apechugar con las consecuencias. Así que tendrá difícil poder autogestionarse algún día.
Otras veces en un movimiento hacia la autogestión cada integrante del equipo estima las tareas que va a realizar, con lo que se pierde la oportunidad de que el resto del equipo las interiorice, total no lo tengo que hacer yo así que desconecto y no presto atención.
No creo que el planning poker sea infalible, porque hay cierto tipo de personas que niegan la realidad y ellos siempre tienen razón y no se equivocan. Pero este tipo de gente es tóxica, así que mejor desprenderse de ella cuanto antes, y que el resto del equipo esté involucrado no es una mala forma de hacerlo.
En scrum se propugnan los equipos autogestionados. Pero la pregunta es ¿Está tu equipo preparado para autogestionarse?
Aunque suene muy interesante la autogestión de un equipo hay ciertas dificultades para llevarlo a cabo. Normalmente los equipos, y consiguientemente los integrantes del equipo, están acostumbrados a tener un jefe que les indique lo que tienen que realizar.
Prescindir de esa figura que se encarga de gestionar el equipo puede ser traumático, por varios motivos.
Cuando los integrantes del equipo están acostumbrados a que alguien se encargue de la gestión, normalmente no se preocupan de como se gestiona, que cosas hay que tener en cuenta, que criterios hay que seguir para priorizar tareas, o para asignarlas, etc.
Así que se corre el riesgo de que cuando el equipo se autogestiona cometa muchos errores por inexperiencia.
Hay que tener en cuenta que aunque el equipo se autogestione eso no implica que todo el mundo se vuelva un experto en todas las materias. Hay que conocer los límites de cada uno y no decir o proponer cosas que luego se comprueben que no son adecuadas, ya que es contraproducente a nivel personal. Si en el equipo, por ejemplo, hay un experto en la funcionalidad del aplicativo, cuando se traten temas de funcionalidad hay que tener muy en cuenta su opinión.
La autogestión no significa tampoco la anarquía o el barra libre. Los acuerdos a los que se llegue dentro del equipo hay que respetarlos, independientemente de que nos parezcan adecuados o no. Los informáticos desgraciadamente somos muy dados a ir por libre, pero es completamente contraproducente, sobre todo porque si el equipo demuestra que no es capaz de autogestionarse, tarde o temprano les acabarán volviendo a poner a un gestor.
No sería el primer equipo que veo autogestionarse hacia el fracaso.
Algunas veces me ha venido a la cabeza la imagen que Kent Beck describe en su libro sobre la programación Extrema.
Describe los elementos que propugna como un cuadro de mandos en el que pone todos los mandos al máximo y el sistema es estable. También explica como unos con otros se compensan para hacer que el sistema sea así de estable.
A veces me encuentro en sitios en los que pese a tener todos o muchas de las herramientas de hoy día las cosas no funcionan bien. Puedes instalarte en un periquete un git y tener control de versiones, un Jenkins y tener una integración continua, un sonar y tener un cuadro de mando de deuda técnica, etc, pero no hacer que el sistema funcione.
De hecho es complicado hacer que funcione, porque tener las herramientas no asegura que el equipo las use, y si no están configuradas con un planteamiento adecuado, es probable que no les sean útiles, con lo que se hundirán como un barco con una gran vía de agua. Y reflotar algo que se ha ido a pique es complicado.
Alguna reflexión ya he dejado previamente.