O que é bom e o que é ruim. Carreira do desenvolvedor através dos olhos de seu líder

Qual é a diferença entre o olhar para a carreira do desenvolvedor e seu líder


A vida é cheia de contradições. Mesmo a luz não pode determinar quem é - uma partícula ou uma onda.
No mundo do desenvolvimento de software, as contradições entre os atores são um carro e um carrinho pequeno. Vejamos alguns: um desenvolvedor e um gerente de desenvolvimento (pode ser um gerente de projeto, gerente técnico, líder de equipe). Acontece que esses dois frequentemente olham as coisas de maneira diferente e geralmente tendem em direções diferentes.



O que o desenvolvedor quer


Todo mundo quer uma coisa diferente. Mas como não podemos prescindir de generalizações, tomamos um desenvolvedor de nível médio esférico no vácuo. Ele é moderadamente preguiçoso, moderadamente curioso e geralmente gosta de sua profissão. Ele só teria um prazo mais curto, melhores processos, tarefas mais interessantes.

Como ele quer se desenvolver? Mas assim:

  • Aprenda novas tecnologias
  • Resolva problemas mais interessantes.
  • Participe de novos projetos
  • Menos atividades de não desenvolvimento
  • Tome decisões você mesmo

Ao mesmo tempo, seu gerente deseja:


  • Para que o desenvolvedor conheça as tecnologias usadas bem
  • Para que o desenvolvedor lide bem com as tarefas: com a qualidade adequada e dentro do prazo
  • Que o desenvolvedor era responsável e sempre completou o que empreendeu
  • Para o desenvolvedor dar avaliações adequadas às tarefas
  • Para que o desenvolvedor tenha um entendimento das necessidades da empresa e do produto como um todo
  • Para o desenvolvedor relatar problemas em tempo hábil

Quer saber como comprometer? Bem-vindo ao gato.

Então, o que temos. Existe uma completa contradição de interesses.

O desenvolvedor quer aprender coisas novas e o gerente deseja que ele seja capaz de usar bem ferramentas familiares.

O desenvolvedor quer resolver problemas interessantes e o gerente tem um conjunto de tarefas comuns que alguém deve executar.

O desenvolvedor quer participar de novos projetos e o gerente precisa de alguém para apoiar os existentes.

O desenvolvedor não deseja fazer nada além de desenvolvimento, e o gerente precisa que o código seja documentado, que o processo de desenvolvimento seja transparente e gerenciável, para que os planos sejam implementados, as liberações sejam emitidas etc. Para fazer isso, ele pede avaliações, realiza levantamentos, retrospectivas e o obriga a planejar suas atividades.

O desenvolvedor quer tomar decisões por conta própria (ele sabe como fazê-lo corretamente), e o gerente exige que ele seja informado dos problemas identificados para poder controlar a decisão.

Não é de surpreender que muitos gerentes de desenvolvimento tenham uma má reputação entre seus desenvolvedores - eles não permitem que você faça o que deseja, mas forçam você a fazer o que o deixa doente.

Causas


A razão, na minha opinião, é muito simples. O desenvolvedor e seu gerente têm objetivos diferentes.

O objetivo do desenvolvedor é ter mais demanda no mercado de trabalho.

O objetivo do líder é entregar o projeto no prazo.

E, no entanto, apesar dessas diferenças radicais, é possível alcançar um compromisso que se adapte aos dois lados.

Vamos tentar entender com mais detalhes.

Desenvolvedor


Aprenda novas tecnologias


É realmente interessante e inspirador. No estágio inicial de se tornar um especialista, é útil ter uma visão ampla do setor e entender o que geralmente há oportunidades de desenvolvimento. No entanto, com o tempo, a quantidade deve se transformar em qualidade.

Não conheço você, mas muitas vezes desconfio do currículo de um desenvolvedor (com 2 a 4 anos de experiência), que lista dezenas de idiomas, estruturas e bibliotecas. Isso pode ser um sinal de que uma pessoa estava fazendo um pouco de tudo, mas não sabe nada profundamente (embora haja exceções). É preferível encontrar uma pessoa que não sabe muito, mas sabe com certeza. E isso requer experiência prática significativa na aplicação da tecnologia. Depois, haverá uma compreensão de suas sutilezas e limites de aplicação, e isso é extremamente importante.

Portanto, é importante e necessário estudar novas tecnologias, mas é altamente desejável que a prática real esteja por trás disso. Mesmo se você estiver desenvolvendo um projeto para animais de estimação, certifique-se de que a tecnologia não seja usada para exibição, mas realmente resolva o problema de negócios.

Resolva problemas mais interessantes.


