Como lidar com a inexperiência?

39 respostas
B

Tomem o seguinte caso:

Você se tornou líder de implementação de uma equipe em um novo projeto, e a gerência colocou duas pessoas sem experiência(*) ou com experiência mínima em lógica e programação para te ajudar.

Considere que um projeto normalmente vira um desastre quando programadores codificam sem pensar na arquitetura, reuso, etc, estas sendo as últimas preocupações deles.
Considere também que o projeto deve ser entregue com um bom índice de manutenabilidade.

Que ações você adotaria para gerir essa situação?

(*) - Por exemplo, estagiários, funcionários que vieram de outro setor, concursados, ou gente com QI muito alto (o primo do chefão).

39 Respostas

tiagogn

passei por uma situação assim e foi desastrosa, principalmente na hora de explicar alguns conceitos do tipo “não programem regras de negócios nas Actions”, por não terem experiencia não se preocupavam em fazer algumas coisas, porem consegui resolver o problema de uma maneira simples, comecei a ser “XIITA”, segui a risca os padrões do J2EE e fiz eles fazerem o mesmo, ou seja, consegui encapsular a caca q eles faziam, pode não ser a melhor, porem foi a solução q eu encontrei para lidar com a falta de experiencia deles, q acho nem ter sido o maior problema e sim a falta de interesse em fazer bem feito e entender o pq.

GabrielCardelli

Nunca passei por isso por nunca ter trabalhado…
Mais acho que seria uma situação bem complicada^^

Sera que sou o inexperiente dessa historiaa? oo :smiley: :shock:

Eduardog

Boa tarde Bruno Laturner,

Antes de mais nada, neste tipo de situação primeiramente você necessita de requisitos muito bem definidos e bem explicativos para que os desenvolvedores sintam o mínimo de incompreensão possível.

Já me aconteceu algo deste tipo na empresa onde trabalho, neste caso adotei a fundo os conceitos de Eng. de Software e Qualidade de Software (manutenabilidade) , ou seja, não adianta você colocar a mão na cabeça desesperado e deixar como está. No meu caso adotamos a métrica de desenvolvimento ágil SCRUM e também o XP, que são os próprios desenvolvedores que irão ficar acima e por dentro do projeto e saberás como está o andamento do projeto e do desenvolvimento em si, pois, apesar da pouca experiência de alguns, os outros que possuíam experiência, ajudavam estes, mostrando a melhor forma de codificar ou de realizar algum requisito que não estivesse conseguindo faze-lo.
Existe também o XP (Extremming Programming) que um de seus ensinamentos é o desenvolvimento em pares que significa dois desenvolvedores fazendo à mesma tarefa, sendo que, um codifica e o outro auxilia nesta mesma codificação onde você como Líder Técnico poderia amenizar as “gambiarras” realizadas pelos desenvolvedores mais inexperientes acompanhando o decorrer do projeto.

Eu aconselharia você adotar o XP como descrevi a cima logo, você líder técnico, cada dia sentaria ao lado de cada desenvolvedor inexperiente e acompanharia o seu desenvolvimento como se fosse um deles, adotando as medidas de refactoring para cada código que pudesse ser aplicado.

  • “Bruno será que você não pode realizar este código da seguinte forma para que fique com melhor entendimento e compreensão!”

Desta forma além de você acompanhar o projeto diretamente ajudaria os desenvolvedores menos experientes a aprender a utilização do refactoring e da forma mais correta de se codificar algo dentro de um projeto, que com o tempo ele mesmo poderá realizar o que você estará realizando no momento.

Espero ter ajudado,

:lol:

s4nchez

Receitinha de bolo básica:

  1. Pair programming pra difundir conhecimento
  2. Code reviews para manter a qualidade do código
  3. Retrospectivas para avaliar os pontos que precisam melhorar
victorwss

Bruno Laturner:
Tomem o seguinte caso:

Você se tornou líder de implementação de uma equipe em um novo projeto, e a gerência colocou duas pessoas sem experiência(*) ou com experiência mínima em lógica e programação para te ajudar.

Considere que um projeto normalmente vira um desastre quando programadores codificam sem pensar na arquitetura, reuso, etc, estas sendo as últimas preocupações deles.
Considere também que o projeto deve ser entregue com um bom índice de manutenabilidade.

Que ações você adotaria para gerir essa situação?

(*) - Por exemplo, estagiários, funcionários que vieram de outro setor, concursados, ou gente com QI muito alto (o primo do chefão).

