O modelo de negócio é assunto comum à profissionais na área de produto, empreendedores, dentre outros. E pode também ter valor para profissionais técnicos. O tema apresenta como o modelo de negócio pode ser utilizado por times de desenvolvimento de software para auxiliar na compreensão do verdadeiro objetivo e características do software.

Todo software é desenvolvido para atender uma necessidade e normalmente ela é uma demanda de negócio que pode facilitar ou até revolucionar o mundo.

Para times de desenvolvimento compreenderem todas as necessidades e expectativas de uma demanda de negócio, é importante que estes tenham acesso a mais informações do que apenas tarefas ou histórias, e embora estas sejam relevantes para a organização e execução do trabalho, podem mostrar apenas um pequeno pedaço do todo.

Uma forma de elevar a compreensão e empatia ao negócio é fazer com que times de desenvolvimento conheçam o modelo de negócio do projeto, produto ou empresa.

Se o time não tiver acesso a ele, ou não haver um modelo de negócio mapeado, é recomendável o diálogo com as pessoas responsáveis pelo negócio para o acesso ou mapeamento do mesmo.

De acordo com Alexander Osterwalder (criador da ferramenta Business Model Canvas), um modelo de negócio descreve a lógica de como uma organização cria, entrega e captura valor.

Há várias formas de mapear um modelo de negócio e atualmente o Business Model Canvas é a ferramenta referência no assunto, sendo ela a utilizada como base para a continuidade do tema e um conhecimento recomendável mesmo para profissionais de perfil mais técnico.

Visão do Business Model Canvas

A seguir o guia destaca como times de desenvolvimento podem fazer uso do Canvas para obter respostas para as seguintes questões do negócio:

• O quê?
• Para quem?
• Como?
• Quanto?

Ao conhecer as respostas, mesmo que não estejam mapeadas em um Canvas, times de desenvolvimento compreenderão melhor o motivo da construção do software e os recursos que deverão ser implementados.

Mapear um modelo de negócio não é uma atribuição de times de desenvolvimento, já compreendê-lo e usá-lo como apoio para decisões técnicas é fundamental para o sucesso e entrega de valor do software.

Proposta de valor

A proposta de valor mostra objetivo do projeto, ela responde a pergunta “O quê?” e ajuda os times entenderem qual o negócio principal que o software precisará atender, somado às características iniciais que deverão estar presentes. A seguir um exemplo de como times de desenvolvimento podem fazer uso da proposta de valor.

Um projeto fictício, de nome Guia Hóspede, definiu sua proposta de valor:

Ao analisar os cartões, entende-se que o negócio principal é a reserva de hotéis! Também é possível verificar atores importantes, no caso hóspedes e hotéis, e outras questões como:

• Hóspedes poderão comparar custos entre hotéis.
• Hóspedes poderão fazer reservas.
• As reservas terão que ser confiáveis.
• Hotéis poderão gerenciar suas reservas.
• Hotéis poderão visualizar as receitas vindas via o Guia Hóspede.

Com isso o time poderá compreender algumas necessidades que o software atenderá, como:

• Cadastro e manutenção de dados de hóspedes e hotéis.
• Controle de acesso e escopo de dados de hóspedes e hotéis.
• Hóspedes fazendo reservas e provavelmente pagando através da solução.
• Hotéis visualizando suas reservas, o que em casos onde já utilizem outros sistemas fará necessário haver integração e sincronização de dados com o Guia Hóspede.

Até chegar o momento da implementação, normalmente há a geração de épicos e histórias, detalhamento de requisitos, dentre outros artefatos que são utilizados pelos times de desenvolvimento. A vantagem em conhecer o modelo de negócio será justamente que os times compreenderão melhor o porquê de cada coisa, diminuindo ruídos e implementações fora das expectativas.

Em geral, para qualquer projeto é possível:

