¿Cómo puedo prepararme para ser atropellado por un autobús?

Documentación.

Compromisos de código razonablemente frecuentes.

Documentación.

Documenta tus ideas, tus diseños y tu código. Cualquier problema que conozcas.

Documentación.

Documentar tus correcciones de errores explicando cuál era el problema y cómo lo has solucionado, y por qué.

¿Y he mencionado la documentación?

Si trabajas en un entorno en el que la política es laxa (de modo que los devs junior simplemente no pueden molestarse en enviar cambios en la documentación - las actualizaciones relevantes de la documentación deberían ser obligadas junto con cada fusión de ramas), falta la revisión por pares (de modo que los devs junior/senior se ven atrapados durante ratos de comprensible pereza), y/o la documentación se almacena por separado del código (de modo que puede perderse fácilmente), entonces también es importante considerar si el entorno puede ser cambiado de modo que estos problemas no se hagan así. De lo contrario, todo su esfuerzo en la redacción de la documentación puede ser en vano.

Dicho esto, no siempre llegaría a llamarlo una responsabilidad personal: en última instancia, si los equipos están mal gestionados y/u organizados, entonces no es su responsabilidad; en el caso de que pase a un nuevo trabajo, simplemente entregaría mi documentación completa y pensaría “bueno, si no puede usar y mantener esto correctamente, entonces es su culpa… ahora buena suerte”.

Esa línea de pensamiento no se sostiene en el caso de “atropellado por un autobús”, sin embargo, donde puedes estar en el proceso de instigar tales políticas pero aún no lo has hecho. Para este escenario, simplemente sugiero que anime a la dirección (y a sus superiores) a que empiecen a tomarse en serio estas cosas lo antes posible.

No hagas NADA de manera diferente. Trabaja como si NO fueras a ser “atropellado por un autobús” mañana.

El problema del “atropello por un autobús” es un problema de organización y no algo que deba ser abordado explícitamente en tus propios objetivos de trabajo.

Tus compañeros de trabajo y la dirección deberían pensar en ello, pero creo que es demasiado esperar que los colaboradores individuales trabajen como si literalmente se fueran mañana. Si la dirección es ajena a los problemas potenciales aquí, significa que están totalmente fuera de contacto o tal vez no eres tan indispensable como pensabas.

En el mejor de los casos, si eres generoso, tal vez quieras recordar a las personas clave y a los clientes potenciales que deben tener un respaldo en caso de emergencia. Pero en una era en la que las corporaciones tiran las carreras “bajo el autobús” a capricho por el bien de los beneficios a corto plazo, ¿cuánto debería importarte realmente?

Las prácticas de ingeniería diligente resuelven muchos de los problemas del dilema del “golpe de un autobús”. Ir más allá de eso hasta el punto de estar listo para la desaparición inmediata y permanente creará muchos gastos generales para el contribuyente individual. Parece que el entorno descrito por la OP podría beneficiarse simplemente con mejores prácticas y personal, no hay necesidad de que trabaje como si pudiera vaporizarse en cualquier momento.

Si trabajas como contratista, diría que esto es 100% culpa de tu empleador. Dígales que el cumplimiento de las metas que le han fijado significa que no se están haciendo otras cosas que usted cree que deberían considerarse metas; pregúnteles si quieren ajustar sus metas. Es muy posible que le digan que continúe tal como está, ya que su tiempo es caro y quieren la mejor relación calidad-precio a corto plazo.

Si trabaja como empleado, puede tener más margen para planificar la sucesión (o posiblemente se espera que ya lo esté haciendo). Aún así, plantee el tema al jefe o al director de su equipo, ya que ellos necesitan conocer el problema y saber cómo está usted, y creen que debería estar, dedicando su tiempo.

Algunas cosas a eso ayudarían en la planificación de la sucesión:

