Se a sua app deixar de funcionar amanhã, quem recebe o alerta e quem pode intervir?

Se a resposta for «ligamos a quem a desenvolveu», falta transformar essa relação num plano. Para uma empresa com uma app em utilização, a manutenção deve definir o que é acompanhado, quando há intervenção e como se confirma que o serviço ficou recuperado.

Não comece por negociar um número de horas mensais. Comece pelo trabalho que o seu negócio precisa de proteger. Depois, peça uma proposta que cubra esse trabalho e identifique claramente o que fica de fora.

Comece pela operação que não pode parar

Imagine uma empresa portuguesa de aluguer de equipamentos com uma app onde os clientes consultam contratos e pedem prolongamentos. Use este exemplo como exercício, não como relato de um caso real.

Uma imagem mal alinhada e um pedido de prolongamento que desaparece não merecem a mesma prioridade. No segundo caso, a empresa precisa de perceber se recebeu o pedido, evitar uma cobrança indevida e dar uma resposta ao cliente.

Antes de falar com a equipa técnica, escolha os percursos que pretende proteger. Para cada um, responda:

  • Que tarefa está o cliente a tentar concluir?
  • Como sabemos que foi realmente concluída?
  • Existe uma alternativa enquanto a app está indisponível?
  • Quem decide suspender temporariamente essa função?
  • Quem informa os clientes afetados?

Não precisa de classificar todos os ecrãs. Precisa de distinguir uma falha incómoda de uma interrupção da operação.

Na nossa empresa hipotética, consultar uma fotografia do equipamento pode esperar. Confirmar um prolongamento exige acompanhamento. Esta distinção deve orientar o plano de manutenção, os alertas e a ordem das correções.

Uma matriz para decidir quando intervir

A tabela seguinte é uma proposta de trabalho. Adapte-a à sua operação antes de a incluir num acordo com um fornecedor. As prioridades não representam uma norma nem impõem tempos universais de resolução.

| Prioridade | Critério de negócio | Exemplo hipotético | Resposta a acordar |

|---|---|---|---|

| Crítica | Há risco para os dados ou uma operação essencial está bloqueada sem alternativa | A app apresenta um contrato pertencente a outro cliente | Interromper a função afetada quando necessário, mobilizar os responsáveis e acompanhar até à contenção |

| Alta | Uma tarefa essencial falha, mas existe uma alternativa utilizável | O cliente não consegue pedir um prolongamento, mas o apoio pode registá-lo | Ativar a alternativa, identificar os utilizadores afetados e dar prioridade à correção |

| Normal | Uma função secundária falha sem impedir a operação principal | O histórico abre, mas não permite ordenar contratos antigos | Registar o impacto e agendar a correção |

| Melhoria | Não há avaria; pretende-se alterar o produto | Acrescentar pesquisa por referência do equipamento | Avaliar e orçamentar fora da resposta a incidentes |

Acrescente ao acordo o horário de cobertura, o canal de contacto e o prazo para a primeira resposta de cada prioridade. Identifique também quem pode alterar a classificação quando surgem novos dados.

Primeira resposta, contenção e resolução são compromissos diferentes. Recomenda-se que a proposta os separe: reconhecer um incidente não equivale a limitar o seu impacto, e disponibilizar uma alternativa não significa corrigir a causa.

Peça ainda uma regra de comunicação. Durante uma interrupção, o responsável do seu negócio deve saber quando recebe a próxima atualização, mesmo que a equipa ainda não tenha encontrado a solução.

O acompanhamento deve mostrar falhas reais

No Android, o Android vitals disponibiliza indicadores de estabilidade e desempenho na Play Console. A Google identifica métricas principais de qualidade que podem influenciar a visibilidade da app no Google Play. Portanto, acompanhar a estabilidade também ajuda a proteger a distribuição do produto. (developer.android.com)

A taxa de falhas sentidas pelo utilizador permite observar problemas durante a utilização ativa da app. A documentação Android recomenda investigar padrões associados, por exemplo, à versão da app, ao modelo do dispositivo e à versão do sistema operativo. (developer.android.com)

Para iPhone, os relatórios de falha e os registos dos dispositivos ajudam a investigar encerramentos inesperados. A Apple recomenda procurar padrões nos relatórios para orientar o diagnóstico. (developer.apple.com)

O que deve pedir à equipa? Um resumo que permita decidir, em vez de uma coleção de gráficos:

  • Que problema apareceu e em que versão?
  • Que utilizadores ou dispositivos parecem afetados?
  • Que tarefa fica comprometida?
  • A situação piorou depois da última atualização?
  • Há informação suficiente para agir ou falta reproduzir a falha?

Acrescente uma verificação própria do negócio. No exemplo do aluguer, proponha comparar pedidos iniciados com prolongamentos efetivamente registados. Defina com a equipa como recolher essa informação sem guardar conteúdo pessoal desnecessário.

Não aceite «não houve reclamações» como único critério de sucesso. Peça evidência de que os percursos escolhidos continuam a funcionar, com testes e indicadores adequados à utilização da sua app.

Separe a rotina das intervenções extraordinárias

