¿Alguna vez has dicho que dices algo completamente normal para ti, pero todos los demás están muy sorprendidos? Esto me sucede constantemente cuando describo lo que se consideraba normal en la empresa donde trabajaba. Por alguna razón, la cara del interlocutor se convierte gradualmente de una sonrisa agradable en una mueca de asombro extremo. Aquí hay algunos ejemplos típicos.

Hay una muy buena compañía, uno de los lugares más agradables en los que he trabajado, una combinación de todas las ventajas de Valve y Netflix. La gente aquí es increíble, y te dan una libertad casi completa para hacer lo que quieras. Pero como efecto secundario de tal cultura, aproximadamente el 50% de los nuevos empleados los dejan en el primer año, algunos de forma voluntaria y otros no. Absolutamente normal, ¿eh?

Hay una compañía que es increíblemente reservada sobre su infraestructura. Por ejemplo, tiene miedo de informar errores al proveedor del equipo, porque entonces los errores serán corregidos y los competidores podrán usar las correcciones. Esto no se puede permitir. Solución: ¡solicite firmware y corrija los errores usted mismo! Esta bien

Más recientemente, me reuní con especialistas que intentaron reproducir el algoritmo publicado en el artículo de esa compañía. No pudieron reproducir el resultado. Además, el algoritmo del artículo condujo a un nivel inusualmente alto de inestabilidad. Cuando se le preguntó a uno de los autores sobre esto, respondió: "Bueno, sí, hay algunos trucos que no aparecieron en el artículo", y se negó a compartir estos trucos. Es decir, la compañía publicó intencionalmente un resultado improductivo para no dar detalles, como solía hacer con los errores.

La compañía amenaza con despedir instantáneamente a cualquier empleado que filtre información. Esto se le dice a cada recién llegado con ejemplos de personas despedidas por la fuga (por ejemplo, un chico filtró información de que el concierto se llevará a cabo en una determinada oficina). Cada despido se informa en voz alta y se comunica a todos los empleados. Como resultado de esta política, muchos temen reenviar correos electrónicos incluso con información inocente, como la actualización de datos de seguros. En cambio, imprimen una carta desde otra computadora y la transmiten en papel. O tomar fotos en el teléfono. Esta bien

En una oficina, una vez pregunté por qué dos empleados específicos parecen evitarse. Me dijeron que su enemistad ha estado ocurriendo durante diez años. De hecho, la situación ha mejorado últimamente. Durante muchos años, literalmente no pudieron estar en la misma habitación, de lo contrario, uno de ellos se enojaría demasiado y haría algo desafortunado. Pero ahora los muchachos se han enfriado, por lo que a veces se los puede encontrar en el mismo ala de la oficina o incluso en la misma habitación. Y estas no son solo personas aleatorias. Estos son los gerentes de los dos únicos equipos en esta empresa. OK!

Hay una compañía con una cultura tan extraña que puedes escribir un pequeño libro sobre ella. De hecho, recientemente comencé a escribir una publicación sobre esta compañía y ya escribí más de 100 mil palabras , más que todas las publicaciones combinadas en mi blog.

Esta compañía me explicó que es mucho mejor tomar decisiones no sobre la base de datos, sino sobre la base de relaciones políticas, y que la idea de tomar decisiones sobre la base de datos es en cualquier caso un mito, nadie lo hace.

En esta empresa me dieron cuatro razones para trabajar con ellos. Los cuatro resultaron ser una mentira. Como resultado, mis responsabilidades laborales se redujeron al hecho de que cuando contraté, acepté no hacer nada.

Cuando me uní a esta empresa, mi equipo no tocó el sistema de control de versiones durante varios meses. Tuve que luchar para que todos lo usaran. Gané esta batalla. Pero no pudo convencer a los empleados para que primero realicen pruebas. Por lo tanto, la asamblea se rompe varias veces al día.

