Como faço para ter sucesso como desenvolvedor líder? [em espera]

Tornei-me o desenvolvedor líder de um projeto específico, mas estou tendo dificuldades em focar no cenário geral e em garantir que todas as partes do projeto sejam cobertas.

O que devo ter em mente ao gerenciar este projeto? Como posso garantir que tudo seja tratado da maneira que deveria?

Eu já vi essa viagem com outros desenvolvedores que fazem a transição para sênior ou líder. Aqui estão algumas sugestões que eu fiz para outras pessoas.

• Entenda qual é o objetivo do projeto.

Frequentemente, não se trata de todos os recursos que foram inseridos no projeto. Trata-se de um conjunto principal de funcionalidades que atende a uma necessidade comercial. Sempre tenha isso em mente, porque esse é seu objetivo principal.

• Divida o que precisa ser feito em tarefas. Entenda as dependências entre eles.

Quebrar um projeto deve ser bem direto. Divida-o o mais cedo possível no projeto. Se você precisar encobrir as peças, entenda que elas representam um risco até você entender o que deve ser feito.

• Entenda quais são as perguntas ou ambiguidades em aberto do projeto.

Você não poderá resolver todas as ambiguidades inicialmente (embora deva tentar). Certifique-se de que seu gerente e as partes interessadas no projeto entendam o que são e quais os riscos que eles representam para o projeto.

• Os negócios odeiam surpresa.

Certifique-se de que todos saibam (idealmente diariamente, mas funciona semanalmente) qual é o status do projeto. Por status, quero dizer o que foi feito, o que resta fazer, perguntas em aberto, problemas etc. Qualquer coisa que possa impactar a conclusão do projeto deve ser relatada.

• Todos os dias, repasse o quadro geral.

Você deve revisar o quadro geral todos os dias por uma hora. Faça a si mesmo as perguntas. O que foi concluído? O que resta fazer? Quais são as perguntas em aberto? Qual é o objetivo? Você deve poder fornecer a alguém um status detalhado do projeto sempre que ele solicitar.

O primeiro conselho que darei a você é aceitar que gerenciar a equipe é mais crítico do que executar suas próprias tarefas de programação. Isso significa que, quando você tem três juniores que precisam de ajuda, é seu trabalho ajudar a não se queixar de como isso o está afastando do desenvolvimento. Como líder, você geralmente se torna o obstáculo para o progresso, se estiver focado demais em suas próprias tarefas de desenvolvimento.

Além disso, você precisa aprender a delegar. É difícil dar tarefas a alguém quando você pode fazer isso facilmente em uma hora e você sabe que elas vão se atrapalhar por um dia. No entanto, eles nunca progredirão, a menos que obtenham as tarefas e você trabalhe horas extras enquanto sua equipe estiver jogando.

Além disso, nunca conserte apenas o código de outra pessoa. Diga a eles o que está errado (e por que) e faça-os consertar. Ou você entrará em um ciclo em que precisará consertar tudo, porque eles não estão melhorando. Se eles não puderem consertar, considere se devem permanecer na equipe. Não deixe que membros fracos da equipe fiquem porque você está consertando tudo o que eles fazem.

Como líder, você passa a ser o vilão e dá a eles as notícias desagradáveis ​​(tanto na cadeia quanto na cadeia). Isso acompanha o trabalho também. Isso significa que você precisa fazer uma avaliação de desempenho ruim; você precisa dizer a eles que o prazo foi alterado ou que os requisitos foram alterados; você precisa empurrar o cara preguiçoso que não está fazendo progresso; e você tem que dizer aos seus superiores quando o prazo não será cumprido e por que e o que você está fazendo a respeito. Ser líder não é gostar, mas sim ser eficaz. Seu trabalho é levar o software para fora da porta, não fazer amigos. A comunicação é fundamental e evitar as más notícias acaba piorando a situação. É muito mais provável que um cliente lide com o aviso de que serão necessárias mais três semanas por mês antes do lançamento do que quando a data de lançamento passar e, então, você lhes diz que precisa de mais três semanas.

Aqui está minha lista de verificação informal. É muito informal ... Eu não faço tudo todos os dias, mas se eu não tiver atingido todas essas coisas semanalmente, fico um pouco preocupado e, se não as tiver mensalmente, devo entrar em pânico. E a milhagem varia inteiramente com base na cultura da empresa / equipe, estilo pessoal e tipo de projeto.

• Converse com a equipe individualmente - todos na sua equipe - têm um trabalho útil a fazer? sabe qual é o objetivo geral do produto e a versão atual? eles sabem como você ganha dinheiro e qual é o principal impulso do seu negócio? eles sabem como seu trabalho atual se encaixa com tudo isso?

• Converse com a equipe coletivamente - reúna-os com as principais notícias, reúna grupos para garantir que a comunicação esteja acontecendo com e sem você. Como uma equipe pequena, provavelmente são sessões de estratégia em grupo. À medida que a equipe cresce, torna-se necessário guiá-los pelos principais pontos, e inevitavelmente se torna um cenário para você falar com eles. Isso não está errado - há momentos em que é muito importante que todos ouçam você dizendo as informações públicas a todos . Então todo mundo sabe que você está fornecendo as informações universalmente. Mas a reunião "você para todos" é muito diferente da reunião de estratégia de grupo, na qual você é mais um guia.

• Experimente o trabalho da equipe - tente fazer uma pequena pesquisa do trabalho de todos. Leia seu código, execute suas funções, tente seus casos de teste. Não vise 100% do trabalho de todos, tente provar um pouco de todos. Dê feedback, mas também arquive áreas de pontos fortes e fracos em toda a equipe.

