Políticas e Cultura da Tribo

• Políticas de Board e Fluxo
• Política de Board - Squad Suporte Técnico
• Política de Board - Squad Fábrica
• Políticas e processos do Board - Geral
• Critério de Priorização - Classes de Serviço
• Acordos da Retro
• Retro - 29/05/25 - Remota
• Retro - 26/05/25 - Presencial
• Políticas e Acordos Gerais
• Políticas e Acordos - Gerais
• Cargos
• Deveres e responsabilidades do cargo

Políticas de Board e Fluxo

Política de Board - Squad Suporte Técnico

Triagem Squad

Coluna onde todos os cards de origem externa devem chegar. Essa coluna é analisada diariamente pelo Squad Leader, que verifica os fluxos e os cards que devem ser priorizados para o backlog. Esses cards ainda não estão na fila do Ponto de Compromisso e precisam ser analisados quanto ao layout, às informações fornecidas e ao atendimento dos critérios mínimos de entrada. Caso não atendam, o card deve ser indeferido, e o Squad Leader deve comunicar ao solicitante os motivos do indeferimento, solicitando as correções necessárias. Nesses casos, o card deve ser removido do board da Triagem Squad.

Backlog

Os cards nesta coluna atendem aos requisitos mínimos de especificação, contendo todas as informações necessárias para o entendimento do contexto, o que deve ser feito, o motivo da execução e os critérios de conclusão bem definidos. Os cards nesta etapa estão na fila direta para o Ponto de Compromisso. A cada Daily, conforme a liberação do WIP pelo time, novos cards devem ser movidos para essa etapa.

Ponto de Compromisso

Os cards inseridos aqui foram priorizados conforme a urgência ou a ordem de chegada e devem ser puxados pelo time de suporte técnico assim que houver liberação do WIP do técnico. Os cards dessa coluna devem ser atendidos em ordem de prioridade, ou seja, o card mais acima na lista deve ser o primeiro a ser tratado. Não deve haver distinção de qual técnico deve puxar o card; o primeiro colaborador com WIP liberado deve assumir a demanda do topo da lista.

Suporte em Andamento

Os cards dessa coluna representam ações de suporte que estão sendo executadas no momento, ou seja, o cliente está sendo atendido e há uma conversação ativa. Essa coluna reflete a atividade em tempo real do time e deve conter comentários sobre a evolução do atendimento. Especialmente nos casos em que o suporte não for finalizado no mesmo dia, é essencial registrar as informações para continuidade posterior.

Em Análise

São situações do suporte técnico em que o atendimento foi realizado, mas não foi possível resolver o problema em tempo real, sendo necessário aprofundar a análise internamente. Os cards dessa coluna devem resultar em uma das seguintes ações:

1. Resolução do problema e contato posterior com o cliente para retorno sobre a solução.
2. Movimentação para a coluna “Suporte Não Resolveu”, caso seja constatado que, mesmo após análise aprofundada, a demanda não pôde ser resolvida.

Suporte Não Resolveu

Os cards dessa coluna representam atendimentos que não puderam ser resolvidos pelo time de suporte. Esses casos são analisados pelo Squad Leader, que avalia o nível da demanda e decide se deve ser encaminhada para o time de fábrica. Além disso, o Squad Leader verifica se a situação requer ações de treinamento para a equipe.

Demandas para Outra Squad

São demandas direcionadas para execução por outra squad, incluindo correção de bugs, manutenções, melhorias ou dúvidas de alta complexidade. Os cards nesta coluna aguardam a execução pelo time de fábrica e ficam pendentes sem atribuição a um colaborador específico do suporte.
O card enviado para outra squad deve seguir o layout padrão de manutenção ou melhoria e atender aos critérios de entrada estabelecidos pelo board da fábrica.

Pronto para Homologar

Os cards enviados para a fábrica pela coluna “Demandas para Outra Squad” e que foram concluídos retornam para essa etapa. Os cards devem ser homologados pelo técnico do time de suporte que solicitou a demanda. Uma vez homologado e atendendo aos critérios de conclusão estabelecidos, o card pode ser encerrado.

Concluído

Nesta coluna ficam os cards finalizados, que não possuem pendências ou responsabilidades a serem tratadas. Todos os critérios de conclusão devem ter sido atendidos e validados pelo solicitante antes do card ser movido para esta etapa.

