Definir o problema, por mais redundante que isso possa parecer, é o maior dos problemas e consequentemente a solução.
Esta postagem foi originalmente divulgada no site www.nossaciencia.com.br e está reproduzida aqui com a autorização do autor.
Em incursões nas quais sou convidado a participar em empreendimentos, seja opinando ou atuando, percebo que os gestores por estarem sobrecarregados com ações a executar: “apagar fogo”, pensarem as próximas demissões (a dele também), contratar consultorias milagrosas, diminuir custos dos setores, maximizar lucros, criar produtos ou serviços; lançar ou parar uma campanha, terceirizar atividades-meio ou fim, o repertório de sempre, esquecem de parar para pensar o que é a origem de toda boa abordagem: o problema foi definido? Veja bem: a pergunta não foi se ele foi mal ou bem definido. A pergunta é imperativa: FOI definido?
Parece óbvio, mas a ação de definição precede até a diagnose, cujo significado está mais para trabalhar a razão da existência do problema (portanto quando ele já existe, claro!) o que nos traz de volta ao problema. Se ele já existe, temos que trabalhar para eliminá-lo e não criar tratados sobre a beleza de sê-lo. Se pensamos mal, planejamos péssimo e elaboramos pior ainda. Para se ter ideia, na disciplina que ministro em nosso Mestrado de Inovação, Teoria para Resolução Inventiva de Problemas, ou simplesmente TRIZ para os íntimos, utilizava, no início, 10% do tempo para trabalhar a definição do problema. Com o caminhar do andor, essa parcela subiu para mais de 30%. Definir o problema, por mais redundante que isso possa parecer, é o maior dos problemas. A solução, que é o mais buscado, será sua consequência.
De forma geral, o caminho que proponho na disciplina segue a sequência: identificação do problema, definição do tipo, seleção das ferramentas para análise de cada um dos tipos e, finalmente, sugestão das ferramentas de abordagem. Observem: ao final de todo este trajeto, consigo encapsular o meu problema. De posse desse desenho, é possível diferenciar perfeitamente a causa da consequência. O resto fica a cargo da criatividade e da gestão de projetos.
Depois desta “teorizada”, vamos aos tipos existentes. Ainda bem!
Tipos de problemas
De um modo geral, costumo enquadrar os problemas técnicos ou administrativos em duas categorias: Específica (reativa ou proativa) ou Geral (proativa). Estes ainda podem conter dois tipos:
Categoria Específica. Contém o Tipo 1, aqueles cuja causa é desconhecida, e o Tipo 2, com causa conhecida.
Categoria Geral. Temos o Tipo 3, aquele que envolve desenvolvimento ou aprimoramento de algo em prol da solução, e o Tipo 4, referente à prevenção de falhas.
Cerca de 95% dos problemas são enquadrados nestes quatro tipos. Determinado seu formato, fica mais fácil traçar uma estratégia de solução.
Alguns exemplos de problemas técnicos.
Tipo 1. Vazamento em longos trechos. Imagine detectar um vazamento em um oleoduto entre Natal e Mossoró. O problema não é o vazamento, pois é facilmente detectado, já que a diferença da vazão entre o início e o fim do trajeto já foi detectada. O problema real é encontrar o furo em 280 km de linha. A solução, que é sua consequência, é simples: tapar o furo. Portanto, temos um problema específico com causa desconhecida!
Um problema Tipo 1 ocorreu recentemente em um duto no México, causando uma explosão que vitimou muitas pessoas. As autoridades levaram dias para encontrar o vazamento, o qual parece ter sido causado de forma intencional. O vazamento não foi um problema em si. Encontrar o furo sim, pois se dependia disso para evitar a explosão.
Tipo 2. Choque térmico. Esse já aconteceu comigo, ao retirar a garrafa de vidro da cafeteira e colocá-la imediatamente em cima de um balcão frio. Resultado: comprar outra garrafa. Portanto, um problema específico com causa conhecida.
Tipo 3. Melhoria de performance. Imagine aumentar a autonomia de um veículo movido a combustível. Várias são as soluções: atuar na mistura do combustível, potência, materiais, modo de direção, peso do veículo. Então, tem-se um problema geral de aprimoramento.
Tipo 4. Prevenção. Esse mora no campo das companhias de seguro. Airbags, cinto de segurança, EPI (Equipamento de Proteção Individual) etc. Observe que temos problemas de ordem geral que envolvem prevenção. Na verdade, nestes casos, tenta-se evitar que o problema aconteça, utilizando-se para isso Abordagens Subversivas. Não se assombrem: os testes de colisão de veículos utilizam esta abordagem!
Assim, é necessário definir corretamente o problema, pois disto dependerá o esforço envolvido e a eficácia da solução, o que pode evitar danos irreversíveis a muitas pessoas e startups. As propostas de valor dos modelos de negócio de inovação incremental – a grande maioria – repousam quase que exclusivamente na definição correta do problema a ser atacado.
Mas, e a versão administrativa para estes quatro tipos de problema? Para que o texto não fique cansativo, deixarei para o leitor como exercício. Esta tipificação se mantém inalterada.
Nas startups, os problemas técnicos estão mais associados a questões de infraestrutura. Já os administrativos, a processos. Esta é a questão central a ser definida, a qual determina uma das principais características das startups: a escalabilidade, ou o poder de se replicar ou replicar processos desenvolvidos, caracterizando a multiplicação da solução sem incremento de custo.
Deste modo, primeiro têm-se que tipificar o problema e, com base nele, determinar se o modelo de negócio no qual sua proposta de valor está centrada envolve processo ou estrutura, pois os custos são incomensuravelmente diferentes, o que pode determinar a viabilidade da startup. Vamos aos desenhos mentais então.
Interlúdio: peço desculpas gráficas ao leitor. Se não consigo desenhar qualquer coisa, não consigo partir para seu desenvolvimento. É só uma característica.
Vale da morte
Conversando com “startupeiros” que já possuem um canvas raiz e um MVP “tinindo”, chega-se àquele momento em que a startup entra no vale da morte, momento que paira entre a entrega da proposta de valor e a respectiva sinalização do nicho, a qual pode ser convertida em sustentação para a startup.
Vale da Morte: momento decisivo entre “a entrega da solução” e o “payback”. (Figura extraída do SaaSholic )
Nesse exato momento, com o feedback ancorado em informações corretas, temos que botar o BI para funcionar e determinar se devemos partir para vender nossa solução ou escalar a startup. E aí, o pleno entendimento do tipo de problema que se tem em mãos, pode colocar você na Avenida Paulista ou na Galeria Pagé, na 25 de Março, vendendo bugiganga.
Modelo de negócio: Funil ou Pilão?
Se a startup apresenta uma solução e ela tem condições de suprir a demanda solicitada pelo nicho, há um equilíbrio de forças, e ela é dita escalável. Nesse caso, o formato que vem à mente é de um Pilão, como mostra a figura. Nesse caso, a “cintura” do pilão, que é um aparente gargalo, pode ser resolvida por meio de processos ágeis, com a correta aplicação da BI. Tenho então um problema de processo.
Por outro lado, se não tenho condições de suprir a demanda crescente que se avizinha, a startup apresenta-se menor do que as solicitações do nicho. Se ela optar por se arriscar a contemplar essa demanda, terá de investir em estrutura, além de processos, pois percebe-se a necessidade de investimento em insumos físicos, pois ter uma excelente solução e não conseguir entregar é o mesmo que não ter. O desenho que vem à mente é a de um Funil, cuja base terá de ser expandida, caso se queira escalar a solução de modo a contemplar o nicho a contento. Nesse tipo de desenho, funil, o recomendado seria vender a solução ou se precipitar no vale da morte e pagar.
Funil ou Pilão. Estrutura ou Processo?
Então é isso pessoal: a correta definição do tipo de problema e, na sequência, do modelo de negócio que vai emergir da respectiva solução, separa os empreendedores dos aventureiros.
Como diria um velho amigo meu: “Quem é grande sem poder, é pequeno sem querer!”.
De que tamanho você quer ser quando crescer? Sayonara!
