No desenvolvimento de produtos, há um aspecto importante sempre comentado mas que com frequência se perde entre uma visão abstrata e suas implicações práticas. É o chamado "valor de negócio". Deveria ser algo tangível, objetivamente medido mas que na prática acaba funcionando de forma diferente. Quanto mais complexo o cenário em que se quer criar valor, mais difusa se torna a maneira de medi-lo. Mas é o valor de negócio que provê o ímpeto para as iniciativas de desenvolvimento de produto, então é preciso dar um passo atrás por um momento e ver como o desenvolvimento de software e o valor de negócio podem andar de mãos dadas.
Valor de negócio tem a ver com conhecer quem irá se beneficiar em última instância daquilo que estamos criando, é sobre criar hipóteses e obter o feedback necessário para validar nossas premissas. Isso é o que nos ajuda a decidir qual é o próximo, potencialmente mais valioso, incremento funcional. Sempre que criamos uma infraestrutura para desenvolvimento de software e adotamos metodologias ágeis para criar coisas e colocá-las rapidamente em produção, isso é feito justamente para melhor entregar valor de negócio.
A literatura sobre processos Lean foca na redução de desperdício, em fazer certo a coisa certa, que é algo que pode confundir muita gente: a diferença entre fazer certo a coisa e fazer a coisa certa. Não é apenas um jogo de palavras engraçado. São aspectos que devem ser mutuamente inclusivos, baseados na sinergia entre o pensamento estratégico e o pensamento tático. Ambos são necessários, cada um para cumprir um objetivo distinto: queremos fazer a coisa certa porque esse é o caminho mais rápido para agregar valor ao negócio; e queremos fazer certo a coisa para que possamos manter uma forma saudável e previsível de fazer a coisa certa.
Há um descompasso comum entre uma bela visão de produto e as tarefas do dia-a-dia que nos mantêm ocupados fazendo fazendo certo a coisa. Sempre que nos desviamos da verdadeira razão pela qual estamos desenvolvendo a funcionalidade A ou B, há um grande risco de prejudicarmos o lado da equação que tem a ver com a entrega de valor.
Então como podemos saber se estamos no caminho certo? Métricas.
Há dois conjuntos de métricas que devem ser tomados em consideração:
O código "perfeito" não é aquele que adere a todos os princípios do SOLID se ele não impacta positivamente o negócio ao mesmo tempo. O código que escrevemos deve ser bom o suficiente para cumprir um dado e oportuno objetivo de negócio de forma a que seja possível continuar evoluindo de acordo com o que formos aprendendo através da sua interação com os usuários. Isso não quer dizer que a qualidade é negociável, que devemos apresentar uma solução rápida e rasteira, de difícil manutenção. Nada disso. A parte de fazer certo a coisa continua verdadeira. A chave é o equilíbrio. É sobre entender os limites de quão longe queremos e podemos ir. Para isso, há algumas métricas que indicam a saúde de nosso código e o processo de desenvolvimento subjacente. Nossas decisões sobre para onde ir e como ir devem ser tomadas de posse dessa informação.
Em resumo, cada incremento funcional — isto é, o software que vamos criando — deve buscar entregar valor ao negócio, ajudando-o a avançar ao mesmo tempo em que garantimos que temos um codebase saudável, em um estado bom o suficiente para manter um ritmo de entrega de valor estável.
Sob uma perspectiva do negócio, estamos falando de problemas e oportunidades. Sobre não resolver um problema a tempo ou tomando tempo demais para agarrar uma oportunidade, fazendo com que um produto ou funcionalidade perca uma boa parte de seu potencial impacto.
Por exemplo, se tomamos em conta o tempo que se leva para desenvolver algo em relação a como essa funcionalidade pode se pagar se lançada tarde demais, ela ou custou demasiado ou vai levar mais tempo para se pagar. Pode acontecer ainda, em um cenário mais catastrófico, que a janela de oportunidade se feche permanentemente. Isso significa tempo e dinheiro investidos e nenhum retorno.
É fundamental entender esse processo porque, quando falamos sobre métricas, é fácil confundir quais métricas são relevantes em cada estágio do ciclo de vida do produto e como uma determinada métrica provê as evidências necessárias para que possamos passar ao próximo. Cada estágio possui diferentes objetivos e nós devemos trabalhar com métricas que, partindo de um alto grau de incerteza, vão nos levar a calibrar nossa certeza em relação ao nível de atingimento de nossos objetivos e validar o valor entregue pelo produto.
Durante a etapa de descoberta, nós temos uma definição de problema e algumas premissas. Estamos lidando com um alto grau de incerteza. Nós entramos nos detalhes durante a etapa de definição, criando um plano e uma hipótese que queremos avaliar rapidamente. Quando chegamos à entrega, estamos tentando garantir que tudo que vá à produção tenha sentido de estar e continuar lá.
Queremos medir a performance do produto em si e a performance do mecanismo de criação do produto. Assim como há uma pirâmide de testes, podemos imaginar uma pirâmide de métricas em cuja base estão as coisas que garantem que estamos fazendo certo a coisa e em seu topo aquelas que indicam que estamos fazendo a coisa certa. Ambas as partes devem estar em um constante fluxo de feedback e validação.
Levando essa discussão a uma visão de horizontes, nosso grau de certeza tende a ser mais alto para aquelas coisas que estão no H1, diminuindo progressivamente em cada horizonte seguinte, com nossa visão do escopo indo de funcionalidades concretas até apostas futuras. Nosso maior investimento de tempo deve ser naquilo que sabemos como fazer e, a partir do conhecimento que obtivermos, refinar nossa visão daquilo que podemos fazer no futuro. Desta forma, garantimos que estamos executando a visão do produto ou obtendo evidências de que devemos tomar um caminho diferente.
O que fazer então? Desde uma visão de negócio ou um conjunto de premissas que queremos verificar, devemos focar em pequenos incrementos de negócio. Devemos, acima de tudo, usar cada incremento funcional para medir o negócio e determinar se ainda estamos na direção certa. Lembre-se: uma direção dentro de vários caminhos "certos" possíveis, mas sempre uma que comprovadamente agrega valor ao negócio. Não é sempre fácil e nem sempre será possível, mas isso deve ser encarado tal qual uma diretiva primária: buscamos sempre agregar valor ao negócio em cada incremento funcional e queremos medi-lo de forma objetiva.
Podemos começar medindo se estamos fazendo certo a coisa. Em seguida, nos perguntamos como o valor de negócio pode ser percebido. Há uma questão básica a perguntar: essa nova versão do meu produto ou funcionalidade é melhor (ou ao menos igual) do que a versão anterior? O que podemos medir para responder a essa pergunta pode ser algo como um aumento de conversão, melhor satisfação de usuário, mais engajamento, qualquer coisa que faça sentido imediatamente.
Não é preciso que nos sintamos oprimidos por algum acrônimo esotérico tirado de uma revista de negócios e gestão. Ainda não. Antes, tente pensar em maneiras simples de determinar o quê o "está melhor agora" quer dizer. Quanto mais aprendemos sobre nosso produto e o impacto que ele gera em cada uma de suas iterações, melhor equipados estaremos para entender se coisas como ROI, NPS, RPU ou LTV são aquelas que nos vão ajudar em nossa jornada.
Isso se traduz em sermos capazes de medir a saúde do nosso ambiente de desenvolvimento de produto bem como conseguir medir o impacto que cada incremento funcional traz ao negócio. Não fazê-lo significa que estamos seguindo um plano de olhos vendados, apenas porque ele nos leva a algum fim. O plano não é o objetivo. Ele é como imaginamos que podemos possivelmente atingir o objetivo, enquanto nos esforçamos para garantir que o objetivo faça sentido de verdade.
Faça uma pausa por um momento e pense no seu projeto atual. Você sabe qual é o objetivo dele? Como você pode ter certeza de que ele está sendo atingido? Você tem como medir o mecanismo de entrega de software e o impacto de cada incremento funcional sendo entregue?
E, mais importante, lembre-se sempre que "valor" é um conceito multifacetado: o que os clientes valorizam pode não ser a mesma coisa que o negócio vê como valor. Conheça seu cliente para conseguir medir sua percepção acerca do produto.
Valor de Negócio: o Alfa e o Ômega
Valor de negócio não é (apenas) sobre dinheiro. É sobre como um impacto positivo é percebido pelos usuários finais, empresa, parceiros ou outras partes interessadas. É sobre fazer algo de maneira mais efetiva e eficaz, reduzindo custos, tempo e assim por diante. É sobre criar formas inovadoras de resolver problemas. Em última instância, o valor de negócio representa as perspectivas que uma empresa tem de continuar operando um negócio saudável no longo prazo.Valor de negócio tem a ver com conhecer quem irá se beneficiar em última instância daquilo que estamos criando, é sobre criar hipóteses e obter o feedback necessário para validar nossas premissas. Isso é o que nos ajuda a decidir qual é o próximo, potencialmente mais valioso, incremento funcional. Sempre que criamos uma infraestrutura para desenvolvimento de software e adotamos metodologias ágeis para criar coisas e colocá-las rapidamente em produção, isso é feito justamente para melhor entregar valor de negócio.
A literatura sobre processos Lean foca na redução de desperdício, em fazer certo a coisa certa, que é algo que pode confundir muita gente: a diferença entre fazer certo a coisa e fazer a coisa certa. Não é apenas um jogo de palavras engraçado. São aspectos que devem ser mutuamente inclusivos, baseados na sinergia entre o pensamento estratégico e o pensamento tático. Ambos são necessários, cada um para cumprir um objetivo distinto: queremos fazer a coisa certa porque esse é o caminho mais rápido para agregar valor ao negócio; e queremos fazer certo a coisa para que possamos manter uma forma saudável e previsível de fazer a coisa certa.
"Queremos entregar o produto certo para o mercado certo no tempo certo com o processo certo."
Há um descompasso comum entre uma bela visão de produto e as tarefas do dia-a-dia que nos mantêm ocupados fazendo fazendo certo a coisa. Sempre que nos desviamos da verdadeira razão pela qual estamos desenvolvendo a funcionalidade A ou B, há um grande risco de prejudicarmos o lado da equação que tem a ver com a entrega de valor.
Então como podemos saber se estamos no caminho certo? Métricas.
Há dois conjuntos de métricas que devem ser tomados em consideração:
- Métricas que nos ajudam a direcionar o produto através de seu ciclo de vida
- Métricas que nos ajudam a medir a saúde de nosso mecanismo de entrega de valor
Valor de negócio e o valor que criamos
Nosso entusiasmo e foco em nos tornarmos cada vez melhores tecnologistas não deve nunca nos fazer esquecer a razão pela qual criamos algum software. Isso é especialmente verdadeiro se desenvolvemos software profissionalmente e temos clientes que nos pagam para entender seus problemas e seus desafios, para identificar oportunidades e propor as soluções apropriadas. Ao escrever código elegante, escalável, robusto e seguro, estamos fazendo uma parte fundamental de nosso trabalho, porém apenas uma parte. Se esse código se desvia de seu principal propósito — que é o de prover um incremento de valor ao negócio — ele acaba não sendo bom.O código "perfeito" não é aquele que adere a todos os princípios do SOLID se ele não impacta positivamente o negócio ao mesmo tempo. O código que escrevemos deve ser bom o suficiente para cumprir um dado e oportuno objetivo de negócio de forma a que seja possível continuar evoluindo de acordo com o que formos aprendendo através da sua interação com os usuários. Isso não quer dizer que a qualidade é negociável, que devemos apresentar uma solução rápida e rasteira, de difícil manutenção. Nada disso. A parte de fazer certo a coisa continua verdadeira. A chave é o equilíbrio. É sobre entender os limites de quão longe queremos e podemos ir. Para isso, há algumas métricas que indicam a saúde de nosso código e o processo de desenvolvimento subjacente. Nossas decisões sobre para onde ir e como ir devem ser tomadas de posse dessa informação.
Em resumo, cada incremento funcional — isto é, o software que vamos criando — deve buscar entregar valor ao negócio, ajudando-o a avançar ao mesmo tempo em que garantimos que temos um codebase saudável, em um estado bom o suficiente para manter um ritmo de entrega de valor estável.
Problemas, oportunidades e resultados
O uso de métricas nos ajuda a tomar uma decisão informada para poder experimentar e avançar tomando riscos calculados, para que saibamos quão longe queremos ir e quando parar. Medir coisas significa validar ideias e buscar por aquelas capazes de entregar melhores resultados para o negócio, com o menor esforço e da forma mais simples que funcione. Significa jogar um jogo onde as regras são conhecidas e onde a equipe pode falar a mesma língua (voltada para o negócio), protegendo-se de decisões HiPPO (a opinião da pessoa com o maior salário) e frustrantes jornadas rumo ao fracasso.Sob uma perspectiva do negócio, estamos falando de problemas e oportunidades. Sobre não resolver um problema a tempo ou tomando tempo demais para agarrar uma oportunidade, fazendo com que um produto ou funcionalidade perca uma boa parte de seu potencial impacto.
Por exemplo, se tomamos em conta o tempo que se leva para desenvolver algo em relação a como essa funcionalidade pode se pagar se lançada tarde demais, ela ou custou demasiado ou vai levar mais tempo para se pagar. Pode acontecer ainda, em um cenário mais catastrófico, que a janela de oportunidade se feche permanentemente. Isso significa tempo e dinheiro investidos e nenhum retorno.
Processo de desenvolvimento de produto
O processo de desenvolvimento de produto que geralmente seguimos possui um ciclo de vida iterativo que vai da descoberta à entrega:
É fundamental entender esse processo porque, quando falamos sobre métricas, é fácil confundir quais métricas são relevantes em cada estágio do ciclo de vida do produto e como uma determinada métrica provê as evidências necessárias para que possamos passar ao próximo. Cada estágio possui diferentes objetivos e nós devemos trabalhar com métricas que, partindo de um alto grau de incerteza, vão nos levar a calibrar nossa certeza em relação ao nível de atingimento de nossos objetivos e validar o valor entregue pelo produto.
Durante a etapa de descoberta, nós temos uma definição de problema e algumas premissas. Estamos lidando com um alto grau de incerteza. Nós entramos nos detalhes durante a etapa de definição, criando um plano e uma hipótese que queremos avaliar rapidamente. Quando chegamos à entrega, estamos tentando garantir que tudo que vá à produção tenha sentido de estar e continuar lá.
Queremos medir a performance do produto em si e a performance do mecanismo de criação do produto. Assim como há uma pirâmide de testes, podemos imaginar uma pirâmide de métricas em cuja base estão as coisas que garantem que estamos fazendo certo a coisa e em seu topo aquelas que indicam que estamos fazendo a coisa certa. Ambas as partes devem estar em um constante fluxo de feedback e validação.
Como chegamos lá?
De volta à questão de problemas e oportunidades. À medida em que avançamos em nossa compreensão das oportunidades de negócio que estamos buscando, nossa capacidade de perceber outros problemas e oportunidades vai aumentar. Estamos explorando o desconhecido e gerando evidências para aumentar nossa certeza. Nós vamos encontrar novos caminhos e alguns bloqueios no caminho planejado. Isso frequentemente significa que encontramos um grau de complexidade mais alto ou problemas mais urgentes que devem ser endereçados para que se possa executar a visão — ou para que consideremos a oportunidade de calibrar a visão dado o novo conhecimento obtido.Levando essa discussão a uma visão de horizontes, nosso grau de certeza tende a ser mais alto para aquelas coisas que estão no H1, diminuindo progressivamente em cada horizonte seguinte, com nossa visão do escopo indo de funcionalidades concretas até apostas futuras. Nosso maior investimento de tempo deve ser naquilo que sabemos como fazer e, a partir do conhecimento que obtivermos, refinar nossa visão daquilo que podemos fazer no futuro. Desta forma, garantimos que estamos executando a visão do produto ou obtendo evidências de que devemos tomar um caminho diferente.
O que fazer então? Desde uma visão de negócio ou um conjunto de premissas que queremos verificar, devemos focar em pequenos incrementos de negócio. Devemos, acima de tudo, usar cada incremento funcional para medir o negócio e determinar se ainda estamos na direção certa. Lembre-se: uma direção dentro de vários caminhos "certos" possíveis, mas sempre uma que comprovadamente agrega valor ao negócio. Não é sempre fácil e nem sempre será possível, mas isso deve ser encarado tal qual uma diretiva primária: buscamos sempre agregar valor ao negócio em cada incremento funcional e queremos medi-lo de forma objetiva.
"Temos de encarar isso como uma oportunidade de começar a questionar a visão do produto e encontrar maneiras efetivas de associar nossas tarefas diárias a essa visão."
Podemos começar medindo se estamos fazendo certo a coisa. Em seguida, nos perguntamos como o valor de negócio pode ser percebido. Há uma questão básica a perguntar: essa nova versão do meu produto ou funcionalidade é melhor (ou ao menos igual) do que a versão anterior? O que podemos medir para responder a essa pergunta pode ser algo como um aumento de conversão, melhor satisfação de usuário, mais engajamento, qualquer coisa que faça sentido imediatamente.
Não é preciso que nos sintamos oprimidos por algum acrônimo esotérico tirado de uma revista de negócios e gestão. Ainda não. Antes, tente pensar em maneiras simples de determinar o quê o "está melhor agora" quer dizer. Quanto mais aprendemos sobre nosso produto e o impacto que ele gera em cada uma de suas iterações, melhor equipados estaremos para entender se coisas como ROI, NPS, RPU ou LTV são aquelas que nos vão ajudar em nossa jornada.
Conclusão
Entender o que é valor de negócio, como ele pode ser medido e como esse conceito se traduz objetivamente para cada um de nossos projetos deve ser considerado a higiene básica da vida de uma pessoa consultora, independentemente se seu papel na equipe. A incerteza e as possibilidades vêm no mesmo pacote e temos de garantir que estamos adequadamente equipadas para lidar com elas.Isso se traduz em sermos capazes de medir a saúde do nosso ambiente de desenvolvimento de produto bem como conseguir medir o impacto que cada incremento funcional traz ao negócio. Não fazê-lo significa que estamos seguindo um plano de olhos vendados, apenas porque ele nos leva a algum fim. O plano não é o objetivo. Ele é como imaginamos que podemos possivelmente atingir o objetivo, enquanto nos esforçamos para garantir que o objetivo faça sentido de verdade.
Faça uma pausa por um momento e pense no seu projeto atual. Você sabe qual é o objetivo dele? Como você pode ter certeza de que ele está sendo atingido? Você tem como medir o mecanismo de entrega de software e o impacto de cada incremento funcional sendo entregue?
E, mais importante, lembre-se sempre que "valor" é um conceito multifacetado: o que os clientes valorizam pode não ser a mesma coisa que o negócio vê como valor. Conheça seu cliente para conseguir medir sua percepção acerca do produto.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.