• Los procesos cotidianos deberían estar documentados hasta cierto punto, pero es probable que otras personas de su equipo sigan los mismos procesos y podrían enseñárselos a un recién llegado. Si no todos usan procesos similares, ese es un problema actual que debería ser resuelto; reúnanse, debatan cuál es el mejor camino, lleguen a algún estándar (consensuado o forzado desde arriba), y usen el estándar, felicitaciones ese estándar puede ir en su documentación para el recién llegado.
• Las cosas importantes que se comunican a través del correo electrónico, reuniones o conversaciones casuales necesitan convertirse en un recurso compartido, cualquier cosa desde una carpeta de documentos en un disco compartido hasta un wiki. Existe esta extraña creencia (al menos en el lugar donde he trabajado) de que si se envía algo por correo electrónico a todos los miembros de un equipo, entonces ese equipo sabrá para siempre la cosa; esto no tiene en cuenta que la composición del equipo cambia y que cualquier formación (si es que llega a suceder) nunca transferirá todo el conocimiento, sólo un subconjunto de los conocimientos utilizados con frecuencia.
• (Posiblemente específico del software) Documentar claramente procesos o decisiones de diseño contrarios a la intuición, es importante identificar que se reconoce que el proceso es contrario a la intuición y por qué es así, independientemente. Por ejemplo, si su cliente le pidió que hiciera algo que parece “incorrecto” (“No soy un experto en dominios, pero ¿está seguro de que quiere hacer eso?”), y usted le explicó por qué pensaba que era incorrecto y ellos confirmaron que era lo que querían (aún mejor si explicaron el porqué), entonces las razones por las que pensaba que era incorrecto y la explicación de por qué era correcto deben ser documentadas. Que el software funciona según las especificaciones no va a ser suficiente para un reemplazo, ellos tendrán la misma pregunta que usted.
• Para cualquier problema que encuentre y que requiera mucho tiempo/investigación para resolverlo, documente el problema, los síntomas, el camino acortado a la solución (es decir: saber lo que sabe ahora, cuál fue el camino más rápido para identificar los síntomas a una solución), y la solución. Los síntomas son realmente importantes para su reemplazo, porque los golpearán antes de que comprendan plenamente el problema.
• El punto anterior es aún más importante en lo que respecta a los sistemas heredados, como las bibliotecas o las plataformas, donde se están lanzando nuevas versiones pero no se utilizan en su producto. Los problemas que encuentre en su versión (o incluso peor, en las interacciones entre varios sistemas heredados) pueden ser resueltos en versiones futuras y así la existencia misma del fallo se desvanecerá del conocimiento público, hasta que sea casi imposible encontrar información sobre el mismo.

Las vacaciones son un buen “entrenamiento” para prepararse para cosas así. También ayuda a medir lo bien que estás preparado. Vuelve al trabajo después de 2 o 3 semanas y cuenta los días y el esfuerzo invertido en la limpieza de tu “atraso” - esto podría ser una aproximación decente al “escenario de atropello en un autobús”.

Esto también es una herramienta útil si quieres mejorar. Analiza los asuntos pendientes que tienes que resolver y pregúntate qué se puede hacer para que esto lo haga otra persona. En uno de los trabajos anteriores, esto me ayudó a bajar los esfuerzos de “vacaciones atrasadas” de unas tres semanas a dos días en menos de un año.

• Oh Dios, parece que soy el único que tiene esta información, necesito documentarla para ponerla a disposición de todo el equipo.
  Maldición nadie puede arreglar este error excepto yo, necesito encontrar y entrenar a un tipo de respaldo…

Lo que vale la pena tener en cuenta es que generalmente esto se considera una responsabilidad de su administración, así que cualquier cosa que haga más allá de lo requerido es a voluntad. Pregúntese cuánto quieren luchar contra factor de bus y proceder en consecuencia.

• *

Yo por ejemplo quiero ser reemplazable…

• …para que otro tipo que revise mis cosas desde repositorio no tenga que volver a mí tratando de entender código no mantenible
• … …para que ese otro tipo que mira mis registros en issue tracker no necesite mi ayuda para figurar lo que estaba pensando mientras trabajaba en ello
• …para que ese otro tipo que lee mis páginas wiki no necesite que le explique cosas documentadas allí
• . …para que yo pueda disfrutar mirando cómo las cosas que hice crecen y florecen, viviendo su propia vida

…para que pueda concentrarme en hacer cosas nuevas sin distraerme por las preocupaciones sobre lo que se deja atrás.

Pregúntele a su equipo. Pregúntale a tu gerente. Preséntales el asunto exactamente como lo has hecho con nosotros.

Dales opciones. Documentación para un futuro desarrollador. Documentación para ellos. Pagar la deuda técnica. Cualquier cosa que se te ocurra. Darles estimaciones de tiempo. Dales la oportunidad de elegir. Déjalos que lo comparen con tu trabajo diario normal.

Hey, podrían incluso decidir que es un riesgo que vale la pena tomar. Pero, realmente, depende de ellos decidir.

Y, si han decidido arriesgarse, entonces tu espíritu inmortal debería dejar de sentirse culpable por ello.

La lección más difícil que aprendí fue no responder a esas preguntas. Pero hacer la pregunta correcta para llevarlos, sin sospechar, a encontrar la respuesta por sí mismos.

¡Una respuesta dada es diferente a una lección aprendida!

Explicación

Hay básicamente dos escenarios diferentes que crean el único punto de fracaso que la OP está abordando.

Negocio

Esto puede ser una decisión consciente o el resultado de una mala planificación, proceso o crecimiento del negocio. También puede ser el resultado de la inacción o el fracaso en reconocer y abordar la creciente brecha de conocimiento.