Resumo do Fluxo

1. Triagem Squad – Cards chegam, são analisados e, se não atenderem os critérios mínimos, são devolvidos ao solicitante.

2. Backlog – Cards validados aguardam disponibilidade para serem priorizados.

3. Ponto de Compromisso – Cards prontos para execução são puxados pelo primeiro técnico disponível.

4. Suporte em Andamento – Atendimento ativo, com registros constantes de progresso.

5. Em Análise – Demandas complexas que precisam de avaliação mais profunda.

6. Suporte Não Resolveu – Problemas sem solução são revisados pelo Squad Leader e podem ser escalados.

7. Demandas para Outra Squad – Cards enviados para times responsáveis por correções e melhorias.

8. Pronto para Homologar – Cards retornam da fábrica e precisam ser validados pelo técnico solicitante.

9. Concluído – Cards finalizados, sem pendências e aprovados pelo solicitante.

Política de Board - Squad Fábrica

Triagem Squad

Coluna onde todos os cards de origem externa devem chegar. Essa coluna é analisada diariamente pelo Squad Leader, que verifica os fluxos e os cards que devem ser priorizados para o backlog. Esses cards ainda não estão na fila do Ponto de Compromisso e precisam ser analisados quanto ao layout, às informações fornecidas e ao atendimento dos critérios mínimos de entrada. Caso não atendam, o card deve ser indeferido, e o Squad Leader deve comunicar ao solicitante os motivos do indeferimento, solicitando as correções necessárias. Nesses casos, o card deve ser removido do board da Triagem Squad.

Backlog

Os cards nesta coluna atendem aos requisitos mínimos de especificação, contendo todas as informações necessárias para o entendimento do contexto, o que deve ser feito, o motivo da execução e os critérios de conclusão bem definidos. Os cards nesta etapa estão na fila direta para o Ponto de Compromisso. A cada Daily, conforme a liberação do WIP pelo time, novos cards devem ser movidos para essa etapa.

Ponto de Compromisso

Os cards inseridos aqui foram priorizados conforme a urgência ou a ordem de chegada e devem ser puxados pelo time de desenvolvimento assim que houver liberação do WIP de um desenvolvedor. Os cards dessa coluna devem ser atendidos em ordem de prioridade, ou seja, o card mais acima na lista deve ser o primeiro a ser tratado. Não deve haver distinção de qual desenvolvedor deve puxar o card; o primeiro colaborador com WIP liberado assume a próxima demanda disponível.

Fazendo Desenvolvimento

Essa coluna representa os cards que estão em pleno desenvolvimento e reflete a atividade em tempo real do time. Os cards devem conter comentários sobre o progresso e são os principais pontos de discussão nas dailys. Caso haja impedimentos na execução, estes devem ser registrados no card e tratados como prioridade na daily.

Ao concluir a implementação do card, o Desenvlvedor deve bloquear o card para code review. O Code Review deve ser feito por outro desenvolvedor que realizará o procedimento de CR e liberará o bloqueio do card e em seguida, move-lo para pronto pra teste.

Liberado para Testar

Cards concluídos pelo time de desenvolvimento e prontos para serem testados pelo profissional de QA. Nessa etapa, o card deve conter todos os comentários sobre sua evolução, além do link do Git da branch desenvolvida. O QA deve puxar os cards por ordem de chegada, priorizando o primeiro da lista.

Fazendo Teste

Essa coluna representa os cards que estão em fase de teste e validação. Os comentários sobre os testes devem ser atualizados constantemente e as principais dificuldades discutidas nas dailys. Caso haja impedimentos, eles devem ser registrados e tratados como prioridade.

Deploy

Os cards que passaram pelos testes e foram validados são liberados para serem submetidos à produção. Essa coluna representa todos os cards prontos para o deploy. Impedimentos podem ocorrer, como dependências de outras rotinas ou parte de um projeto ainda em andamento.

Homologação

Cards nesta coluna são features ou correções de bugs já desenvolvidas, testadas e implantadas em produção. A homologação consiste na validação pelo solicitante, confirmando que os critérios estabelecidos foram cumpridos. O card deve conter um comentário do solicitante confirmando que a entrega foi bem-sucedida.

Concluído

Aqui ficam os cards finalizados, sem pendências e validados pelo solicitante. Nenhuma ação adicional é necessária.

Resumo do Fluxo

