Elcio Ferreira Ao escolher ou desenvolver um software para seu negócio, há uma série de variáveis que são levadas em conta para decidir a melhor solução: adequação aos requisitos necessários e desejáveis, custo, performance, necessidade de manutenção, segurança e confiabilidade, user experience, documentação e suporte. Mas há uma variável que geralmente é subestimada: developer experience.
Developer experience trata-se de quão fácil é para os seus desenvolvedores e para os desenvolvedores dos seus parceiros de negócios entender e executar customizações, extensões e integrações em seu novo software.
No ecossistema digital da sua empresa, o valor de cada software é multiplicado por seu valor de rede. A integração entre os softwares é que vai realmente potencializar e transformar seus processos de negócios. Um software muito bom, mas difícil de integrar, é como um jogador muito bom em seu time, mas que não joga bem em equipe. Cada software com boa developer experience que você agrega torna todo o ecossistema mais valioso.
Nesse cenário, os desenvolvedores que vão trabalhar em seus softwares e suas integrações são clientes muito relevantes do software. Não importa se sua empresa tem desenvolvedores, se você contrata desenvolvimento sob demanda, ou se o seu software será estendido e integrado por parceiros de negócios: você deve levar em conta as necessidades dos desenvolvedores ao decidir suas soluções de software.
Entre essas necessidades, estão:
APIs e interfaces simples
Esse é o campeão da developer experience. Mesmo que você tenha documentação abundante, acessos simples e um bom suporte, se para desenvolver uma simples extensão o desenvolvedor precisa aprender uma nova linguagem, alguns padrões proprietários de projeto e lidar com processos super complexos, a experiência será ruim.
Fuja de sistemas que exigem conhecimentos em uma linguagem ou arquitetura próprias ou pouco conhecidas. Prefira aqueles que seguem padrões de mercado em suas interfaces. Também é um problema se a API exige nomenclaturas muito diferentes das de negócios. Uma API em que o pedido de venda se chama “order” ou “pedidoDeVenda” costuma ser mais fácil de integrar que uma em que o nome é “S43BusinessObject” ou “J_K17T”.
Peça a um programador para avaliar as APIs dos sistemas que vocês estão cogitando implantar e te dar um comparativo de complexidade.
Documentação clara
Documentação é essencial. Ela deve não apenas descrever cada método e objeto disponíveis na interface, mas também o que cada um significa em termos de negócios. Cada vez que é feito um pedido na API do e-commerce, é disparado também um alerta? Ou é necessário chamar o método “sendAlert”? Esse tipo de dúvida acontece o tempo todo e precisa estar sanada na documentação, ou o desenvolvedor vai perder tempo descobrindo, por tentativa e erro, como o sistema funciona.
Os itens a seguir são muito úteis, mas não substituem a documentação de regras de negócios:
- Uma interface Swagger, OpenAPI ou um arquivo para importação no Postman;
- Links para a documentação da linguagem e do framework usados para a extensão do software;
- Uma aplicação de exemplo.
Por outro lado, é preciso tomar cuidado com a profundidade e extensão da documentação. Documentar cada detalhe óbvio do sistema, com três ou quatro exemplos para tudo, pode gerar uma péssima developer experience. Documentação demais é quase tão ruim quanto documentação insuficiente. Se para modificar a UX do carrinho de compras do seu novo e-commerce é preciso ler um livro, talvez a documentação seja excessiva.
E documentação errada ou desatualizada é um problema pior ainda. Um desenvolvedor experiente pode, com facilidade, olhar para a documentação e dizer se é insuficiente ou exagerada, mas para saber se está atualizada e correta ele geralmente vai perder tempo tentando coisas que não funcionam. Por isso, sempre questione seus fornecedores sobre seus processos de atualização da documentação.
Acessos sem burocracia
Obter acesso ao software e APIs é, geralmente, a primeira tarefa de um desenvolvedor. São suas boas vindas à developer experience desse software.
É claro que o procedimento para acesso ao ambiente de produção precisa de controle e governança. Por outro lado, o acesso à documentação e um ambiente de testes deveria ser o mais simples possível. Documentação deveria estar publicamente disponível e o acesso a um ambiente de testes deveria ser possível automaticamente através de um cadastro simples.
Lembre-se que durante o ciclo de vida de um software você pode ter que contratar fornecedores diferentes várias vezes. Em cada projeto que envolve integração ou customização você deve fornecer acesso à documentação a todos os fornecedores com quem estiver conversando, preferencialmente antes de eles enviarem suas propostas comerciais. Se o seu fornecedor de software exige que cada parceiro de negócios assine um contrato antes de ter acesso à documentação, cada novo projeto que envolva esse software vai te fazer passar por uma via crucis de burocracia.
Já participei de dezenas de projetos em que os acessos necessários para o início do desenvolvimento foram concedidos aos desenvolvedores em alguns minutos. E infelizmente participei de alguns em que foram necessárias duas semanas para obter os acessos.
Ambiente de desenvolvimento
Se estamos falando de software web, não existe nenhuma boa desculpa para não oferecer, de um jeito fácil e rápido, a criação de um ambiente de desenvolvimento onde o desenvolvedor tenha acesso completo ao software, incluindo a permissão de criar usuários com diversos perfis. É importante que o ambiente de desenvolvimento tenha os mesmos recursos e comportamento do ambiente de produção, apenas com dados diferentes. Avalie a disponibilidade disso antes de contratar software.
Já quando falamos de software on premise, as coisas costumam ser um pouco mais complicadas. Não esqueça de avaliar se o seu contrato inclui a possibilidade de instalar um ambiente de desenvolvimento e oferecer acesso aos desenvolvedores. Se for preciso contratar licenças adicionais para isso, não esqueça de levar isso em conta no seu processo de decisão.
Por fim, se seu ecossistema vai exigir projetos frequentes ou recorrentes de customização e integração, avalie quão simples é ter dois ambientes para os projetos: um de desenvolvimento, outro de homologação.
Canais de suporte
Em uma developer experience ideal, o desenvolvedor vai conseguir resolver tudo sozinho. Mas o que acontece se as coisas não funcionarem conforme a documentação? Ou se ele, mesmo tendo lido e testado tudo o que conseguiu, ainda tem dúvidas?
Se você contrata desenvolvimento de software, é claro que você precisa fornecer aos seus desenvolvedores informações sobre as regras de negócios e um canal claro e disponível para eles tirarem suas dúvidas.
Mas se eles vão integrar com softwares que você contratou, eventualmente vão precisar tirar dúvidas técnicas, acionando o suporte dos seus fornecedores. É uma pena, mas é comum que projetos de software sejam paralisados por alguns dias por falta de resposta de um fornecedor. Ao contratar software, não esqueça de avaliar isso: quais os canais de suporte disponíveis e seu SLA. Além disso, avalie a facilidade de delegar acesso a esses canais diretamente para os desenvolvedores. Se todo contato tiver que ser feito pelo seu próprio time, vocês vão ficar brincando de telefone-sem-fio com as dúvidas técnicas.
Se, ao invés de contratar licenças de um software pronto, você está contratando desenvolvimento sob medida, não esqueça de levar em conta todos esses fatores de importância para a developer experience. Converse com seus desenvolvedores sobre APIs e documentação, acessos e ambiente de testes, e considere incluir suporte a outros desenvolvedores em seu contrato de sustentação.
A Visie possui vasta experiência em desenvolvimento de software fácil de usar, estender e integrar, além do desenvolvimento de integrações e automações. Converse conosco antes do seu próximo projeto de desenvolvimento.
2 de junho de 2023
