¿Cómo pedir a la dirección más personal?

Nos está pidiendo que demos por sentado que agregar más mano de obra es una buena idea. Por las razones que describo a continuación, mi creencia anterior es que hacer crecer un equipo en respuesta a la carga de trabajo "inflable" es a menudo la primera señal de problemas. Si yo estuviera en su posición, trataría de hablar con mi gerente sobre por qué el trabajo se está disparando, y trataría de analizar algunas especificaciones de software claras, casos de uso, pruebas y planificación de características que deberían abarcar el espacio de trabajo. esa debe ser tu responsabilidad. Si puede trabajar con su jefe para restringir y limitar el crecimiento no planificado del proyecto, el producto restringido por lo general será mucho mejor.

Me gusta pensar en ello como una ciudad plantando algunos árboles a lo largo de la acera de Main Street. Puede dejar que el árbol crezca sin control, en cuyo caso podría romper un montón de aceras y requerir que contrate a un grupo de personas para mantener los efectos secundarios del crecimiento. O bien, puede atar el árbol joven a un poste y guiar su crecimiento con un plan de desarrollo severo y despiadadamente rígido, y obtendrá árboles hermosos y rectos con menos riesgo de aceras rotas.

Más concretamente, en algunos libros de mejores prácticas de software ampliamente citados, como The Mythical Man-Month y Peopleware , a menudo se describe como una falacia que agregar más mano de obra a un proyecto de software generará buenos resultados.

Obviamente, existen límites de capacidad en torno a lo que puede hacer una sola persona. Pero averiguar cuándo y cómo expandir el equipo no es trivial, y expandir un equipo simplemente porque un desarrollador (o grupo) "siente que" el trabajo se está volviendo inmantenible no siempre es una buena idea.

Sin un plan arquitectónico sobre cómo es probable que crezca y cambie el trabajo en el futuro, poner más cocineros en la cocina suele generar problemas. Por un lado, el costo inicial de una nueva persona suele ser mucho más alto de lo presupuestado. Aquí me refiero en términos de ingesta y formación de nuevas personas. E incluso después de que la persona aumenta y comienza a agregar un efecto de productividad positivo neto (meses después), entonces tiene un canal de comunicación adicional que reduce la productividad general de todos, y tiene gastos administrativos adicionales.

En general, dado que hay N*(N-1)/2 conexiones bidireccionales entre N personas, significa que la sobrecarga de comunicación crece con el cuadrado del tamaño del equipo. A menudo, la burocracia gerencial crece al mismo ritmo o más rápido. Rápidamente, los argumentos originales sobre la falta de horas de trabajo se intensificarán en un ciclo de retroalimentación, en el que agregar personas para aliviar la presión de la carga de trabajo causa suficiente presión de carga de trabajo nueva como para que el valor marginal de un nuevo miembro del equipo sea demasiado bajo (¡o incluso negativo!) para hacerlo.

Mucha gente piensa ingenuamente que esto solo sucede cuando se habla de proyectos a escala de la NASA con cientos de ingenieros. Pero, de hecho, puede suceder en un equipo con tan solo 2 a 5 personas. Todo depende de la infraestructura, las necesidades de desarrollo y el plan arquitectónico para lo que se necesita lograr con los roles de software.

Diría que lea los dos libros mencionados en la parte superior de esta respuesta. Reflexione sobre cómo podría 'diseñar' un plan de ataque para el proyecto tal como lo ve ahora, esforzándose por tener en cuenta tantas direcciones diferentes (posiblemente imprevistas) de crecimiento futuro como pueda. Lea acerca de la falacia de planificación . Y luego intente sintetizar todo eso en un plan práctico para hacer crecer un equipo.