En una conversación con la gerencia, insinué que considero que esto es un problema de la productividad de nuestro departamento. Me dijeron que esto es normal. Esta es la situación para todos los empleados, por lo que todos están en igualdad de condiciones. Mi tarea es clasificarlos, así que si el problema afecta a todos por igual, entonces no hay motivo de preocupación.

Otra compañía ha lanzado muchas iniciativas a gran escala para atraer a mujeres desarrolladoras, pero las mujeres aún están siendo evaluadas para entrevistas con preguntas como "¿Tenías experiencia con algoritmos o solo codificación?" Pensé que mi candidato con una muy buena recomendación atravesaría esta barrera pero olvidé lo normal que era la empresa.

En otra compañía, trabajé en un equipo de cuatro en un proyecto con un presupuesto de varios cientos de millones de dólares y un efecto anual de mil millones de dólares. Al mismo tiempo, las solicitudes de cosas por valor de cientos de dólares fueron consideradas durante meses o rechazadas.

Puede parecerle que trabajé solo en compañías inusualmente malas. Pero no, tienen una buena reputación, y dos de ellas son consideradas una de las mejores empresas para obtener empleo. Y escuché historias similares de empleados de otras compañías, incluso con una excelente reputación de ingeniería. La única diferencia es que ahora estaba en estado de shock, y el interlocutor creía que todo estaba bien.

Muchas compañías usan la biblioteca Flaky , que agrega anotaciones de Python a pruebas poco confiables que pasan o fallan. Pregunté a los empleados de tres compañías diferentes qué hace Flaky. Todos ellos sugirieron que ella ejecute repetidamente la prueba y los informes en caso de falla. Cerca, pero no del todo. Técnicamente, se puede usar de todos modos, pero en la práctica reinicia repetidamente la prueba e informa que se completó con éxito. Flaky fue desarrollado por una empresa que se ocupa de la infraestructura de almacenamiento de datos, mientras que la biblioteca está utilizando activamente a su mayor competidor. Marcar como pruebas aprobadas con posibles errores es completamente normal .

Hay una compañía que es conocida por sus buenas prácticas de ingeniería. Cuando lo revisé por última vez, ella tenía un tiempo de actividad del 99.99%, lo que se explica completamente por las prácticas de ingeniería adoptadas allí. Si una startup se parece a Twitter o Reddit, solo un nueve es suficiente, pero estamos hablando de una plataforma de infraestructura que realmente necesita dos. Muchas compañías que construyen la infraestructura para dos nueves consideran que sus prácticas que conducen a tal confiabilidad son completamente normales.

Por lo que puedo decir, muchas de estas compañías han recorrido un largo camino. Al principio, se centraron solo en el crecimiento del producto. Esto es absolutamente razonable, porque inicialmente el valor de la empresa es aproximadamente cero. Ella no implementa una administración de sistema competente o seguridad real, porque no tiene nada que perder. Bueno, con la excepción de los datos del usuario, cuando inevitablemente se piratea, y si hablas con oficiales de seguridad en grandes empresas privadas (se llaman "unicornios", unicornio), entonces esto sucede todo el tiempo.

El resultado es una cultura que se centra demasiado en el crecimiento sin riesgo. Esta cultura a menudo se conserva incluso cuando la compañía ha crecido a mil millones de dólares y ya tiene algo que perder. Si una persona solía trabajar para Google, Amazon u otra empresa con procedimientos sólidos, entonces la situación lo sorprenderá. A menudo intenta arreglar algo, pero no puede hacer nada y renuncia.

Probablemente, Google tiene hoy las mejores prácticas operativas y métodos de seguridad entre todas las empresas de TI del mundo. Es fácil decir que debemos tomar un ejemplo de ello. Pero es instructivo ver cómo lograron esto. Y lo que pasó antes. Si observa la base del código, verá muchos servicios cuyos nombres terminan en z, así como una cantidad sorprendentemente grande de variables. Uno de los antiguos empleados dijo que alguna vez alguien quería agregar monitoreo. No era muy seguro configurar google.com/somename para monitorear, por lo que agregaron z, que es google.com/somenamez , por seguridad. Esto está en la compañía, que ahora se considera la mejor del mundo en seguridad.