1. Triagem Squad – Cards chegam, são analisados pelo Squad Leader e, se não atenderem os critérios mínimos, são devolvidos ao solicitante.

2. Backlog – Cards validados aguardam disponibilidade para serem priorizados.

3. Ponto de Compromisso – Cards prontos para desenvolvimento são puxados pelo primeiro desenvolvedor com WIP liberado.

4. Fazendo Desenvolvimento – Cards em andamento devem conter atualizações sobre o progresso e impedimentos devem ser tratados nas dailys.

5. Liberado para Testar – Cards finalizados pelo time de desenvolvimento ficam disponíveis para QA, contendo comentários e link da branch.

6. Fazendo Teste – Cards em validação pelo QA, com registro de progresso e tratamento de impedimentos nas dailys.

7. Deploy – Cards testados e validados são preparados para serem implantados em produção; podem aguardar dependências.

8. Homologação – O solicitante valida a entrega e confirma que os critérios foram atendidos.

9. Concluído – Cards finalizados, sem pendências e validados pelo solicitante.

Políticas e processos do Board - Geral

Políticas de Board

• Representação Fiel: Todo card deve refletir seu status real. Use as colunas "Fazendo", "Concluído" ou "Bloqueado" conforme o progresso.
• Triagem Squad: Cards externos são analisados pelo Squad Leader. Se não atenderem aos critérios mínimos, são indeferidos e devolvidos para correção.
• Backlog: Cards devem conter informações claras sobre o que deve ser feito, o motivo e os critérios de conclusão.
• Ponto de Compromisso: Cards são puxados por ordem de prioridade, sem distinção de responsável.
• Fluxo de Desenvolvimento e Testes: Cada etapa deve ser documentada com comentários e links relevantes.
• Homologação e Conclusão: Cards devem ser validados pelo solicitante e concluídos apenas quando todos os critérios forem atendidos.

Raias de Prioridade

• Urgentes: Demandas críticas que exigem esforço imediato e ininterrupto.
• Críticas: Prioridade na próxima liberação de Wip.
• Normais: Seguem o fluxo padrão do "Card Workflow".
• OKR: Prioridade definida em acordo com stakeholders.

Políticas de Board

• Representação Fiel: Todo card deve refletir seu status real. Use as colunas "Fazendo", "Concluído" ou "Bloqueado" conforme o progresso.
• Triagem Squad: Cards externos são analisados pelo Squad Leader. Se não atenderem aos critérios mínimos, são indeferidos e devolvidos para correção.
• Backlog: Cards devem conter informações claras sobre o que deve ser feito, o motivo e os critérios de conclusão.
• Ponto de Compromisso: Cards são puxados por ordem de prioridade, sem distinção de responsável.
• Fluxo de Desenvolvimento e Testes: Cada etapa deve ser documentada com comentários e links relevantes.
• Homologação e Conclusão: Cards devem ser validados pelo solicitante e concluídos apenas quando todos os critérios forem atendidos.

Raias de Prioridade

• Urgentes: Demandas críticas que exigem esforço imediato e ininterrupto.
• Críticas: Prioridade na próxima liberação de Wip.
• Normais: Seguem o fluxo padrão do "Card Workflow".
• OKR: Prioridade definida em acordo com stakeholders.

Critério de Priorização - Classes de Serviço

Para controle de priorização de demandas que entrarão no backlog, prevalecerá o critério de priorização com base em Classes de Serviço que serão categorizadas pelo custo de atraso, ou por criticidade envolvida.

Estes critérios levarão em consideração as seguintes Classes:

Urgentes, Críticas e Normais.

Todos boards da Tribo Web devem conter minimamente esta estrutura de Classes de Serviços representadas por raias previamente configuradas. Cada raia, seguem os seguintes critérios base respectivos:

Raia Urgente:

• Representam demandas onde o custo do atraso sobe rapidamente em pouquíssimo tempo, exigindo uma maior urgência e atenção para minimizar o impacto gerado. São card que devem ser executadas imediatamente podendo, inclusive, furar a fila e passar na frente das demais. Ex: NovoAvanço Fora do Ar, Caixa parado, tramitador inoperante.

Raia Crítica:

