Acabo de recibir un comentario de Rafa en el post original, creo que es un resumen, en muchos aspectos, de lo que piensa la gran mayoría de la gente, por eso he decidió hablar un poco mas de este tema.
El post en concreto dice:
Hola Juan, es mi primer comentario en tu blog, pero no he podido resistirme al ver tu post y los comentarios.
He acudido a varios cursos de Rodrigo sobre administración de proyectos, metodologías agiles y demás. Con la experiencia que tengo en este mundo, ya van 11 años, mi opinión es que estas metodologías solo sirven para grandes o grandísimos proyectos en los que estén metidos asesores externos y personal técnico del cliente o para proyectos internos, es decir para los propios proyectos de empresas de software. ¿Por qué?, yo creo que primero el cliente no sabe lo que quiere, o mejor matizo, sabe perfectamente lo que quiere pero no sabe como plasmarlo en un desarrollo informático. El cliente solo paga cuando el trabajo está hecho, es muy bonito que el cliente vaya pagando según los módulos entregados, pero la verdad es que si el cliente no tiene todo, la típica frase es: «No tengo nada». La implicación del cliente o del máximo responsable de tu cliente la mayoría de las veces es escasa o más bien nula, y lo entiendo, esto es diferente a todo lo demás, yo si me compro un armario empotrado le digo lo que quiero al carpintero, pero no me va ensañando las baldas que va haciendo, si me compro un coche, pues no me voy a la fabrica, si me compro una casa, está en la mayoría de los casos es «estándar» como el software y cuando esta me la entregan no se adapta a mis necesidades (como dicen mis clientes con sus programas), pero lo único que puedo hacer es joderme y esto está asumido por la gente, no así en el caso del software. Realmente es un mundo y un tema para tesis doctoral, yo en este mega comentario no aporto nada, lo sé, pero es que no tengo ni idea de que aportar…. Esto sirve muchas veces de terapia, lo sé, los psicologos deben de tener sus consultas llenas de jefes de producto.
Hola Rafa, te agradezco tus comentarios, pero no comparto la mayoría de tus opiniones, en primer lugar te diré, que todos aportamos, de hecho y gracias a tu comentario me he animado a escribir otro post, tu opinión es tan válida como la de cualquier experto y además aprendemos los unos de los otros, ¿De eso se trata? no…. cada uno aporta en base a su experiencia y sus conocimientos, si lo compartes será enriquecedor para todos.
Sé que en el mercado en que nos movemos, muchos piensan que vender un proyecto de esta forma es como un «sueño», pero, depende de nosotros que podamos hacerlo realidad, si te fijas en otro tipo de proyectos, por ejemplo cuando un constructor realiza un edificio, o el gobierno encarga la realización de un tramo de autovía, los proyectos se comportan así por necesidad, es decir, se van realizando paulatinamente y las empresas van pagando según el trabajo que se va acometiendo, en estos casos la imposibilidad de hacer una obra de tal magnitud debido sobre todo al coste económico que supone, hace inviable que el coste se pueda asumir hasta el final, si en un momento dado la empresa no puede continuar el trabajo o el cliente no está satisfecho, siempre existirá otra que pueda terminarlo y el cliente habrá pagado por aquello que se ha realizado.
Lo que cuento en el post es sobre todo, parte de la experiencia que he tenido en mis proyectos, en ningún caso, lo que me han enseñado las metodologías, entiendo que las metodologías nacen para dar una «solución» a muchos de los problemas que se presentan en los proyectos como una necesidad para aquellos que buscan una solución para estos problemas, además han sido probadas con éxito en multitud de proyectos, si no, nadie las utilizaría, en este caso la metología que usamos se adapta perfectamente a esta problemática y surge precisamente para ofrecer una solución.
Desde luego no comparto en absoluto que este tipo de metologías estén pensadas solamente para proyectos grandes, la metología te asegura que realices el trabajo día a día, qué más da si el proyecto tiene una duración de 15 días o 5 años, al final hacemos lo mismo, solo que a la hora de estimarlo y venderlo nos resultara más sencillo.
Creo que los proyectos de desarrollo no son comparables a cuando encargamos un armario, en cualquier caso si te quieres asegurar de que el armario cumple tus expectativas, seguro que le echas un vistazo a las baldas.
El cliente es el que mejor conoce su problemática y por eso, para llevar a cabo cualquier proyecto debemos contar con él, tiene que formar parte indisoluble del equipo, creo que este es uno de los factores donde cometemos la mayoría de los errores, a veces creemos que nosotros sabemos más que él, otras que no sabe transmitirnos los que realmente quiere, en cualquier caso la culpa siempre se la echamos al «cliente». Yo creo que es nuestra obligación conocer en detalle toda la problemática del cliente, si esto no se cumple tenemos muy pocas posibilidades de que nuestro proyecto llegue a buen término. Los proyectos fracasan por diferentes motivos, a veces nos equivocamos al estimar el coste, otras el cliente no sabe muy bien lo que quiere y eso redunda de nuevo en el coste, en otros casos no entendemos lo que el cliente nos quiere transmitir, la mayor parte son causados por «una falta de comunicación». La solución que propongo pasa desde luego por convencer al cliente, si no somos capaces de convencer al cliente, tampoco seremos capaces de realizar un proyecto exitoso sin contar con su colaboración, entiendo que es complicado, sobre todo para empresas que no tienen claras las cosas o simplemente que han tenido experiencias negativas. En cualquier caso, somos nosotros quien marcamos las reglas, si de antemano sabemos que debemos acometer un proyecto y que no vamos a tener la colaboración del cliente, tenemos muchas posibilidades de fracasar, llegados a este punto quizás sea mejor no comenzarlo.
Creo que es importante reflexionar, en el sentido, de que somos nosotros los primeros que cometemos el error «No sabemos vender correctamente un proyecto ni marcar las reglas que regirán a lo largo del proceso». Inicialmente marcamos nuestras propias normas, la mayoría de las empresas suelen investigar al posible cliente para saber si es o no solvente, y exigir un pago antes de comenzar el proyecto. No conozco a ninguna empresa que comience un proyecto de desarrollo con un cliente desconocido, si antes no ha cobrado un porcentaje de su costo. Hacemos esto porque es una norma en la que creemos.
Somos nosotros los marcamos nuestras propias reglas, aunque para hacerlo hay que creer en que, lo que estamos haciendo es lo más adecuado. Dudamos de que esta sea la solución más adecuada, en algunos casos porque nunca lo hemos probado, otras veces porque no tenemos la suficiente disciplina para utilizar una metodología y la mayoría de las veces por que el «cambio» siempre suele significar mayor complejidad y solemos seleccionar el camino más fácil, «el que conocemos». Las implicaciones que tiene el poder realizar un proyecto con estas restricciones son importantes, debemos conocer la metodología y ser estrictos para llevarla a cabo, es el precio que debemos pagar, si queremos cambiar la forma de trabajar y sobre todo de realizar proyectos exitosos.
Sé que este puede ser el «sueño» de muchas empresas, y que existen muchos problemas para la realización de un proyecto tal y como lo expongo en el post, algunas nos vienen dadas por el departamento comercial o impuestas por empresas que llevan muchos años en el mercado. Pero si preguntamos a cualquier cliente, la realidad nos dice, que la mayoría no están satisfechos con sus proveedores, y esto es debido a que no hacemos las cosas bien.
Cuando vendemos un proyecto de software, algo completamente intangible, nuestras reglas conforman parte del producto en sí mismo. Si cambiamos estas en base, únicamente a las exigencias del cliente, estaríamos vendiendo un producto diferente en el cual no creemos. Si no estamos dispuestos a marcar nuestros límites no podremos tener éxito en nuestros proyectos.
Todos hemos oído frases similares a las siguientes, «es que el cliente no me atiende, ya verás cuando vayamos a implantarlo», «nadie sabe cómo funciona esto, no sé cómo solucionarlo.», «en el Dpto de contabilidad me dicen que haga esto, pero en el otro me dicen todo lo contrario….» Si no somos capaces a la hora de vender un desarrollo trasladar al cliente nuestra forma de trabajar y como hay que hacer para desarrollar un proyecto, difícilmente podremos llevarlo a cabo y esto es culpa nuestra, no de el cliente.
Si queremos mejorar, debemos cambiar nuestra forma de pensar y desde luego establecer nuestras propias reglas.
