En muchos lugares es un pecado de decir que NO a un cliente o un proyecto. Él NO se asocia a negatividad, falta de empatía 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 mí, 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 mí y mi líder de área. Él había leído el documento, no le encontró problemas a excepción de la sección de exclusiones de alcance. Según él, 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 más 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 estás 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 estás hablando de algo específico, en cambio, cuando dices que SI estás hablando de algo general.
Él NO te da opciones, el SI te las quita.
Obvio, en algún momento tendrás que decir que SI a algo, y está bien. A lo que sea que le des el visto bueno va a ser lo más importante y lo que aporte más valor al usuario. Es fácil perder el rumbo cuando estás 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 más tiempo entregar el proyecto.
Siempre va a haber más cosas que construir que tiempo y dinero. Tu deber como profesional es decidir que items de todo ese universo de actividades son los más valiosos, y para eso él 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 más 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 a cabo, 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 más gente esté involucrada es más difícil retornar, aun cuando la actividad sea mala o de poca calidad. Muchos proyectos tienden a volverse zombis por este miedo a decir que NO, la cosa ya está 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 fórmula que te permita saber cuándo te tienes que arrepentir de una decisión, lo importante es que te retractes lo antes posible si te das cuenta de que algo 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
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
