Detener interminables discusiones técnicas y tomar una decisión.

Siempre me encuentro con personas a las que les gusta golpear durante años por las "cosas técnicas" más pequeñas.

No me malinterpretes, soy un programador geek que ama lo que hago, pero sabes el tipo de conversación.

• Mac es mucho mejor que Windows
• No use un ciclo For Each, use un ciclo While
• No compre una PC basada en Intel, obtenga una basada en AMD.
• Deberíamos usar un contenedor de IoC sobre otro.

Todas estas "cosas" tienen ventajas y desventajas válidas para ambas partes, y nunca obtendrá una respuesta "correcta", y la persona nunca aceptará el punto. (por supuesto, habrá algunos donde haya una respuesta, tal vez :).

Mi pregunta (¡estoy llegando allí!) Es: En un equipo de software, ¿cómo atraviesas estas largas discusiones sin inhibir la innovación, para que puedas tomar una decisión y puedas resolver los problemas comerciales reales?

Problema 1. A algunas personas no les gusta perder. Si no están haciendo los tiros, van a debatir hasta que tomen los tiros por deserción.

Problema 2. Nada está realmente en juego, por lo que se tolera el debate.

¿Nada está en juego? Sí. La mayoría de las decisiones tienen un impacto de casi cero dólares. El hecho de que se reduzca a "golpear por años" significa que ambas opciones son efectivamente idénticas.

¿Qué hacer?

1. Date cuenta de que no hay nada en juego.

2. Tenga en cuenta que en 2 o 3 años, todo el tema se reabrirá porque algo ajeno a la organización cambió.

3. Tirar una moneda. Seriamente. Simplemente elige algo y sigue adelante. Algunas personas verán la tontería en el debate. Algunas personas debatirán sobre la naturaleza de la moneda que se lanza. Si las personas no pueden estar satisfechas con el lanzamiento de una moneda, tienen problemas de ego y necesitan aprender que (a) no hay nada en juego y (b) la decisión cambiará en unos años.

Si no pueden darse cuenta de que no hay nada en juego, deben escribir el valor en dólares de ambos lados del argumento. En algún momento, alguien puede ver que se dedican más horas-hombre al análisis de lo que vale la decisión real. Un lanzamiento de moneda produce el mismo valor por un costo menor.

Un par de cosas para contemplar:

1. Solo acepte argumentos que sean cuantificables. Si alguien dice que ahorrará tiempo, pídales que lo cuantifiquen y mantengan la respuesta. De esta manera, si están hablando de basura, solo lo intentan antes de que todos sepan que son un rubor roto.

2. Haga que las personas se hagan responsables de sus recomendaciones. Deje en claro que al final del año, si han estado haciendo malas llamadas, eso será parte de su evaluación. No me importan los debates, pero quiero personas con el coraje de sus convicciones: si vas a jurar que algo es genial y esperas que lo adoptemos, será mejor que puedas vivir con las consecuencias.

Estas son cosas reales para escapar de los dos problemas de S.Lott: que a algunas personas no les gusta perder y que no hay nada en juego. Mi respuesta es poner algo en juego para que no haya debate por el bien del debate.

1. Timebox la discusión. - Si a cada lado le lleva más de 5 minutos exponer su caso, entonces es demasiado complejo. De hecho, usamos temporizadores de cocina para esto . Funcionan maravillosamente y cuestan alrededor de 5 dólares.
2. Exija que los participantes discutan con datos y experiencia.
3. Mantenemos las opciones sobre la mesa. Una vez que cada lado tiene su tiempo, pasamos otros 5 minutos discutiendo las implicaciones de cada enfoque. Después de 20 minutos, salimos y lo hacemos (implementarlo). Si no funciona, entonces vamos con el otro enfoque.

La regla es simple. Una vez que no sepa qué elegir, piense qué es mejor para la empresa.

Sí, la elección de Intel v AMD no es tan fácil. ¿Pero cuál es mejor para su empresa? Por ejemplo, si hay una persona que es responsable de ordenar cosas y le tomará mucho tiempo ordenar una PC con procesador AMD, pero Intel se puede pedir en un minuto y realmente no le importa lo que será. solo ordene uno basado en Intel porque es mejor para la compañía.

Por lo general, estas discusiones son realmente solo bikeshedding . Gente discutiendo qué formato de transferencia o qué almacén de datos usar y toneladas de otros detalles que deberían ser realmente transparentes para todos los componentes, excepto el que implementa los detalles. A nadie le importa mientras el componente cumpla con el contrato de diseño y los encargados del mismo podrán responder a los cambios del contrato en un período de tiempo razonable.

