¿Cómo proporcionar una mejor respuesta técnica sin parecer desafiante?

No comience con un "No". Esa es la decisión que debe tomar el PM y, si parece que la está tomando, como ha visto, es bastante simple hacer arreglos para que se le indique que siga las instrucciones. Lo que desea es que el PM decida "No" después de escuchar su aporte técnico.

Con eso en mente, debe desarrollar algunas peculiaridades conversacionales que no digan "no", sino que lleven al PM a comprender todos los problemas antes de decidir sí o no. En este caso, no hay nada de malo con "pero" (que lleva un no implícito) si tienes ganas de usarlo.

¿Pero no es eso sin soporte?

¿Pero eso no fallará para los usuarios en [caso extremo]?

Puedo hacer eso, pero sería mucho menos trabajo si esperáramos hasta que se publique el nuevo marco.

Me preocupa hacer eso con nuestra tecnología actual. No estoy seguro de que funcione para todos nuestros usuarios.

No estoy sugiriendo que seas engañoso y manipulador, diciendo que sí cuando quieres decir que no, o incluso fingiendo que piensas que es genial, pero solo hay un pequeño detalle... Adelante, di que tienes problemas con la idea, pero no lo hagas . No seas tú quien tome la decisión, incluso si es solo un accidente de redacción lo que te hace parecer que lo haces. Deja la decisión al decisor. Como has visto, cuando lideras con la decisión, a veces nunca llegas a decir las razones.

Cuando empiezas con las razones, puedes obtener respuestas como

eso está en mi cabeza, solo implementa lo que he pedido y me preocuparé por los usuarios [del caso extremo].

para cuando haya terminado, la infraestructura se actualizará y no habrá ningún problema.

Estas personas saben que es un programa de adopción temprana y si no funciona para ellos, siempre pueden usar las cosas antiguas.

O podrías obtener

Vaya. No pensé en eso. Gracias. ¿Tienes 30 minutos para analizar algunas alternativas que todavía nos pueden dar lo que necesitamos?

Cualquiera de esos es mucho mejor que un vicepresidente que lo llama insubordinado y le dice que "haga lo que le dicen" como un niño. ¿Derecha?

1. Sepa lo que está haciendo. Se toma más en serio a las personas cuando tienen conocimientos y tienen reputación de hacer las cosas.

2. Hacer preguntas. Si realmente no entiende por qué se le pide algo, dígalo. Los buenos gerentes entienden que obtienen un mejor trabajo de su gente cuando saben por qué lo están haciendo y valoran la retroalimentación de sus subordinados cuando es relevante para el problema en cuestión.

3. Escuchar. Asegúrese de entender lo que se le pide y cuáles son las consideraciones.

4. Ofrezca respeto. Él es el gerente, por lo que, en última instancia, lo que dice vale, pero si su relación con él es respetuosa, su opinión tendrá más peso.

5. Tenga en cuenta el hecho de que todo el mundo tiene días malos.

Empezar como un equipo

En primer lugar, asuma que todos tienen el mismo objetivo final: haga un gran producto que satisfaga las necesidades de los usuarios/clientes y hágalo de la manera más eficiente posible. El desafío es que diferentes puntos de vista interpretarán el estado actual y los próximos pasos hacia ese objetivo de manera diferente. El "debe tener" de una persona puede ser el "imposible" de otra persona cuando el conocimiento de cada uno es muy diferente. Un buen equipo reunirá diferentes puntos de vista y experiencia en diferentes temas, el desafío será alinear los puntos de vista hasta el punto en que se puedan tomar buenas decisiones.

No des una negación general en el dominio del otro tipo

Él está diciendo "necesitamos esto". Como PM, ese es su trabajo: saber qué puede necesitar el cliente. Decir "no, no necesitamos esto" sin básicamente hacer MÁS investigación de la que ha hecho será una batalla perdida. Y si (como ingeniero) ha investigado más que él, entonces probablemente haya asignado mal su propio tiempo.

Argumente desde su dominio

La zona segura para la ingeniería suele ser "la solución que propone es inaceptablemente difícil" y "las acciones que propone no producirán los resultados que desea". El PM posee el dominio del problema (¿cuál es el problema que resuelve su producto?), la ingeniería posee el dominio de la solución (¿cómo lo estamos resolviendo?). Debido a que usted posee el dominio de la solución, es más fácil argumentar desde el punto de vista de: - el tiempo requerido para hacer que la solución se describa - la reacción de los posibles cambios a la solución en todo el sistema

