A morte do gerente de projeto, analista funcional e Testador
“Se você está trabalhando com software e está atuando como gerente de projeto, alguma coisa tá errada.” — Dev na estrada
Produzir software não é a mesma coisa que construir shopping centers. Cuidar de produtos digitais pede muita criatividade, adaptabilidade e resolução de problemas complexos no tempo certo.
“Produto não tem fim. Felicidade sim! “ — Reynaldo Barros Jr
Neste cenário, algumas figuras carimbadas em times de desenvolvimento de software simplesmente não fazem mais sentido da forma que sempre foram exploradas, porque elas geram disfunções, comprometendo o time to marketing das soluções ,aumentando o custo da produção e “perturbando” o time.
Foi em um debate na comunidade Ágil que este texto nasceu. O tema não é novidade entre os agilistas de plantão, mas pode ser um “tapa na cara” dos tradicionalistas ou debutantes no mundo Ágil.
Será que ainda faz sentido termos Gerentes de Projetos, Analistas Funcionais e Testadores em times de desenvolvimento de software?
É sobre isso que eu (Reynaldo Barros Jr) e Lucas Tito vamos falar neste texto.
Considerando que estamos na era do conhecimento e não mais na era industrial vamos começar nossa história.
Não vivemos mais na era industrial
No passado, acreditava-se que quanto maior o grau de instrução e especialização, maior seria a importância do profissional e o valor que ele poderia colaborar para com a empresa.
Agora, necessitamos mais do que nunca de trabalhadores do conhecimento, dado que o trabalho pesado está cada vez mais sendo tocado por máquinas e robôs.
Temos uma indústria de software em ebulição, automatizando tudo que é possível, provendo soluções de trabalho coletivo que viabilizam a ação harmônica da inteligência plural e existente, pedindo que resolvamos problemas complexos e novos.
Com este contexto em mente, podemos destacar dois tipos de trabalhadores: trabalhadores do conhecimento e trabalhadores manuais.
Trabalhadores do conhecimento e trabalhadores manuais
A respeito deste último, podemos concluir que dada a evolução tecnológica, muitas atividades humanas estão sendo feitas por máquinas e computadores, que fazem um trabalho mais preciso, rápido e com menos erros. Portanto, de forma mais eficiente.
No entanto, os trabalhos do conhecimento requerem habilidades e competências ainda não programáveis. Dessa forma, a natureza humana possui características essenciais para um trabalho eficaz, como a criatividade, empatia e etc.
Já faz algum tempo que profissões conhecidas estão sendo afetadas, como um reflexo das mudanças que estão ocorrendo em um mundo cada vez mais volátil, com incertezas, complexo e ambíguo (mundo VUCA).
O impacto do mundo VUCA já fora sentido pelos trabalhadores manuais e agora está sendo sentido para aqueles que trabalham com conhecimento.
Para você entender o que está prestes a acontecer vamos falar sobre as diferentes propostas e abordagens na hora de desenvolver produtos de software: A Old School (Waterfall) e a abordagem Ágil.
Waterfall vs Ágil
O Modelo Waterfall
O modelo waterfall, comumente chamado de modelo tradicional ou modelo clássico, está cada vez menos indicado.
Analisando a figura que representa o fluxo desse modelo, podemos identificar inúmeros motivos para falhas e iremos mencionar somente alguns deles:
- Gargalo na linha de produção
- Alto grau de dependências
- Pouca ou nenhuma adaptabilidade
- Menor possibilidade de competitividade dos clientes, dado o longo tempo para produção
- Concentração de poderes (hierarquia forte)
- Ruídos na comunicação, que podem ser catastróficos
Nesse modelo, Como mencionamos acima, os poderes e conhecimentos estão bem divididos. Em geral, em um time de desenvolvimento vamos ter o analista funcional (ou de requisitos ou de negócios), o gerente de projetos, o desenvolvedor, o testador, o analista de operações e implantação, o analista de sustentação e muitos outros cargos. Cada qual na sua etapa respectiva.
O Modelo Ágil
O modelo ágil possuí valores, princípios e estruturas de trabalho que busca mitigar os problemas do modelo anterior. Exemplos:
- Desenvolvimento iterativo incremental
- Coleta constante de feedback do cliente (a cada iteração)
- Rápida reação a mudanças
- Todos os membros são responsáveis
- Papéis mais generalistas
- Foco em competências e habilidades, não nos cargos
- Times multidisciplinares, diminuindo dependências
- Comunicação e transparência em tempo real, em todas as etapas.
- Busca incansável pela melhoria contínua
Pelas características descritas acima, é natural que “cargos” do modelo tradicional se transformem em novos papéis e suas competências e habilidades sejam reaproveitadas, sendo usadas em outra perspectiva. Uma perspectiva de time e não do indivíduo.
Essa mudança de paradigma, do modelo tradicional para o modelo ágil, nos permite gerar um valor mais importante que cargos para a empresa. Nos permite encarar os times como as menores unidades de trabalho (aqui cabe chamar times de recursos).
O time é o responsável por toda a entrega, de ponta a ponta, do início ao fim do projeto, produto ou serviço.
É no time que todas as competências e habilidades necessárias devem estar e não em indivíduos em particular. Se o time tem alguma disfunção, o time aprende e evolui enquanto unidade de trabalho.
Isso significa que todo mundo faz tudo e agilidade é uma bagunça?
Não! Isso significa que todos tem a capacidade de se encaixar em qualquer papel ou de aprender o que for necessário para o time ter a melhor produção possível. No entanto, existem papéis específicos onde competências e habilidades estão mais presentes do que em outras.
A transformação de papéis
Alguns papéis em times de desenvolvimento de software são fortemente impactados quando a agilidade vai sendo inserida em um modelo tradicional. Dentre eles, destacamos neste texto:
- O analista funcional, de requisitos ou de negócio
- O gerente de projetos
- O testador
- O coordenador ou gestor
O que faz um analista funcional, de requisitos ou de negócio?
Um analista funcional (ou analista de requisitos ou analista de negócio) é um cargo no qual suas responsabilidades são:
- Identificar as necessidades do cliente
- Coletar informações
- Entender processos e sistemas
- Ser o elo entre as áreas de negócio e as áreas de TI
- Identificar falhas e incoerências nas especificações
- Criar e gerenciar documentos que refletem esse trabalho.
- Estar atento(a) para as mudanças do mercado
No mundo da agilidade esse cargo “deixa de existir”. Porém, cada competência e atribuição descrita é distribuída para o time.
Todos os membros do time tem a responsabilidade de entender o negócio, entender o valor agregado do seu trabalho para com o cliente, documentar a realidade do produto e ter um sentimento de “dono” para com o produto ou serviço. Entretanto, existe um papel que qualquer membro do time pode ter, para ter foco maior e se desenvolver mais nessa área, que é o Product Owner (no caso do Scrum) ou design de produto.
O que faz um gerente de projetos?
Um gerente de projetos, por sua vez, é um cargo onde as principais atribuições eram:
- Criar cronogramas
- Verificar dependências entre itens a serem desenvolvidos
- Gerenciar os gastos para o desenvolvimento do produto
- Manter o time unido e alinhado
- Identificar disfunções no time
- Contratar ou demitir membros do time
- Comunicar-se com o cliente
- Negociar contratos
- Dar e colher feedback do cliente.
Como mencionado, todas as atribuições desse cargo agora são do time, porém, algumas são mais direcionadas para um papel do que para outro.
A parte de negócio, como planejamento (que inclui tempo e custo) está com o product owner, a parte de liderança do time está com o scrum master.
Vale ressaltar que a liderança de um scrum master é servidora, ou seja, ele está subordinada às necessidades do time e trabalha única e exclusivamente para a evolução do time.
Dessa forma, o scrum master não coloca à frente suas necessidades pessoais ou seu ego. Tão pouco está acima na hierarquia. Ele está ao lado de todos, servindo-os.
Ele facilita a colaboração do time, permitindo que o time tome as principais decisões, incluindo contratação e afastamento de membros da equipe.
O gerente de projeto vira o que no mundo de desenvolvimento ágil?
O gerente de projeto deixa de ser relevante enquanto cargo, para receber algum papel. Sua relevância está como pessoa membro do time e suas competências serão aproveitadas.
Esse ponto é bem relevante porque principalmente hoje, para se ter equipes de alta performance, busca-se times onde o auto-gerenciamento é uma premissa.
Sendo assim, o gerente de projetos hoje pode ser o Customer Success de amanhã, pode ser um Scrum Master, pode habitar uma Gestão de Mudanças.
O que faz um analista de testes
Analista de testes é o cargo responsável por verificar se o código faz a coisa certa, ou seja, se o comportamento do software é o esperado pelo cliente e pelos casos definidos.
As responsabilidades deste profissional são:
- Ele cria os casos de teste, considerando o fluxo de sucesso e todos as alternativas possíveis / de erros
- Cria os planos para a execução desses casos
- Identifica falhas e erros
- Aponta melhorias se pertinente
Na agilidade, todo desenvolvedor é responsável pelo código. Não pelo código que ele mesmo fez e sim pelo código do produto/serviço. Dessa forma, todo o time tem um comprometimento forte com a qualidade do software e se organiza de tal forma a testar aquilo que é feito. Obviamente, essa organização deve ser feita de um modo a impossibilitar viés de teste.
Em um time ágil é impossível ter uma pessoa dedicada para testar?
Não. Porém ela terá também outras capacidades e competências. Esse tipo de organização descentralizada é importante para gerenciar o gargalo do processo de produção e desenvolvimento de software. Um analista não pode ser fonte de gargalo e por isso é tão importante que todos ou a maior parte dos membros do time tenham todas as competências necessárias para a evolução e manutenção do produto.
Na metodologia Kanban, por exemplo, se identificamos um gargalo exorbitante (quantidade de bugs a serem resolvidos é um bom exemplo), o time pode se organizar e realizar uma ação tipo mutirão — Swarming — para correção dos bugs existentes. Essa ação consiste em todo o time parar e ajudar nesse ponto de gargalo, visto que não há nenhum outro ponto do processo que a melhoria se fará tão necessária do que o gargalo em si.
O antigo testador se transforma em quê?
O antigo testador tende a virar uma figura que advoga em favor da qualidade de um modo geral. Assim, seu papel é mentorar a equipe de uma forma a escalar a prevenção de erros e falhas em produção. Além disso, ele ajuda o time a entender a diferença entre os tipos de teste, o melhor momento para utilizar cada cada um, estimula a integração contínua (CI), ajuda a aumentar a cobertura dos testes e a fazer uma entrega contínua (CD). No entanto, todos precisam se sentir donos e se ajudar para alcançar todos esses objetivos nobres.
Muito mais escalável e sustentável não é?
E o desenvolvedor hein?
Analista de desenvolvimento, vulgo Desenvolvedor, era aquele cargo que lia os requisitos escritos, pensava na arquitetura, transformava em código e dava pra alguém testar.
Hoje, com um mundo ágil, ele tem a obrigação de entender o propósito das funcionalidades, o valor que as funcionalidades trazem para o cliente e por fim pensar na melhor forma de codificar. Seu trabalho ainda inclui:
- Manter a boa convivência no time,
- Ajudar a melhoria contínua com ideias e senso crítico,
- Estar aberto a experimentar novas abordagens,
- Ajudar os colegas a testar o produto
- Encontrar pontos de evolução.
- Dar feedback para os colegas e receber os seus como se fossem presentes
- Manter foco na prioridade e no valor que vai ser gerado para o cliente
- Manter o processo claro e transparente para todos
- Deixar sempre clara as lições aprendidas
- O desenvolvedor vira o que no mundo ágil?
Você acha mesmo que essa figura permanece como era? Claro que não Padawan! Enumeramos várias ações que dependem de Soft Skills. Esse desenvolvedor mais moderno e cool, precisa ser capaz de fazer outras coisas que não sejam olhar para uma tela preta e cuspir código.
O profissional do mundo VUCA é um ator protagonista junto com todos os outros membros do time independentemente do papel.
Conclusão — Se desapegando de cargos
Embora tenhamos iniciado nosso texto decretando a morte de cargos bem conhecidos quando o assunto é desenvolvimento de software, é importante reforçarmos que cargos morrem, conhecimento e competências não. Se você leu o texto e se sentiu desconfortável, pode ser que você tenha apego ao seu cargo. Se você se sentiu assim, por favor repense seus sentimentos e invista em um tempo para autoconhecimento, porque você é muito maior do que está escrito no seu crachá.
Sabendo disso, o importante mesmo é colocarmos nosso conhecimento a serviço de nossos pares, gerando valor continuamente.
Tenha em mente que o mercado exige hoje um profissional denominado T-Shaped. Com profundo conhecimento em assunto, mas conhecimentos complementares horizontais.
Me fale você agora: Como anda a transformação de papéis na empresa que você trabalha? O que você pensa de tudo isso?
Referências:
SUTHERLAND, Jeff; SCHWABER, Ken. The scrum guide. The definitive guide to scrum: The rules of the game. Scrum. org, v. 268, 2017.
Agilidade
Anderson, David J. Kanban: successful evolutionary change for your technology business. Blue Hole Press, 2010.
LALOUX, Frederic. Reinventing organizations: A guide to creating organizations inspired by the next stage in human consciousness. Nelson Parker, 2014.
Agilidade está matando QA — Forbes
A morte do gerente de projetos e o nscimento de uma nova era
