archivo

Archivos Mensuales: noviembre 2011

Me pasa mucho, pero entiendo que es el resultado de muchos años escuchando el mismo mantra y creyéndome las mentiras del mercado y, ¿por qué no decirlo? mis propias mentiras. Sigo hablando del producto o del servicio como el resultado final de un trabajo o el propio trabajo en sí, sin embargo no se trata de eso, se trata de que los mismos cumplan las expectativas para las que fueron contratados.

Los clientes, los usuarios, no buscan un producto o un servicio. Buscan soluciones.

El producto o el servicio es un medio, no un fin.

Barry Boehm evolucionó su modelo en espiral hacia el modelo en espiral win & win, probablemente inspirado en sus convicciones de que las personas son las que condicionan el éxito o el fracaso de un proyecto.

Desde esta perspectiva, Boehm defiende que el equilibrio entre todas las partes implicadas se consigue a través de unas condiciones de trabajo y resultados en el que todos ganan ya que de esta forma todos enfocan sus tareas al cumplimiento de los objetivos.

La visión de Boehm, resulta racional, todos luchan por el éxito del proyecto si a través de él ganan.

Sin embargo, ¿qué sucede en la realidad? pues que resulta complicado alcanzar ese equilibrio ya que depende de dónde cada parte ponga el listón de lo que considera ganar ya que lo mismo se coloca a un nivel donde no es posible que los otros ganen.

Hay autores como Jim Camp que no creen en el ganar-ganar (su conocido libro «De entrada diga no» muestra con ejemplos, basado en su experiencia, que no es posible ganar sin que otro pierda o visto de otra manera, siempre habrá alguien que en una negociación gane más que otro) y el fundamento está en que los intereses individuales nublan o incluso anulan la empatía.

Basado en mi experiencia os comentaré que este negocio es una selva y que en ella cada cual intenta sobrevivir como puede. Este contexto no resulta el más adecuado para buscar soluciones basadas en el ganar-ganar, sin embargo, dentro de él, hay que intentar ir hacia una gestión de proyectos en la cual se intente alcanzar el equilibrio del ganar-ganar (el equilibrio difícilmente se conseguirá, pero en su búsqueda se podría llegar a alcanzar una situación en la que cada parte supere el mínimo válido para cumplir sus expectativas).

Para llegar a esto es necesario que cada parte cumpla con su cometido, con lo que ha acordado y que si las condiciones cambian por el propio devenir del proyecto, se llegue a un nuevo contexto que trate de alcanzar de nuevo el modelo del ganar-ganar.

Para que cada parte cumpla, es necesario que de manera individual funcione de forma adecuada, ya que su propio desequilibrio provocará un desequilibrio entre todas las partes y la ruptura del objetivo del ganar-ganar.

Un ejemplo de esto lo podemos tener en el caso de que el proveedor no cumpla sus objetivos de productividad y empiece a poner en riesgo sus expectativas de beneficio, en ese momento probablemente, para mitigar este efecto se empiece a ver afectado la calidad del producto y/o se solicite una ampliación del presupuesto del proyecto.

Otro ejemplo lo podemos tener desde el punto de vista del cliente, cuando se encuentra próximo a consumir el presupuesto o intentar recortarlo y sin embargo todavía no tiene listo el sistema de información (por continuos cambios en el proceso de desarrollo) o quiere mantener su alcance.

El no he sido yo, como comentaba hace poco, es una constante en nuestro negocio. Son escasas las personas que asumen sus errores, todavía menos las que dan la cara y todavía más reducido las que la dan por su equipo de trabajo.

Lo fácil es echar la culpa a otro y de esta manera mantenerte a flote más tiempo. Y lo peor de todo es que a muchos les funciona ya que hay auténticos expertos en el mundo del naufragio.

El no he sido yo, presenta una variante interesante: el ventilador. Hay veces donde resulta tan complicado echar la culpa a otro o donde no da tiempo de preparar una estrategia de defensa que no queda más remedio que poner el ventilador y salpicar a todo el que coja de camino.

De esta forma, se desvía la atención en más frentes, además y por regla general, más débiles que quien ha pulsado el botón.

En los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño y de larga duración, la estrategia del ventilador suele salir bastante bien (por supuesto si el botón lo pulsa alguien desde arriba) ya que resulta complicado no haber cometido errores y tener un registro documental de todas las decisiones tomadas.

Hay una cita que dice que la programación es una pelea continua. El desarrollo de software en general es una pelea continua.

¿Hay algo malo en ello? Lo único malo es que no se gane la pelea y no se gana si no cumplimos con las expectativas que se tienen depositadas en el software.

Por lo demás, la pelea continua (si se quiere llamar así) es inherente al proceso de desarrollo porque su incertidumbre hace que se necesite que el equipo de proyecto y el resto de stakeholders tengan su enfoque en el proyecto.

También puede interpretarse como pelea continua el desgaste que supone este trabajo. Y sí, desgasta, porque desgraciadamente es difícil que los proyectos sigan un guión establecido, por su incertidumbre y por la naturaleza humana que sirve de base a los mismos.

Nadie es imprescindible, nadie. Ahora bien, no todos son igual de prescindibles.

Debe ser uno de los objetivos de una organización que el talento, la experiencia, el conocimiento, la capacidad, la actitud, la aptitud no se vaya. De la misma manera que todos somos prescindibles, no valen todos los cambios. Lo mismo quien entra es mejor que quien sale pero lo más normal es que no sea así y que por ahorrar sueldos se alguien que, pudiendo tener proyección, no puede rendir a medio plazo como el que ya no está.