Independientemente del cómo, el negocio crea la situación en la que tiene una superdependencia de un solo individuo o un pequeño grupo de individuos que forman el núcleo de su base de conocimiento. Muchas empresas abordan esto mediante el uso de programas de tutoría, entrenamiento cruzado, y el intercambio de conocimientos tanto formales como informales.

Desde mi experiencia los más exitosos en esto también fomentan un enfoque de enseñanza. Con esto quiero decir que rara vez se da una “respuesta” a una pregunta, sino más bien una discusión y preguntas puntuales del experto o expertos que lo llevan por un camino de aprendizaje y expansión de su conocimiento sobre el producto, el proceso, la tecnología en juego.

Esto también ofrece una nueva visión y perspectiva al experto en que la discusión. La enseñanza puede ir de hecho en ambos sentidos.

Empleado

En general tienes dos tipos diferentes de empleados que terminan en esta posición. Lo que yo llamo ‘El Ir a’ y ‘El Protector’.

‘El Ir a_’ es ese empleado que la mayoría de los gerentes aman. Es el que puedes asignar cualquier tarea o proyecto y no tener que preocuparte por ello. Estas son las personas que se hacen un hueco en la empresa y se convierten en la persona a la que hay que acudir y, más probablemente, en la que tiene las respuestas.

‘El Protector’ es ese empleado que ha tomado la decisión de proteger su territorio. Sienten que al proteger sus conocimientos están asegurando su posición, importancia y futuro en la compañía.

Ambos crean inadvertidamente puntos únicos de fracaso. y el “Protector” al no compartir ninguna o todas las informaciones.

Así que en pocas palabras toda la documentación del mundo no resolverá el problema subyacente de un solo punto de fracaso. Sí, es importante y debería ser parte de cada PCN y plan de preparación para desastres. Pero la documentación no es realmente compartir el conocimiento en el sentido de que alguien debería ser capaz de intervenir y realizar las tareas de su trabajo sin tener que vadear un documento de 200 páginas antes.

No responda a la pregunta; déles poder para que puedan responder por sí mismos.

Esto es lo que hacemos donde trabajo:

a) Usamos un wiki para la documentación. No archivos de Microsoft Word, o archivos de texto. Un wiki que es buscable, con seguimiento de cambios completos, etc. (Recomendaría Confluence , pero Confluence v4 es un perro tal que sugiero que busques en otra parte)

• Cualquier proceso repetitivo o delegable debe ser documentado.
• Las listas de verificación de “así es como lo hacemos \N” deben ser escritas
• Las listas de verificación son muy importantes para construir equipos, ya que permiten que los procesos sean hechos por cualquiera que pueda seguir la lista…

b) Control de versiones, obviamente

c) Sistema de seguimiento de casos/temas, obviamente

d) Comentario de su trabajo. Esto es lo más matizado, y es muy difícil de enseñar, pero como contratista/independiente, puede ser capaz de manejar esto: Los comentarios deben explicar su proceso de pensamiento y el por qué de lo que está haciendo. Los enlaces a la documentación, el desbordamiento de la pila, etc. son apropiados. Los párrafos y páginas de comentarios son apropiados. Explicar las cosas que intentó y NO hizo es apropiado. Uno de los mayores problemas del código es que se pierde el pensamiento y el sudor que se dedica a hacer que algo funcione de una manera (en lugar de una manera diferente). Hay un libro, algo así como “código hermoso” o algo así, que tiene un trozo en los bloques de comentarios en una unidad en uno de los grandes sistemas abiertos VCS Subversión o Git , creo). Es hermoso porque cuenta la historia. Esto es lo que hace este código. Así es como funciona. Así es como está estructurado. (Confieso que este bloque, según recuerdo, puede no ser muy grande en la pregunta del “por qué”.)

Un corolario de esto es: ¿Cuánta gente regresa y edita el código sólo para añadir comentarios? Todos deberíamos… muchos. Pero en la práctica casi nadie lo hace.

Netflix tiene un sistema que ellos llaman CaosMonkey . Esencialmente ‘rompe’ o emula la ruptura de ciertos sistemas al azar.

Los empleados pueden ser pensados como sistemas y una manera de emular la ruptura de un empleado es darle a ese empleado tiempo libre sin previo aviso y sin programar. El Mono del Caos te dijo que fueras a ver una película sin avisar a tus compañeros de trabajo. A corto plazo, el efecto en ellos es el mismo que si hubieras sido atropellado por un autobús.

Esto prueba la robustez de sus sistemas y les permite detectar nuevas fallas en sus sistemas que de otra manera podrían haber pasado desapercibidas.