Ahora ha avanzado tanto en seguridad que los nuevos empleados niegan con vehemencia tales prácticas en el pasado. Al mismo tiempo, se invocan razones que realmente no tienen sentido (por ejemplo, para evitar colisiones de nombres).

El tremendo progreso de Google en seguridad, desde agregar la letra z a las mejores prácticas de IB del mundo, no sucedió porque alguien hizo una charla motivadora o escribió un ensayo convincente. Comenzó después de varios "fakap". Solo entonces se les dio a los guardias de seguridad la autoridad para resolver problemas fundamentales. Para las empresas buenas y correctas, las reformas casi siempre comienzan de esta manera. Microsoft se rió de él durante muchos años, pero luego varias hazañas catastróficas los obligaron a cambiar su actitud hacia la seguridad. Solo suena simple. Pero los testigos dicen que el cambio fue cruel. A pesar de estar indicado desde arriba, la inercia se mantuvo muy fuerte. ¿Por qué cambiar lo que funcionó? Por lo tanto, había una presión muy fuerte de las personas que estaban acostumbradas a hacer todo a la antigua usanza.

Tales cosas se pueden ver en cualquier industria. Un ejemplo clásico a menudo citado por los técnicos es el lavado de manos por parte de médicos y enfermeras. Es bien sabido que existen microbios, y lavarse las manos con jabón reduce en gran medida la probabilidad de transmisión microbiana y, por lo tanto, reduce significativamente la tasa de mortalidad en los hospitales. A pesar de esto, incluso los médicos y enfermeras experimentados a menudo no lo hacen. Se requiere intervención. Las señales que recuerdan lavarse las manos salvan vidas. Y aún mejor, que las personas vivas se pusieron de pie y exigieron lavarse las manos: de esta manera se salvan aún más vidas. Las personas pueden ignorar las señales, pero no pueden pasar por la persona a cargo.

Algo así, las compañías de TI están tratando de implementar las mejores prácticas. Si le dice a los empleados qué hacer, ayuda un poco. Si implementa la verificación del código, el efecto es inmediatamente evidente.

Las estadísticas muestran claramente que las personas dominan muy mal los hábitos de rutina que no dan un efecto visible, pero reducen irreversiblemente el riesgo de eventos raros pero catastróficos. A una persona le parece que cortar un camino es la ruta correcta y razonable. Hay un término especial para esto: "normalización de la desviación". Se ha estudiado bien en varios otros contextos, incluidos la asistencia sanitaria, la aviación, la ingeniería, la ingeniería aeroespacial y la ingeniería civil, pero aún no se ha discutido en el contexto del software.

¿Es posible aprender de los errores de los demás y no de los tuyos? El estado de la industria no da razones para contar con esto, pero intentemos. John Banya escribió un breve informe sobre la normalización de la desviación de la atención médica , cuyos hallazgos se pueden aplicar al desarrollo de software. Cabe señalar que el tratamiento de los pacientes se puede comparar con las acciones de los devops. Sin embargo, la normalización de la desviación también ocurre en un contexto cultural donde la analogía no es tan obvia.

La primera sección del artículo describe en detalle una serie de situaciones catastróficas, tanto en la atención médica como en otras áreas. Aquí hay un ejemplo típico:

