Clientes y Colaboradores

Cómo fracasar en tu proyecto elegantemente, parte 2

Previously…

En el anterior artículo de esta serie vimos cómo Zed Shaw nos propone lo que él llama la hipótesis C2I2, que se resume en este cuadrante:

Establecimos que hay dos tipos de proyectos: Invenciones o Implementaciones. También vimos que nuestros clientes pueden dividirse en Clientes/Patrones/Mandantes (Customer) o Colaboradores.

Consideramos lo ventajoso estar en los cuadrantes Colaborador/Invención o Cliente/Implementación.

Si estamos ante una invención, es decir, un proyecto en que no tenemos muy claro que es lo que se debe implementar, lo mejor es adoptar una metodología exploratoria, como XP, y por supuesto estar acompañados por un mandante de tipo Colaborador.

Por otro lado, si el proyecto es la implementación de algo, que es conocido, seguir un proceso estándar, definido, con etapas claras, que Shaw lo denomina CMM, queriendo indicar que cualquier proceso estructurado tradicional va a funcionar en este caso.

Los otros cuadrantes, son la inmensa mayoría, porque todos fallan en clasificar adecuadamente el proyecto, o tienes un cliente que no tiene claro su rol.

Colaborador a Cliente

Llega el momento en que todos están de acuerdo que están ante una implementación, el problema es que el cliente insiste en convertirse en un colaborador. En ese caso lo necesitas es que guarde silencio y actúe como un cliente. Hay que educar al cliente a asumir su rol. Lo importante es que no debes dejar que un cliente tenga el control del proceso de desarrollo. No se trata de mantenerlos en la oscuridad, de tener un reunión de kickoff y no volver a verlo hasta el momento de entrega. No. Si el cliente quiere reportes de avance frecuentes, entonces se los das. Pero ellos no pueden tener el control del proceso y debes evitar que ellos cambien la dirección del proyecto de forma violenta.

Hay que educar al cliente sobre su rol. Si no es posible, entonces le cobras más caro y contratas a algún niñero o niñera que se encargue de ellos durante el proyecto. Este tipo de “clientes” nunca están satisfechos, y se rehusan a pagar, así que sería bueno obtener un buen adelanto en caso de abordar un proyecto con este tipo de personales.

Cliente a Colaborador

Si estás en un proyecto tipo Invención y tu contraparte se está comportando como un cliente quejumbroso. Lo reconoces porque le muestras un prototipo o un sistema semi funcional y se vuelven locos. “¡¿Así se va a ver?! Es una porquería. ¿Por qué no está listo?”

Hay mucha visión distorsionada sobre el tiempo que toma desarrollar software, y sobre el proceso necesario para construirlo.

Muchas veces es mejor no mostrarles nada. Ayuda si en las reuniones sólo usas papel, lápiz, una pizarra, prototipos en papel, sin computadores, por ningún motivo. Sobretodo debes dejar en claro que nada de lo que están viendo es como lucirá el producto final. Debe quedarle claros que estamos ante una invención, y por lo tanto, necesitamos explorar para entender bien que es lo que queremos construir, y de ese modo reducir el riesgo.

Además debes evitar preguntarle lo mismo una y otra vez. Toma notas extensas, junta esas notas, categorízalas, tradúcela en requisitos que debe cumplir el sistema, y crea planes. Sólo pregunta para clarificar. Un Cliente en una Invención{on es alguien que odia que le pregunten lo mismo una y otra vez. Te hace ver como incompetente y lo frustra.

La combinación Cliente+Invención es el tipo de proyecto más difícil. Si logras manejarlo bien, es reconfortante, un logro profesional importante. Pero si puedes, trata de saltarte ese tipo de proyecto.

Lo ideal, si quieres vivir tranquilo y ganar dinero desarrollando proyectos de software, busca esos que están en el cuadrante Cliente+Implementación.

Sobre los procesos de desarrollo adecuado

Acá me voy a alejar de Shaw.

En su ensayo él propone usar XP, Scrum o CMM. Si estás en el cuadrante Invención+Colaborador, el recomienda XP, si estás en Cliente+Implementación usar un proceso tipo CMM. En eso no disiento, me parece que es una buena aproximación.

Pero Shaw admite que es muy difícil encontrar estos proyecto y el usa Scrum casi siempre. Y hubo un tiempo en que pude haber estado de acuerdo con él, pero hoy en día mi recomendación es usar Kanban. Para explicar por qué, necesitamos varios artículos más, así que si les interesa que hablemos de procesos de desarrollo de software, denle like a este artículo o pongan sus comentarios acá abajo.