Como Thoughtworker de longa data, tive o privilégio de trabalhar em muitos projetos e com um conjunto diversificado de equipes. Passar de uma equipe para outra me ajudou a observar e aprender a coexistir e prosperar em vários grupos (interessantes) de tecnologistas! Dividi minha experiência em 8 dicas para seguir ao ingressar em uma nova equipe. Embora a maioria dessas sugestões seja da perspectiva de uma consultora e estejam dentro do contexto de mudança entre equipes, elas se aplicam a alguém que está passando para um novo cargo ou função.
Reservar um tempo para interagir informalmente com cada membro da equipe é uma boa maneira de garantir um bom relacionamento. Costumo começar conversas mencionando cidades e famílias - isso serve como ponto de partida para compartilhar histórias interessantes, encontrar um terreno comum e me sentir confortável.
Também é uma boa ideia participar de atividades em equipe, como almoços ou jogos ocasionais de tabuleiro. Entrei para a minha equipe atual após minha licença de maternidade e estava trabalhando em período parcial nos primeiros meses. Embora isso não tenha me dado muita oportunidade de socializar, tentei jogar ocasionalmente um jogo de pebolim em equipe ou saí para almoçar quando havia tempo. As conversas divertidas me ajudaram a fazer parte da equipe mais cedo ou mais tarde.
Ouvir é uma habilidade necessária e ser novo no projeto é uma ótima oportunidade para exercitar essa habilidade. Aprendi a usar meus primeiros dias em uma equipe para entender termos específicos do domínio, o idioma, nomes e designações das partes interessadas, o trabalho atual da equipe e sobre os serviços / equipes periféricos com os quais colaboramos. Tomar notas me ajuda a voltar e esclarecer algo ou simplesmente reter o novo conhecimento.
Aconselho que você use seus dias iniciais na nova equipe para se concentrar nos detalhes do projeto, processos e tecnologia especificamente necessários para sua função. Por exemplo, quando entrei para minha primeira equipe na Thoughtworks, os desenvolvedores abordaram os nomes das classes Java com suas abreviações durante as discussões sobre design. O PIM seria PipelineInstanceModel e o SIM seria StageInstanceModel e assim por diante. Eu percebi bem cedo que, além dos termos ou conceitos com os quais você deve estar familiarizado, sempre haverá várias abreviações e jargões usados na mesa que você precisará entender. Na minha equipe atual, o SOS não é um sinal de perigo, mas é o Armazenamento de Objetos Estruturados!
Um novo participante da equipe geralmente é informado sobre o que a equipe faz e qual o papel esperado dela. No entanto, a chave para o sucesso é entender claramente os pontos mais delicados dessas expectativas. Deixe-me compartilhar uma instância com você - quando entrei para a Thoughtworks, descobri que, independentemente da antiguidade ou experiência, eu precisava estar completamente envolvido no projeto, questionar decisões, entender o valor do negócio, estar ciente da qualidade do código etc. Essa não era a prática na minha organização anterior, onde, dependendo do domínio e da escala e estrutura da equipe do projeto, o papel real de um indivíduo variava.
Aqui está um exemplo disso: era esperado que um dos meus colegas que liderava a equipe de um projeto compartilhasse responsabilidades com um líder técnico mais experiente (do lado do cliente) em seu próximo projeto - não uma prática usual.
Faz muita diferença quando você se esforça para esclarecer o que se espera de você como jogador de equipe, conversando com seu líder ou gerente técnico. Isso influenciará bastante sua abordagem no trabalho diário, suas interações com colegas e partes interessadas e o tipo de informação que você prioriza ao acelerar.
Uma característica importante de uma rápida aceleração é a obtenção proativa de todas as credenciais necessárias e acesso aos sistemas relevantes, para que você tenha acesso fácil ao aprender ou executar tarefas. Em uma de minhas equipes, alguns novos membros da equipe se concentraram em adquirir o conhecimento certo para começar a contribuir para o projeto, mas não demonstraram interesse em interagir com a equipe de suporte para classificar suas credenciais. E, quando chegou a hora de realmente trabalhar em sua primeira história, eles não conseguiram confirmar o código com suas próprias credenciais, o que era inaceitável para o cliente.
"Quem questiona muito, deve aprender muito e reter muito". - Francic Bacon, filósofo inglês, estadista, cientista, jurista, orador e autor.
Quando as pessoas hesitam em fazer perguntas, isso afeta negativamente sua curva de aprendizado. Eles não compreendem efetivamente o escopo do projeto e os processos e atividades associados que dificultam a produtividade e a autoconfiança. Evite tudo isso e faça perguntas! Eu tenho o hábito de fazer perguntas durante as sessões de treinamento, standups, conversas sobre tecnologia, discussões e, especialmente, quando pareço com outros membros da equipe. Dito isto, estou consciente de não interromper o trabalho ou as discussões em andamento.
Tive a sorte de ter trabalhado com colegas brilhantes, mas acessíveis, que consideraram minhas perguntas. Mas, há momentos em que as perguntas não são atendidas. Nesses casos, precisamos identificar métodos alternativos para encontrar respostas. Foi durante a colaboração com uma equipe do cliente que eu aprendi que não era incentivado ir até um colega e fazer perguntas durante o horário de trabalho. Comecei a anotar todas as minhas dúvidas e verificaria o tempo delas através de ferramentas de bate-papo como o Slack. Eles pareciam mais confortáveis com o arranjo e eu obtive as informações necessárias.
Cometer erros é uma parte óbvia do aprendizado, focada na melhoria contínua. Eu ouvi histórias de vários tecnologistas de longo prazo sobre erros cometidos nos estágios iniciais de sua carreira. Isso incluiu uma instância bastante surpreendente de confirmação de código que causou um defeito de produção embaraçoso. No entanto, o que foi consistente nessas conversas foi o afastamento dos tecnologistas de tais instâncias - de aprender e seguir adiante.
Além disso, alguns de nós podem ter compromissos pessoais que não permitem o tempo que o auto-estudo exige. Nesses casos, procure a ajuda de um membro da equipe para priorizar e escolher tópicos importantes e tente algo que eu fiz - chegue ao escritório mais cedo do que o resto da equipe e use o tempo extra de manhã para ler e aprender.
Se você acumulou uma experiência considerável trabalhando em vários projetos, é altamente possível visualizar várias melhorias observando a base de código, a documentação, os processos ou as práticas nos primeiros dias do projeto. No entanto, antes de entender o contexto e o contexto completos do problema de negócios que está sendo tratado, sugerir ou modificar a solução não está dando o melhor de si.
Alguns anos atrás, eu fazia parte de uma equipe que trabalhava na manutenção e aprimoramento de um produto legado. E, quando esse novo e experiente membro da equipe se juntou a nós, ele questionou a escolha de todas as ferramentas e bibliotecas que estavam sendo usadas. Ele não sabia que todas essas sugestões e escolhas já haviam sido discutidas com o cliente - que não as levou adiante porque as alterações propostas se mostraram complexas e caras. Embora a equipe quisesse explicar isso a ele, sua abordagem dominadora era motivo de atrito. Minha sugestão? Depois de fazer a lição de casa, faça suas sugestões relacionadas ao projeto no momento apropriado com a pessoa apropriada.
Tenho uma ótima história para compartilhar sobre a exibição de propriedade - o tempo de construção do código-fonte do nosso projeto era alto e queríamos mudar isso. Após uma análise, reconhecemos que precisávamos alterar nossa biblioteca de zombaria (RhinoMock), pois isso dificultava os testes de paralelização e reduzia o tempo de criação. Essa transição envolveu a alteração de mais de 500 arquivos, o que também foi um motivo para continuar sendo priorizado. Na mesma época, um novo membro da equipe se juntou a nós e aprendeu sobre o problema. Ele passou seu tempo inicial na nova equipe escrevendo um aplicativo .net que converteria arquivos de teste usando o NSubstitute em vez do RhinoMocks. Essa ferramenta nos ajudou a priorizar essa parte específica do trabalho e aproveitá-la em nossa próxima iteração. As ações do novo membro da equipe mostraram que ele se importava com o produto e estava pronto para assumir a propriedade de sua qualidade.
Uma nova equipe, função ou trabalho são oportunidades interessantes para conhecer novas pessoas, ter novas experiências e aprender novas habilidades. Também pode ser assustador, e minha esperança é que esses oito indicadores sejam capazes de ajudá-lo a navegar nos primeiros dias cruciais.
Conheça sua equipe
O primeiro passo para ser aceita em uma nova equipe é conhecer todos os membros. Como é de se esperar, eu uso o primeiro stand-up para conhecer meus companheiros de equipe e tentar memorizar seus nomes e funções.Reservar um tempo para interagir informalmente com cada membro da equipe é uma boa maneira de garantir um bom relacionamento. Costumo começar conversas mencionando cidades e famílias - isso serve como ponto de partida para compartilhar histórias interessantes, encontrar um terreno comum e me sentir confortável.
Também é uma boa ideia participar de atividades em equipe, como almoços ou jogos ocasionais de tabuleiro. Entrei para a minha equipe atual após minha licença de maternidade e estava trabalhando em período parcial nos primeiros meses. Embora isso não tenha me dado muita oportunidade de socializar, tentei jogar ocasionalmente um jogo de pebolim em equipe ou saí para almoçar quando havia tempo. As conversas divertidas me ajudaram a fazer parte da equipe mais cedo ou mais tarde.
Observe e tome notas
"Ouvi mais do que estudei, portanto, pouco a pouco, meus conhecimentos e habilidades foram sendo desenvolvidos." - Joseph Haydn, compositor austríaco do período clássico.Ouvir é uma habilidade necessária e ser novo no projeto é uma ótima oportunidade para exercitar essa habilidade. Aprendi a usar meus primeiros dias em uma equipe para entender termos específicos do domínio, o idioma, nomes e designações das partes interessadas, o trabalho atual da equipe e sobre os serviços / equipes periféricos com os quais colaboramos. Tomar notas me ajuda a voltar e esclarecer algo ou simplesmente reter o novo conhecimento.
Aconselho que você use seus dias iniciais na nova equipe para se concentrar nos detalhes do projeto, processos e tecnologia especificamente necessários para sua função. Por exemplo, quando entrei para minha primeira equipe na Thoughtworks, os desenvolvedores abordaram os nomes das classes Java com suas abreviações durante as discussões sobre design. O PIM seria PipelineInstanceModel e o SIM seria StageInstanceModel e assim por diante. Eu percebi bem cedo que, além dos termos ou conceitos com os quais você deve estar familiarizado, sempre haverá várias abreviações e jargões usados na mesa que você precisará entender. Na minha equipe atual, o SOS não é um sinal de perigo, mas é o Armazenamento de Objetos Estruturados!
Entenda as expectativas
Um novo participante da equipe geralmente é informado sobre o que a equipe faz e qual o papel esperado dela. No entanto, a chave para o sucesso é entender claramente os pontos mais delicados dessas expectativas. Deixe-me compartilhar uma instância com você - quando entrei para a Thoughtworks, descobri que, independentemente da antiguidade ou experiência, eu precisava estar completamente envolvido no projeto, questionar decisões, entender o valor do negócio, estar ciente da qualidade do código etc. Essa não era a prática na minha organização anterior, onde, dependendo do domínio e da escala e estrutura da equipe do projeto, o papel real de um indivíduo variava.
Aqui está um exemplo disso: era esperado que um dos meus colegas que liderava a equipe de um projeto compartilhasse responsabilidades com um líder técnico mais experiente (do lado do cliente) em seu próximo projeto - não uma prática usual.
Faz muita diferença quando você se esforça para esclarecer o que se espera de você como jogador de equipe, conversando com seu líder ou gerente técnico. Isso influenciará bastante sua abordagem no trabalho diário, suas interações com colegas e partes interessadas e o tipo de informação que você prioriza ao acelerar.
Construa. E rapidamente.
Na minha experiência, o que realmente impressiona as novas equipes é uma aceleração rápida! Para um desenvolvedor, isso equivale a entender os conceitos básicos de domínio e a pilha de tecnologia com rapidez suficiente para poder contribuir para o desenvolvimento da história. Quando em uma nova equipe, acompanho proativamente a conclusão de todas as sessões planejadas, em vez de impor essa responsabilidade a elas. Também comecei a documentar tudo o que aprendi em um espaço compartilhado (se ele ainda não existir) como documentação integrada, para que novos membros da equipe possam se beneficiar do repositório.Uma característica importante de uma rápida aceleração é a obtenção proativa de todas as credenciais necessárias e acesso aos sistemas relevantes, para que você tenha acesso fácil ao aprender ou executar tarefas. Em uma de minhas equipes, alguns novos membros da equipe se concentraram em adquirir o conhecimento certo para começar a contribuir para o projeto, mas não demonstraram interesse em interagir com a equipe de suporte para classificar suas credenciais. E, quando chegou a hora de realmente trabalhar em sua primeira história, eles não conseguiram confirmar o código com suas próprias credenciais, o que era inaceitável para o cliente.
Não hesite. Cometa erros e faça perguntas.
"Quem questiona muito, deve aprender muito e reter muito". - Francic Bacon, filósofo inglês, estadista, cientista, jurista, orador e autor.
Quando as pessoas hesitam em fazer perguntas, isso afeta negativamente sua curva de aprendizado. Eles não compreendem efetivamente o escopo do projeto e os processos e atividades associados que dificultam a produtividade e a autoconfiança. Evite tudo isso e faça perguntas! Eu tenho o hábito de fazer perguntas durante as sessões de treinamento, standups, conversas sobre tecnologia, discussões e, especialmente, quando pareço com outros membros da equipe. Dito isto, estou consciente de não interromper o trabalho ou as discussões em andamento.
Tive a sorte de ter trabalhado com colegas brilhantes, mas acessíveis, que consideraram minhas perguntas. Mas, há momentos em que as perguntas não são atendidas. Nesses casos, precisamos identificar métodos alternativos para encontrar respostas. Foi durante a colaboração com uma equipe do cliente que eu aprendi que não era incentivado ir até um colega e fazer perguntas durante o horário de trabalho. Comecei a anotar todas as minhas dúvidas e verificaria o tempo delas através de ferramentas de bate-papo como o Slack. Eles pareciam mais confortáveis com o arranjo e eu obtive as informações necessárias.
Cometer erros é uma parte óbvia do aprendizado, focada na melhoria contínua. Eu ouvi histórias de vários tecnologistas de longo prazo sobre erros cometidos nos estágios iniciais de sua carreira. Isso incluiu uma instância bastante surpreendente de confirmação de código que causou um defeito de produção embaraçoso. No entanto, o que foi consistente nessas conversas foi o afastamento dos tecnologistas de tais instâncias - de aprender e seguir adiante.
Pratique auto-estudo
O aumento que mencionei anteriormente refere-se ao aprendizado sobre o projeto e processos com a rapidez necessária para começar a contribuir com o projeto. Durante esse processo, você sofrerá uma explosão de informações. Talvez você não tenha tempo para realizar um mergulho profundo e reservar um tempo para aprender sobre o domínio, a tecnologia, a arquitetura e muito mais.Além disso, alguns de nós podem ter compromissos pessoais que não permitem o tempo que o auto-estudo exige. Nesses casos, procure a ajuda de um membro da equipe para priorizar e escolher tópicos importantes e tente algo que eu fiz - chegue ao escritório mais cedo do que o resto da equipe e use o tempo extra de manhã para ler e aprender.
Não imponha suas opiniões a outras pessoas
Se você acumulou uma experiência considerável trabalhando em vários projetos, é altamente possível visualizar várias melhorias observando a base de código, a documentação, os processos ou as práticas nos primeiros dias do projeto. No entanto, antes de entender o contexto e o contexto completos do problema de negócios que está sendo tratado, sugerir ou modificar a solução não está dando o melhor de si. 
Alguns anos atrás, eu fazia parte de uma equipe que trabalhava na manutenção e aprimoramento de um produto legado. E, quando esse novo e experiente membro da equipe se juntou a nós, ele questionou a escolha de todas as ferramentas e bibliotecas que estavam sendo usadas. Ele não sabia que todas essas sugestões e escolhas já haviam sido discutidas com o cliente - que não as levou adiante porque as alterações propostas se mostraram complexas e caras. Embora a equipe quisesse explicar isso a ele, sua abordagem dominadora era motivo de atrito. Minha sugestão? Depois de fazer a lição de casa, faça suas sugestões relacionadas ao projeto no momento apropriado com a pessoa apropriada.
Demonstre propriedade
Expor as qualidades de propriedade e responsabilidade desde o primeiro dia se traduz em ter feito um esforço para saber o máximo possível antes. Depois de se sentir confiante, peça tarefas que você pode realizar sozinho. Isso o ajudará a ser conhecido por sua abordagem pró-ativa e responsável - ambos altamente valorizados em uma equipe de projeto ágil.Tenho uma ótima história para compartilhar sobre a exibição de propriedade - o tempo de construção do código-fonte do nosso projeto era alto e queríamos mudar isso. Após uma análise, reconhecemos que precisávamos alterar nossa biblioteca de zombaria (RhinoMock), pois isso dificultava os testes de paralelização e reduzia o tempo de criação. Essa transição envolveu a alteração de mais de 500 arquivos, o que também foi um motivo para continuar sendo priorizado. Na mesma época, um novo membro da equipe se juntou a nós e aprendeu sobre o problema. Ele passou seu tempo inicial na nova equipe escrevendo um aplicativo .net que converteria arquivos de teste usando o NSubstitute em vez do RhinoMocks. Essa ferramenta nos ajudou a priorizar essa parte específica do trabalho e aproveitá-la em nossa próxima iteração. As ações do novo membro da equipe mostraram que ele se importava com o produto e estava pronto para assumir a propriedade de sua qualidade.
Uma nova equipe, função ou trabalho são oportunidades interessantes para conhecer novas pessoas, ter novas experiências e aprender novas habilidades. Também pode ser assustador, e minha esperança é que esses oito indicadores sejam capazes de ajudá-lo a navegar nos primeiros dias cruciais.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.