A publicação surgiu na véspera do lançamento previsto
A 31 de julho a conta da Google AI Studio publicou uma nota breve a agradecer às cerca de 800.000 pessoas que tinham reservado a sua aplicação móvel em iOS e Android. Essa nota não anunciava um lançamento. Era um cancelamento. A aplicação autónoma não iria sair de todo.
As notícias do mesmo dia situavam a saída prevista a 1 de agosto, o que coloca a decisão dentro das últimas vinte e quatro horas de um calendário de entrega. As reservas estavam abertas no Google Play e na App Store desde a conferência de programadores I/O deste ano, tempo mais do que suficiente para que muitíssimas pessoas registassem o seu interesse e para que algumas organizações já tivessem escrito essa aplicação num plano.
Os números de reservas costumam ser citados como prova de que um lançamento está garantido. Este foi citado no aviso de que o lançamento tinha sido cancelado. É precisamente essa inversão que vale a pena guardar.
A Google indicou a razão, e não era o produto
Os cancelamentos chegam normalmente embrulhados em nada. Este chegou com uma explicação, e a explicação é invulgarmente direta. "Em vez de lhe pedirmos que descarregue mais uma aplicação, decidimos adotar uma abordagem totalmente diferente: uma em que as aplicações surgem de forma natural, no decorrer das suas conversas quotidianas com o Gemini", escreveu a empresa. Para isso trabalha com a equipa da aplicação Gemini, tanto no telemóvel como no computador.
Releia a primeira parte. A objeção não visa a qualidade da aplicação, nem a sua maturidade, nem o custo, nem a receção. A objeção visa a descarga. Na mesma nota a empresa disse ter ficado claro que as pessoas querem construir software enquanto se deslocam, o que constitui um reconhecimento explícito de que a procura medida era real.
A sequência é, portanto, esta: procura confirmada, produto terminado, lançamento cancelado. Nada nesta sequência é um falhanço de produto. É uma decisão sobre onde deve viver uma capacidade, tomada por quem detém a superfície de distribuição e não a funcionalidade.
A superfície separada é o que importa vigiar
A maioria dos compradores avalia o risco do roteiro de um fornecedor com números de adoção. Alguém usa, está a crescer, o fornecedor comprometeu-se publicamente. Os três são instrumentos errados, porque aqui os três estavam positivos e nenhum contou. Oitocentas mil inscrições são mais ou menos o sinal de procura mais alto que uma equipa de produto consegue gerar antes de entregar, e ainda assim perdeu.
O instrumento que teria funcionado é estrutural e aplica-se num minuto. Faça duas perguntas sobre qualquer capacidade de fornecedor de que dependa. Chega até si através de uma superfície própria, ou seja, aplicação própria, consola própria, portal próprio ou linha própria na fatura? E essa superfície faz um trabalho que o produto principal do fornecedor poderia plausivelmente absorver? O que responder que sim às duas é candidato a consolidação, independentemente de estar a correr bem.
Isto não prevê que todas as funcionalidades assim desapareçam. Diz qual é o risco que está realmente a suportar. Quando um fornecedor consolida, a capacidade costuma sobreviver e a superfície não, pelo que a perturbação a planear não é a perda de uma funcionalidade. É uma migração forçada segundo o calendário do fornecedor e não segundo o seu.
O que sobreviveu mostra onde o fornecedor está a sério
A versão web do AI Studio não foi tocada. A Google afirmou continuar a investir nela e posicionou-a para quem quer ir de uma ideia a uma instrução e daí a um negócio. Esse enquadramento é a metade útil do anúncio, porque separa as duas superfícies por intenção: uma é para quem constrói e ficou, a outra duplicava um trabalho que o assistente principal já sabia fazer e desapareceu.
Para uma equipa que planeia, a leitura é assim mais estreita do que "aqui não se pode contar com a Google". É que a superfície para programadores levava o compromisso e a superfície próxima do consumidor levava o risco. Quem pensava construir um fluxo de trabalho na aplicação móvel teria atravessado a semana sem alterações se o tivesse construído sobre a versão web e as interfaces que a sustentam.
Para as equipas europeias há um ponto adicional. Uma capacidade que se muda para uma aplicação de assistente geral não muda de sítio de forma neutra, porque as condições, os controlos administrativos e o tratamento de dados de um assistente de consumo não são automaticamente os de um produto para programadores. Quando um fornecedor anuncia uma mudança destas, peça essa comparação por escrito antes de planear em torno da nova casa, e não depois.
A superfície pertence ao contrato, não ao diapositivo
A alteração prática é pequena. Quando uma capacidade de fornecedor entra num plano, indique a superfície de entrega no documento que vincula, e não apenas a capacidade. "Criação de aplicações disponível na aplicação móvel do fornecedor" e "criação de aplicações disponível" são compromissos diferentes, e só um deles sobrevive a uma consolidação. Se o fornecedor recusar indicar a superfície, essa recusa também é informação, e sai mais barata agora.
O custo de não o fazer não é dramático, e é por isso que se salta. Uma equipa que tivesse colocado 20.000 euros de tempo interno contra uma construção móvel neste trimestre não perdeu a capacidade nem perdeu o dinheiro. Perdeu o calendário, e fica a saber com um dia de antecedência através de uma publicação numa rede social em vez de um pré-aviso previsto num contrato. É uma perda pequena, evitável e perfeitamente repetível.
Leia a seguir: Bruxelas acaba de pôr um preço aos dados de pesquisa da Google | Os chips caíram 20%. A sua conta de computação não
