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

Como miembro de equipos pequeños, tenía una responsabilidad importante. Ya sea impulsando el progreso organizando reuniones o manteniendo/creando/comprendiendo un gran porcentaje de información técnica específica, a menudo tenía tales responsabilidades. A veces yo era la única persona que trabajaba en los aspectos técnicos del proyecto.

Esto sucedió en una variedad de tipos de trabajo. A veces, programaba proyectos como un codificador único con varias personas no técnicas, a veces analizaba o recopilaba información técnica y, a veces, preparaba datos técnicos y presentaciones. A veces yo era el líder del proyecto y efectivamente el intermediario entre todos los involucrados.

Fui realmente bueno en mis responsabilidades al hacer esto y seguí asignándomelas. Desarrollé un conjunto de habilidades de nicho y disfrutaba el trabajo. La vida era genial.

Luego... me atropelló un autobús . ¡Qué tragedia! Era demasiado pronto para ser sacado de este mundo...

Más tarde, mientras flotaba por los pasillos de mi antiguo lugar de trabajo, descubrí que no había hecho un buen trabajo al preparar a mi equipo para mi prematura partida.

Nadie más en el equipo estaba familiarizado con las herramientas que estaba usando como yo. Nadie más entendió ni siquiera a un nivel superficial la información técnica. Quería comunicarme y responder esas preguntas, ¡preguntas tan simples! Pero Ay. Mi espíritu incorpóreo estaba condenado a flotar sin voz.

Me quedé pensando... ¿qué pude haber hecho? ¿Qué me perdí? ¿Cómo podría haber cambiado las cosas para estas pobres almas?

En serio, lo anterior es un gran problema para trabajar en ingeniería. Cuando trabajas en equipos multifuncionales, es difícil mantener informado al resto sobre los detalles de lo que estás haciendo. Es fácil ser una "caja negra" de magia para el equipo. Peor aún, a menudo desarrolla/posee conjuntos de habilidades específicas que no se documentan fácilmente (y pueden implicar horas y horas de capacitación o sistemas de aprendizaje).

Mi pregunta es:

  • ¿Cómo debo funcionar en un equipo como el único colaborador técnico para evitar problemas derivados de mi partida repentina (no necesariamente solo como desarrollador de software)?

Nota: Debo agregar que esto no implica nada sobre mis planes futuros... sino una forma de hacer que una pregunta normal sea potencialmente más entretenida. Es posible que lo atropelle un autobús, tenga una emergencia familiar repentina o, de manera más realista, acepte un nuevo trabajo/ascenso, lo llamen para un proyecto diferente y más urgente, tome una semana de vacaciones y no trabaje (concepto loco), etc.

Pregunta relacionada sobre trabajo independiente: ¿Cómo podemos prepararnos para “ser atropellado por un autobús”?
Imagínese ser un fantasma y pasar su tiempo en el trabajo, comprobando cómo todos gestionan las reuniones ahora.
Un punto importante a recordar es que eventualmente todos los empleados serán atropellados por el autobús . Todos los empleados renunciarán, se jubilarán o morirán. Las corporaciones lo saben: sacan pólizas de seguro de vida para cada empleado, para permitir una recuperación más fácil. Una empresa inteligente asumirá que todos los empleados se irán en algún momento y planificará adecuadamente (documentación, capacitación cruzada, tutoría, etc.)
"¿Cómo puedo prepararme para ser atropellado por un autobús?" ... ni una sola mención de un casco . A nadie más aquí le importa tu seguridad. ¡¡¡Solo les importa seguir con sus vidas!!! Si sospecha que lo atropellará un autobús, ¡use un casco!
La versión optimista de este problema es "¿Cómo puedo prepararme para ganar la lotería?".
@ElijahLynn Por lo general, tiene un retraso legal mínimo que puede usarse para entregar información y/o buscar un reemplazo, después de entregar su renuncia. No es tan repentino como el choque del autobús ;)
@Paul D. Waite Deben haberles encantado mucho el trabajo. :)

Respuestas (13)