Esto podría ayudar en la transferencia de conocimientos de una manera redonda ya que un sistema más robusto es probable que se rompa menos y tendrá menos errores grandes que necesitan atención permitiendo a las personas en cuestión ser capaces de centrarse más en cómo funciona el sistema y por qué hace lo que hace en lugar de sólo perseguir molestos problemas que consumen un valioso tiempo de intercambio de conocimientos.

Desde que escribí esta respuesta, me he dado cuenta de https://www.fdic.gov/news/news/financial/1995/fil9552.html . Básicamente, la FDIC recomienda que los bancos impongan a los empleados claves del banco, vacaciones obligatorias y pagadas de por lo menos 2 semanas consecutivas. El bienestar de los empleados es una consideración secundaria. La consideración primaria es que esto forzará a los bancos a nombrar a alguien más para que se encargue de las responsabilidades del empleado que se va. Si el empleado que se va está malversando el esquema se desmoronará bajo la supervisión del reemplazo. Esto también significa que el banco no será vulnerable a un ataque de autobús.

Yo empezaría con

1. Estandarización

2. Revisiones regulares y obligatorias de códigos/proyectos

3. Espíritu de equipo

4. Obviamente Documento. Es una vieja canción. No la volveré a cantar.

La planificación de esto es parte de un Plan de Continuidad de Negocios mientras que se trata de la planificación para desastres más grandes que sólo ser atropellado por un autobús, pero el proceso pone en su lugar las piezas para recuperarse de pequeños incidentes como un jugador clave que está siendo escalfado, a problemas más grandes como un desastre que derriba los edificios, y las personas que los atienden.

Wiki-How tiene un artículo sobre cómo crear un BCP y aunque no recomendaría usar este método para tu negocio, proporciona una buena visión de los procesos y el pensamiento necesarios para crear uno. Generalmente los PCN se realizan en enfoques por fases, manejando los mayores riesgos, y preparándose para escenarios más probables primero y abordando preocupaciones de menor riesgo después. Pero cada empresa generalmente construye su PCN de acuerdo a sus propias necesidades, por lo que el proceso exacto varía.

El proceso generalmente implica:

• Identificar las áreas de riesgo
• Documentar los procesos involucrados
• Determinar las respuestas apropiadas a varios escenarios
• Promulgar planes para tratar con los escenarios

Nuestras reglas cotidianas prohíben que la gente se lleve el conocimiento a la tumba:

• Si alguien escribe un guión/rutina, entonces alguien más tiene que ser el primero en usar eso en la producción.
• Si alguien despliega nuevos sistemas, entonces nadie los usará o los apoyará hasta que pueda buscar todas las credenciales de acceso necesarias por sí mismo, solo, por la noche, sin preguntarle a alguien más.

• También hay “configuración como código” y pruebas automatizadas para el software. Permite a su sucesor hacer ingeniería inversa de su trabajo.

• En efecto, “las cosas que no están aún listadas/pruebas no existen para nosotros”. Sólo las cosas que están listadas son confiables.

Lo llamamos “ conocimiento de arcanos” (sólo almacenado en la cabeza de alguien), y todo el mundo se niega a actuar en él.

Obviamente eso no funciona entre temas técnicos y no técnicos. Pero tampoco esperamos que los técnicos puedan hacerse cargo de los cálculos financieros del departamento de contabilidad. Así que incluso nuestro departamento de contabilidad podría llevarse “el conocimiento a la tumba”, si sólo un contable hiciera esos cálculos.

Porque hay un límite. Si el equipo es demasiado pequeño, siempre habrá alguien que será atropellado por un autobús.

Los puntos que se indican a continuación deben figurar en la descripción de su trabajo que se le entregó y que establecieron los propietarios de la empresa. Es su responsabilidad tener esto en su lugar. Sin embargo, usted puede ser el único que tenga el conocimiento para informarles de que esto es necesario.

• Trabaje dentro de los estándares bien establecidos para su campo u organización.
• Documente lo que hace.
• Documente con gran detalle si se desvía de los estándares bien establecidos y por qué lo hizo
• Documente cómo documentar para su organización.
• Si usted está en la cima de una cadena de administración de sistemas y tiene las cuentas de root/super usuario; cree una cuenta que tenga la mayor autorización de seguridad posible. Genere una contraseña larga y aleatoria para ella. Imprímalo en papel. Fírmela. Séllala en un sobre y dásela a la junta directiva, no al CEO. Porque un CEO puede separarse de la compañía en malos términos y aún así tener esa contraseña. Diles que la guarden de forma segura, fuera de la empresa y que la usen. (Puede darte el estatus de superusuario en la red en caso de que estés ausente o por otras razones que puedan aplicarse).