Qué tan efectivamente "vender" un buen diseño en grandes reuniones

Muchas veces he sido testigo de una triste tragedia. Esto es lo que pasa:

1. Una revisión del diseño del equipo para un nuevo proyecto.
2. Veo un diseño simple que tiene bastantes agujeros.
3. Menciono casualmente los agujeros y las formas de evitarlos.
4. Las advertencias se ignoran con comentarios como "que 'nunca' suceda en la vida real"
5. Finalmente, suceden las cosas que "nunca" sucederán
6. Una revisión del diseño del equipo de emergencia para un proyecto roto.

¿Entonces qué hago? Hacer frente a la actitud de "Te lo dije" no va a ganar amigos e influir en las personas. A veces pasan los años y los comentarios del paso 3 se olvidan de todos modos. Definitivamente no quiero ser la plaga molesta que le recuerda al mundo las trampas. A menudo me siento y veo el Titanic navegar hacia Europa.

Es frustrante ver que los malos diseños avanzan. También es frustrante que parezca que no puedo convencer a otros del peligro pendiente del camino actual. Me va peor en las reuniones de equipo donde todos tienen diferentes formas de entender diferentes términos. Además, los egos tienden a ganar razón y pensamiento. Estoy buscando buenas tácticas para convencer a los grupos de personas de que usen algunas ideas nuevas y complicadas.

Si es posible, sugiera modificaciones que no agreguen un tiempo significativo a un proyecto. Intente y haga hincapié en que si no se hace ahora, volver a trabajar más tarde será mucho más doloroso. Será más difícil si está tratando de convencer a su equipo de que una nueva dirección completa es mejor, porque eso probablemente retrasará el proyecto, etc.

No ponga a las personas en modo de defensa en una reunión, solo lucharán contra usted para ser el ganador. No lograrás que acepten que la tierra es redonda. Esta es una política normal (por ejemplo, cualquiera en FoxNews)

Realmente ayuda tener el respeto de otros desarrolladores. Si eres el chico nuevo en el equipo, creo que eres SOL. Así que solo construye un representante de equipo y realmente trata de llegar a un nivel en el que no te despidan de inmediato. Por supuesto, si siempre eres una persona pesimista, entonces solo serás etiquetado como el tipo "negativo".

Para cosas simples (es decir, no afecta los horarios), asegúrese de hacer su trabajo de la mejor manera. Si pone el esfuerzo en su salida inmediata (por ejemplo, creando casos de prueba u obteniendo algunas características simples (pero interesantes)) eventualmente otras personas notarán que su código funciona de manera confiable y resiste la prueba del tiempo. Cuando comienzas a mostrarles algunos trucos geniales con el código, pensarán dos veces derribarte frente a todos.

Finalmente, estoy de acuerdo en que no quieres hacer la rutina "Te lo dije", pero asegúrate de intentar darle pistas a tu jefe / líder tecnológico cuando parezca que realmente tenías razón. Tal vez reenvíe un correo electrónico antiguo con sus comentarios anteriores. Pregúnteles si esto ayudaría a resolver el "nuevo" problema. Si no haces esto, ni siquiera recordarán que fuiste tú quien lo mencionó la primera vez. Eventualmente recibirán la pista de que no solo estás tratando de presumir en las reuniones. La próxima vez lo pensarán dos veces antes de volar, especialmente si se da cuenta de que su diseño "antiguo" ahora está reemplazando al actual roto.

Trate de construir una reputación como la persona que puede identificar lo que funcionará y no solo lo que cree que tendrá un problema en algún caso de uso raro. Cuando vea estos posibles problemas, considérelos una nota al pie de página que tal vez necesite abordar más adelante.

La gente se vuelve loca en las congregaciones. Mencione sus preocupaciones a una persona clave fuera de la reunión. Verán esto como menos amenazante y pueden tomarse el tiempo para escuchar su argumento en lugar de pensar en defender su diseño. También pueden tomar más tiempo para explicarle las circunstancias por las que puede tener un punto válido, pero no es posible abordarlo en v1.0.

¡Llave! Ingrese a la reunión con una comprensión completa de la agenda de su supervisor directo. Tal vez lo vean como un proyecto menor y lo último que necesitan en la reunión es que se niegue a tomarse el tiempo de los asuntos más importantes. Pídales que lo ayuden a ayudarlos.

