(ya te digo : 15 años de “tecnico”)

Siguiendo tu propio razonamiento. Llego a un cliente que no me conoce de nada, y me he plantado delante de él usando alguna de las opciones que mencionas.
Qué motivación o seguridad tiene ese cliente a la hora de embarcarse con mi empresa en un proyecto a largo plazo? Invertiría miles de dólares o euros en un proyecto de 6 meses, 1 año… etc?

Considero que una metodología ágil, bien aplicada y comprendida, soluciona este escoyo inicial.

Cuando uno negocia un contrato con un cliente, se puede hacer de diversas maneras. Lo habitual es pactar un número de iteraciones.

Cada Iteración como tal consta de varios días, nosotros usamos iteraciones de una semana, pero hay equipos que usan iteraciones de 2 o 3 semanas. (Iteraciones más largas no son realmente recomendables ya que en el caso de fallar algo, o tomar otro rumbo, tirar a la basura el trabajo de 4 o mas semanas duele mas).
Pongamos el caso de iteraciones semanales.
Esa iteración consta de 5 días laborables de 8 horas cada día. Ni más ni menos.
Y tu eres libre, en función de tu experiencia y trayectoria, de fijar el precio / hora.
Eso es relativamente flexible, pero esta aproximación nos da un acercamiento más o menos directo e intuitivo de como puedes fijar el costo de una iteración.
Tu pactas con tu cliente un número de iteraciones a $X.XX/iteración y el cliente decide si lo compra o no.
Cuál es la ventaja de este acercamiento?
El cliente, si no te conoce, puede decidir arriesgar unos miles de dolares, ver cómo se desempeña y ver si el proyecto es realmente viable en 2, 3 o 4 semanas en lugar de tener que invertir cientos de miles de dólares y no ver resultados finales hasta 6 meses después.

IMHO creo que este acercamiento, cuando es entendido por los clientes (y eso es otra historia bieeeen distinta) es beneficioso para ambas partes.
- Por un lado el cliente, invirtiendo menos dinero, tiene una idea de cuál es la velocidad real a la que tu equipo puede proporcionar resultados. No vendemos motos, vendemos “working software”
- Y por otro lado el equipo decide si el proyecto es realmente viable, si es capáz de llevarlo a cabo y les resulta interesante.

La transparencia es una de las premisas del desarrollo ágil, y ahí choca de lleno en muchas ocasiones con las prácticas habituales en las grandes corporaciones.

Yo, como cliente, preferiría tener mi software en un servidor de pruebas (por ejemplo) para jugar con él a medida que se construye e inspirarme para ir modelando lo que realmente quiero, a tener que reunirme cada x tiempo con un señor (aka jefe de proyecto) y que me cuente como van las cosas sin poder verlas realmente.

Y efectivamente, tal y como sugieres ágil no usa jefes de proyecto (jaja y por la palabra que usaste para definir a los programadores -técnico- intuyo que debes trabajar en algún cargo similar).
En lugar de un jefe de proyecto, es mucho más útil la figura del “Product Owner”
Pero el comentario ya está quedando muy largo e igualmente eso va a ser material para el próximo post

Llegas a un cliente que no te conoce (tal vez alguien le ha dado referencias tuyas, le has conocido tomando cervezas, o le has echado morro y te has plantado en su puerta) y te plantea una necesidad que tu te crees poder proporcionar….
cómo le haces la oferta económica ? le vas a decir que ya ireis viendo semana a semana cuánto le cobras ? cómo se va a embarcar en un proyecto sin saber cuanto tiene que aprovisionar ?
Obviamente tiene que haber una relación contractual donde se delimiten todas estas cosas.
Agil me parece una buena metodologia para proyectos internos pero no te puedes basar solo en ella para ir a un cliente a desarrollar algo personalizado.

IMHO creo que el método Agil confunde al técnico haciendole creer que puede substituir a un jefe de proyecto sólo porque vas a hacer entregas por iteracciones. Creo que lo que suele faltar en todos estos proyectos es un buen jefe de proyecto con método y experiencia. Me atrevo a recomendarte (si no lo has hecho ya) que le eches un ojo por ejemplo a PRINCE2

La diferencia con la lavadora es que ya es un producto acabado con una funcionalidad especifica donde hay muchos modelos. Si tu software es de este estilo (instalar y usar) no hay diferencia, pero si como planteas me vas a hacer una lavadora a mi gusto pues yo creo que no se puede comparar.

A mi siempre me ha gustado mas la comparacion con construir un edificio : un edificio siempre es un proyecto único, aunque sea copiar el de al lado. Porqué un edificio sí se construye en un año y un maldito programa no termina nunca ?

Un saludo.

p.d.
ahora eso sí, lo que cuentas del mercado madrileño es que lo has clavado.