archivo

Archivos diarios: diciembre 10, 2011

A todos nosotros nos cuesta mantener una regularidad en nuestros resultados en los proyectos de desarrollo de software. Por un lado nos encontramos con la complejidad inherente a todo proyecto de estas características y por otro nos enfrentamos ante la dificultad de mantener siempre el mismo nivel en todos los trabajos y es que no debemos olvidar que somos seres emociales y que nuestra motivación, productividad y resistencia no será la misma siempre y debemos tener en cuenta que nuestro conocimiento y experiencia no es suficiente sin el motor necesario para ponerlas en práctica.

A lo anterior hay que sumar que es posible que consigamos unos resultados adecuados en determinados tipos de proyectos, con determinados tipos de clientes y/o contextos, entre otras cosas porque estamos entrenados a trabajar en ese tipo de condiciones y que sin embargo en otro tipo de proyectos o circunstancias nuestro rendimiento o capacidad disminuya.

Es cierto que tenemos de lado nuestro bagaje profesional y que no es lo mismo enfrentarse a algo nuevo teniendo unas bases sólidas que sin ellas pero también lo es que nuevos contextos pueden requerir de prácticas que discrepen con las que estamos acostumbrados a utilizar y que en otros ambientes suelen producir buenos resultados.

Y nos podemos adaptar finalmente a este nuevo tipo de proyectos o no y eso no quiere decir que seamos peores profesionales, ya que la única conclusión real que se puede sacar es que hay determinados contextos en los que no podemos aprovechar nuestro talento, potencial y conocimientos. La clave, por tanto, es tener la posibilidad de que cada persona pueda trabajar en aquellos proyectos donde realmente puedan aprovechar sus posibilidades.

Es cierto que eso no va a ser siempre posible, pero también lo es que muchas veces lo es y sin embargo la asignación de personas a proyectos parece ser el resultado de un juego de dados.

Cuando no existe un equilibrio entre los stakeholders, cuando existe una situación de desgobierno funcional, el único actor que suele quedar solo ante el peligro es el equipo de proyecto (y los responsables técnicos del cliente).

En esta situación, donde casi todos se desmarcan, la ventaja de la aplicación de metodologías o principios ágiles se difumina ya que no hay feedback o si existe no está respaldado por nadie que se haga responsable y después, pasa lo que pasa, que la culpa siempre es del desarrollador porque al fin y al cabo es el que siempre está allí y es el que ha tomado como propio el proyecto.

Es posible terminar el proyecto en estas circunstancias, es posible que incluso con unos resultados aceptables, sin embargo, lo más habitual es que hayamos invertido un esfuerzo enorme persiguiendo a todos aquellos que deberían estar colaborando con nosotros, nos hayamos desgastado en esta pelea contra molinos de viento, que los resultados no sean buenos y encima que la culpa de todo sea nuestra.

Por tanto, sabiendo lo que va a pasar es necesario reconducir la situación o por lo menos intentarlo (ya que quien debe implicar a todos los involucrados en el proyecto, no somos nosotros).

Resulta significativo que en la situación de crisis actual se premie el precio/hora y no la productividad y/o cualificación del equipo de proyecto a la hora de realizar una contratación software.

El triunfo del precio/hora es el triunfo de la mediocridad, es el triunfo de la crisis del software, es el triunfo de los que han provocado que los desarrolladores de software seamos todos medidos por el mismo rasero, es el triunfo de los que hacen sistemáticamente las cosas mal. Total, el que paga al final piensa: “Para el trabajo que me van a hacer, me quedo con el más barato”.

Aunque el triunfo sea precisamente de los que menos se lo merecen, la culpa de que se haya llegado a esta situación es de todos (clientes, proveedores, etc…) por no haber demostrado con suficientes hechos (proyectos que hayan superado las expectativas de los usuarios) que con equipos cualificados y productivos se pueden hacer mejor las cosas y que eso cuesta a la larga (y a la corta) menos dinero.