Dê uma de arquiteto, tente criar você mesmo o esqueleto do negócio e peçam para eles só preencherem o resto. Tenha por perto um código bem horroroso de outro projeto, explique todos os tipos de problemas que a arquitetura ruim ocasiona/ocasionou e explique que é importante que vocês se esforcem para que esse projeto não siga o caminho do outro.
Vigie de perto o código que eles fizerem e corrija o que achar de errado. Quando fizerem algo errado, senta junto e explica o problema.
É importante saber ouvir também e manter sempre uma postura de amigo, de igual para igual.
E seja claro: Não adianta nada correr com o prazo se for necessário refazer um monte de coisas depois.

chun

Já vi , e já tive alguns projetos afundados por inexperiência de programadores…

Hoje prefiro pagar mais caro a pegar programadores “cheirando leite”

Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE…

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar…

No final OU voce estoura todos os prazos possiveis e imaginaveis , ou vai apresentar um produto sem o menor nivel de coesão.

s4nchez

chun:
Já vi , e já tive alguns projetos afundados por inexperiência de programadores…
[…]
Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE…

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar…

Cabe ao programador experiente evitar que a inexperiencia de alguns prejudique o projeto. Como foi dito, o resultado eh fruto da equipe (e voce tambem faz parte dela), nao apenas de uma pessoa.

chun

s4nchez:
chun:
Já vi , e já tive alguns projetos afundados por inexperiência de programadores…
[…]
Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE…

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar…

Cabe ao programador experiente evitar que a inexperiencia de alguns prejudique o projeto. Como foi dito, o resultado eh fruto da equipe (e voce tambem faz parte dela), nao apenas de uma pessoa.

Segundo ele a EQUIPE TODA é inexperiente…
Sem chances.

jingle

Aqui na empresa ja passei pelos doi lados…

Quando eu era o “Novato”, tive um membro da equipe como “tutor” este foi nomiado pra me ajudar sempre que precisava, (claro que podia pedir ajuda aos demais, porém este sempre acompanhava meus passos), sempre que eu fazia um código inapropriado ele me alertava dizendo que não tava certo fazer daquela maneira e mostrava a maneira correta de se fazer. Toda vez que eu “commitava” algo era “revisado” (por cima é claro) só para ver se eu não tava fazendo alguma besteira.

Agora eu ja estou do lado de quem esta ajudando um “novato”, e sempre tento resolver suas duvidas quando elas surgem.
De vez em quando chego na mesa perguntando " e ai tudo certo? ta levando?" e do uma acompanhada, se surge modo que da pra melhorar o código, tento mostrar este modo.

Com o tempo vai ficando cada vez mais idependente, e as duvidas diminuindo em um processo natural.

chun

jingle:
Aqui na empresa ja passei pelos doi lados…

Quando eu era o “Novato”, tive um membro da equipe como “tutor” este foi nomiado pra me ajudar sempre que precisava, (claro que podia pedir ajuda aos demais, porém este sempre acompanhava meus passos), sempre que eu fazia um código inapropriado ele me alertava dizendo que não tava certo fazer daquela maneira e mostrava a maneira correta de se fazer. Toda vez que eu “commitava” algo era “revisado” (por cima é claro) só para ver se eu não tava fazendo alguma besteira.

Agora eu ja estou do lado de quem esta ajudando um “novato”, e sempre tento resolver suas duvidas quando elas surgem.
De vez em quando chego na mesa perguntando " e ai tudo certo? ta levando?" e do uma acompanhada, se surge modo que da pra melhorar o código, tento mostrar este modo.

Com o tempo vai ficando cada vez mais idependente, e as duvidas diminuindo em um processo natural.

Quanto tempo voce levou de “novato” para o atual estagio ?

s4nchez

Pensei que o autor do topico havia sugerido que o programador experiente fazia parte da equipe:

Bruno Laturner:

Você se tornou líder de implementação de uma equipe em um novo projeto, e a gerência colocou duas pessoas sem experiência(*) ou com experiência mínima em lógica e programação para te ajudar

jingle

Atualmente estou 2 anos na empresa…

chun

jingle:

Quanto tempo voce levou de “novato” para o atual estagio ?

Atualmente estou 2 anos na empresa…

Qual projeto que pode esperar 2 anos para amadurecimento de um programador ?

Repito… o resultado do projeto é o resultado do lider + sua equipe…

20% lider
80% equipe.

jingle

chun:
jingle:

Quanto tempo voce levou de “novato” para o atual estagio ?

Atualmente estou 2 anos na empresa…


