Equipa de desenvolvimento de uma app móvel: funções e composição

Uma equipa é mais do que uma contagem de pessoas

Comece pelo percurso principal. O que deve conseguir fazer uma pessoa quando compra um produto, marca um serviço ou começa uma aula? Depois é preciso decidir as regras, desenhar o percurso, implementá-lo, testá-lo em situações normais e inesperadas e manter a solução depois de publicada.

O Scrum Guide descreve uma equipa pequena e multifuncional como uma unidade com as competências necessárias para criar valor. Não é obrigatório seguir Scrum literalmente. A ideia é útil em qualquer modelo: as prioridades do produto precisam de um responsável e a equipa deve conseguir entregar uma versão utilizável.

Num projecto focado, uma pessoa pode cobrir várias linhas. Isso muda a distribuição do trabalho, mas não elimina nenhuma responsabilidade.

Responsável de produto: proteger o primeiro resultado

Pode ser o fundador, alguém da empresa ou um gestor de produto da agência. O título é menos importante do que a autoridade para decidir. Esta pessoa define para quem a aplicação é feita, o que a primeira versão deve provar, o que fica para depois e como será avaliado o resultado.

Também deve responder às perguntas da equipa. Se cada sócio der uma resposta diferente sobre o pagamento, a reserva ou o acesso a uma aula, a estimativa começa a esconder decisões por tomar. Essas decisões voltam mais tarde como alterações ao design, servidor, testes e calendário.

O plano de MVP para uma app móvel ajuda a escrever um objectivo principal, os tipos de utilizador, o percurso essencial e uma lista curta do que não entra na primeira versão.

Designer: transformar regras de negócio num percurso claro

O design não é apenas uma questão visual. É preciso explicar o que a pessoa pode fazer, que informação vê e o que acontece quando falta algo. Numa aplicação de marcações, isso inclui horários indisponíveis, cancelamentos e lembretes. Numa loja, inclui carrinho vazio, pagamento recusado, variante esgotada e alteração da entrega.

Uma boa entrega de design inclui navegação, textos, estados de carregamento, mensagens, acessibilidade e componentes reutilizáveis. Também permite discutir uma interacção cara ou confusa antes de a repetir em muitas páginas.

Programador móvel: levar o percurso para um telefone real

O programador transforma as decisões de produto e o design numa aplicação que tem de lidar com ecrãs diferentes, interrupções, permissões, ligação instável, armazenamento seguro, notificações e actualizações.

Uma abordagem multiplataforma pode evitar trabalho duplicado quando faz sentido para o produto. Não elimina, contudo, decisões próprias de iOS e Android: subscrições, ligações profundas, notificações, funcionamento em segundo plano e regras de publicação continuam a precisar de testes. A documentação do Flutter é uma referência útil, mas a tecnologia deve seguir as necessidades do produto.

Servidor e painel de administração: a parte que não aparece no ecrã

O servidor guarda dados e aplica regras. Normalmente trata de contas, permissões, pagamentos, notificações, ficheiros, integrações e ligação a um painel de administração. Num marketplace, precisa de manter coerentes os estados de comprador, vendedor, pagamento e reclamação. Num produto de entregas, coordena encomenda, estafeta, rota, prova de entrega e apoio ao cliente.

O responsável técnico decide como os dados são organizados, quem tem acesso, como são feitos os ambientes, cópias de segurança, monitorização e futuras alterações. Num serviço pequeno, pode ser a mesma pessoa que desenvolve o servidor. Com dados sensíveis ou muitas integrações, convém ter uma segunda revisão das decisões importantes.

O nosso guia sobre servidor para aplicações móveis explica porque uma função não termina no ecrã visível. Se alguém da empresa precisa de aprovar, editar, devolver dinheiro ou moderar, o painel de administração faz parte do âmbito.

Testes e publicação: o caminho normal não chega

Os testes não devem ficar para a última semana. É necessário verificar sessões expiradas, permissões retiradas, ligações lentas, toques repetidos, catálogos vazios, pagamentos incompletos e carregamentos interrompidos. Também são necessários dispositivos reais e contas de teste próximas do uso real.

Alguém deve assumir as contas das lojas, capturas de ecrã, textos, informação de privacidade, medição e respostas durante a revisão. Consulte as App Review Guidelines da Apple e as recomendações de qualidade base do Android. Uma versão pode estar pronta do ponto de vista do código e ainda não estar pronta para envio.

Qual é a equipa mínima para um MVP?

Uma primeira versão limitada deve cobrir cinco áreas: produto, design, aplicação móvel, servidor e qualidade/publicação. Podem ser três pessoas, cinco pessoas ou uma equipa de agência com especialistas que entram apenas numa determinada fase. O número importa menos do que a capacidade de levar o percurso completo até ao lançamento.

Uma app de aprendizagem simples pode ter uma pessoa de produto, uma designer, um programador multiplataforma com apoio de servidor e alguém para testes e publicação. Um serviço de entregas precisa de mais trabalho operacional mesmo com poucos ecrãs: atribuição, mapas, estados, pagamentos, suporte e dois tipos de utilizador aumentam o esforço.

O processo de desenvolvimento de uma app móvel mostra quando cada competência é necessária. Assim, pode contratar conhecimento especializado para uma fase concreta sem manter todas as funções a tempo inteiro desde o primeiro dia.

Que funções podem ser combinadas?

Num produto pequeno, o fundador pode assumir as prioridades, um programador sénior pode combinar desenvolvimento móvel e direcção técnica, e uma designer pode preparar os fluxos e os componentes visuais. O programador de servidor pode gerir um ambiente simples.

A combinação não deve apagar a revisão. A pessoa que cria a funcionalidade não deve ser a única a decidir que ela funciona. Os acessos de produção, cópias e recuperação também não devem depender de uma única pessoa sem controlo.

Antes de contratar uma equipa pequena, confirme:

1. Quem decide quando existem prioridades contraditórias?
2. Cada tipo de utilizador tem um percurso completo, incluindo erros?
3. Alguém testa o trabalho sem ser a pessoa que o implementou?
4. Estão atribuídos os acessos, a infraestrutura, a medição, as lojas, o suporte e a entrega?
5. O que acontece se a pessoa principal ficar indisponível?

Como a composição da equipa altera o orçamento

O preço não é simplesmente o número de pessoas multiplicado pelo número de semanas. Uma revisão curta de arquitectura, segurança, dados ou publicação pode evitar muito retrabalho. Uma segunda plataforma, uma migração, vários papéis ou integrações externas também aumentam os cenários que precisam de ser verificados.

Para um produto implementado, a Appfyl utiliza como orientação 15.000-20.000 EUR para um MVP focado, 20.000-50.000 EUR para um projecto médio e 50.000-100.000 EUR para um projecto grande. São referências de planeamento da Appfyl, não médias gerais do mercado. O valor real depende do resultado, dos percursos, do painel de administração, das integrações, dos dados e do lançamento. O guia sobre orçamento de uma app móvel separa a implementação de alojamento, serviços externos, suporte e evolução.

Ao comparar propostas, peça as premissas: plataformas, tipos de utilizador, servidor, painel, integrações, dispositivos de teste, publicação, garantia e entrega. A lista de verificação do contrato de desenvolvimento ajuda a registar estas respostas.

Perguntas para fazer antes de contratar

Pergunte quem pode aprovar uma decisão, quem é dono do código e da infraestrutura, como são feitas as revisões, como se verificam os eventos e falhas, quem responde a uma rejeição da loja e que acessos recebe no final.

Pergunte também o que acontece se uma API externa mudar, um pagamento falhar ou as pessoas seguirem um caminho inesperado. Uma resposta concreta mostra que a equipa pensou no produto para além da demonstração.

Como a Appfyl organiza a equipa

A Appfyl começa pelo resultado que a primeira versão precisa de provar. Organizamos os utilizadores, percursos, operações, integrações, riscos dos dados, requisitos de publicação e medição depois do lançamento. Depois definimos quais as competências necessárias durante todo o projecto e quais podem entrar apenas numa fase.

Uma abordagem Flutter-first é adequada para muitos produtos multiplataforma, mas não é uma regra universal. A tecnologia, a equipa e os testes devem seguir o produto. Consulte os casos públicos da Appfyl e descreva a sua ideia na ferramenta de estimativa da Appfyl.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Perguntas frequentes