Cómo asegurarse de que su empresa no se sumerja si sus programadores ganan la lotería [cerrado]

Tengo algunos programadores debajo de mí, obviamente todos están muy bien y muy inteligentes. Muchas gracias.

Pero el problema es que todos y cada uno de ellos son responsables de un área central, que nadie más en el equipo tiene la menor idea de lo que es. Esto significa que si alguno de ellos es retirado, mi empresa como empresa está muerta porque no son reemplazables.

Estoy pensando en traer nuevos programadores para cubrirlos, en caso de que sean atropellados por un autobús, o renuncien o lo que sea. Pero me temo que

1. Los antiguos programadores podrían resistir activamente la idea de la transferencia de conocimiento, temiendo que una copia de seguridad pueda reducir su valor.
2. No tengo un sistema para facilitar la transferencia de tecnología entre diferentes desarrolladores, por lo que incluso si les pido que lo hagan, no estoy seguro de que lo harán correctamente.

Mi pregunta es,

1. Cómo ponerlo a los viejos programadores de tal manera que estén de acuerdo
2. ¿Qué sistemas utiliza para facilitar este tipo de "copia de seguridad"? Puedo entender que puedes hacer una revisión de código, pero ¿hay una manera simple de realizar esto? Creo que no estamos listos para una revisión completa del código de check-in.

Cómo ponerlo a los viejos programadores de tal manera que estén de acuerdo

Presente el problema abiertamente para ellos, por supuesto, de tal manera que no lo vean como una amenaza, sino como una oportunidad para que el equipo y el proyecto funcionen mejor. Por ejemplo, "Me gustaría que otras personas supieran lo que sabes en caso de que te despidan" es obviamente un enfoque equivocado :-) "Me gustaría asegurar el buen funcionamiento del proyecto incluso si alguno de ustedes se va de vacaciones o se enferma " es mucho mejor.

Por lo general, los propios desarrolladores experimentan los problemas cada vez que algunos de ellos están de vacaciones y necesitan cubrirlo. Además, los buenos desarrolladores se sienten responsables del proyecto en el que están trabajando, por lo que probablemente estarán de acuerdo con esta idea. Aún así, deles tiempo para discutir y (con suerte) comprometerse con la idea. Además, permítales opinar sobre cómo y con quién compartir sus conocimientos dentro del equipo. Puede resultar que Joe se siente bien para trabajar (y compartir su conocimiento) con Jim, pero no con Jack, etc.

¿Qué sistemas utiliza para facilitar este tipo de "copia de seguridad"? Puedo entender que puedes hacer una revisión de código, pero ¿hay una manera simple de realizar esto? Creo que no estamos listos para una revisión completa del código de check-in.

En nuestro equipo, aparte de las revisiones de código / diseño, utilizamos

• Rotación de tareas y áreas de responsabilidad entre los miembros del equipo (cada uno de nosotros tiene sus principales áreas de responsabilidad, pero de vez en cuando, hacemos tareas en un área mejor conocida por otro miembro del equipo)
• Sesiones de transferencia de conocimiento cara a cara (generalmente cuando las tareas anteriores lo requieren, pero también antes de que alguien abandone el equipo)
• Equipo / wiki del proyecto

La revisión del código en sí misma puede no ser suficiente ya que en muchas áreas generalmente hay mucho más para que un desarrollador sepa que lo que se puede leer directamente del código. En otras palabras, también existe el modelo de dominio . Puede leer lo que el código realmente hace, pero sin el modelo, no sabrá por qué .

Una forma de motivarlos para que compartan sus conocimientos sería pedirles que hagan una breve presentación de su trabajo a otras personas. Los programadores normalmente se enorgullecen de su trabajo, y esta sería una oportunidad para mostrarlo. Una presentación es una buena oportunidad para hacer que muestren algunas de las peculiaridades raramente conocidas por los extraños.

Además, ¿por qué no simplemente ser abierto al respecto y decirles a todos que todos deben idear un esquema de intercambio de conocimientos en caso de que alguien se golpee con un autobús? No veo esto como irracional. Está sucediendo en mi empresa en este momento, y aunque algunos están a la defensiva al respecto, saben que hay que hacerlo.

Tal vez podrían trabajar en parejas en algunas cosas, si son de naturaleza inquisitiva, no debería haber ningún problema.

Obtener la documentación interna del software actualizado debe ser el primer paso, antes de comenzar a contratar nuevas personas. Claro, significa que sus valiosos programadores pasarán algún tiempo con herramientas de Office y UML en lugar del IDE, pero creo que vale la pena en cualquier caso.

Una vez que tenga una documentación actualizada, puede permitir que sus programadores la verifiquen para asegurarse de que todos entiendan lo que otros han escrito. Todavía no hay necesidad de nuevas personas.

Entonces puede considerar contratar nuevas personas. O no, dependiendo de la carga de trabajo en su empresa.

Si está en una gran empresa, puede llamar a RR. HH. Y hablar sobre este problema. Créame, los chicos de contabilidad tienen el mismo problema si un autobús atropella al personal clave. La gente de marketing también tendrá muchos problemas si un vendedor clave se convierte en un zombi en medio de negociaciones importantes, sucede a menudo, o eso me han dicho.

Creo que el lenguaje de recursos humanos correcto para esto es la planificación de la sucesión . Es posible que su empresa ya tenga políticas y marcos para lidiar con esto.

Un lugar en el que trabajaba tenía el mismo problema. Lo que hicieron fue contratar un desarrollador junior para trabajar con cada desarrollador Senior. Crearon pequeños equipos de 2 que trabajaron juntos en proyectos. Cada pocos meses o proyectos rotarían a los desarrolladores junior entre los equipos. De esta forma, los desarrolladores Senior siguieron siendo los expertos en la materia, pero los desarrolladores junior comenzaron a comprender bien todos los sistemas y cómo trabajaron juntos. Además, con el tamaño del equipo, los proyectos de duplicación se hicieron más rápido.

Para los proyectos más grandes que surgieron, a veces se les pedía a los desarrolladores Senior que actuaran como desarrolladores Junior en otra parte del sistema durante todo el proyecto para que pudieran comenzar a aprender los otros sistemas.

La clave allí era respetar el conocimiento y la antigüedad de los desarrolladores existentes mientras se sigue expandiendo y haciendo crecer el equipo. Fue un proceso lento pero con el tiempo funcionó bien.

Una de las cosas que hace que los proyectos exitosos de código abierto sean tan exitosos es la falta de "propiedad" del código. Con esto quiero decir que nadie es el único responsable del mantenimiento de un área de la aplicación; cualquiera puede y es alentado a hacer contribuciones a cualquier parte de la aplicación. Es algo en lo que creo firmemente.

Lo que quieres hacer es explicar que las cosas están dañando al equipo que tienes ahora. Estos son los puntos que desea transmitir, y preferiblemente en este orden:

• No puedo liberarte para que trabajes en otras cosas interesantes que vienen por la pica si eres el único que sabe cómo funciona esto.
• Nosotros queremos que usted sea capaz de tomar unas buenas vacaciones, pero no podemos permitir porque nadie más puede hacer lo que haces.
• Es un hecho desagradable que las personas cambien de trabajo porque no están satisfechas con su posición actual, no queremos perderlo porque se siente atrapado por el área en la que está trabajando.

En una nota personal, tuve que tratar con un compañero de trabajo que falleció. Si bien no hubo silos de información, la pérdida aún golpeó con fuerza. Las posibilidades de que esto ocurra son mucho más bajas que el tercer punto anterior.

Una vez que haya presentado su caso, solicite su ayuda para obtener ideas sobre cómo corregir el problema. Ven con el tuyo, por supuesto. Sus ideas los ayudarán a darse cuenta de que son parte de un equipo y que son necesarios para algo más que su área de especialización. Puede ser que a Jane le interese lo que está haciendo Joe, pero se siente un poco intimidado por ello. Saber eso puede ayudar a que la transferencia de conocimiento sea más divertida. Algunas de las cosas que querrás hacer son:

• Entrenamiento cruzado del equipo actual. Puede perder un poco de eficiencia a corto plazo, pero puede haber algunas lecciones aprendidas en una esquina de la aplicación que se pueden aplicar a otras partes de la aplicación. Haga que Jane y Joe trabajen juntos en el proyecto del otro por un tiempo.
• Fomentar una cultura de intercambio de conocimientos. Una compañía para la que trabajé tenía un programa de "charla tecnológica sobre bolsas marrones". Cualquiera podría presentar cualquier tema aprobado (generalmente introduciendo tecnología o procesos de software). La compañía atendió el almuerzo y el presentador recibió un par de cientos de dólares por su esfuerzo.
• La tutoría debe ser una forma de vida. El propósito de asesorar a otras personas es liberarte para que hagas cosas nuevas y te hace aún más valioso para la empresa.
• Encuentre formas de cruzar los límites del silo de información sin aumentar el rango. Cuanto más divertido lo hagas, menos amenazante será. Si las personas en su equipo son tan buenas como usted dice, probablemente no estén completamente contentas con las cosas. Tendrás que juzgar si el equipo puede manejarlo, pero puedes tener una semana de "vamos a elegir". Siempre comienza contigo mismo aquí. La idea es hacer que todos vean cuáles son las responsabilidades de "más o menos" y cómo pueden resolver los problemas que están teniendo mejor. Siempre que comience con el cuello en la línea primero, tendrán la idea de que nadie está fuera para tomar su trabajo.

