3 perguntas a serem feitas para descobrir gargalos no #desenvolvimento de software

Tempo de leitura: 6 minutos

Às vezes, você acaba com um plano de jogo que parece perfeito no papel. No entanto, quando se trata de implementação, isso pode acabar como uma história completamente diferente.

Desenvolvedores, marketing, comercial e gerência dizem e veem coisas diferentes – cada um com suas próprias perspectivas de por que as coisas caíram no caminho e você está atrasado em seis meses. O processo de desenvolvimento de software é uma arte que precisa ser coordenada – mas às vezes a coordenação sozinha não é suficiente.

Os gargalos no fluxo de trabalho ocorrem quando há excesso de trabalho em uma área específica e o time não consegue produzir a carga necessária. A solução mais comum para isso é adicionar mais pessoas ao time. No entanto, isso pode aumentar ainda mais a gravidade do problema.

Na superfície, parece uma equação de entrada e saída, mas na maioria das vezes ocorrem gargalos devido a um problema mais profundo. Adicionar mais pessoas não resolverá o problema subjacente.

Aqui estão três perguntas a serem feitas que podem ajudá-lo a descobrir a causa raiz dos gargalos no desenvolvimento de software.

1. O que seus desenvolvedores estão fazendo?

Você tem um time – mas o time não está produzindo ou não está produzindo na velocidade que você precisa.

A primeira pergunta a fazer é: “O que seus desenvolvedores estão fazendo? Quais são as tarefas deles? Quem tem propriedade sobre o quê?

Às vezes, você descobre que os membros da equipe não têm objetivos, funções ou listas claramente definidas de tarefas futuras, que não sabem ao certo qual é o escopo de seu trabalho e onde terminam suas responsabilidades pessoais.

Como agir:

São necessários domínios de responsabilidade claros. Se os limites são imprecisos, os desenvolvedores se tornam um recurso responsável, em que a capacidade de saída pode ser reduzida devido a outros domínios puxados no momento.

Ter domínios de responsabilidade claros também pode ajudar a identificar se um indivíduo ou grupo de desenvolvedores em particular está realizando mais tarefas do que é capaz de produzir, na velocidade que você precisa.

Isso permitirá que você descubra quem em sua equipe está sendo subutilizado e quem tem todo o conhecimento e poder dos sistemas.

Depois que isso for identificado, o conhecimento poderá ser redistribuído e isso excluira o risco no desenvolvimento do software de depender exclusivamente de um único desenvolvedor ou grupo de desenvolvedores.

2. Qual é a natureza da arquitetura do seu sistema?

Ao contrário da crença popular, uma vez construída, ela não é concluída. Por mais que uma empresa queira acreditar que, depois de economizar dinheiro para o desenvolvimento de software, é entregue um produto super completo.

O que é realmente entregue é um produto de trabalho que envelhece e precisará ser mantido de alguma forma. Até novas construções vêm com sua própria marca especial de problemas.

Quando você pergunta sobre a natureza da arquitetura do seu sistema, procura ver como os dados são estruturados – são de uma forma propícia ao crescimento? Existem muitos requisitos para fazê-lo funcionar? Quão automatizados são os processos?

Se a arquitetura do seu sistema é muito rígida ou esquisita, seu software e seus processos de desenvolvimento tornam-se restritos pelos requisitos da arquitetura.

Ser muito “aberto” e “flexível” também pode representar um problema, pois não é um suporte preciso para a empresa em seus requisitos e processos de dados. Ser “flexível” demais cria domínios e definições vagos, o que significa que o sistema não está preparado para produzir algo em particular.

Como agir:

Esse é um problema técnico que precisa ser resolvido desde o início. Isso significa voltar ao início, descobrir exatamente o que sua empresa precisa e deseja e, em seguida, reestruturar a arquitetura do sistema de uma maneira que suporte isso.

Isso pode resultar na reformulação do banco de dados e na reconstrução do backend para corresponder. Embora pareça que você está raspando um sistema inteiro e que seja muito caro, esse investimento inicial é necessário para desobstruir o sistema atual e evitar que ele seja o gargalo na entrega de seus negócios e serviços.

3. Quem está tomando as decisões?

Os gargalos no desenvolvimento de software geralmente surgem devido a indecisões e mudanças de requisitos.

Quando não há uma direção ou decisão clara, o software não pode ser entregue porque não há métricas ou requisitos a serem cumpridos. Nos casos de agilidade, a clareza ainda é necessária. Sem isso, não há foco e as tarefas não podem ser configuradas corretamente.

Tomar decisões é uma das primeiras coisas que precisam ser feitas para que os desenvolvedores criem um código eficaz. Isso ocorre porque lhes dá a capacidade de converter requisitos de forma eficiente em ‘fala por computador’.

Se os requisitos forem inadequados, o código deles também será imperceptível e propenso a erros devido a nenhuma falha.

Como agir:

Antes que alguém contrate uma equipe de desenvolvimento de software ou diga aos desenvolvedores para começar a codificar – tome uma decisão.

Esclareça sua visão, descubra se seu software será um trampolim estratégico para essa visão e descubra quais são os recursos essenciais e os primeiros requisitos.

Sua visão é o seu fim de jogo e o software é o ativo digital que o ajudará a chegar lá.

Realizar reuniões sobre o seu software também não é suficiente. Decisões precisam ser tomadas. Elas não precisam ser grandes decisões – apenas aquelas em que você pode se manter por um certo período de tempo até que seja entregue.

Nada é mais desanimador para os desenvolvedores do que descobrir que eles precisam abandonar o navio pela quinta vez consecutiva porque a alta gerência é instável e não consegue se ater a uma coisa por tempo suficiente para que seja entregue.

Conclusão

Desenvolvimento de software é um processo. Os gargalos geralmente ocorrem no nível humano porque há falta de clareza. A complexidade da arquitetura é frequentemente a causa raiz no nível do software. Software “flexível” é disfarçado de complexidade.

Na maioria das vezes, um gargalo cai em uma ou várias dessas categorias. Ser capaz de identificar e criar clareza é semelhante a desobstruir um dreno bloqueado. Quando o fluxo de trabalho não pode efetivamente se mover pelo processo, nada substancial pode ser realmente entregue.

Essas três perguntas representam três cenários muito comuns que existem, independentemente do setor – e podem ser o ponto de partida para identificar os gargalos no desenvolvimento de software.

Gostou do conteúdo? não deixe de seguir a uebile nas redes sociais, pois toda semana tem post novo aqui no blog com mais dicas para o seu impulso digital.