archivo

Archivos Mensuales: diciembre 2012

No sé si habéis tenido alguna vez una cita a ciegas, si habéis pasado por esa experiencia en más de una ocasión probablemente habréis comprobado cómo los resultados son muy dispares. Y es lógico que así sea, porque te enfrentas a una situación con una información incompleta. ¿Es tirar un dado? Depende de la información que tengas, si os parece bien, reducimos las posibilidades y lo dejamos en un cara o cruz.

¿Quieres jugarte tu dinero a cara o cruz?, ¿quieres dejar el adecuado funcionamiento de un aspecto crítico de tu negocio en manos del azar?.

A veces oyes cantos de sirena, te dejas seducir por una presentación corporativa, por una referencia sin contrastar, contratas sin reunir toda la información necesaria (acertarás o te equivocarás pero por lo menos tratas de hacerlo en base a unos criterios objetivos) y te olvidas de que estás en el mundo real y que tus decisiones producen un impacto sobre tu organización y/o sobre terceros.

No sé que es peor, si intentar por todos los medios que el contenido del análisis o del catálogo de requisitos sea inmutable o pensar que lo va a ser.

Si has participado en proyectos de desarrollo de software sabrás que (entre otras muchas cosas):

– Los usuarios van aprendiendo conforme el producto se va desarrollando y como consecuencia de ese aprendizaje te van a pedir cambios.

– Lo que en papel o en un generador de prototipos parece sencillo, a la hora de enfrentarse a su construcción puede ser tan complejo que resulte recomendable aplicar otro tipo de estrategia.

– El negocio y/o las prioridades puede cambiar y como consecuencia algunas de las especificaciones iniciales ya no sirven.

En base a estas situaciones pensar que el análisis es inmutable es dejarse cegar por la teoría y exigirlo es ir en contra del valor del producto final.

A este antipatrón se llega cuando se acumulan suficientes proyectos de manera que siempre existe la posibilidad de tener ocupadas todas las horas de trabajo.

De entrada podrás preguntarte, ¿es esto un antipatrón? Se convierte en antipatrón cuando el objetivo final no son los proyectos en los que estás trabajando sino en tener facturables todas las horas posibles, dicho de otra manera, el objetivo es protegerte y no la calidad final de tu trabajo.

Para ello empezarás a sumar proyectos a los que puedes imputar horas, los cuales potencialmente ocuparán más del 100% del tiempo, lo cual diversifica el riesgo de encontrarte con valles en los que no tener horas que facturar.

El lado opuesto a ello es el transcurso normal del proyecto o los momentos en los que hay picos. En estos casos se acumularán retrasos en los proyectos y los desarrollos, hechos desde el overtime y/o desde las prisas tendrán una mayor tasa de deficiencias.

Forzar a que un equipo de proyecto admita más trabajo que el que soporta su capacidad en un momento dado del tiempo no suele funcionar. Tal vez se desarrollen las funcionalidades pretendidas pero es más que probable que el grado de acabado de las mismas no sea bueno, de tal forma que la calidad del resultado final se resentirá: más bugs, deficiencias funcionales y funcionalidades que no están totalmente rematadas?.

Y no solo eso, será complicado que se respeten los plazos fijados, así como los compromisos adquiridos. El triángulo de hierro es poco maleable y si mueves uno de sus vértices el resto se resiente, esa flexibilidad adicional te la da el esfuerzo adicional del equipo de proyecto que si bien puede salvar la situación durante un tiempo no podrá sostener un nivel de presión y de overtime de manera sostenida sin que afecte a su propia productividad y a la calidad de los trabajos. Esto es un hecho y seguro que lo has vivido en primera persona.

Se llega a este antipatrón, por un lado por el deseo de avanzar más rápido y en muchos casos por la desconfianza en las estimaciones que se realizan. La confianza requiere un tiempo cimentarla, mientras tanto, pide explicaciones si no terminas de entender alguna de las estimaciones y admítela salvo que entiendas que la desviación respecto a lo que debería ser es flagrante (si tienes dudas, dala también por válida), al final, pasado un tiempo, el propio proyecto irá poniendo las cosas en su sitio.

