Proyectos a Costo Fijo: Vendiendo un Producto, no un Servicio

Hay un cliente que no esta conforme con los resultados de un proyecto Time and Materials, entonces se esta charlando para ver si se puede cambiar a la modalidad de costo fijo, para futuros proyectos.

La idea en estos proyectos es vender un producto, con su garantía, y asumir los riesgos que esto pueda implicar. Obviamente esto se comienza con las especificaciones cerradas del producto a desarrollar. Si en el medio del desarrollo al cliente no le gusta lo que pidió, todo cambio se cobra aparte. Además dependiendo del tiempo se arma el equipo. Igual es importante dejar claro que esto no es para nada lineal. Nueve mujeres no pueden tener un bebe en un mes, se necesita una mujer y nueve meses.

Estamos estimando un proyecto para este cliente, y le mandamos un costo. Luego de esto, el cliente nos pregunto por las estimaciones. Luego de deliberarlo, decidimos mandarle la estimación de desarrollo, separada en tareas. El objetivo del cliente era ver si habíamos sobreestimado cosas y si habíamos contemplado todo lo necesario. Luego de esto, el cliente pidió un plan completo con todas las horas de cada rol que va a intervenir en el proyecto y también pidió a una persona especifica para que lo lidere técnicamente.

El tema en dar esa información, es que va un poco en contra de la idea de un proyecto de costo fijo. Uno cuando compra un televisor, se lo lleva con la garantía. No le pregunta al vendedor cuanto costo cada circuito, ni cuanto tiempo se tardo o cuantos operarios lo instalaron. La cosa es que el cliente necesitaba estos tiempos para venderle el proyecto a su cliente, porque no podía ir y decirle, sale X plata y listo. Mi cliente podía ir a otra empresa proveedora de software y preguntarle cuanto le costaba que le hagan lo mismo.

Lo que intuíamos es que el cliente con esa información iba a calcular el precio hora que le cobrábamos, compararlo con la anterior contratación y quejarse. Obviamente el precio hora de un proyecto de costo fijo es distinto a un proyecto donde se cobra por hora. Dependiendo del riesgo y de lo que se va a hacer, también así como del periodo de garantía, se arma un precio. Nada es gratis.

Otro factor es el equipo, nosotros elegimos quien, los seniorities, y cuanta gente. Total el riesgo es nuestro de entregar lo que se pidió en X fecha y con el nivel de calidad acordado.

Al final parece que le vamos a revelar la información de las horas al cliente, todo por lograr vender el proyecto. Épocas dificiles.

Modalidad de Proyecto: "Capped" Time and Materials con Garantia: Salgan corriendo!

Estoy ejecutando un proyecto Time and Materials con limite de tiempo (y dinero, por eso "Capped") y garantía: realmente es complicado.

Al principio no pensé que habría problemas, pero ahora que esta finalizando, los estoy viendo con mis propios ojos. Cuando mis colegas se enteraron que estaba ejecutando un proyecto de tales características, me dieron su pésame, me dijeron que era el peor tipo posible.

Yo pensaba inicialmente, que puede pasar? Vamos haciendo los features durante los distintos sprints (Utilizamos Scrum), y en el ultimo cerramos los bugs y listo.

El tema es que el primer problema fue que nos pasaron los requerimientos el primer día del primer sprint, o sea bastante tarde. Se armo el equipo teniendo en cuenta un proyecto similar anterior con el mismo cliente. Al final el tiempo de diseño era mucho y el de desarrollo poco, pero por suerte no afecto mucho esto.

Mientras iban pasando los sprints, veíamos que no íbamos a poder a completar todo el backlog. Ahí me empezó a agarrar miedo, sinceramente. El cliente tenia la idea de que se podía hacer todo en el tiempo dispuesto. Ahora estamos en el ultimo sprint, y por suerte muchas features se sacaron de scope, y estamos cerrando bugs. El tema es que lo que puede pasar es que l cliente quiera que completemos features en estos últimos días y luego los bugs se vean por garantía. Mi objetivo es no ejecutar garantía, obviamente, para no perjudicar el margen del proyecto. Estoy en una situación medio tensa con el cliente porque tengo que convencerlo de cerrar lo que esta, corregir los bugs, para poder tener algo listo para producción, y que luego nos contrate por mas tiempo para terminar el resto de los features.

Por suerte tenemos charlas diarias con el cliente, y ellos ven que tenemos una velocidad de desarrollo decente, y que progresamos. Mi objetivo es hacerle entender que tenemos que cerrar todo estos días y que entienda que no quiero ejecutar garantía. Lo bueno es que parece que esta entendiéndolo, porque están ajustados con el tiempo para lanzar el producto, o sino no me entenderían y tratarían de que hagamos features y dejemos bugs para la garantía.

Creo que teniendo en cuenta las cosas que podían pasar, la estoy sacando fácil, pero todavía no canto victoria hasta que termine el ultimo sprint. No, mejor, cuando termine el periodo de garantía.

The Design Of Everyday Things

The Design Of Everyday Things, de David Norman es básicamente un libro de usabilidad. Realmente hice mal, porque leí la continuación de este libro, Emotional Design, antes de leer este, pero igual disfrute ambos un monton.

El objetivo de este libro es apoyar el diseño centrado en el usuario, una filosofía basada en las necesidades e intereses del usuario, enfatizando que se hagan productos utilizables y entendibles.

El diseño de cada producto debe:

• Facilitar al usuario la determinación de que acciones son posibles en cada momento.
• Hacer visible las cosas, incluyendo el modelo conceptual del sistema, las acciones alternativas y el resultado de las acciones.
• Hacer fácil evaluar el estado actual del sistema
• Seguir un mapeo natural entre intenciones y las acciones requeridas, entre acciones y el efecto resultante, y entre la información visible y la interpretación del estado del sistema.

En otras palabras, lo que quiere enseñar el liibro es que los diseñadores se aseguren que el usuario pueda darse cuenta que hacer y que el usuario pueda darse cuenta que esta pasando. Algo básico que no pasa. El libro esta lleno de ejemplos muy interesantes e ilustrativos, vale la pena leerlo si interesa el tema.