¿Cómo debo acercarme a un jefe que sigue contratando trabajadores temporales, solo para que termine algo?

Es posible que desee tomar algunos argumentos del libro The Mythical Man-Month de Frederick Brooks. Aunque originalmente fue escrito en 1975 (revisado en 1995), sigue siendo uno de los trabajos más importantes en lo que respecta a la gestión de equipos de desarrollo de software.

Es más conocido por codificar la Ley de Brooks :

agregar recursos humanos a un proyecto de software tardío lo hace más tarde

Las razones son:

• Se debe enseñar a los nuevos desarrolladores sobre la arquitectura existente del proyecto antes de que puedan hacer algo útil. Esto le quita tiempo al equipo de desarrollo existente.
• Hay un límite superior para cuántas personas podrán hacer contribuciones útiles a un proyecto de desarrollo de software al mismo tiempo. A menudo no es posible encontrar subtareas razonables para asignar a nuevas personas.

Un buen desarrollo de software requiere un equipo central estable que trabaje en conjunto de principio a fin.

Es posible que su gerente no esté al tanto de esta regla. Así que intenta ayudarte de la única manera que se le ocurre: añadir más personas a tu proyecto.

El problema con los trabajadores temporales y los contratistas (divulgación, yo soy uno) es que a menudo no hay respuesta si la entrega es horrible.

Puede valer la pena conversar con su jefe sobre la calidad de los trabajadores temporales. Contratar barato significa mover los costos más adelante, pero eventualmente pagará para arreglar el código.

También puede solicitar participar en el proceso de contratación proporcionando una pequeña prueba de codificación para asegurarse de que realmente valga la pena contratar a los trabajadores temporales. Nada demasiado dramático, menos de una hora de trabajo para hacerse una idea de la capacidad.

Lo que escribió en realidad genera una serie de señales de alerta que sugieren que la única solución viable es cambiar su trabajo. Usted escribió que su gerente ignora la importancia y el valor de las pruebas unitarias, supongo que es lo mismo con el análisis y el diseño, ya que esos conceptos erróneos generalmente vienen en paquetes. También dice que él cree que agregar un desarrollador temporal durante un mes traerá algo más que un retraso adicional. Aparentemente, su gerente tiene poca idea de cómo se debe ejecutar el proyecto de desarrollo de software y hay pocas o ninguna posibilidad de que cambie de opinión.

Sin embargo, puedes intentarlo.

Si bien 9 mujeres para dar a luz en un mes es una forma popular de "probar" que agregar personas no necesariamente agiliza el trabajo, por lo general no funciona en alguien que no está realmente interesado en comprender el problema pero que lo sabe mejor. En lugar de eso, use el ejemplo de cavar un pozo.

Digamos que necesitas cavar un pozo de 1 m de diámetro y 15 m de profundidad. Un hombre necesita 15 horas para cavarlo. ¿Cuántos hombres se necesitarán para hacer la tarea en 1h?

La respuesta que le darán la mayoría de los gerentes (y la mayoría de las personas en general) será que serán 15 hombres, pero eso no es cierto y es fácil de mostrar a cualquiera que no tenga idea sobre la excavación de pozos de codificación . Al igual que en la codificación, puede reemplazar a una persona que excava con otra. Puedes (hasta cierto punto) compartir tu trabajo. Pero solo un hombre cabe en un agujero de 1 m de ancho para trabajar. Si agrega una segunda persona adentro, la primera será obstruida por ellos y no podrá hacer su trabajo.

Puede acelerar un poco el trabajo cambiando a una persona agotada por una nueva para que una segunda persona ayude un poco. No será la mitad del tiempo, un ahorro probablemente no sea más de 1/3. Pero agregar un tercer hombre probablemente no ayudará un poco. Los dos intercambiarán cada hora más o menos, teniendo tiempo para recuperar su resistencia. Entonces, si insistes en usar al tercer trabajador dentro del hoyo, el único efecto será que perderás más tiempo cuando intercambien o simplemente más hombres estarán esperando su turno, siendo pagados pero sin aportar ningún valor extra. Ninguna ganancia en el mejor de los casos, una pérdida en el peor.

Por lo tanto, puede utilizar la tercera persona en algunas tareas auxiliares, como eliminar el exceso de suciedad del vecindario del pozo. Bien, agrega quizás un 5% de ahorro de tiempo por el costo de un trabajador completo.

Pero, ¿cómo puedes utilizar un cuarto hombre, sin mencionar otros 11? Si realmente insiste en usarlos todos, comenzará a tener costos adicionales como comunicación, tiempo para intercambiar, etc. Entonces, comenzando con el cuarto hombre, solo agregará demoras sin ningún beneficio y un costo adicional extenso de personas. .