El triunfo de la mediocridad está llevando al sector a una situación insostenible ya que ese precio/hora no lo puede soportar nadie (tampoco los que los ofertan) y eso es algo que no solo afecta a la cuenta de resultados, sino que también afecta a la calidad de los proyectos, lo que no hace más que retroalimentar la situación.

Partamos de la base y asi lo defiendo sistemáticamente en mis artículos de que todo proyecto de desarrollo de software es complicado (como es lógico se trata de una generalización), ya sea porque de partida es así (se han establecido condiciones iniciales que no se ajustan a la realidad del trabajo a realizar), porque la incertidumbre y riesgo que rodea al proyecto se materializa y porque este proceso de ingeniería es inherentemente complejo.

Ahora bien, dentro de ese ambiente de incertidumbre, riesgo y complejidad se pueden producir muchas casuísticas que definirán finalmente la dificultad que ha tenido la realización del proyecto.

Realizar diez proyectos consecutivos con éxito no es casualidad, ahora bien, eso no quiere decir que el aprendizaje obtenido en los mismos sea superior al que ha fracasado o no ha tenido tanto éxito en dos proyectos mucho más complejos. Tal vez en el futuro se tornen los papeles y sea ahí donde la experiencia adquirida marque la diferencia y el que ha fracasado triunfe.

Lo anterior requiere que se aprenda de los errores tanto de los propios cómo de los que no se han podido controlar, ya que de esta forma en el futuro se podrán prever más situaciones de riesgo y/o actuar de mejor forma contra ellos.

Sun Tzu, vuelve a dejarnos una reflexión muy interesante sobre esto: “Prever una victoria que un hombre ordinario puede prever, no es el espíritu de la excelencia. No importa si triunfas en la batalla y eres aclamado universalmente como “experto”, pues levantar una hoja caida no requiere tener gran fuerza, distinguir entre el día y la noche no es prueba de gran visión, oir un trueno no es muestra de oído agudo”.

Hace poco vi en un programa de televisión al director deportivo del Sevilla Fútbol Club, Ramón Rodríguez Verdejo “Monchi” e hizo referencia a un ejemplo que ponía a sus alumnos del curso de dirección deportiva organizado por la Real Federación Española de Fútbol.

Según la filosofía de trabajo de Monchi, el director deportivo es el que debe fichar los futbolistas ya que su visión del equipo comprende lo operativo, lo táctico y lo estratégico, sin embargo, entiende que los futbolistas que se fichan se tienen que hacer en consenso con el entrenador porque de nada sirve traer a alguien que después no va a jugar.

Es decir, el entrenador y/o el director deportivo consensúan las necesidades del equipo, el director deportivo selecciona una serie de jugadores en función del perfil indicado por el entrenador, de la proyección del futbolista, su coste, etc… y el entrenador prioriza la lista de jugadores recibida. Una vez hecho eso, el director deportivo ficha tomando como base esa lista priorizada, si bien, las negociaciones son las que finalmente determinan si se ha podido traer el primero de la lista u otro más atrás.

Monchi, lo simplifica indicando que si un entrenador te pide una mesa y le traes una lámpara no le va a servir o al menos no se podrá cubrir la necesidad que éste tiene.

En el desarrollo de software, los desarrolladores tendemos siempre a darle un valor añadido a lo que nos piden. Esto en sí no es malo, siempre y cuando no perdamos el enfoque en el objetivo del proyecto y no compliquemos más lo que de por sí, ya es complicado.

Por favor, no más listas de valores y combos sin ordenar, no más listas de valores y combos que deban tener un valor por defecto y no lo tengan, por favor, no más.

¿Cómo es posible que este tipo de incidencias lleguen a producción tan a menudo? La respuesta es que el enfoque no está puesto en la calidad del software y en el cumplimiento de las expectativas del usuario, sino en simplemente ejecutar trabajo.

Sin embargo, lo peor de todo es que parece que la calidad y la productividad son temas incompatibles, cuando en realidad es todo lo contrario.