En el desierto de talentos calificados, los desarrolladores de agua tienen demanda como el agua, incluso si son llevados a mano o insultados, pero esto es un hecho. Sin ellos, no habrá industria, y ellos mismos lo saben. Esto conduce a un sentido tan emocionante de auto-derecho, que rara vez se ve en la historia de la humanidad. Como resultado, nació todo un espectro de personalidades problemáticas muy brillantes.
Un buen desarrollador puede valer su peso en oro,
literalmente . En pocas profesiones, tales ingresos son posibles. Algunas de las personas más ricas del planeta solían ser programadores, por lo que ser un desarrollador en el momento correcto en el lugar correcto es uno de los caminos más fáciles y directos hacia una gran riqueza.
Pero con tales oportunidades a menudo viene una completa falta de respeto por los participantes del proyecto en otras profesiones. Esta falta de respeto puede llegar a ser tan profunda que da lugar a una creencia firme en la mente del desarrollador de que él no solo es el participante más valioso en el proyecto de software, sino que también es necesario para la empresa en su conjunto. Desafortunadamente, aunque solo un pequeño número de desarrolladores pueden acumular algo parecido a la riqueza, muchos se comportan como si estuvieran siguiendo a Mark Zuckerberg, Bill Gates o Steve Jobs; aunque está muy lejos de la verdad. Esto lleva a problemas de personalidad, que son tan emocionantes de ver desde un lado como temibles de contemplar en uno mismo.
Las siguientes son
identidades problemáticas entre los desarrolladores de software:
Prima donna
El desarrollador está tan convencido de su indispensabilidad que se vuelve arrogante e imposible de liderar.
El problema
En cierto nivel, para administrar al empleado, debe hacer lo que usted dice. La prima donna no se puede controlar, porque por su propia naturaleza no cree que funcione para usted. En su opinión, es un privilegio trabajar con él. Se considera completamente indispensable y correcto en cualquier discusión.
Contrariamente a su propia convicción, la prima donna no es necesariamente un desarrollador calificado (ver
tipo estrella de rock ). Su arrogancia se basa en la presentación de su lugar en la organización, y no en las habilidades técnicas reales. Como resultado, las prima donnas con demasiada frecuencia califican su nivel de habilidad mucho más alto que el de sus pares,
aunque en realidad este no es el caso . Esto generalmente lleva al hecho de que a la prima donna generalmente no le gustan los colegas.
Puedes identificar una prima donna con frases típicas:
- "Esto es estúpido, no lo haré de esa manera"
- "Tenemos que hacerlo así".
- "Si no te gusta, puedes hablar con mi gerente"
- "Bueno, ya veremos".
- "Iré a hablar con tu jefe y veré qué dice"
La prima donna no acepta el liderazgo. Él ve cualquier intento de liderazgo como un insulto, ya que está por encima de rendir cuentas por sus acciones. Este problema de personalidad se encuentra comúnmente entre los desarrolladores de toda la vida que están profundamente involucrados en el éxito temprano de las empresas. Ahora, años después, gracias a muchos años de relaciones con los fundadores de la compañía, considera que su opinión es más alta que la de un simple gerente de nivel medio.
La prima donna no representa un peligro material para el proyecto, ya que generalmente no hace nada, solo sacude la ley. Sin embargo, afecta negativamente la moral del equipo, especialmente los desarrolladores nuevos y más productivos. Por lo tanto, debe implementarse para que el proyecto funcione sin problemas.
Solución
La solución para la diva es refutar la creencia básica:
que él es insustituible y, por lo tanto, puede hacer lo que quiera . La forma más directa de refutar esta creencia es contratar a un reemplazo para que trabaje en estrecha colaboración con él. Para transmitir adecuadamente a la prima donna que este es realmente su reemplazo, se deben cumplir dos condiciones:
- El reemplazo debe ser más calificado.
- Es necesario aclararle a la prima donna que su reemplazo no tiene otro trabajo que seguir la sombra de la prima donna y aprender cómo reemplazarlo.
Cuanto más rápido sea el reemplazo, reunirá todo el conocimiento sobre el código heredado que la prima donna puede poseer (vea los tipos de desarrolladores que conservan
el código heredado y el
criador de rehenes ), más rápido la prima donna volverá a controlar. El efecto puede ser dramático: todo puede cambiar en solo unos días. En forma, la diva comienza a realizar una función adicional para su reemplazo. En última instancia, ya no es indispensable y, por lo tanto, ya no es una diva, sino simplemente un empleado pobre.
La única esperanza de prima donna es mantener un sentido de estatus: obtener un ascenso a un puesto gerencial (ver a un desarrollador como
marcar gerentes ). Cuanto mejor sea su habilidad, más pronto, cuando aparezca un reemplazo, intentará hacerlo. Sin embargo, no se recomienda el aumento, ya que es probable que vea el despido de los desarrolladores de los cuales la diva es responsable. Por lo tanto, cuando rechaza una solicitud de promoción, solo tiene dos opciones: estar a la par con otros desarrolladores o irse. En cualquier caso, su problema está resuelto.
Idealista
El desarrollador está tan obsesionado con lograr la elegancia arquitectónica y la excelencia del código que olvida que su trabajo debería beneficiar al negocio.
- Puede mutar en optimista o diva
- Peligroso en combinación con tecnología fan
- Posibilidad de corrección: no
- Peligro del proyecto: extremadamente alto
El problema
La profesión de ingeniero de software requiere un equilibrio constante de dos tareas opuestas:
- El deseo de beneficiar al negocio (y cobrar).
- El deseo de escribir un excelente software (y estar orgulloso).
El idealista ignoró por completo el objetivo de beneficiar al negocio y, en cambio, se centró únicamente en escribir un excelente software.
El desarrollador idealista suele ser muy inteligente, experimentado y profesional. Él realmente sabe de lo que está hablando. Él realmente sabe cómo escribir un excelente software, y si se le da suficiente tiempo, puede crear el sistema perfecto. El problema es que
él cree que tiene todo el tiempo del mundo y libertad total , aunque esto está lejos de ser el caso.
En lugar de comprometerse, se centró en crear el sistema perfecto. Él cree que esto es mejor para los negocios. No los confunda con los científicos que crean algo "absoluto" o "genial": los idealistas creen sinceramente que su sistema ideal es el más adecuado para el desarrollo de la empresa. Es debido a la firmeza de esta fe que son tan difíciles de corregir.
Los idealistas son especialmente peligrosos para un proyecto porque generalmente tienen poder sobre otros desarrolladores clave, porque representan el ideal por el que se esfuerzan los desarrolladores, por lo que es muy fácil lograr que otros programadores estén a su lado, porque todos los desarrolladores quieren estar orgullosos del software que escriben. Por
lo tanto,
toman como rehenes a todo el equipo de desarrollo , y ahora estás en su poder. Si tiene suerte, comenzarán a proporcionar valor al negocio, pero solo será un efecto secundario aleatorio en su búsqueda para crear un excelente software. De hecho, los beneficios para la empresa aparecerán solo al final del trabajo, pero no pueden informarle el plazo ni evaluar este beneficio. En verdad, ni siquiera están interesados en completar, porque es el proceso en sí mismo, no el objetivo, lo que los satisface.
Solución
Resumimos los rasgos idealistas:
- Muy inteligente, experimentado y profesional.
- Sinceramente cree que su sistema es mejor para el futuro de la empresa.
En muchos sentidos, es un muy buen empleado, y si se miran las empresas más innovadoras del mundo, tienen muchos idealistas en los departamentos de investigación y desarrollo. Sin embargo, las mejores compañías tienen tres cosas que el resto no tiene:
- El personal de gestión es tan competente como los idealistas, ofreciendo controles y equilibrios para sus decisiones técnicas.
- La expectativa de que un cierto número de proyectos fracasará, que es el costo habitual de hacer negocios.
- Un gran presupuesto para continuar financiando proyectos que no son rentables.
Si su empresa tiene estas tres cosas, deje en paz al idealista, déjelo hacer lo que quiera. Pero si usted, como la mayoría de las empresas, no tiene estas condiciones lujosas, entonces aparece un problema real, ya que casi todo lo que hace conducirá al desastre:
- Si lo descarta de inmediato, los desarrolladores leales pronto pueden seguirlo.
- Si establece reglas estrictas, entonces él puede desconectarse mentalmente del proyecto, lo que lo dejará sin orientación técnica.
- Si lo deja en paz, las autoridades eventualmente se cansarán de la falta de progreso tangible.
Para obligar a un idealista a cambiar su comportamiento, necesita encontrar a alguien que pueda convencerlo. Esta persona debe demostrarle al idealista que él también puede crear un sistema excelente. Esto es importante, ya que una persona sin competencia técnica simplemente será ignorada como incapaz de comprender el genio de un diseño ideal.
Si se encuentra a una persona con tanta confianza, tendrá que derivar lenta y metódicamente al idealista de su forma idealista de pensar. Esto requiere que un profesional altamente inteligente y experimentado esté listo para hacer lo que cree que es correcto. Las posibilidades de esto son pocas y, por lo tanto, hay pocas posibilidades de corregir al idealista.
Estrella de rock
El desarrollador es tan talentoso, tan productivo, tan importante que si se va, todo el proyecto colapsará.
- Puede mutar en un secuestrador y una diva
- Es peligroso en combinación con un administrador de tipos optimista
- Posibilidad de corrección: no
- Peligro del proyecto: extremadamente alto
El problema
En la industria del software, el término "estrella de rock" a menudo es utilizado por reclutadores que intentan atraer a los desarrolladores inflando su ego, es decir, "estamos buscando varios desarrolladores de estrellas de rock". Es difícil encontrar verdaderas estrellas de rock, ya que son programadores ideales:
- No hay problema que no puedan resolver (y rápidamente).
- Trabajan toda la noche para cumplir el plazo.
- Prácticamente no hay errores en su código o cualquier error se corrige rápidamente.
- Asumen las partes más difíciles del proyecto.
- Suelen ser muy aficionados a los colegas.
Lamentablemente, una vez contratados, se vuelven indispensables en el proyecto.
Una estrella de rock se parece a un agujero negro: el trabajo se acumula a su alrededor y, en última instancia, inevitablemente es absorbido para hacerse. Puede llegar al punto de quitarles el trabajo a los desarrolladores más lentos para cumplir con los plazos, para alivio de todos. Si el proyecto se encuentra en un dilema, salvarán la situación. Si sucede algo dramático e inesperado, sabrán qué hacer. Son realmente geniales, y cada reclutador lo sabe.
Los reclutadores llamarán a una estrella de rock varias veces al día. Su reputación está por delante de ellos. Las empresas siempre quieren atraer a las estrellas de rock porque entienden su valor y, en muchos casos, harán casi todo lo posible por conseguirlas. Por lo tanto, la situación es que hay alguien indispensable para su proyecto, que cada segunda empresa quiere atraer. Si lo hacen, el proyecto fallará. El caso clásico es cuando se colocan demasiados huevos en una canasta.
Solución
No hay "solución" para una estrella de rock. Al final, solo un tonto querrá "arreglarlo", porque es el desarrollador más productivo hasta la fecha. Todo lo que puede hacer es mitigar el daño creando un equipo alrededor que pueda funcionar de manera efectiva si se va. Lo más probable es que necesite varios desarrolladores para reemplazar el desempeño de una estrella de rock, pero al menos puede sobrevivir a su partida.
Para verificar qué tan mala es su situación, preste mucha atención a la productividad del desarrollador cuando una estrella de rock se va de vacaciones. Si durante su ausencia semanal todo el desarrollo se detiene, entonces debe redoblar los esfuerzos para llevar a otros desarrolladores al nivel en el que puedan mantener el desarrollo del proyecto en ausencia de una estrella de rock.
Esto puede ser difícil si los desarrolladores están acostumbrados al hecho de que él hace frente a problemas complejos, se vuelven vagos y presumidos. Existe la posibilidad de que con la repentina partida de la estrella de rock, otros desarrolladores tomen medidas. Pero, muy probablemente, lo aman tanto que lo seguirán a una nueva compañía.
Marcado en gerentes
Un desarrollador que decidió evitar dificultades de programación y convertirse en uno de los gerentes.
El problema
La programación es difícil de aprender. Requiere la capacidad de resolver problemas rápidamente, una gran cantidad de conocimiento e incluso más experiencia real. A diferencia de los campos profesionales comparables, este conocimiento y experiencia se vuelven obsoletos mucho más rápido (a veces en cuestión de meses), lo que requiere el desarrollo constante de nuevos métodos, tecnologías y herramientas. Lanzar gerentes
quiere deshacerse de este escándalo y ve una salida en la administración .
Como regla general, para los gerentes de desarrollo, los requisitos para las habilidades de programación son más bajos que para los desarrolladores. Se dedica tiempo a reuniones, enviar correos electrónicos o incluso caminar y conversar con otras personas. Los gerentes también tienden a ganar más que los codificadores, pero con el estatus vienen los poderes. Esta es una opción obvia para los desarrolladores que desean deshacerse de la escritura de software.
El problema con el desarrollador, que comenzó a pensar en la carrera del gerente, es que busca demostrar sus habilidades de gestión con la esperanza de mejorar, en
lugar de pensar en la programación . Para practicar las habilidades de gestión, el futuro gerente trata de ordenar a otros desarrolladores: asigna trabajo, habla en las reuniones y, por regla general, busca participar en la toma de decisiones más estratégicas. Por lo tanto, no son igualmente amados por otros desarrolladores y otros gerentes que ven una amenaza para su trabajo.
Solución
Es imposible resolver el problema del futuro gerente, porque ya ha tomado una decisión clara sobre su carrera. Una vez que se toma la decisión, no hay vuelta atrás. No puedes obligarlo a escribir programas nuevamente. Incluso si es forzado, pronto encontrará la razón por la que comenzó a pensar en la carrera de un gerente: el tipo no es muy bueno en la programación. Debido a la complejidad de esta situación, muchos programadores y gerentes obtienen lo que quieren: ascenso al puesto de gerente, si hay una vacante.
Como regla general, los desarrolladores en esta posición no son particularmente dañinos para el proyecto, porque su productividad es demasiado baja y, por lo general, no tienen la confianza especial de los desarrolladores o gerentes. A menudo, estas personas a lo largo de sus carreras pasan el tiempo en la organización, y la
alta gerencia lucha por encontrar una aplicación para ellos . Como tal, pueden volverse peligrosos si se les confía una misión crítica, pero como esto se puede evitar por completo, pueden seguir siendo un pequeño factor molesto.
Tomador de rehenes
Un desarrollador que ha escrito una pieza de software crítico y no permite que nadie trabaje en ella para mantener su indispensabilidad.
El problema
Es importante para cualquier persona con obligaciones financieras garantizar la seguridad de su lugar de trabajo y salario. Además, trabajar con código familiar es mucho más fácil que trabajar con código desconocido. De la combinación de estos dos deseos, nace un secuestrador: un desarrollador que
escribió y solo posee una pieza crítica de software, negándose a trabajar en cualquier otra cosa .
Como regla, este es un mal ingeniero de software, lo que irónicamente se convierte en una ventaja importante: su código
generalmente no es comprensible para nadie más , por lo que otros desarrolladores tienen miedo de meterse en un pantano, por temor a hacer más daño que bien. Por lo tanto, todo el trabajo nuevo en un sistema crítico se transfiere al invasor, continuando así el círculo vicioso.
El secuestrador generalmente toma una posición defensiva y de confrontación, está absolutamente cerrado a las críticas o la cooperación con respecto a su base de código. Si realmente lo lleva a una esquina, amenazará con irse, y dado que nadie más quiere enfrentarse a un producto mal diseñado y escrito, ese farol rara vez se castiga. Pueden convertirse en un cuello de botella en el proyecto, ya que todo el destino del proyecto dependerá de su deseo y capacidad de emitir un código.
Solución
No importa cuán peligroso sea el criador de rehenes, la solución es simple: asigne a dos o más desarrolladores la responsabilidad de una parte del sistema invasor, transfiéralo a otra parte. , , .
, .
El problema
. « » , . , .
. , , , (.
) . , , , . , , .
- . — , . « », , , - .
Solución
, :
- , . .
- , .
- . . , , .
- , . , .
- , , .
, . , . , , .
, .
El problema
, . , , . - .
, :
- .
- « » , .
- (. ), .
- , .
- Las funciones implementadas están llenas de errores.
- Los desarrolladores experimentados evitan o se niegan a trabajar con ellos.
- Cuando se les pregunta sobre el progreso, inventan excusas y a menudo toman una posición defensiva.
- Solicitan un puesto gerencial (ver marcado de gerentes ) para brindar "más beneficios".
Toda la industria del software sufre un problema de incompetencia. Este es un ejemplo simple de oferta y demanda cuando no hay suficientes desarrolladores calificados en el mercado laboral.Solución
, . , , . , .
, . , , — , .
, , . :
- , (. )
- , .
, ,
. , . ( ), .
, , .
El problema
, . , . , - , .
: . / , -. , , , , . , ; , , .
El optimista fundamentalmente no comprende el impacto negativo de tales demoras en el éxito general del proyecto. También puede considerar que la evaluación en sí misma es una práctica inútil, ya que nada puede ser estimado con precisión. Por lo tanto, puede evaluar de manera impresionante o dar un número arbitrario sin ningún análisis.Solución
Afortunadamente, un optimista puede corregirse siguiendo algunas reglas:- Pídales que evalúen solo el código con el que están familiarizados.
- Solicite una evaluación solo para las tecnologías con las que están familiarizados.
- Nunca pida evaluar el momento de la implementación de nuevas funciones, solo mejore las existentes.
- Se debe tener cuidado para asegurarse de que comprenden completamente todos los requisitos: no pueden interpretar libremente los requisitos sobre la marcha.
- «TODO» , . .
- : , .
, , , .
, :
, , , . , , , .
, , .
El problema
, , . , . , , .
. , , , -, . :
. , .
Solución
, . — , . , , :
- , .
- , .
- . , .
, . , .
, , , , , .
El problema
, , , ? , , . , . , :
, , .
:
- . : , . , , .
:
- , : . , , .
- , , , .
- , , , .
- , , , - .
- , , .
- , — , .
- Se convencieron de que la sumisión completa es el camino hacia el crecimiento profesional, lo cual es muy triste, ya que esto casi nunca es cierto en el campo innovador del desarrollo de software.
- Estos son realmente ex militares que trajeron consigo una mentalidad específica.
Como resultado, no importa cuán agradable pueda parecer tener un soldado a su mando, esto no es bueno.Solución
, . — . , , . , , . .
, , . , . , . , , «», .
, , , . , , . , . .
, . , .
, , , .
El problema
. -, . .
- : , . , , -.
. , . , , . , , .
Solución
Los fanáticos de la tecnología se arreglarán si la compañía ha instalado una pila de tecnología estándar. Entonces solo necesita asegurarse de que los desarrolladores no se desvíen de él. Si no tiene una pila de tecnología instalada, se recomienda encarecidamente definirla de antemano, ya que será inconveniente ingresarla después de que el ventilador de tecnología comience a activarse.
Es probable que la noticia de que no pueda usar su nueva tecnología perjudique la moral de un amante de la tecnología, pero esta moral se puede restaurar rápidamente al pedirle que haga una presentación sobre esta nueva tecnología. Esta es una decisión extremadamente saludable, porque después de la presentación, el equipo puede discutir juntos si tiene sentido expandir la pila de tecnologías corporativas. La mayoría de los amantes de la tecnología estarán satisfechos con tal prueba, incluso si no les gusta la decisión final.
Guardián de legado
Un desarrollador cuya única capacidad es mantener un software desactualizado y, por lo tanto, no puede asumir un nuevo trabajo.
El problema
Cuando un nuevo desarrollador llega a la empresa, generalmente está lleno de fuego y pasión, tratando de demostrar su valía en todas las formas posibles. Pero con el tiempo, el lugar de la pasión toma complacencia: el desarrollador cree que la experiencia en la empresa le otorga ciertos privilegios. Por sí mismo, reconoce la obligación de mantener sus sistemas, pero no emprender el desarrollo de nuevas partes.
El problema con el custodio de código heredado está relacionado con el escalado: simplemente no están incluidos en el conjunto de recursos disponibles para nuevos trabajos. En este punto, surge la pregunta de si puede permitirse mantenerlos en el personal, es decir, si otros desarrolladores pueden asumir su tarea de dar servicio al código heredado. Por lo general, es difícil convencer a otros desarrolladores para que hagan esto por dos razones:
- El código antiguo generalmente está mal escrito y es difícil trabajar con él.
- El apoyo es un camino de carrera sin salida porque no estás haciendo nada nuevo o innovador, por lo que puedes ser marcado.
Es por eso que los antiguos mantenedores han estado con la compañía durante tanto tiempo. A menudo han estado con la empresa desde su inicio y son los autores del software en el que se basa la empresa. Sin embargo, a medida que la empresa creció, no avanzaron en el servicio o no intentaron dominar nuevas habilidades o nuevas partes del sistema, como resultado de lo cual estaban firmemente unidos al único código que conocían.
Solución
Legacy Code Keeper no crea problemas si comprende que no está entre los recursos para trabajar en nuevos proyectos. En el mejor de los casos, puede pedirle que corrija errores e implemente pequeñas mejoras de funciones. El único problema surge si prohíben que otros se familiaricen con su parte del sistema (ver
secuestrador ).
The Guardian no se puede arreglar porque no tiene ese deseo. Tiene la mentalidad de un trabajador de una fábrica: tuerce la misma tuerca todos los días a lo largo de su carrera y luego se retira. Esta actitud no se puede cambiar, porque es la esencia del hombre.
Una de las opciones que puede cambiar esta actitud es si una persona experimenta eventos importantes en la vida (boda, parto, compra de una casa, etc.), lo que requerirá ganancias adicionales. En este caso, comprenderá que el soporte para software obsoleto no conducirá a un aumento. Desafortunadamente, no controlas este factor.
Ver también: