Equilíbrio entre carga de trabalho e ajuda a novos contratados [fechado]

Estou no meu primeiro emprego há cerca de 2 meses e comecei a perceber que há um delicado equilíbrio entre a carga de trabalho e a ajuda de novos contratados. Como há muita pressão da gerência para corrigir bugs e resolver o maior número possível de problemas dos clientes, todos na equipe parecem estar muito focados em seu atraso de trabalho, em vez de ajudar os recém-contratados a se atualizarem. Os recém-contratados podem fazer perguntas e, ocasionalmente, pediremos que um desenvolvedor se sente e nos ajude, mas geralmente obteremos uma resposta obscura que apenas um veterano do produto entenderia porque está muito ocupado com sua tarefa.

Entendo que o novo contratado também deve manter um equilíbrio. Às vezes, leva três dias para contratar um novo contratado para investigar e consertar algo em que um veterano poderia ter feito isso em 20 minutos. Os recém-contratados precisam mostrar esforço para aprender o produto e a base de código.

Sem simplesmente reduzir a carga de trabalho dos veteranos, como você pode equilibrar entre ajudar os recém-contratados e continuar trabalhando no seu backlog a uma taxa razoável?

Suponho que você esteja perguntando isso do ponto de vista "Novo contratado". Eu já estive nessa situação muitas vezes. Às vezes, você se sente mal ao fazer tantas perguntas, mas realmente não há como chegar à solução, às vezes com uma falta de conhecimento do domínio etc.

A coisa mais importante a lembrar é isso. Não faça perguntas quando "assumir" que não será capaz de encontrar a resposta. Dê uma chance às coisas, bisbilhote primeiro, examine o código, tente mudar algumas coisas e veja o que acontece - veja se você consegue fazer algo funcionar primeiro. Se você realmente não pode, faça sua pergunta. No entanto, quando você fizer sua pergunta, vá até eles com exemplos do que você já tentou. Nenhum deles quer sentir que você está pedindo que eles façam seu trabalho por você.

Diga: "Ei, eu estou tentando fazer isso, e eu tentei isso, isso e isso já, você tem alguma idéia?" Isso os ajudará a gastar menos tempo com você e eles estarão mais inclinados a fazê-lo.

Em nossa empresa, designamos para cada novo contratado alguém para cuidar dele nos primeiros meses. Com essa tarefa formal, garantimos que o novato consuma apenas uma pessoa e a pessoa que está "treinando" o novo contratado tem a responsabilidade pelo seu desenvolvimento, portanto não é um fardo, apenas uma responsabilidade temporária. Para o novo cara é bom, porque ele aprende mais rápido e para o cara que já está lá, há um investimento: em menos tempo ele conseguirá alguém para ajudá-lo.

O melhor conselho que posso lhe dar é marcar uma consulta . Todo mundo tem algum tempo de inatividade durante o dia, mas se você aparecer aleatoriamente, é muito improvável que o acerte. Diga algo como: "Eu tenho algumas perguntas sobre o X, posso marcar um horário hoje para discutir isso com você?" Eles podem decidir dar-lhe tempo nesse momento ou mais tarde, ou talvez encaminhá-lo para alguém que possa responder melhor ou mais rapidamente à sua pergunta. De qualquer forma, você terá uma atenção mais focada. Se eles marcarem uma consulta mais tarde, use o tempo intermediário para tentar descobrir a resposta por conta própria ou pelo menos para refinar a pergunta. Mesmo se eu adiar a pergunta de alguém por apenas 15 minutos, na maioria das vezes eles descobrirão por conta própria.

Lembre-se de que, para a maioria de nós, suas perguntas são importantes para nós, geralmente não são urgentes . Tente não se ofender com a diferença.

Alguns dos codificadores mais experientes realmente gostam de orientar desenvolvedores mais jovens, e fazem disso uma prioridade. Sim, sempre que tenho a oportunidade. Talvez você possa encontrar alguém assim na sua empresa perguntando a um colega diferente cada vez que precisar de ajuda e depois medindo o entusiasmo deles em responder a você.

Há duas maneiras pelas quais você pode precisar de ajuda: se houver um problema com o idioma ou suas ferramentas, você poderá encontrar as respostas on-line ou comprando livros técnicos e lendo-as no seu próprio tempo. Embora você ache razoável que é responsabilidade da empresa treiná-lo, muito poucas empresas investem muito em treinamento. Se você deseja crescer como desenvolvedor, precisa investir tempo e dinheiro em seu treinamento quando não estiver no trabalho.

Se sua pergunta é sobre o produto da sua empresa, como algo funciona no código-fonte, é mais provável que você precise pedir ajuda a um de seus colegas. Como alternativa, crie uma ramificação do código do seu produto no seu sistema de controle de revisão, nomeie a ramificação como "learning_new_code" e experimente.

Por fim, os gerentes de projeto e gerentes de departamento estão lá para ajudar com problemas como o seu. Se você sente que não tem recurso, a não ser arranjar tempo de seus colegas mais experientes, mas eles não podem dar a você, talvez seja porque eles têm prazos a cumprir. Talvez o seu gerente estenda seus prazos para permitir mais tempo para que você se mantenha atualizado.

Tenho a sorte de trabalhar atualmente em algum lugar, isso não é um problema. Eu recebi uma dose saudável de orientação aqui e estou muito satisfeito com isso.

1. Todos os dias, um desenvolvedor da minha empresa é o desenvolvedor "util", de forma rotativa. O desenvolvedor Util é a primeira linha de contato quando o suporte precisa escalar algo. Freqüentemente, o Util está passando um problema para outra pessoa. Mas é um desenvolvedor específico e o suporte sabe ir a essa pessoa. Eu fiz algumas "carona" no começo (eles não me colocaram no cronograma por um tempo) para ver como alguns problemas foram tratados. Isso me expôs a partes do código. Quando eles começaram a agendar meus dias úteis, havia alguém "de plantão" a princípio para adicionar assistência adicional.

2. Nós emparelhamos. Você precisa agendar um horário par, praticamente, mas todos aqui estão dispostos a fazê-lo. Além disso, todo mundo sabe qual é o cronograma e, graças ao próximo ponto, tem uma idéia de como o progresso está indo para cada indivíduo. Portanto, se houver um problema, ele recebe a devida atenção.

3. Todos os dias fazemos uma reunião às 11:45. Isso é de 15 a 20 minutos. Todo desenvolvedor / pessoa de controle de qualidade fala. É basicamente uma maneira de dizer "é isso que estou fazendo e é aqui que estou preso", e se você está preso, geralmente é apontado em uma direção alternativa (se é um problema conhecido / um problema com o código que alguém está familiarizado) com) ou o tempo de par está configurado. Ocasionalmente, uma reunião adicional é agendada.

4. Eu tive que mergulhar em código completamente alienígena várias vezes aqui (como em qualquer trabalho). Alguém sempre teve a certeza de se disponibilizar para responder perguntas, se não imediatamente.

Vou repetir outras pessoas: agende o horário da reunião para fazer perguntas sempre que possível. Id que ainda não é útil. . . bem, eu não quero ser extremo aqui. Mas não considero esse o local de trabalho ideal. É possível que as pessoas ainda estejam se aquecendo com você / controlando suas habilidades / etc?

Suspeito que o tempo extra gasto quando subi a bordo foi facilmente justificado porque, uma vez que as pessoas sentiam que eu estava em dia, isso obviamente significava menos trabalho para elas. Mais tempo gasto a curto prazo economizou muito tempo, e todos entenderam isso onde eu trabalho. Tenho muita sorte na minha posição atual.

Muitas vezes, isso é mais uma questão de foco do que de tempo. Programe reuniões de 30 a 45 minutos com o líder ou mentor da equipe (antes ou depois do almoço é sempre a minha preferência - meu fluxo já está interrompendo) algumas vezes por semana e guarde suas perguntas.

A maioria dos desenvolvedores (ou, pelo menos, os que provavelmente serão úteis na reunião) ficará bem com isso.

Se houver um detalhe muito específico que esteja bloqueando seu progresso, use o email.