Y eso suponiendo que todos los trabajadores estén calificados. ¿Qué sucede si cavar un pozo requiere una precisión adicional y contrata a un trabajador temporal no capacitado para eso? Debes enseñarles para que pases la primera hora mostrándoles cómo hacer bien las paredes para que no se deshagan y cómo lograr esa forma perfectamente redonda. Luego estarán trabajando al 50% de la velocidad del hombre capacitado y su trabajo aún no será perfecto, por lo que el encargado de la permanente tendrá que hacer las correcciones, perdiendo algo de tiempo de su trabajo. En realidad, antes de que la persona nueva pueda traer algo más que demoras, el pozo estará listo. Y llevará más tiempo que si el trabajador calificado excava solo. Todavía puede usar una temperatura para esas tareas auxiliares o las más simples (mientras estoy tomando un descanso, excave en el medio, deje las paredes intactas), pero eso sigue siendo 5, tal vez 10% de ganancia en el mejor de los casos.

Y es algo tan simple como mover una pala. La codificación es mucho más compleja.

Resúmelo con algo así:

Es obvio que necesita capacitar a un desarrollador y 1 mes es un mínimo para que funcionen al nivel de productividad básico si están capacitados . Durante la capacitación, debe invertir el tiempo de un desarrollador regular en la capacitación y el trabajo de los temporales debe revisarse de todos modos, por lo que agregar a alguien al equipo por menos de 4 a 6 meses no es más que un desperdicio.

La otra idea sugería que usted podría participar en el proceso de contratación. Ese es un buen consejo para reducir el tiempo de introducción de una nueva persona en el equipo y limitar la cantidad de errores en su código, pero aún requerirá capacitación (una introducción). Así que un trabajo temporal, incluso uno calificado, durante un mes es un desperdicio. En el mejor de los casos, puedes usarlos para escribir cosas auxiliares. Como pruebas unitarias ;-)

Si su gerente no puede comprender tal comparación, su última opción es volver al mercado laboral.

Esto incursiona en el asesoramiento general de desarrollo de software....

1. Si el código que alguien escribe rompe algo, agregue una prueba automática para que pueda verlo antes la próxima vez.

2. Revisa las solicitudes de extracción, no fusiones nada hasta que estés seguro de que nada más se rompe.

3. Las pruebas hacen una buena especificación. TDD es una buena manera de asegurarse de que lo que obtiene es lo que desea. Asigne a alguien una tarea para escribir el código que necesita (como lo demuestran las pruebas que ya escribió).

4. La programación entre pares podría ser una opción. Puede corregir las cosas de inmediato y responder preguntas a medida que avanzan las cosas.

¿Cómo abordar al jefe que sigue contratando trabajadores temporales solo para que termine algo?

Tu ya lo tienes. Todo lo que puedes hacer es perseverar en decírselo al jefe.

Mientras tanto, hay una solución, la razón por la que tienes que rehacer el trabajo es porque descubriste que era basura demasiado tarde. Tiene la oportunidad de practicar algunas habilidades y asumir más responsabilidades, pero no lo está haciendo. No es un problema esotérico, es solo una forma de ver un problema y una metodología de resolución. Bien vale la pena aprender.

Este es uno de esos momentos en que la microgestión es fundamental. Evaluar la situación en su conjunto (incluidas las personas, son un recurso) y hacer un plan de resolución, utilizar la mano de obra de manera eficiente en esos términos. Esta es la ÚNICA forma de hacerlo, no permite que ni siquiera las personas con experiencia se desvíen de su plan, no tienen el panorama completo, les asigna tareas pequeñas y verifica todo lo que hacen, le informan en cada paso.

Lo más importante es comprender el problema por completo y tener un plan sólido. Luego divídalo en tareas más simples siempre que sea posible y no confíe en que nadie haga su parte sin supervisión.

Si puede salirse con la suya con argumentos lógicos como los 9 meses para hacer una analogía con un bebé, eso es genial pero, en mi experiencia, este argumento solo funciona con personas que ya lo entienden. E incluso cuando lo hagan, a menudo seguirán preguntas sobre cuál será el número óptimo de miembros del equipo.

Lo que podría ayudar si la lógica falla es reunir algunos datos que muestren cómo se está haciendo el trabajo y centrarse en qué trabajo de las personas necesita remediación. Si reúne esto, puede mostrar un gráfico bastante dramático de quién está realmente agregando a la salida y quién está restando valor.

Parte del problema es que los gerentes están bajo presión para cumplir y necesitan demostrar que están haciendo algo para que esto suceda. No hacer nada podría hacerlos parecer ineficaces e irrelevantes. Puede ayudar con esto ofreciendo algunos cambios que su gerente puede hacer que ayudarán (mejores máquinas, computadoras portátiles, pizarras, un servidor de compilación, diferentes horarios, espacio de trabajo aislado, etc.)

Es probable que el nivel de habilidad de los trabajadores temporales dependa de la cantidad de dinero que su gerente esté invirtiendo en ellos. Como son solo temporales, obviamente no quiere desperdiciar demasiados fondos. Como usted dice, su jefe no es un desarrollador y probablemente solo asuma que un codificador puede codificar.

Sin embargo, si está aumentando su carga de trabajo a largo plazo y está afectando su trabajo actual. Necesita atraerlo para un 1x1 y simplemente transmitir sus problemas y la razón por la que no les está delegando tanto trabajo y sus preocupaciones para el futuro si les delega trabajo.