• Conhecer o domínio de negócio.
• Identificar contextos e entidades fortes do negócio.
• Identificar contextos secundários que podem pertencer a outros domínios/soluções.
• Visualizar necessidade de soluções Web, Mobile, etc.
• Visualizar possíveis integrações entre soluções.
• Entender que tipo de infraestrutura será necessária.

Ao conhecer a proposta de valor e a resposta para “o que?”, times de desenvolvimento compreendem o tamanho do desafio, e ainda mais relevante, o valor da solução para o cliente, o que contribuirá na empatia e engajamento para construir o software acreditando na ideia.

Segmento de clientes

Embora a proposta de valor às vezes indique atores do projeto, é no segmento de clientes que residem os detalhes reais sobre o público que irá utilizar o software, o que responde a pergunta “Para quem?”. Conhecer o segmento auxilia no direcionamento das soluções técnicas e construção do software, desde a escolha de tecnologias a priorização de entregas.

Seguindo o exemplo do Guia Hóspede, o segmento definido foi:

A figura de hóspedes e hotéis, aqui tem uma visão melhor, ainda não completa como em um processo de definição de personas, mas já com orientações úteis para o desenvolvimento de software.

No segmento de viajantes, pode-se compreender pessoas com vários níveis de familiaridade com tecnologia, logo o software deverá ser intuitivo, de boa usabilidade, acessível a qualquer idade, dentre tantos outros pontos que podem ser analisados.

No segmento de hotéis, provavelmente será necessário uma visão gerencial e talvez analítica, além disso hotéis com baixo poder de investimento dificilmente contam com pessoas com conhecimento técnico, poderá haver dificuldades se for necessário realizar integrações.

Em geral, conhecer para quem está sendo desenvolvido o software contribui para:

• Software melhor direcionado ao perfil do cliente.
• Maior capacidade de priorização por segmentos.

No guia, o tema Personas aprofunda o “para quem” e apresenta a relevância do assunto para questões técnicas e como os times podem atuar.

Canais e relacionamento

No Canvas, canais e relacionamento com clientes contém informações de maior valor para áreas de vendas, marketing, atendimento a clientes. Porém estes blocos ainda contribuem na resposta de “Para quem?”, e para times de desenvolvimento é onde deve-se buscar o entendimento sobre o modelo de aquisição de clientes, ou seja, como o cliente terá o contato inicial e será cadastrado no software.

O modelo de aquisição deve facilitar a resposta de questões como:

• Como o cliente será cadastrado na solução?
• O vendedor, ou time de atendimento irão cadastrá-lo?
• O cliente se cadastra através de um processo de “autocontratação”?
• Haverá uma versão trial ou free?
• Haverá planos pagos? Caso sim, quem fará a gestão de planos?

As respostas influenciam diretamente na forma de construção do software, cada resposta positiva pode levar a necessidade de implementação adicional no software. Abaixo, exemplos de questões que surgem:

• Se o cliente será cadastrado por vendedores, ou time de atendimento, eles deverão ter acesso ao sistema? Caso sim:
  • Quais dados são de responsabilidade do cliente e do vendedor/atendimento?
  • Haverá algum controle sobre vendas, implantação, comissão, etc?
  • Quais as políticas para uso de dados do cliente, já que terão acesso a eles?
• Se o cliente se autocadastrar, como validar a veracidade de seus dados?
  • Será necessário o cliente assinar um contrato? Caso sim, deverá ser online!
  • Em planos pagos, como será o processo de ativação? Somente após pagamento da primeira mensalidade? Após assinatura do contrato?
  • Quais meios de pagamento serão disponibilizados para os clientes?

Há no mercado soluções prontas que podem auxiliar ou até resolver essas questões, porém ainda assim poderão haver detalhes que não sejam atendidos em função de especificidades do negócio. Quanto antes for conhecido o modelo de aquisição, mais fácil será atuar sobre a solução, evitando processos de reconstrução do software, que podem comprometer o próprio projeto.

Atividades chave

No Canvas as atividades chave são parte da resposta para pergunta “Como?” o negócio será atendido.

