Lo quiero todo, todo y todo… o la triste realidad del triángulo de la gestión de proyectos

Resulta que esta mañana me he levantado graciosito y no se si como resultado del aburrimiento, de la pila de días de descanso vacacional que llevo, o de los cubatas del Cebolla Rock, me he propuesto hacer un experimento. Me he ido al concesionario de BMW más cercano, he buscado a uno de esos aseados y sonrientes y le he dicho…

Buenos días, me gustaría comprar un 750i, blanco, que le gusta a mi mujer de eso color, aunque a mi me parece un poco taxi. Taxi, un 750i, ni aunque le ponga lucecita verde hombre, ha dicho el comercial. Ya que estamos, no lo vamos a mirar, he seguido yo… póngamelo con llantas de 20’’, como no y todos los extras, lo quiero todo, todo y todo… si si el paquete M también, como no, yo soy un joven, dinámico y profesional, no puedo ir por el mundo sin el paquete M, faltarías más.

¿No sería interesante añadir también la garantía extendida? Por su tranquilidad, ya sabe. Ha dicho el comercial. Y claro, pues yo he pensado… como no se me habrá ocurrido, póngalo, póngalo. Quizás no lo use pero que le vamos a hacer, nunca se sabe lo que puede pasar.

Y la bola de caravana, ¿no la necesitará usted?… Hombre, yo no tengo caravana, pero ya que lo comentas, y como nunca se sabe, a lo peor me da por cambiar el pueblo por un camping… venga vale, total, molestar tampoco molesta.

Y claro, seguro que un profesional, joven, dinámico, con paquete M y toda la zarandaja es una avezado ciclista, de los de mountain bike molona, de esos de los de gafas Oakley, maillot, culotte, zapatillas y pedales automáticos ¿no? Seguro que necesita el exclusivo portabicicletas de BMW para pasear, digo transportar sus bicis. Pues no, he dicho yo, eso si que no, que yo hace mucho que deje la bici y soy de pelota mano y tal y cual. Hombre, recuerde que nunca se sabe, ha dicho el comercial, y se lo dejo a precio de risa, a añadido. Así que he pensado, por si acaso, con portabicis, ¿voy a saber yo más que el comercial?.

Ya solo nos quedan dos detalles menores. Empecemos por el plazo de entrega. El comercial a empezado a farfullar no se que de disponibilidad, que si las opciones retrasan no se que y no se cual. Yo he pensado, coño, aquí el cliente soy yo ¿no? y le he dicho… a ver si yo lo entiendo todo, pero me lo tienes para dentro de dos semanas, son fiestas del pueblo y tengo que fardar. El comercial no ha dicho ni mu, es más me ha dicho, que quizás lo tenga un poco antes.

El segundo tema menor, el precio. Aquí yo he tomado la iniciativa que para algo soy el cliente ¿no?. Para esto tengo treinta mil euritos, entiendo que tengo que poner otros dos cientos, por la llantas, pero esto es lo que hay. Me han dicho que en la india hay unos concesionarios que lo hacen más barato y mejor, eso sí, por evitarme el papeleo que sino te iba a comprar al ti el BMW Rita… la cantadora.

Entonces me he despertado. Claro. ¿Por qué estas cosas solo nos pasan en el mundo del software? La historia no se sostiene, claro está, pero cambiad BMW por aplicación de software, y dar sudores fríos el pensar realismo que se añade. ¿Alguno de vosotros le suena? 😉

Hace mucho, mucho tiempo, que se describió el famoso triangulo o tetraedro de hierro de la gestión de proyectos (hay gente que cree que la calidad también es un factor sobre el que podemos gestionar, yo soy de los que piensan que la calidad no es algo con lo que se pueda especular, la calidad no es opcional, y la marca el cliente, no nosotros).

Triangulo de gestión de proyectos

La idea es que de los tres aspectos: alcance, coste, y plazo, el cliente puede manejar dos grados de libertad. El otro, lo maneja la gestión del proyecto. Esta es en esencia una idea de equilibrio básico entre las partes de un proyecto. Es problema es que a menudo este equilibro se rompe. Incluso hay un antipatrón que describe esta situación. Diferentes metodologías dan diferentes respuestas a este problema, en un próximo post, comentaré la solución que propone Scrum. De hecho el propósito de este post, es comentar el dichoso triangulo de una manera un poco amena, como prolegómeno a dicho post.

Por cierto, ya tengo mi BMW, ha llegado seis meses tardes, no es blanco, y le faltan algunos detalles menores. Eso si, cuatro ruedas y volante tiene. Os dejo una fotito, para daros envidia. No es lo que esperaba, pero esa es otra historia…

 BMW

¿Qué es lo que hace que cuando se habla de software la realidad se torne tan anómala? ¿Por qué creéis vosotros que es tan difícil mantener el equilibrio descrito en el triangulo de la gestión de proyectos en la realidad? ¿Que factores hacen que salte por los aires tan a menudo en los proyectos? Y no, no vale el argumento fácil: ¡es que los comerciales…! 😉