• Representam demandas onde o custo de atraso de forma rapida mas não tão grave quanto uma demanda urgente. São situações que precisam ser priorizadas mas não necessariamente afeta o trabalho atual em andamento, ganhando prioridade nas demais raias mas não afetando o andamento de demandas já em execução. Ex: Geração de Sped com erro de registros, sistema não permitindo alteração de preços, NFC-e em causando rejeição por conta da apliacação.

Raia Normal:

• Representam a maior parte das demandas que lidamos no dia a dia e possuem um custo de atraso moderado que cresce linearmente com o passar do tempo, sem muitas variações e portanto, toleram prazos de entrega mais longos. Ex.: Dúvidas de clientes sob como emitir nota a partir de cupom, alteração de imagem da logo do caixa, treinamento de cadastro de produtos.

Acordos da Retro

Retro - 29/05/25 - Remota

Membros presentes: Gabriel Brumer, Hélio Júnior, Luiz Paulo, Pedro Souza, Rafael Rodrigues, Ruver Clacyus

1. Definição mínima de WIP (Work in Progress)

Fica acordado que, para todas as squads, deve ser respeitado o limite de no máximo 3 cards em execução simultaneamente, sendo permitido que apenas 1 esteja desbloqueado por pessoa.
Essa prática está alinhada aos princípios do Kanban no nível 2 do KMM, e tem como objetivo promover eficiência na vazão e melhorar o fluxo de trabalho.
O limite de WIP garante foco, reduz multitarefa e permite maior previsibilidade nas entregas.

---

2. Fluxo e ordem de fila

O card mais envelhecido no ponto de compromisso  deve ser o próximo a ser puxado para execução.
A ordem de chegada dos cards no fluxo deve ser respeitada, observando as políticas de classe de serviço e a priorização previamente estabelecida no board.

A fila só pode ser reordenada em casos justificados por nível de criticidade superior (ex: urgências ou bloqueios graves).

---

3. Especificação mínima do card

Para que um card entre no ponto de compromisso, ele deve conter no mínimo:

• O contexto claro do problema;

• A ação objetiva esperada;

• Os critérios explícitos de conclusão.

O objetivo é garantir que o time compreenda exatamente o que deve ser feito, por que e como saber que está pronto.

Não devem ser criados cards com a única intenção de transferir a responsabilidade de análise para outras pessoas ou squads.
Cards só podem ser transferidos entre squads quando houver clareza total sobre a definição do problema.

Caso contrário, o card deve ser indeferido, com registro da justificativa e comunicação ao originador e finalização do mesmo..

---

4. Gráficos de dispersão (Scatterplot)

Em pelo menos uma daily por semana, é indispensável a análise do gráfico de dispersão, localizado no Kanbanize em:

Métricas > Tempo de Ciclo > Gráfico de Dispersão

A análise deve considerar os cards criados nos últimos dias até a data da última daily.
O gráfico ajuda a identificar envelhecimento de cards e promover ações práticas para:

• Desbloquear e dissolver gargalos;

• Reforçar o ritmo de execução;

• Alinhar expectativas com o autor e com o time sobre a situação do card.

O uso recorrente dessa métrica promove transparência e melhoria contínua na gestão do fluxo.

Retro - 26/05/25 - Presencial

Membros presentes: Gabriel Brumer, Hélio Júnior, Luiz Paulo, Pedro Souza, Rafael Rodrigues, Ruver Clacyus

-----------------

5. Política de Comentários

Fica definido que, durante a execução de um card, deve-se manter o histórico de andamento por meio de comentários obrigatórios em situações específicas. Essa prática busca garantir transparência, rastreabilidade e continuidade, especialmente em cenários de troca de responsável, interrupções ou investigações futuras.

São obrigatórios comentários nos seguintes casos:

• Fim de expediente
  Quando a execução de um card em andamento for interrompida pelo encerramento do horário de trabalho, deve ser realizado um comentário com a parcial atual, indicando o que já foi feito, pendências e próximos passos.

• Estouro de SLE*
  Caso o SLE da coluna seja ultrapassado, é obrigatório o comentário com as possíveis causas do estouro, status atual e, se possível, previsão de retomada ou conclusão.

• Checkpoints (marcos relevantes)
  Sempre que houver conclusão de etapa significativa, merges parciais, identificação de dependências, criação de cards derivados, surgimento de problemas externos ou quaisquer situações relevantes no andamento do card, deve ser registrado comentário com o contexto da situação.

• Ausências, interrupções e bloqueios
  Quando o responsável pela execução precisar se ausentar ou for interrompido por qualquer motivo que comprometa a previsibilidade da entrega, ou se o card estiver bloqueado por algum fator externo, deve-se registrar um comentário detalhado com a justificativa da interrupção.

---

6. Política de Tipagem dos Cards

Fica definido que, para que um card entre no backlog, ele deve obrigatoriamente conter a tipagem correta, com base em sua natureza. Essa prática garante clareza no entendimento, melhor análise de métricas e tratamento adequado das demandas.

São permitidas as seguintes tipagens no fluxos "cards workflow":

• Suporte
  Quando a demanda for uma solicitação pontual, geralmente de ação técnica rápida, como: extração de dados, reprocessamentos manuais, inserções diretas no banco de dados, desbloqueios, correções pontuais sem alteração de lógica do produto.

• Bug
  Quando o card corresponder à correção de um erro ou falha detectada em rotinas existentes, impactando o funcionamento do sistema ou a experiência do usuário. Envolve análise de causa e ajuste de lógica previamente implementada.

• Melhoria
  Quando a demanda tiver como objetivo o desenvolvimento de uma nova funcionalidade, ajuste de comportamento ou evolução do sistema. Representa uma entrega de valor incremental, seja funcional ou técnica.

---

7. Política de Criticidade das Demandas

Fica definido que toda demanda, ao ser abastecida no ponto de compromisso, deve conter a criticidade definida, com base na urgência e impacto relativo à fila atual de trabalho. Essa definição orienta a priorização, a condução das dailys e a gestão de expectativas com solicitantes.

As classificações possíveis são:

• Baixa
  Demanda que, apesar de relevante, pode aguardar execução em função de outras prioridades mais urgentes. Não há impacto direto imediato na operação ou nos fluxos críticos.

• Média
  Demanda importante, que possui certa prioridade, mas que ainda permite certo grau de flexibilidade na execução. Idealmente deve ser tratada nas próximas sprints.

• Alta
  Demanda com prioridade clara, que exige atenção nas próximas movimentações de cards. Seu atraso pode comprometer fluxos relevantes ou gerar insatisfação perceptível.

• Crítica
  Demanda de altíssimo impacto. Pode representar parada de sistema, risco de perda de dados, exigência legal ou alto impacto comercial. Justifica a reorganização da fila e a suspensão de outras execuções em curso, quase sempre, estará na raia urgente.

 

Maturidade dos acordos:

Políticas e Acordos Gerais

Políticas e Acordos - Gerais

Políticas de Valores

Horário de Trabalho e Ausências

• Squad Fábrica: O horário de trabalho padrão é das 8h00 às 17h00, com intervalo de almoço das 12h00 às 13h00.
• Squad Leaders e Squad de Suporte (2.F): O horário padrão é das 8h00 às 18h00, com intervalo de almoço das 12h00 às 14h00.

Qualquer variação nesses horários, como ausências para compromissos pessoais (sair mais cedo, resolver questões pessoais pela manhã, trocar o horário de almoço, etc.), deve ser excepcional e comunicada ao Squad/Team Leader com pelo menos um dia de antecedência.

• Folgas, Compensação de Horas, ausências programadas:: Devem ser acordadas com no mínimo 20 dias de antecedência.
• Situações Imprevisíveis/Urgentes: Ausências não programadas devem ser comunicadas imediatamente ao Squad Leader.
• Férias: Devem ser planejadas em conjunto com o Squad Leader, considerando a carga de trabalho e as entregas da Squad. O acordo deve ser alinhado com o Administrador da Tribo e formalizado por e-mail.

Variabilidades e Solicitações Gerais: Qualquer indisponibilidade ou solicitação do Squad Leader ou Tech Manager deve ser alinhada diretamente com o Tribe Leader.

---

Disponibilidade e Visibilidade

Durante o horário de trabalho, é essencial garantir visibilidade e disponibilidade. No contexto de home office, a plataforma padrão de comunicação é o Discord, onde todas as informações necessárias para o fluxo de trabalho são trocadas.

• Respostas Rápidas: Quando acionado por mensagens diretas ou no chat da Squad, responda no menor tempo possível. Caso não possa responder imediatamente, justifique com mensagens como:

  • "Estou em uma reunião, retorno em breve."
  • "Estou resolvendo uma questão, assim que disponível te retorno."
  • "É isso mesmo, assim que liberar explico melhor."