Desenvolver e manter o software normalmente é uma atividade chave, junto a outras atividades que podem em um primeiro olhar não envolver times de desenvolvimento, mas que ao serem aprofundadas podem gerar necessidades no software.

Esse bloco também destaca que um negócio ou produto precisa mais do que apenas software para acontecer e ter sucesso.

Seguindo o exemplo do Guia Hóspede, itens presentes em atividades chave:

O primeiro cartão mostra justamente como o software é essencial para o atendimento do negócio.

O segundo cartão traz a visão de que o software poderá estar pronto mas se não houver hotéis cadastrados na solução, o projeto poderá não ter sucesso. Vale aqui para o time de desenvolvimento a reflexão de como pode contribuir com isso, um exemplo é garantir um software simples e confiável para os hotéis.

O terceiro cartão pode gerar a necessidade de um módulo administrativo no software, que possibilite à empresa dar o devido suporte aos clientes. O tema Suporte e Operação aborda em mais detalhes essa questão.

Parceiros

Na resposta de “Como?” o negócio será atendido, parcerias podem ser necessárias, o que em muitos casos gera no software a necessidade de integração com os parceiros.

Seguindo o exemplo do Guia Hóspede, foram definidos os seguintes parceiros:

No Guia Hóspede hotéis aparecem como clientes e também como parceiros, o que reforça um relação diferenciada e provavelmente mais próxima. Isso poderá refletir em funcionalidades no software direcionadas ao hotél na figura de parceiro.

Uma outra necessidade apresentada é a de disponibilizar para os hóspedes a opção de pagar pela reserva, para isso será necessária uma integração com processadoras de pagamento. O negócio principal do Guia Hóspede é reservas de hotéis e não processamento de pagamentos, desta forma essa necessidade será atendida através de um parceiro.

Em geral, os parceiros estão mais associados ao negócio em si do que ao software, porém times de desenvolvimento podem contribuir nessa questão indicando parcerias que viabilizem ao negócio o atendimento de necessidades sem que os próprios times precisem implementar todo o software, principalmente quando a necessidade envolve questões que são secundárias ao domínio de negócio do projeto.

É comum também cenários onde parceiros utilizem o software, com acesso focado em analisar informações relacionadas a parceria.

Estrutura de custos

No Canvas este bloco ajuda a responder a pergunta “Quanto?”, no caso o quanto custa a solução como um todo. Esse custo contabiliza os times de desenvolvimento e infraestrutura de tecnologia utilizada no dia a dia.

Desta forma, é válido que os times estejam conscientes do poder de investimento no projeto para mantê-los. Para isso é necessário que os responsáveis pelo projeto sejam transparentes e claros no diálogo com os times. E aos times, considerando que o mais importante é atender ao negócio e não necessariamente apenas construir o software, é adequado serem pró ativos com relação a trabalharem dentro das capacidades de investimento do projeto.

Tamanho do time de desenvolvimento

Embora normalmente sejam essenciais para o projeto, times de desenvolvimento são um custo na composição de um modelo de neǵocio e seu tamanho influencia na construção e vida do projeto. Na linha de transparência com os times, alguns números relevantes que variando da política do projeto ou empresa podem ser apresentados:

• Custo total do time.
• Receita atual com o negócio.
• Previsão de receita de futuras entregas de software.
• CAC (Custo de aquisição de clientes), mesmo sendo uma métrica mais associada a marketing, times de desenvolvimento também entram na conta.

Em geral, o mais importante não é ser um time grande ou pequeno, mas sim eficiente e que entregue software dentro de um custo condizente com a capacidade do projeto.

Infraestrutura de TI

Os times de desenvolvimento são normalmente os responsáveis pelas decisões relacionadas à infraestrutura que será utilizada para construir e manter o software em funcionamento, o que reforça a relevância de conhecerem a capacidade de investimento para o projeto.

Custos de infraestrutura não previstos, ou que com o crescimento do negócio e quantidade de clientes aumentam em grandes proporções podem afetar diretamente várias métricas do projeto, como a já citada CAC, chegando ao ponto de inviabilizar o negócio.