El caso de negligencia catastrófica, que el autor observó como testigo experto, se relacionó con el anestesiólogo apagando el aparato de ventilación pulmonar artificial a pedido de un cirujano que quería tomar una radiografía de la cavidad abdominal del paciente (Banya, 2005, p. 87-101). Se suponía que el ventilador debía apagarse solo por unos segundos, pero el anestesiólogo olvidó volver a encenderlo o pensó que estaba encendido, pero no lo encendió. La paciente no tenía oxígeno el tiempo suficiente para que comenzara la anoxia completa, lo que la sumergió en un estado vegetativo. Ella nunca se recuperó. Después de 9 días, se desconectó de la ventilación mecánica, y después de 2 días murió. Más tarde se descubrió que las alarmas de anestesia y el equipo de monitoreo en la sala de operaciones fueron programados intencionalmente para "suspender indefinidamente" de tal manera que el anestesiólogo no recibió una advertencia sobre un problema con el ventilador. La alarma en sí estaba en su lugar, pero apagada, tal vez porque el personal operativo encontró el dispositivo chirriando molestamente.

¿Apagar o ignorar las notificaciones porque hay demasiadas y son demasiado molestas? ¿Actúa manualmente con el riesgo de cometer un error? Sí, puedo nombrar algunas compañías a la vez, donde el informe después de un desastre comienza precisamente desde estos puntos, a menos que al final nadie muera y solo se pierdan unos pocos millones de dólares. Si lee muchos análisis de tales incidentes en TI , cada ejemplo en el artículo de Bunny le parecerá familiar, incluso si los detalles son diferentes.

La sección termina con esta conclusión :

Como regla general, estos desastres se explican por "una larga violación de las reglas, eventos contradictorios que se acumularon sin ser detectados y una idea cultural incorrecta de los peligros". Juntos, estos factores impidieron una intervención que podría haber evitado los efectos nocivos ". Es especialmente sorprendente cómo se combinan numerosas violaciones de las reglas y errores para crear la oportunidad de un desastre.

Nuevamente, el texto parece ser de un artículo sobre fallas técnicas. Por lo tanto, la siguiente sección sobre las causas de estas fallas merece atención. Y las razones son las siguientes.

Reglas tontas e ineficaces

El artículo proporciona un ejemplo de la administración de medicamentos a los recién nacidos. Para evitar la "fuga de drogas", la enfermera debe ingresar una contraseña en la computadora. Ella tiene acceso a la caja de medicamentos y toma la cantidad correcta de medicamentos. Para asegurarse de que la primera enfermera no haya robado nada, la segunda enfermera debe monitorear el proceso. Luego, debe ingresar su contraseña en la computadora como confirmación de que ha observado el procedimiento correcto para manipular el medicamento.

Suena familiar Muchos informes de incidentes comienzan con el hecho de que "alguien omitió algunos pasos porque no son efectivos". Por ejemplo, "un programador lanzó una configuración incorrecta o un código incorrecto porque estaba seguro de ello y no quería pasar tiempo preparando o probando". El famoso cierre de Azure en noviembre de 2014 ocurrió precisamente por esta razón.

Aproximadamente al mismo tiempo, uno de los competidores de Azure, los desarrolladores cancelaron una regla que prohíbe empujar una configuración que falla las pruebas en la sucursal de Canarias. Los desarrolladores estaban seguros de que la configuración estaba en orden. Cuando Canary comenzó a fallar, cancelaron la regla que prohíbe el despliegue de Canary a Staging con un error. Estaban seguros de que la configuración estaba en orden y que la falla fue causada por otra cosa. El análisis posterior mostró que la configuración era técnicamente correcta, pero con ella se manifestó un error en el software principal. Es pura suerte que el error oculto revelado por la configuración no sea tan grave como el error de Azure.

La gente no comprende bien cómo se superponen los errores. Por lo tanto, aceptamos las reglas para una implementación segura. Pero por la misma razón por la que las personas no comprenden bien cómo se superponen los errores, ¡estas reglas parecen tontas e ineficaces!

El conocimiento es imperfecto y desigual.

El concepto de una norma no es innato. Cuando llegan nuevas personas a la empresa, absorben fácilmente los procesos desviados que se han convertido en la norma.