• Status no Discord: Utilize os status "Ausente" ou "Não perturbar" e adicione um motivo personalizado. Isso ajuda a comunicar sua indisponibilidade e evita expectativas de resposta imediata.

Evite Falhas de Comunicação: Não deixe de responder, demore excessivamente ou fique ausente sem justificativa, especialmente durante o horário de trabalho.
Está "ON"? Deixe isso claro!: Iniciou suas atividades hoje ? De um "Bom dia", "Boa tarde" ou um "To On". Mostrar que está disponível e em operação ( além do simples status do discord ) é importante para fortalecer a idéia de ambientação e disponibilidade.

---

Comunicação na Squad

A comunicação na Squad deve ser fluida e desburocratizada, baseada em princípios de igualdade e colaboração.

• Acesso Igualitário: Qualquer membro da Squad, independentemente da competência (Relacionamento, QA, Dev), pode e deve se comunicar com outros membros de forma natural.
• Resolução de Problemas: A Squad só funciona se todos estiverem disponíveis e acessíveis para resolver problemas ou entender solicitações. Isso agiliza o fluxo de trabalho e dissolve impedimentos.

---

Comunicação Fora da Squad

Não há restrições para interações com membros de outras Squads, mas é importante avaliar o custo de transação dessas interações.

• Custo de Transação: Refere-se a ações que não estão diretamente ligadas à entrega ou que não agregam valor a ela.
• Dependências Externas: Se um card exigir alinhamento com outra Squad, acione os envolvidos e peça auxílio ao Squad Leader. Formalize essas dependências por meio de cards para que possam ser analisadas nos comitês de melhoria contínua (CMC).

---

Participação em Dailys e Retros

A participação nos rituais da Squad é indispensável.

• Daily: É o principal momento de alinhamento sobre demandas em execução, expectativas de entrega e planejamento diário. Nada é mais importante que a Daily. Organize sua agenda para participar sempre.
• Retrospectiva: Realizada mensalmente, tem a mesma importância que a Daily.
• Reuniões de Tribo e Encontros Específicos: Devem ser priorizados conforme convocados pelo Squad Leader/Tribe Leader.

---

Respeito e Ética nas Relações

Valores como ética, excelência, respeito, responsabilidade individual, trabalho em equipe e satisfação do cliente devem ser praticados diariamente, refletindo a cultura da empresa.

---

Câmera Ligada nas Interações

Em reuniões formais da Squad ou da Tribo, mantenha a câmera ligada. Isso facilita a comunicação, aproxima a equipe e reforça o senso de pertencimento.

• Cumprimentos: Ao iniciar uma interaçao, cumprimente a equipe com um "Bom dia", "Boa tarde". Isso demonstra contersia e respeito ao grupo.
• Posicionamento da Câmera: Manter a câmera ligada ajuda a compartilhar expressões e promover uma maior conexão entre os participantes. Posicione-a de forma que seu rosto esteja bem enquadrado e visível, evitando ficar de perfil.

---

Responsabilidade Coletiva

Tudo na Squad é responsabilidade de todos. Compartilhamos gargalos, impedimentos, métricas e vitórias. Oferecemos ajuda, distribuímos carga de trabalho e experimentamos novas atividades para aumentar a agilidade e o valor das entregas.

Interações e Acordos Gerais

• Dailys: Foco em impedimentos e ações claras para resolvê-los.
• Cards: Todo card finalizado deve ter um tipo definido. Cards no backlog não podem ter dono ou impedimentos.
• Fluxo de Iniciativa e Especificação: Cards estratégicos devem ser quebrados em tarefas específicas para execução.

Somos uma SQUAD

Uma Squad é um time multidisciplinar e autônomo que trabalha de forma colaborativa para atingir um objetivo específico dentro de um projeto ou produto. Ela é formada por profissionais com diferentes habilidades, como desenvolvimento, QA, Suporte Técnico, Squad Leadere Tech Manager que atuam juntos para entregar valor contínuo.

Cada Squad tem autonomia para definir seu fluxo de trabalho, priorizar tarefas e tomar decisões, garantindo maior agilidade e eficiência no desenvolvimento de soluções.

