Una de las principales frustraciones que he tenido trabajando en una startup sin ser programador es no poder involucrarme en el producto y crear nuevos features con facilidad. Me tomó solo 4 años entender que una de las bases para hacer un gran producto es comenzar por decir NO
Hace poco un gran amigo y excelente programador me mostró los libros que ha leído en el año, me puse a hojear uno y encontré un párrafo que me hizo entender al equipo de desarrollo de Platzi de un solo golpe.
37Signals. (2006). Getting Real
“Cada vez que dices sí a un feature, estás adoptando un hijo. Tienes que llevar a ese bebé a través de una cadena de eventos (diseño, implementación, pruebas, etc.) Y una vez que el feature está afuera, estás atado a él. Solo intenta quitarle a tus clientes un feature que ya está lanzado y mira qué tan molestos se ponen”
Para entender mejor esta situación hay que tomar en cuenta que el software no se construye de forma monolítica y estática, el código requiere mantenimiento, observación, monitoreo y cuidados. En palabras de Freddy Vega:
“Hacer software no es como construir un edificio, el software es como plantar un jardín”
Para que un nuevo feature sea implementado tiene que probar ser digno de ese jardín. Si es importante llegará el punto en que será imposible ignorarlo, ya sea por que existe mucha presión por parte del equipo o por parte de los usuarios.
Ahora te estarás imaginando a un equipo de desarrollo diciendo “muy interesante, voy a anotarlo en mi máquina de escribir invisible” a todo y haciendo nada durante el día, pero la verdad es que siempre hay cosas que hacer. Siempre. Y estas tareas están definidas por un RoadMap.
Un RoadMap es una guía de objetivos en los que se busca alcanzar hitos en distintos plazos de tiempo Por ejemplo:
A largo plazo: Necesitamos comenzar pruebas de migración para que a finales del Q2 del siguiente año movamos nuestra base de datos a otro servicio que satisfaga nuestras necesidades actuales y futuras. (Guiño, guiño)
Esta metodología permite la colaboración con otros equipos y crea un ambiente ideal para medir el impacto de los avances. Recuerda, lo que no se mide no crece.
¿Esto quiere decir que no debo molestar al equipo de ingeniería o rendirme con mi idea? La respuesta, para variar, es NO.
Dentro de una empresa debe existir un ambiente de seguridad para que cualquiera pueda proponer ideas, puede ser dentro de un canal dedicado en Slack, en una junta o mientras almuerzas con tu compañero de trabajo. Si tu idea tiene los fundamentos suficientes, el apoyo indicado y perseverancia será imposible de ignorar.
Tenemos un canal en Slack donde todos compartimos nuestras ideas y elevamos las sugerencias que nuestros estudiantes nos dejan por diferentes medios. El nombre del canal tiene su toque de historia, se llama #mejorando
Cada semana hacemos una junta con todo el equipo. El Platzi All-Hands. Al final de la reunión abrimos el micrófono a preguntas y sugerencias del equipo.
La Hackatón de Platzi. No existe mejor momento para llevar a cabo cualquier idea loca que tengamos que la hackatón anual de Platzi. ¿Sabías que los features de bookmarks, las reseñas de cursos y el Curso de Marca Personal nacieron en una hackatón?
La conclusión es contraintuitiva, (pero, ¿qué no lo es en una startup?) aprende a decir NO, y nunca te rindas ante un NO.
El libro que inspiró este post se llama Getting Real de 37 Signals, lo puedes descargar gratis aquí.
Decir NO es sano, incluso puedes salvar a tus programadores de mucho estrés, me ha pasado que me exigen tener que poner features aunque diga que NO, por ordenes de arriba.
Y cómo haces para decirle NO al cliente?
Saludos
Hay veces que debes explicarles al cliente que la idea, no es loable como se la imagina, y llevarlo a disuadir para que se convenza que tu propuesta es mejor…
Interesante consejo! Persuadir al cliente (mejor sí es con pruebas válida y/o técnicas). Saludos.
Cuando mi project manager en ese entonces era del tipo que le decía que SI a los cliente sin ver la importancia es cuando, aunque defendiera la postura del porque NO era sano agregar dicha feature, al final terminaba agregándolo. A eso me refería.
Excelente articulo, hablando de llevar las ideas de los usuarios a las reuniones, seria bastante interesante poder ingresar a tu perfil en platzi y ver alguna sección con los cursos o artículos que han sido creados por ti
Para leer entradas al blog específicas de un autor solo debes colocar en la barra de navegación
https://platzi.com/blog/autores/username/En el caso específico de foloarte sería: https://platzi.com/blog/autores/foloarte/
Decir NO es saludable (no sólo aplica para el desarrollo), pero… bajo la premisa de “el cliente siempre tiene la razón” ¿Cómo decir/gestionar un NO, sí es el cliente quien pide?
Saludos.
Se tienen que explicar los motivos del NO del modo más claro y entendible posible. Luego ya depende de cada cliente (y de su importancia para la empresa) si se acepta el NO o no te toca más remedio que hacer lo que te pide.
Por experiencia hay de todo, normalmente si los motivos son de peso y están bien explicados terminan aceptando el NO. Otras veces puedes encontrar una alternativa que no es la preferida de ambos, pero es lo suficientemente satisfactoria para las dos partes.
Una forma muy sana es negociando con el cliente. No hace mucho contaba en un blogpost sobre una de las formas hacerlo: Aprende a cómo ganar una negociación sin discutir
Creo que la base para decir !NO" es poder “SI” pero de forma diferente, el problema no es decir !NO¡, el problema es que ese !NO¡ sea “VISEADO” sin observar las demás posibilidades. Tenemos que decir !NO¡ dándole a una posibilidad un !SI¡ para lograr lo deseado.
Una de las características del buen liderazgo es el servir a los demás, entre ellas el saber decir no en los momentos y a las actividades adecuadas. Pero también al decir “no”, uno debe ser capaz de ofrecer alternativas.