Julia Evans me describió cómo sucede esto:

llega el recién llegado
Novato : WTF WTF WTF WTF WTF
Veterano : Sí, lo sabemos, estamos haciendo esto.
novato : WTF WTF wTF wtf wtf w ...
novato se acostumbra
viene el segundo principiante
novato No. 2 : WTF WTF WTF WTF
principiante : sí, lo sabemos, estamos haciendo esto.

Lo más insidioso es que las personas realmente aceptan la idea de WTF, y luego pueden difundirla en otros lugares a lo largo de su carrera. Una vez trabajé con un proyecto de código abierto que se bloqueaba regularmente. Me dijeron que esto es normal y que su producto es mejor que el promedio. Lo comprobé y descubrí que era el peor de su clase en casi todos los aspectos. Y esbozó la idea de cómo lanzar versiones con relativamente poco esfuerzo, lo que casi siempre pasará las pruebas. La respuesta más común fue: “Wow, este tipo debe estar trabajando con programadores superestrella. Pero seremos realistas. La asamblea de todos se rompe al menos varias veces a la semana ". Como si ejecutar pruebas (o, para el caso, incluso tratar de compilar) antes de verificar el código requiera esfuerzos sobrehumanos. Pero tan pronto como la gente cree que algún tipo de desviación es normal, a menudo realmente absorben la idea.

Rompo la regla por el bien del paciente

El artículo proporciona un ejemplo de un médico que viola la regla de que se deben usar guantes al buscar una vena. Él cree que usar guantes hace que sea difícil encontrar una vena, por lo que tendrá que pinchar a un niño con una aguja varias veces. Es difícil discutir con eso. ¡Nadie quiere lastimar a un niño!

El segundo fracaso más grande de todo lo que he visto en mi vida sucedió por esta razón. Alguien notó una desaceleración de la base de datos. Rápidamente escribieron un parche, y para evitar que la degradación se extendiera aún más, ignoraron la regla de un despliegue lento y gradual. En cambio, enrollaron el parche en todas las máquinas. Es difícil discutir con eso. ¡Nadie quiere que los clientes experimenten una degradación del servicio! Desafortunadamente, el parche detectó un error que provocó un cierre global del servicio.

Las reglas no se aplican a mí / Puedes confiar en mí

La mayoría de las personas se consideran buenas y decentes, por lo tanto, pueden considerar su violación de las reglas como una respuesta completamente racional y éticamente aceptable a situaciones problemáticas. Están seguros de que no están haciendo nada malo, y se indignarán y, a menudo, se defenderán ferozmente si se enfrentan a pruebas de lo contrario.

A medida que la empresa crece, es necesario introducir un sistema de seguridad que no permita que todos los empleados tengan acceso a casi todo. Y cuando esto sucede, en la mayoría de las empresas, algunos empleados están realmente molestos: “¿No confías en mí? Si confías, ¿por qué niegas el acceso a X, Y y Z? ”

Se sabe que Facebook ha proporcionado a los empleados acceso al perfil de cualquier usuario desde hace mucho tiempo.. Algunos reclutadores incluso mencionaron esto como una ventaja de trabajar en Facebook. Y conozco más de una startup respetada, donde, como antes, cada empleado tiene acceso a casi toda la información, incluso después de una o dos filtraciones de información. Se necesita cierta voluntad política para limitar el acceso de las personas a lo que consideran necesario o habitual por ley. Muchas startups de moda han declarado los valores centrales de "confianza" y "transparencia", lo que dificulta la justificación de las restricciones de acceso.

Los trabajadores tienen miedo de realizar

No quiero expresar mi opinión a algunas personas, porque pueden enfrentarlo con hostilidad y no pueden devolver las palabras habladas. En el artículo científico mencionado, el autor da un ejemplo de un médico con mala escritura. Se enoja cuando alguien le pide que aclare lo que escribió. Como resultado, la gente se pregunta, no pregunta.