Debes asegurarte de no dar la impresión de que estás tratando con tu jefe, pero al mismo tiempo debes transmitir el mensaje, ya que él no entiende lo que sucede dentro del desarrollo. Si simplemente menciona que estaría feliz de delegar el trabajo, pero solo cuando se sienta seguro de hacerlo.

Me parece útil discutir un ejemplo específico. Tome un caso de algo que hizo un trabajador temporal que requirió que usted lo arreglara. Describe el tema que se está trabajando. Haga una línea de tiempo cuidadosa de los eventos, que muestre cuándo se le pidió al temporal que trabajara en él, cuánto tiempo trabajó en él, cuándo se descubrieron los problemas, cómo se solucionaron los problemas y cuándo estuvo listo el código o al menos volvió a funcionar. usable. Compare con una estimación de cómo habría funcionado con un equipo de desarrollo estable. Puede admitir que seleccionó el ejemplo, pero también tiene una lista de muchos problemas en los que esto ha ocurrido.

Ahora discuta su solución, que parece ser la contratación de una adición permanente al personal. ¿Cuánto tiempo llevará capacitar a esta persona (pero solo lo hace una vez, no una vez por temporario), cómo se comparan los costos (lo mejor que sabe), etc.

Parece que su jefe/empresa no entiende que hay demasiado trabajo para usted. La contratación de trabajadores temporales tiene sentido cuando la sobrecarga es temporal, pero es una solución muy costosa cuando la sobrecarga es permanente. Necesitas hacer este caso.

Las otras respuestas son todas muy buenas. Sin embargo, sugeriría otra táctica. Si este es un problema recurrente, tal vez sea, como parece pensar su gerente, una indicación de que su carga de trabajo es demasiado alta para que usted solo pueda cumplir con sus expectativas.

Estás señalando que su solución a esto no funciona, y es muy posible que necesites explicarle por qué. Las otras respuestas cubren la mayoría de los posibles argumentos que podría hacer al respecto. Pero si quiere ver un cambio, la mejor manera de lograrlo es, por lo general, sugerir su propia solución alternativa.

Tal vez en lugar de seguir contratando trabajadores temporales, podría considerar una adición permanente al equipo. Si realmente está dispuesto a delegar tareas, pero no puede porque la calidad del código no está a la altura, entonces esa es la parte que debe corregir. Sin embargo, si desea que alguien invierta en aprender su arquitectura y estilo de codificación, debe tener alguna expectativa de que la inversión valdrá la pena. Una adición permanente al equipo conlleva costos adicionales, pero la calidad mejorada de su contribución y la menor necesidad de supervisión/reelaboración pueden amortizarse fácilmente a largo plazo.

Pruebas unitarias

Esta respuesta sugiere que debe escribir pruebas unitarias y hacer que codifiquen las pruebas. Ese es un enfoque, pero deja su trabajo como escribir pruebas unitarias. Puede que eso no sea lo que quieres. Y para obtener los mejores resultados, debe escribir pruebas excelentes y completas y tener buenos desarrolladores. Porque las pruebas controlan el resultado más que el proceso. Es totalmente posible escribir un código pésimo (difícil de mantener y modificar) que pase las pruebas.

Otro enfoque es cambiar las cosas. En lugar de escribir pruebas, haga que los otros desarrolladores escriban las pruebas. Continúas escribiendo el código que ibas a escribir de todos modos. Si pasa las pruebas, genial. Si no es así, puede considerar por qué. Si el motivo es que la prueba apesta (lo que significa que no cumple con los requisitos reales), elimine la prueba. Cada vez que haga eso, registre esa decisión.

También puede revisar las pruebas de aprobación para ver si son útiles. Nuevamente, si no son útiles para codificar los requisitos, elimínelos. Registre la decisión.

Esto se basa en que es más fácil revisar las pruebas que el código. Por lo tanto, es mucho más fácil ver si un desarrollador puede pasar de escribir pruebas a código que determinar si el código del desarrollador es lo suficientemente bueno por sí solo.

Al final del mandato del desarrollador temporal, escriba estadísticas sobre cuántas pruebas fueron útiles y cuántas se eliminaron. Esa es entonces la información que le presenta a su jefe cuando argumenta en contra de contratar más trabajadores temporales. Incluya cuánto tiempo tomó revisar las pruebas versus cuánto tiempo hubiera tomado escribir el conjunto de pruebas final. Si ese número es neto negativo, entonces la empresa pagó dinero por un "desarrollador" para que empeorara su software. Incluso si es positivo neto, compare el costo de la temporal con lo que hubiera sido su costo.

En mi experiencia, los jefes responden mejor a los argumentos financieros con evidencia. Sin la evidencia, pueden rechazar el argumento. Con evidencia técnica pero no financiera, no necesariamente entenderán la evidencia (algunos pueden pero muchos no). Así que exprese cualquier evidencia técnica en términos financieros.