Si desea influir en ellos, hable con ellos al respecto fuera de la reunión de diseño. De lo contrario, van a pensar que estás tratando de "ganar puntos" de ellos. Mucha gente nunca quiere tener discusiones reales en una reunión con una "audiencia".

No veo cómo esta situación es muy diferente de un desarrollador solitario con un jefe despistado. Desafortunadamente, he perdido la cuenta de la cantidad de veces que estaba 'convencido' de construir un proyecto de una manera determinada y enviarlo, a pesar de mis advertencias de muerte inminente. Eso te deja no solo construyendo, sino navegando el proverbial Titanic directamente en un iceberg solo.

Tal como lo describiste, cuando los bits golpearon el cubo proverbial, mis advertencias habían sido olvidadas hace mucho tiempo. A veces (por suerte para mí) las cosas salieron mal meses o más después de que ya no estaba involucrado en el proyecto. Desafortunadamente, esto dejó a mi sucesor pensando que debo estar loco, ya que puedes apostar que el jefe negó cualquier mano en él :)

De todos modos, un grupo de programadores 'convencidos' puede ser tan despistado como un jefe de pelo puntiagudo, a veces incluso más porque no tienen ni idea, como Jeff O menciona . Cuando esto sucede, tienes tiempo suficiente para arreglar las cosas. No trates de hacer que se escuche una sola voz de razón por un pedo cerebral colectivo. Si puede hacerlo de manera efectiva, su lugar está en el congreso, no detrás de un software de escritorio.

Como las acciones hablan más que las palabras, puedes:

• Muestre (con escenarios de prueba) por qué el diseño fallará en circunstancias normales. Esto probablemente resultará en una reunión más pequeña donde usted es el que presentará, y es probablemente todo lo que necesita para ser escuchado.

• Muestre un producto de la competencia que aborde adecuadamente lo que el grupo pensó que eran solo 'casos de esquina'. Te sorprendería hasta dónde llega Google para anticipar errores en su programa de hoja de cálculo, por ejemplo.

• Reitere el último proyecto que requirió una reescritura desde cero una semana antes de que se suponía que se enviaría.

En otras palabras, el primer paso, no importa lo que haga, es tratar con personas o un grupo (mucho) más pequeño. Si sus inquietudes realmente son válidas, estoy seguro de que serán mejor recibidas una o dos semanas en desarrollo. Simplemente, como notó, evite la postura de 'Te lo dije'.

Si es posible, revise el diseño antes (o incluso después) de la reunión y hable con los diseñadores en privado. Derribar a la gente en una reunión frente a todos sus colegas tenderá a hacerlos instantáneamente defensivos y de mente cerrada acerca de sus sugerencias, y puede dar lugar a una reputación como "problemático" a pesar de que cree que está siendo útil.

Una buena (pero a menudo difícil) forma de presentar "críticas" es hacer preguntas importantes: deje que la otra persona trate de responder a su pregunta y se dé cuenta de la falla por sí misma. Entonces parece mucho más como su propia idea y será más probable que la lleven adelante. Una vez más, esto funciona mejor en discusiones privadas, pero puede ser una forma más diplomática y efectiva de avanzar en una situación de reunión (Nota: trate de evitar entrar en una discusión o una discusión larga para convencer a las personas en la reunión. Simplemente haga llegar la idea e intente para no insistir en el punto. Puede ser mejor dejarlo y luego conversar con los diseñadores después de la reunión para "aclarar algo que no entendí bien" que ser "el tipo que hizo un simple 30 minutos reuniendo desperdicio toda mi mañana ")

Otro enfoque es enviar sus sugerencias (diplomáticamente) por correo electrónico al diseñador principal (o una lista de distribución relevante pero pequeña). Puede ayudarlo a considerar sus ideas, y también le brinda un "rastro de papel" para respaldar cualquier situación de "Te lo dije" en el futuro (si las cosas se ponen en forma de pera, al menos tiene pruebas de que intentó ayudar pero fue ignorado, pero si las cosas se ponen tan mal, probablemente no estés trabajando en la compañía correcta)