La mayoría de las empresas han desarrollado una cultura de que la retroalimentación es difícil. Muchos proyectos se retrasaron durante varios meses y luego se detuvieron, porque cada empleado tenía miedo de expresar su opinión desde el principio, por miedo a las críticas. El problema está presente incluso en culturas que fomentan la cortesía: allí también es difícil expresar críticas sinceras. Resulta que en algunas empresas las personas tienen miedo de hablar, porque alguien las ataca. En otros, tienen miedo de hablar, porque ellos mismos son tildados de malvados. Problema difícil

Manual oculta problema

Un artículo científico dice cómo la información sobre un problema se borra cuando se pasa por la cadena. Un ejemplo es cómo un gerente toma acciones no óptimas para no verse mal frente a sus superiores.

Me sorprendió cuando vi esto por primera vez. Las personas entienden que están haciendo algo claramente mal. Pero si optimiza, hay una probabilidad de falla distinta de cero, y entonces será muy vergonzoso. Por lo tanto, es más fácil dejarlo como está. Con años de experiencia profesional, entiendo mejor cómo y por qué las personas juegan a este juego, pero todavía lo encuentro absurdo.

Soluciones

Supongamos que su empresa tiene un problema típico: las personas son recompensadas por el heroísmo en la extinción de incendios y no por evitarlos. Y las personas son promovidas por lanzar nuevas funciones, no por realizar tareas críticas de mantenimiento y corrección de errores. ¿Cómo cambiar esto?

La opción más fácil es hacer lo correcto por su cuenta e ignorar lo que sucede a su alrededor. Traerá algún beneficio, pero el alcance de su influencia es limitado. A continuación, puede convencer a su equipo para que haga lo correcto: lo he hecho varias veces para implementar prácticas que creo que son realmente importantes.

Pero si los incentivos se dirigen contra usted, se necesitarán esfuerzos constantes e irregulares para que las personas hagan lo correcto. En este caso, el problema es persuadir a alguien para que cambie los incentivos y luego asegurarse de que los cambios funcionen como se esperaba. Cómo convencer a la gerencia para que cambie los incentivos es el tema de un artículo separado. Con respecto a la implementación de los cambios, vi muchos errores "obvios" que se repiten en diferentes compañías.

Las pequeñas empresas lo encuentran fácil. Cuando trabajaba para una empresa de cien personas, había una jerarquía simple: participante individual (IC) -> jefe de equipo (TL) -> director general (CEO). Eso es todo El director no intervino particularmente, pero si dijo algo, se ejecutó implícitamente. Es importante que él supiera lo que cada empleado estaba haciendo y que en general pudiera regular la remuneración en tiempo real. Si hiciste algo bueno para la empresa, entonces podrías esperar un aumento. No nueve meses después, cuando surgió el siguiente ciclo de análisis de eficiencia del personal, sino casi de inmediato. No para todas las pequeñas empresas, esto funciona de manera efectiva, pero con el liderazgo adecuado, esto es posible. En grandes empresas, nada.

Una gran empresa tenía ese problema. La gerencia ordenó recompensar a los empleados por realizar un trabajo crítico pero discreto. Había demasiados empleados para distribuir inmediatamente las bonificaciones, pero el gerente podía analizar informes, tomar decisiones sobre controles puntuales y otorgar bonificaciones, de modo que con el tiempo los incentivos correctos se convertirían en parte de la cultura. En mi opinión personal, la compañía no ha alcanzado la paridad entre el aburrido trabajo de mantenimiento y los nuevos proyectos brillantes. Pero la gente al menos comenzó a trabajar en infraestructura y a corregir errores sin dañar mucho sus carreras.