Qual projeto que pode esperar 2 anos para amadurecimento de um programador ?
Repito… o resultado do projeto é o resultado do lider + sua equipe…
20% lider
80% equipe.

Desculpe interpretei mal sua pergunta achei que estava pedindo quanto tempo eu estava na empresa, o estagio até se tornar mais idependete demorou ±3 mês, que foi quando comecei a receber projetos própios.

concordo com sua analise de :

B

E falei mesmo. O único membro experiente da equipe, com condições atuais de arquitetar, refatorar, além de ter mais conhecimento das regras de negócio e infra é o líder, os outros 2 são novatos mesmo.

Aliás, outro papel deste líder é aumentar o nível dos outros integrantes, pelo bem da equipe e também pelo bem das outras que eles formarão no futuro.

Obs: Só pra deixar claro, não sou o lider da suposta equipe, até por que ela não existe no presente. Porém já tive esse papel, em breve poderei ter novamente, nestas mesmas condições. Por isso a pergunta, para me preparar até lá.

victorwss

E falei mesmo. O único membro experiente da equipe, com condições atuais de arquitetar, refatorar, além de ter mais conhecimento das regras de negócio e infra é o líder, os outros 2 são novatos mesmo.

Aliás, outro papel deste líder é aumentar o nível dos outros integrantes, pelo bem da equipe e também pelo bem das outras que eles formarão no futuro.

Obs: Só pra deixar claro, não sou o lider da suposta equipe, até por que ela não existe no presente. Porém já tive esse papel, em breve poderei ter novamente, nestas mesmas condições. Por isso a pergunta, para me preparar até lá.

Bem, a palavra “líder” já define o que o cara tem que fazer, não é?

chun

O lider tmb vai programar ?

bandrade

Além de PP, sugiro criar um mini-curso sobre algoritmos, orientacao a objetos, padroes de projeto para elevar o conhecimento da equipe…

