¿Debemos cambiar la forma de vender software?…

Uno de los problemas más graves en el desarrollo de aplicaciones, sobre todo en los desarrollos a largo plazo, se produce cuando se realiza la estimación, los factores que la rodean como los plazos, personas que conforman el equipo de trabajo, nivel de formación, necesidades y otros factores hacen que este sea uno de los procesos más complicados de realizar.

La mayoría de las veces, las empresas suelen fijarse en desarrollos similares para realizar una estimación, otras simplemente tiran un dado al aire, lo multiplican por un factor determinado para evitar pillarse las manos y se lo ofrecen al cliente.

Lógicamente, muchos proyectos realizados de esta forma no cumplen las expectativas o simplemente fracasan, en otros, los menos, el cliente ha pagado un sobreprecio por la solución. Cuando esto sucede se suelen producir daños colaterales, la empresa que, inicialmente ha estimado mal el proyecto, traslada la presión y la culpa al equipo de desarrollo que en muchos casos ni siquiera participa de las decisiones comerciales.

¿Cómo se puede estimar un proyecto, del que es prácticamente imposible conocer todas sus interioridades, porque un análisis a fondo nos llevaría casi más tiempo que el propio desarrollo, y del que desconocemos muchas de las implicaciones que tiene a lo largo del proceso de implantación?

A veces el cliente acostumbra a hacerse una idea equivocada, de una solución que desconoce, que en muchos casos ve por primera vez cuando se realiza el proceso de implantación, es decir cuando el proyecto está prácticamente terminado. Este, cuando ve la aplicación observa que hay algunas cosas que no le gustan y procede a cambiarlas, los cambios se producen una vez el desarrollo a finalizado y suelen provocar que gran parte del proyecto se tenga que volver a reconstruir, con el consiguiente coste, difícil de repercutir y que genera numerosos problemas dañando la relación empresa-cliente.

Pienso que una estimación a largo plazo es completamente imposible de realizar en base a un análisis exhaustivo, en cambio será mucho más sencillo estimar lo que vamos a realizar a corto plazo. Creo que se debe cambiar la forma de vender software, ya que estos errores se arrastran a lo largo de todo el proyecto.

La venta de software debería basarse en ideas como las que proponen las metodologías agiles. El cliente debe formar parte imprescindible del equipo de trabajo, del que recibiremos el feedback y nos ayudara a lo largo del proceso de desarrollo, la entrega paulatina de pequeños «módulos» completamente funcionales que conformaran la solución, permiten que el cliente pueda probar parte de su aplicación, observar el progreso que se va realizando y alterar o mejorar su funcionamiento a lo largo de todo el proceso de desarrollo, los pequeños cambios y propuestas de mejora se producirán de forma paulatina evitando rehacer gran parte de la aplicación. El cliente ira pagando de forma progresiva el trabajo realizado, contento, porque sabe que su aplicación va cumpliendo los objetivos acordados y que además está abierta a sufrir cualquier tipo de variación si es necesaria a lo largo del proceso de desarrollo.

Cambiar el hábito de vender una aplicación que normalmente puede sufrir muchos cambios, es algo muy difícil de comprender para las empresas y todavía más difícil para los clientes que quieren comprar un desarrollo de software, esto fundamentalmente se debe a las malas experiencias que han tenido y quieren a toda costa cerrar un presupuesto y obtener un compromiso serio por parte de la empresa.

Creo que el proceso para convencer un cliente, pasa simplemente por realizar las primeras entregas de software, cuando el cliente observa que se esta entregando parte de su aplicación, y que paga únicamente por aquello que ya tiene, las dudas desaparecen. Si el módulo desarrollado es lo suficientemente independiente puede comenzar a amortizar la inversión de manera inmediata y no esperar a que se encuentre finalizada completamente.

Las gestión de estas pequeñas entregas de software que se van realizando, conformaran una estimación final mucho más real que cualquier estudio pormenorizado, y nos dará una visión del progreso mucho más real, proporcionándonos además un dato muy importante, la velocidad real de nuestro equipo de desarrollo, que nos ayudara a mejorar la estimación de las siguientes fases del proyecto. Estas estimaciones recogerán todas las desviaciones que se produzcan a lo largo del proceso conformando así parte del proyecto.

