Buen año nuevo a todos!
Inspirado en el artículo Negocios, los amo colegas de Verovir , así como en su propio artículo. Una charla nocturna sobre despidos (aunque este último merece una respuesta detallada por separado).
Colega, usted en el artículo ha identificado bien los puntos clave del problema que puede encontrar en el negocio de TI (y no solo).
Pero una evaluación objetiva y recomendaciones para cada uno de estos puntos ("lo que realmente sucedió y qué hacer") es una pregunta discutible.
// Por cierto, lo mismo ocurre con tu artículo anterior
Por ejemplo
Usted habló de un graduado de VMK que fácilmente dispersó a los líderes de su equipo y se fue a California, luego se perdieron los rastros.
Esta es una historia bien conocida de la era soviética, cuando a las fábricas no les gustaban los graduados que elaboraban varias normas por unidad de tiempo.
No les gustó porque "hoy es una hazaña, mañana es un plan".
Mañana, este graduado se irá a California, o se convertirá en una familia y una hipoteca, y se convertirá en el mismo líder del equipo que no atrapó a los ratones que despediste debido a él.
Pisaste un rastrillo, pero no notaste un golpe en la frente.
Esto es independiente de la calidad real de esos líderes de equipo (dependiendo de si su despido fue su error o si debieron ser despedidos no en relación con el graduado de VMK).
Escribes sobre el negocio, pero el negocio no se trata solo de las hazañas de choque en una sola tarea, con un alto factor de bus.
El negocio se trata de resolver tareas a gran escala con un equipo que se mueve lentamente (sí, con líderes de equipo como el suyo, con empleados que piensan como tomar y sacar descendientes del jardín de infantes, etc.), pero seguramente, como un rompehielos, e irreversiblemente barre todo a su paso y con un alto grado de probabilidad alcanza los resultados planificados.
Según mis colegas que estudiaron este tema, un equipo de cinco genios motivados rockstar lo hará en N tiempo, un equipo de cinco personas lo hará en 3xN tiempo.
Y esta evaluación me parece adecuada.
Tenga en cuenta que el aumento total en el precio será de aproximadamente 15xN, porque no solo debe pagar 5 salarios, sino pagarlos 3 veces más. Y esto sin contar otros gastos: una oficina más grande, más computadoras y otros gastos.
Pero este es un equipo. Con una gestión adecuada, se garantiza que llegará al resultado planificado.
Y, si hablamos de negocios , el equipo puede manejar las tareas en términos de volumen y escala, que los solitarios ya no pueden hacer frente.
Otro ejemplo. Un colega OlegGelezcov señaló que su artículo es de la serie que "los remeros no valen nada" (por cierto, su artículo anterior está en la misma estepa).
Es decir, en su mayor parte escribes "no importa cómo te traten, límpiate, saca conclusiones y sigue adelante".
Hablemos de remeros
Aparentemente, estamos hablando de desarrolladores (programadores) y en parte de ingenieros de control de calidad.
Recientemente, ha estado de moda comparar a los desarrolladores no solo con los remeros, sino también con los trabajadores de la máquina.
A ver si esto es cierto.
Para empezar, un desarrollador es un ingeniero, y un trabajador, incluso el más calificado, es un trabajador.
Y esta es una diferencia fundamental, de la cual todo lo demás se sigue, hasta diferencias de 180 grados.
¿Puede un desarrollador reemplazar a un probador, analista, PM?
Un probador es fácil.
Haga casos de prueba para su código, haga clic en todo y escriba autotests.
Además, el desarrollador todavía escribe pruebas de unidad e integración.
Sí, será un poco peor, porque el autor probará su código con los ojos cerrados (pero puede dárselo a otro desarrollador).
Análisis: si no es fácil, pero no es difícil.
Una parte del curso de capacitación para desarrolladores es precisamente el estudio del área temática, la declaración del problema y el modelado. Y ahora OOP, que no está de moda hoy, se trata exactamente de "esto".
PM'a? Bueno, si un desarrollador es más o menos capaz de ver tareas "desde arriba", más o menos sociables y generalmente amigos de su cabeza, entonces si no hay experiencia, entonces con dificultad, con menos calidad, pero puede hacerlo.
¿Es posible un reemplazo inverso? Especialmente si somos honestos con nosotros mismos y admitimos que los evaluadores, analistas y PM son principalmente graduados de universidades técnicas que francamente no han "retirado" la programación (y recientemente, la gente ha venido a "ingresar a TI" en absoluto partidos, y precisamente estas posiciones; las excepciones entran en desarrollo))?
Un probador: con dificultad, comenzando, muy probablemente, desde una posición junior, desde el estudio posterior de lenguajes y plataformas de desarrollo, patrones de desarrollo (en lugar de pruebas), Ciencias de la Computación en general, un cambio en el paradigma del pensamiento, pero puede.
En otras palabras, puede, pero no todos, y con muy grandes dificultades y gastos.
Analista? Si hay antecedentes en educación y trabajo de ingeniería, probablemente será capaz, pero menos probable que un probador.
Porque, con la rara excepción de analistas fuertes (y de hecho analistas , no "analistas"), aquellos que no han dominado el desarrollo acuden a los llamados analistas.
Y el hecho de que el desarrollo requiere una cierta composición psicológica (introversión, perseverancia, alta concentración; sí, ahora hay intentos de rehacer la industria para que, por el contrario, exista hiperactividad, pero también estamos discutiendo este problema), y moderno los analistas "en este sentido están claramente más lejos de los desarrolladores que los probadores.
En general, el concepto de análisis no se trata del papel que se denominó "análisis" en los procesos de desarrollo modernos.
En otras palabras, no más que sí.
PM? Como dice el refrán, "no hay tiempo para explicar". Con un alto grado de probabilidad, no, con muy pocas excepciones.
Y si no estamos hablando de un sistema cuando la compañía aumenta intencionalmente los gerentes de línea / PM de desarrolladores, y no de probadores y analistas.
Pero en el caso de la planta y los trabajadores, la situación es más bien un espejo.
En general, si envía al director, contador, comercializador a cursos de 3 meses, entonces, al menos, podrán reemplazar al tornero, soldador y cerrajero en las categorías iniciales.
Pero, ¿puede un trabajador reemplazar estos roles después de un curso de 3 meses?
Quizás un trabajador altamente capacitado pueda reemplazar a un contador (no el principal) después de los cursos y reducir el débito con el préstamo y transferir fondos y fondos entre cuentas (si será interesante para él es otra cuestión).
Director, comercializador, etc. Esto es claramente más difícil, si no hablar de excepciones explícitas.
En todo caso, la discusión anterior sobre diversas profesiones y roles no tiene como fin elevar a alguien en relación con los demás, y viceversa.
Esto se trata del hecho de que hay ciertos roles en el proceso de producción, y sobre el valor objetivo de cada rol, que se determina incluyendo (no) reemplazabilidad por representantes de otros roles.
Se trata del hecho de que todas estas charlas de moda en los últimos años sobre "remeros", "desarrolladores en la máquina", esto es solo un intento sistemático de minimizar el papel de los desarrolladores.
Aquellos que mueven este tema no tendrán éxito al final, porque existe la naturaleza de las cosas de las cuales todo lo demás fluye. Un desarrollador es un ingeniero , no un remero o un trabajador (con el debido respeto a este último).
Y tarde o temprano todo volverá al punto de partida, porque no funciona de otra manera, o todo se romperá cuando todos se vayan a QA, analistas, PM y nadie quiera ir a los desarrolladores (y no hay nadie más). )