• Entre em contato com a gerência cedo e com frequência - isso não é um nariz marrom, é manter-se atualizado. Se você não sabe o que sua gerência precisa e o que pensa, como sua equipe pode atender às expectativas? Você precisa ter uma boa reputação com seu chefe e precisa estar no time dele, da maneira que seu pessoal está no seu time. Ser capaz de se comunicar efetivamente com o chefe em assuntos triviais aumenta a confiança de que você poderá obter ajuda e entender claramente quando a crise ocorrer. Também é uma boa verificação da realidade para saber onde estão seus antolhos.

• Revise os recursos da equipe periodicamente - as pessoas gritarão quando um recurso disponível anteriormente se tornar indisponível, mas analisará pontos de dor desconhecidos. Onde estão seus pontos de estrangulamento? Existem novas ferramentas que seriam úteis? A maioria das equipes tem um cara que eu considero o Caçador de Ferramentas que está sempre atualizado com os melhores e mais recentes gadgets. Equilibre as conversas entre o Tool Hunter e o GuyWhoHatesEverythingNew para encontrar o próximo ponto para a evolução. As ferramentas incluem tudo - SW, HW, espaço físico, recursos de aprendizado.

• Conheça e mantenha contato com as equipes de suporte. Cada empresa é diferente, mas conhece as pessoas encarregadas de seu controle de qualidade, redação de documentos, jurídico, instalações, finanças e qualquer outro grupo de suporte exclusivo ao seu negócio. Eles são os melhores gatilhos do cenário geral em que consigo pensar, porque vêem o mundo completamente diferente de você.

• Conheça sua concorrência - gaste pelo menos algum tempo por semana descobrindo como alguém resolveria os problemas que seu produto resolveria se não estivesse usando seu produto. Pode não ser uma empresa única, mas o que essa outra solução oferece que você não oferece?

• Revisar custo e cronograma- Qual a probabilidade de sua equipe significar o prazo atual? Que tal o próximo prazo? Qual é a taxa de gravação dos seus custos? Que grandes compras futuras você ainda não pagou? O que resta do seu orçamento? Os detalhes variam de acordo com a forma como você faz o rastreamento financeiro, mas mesmo em uma empresa muito informal, você deve ter uma idéia de quantos dias / semanas / meses de orçamento ainda resta e qual é o prazo para o produto atual. Em algum lugar, é melhor alguém planejar "quantas pessoas precisamos para fazer esse trabalho?" e "podemos pagar para eles no próximo mês / trimestre / ano?". Você precisa conhecer esses números e ter informações sobre as próximas etapas. Você precisa de um plano claro para a próxima semana que possa explicar agora mesmo se alguém entrar e perguntar. Você precisa de um plano muito bom para o próximo mês, isso só mudará em 2-3 lugares quando a realidade chegar. Você precisa de um plano superficial para o trimestre e de um general em primeiro plano para o ano. Depois disso, mesmo em grandes projetos, os números são apenas números. Ouça-os, mas perceba que ninguém assinou sangue.

Esse é o meu topo da minha lista. Eu geralmente adiciono a ele quando sou atingido na cabeça por uma "surpresa" (imagine-me bastante sensível a uma área que perdi e, em seguida, consigo dobrá-la na lista de verificação.g "surpresa" com um sorriso forçado e dentes cerrados )

Também - esteja preparado para o Dread Context Switch. Se você está apenas começando no gerenciamento, é provável que tenha uma equipe pequena e alguém na administração pensou que seria bom você gastar algum tempo gerenciando uma equipe e algum tempo fazendo coisas de colaboradores individuais. Isso pode ser feito, mas a alternância de contexto entre os dois é difícil. Planeje isso. Bloqueie o tempo para alternar (como antes e depois do almoço) e conheça seu conjunto de habilidades menos praticado e perceba que você precisará se arrastar até lá nas primeiras vezes - então reserve um tempo para fazer algo "relacionado ao cenário geral" e descobrir que você precisará de pelo menos duas horas para realmente chegar a algum lugar.

A mudança de contexto funciona nas duas direções - gerenciamento para trabalho prático e vice-versa. Mas quando você vai do seu ponto de força e prática ao seu lugar de desconforto e menos prática, sente mais a dor e o ímpeto de recuar é forte. Conheça o que está lá e lute contra ele e perceba que se debater no cenário geral o torna melhor em entender tudo. Dê tempo a si mesmo para debater.

Leia este livro: Pastoreio de gatos: uma cartilha para programadores que lideram programadores

Algum tempo atrás, presenteiei este livro com meu chefe e ele gostou. Quando eu estava lendo, parecia que ele sabia do que estava falando. E é assim. O autor conta sobre sua própria experiência. Não é uma coleção de "verdades simples" do gerente - estas são as palavras do ex-programador. E deve-se entender que foi a experiência dele, mas a sua pode ser diferente. Então, em algumas coisas você deve olhar criticamente. "O gerente não pode mais ser programador - é importante".

Quando assumi a liderança técnica de uma pequena empresa recentemente em um produto que não desenvolvi, o que achei muito útil para gerenciar as coisas foi documentar em inglês simples o funcionamento do produto - recursos que documentei em pepino e para uso interno Eu escrevi explicações sobre o modelo de objetos e fluimos através de vários controladores. O que descobri foi que A) o produto estava um pouco confuso :) E B) aprendi muito mais rapidamente como o aplicativo funcionava, para que eu pudesse ter uma conversa inteligente sobre quais problemas estavam lá e o que precisava ser refatorado, ou o que seria necessário para implementar um determinado recurso.

As imagens também ajudam - eu não mexo com produtos como o Visio, apenas uso lápis de cera e papel em branco (na verdade, eu trabalho - trabalho em casa e frequentemente com meus 2 anos de idade), mas o que funciona para você é o que você deve usar.