Desde que trabajo con Ruby on Rails como freelance, mi trato con los clientes ha cambiado radicalmente, respecto a la manera de trabajar “a la antigua” que tenía en las empresas donde estuve anteriormente.
Antes, se trataba a toda costa de blindarse contra el cliente. El cliente era el enemigo, malo, tonto y perverso por naturaleza, así que la idea era protegerse contra él. Las principales armas eran dos, la primera redactar un contrato especificando lo más en detalle posible el alcance de la aplicación a desarrollar; la segunda, el secretismo hasta el final: no enseñar nada del desarrollo hasta que se llegue a la fecha acordada, no sea que comiencen a opinar y nos cambien algo.
Estas dos armas siempre se demostraron inútiles y engorrosas, y más que facilitarnos la vida, nos la complicaban. Que el cliente nunca sabe lo que quiere es una verdad como un templo, y para comprobarla basta con ponernos en su lugar.
Afortunadamente, han llegado nuevos tiempos y sabemos que hay mejores maneras de hacer las cosas, que nos harán a todos mucho más agradecido nuestro trabajo.
Una vez asumido que el cliente no es el enemigo, hemos de integrarlo en el proyecto. Demos por hecho que no sabe lo que quiere, así que trabajemos con él para definirlo. Nuestras nuevas dos armas serán dos: especificaciones compartidas, y prototipado rápido.
Una buena manera de trabajar en especificaciones compartidas es usar Google Docs para redactar un documento en común donde apuntaremos los objetivos del proyecto. Google Docs nos permite compartir un documento a través de un procesador de textos común, donde todos los interesados pueden editar, y tendremos un historial de revisiones del documento, al que podemos recurrir en cualquier momento para ver los cambios.
Como complemento, recordando que una imagen vale más que mil palabras, y un interfaz no digamos, haremos uso de Rails para desarrollar un prototipo rápido, con las ideas básicas de la aplicación, y lo tomaremos de referencia para concretar con el cliente lo que quiere, dándole acceso desde el principio, incluso antes de haber terminado de redactar las especificaciones.
A mí me funciona de maravilla… ¿Y a vosotros?
2 comments ↓
Yo estoy en empresa, y no se puede trabajar de forma CERRADA. Como dices un cliente nunca sabe lo que quiere.
Yo ahora me encuentro en un proyecto de un cliente, que a su vez tiene un cliente pidiendole modificaciones. Super-divertido. Cambios al cuadrado. Lo mejor es ser lo más fléxibles posibles, y entregarles versiones funcionales cada muy poco tiempo con los que ellos puedan toquetear y ver pos donde les cojea (o que se les ocurre)
Yo el problema que veo es como lo plantear de forma económica. ¿ Podrias explicar como lo haces tu ? Cuando te dan los requesitos, puedes saber el tiempo y el precio. Pero cuando programas de forma flexible, pocos clientes confiarán en que uses las horas que quieras. Poner un precio al proyecto, siendo flexible es pillarte los dedos, porque un cliente, cuando comienza a pedir… pide pide pide, tiene mil ideas. Acabarias perdiendo dinero.
¿Como lo solventas tu?
Hola Manu, es cierto que uno de los peligros de ser tan flexible es que se nos vaya de las manos y vayamos de cambio en cambio sin cerrar nada, y esto con presupuesto cerrado es un peligro… llega un punto en que comenzaríamos a perder dinero. Una solución es cobrar por horas, claro… ahí seguro que cuando el cliente vea que los cambios que pide se hacen, pero se cobran, se irán calmando poco a poco…
Pero mi post va encaminado a, precisamente, ser capaces de cerrar unas especificaciones en las primeras fases del proyecto. Me parece que, cuando trabajamos con un presupuesto y/o plazos cerrados, hemos de cerrar las especificaciones cuanto antes podamos. Lo que es irreal es cerrarlas antes de comenzar a programar, porque ni el cliente ni nosotros sabemos qué es lo que tenemos que programar. Por eso propongo el compartir la redacción de las especificaciones con el cliente, y apoyar eso en un prototipo inicial que se irá cambiando conforme se revisan las especificaciones, para finalmente, cerrarlas y comenzar a programar “en serio”.
Esto no quita para que después estemos abiertos a cambios, pero creo que es importante tener bien definido el proyecto al principio, en líneas generales, para ponerle un coto a la versión 1… las mil ideas que le surjan después las podremos ver como siguientes fases, a presupuestar aparte.
En todo caso, hasta esta manera de trabajar debe ser flexible, rompe las reglas donde veas que no te encajan, pero teniendo siempre en mente que debemos divertirnos con el trabajo… y ganar dinero al mismo tiempo!
Leave a Comment