Programadores, deberían decir no más a menudo

Todos hemos escuchado esas historias de terror: un gerente de producto que le envió un mensaje de Slack tarde un viernes, diciendo que necesita desesperadamente agregar un nuevo menú desplegable a la aplicación para una presentación del cliente.

O tal vez su CEO tiene una idea brillante. Que todo necesita "utilizar blockchain", pero no puedo explicar por qué. Tal vez el desarrollador junior más nuevo no entiende que necesita leer la documentación cuidadosamente y que no puede simplemente sumergirse y comenzar a codificar sin ella.

En un entorno profesional, decir que no puede ser incómodo y puede tener consecuencias si se hace mal, tienes jefes a los que apaciguar y eso puede hacerte sentir que puedes perder tu trabajo por rechazar una tarea, o tal vez subconscientemente buscas aprobación en tu trabajo Tal vez solo quieras probarte algo a ti mismo.

A veces, simplemente está demasiado ocupado para pensar y tener discusiones difíciles. Es posible que tenga demasiados tickets de Jira en su cartera de pedidos y sienta que simplemente no hay tiempo para discutir nada más. Entonces, de manera contraria a la intuición, dice que sí a algo sin analizar completamente las consecuencias.

Y, sin embargo, a veces, decir que no es bueno tanto para usted como para su organización.

Al informar y educar a sus partes interesadas, con el tiempo pueden aprender más sobre lo que es posible y lo que se considera la mejor práctica. Además, practicar decir no podría mejorar su salud mental y, a su vez, ser más feliz lo hará aún más productivo.

Un proceso codificado para decir no

Aunque, por supuesto, también debe tener en cuenta las circunstancias de su propio flujo de trabajo, el proceso a continuación lo ayudará a comenzar.

Si no está acostumbrado a establecer límites, entonces esto puede ser un poco incómodo. Incluso si realiza mal los primeros empujones, aprenderá cómo hacerlo mejor en el futuro. En poco tiempo, su confianza aumentará, y comenzarás a hacer esto inconscientemente.

Comprenda su entorno para obtener la ventaja

Nosotros, los programadores, tenemos la tendencia a estar hiper-enfocados en el código fuente. Esto a veces puede cegarnos ante el panorama general de lo que sucede a nuestro alrededor. A veces, es fácil pensar que la gerencia es idiota.

Aquí hay un ejemplo: uno de los equipos de marketing de nuestros clientes se acercó a nosotros para pedirnos listas de contactos. La solicitud no era razonable porque nuestro trabajo era crear aplicaciones que interactuaran con su base de datos, no manejar consultas SQL. ¿Por qué no pudieron obtenerlas ellos mismos? Después de algunas investigaciones, resulta que otro proveedor había fallado por completo en la migración de una plataforma de misión crítica para ellos. Esto había dejado a la empresa sin poder llegar a sus clientes. ¡D'oh!

El desafío aquí es que decir sí significa que ha creado un camino insostenible de menor resistencia. El cliente nos habría molestado sin cesar para obtener datos, lo cual está fuera de nuestro alcance. Pero, por otro lado, decir no podría haber perjudicado a nuestro cliente. Descubrir los detalles de cómo ese proveedor dejó caer la pelota fue nuestra clave para decir que no. La forma en que dijimos que no fue consultar adecuadamente con ellos sobre un curso de acción más correcto mientras ayudamos a corto plazo.

Sea asertivo, fáctico y respetuoso

No es necesario que te disculpes por decir que no. Tienes razones legítimas para hacerlo y probablemente tengas años de experiencia en desarrollo a los que recurrir. Al decir que no, es importante ser asertivo y explicar respetuosamente por qué la solicitud no es válida. trate de explicar esto de la manera menos técnica posible.

Buen ejemplo: "No podré completar la implementación de esta característica en ese período de tiempo. Necesito hacer algunas preguntas adicionales sobre la especificación. También habrá algunos pasos adicionales que tomar en ese tiempo. ¿Podemos tener más tiempo para ¿hacer esto? "

Esté preparado para la próxima pregunta inmediata que probablemente escuchará en este punto. Probablemente se le preguntará cuál considera que es un framework de tiempo razonable. Es cierto que es realmente difícil estimar cuánto tiempo tomará algo hasta que esté a mitad de camino. Por lo tanto, tenga esto en cuenta y no tenga miedo de dar una estimación del rango, tal vez el mejor y el peor de los casos.

Mal ejemplo: “Déjame explicarlo de una manera que incluso tú puede entender... "Tenga cuidado de cómo sus percepciones de los demás pueden afectar su lenguaje y cómo habla con ellos. Sí, he escuchado a alguien decirle esto a un gerente de producto antes.

Este desarrollador se había quejado públicamente en el pasado de que pensaba que el PM era "un imbécil". Así que finalmente se escapó y definitivamente perjudicó la relación, y el programador de software no tuvo ninguna posibilidad de decir que no con éxito.

Es mejor simplemente no pensar mal de las personas en absoluto. ¿Recuerdas lo que dijimos sobre las personas que tienen diferentes fortalezas?

Alternativas de oferta

A veces, la solicitud no es razonable debido a limitaciones de tiempo. Pregunte, ¿es necesario que esto suceda en este instante? ¿Puede quitarle prioridad a otra cosa? Esto ayuda a garantizar que las personas que lo rodean comprendan las consecuencias de ser trasladado y puede ayudar a evitar que esto suceda en el futuro. ..

También puede haber ocasiones en las que la solicitud simplemente no sea técnicamente factible. Si no está de acuerdo con un cambio, o si esta solicitud de función es imposible, ¿puede ofrecer algo que sea técnicamente más factible o mejor pensado?

Practica regularmente

Práctica no decir que si siempre gane tiempo para obtener más información sobre la solicitud. En su lugar, simplemente acepte evaluar evaluar Hacer esto debería ganarte el respeto de tus colegas, además de que serás visto como más consultivo.

Después de todo, ¿quién no quiere ser el oráculo de su organización, consultado sobre todos los asuntos que le conciernen?Tal vez eso no le importe, ¡pero eso suena mucho mejor que recibir órdenes interminables!

No se trata de ganar

En última instancia, aprender a decir no es enseñar a los demás a tratarte con el respeto que mereces como parte integral de la organización en lugar de alguien a quien siempre se puede intimidar para que acepte tareas imposibles.

Aprender a decir no es un cambio de mentalidad

En pocas palabras, se trata de un cambio de mentalidad y de proceso. Lo animo a que piense en un nivel más alto acerca de dónde se originan estos problemas en su organización. Practicar un proceso de nunca ponerse de acuerdo de inmediato, sino aceptar evaluar la solicitud, puede hacer que la experiencia sea más consultiva. Te comprará el respeto que mereces en el lugar de trabajo o de tus clientes.

Con suerte, como efecto secundario, ya no sentirá que está perdiendo el control en el trabajo y, con suficiente práctica para establecer límites para su tiempo y energía, se volverá más feliz y productivo en su carrera.

Aprende más de programación:

Si quieres conocer otros artículos parecidos a Programadores, deberían decir no más a menudo puedes visitar la categoría Consejos.