O problema com seu software não está no código

O problema com seu software não está no código
Na real, até pode estar no código e nesse caso vai (quase) sempre ser reflexo de um outro problema.
Eu trabalho com desenvolvimento de software desde 2013 e ao longo desses quase 10 anos já vi muita coisa boa e muita coisa assustadora na área. Eu cheguei até mesmo a acreditar que as empresas de desenvolvimento, depois de tanto tempo, já saberiam que nenhum cliente paga por código fonte (seja ele bem ou mal escrito) e pela solução de um problema. Infelizmente, isso ainda não aconteceu e tem empresas que correm atrás do próprio rabo achando que o problema é puramente técnico.
Nosso principal objetivo, como profissionais na área de software, deveria ser conseguir uma forma simples e otimizada de resolver os problemas e só daí nos preocuparmos com um código lindo e com 100% de cobertura de testes.
Não me entendam mal, eu acho que um código bem escrito e uma boa cobertura de testes é essencial, MAS isso não deve ser desculpa ou ter prioridade sobre agregar valor e entregar uma funcionalidade que realmente faça sentido com o problema do seu cliente.

É relativamente comum, times e empresas de software focarem na entrega de código e em eliminar o máximo de tarefas de um quadro e esquecerem que todo software faz parte de um produto e um produto precisa fazer uma coisa bem feita: agregar valor para quem usa.
Entregar 10 funcionalidades com 100% de cobertura de testes, várias linhas de códigos e commits, que serão usadas apenas 1 vez por um usuário interno do sistema tem bem menos impacto do que entregar uma única funcionalidade de ponta-a-ponta com a qual o usuário final consiga interagir e ter algum valor agregado no final daquele fluxo. Ou seja, uma funcionalidade entregue que resolve um problema real é infinitas vezes melhor do que todas as outras não o fazem.
E aqui chegamos no cerne da nossa discussão: apesar de termos pessoas com cargos e com a responsabilidade de levantar requisitos e priorizar tarefas, isso é algo que deveria ser responsabilidade de todos. E é aqui onde mora o problema do seu software (ou até mesmo da sua empresa) e sobre isso que quero trazer 5 reflexões que podem te ajudar a compartilhar melhor essa responsabilidade.

1. Treine desenvolvedores juniores
Nos últimos anos nada recarregou mais minhas baterias profissionais do que receber um time de novos desenvolvedores querendo aprender e evoluir. É uma tarefa difícil e cansativa mas que deve fazer parte do processo de crescimento de toda empresa e esse é o momento perfeito para você ensinar que a responsabilidade sobre um produto esta acima da quantidade de código gerado.
Esse profissional, começando a carreira, está ansioso por aprender e programar, mas também em entregar valor e ser reconhecido. Ensine-o a detectar o que entrega valor, cobrar dos pares caso a atividade priorizada não esteja condizente com o direcionamento do produto e/ou da iteração atual e sem dúvidas ele te ajudará a chegar mais longe.

2. Pense em tecnologia, mas não deixe-a te limitar
Sendo uma empresa que desenvolve software é claro que a tecnologia tem uma grande importância no dia a dia, porém não se prenda a ela para entregar resultados. Seu cliente está mais preocupado em ter seu problema resolvido do que saber se ele foi resolvido com a linguagem X ou Y.
É o papel dos engenheiros e desenvolvedores mais experientes terem a escolha final das tecnologias utilizadas, mas por experiência própria, as que são mais simples, padronizadas e que facilitam a entrada de novas pessoas, geralmente facilitam a entrega de resultados.

A Experiência do time também deve entrar nessa balança, pois por mais legal que seja aquela nova tecnologia do momento, leva tempo para se ter uma equipe madura para solucionar problemas com ela. E isso nos leva ao próximo ponto…

3. Dinheiro não é infinito

Quem dera fosse, não é mesmo?
Dinheiro é um recurso finito. Quem tem pouco tem que economizar e quem tem muito não quer perder. Então toda decisão de arquitetura, ferramenta e serviços deve levar isso em consideração. Uma ideia genial que não possuí investimento para ser executada é o mesmo que ideia nenhuma.

A quantidade de dinheiro que você tem disponível é como o comprimento de uma pista de decolagem. Se você estiver focado nas atividades certas e as fizer bem feito você pode até decolar com um pista curta, mas nunca terá pista o suficiente para decolar se você se preocupar em pintar o avião ao invés de montar o avião que de fato voe.

E deixe seu time saber disso, porque isso implica diretamente na priorização de tarefas e escolha (ou troca) de ferramentas e tecnologias.

4. Faça pequenas (e constantes) entregas

Todo software tende a ser infinito e sempre haverá uma funcionalidade a mais, uma tela a mais e (infelizmente) um problema a mais para ser corrigido.
Dividir as entregas em pequenos pedaços, além de manter um fluxo de entrega continuo, te ajuda a “sentir a temperatura da água” e guiar melhor a priorização das tarefas a serem executadas.
Em um cenário normal, o ideal seria sempre priorizar a “próxima tarefa mais importante” e ela ser o artefato de entrega da sua equipe. Seja essa entrega mensal ou (como eu recomendaria) semanal. Isso ajudará sua equipe a ficar mais focada, haja vista que o foco estará apenas naquela tarefa e deixará seu cliente satisfeito, pois você sempre terá uma entrega a ser feita com riscos mínimos de atraso.

E é claro que decisões ruins de priorização acontecem, infelizmente não podemos evitar, mas entregas pequenas ajudam a minimizar os impactos dessas decisões, nos permite realizar experimentos técnicos e validar tudo com muito mais velocidade e assertividade o rumo do produto.

5. Microgerenciamento

Por fim, mas não menos importante. Não microgerencie sua equipe. Treine e tenha pessoas em quem você confia para executar o precisa ser feito. Partilhe conhecimento e permita que todos tenham a as ferramentas e capacidades de agirem por si.
Vale muito mais um líder que atue como um escudo para equipe, evitando interferências e ruídos externos, do que um líder que questiona e precisa participar de todas as decisões, seja quais forem.

—

Oi, Eu sou o João!
Olá! Me chamo João Mateus Scarpa sou formado em Ciência da Computação com MBA em Gestão de TI e Especialização em Docência do Ensino Superior. Atuo com desenvolvimento Web desde 2013, já atuei como Gestor de TI no Hub de Inovação Tecnológica de Taubaté e atualmente tenho me dedicado em mapear e documentar os processos de gestão e desenvolvimento de software na Designa.
Você pode me encontrar online no LinkedIn, Twitter e Instagram ou através do e-mail [e-mail]