Comunicação em equipe (importa mais do que suas ferramentas)
Desde que trouxe alguns empreiteiros, uma pergunta que os outros fazem é:
o Como é passar de trabalhar em projetos sozinho para trabalhar em projetos com uma equipe?
Ou, mais simplesmente, como é ter empreiteiros? A resposta curta é que eu curto porque oferece algumas vantagens:
- temos que ter uma divisão precisa do trabalho,
- a empresa pode assumir mais projetos,
- somos capazes de colaborar em coisas (o que é algo que sinto falta de voar sozinho),
- e mais.
O outro lado disso, porém, é que sinto que tenho que aprender o que é começar um negócio novamente.
Como começar com uma lousa em branco.
Isso, de forma alguma, é uma coisa ruim. É o contrário. Mas quando você deixa de trabalhar em projetos por conta própria e desenvolve sua configuração, há um período de ajuste que acontece.
Eu ainda estou experimentando isso e trabalhando com isso. Requer conversas com sua equipe e um pouco de introspecção para determinar se o que você está fazendo ainda está certo para a maneira como trabalha ou se deve ajustá-lo.
Comunicação da equipe
Obviamente, este tópico em particular é amplo e eu – junto com muitos de vocês – poderia falar sobre uma variedade de coisas relacionadas à administração de um negócio.
Mas, por hoje, a única coisa que quero falar é o papel que a comunicação da equipe, e não suas ferramentas de desenvolvimento de software, desempenha na entrega de soluções para os outros.
Suas ferramentas importam (mas não tanto)
Por exemplo, eu trabalhei em lugares onde eles trazem uma máquina com um conjunto específico de ferramentas e dizem “Isso é o que usamos para construir nossos projetos".
Claro, requer que você aprenda, mas parte de mim gostou disso, pois remove uma dor de cabeça que vem ao descobrir o que usar. Também me impediu de ter que tomar essas decisões por conta própria.
Por outro lado, também dificultou a introdução de uma nova ferramenta, pois interromperia o fluxo de trabalho de um departamento inteiro. Quando você é uma equipe pequena, porém, é um pouco mais fácil de ajustar.
O Visual Studio Code se tornou meu IDE favorito.
Primeiro, ao trabalhar para si mesmo, você provavelmente tem o seu favorito:
- VAI
- sistema de controle de origem,
- ferramentas de construção,
- ferramentas de implantação,
- ambiente de hospedagem,
- e assim por diante.
Quando você traz outros para a mistura, no entanto, você está trazendo exatamente as mesmas coisas, exceto que está nos termos deles. Agora você tem a tarefa de determinar se deve ficar com o que tem, avaliar o que eles têm, fazê-los adotar suas ferramentas, adotar as ferramentas deles, combinar os dois ou começar de novo.
Esta não é uma maneira trivial, especialmente quando você está trabalhando um com o outro para resolver uma solução para um cliente. Eu poderia escrever muito mais sobre isso. E não me entenda mal: acho que é um tema que deve ser discutido e é algo que acho importante.
Mas há algo que está acima de tudo isso que nunca deve ser subestimado, e esse é o processo de comunicação da equipe.
A comunicação importa (e importa mais)
Não estou falando de verificar o humor das pessoas todos os dias (embora isso seja importante), e não estou falando de conversar por mensagens de texto, Slack ou IRC apenas para que você se sinta produtivo.
A comunicação da equipe é mais do que o Slack.
Estou falando de requisitos de comunicação completa.
Caso em questão: digamos que estou conversando com um cliente, aceito um contrato e então estou pronto para seguir em frente. Eu sei o que eles querem, os designs existentes e como algo deve funcionar. Então eu trago um companheiro de equipe e digo “Ei, vamos começar”.
O problema aqui é claro, certo? Ele/ela não tem ideia do que estamos procurando.
E não importa o quanto você descreva as etapas em sua ferramenta de gerenciamento de projetos ou converse sobre como algo deve funcionar.
Além disso, você pode ter a configuração de ferramentas mais elegante e eficiente possível, mas se sua equipe não tiver clareza sobre os requisitos do projeto, nada disso importa.
Quando você decidir contratar alguém para ajudá-lo com os projetos e quando decidir começar a colaborar na solução, faça uma discussão sobre ferramentas e requisitos de primeira discussão.
Isso não pode ser subestimado.
Se você conhece os requisitos e seu colega de equipe não, ou se os requisitos não são comunicados claramente por um motivo ou outro, a solução adequada não será entregue. E isso é obviamente caro.
Além disso, se você acaba achando que tem as mesmas ideias em mente e acaba implementando algo completamente diferente, então você tem outro conjunto de problemas com os quais lidar.
No que diz respeito ao meu negócio, preocupo-me principalmente em desenvolver relações com as pessoas com quem trabalho tanto na minha equipa como com quem nos contrata.
Mas se as discussões internas sobre as soluções em que estamos trabalhando não estiverem na mesma página, nada mais importa – nem suas ferramentas, nem o que você envia, nem a rapidez com que você envia, e não se simplesmente é feito.
Mais por vir
Então, em um post futuro, compartilharei algumas ideias de experiências pessoais até agora – tanto erros quanto vitórias – na esperança de que você seja capaz de evitar o que quer que possa enfrentar quando optar por aumentar sua equipe.
Não me entenda mal: é uma coisa fantástica de se fazer (e eu adoro isso), mas requer ajustes em níveis para os quais eu não estava completamente preparado.
Enquanto isso, se você tiver algo para contribuir com este post, sinta-se à vontade para fazê-lo nos comentários. Estou sempre ansioso para saber como freelancers e aqueles que também são autônomos ou que gerenciam equipes lidam com esse tópico específico.