Eu acho que todo mundo está familiarizado com o conceito de "rotina". Ninguém quer fazer a mesma coisa o tempo todo. No entanto, há um detalhe muito importante. É injusto querer novas tarefas interessantes se você mal administra tarefas antigas e desinteressantes. Qualquer habilidade tem etapas, e você não pode pular sobre elas - mais cedo ou mais tarde, isso causará uma queda dolorosa.

Em geral, tudo é como em um jogo de computador. Para passar para um novo nível, você precisa passar bem os anteriores. Antes de exigir tarefas interessantes do gerente, aprenda a resolver os problemas atuais com rapidez e eficiência, e ficará óbvio que você merece mais.

Participe de novos projetos


Obviamente. Muitas pessoas estão entusiasmadamente engajadas em apoiar o projeto regularmente. Corrigir erros próprios e de seus companheiros enquanto eles estão desenvolvendo algo novo é uma pena.

Afinal, é no suporte que muitas vezes é adquirida uma compreensão das necessidades dos negócios, o que é vital para qualquer projeto. O desenvolvedor aprende a olhar seu software através dos olhos do usuário - e essa é uma das habilidades mais valiosas para o programador. Além disso, a capacidade de entender o código existente aparece, refatorá-lo com cuidado, sem interromper o sistema inteiro. Essas habilidades serão úteis não apenas para suporte, mas também para o desenvolvimento de um novo projeto - não repita erros passados, mantenha a base de códigos em condições decentes e lide com dívidas técnicas.

Não se recuse a apoiar os projetos que você desenvolveu - esta é uma experiência inestimável que pode acelerar significativamente sua carreira.

Menos atividades de não desenvolvimento


Muitos desenvolvedores consideram escrever documentação, planejar reuniões, retrospectivas, se comunicar com o cliente como uma perda de tempo. O principal é escrever código? Que tudo estava arrumado, bonito, consistente com as diretrizes.

Não. O principal é que o software faz o que é necessário - resolve problemas de negócios. Além disso, é altamente desejável que o desenvolvimento atenda aos prazos e orçamentos. Caso contrário, é perfeitamente possível que nosso código ideal nunca funcione.

Você precisa estar ciente de que, para qualquer desenvolvimento complexo, é necessário um plano, sincronização regular dos participantes do projeto (incluindo o cliente), documentação de qualidade e outras coisas que não são de código.

Se você deseja ser um participante importante e útil no projeto, deve entender os processos que ocorrem no projeto e tentar segui-los. Essa é outra experiência útil que todos deveriam ter.

Supervisor


Conheça as tecnologias usadas para
lidar com as tarefas definidas: com a qualidade certa e dentro do prazo


Um líder precisa que as pessoas confiem. Se a tarefa estiver definida, ela deverá ser resolvida. Não importa se o desenvolvedor estava interessado em fazer isso ou se era uma rotina dolorosa para ele. Isso acontece se você "resolver os problemas assim que estiverem disponíveis" e "viver no presente". Mas, para resolver a contradição, é preciso agir de maneira diferente. Ao ensinar constantemente aos desenvolvedores coisas novas e passar a eles a experiência de resolver problemas existentes, aumentamos seu nível. Ao adquirir conhecimento, experiência e amplitude adicionais, eles resolverão os problemas existentes muito mais rapidamente e possivelmente oferecerão uma melhoria no processo. Tais mudanças, iniciadas “de baixo”, são valiosas não apenas pelo resultado direto, mas também são grandes motivadores para que os desenvolvedores busquem e ofereçam novos.

Alocando tempo para as pessoas aprenderem independentemente novas tecnologias ou treiná-las, é possível obter uma equipe altamente produtiva e motivada.

Seja responsável e sempre complete o que foi preciso


Eu acho que todos concordarão que a programação profissional é principalmente para alcançar resultados. Para ter sucesso, todos os participantes do projeto devem concluir suas tarefas. Como resultado, não importa o quão legal é um desenvolvedor tecnicamente, se ele não puder concluir uma única tarefa e lançar tudo pela metade. A verdade universal colocada pelos grandes programadores é que o problema deve ser resolvido da maneira mais simples possível. Talvez essa seja geralmente a qualidade mais importante do desenvolvedor - poder resolver problemas sem dificuldades desnecessárias. Complicar é fácil, simplificar é difícil.

Não tenho medo de dizer que são essas pessoas que são mais valorizadas em projetos reais. Tanto o líder quanto os parceiros do projeto sabem que você pode contar com uma pessoa que ela não falhará.

A educação de pessoas com exatamente essas atitudes profissionais é uma das tarefas importantes de um líder. O mecanismo mais importante nessa questão é a promoção de resultados. Como resultado, você obtém não apenas uma equipe de desenvolvimento, mas uma equipe de pessoas afins, cada uma das quais está interessada em alcançar um objetivo comum.

Dar avaliações adequadas às tarefas


