Categoría: Marca Personal & Carrera

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.

Después de un cierto tiempo sin cosas relevantes que contar, aunque por mucho que en algunos sitios de la red propongan escribir siempre algo, aunque sea repetido, a mi no me gusta.

Pero en los últimos días me he embarcado en una prueba de concepto de BigData.

La idea es poder procesar los datos de la estación meteorológica que tengo, pero con una solución basada en pequeños scripts del estilo de este

Estos scripts están implementados con JavaScript con la implementación de Java para dar la posibilidad de crear los programas sin necesidad de un compilador.

Para la solución de BigData uso Infinispan/DataGrid de JBoss ya que permite utilizar soluciones BigData sin necesidad de montar una gran infraestructura como con Hadoop. Por ejemplo permite utilizarlo en modo librería, sin instalar servidores.

El proyecto lo tengo albergado en GitHub en https://github.com/inigoserrano/BigWeather/

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.

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.

Esta semana pasada he andado algo acatarrado/griposo así que he pasado bastante tiempo en la cama echo un trapo y haciendo zapping he visto algunos capítulos de pesadilla en la cocina en su versión americana.

Lo más curioso del asunto es que ves situaciones en un negocio de restauración que también he visto en sitios por los que he pasado como informático. Falta de liderazgo, por unos u otros motivos, gente que funciona por amiguismos, personal desmotivado, falta de calidad, etc.

Sobre el tema del amiguismo no me puedo quitar de la cabeza una dueña que había cogido el restaurante en el que trabajaba de camarera y no había cambiado nada así que defendía a su amigo al chef… que no sabia hacer ni una albóndiga.

Puede parecer un poco extraño, pero al final muchos de los problemas en una empresa son problemas con las relaciones entre las personas y el trabajo, no simplemente con el trabajo.

Sobre la parte de marca personal de este binomio de agilismo y marca personal estoy contento con la marcha del blog y del seguimiento que voy teniendo.

Me he apuntado al Bilbostack para ir ampliando horizontes. Hasta me he hecho unas tarjetas de visita, que aunque cada vez se usan menos, todavía hay ciertas situaciones en las que son útiles. También se supone que el curriculum está muerto, pero te lo siguen pidiendo, así que mejor tener cubierto ese flanco.

Es curioso en alguna entrevista que he hecho sonaba raro el hecho de decirles que el curriculum lo tienes en LinkedIn. Supongo que son costumbres que tardan en ir desapareciendo.

Algunos amigos y excompañeros me preguntan a ver que tal lo llevo, y la verdad es que nunca me había sentido tan a gusto. Desde que empecé aya por verano con estos temas de marca personal tengo las cosas mucho más claras sobre lo que puedo aportar, cual es mi producto, y eso da confianza.

Si me hubiese quedado sin trabajo antes de verano probablemente hubiese estado más desorientado, pero me pilló con las ideas bastante ordenadas. Ideas sobre cosas que normalmente los técnicos no solemos dedicarle mucho tiempo. Como por ejemplo responder a una simple pregunta como ¿cual es tu producto?, ¿que es lo que ofreces?.

Normalmente en una entrevista de trabajo estamos acostumbrados a soltar una retaila de herramientas, lenguajes, metodologías y clientes en los que hemos estado, diciendo por supuesto lo maravillosos que somos en esas cosas.

Pero hacer un planteamiento de, te puedo ayudar con este tipo de problemas y situaciones es completamente diferente, tanto es así que me cuesta no hacer una entrevista clásica de «leer el curriculum».

Hace algo más de un mes, cuando decidieron prescindir de mis servicios en mi antigua empresa, me propuse gestionar mi nueva situación intentando una mezcla entre marca personal y agilismo.

Empecé a utilizar evernote para tener el backlog y los sprint, porque era la herramienta que utilizaba en ese momento para organizar las ideas y pequeñas notas, pero no me acaba de convencer. Se puede hacer pero es un poco forzado. Así que he empezado a utilizar una herramienta que creo que se ajusta más a la filosofía ágil. Esta herramienta es trello.

Por otra parte una de las cosas que más me está costando es cerrar ciertas tareas, porque son como quien dice historias de usuario continuas. Es decir, buscar trabajo es una tarea continua y las historias de usuario van surgiendo conforme se te van ocurriendo ideas de como conseguirlo, así que incluso un sprint de una semana se hace largo, sobre todo si tienes en cuenta que se supone que en el sprint no debes cambiar las tareas a realizar.

Creo que debería hacer sprints incluso todavía más cortos, de un par de días. E incluso más concretos, los que he realizado hasta ahora eran un poco vagos o amplios.

Las restrospectivas normalmente no son formales porque obviamente me reuniría conmigo mismo y estoy reunido conmigo mismo hasta cuando duermo… Así que según se me ocurre algo que mejorar lo apunto o a veces incluso directamente lo hago (esto está mal…).