La gran mayoría de todos los problemas técnicos que encuentra en el desarrollo de software son problemas de bicicletas. Simplemente porque ya tienen soluciones y la única pregunta es qué solución desea elegir.
No debe encerrarse en tales decisiones. Debe bloquear tales decisiones en una capa de abstracción que desacople su aplicación de dichos detalles .
Los problemas realmente importantes en el desarrollo de software son problemas de diseño a nivel de funciones y sistemas. Todo lo demás es secundario.

Así que realmente ni siquiera comience tales debates. Concentra tu energía en dividir tu proyecto en partes independientes. Esto produce software, que es más robusto y flexible. Y si puede identificar las decisiones técnicas que tienen desventajas claras (algo que solo puede hacer, una vez que tiene un software en ejecución), puede tomar una decisión diferente sin afectar el resto del sistema.

La estandarización es un enfoque

Su equipo debe llegar a un consenso sobre lo que adoptará como su estándar de desarrollo y luego cumplirlo durante un período de tiempo razonable (decidido por el equipo). Si el estándar falla, entonces se adopta uno nuevo probablemente de un nuevo lote de posibles marcos de solución.

"Hey, esas PC fueron inútiles al final, ¡intentemos Macs!"

o

"¡Te lo dije! La primavera es mucho mejor que EJB".

Y así.

Tener un estándar significa que es más fácil trabajar con el código en un equipo, lo que a su vez conduce a un entorno más productivo.

Actualmente estoy probando el enfoque, el código llamado "cónclave papal" y es bastante prometedor. Se basa en una historia, que durante una de las elecciones papales hubo un "punto muerto" y los cardenales simplemente no pudieron tomar una decisión. La entidad anfitriona de una elección (muy probablemente algunos de los principales de la ciudad) primero encerró a los cardenales en un edificio, luego redujo drásticamente el suministro de alimentos y luego retiró el techo del edificio para que el debate fuera aún menos cómodo. Como se esperaba, los cardenales tomaron la decisión después de que se quitó el techo y terminó un punto muerto de tres años.

Entonces, mi enfoque es que cuando las personas no están de acuerdo en algunas cosas, se ven obligadas a discutirlo hasta que se les ocurra una elección. No proporciono ninguna otra molestia, ni siquiera una limitación de tiempo y, por supuesto, no hago nada con el techo :). Todo lo que hago es plantear constantemente el problema todos los días. Si alguien dice "No podemos tomar una decisión", respondo con "Bueno ... tienes que hacerlo". Hasta ahora no he conocido a una persona tan irremediablemente adicta a algunos detalles tecnológicos menores. Después de un montón de reuniones, tienden a buscar un compromiso al igual que los cardenales.

Estoy de acuerdo en que esta es una discusión más sostenida, en lugar de cortarla. Sin embargo, las discusiones no son interminables y, como ventaja, algunas personas después de tal "cónclave" tienden a evitar debates tecnológicos menores, lo que hace las cosas más cómodas para todo el equipo.

He leído en alguna parte que no debería viajar más de 6 juntos si necesita ponerse de acuerdo sobre dónde ir y qué hacer, ya que no llegará a un consenso.

Este es un excelente ejemplo de por qué debe haber una persona con poderes decisivos. En este ejemplo en particular, dicha persona necesita tomar una decisión y decir "debe ser así", y los demás deben respetar esa decisión para poder realizar un trabajo real.

Si la decisión luego resulta ser mala, al menos lo sabe con certeza y puede aprender de ella.

Un enfoque es por voto y funciona bien en equipos de menor tamaño.

Mientras que dos personas pueden estar teniendo la conversación; moverlo a un foro abierto ... debatir durante N cantidad de tiempo y luego celebrar una votación levantando las manos.

Simple pero democrático y le permite avanzar.

Una pregunta similar podría ser:

¿Cómo detener las guerras religiosas / de fuego en los foros?

Creo que @ S.Lott tiene razón en su comentario, si el único punto es "discusión", "alejarse" o ignorarlo podría ser la única respuesta. He usado esa técnica en el pasado.

Si el punto es llegar a una solución, evalúe los pros / contras para el dominio en cuestión, establezca un límite de tiempo y (asiente a Nike) simplemente hágalo.

Idealmente, en mi opinión, la figura de autoridad o líder tecnológico dice: "está bien, gracias por sus puntos, estamos ..." sonido de tirada de dados "... yendo con la idea de tal y tal". y todos van y se sientan.

Geekery sobre puntos minúsculos ha desperdiciado una gran cantidad de mi tiempo de reunión, y no quiero escucharlo más. : - /

Me parece que cuando enfocas la conversación no en qué alternativa es la correcta sino en cuáles son las consecuencias de elegir la incorrecta, tiendes a no quedarte empantanado. Si podemos llegar a un consenso de que, incluso si A tiene razón, B no nos matará, nadie se enojará demasiado si terminamos con B. Si no podemos llegar a ese consenso, generalmente es porque hay un problema real que tenemos que abordar