Lo vemos todos los días. Conocemos gente que es capaz de desarrollar en una semana (y con más calidad) lo que otros pueden tardar un mes (o más), gente que es capaz de llevar él o ella solo el trabajo de varias personas, gente es capaz de mantener clientes por el simple hecho de la confianza que genera. Probablemente si se van, la organización siga funcionando pero, si lo hacen, muchos, incluido la propia organización, los echará de menos (mucho de menos).

Ahora bien, una organización no puede ser cautiva de sus empleados y debe tener una estructura de procesos lo suficientemente sólida y consolidada como para minimizar la pérdida de conocimiento y el impacto de estas salidas. Hablo de minimizar porque siempre habrá pérdidas.

Los procesos deben entenderse como el alma de la cultura corporativa, lo que persiste independientemente de quien la habite en cada momento, lo que da continuidad a todo. Ahora bien, al alma deben acompañarle sentimientos porque sin ellos la organización es un mero autómata.

Los procesos son el alma, pero las personas son la vida.

Creo que queda bastante claro a los lectores habituales de este blog mi creencia absoluta (que no ciega) en los principios ágiles. En este artículo voy a tratar de mostrar como los procesos, aún encontrándose en un peldaño por debajo de las personas, son fundamentales para coordinar, orquestar y armonizar el trabajo de las mismas.

Meter a personas en un proyecto es sencillo si se dispone del presupuesto adecuado y de la posibilidad de personal en la organización para ser asociado al proyecto o en caso contrario de contratar o subcontratar lo que haga falta. Ahora bien, gestionar diferentes líneas de trabajo en un proyecto, cada una de ella con sus técnicos correspondientes, en la que es posible que no compartan localización, donde cada cual solo ve la parcela de su desarrollo, no se soluciona a base de músculo, salvo que el gestor del proyecto se deje el alma en ello y exista una proactividad por parte de los jefes de equipo o analistas en que exista una coordinación y no una carrera por terminar las tareas que tienen encomendadas y quitarse el problema de encima.

En estas situaciones los procesos importan (si se ejecutan de manera adecuada, ya que un proceso es solo un conjunto de párrafos en un papel) ya que establecen el marco de trabajo y las interfaces, permitiendo por un lado que los trabajos estén integrados, que no se pisen tareas, se compartas conocimiento y se establezcan sinergias.

Si hay una cosa que no encajo nada bien es que no se asuman las responsabilidades. Es muy fácil mirar para el lado y echarle la culpa a un subordinado, a una tecnología o al mundo.

Si la culpa es tuya, asúmela, si la culpa es de alguien de ti equipo, asúmela y después lava la ropa sucia en casa.

Es muy bonito estar en primera línea para recoger las medallas. Para mi no es el mejor que colecciona medallas, sino el que da la cara por su gente y por su equipo.

Muy interesante la siguiente cita del libro «El arte de la guerra» de Sun Tzu: «En la guerra el estratega victorioso solo busca batalla después de que la victoria ha sido ganada, mientras que el que está destinado a la derrota primero pelea y después busca la victoria».

En los proyectos de desarrollo de software sucede lo mismo, antes de pelear por intentar sacar un proyecto adelante lo mejor es sentar las bases para que el mismo pueda ejecutarse con éxito: stakeholders implicados, presupuesto y plazos acordes a las expectativas, análisis de riesgos, selección de la metodología y tecnología adecuada, etc…

Después pueden pasar muchas cosas, ya que los proyectos son así, llenos de incertidumbre, en los que el escenario inicial probablemente cambiará y en donde la capacidad de adaptación al cambio determinará la suerte final del mismo, pero desde luego, si no trabajamos por conseguir unas condiciones de partida adecuadas y lo dejamos todo a nuestra destreza, probablemente se tendrá mucho perdido antes de ni siquiera haber empezado.

En cada iteración el feedback del usuario permite que el producto se acerque cada vez más a sus expectativas. Sin embargo si centramos el conocimiento y resultados de cada iteración exclusivamente en el software perdemos la oportunidad de hacer mejoras sobre el proceso, sobre las relaciones entre los distintos equipos implicados en el proyecto, de nuestras decisiones, de nuestras acciones individuales.

Mirar hacia atrás de manera constructiva permite mejorar, pero para ello es necesario hacerlo desde la humildad de reconocer nuestros errores, nuestras debilidades y que algo se podía haber hecho mejor.

Tradicionalmente las TIC se consideraban como la suma de elementos físicos (hardware) y elementos lógicos (software), como si no hubiera nadie que las manejase, construyese, implementase o alguien que quisiera obtener resultados con las mismas.

Con el paso de los años, se le empezó a dar importancia a un tercer elemento, las personas, hasta convertirse en centro del universo TIC y como no podía ser de otra manera, del desarrollo de software.

Son muchos autores los que han destacado el papel capital de las personas en los proyectos de desarrollo de software, tanto antes como después de ese punto de inflexión que supuso el manifiesto ágil.

Un ejemplo de ello lo tenemos con los autores Tom DeMarco y Timothy R. Lister que utilizaron este término en una de las obras más importantes para interpretar la perspectiva de la personas en la gestión de proyectos y equipos en el desarrollo de software. Este libro fue escrito en el año 1987 y tiene como título: «Peopleware: Productive Projects and Teams».

Sin embargo, el origen del término es anterior, del año 1977, y se relaciona con Peter G. Neumann y su libro «Peopleware in Systems».