Jobcenter - Uma plataforma, três públicos diferentes
Aplicativo, site e portal administrativo para empresa contratante, candidato e trabalhador terceirizado, com holerite e benefícios vindos do sistema de folha.
Três pessoas, três relações, um produto
A Jobcenter fornece mão de obra temporária e terceirizada. Isso coloca três pessoas muito diferentes em volta do mesmo negócio, e cada uma quer uma coisa:
- A empresa contratante quer abrir vaga, acompanhar solicitações e ver seus números. O candidato quer encontrar vaga e se inscrever. O trabalhador já alocado quer o holerite, os benefícios e o informe de rendimentos, e é ouvido por pesquisa de satisfação.
O desafio de produto foi acomodar os três num só aplicativo sem transformá-lo em três aplicativos colados, e sem que o trabalhador precise navegar por telas que não são para ele.
O que cada perfil encontra
Cliente. Abertura de vaga com formulário completo, incluindo tipo de contrato, cargo, faixa salarial, escolaridade, experiência exigida, local de trabalho, jornada e anexo. Mais o envio de documentos, o acompanhamento das próprias solicitações e o painel com os indicadores da conta.
Funcionário. Holerite, benefícios, informe de rendimentos, envio de documentos por foto tirada na hora e a pesquisa de satisfação.
Candidato. Acesso às vagas abertas e cadastro de currículo.
Uma decisão de escopo merece registro: o cadastro de currículo do candidato não foi reconstruído. A Jobcenter já publicava suas vagas em um portal de empregos consolidado, e o aplicativo leva o candidato até lá em vez de duplicar uma base de currículos.
Recriar o que já funciona em outro lugar custa caro e entrega pouco. Reconstruir só faz sentido quando o resultado é melhor para quem usa, e não era o caso.
O dado mais importante não era da Jobcenter
Aqui está a decisão de arquitetura que define este projeto.
Holerite, benefícios e informe de rendimentos não moravam num sistema da Jobcenter. Viviam no sistema de folha de pagamento de um fornecedor terceiro. O produto tinha duas saídas: copiar esses dados para uma base própria, ou lê-los na origem.
A escolha foi ler na origem. Dado de folha replicado é dado que diverge: basta um ajuste de cálculo no sistema de origem para o trabalhador ver um valor no aplicativo e outro no contracheque, e não existe conserto bom para isso depois que acontece.
O custo dessa escolha foi a dependência. O produto só mostra holerite quando o sistema de origem expõe holerite, e a integração ficou pendente por longos meses, aguardando a interface de dados do terceiro.
A pendência foi registrada e cobrada diariamente, no mesmo canal do projeto, até ser resolvida. Quando a integração chegou, ainda houve uma rodada de ajuste de autenticação, porque o token emitido pela rota nova não era aceito pelas rotas de holerite e benefícios.
A lição para projetos parecidos: quando a informação central do produto está na mão de um terceiro, essa dependência é o maior risco do cronograma, e precisa estar visível como tal desde o primeiro dia, não tratada como detalhe de integração.
Design validado tela a tela
O projeto teve uma fase de desenho longa e bem documentada, e ela atravessou o começo da pandemia, com o time do cliente passando a trabalhar de casa no meio das validações.
O que foi entregue nessa fase:
- Arquitetura de informação do produto inteiro. Protótipo navegável do aplicativo, validado com o cliente em rodadas sucessivas, com apontamento tela a tela. Protótipo navegável da versão web. Painéis do perfil cliente desenhados a partir da planilha de indicadores que o próprio cliente usava. Repasse formal do design para o desenvolvimento, gravado em vídeo, para que a intenção de cada tela ficasse registrada além do arquivo.
Uma decisão de experiência que saiu dessa fase: o formulário de pesquisa de satisfação passou a mostrar o progresso de preenchimento, exatamente para reduzir o abandono de quem olha um questionário longo e desiste no meio.
Stack e práticas
- React Native para o aplicativo iOS e Android, com visualização de documento em PDF para o holerite. React no site web. Strapi como camada de back end e portal administrativo. Banco relacional, com o ambiente de produção na infraestrutura de nuvem do cliente. Contêineres com esteira de build e publicação automatizada para o ambiente de homologação. Integração com o sistema de folha de pagamento de terceiro para holerite, benefícios e informe de rendimentos. Protótipos em Adobe XD com link de visualização, validados antes do desenvolvimento.
O aplicativo foi publicado nas duas lojas, e a X-Apps apoiou o cliente na montagem das contas de publicação e da infraestrutura de produção, que ficaram no nome dele.
Seu produto depende de dado que está em outro sistema?
Quase todo produto corporativo depende de um sistema que já existe e que não é seu: folha, ERP, CRM. A decisão entre replicar o dado e lê-lo na origem define a confiabilidade do produto e o risco do cronograma. A X-Apps ajuda a tomar essa decisão com os dois custos na mesa.