Si está trabajando como contratista, diría que esto es 100% de su empleador. Dígales que lograr las metas que se han fijado para usted 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 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 está trabajando como empleado, es posible que tenga más margen de maniobra para planificar la sucesión (o posiblemente exista la expectativa de que ya lo esté haciendo). Aún así, hable con el líder o gerente de su equipo, ya que necesitan saber sobre el problema y cómo está, y cree que debería estar, gastando su tiempo.

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

  • Los procesos cotidianos deben documentarse hasta cierto punto, pero es probable que otras personas de su equipo sigan los mismos procesos y puedan enseñárselos a un recién llegado. Si no todos usan procesos similares, ese es un problema actual que debe resolverse; reúnanse, debatan cuál es la mejor manera, 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 por correo electrónico, reuniones o conversaciones informales deben convertirse en un recurso compartido, desde una carpeta de documentos en un disco compartido hasta un wiki. Existe esta extraña creencia (al menos donde he trabajado) de que si algo se envía por correo electrónico a todos los miembros de un equipo, entonces ese equipo lo sabrá para siempre; esto no tiene en cuenta que la composición del equipo cambia y que cualquier capacitación (si es que sucede) nunca transferirá todo el conocimiento, solo un subconjunto del conocimiento de uso frecuente.
  • (Posiblemente específico del software) Documente claramente los procesos contrarios a la intuición o las decisiones de diseño; es importante identificar que el proceso se reconoce como contrario a la intuición y por qué lo es, independientemente. Por ejemplo, si su cliente le pide que haga algo que parece "incorrecto" ("No soy un experto en el dominio, pero ¿está seguro de que quiere hacer eso?"), y le explica por qué pensó que era incorrecto y ellos confirmaron que era lo que querían (incluso mejor si explicaron por qué), luego se deben documentar las razones por las que pensó que era incorrecto y la explicación de por qué era correcto. Que el software funcione según las especificaciones no será suficiente para un reemplazo, 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 abreviado hacia la solución (es decir, sabiendo lo que sabe ahora, cuál fue el camino más rápido desde la identificación de los síntomas hasta la solución). ), y la solución. Los síntomas son realmente importantes para su reemplazo, porque los atacarán antes de que comprendan completamente el problema.
  • El punto anterior es aún más importante con respecto a los sistemas heredados, como bibliotecas o plataformas, donde se lanzan nuevas versiones pero no se usan en su producto. Los problemas que encuentre en su versión (o, peor aún, en las interacciones entre varios sistemas heredados) pueden resolverse en versiones futuras y, por lo tanto, la existencia misma de la falla se desvanecerá del conocimiento público, hasta que sea casi imposible encontrar información al respecto.
Gran respuesta. Siento agregar que, para evitar tales situaciones, se me recomendó agregar una condición muy, muy clara de "consignación final" a los contratos independientes: "se proporcionará el código y se proporcionará una máquina virtual con la cadena de herramientas utilizada para compilar la versión final . El código se aceptará tal cual después de su revisión y, de todos modos, a más tardar el xxx/xx/xx, la compatibilidad del código debe ser solo para OS xxxx, versión xxxx. No se proporcionarán más mantenimiento ni parches después de xxxx. Todo UX/ funcional no se cambiará después de xxxx/xx/xx"
No estoy seguro de estar de acuerdo con "Si no todos usan procesos similares, ese es un problema actual" la conformidad por el bien de la conformidad suele ser una señal de alerta para mí, se supone que todos funcionan mejor de la misma manera. Por ejemplo, todos usamos el control de versiones de git, sin embargo, no hay una receta sobre qué cliente usa para acceder a él por diseño. A algunas personas les gusta la línea de comandos, a otras les gusta un cliente visual

Documentación.

Confirmaciones de código razonablemente frecuentes.

Documentación.

Documente sus ideas, sus diseños y su código. Cualquier error del que estés al tanto.

Documentación.

Documente sus correcciones de errores explicando cuál fue el problema y cómo lo solucionó y por qué.

¿Y mencioné la documentación?

Si trabaja en un entorno donde la política es laxa (por lo que los desarrolladores junior simplemente no pueden molestarse en enviar cambios en la documentación; las actualizaciones de documentación relevantes deben ser obligatorias junto con cada fusión de sucursales), falta la revisión por pares (por lo que los desarrolladores junior/senior quedan atrapados durante las avalanchas de pereza comprensible), y/o la documentación se almacena por separado del código (por lo que puede perderse fácilmente), entonces también es importante considerar si se puede cambiar el entorno para que estos problemas no se hagan así. De lo contrario, todo su esfuerzo por escribir la documentación puede ser en vano.

Dicho esto, no siempre iría tan lejos como para llamarlo una responsabilidad personal: en última instancia, si los equipos están mal administrados y/u organizados, entonces esa no es tu responsabilidad; en el caso de que cambies a un nuevo trabajo, simplemente entregaría mi documentación completa y pensaría "bueno, si no puedes usarla y mantenerla correctamente, entonces es tu culpa... ahora buena suerte".

Sin embargo, esa línea de pensamiento realmente no se sostiene en el caso de "atropellado por un autobús", donde puede estar en el proceso de instigar tales políticas pero aún no lo ha hecho. Para este escenario, simplemente sugeriría que aliente a la gerencia (y a sus desarrolladores senior) a comenzar a tomarse esto en serio lo antes posible .

Desde un punto de vista técnico, esto es lo mejor que puede hacer una sola persona. Pero iría y al menos intentaría arreglarlo también a nivel organizativo.
Una cosa que también es importante recordar es que comentar su código no es una forma suficiente de documentación. Es una necesidad absoluta para cualquier sistema mantenible, pero no le dice a QA cómo probarlo, y no le dice a soporte cómo usarlo. Debe proporcionar documentación de calidad tanto desde el punto de vista técnico como desde el punto de vista del usuario final.
Esto es muy cierto cuando se trabaja como desarrollador de software en un proyecto a mayor escala, pero ¿cómo se aplica esto a situaciones de ingeniería como la única persona técnica en un proyecto?
@enderland: Precisamente de la misma manera. Cuando tenga documentación para dejar a la siguiente persona, esta puede retomar en gran medida donde usted la dejó. El único problema entonces se vuelve uno de experiencia y habilidad, para lo cual la única solución es que el chico nuevo se capacite y pase tiempo con el proyecto, pero no le faltará material de referencia y no debería haber "vacíos en el conocimiento" si usted He documentado su trabajo (incluida la documentación de prueba adecuada, como identifica correctamente Polynomial). Se explica por sí mismo, incluso, en mi opinión.
@dema80: Lo que estoy haciendo en nuestro lugar en este momento para solucionar esto a nivel organizacional, es implementar procedimientos que hacen que sea fácil, interesante y deseable escribir documentación . Y no estoy bromeando.
Voy a agregar diagramas. Necesita diagramas de la arquitectura (ERD, diagrama de flujo, diagrama de casos de uso, etc.). Tenga diagramas separados para las partes del sistema que son más complejas y necesitan ser explicadas en detalle y que no pueden explicarse bien solo con palabras. Una imagen dice más que mil palabras literalmente. Tampoco hay nada peor que retomar un proyecto escrito por otro desarrollador que ha dejado la organización y no tener nada con qué continuar. Sin comentarios de código, sin diagramas, sin explicaciones sobre por qué se hicieron las cosas y múltiples capas de código. Es básicamente como andar a tientas en la oscuridad.
@zuallauz: Maldita sea.
La gente piensa que la documentación ayuda, pero en realidad duele, a menos que la escribas justo antes de irte. ¿Por qué? porque nadie lo mantiene actualizado. La documentación que es antigua siempre es sospechosa; debe inspeccionar los sistemas/software reales para asegurarse de que realmente se comporte de esa manera de todos modos. Mi consejo es, sí, escriba la documentación que se necesita a medida que avanza y que le ayudará en sus tareas actuales, pero no espere que esos documentos sirvan como algo más que un indicador de dónde buscar realmente para averiguar el verdadero historia.
@tvanfosson: Es por eso que mantiene la documentación en el control de versiones y falla la revisión del código cuando la documentación no está actualizada. Y, sí, cuando miras la documentación, por supuesto, verificas la fecha de "última modificación" y te aseguras de que todo coincida, en lugar de simplemente tomarlo ciegamente como la palabra de Dios. De todos modos, la documentación de diseño y arquitectura, siendo la más importante, no se vuelve obsoleta hasta que refactorizas todo.
Dos cosas sobre la documentación: 1) Otras personas tienen que saber sobre ella (te sorprendería saber cuánta documentación nunca se usa después de que el autor se va) y 2) tiene que ser fácil de mantener actualizada (usualmente debe ser un wiki, y muy corto, solo lo suficiente para decirle dónde buscar en el código o en los servidores para encontrar las respuestas reales).
@MGOwen Es por eso que no contrata a personas que no son lo suficientemente inteligentes como para buscar documentación para los sistemas que usan.
En mi experiencia, esto es completamente incorrecto. Nadie mantiene la documentación al día. Se vuelve obsoleto o se pierde, o ambas cosas. Esta no es realmente la forma de proteger a su organización de su partida o desaparición. Esta habría sido una mejor respuesta si no hubiera mencionado la documentación.
@David: Mantengo toda mi documentación actualizada porque soy un desarrollador de software decente. Tu también deberías. No entiendo por qué todo el mundo sigue argumentando en contra de la documentación usando la pereza como excusa. Si yo puedo manipular a la gerencia para encontrar tiempo para mantener completamente actualizadas mis 1000 páginas de documentación técnica para varios proyectos, entonces estoy seguro de que usted también puede hacerlo. También puede considerar revisar sus políticas de registro de código: no se debe aceptar ningún registro a menos que sus pruebas y la fuente de documentación se actualicen en la misma revisión. (¡¿Cómo se "pierde" la documentación?!)
Claro, TÚ puedes hacer esto. Pero, ¿no se trata de lo que sucede después de dejar la organización? Unas cuantas veces me han vuelto a contratar en una organización que dejé antes; solo para descubrir que alguien ha reorganizado los recursos compartidos de red y se olvidó de copiar toda la documentación que escribí antes de irme; o alguien ha cambiado el software y no ha actualizado la documentación; o alguien ha enviado software sin seguir todos los procedimientos de verificación que existían antes de que me fuera. Puedes ser tan bueno como quieras; pero las organizaciones siempre emplean a OTRAS personas también.
Por lo tanto, la respuesta correcta a la pregunta no es escribir mucha documentación, sino asegurarse de que todos estos procedimientos (mantener la documentación en control de versiones con el código, tener ciertos elementos en la lista de verificación de revisión por pares, no registrar cosas sin la documentación correspondiente etc.) son entendidos por su organización y seguidos sin falta. Estas son cosas mucho más valiosas que hacer que escribir grandes cantidades de documentación. Parte de su función como contratista de TI (o incluso como empleado) que probablemente se vaya algún día es compartir el beneficio de su sabiduría y experiencia con su...
... organización y asegurarse de que "hacen las cosas bien".
@DavidWallace: Sí, en realidad creo que es una buena observación. Lo doy por sentado, pero si hay muchos lugares que hacen esto mal, entonces parte de los pasos deberían ser garantizar que las políticas se implementen y se cumplan , de lo contrario, escribir la documentación sería una pérdida de tiempo. Agregaré esto a mi respuesta; Gracias.

