Desenvolvendo internamente? Você não é especial
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Em diferentes oportunidades, organizações de TI precisam desenvolver ferramentas internas ou código para ser usado por seus desenvolvedores. As razões para isso são muitas vezes questionáveis, mas existem momentos em que são a opção certa. Com o crescimento da entrega contínua, ferramentas de automação de deploy são um dos exemplos onde ferramentas comuns podem ser úteis para uma empresa.
Quando isso acontece, times internos são frequentemente montados para lidar com esse problema e criar soluções para uso interno. Infelizmente, esses times parecem sofrer de um “problema de introspecção excessiva” e frequentemente esquecem lições aprendidas sobre desenvolvimento de produto ao partir para sua missão.
Existe uma percepção de que, porque algo é desenvolvido internamente e “aprovado” pela sede, outras pessoas serão muito mais receptivas e compreensivas sobre problemas e mau atendimento ao cliente.
Como não existem clientes pagantes de verdade e todos terão que usar a ferramenta no final (pelo menos esperamos), a necessidade de iteração curta de produto e feedback constante não parece tão necessária, planos são feitos para arquitetar algo que poderia resolver todos os problemas, só não o que os usuários estão tendo.
O problema é que, na realidade, as leis de mercado operam internamente em uma empresa tanto quanto no mundo exterior, e soluções ruins e super-arquitetadas que são impostas aos usuários continuam não fazendo sucesso, mesmo dentro das paredes da organização.
Para produtos reais (aqueles pelos quais as pessoas pagam), a solução atual são técnicas de lean startup e times de produto, e acredito que a mentalidade ao entrar no mundo do desenvolvimento interno deveria ser a mesma.
Comece com uma visão, não uma solução completa
Mesmo quando o problema supostamente é conhecido e entendido, geralmente não é tanto quanto esperamos. Super-arquitetar é um problema aqui como em qualquer outro projeto de software, e a única maneira de evitar que o plano falhe ao enfrentar a realidade é começar pequeno e validar sua ideia conforme avança. Sim, estou falando de um MVP.
Saia do prédio
Nesse caso, seus usuários provavelmente estão dentro do mesmo prédio, então realmente não há razões para evitá-los. Ande pelo andar, encontre as pessoas que você vai ajudar com seu produto e peça que ajudem a definir o que precisa ser executado a partir da sua visão.
Itere rápido, perto do cliente
Coloque sua solução para ser usada desde o início. Sente com seus usuários, ajude-os a adotá-la e trate o feedback apropriadamente (como em ouça e faça algo a respeito).
Use métricas, acompanhe adoção e problemas
Métricas existem para serem usadas, então por que não utilizá-las para entender como sua ferramenta está sendo usada e adotada pelos seus colegas (ou não)?
Em resumo, apesar de não ter usuários pagantes, software interno também é feito para ajudar de alguma forma, e se não ajuda, será deixado para trás e esquecido, então empresas deveriam dar a ele a importância que merece.