Mentoring: Nuevo área en el canal

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.

 

Creatividad S.A. como gestionar equipos al estilo de Pixar y Disney.

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.

 

Innovación

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. 

Cambiando tu organización (para peones)

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.

Autogestión y planning poker

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.

¿Está tu equipo preparado para autogestionarse?

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.

Tengo todos los ingredientes y esto no funciona…

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.

He terminado… Pues yo creo que no…

No recuerdo muy bien con quien tuve la siguiente conversación, casi literal :

– ¿Has terminado el programa?
– Si
– ¿Lo has probado todo bien?
– No, no he probado todavía
– Entonces no has terminado

A veces, sobre todo con los compañeros con menos experiencia, pasa que creen que terminar de programar es terminar el trabajo pero no es así, hay muchas cosas más a tener en cuenta para dar por terminado la tarea.

Aparte de las pruebas está la documentación, la deuda técnica, con sus pruebas unitarias, auditorias de código, etc

El problema es que si no se es riguroso con cuando se considera algo como terminado es que luego surjan sorpresas, porque alguien pensaba que la tarea estaba terminada cuando quedaban cosas por hacer y se tenga que dedicar tiempo imprevisto con los consiguientes retrasos.

Es por ello que es importante fijar bien los criterios dentro del equipo de trabajo, para evitar sorpresas.

Porque me preocupo tanto por las personas

Una amiga me dijo hace no mucho que debería añadir más entradas de índole técnico en el blog, para que se viese más claramente el nivel técnico que tengo.

Si me guiase por maximizar el número de visitas y mirase las estadísticas de entradas más vistas debiera de hacerlo, ya que con diferencia la que mas visitas ha tenido ha sido la que hablo sobre ant, maven y gradle.

Pero el objeto de este blog, aparte de que no es aumentar mi ego, está mas centrado en contar experiencias. Y he estado en demasiados sitios en lo que había suficiente nivel técnico pero la cultura de empresa o la visoñez de la gente acabó cargándose el «chiringuito».

Por eso me preocupa tanto esa parte. Probablemente debiera de ser tarea de recursos humanos y no de un técnico como yo, pero al final te acaba salpicando.