archivo

Archivos Mensuales: enero 2013

Hay una reflexión del actor y cómico americano Steven Wright que me parece muy interesante: “La experiencia es algo que no se consigue hasta justo después de que lo necesitas”.

Y es que siempre llega tarde a la primera cita, aunque tal vez, lo más importante es que a partir de entonces siempre llegue a tiempo. Para eso es fundamental haber extraído conocimiento de la situación y eso solo se consigue con mentalidad abierta y capacidad para reconocer que las cosas se podrían haber hecho mejor, incluso en aquellos casos donde se hayan hecho bien.

La experiencia no es acumulación de años, sino como su propio nombre indica, de experiencias, de circunstancias. Por tanto no es lineal con el tiempo y sí con la intensidad y características de las situaciones que te has encontrado.

Y sobre todo es importante tener presente que por mucho que pienses que ya has pasado por todo, te seguirás encontrando con momentos en donde mires tu reloj y veas que la experiencia vuelve a llegar tarde.

Una última reflexión, si la experiencia se alcanza al enfrentarnos con el problema y analizar los resultados, y la trasladamos al desarrollo de software, ¿es el camino los enfoques predictivos o clásicos o resultan más adecuados los enfoques iterativos incrementales?.

Los extremos no son buenos y ya sabemos que en el desarrollo de software solo nos traen malas noticias.

En un extremo tenemos la cautividad que un cliente puede tener con respecto a un proveedor o viceversa. Es un hecho que la diversificación reduce riesgos y yo lo aconsejo, entre otras cosas porque te permite respirar en el caso de que te quieran dejar sin oxígeno.

Si un proveedor te tiene cautivo y se quiere aprovechar de esa situación, lo hará, porque sabe que cumpliendo unos mínimos (que cada vez serán más mínimos) tiene el sustento asegurado. Si es el cliente quien te tiene cautivo y se quiere aprovechar, te exprimirá hasta la última gota.

En el otro extremo tenemos a clientes y proveedores que solo viven proyecto a proyecto y como tal, solo tienen en mente, respectivamente, desarrollar un producto satisfactorio y conseguir un beneficio como sea. Las intenciones de partida pueden ser buenas e incluso no haber problemas, pero llegado el momento no se dudará en entrar en una relación de desgaste con tal de conseguir los objetivos que se tenían marcados.

Este antipatrón trata de este extremo, en la falta de miras por parte de clientes y proveedores en conseguir relaciones a más largo plazo, en un contexto de colaboración y reparto de riesgos. Esto no se consigue solo con palabras, se requieren intenciones, mucho trabajo y creer en los beneficios que eso puede reportar

Considerar a clientes y proveedores como fungibles no es ninguna virtud, por mucho que se argumente que solo existe el día y a día y que este tipo de prácticas te hacen más independiente, para empezar porque fomenta la cultura del todo vale y eso es nocivo incluso a corto plazo.

Quienes entienden que la solución a los problemas del desarrollo de software está en el proceso tienen a echar las culpas a las personas: “Si el proyecto ha ido mal es porque las personas no han seguido adecuadamente el proceso o porque no han ejecutado con calidad los diferentes entregables establecidos”.

Claro que tienen culpa las personas, tanto para lo bueno como para lo malo, pero, ¿se ha analizado la influencia real que ha tenido el proceso?. Si obligas a la persona a ir por un camino que no es el más adecuado o le pones resistencias para adaptarse a la estrategia más adecuada a las circunstancias, le estás poniendo las cosas más difíciles y si ya de por sí es complicado desarrollar software, más complejo resulta si se hace cuesta arriba.

Cuando se piensa que la clave es el proceso y el proceso no termina de dar resultados, ¿qué solución terminan aplicando? Pues más proceso, más restricciones, y en teoría menos margen de maniobra para el desarrollador. Esta disminución de la flexibilidad lejos de solucionar los problemas, los agravarán y a un mayor coste.

La falta de ritmo y los parones, que con mayor o menor duración, se pueden producir en un proyecto de desarrollo de software suelen hacer mucho daño.

Hay que tener en cuenta que el equipo de desarrollo está centrado en la realización de este trabajo (independientemente de que alguno de sus integrantes comparta su tiempo con algún otro proyecto) y que si no recibe materia prima para poder trabajar, ocurrirá alguna de las siguientes circunstancias:

– El equipo de proyecto quedará parado o realizando tareas secundarias a la espera de recibir trabajo y ese coste se imputa al cliente.

– Como el cliente no suele asumir ese coste, el proveedor tratará de recolocar a los componentes del equipo en otros proyectos, de tal manera que su colaboración en los mismos sea puntual, para de esta forma poder “rescatarlos” en el caso de que haya una reactivación.

Habrá algún miembro del equipo que no pueda volver por compromisos en el nuevo proyecto en el que está (a veces lo puntual termina por convertirse en una integración efectiva en otro equipo de trabajo) y otros tardarán algo más de lo que inicialmente se esperaba. Esta situación tenderá a ir a peor conforme vaya aumentando el tiempo de parón.

Si la organización no tiene proyectos donde recolocar a algunas de estas personas y el cliente no se hace cargo de este período de inactividad, probablemente la mayoría de ellas deje de trabajar para la organización.

