archivo

Archivos diarios: noviembre 1, 2013

Si quieres acabar con la productividad de un desarrollador o de un equipo de trabajo solo tienes que socavar su confianza y/o crear un contexto en el que se tema cometer cualquier error.

¿Se trabaja mejor con presión? A corto plazo puede valer (otra cosa es analizar el coste que tendrá después ese esfuerzo de más que se tiene que echar), más allá es un lastre porque no olvidemos que somos personas y cuando estamos sometidos mucho tiempo a una nivel de exigencia muy alto terminamos por obtener peores resultados.

También se tiende a arriesgar menos y a ir por caminos más seguros independientemente de que sea algo que convenga o no realmente al proyecto, tal vez de esa forma nadie pueda reprocharnos un error ya que al fin y al cabo hemos tirado de manual pero también de esa forma estamos limitando nuestra capacidad de aprendizaje.

Eso de ser correcto aunque no se obtengan resultados es una de las características del cumplidor y se debe huir de la creación de un contexto que haga que proliferen ese tipo de figuras. Personalmente prefiero un desarrollador se equivoque y aprenda del error que un desarrollador que no se manche las manos ya que en el primer caso existe posibilidad de evolución y en el segundo solo tendremos a alguien que quedará bien en las fotos.

No se trata de premiar el error sino de entenderlo y de dar confianza a la persona que lo ha cometido. Es cierto que la confianza no puede ser infinita y si nos equivocamos mucho más que acertamos es posible que independientemente de todo lo que estemos aprendiendo nos pidan responsabilidades y eso debemos aceptarlo como algo normal, como parte de nuestro negocio y lo que puede ser un fracaso profesional hoy mañana puede haber sido el detonante de un éxito mayor.

Decía Voltaire que: “Hay alguien tan inteligente que aprende de la experiencia de los demás”.

Aprendemos de nuestra experiencia, siendo el grado de aprendizaje proporcional no al tiempo, sino a la propia experiencia, al contexto en el que se ha desarrollado, a lo implicado que hayamos estado, a nuestra capacidad de observación, de escuchar a los demás y a la capacidad de analizar nuestros propios errores.

Pensar que siempre se tiene la razón o que nuestra opinión pesa más que ninguna, lo único que hace es limitarnos porque no debemos olvidar que hay una diferencia entre ser tu quién tiene que tomar la decisión y ser tu quién tiene que tener siempre la fórmula mágica que resuelve cualquier problema.

Cada persona puede aportar, lo único que hay que hacer es darles la oportunidad y no cerrarnos en prejuicios de si tiene más o menos experiencia, de si creo tener de base más conocimiento, de si su formación ha sido una u otra o si se encuentra o no dentro de nuestro círculo de confianza.

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,