El truco es que no puedes decir "no vale la pena resolver este problema". La forma más segura es "este problema tardará un tiempo inaceptablemente largo en resolverse, es decir, X años". Sin embargo, con eso sobre la mesa, si dice "15 años-hombre" y el primer ministro acude al vicepresidente, el vicepresidente está dentro de su autoridad para decir "sí, haré la inversión; por favor, gaste 15 años-hombre de mi dinero haciendo esta solución tan rápido como puedas..."

La estrategia aún mejor es tener un plan en mente que logre la meta pero de una manera más eficiente. Por ejemplo, si le preocupa un caso extremo, ¿qué sucede si bloquea la GUI para que no permita el caso? ¿O proporcionas una ruta alternativa? A menudo, he podido obtener una solución del 90 % que era aceptable y notablemente más económica que la propuesta original.

Conozca a su oyente

Cada persona es diferente: diferentes personas se enfrentarán a una negación rotunda de manera diferente. Diferentes personas requerirán diferentes niveles de prueba o detalle antes de estar de acuerdo. Algunas personas necesitan escuchar la idea, pensar un poco y responderle más tarde. Algunas personas prefieren tener una imagen o escuchar una idea difícil por escrito, en lugar de tratar de captarla mientras el orador está hablando.

Sepa con quién está hablando y construya un modelo de cómo responden típicamente en estas situaciones. Estructura la comunicación para que estén en el mejor estado posible de aceptación, particularmente cuando tienes una idea realmente difícil de vender. Este es en parte el trabajo activo de generar confianza y en parte el trabajo de prueba y error.

Conoce a toda la audiencia

Sea consciente de las dinámicas de poder. No estar de acuerdo en una reunión con una parte interesada clave que supera al PM no es un buen lugar para discutir un problema. Preferiblemente la audiencia más pequeña de individuos afectados. Aunque con un caso particularmente difícil, es posible que desee hacer un seguimiento de su nuevo acuerdo encontrado con un correo electrónico a una audiencia más amplia que diga "Estoy muy contento de que estemos de acuerdo con X, ¡solo quería enviar un correo para que todos lo supieran! Gracias por ayudar ¡con este!"

De esa manera es agradable, claro y documentado. :)

Fondo

Mi pregunta general es: ¿cómo puedo proporcionar reservas técnicas sin antagonizar a las personas o parecer demasiado hostil?

El primer paso es reconocer que las personas tienen diferentes percepciones de ti que tú . Esto es fundamental, ya que responder "¿tiene esto sentido?" es una pregunta trivial y vale la pena una respuesta trivial. Pero las percepciones de las personas sobre todo pueden ser dramáticamente diferentes

En segundo lugar, para la persona que hace la pregunta, no tiene ni cerca de los antecedentes que usted tiene ni la comprensión técnica y, en muchos casos, puede carecer de la experiencia técnica incluso para relacionarse.

Lo que debe hacer es lo siguiente en el futuro:

• Suponga que la persona que está "rechazando" no tiene idea de por qué está rechazando algo o rechazando algo. Siempre proporcione algún "pedir aclaración" cuando niegue cosas y siempre proporcione como mínimo alguna razón.
• Para solicitudes más complicadas, si tiene que decir "no", incluya algo como "avíseme si desea discutir esto con más detalle, la explicación es relativamente complicada".

A la gente no le gustan nada las respuestas "no" cuando vienen de una caja negra . Estos serán mal vistos en general y en el lugar de trabajo.

Una opción sería evitar decir "No" por completo, incluso si está diciendo "No, porque..."

En su lugar, diga "Sí, pero..."

Independientemente de lo que pida su gerente, diga " Sí, esto se puede hacer, definitivamente puedo hacerlo... PERO requerirá [más tiempo, más recursos, etc.] y tendrá las siguientes consecuencias: [con lista]". El beneficio de este método es que deja la decisión de hacer o no hacer a su gerente, quien puede mantener el control.

Una posible ventaja es que puede comenzar diciendo "Sí, puedo hacer esto, pero primero tendré que investigar un poco" , y luego puede volver más tarde con una explicación más detallada de las consecuencias.

Me sorprende que casi todas las otras respuestas, aunque en general brindan buenos consejos sobre "cómo decir que no", parecen ignorar el panorama general de "¿cuál es el problema?".

Su PM tiene un problema que resolver. Alguien, tal vez su gerente, u otro equipo, o un cliente o grupo de clientes, confía en él para encontrar una solución y él, a su vez, confía en usted para encontrar una solución. Por supuesto, una respuesta "no" lo pondrá a la defensiva, porque en lugar de resolver su problema, simplemente está creando un problema adicional (cómo explicar esto al jefe/cliente/etc. sin que le griten, perdiendo su trabajo). , o simplemente parecer un idiota).

