Continuamos a compartilhar trechos do
guia de sobrevivência para techlides iniciantes da J.H. Rainwater. Na primeira série, falamos sobre com quais tipos de desenvolvedores o gerente geralmente trabalha; Agora vamos tentar entender o que fazer com todo esse zoológico. As atividades organizacionais em uma equipe técnica podem ser divididas em duas partes - coisas mais ou menos nativas (como revisões de código e gerenciamento de arquitetura) e tudo o que a vida de um programador não se preparou - ou seja, gerenciar pessoas e processos. Vamos lidar com um estranho primeiro.
Priorização
A primeira coisa que geralmente derruba um líder recém-assado é uma avalanche das mais diversas informações. Esse estado de coisas é bastante lógico: quem está à frente da equipe é menos fechado em sua estrutura e está envolvido em mais processos, mas não fica mais fácil. Como resultado, o líder técnico geralmente começa a se dispersar - considerando seu dever de responder a todos os sinais, ele agarra tudo de uma só vez, passa de uma tarefa para outra e perde o que mais precisa de atenção.
Há apenas uma saída - filtrar esse fluxo de informações, separando o que está diretamente relacionado à tarefa principal (liberar um código que atenda aos requisitos comerciais, com um prazo acordado) e enviando o principal para o backlog. Mas, a princípio, os critérios para essa classificação podem não ser óbvios. Para iniciantes, absolutamente tudo parece importante.
Para complicar, o fato de muitos estímulos excitarem emoções que impedem uma avaliação sensata da importância e urgência do problema. Os sinais recebidos podem causar interesse (uma anomalia curiosa foi encontrada no código), culpa (o designer lembra que ele já solicitou várias vezes a implementação da função que deseja implementar), apreensão (o usuário reclama da atualização).
Para sistematizar com êxito todos os pedidos e informações, o autor sugere usar a seguinte matriz para processá-los:
- Como os novos dados afetam o escopo do projeto, a decisão de design e o prazo do projeto?
- A fonte de informação é confiável? Caso contrário, pode ser ignorado?
- Devo reagir imediatamente ao recebimento de informações ou posso esperar um pouco?
- Onde e como salvar as informações para que, se necessário, possam ser rapidamente tratadas?
- Qual é o período de validade das informações? Quando isso se torna irrelevante?
- Como essas informações se comparam com o que já é conhecido sobre o projeto?
Como você pode ver, essa matriz ajuda a separar os grãos do joio em vários aspectos: livrar-se de informações francamente inúteis ou não-confiáveis, afastar o que mais pode ser movido e avaliar a importância das informações estritamente para o projeto atual. No entanto, perguntas sobre os métodos de tempo e armazenamento sugerem que as informações que não são relevantes no momento não devem ser descartadas como irrelevantes em princípio - esse é outro extremo que levará a equipe à estagnação a longo prazo. Falaremos mais sobre isso mais tarde, quando discutirmos os conceitos de "liderança" e "liderança".
Projetos em expansão
O próximo ponto problemático é a avaliação de volumes e termos de trabalho. Novamente, por algum tempo, “nadar” nessa área é quase inevitável para um técnico iniciante - é necessária experiência para poder revisar todos os componentes do projeto de uma só vez, sem perder nada, e desde a primeira tentativa de definir para cada tipo de trabalho, incluindo termos não familiares e adequados. Mas mesmo a experiência adquirida não salva de um determinado erro e não é possível reduzi-lo a zero. A extrema precisão no planejamento do trabalho é prejudicada por duas leis que Humphrey formulou apropriadamente:
Qualquer processo durará mais do que o esperado. Sempre aparece algo em que você não pensou.
Baseado em tudo isso, o autor pede para tratar o problema filosoficamente. Muito provavelmente, como primeira aproximação, você não poderá levar em consideração funções menos óbvias ou complicações imprevisíveis, e elas exigirão um recurso adicional que você não hipotecou. Para essas surpresas, você precisa estar preparado e preparar uma equipe - para ensinar as pessoas a se reconstruírem rapidamente, a fim de "consertar buracos", para deixar um pouco de tempo reservado para circunstâncias imprevistas. O que não pode ser feito em qualquer caso é considerar a proliferação natural como uma emergência e procurar culpar os responsáveis, especialmente em outros departamentos (e isso sempre parece especialmente tentador). Então você semeia inimizade entre as equipes e não faz nada para resolver o problema.
No entanto, não se deve cair no fatalismo completo: o crescimento do projeto é, no entanto, o resultado de falhas no planejamento. Você não será capaz de se livrar completamente deles, mas pode e deve reduzir a concentração.
Se transferirmos as leis de Humphrey para a realidade do programador, fica claro que o planejamento diminui por dois motivos: análise insuficiente dos detalhes e estimativas desnecessariamente otimistas da duração do design do produto de software. O otimismo entre os gerentes geralmente desaparece de maneira natural: várias vezes, quebrando os prazos, você sempre começa a jogar pelo seguro. Quanto aos detalhes, essa habilidade também vem com experiência, mas vale a pena desde o início ter uma idéia geral de como deve ser o roteiro.
Por exemplo, se você embarcar em um projeto armado com esse documento, haverá muitos desastres naturais e aborrecimentos à sua frente:
Se o roteiro for mais semelhante ao exemplo abaixo, as chances de um resultado feliz aumentam significativamente:
Além desses dois motivos, a Rainwater lista alguns fatores de risco adicionais que Robert Glass, autor de um livro triste sobre projetos de desastres no campo de TI, destacou:
- Especificação inadequada dos objetivos do projeto
- Aplicação de tecnologia nova para esta empresa
- Metodologia de gerenciamento de projetos anual / ausente
- Falta de especialistas líderes no grupo
- Interrupção de acordos por fabricantes de hardware / software
Pesquisa de idioma comum
Você pode pensar que estamos falando sobre habilidades de comunicação de talentos comunicativos - mas não, o significado do título é muito mais literal. Em diferentes empresas, equipes de programadores são formadas por diferentes motivos. Se você tiver sorte, pode ser o responsável pelas pessoas que trabalham com sua pilha de tecnologia nativa. Mas, muitas vezes, equipes mistas aparecem, onde funcionários diferentes falam idiomas diferentes. Essa confusão às vezes dificulta a vida do líder.
Um dos deveres do líder é supervisionar todas as atividades da equipe, para garantir que todo o código que entra no mundo esteja funcionando, de alta qualidade e sem complexidade excessiva. Se você não estiver familiarizado com as ferramentas que seus subordinados usam ao desenvolver, suas mãos estão atadas. Você não pode conduzir revisões de código de forma independente, aprenderá sobre erros sérios apenas na fase de testes, o que derruba todo o ritmo do trabalho e, falando grosso modo, é muito mais fácil dirigir pelo nariz.
O que fazer nesta situação? Em geral, existem duas maneiras. Se o conjunto de idiomas e tecnologias não for muito grande e mutável, você não poderá poupar tempo e tentar dominá-los pelo menos em um nível básico. Esta é talvez a melhor saída - para que você não precise depender de ninguém, você receberá informações diretamente, o que significa que você pode evitar o “telefone inoperante” ao discutir funcionalidades, requisitos e prazos.
Se você não conseguir aprender os idiomas necessários, precisará procurar maneiras de delegar essa responsabilidade. Forme o núcleo de assistentes que podem fornecer um feedback objetivo e honesto sobre cada tecnologia desconhecida (se apenas um funcionário for o proprietário, esse método naturalmente não funcionará).
Aprofundar o seu conhecimento em questões relacionadas a tecnologias e ferramentas também é útil por outro motivo - esta é a única maneira de se tornar um líder técnico no sentido pleno da palavra. Em seu sistema terminológico, o autor divide os conceitos de "gerente" e "líder". Um gerente é aquele que organiza o trabalho, resolve os problemas do dia-a-dia e garante que as tarefas atuais sejam concluídas no prazo e adequadamente. Um líder é um estrategista que pensa fora dos prazos de controle, define a direção geral do movimento de sua equipe, eleva a fasquia, repensa e otimiza processos. Obviamente, na equipe de desenvolvimento, esse trabalho visionário requer um bom conhecimento do mercado de tecnologia. Em segundo plano, o líder técnico constantemente estima que o kit de ferramentas atual está desatualizado e precisa ser substituído, monitora novos produtos e, ao mesmo tempo, tem uma perspectiva ampla o suficiente para avaliar seus méritos reais (e não cair na síndrome de Stunt).
Na primeira parte do artigo, falamos sobre o fato de o líder não precisar se preocupar em deixar de trabalhar com a tecnologia - e para aqueles que marcam líderes, isso é realmente verdade. Mas aqui faz sentido repetir o aviso do mesmo local: não espere, ao mesmo tempo, fugir das responsabilidades do gerente. O gerenciamento envolve o equilíbrio entre as duas funções, que às vezes entram em conflito, mas permanecem quase igualmente (o gerenciamento é um pouco inferior) necessário para a sobrevivência da equipe. Aprimore suas habilidades organizacionais - quanto menos tempo uma rotina consumir, mais rápido você crescerá como especialista técnico. Se as tarefas diárias forem deixadas ao acaso, reinará o caos, no qual não haverá mais nenhuma estratégia.
Colheita de rebanho
Agora nos voltamos para o segundo bloco de problemas - o notório trabalho com as pessoas. Vamos começar desde o início: antes de falar sobre como gerenciar um recurso humano, você precisa descobrir onde obtê-lo. Mesmo que você tenha a equipe estabelecida, mais cedo ou mais tarde surgirá a questão sobre o recrutamento de funcionários. Antes, analisamos os tipos de programadores e apontamos para aqueles que deveriam ser perseguidos em primeiro lugar. Agora você precisa entender como agir para identificar as qualidades necessárias nos candidatos e não se decepcionar com sua escolha.
O autor oferece as seguintes recomendações para entrevistas:
- Dê ao candidato uma tarefa de teste. Defina para um funcionário em potencial uma tarefa que ele precisará resolver imediatamente ou leve-a para sua casa e resolva-a na data de vencimento.
- Certifique-se de realizar uma prova oral das habilidades do candidato - para poder avaliar o conhecimento dele e a capacidade de pensar com clareza em uma situação estressante.
- Na medida do possível, anote as funções do funcionário desejado, todas as tarefas que ele deve executar e entregue essa lista ao candidato para revisão. Portanto, a conversa se tornará imediatamente mais objetiva e, em regra, mais franca.
- Não se limite a uma reunião. Será muito bom se o candidato se comunicar não apenas com você, mas também com o “núcleo” mencionado acima - seus assistentes, deputados, desenvolvedores líderes da equipe. Mas organizar um show com toda a equipe não vale a pena, isso já é demais.
- A verificação de qualidades pessoais, testes tipológicos e similares são um passo possível, mas opcional. Apenas recorra a ele se o candidato não se opuser e você tiver ferramentas de avaliação confiáveis.
Falando em contratação, não se pode deixar de mencionar o outro lado - a demissão de trabalhadores que derrubam a equipe. Aqui, a Rainwater assume uma posição bastante difícil e aconselha, sem hesitação, a se livrar daqueles que se mostraram incompetentes ou problemáticos. A melhor posição é a política de um aviso: oferece a uma pessoa a oportunidade de melhorar, mas não permite o abuso desse direito. Se um funcionário entrou na "lista negra" e você teve uma conversa com ele, é necessário supervisionar seus sucessos adicionais com cuidado especial. Isso requer um esforço adicional, portanto, dar uma terceira chance já é um desperdício injustificado.
Além disso, não apenas a “causa comum” abstrata geralmente sofre negligência de um membro da equipe, mas também pessoas muito específicas que precisam corrigir seus erros ou tolerar o fato de que ele estraga os resultados do trabalho deles. A indulgência excessiva, portanto, é paga às suas custas e dificilmente fortalecerá sua posição de liderança.
Organização do trabalho dos empregados
Ambiente confortávelO livro presta muita atenção a esse aspecto. Alcançar a produtividade máxima de seus funcionários é uma responsabilidade direta do líder, mas a alta produtividade requer alta concentração, e a concentração é impossível se o programador estiver cercado por substâncias irritantes de todos os lados. Portanto, o líder deve fazer tudo o que estiver ao seu alcance para proporcionar à equipe boas condições de trabalho.
As recomendações específicas para projetar um escritório que a Rainwater fornece em locais parecem um pouco idílicas (por exemplo, em um escritório separado para um irmão), e em locais que parecem ecos de um passado distante e difícil (cada desenvolvedor deve ter seu próprio computador). Mas o princípio geral ainda permanece razoável e aplicável: para que os programadores alcancem sucesso em suas atividades, eles devem ter a oportunidade, por um lado, de trabalhar em equipe por algum tempo e, por outro lado, fazer lavagem cerebral apenas. Para o primeiro, você precisa de locais de treinamento devidamente equipados: salas de reuniões com projetores, equipes de lazer (idealmente) com as notórias mesas de tênis ou consoles de jogos. No segundo, é necessário organizar o espaço disponível para que as pessoas sejam distraídas o mínimo possível com ruídos, tremulações, cheiros e outros fatores que distraem. Se as condições forem ruins, permita que os funcionários, especialmente aqueles que são valiosos e confiáveis, trabalhem em casa.
Um mínimo obrigatório de comodidades também inclui equipamentos modernos e de alta qualidade, que o desenvolvedor pode, dentro do razoável, configurar a seu próprio critério. Se os carros são fracos e desatualizados, não há necessidade de falar sobre avanços tecnológicos e você não tem apenas uma operação silenciosa e sem problemas. Para programas de teste, devem ser alocados dispositivos especiais que reproduzem as características padrão do usuário.
Horas de trabalhoA pilha de tarefas do consultor técnico, que descrevemos, sugere que a duração do seu dia de trabalho quase dobrará. Mas aqui você deve ter cuidado. O problema é que, com seu regime de trabalho, o próprio gerente, sem querer, define o tom para todo o departamento. Se você se atrasar, os trabalhadores assumirão que algo semelhante também é esperado deles. Como resultado, o processamento pode entrar na carne e no sangue da sua cultura local - e isso está cheio de problemas.
Em primeiro lugar, nem todos ficarão felizes com esse estado de coisas. Primeiro de tudo, o processamento atingirá aqueles que são sobrecarregados por obrigações adicionais, por exemplo, familiares. Se houver muitas dessas pessoas, a situação na equipe será tensa. Bem, e em segundo lugar, o autor, como muitos outros depois dele, aponta que as horas extras de trabalho são mais propensas a prejudicar a produtividade - tanto por causa do cansaço quanto por uma diminuição na motivação. É mais sábio exigir da escola um trabalho eficaz do que incutir hábitos que levarão ao esgotamento.
Distribuição e supervisão de tarefasSejamos honestos: mesmo as condições ideais e uma agenda suave em si mesmas não incentivarão as pessoas a se auto-organizarem e trabalharem diligentemente. Entre outras coisas, é necessário um chefe para distribuir o trabalho e garantir que ele seja realizado. Alguma parte do seu tempo deve ser ocupada pelo controle - a propósito, isso também contribui para a concentração.
O autor aconselha a não dividir demais os "períodos do relatório" para os subordinados, a não sufocá-los com observação constante com uma solicitação diária de resultados. É mais sábio determinar uma lista de tarefas para cada semana e avaliar a quantidade de trabalho realizado no mesmo período. Em períodos particularmente quentes, as listas terão que ser ajustadas mesmo neste pequeno intervalo devido a questões urgentes que surjam e mudanças nas prioridades. O líder deve ter em mente todas essas mudanças (e nas realidades modernas - e fazê-las nos sistemas contábeis apropriados).
Se um líder chega a uma equipe “estrangeira” com um ritmo de trabalho já estabelecido, vale a pena pedir a cada funcionário que pinte suas tarefas habituais da mesma maneira. Essa documentação pode revelar muitas coisas interessantes - não apenas quem e o que está envolvido e como o gerenciamento foi realizado antes, mas também o que as pessoas geralmente pensam sobre suas responsabilidades.
Quanto ao conteúdo dessas listas, é claro, em muitos aspectos, será determinado pelas habilidades dos funcionários e pelos requisitos da empresa. Mas com tudo isso, o livro avança a idéia de que é necessário rotacionar as tarefas o máximo possível - o desenvolvedor não deve fazer a mesma coisa de semana para semana. Existem várias razões para isso. Em primeiro lugar, ajuda a manter um clima saudável na equipe: sem ofensa, porque alguém constantemente fica com as coisas mais desagradáveis ou, inversamente, as mais interessantes, menos sensação de rotina e monotonia no trabalho. Em segundo lugar, os programadores precisam permanecer em boa forma intelectual - uma variedade de tarefas contribuirá para isso. Finalmente, com essa alternância, será necessário um mínimo de esforço para formar uma bancada.
O Reinwater atribui grande importância ao banco. A principal idéia aqui é que, em caso de doença, férias, demissão, morte prematura de qualquer um dos desenvolvedores, a equipe deve incluir pessoas que possam cumprir suas funções - pelo menos durante esse período, até contratar um substituto. Isso não apenas garante o bom funcionamento do departamento, mas também evita alguns outros problemas (por exemplo, a aguda dependência da empresa em relação à Wizards). Portanto, é necessário manter o interesse dos funcionários em tecnologias relevantes, de todas as formas possíveis para incentivar a cooperação e a participação em projetos "estrangeiros".
A propósito, o próprio chefe não está protegido do fator de queda de tijolos. Portanto, assim que você se acostumar um pouco, comece a pensar em quem você seria seu sucessor. Isso não é apenas resseguro, mas também é um bom exercício para delegar tarefas - ao preparar um sucessor, você involuntariamente precisa pensar em qual trabalho é o mais fácil e seguro de confiar a outras pessoas. Durante as remoções, esse conhecimento será muito útil.
E a última: até agora, tratava-se principalmente dos interesses da equipe e dos superiores, mas não perdia de vista o fato de ainda trabalharmos com pessoas. As preferências e características pessoais dos funcionários devem ser levadas em consideração sempre que possível. Você não deve esperar mobilidade especial de alguém que seja difícil de mudar de um para o outro; por razões de justiça, não deve enviar os freios para uma tarefa que ele tem medo de não lidar e assim por diante. Aqui, novamente, descansamos contra a tese de que precisamos monitorar cuidadosamente nossos funcionários e conhecê-los bem.
Motivação e incentivo
Mas chega de chicotes, vamos falar sobre os mais agradáveis - aqueles biscoitos de gengibre que os programadores devem obter do trabalho. A Rainwater nomeia os seguintes tipos de pão de gengibre (em ordem de prioridade): salário, progressão na carreira, palavras gentis e, finalmente, regalia corporativa abstrata.
Em termos de remuneração, os gerentes que deixaram o desenvolvimento não são muito propensos a serem exigentes, mas geralmente caem no extremo oposto e superestimam as expectativas dos funcionários. Ao decidir sobre taxas, lembre-se dos seguintes fatores: produtividade, experiência, eficácia, pontualidade das tarefas, taxa média atual, condições de mercado e padrões corporativos. Um erro comum é aumentar os salários antecipadamente, esperando que isso incentive os trabalhadores a dar tudo de si. , – , .
, , , . , , .
– . , , , (, , «»). . – , . , , , .
, . – , -, , , , . : , . « » , . ( – ) – .