archivo

Archivos Mensuales: octubre 2013

La imposición de procesos que no tienen en cuenta las personas y equipos que trabajan en la organización y tampoco a la propia naturaleza de los trabajos que se realizan está condenada al fracaso, independientemente de que consiga prevalecer en el tiempo.

La teoría debe servir a la práctica y no al revés. Lo teórico puede ser maravilloso en el papel pero si no se adapta a la realidad de la organización se puede convertir en un carga.

Si a esto le sumamos que en muchas organizaciones, cada departamento establece sus propias normas sin tener en cuenta los puntos en común que tienen con otros y sin una visión general de lo que es la organización, el problema lo único que hace es seguir creciendo.

Un ejemplo muy sencillo de esto lo encontramos en el establecimiento de procesos teóricos de gestión en los departamentos de desarrollo, sistemas y explotación de las organizaciones, los cuáles además no se han engarzado entre sí y en la práctica de su aplicación nadie hace por tratar de a través del diálogo de reducir la resistencia que producen unas normas que consideran cada departamento como estanco.

Cuando se trata de crear procedimientos se intenta en muchas ocasiones de ir hacia máximos en lugar de realizar una transición más suave que permita que los cambios se vayan introduciendo poco a poco conforme se vaya experimentado con los introducidos anteriormente y todo esto con la participación de otros agentes de la organización que puedan estar implicados o sean interesados del resultado del propio proceso.

Es cierto que Scrum es la suma de sus prácticas debidamente ejecutadas en un proyecto. Por eso cuando trato de hablar sobre qué estrategias, prácticas o metodologías suelo aplicar en mis proyectos trato de indicar que, entre otras, utilizo algunas prácticas de Scrum.

Soy de la opinión de que cada organización y cada proyecto presenta sus peculiaridades y que cuanto más nos adaptemos a ellas más probabilidad existe de que el proyecto salga adelante. Por ese motivo no hay que cerrarse entre las cuatro paredes de una metodología, la agilidad implica ser flexible y esto supone que siempre hay que poner por encima la actitud ágil que cualquier estrategia que quieras aplicar.

No se trata de reinventar la rueda sino de aplicar en base a lo que conoces de la organización, del proyecto, de tu propio equipo, del cliente y en base a tu conocimiento y tu experiencia los ingredientes que consideras necesarios, ¿qué después habrá que seguir puliendo? pues lo más probable es que sea así ya que los proyectos no son lineales y lo que funciona hoy no tiene por que ser lo más adecuado mañana.

Decía Gandhi que: “Ojo por ojo, y el mundo acabará ciego”.

En tu día a día profesional te encontrarás con situaciones en las que terceros, sean estos personas u organizaciones, te fastidian una tarea o un proyecto.

Mi recomendación, aunque sea difícil evitarlo, aunque tengas que contar hasta un millón, es que no lo tomes por la vía personal y lo entiendas siempre como algo profesional, de esta manera, además de afectarte menos como persona no te dejarás llevar por sentimientos que solo te llevarán a empeorar la situación.

La teoría es muy fácil, la práctica mucho más difícil. Para tratar de mitigar esa distancia, es conveniente reflexionar qué te ha aportado adoptar posturas en lo profesional en las que te has dejado llevar más por las emociones que por la razón y la objetividad.

Evidentemente todo tiene un límite, pero es mejor gestionarlo desde la reflexión que desde el impulso. Existen diferentes formas de poder resolver el conflicto, trata de ser inteligente y opta por aquella que sea más beneficiosa para el proyecto porque si finalmente termina con éxito esa realmente será tu victoria.

Hay proyectos donde el plazo de tiempo realmente importa porque cada día que se llegue tarde implica pérdida de mercado o de dinero.

Sin embargo lo que es realmente trascendente es el resultado final del producto y esto es así en todos los casos porque da igual si llegas a tiempo pero no consigues satisfacer a tu audiencia potencial.

Lo que quiero decir es que los plazos tienen una importancia relativa que dependerá de cada proyecto por lo que la política a aplicar respecto a los mismos no puede ser igual en todos los casos.

Lo que pasa es que como el cumplimiento de plazos es fácil de medir se tiende a evaluar el grado de evolución de un producto o del proyecto en base a los mismos y aunque puede resultar muy interesante para detectar desviaciones y tomar decisiones de interés, tiene menos relevancia que el valor que vaya ganando el producto.

Al final, el cliente no va a recordar (o al menos no lo va a tener en primer plano) si te has retrasado una semana, un mes o varios, lo que sí va a tener presente es si el producto que se ha desarrollado le resulta satisfactorio.

No se trata de trabajar sin plazos porque los mismos siempre establecen una referencia sino de relativizar su importancia en aquellos casos en los que sea posible.

Por otro lado los retrasos deben gestionarse de manera adecuada entre las partes porque de lo contrario se está jugando con algo muy peligroso como son las expectativas, es decir, todos deben ser conscientes de que no se van a cumplir los plazos estimados, deben llegar a un acuerdo de cuáles serán los nuevos y tener comprendidos los motivos que han llevado a ellos.

Cuando se trabaja en proyectos con ciclos de entrega largos se pierde la perspectiva que tiene la pérdida de un día de trabajo. Duele mucho menos y solo nos acordamos de ellos cuando tenemos que echar en los últimos meses o semanas jornadas de trabajo interminables que terminan afectando a la calidad del producto y a nuestro rendimiento a corto plazo porque una vez realizada la entrega el nivel de cansancio y hartazgo es tal que resulta complicado coger de nuevo un ritmo adecuado.

Esto es equivalente a decir que los días perdidos no se recuperan porque ese esfuerzo adicional tiene un impacto.

En los ciclos de entrega cortos cada día cuenta. El esfuerzo se reparte mejor entre los días disponibles y ahí está el burndown para recordarnos lo que pasa cuando el sprint no avanza. Si no avanza como se quisiera que sea porque nos hemos encontrado con inconvenientes no previstos (que de alguna u otra forma terminan apareciendo) y no por pérdidas de tiempo.

Esta forma de trabajar es más intensa porque se pretende, en condiciones ideales, mantener un ritmo constante. Recordemos que somos personas y que de vez en cuando es necesario levantar un poco el pie del acelerador. Esto no es equivalente a no hacer nada sino a complementar el proyecto con otras actividades que resulten beneficiosas para todos.

No solo se pierde tiempo por no aprovecharlo de manera adecuada y relajarnos en exceso, sino también se pierde a través de malas decisiones independientemente de quien sea que las haya tomado. Una mala especificación de los usuarios puede dar lugar a tirar días, semanas o incluso meses de trabajo, una mala ejecución de una funcionalidad por parte de los desarrolladores puede producir los mismos efectos, después, si no se asumen responsabilidades y/o todos no ponen de su parte llegará el desgaste en las relaciones al tratar por un lado de que las pérdidas sean moderadas y por otro de que el producto software alcance, al menos, unos objetivos mínimos.

En el desarrollo de software donde existen tantos intereses en juego resulta complicado pensar en mantener un alto nivel de éxito si no se trata de que todas las partes implicadas en un proyecto sean tenidas en cuenta y no solo por el hecho de que puedan aportar su granito de arena o se sientan escuchadas (que de por sí es importante) sino por el hecho de que se trabaja mucho mejor, con más motivación, con más confianza si se busca el beneficio mutuo que si una de las partes decide imponer su posición sobre las demás.

¿Es difícil conseguir ese equilibrio? Por supuesto que sí y ahí es donde entra no solo la capacidad del gestor y del equipo para conseguirlo sino la voluntad de todas las partes para tratar que exista esa fluidez necesaria en los trabajos que se consigue si todos persiguen el mismo objetivo y entienden que de esa forma todos saldrán beneficiados, tal vez no en la misma proporción pero sí por encima de los mínimos esperados.

La imposición de criterios o decisiones te puede funcionar en un proyecto concreto pero tienes que valorar el desgaste que ocasiona en las relaciones con los afectados ya que tal vez la confianza se pierda y/o se cree una situación en la cual solo exista el deseo de terminar cuanto antes el proyecto sea como sea y en la cual el primer afectado será el producto. Y no solo eso, tal vez se acabe con una relación que era beneficiosa o la misma quede sensiblemente perjudicada de tal manera que se tarde un tiempo en que vuelva a ser más efectiva que antes.

Está claro que tienes que mirar por tus intereses pero entre esos intereses se encuentran también que los trabajos salgan adelante y que se pueda sacar provecho de las ventajas que proporcionan las relaciones a largo plazo.

Cuando las personas que tienen mayor poder de decisión en las organizaciones y en los proyectos tomen conciencia real de todo esto, mejorarán los resultados. Quienes lo han hecho ya llevan ventaja sobre el resto.

Las personas son las que realmente sacan adelante los proyectos, las herramientas, frameworks y metodologías si son las adecuadas, ayudan, pero son accesorias ante la relevancia de las personas.

Se requiere actitud, aptitud, motivación, entender que se trabaja en equipo y una visión más panorámica, cada desarrollador tiene una proporción de cada una de ellas y su misión como profesional es seguir evolucionando y la misión de un gestor es proporcionar las condiciones adecuadas para que puedan seguir creciendo y sacar el máximo provecho posible a su potencial en cada momento y atendiendo a las circunstancias.

También el gestor debe saber calibrar qué personas son las que comparten los valores que entienden que son adecuados para la organización, el hecho de que los desarrolladores sean considerados personas no quiere decir que no tengan y no se les exijan responsabilidades, como de igual manera se tiene que premiar a aquellos que obtienen resultados y/o contribuyen al crecimiento de la organización.

La propia palabra recurso equipara, aún sin querer, a la persona con un objeto, el cual, independientemente de las condiciones, no varía su estado. Sin embargo, las personas están llenas de emociones y se ven afectadas por sus propias circunstancias personales. Esto es muy importante tenerlo en cuenta a la hora de gestionar y es una diferencia sustancial con lo que se considera un recurso.