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

14

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

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

Entonces, ¿qué hago? Eliminar 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 recuerda al mundo de las trampas. A menudo me siento y observo cómo el Titanic navega hacia Europa.

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

    
pregunta User1 05.11.2010 - 02:36

10 respuestas

3

Si es posible, sugiera modificaciones que no agreguen tiempo significativo a un proyecto. Intente y enfatice 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 demorará el proyecto, etc.

No pongas a las personas en modo de defensa en una reunión, solo lucharán contra ti para ser el ganador. No conseguirás que acepten que la tierra es redonda. Esto es 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 seas despedido de inmediato. Por supuesto, si siempre eres algo pesimista, entonces serás etiquetado como el tipo "negativo".

Para cosas simples (es decir, no afecta a los horarios), asegúrese de hacer su trabajo de la mejor manera. Si pones el esfuerzo en tu salida inmediata (por ejemplo, creando casos de prueba o obteniendo algunas funciones simples (pero geniales)), otras personas notarán que tu código funciona de manera confiable y resiste la prueba del tiempo. Cuando comiences a mostrarles algunos trucos con el código, pensarán dos veces disparándote 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 / jefe de tecnología cuando sea que realmente tenías razón. Tal vez vuelva a enviar un correo electrónico viejo con sus comentarios anteriores. Pregúnteles si esto ayudaría a resolver el problema "nuevo". Si no haces esto, ni siquiera recordarán que fuiste tú quien lo mencionó la primera vez. Eventualmente obtendrán el indicio de que no solo estás tratando de ser un showoff en las reuniones. La próxima vez se lo pensarán dos veces antes de despedirte, especialmente si se da cuenta de que tu diseño "antiguo" ahora está reemplazando al actual.

    
respondido por el cmcginty 05.11.2010 - 03:54
11

Intente construir una reputación como la persona que puede identificar lo que funcionará y no solo lo que usted cree que tendrá un problema en algún caso de uso raro. Cuando vea estos problemas potenciales, considérelos como una nota a pie de página que tal vez deba ser tratada 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 que esto es menos amenazador y pueden tomarse el tiempo para escuchar su argumento en lugar de pensar en defender el 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 factible abordar en v1.0.

Clave! Vaya a la reunión con una comprensión completa de la agenda de su supervisor directo. Tal vez vean esto como un proyecto menor y lo último que necesitan en la reunión es que no diga nada y se tome el tiempo para asuntos más importantes. Pídales ayuda para ayudarlos.

    
respondido por el JeffO 05.11.2010 - 03:07
4

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

    
respondido por el Jeremy 05.11.2010 - 13:54
1

No veo en qué se diferencia esta situación de un desarrollador solitario con un jefe despistado. Desafortunadamente, he perdido la cuenta de la cantidad de veces que estuve "convencido" de construir un proyecto de cierta manera y enviarlo, a pesar de mis advertencias de inminente muerte. Eso te deja no solo construyendo, sino navegando por el proverbial Titanic en un iceberg por ti mismo.

Tal como lo describiste, cuando los bits golpearon el cubo proverbial, mis advertencias ya habían sido olvidadas. A veces (afortunadamente para mí) las cosas se pusieron 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 a que el jefe le negó cualquier mano :)

De todos modos, un grupo de programadores 'convencidos' puede ser tan despistado como un jefe de pelo puntiagudo, a veces incluso más porque carecen de información, como Jeff O menciona . Cuando esto sucede, tienes tiempo suficiente para arreglar las cosas. No trates de hacer que una sola voz de la razón se escuche sobre un cerebro colectivo. Si puede hacerlo de manera efectiva, su lugar está en el Congreso, no detrás de un software de escritura 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. Es probable que esto resulte en una reunión más pequeña en la que sea usted quien presente, y probablemente sea todo lo que necesita para ser escuchado.

  • Muestre un producto de la competencia que aborde adecuadamente lo que el grupo pensaba que eran solo "casos de esquina". Usted se sorprendería a qué longitud va Google para anticipar errores en su programa de hoja de cálculo, por ejemplo.

  • Reitere el último proyecto que requirió una reescritura inicial una semana antes de su envío.

En otras palabras, el primer paso, no importa lo que hagas es tratar con individuos o con un grupo (mucho) más pequeño. Si sus inquietudes son realmente válidas, estoy seguro de que serán mejor recibidas una o dos semanas antes del desarrollo. Solo, como notaste, evita la postura de "Te lo dije".

    
respondido por el Tim Post 05.11.2010 - 03:38
1

Si es posible, revise el diseño antes (o incluso después) de la reunión y hable con los diseñadores en privado. Disparar a las personas en una reunión frente a todos sus colegas tenderá a hacer que se pongan instantáneamente a la defensiva y cerradas con respecto a sus sugerencias, y puede llevar a una reputación de "creador de problemas" a pesar de que cree que está ayudando.