Lo principal es que tenemos que ser maduros y comprender que no siempre podemos estar de acuerdo entre nosotros, lo importante y maduro es aprender unos de otros, por qué tenemos las posiciones que tenemos y tal vez relacionadas con las mías. pregunta, aprenda qué experiencias y por qué. Entonces podemos inventar nuestra propia opinión informada y ser condenados o no.

Personalmente no necesito ni espero que otras personas estén de acuerdo conmigo, sería bueno, pero no importante. Y hasta este punto, cito a Voltaire.

"Puedo estar en desacuerdo con lo que dices, pero defenderé hasta la muerte, tu derecho a decirlo". -Voltaire, filósofo del siglo V

Cada reunión debe tener un presidente responsable de la agenda y mantener el orden (y tomar minutos, aunque pueden delegar esta tarea a otra persona si la reunión es demasiado grande para que puedan manejar todo). La tarea del presidente es decirle a alguien que deje de discutir ("muchachos, desconéctense" en el discurso corporativo).

Si no vale la pena nombrar a un presidente para la reunión, no vale la pena tener una reunión. También podría tener una conversación en el refrigerador de agua.

Se puede decir "más fácil decirlo que hacerlo, quant_dev". Bueno ... un presidente natural es un líder de equipo, un gerente de proyecto, un gerente de equipo. Deben tener la autoridad necesaria. Las reuniones donde nadie sabe quién lidera realmente las reuniones son signos de caos en la organización, un problema más profundo que debe resolverse.

Primero resuelva los problemas generales: necesitamos un servidor web, un servidor de aplicaciones, una base de datos, etc.

Para los debates sobre qué DB o servidor usar, estacione esos elementos para otra reunión.

Durante las reuniones subsiguientes, permita que la discusión haga una "lista corta" de las ofertas potenciales, por ejemplo, MySQl, MS SQL Server, Postgres, etc.

Permita que los miembros del equipo expresen sus opiniones, pero solicite que los respalden con hechos. ¡El producto X apesta! ¡No lo corta, el producto Y no escala! Es muy vago Etc.

Una vez que todos los detalles estén en la mesa, debe someterlo a votación o, como líder del equipo, tomar una decisión ejecutiva.

Si necesita eliminar a un claro ganador o confirmar el apoyo / falta de una característica / concepto, no dude en tomarse un tiempo para hacer un POC (prueba de concepto), pero tenga en cuenta que esto llevará tiempo y hay una tendencia para que los desarrolladores desea correr con lo que sea que hayan comenzado ... Asegúrese de verificar cualquier obstáculo / inquietud tecnológica antes de ir con el POC.

Como líder de equipo, siento que depende si la decisión debe tomarse aquí y ahora.

Si es necesario, entonces busco el que tiene el menor costo de reversión. Siempre es importante, como equipo de desarrollo, saber que su decisión puede estar equivocada, puede que tenga que tomar la decisión descarada y cambiar de opinión. El costo de hacerlo siempre debe minimizarse.

Si puede esperar, considere el hecho de que ninguna de las partes en desacuerdo está en posesión de todos los hechos. Pídales que se vayan e investiguen más y hagan su propia investigación.

¿Siempre hacemos esto en el fragor de la batalla? No, particularmente cuando soy uno de los que tienen una opinión acalorada (no pretendo ser perfecto). Pero sí creo que esta es la forma de abordar tales situaciones. El boxeo en el tiempo nunca parece llevar a que todos estén de acuerdo, solo lleva a una discusión inconclusa.

A menos que tenga un miembro difícil del equipo, generalmente no tiene un debate interminable a menos que no haya una ventaja clara para ninguno de los enfoques. Los siguientes son algunos buenos enfoques para romper un empate:

• Deje que la persona que realmente tiene que implementarlo decida.
• Para problemas de UI, deje que la persona más consciente de los requisitos del cliente decida.
• Deje que la persona con más experiencia en el tema o parte de la base del código decida.
• Deje que la persona con las restricciones de horario más estrictas o la mano de obra y las limitaciones de recursos decidan.
• Deje que la persona decida quién tiene objeciones más concretas que teóricas.
• Encuentre un compromiso entre los enfoques.
• Reúna más información y decida en la próxima reunión, dando más peso a las personas que obviamente pasaron algún tiempo investigando desde la última reunión.

En cuanto a cómo anunciar una decisión, simplemente dice: "Bien, vamos a seguir con esto debido a esto ". Si las personas sienten que les has dado una audiencia imparcial, y no eres indeciso como líder, aceptarán tu decisión. Para los más obstinados, puede prometer reevaluar después de que se haya realizado una cierta cantidad de implementación, pero la mayoría de las personas lo abandonarán en ese momento.

Un buen facilitador de reuniones puede facilitar este tipo de discusiones sin dejar que se salgan de control.