Muitos desenvolvedores provavelmente tiveram o pensamento - por que eles constantemente exigem estimativas de mim, como eu o farei, de qualquer maneira, antes de terminar, nada aparecerá. As classificações parecem um mecanismo de controle humilhante. No entanto, olhe isso pelos olhos de um líder.

Como já escrevi, para que o projeto seja bem-sucedido, o gerente deve ter um plano. Existem felizes exceções, mas no caso geral, sem um plano, o desenvolvimento se transforma em caos. Mesmo que o plano não seja implementado em uma base de calendário, ele ainda será beneficiado - o gerente vê onde está o problema e pode reorganizá-lo para resolvê-lo. Para fazer um plano, o líder precisa de avaliações. Mesmo que o desenvolvedor tenha subestimado ou superestimado a tarefa, para o gerente isso é apenas uma desculpa para introduzir um fator de correção. Assim, tendo estimativas dos desenvolvedores e fatores de correção historicamente confirmados, o líder pode construir um plano próximo da realidade.

Os desenvolvedores geralmente subestimam a necessidade de planejamento porque se concentram no desenvolvimento. Mas, como sabemos, um projeto bem-sucedido não é apenas desenvolvimento. Requer testes, documentação, emissão para o cliente, organização do UAT, etc. A equipe deve agir em conjunto, planejando e seguindo o plano para fornecer essa consistência.

Como o sucesso do projeto também é o sucesso de cada participante, para alcançar seu próprio sucesso, o desenvolvedor deve ser capaz de avaliar adequadamente as tarefas.

É o líder que deve fornecer aos desenvolvedores uma compreensão de todos os processos que ocorrem fora do desenvolvimento. Explique o significado de cada ação e decisão, a importância do planejamento, da comunicação. Consciência é a chave para o sucesso.

Compreender as necessidades da empresa e do produto como um todo


Frequentemente, os desenvolvedores se concentram em escrever código, ignorando o problema de negócios que resolvem. Infelizmente, isso é característico não apenas para iniciantes, mas também para especialistas bem estabelecidos e titulados.

Como já escrevi, considero a solução para os problemas de negócios a principal tarefa da programação. Portanto, de uma maneira natural, apenas quem pode efetivamente resolver esses problemas pode ser considerado um bom programador. Para fazer isso, é vital entender claramente o que está acontecendo nos negócios que automatizamos.

Assim, o desejo do gerente de que o desenvolvedor compreenda as necessidades de negócios e considere cada tarefa principalmente deste ponto de vista (qual tarefa de negócios resolvemos e por quê) é mais do que um desejo natural. Somente dessa maneira um desenvolvedor pode alcançar um domínio real. Portanto, os reais interesses do líder e desenvolvedor coincidem aqui.

Como no parágrafo anterior, o dever do líder é explicar de forma clara e clara ao desenvolvedor o que a empresa precisa e por quê. Além disso, é necessário transmitir uma verdade simples - quem pode se aprofundar na área de assunto e resolver um problema específico é apreciado, e não quem simplesmente escreve um código bonito.

Relatar problemas em tempo hábil


Para garantir o sucesso do projeto, é vital que o gerente receba informações oportunas sobre problemas na conclusão de tarefas. O desenvolvedor, pelo contrário, geralmente prefere lidar completamente com o problema e relatá-lo apenas quando todos os prazos razoáveis ​​tiverem passado. Deve-se dizer que o desejo de entender independentemente o problema é sempre louvável. No entanto, para o benefício do projeto, é necessário informar o responsável pelos problemas que podem aumentar o tempo para resolvê-lo, para que ele possa levar isso em consideração no plano.

A habilidade mais importante do desenvolvedor é a capacidade de se comunicar de maneira oportuna e aberta com outros participantes do projeto. A notificação oportuna de um problema é uma parte importante da comunicação.
Nesse caso, o líder não deve se apressar imediatamente para resolver o problema. É mais sensato dar tempo ao desenvolvedor para descobrir por si mesmo, tomar as decisões necessárias e apresentar o resultado. Isso lhe dará confiança em suas habilidades, o hábito de confiar em si mesmo e, ao mesmo tempo, aliviar-se do medo de relatar problemas em tempo hábil.

Resumir. Como combinar os interesses do desenvolvedor e de seu líder?


Para o desenvolvedor


  • O sucesso de um projeto é o sucesso de cada um de seus participantes. Todo projeto de sucesso é um passo à frente em sua carreira. Em qualquer entrevista, você ganhará muito mais pontos se concluir com êxito os projetos nas suas costas.
  • Resolver problemas de negócios é o principal objetivo do desenvolvimento. Se o projeto falhou, não importa o quão boa foi a arquitetura e o quão bonito o código foi.
  • – : , , , – .
  • , . , . . , .
  • – , , , , , , - .


  • , . , . .
  • , .
  • , .
  • .
  • .
  • .

All Articles