En otra gran empresa, los empleados de base acuerdan que está mal recompensar más generosamente por crear nuevas funciones que por realizar un trabajo crítico. Cuando hablé con los gerentes, a menudo también estuvieron de acuerdo. Sin embargo, el aumento fue recibido principalmente por desarrolladores de cosas nuevas y brillantes. La gerencia ha intentado un cambio cultural y tecnológico. Básicamente, en forma de declaraciones inspiradoras de personas con publicaciones elegantes. Para cosas realmente importantes, tenía que mirar el video y pasar la prueba requerida con varias opciones de respuesta después de ver el video. El único resultado de esta campaña fue la opinión general de que la administración está muy lejos de la vida de los empleados comunes.

Es un poco gracioso que al final todo se reduce al problema de los incentivos. En la industria, pensamos mucho en cómo alentar a los consumidores a hacer lo que queremos. Pero dentro de la empresa, creamos un sistema de incentivos que nos empuja a las cosas equivocadas. Una especie de mezcla de teléfono malcriado y culto a la carga. En los viejos tiempos, Microsoft era un modelo a seguir: copiamos sus métodos y pedimos rompecabezas de entrevistas. Ahora Google se ha convertido en un modelo, y hacemos preguntas sobre algoritmos. Si nos fijamos en las empresas de moda que son más jóvenes que Google, la mayoría de ellas básicamente copian el sistema de publicación de Google, con algunos cambios menores. La buena noticia es que Google ha pensado bien en la mayoría de sus procesos, y las decisiones se toman en función de los datos. La mala noticia es que Google es, en muchos sentidos, una empresa única. Sus prácticas a menudo no funcionan para el resto, por lo que las personas simplemente practican el culto de carga. Y durante mucho tiempo después de que Google ya haya abandonado esta práctica .

Tal difusión también ocurre en soluciones técnicas. Stripe creó una cola de mensajes robusta sobre Mongo , por lo que también construiremos colas de mensajes robustas sobre Mongo ¹ .Culto de carga baja por la cadena ² .

El artículo médico tiene secciones especiales sobre cómo prevenir la normalización de la desviación.

• Presta atención a las señales débiles.
  
• Resista el deseo de ser excesivamente optimista.
  
• Enseñe a los empleados cómo llevar a cabo conversaciones emocionalmente incómodas.
  
• Los operadores del sistema deben sentirse seguros al expresar una opinión.
  
• Tenga en cuenta que la vigilancia y el monitoreo nunca se detienen.

Veamos cómo funciona el primer principio cuando un recién llegado llega a la empresa y comienza a gritar "WTF WTF WTF".

Cuando un vicepresidente expresa su opinión, la gente generalmente lo escucha. Esta es una señal fuerte. Si no, el vicepresidente todavía sabe cómo implementar su decisión. El principiante no sabe qué influencia sacar, con quién hablar. Producen señales débiles que son fáciles de ignorar. Para cuando ha estudiado el sistema lo suficiente como para emitir señales fuertes, ya se está aclimatando.

"Prestar atención a las señales débiles" suena bien, pero ¿cómo hacerlo? Las señales fuertes son pocas y raras, por lo que es fácil prestarles atención. Hay demasiadas señales débiles. ¿Cómo filtrar el ruido? ¿Y cómo hacer que todo el equipo u organización en realidad haga esto? No hay una respuesta simple a tales preguntas; se debe prestar considerable atención a esto.

Desafortunadamente, las compañías rara vez hacen esto. Las startups piensan mucho en el crecimiento. Aunque todos dicen que están muy preocupados por la cultura de la ingeniería, en la práctica esto no es así. Con algunas excepciones, las grandes empresas no son muy diferentes. En una de estas empresas, vi diapositivas de análisis competitivo, y son increíbles. Los detalles más pequeños se estudian en cientos de productos para garantizar que los usuarios recibirán una calidad perfecta en todos los aspectos, desde la implementación hasta la interacción con los productos de la competencia. Si incluso un parámetro es más complicado o confuso que el de cualquier competidor, la gente se molesta y trata de arreglar la situación. Esto es muy impresionante