Una buena (pero a menudo difícil) forma de presentar "críticas" es hacer preguntas importantes: deje que la otra persona intente responder 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. Nuevamente, esto funciona mejor en discusiones privadas, pero puede ser una manera 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 discusión prolongada para convencer a las personas en la reunión. Simplemente transmita la idea e intente no trabajar el punto. Puede ser mejor dejarlo ir y luego conversar con los diseñadores después de la reunión para "aclarar algo que no entendí del todo" que ser "el tipo que hizo un simple 30 minutos". perdiendo la reunión toda la mañana ")

Otro enfoque es enviar por correo electrónico sus sugerencias (diplomáticamente) al diseñador principal (o una lista de distribución relevante pero pequeña). Puede ayudar a que sus ideas se consideren, y también le da un "rastro de papel" para respaldar cualquier situación "te lo dije" en el futuro (si las cosas van en forma de pera, al menos tienes pruebas de que intentaste ayudar, pero ignorado. Pero si las cosas se ponen tan mal, es probable que no estés trabajando en la empresa adecuada)

Finalmente, tenga en cuenta que a veces puede estar "equivocado". Las personas con las que está hablando pueden tener una comprensión más clara o completa de su diseño que usted, y tienen buenas razones para su enfoque (por ejemplo, un miembro del equipo me acusó recientemente de crear un diseño "ineficiente", pero fue un diseño deliberado ya que sabía que el rendimiento aún sería aceptable, pero reduciría a la mitad el costo de desarrollo (fue una decisión de negocios en lugar de una decisión de calidad de código). Solo trate de tener una mente abierta con respecto a las ideas de los demás; a veces, lo que parece ser una mala idea para usted puede ser una buena idea por razones que no ha considerado.

    
respondido por el Jason Williams 06.11.2010 - 08:14
0

Cuando se encuentren con el escenario "eso nunca sucederá", recuérdeles todas las veces en el pasado cuando tuvieron que arreglar esos elementos "que nunca sucederán". Pero debes tener cuidado de no aparecer como "te lo dije". Me parece más efectivo plantear problemas pasados (y cuán caros y dolorosos fueron para solucionarlos) al analizar por qué cree que debemos hacer algo por este proyecto ahora como ejemplos de por qué considera que esto es importante antes de que surjan del "eso". Nunca sucederá "cita".

Creo que tal vez su problema sea que usted dice que menciona casualmente una manera 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 hablar sobre el tema en una segunda reunión después de haber tenido tiempo de investigar un poco. Cree un caso de negocios para lo barato que es hacer ahora y cuánto costará hacerlo más tarde.

    
respondido por el HLGEM 05.11.2010 - 14:49
0

Parece que tu mejor apuesta es trabajar para llegar a una posición de líder de equipo. Aproveche estas oportunidades para señalar a los poderes que vieron que esto se avecinaba y podría haberse evitado. No debería tener que vender a su equipo actual corto al hacerlo.

    
respondido por el Kavet Kerek 05.11.2010 - 15:52
0

El "casual" en "mencionar casualmente los agujeros" parece ser un problema. Trate de usar (o ingrese si no existe) algún proceso escrito para analizar los riesgos del proyecto. Por lo general, el resultado de una reunión de análisis de riesgos es una tabla simple de dos columnas: el riesgo y la estrategia acordada para mitigar el riesgo ("pensamos que 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 estén registrados como riesgos. Los riesgos deben ser revisados regularmente; lo más probable es que muchas personas hayan llegado a su punto de vista mucho antes de que realmente ocurra la crisis y una revisión de riesgos actuará como un "OMG que sí ocurre ; estaríamos locos si continuáramos. como este "catalizador. A más largo plazo, un rastro de papel es una evidencia útil para decir "mira, parece que tenemos un problema institucional aquí" y obtener actitudes para el diseño o lo que sea que haya cambiado.

    
respondido por el timday 05.11.2010 - 22:55
0

Cómo implementar tus ideas

Lo primero en reuniones se refiere a los problemas como desafíos. Arreglas problemas, superas retos. 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:

  • Desarrolle tres enfoques similares pero diferentes
  • Dígale a su jefe que necesita 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 a él / ella que lo ayude a elegir uno de los tres

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

2. El uso de las palabras es muy importante 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" extrayendo secciones de "A", "B" y "C". Lo que estás haciendo es dejar que tu jefe tome una decisión.

En este punto, a usted no le importará la opción que elija, porque son todas sus ideas. Pensará que en realidad está resolviendo el problema porque dejas que la decisión se convierta en suya.

    
respondido por el Michael Riley - AKA Gunny 06.11.2010 - 19:26
0

Ha implementado Proof of Concept de tu idea. Si le muestra a su equipo algo trabajando y resolviendo el problema actual en cuestión, entonces les gustará.

    
respondido por el Rachel 29.01.2011 - 05:24

Lea otras preguntas en las etiquetas