O plano deve reservar espaço para prevenir problemas, além de responder a avarias. Use a cadência seguinte como ponto de partida e ajuste-a à criticidade do serviço. Não é uma frequência obrigatória para todas as apps.

No acompanhamento regular

Defina quem revê os alertas, confirma se há incidentes por tratar e acompanha os serviços de que a app depende. O horário dessa revisão deve corresponder à cobertura contratada. Não pressuponha vigilância permanente se ela não estiver prevista.

Na revisão periódica do produto

Peça uma análise dos erros recorrentes, das versões ainda utilizadas e das alterações técnicas pendentes. Inclua uma lista de dependências da app — componentes externos e serviços integrados — com responsável e decisão: atualizar, testar, substituir ou manter sob observação.

Evite atualizar tudo apenas para apresentar uma lista de tarefas concluídas. Peça a razão da alteração, o risco de a adiar e os testes necessários.

Antes de uma alteração relevante

Planeie testes dos percursos críticos sempre que a equipa propuser mudanças que os possam afetar. Inclua instalações novas e atualizações sobre a versão anterior, com os dados de teste apropriados.

Peça também uma lista explícita de dispositivos e versões de iOS e Android abrangidos pelo suporte. Se a equipa recomendar abandonar uma versão antiga, solicite os dados de utilização disponíveis, o impacto previsto e uma proposta de comunicação aos clientes.

Atualizar sem entregar o risco a todos de uma vez

Nas atualizações para iPhone, a Apple permite uma distribuição faseada ao longo de sete dias para utilizadores elegíveis com atualizações automáticas. Contudo, qualquer pessoa pode descarregar manualmente a atualização durante esse período. A distribuição faseada não deve, por isso, ser tratada como um teste fechado. (developer.apple.com)

No Google Play, a distribuição faseada permite disponibilizar uma atualização a uma percentagem de utilizadores. Essa percentagem não aumenta automaticamente. Se a distribuição for interrompida, quem já recebeu a versão continua com ela; a interrupção não repõe a versão anterior nesses dispositivos. (support.google.com)

A consequência para o seu plano é concreta: peça um procedimento para detetar problemas e decidir se a distribuição avança, pára ou exige uma correção.

Antes de autorizar uma atualização, confirme:

1. O que foi alterado: funções afetadas, correções e eventuais mudanças nos serviços ligados à app.

2. O que foi testado: percursos, dispositivos e resultados, incluindo limitações conhecidas.

3. Quem acompanha: responsável técnico e contacto do negócio durante a distribuição.

4. O que faz parar: sinais de falha que justificam suspender o avanço.

5. Como se contém o impacto: alternativa operacional e medidas técnicas disponíveis.

Se a app permitir desativar remotamente uma função problemática, documente quem tem autorização para o fazer. Se não permitir, não aceite essa possibilidade como parte do plano de recuperação sem trabalho adicional identificado.

O que deve ficar escrito na proposta de manutenção

Peça uma proposta organizada por responsabilidades e entregas, não apenas por horas. Use estas perguntas para encontrar lacunas antes de assinar:

A manutenção cobre só a app instalada ou também os serviços que a suportam? Identifique quem acompanha o servidor, as integrações e o painel de gestão. Quando há vários fornecedores, escolha quem coordena o diagnóstico inicial.

O que conta como correção e o que conta como evolução? Solicite exemplos aplicados ao seu produto. Corrigir uma função aprovada e acrescentar uma nova regra comercial devem ter enquadramentos claros.

Quem consegue preparar uma atualização? Confirme que o código, as instruções técnicas e os acessos necessários estão disponíveis às pessoas autorizadas. Peça evidência de que a equipa responsável consegue gerar uma versão de teste.

Como é aprovado trabalho adicional? Defina quem autoriza despesas, que informação recebe antes da decisão e como são tratadas intervenções urgentes. Não deixe a urgência substituir todas as regras de aprovação.

O que recebe no final de cada período? Recomenda-se um relatório curto com incidentes, alterações, testes realizados, riscos pendentes e decisões necessárias. As horas consumidas podem constar, mas não devem ser a única entrega visível.

Como termina ou muda o serviço? Preveja a passagem de conhecimento, a entrega de documentação atualizada e a revisão dos acessos quando houver mudança de equipa.

Saia da reunião com um responsável e uma data

Para começar, marque uma sessão entre quem gere a operação e quem mantém a app. Leve os percursos críticos, os problemas conhecidos e o acordo atual, se existir.

O resultado deve caber numa página: prioridades, cobertura, responsáveis, próxima revisão técnica e procedimento para uma atualização problemática. Anexe a essa página a lista de trabalhos pendentes, cada um com uma decisão e uma data de revisão.

Se ainda não houver informação suficiente para assumir esses compromissos, peça primeiro um levantamento técnico de âmbito fechado. O objetivo será identificar o estado da app e as condições necessárias para a manter, não prometer cobertura sem conhecer o produto.

A decisão comercial fica então mais simples: contratar resposta ocasional, reservar manutenção regular ou corrigir primeiro as lacunas que impedem qualquer equipa de intervir. Escolha com base na operação que precisa de proteger — e exija que a proposta mostre como o fará.