Luego, la compañía acepta nuevos empleados, y cada tercio no tiene una cuenta en el sistema, un lugar en la oficina o una computadora, y esta condición puede persistir durante semanas o meses. Las diapositivas de análisis competitivo dicen que solo tiene una oportunidad para causar una primera impresión, y luego los empleados tienen la impresión de que la empresa no puede ocuparse de ellos. Y que interrumpir constantemente los procesos de trabajo es normal.

La compañía ni siquiera puede entender los conceptos básicos de la incorporación, sin mencionar cosas realmente complejas como la aculturación. Los motivos son claros. Los indicadores externos, como el crecimiento o la disminución de la audiencia, son medibles, a diferencia de la aculturación de los recién llegados, para que no ignoren las señales débiles. Pero esto no significa que este último sea menos importante. Muchos dicen que los nuevos lenguajes o métodos, como TDD o Agile, aumentan la productividad, pero tener una cultura de ingeniería sólida es un animador mucho más poderoso.

---

1. La gente parece pensar que estoy bromeando. Y trata de googlearlo mongodb message queue. Encontrará declaraciones como "los conjuntos de réplicas en MongoDB proporcionan muy bien redundancia y conmutación por error automática". Casi todas las empresas que conozco que lo han probado a gran escala, encontraron que el sistema no era óptimo, por decir lo menos. Pero no encontrarás nada al respecto. Solo artículos y presentaciones de compañías que han probado y fascinado por este DBMS. Esto es común a muchas tecnologías. Hay recomendaciones brillantes en público y en privado, la gente le informará sobre todos los problemas. Si ejecuta una consulta de búsqueda de este tipo hoy, encontrará un montón de artículos admiradores sobre lo genial que es crear una cola de mensajes sobre Mongo, encontrará este artículo y quizás varios artículos en el blog de Kyle Kingsbury, dependiendo de la frase de búsqueda específica.[]

Si se produce un mal funcionamiento grave, verá un informe con una descripción técnica. Pero nos gusta hacer este análisis para detectar accidentes como "El sitio estuvo inactivo durante 30 segundos", pero raramente analizamos situaciones como "Requiere 10 veces más esfuerzo que la alternativa, y esto es la muerte por mil cortes" o "Diseñamos mal el sistema, y ahora es muy difícil hacer cambios que deberían ser triviales "o" Nuestro competidor pudo hacer lo mismo, gastando un orden de magnitud menos esfuerzo ". A veces realizo un informe informal, haciendo preguntas a todas las personas involucradas, pero esto es más para mí, porque no estoy seguro de que la gente realmente quiera escuchar la verdad. Especialmente si varios empleados recibieron una promoción para el desarrollo de este proyecto. Parece que cuanto más dañado está el proyecto, más a menudo se lo adjudica. Cuanto más grande es el proyecto,cuanto más notable es y más bonificaciones, incluso si se pudiera hacer con mucho menos esfuerzo.

2. A menudo hice esta pregunta en compañías exitosas, y en otras, donde todo es malo. Donde todo es malo, todos tienen ideas. Pero donde todo está bien, nadie tiene una idea de por qué todo funciona, como en la pequeña empresa mencionada anteriormente con un director que no interfiere particularmente en los asuntos. Asombroso La gente literalmente dice que todo se parece a otra compañía donde trabajaban, excepto que todo estaba mal allí, pero aquí es mágicamente bueno. Por razones que no entienden. Pero esto no es magia. Este es un trabajo duro del que pocos son conscientes. Muchas veces vi irse al vicepresidente, y se vuelve desagradable para la empresa trabajar. Poco a poco se trata de personas: el vicepresidente se aseguró de que todos los empleados estuvieran contentos en sus lugares de trabajo. Es difícil de entender hasta que la situación va mal. Si no ves nada claramente incorrecto,o no prestas atención, o alguien hizo un gran esfuerzo para que todo saliera bien.[]