En función del grado de avance del proyecto y de la especialización del personal que participa en él, el impacto de que haya cambios importantes en el equipo puede ser mayor o menos, teniendo en cuenta que incluso en el mejor de los casos hay coste, porque se ha perdido la inercia existente, se requiere un tiempo para la puesta al día y para que la maquinaria vuelva a estar engrasada.

Tener la mentalidad abierta para aprender de todos es muy importante. De la competencia se puede aprender mucho, tanto de lo que nos parece bueno como de lo que nos parece malo.

Esta actitud se convierte en antipatrón cuando lo único que vemos son las virtudes de los demás, incluso en aspectos que vistos de una manera objetiva son defectos o no tienen importancia operativa.

Copiar lo bueno es positivo, tratar de copiar todo es negativo y añorar lo que no se puede copiar es dañino.

Como organización necesitas tener identidad propia, si tratas de ser una copia de tus competidores perderás casi siempre porque tu competencia llegará siempre antes, al limitarte a intentar calcar su sombra.

Este antipatrón no solo plantea ese inconveniente, presenta otros:

– Le estás diciendo implícita y explícitamente a tu personal lo bien que funcionan otras empresas del sector, convirtiéndote en el mejor captador de talento para tu competencia.

– Estás empequeñeciendo a tu organización y al conjunto de personas que la integran, lo que resta fuerza y confianza a la hora de competir.

– Cuando se trata de copiar todo o casi todo, nos estamos trayendo lo bueno y lo malo, siendo esto último lo más fácil de copiar.

Mirar para atrás sirve si nos permite aprender. Tanto del éxito como del fracaso se aprende, sobre todo de estos últimos, porque cuando las cosas salen bien o muy bien se nos suele nublar nuestro espíritu crítico.

Está bien recordar las hazañas y logros de personas que ya no están en la organización y que en un momento dado de su trayectoria profesional quisieron buscar otros destinos, lo que lo convierte en antipatrón es cuando las mismas se ponen continua y repetidas veces como ejemplo a los demás, ya sea a modo de reproche cuando los resultados no han sido los esperados o para tratar de demostrar, simplemente, que las cosas se pueden hacer mucho mejor.

Cuando se mitifica se magnifica, lo bueno es más bueno y lo malo es más malo. En este caso, las hazañas se convierten casi en leyendas y lo que fue un trabajo en equipo (porque en este negocio se trabaja de esta manera) se ha convertido en un gesto de heroicidad de un solo individuo.

El culto al mito, presenta los siguientes inconvenientes:

– Se intenta trasladar al presente resultados que personas concretas (con los equipos en los que trabajaron) consiguieron en un momento dado, generalmente exagerados por el paso del tiempo, sin tener en cuenta que el contexto de la organización y del negocio ha cambiado, de tal forma que lo mismo ahora conseguir esos objetivos (o la mitad de los mismos) resulta mucho más complicado aún invirtiendo el doble de esfuerzo.

– A las personas a las que les toca sacar las castañas del fuego en estos momentos se les minusvalora con esa continua comparación. Esa circunstancia termina provocando desmotivación y pérdida de confianza, factores que afectan directamente a la productividad.

– A las personas que continúan en la organización y que participaron en los equipos de trabajo de esos mitos se sienten menospreciadas, cuando tal vez su esfuerzo, dedicación y ganas fueron esenciales para el cumplimiento de esos objetivos.

Un equipo de personas que no se entienden, que no conectan, que no está equilibrado, es una forma de tirar talento individual a la basura porque en el desarrollo de software se obtiene provecho de ese talento cuando se pone a favor de un colectivo, en el que se rompen las matemáticas porque su valor conjunto será mayor que la suma de las individualidades. Esto es así porque se complementan conocimientos y experiencias y porque visiones diferentes de un problema ofrecen mayores alternativas de solución.

Si un equipo no funciona, el proyecto no irá bien. Y no hace falta mucho para que un equipo no funciona, como tampoco hace falta mucho para que un código no compile. Por ese motivo, es necesario hacer un esfuerzo para conformar el mejor equipo posible dentro de la disponibilidad que exista en la organización.

Este antipatrón surge cuando no se le da importancia a la formación del equipo, seleccionándose exclusivamente perfiles sin tener en cuenta a las personas, como si fuéramos simples piezas de una maquinaria que se escogen al azar, y si hay algo que no es precisamente simple son los seres humanos.

El lado opuesto del antipatrón se encuentra en dar autonomía a los equipos para que sean ellos mismos los que seleccionen a las personas que lo van a formar y decidan sobre las entradas y salidas a lo largo del proyecto. Quienes están a pie de obra saben muy bien (aunque se equivoquen) quiénes pueden ser los mejores compañeros para este viaje.

Si no se cae en malas prácticas como el amiguismo o la falta de responsabilidad es una fórmula que puede funcionar muy bien, siempre y cuando exista comunicación fluida y en confianza con los gestores (recíproca) porque no todas las variables se encuentran en el equipo, ya que hay otras que se mueven a otro nivel ya sea dentro de la organización o en las relaciones cliente-proveedor.

Hay quienes consideran que el simple hecho de que el equipo sea designado por un tercero es un antipatrón (de hecho lo denominan: equipo designado). Yo no estoy de acuerdo con que ese simple hecho constituya una mala práctica, por mucho de que, por regla general, sean más óptimas soluciones más abiertas como la que comento en el párrafo anterior, ya que el antipatrón surge por no hacer esa selección de manera responsable, pensando más allá que en el simple hecho de cubrir huecos con personas.