¿Por qué dejar que sea el equipo quién estime? Pues porque es el equipo al que se le exige el cumplimiento de los compromisos. Puedes exigir si ellos establecen sus límites, si los pones tú no solo te arriesgas a los inconvenientes indicados en párrafos anteriores sino que estás dejando la puerta abierta a que te pongan la excusa de que las condiciones que has planteado eran imposibles.

En el fútbol se puede jugar bonito pero la línea entre el éxito y el fracaso la marca el gol. Cuando miras atrás ves los trofeos y partidos ganados y nadie se acuerda de lo bien que jugó el que perdió.

El desarrollo de software es igual. Lo difícil es rematar. Conforme se va avanzando en el proyecto cada vez se ve la portería más pequeña y cada vez la cuesta se hace más empinada. Se juega fácil en tres cuartos de campo, se juega fácil dando toques, pero llegado el momento tienes que ir cerrando tareas y poner versiones del producto en producción.

Jugando bien es más fácil ganar, pero jugar bien no es suficiente. Si te falta gol o le falta a tu equipo, el proyecto se resiente generalmente en la calidad del producto final y en los plazos. Lo primero porque no se terminan de capturar bien las especificaciones y/o no se terminan de rematar bien las tareas y lo segundo porque resulta complicado salir de tu zona de comodidad (al final con o sin problemas te acostumbras a lo que te va deparando el proyecto).

Cuando hay abundancia de peces es mucho más fácil pescar, tanto que si has dado con uno o varios buenos caladeros solo tienes que situarte en sus proximidades y echar las redes.

En un contexto como el actual en el que el número de peces ha disminuido considerablemente, las piezas son cada vez más pequeñas y la competencia va a por todas, se requiere que salgan a la luz habilidades que lo mismo no eran necesarias cuando la pesca era abundante y relativamente sencilla.

En estas situaciones la teoría de la evolución ejerce todo su poder y solo los mejores sobreviven. Para ello la habilidad comercial es un gran punto de partida, pero también juega un factor importante la perseverancia y no bajar nunca los brazos.

Lo que no funciona es quedarte como un paciente pescador en la orilla esperando a que de nuevo vuelvan a picar los peces, ya que lo mismo te tocan solo los que los demás no quieren o incluso aún peor, te vuelves todos los días a casa con el cesto vacío.

Hay antipatrones que superan a otros, estamos ante uno de ellos. Hay algo peor que barrer bajo la alfombra y es saber que personas que están bajo tu responsabilidad lo hacen y no tomar ningún tipo de medida al respecto.

Aquí no vale lo del ojos que no ven, corazón que no siente, aquí estas prácticas son conocidas y sin embargo no se hace nada. Quién las admite, no solo es cómplice, es como si las estuviera haciendo él mismo. Eres lo que proyectas y lo que dejas que se proyecte y ten en cuenta que tus equipos son una extensión tuya.

Existen muchas formas de llegar al éxito, una de ellas es esconder basura y mostrar solo lo bueno o lo que interesa. También pienso que no vale todo y que el éxito conseguido de esa manera no vale igual que el que se alcanza de manera legítima por mucho que sus resultados puedan ser (y suelan ser) incluso mejores.

Si quieres crear una cultura de confianza en los clientes debe empezar por tu propia actitud y a continuación exigir la misma en tus equipos. Alcanzar esa situación es complicado, obliga a tomar decisiones que no son gratas, incluso te puede llevar a una situación de desgaste personal, pero nadie dijo que lo bueno fuera fácil.

De hecho lo fácil es mirar para otro lado y esperar solo la frialdad de los resultados sin interesarnos en conocer cómo se han alcanzado los mismos. En el momento en que este esquema se desmorona prácticamente no hay solución salvo que te dediques a explorar otros clientes o mercados, ya que en tus relaciones solo quedará desierto.