#Agile La importancia de decir NO en los proyectos.

En muchos lugares es un pecado de decir que NO a un cliente o un proyecto. El NO se asocia a negatividad, falta de empatia o malas actitudes. Es importante que empieces rechazando algo antes que decir que aceptarlo, aunque los demás no estén de acuerdo. Hace unos años tuve que redactar un requerimiento sobre una mejora vaga que quería un cliente, ya no recuerdo de que iba tal cambio. Recibí un correo electrónico con un párrafo que decía lo que el cliente quería, por todos lados se veía que ese cambio iba a convertirse en un dolor de cabeza para todo mundo, tanto para mi, como para el cliente y la empresa. Así que decidí redactar todas las exclusiones de alcance que pude para dejar claro que NO iba a ser ese pequeño proyecto, termine el documento y lo envié. Unos días después el gerente de piso nos llamo a mi y mi líder de área. El había leído el documento, no le encontró problemas a excepción de la sección de exclusiones de alcance. Según el, desprendíamos mucha negatividad al decirle al cliente lo que no se iba a hacer. No recorte funcionalidades, ni escondí complejidad, simplemente dije: todo esto no se va a construir. Esto no fue un regaño ni una llamada de atención ya que técnicamente no había nada malo en el documento mas que la sensación del “que dirán” que tuvo mi gerente sobre el alcance. Me sentí orgulloso de ese documento. Gracias a esa reunión mi sentir a cerca de la importancia de decir que NO se reforzó. A veces da miedo dar negativas a los clientes aunque es lo que ellos necesitan.

Decir NO es fácil, mantener un SI es difícil.

Cuando dices que si a algún cambio o característica, la mayoría de las veces no sabes las implicaciones de costes y tiempo que tiene una actividad. Por lo tanto,  si decides dar visto bueno a todo lo que te llega estas hipotecando tu tiempo y el de tu equipo. Cada cosa a la que le das el SI es general. Basta con que en alguna reunión sobre la factibilidad de algún proyecto digas que si es posible hacer algo para que alguno de los asistentes de por hecho que entonces tal o cual proyecto se hará. El SI es general y fácil de pronunciar, el problema son las puertas de actividades que abren y luego no se pueden cerrar. Cuando dices que NO estas hablando de algo especifico, en cambio, cuando dices que SI estas hablando de algo general.

El NO te da opciones, el SI te las quita.

Obvio, en algún momento tendrás que decir que SI a algo, y esta bien. A lo que sea que le des el visto bueno va a ser lo mas importante y lo que aporte mas valor al usuario. Es fácil perder el rumbo cuando estas en medio de un proyecto, llegan muchas ideas y opiniones que pueden hacer perder el rumbo al equipo. Siempre hay un “y si agregamos esto…”, “esta característica no requerida por nadie definitivamente va a solucionar la vida de nuestros usuarios”, etc.. que tendrás que filtrar si quieres salir con un producto de calidad. La mayoría de las cosas que te piden en realidad no se quieren o necesitan, estas tienen un coste que no todos están dispuestos a pagar cuando tome mas tiempo entregar el proyecto.

Siempre va a haber mas cosas que construir que tiempo y dinero. Tu deber como profesional es decidir que items de todo ese universo de actividades son los mas valiosos, y para eso el NO es tu herramienta de confianza.

Cuando dices que NO un mundo de posibilidades se abre ante tus ojos, en cambio cuando dices que SI las posibilidades de lo que podría o puede ser se cierran. Y recuerda, cuando dices que NO siempre puedes volver a decir que SI mas adelante.

Es complicado retractarse del SI.

En el momento que le comunicas a tu equipo, a los stakeholders, a los clientes o a los usuarios que alguna tarea se llevara acabo, en ese momento empiezan a crearse expectativas y se piensan en resultados. Todo esto genera tracción en la empresa que con los días vuelve muy complicado echar a atrás una decisión. Entre mas gente este involucrada es mas difícil retornar,  aun cuando la actividad sea mala o de poca calidad. Muchos proyectos tienden a volverse zombies por este miedo a decir que NO, la cosa ya esta construida o en proceso de construcción, si se da marcha atrás los jefes se enojaran, el cliente se enojara, es mejor que se diga que el proyecto sigue en marcha aun cuando nadie hace uso del producto, no es rentable o mantenible. Las personas prefieren mantenerse en el SI cuando los hechos dicen que ese proyecto debió ser un NO.

No hay una formula que te permita saber cuando te tienes que arrepentir de una decisión, lo importante es que te retractes lo antes posible si te das cuenta que algo no no debió haber sido hecho en un inicio.

Conclusiones.

No eres un vendedor, eres un desarrollador o desarrolladora de software. Tu trabajo es tener una visión fría y calculadora para que construyas cosas con efectividad. Tu trabajo no es quedar bien con las personas o negociar  con el cliente, eso, en teoría lo debería de hacer un vendedor. Aun con un rol apegado al usuario como un product owner, debes de siempre buscar lo mejor para tus usuarios. Lo que los usuarios quieren, puede no ser lo que los usuarios necesitan, tenlo en cuenta.

Autor imagen: Jon Tyson