• Equipe Multidisciplinar: Buscamos autonomia e independência, tomando decisões em conjunto para atender aos interesses alinhados pela Squad. Evitamos desperdícios, reuniões desnecessárias e resolvemos impedimentos de forma rápida e documentada.
• Foco na Entrega: Não aceitamos cards mal estruturados ou sem critérios mínimos de aceite. Nosso backlog é alimentado apenas por demandas triadas pelos stakeholders.
• Interações Externas Formalizadas: Qualquer interação externa deve ser formalizada no backlog do quadro respectivo, com cards replicados no backlog do ator solicitado.

Cargos

Deveres e responsabilidades do cargo

Das Ações do Tribe Leader

• Aplica e assegura as políticas de processos macros e de gerenciamento da Tribo, direcionando as ações das Squads juntos aos Squad Leaders assegurando que as ações executadas estejam em pleno alinhamento aos acordos e estratégias de curto e longo prazo da Avanço, de forma eficaz e coerente.
• Cuida, motiva e conecta o time, gerenciando as pessoas diariamente e imprimindo ritmo no trabalho.
• Participa efetivamente e/ou promove as cerimônias da Avanço, como Retros, 1:1, Alinhamento com Tech People, CMC, Alinhamento com Diretoria e Gerência de RH.
• Direciona os Squad Leaders, resolve impedimentos e conflitos tomando decisões de nível estratégico e operacional.
• Garante um ambiente colaborativo, inspirador, horizontal e de comunicação aberta e simplificada.
• Define objetivos claros, delega tarefas e estabelece prazos, supervisionando a operação do dia-a-dia e monitorando o desempenho da equipe e suas métricas através de alinhamentos contínuos com os representantes das equipes e personas de interesse.
• Ouve e retorna feedbacks aos membros da equipe, incentivando a criatividade e colaborando para a tomada de decisões.
• Promove alinhamentos com outras áreas de negócio da Avanço e negocia soluções referentes às demandas/processos.
• Garante a evolução técnica da equipe com planos de capacitação e acompanhamento contínuo, promovendo ações de melhorias estruturais, governamentais e processuais.
• Participa e contribui para o processo de tomada de decisão, definição e criação de programas de melhoria contínua e definição de ações estratégicas.
• Participa do processo seletivo de novos colaboradores para a Tribo, avaliando os candidatos em todas as etapas.
• Participa dos Workshops e cumbucas promovidos pela empresa ou parceiros.

Das Ações do Tech Manager

• Coordenar e direcionar decisões de arquitetura e escolhas tecnológicas para desenvolvimento e melhoria de produtos Avanço, garantindo escalabilidade, sustentabilidade e eficiência.
• Promover e acompanhar ações de melhoria e qualidade do código através de revisões regulares e promoção de melhores práticas.
• Abstrair problemas de complexidade técnica, facilitando e intermediando soluções.
• Participar do planejamento de projetos, definindo escopos e recursos.
• Distribuir tarefas e responsabilidades entre o time técnico, de acordos com as políticas e ações estabelecidas, coordenando ações coletivas, monitorando o progresso do projeto e contribuindo para ajuste de planos conforme necessário.
• Oferecer suporte técnico e orientação aos membros da equipe incentivando a colaboração e comunicação entre os desenvolvedores.
• Avaliar a capacidade técnica e senioridade da equipe.
• Ser o ponto de contato entre desenvolvimento e outras partes interessadas.
• Preparar e apresentar relatórios de progresso, projetos e dashboard de evolução e representação da escalabilidade e progressão das nossas aplicações.
• Provocar verificação e acompanhamento em novas tendências tecnológicas.
• Incentivar soluções inovadoras e melhorias contínuas.
• Modelar a fábrica de software com base na cultura da empresa.
• Facilita a execução das Dailys e se baseia nas prioridades do quadro e no gráfico Aging WIP do Kanbanize.
• Planeja e lidera as Retrospectivas mensais da squad, definindo ações e acompanhando resultados.

Das Ações do Squad Leader

