Quando um serviço pede algo que ainda não existe

Uma coordenadora de terapias descreve a sessão que faz às quintas de manhã, com um grupo específico, de uma forma específica — e pergunta se o headset consegue fazer aquilo.

Às vezes já consegue. Outras vezes não, e na maior parte do software é aí que a conversa acaba. O pedido vai para uma lista. Compete com todos os outros pedidos de todos os outros clientes e, se algum dia sair, sai para toda a gente, dezoito meses depois, numa versão limada até caber na média.

Não é falta de boa vontade. É o que acontece quando um produto é uma coisa só. Tudo o que se acrescenta, acrescenta-se a tudo.

O RVer não é uma coisa só. É uma base mais módulos — e isso muda a resposta.

O que um módulo realmente permite

O RVer é uma plataforma nativa para o Meta Quest 3 e corre inteiramente no equipamento. Sem contas, sem login, sem dependência da nuvem — nenhum dado de utente sai da instituição.

A capacidade é empacotada em módulos, licenciados e ativados por dispositivo:

• RVer — a biblioteca base de vídeo imersivo 360°
• RVer Motion — atividades de movimento e fisioterapia
• RVer Neuro — atividades de treino e estimulação cognitiva

Como a capacidade vive em módulos, e não fundida numa aplicação única, algo novo não tem de ser feito para toda a gente para poder existir. Pode ser feito para um caso de uso — um tipo de sessão, uma população, uma maneira própria de uma equipa trabalhar. Pode ser feito para um único cliente. Pode ficar ativo num só dispositivo, numa só sala, se for aí que faz sentido.

Portanto a coordenadora não está a pedir que se altere um produto de que dependem todos os outros serviços. Está a pedir um módulo. É uma pergunta muito mais pequena, e muito mais respondível.

Os serviços que não pediram nunca o veem

Esta parte importa mais do que parece.

Software que acumula tudo o que alguém alguma vez quis torna-se pesado para quem o usa todos os dias. Uma auxiliar que vai iniciar uma sessão antes do almoço deve ver as poucas coisas que o seu serviço faz — e não um menu carregado com os requisitos de outra instituição.

Os módulos mantêm isso verdadeiro. Um dispositivo leva aquilo que o seu serviço ativou e mais nada. O crescimento da plataforma não se transforma em confusão no headset, e ninguém é formado em funcionalidades que eram para outra pessoa.

Também significa que um módulo à medida não é uma versão à parte. Está tudo na mesma base, gerido da mesma maneira, atualizado da mesma maneira. Uma frota, seja qual for a combinação de capacidades a correr nela.

E chega sem que ninguém se desloque

Os módulos são ativados remotamente, e tanto a aplicação como os conteúdos atualizam pela rede.

Uma decisão tomada numa terça-feira está ativa na frota. Sem reinstalação, sem ninguém no corredor, sem headsets encaixotados e enviados para parte nenhuma. Quando um módulo que o serviço já tem ganha novas atividades, elas simplesmente aparecem.

Foi assim que a versão mais recente chegou às frotas que já a corriam: tanto o RVer Motion como o RVer Neuro ganharam novas atividades, e os dados de movimento que o RVer Motion entrega ao clínico tornaram-se mais detalhados. Nada foi instalado à mão e nenhum equipamento mudou.

O lado comercial disto — pagar apenas pelos módulos que se ativa, e apenas nos dispositivos em que se ativa — já escrevemos à parte, em porque é que um software modular é melhor para uma instituição de saúde. Aqui o ponto é mais estreito: o que a arquitetura permite construir, e não o que permite poupar.

O que isto é, e o que não é

O RVer Motion é um auxiliar de exercício e registo de movimento. O RVer Neuro é treino e estimulação cognitiva, atualmente em piloto de co-validação com uma clínica de neurologia e não está clinicamente validado. Ambos apoiam o clínico — nenhum o substitui, e nenhum toma decisões clínicas.

O que se adapta aqui é comercial e operacional: que capacidade fica ativa, em que dispositivos, em que sala. O juízo clínico continua onde estava.

De onde vem o roteiro

Outros módulos estão em desenvolvimento, e a resposta honesta sobre a sua origem é simples: foram serviços que pediram.

Isso só é viável porque uma boa ideia para uma instituição não tem de se tornar uma alteração para todas as instituições. O pedido que seria demasiado específico para um produto monolítico — demasiado pequeno, demasiado particular, demasiado a maneira de trabalhar de uma equipa — é exatamente o pedido a que uma plataforma modular consegue dizer que sim.

Se o vosso serviço tem um desses, preferimos ouvi-lo.

← Voltar ao blog