13 comentarios en “Lo quiero todo, todo y todo… o la triste realidad del triángulo de la gestión de proyectos”

  1. Hola Rodrigo,

    evidentemente, lo que cuentas es así, y respecto a que “la calidad no es una opción”, totalmente de acuerdo, pero… pero… (y no voy te/os voy a contar lo que pienso sino la realidad con la que lucho todos los días).

    Ahora bien… y con tus preguntas últimas:

    Cuando hablas de calidad, la respuesta es… ¿y cuanto tiempo se alarga el proyecto por aplicar esa calidad?. ¿En cuanto tiempo estaría haciéndolo un “poquito” más “rápido”?, ¿más a lo “bruto”?. Yo tengo claro que la caliadd no es una opción, pero ¿si tu jefe está dispuesto a sacrificar esa calidad/tiempo y te dice “lo quiero rápido, rápido y ya…”?.

    El hecho por el cual es tan difícil el mantener el equilibrio en mi opinión es porque a la calidad se la ve como una pérdida de recursos/tiempo y uso de personas (cuando hablo de recursos NO hablo de personas) que podrían estar dedicadas a otra tarea.

    Los que hemos desarrollado con y sin calidad, sabemos que los costes de no aplicar calidad, son después y al 99% siempre, MÁS ALTOS que los costes de haberla aplicado previamente.

    El tema de los comerciales no lo sé, no en mi caso en cliente final, pero sí el hecho de sacar adelante proyectos que resuelvan el dinamismo con el que se mueve la empresa en la que actualmente estoy, y que requiere sacar proyectos como churros con un número de personas limitado. Ante eso, y puesto que no se puede invertir en contratar más… la calidad pasa a un segundo plano vs sacar proyectos rápidamente… más que nada porque no hay otra solución.

    Espero que quede claro uno de los escenarios con el que me encuentro. 🙁

  2. @Jorge:

    En el post digo que la calidad no es una variable con la que se pueda especular por lo siguiente:

    Estamos de acuerdo en que la calidad la marca el cliente. De nada vale que nosotros decidamos sacrificar calidad si luego el resultado es que el cliente no acepta el producto ¿no?.

    De igual manera, entregar más calidad de la que el cliente demanda es, efectivamente, tirar recursos a la basura. ¿Para qué dar más calidad que la que el cliente aprecia?. El preciosismo no sirve de nada.

    La clave es buscar el nivel de calidad que el cliente demanda y ceñirse a ese nivel durante toda la duración del desarrollo. Evitar los altibajos de calidad o desarrollar con poca calidad es clave.

    Es importante mantener la calidad y evitar quebraderos de cabeza al final:
    http://geeks.ms/blogs/rcorral/archive/2007/01/18/evitar-quebraderos-de-cabeza-al-final-de-los-proyectos.aspx

    ¡Un saludo y gracias por tu comentario!

  3. Hola Rodrigo, el caso es que no puedo estar más de acuerdo contigo y suscribo todo lo que dices al respecto, sin embargo, la realidad es otra en muchas ocasiones.

    En España al menos, en informática se trabaja como se trabaja en casi todos los sitios (mal).

    Por suerte, he trabajado fuera de España y he visto otras cosas, y en España, muy pocos sitios donde lo que dices (y que reitero, tienes más razón que un Santo) se de, se pueda dar, o… peor… te dejen maniobra o espacio para aplicarlo.

    Desde luego que hay que buscar el equilibrio, pero no en todos los sitios se tiene margen de maniobra para aplicar beneficiosamente ese equilibrio o a veces, depende del proyecto (estratégico, ceñido a fechas previamente, etc).

    Sin embargo,… casi siempre hay una estrecha unión comercial que nos obliga a ajustarnos que varían toda la previsión inicial y que nos obliga a meter la tijera.

    Gracias a tí. Me parece una entrada muy interesante para debatir.

  4. Hola preguntoncojonero,

    un MVP no es mejor que alguien que no lo es, y TODOS debemos y podemos hacer cambiar ciertos hábitos de nuestra querida informática, sin embargo, en mi comentario no me quería referir a que en España no se trabaje bien, sino que en muy pocos sitios en España (es mi opinión), se trabaja bien (como se deben hacer las cosas).

    Eso sí, tampoco fuera de España se hacen a veces las cosas bien, pero yo al menos he tenido la suerte de haber disfrutado de haber hecho las cosas bien (buena culpa la tendrán los jefes que he tenido, la experiencia del equipo, las personas de la empresa o empresas, etc).

    Muchas empresas solo miran el dinero perdiendo el foco en otros aspectos mucho más importantes que a la larga, devuelven ese dinero como retorno de inversión. Pero España no es un pais donde el I+D se entienda como inversión rentabilizada y donde aspectos como la calidad se ven como una pérdida de dinero y recursos. Así lo veo. Existen empresas en España que sí lo han visto y lo están aplicando, pero todavía queda muchísimo camino por recorrer.

    Yo soy MVP, sí, pero no soy mejor que otras personas que no lo son. De lo que al menos yo hablo, es de sentido común. La entrada de Rodrigo, creo que también trata casi siempre de eso, de sentido común, pero lamentablemente, a veces el sentido común pasa a segundo plano vs dinero. Así lo pienso y así lo creo.

    Para cambiar hábitos, todos debemos poner de nuestra parte.

    Un saludo.

  5. Hola a tod@s.

    Últimamente, cada vez que me marcan plazos, calidad o funcionalidades, siempre muestro un triángulo de compensación Recursos/Tiempo/Funcionalidades por el que cuando nos fijan una de las características y la otra no se puede mover, la otra hay que ajustarla al alza o la baja.

    Junto a este triángulo de compensación muestro una planificación en el tiempo lo más real posible del resultado de la compensación del triángulo, y dejo a comercial o al cliente escoger.

    Es la forma más visible que he encontrado de que se den cuenta de que no somos magos y que incrementar las funcionalidades o las pruebas de calidad repercute de lleno en el tiempo o la cantidad de personas que deben trabajar en el producto.

    Por lo general suelen quitar funcionalidades, pero eso ya es bajo responsabilidad de quien vende o quien compra, no de nosotros, que desarrollamos y que intentamos hacer lo que nos piden lo mejor posible.

    Un saludo
    CNatra

  6. Estoy deacuerdo en que la calidad hoy en dia no es opcional, puesto que el coste del proyecto al final aumenta, sin embargo todavia hoy en dia muchas empresas acostumbradas a sacar valor añadido precisamente de este aspecto.

    Cuando hablo de calidad, hablo de calidad con limites, aplicar todas los sistemas de calidad existentes hoy en dia puede ser peor que no hacer nada, pasa como con la seguridad, si nos obsesionamos con ella caeremos en un abismo sin fin, es importante tener claras aquellas reglas que queremos seguir a lo largo de todo el proyecto y es importante trasladar y convencer al cliente para que conozca de antemano las ventajas de un desarrollo con determinadas reglas de calidad y que despues acepte o reuse a utilizarlos asumiento los riesgos que conlleva.

    Por otra parte entiendo perfectamente la reflexión de Jorge Serrano, ya que hay veces en que la presión hace que tengamos que renunciar a la calidad, la “presión” es incompatible con la calidad, aunque hay veces que es necesaria en su justa medida, la presión que propone Scrum que hace que cada desarrollador se comprometa a realizar algo, es positiva pues obliga a un compromiso con nuestro trabajo, sin embargo la presión con metódos como dirigir y controlar de Joel, hacen que muchas veces se renuncie a la calidad con tal de “terminar” algo en un plazo determinado, creo que para trabajar con calidad, la presión debe ser controlada y aceptada por todos los participantes del proyecto incluido el propio cliente.

  7. También debe tenerse en cuenta que no es lo mismo un producto (un BMW por muchos packs que se pidan no deja de ser algo “cerrado” y empaquetado) a un desarrollo a medida en la que todo está abierto a los “caprichos” del cliente 😉

  8. Yo estoy de acuerdo en que no es comparable un producto con un desarrollo, aunque al fin y al cabo, las labores comerciales desenfocan igualmente la realidad, provocando decepción en el cliente.
    Eso es lo que le pasó a Rodrigo con el BMW. Quizas un símil mas parecido al software es el de la construcción… compras una primera vivienda en planos y las ves construir… día a día … y al final… lo entregan en fecha?? con cuantos defectos? humedades? suciedad? …

    Estoy de acuerdo con Frank CNatra.
    Mi opinión: es un error que un comercial venda un desarrollo software.

  9. Estoy de acuerdo en que la informática no es lo mismo que hacer otro tipo de productos industriales. Hace tiempo dedique una entrada a eso: http://geeks.ms/blogs/rcorral/archive/2008/04/06/la-falacia-de-la-industrializaci-243-n-del-desarrollo-de-software.aspx

    Solo quería dar un aspecto ameno al aburrido triángulo de hierro de la gestión de proyectos. La construcción tampoco vale como simil.

    Solo un comentario más sobre la calidad, repetid todos conmigo por favor: la manera más rápida de hacer software es hacerlo con la calidad requerida a la primera. Tenemos que hacer de esto un mantra, tanto nuestro como profesionales como machacarselo a nuestros compañeros no desarrolladores cuando nos piden que sacrifiquemos calidad. Ojo con la calidad REQUERIDA, ni más ni menos.

    Claro que saber que significa eso de la calidad requerida y mantener el punto justo sin caer en el preciosismo también es algo que puede dar mucho que hablar.

    ¡Un saludo, gracias por los comentarios!

  10. Indudablemente, la calidad no es cuestionable.

    No debemos relacionar calidad con funcionalidades.

    Filtrar, escoger, reducir la cantidad de funcionalidades de una solución no implica que tengamos más tiempo para aumentar la calidad de las funcionalidades que se desarrollarán, o para meter otras diferentes, como suelen pensar los comerciales o el cliente, sino que tendremos el tiempo justo para hacer un producto final con menos funcionalidades, pero con la calidad “requerida”.

    Es difícil, de cualquier modo, encontrar empresas donde el comercial se funda con el jefe de proyecto (no, miguelón?), pero al final, el cliente tendrá casi la misma visión, y será difícil convencerle de que si se rompe “el triángulo”, la solución final será un chindogu (珍道具) más.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *