No deserto de talentos qualificados, os desenvolvedores de água são procurados como a água, mesmo que sejam transportados em mãos ou insultados, mas isso é um fato. Sem eles, não haverá indústria, e eles próprios estão bem cientes disso. Isso leva a um empolgante senso de auto-direito, que raramente é visto na história da humanidade. Como resultado, nasceu todo um espectro de personalidades problemáticas muito brilhantes.
Um bom desenvolvedor pode valer seu peso em ouro -
literalmente . Em poucas profissões, essa renda é possível. Algumas das pessoas mais ricas do planeta costumavam ser programadores, portanto, ser um desenvolvedor no momento certo, no lugar certo, é um dos caminhos mais fáceis e diretos para obter grande riqueza.
Mas com essas oportunidades, muitas vezes surge uma completa falta de respeito pelos participantes do projeto em outras profissões. Essa falta de respeito pode se tornar tão profunda que leva a uma firme crença na mente do desenvolvedor de que ele não é apenas o participante mais valioso do projeto de software, mas também é necessário para a empresa como um todo. Infelizmente, embora apenas um pequeno número de desenvolvedores consiga acumular algo semelhante a riqueza, muitos se comportam como se estivessem seguindo Mark Zuckerberg, Bill Gates ou Steve Jobs; embora esteja muito longe da verdade. Isso leva a problemas de personalidade, que são tão emocionantes de assistir de lado quanto assustadores de se considerar.
A seguir,
identidades problemáticas entre desenvolvedores de software:
Prima donna
O desenvolvedor está tão convencido de sua indispensabilidade que se torna arrogante e impossível de liderar.
O problema
Em um certo nível, para gerenciar o funcionário, ele deve fazer o que você diz. A prima donna não pode ser controlada, porque, por sua própria natureza, não acredita que funcione para você. Na sua opinião, é seu privilégio trabalhar com ele. Ele se considera completamente indispensável e correto em qualquer discussão.
Ao contrário de sua própria convicção, a prima donna não é necessariamente uma desenvolvedora qualificada (veja o
tipo de estrela do rock ). Sua arrogância é baseada na apresentação de seu lugar na organização, e não em habilidades técnicas reais. Como resultado, as prima donnas frequentemente avaliam seu nível de habilidade muito mais alto que o de seus pares,
embora esse não seja realmente o caso . Isso geralmente leva ao fato de que a prima donna geralmente não é apreciada pelos colegas.
Você pode identificar uma prima donna por frases típicas:
- "Isso é estúpido - não vou fazer dessa maneira"
- "Temos que fazer assim."
- "Se você não gostar, pode conversar com meu gerente"
- "Bem, vamos ver."
- "Vou conversar com seu chefe e ver o que ele diz"
A prima donna não aceita liderança. Ele vê qualquer tentativa de liderança como um insulto, pois está acima de ser responsabilizado por suas ações. Esse problema de personalidade é comumente encontrado entre desenvolvedores de longa data que estão profundamente envolvidos no sucesso inicial das empresas. Agora, anos depois, graças a muitos anos de relacionamento com os fundadores da empresa, ele considera sua opinião maior do que a de um simples gerente de nível médio.
A prima donna não representa um perigo material para o projeto, uma vez que geralmente não faz nada, mas apenas infringe a lei. No entanto, isso afeta negativamente o moral da equipe, especialmente desenvolvedores novos e mais produtivos. Portanto, ele deve ser colocado em prática para que o projeto seja executado sem problemas.
Solução
A solução para a diva é refutar a crença básica:
que ele é insubstituível e, portanto, pode fazer o que quiser . A maneira mais direta de refutar essa crença é contratar um substituto para trabalhar em estreita colaboração com ele. Para transmitir adequadamente à prima donna que essa é realmente sua substituição, duas condições devem ser atendidas:
- A substituição deve ser mais qualificada.
- É necessário deixar claro para a prima donna que seu substituto não tem outro trabalho senão seguir a sombra da prima donna e aprender a substituí-la.
Quanto mais rápido o substituto reunir todo o conhecimento sobre o código legado que a prima donna possa possuir (consulte os tipos de desenvolvedores,
o detentor do código legado e o
gerador de reféns ), mais rápido a prima donna retornará ao controle. O efeito pode ser dramático: tudo pode mudar em apenas alguns dias. Na forma, a diva começa a desempenhar uma função adicional em sua substituição. Em última análise, ele não é mais indispensável e, portanto, não é mais uma diva, mas simplesmente um funcionário pobre.
A única esperança da prima donna é manter um senso de status - obter uma promoção para uma posição gerencial (veja um desenvolvedor como
marcar gerentes ). Quanto melhor o seu conhecimento, mais cedo quando um substituto aparecer, ele tentará fazê-lo. No entanto, o aumento não é recomendado, porque você provavelmente verá a demissão dos desenvolvedores pelos quais a diva é responsável. Portanto, ao rejeitar uma solicitação de promoção, ele tem apenas duas opções: ficar em pé de igualdade com outros desenvolvedores ou sair. De qualquer forma, seu problema foi resolvido.
Idealista
O desenvolvedor está tão obcecado em alcançar a elegância arquitetônica e a excelência em código que esquece que seu trabalho deve beneficiar os negócios.
O problema
A profissão de engenheiro de software exige um equilíbrio constante de duas tarefas opostas:
- O desejo de beneficiar o negócio (e ser pago).
- O desejo de escrever um excelente software (e ter orgulho).
O idealista ignorou completamente o objetivo de beneficiar os negócios e, em vez disso, se concentrou apenas na criação de ótimos softwares.
O desenvolvedor idealista é geralmente muito inteligente, experiente e profissional. Ele realmente sabe do que está falando. Ele realmente sabe escrever um ótimo software e, se tiver tempo suficiente, poderá criar o sistema perfeito. O problema é que
ele acredita que tem todo o tempo do mundo e completa liberdade , embora isso esteja longe de ser o caso.
Em vez de se comprometer, ele se concentrou em criar o sistema perfeito. Ele acredita que isso é melhor para os negócios. Não os confunda com cientistas que criam algo “absoluto” ou “legal”: idealistas sinceramente acreditam que seu sistema ideal é mais adequado para o desenvolvimento da empresa. É por causa da firmeza dessa fé que eles são tão difíceis de corrigir.
Os idealistas são especialmente perigosos para um projeto porque geralmente têm poder sobre outros desenvolvedores importantes, porque representam o ideal pelo qual os desenvolvedores estão se esforçando, por isso são tão fáceis de levar outros programadores para o lado deles, porque todos os desenvolvedores querem se orgulhar do software que escrevem. Assim,
eles tomam toda a equipe de desenvolvimento como refém , e agora você está no poder deles. Se você tiver sorte, eles começarão a agregar valor aos negócios, mas será apenas um efeito colateral aleatório na busca de criar um ótimo software. De fato, os benefícios para os negócios aparecerão apenas no final do trabalho, mas eles não podem informar o prazo ou avaliar esse benefício. Na verdade, eles nem sequer estão interessados em concluir, porque é o próprio processo, não o objetivo, que os satisfaz.
Solução
Resumimos os traços idealistas:
- Muito inteligente, experiente e profissional.
- Atenciosamente, acredita que seu sistema é melhor para o futuro da empresa.
De muitas maneiras, ele é um funcionário muito bom e, se você observar as empresas mais inovadoras do mundo, elas têm muitos idealistas nos departamentos de pesquisa e desenvolvimento. No entanto, as melhores empresas têm três coisas que o resto não tem:
- A equipe de gerenciamento é tão competente quanto os idealistas, oferecendo freios e contrapesos para suas decisões técnicas.
- A expectativa de que um certo número de projetos falhe, que é o custo usual de fazer negócios.
- Um orçamento grande para continuar financiando projetos que não são lucrativos.
Se sua empresa tem essas três coisas, deixe o idealista em paz, deixe-o fazer o que ele quer. Mas se você, como a maioria das empresas, não tem essas condições luxuosas, um problema real aparece, pois quase tudo o que você faz leva ao desastre:
- Se você imediatamente o dispensar, desenvolvedores leais poderão segui-lo em breve.
- Se você definir regras rígidas, ele poderá se desconectar mentalmente do projeto, o que o deixará sem orientação técnica.
- Se você o deixar em paz, as autoridades eventualmente se cansarão da falta de progresso tangível.
Para forçar um idealista a mudar o comportamento, você precisa encontrar alguém que possa convencê-lo. Essa pessoa deve demonstrar ao idealista que ele também pode criar um excelente sistema. Isso é importante, pois uma pessoa sem competência técnica será simplesmente ignorada como incapaz de entender a genialidade de um projeto ideal.
Se uma pessoa com tanta confiança for encontrada, ela terá que derivar lenta e metodicamente o idealista de sua maneira idealista de pensar. Isso exige que um profissional experiente e altamente inteligente esteja pronto para fazer o que acha certo. As chances disso são poucas e, portanto, há pouca chance de corrigir o idealista.
Estrela do rock
O desenvolvedor é tão talentoso, tão produtivo, tão importante que, se ele for embora, todo o projeto entrará em colapso.
- Pode se transformar em um seqüestrador e diva
- É perigoso em combinação com um gerente de tipo otimista
- Possibilidade de correção: não
- Risco do projeto: extremamente alto
O problema
Na indústria de software, o termo "estrela do rock" é freqüentemente usado por recrutadores que tentam atrair desenvolvedores inflando seu ego, ou seja, "estamos procurando vários desenvolvedores de estrelas do rock". É difícil encontrar estrelas do rock reais, pois são programadores ideais:
- Não há problema que eles não possam resolver (e rapidamente).
- Eles trabalham a noite toda para cumprir o prazo.
- Praticamente não há bugs em seu código ou quaisquer bugs são rapidamente corrigidos.
- Eles assumem as partes mais difíceis do projeto.
- Eles geralmente gostam muito de colegas.
Infelizmente, uma vez contratados, eles se tornam indispensáveis no projeto.
Uma estrela do rock se parece com um buraco negro: o trabalho se acumula ao seu redor e acaba sendo inevitavelmente sugado para ser feito. Pode ser que eles tirem o trabalho de desenvolvedores mais lentos para cumprir os prazos - para alívio de todos. Se o projeto se encontrar em um dilema, eles salvarão a situação. Se algo dramático e inesperado acontecer, eles saberão o que fazer. Eles são realmente ótimos - e todo recrutador sabe disso.
Os recrutadores telefonam para uma estrela do rock várias vezes ao dia. A reputação deles está à frente deles. As empresas sempre querem atrair estrelas do rock, porque entendem seu valor e, em muitos casos, farão quase tudo para obtê-las. Portanto, a situação é que existe alguém indispensável para o seu projeto, que toda segunda empresa deseja atrair. Se o fizerem, o projeto falhará. O caso clássico é quando muitos ovos são colocados em uma cesta.
Solução
Não existe "solução" para uma estrela do rock. No final, apenas um tolo vai querer "consertar", porque ele é o desenvolvedor mais produtivo até o momento. Tudo o que você pode fazer é mitigar o dano criando uma equipe que funcione efetivamente se ele sair. Provavelmente, você precisará de vários desenvolvedores para substituir o desempenho de uma estrela do rock, mas pelo menos você pode sobreviver à partida dele.
Para verificar o quão ruim é a sua situação, preste muita atenção à produtividade do desenvolvedor quando um astro do rock sai de férias. Se durante sua ausência semanal todo o desenvolvimento parar, será necessário redobrar os esforços para levar outros desenvolvedores ao nível em que eles possam manter o desenvolvimento do projeto na ausência de uma estrela do rock.
Isso pode ser difícil se os desenvolvedores estiverem acostumados ao fato de que ele lida com problemas complexos, eles se tornam preguiçosos e presunçosos. Há uma chance de que, com a saída repentina do astro do rock, outros desenvolvedores entrem em ação. Mas, provavelmente, eles o amam tanto que o seguirão para uma nova empresa.
Marcação nos gerentes
Um desenvolvedor que decidiu evitar dificuldades de programação e se tornar um dos gerentes.
O problema
Programação é difícil de aprender. Requer a capacidade de resolver rapidamente problemas, uma grande quantidade de conhecimento e uma experiência ainda mais real. Diferentemente de campos profissionais comparáveis, esse conhecimento e experiência tornam-se obsoletos muito mais rapidamente (às vezes em meses), o que exige o desenvolvimento constante de novos métodos, tecnologias e ferramentas. Gerir gerentes
quer se livrar desse barulho e vê uma saída na administração .
Como regra, para gerentes de desenvolvimento, os requisitos para habilidades de programação são mais baixos do que para desenvolvedores. O tempo é gasto em reuniões, envio de e-mails ou até mesmo andando e conversando com outras pessoas. Os gerentes também tendem a ganhar mais do que codificadores, mas com status vêm poderes. Esta é uma escolha óbvia para desenvolvedores que desejam se livrar de escrever software.
O problema com o desenvolvedor, que começou a pensar na carreira do gerente, é que ele procura demonstrar suas habilidades de gerenciamento na esperança de melhorar, em
vez de pensar em programação . Para praticar as habilidades de gerenciamento, o futuro gerente tenta comandar colegas desenvolvedores: atribui trabalho, fala em reuniões e, via de regra, procura participar da tomada de decisões mais estratégicas. Portanto, eles não são igualmente amados por colegas desenvolvedores e outros gerentes que vêem uma ameaça ao seu trabalho.
Solução
É impossível resolver o problema do futuro gerente, porque ele já fez uma escolha clara de carreira. Uma vez tomada a decisão, não há como voltar atrás. Você não pode forçá-lo a escrever programas novamente. Mesmo se forçado, você encontrará em breve o motivo pelo qual ele começou a pensar na carreira de um gerente: o cara não é muito bom em programação. Devido à complexidade dessa situação, muitos programadores e gerentes conseguem o que desejam: promoção para o cargo de gerente, se houver uma vaga.
Como regra, os desenvolvedores nesta posição não são particularmente prejudiciais ao projeto, porque sua produtividade é muito baixa e geralmente não têm a confiança especial de desenvolvedores ou gerentes. Freqüentemente, essas pessoas ao longo de suas carreiras frequentam a organização e a
gerência sênior luta para encontrar um aplicativo para elas . Como tal, eles podem se tornar perigosos se forem confiados a uma missão crítica, mas, como isso pode ser completamente evitado, eles podem permanecer com segurança apenas um pequeno fator irritante.
Tomador de reféns
Um desenvolvedor que escreveu um software crítico e não permite que ninguém trabalhe nele para manter sua indispensabilidade.
O problema
É importante para qualquer pessoa com obrigações financeiras garantir a segurança de seu local de trabalho e salário. Além disso, trabalhar com código familiar é muito mais fácil do que trabalhar com código desconhecido. A partir da combinação desses dois desejos, nasce um seqüestrador - um desenvolvedor que
escreveu sozinho e possui um software crítico, recusando-se a trabalhar em qualquer outra coisa .
Como regra geral, este é um péssimo engenheiro de software, que ironicamente se torna uma vantagem importante: seu código
geralmente não é compreensível para mais ninguém ; portanto, outros desenvolvedores têm medo de entrar em um pântano, temendo causar mais mal do que bem. Portanto, todo novo trabalho em um sistema crítico é transferido para o invasor, continuando assim o ciclo vicioso.
O seqüestrador geralmente assume uma posição defensiva e de confronto; ele está absolutamente fechado a críticas ou cooperação em relação à sua base de códigos. Se você realmente o levar a um canto, ele ameaçará sair e, como ninguém mais quer usar um produto mal projetado e escrito, esse blefe raramente é punido. Eles podem se tornar um gargalo no projeto, pois todo o destino do projeto dependerá de seu desejo e capacidade de emitir um código.
Solução
Não importa o quão perigoso seja o criador de reféns, a solução é simples: atribua a dois ou mais desenvolvedores a responsabilidade por parte do sistema invasor, transfira-o para outra parte. , , .
, .
O problema
. « » , . , .
. , , , (.
) . , , , . , , .
- . — , . « », , , - .
Solução
, :
- , . .
- , .
- . . , , .
- , . , .
- , , .
, . , . , , .
, .
O problema
, . , , . - .
, :
- .
- « » , .
- (. ), .
- , .
- As funções implementadas estão cheias de erros.
- Desenvolvedores experientes evitam ou se recusam a trabalhar com eles.
- Quando perguntados sobre o progresso, eles dão desculpas e muitas vezes assumem uma posição defensiva.
- Eles se candidatam a uma posição gerencial (consulte a marcação de gerentes ) para trazer "mais benefícios".
Toda a indústria de software sofre de um problema de incompetência. Este é um exemplo simples de oferta e demanda quando não há desenvolvedores qualificados suficientes no mercado de trabalho.Solução
, . , , . , .
, . , , — , .
, , . :
- , (. )
- , .
, ,
. , . ( ), .
, , .
- Pode se transformar em um pessimista
- Perigoso quando combinado com um gerente de projeto otimista
- Possibilidade de correção: alta
- Perigo para o projeto: médio
O problema
Subestimar prazos é um sintoma tão comum na indústria de software que muitos nem consideram isso um problema. Todos sempre subestimam o tempo e, em muitos casos, isso é aceito como parte do negócio. No entanto, o desenvolvedor otimista leva o problema a um nível totalmente novo, pois quase sempre desiste do trabalho muito mais tarde.: . / , -. , , , , . , ; , , .
O otimista fundamentalmente não entende o impacto negativo de tais atrasos no sucesso geral do projeto. Ele também pode considerar que a avaliação em si é uma prática fútil, já que nada pode ser estimado com precisão. Assim, ele pode avaliar ou fornecer de forma impressionante um número arbitrário sem nenhuma análise.Solução
Felizmente, um otimista pode ser corrigido seguindo algumas regras:- Peça-lhes para avaliar apenas o código com o qual estão familiarizados.
- Peça uma avaliação apenas para as tecnologias que eles conhecem.
- Nunca peça para avaliar o momento da implementação de novas funções, mas apenas melhore as já existentes.
- Deve-se tomar cuidado para garantir que eles compreendam completamente todos os requisitos - eles não podem interpretar livremente os requisitos em tempo real.
- «TODO» , . .
- : , .
, , , .
, :
, , , . , , , .
, , .
O problema
, , . , . , , .
. , , , -, . :
- - .
- , , - .
- Quando eles concordarem rapidamente, se você mover ligeiramente a data para uma data anterior, eles também concordariam com essa data. Isso significa que, entre as duas datas, não é preciso muito tempo para concluir a tarefa.
Um pessimista pode reduzir a competitividade de uma empresa. Se você estiver envolvido em uma corrida com um concorrente, sempre será mais lento que ele.Solução
Os pessimistas nascem por culpa de uma organização que pune o não cumprimento dos prazos. A reação natural das pessoas é solicitar o máximo de tempo possível, a fim de minimizar a probabilidade de punição. Isso pode parecer uma solução fácil, mas três coisas funcionam contra você:- O trabalho pessimista é muito menos estressante do que o trabalho normal.
- Os pessimistas geralmente são recompensados e promovidos com mais frequência do que aqueles que perdem prazos importantes.
- Os negócios devem ser mais tolerantes com o atraso. Quando uma certa cultura de desenvolvimento é estabelecida, a maioria das empresas não é capaz disso.
Portanto, o problema é corrigível, mas geralmente não há vontade de corrigi-lo. Por sua natureza, os pessimistas não representam uma ameaça ao projeto, mas são potencialmente muito perigosos para a viabilidade futura da empresa.Um soldado
Um desenvolvedor que faz exatamente o que diz, sem questionar, independentemente de estar certo.
O problema
, , , ? , , . , . , :
, , .
:
- . : , . , , .
:
- , : . , , .
- , , , .
- , , , .
- , , , - .
- , , .
- , — , .
- , — , , .
- , .
, , .
Solução
Se você der as ordens corretas, o soldado não causará nenhum problema. De fato, com forte liderança, a presença de um destacamento de soldados é uma arma muito eficaz. Mas se você precisar de feedback dos desenvolvedores para ajudar a liderar o projeto, não terá essa cooperação. Isso deixa você em uma situação de suspense, quando você nem sabe que está perdendo alguma coisa. Mas o soldado não vai contar.Se você pode determinar o motivo pelo qual o soldado lhe obedece implicitamente, há uma chance de corrigi-lo. No entanto, por natureza, ele não diz abertamente por que se tornou assim. Normalmente, um soldado prefere se comunicar sobre tópicos de trabalho específicos. Se você pressionar e perguntar se há algum problema, a resposta mais provável será "Não", independentemente de seus verdadeiros sentimentos., , , . , , . , . .
, . , .
, , , .
O problema
. -, . .
- : , . , , -.
. , . , , . , , .
Solução
Os fãs de tecnologia se consertarão se a empresa tiver instalado uma pilha de tecnologia padrão. Então você só precisa garantir que os desenvolvedores não se desviem dela. Se você não possui uma pilha de tecnologia instalada, é altamente recomendável defini-la com antecedência, pois será inconveniente inseri-la após o ventilador da tecnologia começar a se tornar ativo.
As notícias de que você não pode usar sua nova tecnologia provavelmente prejudicam o moral de um amante da tecnologia, mas esse moral pode ser rapidamente restaurado pedindo-lhe que faça uma apresentação sobre essa nova tecnologia. Essa é uma decisão extremamente saudável, porque após a apresentação, a equipe pode discutir em conjunto se faz sentido expandir a pilha de tecnologias corporativas. A maioria dos amantes de tecnologia ficará satisfeita com esse teste, mesmo que não gostem da decisão final.
Guardião do Legado
Um desenvolvedor cuja única capacidade é manter um software desatualizado e, portanto, não pode assumir um novo trabalho.
- Pode se transformar em um invasor ou soldado refém
- Perigoso em conjunto com um designer criativo
- Possibilidade de correção: não
- Perigo para o projeto: não
O problema
Quando um novo desenvolvedor chega à empresa, ele geralmente está cheio de fogo e paixão, tentando provar a si mesmo de todas as maneiras possíveis. Mas, com o tempo, o lugar da paixão exige complacência: o desenvolvedor acredita que a experiência na empresa lhe concede certos privilégios. Por si mesmo, ele reconhece a obrigação de manter seus sistemas, mas não de empreender o desenvolvimento de novas peças.
O problema com o guardião do código legado está relacionado à escala: eles simplesmente não são incluídos no pool de recursos disponíveis para novos trabalhos. Nesse ponto, surge a questão de saber se você pode mantê-los na equipe, ou seja, se outros desenvolvedores podem assumir sua tarefa de atender ao código legado. Geralmente é difícil convencer outros desenvolvedores a fazer isso por dois motivos:
- O código antigo geralmente é mal escrito e difícil de trabalhar.
- O suporte é uma carreira sem saída, porque você não está fazendo nada de novo ou inovador, para o qual pode ser marcado.
É por isso que antigos mantenedores estão na empresa há tanto tempo. Muitas vezes, eles estão na empresa desde o início e são os autores do software no qual a empresa é construída. No entanto, à medida que a empresa crescia, eles não avançavam no serviço ou não tentavam dominar novas habilidades ou novas partes do sistema, pelo que estavam firmemente ligadas ao único código que conheciam.
Solução
O detentor de código herdado não cria problemas se você entender que não está entre os recursos para trabalhar em novos projetos. Na melhor das hipóteses, você pode pedir a ele para corrigir erros e implementar pequenos aprimoramentos de recursos. O único problema surge se eles proíbem que outros se familiarizem com sua parte do sistema (veja o
tomador de reféns ).
O Guardião não pode ser consertado porque ele não tem esse desejo. Ele tem a mentalidade de um operário: torcer a mesma porca todos os dias ao longo de sua carreira e depois se aposentar. Essa atitude não pode ser mudada, porque é a essência do homem.
Uma das opções que podem mudar essa atitude é se uma pessoa experimenta eventos significativos na vida (casamento, parto, compra de uma casa etc.), o que exigirá renda adicional. Nesse caso, ele entenderá que o suporte a software desatualizado não levará a um aumento. Infelizmente, você não controla esse fator.
Veja também: