¿Debemos cambiar la forma de vender Software?, continuación…

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.

20 comentarios sobre “¿Debemos cambiar la forma de vender Software?, continuación…”

  1. Bueno Juan , en el fondo de la cuestión entiendo que tienes razón , aplicar metodologías repercute en el beneficio nuestro y en el proyecto , pero creo que se te escapa un parámetro adicional muy importante que es la dimensión del proyecto y el tipo de cliente . Si tenemos que realizar un proyecto donde el factor primordial y básico es el coste ( y que este sea mínimo ) evidentemente pese a sú importancia tienes que reducir costes de desarrrollo , y entre ellos la aplicación de metodologias en el proyecto , evidentemente no es lo mismo desarrollar un proyecto por 6.000€ que uno de 100000€ ;por eso entiendo lo que quiere decir Rafa ; el tema de aplicación de metodología pese aser ideal a veces es inalcanzable por la propia ideosincrasia , limitaciones del proyecto y aunque no sea recomendable ni quieras hacerlo no te quedan más narices que tomar la decisión de no aplicar metodologías .

    Saludos

  2. @Fidel: si el coste es un factor primordial, con más razón para aplicar una metodología.

    Usar una metodología no tiene por qué implicar más tiempo de proyecto. La metodologías están por algo, no están por tener o por decir qué tengo algo. No aplicar puede implicar más tiempo de desarrollo por no tener bien los requisitos, por no gestionar los riesgos, los impedimentos y todos los problemas que pueden surgir por trabajar a salto de mata…

    Me viene a la mente esta dicho popular: «visteme despacio que tengo prisa.»

    Eso sí, el proceso de pasar de no tener nada a trabajar con una implica una inversión, que hasta la adaptación tendrá un coste que posteriormente tendrá una gran recompensa. Las implantaciones implican inversión.

    Un saludo,

  3. Fidel, estoy completamente de acuerdo con lo que te dice Ibon, añadiría también que la metología está formada por un conjunto de normas que hacen que la realización de nuestro trabajo se realice de una forma más ordenada y nos permite controlar y estimar mejor el proyecto, no sé porque se miran las metologías como algo que nos va a costar dinero, bueno rectifico, en el caso de CMMI, seguramente si queremos certificarnos esto tenga un coste, pero si hablamos de Scrum que es la que comparte las ideas del post no. Está claro que si la usamos por primera vez necesitaremos algo de tiempo y sobre todo disciplina para sacarle partido, pero esto pasa con cualquier tecnología nueva que abordemos.

    El coste del proyecto no tiene nada que ver, para mi es más fácil utilizar una metodología que no utilizarla, independientemente del coste y complejidad del proyecto, si lo hago es porque me proporciona ventajas que de otra forma serían muy difícil de obtener.

  4. Defendiendo y pareciéndome excelente una metodología como Scrum, estoy de acuerdo con algunos comentarios que ponen de manifiesto algunos problemas que surgen con los clientes en la estimación del costo de un proyecto.

    Pese a todo lo que hablemos sobre lo importante que es convencer al cliente de las ventajas que va a obtener si no fijamos un precio cerrado hoy, sino que es mejor una estimación viva sobre entregas parciales, o incluso si simplemente le decimos que no podemos afinar en el presupuesto sino a «nivel orientativo» debido a que el grano fino se tratará cuando se aborde un determinado módulo, muchas veces el cliente no pasa por ahí y se niega en redondo.

    Es decir, por mucho que le expliquemos que tendrá una lista de funcionalidades sobre la cual podrá modificar su orden de implementación, añadir nuevas, eliminar, extender, etc. y que esta ventaja y flexibilidad hará que no podamos darle un presupuesto cerrado desde el principio, muchas veces la respuesta será que eso es inviable porque hay que pasar un presupuesto al departamento que aprobará el proyecto, porque se necesita saber el presupuesto ahora y no embarcarse en algo «indefinido», porque…

    Con esto quiero decir que en mi experiencia, hay casos en los que es imposible convencer al cliente de esto y la única manera de aceptar cierto proyecto es dando una estimación de costo de la que luego habrá que desviarse muy poco. En este caso la toma de requisitos toma un papel crucial (más si cabe) desde el principio, ya que serán un factor determinante para dar ese presupuesto. En estos escenarios siempre he pensado que Scrum no da una respuesta satisfatoria para la gestión del proyecto de cara al cliente, otra cosa es internamente en el equipo de desarrollo.

    En resumen, creo que no se puede achacar todo a la necesidad de «convencer» de que estamos proponiendo la manera correcta de gestionar el proyecto de cara al cliente, ya que al final, esta decisión es cosa de las dos partes y si una parte se niega no se podrá llevar a cabo.

    Ya me comentan qué piensan sobre esto.

    ¡Saludos!

  5. Comparto todo lo dicho por Juan y por Ibon, pero no me resisto a escribir… aunque sea en la misma línea.

    Entiendo perfectamente lo que comenta Rafa… durante mucho tiempo se ha pensado que el cliente era el enemigo y eso lo pagamos. Pero hay que cambiar la manera de relacionarse con el cliente. Es necesario establecer una relación basada en la confianza y la colaboración. Es indispensable hacerlo así para que los proyectos sean exitosos.

    Pero la confianza empieza por nuestro lado, nosotros debemos confiar en los clientes y dejarles patente que queremos colaborar. Que necesitamos sus feedback, que el software es mucho más complejo que las baldas y que solo si tenemos feedback podremos llegar a una solución que les sirva.

    Además una diferencia sustancian es que no tiene sentido entregar un coche por etapas, un coche sin ruedas no sirve. Un software sin un par de informes y un par de pantallas y sin el manual pero con tooltips en los campos puede servir, aunque a la larga sea necesarios esos informes o el manual o las pantallas que falta.

    Es necesario un cambio de mentalidad, algunos ya estamos en ese cambio y ya estamos promoviendo ese cambio también en nuestros clientes. Evidentemente, no todos los clientes querran andar este camino, ni todos los equipos de desarrollo…

    Hace mucho escribí sobre esto en mi blog, creo que sería interesante y que viene al caso, por si os interesa: http://geeks.ms/blogs/rcorral/archive/2006/09/07/No-les-vamos-a-volver-a-enga_F100_ar.aspx

    ¡Un saludo!

  6. Buenos dias a todos; me gustaría dejar una pregunta al hilo de tu post Juan, ¿Se deben descartar clientes según su nivel participativo(a la hora de involucrarse), al igual que se descartan por su solvencia? Tiene esto que ser un parametro más?, Porque todos conocemos clientes imposibles..merecen la pena??

    Saludos.

  7. Rodrigo. Excelente post que lei hace tiempo y que comparte la esencia de lo que se dice aqui.

    Eduardo, yo creo que no debemos descartalos, sino convencerlos de que la importancia de la comunicación y la colaboración entre ambas partes es vital para el correcto desarrollo del proyecto.

    Si decimos a un cliente: si no estas dispuesto a colaborar, el proyecto tiene grandes posibilidades de ser un fracaso, este seguramente se lo piense antes de adjudicarnos el proyecto si no quiere participar.

    El problema es que desde las empresas que venden software esto no se hace, la empresa suele decir, bueno si usted no colabora tenemos a una persona muy experta en estos temas que desarrollo algo parecido o frases similares.

    Esto es debido a que no estan dispuestas a marcar sus reglas con tal de no perder el proyecto, entiendo la dificultad que entraña decir que no, sobre todo para las pequeñas empresas que tienen mas dificultades, pero hay veces, que es mejor hacerlo a realizar un proyecto sobre el que tenemos muchas posibilidades de fracasar.

    Si informamos al cliente de su error y este asume el riesgo de realizar el proyecto de esta forma, podremos realizarlo, sabiendo que le hemos informado correctamente de los riesgos que conlleva, al menos no le estaremos engañando…

  8. Hola Juan otra vez, lo primero agradecer que un comentario mío sirva para generar una nueva entrada en tu blog y seguir dándole vueltas a este tema.

    Voy por partes. Lo primero insistir, quizás no lo deje bien claro o se me malinterpreto que yo estoy 100% a favor de las metodologías de trabajo, me encanta Scrum, lo que yo quería decir es que me parece complicado llevarlo a cabo dependiendo de qué proyecto queramos afrontar.

    Segundo, en efecto el cliente no es el enemigo. Es nuestro mejor amigo mas bien. Lo digo yo que estoy todo el día intentando inculcar a mis compañeros que se olviden de comentar las típicas frases «este tío es un pesado», «no sabe lo que quiere», «y ahora me lo hace cambiar todo», etc… A todos nos fastidia trabajar, y si que es cierto que parece ser que los informáticos de profesión somos los únicos que sabemos manejar ordenadores y que el resto de mortales están en este mundo solo para tocarnos las pelotas y no hacernos caso. Eso está impreso en la cabeza de todo desarrollador y luego eso en la relación con el cliente se nota.

    Creo que el problema no es si utilizar o no una metodología de trabajo. Utilizarla por si es muy bueno, nos ayuda en el día a día. Pero creo que no es lo mismo eso que hacer que el cliente «trabaje» con nosotros. Yo puedo en mi equipo de trabajo hacer las cosas muy bien, pero lo que el cliente «persé» espera de mí y de mi trabajo puede no parecerse en nada a la realidad.

    Me explico con un ejemplo espero que claro. Yo trabajo en una empresa de software «pequeña». Realizamos desarrollos a medida para pymes, y tenemos nuestras aplicaciones paquetizadas, envueltas en una cajita muy mona y puestos en una estantería para vender. Bien, cuando un cliente nos contrata suele ver una demo de nuestro software, comentarla y decir lo que le vale y lo que no. Tras esto se analiza de forma más minuciosa la situación y se redacta un análisis mas detallado. Ahora nos ponemos a trabajar. La mayoría de las veces el cliente (y lo digo por mi experiencia, si alguno es de otra manera, suerte que tiene), no tiene tiempo para probar lo que tú le vas haciendo, muchas veces tu software reemplazara a otro ya existente y la gente te dice (creo que con razón), «no me voy a poner a hacer las cosas dos veces». Bien con esto ya empiezas a no tener el feedback del cliente, el lo puede probar, pero no usar, que son dos concepto totalmente diferentes.
    Cuando tu acabas tu trabajo, se sustituye como digo, el software anterior empiezan los problemas.
    Cliente: «Esto no hace esto, esto y esto otro».
    Jefe de producto: «Pero si tengo un análisis de hace 2 meses, en donde no hemos especificado nada sobre lo que me está contando».
    C: «Para tener un programa que me haga lo mismo que el anterior, para eso no cambio».
    JP: «Pero si usted me dijo que el análisis lo hiciéramos viendo pantalla por pantalla lo que ya había implementado?».
    C: «Pero si no está hecha la parte de taller, el jefe de taller cuando se hizo el análisis estaba de vacaciones y utilizaba un programa hecho en cobol del año de la polca que solo tenía en su ordenador».
    JP: «¿?¿?¿?¿?¿?¿?»

    La solución a todo esto, es fácil, ampliación de presupuesto y vuelta a hacer un análisis, fase 2. Mala cosa esta, una ampliación de presupuesto significa más dinero, el cliente no está dispuesto, la aplicación ya esta coja desde el primer día, malos rollos, los trabajadores de la empresa tiene que hacer lo que en un principio no querían, trabajar con dos programas a la vez. Solo hay dos salidas o te comes las horas de rehacer/terminar, o discutes con el cliente y la batalla ya está en marcha.

    Mi conclusión es la siguiente. Métodos de trabajo, por supuesto que si, relación con el cliente también, implicación de este, fundamental. Estoy totalmente de acuerdo con Eduardo Obregón, yo no trabajo con un cliente que no se implique porque se lo que pasa luego. Por eso decía en mi primer comentario que si el cliente posee personal técnico implicado o un asesor/consultor externo las cosas suelen salir mejor y es más fácil implicar al cliente.

    Otra de las afirmaciones que decía yo en cuanto a que esto solo funciona con clientes grandes y grandes proyectos, me reafirmo en lo que digo, ya que para cosas pequeñas, yo no puedo estar todo el día codo a codo con el cliente, visitando, haciendo pruebas de concepto, etc.. lo que me va a pagar no compensa ese esfuerzo de horas invertidas. Por eso creo que los desarrollos a medida deben de costar dinero, y el cliente debe de ser consciente de ello, obviamente esto sobraría decirlo, pero es que creo que es el principal problema, la relación entre los conceptos «CLIENTE < -> COMERCIAL < -> DESARROLLO»

  9. Efectivamente , es ideal todo lo que contais , pero también es cierto que muchas veces la realidad es diferente sobre todo en pequeñas empresas de desarrollo de software , época de crisis , necesidad de aceptar el proyecto por necesidades económicas o por situación estrategica de la empresa , o pese a las pegas que pongas al proyecto la empresa lo acepta ,…etc ; muchas veces la realidad por mucho que no queramos nos sobrepasa pese a la ideonidad de de aplicar metodologías al proyecto. Yo sigo pensando y llevos más de 12 años desarrollando proyectos , que las cosas no son tan sencillas , cada empresa , cliente , proyecto es un mundo , a veces es muy dificil realizar un análisis profundo y detallado de un proyecto , evidentemente en un mercado tan competitivo como el que tenemos y por desgracia para nosotros el cliente final en un alto porcentaje de casos » se la suda las especificaciones y metodologias» lo que miran es la «pela» además de que las personas que toman las decisiones de a que empresa asignar un proyecto son normalmente personas de los departamentos de compras que lo único que miran es el precio , y es muy dificil o imposible vender un producto un 50% más caro que la competencia aunque sus análisis o informes del proyecto sea un papel de 1 hoja con 2 líneas .

    Además existe otro tipo de cliente , el listillo , que no quiere análisis ni especificaciones ni nada , porque de esa manera te puede exigir practicamente lo que le de la gana , evidentemente hay que huir de estos casos , pero puede pasar que pese a la pegas que pongas la «dirección» decida que adelante ….

    Yo creo , y tengo bastante experiencia en el tema , pese a la idoenidad del uso de metologías ,muchas veces es imposible y pese a que estoy de acuerdo de que debemos vender no solo el producto sino que «como lo hacemos» y «porque somo diferentes y mejores que la competencia» , pero muchas veces te encuentras con la realidad , y más ahora en época de crisis , que para el cliente lo único que importa es la «pela» ; te acabará diciendo si todo muy bonito , perfecto pero la competencia me lo hace por menos
    Saludos

  10. Hola!

    No quiero entrar en mucho detalle porque sería otro post tan grande como el de Juan pero según leo algunos comentarios, parece ser que trabajar sin metodologías es mucho más rápido y más barato. Este me parece un grave error.

    Que no siempre se puede contar con la ayuda del cliente porque no colabora tanto nos gustaría, perfecto….

    y eso significa que no vamos a gestionar nuestros riesgos? que no vamos a tener un listado de requisitos? que no vamos a tener nuestras tareas registradas y estimadas? que no necesitamos métricas para saber cómo vamos? que no vamos a ver cómo es la mejor manera de generar buen código? que no nos vamos a marcos hitos? que no vamos hacer pruebas? que no…..

  11. Hola Ibon

    Que sí que todo muy bien y bonito , que el uso de metologías repercute sin ninguna duda en beneficio de todos , pero sigo insistiendo en que las cosas no son tan sencillas, depeden de un montón de parámetros , y uno de ellos es la envergadura del proyecto y el coste ; en un proyecto de 6000€ olvídate de todo lo que comentas , tendrás que tirar de la experiencia y de otros mecanismos que te permitan llevar a buen puerto el proyecto con los menores costes posibles.

    Estoy convencido de que más del 70% de los proyectos informáticos que se desarrollan hoy en día no se usa ningún tipo de metodología , aunque pienso que es un error , es la realidad . Es más , al comienzo de vida laboral después de acabar mi licenciatura en informática entre a trabajar en una de la mayores empresas informáticas de este país , concretamente Ibermática , pues te puedo aseguar que en departemento que yo estaba pese a que eramos más de 40 personas trabajando en diferentes proyectos , muy importantes algunos de ellos , algunos de ellos de largísima duración de años y con unos presupuestos enormes , no existía ningún tipo de metodología de trabajo…..y yo en aquella época era nada más que un simple e inquieto programador .

    Salu2

  12. Llegué muy tarde a este debate parece.

    @Fidel: que a uno cuando ingresa no le digan «nosotros usamos scrum» o «nosotros usamos rup» no significa necesariamente que no tengan una «manera de hacer las cosas».
    Yo concuerdo con vos en esos porcentajes, es mas o menos el número que yo manejo (70%) y también trabajé en 3 empresas que no usaban ninguna metodología. No obstante en dos de ellas, si bien no tenian un nombre, si habia un m’etodo, un orden y todas las buenas prácticas. Por esa razón yo escribí un post en el que comento que lo importante no son las metodologias con nombre y apellido sino el que cada empresa arme SU propia forma de trabajo que le de mayor resultado.
    En este caso yo entiendo que todo lo que dice Ibon es correcto, todo.
    La tercera empresa en la que trabajé y la cual no tenia una metodología, era un completo desastre!!! un verdadero y absoluto desastre, era una cosa increible.
    Bueno, seguramente alguien dirá que es mejor utilizar una metodologia ya probada y conocida como scrum u otra antes de «inventarse una». Esto puede ser preferible en muchos casos y en otros no tanto. En mi primer trabajo haciamos un trabajo excelente con un producto gracias al liderazgo del que en ese momento era mi jefe. Nunca termin’e de entender el porqué se quizo implementar CMM allí donde las cosas funcionaban bien sin una metodolog’ia de terceros.

    Uyy, me fuí.

  13. @Fidel, por terminar que sino nos enfrascamos en una discusión que no tiene fin 🙂

    Vuelvo a repetir que el uso de una metodología no tiene por qué implicar mayor coste de proyecto, por lo que no usar una metodología si el proyecto es de 6.000 euros no me vale.

    Que en la gran mayoría de los proyectos no se use no significa que sea mejor no usarlas. Yo tb he estado en muchos proyectos sin metodologías sí…retrasos, horas extras, luchas con los clientes, clientes descontentos, fines de semana, código chapuza y en muchos casos, apelando a la heroica para salir adelante 🙂 Exagero un poco, pero bueno, la idea es esa.

    Desde que uso o intento usar una metodología las cosas me van mucho mejor y los grupos de desarrollo con lo que he trabajado tb están bastante más contentos…al menos eso decían.

    Un saludo!

  14. Rafa, estoy de acuerdo con lo que expones, en tu ejemplo detallas a la perfección lo que sucede si la implicación del cliente no es adecuada, tan solo decirte respecto a tu último párrafo en que dices que en proyectos pequeños no puedes estar todo el día codo a codo, utilizar una metología no implica que tengas que estar todos los días codo a codo con el cliente, el esfuerzo es directamente proporcional al tamaño del proyecto.

    Fidel, es cierto que muchas veces factores económicos y de otro tipo, hacen muy difícil la relación con el cliente, pero insisto, somos nosotros quien ponemos las normas, entiendo que decir que no a un proyecto en estos tiempos sobre todo para una empresa pequeña es muy complicado. Pero te pregunto, ¿En base a tus convicciones cuantas empresas dicen que no a un proyecto? o al menos trasladan al cliente las implicaciones que tiene no hacerlo de esta forma.
    Entiendo que cada cliente es un mundo, pero depende de nosotros transmitirle la necesidad de trabajar en equipo, en cualquier caso cometemos el error, de aceptar las normas del cliente sin estar de acuerdo y la mayor parte de las veces ni siquiera se lo comentamos. El verdadero error está en que aceptamos hacerlo sin resistirnos.

    He estado al frente de dos empresas de informática durante varios años, he visto de todo y he tenido que hacer de todo para subsistir, y créeme, se de lo que te estoy hablando. Aceptar un desarrollo de antemano sabiendo que no vamos a contar con la colaboración del cliente y que no vamos a poder establecer las reglas en las que creemos es un error. Esto lo he aprendido a base de tropezar con diferentes proyectos a lo largo de mi trayectoria profesional y no me lo ha enseñado ninguna metología.

    La metología ofrece una solución para estos problemas y depende sobre todo de nosotros utilizarla y sacarle valor, surge como una necesidad de muchas empresas que observan que su trabajo no se realiza correctamente.

    Creo que el dinero y el tamaño del proyecto no tienen nada que ver, para utilizar la metología de la que hablo, es más, si la utilizas, estoy seguro de que vuestros costes serán menores. Al menos los míos si lo son. No entiendo como los vuestros no.

    Ibon, estoy completamente de acuerdo, la metología aporta valor no genera costes, si una metología genera costes, no tiene mucho sentido utilizarla, la metología nos enseña a hacer las cosas bien y obtenemos grandes mejoras y beneficios, mejores estimaciones, mejor forma de trabajar, mejora de la relación del equipo de desarrollo, mejora de la relación con el cliente, mayor control, etc.

    buff, como me he enrollado….

  15. Juan,

    no estoy deacuerdo cuando dices que: «el esfuerzo es directamente proporcional al tamaño del proyecto», el esfuerzo es el mismo pero tendrás menos reuniones con el cliente o más. El esfuerzo tiene que ser lo mismo para uno grande que para uno pequeño. Puede ser que el esfuerzo del pequeño sea mayor que del grande, porque requiera que calcules cuantos planetas hay en el universo, y el grande sea 100000 formularios que cada uno haga una operacion distinta pero la mayor complejidad sea sumar 1 + 1… uno es en tiempo el otro en complejidad, en tiempo mas reuniones, pero sin complejidad…

  16. Quique, el tamaño de un proyecto, parte de una lista de tareas, como sabes, estas tareas tienen información sobre su duración, la duración esta basada principalmente en la complejidad de cada una de ellas, la suma de la duración de cada una de las tareas nos da el coste total del proyecto o al menos realiza una aproximación, por eso digo que el esfuerzo es directamente proporcional al tamaño del proyecto.

  17. Juan,

    A que te refieres con esfuerzo, economico? esta claro que no es lo mismo un proyecto de 1 dia con uno de 100 dias, economicamente hablando. Pero quizas requiera mas esfuerzo el proyecto pequeño por la complejidad, que el grande que puede ser bastante repetitivo. por eso sigo pensando que el esfuerzo NO es directamente proporcional al esfuerzo.

  18. Pues fijaros que yo creo que un proyecto puede tener éxito sin utilizar ninguna tecnología. Eso sí, el cliente debe de tener una implicación del 200%. Es una herramienta para conseguirlo, pero si el cliente no quiere participar, ya puedes usar Scrum, que la metodología más puntera del momento… En un 90% de los casos el cliente no va a tener lo que quiere.

    Además, a mí me parece mucho más caro conseguir la participación del cliente, que la inversión necesaria para aprender una metodología e implementarla en un equipo de desarrollo. En cada proyecto que no lo consigas, estás perdiendo dinero. Al final se reduce a n al cuadro de cambios en la funcionalidad, unas funcionalidades, que el equipo acabe hasta las narices de rehacer cosas y que un proyecto de 6 meses se convierta en uno de dos años, sin que el cliente este satisfecho con el producto.

    Ahora claro, conseguir que el cliente se involucre es muy costoso porque ya no sólo tiene el coste propio del proyecto en sí, sino que tiene un adicional, y es que el tiempo que te dedique no es gratis para él. Pero a mí me parece que es la llave para que el cliente piense que tiene el mejor producto del mundo mundial.

    Un saludo, Pedro.

  19. Pedro, estoy de acuerdo, sin la implicación del cliente es muy difícil sacar un proyecto adelante, está claro que la implicación del cliente tiene un coste para el, pero creo que al final se compensa abaratando el coste del proyecto, puesto la comunicación mejora y se evitan gran parte de los errores, que luego nos obligan a rehacer el desarrollo.

    Saludos.

Responder a anonymous Cancelar respuesta

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