Normalización de la desviación. Cómo las prácticas incorrectas se están convirtiendo en la norma en nuestra industria

¬Ņ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 1 .Culto de carga baja por la cadena 2 .

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.[]

Source: https://habr.com/ru/post/486120/


All Articles