No hagas NADA diferente. Trabaje como si NO fuera a ser "atropellado por un autobús" mañana.

El problema del "atropello por autobús" es un problema organizativo y no algo que deba abordarse explícitamente en sus propios objetivos de trabajo.

Sus compañeros de trabajo y la gerencia deberían estar pensando en ello, pero creo que es demasiado esperar que los colaboradores individuales trabajen como si literalmente se fueran mañana. Si la gerencia no se da cuenta de 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 es generoso, es posible que desee recordar a las personas clave y a los clientes potenciales que tengan respaldo en caso de emergencia. Pero en una era en la que las corporaciones arrojan carreras "debajo del autobús" por capricho en aras de las ganancias a corto plazo, ¿cuánto debería importarle realmente?

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

Si usted fuera realmente indispensable, la gerencia contrataría a alguien para que caminara a su lado y tomara el golpe por usted. La única forma de resolver totalmente el problema de un autobús es hacerse innecesario y eso no es lo mejor para usted.
@emory: Innecesario no es necesariamente no deseado. Puede colocarse en una posición en la que no sea necesario, pero es la mejor opción y ya está haciendo el trabajo, lo cual es MUY de su interés. Aquellos que son absolutamente indispensables terminan sin poder tomarse vacaciones, nunca tienen un fin de semana libre, trabajan toda la noche y, si tienen algo de orgullo, terminan sin poder irse a buscar un trabajo mejor.
tienes razón: es un problema de organización. Pero creo que tu deber es al menos tratar de resolverlo a nivel técnico, como sugirió Lightness Races in Orbit (!)
@pdr tiene razón, mantenerse indispensable en su puesto actual es una excelente manera de evitar que lo asciendan
@ChrisFletcher El presidente Obama no es prescindible ni promocionable. Si el vicepresidente Biden fuera realmente indispensable en su cargo actual, entonces sí, no podría ser ascendido a presidente. Pero si el vicepresidente Biden era indispensable y el presidente Obama prescindible, ¿no significaría eso que la vicepresidencia era más importante que la presidencia? Biden ya habría alcanzado la cima de facto del organigrama y el ascenso a presidente sería, de hecho, una degradación.
Lleve la discusión a The Workplace Chat
@Chad, listo. Aunque no estoy de acuerdo en que haya un tono egoísta. Si realmente quieres ver egoísta, busca en Google "seguro de campesino muerto".
@emory ese es un mal ejemplo, ambos son roles no técnicos. La naturaleza de ser promovido en ingeniería generalmente significa volverse menos técnico. Si el OP permanece como la fuente de todo el conocimiento técnico en lugar de catalogarlo y compartirlo, abre la puerta a que se reclute a personas para roles no técnicos por encima de él.
@Angelo: el egoísmo puede haber sido el término incorrecto. Pero la respuesta parecía egocéntrica. Creo que la adición redujo eso.
@dema80: ¿Te gusta mi nombre? :)
No estoy de acuerdo con esta respuesta categóricamente. Si te das cuenta de que, si te atropellara un camión mañana, tu equipo no podría funcionar, entonces el "número de camión" de tu equipo, por definición, es 1: tú. Este es un mal estado de cosas e inevitablemente lo afectará, porque en cualquier situación que no sea ser atropellado por un camión en el que no esté personalmente disponible en la oficina, su equipo aún intentará comunicarse con usted por cualquier medio. pueden, incluso cuando está en el hospital, de vacaciones o trabajando en su nuevo trabajo.
@KeithS, Estar en el hospital o de vacaciones son condiciones temporales. Todo lo que estoy tratando de decir es que uno puede ser completamente diligente y responsable sin tener que trabajar como si literalmente se fueran a ir para siempre sin previo aviso. La historia es, por supuesto, diferente si la vida humana o la supervivencia literal de la empresa están en juego, pero ese rara vez es el caso y si se trata de una organización que vale la pena, se preparará para esa contingencia con cuidado.
Hay una excepción: inicios de sesión y contraseñas. Haga que una aplicación administre sus contraseñas [esa es una buena práctica de seguridad ya que a) su contraseña debe ser lo suficientemente compleja yb) generalmente no debe reutilizar contraseñas]. Esa aplicación tiene una contraseña maestra. Asegúrese de que alguien conozca esta aplicación y tenga acceso a la contraseña maestra en caso de que la colisión del autobús sea fatal.
Si solo eres un dron, esta respuesta es aceptable. Si, como en muchas posiciones tecnológicas hoy en día, el equipo y las personas están facultadas para asumir la responsabilidad general de que el equipo "haga lo correcto", entonces es una preocupación legítima para un colaborador individual. "Ese es un problema de la gerencia" es una respuesta para un trabajador de fábrica, no para un profesional de la tecnología.
@mxyzplk sí y no. Hay cosas que se espera que haga un profesional en un puesto técnico. Documente los procesos en cualquier método que prefiera la empresa, documente los puntos de preocupación de la misma manera, etc. Esto cubre las transacciones diarias predecibles, pero muchas tareas técnicas requieren capacitación que no se puede realizar razonablemente en documentación. Aquí es donde la responsabilidad pasa a la gerencia. ELLOS deben asegurarse de que existan prácticas de documentación establecidas, deben asegurarse de que haya capacitación cruzada y necesitan un plan para responder a las personas que son "atropelladas por autobuses".