Pega a apostila da Caelum a (FJ11) e ensina para eles… ((;

B

Ou pelo menos o que deveria fazer né.

Com certeza! É de se esperar que entre arranjar tempo pra gerir a equipe, ele também produza algo, alias, até mais que os novatos. Senão bye bye prazos.

chun

Ou pelo menos o que deveria fazer né.

Com certeza! É de se esperar que entre arranjar tempo pra gerir a equipe, ele também produza algo, alias, até mais que os novatos. Senão bye bye prazos.

Então me desculpe…
Com duas pessoas inexperientes o resultado deste projeto vai depender 99,999999999999% do tempo que o lider vai ter para desenvolver…

É impossivel coordenar uma equipe , aguardar resultados e ainda em cima produzir codigo de qualidade e coeso.

Se eu fosse o lider passaria alguns lapis de cor e algumas folhas em branco para os caras e pedia para eles ficarem desenhando e pintando o projeto todo…

INEXPERIENTE devem ser tratados como INDEXPERIENTES e não como “mão de obra disponivel”

Marcio_Duran

Scrum não seria o ideal ?

klayrocha

Concordo ! É claro que não vai passar o paint pra eles, mas funções menos importantes, até perceber que já pode passar algo mais.

chun

Resumindo, este vai ser um projeto de um homem só jhehehe

a tradicional EUquipe.

Leozin

O que tem a ver uma coisa com a outra?

fantomas

Oi Bruno Laturner ,

Já passei por coisa parecida, e acho que quem caia nessa situação tá ferrado. A não ser que tenha uma gerencia compreensiva e prazos tranquilos.

A primeira equipe éra mesclada, havia gente sem experiencia e gente com experiencia apenas em manutenção, nunca havia monta um sistema desde o início; a situação éra bem conturbada pois havia muita cobrança e detalhe - Não foi eu quem escolheu os componentes. Comecei com algumas coisas de SCRUM / XP e começou a ocorrer muitas brigas em função da divergencia de opinião, alguns não queria ceder a idéia do outro e tava difícil e bem desgastante; a produtividade éra muito baixa em função do entrosamento ruim. Acabei adotando a arquitetura J2EE que eram o que eles sabiam mesmo sendo por leitura. Montei a proposta da infraestrutura do projeto apresentei à eles; foi aceita após algumas críticas e sugestões que logo depois foram incluidas gerando assim a primeira versão. Logo depois disto eles tinha o “esquema” de trabalho; cada um recebia um funcionalidade para desenvolver éra só pegar a máquina e começar a “fritar” os códigos.
Com isso eu fragmentei a equipe e acabei com as brigas e o dono do projeto conseguia fazer reuniões com cada um da equipe que estava cuidando de determinada funcionalidade, ele adorou o esquema se sentia o dono da bola; éra só mandar incluir uma funcionalidade e ZAZ um maluco já começava a ralar o peito em cima daquilo.

Bom, eu consegui resolver o projeto, mas internamente a coisa ficou ruim, havia muita redundancia de código, o sistema não éra nada otimizado. A equipe não evoluiu nada tecnicamente, sem falar que havia casos do desenvolvedor malandro, só ficava “embassando” e não rendia nada enquanto alguns se matavam. Eu não éra o líder de fato, eu era aquele cara que surge quando tudo esta perdido e a direção é apenas uma, o fundo do poço com muita força.

No outro projeto, no mesmo local, com alguns brigões fora da equipe e novos componentes afim de uma idéia diferente. Conseguimos adotar o XP e o projeto saiu muito melhor mesmo porque eu já tinha uma lista enorme do COMO NÃO FAZER para me basear.

Resumindo, a carga de trabalho e responsabilidade sempre cai em cima de quem sabe mais / está afim nesta hora. Se tiver sorte da equipe ser tranquila, saber discutir ideias, ser colaborativa etc… adote SCRUM / XP. Caso contrario e seu “coro” depender disso pegue o J2EE monta uma receita de bolo (BOLOVO rsrsrs) e bota os macaquinhos pra pressionar os botões quando eles estiverem mais adaptados vc tenta uma…outra coisa.

flws

B

Seria a pior opção.

leandronsp

chun:
Já vi , e já tive alguns projetos afundados por inexperiência de programadores…

Hoje prefiro pagar mais caro a pegar programadores “cheirando leite”

Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE…

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar…

No final OU voce estoura todos os prazos possiveis e imaginaveis , ou vai apresentar um produto sem o menor nivel de coesão.

:shock:
Os programadores iniciantes agradecem pela chance.

Marcio_Duran

Seria a pior opção.

- Porque ?, será que o sentindo de experiência é só a implementação sem o entendimento ao gerenciamento de projeto.

B

Por que nessas metodologias a equipe é formada por pessoas que sabem o que estão fazendo, de preferência que sejam especialistas na área, ou proxys para outros times. O objetivo é que elas agreguem valor com o conhecimento delas, que outros membros do time não tem.

Vejo isso como aprender a correr sem ter passado pela fase de engatinhar.

Por outro lado, pequenas partes dele podem ajudar. Por exemplo, XP é outro que não adotaria por inteiro, mas pair programming acho obrigatório. Assim como ter um padrão de codificação, ter releases poucos aos poucos.

Coisas bem fáceis mesmo.

Marcio_Duran

Bruno Laturner:
Por que nessas metodologias a equipe é formada por pessoas que sabem o que estão fazendo, de preferência que sejam especialistas na área, ou proxys para outros times. O objetivo é que elas agreguem valor com o conhecimento delas, que outros membros do time não tem.

Vejo isso como aprender a correr sem ter passado pela fase de engatinhar.

Por outro lado, pequenas partes dele podem ajudar. Por exemplo, XP é outro que não adotaria por inteiro, mas pair programming acho obrigatório. Assim como ter um padrão de codificação, ter releases poucos aos poucos.

Coisas bem fáceis mesmo.


Acho que o nível de exigência ai é de alto nível, não é possível que alguém que não tem a mesma cultura não possa compartilhar, existem ciclos no projeto mesmo sendo com um time de especialista enxuto, visto que saber o que esta fazendo no minimo onde ainda não aconteceu no projeto isso é teorizado antes de proceder, algo como alguém no minimo tem que fazer especificação, ou mesmo tenha que lidar com assunto que seja na ponta desse projeto, nada começa pelo no meio e termina, talvez migração mas ainda assim processos e especificações andam juntos.Outra coisa metodologia é o que vai se aplicar em fase de processo, mas um motivo para ter colaboradores mesmo esses vindo de outros projetos menores.

chun

leandronsp:
chun:
Já vi , e já tive alguns projetos afundados por inexperiência de programadores…

Hoje prefiro pagar mais caro a pegar programadores “cheirando leite”

Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE…

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar…

No final OU voce estoura todos os prazos possiveis e imaginaveis , ou vai apresentar um produto sem o menor nivel de coesão.

:shock:
Os programadores iniciantes agradecem pela chance.

Programadores iniciantes não devem ter chance em projetos… a não ser que sejam projetos simples e sem muito impacto…

Me desculpe, é a mais pura realidade…

Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

Marcio_Duran

chun:

Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

Isso prova o quanto as pessoas não trabalham pelo processo ou sobre qualquer metodologia é pura intuição e praticidade pela sua mão de obra, provavelmente SCRUM é algo que ainda não atingiu maturidade nessas organizações, melhor dizendo nem sabem o que é isso.

chun

Marcio Duran:
chun:

Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

Isso prova o quanto as pessoas não trabalham pelo processo ou sobre qualquer metodologia é pura intuição e praticidade pela sua mão de obra, provavelmente SCRUM é algo que ainda não atingiu maturidade nessas organizações, melhor dizendo nem sabem o que é isso.

A questão é simples…

Com uma equipe imatura ou de amadores , não espere um resultado profissional…

Tem muito gerente de projeto aí achando que jogar duzias de programdaores inexperientes e cobrar resultados profissionais é algo “normal”.

Para evitar isso a regra é simples…

Amadores devem fazer serviço de amadores.

Andre_Fonseca

s4nchez:
Bruno Laturner:

Que ações você adotaria para gerir essa situação?

Receitinha de bolo básica:

  1. Pair programming pra difundir conhecimento
  2. Code reviews para manter a qualidade do código
  3. Retrospectivas para avaliar os pontos que precisam melhorar

perfeito!

PS: só complementaria com um item, código coletivo, se o Pair Programming for sempre feito isso acaba sendo automático

Marcio_Duran

Se não temos profissionais colaboradores, temos um projeto cuja o dominio é de uma classe eletizada pelos seus interesses, é de responsabilidade da empresa dar treinamento e qualificar o profissional, mas isso é um estado ideal, na regra as coisas funcionam mesmo é no Hacker.

C

A unica forma de lidar com inexperiencia é evitando-a! seja nao contratando programadores inexperientes, ou treinando-os ate que acumulem alguma experiencia. :slight_smile:

Em qualquer projeto com prazos e objetivos reais é importante propiciar um ambiente controlado para a realizacao das atividades previstas, portanto vc deve incluir o treinamento como uma dessas atividades e assumir o fato que estara introduzindo ainda mais complexidade ao processo.

Mero_Aprendiz

Bem, queria apenas deixar minha simples opinião.

Nessa situação, o que já vi algumas vezes, os arquitetos do projeto definiram muito bem o que deve, pode, e não pode ser feito. Por exemplo, deve usar o mesmo método para persistir, ou para aplicar a mesma regra de negocio, pode criar algo novo, desde que isso passe pela avaliação de um arquiteto e não pode codificar sem obedecer uma diretriz de programação (isso é ótimo para padronizar código).
Isso não é nivelar por baixo os seus desenvolvedores, mas sim garantir que as coisas tenham um norte na hora de codificar as coisas.
Como diria um amigo meu: Profissionais de elite trabalham para “mamãos” de alta performance.

[]'s
JL

C

Mero_Aprendiz:
Bem, queria apenas deixar minha simples opinião.

Nessa situação, o que já vi algumas vezes, os arquitetos do projeto definiram muito bem o que deve, pode, e não pode ser feito. Por exemplo, deve usar o mesmo método para persistir, ou para aplicar a mesma regra de negocio, pode criar algo novo, desde que isso passe pela avaliação de um arquiteto e não pode codificar sem obedecer uma diretriz de programação (isso é ótimo para padronizar código).
Isso não é nivelar por baixo os seus desenvolvedores, mas sim garantir que as coisas tenham um norte na hora de codificar as coisas.
Como diria um amigo meu: Profissionais de elite trabalham para “mamãos” de alta performance.

[]'s
JL

A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.

Mero_Aprendiz

cmoscoso:

A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.

A criação das diretrizes é para que os desenvolvedores tenham um norte. Um modelo de como fazer as coisas.
Claro que uma revisão de código é bem vinda.
E apenas mais uma coisa. Concordo com você que não garante que elas seram respeitas, mas é sempre bom lembrar que esse tipo de documento e norma da empresa (é sempre bom lembrar que desenvolvedor de softwares também é funcionário) o que deveria ser respeitado como qualquer outra norma, como conhecer a missão e a visão da empresa.
Se um desenvolvedor sabe das normas, e não se esforça para conhece-las e aplica-las, não deve ser um bom funcionario.

[]'s
JL

Criado 4 de abril de 2009
Ultima resposta 7 de abr. de 2009
Respostas 39
Participantes 17