A simplicidade complexa da construção de produtos (digitais)
Aprendi nesse quase um ano e meio à frente de um time de produtos dedicado à concepção e desenvolvimento de software (ou produtos digitais, em sua versão hipster), que construir soluções digitais é muito simples. Mas antes de alegarem que digo isso por ser economista e não conhecer quase nada de código, reforço que é simples mesmo, mas ao mesmo tempo altamente complexo. Me explico. Um bom produto que gera retorno e impacto passa por três simples pilares: Efetividade, Qualidade e Velocidade. Na sequência pretendo detalhar um pouco cada um desses pontos e ao mesmo tempo não adormecer o leitor.
Efetividade
Todo produto ou software tem uma razão de existir unificante: Resolver Problemas. Logo, um bom produto resolve efetivamente aquilo que se propõe. Na verdade, muitas vezes, uma solução resolve muitos pequenos problemas para endereçar um grande. Ser Efetivo é entregar valor de fato (mensurável): conectar profissionais procurando emprego com o emprego certo (LinkedIn); ou conectar Hospitais que querem comprar insumos com Fornecedores que querem vender (bionexo).
Efetividade requer uma investigação profunda de necessidade, que passa por UX, UI e outros Us bem como pelos PO’s, PM’s e outros P’s. Que por sua vez podem se valer de metodologias mais ou menos caretas, como os “Cinco Porquês”, ou “Five Whys”, que são perguntas sequenciais para se chegar ao cerne de um problema (recomendo). Claro que sempre contando com a sapiência dos Devs, DevOps e outras tantas siglas em inglês que se fossem em português me sentiria em um Depto. de Pesquisa de uma Universidade Pública.
Qualidade
Ser efetivo em resolver o problema hoje, não significa resolver amanhã ou daqui a 10 anos. Qualidade é muito isso. Um produto idealmente não só soluciona alguma coisa hoje, mas o faz de maneira sustentada e idealmente barata, de modo que seu codificador, ops.. coder ou desenvolvedor, ou engenheiro ou whatever não seja o único do mundo que sabe o que tem por trás. Para isso é essencial documentar, por escrito de preferência, tudo bonitinho (para mais ver este blog post). Três bugs para cada issue, a qual a correção gera mais três também não é qualidade (mais uma referência prata da casa sobre qualidade neste blog post).
Além disso, qualidade também passa por monitorar o fluxo de dados: quanto vai daqui pra lá, por onde vai, aonde pára e quando segue. Importante também garantir a integridade das informações, balancear cargas e serviços e tantos outros critérios importantes para que um produto não se desvaneça no tempo, o promotor no NPS não tropece na escala terminando o dia como detrator e a AWS não sorria (tanto) com nossas contas com eles.
Velocidade
Para quem não lembra, Velocidade significa a variação da posição no espaço em relação ao tempo, ou seja a distância percorrida em um intervalo de Tempo. Resolver efetivamente um problema identificado e com um produto de qualidade, não faz sentido na eternidade e, tão pouco em intervalos tidos hoje como longo prazo, tipo um ano. As necessidades mudam rápido e as ferramentas para resolvê-las também. Portanto o fator tempo é essencial.
Pausa para desabafo: não existe nada fora do tempo (ou do espaço) e também não sei de onde que linhas de interpretação (rasas) do Manifesto Ágil defendem a não existência de prazo, que é nada mais que o objetivo no tempo. Aliás, sem o componente tempo, a própria palavra Ágil tem sua existência semântica completamente esvaziada. Como no diálogo do Gato e Alice — Para quem não sabe aonde vai, qualquer caminho serve. De maneira análoga — Para quem não sabe para quando, qualquer data serve. Mas isso é (só) no País das Maravilhas, “(…) marciano, aqui quem fala é da terra” e aqui as vezes a coisa esquenta.
Levar tempo demasiado para endereçar uma necessidade de mercado pode significar não ter mais que resolvê-la pois ela já não existe, o cliente já se mandou ou, mais provável, alguém já resolveu na sua frente.
A velocidade não precisa ser necessariamente muito alta, mas é preciso mover no tempo em direção ao ponto de chegada. Além disso, quanto mais linear a trajetória mais longe se vai com a mesma velocidade. Não entenda linear como algo que prescinde das iterações circulares de uma boa dinâmica ágil, mas sim como um projeto que tenha cadência e sabe onde, e quando, quer chegar.
Bom, dados estes simples princípios de Efetividade, Qualidade e Velocidade, caberia uma pergunta pertinente: Mas essas três dimensões do desenvolvimento de um produto não seriam muitas vezes concorrentes entre si? Sim. Adicionalmente, além de concorrente, essas dimensões seriam não binárias certo? Sim. Tem problemas que eu posso resolver, mas não inteiramente, qualidade pode significar ter cobertura de 1 ou 99,99% de teste, bem como a velocidade também varia e flutua.
Logo surgem as perguntas: Será que quanto mais rápido menor qualidade? Qual o nível de qualidade ideal dada a criticidade deste problema? O quanto preciso acelerar a resolução de algo para que já haja uma percepção inicial de valor?
Aí é que entra um pouco do que um non-tech em produto aprendeu ser útil do seu conhecimento econômico. A vida é feita de escolhas (ou trade-offs), ou seja, as vezes é preciso recortar o problema para ganhar velocidade. O quanto de recorte para o quanto de velocidade, ou quanto de qualidade podemos abrir mão para ganhar 5 metros por segundo de throughput é em essência, assumir riscos, precificá-los (de veras) e buscar o resultado líquido mais positivo possível. Quem souber como fazer isso me avise? Estamos contratando. Bem-vindos então à parte (mega) complexa dessa simples missão de construir produtos digitais.