Os recomiendo la lectura de los posts de Rodrigo sobre estimaciones agiles y Scrum.

http://geeks.ms/blogs/rcorral/search.aspx?q=estimaci%c3%b3n

http://geeks.ms/blogs/rcorral/search.aspx?q=scrum

 

 

 

15 comentarios sobre “¿Debemos cambiar la forma de vender software?…”

  1. En mi opinión tienes razón en muchos de los puntos que comentas, pero yo resaltaría que cuando dices que es necesario integrar al cliente en el equipo de trabajo, lo más importante es encontrar a la persona dentro del cliente, la cual esté suficientemente preparada y motivada para ser ese punto de conexión fundamental para lograr que el proyecto tenga éxito. Si nos confundimos de persona o no existe no hay nada que hacer.

  2. @Eduardo, yo creo que lo importante es que el equipo oiga a través de una única voz las necesidades del cliente. Si esta voz, es del propio cliente, perfecto, sino, pues alguien del equipo tendrá que preocuparse de descubrir y priorizar esas necesidades.

    @Juan, espero que comentes cosas sobre como os ha ido con Scrum.

    ¡Un saludo!

  3. Si esto te parece compilcado (que lo es) imagínate el desarrollo continuo sobre productos estandard que se versionean cada año.

    En este plano que comentas al menos cuentas con un cliente que te va diciendo por donde ir.

    Pero el desarrollo de aplicaciones estándar es lo mas chirriante para los oidos (y para el alma) que puedas encontrar: un grupo de usuarios te reclaman un conjunto común a todos ellos de mejoras que justo otro grupo de usuarios te advierte que «eso» entorpece la operabilidad de la aplicación y es algo por lo que no piesan pagar.

    En informática, lo fácil es difícil, y lo difícil es el dia a dia.

  4. Hola Juan!
    Estoy muy de acuerdo en lo que dices, de todos modos cambiar el sistema es muy complicado ya que cuando ciertas entidades(Gobiernos, ayuntamientos, empresas grandes…) sacan un pliego, quieren una oferta del coste total del proyecto y esto es algo complicado…
    Ahora estoy en pleno proceso de implantación del modelo CMMI y aunque no tenía plena confianza en este sistema de trabajo, soy de una manera de penbsar mas «agil» ;), he observado que los métodos de estimación son muy buenos, y que mejora con la experiencia y que se puede abordar y presupuestar un proyecto grande, con una tasa de error muy baja.

  5. @Miguel, CMMI no dice nada sobre cómo debes estimar. Así que los métodos de estimación serán los que vosotros o vuestro consultor de CMMI elijáis.

    Dicho, esto, hay un cambio radical, absoluto y espectacular entre estimar de manera explicita, sea como sea y no estimar de manera explicita.

    Las administraciones no son reacias a Scrum o el desarrollo ágil, el problema es que nadie se lo explica. Yo cuando he hecho el esfuerzo siempre a sido fructifero. Los clientes sean los que sean, lo que quieren es ver que tienes un camino claro para cubrir sus necesidades y aportarles valor. CMMI es un camino claro para trasladarles tus costes metodológicos, y para diferenciarte mediante una certificación, pero no tengo tan claro que sea un camino para trasladar valor. Pero bueno todo el mundo sabe que yo prefiero un efoque ágil frente a un enfoque CMMI :).

    @Julio, precisamente en la situación que describes es cuando es más importante tener un Podruct Owner o Product Maneger que aune las voces de los clientes actuales y potenciales y haga un trabajo de continua priorización de las necesidades. Seguro que hay más peticiones de los clientes que las que podéis abordar, la clave está en hacer aquellas que aportan valor y evitar aquellas que solo aportan valor a un número muy limitado de la base de clientes. Hay técnicas para asegurar que aciertas, en la medida de lo posible, en este proceso.

    ¡Un saludo!

  6. @Rodrigo, a mi me exigen tener unas tablas de estimaciones donde quede muy claro, por ejemplo, la complejidad del formulario (nº de controles, grids, busquedas, ordenaciones…), tipo de formulario (web, ajax, disp. movil, wpf, forms…), la habilidad y la categoría del desarrollador y eso genera la estimación que mas el factor de ajuste del jefe de proyecto da la estimación, todo esto debe quedar registrado en un histórico que de una media… el objetivo es no dejar la estimación completamente al estado de ánimo, optimismo y experiencia del que estima… el caso es que esta es la exigencia, para acceder a CMMI nivel 2, esperando llegar al 3 en un año… Yo al igual que tu, tenia mis dudas (vamos que no confiaba en que aportase valor, solamente coste) el caso es que yo ya estoy empezando a ver las ventajas del modelo y en concreto la estimación me parece muy buena.
    Mas que nada veo que CMMI evita riesgos y dependencias de personas, si todo está documentado y organizado.
    Volviendo al ejemplo de la estimación, si cambia el jefe del proyecto…, en que se basa para estimar ¿? pues con este sistema tendrá unas referencias sólidas para realizar sus estimaciones.
    Voy a escribir un post de mis esperiencias con CMMI (las buenas y las malas) y lo discutimos sobre él ¿os parece?

  7. Eduardo, te contesto lo mismo que a Rodrigo.
    Rodrigo, entiendo lo que dices de tratar que el equipo oiga a través de una única voz para no distorsionar el contenido, si bien, tengo mis dudas con esta afirmación.

    En el caso de que la persona elegida no tenga un perfil adecuado, es decir “sea capaz de captar y comunicar perfectamente las necesidades de la empresa y de aquellos que trabajan en ella”, el desarrollo se realizara de manera errónea.

    En mi opinión si hacemos esto, corremos un riesgo enorme, nos apoyamos en el “saber hacer de una sola persona”, he descubierto a través de la experiencia, que la mayor parte de la gente desconoce el trabajo de otras personas y que muchas veces se crea una opinión errónea de su trabajo, incluso con aquellos que les rodean, creo que es importante hablar con las personas que realizan los cometidos de forma individual, ya que son ellos los mejores conocedores de su trabajo.

    Lo ideal para mi, seria obtener la información del responsable conjuntamente de las personas que realizan el trabajo, entiendo que esto pueda entrañar ciertas dificultades, creo también que la persona responsable la encargada de realizar este trabajo, pero obtener dos puntos de vista de forma directa nos puede aportar visión de ciertos aspectos que de otra forma desconoceríamos.

    Intentare hablar, solo un poco de nuestra experiencia con Scrum, ya que no me considero un buen ejemplo a seguir, sin bien estoy completamente de acuerdo con la metodología, fallamos en que no tenemos la suficiente disciplina para sacarle el partido que realmente merece.

    Julio, simplemente es una cuestión de disciplina, si llevas a cabo un solo proyecto utilizando una metodología como “Scrum”, te darás cuenta de forma inmediata de sus beneficios, es lo mismo que trabajes con un proyecto a que trabajes con cien, entiendo la problemática con “ciertos clientes”, ya que en esta vida me ha tocado lidiar con todo tipo de gente, pero te puedo decir que metología se adapta a tu trabajo y no como piensan algunos “tú te adaptas a la metodología”, es un método que te facilitara el control de tu proyecto y te dará información importante sobre tu velocidad de desarrollo pudiendo realizar una estimación mucho más real, fomenta el trabajo en equipo y aporta muchas otras ventajas. Pero no pienses que es la solución a todos los problemas de un desarrollo y de la relación con tus clientes.

    Miguel, siento decirte, que, de lo poco que conozco de CMMI, me parece de todo menos una metodología ágil, me parece más un proceso que burocratiza todo lo que haces, pero no me hagas mucho caso, no soy ningún experto de CMMI, y pienso que es mejor utilizar una metología que no utilizar ninguna. Siempre se aprende algo.

  8. Sobre CMMI, yo pensaba lo mismo, Juan, pero tras unas formaciones y experiencias, ya empiezo a ver la luz al final de este tunel (CMMI) y creo que va a aportar control a los proyectos… bueno, ya os contaré mas 😉

  9. Hola a todos.

    @Miguel, no entiendo muy bien como podeis estimar en función de criterios como el numero de controles, grids y ese tipo de cuestiones ¿significa que un formulario con 8 controles es el doble de complejo que uno que sólo tiene 4? ¿no tendrá más complejidad la lógica de negocio asociada a esos controles que los controles en sí?. No sé, a mí esto de estimar siempre me ha parecido harto complejo y los intentos que hemos realizado con criterios parecidos al que propones no nos han dado mucho resultado. La verdad estoy intrigadísimo porque cuentes como os va con ellos.

    Un saludo.

  10. Hola Juan,

    Yo veo acá algunos conceptos que si bien están muy relacionados entre si, no son lo mismo. En tu post tocas, sin hacer una segunda lectura más profunda, 4 temas distintos:

    – Estimaciones.
    – Presupuestación (relacionado pero un tema aparte)
    – Negociación (por lo menos en cuanto a los cambios de requerimientos que mencionas como ejemplo)
    – Metodologías.

    En cuanto a las estimaciones…ummm.. que decir, son todo un temas, hay mil técnicas y a mi entender no hacen mucha diferencia ya que por el concepto de «cono de la incertidumbre» todas te dan un valor bastante alejado. Cuando usas mas de una técnica podes reducir un poco el error, pero bueno, EL libro es el de McConnell (imprescindible leerlo).

    La presupuestación es un tema totalmente aparte. Contempla las estimaciones pero no es una función directa. Es otro tema.

    En cuanto a los cambios en los req. (cuando el cliente quiere cambiar cosas que no le gustan) ese es un «nuevo trabajo» que se debe estimar y presupuestar nuevamente, no significa que si el cliente quiere cambiar todo el sistema uno lo tiene que rehacer gratis. No hay que confundir esto, es importante.

    Las metodologías no tienen mucha relación con las estimaciones más allá del marketing. Por ejemplo, si quiero estimar una tarea y estoy utilizando una metodología agil nada me impide utilizar una que usan mis amigos en sus proyectos con CMMI 5. Lo que pasa es que el m’arketing hace que las cosas mal sonantes se relacionen con CMMI (ej: cocomo II) y a s m’as naturales y habituales les ponemos la palabra «ágil» para que suene mejor (ej: tecnicas de estimación agiles). No existen las tecnicas de estimación agiles, son solo tecnicas de estimación y algunas ultraconocidas pero rebahutizadas. No hay nada nuevo bajo el sol en cuanto a estimaciones.

  11. Lucas, te agradezco mucho tus comentarios, te sigo desde hace tiempo.

    Sobre el post te diré varias cosas:

    Yo estoy hablando de gestión de proyectos en general, para mí la estimación, presupuesto, negociación, metologias, equipos de trabajo, etc, son partes de un proyecto, del que solamente me interesa una cosa, que sea exitoso, entiendo que un proyecto está compuesto por infinidad de factores relacionados, los que comento en este post son dependientes unos de otros, es muy raro verlos por separado aunque admito que se puede dar el caso.

    No soy un experto en estimaciones, tan solo expongo la que utilizo con Scrum, sé que hay muchas formas de estimar, te agradezco lo del libro, tratare de leerlo.

    Yo nunca he dicho que los cambios no tengan que repercutirse al cliente, digo que es una posibilidad que se abre para que el cliente pueda realizar modificaciones y adaptar mejor su programa en la misma fase del desarrollo, con lo que los efectos colaterales serán menores.

    La presupuestación desde luego que tiene factores añadidos, pero la estimación suele ser uno de los valores que más relevancia tienen en esta fase, aunque no siempre, estoy de acuerdo con lo que dices.

    En Scrum, estas estimando cada tarea y en cada sprint evalúas las tareas que puedes realizar durante un periodo de 20 a 40 días, sin estimación perderia mucho de su valor.

    En cualquier caso aprovecho para hacerte una pregunta ¿Podría funcionar cualquier metología agíl sin estimación?

    Me gustaría hablarte de lo que pienso de la estimación, pero no quiero alargarme más, intentare pensarlo bien, y dentro de unas semanas quizás escriba un Post.

    Saludos y gracias por tus comentarios.

  12. Creo que estamos de acuerdo en todo. Yo solo expongo algunas cuestiones y nada mas que eso. Es un tema dificil. Este es el segundo año que tomo el curso obligatorio de estimaciones (16hs en dos dias solo de esto parace mucho, al menos a mi me parece) y siempre se dan discusiones que a veces resultan muy interesantes como las que planteas aquí.

    Casi siempre por mi defensa sobre ciertas formalidades me acusan de antiagil o ridiculeces por el estilo pero realmente no es así, es solo que reconozco mucho marketing en todo esto. Cualquier pibe que nunca ha trabajado «sabe» que las metodologias agiles son mejores que las ingenieriles y eso solo se logra mediante marketing. Todo el que toma un curso sobre estimaciones formales sale como hipnotizado, como si hubiese tomado la pildora roja, y ese lavado de cerebro es marketing también.

    Lo que dices sobre las estimaciones de los sprints de scrum creo que es una de las mejores cosas que hay. Estimando por sprints hace que la incertidumbre se reduzca muchísimo y eso redunda en mejores estimaciones ya que no tenemos un cono gigante sino muchos conitos. Ahora, es posible que para presupuestar debas entregar una rom a tu cliente. Como lleves adelante tu proyecto luego es cosa aparte. Se que muchos quisieran no tener que hacer esto y simplemente pactar con el cliente cada parte del proyecto pero el mundo no es así. Aunque todo es relativo, no todo lo que funciona para proyectos de 3 meses aplica para proyectos de un año, ni es lo mismo hacer soft para una cadena de comidas rápida que hacerlo para el gobierno, bancos, aeropuertos. Todos se pactan de manera diferente.

    Un ejemplo que no se si viene al caso pero hace dos meses que en mi equipo trabajamos con timeboxs (tenemos un deadline definido) y estimamos con wideband para estimar cuanto podemos hacer en ese tiempo y luego lo negociamos con el cliente. Aquí, los conceptos que te mencionaba están muy divididos ya que el presupuesto es muy simple: un ing x mes = $xxxx –> 4 ing. x 3 meses = 12 x $xxxx.
    Las estimaciones no se relacionan con el presupuesto en este caso. Y la metodología es una mexcla infernal, en este momento nosotros no la hemos elejido todavia y nuestro cliente interno usa scrum y en general todos conocemos cmmi y así.

    Bueno… me fuí por el teclado 🙂 sorry.

    Un abrazo.

  13. 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 administracion de proyectos, metodologias agiles y demas. Con la experiencia que tengo en este mundo, ya van 11 años, mi opinion es que estas metodologias solo sirven para grandes o grandisimos proyectos en los que esten metidos asesores externos y personal tecnico del cliente o para proyectos internos, es decir para los propios proyectos de empresas de software. ¿Por que?, 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 informatico. El cliente solo paga cuando el trabajo está hecho, es muy bonito que el cliente vaya pagando segun los modulos entregados, pero la verdad es que si el cliente no tiene todo, la tipica frase es: «No tengo nada». La implicacion del cliente o del maximo responsable de tu cliente la mayoria de las veces es escasa o mas bien nula, y lo entiendo, esto es diferente a todo lo demas, 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, esta en la mayoria de los casos es «estandar» como el software y cuando esta me la entregan no se adapta a mis necesidades (como dicen mis clientes con sus programas), pero lo unico que puedo hacer es joderme y esto esta asumido por la gente, no asi en el caso del software. Realmente es un mundo y un tema para tesis doctoral, yo en este mega comentario no aporto nada, lo se, pero es que no tengo ni idea de que aportar…. Esto sirve muchas veces de terapia, lo se, los psicologos deben de tener sus consultas llenas de jefes de producto.

Responder a anonymous Cancelar respuesta

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