Tal vez ya haya hecho algún tipo de compromiso en torno a esto, lo cual, sí, es una mala decisión para un gerente sin preguntar primero a las personas que saben, pero sucede, a veces sin querer.

No importa cómo disfrazes el "no". No importa si lo expresas en forma de pregunta, y no importa cuán tranquilo y diplomático seas al respecto. ¡Esas cosas ayudan a engrasar las ruedas de su relación en curso, pero no ayudan a resolver su problema!

Como "fabricante", es su trabajo, si tiene que oponerse, sugerir alternativas . Encuentre una manera de resolver el problema , incluso si no es de la manera que esperaba originalmente. En mi experiencia, solo los gerentes más obstinados e incompetentes insistirán en una solución específica sin justificación, incluso cuando se les hayan presentado alternativas razonables.

Con mucho, el ejemplo más común de esto que probablemente todos experimentamos casi todos los días es la gestión del tiempo. Se nos dice que tenemos X días para hacer Y. Invariablemente, no le llevará a ninguna parte simplemente decir " Lo siento, pero no puedo hacer Y en X días, no es suficiente tiempo ". Es probable que le digan que "haga suceda" o "encuentra una manera de hacerlo".

Así que no dices eso. Tu dices:

No estoy seguro de si podemos hacer todo Y en X días, pero tengo una sugerencia: si asumimos A, B y C, entonces podríamos tomar algunos atajos en Q y diferir la parte Z hasta un poco más tarde, y creo que podríamos lograrlo en X días. Funcionaría eso?

Si su problema no se basa en el tiempo, sino en algunas restricciones técnicas, solo necesita cambiar algunas palabras. Por ejemplo, en su caso, parece haber una dependencia de que se complete algún otro trabajo o componente, así que cambie "en X días" a "sin que el componente/función X se complete primero", y en lugar de expresarlo como una incapacidad, expresarlo como un riesgo.

Si acaba de surgir esto y no ha tenido tiempo de pensar en ninguna alternativa, simplemente dígalo:

Me gustaría tener un poco de tiempo para investigar esta solicitud/requisito. Creo que podría haber algunas complicaciones, pero si me puede explicar un poco por qué necesita esto en este momento, estoy seguro de que puedo tener una solución planeada para usted al final del día.

Todavía es posible que no se salga con la suya y se vea "obligado" a seguir adelante a pesar de sus objeciones, pero si ha discutido alternativas, presumiblemente él ya le ha explicado por qué no funcionarán, lo que significa que en realidad está correcto, o al menos que su razonamiento es tan válido como el tuyo. Además, es importante fijar el tiempo de esta investigación y realmente comprometerse a volver con él, de lo contrario, parecerá (y con razón) que está obstruyendo.

Por cierto, esto funciona en casi cualquier negociación, y debería considerar esto como una especie de negociación. Es mucho más difícil negociar si solo está dispuesto a poner un tema sobre la mesa (como, por ejemplo, una cantidad de dinero); eso hace que la negociación sea antagónica en lugar de constructiva, dos personas peleándose por quién se lleva una parte más grande del pastel.

Quiere hacer el pastel más grande, ofreciendo otras opciones o concesiones que sean preferiblemente baratas para usted pero valiosas para ellos. En una negociación financiera pueden ser planes de pago, tasas de interés, obsequios, testimonios, ese tipo de cosas. En el lugar de trabajo, la moneda principal suele ser el esfuerzo, pero también puede negociar el alcance, el tiempo, la calidad y un puñado de otros modificadores específicos del dominio (por ejemplo, el rendimiento y la disponibilidad en el trabajo de TI).

Tal vez haya algo realmente simple que pueda hacer en un corto período de tiempo que producirá casi el mismo resultado o al menos eliminará la mayoría de los riesgos que le preocupan. Tal vez no, pero al menos date la oportunidad de pensarlo antes de simplemente decir "no" (en cualquier forma).

Si te inclinas a decir "no", debes tener buenas razones. Presente esas razones (precio, riesgo, tiempo, etc.) de tal manera que cualquier persona razonable llegue a la misma conclusión que usted.

Eres el experto técnico; si la solución propuesta parece buena para el PM pero mala para usted, debe poder articular los puntos relevantes que el PM puede no conocer.

Presente su protesta de la manera más cortés posible... luego haga lo que le diga su gerente, sin importar el resultado.

Me hago eco del sentimiento de que siempre debe comenzar con la explicación, en lugar de una negativa, ya que escuchar un "no" puede cambiar inmediatamente su tono. Pero si ya ha explicado por qué la idea es mala y su jefe todavía insiste en que se lleve a cabo... entonces ha hecho todo lo posible.