Las vacaciones son un buen "entrenamiento" para prepararse para cosas como esa. También ayuda a medir qué tan bien está preparado. Regrese al trabajo después de 2 a 3 semanas y cuente los días y el esfuerzo dedicado a limpiar su "retraso"; esto podría ser una aproximación decente al "escenario de atropello por autobús".

Esto también es una herramienta útil si desea mejorar. Analice los elementos pendientes que tiene que resolver y pregúntese qué se podría hacer para que alguien más pueda hacerlo. En uno de los trabajos anteriores, esto me ayudó a reducir los esfuerzos de "atraso de vacaciones" de unas tres semanas a dos días en menos de un año.

  • Oh, parece que soy el único que tiene esta información, necesito documentarla para que esté disponible para todo el equipo.
    Maldita sea, 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, en general, esto se considera una responsabilidad de su administración , por lo que cualquier cosa que haga más allá de lo requerido es a voluntad. Pregúntese cuánto quiere luchar contra el factor autobús y proceda en consecuencia.

Yo por mi parte quiero ser reemplazable ...

... para que pueda concentrarme en hacer cosas nuevas sin distraerme con las preocupaciones sobre lo que dejé atrás.

... para que sea posible conseguir un ascenso. Si eres el único que puede hacer algo, tus posibilidades de ser promovido son menores, ya que necesitan que sigas haciendo lo que ya estás haciendo. ¡Si no eres reemplazable, no eres promocionable!

Pregúntale a tu equipo. Pregúntele a su gerente. Presénteles el problema exactamente de la misma manera que lo ha hecho con nosotros.

Dales opciones. Documentación para un futuro desarrollador. Documentación para ellos. Pago de la deuda técnica. Cualquier cosa que puedas pensar. Dales estimaciones de tiempo. Dales la opción. Deje que lo comparen con su trabajo diario normal.

Oye, incluso podrían decidir que vale la pena correr el riesgo. Pero, en realidad, depende de ellos decidir.

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

Veo el problema del OP constantemente en mi trabajo. Y siempre trato de hacer lo que me sugieres. Pero, ¿y si la respuesta es siempre "está genial, deberíamos hacerlo, pero no tenemos tiempo"?
@dema80 Todo lo que realmente puede hacer es explicar el problema, proponer una solución o soluciones y dejar que el líder del equipo o el gerente decidan. Al final, se les paga para administrar su tiempo y, a menudo, tienen más información que usted (p. ej., dejaremos ese producto en 2 meses, por lo que es probable que reducir el factor bus sea una tarea de muy bajo valor; no se lo he dicho a los empleados porque algunos despidos estarán asociados con este cambio de estrategia).
Si su empresa no está pensando en su futuro, tenga en cuenta que ellos tampoco están pensando en su futuro. Entonces, si está dispuesto a aceptar que su empresa no quiere planificar su futuro, tampoco está planificando su futuro con la empresa.

Quería comunicarme y responder esas preguntas...

La lección más difícil que aprendí fue no responder a esas preguntas. Pero para 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

Básicamente, hay dos escenarios diferentes que crean el único punto de falla que aborda el OP.

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 la incapacidad de reconocer y abordar la creciente brecha de conocimiento.

