Na Testlify, o controle de tempo de engenharia dependia de uma aplicação cara de terceiros, desconectada dos fluxos de trabalho diários do Jira. Liderei o desenvolvimento de frontend do Timesheets by Appforest, uma aplicação integrada ao Jira para controle de tempo, planejamento de capacidade de equipe e alocação de custos de projeto. O produto é publicado no Atlassian Marketplace e implantado internamente em toda a empresa.
O que construí
- Integração com o Atlassian Marketplace: Construído sobre o Atlassian Forge, o runtime serverless sandboxed da Atlassian, com permissões de leitura/escrita no Jira estreitamente escopadas, de privilégio mínimo, em vez de um backend auto-hospedado.
- Interface embutida no Jira: Um painel de registro de tempo embutido diretamente nas issues do Jira para lançamentos rápidos, além de um app de dashboard completo para visões de calendário e envios de timesheet diários/semanais, sem trocar de contexto.
- Relatórios e analytics: Visões de relatório combinando dados do Jira e de registro de tempo interno para contabilidade de sprint e rastreamento de custo de projeto.
Por que importou
Publicado no Atlassian Marketplace para clientes externos, o plugin também substituiu nosso software legado de controle de tempo internamente, economizando mais de US$ 9.000 em custos anuais de licenciamento e dando à liderança visibilidade em tempo real sobre a alocação de engenharia.
Time e Responsabilidade
Liderei o desenvolvimento de frontend em um time pequeno: 397 commits de 4 contribuidores desde meados de 2024, ainda mantido ativamente hoje. Este é um produto de vários anos e várias pessoas, não uma construção solo, e meu papel foi escopado ao frontend, não uma responsabilidade full-stack.
Forge, Não Connect
O app roda sobre o Atlassian Forge, um runtime serverless sandboxed, não o framework Connect mais antigo (um app auto-hospedado com seu próprio backend, se comunicando com o Jira via iframes e webhooks). Forge significa nenhum servidor para rodar ou corrigir na superfície voltada ao Jira: a Atlassian hospeda o ambiente de execução, impõe os escopos de permissão declarados no manifesto e aplica restrições no estilo serverless (Node 22 em ARM64, 1024MB de memória, tempo de execução limitado por invocação), em vez de deixar essa infraestrutura para nós.
Duas Superfícies para Duas Intenções Diferentes
O produto se divide deliberadamente em duas UIs, não uma. Um painel no contexto da issue cuida do caso comum: registrar tempo contra o ticket que você já está olhando, em um clique, sem sair dele. Um app de dashboard completo separado (visões de calendário, relatórios, configurações administrativas, rastreamento de custo) cuida do planejamento e da supervisão, as tarefas que precisam de um espaço de trabalho de verdade, não de um painel lateral. Cada superfície é construída para o trabalho que faz, em vez de forçar uma única interface a fazer as duas coisas.
Uma Integração Real Entre Projetos
Isso não é um app isolado. Funções resolver ingerem e limpam explicitamente sugestões de lançamento de tempo vindas do Google Calendar, do Outlook Calendar e da extensão complementar Appforest Timetracker para VS Code, para que a atividade de programação de um desenvolvedor no VS Code possa aparecer aqui como uma sugestão de lançamento de timesheet, em vez de exigir reentrada manual.
Modelo de Dados e Escala
- Os escopos de permissão do Forge são estreitos e explícitos (
read:jira-work,write:jira-work,manage:jira-configuration, além de leituras de usuário/token), não uma concessão ampla e genérica. - Os componentes de UI usam os próprios design tokens da Atlassian (
@atlaskit), para que o plugin combine visualmente com o Jira nativo, em vez de parecer um terceiro encaixado à força. - O app de dashboard é Vue 3 com Pinia para estado, 46 componentes, separado do painel de contexto de issue baseado em React; duas stacks de frontend em um único produto, não uma única base de código artificialmente esticada para cobrir as duas superfícies.
- A alocação de memória da função Forge foi elevada de 256MB para 1024MB depois de um problema real de desempenho, não definida em 1024MB como padrão inicial.
O motor de relatórios por trás dessas visões de custo/sprint escala sua própria estratégia de query: ele divide as requisições de busca JQL do Jira em blocos de 25, 50 ou 100 issues por chamada, dependendo do volume do relatório, buscando 16 campos por issue, em vez de disparar uma requisição por issue ou uma única query sem limite que arrisca dar timeout em uma sprint grande.
Construir vs. Comprar
Forge em vez de um app Connect auto-hospedado: o runtime e o modelo de permissões da Atlassian substituem uma infraestrutura que esse time teria que construir e proteger sozinho. Design tokens nativos da Atlassian em vez de um kit de UI personalizado: o plugin herda a própria aparência e os padrões de interação do Jira, em vez de manter um design system paralelo só para este app.
Stack
Atlassian Forge (Node 22, ARM64), React 18 para o painel de contexto de issue, Vue 3 com Pinia para o app de dashboard, tokens e primitivas do Atlassian Design System, implantado via Atlassian Marketplace.