A veces, el impulso no proviene de su jefe, sino de un superior o de una fuente externa; ya he tratado esto antes. Los usuarios a veces pueden hacer demandas irrazonables de las que no se les puede convencer y, lamentablemente, depende de su jefe hacer que suceda y, por lo tanto, depende de usted ayudarlo a hacerlo realidad.

Sin embargo...

Ahora, si realmente ES imposible, entonces realmente estás en una situación difícil y es posible que debas sentarte con tu jefe y su jefe para explicarles que literalmente no puedes hacer lo que te piden . Y deberá dejar en claro que es imposible, porque pueden tener la impresión de que solo lo dice para salir del trabajo. Escribe tu razonamiento, déjalo lo más claro posible sin tomar un tono de confrontación, y sobre todo lamenta que no se pueda hacer, porque ojalá estarías dispuesto a hacerlo si fuera posible.

Usted pregunta, "¿cómo puedo proporcionar reservas técnicas sin antagonizar a las personas o parecer demasiado hostil?". Hay dos partes en esto:

1. Asumiendo que no está antagonizando ni siendo hostil, ¿cómo se asegura de reflejar esto en su enfoque y en cómo expresa las cosas? Creo que has obtenido excelentes respuestas desde este ángulo.

2. ¿Hay alguna base en su actitud, en su enfoque de su trabajo y sus interacciones laborales, que pueda parecer antagónico u hostil, independientemente de cómo exprese las cosas?

(Obviamente, es mejor en cualquier caso expresar las cosas bien que mal. Pero si hay algo en el n.° 2, simplemente formular las cosas bien no es la solución a largo plazo).

He escrito y reescrito esta respuesta y es realmente difícil comunicarla bien. Estoy pensando principalmente en mí mismo al principio de mi carrera y en algunos de los problemas que tuve, algunos de los cuales percibí vagamente en ese momento pero que ahora puedo ver más claramente en retrospectiva.

Por ejemplo, tenía (y todavía tengo en gran medida) una visión bastante científica de cómo se llega a la mejor implementación: el vigoroso choque de varias propuestas y la mejor idea gana. Por sincera que fuera mi creencia, y por muy dispuesto que estuviera a admitir que la idea de otra persona era la mejor idea, no es así como le parece a la mayoría de la gente. Y puedo ver ahora que este enfoque es estrecho y no mira el panorama general de un equipo, un proyecto y lo que es el éxito.

Así que mi pregunta para ti es: ¿cuál fue tu actitud? ¿Veía al PM como un poco fuera de contacto con los aspectos técnicos y, por lo tanto, como una voz menos válida en la implementación? ¿Estabas explorando las opciones o querías persuadir al PM de que su idea era una mala idea? ¿Sigue siendo consciente de que el PM tiene que lidiar con una variedad de preguntas y presiones que usted no tiene y, en última instancia, el éxito y la utilidad de un proyecto no se miden únicamente por sus méritos técnicos o poder? ¿Estabas viendo esto, casi inconscientemente, como un momento rápido de "pelea" en el que reúnes tu argumento, reúne la suya y la mejor idea gana? ¿Estaba viendo inconscientemente al PM como técnicamente inferior y, por lo tanto, como el que tiene que acudir a usted (el técnicamente superior) para la aprobación o validación de sus sugerencias de características ?

Puedo ver todos estos problemas en mi carrera. Nada cínico: fui sincero y sentí que estaba contribuyendo lo mejor que podía como miembro del equipo. La conclusión es que la actitud conduce al enfoque, que conduce a la redacción, e incluso entonces la actitud se filtra en la emoción y el lenguaje corporal.

Tal vez esa parte solo se pueda aprender "de la manera difícil" a través de la experiencia. Aunque algunas personas parecen haberlo aprendido a una edad mucho más joven que yo.

En estas situaciones, encuentro que ser realmente concreto sobre los resultados ayuda. Si está especulando que sucederán cosas malas, entonces su especulación (que ganarán más dinero) ganará.

Por cierto, también funciona al revés, cuando ves una oportunidad pero todo lo que ven es el riesgo.

Sacarlo del ámbito especulativo y llevarlo a lo concreto realmente fundamenta la conversación. Si puede decir: "El 20 % de nuestros clientes activos no podrán iniciar sesión en el producto", entonces, de repente, depende de ellos resolver esa realidad, y muchas veces la realidad es demasiado desalentadora. .

Pero hay que estar preparado para la posibilidad de que tengan razón. A veces, la diferencia se reduce al optimismo frente al pesimismo, y en ese caso la flexibilidad es importante.