(Fuente: http://www.dilbert.com/strips/comic/2009-12-07/)
Update: El título de este post es metafórico, “persona non grata” significa persona que no es bienvenida, acá significa empresa que no es bienvenida para hacer negocios. Esto porque este post ha generado un hilo de discusión en el forum de ChileAgil con mucha polémica debido entre otras cosas a la interpretación del titulo.
Hace algunas semanas, nos contactó una empresa con el objetivo de contratarnos para la implementación de un sistema. Había recibido buenas referencias nuestras en su búsqueda de empresas de desarrollo que fueran «confiables» y «trabajaran con calidad».
Luego de una primera conversación telefónica nos reunimos. Nos contó de que se trataba el proyecto y yo les presenté nuestra «filosofía» y «métodos de trabajo». Me pidió que le enviará un correo electrónico contando más sobre estas cosas para discutirlas con sus superiores y ver si realmente eramos lo que buscaban, además me entregó «el documento de requerimientos» del sistema que ellos mismos habían escrito y me dijo casi al despedirnos «Necesito una propuesta económica o cotización de los requerimientos que están en este documento» .
Era un documento muy vago, de 9 páginas y escrito con muchos tecnicismos de su negocio, en realidad no decia mucho, bueno en realidad no decia nada.
No ibamos a hacer la cotización, porque sencillamente no sabíamos que había que cotizar, y probablemente esta empresa tampoco lo sabia. Decidimos escribir un mail explicando lo que podiamos hacer para trabajar juntos, y comenzó un diálogo a través del correo electronico.Quiero compartir la conversación de la cual se pueden sacar algunas conclusiones, pero para nosotros la más valiosa fue que a esta empresa la declaramos persona non grata para trabajar.
Nota: La conversación fue editada para ocultar la identidad del cliente. El texto en gris son sus respuestas.
[1] ==================================================
Estimada Empresa,
Lo que sigue es un resumen de nuestra metodología de desarrollo . Esta es una especie de guía que debemos cumplir ambos y que de nuestra experiencia es la única forma de garantizar el éxito del proyecto.
Por favor, si tienes alguna duda podemos reunirnos para discutirlas en detalle.
De nuestra metodología ágil:
“No podemos cotizar lo que no sabemos cuanto va a tomar en esfuerzo aun…”
Partimos cotizando la(s) primera(s) semana(s) de consultoría (desarrollo) donde hacemos “Story Cards” o levantamiento de requerimientos junto a ustedes.
Es un tiempo intenso (exige muchas horas de ambos) donde en reuniones (participan los desarrolladores y los usuarios de negocio) escribimos en tarjetas los requerimientos del software colocando indicadores (número) del valor de negocio del requerimiento en las tarjetas (1 tarjeta = 1 requerimiento ).
Las tarjetas contienen en una especie de template, algo en la forma:
Para obtener <valor de negocio>
Como <role>
Quiero lograr <objetivo>
Además contienen criterios de aceptación en forma de escenario:
Dado que…
y que…
Cuando…
Entonces…
Todo esto sirve como comunicación entre el usuario y el desarrollador y además crea criterios de aceptación del requerimiento que en cada entrega parcial del software se valida (re-leyendo la tarjeta {“card”} ).
Las prioridades la coloca el usuario (o sea ustedes) por el valor de negocio que representa el requerimiento, es posible re-negociar todo el tiempo las prioridades con el equipo de desarrollo.
Una vez terminada la primera semana de levantamientos de Story Cards (este proceso es denominado ’story-carding’), los desarrolladores le colocan peso en esfuerzo (basado en su experiencia en escenarios similares) . Para esto los desarrolladores pueden separar el requerimiento en requerimientos más pequeños (un requerimiento grande es inestimable en esfuerzo)
Es importante definir bien los criterios de aceptación en las reuniones, pues es la única medida de que se ha terminado el requerimiento.
Para todo lo anterior usamos una herramienta online llamada “Pivotal Tracker” http://pivotaltracker.com
—–
De la implementación:
El entregable de esta primera etapa son los “Story Cards” del sistema más el esfuerzo de construirlo.
Si se aprueba, entonces en la segunda parte (construcción) partimos con el desarrollo de los requerimientos en orden de prioridad. Se crean iteraciones de un máximo de 2 semanas (puede ser de 1 semana). Cada semana tiene un entregable o release donde se ejecutan los criterios de aceptación del sistema junto al usuario de negocios (ustedes).
Si hay cambios (nuevos requerimientos), se crean nuevos story card, se valora la prioridad y en caso de ser alta, se estima y se re-organiza el backlog (pool de requerimientos a implementar en la próxima iteración.)
Del pago del proyecto:
Es siempre contra avance o entregable. El primer pago es una vez terminada la o las semanas de story carding. Los próximos pagos una vez entregados el release en cada iteración.
Se cobrán los avances en cada iteración (cada 2 semanas).
[2] ==================================================
Estimado continuum,
Me parece excelente la metodología AGIL, con la cual he trabajado en el desarrollo de proyectos, pero necesitamos tener una estimación de esfuerzo lo mas pronto posible, de acuerdo a los requerimientos entregados, si tienes dudas al respecto favor enviarlas a la brevedad, para acotar lo mas posible las actividades a desarrollar, ya tenemos la cotización de otros y con toda esta información tomaremos una decisión esta semana a más tardar la siguiente, por lo tanto necesitamos un orden de magnitud de costos para desarrollar este proyecto.
[3] ==================================================
Estimada Empresa,
¿Como puedes estar seguro que las demás empresas que dices que te enviaron cotizaciones entendieron los requerimientos y que estimaron el esfuerzo real?, ¿no has tenido ya pesimas experiencias con esta forma de trabajar?
No podemos estimar lo que no sabemos estimar, sería mentir (que en mi opinión es lo que están haciendo los otros con las metodologias clásicas de cascada) pues los requerimientos que tenemos son muy vagos y una reunión o una llamada telefónica no nos va a ayudar.
De la reunión que tuvimos lo único que rescaté fue que necesitan levantar los requerimientos junto al equipo que los va a desarrollar para poder comunicar que es lo que quieren e incluso para que a ustedes les quede más claro y puedan ordenar las prioridades.
En el mail anterior está la forma en que lo hacemos, si quieres una cotización para competir con los otros en tiempo o esfuerzo entonces preferimos quedar fuera, yo si tengo malas experiencias cuando trabajé en empresas que usaban este modelo y ahora tengo excelentes experiencias usando este nuevo paradigma, pero ambos tenemos que estar convencidos que es lo mejor, sino no funciona.
[4] ==================================================
Estimado continuum,
¿Cuanto tiempo necesitas para hacer el levantamiento que tu indicas y a que costo?
[5] ==================================================
Estimada Empresa,
Un equipo de 2 desarrolladores analistas. Nosotros trabajamos 35 horas semanales, y estarían disponibles para hacer el story-carding, pero ustedes tiene que garantizar el mismo tiempo de disponibilidad del usuario de negocios.
Si no es posible, tenemos que buscar una alternativa como por ejemplo 3 días corridos por 2 semanas o 3 semanas; Esto último en caso que no logremos escribir todo los requerimientos. Lo que si creemos necesario trabajar todo el día (sin interrupciones) para garantizar continuidad.
Entonces el costo aprox del “Story Carding” sería:
2 desarrolladores x [costo-desarrollador-hora-en-UF] UF/h x 24h x [2, 3] semanas = entre xxx.xx UFs (2 semanas) y xxx.xx UFs (3 semanas)
[6] ==================================================
Estimado continuum,
Eso seria factible si decidiramos hacer el proyecto con uds, lo cual aún está en evaluación junto con otros proveedores, en esta etapa del proceso necesito una estimación de parte de uds de que significa hacer el proyecto en tiempo y costo, pero no es factible que incurramos en un costo (esta semana que llamas story-carding), para que uds nos entregue este dato.
Te invito que nos hagas llegar tus dudas de los requerimientos o tener otra reunión para acotarlos, de manera que con su experiencia en el desarrollo de estos proyectos puedan hacer una estimación
—————–
Notas: En este punto ya tuve deseos de enviar un mail agradeciendo el contacto y que abandonabamos la negociación, esta empresa sencillamente no habia entendido nada y no queria entender. Esperé entonces algunas horas, debatí los mails con algunos de mis colegas en continuum y decidimos que enviariamos un correo más, esta vez un correo estratégico del cual sabiamos que o obteniamos una respuesta esperanzadora o terminaba la negociación, y así lo hicimos.
—————–
[7] ==================================================
Estimada Empresa,
En unas horas más te envio un correo de definición donde te daré algunas cifras y como podriamos hacer para mitigar el riesgo de ambos.
PD: No tenemos dudas en los requerimientos, porque no existen, hay que levantarlos (¿recuerdas los Story Cards?). Al documento que me entregastes le falta mucha información.
[8] ==================================================
Estimada Empresa,
Como lo que estás buscando es tener “Presupuesto en frente” te propongo lo siguiente:
En continuum creemos que cualquier desarrollo de más de 2 meses es demasiado grande para estimarlo adecuadamente en el largo plazo. En nuestra experiencia, siempre se cae en los problemas de:
(A).- Terminar construyendo cosas que en realidad se descubre posteriormente que no son importantes o nunca se usan.
(B).- No poder implementar las sugerencias o requerimientos nuevos que inevitablemente surgen.
En esos casos (proyectos grandes) lo que hacemos es estimar por 8 semanas primeramente y sino alcanzamos, re-estimar por 8 semanas o menos más, y así iterativamente hasta terminar o alcanzar un punto de “Valor de negocio confortable” (a veces ocurre que el cliente se conforma con una parte del sistema que le sirve para operar). Sin embargo no faltan los clientes que piden requerimientos sin valor de negocio porque “creen” que algún día les servirá sin pensar en que estan afectando el presupuesto.
Entonces, nada garantiza que en 8 semanas se implementen todos los requerimientos con “Valor de negocio” de tu sistema.
La semana de Story Carding (que está incluida en los 2 meses) dirá que tamaño tiene el sistema que quieren construir, ustedes deberán decidir que requerimientos tienen más valor de negocio y por tanto mayor prioridad.
Nosotros estimamos los tiempos de estos requerimientos y los requerimientos que no puedan ser implementado dentro de las 8 semanas debemos renegociarlos en la forma:
(1).- No lo hacemos.
(2).- Estimamos el costo del nuevo desarrollo. Como otro proyecto de X tiempo más (el tiempo que demoren los nuevos requerimientos).
Costo x 2 meses = 2devs x [costo-desarrollador-hora-en-UF] UF/H x 35H/semana x 8 semanas = xxx.xx UF (Total)
…
No obtuvimos respuestas. Fin de la negociación y declaración de persona non grata.
…
