Cuando trabajas como desarrollador, todo el tiempo ves cómo los líderes del equipo se sientan en un montón de llamadas, son responsables de todo, escriben tanto código como tú, y al mismo tiempo no tienen más dinero. Tanto los ideológicos como los idiotas irán por esto.
No soy un idiota, mis ideas no giran en torno a los valores comerciales, así que no me suscribes. Pero no siempre nos preguntan sobre esto. Primero, me contrataron como el primer y único desarrollador en una startup renacida, luego me dijeron que contratara a más personas, y luego me encontré a cargo de tres desarrolladores, dos probadores y un analista.
En resumen, todo es incluso peor de lo que parecía desde fuera.
Seis personas todos los días te esperan para que les digas qué hacer, luego les dirás cómo hacerlo, y luego también evaluarás si lo hiciste bien. La séptima persona al final del día también le preguntará qué hizo usted mismo. En el sentido de que te codificaste a ti mismo, y que hizo cada una de las personas de las que eres responsable.
Aquí una vez me quejé de que el timbre es una muleta que te permite controlar sin ahondar, y ahora estoy convencido una vez más de que tenía razón. Vienen a mí con una pregunta, y no tengo ni idea de qué responder. Nos llamamos y la persona obtiene una respuesta de mi desafortunado cerebro sin mi participación. Tampoco estoy preparado para formular mis preguntas, no tengo ni idea de qué preguntarles. Así que llamo y observo cómo todo se arregla. Y aún mejor, me aseguro de que se llamaran entre sí, sin mí en absoluto. Hace un mes que no puedo cerrar una tarea bastante sencilla, porque mi cerebro está agotado por las tareas de gestión, y sobre todo por el hecho de que no sé cómo realizarlas.
Pensé, está bien, así debería ser. No estudié para ser gerente. Luego miré mi pasado, recordé todas mis pistas y de repente me di cuenta de que nadie había estudiado. Ninguno sabía cómo arreglárselas. También lo enmascararon con interminables llamadas telefónicas y dilación. No sabían qué responderme, no sabían adónde íbamos, no sabían qué estaba pasando en absoluto y quién estaba haciendo qué.
Cuando estaba haciendo una tarea simple durante dos meses, y todos los días mentía diciendo que tenía grandes dificultades y que había un problema grave allí, y luego hice una solicitud de extracción para cuatro archivos esbozados durante la noche, nadie me regañó, no porque lo lamentaran. Simplemente no tenían idea de lo que estaba haciendo allí. Y miraron mi código línea por línea, para llegar al final de la nomenclatura y encontrar antipatrones jugosos, pero no profundizaron en eso. Porque no hay tiempo para ahondar, no quiero, y no está claro por qué.
Todos mis jefes anteriores han abrazado e idolatrado ágil: es un gran juego de muletas, un juego que ayuda a un grupo de personas que no tienen idea de lo que está sucediendo a fingir que todo está bien y que estamos avanzando.
Trabajé con líderes de equipos provinciales de cosecha propia, a quienes en equipos serios ni siquiera se les permitiría componer tipografías, trabajé con gerentes de desarrollo geniales de las principales empresas extranjeras, trabajé con personas a quienes alguien consideraba verdaderos genios en programación.
Y todos ellos, en lo que respecta a la gestión, se sentaron en el culo. Aprendí las reglas de este juego en mi primer trabajo con Agile. Nos llamábamos todas las mañanas y todos decían lo que habían hecho, lo que estaban haciendo y lo que harían. En la primera llamada de este tipo, vine con la idea de informar y demostrar que no estoy comiendo mi pan en vano. Comencé un discurso largo, muy largo sobre mi tarea, expliqué en detalle por qué aún no estaba lista y con qué estoy luchando ahora. Me interrumpieron en el medio: “Phil, ¿quieres algo de nosotros? ¿No? De acuerdo, ¿todos descubrimos quién es el próximo? "
La persona que nos controlaba solo necesitaba saber una cosa: le arrojaría problemas por hoy o no. ¿Tiene que pasar tiempo conmigo hoy? Antes de que comenzara a hablar, él ya tenía el discurso perfecto en su cabeza para mí: "todo lo que está dentro del plan". Cualquier otro desarrollo de eventos para él es pura maldad.
Existe otra opción. Cuando el problema no se lo planteé yo, sino otras partes del sistema, el cronograma ágil está podrido y ahora no puede decir en su reunión de clientes potenciales que todo va según lo planeado, y también se convierte en un problema de alguien. Esto automáticamente me convierte en su problema, y llama al PM.
Comenzamos a discutir algo y ambos lo entendemos: tenemos que encontrar una manera de dejar de ser problemas. No tiene nada que ver con el producto o proyecto. Tenemos un jodido boleto que tenemos que mover. Y lo movemos, de la forma más sencilla disponible. Lo arreglamos con el código, lo ponemos en el norepro, ponemos la etiqueta "bloqueado por" - lo que sea. En este momento, no nos importa un comino el producto, tenemos un boleto. O muchas entradas.
Había dos realidades en cualquier equipo en el que trabajaba. Una realidad es un producto real y personas reales que lo mejoran porque quieren. Y luego estaba la jira, que existe absolutamente paralela a todo esto. Y la única persona que puede sincronizar el estado real del proyecto con las tarjetas es el líder del equipo.
Todos los líderes de equipo con los que trabajé no saben cómo hacerlo, y no quieren hacerlo. Trabajan como trabajan, y utilizan jiru para considerar cumplidas sus responsabilidades de gestión. Después de todo, las personas que evalúan los líderes de equipo miran a jira, no al producto. Y las personas que miran el producto solo pueden generar nuevos tickets para la jira. No pueden evaluar a los programadores. ¡Pero la jira no afecta a nada! He visto productos terribles que tenían su tablero kanban en perfectas condiciones y productos excelentes que tenían tickets en la columna "en el trabajo" durante tres meses con el título "hacer un proyecto".
El argumento "Yo vi" no es muy bueno, pero servirá, porque estoy bastante seguro de que usted también lo vio todo.
En un sentido amplio, un líder de equipo debe asegurarse de que las personas que realmente quieran trabajar no tengan ningún problema. Y gente que no quiere ni echarse ni ser trasladada a la primera categoría. Todo el dolor del manejo radica en el segundo: hay muchos más. Y nadie hace nada con ellos. Solo un desarrollador puede determinar adecuadamente si un desarrollador funciona bien. Esta es una historia muy comprensible: debe revisar a fondo sus solicitudes de extracción y profundizar en sus tareas, y hay un problema: consume tanto tiempo como costaría hacerlo todo usted mismo. En resumen, no es una opción.
Por lo tanto, fueron los gerentes puros, no los desarrolladores, quienes decidieron identificar a los malos desarrolladores. Se les ocurrió un montón de sistemas con tickets, gráficos, todo tipo de revisiones de desempeño y un sombrero así. E incluso funcionaría, en algunos tontos. Pero incluso los peores desarrolladores son lo suficientemente inteligentes como para engañar a este sistema. Bueno, ya sabes cómo se hace. Miden todo en boletos, ¿verdad? Frio. Descompondré el "rediseño de la interfaz del formulario X" en diez tareas al estilo de "arreglar la etiqueta en el botón Y". La misma cantidad de trabajo, más tickets. El líder del equipo me pateaba en la cara por tales fintas.
Pero en el sistema actual, nunca hará eso. Después de todo, en primer lugar, cuantos más tickets se cierran, menos problemas tiene. En segundo lugar, está lo suficientemente cargado como para profundizar en mis tickets y mi código. En tercer lugar, lo hace él mismo, porque debido a sus deberes de liderazgo, también carece de la fuerza para desempeñarse bien. Y en cuarto lugar, y esto es lo más importante, puede que sea una de esas personas que no quiere trabajar.
Esta es mi experiencia, la experiencia de todos mis conocidos, pero tiene excepciones. Hay empresas donde el proceso de desarrollo realmente funciona muy bien. Te diré por qué, ganaron la lotería. Resultó que había muchas más personas que querían trabajar; con personas que no administran, todo irá bien. Incluso usan oropel gerencial con tableros para negocios, y su desempeño es claramente visible tanto por jir como por métricas intuitivas. Y cuando sus gerentes no desarrollados se interponen en el camino, tienen un gran producto detrás de ellos que les da el derecho de enviar a estos cabezas parlantes al infierno.
Estos equipos se reproducen a sí mismos: durante el proceso de contratación, aprueban intuitivamente solo a personas como ellos y tienen suficiente peso en la empresa como para no dar palabras decisivas a los RR.HH. que juegan con sus “métricas” y su psicología.
Pero un equipo así es una suerte fantástica. Y lo que suele pasar es esto. Para diez personas, tienes dos que quieren trabajar. Uno de ellos es líder de equipo y el otro renuncia. El desarrollo funciona mal y los gerentes vienen a arreglarlo. Y a partir de ese momento, no habrá posibilidad. Los gerentes construirán un proceso en torno a jira, tomarán el control de las cosas que no comprenden en absoluto. Construirán una contratación de personas cuyo trabajo no saben nada, comenzarán a invitar a los desarrolladores existentes allí que divertirán a ChSV, iniciarán sesión esta vez en el informe de tiempo y darán comentarios aleatorios. Y luego deciden a quién contratar, también al azar. Las personas que quieren trabajar se unirán de vez en cuando a estos equipos, donde se convertirán en holgazanes o no echarán raíces.
No quiero decir que los gerentes sean idiotas y no puedan hacer nada. Todavía saben cómo manejarse. Pero no por desarrolladores. Los desarrolladores solo pueden ser administrados por un desarrollador que realmente sepa cómo administrar. Tal persona arreglará el equipo con cualquier proporción de voluntad y no voluntad de trabajar.
La única lástima es que casi no existen. Para convertirse en un buen desarrollador, debe ser inteligente y aprender mucho. Para convertirse en un buen gerente, es necesario tener talento y mucho aprendizaje. ¿Y cuál es entonces la posibilidad de que una persona combine estas dos cualidades? Es lo mismo. Al mismo tiempo, la mayoría de los líderes de equipo de la industria se convirtieron en ellos, porque, bueno, alguien debería hacerlo. Absolutamente aleatorio.
Creo que debe aprender a comprender que el desarrollo es una habilidad, la gestión es la segunda habilidad y la gestión del desarrollo es la tercera habilidad que incluye partes de la primera. Y esto debería estudiarse por separado. Y de manera muy metódica y eficiente. Hasta que hagamos esto, tendremos desarrolladores que no pueden administrar desarrolladores y administradores que no pueden administrar desarrolladores.
Publicidad
Muchos clientes ya han apreciado los beneficios de los servidores épicos de Vdsina .
Estos son VDS económicos con procesadores AMD EPYC, frecuencia de núcleo de CPU de hasta 3.4 GHz. La configuración máxima le permitirá realizar casi cualquier idea: 128 núcleos de CPU, 512 GB de RAM, 4000 GB de NVMe. ¡También puedes pedir!
