Buenas,
en estos días cuando la cosa está bastante complicada, una de las herramientas que tenemos para salir adelante es mejorar la forma en la que trabajamos. Los que trabajamos en informática sabemos que desde hace bastante tiempo el estereotipo de trabajo repetitivo de 0900 a 1700, durante 30 años en el mismo sitio, es un imposible. Jose Manuel Alarcon ha escrito un post muy bueno al respecto, llamado “Artesanos del Conocimiento”, y uno de los puntos que más resalta en este post es la necesidad constante de mejorar que tenemos en nuestra profesión.
Pero cuidado, muchas personas han entendido mal el mensaje. Piensan que lo que tenemos que hacer es estar al día de todas las nuevas tecnologías que van apareciendo, conocer todos los nuevos productos que salen y adorar a cualquier nueva tendencia que prometa un futuro más brillante y pacífico. Cuando esto es solo un 10% de nuestra nueva responsabilidad. El otro 90% es un poco más complicado, ya que requiere que apliquemos eso que pocas veces utilizamos que se encuentra un metro por encima de nuestro culo (un metro aproximadamente, aunque existen muchos casos que el culo está conectado directamente con el cerebro). En este 90% restante se requiere pensar, se requiere aprender de los conocimientos que poseemos y a partir de las experiencias que tenemos, proponer cambios para mejorar la forma en la que trabajamos.
Por ejemplo, es muy simple estar suscrito a los 10 blogs más influyentes del la blogosfera y seguir a los 10 cracks que más opinan sobre diferentes temas de informática. Con dedicar 60 minutos al día a leer estos blogs, y darle un rápido vistazo al twitter cada tanto, ya podremos estar al tanto de todas las novedades. Habremos cambiado la forma de trabajo artesanal de nuestros padres, donde aprendías una profesión para toda la vida; y aplicaremos una nueva premisa que es la de la formación constante. Podremos tener un status social más avanzado, donde nuestros compañeros nos mirarán y se preguntarán cosas cómo: “¿De dónde saca tiempo para estar al día de todo?”; e incluso podremos llegar a tener un club de fan al mejor estilo de Justin Bieber.
Sin embargo si a toda esta información que leemos no la procesamos correctamente, esta forma de trabajo no sirve para nada. No sólo tenemos que leer, tenemos que aprender a aprender. En la gestión de proyectos informáticos es imprescindible conocer nuevas formas de trabajo, nuevas herramientas y nuevas tendencias; pero es mucho más importante entender como podemos aplicar las mismas a un escenario concreto para obtener buenos resultados. Tenemos que saber, que no hay fórmulas mágicas que solucionen todos los problemas; y que además una técnica tan vieja como el “refactoring” no solo es aplicable a los desarrollos sino también a la forma de trabajo y de gestión.
En muchos casos, existen personas/organizaciones que se esmeran por definir “un proceso” que sea útil tanto para proyectos de desarrollo de 2 meses de duración, como para proyectos de 2 años. Que además también sirva para equipos de trabajo de 5 personas y para equipos de 200 personas; y finalmente, que se pueda utilizar para equipos de trabajo que trabajen todos en el mismo sitio, como para equipos de trabajo distribuidos. Cuando nos encontramos en estos casos, no es raro que para crear este proceso se esté invirtiendo en un proyecto de 2 años de duración. Donde, obviamente, las premisas al día 1 de enero de 2010 no son las mismas que las premisas al 1 de enero de 2012, etc. etc. etc.
En el caso anterior, seguramente los agilistas extremos tendrán más de una úlcera y comenzarán a evangelizar con el ABC de Kent Beck sobre AGILE y las tendencias de los últimos 10 años. Por otra parte, los amantes de los procesos, se dedicarán a destruir el Amazonas creando manuales de procesos que contemplan 1000 situaciones que nunca se darán en ningún proceso, y que luego serán un libro muerto en algún armario de una organización. Seguramente existirá una 3ra línea de trabajo, que intentará conocer las necesidades reales de esta persona/organización y a partir de las mismas; creará una propuesta con una solución. En todos los casos, no sirve de nada la solución propuesta, sino tenemos en cuenta que cada un período determinado tenemos que analizar la forma en la que estamos trabajando y ver si podemos mejorar la misma.
En el mundo AGILE esto se conoce como una retrospectiva, y TODOS los agilistas que conozco son amantes de crear reuniones de retrospectiva. Sin embargo, estas reuniones mal llevadas, solo suponen una pérdida de tiempo que poco aporta a un proyecto y mucho menos a una organización. Como no voy a escribir de esto en este post, dejaré la referencia a un libro que me ha encantado sobre este tema > Agile Retrospectives: Making Good Team Great (http://pragprog.com/book/dlret/agile-retrospectives). En CMMI también se toma en cuenta este modelo, por algo la “I” es de Improvement y la de “M” de Model. Para CMMI (bien entendido), los procesos, las personas y las herramientas tienen el mismo valor en el triángulo de valores. Cuidado, esto te puede gustar o no, pero es una forma de organizar y de gestionar que también es válida en muchos casos. Si quieres invertir dinero en un libro que te explicará lo mismo que las guías de CMMI, pero con un toque más humano, pues CMMI for Development®: Guidelines for Process Integration and Product Improvement (http://www.amazon.com/CMMI-Development-Integration-Improvement-Engineering/dp/0321711505/ref=cm_cr_pr_product_top).
En resumen, la mejora constante de la forma en la que trabajamos es igual de importante que las tecnologías con las que trabajamos. Es más, conocer nuevas formas de trabajo nos ayudará a mejorar las guías con las que estamos trabajando y además no ayudará a tener una perspectiva más amplia sobre cómo podemos trabajar.
Pero antes de terminar, tengo que señalar 2 problemas grandes que tenemos en este aspecto. Por un lado, el estar al tanto de “todo lo último” nos lleva a situaciones como la que comenta Rodrigo Corral en este tweet.
Hemos fallado con Scrum no es un motivo para adoptar Kanban. El motivo debe ser que Kanban es lo que mejor se adapta a tus necesidades.
El solo hecho de que algo falle, y que exista una solución alternativa no significa que la debamos adoptar lo antes posible. Como muchas veces he visto lo que comenta Rodrigo, no he podido resistirme a responder con una analogía un tanto molesta:
@r_corral también se puede aplicar >> "he tenido un accidente en coche, ahora me cambio a la moto"; mejor aprender a conducir no?
Finalmente, el 2do problema es el siguiente:
¿Cómo es posible que los problemas en la informática sigan siendo iguales hoy que los que teníamos hace 20 años?
Parece una contradicción, ya que metodologías como SCRUM nacen allá por el 1993, pero todavía hoy seguimos teniendo los mismos problemas. Yo escribí mi opinión al respecto en mi libro, y como veo que el post es un poco largo, lo dejo como pendiente para otro post.
Saludos @ Home
El Bruno
Links
