Muito já foi dito sobre o gerenciamento de pessoas como um todo (de acordo com muitos, mais do que suficiente). Sobre o gerenciamento de programadores, levando em consideração as especificidades de suas tarefas, organização do trabalho e relações internas em uma equipe, é muito menos. Qualquer tentativa de resumir e analisar sua experiência de uma pessoa que cozinhou no ambiente de TI, como desenvolvedor e gerente, é de particular valor para aqueles que estão se preparando para seguir o mesmo caminho e entender como aplicar as teorias gerais de gerenciamento às realidades do programador.
J. Hank Rainwater, um programador da velha escola, é uma das pessoas que conhece todos os lugares difíceis no papel de líder técnico em vão, porque eles mesmos flutuavam neles. Seu livro "
Como roçar gatos " cativa por sua objetividade: descreve situações específicas conhecidas por todos, diferentes componentes e condições de trabalho da equipe e até soluções tecnológicas do autor (infelizmente, já desatualizadas). Em uma curta série de artigos, planejamos destacar tudo o que nos pareceu mais útil e relevante no livro - da tipologia dos funcionários às recomendações de comunicação com outras equipes.
Comece com uma pergunta razoável: por que, de fato, gatos? O próprio autor, como explicação, refere-se a uma citação de Helen Alman, que desenha essa analogia em seu livro Close to the Machine:
“Um dos meus conhecidos com gerentes de projeto uma vez comparou o processo de gerenciamento de programadores ao pastoreio de gatos. Ele queria dizer que os cães, olhando fielmente nos olhos, absolutamente não precisamos. Um bom programador precisa ser apreciado junto com todas as suas esquisitices. Por outro lado, todos esses bons programadores precisam ser, de alguma forma, movidos em uma direção. ”
Em primeiro lugar, os programadores são parentes de gatos pelo fato de que nem um nem outro têm uma tendência inata de se perder. Eles preferem andar por conta própria, e a cultura que se desenvolveu na esfera da TI há muito incentiva esse tipo de comportamento (ou, pelo menos, não o impede). Consequentemente, o gerente técnico enfrenta uma tarefa duplamente difícil: organizar pessoas solteiras em um grupo mais ou menos coeso, sem violar sua individualidade; provavelmente, você terá que aprimorar suas próprias habilidades ao trabalhar com pessoas.
A Rainwater define seu público-alvo da seguinte maneira: recém-chegados à gerência (desenvolvedores de ontem que receberam uma posição de liderança), líderes de pequenas equipes (até dez pessoas) trabalhando em vários projetos, de pequenas e médias empresas. Para uma escala maior, algumas técnicas não funcionarão mais, e os líderes técnicos mais experientes provavelmente já aprenderam muito por si mesmos. O livro foi desenvolvido para ajudar o líder no período de transição mais agudo e se preparar para futuras mudanças.
Se você observar de maneira ampla, um gerente iniciante enfrenta dois problemas principais: uma nova posição transforma fundamentalmente os mecanismos de sua interação, primeiro com as pessoas e, em segundo lugar, com os processos. Falaremos sobre o segundo em detalhes posteriormente, mas um erro comum deve ser mencionado imediatamente.
Muitos não podem aceitar que terão que desistir de parte de suas tarefas relacionadas à escrita de código, e quanto mais forte o programador, mais forte esse sentimento de protesto. A situação é agravada por um novo senso de responsabilidade por todo o código que a equipe produz. Como resultado, em vez de redistribuir tempo e dedicar horas ao trabalho administrativo, o gerente se preocupa com o lado técnico dos projetos - ele próprio faz todas as revisões, verifica meticulosamente o design ou até reescreve os fragmentos sem êxito. A mais persistente negligencia todas as outras responsabilidades não diretamente relacionadas ao código, e isso termina em desastre. Os mais sóbrios se transformam em lobisomens: durante o dia o líder, à noite o programador, e isso acaba em esgotamento.
Por esse motivo, a primeira coisa que um líder técnico deve fazer é reconhecer e aceitar a inevitabilidade das mudanças na estrutura do trabalho e se sintonizar por um período bastante longo de "desmembramento". O autor estima o período de adaptação em cerca de seis meses - somente a essa altura a maioria se acostuma com o novo papel e começa a se sentir confortável nele. Pode-se confortar o fato de que a definição de "técnico" não é uma frase vazia: quem lidera os desenvolvedores simplesmente não pode se dar ao luxo de deixar completamente de trabalhar com tecnologias, portanto, não há necessidade de temer que as atividades de gerenciamento a substituam.
Agora vamos para a segunda fonte de mudança - trabalhando com pessoas. Em uma posição de liderança, o programador precisa não apenas se dar bem com os membros da equipe, mas, falando de maneira brusca, usá-los como um recurso - identificar quem é capaz de quê e direcionar essas habilidades para onde elas são mais necessárias. Portanto, a tarefa se divide em duas partes: você precisa entender as pessoas e se comunicar com elas.
Para ajudar o leitor no primeiro parágrafo, Rainwater oferece uma classificação das "raças" de gatos de TI, que ele construiu com base em sua própria experiência e observações. Sua lista de raças resume tipos de desenvolvedores que ocorrem regularmente com características, pontos fortes e fracos distintos. Como qualquer outra, essa classificação não deve ser tomada como um padrão absoluto - na natureza, os tipos geralmente se misturam e se cruzam, são cada vez menos pronunciados. No entanto, este é um ponto de partida útil para analisar as características intelectuais e pessoais de seus programadores.
O autor divide as raças em três grupos: comum (encontrado com mais frequência), raro (apanhado ocasionalmente) e vira-latas (na sua forma original carregam menos valor que a massa total).
Raças comuns
ArquitetoFavorito da maioria dos gerentes. Ele se concentra na estrutura geral do código, vai da análise e construções abstratas à implementação de soluções específicas para eles no código. Força - gera boas idéias, às vezes pode liderar um projeto sozinho, desde o design até a forma final (embora algumas pessoas percam o interesse depois que a estrutura geral é delineada e dão o trabalho artesanal para desenvolvedores de nível inferior). Fraqueza - geralmente produz um código confuso e obscuro, com designs estranhos que apenas obedecem ao proprietário e é muito difícil fornecer suporte externo.
ConstrutivistaEle tem um prazer sincero do próprio processo de programação, se esforça para obter um bom resultado. O planejamento estratégico é geralmente indiferente, o código é escrito com um palpite, sem pensar muito na lógica geral. A distâncias curtas, isso não causa muito dano, e você pode confiar na qualidade do trabalho do construtivista. Quando o projeto cresce, a falta de lógica interna geralmente começa a afetar e as decisões de “correção” são usadas - lembramos que o construtivista está muito focado no resultado. Funciona muito bem em conjunto com um arquiteto. Documentos com relutância ("tudo está claro"), mas com a devida persistência da cabeça - bastante profundamente.
O artistaEu também conhecia a alegria de escrever código, mas seu elemento é a busca de soluções inesperadas e elegantes para implementar os requisitos fornecidos. Com lógica e organização, como regra, não há problemas. A principal desvantagem é o amor excessivo à arte e à experimentação, que incentiva a estender tarefas simples e a interromper os prazos. Tem algumas semelhanças com o arquiteto e o construtivista, mas geralmente se destaca pelo seu brilhante estilo de programação individual.
EngenheiroConsidera o desenvolvimento de software como um análogo virtual da montagem de hardware, com todas as conseqüências resultantes. Ele gosta muito de encaixar um no outro, montar módulos díspares em uma estrutura complexa para que tudo funcione, para encontrar um lugar para soluções de terceiros no sistema construído. As habilidades são certamente úteis, mas há uma maneira de deixar o engenheiro se deixar levar, a complexidade pode se transformar em um fim em si mesma. Complexidade excessiva e falta de flexibilidade do produto são duas vulnerabilidades dessa raça.
CientistaAo contrário dos artistas, ele considera a programação uma ciência exata - ele tenta seguir princípios fundamentais em tudo e evitar a “mordaça”. Muito pedante, esforçando-se para aperfeiçoar o código e alcançar a operação correta em qualquer condição, muitas vezes em detrimento de considerações práticas. Como um engenheiro, ele tende a complicar tudo desnecessariamente. Mas quando se trata de tarefas verdadeiramente complexas que exigem escrupulosidade e conhecimento, ele não tem preço.
LihachEle coloca a velocidade acima de tudo, incluindo a qualidade do código. Negligencia insignificâncias como comentar, design correto, seguindo os regulamentos aceitos. À primeira vista, ele fornece um resultado bom e bastante funcional, mas os testes detalhados revelam muitos problemas. Infelizmente, essa raça é cultivada pelos próprios líderes: os queimadores são mais frequentemente obtidos de jovens programadores que são instilados com prioridades falsas e que têm medo de não atender às expectativas.
Raças raras
O magoNa terminologia moderna, um mago geralmente é chamado de estrela do rock. Assume as tarefas mais difíceis e gerencia, encontra maneiras revolucionárias de resolver problemas, faz tudo no prazo e com eficiência. Mesmo com a manutenção de seu código, dificuldades especiais geralmente não surgem. Em geral, tudo parece maravilhoso, mas o líder técnico precisa manter os olhos abertos em dois aspectos. Primeiro, não se deve permitir dependência excessiva do mago - toda a equipe, incluindo o líder, corre o risco de se transformar em uma dança para um funcionário. Em segundo lugar, você precisa estar preparado para o fato de que um dia o mago o decepcionará da mesma forma - ninguém pode fazer milagres de forma consistente. Essa oportunidade deve ser aproveitada com calma e ter um plano de backup.
MinimalistaEle escreve um código surpreendentemente funcional de quantias muito modestas. Tudo parece harmonioso, claramente construído e anuncia inequivocamente sua nomeação. Esta raça é muito temperamental na escolha de tarefas e projetos; O minimalista lutará mais do que outros pelo direito de estabelecer a área de aplicação de suas habilidades. Ponto fraco - escolta. Ele luta com todas as suas forças para fazer alterações em seu código (para não mencionar o de outra pessoa) - ele simplesmente não está interessado em mexer nos detalhes quando a coisa principal é feita.
AnalogueDifere no pensamento específico, compensa suas dificuldades com abstrações com um amor por analogias. Nas reuniões, é difícil entender sua linha de pensamento, mas ele rapidamente entende o assunto. Como regra, eles escrevem um código bom e fácil de suportar, mas, em alguns casos, um mal-entendido de uma abstração pode retardá-lo. Acontece também que as analogias fracassam, especialmente se a analista destaca uma de suas amadas de tudo o que está tentando fazer. Você pode equilibrar as falhas do analista colocando-o em conjunto com o arquiteto - eles se matam ou criam algo extraordinário.
DublêEle adora truques espetaculares e está constantemente em busca de inovações tecnológicas que os entregam. De fato, não há retorno real sobre esse hobby: o dublê não pode pensar pragmaticamente, o valor real dessa ou daquela tecnologia para o produto final e o usuário permanece oculto para ele. Esse funcionário precisará monitorar e redirecionar constantemente seu entusiasmo para as tarefas prioritárias.
Mutts
A água da chuva destaca os mestiços em uma categoria separada, como gatos com algumas falhas óbvias, uma vantagem sobre as fraquezas em relação aos pontos fortes. Mas ele não chama para se livrar deles sem olhar. Muitos mestiços são bastante receptivos ao treinamento e podem gradualmente ser re-treinados em outras raças. Abaixo, fornecemos previsões e recomendações para diferentes tipos.
SlobberO principal provedor de código desleixado e desleixado. Frequentemente pula de um estilo para outro. Como um queimador, ele sacrifica o design e a aderência aos acordos adotados pela equipe, mas, diferentemente do queimador, ele não pode ser justificado nem pela alta velocidade do trabalho. É o código dele que às vezes precisa ser reescrito do zero - tão exaustivo e com muitos recursos para entendê-lo.
Desleixo é agudo e crônico. Se ele atacou um funcionário repentinamente, isso pode ser devido a problemas pessoais. Se essa é uma condição usual para ele, vale a pena considerar se faz sentido dedicar algum tempo à reciclagem. O principal critério aqui é o desejo e a prontidão do esloveno em fazer esforços. O esloveno, que geralmente gosta de seu trabalho, com a devida atenção do chefe ou mentor, pode muito bem ser reabilitado e aprender métodos de trabalho mais eficazes.
FreioPor um longo tempo, ele não pode assumir a tarefa, não sabe por onde começar, persegue as especificações na esperança desesperada de que elas tragam algum tipo de clareza. Como não é difícil adivinhar, a indecisão do freio vem da insegurança. É necessário agir aqui com base em onde essa incerteza veio. Se um desenvolvedor falhou miseravelmente no passado e agora está em pânico com medo de falhas, deixe-o ter a oportunidade de provar a si mesmo mesmo em tarefas pequenas e descomplicadas, para que esse medo desapareça gradualmente. Se o assunto é inexperiência, então, com o tempo e o conhecido apoio da equipe, tudo provavelmente se normalizará. Se essa indecisão é simplesmente um traço de caráter, é mais fácil dar ao pobre sujeito um modelo que o ajude a escolher um estilo e começar a trabalhar.
AmanteO amante carece de conhecimento, mas geralmente há motivação mais do que suficiente. É mais provável que essa espécie de híbridos entre em bons desenvolvedores. No entanto, seu progresso deve ser monitorado de perto - para avaliar habilidades, registrar conquistas que dêem motivos para enviá-las para tarefas mais responsáveis. Não se deve exagerar demais as expectativas: muitos estão exaustos quando confrontados com dificuldades ou com uma rotina inevitável no trabalho de um programador. De um modo geral, os amadores têm suas vantagens - em primeiro lugar, o notório visual fresco e desagradável, embora possa ser cansativo esperar até que eles pisem em todos os ancinhos e compreendam verdades comuns.
ProfanParece simplesmente chato. Geralmente, o novo líder os herda do antigo; a história de sua colocação na equipe permanece um mistério. Fazer algo por essas pessoas é difícil - o desenvolvimento requer constante auto-aperfeiçoamento, o que elas simplesmente não fazem. Se o próprio leigo está ciente de seu nível e não se distingue por ambições inadequadas, você pode tentar anexá-lo ao departamento de testes - algumas vezes, habilidades baixas não impedem as pessoas de encontrarem erros adequadamente. Aqueles que nem sequer estão conscientes de sua proximidade são melhores em não ter que lidar.
EcléticoUma mistura nuclear de um engenheiro, um artista esloveno e pouco talentoso. O código que ele escreve é um vinagrete indigesto de diferentes estilos e módulos. Diferente dos produtos desleixados, esse é um código que exige talento - na aparência, pode parecer que ele tenha algo até que você tente executá-lo. A principal questão da pessoa que lê o código eclético: "O que ele quis dizer?" Para corrigir a situação, você deve primeiro entender se essa confusão é realmente o resultado de algum tipo de pesquisa ou se você está tentando babar nas trilhas. O ecletismo benigno é muito beneficiado por revisões sistemáticas de código.
Finalmente, há outra raça que se destaca do resto em todos os sentidos - este é um
cowboy ou um lobo solitário. Os hábitos felinos o alcançam ao mais alto grau. Em seu ofício, um cowboy, por via de regra, é muito bom (caso contrário, ele simplesmente não pode ficar no lugar), no trabalho em equipe - é absolutamente inútil. Ele se distingue por sua determinação em jogar apenas de acordo com suas próprias regras: assumir projetos que lhe interessam, e nenhum outro, usar os meios que ele deseja, considerar exclusivamente seus planos e assim por diante. Os cowboys só têm uma maneira: de uma vez por todas, entender que eles não farão parte da equipe e decidir se você os valoriza o suficiente para suportar seus hábitos peculiares. Em geral, os cowboys são indispensáveis em dois casos: situações críticas e aparentemente sem esperança e projetos isolados que serão acompanhados por especialistas externos.
Então, listamos as raças que o autor encontrou com mais frequência. No entanto, algumas anotações devem ser feitas nessa classificação:- O líder não deve se considerar uma exceção à regra: ele tem experiência em programação, o que significa que ele próprio pertence a uma das raças. Essa é uma circunstância importante - sua abordagem individual para escrever código afetará a cultura da equipe como um todo. Por exemplo, em um grupo, o líder minimalista pode ceder documentação, porque nunca prestou a devida atenção, mesmo em seu próprio trabalho.
- : , , . , , , – .
- , , – ( ), ( ) ( ). , , – .
- , – , .
, . , .
№1
: , , -, . , – , : . O que fazer
: . , – , . . , , – , .
№2
: . , - , .
: – , . , , . , , – -. , , . , , – , , .
. , , , , .