Independientemente del cómo, la empresa crea la situación en la que tienen una gran dependencia de una sola persona o un pequeño grupo de personas que forman el núcleo de su base de conocimientos. Muchas empresas abordan esto mediante el uso de programas de tutoría, capacitación cruzada e intercambio de conocimientos tanto formales como informales.

Desde mi experiencia, los que tienen más éxito en esto también fomentan un enfoque de enseñanza. Con eso quiero decir que rara vez se le da una "respuesta" a una pregunta, sino más bien una discusión y preguntas puntuales de los expertos que lo guían por un camino de aprendizaje y ampliación de su conocimiento sobre el producto, proceso, tecnología en desempeñar.

Esto también ofrece una visión y una perspectiva frescas al experto en la discusión. De hecho, la enseñanza puede ir en ambos sentidos.

Empleado

En términos generales, tiene dos tipos diferentes de empleados que terminan en este puesto. Lo que yo llamo ' The Go To ' y ' The Protector '.

' The Go To ' es ese empleado que la mayoría de los gerentes aman. Él\ella es a quien puedes asignar casi cualquier tarea o proyecto y no tener que preocuparte por eso. Estas son las personas que se hacen un hueco en la empresa y se convierten en la persona a la que acudir y, muy probablemente, en la que tiene las respuestas.

' The Protector ' es ese empleado que ha tomado la decisión de proteger su territorio. Sienten que al resguardar sus conocimientos están asegurando su posición, importancia y futuro en la empresa.

Ambos crean inadvertidamente puntos únicos de falla. ' The Go To ' al proporcionar siempre la respuesta rápida y ' The Protector ' al no compartir ninguna o toda la información.

Entonces, en pocas palabras, toda la documentación del mundo no resolverá el problema subyacente de un único punto de falla. Sí, es importante y debe ser parte de cada BCP y plan de preparación para desastres. Pero la documentación no es realmente compartir conocimientos en el sentido de que alguien debería poder intervenir y realizar las tareas de su trabajo sin tener que leer un documento de 200 páginas de antemano.

No responda la pregunta; empoderarlos para que puedan responder por sí mismos.

La diferencia es que "The Protector" es alguien de quien la empresa querrá deshacerse. No es una posición segura.

Esto es lo que hacemos donde trabajo:

a) Utilizamos un wiki para la documentación. No archivos de Microsoft Word o archivos de texto. Una wiki en la que se puedan realizar búsquedas, seguimiento de cambios completos, etc. (Recomendaría Confluence , pero Confluence v4 es tan bueno que le sugiero que busque en otra parte)

  • Cualquier proceso repetitivo o delegable debe documentarse.
  • Se deben escribir listas de verificación de "así es como hacemos _____"
  • Las listas de verificación son muy importantes para formar equipos, ya que permiten que cualquier persona que pueda seguir la lista pueda realizar los procesos...

b) Control de versiones, obviamente

c) Sistema de seguimiento de casos/problemas, obviamente

d) Comentar su trabajo. Esta es la cosa más matizada, y es muy difícil de enseñar, pero como contratista/independiente, es posible que pueda asimilar esto: los comentarios deben explicar su proceso de pensamiento y el por qué de lo que está haciendo. Los enlaces a la documentación, Stack Overflow, 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 implica hacer que algo funcione de una manera (en lugar de una diferente). Hay un libro, algo así como 'código hermoso' o algo así, que tiene un fragmento en los bloques de comentarios en una unidad en uno de los grandes sistemas VCS abiertos ( Subversion o Git, Pienso). 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, por lo que recuerdo, puede no adentrarse demasiado en la pregunta del "por qué").

Un corolario de esto es: ¿cuántas personas regresan y editan el código solo para agregar comentarios? Todos deberíamos... mucho. Pero en la práctica casi nadie lo hace.

Esto es bueno, pero está escrito casi al 100% desde una perspectiva de software... no necesariamente aplicable para un ingeniero.
@enderland Se aplica al trabajo en CAD, Word, Excel.... o la mayoría de las herramientas.... Sí, está escrito desde la perspectiva de un codificador, pero se aplica en todos los ámbitos, en mi opinión.
Uno de los mayores problemas del código es que se pierde el pensamiento y el sudor que implica hacer que algo funcione de una manera (en lugar de una diferente) . Esta observación no tiene precio y todos los desarrolladores deben decirla en voz alta cada mañana mientras desayunan.

Netflix tiene un sistema al que llaman ChaosMonkey . Esencialmente "rompe" o emula romper ciertos sistemas al azar.

Se puede pensar en los empleados como sistemas y una forma de emular el descanso de un empleado es darle tiempo libre sin previo aviso ni programado. El ChaosMonkey te dijo que fueras a ver una película sin decírselo a tus compañeros de trabajo. A corto plazo, el efecto sobre ellos es el mismo que si te hubiera atropellado un autobús.

Esto prueba la solidez de sus sistemas y les permite detectar nuevas fallas en sus sistemas que de otro modo podrían haber pasado desapercibidas.

Esto podría ayudar en la transferencia de conocimientos de manera circular, ya que es probable que un sistema más robusto se rompa menos y tenga menos errores grandes que necesiten atención, lo que permite a las personas en cuestión concentrarse más en cómo funciona el sistema y por qué. hace lo que hace en lugar de simplemente perseguir problemas molestos 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 vacaciones pagadas obligatorias de al menos 2 semanas consecutivas a los empleados clave del banco. El bienestar de los empleados es una consideración secundaria. La consideración principal es que esto obligará a los bancos a designar a otra persona para que se encargue de las responsabilidades del empleado vacante. Si el empleado que deja vacante está malversando, el esquema se desmoronará bajo la vigilancia del reemplazo. Esto también significa que el banco no será vulnerable a un ataque al autobús.

@RhysW, ha realizado algunas ediciones realmente buenas, aunque normalmente es mejor si va a agregar tanto contenido para agregar una respuesta separada, actualmente estamos discutiendo esto en el chat aquí

empezaría con

  1. Estandarización

    Mi último puesto antes del actual solía ejecutar una metodología tipo salvaje oeste. Todos usaron las herramientas que querían, con las que estaban familiarizados. Lo que importaba era entregar los proyectos en buenas condiciones de trabajo y a tiempo. Hizo un mantenimiento de código horrible donde un proyecto se desarrollaría con GWT como la capa de presentación y JUnit únicamente para todo tipo de pruebas unitarias y otro desarrollador se quedó con JSP sin procesar mientras que otro incorporó JSF a la mezcla. Todo el mundo estaba encadenado a sus proyectos e irse de vacaciones era impensable para muchos y sonaba como la sentencia de muerte para las revisiones y la optimización del código.

    Propuse que estandarizáramos una serie de tecnologías y herramientas estándar de la industria que garantizaran que todos durmiéramos en la misma dirección de la cama (SoapUI para pruebas ws, JSF para el nivel web y con un éxito moderado, Spring para el procesamiento de back-end y un un par de cosas más). Y todos vivimos felices para siempre. Desaliente cualquier individualidad cuando se trata de herramientas del oficio que crearán archivos con una extensión propietaria (o al menos tratarán de mitigarlo); yo

    Si alguien tiene una herramienta favorita en la que confiar su vida, que la lleve ante el tribunal para su evaluación y posiblemente para la adopción de todo el equipo. Deberías haberte encargado de establecer los estándares con tus herramientas. Los beneficios son obvios aquí, todos usaron las mismas cosas con niveles aceptables de comodidad, por lo que con un documento de diseño decente, cualquiera puede tomar la parte de otra persona y seguir adelante.

  2. Revisiones periódicas y obligatorias de códigos/proyectos

    Esta es otra característica de mi último concierto. Todos nos reuníamos una vez por semana con nuestro gerente en una sesión de grupo y discutíamos el estado de los proyectos de cada uno y planteamos inquietudes y desafíos. Todos, en un nivel muy alto, teníamos una idea de en qué estaba trabajando el siguiente tipo y, a veces, aportábamos consejos y un par de líneas de código para ayudar. No hubo aislamiento total.

  3. Espíritu de equipo

    Sé que parece un poco trillado y posiblemente una obviedad, pero el espíritu de equipo saludable (y posiblemente un poco de competencia) fomenta el intercambio de información. La desventaja del entorno de cubículo (especialmente los miembros del equipo en cubículos muy separados) es que los miembros del equipo a menudo están demasiado alejados de la vida laboral de los demás, por lo que es demasiado fácil tener una falla en las comunicaciones. Hay una mejor comunicación e intercambio de información cuando los compañeros de equipo están situados cerca uno del otro, preferiblemente en un entorno de oficina abierta con pocas paredes o divisores. Las discusiones y el frotamiento mental ocurrirán y fluirán más libremente, con el objetivo de fomentar el intercambio de información.

  4. Obviamente Documento . Es una vieja canción. no lo volveré a cantar

Estoy de acuerdo con esta respuesta en general, pero estoy totalmente en desacuerdo con el tercer punto, que comete el error (desafortunadamente) demasiado común de confundir la comunicación y el espíritu de equipo con el espacio abierto; el espacio abierto no fomenta una buena comunicación; las revisiones periódicas y la programación en pareja sí lo hacen.

La planificación para esto es parte de una Planificación de continuidad comercial , mientras que se trata de planificar desastres más grandes que solo ser atropellado por un autobús, pero el proceso pone las piezas en su lugar para recuperarse de pequeñas incidencias como un jugador clave que es cazado furtivamente, a problemas más grandes. como un desastre que destruye los edificios y las personas que los atienden.

Wiki-How tiene un artículo regular sobre cómo crear un BCP y, aunque no recomendaría usar este método para su negocio, proporciona una buena perspectiva de los procesos y el pensamiento necesarios para crear uno. En general, los BCP se realizan en enfoques por etapas que manejan los mayores riesgos y se preparan primero para los escenarios más probables y luego se abordan las preocupaciones de menor riesgo. Pero cada empresa generalmente construye allí BCP de acuerdo con sus propias necesidades, por lo que el proceso exacto varía.

El proceso generalmente implica:

  • Identificar áreas de riesgo.
  • documentar los procesos involucrados
  • determinar las respuestas apropiadas a varios escenarios
  • Promulgar planes para lidiar con los escenarios.

¿Qué haría si le diera dos semanas de anticipación?

Hice un esquema rápido y comencé a grabar en video mi pantalla y mi voz. Incluía:

  1. Donde guardo todo.
  2. Ejemplos de solicitudes actuales y dónde estoy en el proceso.
  3. Demostraciones de cómo hacer algunas de las tareas más únicas o complejas en caso de que una persona menos técnica tenga que manejar las cosas por un corto plazo.
  4. Cómo encontrar cosas en la base de datos que construí el primer día para administrar todas las pequeñas cosas (cuando comienzas un trabajo por primera vez, realmente descubres lo que no sabes).

Mi objetivo como siempre es dejar un trabajo mejor de lo que lo encontré. Trato de no dejar que la gerencia establezca mis estándares. Su trabajo es preocuparse por los resultados finales, mi trabajo es saber cómo hacer mi trabajo mejor que ellos. No soy solo un par de manos extra.

Nuestras reglas cotidianas contra la gente que se lleva el conocimiento a la tumba:

  • Si alguien escribe un guión/rutina, entonces alguien más tiene que ser el primero en usarlo en producción.
  • Si alguien implementa nuevos sistemas, nadie los usará ni los admitirá hasta que pueda buscar todas las credenciales de acceso necesarias por sí mismo, solo, por la noche, sin preguntarle a otra persona.
  • También hay "configuración como código" y pruebas automatizadas para software. Le permite a su sucesor aplicar ingeniería inversa a su trabajo.

En efecto, "las cosas que aún no están listadas/probadas no existen para nosotros". Solo las cosas que se enumeran son confiables.

Lo llamamos " conocimiento arcano " (solo se almacena en la cabeza de alguien), y todo el mundo se niega a actuar en consecuencia.

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. Entonces, incluso nuestro departamento de contabilidad podría llevarse el "conocimiento a la tumba", si solo 1 contador 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.

No es parte de la respuesta: Nosotros (deberíamos) nunca documentar en texto. Solo documentamos en sistemas que proporcionan un resultado útil por sí mismos. Su documentación es un efecto secundario. (La forma en que una lista de control de lanzamiento resume las partes más importantes de un avión. O la forma en que las llaves de recepción son una forma confiable de enumerar a las personas que aún están dentro del edificio).

Los puntos a continuación deben estar en la descripción de su trabajo y establecidos por 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 que esto es necesario.

  • Trabaje dentro de estándares bien establecidos establecidos para su campo u organización.
  • Documenta lo que haces.
  • 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 se encuentra en la parte superior de una cadena de administración del sistema y posee las cuentas raíz/superusuario; cree una cuenta que tenga la autorización de seguridad más alta posible. Genere una contraseña aleatoria larga para ello. Imprímelo en papel. Firmarlo. Séllelo en un sobre y entrégueselo a la junta directiva, no al director ejecutivo . Porque un CEO puede deshacerse de la empresa en malos términos y aún tener esa contraseña. Dígales que lo almacenen de forma segura, fuera del sitio y su uso (puede otorgarle el estado de superusuario en la red en caso de su ausencia u otras razones que puedan aplicarse).
¿Por qué entregárselo a la junta directiva y no al CEO? Los miembros individuales de la junta pueden separarse de la empresa y aún tener esa contraseña. ¿Por qué no simplemente aceptar que así como ningún individuo es indispensable, ninguna organización es indispensable? Todos, individuos y organizaciones, moriremos algún día.
Entonces, la junta directiva puede alcanzar el estado de superusuario, pero ¿qué pasa si ninguno de ellos tiene habilidades técnicas? Esto realmente no resuelve el problema del autobús.
@emory: en realidad, pueden darle el sobre a alguien que pueda hacerse cargo de sus responsabilidades.
@Chad pero enderland escribió: "Nadie más en el equipo estaba familiarizado con las herramientas que estaba usando como yo lo estaba. Nadie más entendía ni siquiera a un nivel superficial la información técnica". Supongo que eso significa que la junta realmente no tiene a nadie a quien pueda entregarle las llaves.
¿Cómo puedo prepararme para ser atropellado por un autobús?
RespuestasAquíPolítica de privacidad1y, 0v