En general, trate de impresionarles de que desea que el trabajo sea más agradable y que necesita su ayuda para hacerlo.

Los pasantes pueden ser una buena idea, serán subordinados directos de los desarrolladores actuales, por lo que no se sentirán amenazados.

A medida que la empresa crezca, necesitará tanto desarrolladores antiguos como aquellos que lo lograron después de su pasantía.

Creo que esto podría funcionar.

En general, cuando algún gerente de repente comienza a preocuparse por la documentación y la planificación de la sucesión, es una fuerte señal de advertencia de que los programadores están a punto de ser despedidos o despedidos. Es una desviación del comportamiento administrativo típico y las preocupaciones que desencadena todo tipo de señales de advertencia en los programadores.

Todos deben documentar todos sus procedimientos y procesos.

Nivel 3 de " Señales de advertencia de fatalidad corporativa ".

Como alternativa, un ensayo sugiere que alentaríamos una cultura de " Arriba o Fuera ", aunque el argumento en contra es que muy pocas compañías tienen una escalera de carrera técnica que de alguna manera se asemeje al espectro financiero y de poder que la (mala) escalera de carrera gerencial contiene.

Partiendo del concepto de documentación completa que @ammoQ comenzó en su respuesta ...

Un buen gerente trabaja para desarrollar las habilidades de sus informes directos para que cualquiera de los informes pueda reemplazarlos. Haga que sus desarrolladores comprendan que un empleado que brinda total transparencia de su trabajo es más valioso que uno que mantiene todo su trabajo en secreto y oculto. Si el desarrollador 'secreto' muriera hoy, sería un gran costo para la compañía recuperar ese conocimiento perdido. Si el empleado de "divulgación completa" muriera hoy, la compañía aún estaría perdida, pero sería menos devastadora. Por lo tanto, el empleado de "divulgación completa" tiene más valor.

Cualquier empleado que intente mantener el conocimiento oculto para hacerse inmune a ser despedido también se hace inmune a un ascenso. No puede mover a un desarrollador a una posición más desafiante y gratificante si no hay nadie para completar las tareas mundanas con las que se encuentra cargado. Si las tareas cotidianas están completamente documentadas y divulgadas, puede contratar a un nuevo desarrollador junior para que complete y promueva al desarrollador anterior a un puesto más alto.

Esto significa que usted también debe documentar lo que hace y proporcionar capacitación a cada uno de sus informes directos. De esta manera, si usted muriera hoy, uno de ellos podría reemplazar a usted hasta que se encuentre un reemplazo de tiempo completo.

Antes de comenzar a traer nuevos programadores, les pediría a cada uno de ellos que me ayuden a crear su propio legado documentado.

Ya sea con una wiki o una biblia de 3 anillos de documentos sobre cada aspecto de su trabajo.

O si desea documentación realmente detallada y exhaustiva, contrate a un escritor técnico para entrevistar a cada programador y luego cree una documentación de todo, todos lo hacen, diariamente, semanalmente, mensualmente, anualmente.

Luego haga una versión wiki de él, que su programador pueda actualizar / editar / participar / comentar.

Entonces tiene un sistema que crecerá en el tiempo y será la curva de aprendizaje mejorada para cualquier programador nuevo.

Además, sinceramente, no es aconsejable que los programadores se queden atrapados en un área central, realmente vale la pena cruzar el tren, el trabajo cruzado.

Entonces puede usar su personal existente, cuando 1 persona se toma vacaciones o algo así.

Cada vez que uno de tus programadores se enferma, llámalo repetidamente con preguntas y problemas.

Cada vez que uno de tus programadores esté de vacaciones, llámalo repetidamente con preguntas y problemas.

Pronto se darán cuenta de que es mejor para ellos y para la empresa no tener personas solteras responsables de las áreas centrales.

Nadie quiere ser atropellado por el autobús, pero tampoco quieren tener que hacerse cargo del proyecto de otra persona a corto plazo y mantener su proyecto también. Entonces todos corren el riesgo de cerrar el negocio.

Si se está desarrollando en silos, debe comenzar a mover personas de un proyecto a otro. Comience con la documentación, la revisión del código o la reparación de un error simple. Cualquier pequeño acto de protección de código / territorialidad debe abordarse antes de que esto se salga demasiado de control.

Tener un especialista solitario en una parte de su código es una ilusión de eficiencia.

¿Alguien quiere ir de vacaciones?

He tenido muchas más compañías quebradas debido a errores estúpidos de la gerencia. No se estrellará y quemará si uno o dos ingenieros se van, solo tendrá que trabajar un poco más por un tiempo. Sheesh, administro un equipo offshore que pierde a alguien cada trimestre. Comience a mover las tareas. Hoy.