Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica) percebe-se que os problemas impactam todas elas. Vamos a eles
Problemas no Domínio de Negócio
É o domínio que representa a fronteira entre a organização e seus clientes. Aqui avaliamos os resultados que o produto traz para a organização.
Não utilizar métricas
“Confia em mim” disse o produteiro meses antes de afundar seu produto e seu time.
Não tem como. Se você cria produtos você tem que saber o resultado. Quantas pessoas utilizam? Quanto ele representa de resultado financeiro? Seus clientes estão satisfeitos? As pessoas acham que o seu produto resolve o problema delas? Métricas são essenciais. Se você não as utiliza dê uma olhada nesse artigo aqui.
Se não é costume na sua organização comece com poucas. Comece com o básico: quantas pessoas utilizam, quantas vezes elas utilizam. Se o seu produto for digital, um contador na página já resolve o problema ou então um Google Analytics.
Imagine que você é o capitão / capitã do barco de guerra. Toda a sua tripulação depende de você e sua arma conta com o seu sucesso. Você tem que saber para onde esse barco está indo. Não pode navegar sem métricas.
Não envolver os stakeholders
Quem são os seus stakeholders? Você tem que envolvê-los na criação do seu produto: Conhecer, Ouvir, Entender, Informar, Alertar e Combinar. Existem vários tipos de stakeholders. Saiba identificar cada um deles. Os mais comuns são: Clientes, Usuários (não necessariamente são as mesmas pessoas) e gestores.
Dependendo do mercado que você atue, governo e sociedade também podem entrar no hall de pessoas interessadas no seu produto / serviço. Obviamente, no seu contexto você pode ter outros mais específicos. Por exemplo, na educação você tem os usuários: aluno, pais, administrativo, professores, MEC etc.
Gostaria de alterar sobre uma situação comum. Um cliente te contrata para construir um produto e ele mesmo elege alguém para ser a pessoa que fará a interface com você. NÃO PARE NESSA PESSOA. Ela pode não ser representativa do grupo que utilizará ou pior,
ela sequer será a usuária do seu produto. Quando você entregar para aqueles que de fato utilizarão, vai tomar um feedback nada positivo.
Envolva todos os stakeholders relevantes!
Afastado da visão
Um artefato muito ignorado nos produtos é a visão. Ela dá um norte, um caminho, uma delimitação do escopo. Quando ela não existe ou é ignorada, qualquer coisa serve para entrar no produto. Ele vai desde pedir empréstimo bancário até calcular o horário do próximo voo para a Guatemala.
Uma boa visão do produto ajuda a decidir qual item entra ou não no backlog.
Problemas no Domínio Cultural
Neste domínio queremos melhorar a satisfação interna. Nossos times e da organização.
Pessoas como recursos
Pessoas não são recursos. Os trabalhadores do conhecimento têm uma característica interessante. Caso eles saiam da empresa ou caso eles “quebrem”, vai demorar muito tempo e um custo bem alto para reposição. Se você está trabalhando há algum tempo na sua empresa, você consegue saber a diferença entre o momento em que você entrou e o momento atual.
Existe um momento na sua carreira dentro da empresa em que você já conhece as necessidades e expectativas dela, pessoas com quem você tem que falar, quem são os freios-de-mão puxados, quem são os workaholics, qual o processo desejado e como ele difere do processo realizado etc. Leva tempo até entender tudo isso e substituir uma pessoa do seu time, levará o aprendizado de volta para a estaca zero.
Problemas no Domínio Organizacional
Aqui o objetivo é melhorar como nos organizamos para nos tornarmos mais eficientes nas entregas.
Produto sem processo
Não há dúvida que o produto entregue para o cliente é que paga as contas no final do mês. Todavia, muitos times têm desistido de melhorar seu processo de desenvolvimento em detrimento de tentar entregar de qualquer jeito. Ou então entendem que seu processo sempre foi assim e deve ficar assim.
Todavia afirmo: É muito difícil criar bons produtos com processos ruins. O item vai e volta no fluxo de desenvolvimento, fica parado em uma etapa durante meses, a qualidade fica comprometida e o timing da entrega é perdido.
Normalmente uma dessas coisas costuma a acontecer:
Complexo de Gabriela
Eu nasci assim, eu cresci assim
E sou mesmo assim, vou ser sempre assim
Gabriela, sempre Gabriela!
A música do grande Dorival Caymmi que ficou famosa na voz da gigante Gal Costa serviu como inspiração para traduzir a disfunção onde nada muda porque sempre foi feito do mesmo jeito. “Já estava assim quando cheguei aqui e é melhor não mexer”. Normalmente as pessoas que vivem nesse complexo têm medo de mudar e serem de alguma forma responsabilizados se algo der errado.
Empresa engessada
É a empresa que se você quiser mudar qualquer coisa no processo de trabalho, você tem que submeter 27 pedidos de solicitação de mudança para o comitê de mudanças que se reúne uma vez a cada quadrimestre que tem que submeter para aprovação da diretoria da empresa e… Ufa! Mudar dá tanto trabalho que é melhor deixar pra lá.
O que os olhos não veem, coração não sente
A ampla maioria de times cai nessa disfunção aqui. Como as pessoas estão tão focadas em fazer a sua parte, não tem ninguém acompanhando o processo. Não há métricas, não há cadências para melhoria, bloqueios não são avaliados e refluxos não são vistos.
O processo não é um quadro e muito menos um papel com um monte de diagramas. Ele é um ser que deve ser nutrido, verificado e aperfeiçoado.
Empurrar escopo sem entregar
Produtividade lá nas estrelas, várias sprints com dezenas de itens “entregues” em homologação, testes, mas nada em produção. Não faça isso. Quanto mais tempo demorar para entregar, mais medo você terá de fazer a entrega verdadeira. Principalmente caso seja um produto que substitua outro.
Obviamente cada produto tem seu tempo de entrega. Já trabalhei com software e com automação industrial e sei que os tempos de entregas são diferentes. Mesmo em produtos de software, os tempos são diferentes. Todavia, seu objetivo tem que ser entregar o quanto antes. Quanto mais ágil seu time for, melhor será a sua capacidade de adaptação e maior a chance do seu produto ser bem-sucedido.
Problemas no Domínio Técnico
Neste domínio, um dos objetivos é avaliar a qualidade do produto
Dívida Técnica Impagável
Sou desenvolvedor de software, amante do Clean Code (Código Limpo). Reclamo de tudo: código comentado, código com regras de negócio sem testes automatizados, métodos que fazem tudo e muitas outras coisas. Mesmo assim, tenho alguns esqueletos no armário. Aquele código que funciona na base do POF (Programação Orientada a Fé). Está lá, funciona, mas só Deus sabe como. Essas gambiarras que fazemos para entregar vão criando uma dívida técnica.
O termo é utilizado para simbolizar que os itens técnicos de um produto precisam de manutenção e evolução. Às vezes para remover as gambiarras, outras porque precisa de melhoria, mesmo não tendo gambiarra. Também existe a necessidade de evolução da tecnologia, redução de riscos, entre outras necessidades.
Se o time só entrega itens de negócio sem nunca pagar parte dessa dívida técnica, há grande chance dela se tornar impagável. Quando for necessário incrementar o produto, vocês terão que jogá-lo fora e construir outro do zero.