Finalmente, tenga en cuenta que a veces puede estar "equivocado". Las personas con las que habla pueden tener una comprensión más clara o más completa de su diseño que usted, y tener buenas razones para su enfoque (por ejemplo, un miembro del equipo me acusó recientemente de crear un diseño "ineficiente", pero era un diseño deliberado ya que sabía que el rendimiento seguiría siendo aceptable, pero reduciría a la mitad el costo de desarrollo: era una decisión comercial en lugar de una decisión de calidad del código). Solo trata de ser abierto sobre las ideas de los demás; a veces, lo que parece ser una mala idea para ti puede ser una buena idea por razones que no has considerado.

Cuando se encuentre con el escenario "eso nunca sucederá", recuérdeles todas las veces en el pasado cuando tuvieron que arreglar esos elementos "eso nunca sucederá". Pero hay que tener cuidado de no aparecer como "te lo dije". Creo que es más efectivo plantear problemas pasados ​​(y lo caros y dolorosos que fueron solucionarlos) al discutir por qué piensan que deberíamos hacer algo ahora para este proyecto como ejemplos de por qué piensan que esto es importante antes de que traigan el "que nunca va a suceder "cita.

Creo que quizás su problema es que dice que menciona casualmente una forma de evitar un problema. Quizás debería venir armado con más información y mostrarles con más detalle por qué esto es un riesgo para el sistema. A veces eso significa mencionar el tema en una segunda reunión después de haber tenido tiempo para investigar un poco. Elabore un caso de negocios sobre lo barato que es hacer ahora y lo caro que es hacerlo más tarde.

Parece que su mejor apuesta es trabajar para llegar a una posición de líder de equipo. Aproveche estas oportunidades para señalar a los poderes fácticos que lo vio venir y que podría haberse evitado. No debería necesitar vender a su equipo actual en corto para hacerlo.

Lo "casual" en "mencionar casualmente los agujeros" parece ser un problema. Intente utilizar (o incorporar si no existe) un proceso escrito para analizar los riesgos del proyecto. Normalmente, el resultado de una reunión de análisis de riesgos es una simple tabla de dos columnas: el riesgo y cuál es la estrategia acordada para mitigar el riesgo ("creemos que eso nunca sucede" es una mitigación aceptable; lo importante es registrar el pensamiento actual sobre el tema en el momento). Asegúrese de que sus problemas se registren como riesgos. Los riesgos deben revisarse periódicamente; lo más probable es que algunas personas hayan llegado a su punto de vista mucho antes de que la crisis realmente ocurra y una revisión de riesgos actuará como un "OMG que sí sucede"; estaríamos locos para continuar con este "catalizador". A largo plazo, un rastro en papel es una evidencia útil para decir "mira, parece que tenemos un problema institucional aquí" y obtener actitudes para diseñar o lo que sea que haya cambiado.

Cómo implementar su (s) idea (s)

Primero en las reuniones se refieren a los problemas como desafíos. Arreglas los problemas, superas los desafíos. Los desafíos son cosas buenas, los problemas no lo son.

Comience despacio y use esta técnica en un solo desafío a la vez. La próxima vez que desee que su jefe adopte una de sus ideas, haga lo siguiente:

• Desarrollar tres enfoques similares pero diferentes.
• Dile a tu jefe que necesitas su ayuda con algo
• Explique que no está seguro de cuál de los tres métodos es el mejor curso de acción para resolver el problema.
• Pídale que lo ayude a elegir uno de los tres

1. Esto es extremadamente poderoso. Lo que está haciendo es proporcionar opciones, no un ultimátum. Los ultimátums más a menudo no son derribados porque no es su idea y solo hay una opción.

2. Su uso de palabras es muy clave aquí. " Necesito tu ayuda ".

3. Deje que el jefe elija "A", "B" o "C". De hecho, deje que el jefe cree la opción "D" sacando secciones de "A", "B" y "C". Lo que estás haciendo es dejar que tu jefe tome una decisión.

En este punto, no te importa qué opción elija, porque son todas tus ideas. Pensará que en realidad está resolviendo el problema porque dejas que la decisión se convierta en suya.

Tener Proof of Conceptde su idea implementada. Si le muestra a su equipo algo que funciona y resuelve el problema actual, entonces les gustará.