• Facilita a execução das Dailys e se baseia nas prioridades do quadro e no gráfico Aging WIP do Kanbanize.
• Planeja e lidera as Retrospectivas mensais da squad, definindo ações e acompanhando resultados.
• É responsável por gerenciar as férias e registrar as faltas dos colaboradores.
• Contribui ativamente para a definição e acompanhamento das OKRs, garantindo que a equipe esteja alinhada com os objetivos estratégicos.
• É o principal defensor da estratégia da Avanço dentro da Squad.
• Acompanha de perto a evolução dos projetos da squad e o progresso no Kanbanize, garantindo que estejam dentro do prazo e da qualidade esperada.
• Estabelece e revisa os limites WIP no board, assegurando um fluxo de trabalho eficiente e equilibrado.
• Também gerencia os backlogs, realiza triagens e prioriza as atividades no Kanbanize, garantindo que a equipe esteja sempre focada nas tarefas mais importantes.
• Conduz as cadências de abastecimento de backlogs e o planejamento de entregas, garantindo uma visão clara do que precisa ser feito e quando.
• Realiza feedbacks individuais para garantir o desenvolvimento contínuo da equipe.
• Como facilitador da comunicação e cerimônias da squad, promove um ambiente de trabalho colaborativo e transparente.
• Coordena iniciativas entre squads, buscando maximizar a sinergia e a eficiência entre as equipes da Squad.
• Apresenta métricas relacionadas ao desenvolvimento de produtos de pauta da Squad, utilizando os dados do Kanbanize para identificar áreas de melhoria.
• Busca continuamente melhorias nos processos da squad, garantindo que estejam sempre evoluindo e se adaptando às mudanças e necessidades da Avanço.

Das ações do PO

• Define claramente o que se espera do produto, garantindo que todos entendam o objetivo.
• Organiza a lista de tarefas (backlog), priorizando o que é mais importante e garantindo que tudo esteja sempre atualizado.
• Define o que é necessário para considerar uma tarefa como concluída, ajudando a equipe a entender exatamente o que precisa ser feito.
• Planeja quais funcionalidades serão lançadas e quando, sempre conversando com a equipe para tirar dúvidas e orientar o trabalho.
• É a voz dos clientes e usuários dentro do projeto, usando o feedback deles para fazer ajustes e melhorias.
• Mantém o projeto no caminho certo, certificando-se de que o produto final atenda às necessidades e mantenha a qualidade prometida.
• É o guardião da boa prática, levantando argumentos e evidências sobre o desenvolvimento do produto e seu MVP, definindo claramente quais são as melhores práticas em cada etapa do projeto, deixando claro para o time e a liderança o porquê de cada ação, trabalhando a praticidade, transparência, colaboração e coordenação entre todas as partes interessadas ao produto, seja clientes internos ou externos.

Das Ações da Tribo Web

• Garante a projeção, arquitetura e desenvolvimento de novos produtos que estejam alinhados com a estratégia da Avanço.
• Garante a manutenção de produtos legados e o desenvolvimento de estratégias de migração de tecnologias obsoletas para novas tecnologias.
• É responsável por manter e responder por todas as tecnologias de integração de produtos e parceiros, além de responder por todos produtos “web” da Avanço.
• Define estratégias de escalabilidade e melhoria, buscando definir processos aprimorados e inteligentes, que minimizem atritos e burocracias para entrega de resultados.
• Determina ações de nível de arquitetura, mantendo e acompanhando o gerenciamento e uso de estrutura de banco de dados e a AWS.
• Compõe um ambiente entre diferentes Squads com ações distintas mas com propósitos multidisciplinares, compatíveis e complementares.
• Um ambiente coordenado onde todos os times com suas competências distintas, cooperam para o alcance de um objetivo em comum que esteja alinhado com a estratégia da Avanço.

Das Ações da Squad

• Garante que todos os acordos feitos em OKRs sejam entregues dentro do prazo estabelecido, seguindo boas práticas de planejamento e desenvolvimento.
• Busca quebrar impedimentos e gargalos que impeçam a entrega das OKRs, identificando e escalando de forma ágil e pragmática.
• Cuida do legado, garantindo que produtos em serviços sejam mantidos.
• Garante o suporte, manutenção e implementação de novas melhorias de acordo com os novos acordos estabelecidos.
• Responde pelos processos, entregas e competências atreladas a Squad, seja desenvolvimento de novos produtos ou manutenção de legado, assim como sendo a entidade responsável pelas primeiras ações que correspondem aos produtos e responsabilidades destacadas na tabela RACI da Tribo Web.
• Garante a correta coordenação entre as partes competentes da Squad, onde cada colaborador atua de acordo com suas skills, contribuindo diretamente para os objetivos acordados junto aos Stakeholders, abstraindo a excelência na execução de cada colaborador.