7 Problemas Comuns na Construção de Produtos

Compartilhe:

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

Problemas de negócio. Duas pessoas conversando em volta de muitos números

“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. 

Problemas envolvendo pessoas. Um grande motor com várias pessoas trabalhando nele

 

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.

Humanos sim! Recursos não!

 

Problemas no Domínio Organizacional

Aqui o objetivo é melhorar como nos organizamos para nos tornarmos mais eficientes nas entregas. 

Produto sem processo

Problemas de falta de processo. Uma pessoa olhando desolada para uma palheta de cores.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

Problema técnico. 3 Desenvolvedores em volta de muitos bugsSou 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.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Uma das principais habilidades que desenvolvemos enquanto consultores é a de fazer boas perguntas. Uma vez que as pessoas percebem o poder que tem uma boa pergunta, colocada ali na hora certa e que muda o destino de uma reunião,…

Há cerca de uma semana um estudo com um título bombástico tomou conta da web: “268% dos projetos que passaram a utilizar Métodos Ágeis pioraram e 56% passaram a falhar”, dizia o título. E ao ler o conteúdo, pareceu que…