Realmente necesitamos buenos gerentes en el desarrollo de software.
Por lo general, alguien como yo se hace notar como “bastante bueno en ese software”. Eventualmente, se nos pedirá que ocupemos un puesto administrativo. Después de todo, somos expertos en software, ¿verdad?
Mi propia experiencia la primera vez que esto sucedió es típica.
- ¿Microsoft Surface Pro 3 es bueno para los estudiantes de CS?
- ¿Cómo es AIT, Pune para CSE? ¿Cómo es la multitud, la cultura de codificación y las ubicaciones para CSE allí? ¿Cómo son las instalaciones del albergue? Con 20,000 rango aéreo, ¿vale la pena ir?
- En Machine Learning, ¿por qué aplicamos a menudo la suposición de registros independientes e idénticamente distribuidos?
- ¿Quién es el Einstein de la informática?
- ¿Cuáles son algunos de los asombrosos usos de los gráficos en CS / Modelado?
Conocía el software al revés, y no quería nada más que continuar codificando.
Pero luego sucedieron los informes de estado. Los altos directivos querían saber ‘¿Está en marcha el proyecto? ¿Cuánto tiempo más necesitas? (Todavía no tenemos una buena metodología para pronosticar eso).
Inevitablemente, el proyecto “se quedó atrás”, lo que significa que salió muy, muy bien, con una productividad y un compromiso increíbles del nuevo equipo … pero era poco probable que cumpliera con la fecha límite de la feria.
Luego vienen las preguntas: “¿Qué vas a hacer para asegurarte de ir a la feria? Y necesitamos todas las funciones: ¡aceptaremos pedidos de ventas ese día! ”(Más allá de eliminar bloqueadores, resulta que no siempre hay mucho que puedas hacer: cortar funciones, reemplazarlas con versiones más simples quizás)
Luego, justo cuando no lo necesita, supervisa a sus dos mejores desarrolladores teniendo una discusión acalorada. Aparentemente, el enfoque de Dave es mucho mejor que el de Bob, pero Bob no está de acuerdo y Dave está frustrado. Así que paseas y te das cuenta de que, como programador, eres un introvertido que evita el conflicto. Y aquí estás, voluntario para ser cerdito en el medio.
Entonces, Dave y Bob se calmaron cuando apareció el gerente de producción. Esos chips de CPU de alta memoria se han duplicado en precio después de un terremoto que eliminó el chip fab. Por lo tanto, solo podemos obtener las versiones de menor memoria en cantidad.
S ahora estamos negociando con nuestros desarrolladores, que están ocupados, y los interesados de nuestro proyecto sobre qué característica debemos eliminar, porque no encajan.
Y luego el marketing se acerca y dice que ya hemos filmado el video web que promete esas características, y no tenemos presupuesto para volver a filmar.
Un vendedor al azar deambula diciendo: “¡Si solo tuviéramos otra característica nueva, podría vender un millón este año! ¡De Verdad! Quiero decir, no han firmado el contrato, pero … ”
Y luego Bob se enferma de estrés. Resulta que Dave y Bob habían estado hirviendo durante mucho tiempo. Bob tiene síntomas físicos en realidad.
Entonces, ahora habla con Recursos Humanos sobre la contratación de un contratista. Sabes en el fondo de tu corazón que esto va a nivelar la productividad del equipo durante una semana o dos mientras haces una inducción decente.
Ahora está escribiendo una especificación de trabajo y reservando salas de reuniones.
Estás probando tu traje, por lo que pareces el entrevistador y te das cuenta de que ha pasado un tiempo desde que lo usaste como codificador. Casi cabe. Se parece un poco a Dilbert, pero bueno.
Luego pasan dos días con entrevistas. Y necesitas escribir un ejercicio de codificación. Y RR. HH. Sigue pidiéndole su opinión. Y su teléfono móvil está todo el tiempo con reclutadores, prometiendo que “este candidato es realmente el mejor”.
Y te sientas en tu escritorio, mira
clase UiToolsBasedMachineUi: public MachineUi {
privado:
const UiTools & ui;
público:
MachineUi (const UiTools y uiTools) {
ui = uiTools;
}
void onOutOfPaper () {
ui.createDialog (“Advertencia”). withMessage (“no tiene papel. necesita reemplazar la bandeja A”). buildWithStandardCloseButton ();
}
};
Y te preguntas qué demonios está pasando.
Los problemas que enfrenté fueron simplemente que tenía que aprender a ser gerente mientras era el codificador principal . Muchas de estas habilidades blandas se pueden aprender y enseñar. Pero no siempre son innatos en las personas que se sienten atraídas por la codificación.
Aprendí desde entonces un montón de técnicas para manejar gran parte de esto.
Pero si puede ingresar al campo con su propio enfoque del lado humano, entonces mucho mejor.
Hay un lado negativo que te diría: los peores administradores de software que he encontrado son los que nunca han codificado .
Tenemos un problema básico en el desarrollo de software. Es inherentemente fluido. No existen proyecciones confiables para proyectos de software típicos, es decir, nuestra industria adoptó los métodos ágiles. Estos son un reconocimiento de que los pronósticos de largo plazo para el desarrollo son, en el mejor de los casos, muy inexactos.
Esto hace que los proyectos de software no sean aptos para las técnicas de línea de producción. Y creo que la experiencia de la codificación ayuda a llevar eso a casa. Ayuda a capacitar a un gerente para los tipos de problemas ‘esperados inesperados’ que enfrentarán todos los días para mantener los proyectos encaminados.
Entonces, si combina una comprensión genuina de lo que se necesita para que un equipo de desarrolladores ponga el código en producción y tenga un don natural para ayudar a allanar ese camino, entonces la administración podría ser un gran uso de sus habilidades.