Alguns custos (mensais ou anuais) que podem ser gerenciados e apresentados aos times:

• Custo com ferramentas para desenvolvedores(as).
• Custo com servidores e serviços utilizados, agrupando-os por ambientes como produção, staging, dentre outros.
• Custo com armazenamento de dados, tempo de processamento, dentre outros.

Um acompanhamento dos times com relação a esses custos é o que possibilita o trabalho para redução deles.

Fontes de receita

Respondendo a pergunta “Quanto?”, focada na receita financeira da solução, as fontes de receita no Canvas indicam como o cliente será cobrado, o que demandará provavelmente que o software dê suporte para quantificar dados relacionados a seu uso.

Um software pode ser cobrado pela sua aquisição ou uso, sendo isso o que “paga” sua construção, manutenção e evolução. Para possibilitar a cobrança geralmente é necessário quantificar o uso de recursos como:

• Número de usuários.
• Número de transações.
• Número de acessos.
• Quantidade de dados trafegados ou persistidos.
• Funcionalidades disponíveis.

O recurso utilizado pode variar de acordo com o negócio, estratégias de mercado, etc. O importante para times de desenvolvimento é ter clareza com relação a quais recursos serão quantificados, isso porque o software deverá comportar a capacidade de disponibilizar esses dados. Não considerar essa questão desde o início da construção do software pode gerar necessidade de reconstrução de partes do mesmo, ou pior, pode inviabilizar a adequada tarifação pelo seu uso.

Há várias estratégias para quantificar esses dados e não há necessariamente uma mais adequada. Porém há algumas estratégias técnicas que podem ser consideradas para evitar que código e lógica associados a tarifação se misturem ao negócio principal do software. Cita-se algumas:

• Evitar o uso de atributos exclusivos do contexto de tarifação na modelagem usada para o negócio. Toda modelagem referente a tarifação pode estar em um contexto separado, tal abordagem pode ser melhor vista no tema Modelo de domínio.
• Fazer processamento de totalizações separado do processamento dedicado ao uso dos clientes. Ter dados para tarifação é uma necessidade do projeto e não pode afetar o uso do cliente.
• Executar processamento em datas ou períodos pré-estabelecidos, assim quando as informações forem solicitadas já estarão totalizadas.
• Considerar uso de soluções de terceiros, especializadas nesse contexto, integrando o software a elas e exportando os dados necessários.

Em resumo, times de desenvolvimento são peça importante para viabilizar as fontes de receita.

Quando utilizar

Entendendo melhor a utilidade do modelo de negócio para times de desenvolvimento, o momento de utilização do mesmo fica a critério da necessidade dos times, porém abaixo segue alguns momentos recomendados:

• Início de projeto, sendo aqui sua maior utilidade.
• Novas funcionalidades/recursos, se o time sentir necessidade.
• Chegada de novos integrantes aos times, onde poderão ter contato com o negócio sem tomar um tempo maior de quem já está no time.
• Decisões em geral onde o time esteja com dúvidas sobre o foco do projeto e revisitar o modelo poderá realinhar o time.

É comum que empresas startups ou projetos mais novos possuam um mapeamento do modelo de negócio, já em projetos ou empresas de maior idade normalmente essa informação está diluída em outros formatos ou apenas na memória das pessoas.

Nestes casos, onde inclusive o software já existe, mapear o modelo de negócio pode parecer uma tarefa desnecessária, e em certos casos realmente não faz sentido, principalmente se o software não sofre grandes alterações.

Porém, se ainda há uma rotatividade de profissionais nos times, se ainda há o planejamento de novas versões e funcionalidades, ter em mãos ao menos as respostas para “O que? Para quem? Como? Quanto?” poderá contribuir para o trabalho dos times.

O modelo de negócio fictício do Guia Hóspede utilizando o Business Model Canvas pode ser acessado aqui em sua versão PDF.