El coste de la falta de pensamiento telepático
Da igual que no creas en la telepatía, puedes ser todo lo escéptico que quieras, tener argumentaciones que rebatan sin lugar a dudas la existencia de la transmisión de contenidos psíquicos entre personas, sin intervención de agentes físicos conocidos.
Eso no es relevante. Lo importante en la gestión de proyectos con cierto tipo de clientes es que, aun no siendo conscientes de la situación, te exigen capacidades altamente adivinatorias.
El escenario es este: un cliente quiere hacer algo, normalmente se trata de una renovación, rediseño o, en definitiva, cambiar algo existente. Sabe que quiere cambiarlo, pero no sabe en qué sentido. Quiere que le propongan ideas, en este punto la comparativa es muy importante. Queremos algo parecido a esto otro, te dicen.
Si bien es cierto que personalmente no creo en la telepatía, soy consciente de que hay gente excepcional que es capaz de hacerse una idea, bastante aproximada, de lo que quiere un cliente, después de una reunión abstracta en la que no se habla más que paja y generalidades.
Lamentablemente no tengo esas capacidades, así que me centro en el sentido común y la lógica: estudio previo del estado actual del proyecto, información comparativa de proyectos similares, posibilidades de implementación así como alternativas, preparación detallada del proyecto y el presupuesto. Una vez hecho esto y superado el corte presupuestario. Llega el momento en que te dicen adelante.
A partir de ahí las tres fases de preparación, desarrollo y ejecución invierten sus roles totalmente, algo así:
- Preparación = ausencia de participación del cliente, no manda información.
- Desarrollo = lo que debía haber sido la preparación.
- Ejecución = comienzo del desarrollo para el cliente.
Un ejemplo claro:
- Cliente inseguro: Hola, quiero rodar El Señor de los Anillos, pero ummm, no tengo muy claro cómo hacerlo.
- Contestación: Vale, no hay problema, contratamos 3000 extras vestidos de orcos, elfos, humanos y ya si eso vemos lo que hacemos.
Evidentemente esto no va así, antes de programar un día de rodaje tan costoso, se ha de preparar minuciosamente toda la jornada, en todos los sentidos, ya que si el día en cuestión algo falla, el coste se dispara automáticamente.
Este ejemplo que es bastante claro para cualquier persona, en otros ámbitos como en el de las aplicaciones web se vuelve algo borroso.
No estoy criticando a los clientes que tienen dudas, las dudas son inherentes a la condición humana, entiendo perfectamente que se cambie de opinión y se decida cambiar el planteamiento en la fase final, seguramente habrán razones para ello. Eso no es criticable, es perfectamente entendible.
Lo que se debe tener en cuenta es que esto tiene un coste. Y ese coste, en el ámbito web, aun siendo extraordinariamente menor que en el rodaje de una superproducción de cine, existe, es real, tangible y no se puede obviar.
Si el cliente no sabe lo que quiere y pretende concentrar las modificaciones del proyecto en la fase de ejecución, tendrá que asumir el coste que acarrea hacerlo. O eso, o encontrar alguien con capacidad telepática.







Euribates
mar 02, 2010 @ 14:19:23
Joder, me has leído el pensamiento.
Ooops!
Juanjo
mar 02, 2010 @ 14:55:41
Preguntar, preguntar, preguntar. Desarrollar iteraciones de trabajo cortas (un par de semanas como mucho), y mostrárselo al cliente. ¿Qué no le gusta? Se cambia, ¿Qué quiere mejorar? Se mejora. ¿Qué falta? Se añade, siempre que su petición no consista en construir un telescopio nuevo en Izaña ni algo descabellado. Y volver a empezar
Es lo que en la ing. del software denominamos, muuy simplificadamente, Metodologías de Desarrollo de Software Ágiles. Teniendo en cuenta que las dudas son inherentes a las personas, intentar que vea con la mayor asiduidad posible cómo evoluciona el producto es una buena estrategia cuando no se tiene claro qué se quiere.
¿El problema? La falta de implicación del cliente (“no tengo tiempo”, “deberías saber hacerlo”) Aquí entra en juego otro superpoder: la persuasión. Se debería intentar convencerles de que la única forma de llegar a buen puerto es colaborando y comunicándose. Si no, jodido lo llevamos. Y qué coño, es su dinero. Después hacemos una cochinada, y se quejan. Y es que los desarrolladores no nos enteramos.
Salu2!
PD: Esta es la bella teoría, la práctica puede ser más o menos diferente a lo que cuento aquí.
PD2: Así como se aplica al desarrollo de software “tradicional”, el desarrollo web debería poder aplicarse el mismo enfoque.