Aula 11 — Estudo de Caso: Gestão de uma Crise em Produção

Objetivo

Analisar uma situação crítica em um projeto de desenvolvimento de software e elaborar um conjunto de decisões e planos de ação para restabelecer a operação, reduzir riscos e garantir a continuidade do produto.

A atividade deverá demonstrar a capacidade de aplicar conceitos de gerenciamento ágil em situações que envolvem incerteza, restrições de prazo, problemas técnicos e conflitos entre objetivos de negócio e qualidade.

Organização: grupos de até 5 estudantes.

Entrega: um único documento por grupo, contendo todos os artefatos solicitados por email para: andre.delorme@docente.unip.br

Data Limite: 06/11/2026

1. Cenário: Uma crise antes do lançamento

Uma empresa de desenvolvimento mantém uma plataforma utilizada por instituições de ensino para gerenciar processos seletivos.

O sistema permite:

• Cadastro de candidatos.
• Inscrição em processos seletivos.
• Envio de documentos.
• Pagamento de taxas de inscrição.
• Consulta de resultados.

Uma universidade cliente iniciará seu processo seletivo na próxima segunda-feira.

A equipe de desenvolvimento trabalha há três semanas em uma nova versão da plataforma, que inclui melhorias na experiência dos candidatos e uma integração com um novo provedor de pagamentos.

A publicação da versão está prevista para sexta-feira, às 18h.

Na sexta-feira, às 15h30, durante os últimos testes antes da publicação, foram identificados os seguintes problemas:

1. A integração com o novo provedor de pagamentos apresenta falhas intermitentes.
2. Alguns candidatos conseguem enviar o mesmo documento mais de uma vez, gerando registros duplicados.
3. Uma análise de segurança identificou uma vulnerabilidade de severidade alta em uma biblioteca utilizada pela aplicação.
4. Informações pessoais de candidatos estão sendo registradas indevidamente nos logs de depuração.
5. Os testes de regressão ainda não foram concluídos.
6. A documentação técnica da nova integração está desatualizada.

O cliente insiste que a publicação aconteça na sexta-feira, pois o início das inscrições já foi anunciado.

A diretoria da empresa também demonstra preocupação com o cumprimento do contrato.

Restrições

Considere as seguintes condições:

• A equipe possui quatro desenvolvedores e um profissional de QA.
• A correção da vulnerabilidade levará aproximadamente quatro horas.
• A correção dos registros duplicados levará aproximadamente três horas.
• A integração com o provedor depende de uma equipe externa, que só poderá responder na segunda-feira.
• O mecanismo anterior de pagamento ainda está disponível.
• Não existe possibilidade de contratar novos profissionais.
• O processo seletivo deverá começar na segunda-feira.

Sua equipe foi encarregada de apresentar uma solução para a situação.

2. Entrega 1 — Diagnóstico e avaliação de riscos

Elabore um diagnóstico da situação.

O documento deverá conter:

1. Identificação dos problemas encontrados.
2. Classificação dos problemas por criticidade.
3. Avaliação dos impactos técnicos, operacionais e de negócio.
4. Identificação dos riscos relacionados à segurança e à LGPD.
5. Identificação das informações adicionais que seriam necessárias para uma decisão mais segura.

Utilize uma matriz de riscos contendo:

Apresente pelo menos cinco riscos.

3. Entrega 2 — Plano de recuperação

Elabore um plano de ação para resolver a situação.

O plano deverá considerar:

• Correção da vulnerabilidade.
• Tratamento dos dados pessoais registrados nos logs.
• Correção dos registros duplicados.
• Problemas na integração de pagamentos.
• Conclusão dos testes de regressão.
• Atualização da documentação técnica.

Organize as atividades em uma tabela:

O plano deverá respeitar as restrições de equipe e de disponibilidade de recursos.

Não é necessário implementar as correções. O objetivo é demonstrar capacidade de planejamento e organização.

4. Entrega 3 — Decisão de release

A equipe deverá decidir como proceder com a publicação.

Considere três alternativas:

Alternativa A — Publicação completa

Publicar a nova versão com todas as funcionalidades, incluindo a integração com o novo provedor de pagamentos.

Alternativa B — Publicação parcial

Publicar as funcionalidades consideradas seguras, mantendo temporariamente o mecanismo anterior de pagamento.

Alternativa C — Adiamento

Adiar a publicação até que todos os problemas sejam corrigidos e os testes sejam concluídos.

Elabore uma análise comparativa:

Ao final:

1. Escolha uma alternativa.
2. Justifique a decisão.
3. Defina os critérios mínimos para autorizar a publicação.
4. Descreva uma estratégia de rollback.
5. Defina quais indicadores deverão ser monitorados após o release.

5. Entrega 4 — Plano de comunicação e gerenciamento de incidentes

Elabore um plano de comunicação para os seguintes públicos:

• Diretoria da empresa.
• Universidade cliente.
• Equipe técnica.
• Usuários da plataforma, caso sejam afetados.

Para cada público, defina:

• Informação que precisa ser comunicada.
• Canal de comunicação.
• Momento adequado.
• Responsável pela comunicação.

Em seguida, considere a seguinte situação hipotética:

A nova versão foi publicada e, pouco depois, o monitoramento identificou um aumento de falhas nos pagamentos. Alguns candidatos também relataram cobranças duplicadas.

Elabore um procedimento de resposta ao incidente contendo:

1. Identificação e classificação do incidente.
2. Ações imediatas para limitar o impacto.
3. Decisão sobre rollback ou desativação da funcionalidade.
4. Verificação de possíveis cobranças duplicadas.
5. Comunicação aos usuários afetados.
6. Registro e análise da causa raiz.
7. Ações preventivas para evitar recorrência.

6. Entrega 5 — Melhoria contínua

Após a estabilização do sistema, a empresa decidiu revisar seu processo de desenvolvimento.

Foram identificadas as seguintes fragilidades:

• Dependências externas identificadas tardiamente.
• Critérios de aprovação de release pouco claros.
• Testes de regressão insuficientes.
• Ausência de revisão sobre os dados registrados em logs.
• Comunicação deficiente entre desenvolvimento, QA e negócio.
• Monitoramento insuficiente após publicações.

Elabore uma proposta de melhoria contínua contendo:

Apresente pelo menos cinco ações.

As ações devem ser específicas e verificáveis, evitando propostas genéricas como “melhorar a comunicação” ou “aumentar a qualidade”.

7. Entrega final

O grupo deverá entregar um único documento organizado nas seguintes seções:

1. Diagnóstico e avaliação de riscos.
2. Plano de recuperação.
3. Análise comparativa e decisão de release.
4. Plano de comunicação e gerenciamento de incidentes.
5. Proposta de melhoria contínua.

Critérios de avaliação

Orientações

• Todas as decisões devem ser justificadas.
• As propostas devem considerar as restrições apresentadas no cenário.
• Não basta identificar problemas: é necessário propor ações concretas.
• As soluções devem considerar os impactos para o negócio e para os usuários.
• Não existe uma única resposta correta, desde que as decisões sejam tecnicamente e gerencialmente justificáveis.

O objetivo é demonstrar que gerenciar software não significa apenas planejar entregas, mas também saber lidar com problemas, tomar decisões difíceis, controlar riscos e promover a melhoria contínua.