Data de Publicação

09/11/2026

Data de Modificação

26/10/2026

Relatório de Avaliação - L07

Gerado em 26/10/2026 18:57:51

📊 Resumo de Entregas

Aluno	Q1	Q2	Q3	Q4	Q5	Total
ANDRÉ GUILHERME R.	✅	✅	✅	✅	✅	5/5
ARTHUR BALTAR ELE.	✅	✅	✅	✅	✅	5/5
BIANCA DA SILVA B.	✅	✅	✅	✅	✅	5/5
CARLOS ESTEVÃO	✅	✅	✅	✅	✅	5/5
CARLOS MATHEUS	✅	✅	✅	✅	✅	5/5
DANYEL MARTINS ZI.	✅	✅	❌	❌	❌	2/5
DAVI JOSÉ DO NASC.	✅	✅	✅	✅	✅	5/5
EMMANUEL DINIZ CH.	✅	✅	✅	✅	✅	5/5
EVELYZE PINHEIRO.	✅	❌	✅	✅	✅	4/5
FILLIPE TOMAZ CAR.	✅	✅	✅	✅	✅	5/5
GABRIEL ALVARENGA.	✅	✅	✅	✅	✅	5/5
GABRIEL CAMPOS MA.	✅	✅	✅	❌	✅	4/5
GABRIEL PINHEIRO.	✅	✅	✅	✅	✅	5/5
GABRYEL FERREIRA.	✅	✅	✅	✅	✅	5/5
ISAÍAS CÉSAR SAMP.	✅	✅	✅	✅	✅	5/5
JOÃO CARLOS FERRE.	✅	✅	✅	✅	✅	5/5
JOÃO VÍTOR MARQUE.	✅	✅	✅	✅	✅	5/5
LETICIA MAURICIO.	✅	✅	✅	✅	✅	5/5
MATEUS SILVA LOPE.	✅	✅	✅	✅	✅	5/5
MATHEUS MATOS BOT.	✅	✅	✅	✅	✅	5/5
NATHAN BALMANT DE.	✅	✅	✅	✅	✅	5/5
PEDRO CLAUDIO JAC.	✅	✅	✅	✅	✅	5/5
RONALD RODRIGUES.	✅	✅	✅	✅	✅	5/5
SABRINA EVELYN SI.	✅	✅	✅	✅	✅	5/5
SAMUEL BRUM LELLE.	✅	✅	✅	✅	✅	5/5
THALLES VINÍCIUS.	✅	✅	✅	✅	✅	5/5
VICTOR GABRIEL MA.	✅	✅	✅	✅	✅	5/5
VICTOR OTAVIO SOU.	✅	✅	✅	✅	✅	5/5
VITOR EMANUEL VEN.	✅	✅	✅	✅	✅	5/5
VITOR OLIVEIRA CA.	✅	✅	✅	✅	✅	5/5
ANDERSON DE LIMA.	❌	❌	❌	❌	❌	0/5
CARLOS EDUARDO	❌	❌	❌	❌	❌	0/5
FLÁVIO CORCINI DE.	❌	❌	❌	❌	❌	0/5
GABRIEL SILVA GON.	❌	❌	❌	❌	❌	0/5
HUGO VICENTE COEL.	❌	❌	❌	❌	❌	0/5
RAFAEL DE OLIVEIR.	❌	❌	❌	❌	❌	0/5
SAULO DIAS DE OLI.	❌	❌	❌	❌	❌	0/5

🟢 ANDRÉ GUILHERME R. (Matrícula: 20243000982, Login: @andreguilherme)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

É possível fazer isso a partir de transparência das regras de negócio,dos limites internos e possíveis alucinações da LLM, além de limitações de tokens e contexto da LLM para garantir total transparência das suas limitações

4 coisas no nosso projeto que já estão completas antes do módulo 2 é o EAP, project charter, cronograma de milestones e a primeira conexão com a API

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Explicitar o problema -> Define primeiramente qual é o problema de forma objetiva, separando sintomas de causas

Ouvir interesses e evidências -> Coleta as necessidades preocupações e expectativas de todas as partes, além de buscar dados concretos, fatos, métricas históricas, pesquisas científicas ou relatórios de mercados para fundamentar a análise

Decidir com responsabilidade -> Tendo os dados e o ponto de vista, o time toma uma decisão estratégica e ética, avaliando os impactos a longo prazo, riscos e etc

Registrar o impacto -> Monitorar, mensurar e documentar os resultados da decisão, gerando aprendizado pros próximos ciclos

No projeto, uma possível discussão é nos limites de contexto, se o LLM deve saber sobre interações passadas, que melhoraria a experiencia do usuário mas tambem levaria a um custo maior, essa discussão deve ocorrer, pela facilidade, pessoalmente ou em um grupo do whatsapp, usando os comentários das issues apenas para casos isolados, mas em um time onde o pessoal não é possível, seria melhor um chat em grupo em uma plataforma como o slack

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Porque algo assim pode facilmente passar despercebido, já se tiver testes automatizados e contratos explicitando isso, é impossível de passar despercebido e é algo que vai ser encontrado antes de enviar para produção

Já no nosso projeto, o ponto mais suscetível a erros é na comunicação entre a IA e o usuário, do usuário não conseguir uma brecha na nossa proteção e fazer a IA gerar algo que está fora do escopo do projeto, para evitar esse acontecimento, vários testes tentando fazer com que a IA quebre esse escopo foram feitos, e caso os testes passam sem nenhuma quebra, a chance de acontecer em produção se reduz significantemente

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de perto -> Principais no projeto, devem participar ativamente no projeto e ter suas expectativas atendidas com prioridade

Manter Satisfeito -> Podem influenciar o projeto, mas não o acompanham de perto, devem ser mantidos satisfeitos para evitar oposição

Manter informado -> Preocupam-se com os resultados, mas têm pouca força de decisão. Devem receber atualizações frequentes para continuar apoiando

Monitorar -> Exigem o mínimo esforço. Apenas acompanhe periodicamente sem sobrecarregar com excesso de comunicação

No nosso projeto, o professor seria apenas o monitorar, porque ele apenas acompanha o projeto cada semana, um usuário competidor do ICPC seria um no Manter informado, ele está preocupado com os resultados mas não decide muita coisa, ele provavelmente olharia mais de 1 vez por semana pra ver se foi feito algum progresso, e outro seria administrador da infraestrutura interna, que seria no manter satisfeito, que como estamos usando o discord, quando o bot chegar a 10000 usuários ele vai ter um impacto direto no bot de exigir uma verificação antes de continuar o uso

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Usando a formula, se saltar de 4 pra 10 pessoas, iremos de 6 pares para 45 pares, que mostra um crescimento quadrático pela formula, a comunicação sincrona é aquela efetuada em tempo real, no momento, já a assincrona pode ser feita em estágios diferentes, por exemplo em issues, que é usada para resolver problemas mais complexos, que é o porque certos problemas devem ser resolvidos de forma assíncrona, porque não tem como resolve-los de forma sincrona pelo seu tamanho ou outros aspectos

A comunicação no nosso time é principalmente a sincrona, em um grupo do whatsapp que é onde é definido as decisões de arquitetura, já a implementação de certas coisas é feita de forma assíncrona por meio das issues e milestones

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 ARTHUR BALTAR ELE. (Matrícula: 20223004240, Login: @ArchieBaltar)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Para gerenciar expectativas sobre LLMs, a equipe deve declarar as limitações antes de qualquer demonstração, inclusive a final, e não depois que algo der errado. O Maieut-IA pode alucinar, tem latência variável, usa uma cota de tokens e não é totalmente determinístico: a mesma pergunta pode gerar respostas um pouco diferentes. O Escopo “Fora do MVP” do Charter já cobre parte disso. Declarar essas limitações no Plano de Comunicação evita o Efeito Demonstração, em que uma primeira demonstração bem-sucedida cria a falsa expectativa de perfeição. Transformar a expectativa em RNF, como o RNF01 de tempo de resposta, a torna um limite testável e comunicável.

Das quatro evidências esperadas no Check 02, só a primeira está completa no repositório:
1. A EAP e o cronograma estão prontos: docs/EAP.md (hierarquia, Dicionário e Regra dos 100%) e os 4 Milestones no GitLab, com Issues vinculadas. b.A Matriz de Riscos está parcial. Os 5 riscos com mitigação estão no docs/PROJECT_CHARTER.md, mas como lista e não como matriz P×I. Os dois riscos classificados na Matriz PxI (latência da API e perda da chave do João) e não foram commitados.
2. A Matriz RACI não está formalizada. O raciocínio foi aplicado uma vez, na revisão do MR do spike (R=João, A=Arthur, C=Bianca, I=professor), mas nunca virou um documento do projeto.
3. A Matriz de Stakeholders também não está formalizada.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Um conflito técnico passa por quatro passos: nomear a divergência (objetivos, evidências, prioridades ou restrições), ouvir os motivos técnicos de cada lado, deixar quem tem a autoridade (o “A” da RACI) decidir e registrar a decisão em Issue, MR ou ADR. A postura adotada depende do contexto: colaborar quando há tempo, conceder quando prolongar custa caro, forçar quando a decisão já está autorizada, apaziguar declarando o impacto técnico aceito e evitar apenas com data e responsável para retomar.

Forçar é legítimo numa emergência como uma chave de API exposta, porque a autoridade foi combinada antes do incidente e a justificativa é registrada depois. Evitar é prudente quando faltam dados, já que decidir sob incerteza alta custa caro de reverter, desde que o adiamento seja rastreado.

No Maieut-IA, o caso foi o MR do spike do João, que usou client.responses.create() com gpt-3.5-turbo. Levantei a dúvida técnica, pedi evidência de que rodava, segurei a aprovação com o João como responsável por testar e deixei tudo registrado no MR, vinculado à Issue #7. O comentário tratou do que precisava ser confirmado, sem apontar quem errou.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

O incidente do Mars Climate Orbiter não se explica por uma única falha de comunicação. Envolveu requisitos de interface, validação, testes e controles de projeto. Lockheed Martin e NASA JPL assumiram, cada uma, que a outra usava a mesma unidade de medida. O acordo existia só na cabeça das pessoas e nunca foi verificado automaticamente antes de o dado cruzar a fronteira entre os sistemas.

Um alinhamento verbal depende de memória humana e não é reexecutado a cada integração. Também não falha de forma visível: o sistema recebe o número, processa normalmente e só o resultado final sai errado, sem alarme no meio do caminho. Um contrato explícito, com schema e validação automática, verifica a cada execução e falha de forma imediata quando o formato não bate. Ele prova que a integração está certa toda vez que roda, em vez de apenas supor.

A fronteira mais arriscada fica entre o Core Lógico e a resposta da API da OpenAI. A interface Streamlit e o Core Lógico vivem no mesmo processo Python, então uma incompatibilidade de tipo tende a quebrar na hora, com um erro de execução óbvio. Na API, a equipe não controla o outro lado: a OpenAI pode mudar o formato da resposta, o comportamento do modelo ou a estrutura de saída sem aviso direto, como o Risco 5 do Charter já registra. Se o Core Lógico espera, por exemplo, a classe do algoritmo em um campo separado da complexidade (RF04) e a resposta vem em formato um pouco diferente, a aplicação não quebra. Ela exibe a informação errada, a mesma falha silenciosa do Mars Climate Orbiter.

Para blindar o repositório, a equipe pode seguir três passos:

A validação anti-vazamento de resposta (pacote 1.2.3 da EAP) cobre parte do problema, mas só verifica o que não pode aparecer, como código completo, e não a forma que a resposta deve ter. Um schema em Pydantic define o que o Core Lógico espera extrair da resposta do LLM, com campos tipados para a classe do algoritmo, o nível de complexidade sugerido e o texto da dica. A saída é validada contra ele antes de seguir para a interface. Essa validação roda como teste de contrato automatizado no pipeline de CI/CD (pacote 1.4.2 da EAP). Se a resposta do modelo deixar de bater com o schema, o pipeline falha e bloqueia o merge, em vez de o erro passar silenciosamente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Em “gerenciar de perto” (alto poder, alto interesse), o engajamento é ativo e nos dois sentidos: consultar antes das decisões importantes, dar visibilidade constante do progresso e envolver a pessoa nos marcos críticos. É o quadrante que mais exige atenção da equipe.

Em “manter satisfeitos” (alto poder, baixo interesse), a comunicação é resumida e pontual, centrada em marcos e riscos que afetam as prioridades da pessoa. Detalhes operacionais do dia a dia ficam de fora, já que o interesse é baixo, mas o poder de ajudar ou atrapalhar o projeto é alto.

Em “manter informados” (baixo poder, alto interesse), as atualizações são regulares, em geral por canal assíncrono, e a pessoa acompanha o progresso e opina quando fizer sentido, sem autoridade de decisão.

Em “monitorar” (baixo poder, baixo interesse), o esforço é mínimo. A equipe só reage se o contexto mudar, por exemplo quando a pessoa ganha interesse ou poder ao longo do projeto.

O professor avalia evidências da disciplina conforme uma regra acadêmica publicada, a rubrica. Um cliente esclareceria necessidades de uso do produto. As perguntas são diferentes: o cliente quer saber se aquilo resolve o problema dele, e o avaliador quer saber se a equipe aplicou corretamente os conceitos de gestão. Por isso a evidência a entregar são os artefatos que a disciplina define: EAP e cronograma, matriz de responsabilidades, critérios de qualidade, plano de riscos e mapa de stakeholders. Provar que o Maieut-IA é bom em termos comerciais, com usuários satisfeitos, retenção ou ROI, não responde ao que está sendo avaliado. Tratar o professor como cliente levaria a equipe a gastar esforço no lugar errado, como polir a interface em vez de garantir rastreabilidade no GitLab.

O professor avaliador, Aléssio Jr, tem alto poder, porque define a nota e a aprovação, e alto interesse, porque acompanha as Issues e revisa cada módulo. Fica em “gerenciar de perto”. A cadência é por marco (cada Milestone ou Módulo), mais comentários pontuais quando ele abre uma Issue de pergunta reflexiva. O canal oficial são os comentários nas Issues do GitLab e a Wiki do repositório.

O usuário competidor do ICPC, o aluno que usaria o assistente, tem baixo poder, pois não decide nada no projeto, e alto interesse, pois é quem se beneficia ou não da ferramenta. Fica em “manter informados”. A cadência é por marco, quando houver uma versão testável, por exemplo no fim do Milestone 2 ou 3. O canal é o feedback coletado pela equipe em testes manuais. Ainda não há um canal direto formalizado, porque o MVP acadêmico não tem usuários reais.

O administrador da API externa (OpenAI) tem alto poder, pois pode mudar preços, descontinuar modelos ou alterar limites sem aviso à equipe, caso já previsto no Risco 5 do Charter. Seu interesse no projeto é baixo, já que o Maieut-IA é só mais um cliente entre milhões. Fica em “manter satisfeitos”. A cadência é de monitoramento contínuo e passivo, com revisão pontual quando houver aviso de descontinuação. O canal é a página oficial de deprecations e changelog da OpenAI, já referenciada no Charter.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Os canais diretos entre N participantes seguem C = N(N − 1)/2. Cada pessoa nova se conecta a todas as que já estão no grupo, então o total cresce com N², e dobrar a equipe aproximadamente quadruplica os canais. Se o crescimento fosse exponencial (2ᴺ), cada pessoa nova dobraria o total. De 4 para 10 pessoas, os canais vão de 6 para 45: a equipe cresce 2,5 vezes e os canais, 7,5 vezes. O modelo simplifica, porque nem todo par precisa conversar e papéis e artefatos compartilhados reduzem as conversas individuais.

Reuniões e chamadas servem para descoberta, negociação e temas sensíveis. Issues, e-mail, documentação, MRs e ADRs favorecem preparação, rastreabilidade e participação em horários diferentes. Decisões relevantes precisam de registro acessível às pessoas autorizadas, seja qual for o canal em que foram discutidas. Por isso decisões de arquitetura (ADR), requisitos, riscos e mudanças de código (MR) devem ficar no modo assíncrono, e o chat fica para alertas rápidos, sem credenciais nem dados pessoais.

No Maieut-IA, a equipe tem 3 pessoas (Estudos, Bianca e João), o que dá 3 canais. Com o professor Aléssio como avaliador, são 4 pessoas e 6 canais. Se entrarem também um representante de usuários e a coordenação, chega-se a 6 pessoas e 15 canais. Esse número é um teto, já que os externos não precisam conversar entre si.

A política proposta é esta: o GitLab é a fonte única da verdade; cada assunto tem uma Issue, aberta só depois de buscar duplicatas; A partir de agora, a equipe formaliza esta política: decisões de arquitetura passam a ser registradas em ADRs na pasta docs/adr/ (ainda não criada, primeira a ser adicionada no próximo commit); todo código entra por MR com revisor; o que for decidido no chat é resumido na Issue em até 24 h; reuniões geram uma ata curta na Issue do milestone.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 BIANCA DA SILVA B. (Matrícula: 20223004410, Login: @biancaB)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve deixar claro que o Maieut-IA possui limitações, como respostas incorretas, variação entre respostas, demora da API e limites de uso. Também deve explicar seu escopo: o bot ajuda o aluno a chegar à solução, mas não garante respostas perfeitas e não fornece código pronto.

Para o Check 02, o projeto já possui como evidências: - EAP e cronograma: docs/EAP.md, com os pacotes de trabalho e referência aos 4 Milestones do GitLab. - Definição de responsabilidades: README.md e docs/PROJECT_CHARTER.md, com os papéis de Scrum Master, Product Owner e Tech Lead/Dev. - Riscos e planos de resposta: docs/PROJECT_CHARTER.md, na seção de riscos iniciais. - Stakeholders: estão identificados pelo contexto do projeto, principalmente professor avaliador, equipe e alunos usuários, mas o repositório ainda não possui uma Matriz de Stakeholders formal.

Assim, três das evidências estão documentadas diretamente no repositório, enquanto a Matriz de Stakeholders ainda precisaria ser formalizada para o Check 02.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O tratamento de conflitos deve começar deixando claro qual é o problema, depois ouvindo os interesses e as evidências de cada lado, tomando uma decisão e registrando seus impactos no projeto.

As cinco posturas são: colaborar, quando as partes buscam juntas a melhor solução; conceder, quando cada lado abre mão de algo; forçar, quando uma decisão precisa ser tomada rapidamente, podendo ser legítima em situações de segurança; apaziguar, quando se prioriza manter a relação e reduzir o conflito; e evitar, quando é melhor adiar a decisão, principalmente quando ainda faltam informações.

No Maieut-IA, um possível conflito técnico envolve o System Prompt, já que ele precisa orientar o usuário sem entregar diretamente a solução dos problemas. Uma alteração pode melhorar a ajuda dada pela IA, mas também aumentar o risco de ela fornecer respostas completas. Essa discussão deve acontecer em uma Issue ou Merge Request, comparando resultados dos testes do prompt e não opiniões pessoais. A decisão escolhida deve ficar registrada no GitLab, junto com sua justificativa e impacto, mantendo a discussão focada no projeto e não nas pessoas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Interfaces entre módulos precisam de contratos explícitos porque cada parte deve saber exatamente quais dados enviar e receber. Só alinhamentos verbais podem gerar interpretações diferentes, enquanto documentação e testes ajudam a identificar incompatibilidades antes que cheguem ao usuário.

No Maieut-IA, a fronteira mais sujeita a erros está entre o backend e a API da OpenAI, principalmente no envio do prompt e no tratamento da resposta. O repositório documenta esse fluxo em ARQUITETURA.md, definindo módulos como Parser, ClienteAPI e ProcessadorResposta. Também existem requisitos para validação da entrada, tratamento de erros, rate limit e proteção da chave da API. Atualmente, porém, o projeto não possui contratos OpenAPI, schemas Pydantic ou testes automatizados de contrato, há apenas um teste inicial de integração com a API em spike/test_api.py.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Na matriz Poder x Interesse, stakeholders com alto poder e alto interesse devem ser gerenciados de perto; alto poder e baixo interesse devem ser mantidos satisfeitos; baixo poder e alto interesse devem ser mantidos informados; e baixo poder e baixo interesse apenas monitorados.

O professor atua como avaliador acadêmico, não como cliente comercial. Por isso, o foco das entregas deve ser mostrar cumprimento dos requisitos da disciplina, funcionamento do sistema, documentação e evolução do projeto.

No Maieut-IA: - Professor avaliador: alto poder e alto interesse, com acompanhamento por marco pelo GitLab e documentação. - Usuário competidor: baixo poder e alto interesse, devendo ser informado durante testes e novas entregas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O número de canais de comunicação é dado por (C = N(N - 1) / 2). Por isso, o crescimento é quadrático, O(N²). Com 4 pessoas existem 6 canais (C = 4(4 - 1) / 2 = 6). Com 10 pessoas existem 45 canais (C = 10(10 - 1) / 2 = 45).

Isso mostra que, conforme a equipe cresce, fica cada vez mais difícil manter tudo só em conversas informais. A comunicação síncrona acontece em tempo real, como em reuniões e chats. Já a assíncrona fica registrada, como em Issues, Merge Requests e ADRs. Decisões importantes sobre tarefas, código ou arquitetura devem ser registradas de forma assíncrona, porque assim podem ser consultadas depois.

No projeto Maieut-IA, considerando os 3 integrantes da equipe e o professor como principal interlocutor externo, são 4 participantes e 6 canais diretos. O GitLab é usado para registrar as atividades do projeto, enquanto o chat fica mais para dúvidas rápidas e alinhamentos do dia a dia.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 CARLOS ESTEVÃO (Matrícula: 20243001658, Login: @carlos-e-araujo)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve esclarecer explicitamente o objetivo do sistema, dados de entrada, limitações inerentes de modelos generativos e evidências obtidas em testes representativos. Protótipos rápidos e demonstrações servem para apoiar a conversa, mas não substituem requisitos nem garantem precisão operacional.

O que o bot faz é o que expressamente não faz deve ser formalizado no Project Charter e na interface com o usuário. Deve-se explicitar que o agente é um tutor socrático para guiar com pistas, e não uma ferramenta de gabarito ou gerador de soluções prontas.

Devemos também, comunicar ao usuário e stakeholders que as respostas são probabilísticas. Explicar a dependência de serviços externos de IA. Esclarecer limites de uso e aplicar barreiras de proteção no servidor.

Até o momento temos:

Project Charter: https://git.juninho.com.br/cefet-gps-2026/gps-projetos-integradores/cemig-01/-/blob/develop/docs/PROJECT_CHARTER.md?ref_type=heads
Requisitos: https://git.juninho.com.br/cefet-gps-2026/gps-projetos-integradores/cemig-01/-/blob/develop/docs/REQUISITOS.md?ref_type=heads
EAP: https://git.juninho.com.br/cefet-gps-2026/gps-projetos-integradores/cemig-01/-/blob/develop/docs/EAP.md?ref_type=heads
Diretrizes de Prompt: https://git.juninho.com.br/cefet-gps-2026/gps-projetos-integradores/cemig-01/-/blob/develop/docs/DIRETRIZES_PROMPT.md?ref_type=heads

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Explicitar o problema: Torna claro os fatos e o objeto central da divergência técnica, separando o problema das pessoas envolvidas.

Ouvir interesses e evidências: Levanta dados técnicos objetivos, restrições reais e os objetos de cada parte antes de qualquer julgamento.

Decidir com responsabilidade: Adiciona o responsável pela decisão técnica, avaliando trade-offs de curto e longo prazo.

Registrar o impacto: Documenta formalmente o que foi decidido, os impactos técnicos assumidos e as ações acordadas em uma ADR ou issues, garantindo rastreabilidade futura.

Colaborar / Resolver o problema: Investiga a fundo os interesses, alternativas e evidências para alcançar uma solução conjunta que atenda aos objetivos do projeto quando há tempo disponível.

Conceder / Reconciliar: Encontra um meio-termo aceitável para ambas as partes, sendo útil quando prolongar a discussão traz custo superior á concessão.

Forçar / Impor: Aplica uma decisão autorizada de forma unilateral. Em incidentes críticos, vazamento de credenciais ou vulnerabilidades ativas, a prioridade é a contenção imediata de danos e a conformidade legal, onde a deliberação demorada acarreta riscos severos.

Apaziguar: Prioriza os pontos de concordância ou cede parcialmente para preservar o relacionamento da equipe, exigindo explicitar o impacto técnico tolerado.

Evitar / Retirar: Adia ou suspende temporariamente a discussão. Tomar decisões arquiteturais sob incerteza ou suposições infundadas gera retrabalho, suspender a decisão permite realizar provas de conceito e coletar dados empíricos antes a escolha definida.

A equipe estava em duvida entre Groq e o OpenRouter, o Groq oferece um plano gratuito mais generoso, porem poucas opções de LLM ao contrario da OpenRouter.

Não discutimos isso no GitLab, mas em uma situação ideal deveria ser assim:

Debate Técnico na Issue: A discussão abre em uma issue concentrado em requisitos verificáveis como custo, latência, resiliência a quedas, limites de cota. Nenhum comentário é pessoal, mantendo a conversa restrita aos fatos apresentados.

Análise de Evidências e Provas de Conceito: Cada lado apresenta métricas reais obtidas em chamados de testes, evitando decisões por preferencia pessoal.

Decisão Responsável e Formalização em ADR: A escolha pela OpenRouter é consolidada pelo critério de flexibilidade e mitigação de risco de dependência de fornecedor. Para evitar conversas duplicadas ou dúvidas futuras, registra o arquivo detalhando o contexto, decisão, justificativa e os trade-offs aceitos. O link do ADR é publicado na issue e o tópico é fechado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Conversas informais e combinados verbais introduzem ruídos semânticos, ambiguidades e perda de rastreabilidade com o tempo e com o crescimento da equipe. Eles não fornecem garantias formais sobre tipos de dados, limites de carga, tratamento de nulos ou conversões de unidades de medida, como no caso da Mars Climate Orbiter, onde a falta de validação de interface causou a perda da sonda.

Quality Assurance (Processo): O contrato formalizado, ou seja a especificação da interface, define uma fronteira clara e invariável que impede divergências de implementação entre módulos independentes.

Quality Control (Produto): Apenas testes de contrato e integração automatizados executados na esteira de CI conseguem validar, a cada alteração de código, se os dados trafegados respeitam rigorosamente a estrutura acordada antes de chegarem aos ambientes integrados.

A fronteira mais suscetível é a integração entre o backed do bot e a resposta da API do LLM. Como o LLM possui uma natureza probabilística e não determinística, suas saídas de texto livre podem variar, omitir campos, quebrar formatações esperadas ou alucinar formatos estruturados.

Para blindar a ideia é criarmos uma validação do payload que vem do LLM, definindo modelos estruturados em JSON. Fazendo uma desserialização e validação dos campos antes de mandar para o frontend.

Também vamos documentar a API com o Swagger para garantir que o front faça requisições de forma adequada.

Vamos fazer, também, testes de CI/CD, que vão barrar qualquer comportamento inadequado conhecido e que possuem testes automatizados já definido no projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de Perto (Alto Poder, Alto Interesse): Exige engajamento ativo, comunicação frequente e alinhamento próximo de decisões riscos e progresso crítico.

Manter Satisfeitos (Alto Poder, Baixo Interesse): Foco em resumos executivos de marcos, impactos de alto nível e decisões estratégicas para assegurar que suas restrições e expectativas sejam atendidas sem sobrecarga de detalhes.

Manter Informados (Baixo Poder, Alto Interesse): Comunicação periódica com relatórios, demonstrações e canais para receber feedback e consultas, aproveitando sue interesse para validar requisitos e testes.

Monitorar (Baixo Poder, Baixo Interesse): Acompanhamento com comunicação de baixa intensidade por canais gerais, observando se mudanças no contexto alteram sua influencia ou interesse no projeto.

O professor atua avaliando o cumprimento as regras acadêmicas, a maturidade metodológica e o processo de engenharia. Ele não define dores comerciais nem consome o valor do negócio como cliente. Um cliente busca apenas a entrega da funcionalidade, já o professor exige rastreabilidade do processo, mesmo que o escopo seja um protótipo.

Professor: Tem alto poder e alto interesse. O professor possuí autoridade direta na aprovação e avaliação do projeto. A cadência da comunicação é por marco através do GitLab.

OpenRouter: Alto Poder e Baixo Interesse. As cotas e instabilidades podem bloquear o sistema, mas a entidade não tem interesse direto no projeto. A cadência de comunicação é feita frequentemente, para verifica o consumo das cotas, isso é feito através do dashboard do provedor.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A quantidade de pares de comunicação é dado pela formula da combinação simples. O termo de mair ordem é O(N^2) e não exponencial O(2^N).

Para N = 4, C = (4x3)/2 = 6 canais.

Para N = 10, C = (10x9)/2 = 45 canais.

Quando saltamos de 4 para 10 pessoas, os canais diretos aumentam de 6 para 45 tendo um acréscimo de 39 conexões.

A comunicação síncrona é indicada para alinhamentos rápidos, resolução de bloqueios operacionais e desobstrução de impedimentos e outras discussões que precisam de resposta em tempo real.

A assíncrona são coisas com issues, merge requests, ADRs favorece a rastreabilidade, reflexão e consulta ao longo de ciclo de vida do projeto, e são para coisas “menos” urgentes.

O grupo tem 3 membros e o professor como interlocutor externo, logo 4 pessoas. Temos então C = (5x4)/2 = 10 canais.

Para comunicação assíncrona definimos: As escolhas estruturais ficam documentadas no projeto. As tarefas ficam em issues no repositório. O código é enviado pro meio ode Merge Request. Os debates relacionado a um tópico especifico como uma issue, merge request, ou documentação ficam nos comentários do GitLab referente ao item. Os pontos que não se encaixo como discussões sem urgência, duvidas e etc. é feito no grupo de WhatsApp por ser um canal mais rápido.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 CARLOS MATHEUS (Matrícula: 20233007620, Login: @Carlos_Matheus_2005)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe precisa ser sincera que se trata de um modelo genérico feito por alunos e deve esclarecer de maneira sucinta sobre os objetivos, os dados disponíveis, os critérios de qualidade, os riscos, as alternativas e as evidências de teste, pois o nosso sistema tem limitações, incertezas, custos, riscos de privacidade e comportamentos que precisam ser avaliados no contexto de uso. Então, é necessário ser bem equilibrado nas expectativas do usuário, pois apesar de tudo isso, a LLM ainda funciona e é um projeto bem interessante de ser testado e construído, apesar de deixarmos baixas as expectativas, devemos ainda sim empolgar o usuário para que ele tenha interesse e se divirta testando.

As evidências de gestão do grupo:

EAP/WBS -> EAP.md e acompanhamento por Milestones e Issues no GitLab.
Matriz RACI -> documentação das responsabilidades dos integrantes do grupo. (está no README.md)
Matriz de Riscos e plano de contingência -> documentação dos riscos identificados, probabilidade, impacto e estratégias de resposta (está no PROJECT_CHATER.md).
Matriz de Stakeholders -> ainda não foi formalizada no repositório. Embora os principais stakeholders já tenham sido identificados e discutidos, a matriz ainda precisa ser registrada como documento no GitLab.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Primeiramente, é importante Explicitar o Problema, ou seja, definir o conflito de forma objetiva, separando os fatos das emoções, depois é Ouvir os Interesses e Evidências, ou seja, investigar os motivos reais de cada lado e os dados que sustentam cada visão. Em seguida, deve-se Decidir com Responsabilidade, criando soluções justas, éticas e viáveis que atendam às necessidades identificadas. Por fim, o ciclo se fecha ao Registrar o Impacto, documentando o acordo e avaliando os resultados a longo prazo para garantir que o problema foi realmente resolvido.

As cinco posturas situacionais:

Colaborar/resolver o problema: investiga interesses, evidências e alternativas. Pode ser útil quando há tempo e compromisso para uma decisão conjunta.
Conceder/reconciliar: busca um acordo aceitável para as partes; pode ser apropriado quando o custo de prolongar a decisão é alto.
Forçar/impor: aplica uma decisão autorizada, por exemplo diante de incidente com responsabilidade previamente definida. Requer justificativa e registro.
Apaziguar: enfatiza pontos de concordância ou cede em um aspecto para preservar a relação; é preciso explicitar o impacto técnico aceito.
Evitar/retirar: adia ou transfere a discussão; pode criar tempo para obter dados, mas requer data e responsável para retomar o tema.

Forçar mostra-se importante quando precisamos resolver algo rapidamente, não podemos perder muito tempo e não há tanto espaço de diálogo, mas mesmo assim existe um motivo para tudo ser feito.

Evitar é uma forma prudente porquê, se não apresentarmos todas as informações e dados disponíveis, não podemos tomar as decisões verdadeiramente corretas. Então, as vezes é melhor prevenir do que remediar, esperando mais informações chegarem para ter uma maior clareza.

Até o momento, não ocorreram conflitos técnicos na equipe. Entretanto, um possível problema futuro talvez seja na definição do limite de contexto enviado ao Gemini, pois enviar todo o histórico da conversa pode aumentar o custo e o tempo de resposta, enquanto limitar demais o contexto pode prejudicar a continuidade do raciocínio do aluno. Se surgir, imagino que seja enviado uma mensagem para o Scrum Master (no caso eu) para ajudar a decidir como prosseguir e podermos lidar isso em equipe, analisando em conjunto a parte técnica relevante e depois documentando nossas possíveis alterações.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Os contratos explícitos e testes automatizados conseguem evitar que ocorram divergências técnicas relacionadas a integridade do projeto por apresentar um meio concreto e físico de se fazerem as verificações, ou seja, todo o estudo é conduzido de acordo com os conformes e ainda é possível fazer análises do que diverge entre o que foi já foi feito pelas duas equipes diferentes (a falta disso provocou o incidente da sonda espacial, tendo em vista que se tivessem a documentação veriam as unidades de medidas diferentes). Apenas algo verbalizado não consegue concentrar todo o dimensionamento do projeto, podendo surgir conflitos do que foi feito e do que foi pedido.

No meu projeto:

A fronteira mais suscetível a erros está na comunicação entre a interface Web, o backend e a API do Gemini, pois é nesse ponto que os dados precisam seguir formatos e regras previamente definidos.
Meu documentou esse contrato no repositório por meio dos requisitos e da documentação da arquitetura, especificando as responsabilidades de cada parte e as regras de comunicação com a IA

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

As estratégias de comunicação para os quatro quadrantes da Matriz de Poder e Interesse servem para otimizar o engajamento e evitar desperdício de recursos na gestão de partes interessadas, que são os stakeholders.

Gerenciar de Perto (alto poder, alto interesse): São os participantes mais críticos para o sucesso do projeto (como os principais patrocinadore)

Manter Satisfeitos (alto poder, baixo interesse): São pessoas influentes que podem impactar o projeto se ficarem insatisfeitos, mas que não acompanham os detalhes do dia a dia (como órgãos reguladores ou a diretoria financeira)

Manter Informados (baixo poder, alto interesse): São os grupos muito afetados pelas entregas do projeto, mas com pouca autoridade para alterá-las diretamente (como os usuários finais)

Monitorar (baixo poder, baixo interesse): Indivíduos que demandam o menor esforço de gestão, pois não têm forte influência nem grande engajamento no momento (como os colaboradores de outros departamentos não ligados ao projeto)

O professor é um Avaliador de Conformidade Acadêmica porque ele vai orientar e indicar os erros, auxiliando na construção do projeto conforme as dúvidas forem surgindo. Um cliente comercial só quer enviar a ideia e receber o projeto funcionando sem falhas, sem problemas e completo.

Mapa de Stakeholders do meu assistente de IA:

Gerenciar de Perto (alta poder/alto interesse): Professor Avaliador -> acompanhar o andamento do projeto para cada marco alcançado no prazo.
Manter Informado (baixa pode/alto interesse): Estudante usuário final -> acompanhamento semanal e quem vai ser um usuário teste quando tiver tudo pronto.
Monitorar (baixo poder/baixo interesse): Colegas de Outros Grupos -> Estão focados em seus próprios projetos. Portanto, não é necessário manter uma comunicação frequente com eles, basta monitorar caso surja alguma interação relevante entre os grupos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O crescimento exponencial ocorre quando uma quantidade aumenta proporcionalmente ao seu próprio valor, gerando um crescimento multiplicativo. Já o crescimento dos canais de comunicação em uma equipe é quadrático porque cada participante pode precisar se comunicar com os demais, formando diferentes pares. Por isso, conforme o número de participantes for aumentando, o número de possíveis conexões vai crescendo proporcionalmente a n^2, e não por ramificações multiplicativas sucessivas.

Por exemplo, utilizando a fórmula, com 4 participantes teremos um valor de 6 pares e com 10 participantes teremos um valor de 45 pares.

Comunicação Síncrona: Acontece em tempo real, exigindo que as pessoas envolvidas estejam ativas e disponíveis no mesmo momento como reuniões e chamadas, podendo ajudar em descoberta, negociação, temas sensíveis ou decisões que exigem interação imediata.

Comunicação Assíncrona: Ocorre em momentos diferentes, sem a necessidade de uma resposta imediata ou simultânea como issues, e-mail e documentação, podendo favorecer preparação, rastreabilidade e participação em horários diferentes.

A escolha da forma de comunicação depende de vários fatores como urgência, complexidade, disponibilidade, acessibilidade e confidencialidade. Entretanto, coisas muito importantes e que não devem ser esquecidas precisam do modo assíncrono, pois geralmente ele é o que documenta o que precisa ser feito, a forma, as instruções, uma simples reunião para definir as coisas pode causar o risco de esquecimento do que precisa ser feito ou uma confusão da coisa certa a ser feita (a pessoa pode entender a instrução errado, mas se tiver escrito ela terá mais segurança do que fazer)

Para o meu projeto integrador, considerando que somos 4 integrantes e os interlocutores externos seriam o professor e talvez um aluno teste, podemos dizer que teremos 6 pessoas. Pela conta -> C = (6(6-1)/2 = 15 canais de comunicação.

Além disso, as políticas de comunicação assíncrona foram as issues, para as decisões do que fazer e a forma de registrar o que foi feito (além de registrar as tarefas).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟡 DANYEL MARTINS ZI. (Matrícula: 20243014020, Login: @DanyelZini)

Progresso: 2 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciamento de Perto: São stakeholedrs que possuem grande influência sobre o projeto e também acompanham os resultados de forma ativa.

Manter Satisfeito: Capacidade de influenciar o projeto, mas não acompanha todos os detalhes, tendo como objetivo fornecer informações suficientes para que continuem de acordo com o esperado.

Manter informado: Podendo ser clientes com bastante interesse no projeto, mas sem muitas autoridades, onde recebem atualizações frequentes sobre o progresso e resultados, além de dar feedbacks mas sempre com uma analise posterior.

Monitorar: Pessoas com pouca influência e pouco interesse direto no projeto, normalmente espera-se somente o resultado final, mas mesmo assim e necessário informar caso haja algum erro ou mudança relevante no projeto.

O professor/analisador possui como responsabilidade verificar se o projeto atende aos requisitos, como metodologia, documentação, arquitetura e qualidade técnica, dando feedbacks bem estruturados e com grande importância aos desenvolvedores. 2. Professor/avaliador: Com grande poder e interesse, podendo gerenciar de perto com uma frequência alta.

Usuário final: Baixo poder mas com grande interesse, mas mantendo informado sempre que necessário.

Administrador: Alto poder mas baixo interesse, só informado quando extremamente necessário.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Utilizando a formula, para 4 pessoas o numero de comunicações será de 6 e para 10 pessoas, o numero de comunicações sobe para 45. Assim, demonstrando o qual invalido é utilizar o WhatsApp para se comunicar para o projeto.

Agora sobre as comunicações síncronas e assíncronas, a síncrona acontece quando as pessoas precisam estar disponíveis praticamente ao mesmo tempo, como em reuniões, chamadas ou conversas presenciais, já a assíncrona, não exige que ambos estejam disponíveis simultaneamente, referente ao Issues, Merge Requests e documentações, que não necessariamente precisa de todos disponíveis e somente aquele responsável. 2. No projeto de Assistente de IA, são 4 pessoas, então é necessário 6 canais de comunicação, para que facilite a organização entre os membros a organização que podemos usar e englobando três métodos, sendo eles o CPM, Milestone e Issue, organizando por categorias, tempo e tarefas para cada membro, além de um chat somente para comunicações rápidas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes
Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais
Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

🟢 DAVI JOSÉ DO NASC. (Matrícula: 20243001685, Login: @DaviJ)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Uma forma efetiva de explicar essa delimitação é buscar exemplos aonde a limitação da IA fique explicitada e deixar fresco na cabeça dos stakeholders que esse é um comportamento esperado e uma resposta rápida pode acontecer, mas não é a norma.

EAP: Painel de milestones e no board do gitlab

RACI: Readme do projeto no repositório git

Matriz de risco: Readme do projeto no repositório git

Mapa de Stakeholders: Documentação estrutural do projeto no repositório git

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Explicitar o problema: Separar o problema de forma técnica;

Ouvir interesses e evidências: Coletar informações a cerca do contexto do problema;

Decidir com responsabilidade: O responsável decide como a equipe deve tratar determinado problema;

Registra o impacto: A decisão e seu contexto é explicitado em um documento e guardado.

Colaborar: Investir tempo em conjunto investigando formas de solucionar um problema de maneira efetiva;

Conceder: Buscar um meio termo aceitável para ambos os lados de uma discussão;

Forçar: Decisão imposta por uma autoridade ou uma maioridade, sem conseguir chegar em uma aceitação mutua. Em situações de segurança não se deve aceitar soluções que envolvam diminuição de camadas de proteção sem compensação, independente da discussão;

Apaziguar: Um lado cede intencionalmente para resolver uma questão;

Evitar: Adiar a discussão e resolução de um problema. Pode ser efetivo quando não há informações o suficiente para tomar a melhor decisão possível; 2. A discussão entre fazer um bot para telegram ou um site próprio para hospedar o assistente surgiu no começo do projeto. Todos os membros colocaram suas opiniões a respeito dessa escolha em uma discussão e foi avaliado objetivamente qual era a melhor. Por fim foi escolhida a hospedagem de um site próprio.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

A dependência exclusiva em alinhamentos verbais pode carregar problemas de comunicações causados pela limitação da linguagem, permitindo passar problemas que outrora, de forma mais técnica, não iriam passar. Contratos explícitos e testes automatizados não tem a barreira linguística e de interpretação, podendo avaliar mais objetivamente se algo é capaz de ser integrado ou não.

Fronteira mais suscetível a erros de comunicação: Na transição entre o backend e o frontend.

O grupo se blindou por contratos verbais, escritos em canais assíncronos e em arquivos como gitnore e pom.xml.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de Perto: São as peças-chaves que definem o sucesso ou fracasso de um projeto. Comunicação com canais síncronos e assíncronos. Participam de revisões e definem metas.

Manter Satisfeito: São pessoas que mantém o poder de controle sobre o projeto, podendo cancelar o projeto ou fazer mudanças orçamentarias. A comunicação deve ser focada e com bastante relatórios de progresso.

Manter Informados: Normalmente a equipe que ficara a mercê do sistema. Eles não tem poder real sobre o destino do projeto mas mantê-los informados e ouvir suas opiniões aumenta a chance de sucesso na adaptabilidade do projeto. Comunicação mais resumida e focada em funcionalidades.

Monitorar: Acompanhamento passivo com informações mais básicas sob demanda.

O professor atua como avaliador porque não esta interessado apenas no resultado final do projeto, ou seja, no produto, mas sim também esta interessado no processo e na forma como tudo foi feito por trás dos panos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A fórmula de comunicação modela as arestas de um grafo e não a quantidade de subgrupos possíveis. Pela formula quando temos 4 participantes temos um total de 6 conexões, mas quando aumentamos para 10 subimos para 45 conexões, um aumento grande. Comunicação síncrona se refere a comunicações em tempo real com resposta imediata, como uma reunião, já á comunicação assíncrona se refere a uma comunicação com tempo de resposta maior, podendo variar o prazo dependendo da situação, como uma issue ou um comentário. As decisões devem migrar para o modo assíncrono quando envolver mudanças em estados já predefinidos e que podem mudar o produto.

Como o projeto constitui de 3 membros e 1 professor ele possui 6 canais de conexão. Para evitar problemas futuros o grupo decidiu usar mensagens por whatsapp e o gitlab como forma de realizar a comunicação assíncrona e manter a rastreabilidade das decisões.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 EMMANUEL DINIZ CH. (Matrícula: 20213005843, Login: @EmmanuelD1)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve explicar que o Professor Agente é uma ferramenta de apoio e não uma fonte infalível. Ele pode produzir informações incorretas, variar a resposta para perguntas semelhantes, sofrer com latência, ficar temporariamente indisponível ou atingir a cota da API.

Essas limitações devem aparecer no README, na interface e nas demonstrações. Também deve ficar claro que o sistema orienta o raciocínio, mas não entrega código completo, não substitui o professor, não funciona como juiz online e não garante que uma solução esteja correta. Respostas importantes devem ser verificadas pelo aluno.

Para o Check 02, o estado atual das quatro evidências é:

EAP e cronograma rastreável: estão em docs/EAP.md e nas Issues distribuídas entre os quatro Milestones do semestre.
Responsabilidades: os papéis estão na tabela da equipe no README.md, e as responsabilidades aparecem nas Issues atribuídas. Essas informações ainda precisam ser consolidadas em uma Matriz RACI formal.
Riscos: os riscos iniciais e suas mitigações estão em docs/PROJECT_CHARTER.md, e o tratamento de indisponibilidade e limites está planejado na Issue #12. Ainda precisamos transformar isso em uma Matriz de Probabilidade e Impacto com responsável e contingência.
Stakeholders: o professor, os estudantes e o provedor ou administrador da infraestrutura já foram identificados. Ainda precisamos registrar formalmente a Matriz de Poder e Interesse no repositório.

Portanto, antes do Check 02, devemos criar ou consolidar no repositório:

docs/RACI.md;
docs/RISCOS.md;
docs/STAKEHOLDERS.md;
uma ADR sobre a decisão de utilizar Streamlit com um backend FastAPI.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O tratamento de um conflito começa deixando claro qual é o problema, sem atacar pessoas. Depois, cada integrante apresenta seus interesses, restrições e evidências. A decisão deve ter um responsável e critérios objetivos. Por fim, o resultado e seus impactos devem ser registrados para que a discussão não precise ser refeita.

As cinco posturas são:

Colaborar: buscar uma solução que atenda aos interesses das duas partes. É a melhor opção para decisões importantes.
Conceder: cada lado abre mão de parte da preferência para chegar a um acordo possível.
Forçar: uma pessoa responsável toma a decisão. Pode ser legítimo em uma emergência de segurança, como revogar imediatamente uma chave exposta.
Apaziguar: destacar pontos de concordância e reduzir temporariamente a tensão, preservando a relação.
Evitar: adiar a discussão quando o assunto tem pouca prioridade ou ainda não existem dados suficientes para decidir.

Um dilema real do TheSurvivors é decidir se o Streamlit deve chamar a Gemini diretamente ou se toda comunicação deve passar por um backend FastAPI. A chamada direta é mais rápida de desenvolver, mas mistura interface, credenciais e regras pedagógicas. O backend separado exige mais integração, porém melhora a segurança, a manutenção e os testes.

A discussão deve ocorrer nas Issues de desenvolvimento da interface, integração e serviço backend. Cada alternativa deve ser apresentada com vantagens, riscos e impacto no prazo. A decisão escolhida é manter a interface separada do serviço FastAPI.

O debate deve se concentrar na solução, evitando frases pessoais como “seu código está errado”. Depois da decisão, o resultado deve ser registrado em uma ADR e vinculado às Issues e Merge Requests correspondentes.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Alinhamentos verbais não são suficientes porque pessoas diferentes podem interpretar nomes, tipos, unidades e formatos de maneiras distintas. Um contrato explícito define campos obrigatórios, tipos de dados, unidades, códigos de erro e versões. Os testes automatizados verificam se os dois lados continuam respeitando esse contrato depois de uma alteração.

No TheSurvivors, a fronteira mais suscetível a erros é a comunicação entre a interface Web, o backend e a API Gemini. A interface precisa enviar a dúvida, o trecho de código e o contexto no formato esperado. O backend precisa converter essas informações para a chamada da Gemini e devolver texto ou erro de maneira previsível.

No estágio atual, o contrato com a Gemini é documentado e validado por:

.env.example, que define GEMINI_API_KEY e o modelo;
requirements.txt, que informa a dependência usada na integração;
src/test_api.py, que realiza a chamada, verifica a chave e trata respostas vazias ou exceções;
.gitlab-ci.yml, que compila o código e executa a validação offline do spike;
README, que explica como configurar e executar o teste.

O próximo passo para a integração Streamlit–FastAPI é definir schemas Pydantic para requisição, resposta e erro. O FastAPI poderá gerar o contrato OpenAPI/Swagger automaticamente, enquanto testes no pipeline verificarão se a interface e o backend continuam usando os mesmos campos. Esse contrato formal ainda precisa ser implementado no Módulo 2.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

As estratégias da Matriz de Poder e Interesse são:

Gerenciar de perto: stakeholders com alto poder e alto interesse. Devem participar das decisões e receber atualizações frequentes.
Manter satisfeitos: possuem alto poder, mas pouco interesse no acompanhamento diário. Devem receber informações importantes, sem excesso de detalhes.
Manter informados: possuem baixo poder, mas alto interesse. Precisam acompanhar o progresso e fornecer feedback.
Monitorar: possuem baixo poder e baixo interesse. O acompanhamento pode ser eventual.

O professor não é um cliente comercial porque ele não está contratando o produto nem avaliando retorno financeiro ou satisfação de mercado. Ele atua como avaliador de conformidade acadêmica. Por isso, devemos entregar evidências ligadas à rubrica, como documentos versionados, Issues, Milestones, commits, revisão por Merge Request, pipeline e participação da equipe.

No TheSurvivors, o mapa inicial possui estes stakeholders:

Professor avaliador — Gerenciar de perto: possui alto poder sobre a avaliação e interesse no cumprimento da disciplina. A comunicação ocorre nas aulas e por marco, usando o GitLab, os documentos, as Issues e as Merge Requests como evidência oficial.
Estudante de programação ou competidor — Manter informado: possui alto interesse no Professor Agente, mas pouco poder administrativo sobre o projeto. Deve receber demonstrações e participar de validações a cada protótipo ou sprint. O feedback deve ser registrado em Issues.
Provedor Gemini ou administrador da infraestrutura — Manter satisfeito: possui grande poder sobre a disponibilidade da API e do ambiente, mas pouco interesse nas decisões diárias da equipe. Devemos acompanhar a documentação, os limites e o status antes de cada marco ou apresentação. Falhas devem ser registradas na Issue de integração e tratamento da API.

Esse posicionamento deve ser revisto se algum stakeholder passar a controlar novos recursos, requisitos ou riscos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A quantidade de canais cresce de forma quadrática porque cada participante pode se comunicar diretamente com todos os outros, mas cada par deve ser contado apenas uma vez. Por isso, usamos C = N(N−1)/2.

Com 4 participantes:

C = 4 × 3 / 2 = 6 canais.

Com 10 participantes:

C = 10 × 9 / 2 = 45 canais.

O número de participantes aumentou 2,5 vezes, mas os canais passaram de 6 para 45. O crescimento não é exponencial porque cada novo participante acrescenta uma quantidade linear de novos pares, em vez de multiplicar repetidamente todos os resultados anteriores.

A comunicação síncrona acontece em tempo real, como em reuniões, chamadas ou conversas presenciais. Ela é adequada para urgências, dúvidas rápidas e discussões que precisam de resposta imediata. A comunicação assíncrona acontece sem exigir que todos estejam disponíveis ao mesmo tempo, como em Issues, Merge Requests e ADRs.

Decisões de arquitetura, alterações de requisitos, divisão de responsabilidades, aprovação de código e mudanças que afetam o escopo devem ser registradas de forma assíncrona. Se ficarem somente no WhatsApp, não existe histórico confiável, justificativa ou ligação com o código alterado.

No TheSurvivors, temos quatro integrantes e consideramos como principais interlocutores externos o professor avaliador, um representante dos estudantes que usarão o assistente e o responsável pela infraestrutura/API. Assim, temos sete participantes principais:

C = 7 × 6 / 2 = 21 canais.

Nossa política é usar o WhatsApp apenas para avisos rápidos e combinação de horários. Toda decisão que alterar código, arquitetura, requisito ou prazo deve ser registrada na Issue correspondente, discutida na Merge Request e, quando for uma decisão arquitetural importante, resumida em uma ADR. No chat deve ficar apenas o link para a fonte oficial, evitando conversas duplicadas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟠 EVELYZE PINHEIRO. (Matrícula: 20213012374, Login: @evelyze)

Progresso: 4 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

1. Comunicar e gerenciar as limitações dos LLMs

Uma demo rápida mostra o melhor caso, não o comportamento real. A equipe deve deixar claro, por escrito e antes de o usuário depender do bot, o que ele faz e o que não faz:

Escopo explícito: documentar no README e na mensagem de boas-vindas que o assistente guia o raciocínio com perguntas (abordagem socrática) e não entrega código pronto, não garante resposta correta e não substitui o professor ou o juiz da competição.
Alucinações: avisar que as respostas podem conter erros e devem ser verificadas; o bot deve admitir incerteza e recusar o que estiver fora do escopo.
Latência de rede: informar que há tempo de resposta variável e exibir indicador de “processando”, com timeout e mensagem de erro amigável.
Custos de cota: declarar limites de uso por usuário e o comportamento ao atingir a cota (aviso claro, sem falha silenciosa).
Variações probabilísticas: explicar que a mesma pergunta pode gerar respostas diferentes; reduzir isso com prompts estruturados e temperatura controlada.
Demonstrar também os limites: incluir na demo casos de falha e de recusa, e manter uma lista de limitações conhecidas e requisitos não funcionais testados (Issues), em vez de prometer “responde tudo”.
Comunicar por marcos: alinhar o que será entregue em cada versão no changelog, para que o protótipo não seja confundido com o produto final.

2. Evidências de gestão para o Check 02

Evidência	Conteúdo	Onde encontrar (ajustar ao repositório)
EAP/WBS e cronograma	Decomposição das entregas e prazos rastreáveis	Milestones e Issues vinculadas; `docs/` ou Wiki
Matriz RACI	Responsabilidades por entrega (quem executa, aprova, é consultado e informado)	Wiki ou `docs/gestao/`
Matriz de Riscos	Riscos, probabilidade, impacto e plano de contingência	Wiki ou `docs/gestao/`, com Issues de risco rotuladas
Matriz de Stakeholders	Poder vs. interesse, cadência e canal oficial (professor avaliador, usuário competidor, administrador da API)	Wiki ou `docs/gestao/`

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

1. Ciclo de tratamento e posturas situacionais

O conflito sinaliza incerteza, restrição ou visões diferentes sobre o projeto. Tratá-lo bem significa debater o problema, não a pessoa, seguindo quatro etapas:

Explicitar o problema: descrever o desacordo de forma neutra e verificável (“a consulta leva 3 s com SQLite”), e não como crítica a alguém.
Ouvir interesses e evidências: entender o que cada lado quer proteger (prazo, custo, qualidade) e apoiar os argumentos em dados, testes ou documentação.
Decidir com responsabilidade: definir quem decide e com que critério, assumindo a escolha mesmo com discordância residual.
Registrar o impacto: documentar a decisão, o motivo e as consequências (em ADR ou Issue), para que ela não seja rediscutida nem esquecida.

As 5 posturas:

Colaborar: busca uma solução que atenda aos interesses de todos. Ideal para decisões importantes e complexas, quando há tempo.
Conceder (compromisso): cada lado cede em parte. Útil quando o prazo é curto e uma solução “boa o bastante” basta.
Forçar: impor uma decisão. É legítimo em emergências de segurança (vazamento de chave de API, falha crítica em produção), porque o custo de debater supera o de errar e é preciso agir rápido. Deve ser exceção, explicada e registrada depois.
Apaziguar (acomodar): ceder para preservar a relação. Serve quando o assunto é pouco relevante, mas, em excesso, esconde problemas reais.
Evitar: adiar ou não entrar no conflito. É prudente quando faltam dados, pois decidir sem evidência é pior que esperar; o correto é adiar com prazo e responsável definidos (por exemplo, fazer um experimento antes). Evitar por medo ou desconforto, porém, é omissão.

O dilema foi sobre a divisão de tarefas do Check 02: como distribuir entre os 4 membros o trabalho de backend, integração com a API de LLM/Gemini, interface (Telegram/Web), testes e documentação. As visões divergentes envolviam dois critérios legítimos: dividir por especialidade (cada um faz o que domina, entrega mais rápido, mas concentra conhecimento em uma pessoa) ou por fatias verticais (cada um entrega uma funcionalidade completa, o que distribui o aprendizado, mas pode atrasar e gerar retrabalho). Havia ainda a preocupação com carga desigual e dependências entre as tarefas.

Como a discussão deve ocorrer nos comentários do GitLab

Explicitar o problema na Issue: abrir uma Issue “Divisão de tarefas do Check 02” com o objetivo, o prazo, a lista de entregas e os critérios de decisão (carga equilibrada, dependências, prazo, aprendizado do grupo). O foco é a divisão, não quem errou ou acertou.
Ouvir interesses e evidências: cada membro comenta o que prefere fazer e o que quer proteger (prazo, nota, aprendizado), com dados concretos, como estimativa de esforço e dependências entre tarefas, em vez de “eu acho”.
Linguagem sobre o trabalho, não sobre a pessoa: “essa divisão deixa o backend sobrecarregado” em vez de “fulano não está fazendo sua parte”. Perguntas antes de objeções (“quanto tempo você estima para essa parte?”) mantêm a segurança psicológica.
Decidir com responsabilidade: definir antecipadamente quem fecha a decisão (consenso ou, na falta dele, o responsável pela coordenação). Se faltarem dados, adiar conscientemente com prazo curto, por exemplo, estimando as tarefas antes de fechar.
Registrar o impacto: atribuir cada tarefa como Issue com responsável, prazo e critério de aceite, em um quadro (board), e anotar na Issue principal o motivo da escolha e quando a divisão será revisada (por exemplo, se alguém ficar bloqueado).
Fechar o ciclo: quem teve a proposta não escolhida segue colaborando, e a decisão passa a ser do time, não de uma pessoa.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

1. Por que contratos explícitos e testes automatizados

Alinhamentos verbais falham porque:

Suposições implícitas não são visíveis. Cada equipe acredita que o que é óbvio para ela é óbvio para a outra.
A memória é volátil. A conversa não deixa registro, não é versionada e se perde com a troca de pessoas.
O erro surge só na integração. Cada parte passa nos próprios testes; a falha aparece apenas quando os módulos se encontram, muitas vezes tarde e a um custo altíssimo.

Um contrato explícito (formato, tipos, unidades, limites, erros esperados) transforma a suposição em especificação única e consultável. Um teste automatizado de contrato e integração transforma a especificação em verificação contínua: qualquer quebra é detectada no CI/CD, e não em produção. Assim, a confiança deixa de depender de “combinamos por conversa” e passa a depender de evidência executável.

2. A interface verificável do Assistente I.A.

Fronteira mais suscetível a erros. O ponto mais crítico é a comunicação entre o backend do bot e a API de LLM (Ollama), pois a resposta do modelo é não determinística e pode vir fora do formato esperado (JSON malformado, campos ausentes, texto extra). A segunda fronteira sensível é Telegram/Web → backend, onde mensagens chegam com formatos, tamanhos e tipos variados (texto, código, anexos, caracteres especiais).

Como blindar o contrato:

Schemas Pydantic para validar toda entrada e saída: tipos, campos obrigatórios e limites, rejeitando dados inválidos logo na fronteira.
Contrato OpenAPI/Swagger gerado e versionado no repositório, descrevendo endpoints, payloads e códigos de erro do backend.
Saída estruturada do LLM (JSON com schema definido no prompt) e validação da resposta antes de enviá-la ao usuário, com tratamento de falha e fallback.
Testes de contrato e integração com respostas simuladas (mocks) da API do Ollama, cobrindo casos válidos, malformados, vazios e timeouts.
CI/CD executando esses testes a cada Merge Request, bloqueando a integração caso o contrato seja quebrado.
Decisões de interface registradas em ADR, para que mudanças no contrato fiquem rastreáveis.

Dessa forma, a “unidade de medida” do projeto (formato, tipo e significado dos dados) fica documentada e verificada, e não apenas combinada de boca.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O crescimento é quadrático (O(N²)) e não exponencial porque cada canal é um par de pessoas. Cada uma das N pessoas pode se conectar às outras N−1, e como a conversa A->B é a mesma que B->A, divide-se por 2. Na fórmula aparece N elevado a uma potência fixa (2), e não uma potência com N no expoente (2ᴺ), como seria se contássemos todos os subgrupos possíveis.

Na prática:

N = 4: C = 4 × 3 / 2 = 6 canais
N = 10: C = 10 × 9 / 2 = 45 canais

A equipe cresceu 2,5 vezes, mas os canais cresceram 7,5 vezes. Cada nova pessoa traz mais pontos de falha, mais chances de informação desencontrada e mais conversas paralelas que ninguém consegue acompanhar por inteiro.

Síncrono vs. assíncrono

Síncrono (reunião, chamada, chat em tempo real) exige que todos estejam disponíveis ao mesmo tempo. Tem feedback rápido e é ótimo para alinhar dúvidas simples e destravar impedimentos, mas é efêmero, difícil de auditar e não escala.

Assíncrono (Issues, Merge Requests, ADRs) permite resposta no tempo de cada um. É mais lento, porém deixa registro permanente, pesquisável e com autoria, e permite que quem entrar depois entenda o contexto.

A decisão deve migrar obrigatoriamente para o assíncrono quando:

Afetar a arquitetura, o escopo, contratos de API ou dependências (registrar em ADR).
Envolver mudança de código que precise de revisão e aprovação (Merge Request).
Definir requisito, bug ou tarefa que alguém vai executar depois (Issue).
Envolver mais de duas pessoas, ou pessoas em fusos/horários diferentes.
Precisar ser justificada ou consultada no futuro (rastreabilidade).

O chat serve para avisos e dúvidas rápidas. Se uma conversa gerou uma decisão, ela deve ser transcrita para o repositório.

2. Regra de fluxo do time (Assistente I.A.)

Cálculo dos canais diretos: equipe de 4 membros + 1 professor (interlocutor externo) = N = 5.

C = 5 × 4 / 2 = 10 canais diretos

(Só entre os 4 membros seriam 6 canais; a inclusão do professor adiciona 4 canais, um com cada integrante, elevando o total para 10.)

Política assíncrona sugerida:

Toda tarefa nasce como Issue, com responsável, critério de aceite e rótulo.
Toda alteração de código passa por Merge Request, com no mínimo uma revisão, vinculada à Issue correspondente.
Decisões arquiteturais viram ADR (contexto, decisão, consequências), versionada na pasta /docs/adr.
O chat não é fonte de verdade: decisões tomadas lá devem ser registradas na Issue ou ADR em até 24 horas, com link de volta.
Um único canal por assunto: a discussão acontece na Issue/MR correspondente, evitando conversas duplicadas; o chat só recebe o link.
O professor interage preferencialmente por meio de um ponto focal da equipe e dos registros no repositório (Issues, MRs e ADRs), o que reduz os canais diretos ativos de 10 para 6 (apenas entre os membros) mais um canal único com o professor.

Assim a rastreabilidade é mantida, e a sobrecarga cai porque cada informação tem um único lugar de registro.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

🟢 FILLIPE TOMAZ CAR. (Matrícula: 20233004600, Login: @Fillipe)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Deixar claro aos alunos que uma IA Generativa pode conter erros, então, deve se ter discernimento para que as informações estejam corretas após a geração da resposta.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Tudo começa com a explicação do problema que está ocorrendo no software, depois, temos que procurar sugestões de dicas para como resolver a pendencia, depois de juntar as sugestões, pensando nas melhores ideias para ser inseridas para a resolução, e por fim, aplica-las de maneira correta.

Colaborar: investigar alternativas. Conceder: acordo aceitável quando prolongar custa mais. Forcar: decisão autorizada, por exemplo em incidente. Apaziguar: enfatizar concordâncias ou ceder com impacto explicito. Evitar: adiar para obter dados ou reduzir tensão, definindo retorno.

Em casos onde o tempo de resolução é curto, forçar uma ideia é importante visto que não há tempo de analisar com precisão o que está ocorrendo, e assim começa a “correria”, mas em casos menos urgentes, mas que não há dados, é melhor evitar algumas ações que possa quebrar o software.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Pois o software pode se transformar numa enorme colcha de retalhos, onde cada função vai ficar deslocada da outra, causando assim a falta absurda de unidade.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Manter satisfeitos: alto poder, baixo interesse

Monitorar: baixo poder, baixo interesse

Gerenciar de perto: alto poder, alto interesse

Manter informados: baixo poder, alto interesse

A função do professor é avaliar os conceitos técnicos e os detalhes dos softwares que seus alunos o entregaram, já o cliente, ele só quer que seu software funcione.

_______________

Professor Avaliador: Gerenciar de perto

Aluno: Manter Informados

Diretores: Manter satisfeitos

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Quando o valor de 4 para 10 membros, o valor de pares aumenta de 6 para 45, isso aumenta ainda mais a informação lançada no chat, aumentando ainda mais a chances de uma informação importante se perder no meio de tantas mensagens lançadas por outros membros do grupo. Fizemos o grupo do WhatsApp entre os quatro membros do grupo, mas isso é devido a quantidade de pares serem totalmente controláveis para nós.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 GABRIEL ALVARENGA. (Matrícula: 20243001694, Login: @gLx)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

o efeito demonstração cria a falsa esperança de que o protótipo inicial já é perfeito e para controlar isso a equipe precisa colocar avisos claros na interface informando aos alunos sobre as possíveis alucinações e os limites exatos do que o assistente consegue responder. para o fechamento do check dois nesta aula nós organizamos as evidências obrigatórias de gestão para mostrar que estruturamos tudo direito antes de codar. já deixamos prontas a eap com o cronograma rastreável nos milestones e a matriz raci para divisão justa de tarefas além da matriz de riscos e a matriz de stakeholders que estão salvas e acessíveis direto nos arquivos markdown e na wiki do nosso repositório no gitlab

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

para resolver atritos a equipe precisa primeiro explicitar o problema e ouvir as evidências de todos para depois decidir e registrar o impacto sem levar para o lado pessoal usando posturas como forçar que é útil numa emergência de segurança ou evitar que salva tempo quando faltam dados. as outras posturas como colaborar e apaziguar ajudam a manter a paz dependendo da urgência do conflito e do nível de estresse da galera. no nosso projeto já tivemos atrito sobre usar sqlite comum ou banco vetorial para o assistente e conduzimos isso criando uma issue técnica no gitlab onde cada lado colocou os prós e contras focando na arquitetura e não em opiniões pessoais o que garantiu a segurança psicológica e virou uma documentação oficial.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

o desastre da sonda de marte prova que alinhamentos verbais não funcionam em sistemas complexos porque cada equipe assume um padrão diferente e na hora de integrar os dados tudo quebra exigindo contratos de interface explícitos e testes automatizados que validem as informações antes do código ir para produção. no nosso assistente a fronteira mais perigosa de comunicação fica entre o nosso backend e a resposta probabilística da api do modelo de linguagem porque a ia pode retornar qualquer texto fora do padrão. para blindar isso nossa equipe definiu o uso de schemas validando rigidamente o json no backend para que qualquer resposta fora do contrato seja rejeitada por testes automatizados no ci cd antes mesmo de chegar na tela web do usuário

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

na matriz de stakeholders quem tem alto poder e alto interesse deve ser gerenciado de perto enquanto pessoas com alto poder e baixo interesse são mantidas satisfeitas e quem tem baixo poder mas alto interesse é apenas mantido informado. o professor age como um avaliador de conformidade acadêmica e não como um cliente comercial porque ele precisa ver as evidências metodológicas no gitlab como testes e documentação e não apenas um robô funcionando. mapeando nosso projeto o professor fica em gerenciar de perto acompanhando cada marco pelo repositório enquanto os alunos do cefet ficam em manter informados sobre as novidades do bot e a equipe de infraestrutura fica em manter satisfeitos recebendo avisos se precisarmos de algum servidor

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

o crescimento de canais de comunicação é quadrático porque cada nova pessoa precisa se conectar com todas as outras formando uma teia onde quatro pessoas geram apenas seis canais mas dez pessoas já causam quarenta e cinco conversas cruzadas. a comunicação síncrona como o chat é boa para alertas rápidos mas péssima para manter histórico e por isso toda decisão importante do projeto precisa migrar para o modo assíncrono no gitlab através de issues e adrs. no nosso projeto do assistente considerando o time e o professor somamos uns seis membros gerando quinze canais diretos e a nossa política oficial é que todo debate sobre a api do gemini ou arquitetura comece como uma issue no repositório para centralizar a rastreabilidade e evitar conversas duplicadas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟠 GABRIEL CAMPOS MA. (Matrícula: 20243008185, Login: @gabrielcm)

Progresso: 4 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Para gerenciar e comunicar as expectativas dos stakeholders sobre as limitações das LLMs, é necessário adotar uma abordagem proativa, transparente e baseada em métricas, de forma que possa-se traduzir as limitações técnicas em impactos de negócio e gerenciar o risco.

O meu grupo preparou o cronograma rastreável em milestones, a matriz RACI de responsabilidades, matriz de riscos e matriz de stakeholders, porém ainda não estão disponíveis no gitlab.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

A dependência de alinhamentos verbais para interfaces técnicas cria vulnerabilidades criticas em projetos, assim como foi citado no texto acima, logo, ao utilizar contratos explícitos e testes automatizados garante-se a mitigação de riscos, garante a integridade do produto e assegura a eficiência operacional.

A fronteira mais suscetível a erros de comunicação entre os dados é a interface do telegram e/ou da API do modelo LLM, pois, como cada um deles depende de um servidor externo aos desenvolvedores do projeto, qualquer erro nessas empresas terceiras afeta o produto final.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

As estratégias de comunicação para os 4 quadrantes: Gerenciar de perto, o objetivo é engajar ativamente e garantir a total satisfação, pois são os principais tomadores de decisão, essa é uma abordagem de comunicação bidirecional. em que envolve-se nas decisões críticas, valida as premissas e mitiga os riscos rapidamente.

Manter satisfeitos, o objetivo é evitar que se tornem barreiras ao projeto, atendendo às suas necessidades sem sobrecarregá-los com detalhes. Como abordagem utiliza-se uma comunicação focada em resultados de alto nível e conformidade, garantindo que saibam as regras que estão sendo seguidas.

Manter informados, o objetivo é aproveitar o entusiasmo e a colaboração, mantendo-os cientes do progresso para que possam ajudar na execução, essa abordagem é utilizada pois tem-se uma comunicação transparente sobre o andamento, desafios enfrentados e lições aprendidas.

Monitorar, o objetivo é acompanhar passivamente para notar se o nível de interesse ou poder muda ao longo do tempo, essa abordagem utiliza da comunicação unidirecional e minimalista, para que não gaste energia excessiva.

O professor da disciplina atua como uma avaliador de conformidade acadêmica e não como uma cliente comercial, pois o professor precisa analisar as nuances de como o projeto foi desenvolvido enquanto o cliente apenas espera a funcionalidade do projeto. 2. Professor Avaliador

Posicionamento na matriz: Alto impacto / Monitoramento estratégico

Cadência de comunicação: por milestone do projeto utilizando o SIGAA

Justificativa: Precisa acompanhar a evolução pedagógica e técnica do projeto

Colegas de Equipe

Posicionamento na Matriz: Alto impacto / Gestão Direta e Colaborativa.

Cadência de Comunicação: Diária

Canal Oficial: Discord/Teams (para reuniões rápidas) e GitHub (issues, pull requests e kanban integrado).

Justificativa: Como o desenvolvimento de um Assistente de I.A. exige integração constante entre front-end, back-end e engenharia de prompt/modelagem, a comunicação diária é vital para alinhar o código, resolver impedimentos (blockers) e dividir tarefas de forma ágil.

Usuário Final Competidor

Posicionamento na Matriz: Alto interesse / Validação de Escopo.

Cadência de Comunicação: Semanal

Canal Oficial: Formulários de feedback (Google Forms/Typeform) e sessões breves de testes de usabilidade (User Testing).

Justificativa: Para garantir que a I.A. realmente resolva as dores do competidor (ex: explicando algoritmos complexos de forma clara), o feedback semanal ajuda a validar se o assistente está entregando respostas úteis, precisas e no tom correto antes de avançar para a próxima funcionalidade.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O número de canais é considerado quadrático por causa da Lei de Metcalfe, em que, um número N de pessoas pode se comunicar com um número N - 1 de outras pessoas, e como elas estão conversando pelo mesmo canal, divide-se por dois a conta final, dessa forma chegando na fórmula apresentada. E esse crescimento é quadrático pois cada pessoa sempre traz no mínimo o mesmo número de pessoas que já tinha nesse mesmo canal, nunca duplicando ou triplicando o número de pessoas. Usando o exemplo de 4 e 10 pessoas, teríamos essa diferença de canais:

Canal = (4 * 3) / 2 = 6

Canal = (10 * 9) / 2 = 45

Uma diferença de 39 canais no total.

A diferença entre a comunicação síncrona e assíncrona está em como a informação se passa entre as pessoas, enquanto a síncrona requer a presença de todos os participantes, a assíncrona apenas necessita que a informação seja passado, permitindo que o ouvinte leia a informação quando necessário. Normalmente é utilizado a comunicação assíncrona quando a equipe cresce e as informações vão se perdendo, para isso é utilizado ferramentas assíncronas para permitir que decisões de arquiteturas e projeto estejam sempre bem definidas e quando necessário mudar, a informação passe por todas as pessoas envolvidas. 2. Canais = (4 * 3) / 2 = 6 canais no total. Nossa equipe definiu uma política de comunicação assíncrona de forma que fica proibido alinhar decisões de escopo em conversas diretas (DM) ou chats gerais. Discussões de refinamento devem acontecer estritamente dentro da Issue correspondente ou no card do repositório, garantindo o histórico para futuros membros da equipe.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

🟢 GABRIEL PINHEIRO. (Matrícula: 20243000884, Login: @gabriel_pinheiro067)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

1- Para conter o efeito demonstração, é necessário que a equipe gerencie as expectativas dos stakeholders comunicando de forma direta e precisa que um mero protótipo não exclui o fato de que, para chegar a um produto final preciso e correto, necessita-se de passar por todo um projeto de desenvolvimento que siga pontualmente todas as etapas de gestão e desenvolvimento de um projeto de engenharia. Esta comunicação deve ser feita apresentando dados reais dos testes feitos junto da exposição de todas as limitações que a API possui. Ja para que que o usuário entenda com clareza o que o bot faz ou não, é necessário expor diversos avisos na inferface de interação com o usuário do bot todas as limitações do software em si, além também das regras e de toda a blindagem feita no backend para garantir que o bot se comporte como esperado.

2- Até o momento, meu grupo construiu todas as Issues e Milestones seguindo perfeitamente a EAP do projeto associando sempre o responsável pela Issue, o revisor da mesma e o cronograma de entrega de acordo com o Milestone que pertence. Tal ação evidencia a EAP e seu cronograma rastreável e a definição dos responsáveis que estarão presentes na matriz RACI. Continuamente, a matriz de RACI construída, a matriz de riscos com planos de contingência e a matriz de stakeholders serão inseridos como documentos do projeto e ficarão visíveis na pasta “docs” junto com o documento EAP e nas Issues cadastradas durante todo o projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

1- Explicitar o problema: Definir de forma clara qual é o problema a ser resolvido focando sempre em pontuar o que é fato e importante sobre ele;

Ouvir interesses e evidências: Coletar todos os possíveis argumentos que possuam base teórica e fundamentos do projeto;

Decidir com responsabilidade: Definir qual o caminho a ser seguido baseando-se nos critérios do projeto, tal decisão só pode ser tomado pelo responsável direto do projeto;

Registrar Impacto: Documentar o resultado final e todas as consequências do problema, desde identificação dele até a resolução final garantindo rastreabilidade para a equipe.

Colaborar: A equipe busca a raiz e acha a solução ideal;

Conceder: Cada indivíduo cede um pouco de seu tempo e esforço para a solução. Rápido, porém pode gerar soluções sub-ótimas. Acordo realizado quando prolongar custa mais;

Forçar: Uma autoridade impõe uma decisão. Essencial em casos de emergências ou falhas de segurança onde o tempo de reação é crítico sem tempo para discussões;

Apaziguar: Focado em manter a concordância geral da equipe evitando decisões onde há divergências a fim de manter a paz e o andamento do grupo como um todo;

Evitar: Adiar a discussão entre o equipe a fim de focar em partes mais urgentes ou para dar mais prazo de coleta de informações sobre a problemática. É necessário definir uma data limite para retorno das discussões.

2- No monitor socrático, tal discussão poderá ser realizada no momento de dividir as tarefas do check 2 onde debateremos via grupo do WhatsApp sobre quem ficará com cada parte da demanda atual. No caso citado a melhor abordagem seria a de colaborar de forma que juntos possamos definir quem ficará com o que e traduzir isso para o GitLab diretamente usando Issues atribuídas a cada responsável no repositório. Desta forma a conclusão inteira do debate será visível no GitLab garantindo assim rastreabilidade do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

1- Interfaces técnicas entre subsistemas desenvolvidos por pessoas diferentes exige contratos explícitos que funcionem como fonte única e oficial de comunicação entre as pessoas e testes automatizados que verifiquem continuamente se o contrato está sendo seguido de forma correta e barrando qualquer erro de incompatibilidade entre os projetos pois manter qualquer integração entre sistemas de forma unicamente verbal não garante em nada que os sistemas internamente sejam compatíveis e funcionem como devem funcionar quando são operados de forma conjunta.

2- No monitor socrático, a fronteira mais suscetível a erros de comunicação é a interação entre backend e a API, visto que a resposta final é totalmente redigida em texto enquanto o backend trabalha diretamente com dados e variáveis separadas. Para blindar o contrato, podemos utilizar contratos OpenAPI/Swagger e validações de dados no backend junto de testes de contrato em CI/CD que garantam que se houver qualquer quebra da interface na parte do backend ou então nas respostas finais a serem exibidas para o usuário, estas serão bloqueadas pelo CI/CD antes mesmo de serem processadas e aplicadas no restante do código.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

1- Gerenciar de perto (Alto Poder + Alto Interesse): É o cliente/professor. Ele toma decisões e avalia constantemente o desenvolvimento. Necessita de comunicação constante e validações arquiteturais;

Manter satisfeitos (Alto Poder + Baixo Interesse): É a Coordenação. Não se importa com detalhes operacionais, mas pode limitar ou até cancelar o projeto. Exige envio de relatórios executivos concisos;

Manter informados (Baixo Poder + Alto Interesse): São os usuários finais. Usam o projeto como produto e não se importam com rumo orçamentário. Exige envio de release notes e tutoriais de como fazer uso do projeto;

Monitorar (Baixo Poder + Baixo Interesse): Exige esforço mínimo.

O professor atua como avaliador de conformidade acadêmica e não como um cliente comercial pois ele está mais interessado em avaliar e monitorar se os conceitos de gestão de projeto e de engenharia estão sendo aplicados corretamente durante todo o desenvolvimento do projeto e não em receber um protótipo do projeto já funcionando sem detalhamento algum sobre as etapas de seu desenvolvimento.

2- No projeto do monitor socrático, podemos ter 3 stakeholders reais: O professor, os alunos que usaram o assistente e os alunos que também estão desenvolvendo o mesmo projeto.

Professor: Gerenciar de perto, pois ele deve possuir meios de comunicação e monitoramento constantes do grupo via comunicação assíncrona dentro do repositório do projeto e na gestão e organização do mesmo via Issues, Merge Requests, etc;

Alunos usuários: Manter informados, pois tudo que interessam eles é acompanhar cada release feito e interagir via feedbacks ou testando o projeto;

Alunos de outros grupos: Monitorar, pois apenas acompanham o projeto totalmente de fora através de apresentação do projeto e conversas informais com os desenvolvedores.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

1- O crescimento é quadrático pois o números de canais entre N pessoas cresce proporcionalmente a N ao quadrado. Se eu tenho 4 pessoas, tem-se: [4(4-1)]/2 = [16-4]/2 = 6 canais de comunicação. Já para 10 pessoas, tem-se: [10(10-1)]/2 = [100-10]/2 = 45 canais. Desta forma fica perceptível que, aumentando a quantidade de pessoas para um pouco mais que o dobro, o número de canais aumenta para mais de 7 vezes o valor anterior.

Para lidar com este problema, é necessário separar o que é necessário comunicação síncrona e o que é comunicação assíncrona. Comunicação síncrona é uma interação imediata que pode ajudar em descoberta, negociação, urgência e/ou assunto sensível, porém quebram o flow da programação. Já comunicação assíncrona são focadas na distribuição do trabalho e rastreabilidade permitindo que o indivíduo trabalhe no seu tempo usando Issues, email e documentos. As decisões do projeto deve migrar obrigatoriamente para o modo assíncrono quando é necessário realizar ações que envolvam a arquitetura do projeto, revisões de código e rastreamento de erros.

2- Aplicando estes conceitos no projeto do monitor socrático considerando minha equipe com 3 integrantes e o professor como agente externo, tem-se:

C = [4(4-1)]/2 = 6 canais de comunicação.

Para evitar sobrecarga nos canais de comunicação, é necessário limitar o uso de chat apenas para avisos rápidos, deixando assim que quaisquer ações que envolvam diretamente a estrutura e desenvolvimento do projeto seja realizada em comunicação assíncrona em formato de Issue e Merge Request e documentos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 GABRYEL FERREIRA. (Matrícula: 20243004954, Login: @Gabryel)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Demonstrações mostram o que o produto faz, mas tem que ser mostrado e documentado as limitações do projeto para que os stackholders não sejam pego de surpresa pelo funcionamento do sistema.

No quadro de issues já tem algumas tarefas para dar inicio a programação e regras de negócio do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo é Explicitar o problema (deixar claro qual é o problema) -> Ouvir Interesses e Evidências (Escutar o dev por exemplo e ver se têm algo que confirme esse ponto) -> Decidir com responsabilidade (Considerar riscos, prazo, custo. Não com o coração ou facilidade) -> Registrar impacto é coordenar todo o processo.

As 5 posturas situacionais

Colaborar - É a ideal em um projeto que está fluindo bem e sem problemas, todo mundo conversa focando na melhor solução e alcançam um excelente resultado, isso requer altíssima maturidade da equipe.
Conceder - Cada lado cede um pouco mas no final não fica o melhor conjunto final.
Forçar - O Líder impõe sua ideia porque ele é o líder e arca com as consequências, é uma ótima prática em situações de crise, uma pessoa com mais experiência geralmente tende a tomar a melhor decisão e sabe lidar com elas.
Apaziguar - O gerente do projeto por exemplo cede para não quebrar a ligação do time, pena que no final pode das ruim e a cobrança terá que vir.
Evitar - É quando deixa a sujeira para frente e depois vê no que vai dar. Isso pode ser bom se não tiver total controle de alguma propriedade do sistema, pois se implementa de um jeito e depois tem que mudar é osso.

No GitLab não tivemos nenhuma conversa sobre alguns pontos do trabalho, mas no inicio do projeto ficamos em duvida sobre uma pagina web ou telegram mas decicidimos conversando e pesquisando e documentamos as escolhas em documentos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Basicamente contratos explícitos e testes automatizados reduzem a dependência de alinhamentos verbais, tornando as expectativas entre equipes documentadas, verificáveis e detectáveis automaticamente quando são violadas. Se ficar apenas na troca de informações boca a boca isso pode se perder e não ser implementado de forma correta fora que não saberá quem é o errado da situação.

Uma falha no nosso sistema poderia ser o idioma reconhecido pelo BackEnd e o que a API espera, vamos configurar de alguma forma para que seja reconhecido do jeito que for ou uma tradução.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

FIZ BONITINHO MAS PERDI TUDO

Gerenciar de Perto, são os donos do projeto (PO, Patrocinador) eles tem o poder de cancelar o projeto. Eles requerem comunicação massiva. ALTO PODER + ALTO INTERESSE.

Manter Satisfeitos, podem ser referidos a por exemplo a empresa que está desenvolvendo o projeto, tipo a diretoria da empresa, eles tem alto poder mas não ligam para detalhes técnicos querem apenas saber se não está extrapolando custo ou infringindo alguma lei.

Manter Informados, publico alvo do projeto, eles não mandam em nada, só querem usar o produto, mantenham os informados com noticias em alguma rede social de informação da empresa.

Monitorar, público não alvo apenas monitore-os para caso o interesse deles mude repentinamente.

MATRIZ - PODER versus INTERESSE

Alunos = Alto Interesse + Baixo poder -> macro
Concorrentes = Baixo Poder + Baixo Interesse -> zero
PO = Alto poder + Alto interesse -> Comunicação Massiva

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Os canais de comunicação crescem na proporção quadrática pelo fator de maior grau da expressão e ao número de pessoas pelo fato da comunicação está relacionada aos pares de pessoas da equipe, e jogando na formula chegamos aos seguintes valores, de 4 para 10 pessoas, a equipe aumentou 2,5 vezes em quando a quantidade de canais de comunicação aumentaram 7,5 vezes.

A comunicação Assíncrona é quando ela não é feita em reuniões e chamadas, ou seja, a comunicação é estabelecida em algum canal de comunicação corporativo, como GitLab; Teams; E-mail; entre outros. A comunicação Síncrona é a famosa reunião. Algumas situações devem ser tratadas e acompanhadas de forma assíncrona porque falar até papagaio fala, então o dev fala que vai fazer ‘x’ coisa hoje e entregar, mas de nada adianta não ter o acompanhamento no Git por exemplo que garante o versionamento, e monitoração de atividade.

O número de canais do nosso projeto integrador está em 6 contando com o professor. Nesse projeto temos duas fontes de comunicação, o GitLab, configurado para o rastreamento de tarefas e também o WhatsApp da equipe onde tomamos o maior cuidado para não exceder a conversa, apenas conversamos do que está sendo feito no momento. Mesmo que o WhatsApp não seja o ideal, nós usamos ele.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 ISAÍAS CÉSAR SAMP. (Matrícula: 20243006289, Login: @isaiascsl)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve deixar claro sobre as limitações inerentes dos LLMs, garantindo até que seja assinado um contrato ou termo de ciência diante dessas questões para que futuramente isso não acarrete em problemas.

Atualmente, nós temos:

EAP (eap.md)
Cronograma rastreável em milestones (na raiz do projeto)

Deverá ser adicionado:

Matriz RACI de responsabilidades
Matriz de Riscos com plano de contingência
Matriz de Stakeholders

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

ERxplicitar o problema é definir claramente qual é a divergencia. Ouvir interesses e evidências é entender o motivo de cada posição e comparar argumentos com requisitos dados, testes e riscos. Decidir com responsabilidade é escolhar uma solução e deixar claro qual foi a base que levou à essa conclusão. Registrar o impacto é documentar a decisão contendo justificativas e consequências.

Colaborar: a equipe busca a causa raiz e acha a solução ideal
Conceder: cada um cede um pouco buscando um meio-termo através da diplomacia
Forçar: o gerente usa autoridade para impor algo, essencial em emergencias, mas destroi a moral se for a regra
Apaziguar: focar nas áreas de concordância e recuar nas divergências para manter a paz

Não tivemos divergências relevantes na equipe do assistente de IA, mas ocorreu uma vez no estágio um pouco de scope creep em que o cliente pedia bastante coisa fora da área de atuação combinada e, como vinha junto às demandas eram, de fato, nossas, acabava acarretando em um desperdício de tempo, fazendo com que o projeto começasse a ficar inviável financeiramente para a equipe.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Interfaces sentre subsistemas desenvolvidos por equipes diferentes exigem contratos transparentes, pois alinhamentos verbais podem acarretar em perda de conhecimento com o tempo além de decisões incompletas. Os testes automatizados verificam continuamente se esses contratos estão sendo respeitados, detectando incompatibilidade antes da implantação. No assistente IA, a fronteira mais suscetível a erros de comunicação entre dados ou módulos está entre a interface do telegram com a API do LLM, pois cada componente precisa enviar e receber dados em formatos previamente definidos. O contrato pode ser documentado e prtegido por schemas e validação de JSON, contando que testes de integração no CI CD já vão evitar que mudanças em determinado módulo quebre os demais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de Perto: tem como característica alto poder e alto interesse, é quem toma a decisão e quem se importa com o dia a dia. Precisam de comunicação constante e validações arquiteturais.

Manter Satisfeitos: tem como características alto poder e baixo interesse, não se importam como que foi feito, mas tem o poder de cortar verba ou cancelar o projeto. Nesse caso, envie relatórios executivos concisos.

Manter Informados: tem como características baixo poder e alto interesse, são o usuários finais, vão ser quem vai usar que está sendo desenvolvido. Nesse caso, envie Release notes e tutoriaios de como dar comandos no CLI.

Monitorar: tem como características baixo poder e baixo interesse, nesse caso exigem esforço mínimo.

O professor atua como avaliador de conformidade pois ele verifica se o projeto atende aos requisitos popostos, mas não representa uma necessidade comercial. Por isso, as evidencias entregues devem estar sincronizados com o que foi pedido que o projeto tivesse.

O mapa de stakeholders do assistente IA do grupo Tirateeth são:

Gerenciar de perto: Professor avalliador, pois avalia as entregas e o cumprimento dos requisitos comunicação por marco no gitlab

Manter Informados: Alunos do CEFET-MG campus timoteo, matriculados no bacharelado em Engenharia da Computação, potenciais usuários e publico-alvo do projetom. Devem receber release notes

Monitorar: Colega de outros grupos, comunicação quando necessário.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A fórmula estabelecida pelo PMBOK coloca o crescimento de canais de comunicação como quadrático pois atribui pelo menos um canal de comunicação entre cada participante. Ou seja, é levado em consideração uma comunicação direta e singular entre cada colaborador. No caso de um projeto de 4 participantes, os canais de comunicação são 6, já que se conta a comunicação do participante 1 com o 2,3 e 4, o mesmo considera para os outros n participantes. Por isso, o aumento de 4 para 10 participantes acarretaria em 45 canais de comunicação.

Os canais síncronos são necessários apenas em situações específicas em que a conversa é priorizada visando sua importancia ou urgencia, deve ser usado para negociação ou resolução de problemas graves. Os canais assíncronos oferecem melhor gestão de tempo e funcionam a favor do flow da programção, deve ser usado para atualização de status e documentação.

No projeto do Assistente I.A, o número de canais diretos considerado os membros da equipe são 6. Por familiariadade, o canal de comunicação assíncrono do grupo é o WhatsApp por conter outros grupos de demandas acadêmicas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 JOÃO CARLOS FERRE. (Matrícula: 20213003750, Login: @joaocarlos.fm)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve deixar claro aos stakeholders que o protótipo possui limitações, como alucinações, latência, custos de API e respostas que podem variar. Dessa forma, é importante explicar o que o assistente faz e o que ele não faz, evitando expectativas de respostas perfeitas para qualquer pergunta. As 4 evidências obrigatórias são a EAP/WBS, o cronograma com Milestones, a Matriz RACI e a Matriz de Riscos com plano de contingência. Essas informações foram organizadas no repositório do GitLab, junto com a Matriz de Stakeholders, permitindo que a consulta facilmente a documentação do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo de tratamento de conflitos começa por explicitar o problema, ouvir os interesses e evidências, decidir com responsabilidade e registrar o impacto. As cinco posturas são Colaborar, buscando uma solução que atenda todos; Conceder, priorizando o interesse do outro; Forçar, impondo uma decisão quando necessário, como em emergências de segurança; Apaziguar, reduzindo a tensão; e Evitar, adiando o conflito quando ainda faltam informações para tomar uma decisão adequada. Um exemplo seria uma discussão sobre qual banco de dados utilizar no projeto. A equipe discutiu o problema no grupo criado, apresentando argumentos e evidências. Após a decisão, o motivo foi registrado para evitar novas discussões sobre o mesmo assunto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Interfaces técnicas entre diferentes equipes precisam de contratos explícitos para definir exatamente como os dados devem ser enviados e recebidos, evitando interpretações diferentes. Além disso, testes automatizados garantem que alterações em um módulo não quebrem a comunicação com os demais, reduzindo erros e aumentando a qualidade do sistema. No nosso projeto, a fronteira mais suscetível a erros está entre o Web e o backend do bot. O grupo documentou o formato das requisições e respostas e utilizar validação de dados garantinddo que os módulos continuem compatíveis.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

A Matriz de Poder vs. Interesse define a comunicação de acordo com o poder e interesse de cada stakeholder. O professor atua como avaliador de conformidade acadêmica, verificando se o projeto atende aos critérios acadêmicos, sendo necessário apresentar documentação, testes e resultados. No projeto do Assistente I.A., os stakeholders são João Carlos Martins, Artuhr Baltar e Bianca Barros. João atua como R, desenvolvendo e implementando o sistema. Artuhr atua como A e I, aprovando as tarefas e sendo informado sobre as funções criadas. Bianca atua como C, analisando as regras do sistema e sugerindo melhorias na implementação.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A quantidade de canais de comunicação cresce de forma quadrática porque cada novo integrante pode se comunicar com todos os outros membros da equipe. Desta forma, uma equipe com 4 pessoas possui 6 canais, enquanto uma equipe com 10 pessoas possui 45 canais, demonstrando que o crescimento da equipe aumenta bastante a complexidade da comunicação, mas não de forma exponencial. Em relação ao projeto do Assistente I.A., a comunicação síncrona pode ser utilizada para conversas rápidas e reuniões, enquanto decisões importantes devem ser registradas de forma assíncrona no GitLab. Assim, issues serão utilizadas para tarefas e problemas, Merge Requests para alterações no código e ADRs para decisões arquiteturais, garantindo a rastreabilidade das decisões e evitando informações perdidas no chat.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 JOÃO VÍTOR MARQUE. (Matrícula: 20243003394, Login: @joao)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

1- É preciso que toda a equipe deve comunique claramente que os sistemas que são baseados em LLMs possuem muitas limitações, incertezas, custos e riscos que precisam ser avaliados (ainda mais no caso do nosso projeto que usamos a parte gratuita). Pra isso a equipe tem que esclarecer pro usuário o objetivo exato do bot, os dados que tem disponíveis, os critérios de qualidade e os testes cumpridos. A equipe também tem que alertar que embora os protótipos ajudem a visualizar o uso, eles não substituem requisitos formais, controles de segurança e análises de impacto.

2- Ainda não temos todas as 4 100% preparadas mas até a data de entrega teremos o EAP e cronograma, a matriz de responsabilidades, o plano de riscos e o mapa de stakeholdes. Eles estão todos disponíveis no repositório do nosso IAplace no gitlab, lá onde temos todas as documentações do nosso projeto, lá usamos as issues pro rastreamento das tarefas, a aba do milestone pro cronograma e etc…

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

1- O ciclo trata o conflito como uma diferença legítima de objetivos e evidências, e não como um desvio pessoal. Depois de investigar as evidências, tem que tomar uma decisão e o impacto/justificativa tem que obrigatoriamente ser registrado. Já as abordagens:

Colaborar: Investiga interesses e alternativas conjuntas quando tem tempo pra uma decisão compartilhada.

Conceder: Busca um acordo aceitável entre as partes quando o custo de prolongar a decisão que já havia sido decidida fica em um valor alto.

Forçar: É uma decisão autorizada mas como uma imposição. É válido em emergências pois permite agir rapidamente quem tem a responsabilidade, e depois só exige uma justificativa e registro da ação.

Apaziguar: Deixa enfatizado os pontos de concordância ou acaba cedendo em um aspecto pra preservar o relacionamento da equipe, mas exige que o impacto técnico aceito seja explicito.

Evitar: Ela adia ou transfere a discursão, é interessante quando falta informações, pois cria tempo pra obter dados, desde que seja definido um responsável e uma data pra retomar.

2- Dilema iminente: Como equilibrar o prompt da API do gemini pra garantir que o assistente seja um bom tutor, sem estourar o limite de tokens e sem termos custo. Um de nós pode querer um prompt longo e muito complexo com restrições, enquanto isso os outros dois podem querer uma abordagem mais simples e econômica com menos restrições.

No gitlab temos que fazer as discursões pelos comentários com contexto e os objetivos direto no Merge Request ou nas issues. Pra garantir a segurança a revisão do código deve focar em discutir as evidências e as mudanças propostas, sem questionar a capacidade do membro que propôs. Se ficar complicado o assunto, podemos ir no privado e resolver o assunto sem nenhuma confusão.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

1- Os alinhamentos verbais são informais e com mais chances de acontecer falhas de memória ou interpretações erradas. o caso da sonda Mars Climate Orbiter mostra que falhas desse tipo não é apenas um errinho de comunicação, mas mostra a falta de requisito de interfaces verificáveis, validação independente e testes rigorosos. Se fizermos contratos explícitos e automatizados vamos garantir que as regras de integração sejam checadas sistematicamente pelo software, e eliminamos a dependência da interpretação humana entre equipes diferentes.

2- A fronteira mais suscetível a erros é quando a conexão entre o backend em python e a API do gemini que estamos usando. Como os sistemas baseados em modelos de linguagem possuem limitações, incertezas e comportamentos imprevisíveis, o formato ou o conteúdo do texto retornado pelo assistente é o maior ponto de risco de quebra de contato.

Pra garantir a integridade nós da equipe tentamos blindar essa fronteira validados os dados que vão chegando a API. Também as definições da arquitetura e os testes são documentados de forma assíncrona no gitlab do projeto, pelas issues e validados em revisões de código pelo Merge Request.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

1- Gerenciar de perto: Exige o engajamento ativo, uma comunicação síncrona e detalhada pra alinhar as decisões complexas e ter um apoio contínuo.

Manter satisfeitos: Foca em fornecer resumos de marcos e resultados importantes, evita a sobrecarga com detalhes operacionais que podem gerar um ruído.

Manter informados: Envolve o fornecimento de atualizações regulares e a solicitação ativa de feedbacks e aproveita o engajamento sem ceder o poder de decisão.

Monitorar: Precisa de um acompanhamento com pouco esforço, observando apenas se a posição do stakeholder muda com o passar do projeto.

Em um projeto igual o nosso de faculdade, funções de professor, cliente e patrocinador são diferentes. O professor é um avaliador que verifica se está de acordo com a disciplina com base nas regras académicas. O cliente, é quem esclarece as necessidades de uso do produto. Essa diferença altera as evidências: enquanto um cliente comercial vai focar no funcionamento do software, a entrega pro professor exige mais coisas combinadas do projeto, como o EAP, o cronograma, a matriz de responsabilidade, plano de risco e etc…

2- Stakeholder 1: Professor, manter satisfeito.

Justificativa: Ele tem o poder de aprovar nosso projeto ou reprovar ele, e não precisa acompanhar cada linha do código de nosso problema.

Cadência do canal: Pelos marcos/checkpoint, utilizando o gitlab para as entregas do nosso projeto para a avaliação.

Stakeholder2: Estudantes, manter informados.

Justificativa: Ele é fundamental pra validar se o nosso assistente realmente instiga o pensamento sem dar as respostas diretas. E com isso ele pode contribuir ativamente com feedback e testes, mesmo que não controle a gestão do nosso projeto.

Cadência e canal: Semanal, utiliza os testes no protótipo e formulários assíncronos de feedback sobre a qualidade da interação com o assistente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

1- O crescimento dos canais de comunicação é considerado quadrático pois se expandimos a equação de C = (N(n-1))/2 vamos ter um termo como N²/2 , com isso, o número de conexões crescendo proporcionalmente ao quadrado do número de pessoas, e não na forma exponencial que seria 2^N. Com uma equipe de 4 pessoas, temos C = (4*(3))/2 = 6 par de comunicação, se a equipe mudar para 10 pessoas a quantidade de canal muda bastante, vai ser C = (10*(9)/2) = 45.

A comunicação síncrona é a interação imediata, que é boa para a descoberta de problemas, negociações ou conversas de temas importantes. Já a comunicação assíncrona é pautado pelo tempo diferido, e favorece a preparação das respostas, a participação em fusos ou horário diferente, e também para a rastreabilidade do projeto. As decisões relevantes são aquelas que envolvem mudanças nos requisitos, riscos ou definições arquiteturais que já foram conversadas pelos chats, elas devem obrigatoriamente migrar pro modo assíncrono. Já a equipe precisa registrar a síntese das decisões nas ferramentas pra garantir o histórico e o acesso das pessoas autorizadas, e não depende da memória ou de conversas informais perdidas.

2- Considerando nós 3 da equipe mais o professor temos 4 pessoas pro escopo primário de comunicação. Podemos fazer C = (4*(4-1))/2 = 6 canais diretos possíveis de comunicação. Pra garantir a rastreabilidade sem sobrecarga, na nossa politica definimos que os aplicativos de mensagem vai ser usado para alertas rápidos e alinhamento de coisas triviais. Qualquer decisão mais técnica, como mudança de escopo ou alguma definição arquitetural sobre nosso agente que gerarmos em uma conversa informal precisamos formalizar com uma issue ou um registro ADR no gitLab. Também a validação do código e as discursões sobre as implementações técnicas tem que ocorrer por comentários contextuais e objetivos nos Merge Requests, assim vamos centralizar a discursão no próprio código.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 LETICIA MAURICIO. (Matrícula: 20243001649, Login: @leticia)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve comunicar as limitações dos LLMs de forma clara, evitando o efeito caixa preta na comunicação com o cliente. O cliente ou professor pode assumir que, por utilizar IA, qualquer coisa pedida é rápida, barata e magicamente infalível. Por isso, é necessário apresentar as limitações matemáticas de tokens, as alucinações estatísticas, a latência e os custos envolvidos. Trazer a métrica das limitações do LLM não é ser negativo ou ter má vontade, mas sim realizar uma negociação madura de escopo científico. Para demonstrar essas limitações, a equipe pode utilizar protótipos funcionais iterativos que mostrem a IA travando ou alucinando na prática, deixando claras as fronteiras do projeto.

As quatro evidências de gestão já preparadas e organizadas pelo grupo são a EAP, o Project Charter, os Requisitos e as Diretrizes do Prompt. A EAP está disponível em docs/EAP.md e também está vinculada à issue 5; o Project Charter está em docs/PROJECT_CHARTER.md, vinculado à issue 2; os requisitos estão em docs/REQUISITOS.md, também relacionados à issue 5; e as Diretrizes do Prompt estão em docs/DIRETRIZES_PROMPT.md, vinculadas à issue 4. Essas evidências correspondem principalmente ao trabalho desenvolvido no Módulo 1, enquanto as evidências de gestão específicas para o Check 02 estão sendo organizadas pelo grupo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Os conflitos em engenharia ágil não são necessariamente ataques ou brigas pessoais, mas sim embates técnicos intensos. O PMBOK mapeia 5 Abordagens Clássicas de Resolução de Conflitos: Evitar (Perde-Perde), quando o gerente adia o problema porque “não tem tempo de lidar com isso agora”; Apaziguar (Perde-Ganha), quando recua nas suas convicções técnicas apenas para manter a paz com o colega; Forçar / Impor (Ganha-Perde), quando o líder usa a autoridade hierárquica para impor uma decisão, sendo excelente e necessário para situações de altíssima crise, mas péssimo para o dia a dia porque corrói e destrói o moral do time; Conceder / Reconciliar (Ganha-Ganha parcial), quando cada lado cede um pedaço da sua ideia para fechar um acordo de meio-termo rápido; e Colaborar / Resolver (O Verdadeiro Ganha-Ganha), considerado o Padrão Ouro da Gestão Ágil, em que a equipe abandona as defesas de ego pessoais e ambos os lados focam o ataque na causa raiz do problema de software.

Um dilema técnico possível é definir como lidar com os limites de contexto do prompt, principalmente quando a quantidade de informações enviadas para a LLM fica muito grande. A discussão pode ocorrer nos comentários da issue correspondente no gitlab, apresentando os argumentos técnicos, limitações e evidências de cada alternativa, sem associar a escolha à opinião ou capacidade de uma pessoa. Depois da discussão, o grupo registra a decisão e seus impactos no próprio gitlab, permitindo que todos entendam por que aquela alternativa foi escolhida e permitindo também que as motivações da decisão fiquem registradas. Dessa forma, a discordância continua sendo uma discussão técnica, evitando que o conflito se transforme em atrito pessoal.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Interfaces técnicas entre subsistemas desenvolvidos por pessoas ou equipes diferentes precisam de contratos explícitos porque o alinhamento verbal pode ser esquecido, interpretado de formas diferentes ou não acompanhar as mudanças no sistema. Um contrato define claramente o formato dos dados, os campos esperados, tipos, entradas e saídas de cada módulo. Além disso, os testes automatizados verificam se esses contratos continuam sendo cumpridos quando o sistema é alterado, evitando que um módulo envie uma informação em um formato diferente do que o outro espera. Dessa forma, a comunicação entre os módulos deixa de depender apenas de pessoas e passa a ser documentada, verificável e rastreável.

No projeto, a fronteira mais suscetível a erros de comunicação está na integração entre o backend do bot e as APIs de LLM, principalmente na troca de requisições e respostas em JSON. É nessa comunicação que podem ocorrer problemas de formato, campos ausentes ou tipos de dados diferentes dos esperados. Para reduzir esse risco, o contrato deve ser documentado no repositório por meio de schemas de validação, definição das estruturas JSON e testes automatizados que verifiquem as respostas da API. Assim, antes de uma alteração ser integrada, o CI/CD pode verificar se os módulos continuam seguindo o mesmo contrato, evitando que uma mudança em uma parte do sistema quebre a integração com as demais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

A Matriz de Poder x Interesse cruza o poder de veto e decisão com o interesse no dia a dia do desenvolvimento, permitindo definir o nível de engajamento de cada stakeholder. Em Gerenciar de Perto (Alto Poder + Alto Interesse), devem ser feitas reuniões frequentes, demonstrações contínuas, validação da arquitetura e protótipos funcionais. Em Manter Satisfeitos (Alto Poder + Baixo Interesse), devem ser enviados relatórios executivos concisos, com informações como prazo, orçamento e possíveis problemas, sem sobrecarregar com minúcias técnicas. Em Manter Informados (Baixo Poder + Alto Interesse), podem ser utilizados Release Notes, e-mails, tutoriais e um canal de Feedback. Já em Monitorar (Baixo Poder + Baixo Interesse), o esforço deve ser mínimo, apenas acompanhando se o nível de poder ou interesse muda ou se surgem obstáculos burocráticos.

No caso do professor, seu papel no projeto não é o de um cliente comercial que está comprando um produto, mas de uma parte interessada que acompanha as entregas, o escopo e os critérios da disciplina. Por isso, a evidência deve estar relacionada ao cumprimento do projeto, como issues, documentação, arquitetura, riscos, entregas e demais registros no gitlab. A comunicação assíncrona é importante porque deixa tudo documentado, rastreável e versionado, e a regra é que uma decisão técnica só existe oficialmente quando está registrada na ferramenta corporativa, como issue, wiki ou commit do gitlab.

No projeto, o PO pode ficar em gerenciar de perto, pois possui alto interesse no desenvolvimento e participa das decisões sobre o produto, com acompanhamento diário pelo gitlab e reuniões quando necessário. Um dev da equipe também pode ser colocado em gerenciar de perto, por participar diretamente do desenvolvimento e das decisões técnicas, com comunicação diária por meio das issues e merge requests. Já o Scrum Master pode ser colocado em Manter Informados, acompanhando o andamento do trabalho e ajudando a equipe a manter o fluxo organizado, com comunicação semanal pelo gitlab. Dessa forma, cada stakeholder recebe a comunicação adequada ao seu nível de poder e interesse, mantendo o projeto organizado e evitando excesso de informações.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O crescimento é quadrático porque, conforme novas pessoas entram na equipe, elas não criam apenas um novo canal, mas passam a ter possibilidade de comunicação com todos os participantes que já estavam no grupo. Por exemplo, com 4 pessoas existem 6 possíveis conexões. Ao aumentar para 10 pessoas, esse número chega a 45.

A comunicação síncrona acontece em tempo real, como em reuniões ou conversas pelo whatsApp, sendo útil para dúvidas rápidas, alinhamentos e situações que precisam de uma resposta imediata, enquanto a comunicação assíncrona permite registrar as informações para consultas futuras. Assim, decisões importantes do projeto não devem ficar somente no chat, de modo que issues podem registrar problemas e demandas e merge requests as alterações e discussões do código, para que possam existir oficialmente.

No nosso projeto, a equipe é formada por 4 pessoas e também precisa manter comunicação com o professor, totalizando 5 participantes principais de modo que existem 10 canais diretos de comunicação. Para evitar que as decisões fiquem dispersas, o grupo definiu o gitlab como o local oficial para registrar questões, alterações e decisões importantes do projeto. O whatsApp fica destinado a avisos, dúvidas e alinhamentos rápidos, enquanto informações que precisam ser consultadas posteriormente devem ser registradas no repositório. Assim, o grupo mantém a organização e o histórico das decisões sem precisar repetir as mesmas discussões em diferentes canais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 MATEUS SILVA LOPE. (Matrícula: 20243004300, Login: @MateusLopes15)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

O bot em si apresenta limitações, ele não utiliza os modelos mais fortes da IA, utiliza o modelo de melhor uso gratuito, além de que ele só mantem 5 históricos, a equipe em si, ao levar isso para um stakeholder totalmente externo, ele terá total conhecimento das limitações, não iremos ocultar nada. Pois vamos declarar o escopo do assistente, explicando as limitações da LLM e do nosso projeto.

Por enquanto fizemos apenas o EAP e os milestones, ainda iremos providenciar o resto das coisas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo para o tratamento de conflitos funcionar primeiro explicar o problema(trazer de forma clara o problema, sem despersonalizar)->Ouvir interesses e evidencias(analisar os dados técnicos, prazos, prioridades e restrições afetadas)->Decidir com responsabilidade(esclarecer prazos, verificar quem é afetado e quem responde legalmente ou tecnicamente pela decisão final)->Registrar Impacto(Documentar a decisão tomada para preservar o contexto e a rastreabilidade no projeto).

Colaborar: Investigar alternativas para buscar uma solução ótima e duradoura.

Conceder: Chegar a um acordo aceitável quando o custo de prolongar o debate supera o benefício de vencer a discussão

Forçar: Tomar uma decisão baseada em autoridade, em emergências é importante que alguém decida, não deixando espaço para debates longos.

Apaziguar: Tentar mostrar pontos de concordância, ou ceder para baixar a tensão.

Evitar: Adiar o confronto, quando se falta dados, é interessante adiar o confronto até que tenha evidências sólidas.

No nosso caso, eu com PO, pensei em umas tecnologias, pesquisei a viabilidade delas, depois disso mandei uma mensagem para os integrantes da equipe, e eles gostaram da ideia, em si, até agora não houveram problemas de discordância, pois sempre estamos se comunicando antes de realizar algo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Alinhamentos verbais não significam muita coisa, uma brincadeira clássica é o telefone mudo, onde uma pessoa na mesma hora cria uma frase e vai passando de pessoa pra pessoa, e no final a última pessoa escuta uma coisa nada a ver com a primeira pessoa. Tentar alinhar as coisas sem uma documentação escrita explicita, deixa margem para erros absurdos, não ter a certeza abre margem para imaginação, e esse é o maior problema. testes automatizados agem como protetores, impedindo que alterações em um módulo quebrem o comportamento esperado de outro subsistema dependente.

Para nosso projeto, no caso sempre que uma pessoa mandar uma mensagem, o back-end irá tratar ela antes de chegar no LLM, evitando que ocorram esses problemas. E o CI/CD configurado no gitlab já realiza os testes automatizados para validação.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de perto: Envolve engajamento ativo, uma comunicação para validar a arquitetura, nesse caso os stakeholders estão engajados com o projeto.

Manter Satisfeito: eles tem alto poder, mas baixo interesse, pois exigem atenção focada em relatórios, mas não desejam saber detalhes técnicos e profundos, apenas tem a autoridade de alterar orçamento, recursos e eventualmente cancelar iniciativas.

Manter Informado: São as pessoas que possuem baixo poder, mas alto interesse, então eles recebem as atualizações regulamente e utilizam o projeto, mas não tem poder de mudança sobre ele.

Monitor: ele tem baixo poder, e baixo interesse, basicamente é uma pessoa que acompanha passivamente o projeto para evitar problemas.

Um professor possui um pensamento diferente de um cliente, o primeiro ponto a se pensar é que o cliente bota dinheiro, e normalmente espera que com seu trabalho, no futuro ele tenha retorno de mais dinheiro, é claro, considerando uma empresa com fins lucrativos, por outro lado o professor receberá seu dinheiro independente do resultado do aluno, então tudo que o professor for seguir, vai ser para ajudar o aprendizado do aluno, o projeto terá regras especificas para saber se vai ficar bom ou não, fora que o professor “pega na mão” e mostra o que deve ser feito, em que fase e vai indo. Diferente do cliente, que além de ter seu dinheiro em risco, ele vai esperar que você saiba tudo que precisa, você terá que ter a carga toda.

Os 3 stakeholders que teremos serão um dos membros do grupo(alto poder e alto interesse), um amigo da EC(baixo poder, alto interesse) e o professor(baixo poder, alto interesse).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Basicamente, cada membro que entra estabelece uma conexão com cada outro membro da equipe, ou seja, ligação bilaterais. Dessa forma ao calcular com 4 pessoas numa equipe, o resultado final é de 6 pares possíveis, mas ao aumentar por exemplo para 5 pessoas já são 10 pares possíveis, com 10 pessoas são 45 pares possíveis.

As comunicações síncronas, são aquelas que acontecem diretamente, uma mensagem, uma vídeo chamada, uma ligação, elas envolvem respostas imediatas, e podem quebrar o fluxo do projeto, por outro lado, temos as assíncronas que envolvem por exemplo, tasks no kanban, documentação, não exigindo comunicação imediata, normalmente ela é boa para preparar e rastrear o fluxo da equipe.

No caso temos 3 pessoas no grupo, aplicando a formula tempos 3(2)/2 = 3 pares possíveis. Basicamente temos um grupo no WhatsApp que definimos algumas coisas, e quando há atualização no kanban, merge ou afins, avisamos no grupo marcando a pessoa para ela saber. Como o gitlab, não é algo que utilizamos todos os dias, precisamos ter uma comunicação síncrona para lembrar da assíncrona, claro, que isso para um trabalho seria inviável, mas como estamos no ambiente acadêmico, isso é totalmente plausível.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 MATHEUS MATOS BOT. (Matrícula: 20243001353, Login: @matheusmb10)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Primeira pergunta: As expectativas sobre IA exigem evidências e protótipos e avaliações ajudam a aprender mas não substituem requisitos, segurança e nem análise de impactos, o que serve de solução ao Efeito Demonstração. Dessa forma é importante informar o que o bot faz, como faz e o que acontece com os dados digitados, demonstrando também que pode ocorrer erros, demora e que o bot pode estar sujeito a limitações também, mas lembrando também que o usuário pode sempre conferir e questionar aquilo que o bot traz. O melhor canal para confiabilidade do usuário é o README e a própria interface.

Segunda questão: Meu grupo já preparou o EAP e o cronograma rastreável de Milestones, com os papéis definidos para cada integrante conforme sua responsabilidade de papel. Se atém a isso, ainda não iniciamos o módulo 2.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Primeira questão:

Explicitar o problema é saber identificar aquilo que diverge em termos de projeto e não daquele que executa (a pessoa), esclarecendo, antes de tudo, o prazo, as pessoas afetadas e quem responde pela decisão. Ouvir interesses e evidências é entender o que é necessário para cada lado e em que dados se apoiar. Decidir com responsabilidade envolve a decisão ter um responsável identificado, que assume aquilo que o compete. Por fim, registrar impacto é saber entender o que a decisão muda e registrar isso, para não perder contexto e nem aprendizado.

Quanto as 5 posturas: Colaborar é saber investigar alternativas e é interessante quando se tem tempo de sobra. Conceder é um acordo aceitável quando prolongar custa mais e é válido quando o custo de continuar discutindo supera o ganho. Forçar é decisão autorizada e faz sentido quando quem tem autoridade decide sem aguardar consenso. Apaziguar é enfatizar concordâncias ou ceder com impacto explícito, o que faz sentido se preservar a relação ou a tensão baixa com custo da cessão declarado. Por fim evitar é adiar para obter dados ou reduzir a tensão, definindo retorno e faz sentido em situação que falta dados ou a tensão precisa baixar antes da conversa acontecer.

Forçar pode ser legítimo numa situação de emergência, por exemplo, onde o custo de esperar o consenso geral é maior do que tomar a decisão de forma imediata por aquele que detém a responsabilidade. Evitar é prudente, pois se não há evidência, a decisão tomada agora pode se tornar uma aposta e apostas não te trazem certeza de ganho.

Segunda questão:

Um dilema que enfrentamos era decidir entre um modelo de IA fixo da OpenRouter ou o roteador de modelos. Decidimos optar pelo fixo por maior previsibilidade. Não foi algo formalizado pelo GitLab, isso foi uma decisão tomada ao vivo por nós 3 integrantes. Mas ainda está em aberto caso aconteça alguma mudança de posicionamento de algum integrante com algum argumento válido para a mudança e considerando,claro, que não estamos tão avançados no projeto e que temos margem para isso dentro daquilo que se tem planejado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Primeira questão: O alinhamento verbal falha pois não deixa registro conferível e permite que cada lado da conversa assuma pontos de vistas diferentes sem entrarem em acordo. O contrato de interface por suas vez transforma uma premissa implícita em algo versionado e compartilhado, com capacidade de rastreamento. Conforme a quantidade de participantes cresce, se torna evidente a necessidade do contrato para funcionamento do projeto, já que as interações em pares também crescem mesmo que não precisem necessariamente de contato direto para ocorrer.

Segunda questão: Acredito que a fronteira mais sensível é a do backend com a API DO LLM pois é uma parte externa que não temos controle, o que abre margem para diferentes interpretações para diferentes premissas. O mesmo ocorre na fronteira back - front, porém por outro motivo: duas pessoas diferentes fizeram cada módulo. Apesar do controle interno existir nesse caso, diferentes pessoas podem enxergar uma tarefa de diferentes maneiras.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Primeira questão:

Gerenciar de perto = conversa frequente e bidirecional, cabendo interação síncrona para descoberta, negociação e urgência e as decisões vão para um registro rastreável.

Manter satisfeitos = uma comunicação objetiva, apenas com aquilo que importa para decidir, sem sobrecargas, através de um canal assíncrono.

Manter informados = informação clara, mas sem negociação direta de cada ponto, focando em transparência e rastreabilidade

Monitor = menor esforço possível, reavaliando se algo mudar, alertas rápidos.

Funções como professor e cliente não são a mesma coisa. O cliente comercial define o valor do produto, o professor define conformidade acadêmica, a fim de entender se o grupo entregou aquilo que foi solicitado, dentro do prazo e nos critérios pré-definidos.

Segunda questão:

Professor avaliador = Gerenciar de perto (alto poder, alto interesse), definindo critérios, prazos, evidências e verificando conformidade por cada marco através do repositório do GitLab.

Usuário final = Manter informados(baixo poder, alto interesse), já que não decide escopo nem prazo mas é o mais afetado pelo comportamento do tutor socrático. Deve ser atualizado por marco e o canal oficial é através da documentação, como README ou a própria interface web.

Responsável pela API externa de IA = Manter satisfeitos (alto poder, baixo interesse), já que pode mudar os limites, modelos ou disponibilidade mas não tem nada de interesse com o projeto, sendo atualizados por marco sempre que os termos ou disponibilidade mudar. O canal oficial é a documentação oficial do provedor.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Primeira questão: Utilizando o exemplo do slide, a combinação de 4 pessoas de 2 a 2 resulta em 6. A mesma combinação para 10 pessoas resulta em 45. Isso prova um crescimento quadrático frente ao exponencial. Pela própria fórmula é possível ver que para N grande, a parte quadrada domina o restante da função. Partindo para comunicação síncrona e assíncrona, podemos definir a primeira como aquela que ocorre em tempo real, exigindo que aqueles envolvidos estejam ativos, enquanto a assíncrona é aquela que pode ocorrer em momentos distintos, sem necessidade de imediatismo ou resposta em tempo real. Se uma determinada tarefa comunicada de forma síncrona, a princípio, não precisa da comunicação em tempo real e ativa dos participantes, podemos transformá-la em assíncrona.

Segunda questão: Considerando 3 pessoas no projeto + o professor, aplicando a fórmula fica 4(3)/2 = 6. Nos organizamos de forma assíncrona através da issues no GitLab, que já estão dispostas e separadas coma responsabilidade de cada membro do grupo, o que permite rastreabilidade também. A issue só pode ser fechada após o merge request aceito pelo reviewer, o que garante a não duplicidade de tarefas dentro do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 NATHAN BALMANT DE. (Matrícula: 20223004358, Login: @NathanBalmant)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

1. A equipe deve deixar os limites do bot explícitos desde o início, no Charter e no README. O bot ajuda a encontrar informações de editais, regras do Cefet, matriz do curso e co-requisitos de disciplinas, contudo não da detalhe de horários, não explica conteúdo técnico. As expectativas são ajustadas com evidências, mostrando aos stakeholders os resultados de testes com cenários definidos em vez de uma única demonstração bem-sucedida.

2. A documentação de gestão está na pasta docs do repositório. A EAP está em EAP.md, com os pacotes vinculados às Issues e aos Milestones do GitLab, que formam o cronograma rastreável. O Charter, os requisitos e as diretrizes do prompt estão em PROJECT_CHARTER.md, REQUISITOS.md e DIRETRIZES.md.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

1. O ciclo é explicitar o problema sem identificar pessoas diretamente, ouvir os argumentos e as evidências de cada lado, decidir definindo quem responde pela decisão e registrar o impacto para revisão futura.

Colaborar é buscar uma solução conjunta. Conceder é aceitar um meio-termo. Forçar é decidir por autoridade. Apaziguar é ceder deixando o impacto explícito. Evitar é adiar com data para retomar. Forçar é legítimo em emergências, porque esperar um consenso aumenta o dano. Evitar é prudente quando faltam dados, para não decidir às cegas.

2. Nosso dilema é ate onde nosso assistente deve responder, se deve responder apenas informações de escopo institucional do Cefet ou também informações mais internas como detalhes de disciplinas, a decisão esta registrado nos documentos do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Quando equipes diferentes constroem partes que se conectam, cada uma assume ideias próprias. Um alinhamento verbal não deixa registro, não é verificado e se perde quando as pessoas mudam. Um contrato explícito, testado automaticamente no CI, transforma essa ideias em algo que falha antes da entrega, e não em produção, como aconteceu com a sonda.

No nosso assistente, uma das fronteiras mais frágeis fica entre a mensagem do usuário e o LLM, por causa do risco de prompt injection, onde o aluno pode tentar usar a LLM de outras maneiras do que foi proposto. Para reduzir esse risco, antes de enviar a mensagem ao LLM o backend a submete a um modelo classificador da Meta (prompt guard) que identifica e bloqueia tentativas de injeção.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

1. Gerenciar de perto, para alto poder e alto interesse, significa envolver nas decisões com contato frequente. Manter satisfeitos, para alto poder e baixo interesse, significa enviar sínteses e consultar só no que os afeta. Manter informados, para baixo poder e alto interesse, significa dar atualizações regulares e espaço para feedback. Monitorar, para baixo poder e baixo interesse, significa apenas acompanhar mudanças.

O professor é avaliador porque os critérios vêm da disciplina, não de uma necessidade de negócio. Por isso, a evidência esperada é a rastreabilidade no GitLab como comentários, e não apenas o bot funcionando.

2. O professor avaliador, com alto poder e alto interesse, é gerenciado de perto. O usuário do CEFET, com baixo poder e alto interesse, é mantido informado e participa dos testes. O provedor da API do LLM, com alto poder e baixo interesse, é mantido satisfeito, com a equipe respeitando os termos de uso e monitorando mudanças de preço e cotas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

1. O crescimento é quadrático porque cada pessoa se conecta com as outras N−1 e cada par é contado uma só vez, o que dá aproximadamente N²/2. Exponencial seria 2ᴺ, muito mais rápido. Passando de 4 para 10 pessoas, os canais vão de 6 para 45: as pessoas aumentam 2,5 vezes e os canais aumentam 7,5 vezes.

A comunicação síncrona que envolve chamadas ou conversas ao vivo é importante para resolução de certos chamados mas deixa poucos rastros e registros, enquanto a Assíncrona usando issues e ADRs produzem uma rastreabilidade melhor e decisoes mais importantes como de arquitetura devem sempre migrar para a Assíncrona pois elas devem servir de documentacao.

2. Considerando os 4 membros da equipe (dois desenvolvedores, o gestor e o responsável pelo produto) e o professor como principal interlocutor externo, temos N = 5 e, portanto, 10 canais. A política do grupo é usar o WhatsApp como conversa informal e avisos contudo toda decisão técnica devera passar por uma Issue, as mudanças de código passam por MR vinculado à Issue e as decisões arquiteturais viram ADRs, sob responsabilidade do gestor.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 PEDRO CLAUDIO JAC. (Matrícula: 20223006791, Login: @pejacome)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Usuario e objetivo - Dados e privacidade - Qualidade e limites -> Controles e decisao.

EAP=diretorio docs; cronograma rastreável em Milestones=gitlab; Matriz de Riscos com plano de contingência e Matriz de Stakeholders = docs

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Esse é o ciclo para lidar com conflitos. Colaborar: investigar alternativas. Conceder: acordo aceitavel quando prolongar custa mais. Forcar: decisao autorizada, por exemplo em incidente de segurança. Apaziguar: enfatizar concordancias ou ceder com impacto explicito. Evitar: adiar para obter dados ou reduzir tensao, definindo retorno.

a escolha entre telegram e terminal. deve ser discutidas em termos da tecnologia e não das pessoas envolvidas

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

por que assim é menos provavel o erro manual.

a api da IA. blindamos por meio de validação json

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

gerenciar de perto = altoxalto; manter satisfeitos = baixoxalto; manter informados = altoxbaixo; monitorar = baixoxbaixo. pois tipos diferentes de stakeholders tem interesses diferentes.

Professor Avaliador=altoxbaixo,por marco,gitlab; Usuário Competidor do ICPC=baixoxbaixo,fim,gitlab; Colegas=baixoxbaixo,fim,gitlab

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

ele é quadratico porque a função é quadratica. com 4 pessoas há 12 conexões mas com 10 há 45. coisas que beneficiariam de preparacao, participacao distribuida e rastreabilidade.

há 12 canais, o método assincrono é o gitlab

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 RONALD RODRIGUES. (Matrícula: 20243003723, Login: @ronaldrodriguesvitorino)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A comunicação e a gerência das expectativas dos stakeholders deve se basear principalmente na documentação do projeto e em métricas reais, mais do que uma demonstração inicial rápida; a documentação deve trazer explicitamente o escopo do projeto, delimitando o que a IA será capaz de fazer e o que ela não será capaz de fazer, bem como as limitações e restrições do projeto, além de seus riscos; isso também pode ser feito através de uma mensagem inicial do bot, que definirá para o usuário o que ele será ou não capaz de fazer.

Para as evidências obrigatórias de gestão no GitLab, estão o cronograma rastreável em milestones, disponível em Plano -> Ítens de Trabalho no repositório; a EAP, disponível em /docs/EAP.md; o Project Charter, disponível em /docs/PROJECT_CHARTER.md; a especificação de requisitos em /docs/REQUISITOS.md.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo de tratamento se baseia em: explicitar o problema, colocando-o em evidência de todos para o diálogo; ouvir interesses e evidências, catalogando-as para serem levadas em consideração; decidir com responsabilidade, baseando-se em métricas e restrições ao invés de fatores pessoais; registrar o impacto, para determinar se a escolha foi positiva ou não. Nesse sentido, existem cinco posturas situacionais a se lidar com um problema: colaborar para investigar alternativas; conceder, gerando um acordo aceitável quando prolongar custa mais; forçar, uma decisão autorizada, que pode ser legítimo em emergências de segurança quando a ação precisa ser imediata; apaziguar, enfatizando concordancias ou cedendo com impacto explicito; evitar, que também pode ser prudente, adiando o problema para obter mais dados ou reduzir tensão, definindo um retorno.

Para o dilema técnico, os limites de contexto do prompt é um problema iminente, e a discussão deve seguir da seguinte forma: primeiro, haverá uma contextualização focada em dados, métricas e restrições; depois, uma proposta de benchmark com algumas propostas de soluções para avaliarmos as métricas; uma escolha com base em requisitos, prazos e resultados do benchmark; por fim, uma formalização da decisão através de uma ADR.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Alinhamentos verbais geram ambiguidade, e o código não possui a capacidade de adivinhar as pressuposições adotadas pelos desenvolvedores ao desenvolverem os subsistemas; alinhamentos verbais se perdem com o tempo, e a ausência de um contrato explícito e testes automatizados fazem com que a falha seja detectada tardiamente. Um contrato explícito gera especificação, denotando os tipos de dados, estrutura esperada e o fluxo de entrada e saída, além dos testes automatizados promoverem a execução do código em um terreno neutro, impedindo o deploy caso algum erro seja detectado.

No caso do projeto de IA, a fronteira mais suscetível a erros é na integração da LLM com a interface do Discord, devido a natureza não-determinística da LLM e, para mitigar isso, as respostas serão mediadas por schemas Pydantic, forçando uma validação dos campos, além de uma validação em CI/CD para bloquear merge requests que sofram de erros de comunicação de dados.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Na matriz de Poder x Interesse, existem quatro quadrantes, e cada uma delas possui uma estratégia de comunicação recomendada: os com alto poder e alto interesse, que devem ser gerenciados de perto; os com alto poder e baixo interesse, que devem ser mantidos satisfeitos; os com baixo poder e alto interesse, que devem ser mantidos informados; os com baixo poder e baixo interesse, que devem ser monitorados.

O professor, no contexto do projeto, é um Avaliador de Conformidade Acadêmica, analisando mais o processo do que o produto final, e verificando se os passos tomados para a construção fazem sentido, enquanto o cliente foca no resultado final e no valor que isso irá gerar para ele.

Três stakeholders do projeto podem ser: um usuário competidor de maratonas de programação, com baixo poder e alto interesse, justificando uma comunicação semanal através da documentação no GitLab; o professor, com alto poder e alto interesse, justificando uma comunicação diária através das issues e merge requests no GitLab; os colegas de outras equipes, com baixo poder e baixo interesse, justificando uma comunicação por marcos através do GitLab, com a documentação a cada parte nova do sistema.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Visto que o modelo formal de conexões é dado pela formula N(N-1)/2, em que N é o número de pessoas, isso pode ser desenvolvido para (N^2-N)/2, o que em notação Big O se torna apenas O(N^2); um crescimento exponencial representaria todos os possíveis subsets (com complexidade O(2^N)), e não as comunicações de pares. Com quatro pessoas, existem 6 possíveis pares e, com 10 pessoas, existem 45 possíveis pares.

Para os dois tipos de comunicação, temos a síncrona: provê interação imediata, o que pode ajudar em descoberta, negociação, urgência ou assunto sensível; a assíncrona, através de issues, e-mails e documentos favorecem preparação, participação distribuída e rastreabilidade, e devem ser escolhidas com base em urgência, complexidade, disponibilidade, acessibilidade e confidencialidade. Como via de regra, toda decisão que precisa ser rastreada deve ser migrada para o modo assíncrono, como no caso de ADRs, merge requests ou issues, ou no caso do mismatch de horários (como pessoas trabalhando em países com fusos horários muito diferentes, sem a possibilidade de uma comunicação síncrona frequente).

Considerando o projeto, existem os três membros da equipe e o professor, totalizando quatro pessoas. Isso dá um total de 6 possíveis pares. Para a política oficial de comunicação assíncrona, as issues e merge requests são as principais formas de garantir rastreabilidade das decisões e o que será feito, de forma a centralizar tudo no GitLab para que não hajam ambiguidades.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 SABRINA EVELYN SI. (Matrícula: 20243000454, Login: @SabEvelyn)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Para evitar falsas ilusões com a IA, nós avisamos com clareza na tela do bot o que ele sabe e o que ele não faz, além de explicar o tempo de resposta e pode cometer erros se forçar assuntos fora do combinado. Para o Check 02, organizamos as 4 evidências obrigatórias de forma fácil de achar no GitLab: o cronograma de tarefas nas abas de Milestones e Issues; a divisão de quem faz o quê no arquivo docs/gestao/raci.md; o plano para possíveis problemas e riscos em docs/gestao/riscos.md; e o mapa das pessoas envolvidas no projeto em docs/gestao/stakeholders.md.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo de conflito é basicamente apresentar o problema, ouvir argumentos gerais, tomar uma decisão e registrar o que foi decidido. Em um grupo existem divergências, pode-se colaborar para achar um meio termo, abrir mão de algo, ou adiar a discussão. No nosso projeto, o dilema foi escolher entre usar um banco de dados simples (SQLite) ou um banco vetorial mais complexo para salvar as mensagens do bot. A discussão no GitLab focou apenas no código e nos prazos da entrega, usando perguntas como “o que a ferramenta resolve hoje?” em vez de críticas pessoais, mantendo a conversa respeitosa e técnica.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Alinhamentos verbais podem se deturpar ou perder, por isso um sistema precisa de regras escritas e testes automáticos. No nosso projeto, a fronteira mais suscetível a erros fica na resposta da Inteligência Artificial que pode responder com um texto solto ou com campos faltando em vez do formato exato que esperamos. Para prevenir isso, definimos um molde rígido de dados (usando esquemas de validação de JSON/Pydantic) que confere se todas as informações vieram com os nomes, valores e tipos corretos. Além disso, criamos testes automáticos no repositório que rodam sozinhos a cada alteração, impedindo que qualquer código seja aceito se o formato da resposta for quebrado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Essa matriz ajuda a decidir o quanto de esforço cada pessoa vai ser vigiada. Quem manda muito e se importa muito deve ser acompanhado muito, quem não manda mas tem interesse deve receber avisos regulares e quem não tem o que vigiar. O professor é o avaliador que define se seguimos as regras pressupostas, se usamos boas práticas e a organização do trabalho. No nosso projeto: o Professor fica responsável de acompanhar de perto cada entrega de etapa via repositório; o Usuário que vai usar o app fica responsável de manter informado; e o Responsável pelos servidores/API fica responsável de gerir o produto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O modelo é quadrático e não exponencial porque uma pessoa (n) se conecta apenas a outras (n - 1) pessoas, sem permutações de subconjuntos: com 4 pessoas há 6 canais (4 x 3 / 2), saltando para 45 canais com 10 pessoas (10 x 9 / 2), uma sobrecarga de 750%. No entanto, a comunicação síncrona serve para alinhamentos específicos, e decisões urgentes. Se houver mudança estrutural deve ser cadastrado como Issues ou Merge Requests. Considerando minha equipe de 4 componentes (4 x 3 / 2) serão 6 canais. Para evitar erros, as conversas em chats servem apenas para levantar ideias, sendo obrigatório registrar a proposta em uma Issue e aprovar qualquer definição técnica via ADR vinculada ao Pull Request correspondente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 SAMUEL BRUM LELLE. (Matrícula: 20243004560, Login: @Sam)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Para neutralizar o efeito demonstração deve haver uma abordagem transparente em três frentes técnicas e comunicacionais:

Transferência na interface: Explicitar na primeira mensagem do assistente o seu domínio de atuação e o que não faz. Inserir alertas visuais na interface indicando que a IA é probabilística e pode cometer erros.

Mecanismos de engenharia para mitigação técnica: RAG com citações de fontes para mitigar alucinações e responder apenas com base no contexto injetado pelo banco de dados vetorial, exigindo que a reposta apresente a fonte da informação.

Mapeamento de rate limits e custo: Estabelecer travas de cota por usuários de uso de tokens de API para evitar estouro de cotas da API.

Comunicação alinhada com stakeholders: Apresentar na documentação os cenários em que o projeto atua e delimitar as restrições de contexto assumidas pela equipe.

As 4 evidências obrigatórias de gestão de projeto estruturadas no GitLab e a localização de acesso no repositório são:

Evidência de Gestão	Descrição Prática do Conteúdo	Localização no Repositório GitLab
1. EAP/WBS e Cronograma Rastreável em Milestones	Estruturação de todas as entregas do Módulo 02 fatiadas em Issues com prazos, responsáveis e agrupadas na Milestone “Check 02”.	Plan > Milestones e Plan > Boards (Board Kanban filtrado pela Milestone do Check 02).
2. Matriz RACI de Responsabilidades	Definição clara dos papéis de cada membro do time para cada entregável (Responsible, Accountable, Consulted, Informed).	Arquivo docs/management/raci-matrix.md no repositório ou no Wiki do GitLab.
3. Matriz de Riscos com Plano de Contingência	Mapeamento de riscos técnicos (ex.: estourar cota de API, alucinações, atraso no front-end), com probabilidade, impacto e plano de ação/contingência.	Arquivo docs/management/risk-matrix.md e registrado em Issues com a label ~Risco.
4. Matriz de Stakeholders e Plano de Engajamento	Classificação dos stakeholders (Professor, Alunos/Usuários, Provedor de API) na Matriz Poder vs. Interesse e canais de comunicação oficiais.	Arquivo docs/management/stakeholder-matrix.md ou na seção dedicada da documentação do repositório.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O tratamento ocorre em quatro etapas:

Explicitar o problema: Definir a divergência técnica livre de opiniões pessoais ou julgamentos morais.

Ouvir interesses e evidências: Reunir argumentos de cada lado da discussão embasados em dados, testes e restrições do projeto.

Decidir com responsabilidade: Tomar a decisão com base na análise custo-benefício, levando em conta os riscos que ela carrega

Registrar o impacto: Documentar a decisão e suas consequências.

Colaborar: Buscar uma solução que englobe diferentes ideias para elaborar uma solução benéfica para todas as partes.

Conceder: Abrir mão de uma preferência em prol da harmonia do grupo.

Forçar: Impor uma decisão técnica com autoridade inquestionável. Em casos de emergência pode não haver tempo para discutir uma resolução, exigindo intervenção imediata para sanar o problema.

Apaziguar: Suavizar o atrito, enfatizando pontos de concordância em vez de divergências.

Evitar: Adiar ou contornar temporariamente a discussão da divergência

Durante a etapa de definição de interface para o Assistente de IA do Projeto Integrador, a equipe se dividiu sobre qual canal deve ser a interface principal de interação com o usuário final:

Opção A: Bot no Telegram

Argumentos a favor: Foco total no core da IA, desenvolvimento extremamente rápido (UI pronta e nativa), custo zero de hospedagem de front-end, facilidade de uso em dispositivos móveis e suporte nativo a mensagens assíncronas/streaming de respostas.
Objeções: Dependência de uma plataforma de terceiros (risco de lock-in ou bloqueios da API do Telegram), limitação para personalização visual (layout engessado ao chat do app) e dependência de o usuário ter a conta/aplicativo instalado.

Opção B: Aplicação Web Própria (Site/Dashboard)

Argumentos a favor: Controle e personalização total da experiência do usuário (UX/UI), possibilidade de criar relatórios visuais, dashboards e gráficos ricos, maior facilidade para apresentações acadêmicas e independência de plataformas externas de mensageria.
Objeções: Alto custo de desenvolvimento (necessidade de construir layout responsivo, gerenciar estados no front-end, autenticação e sessão), maior complexidade de hospedagem e risco de gastar o tempo da equipe com o front-end em detrimento do motor de IA.

Para resolver este conflito técnico de forma objetiva, a equipe aplicou o ciclo de tratamento de conflitos no repositório:

Abertura de Issue Centralizadora:
- Título: [Debate/Arquitetura] Interface do Usuário: Bot no Telegram vs. Web App Próprio
- Conteúdo: Apresentação imparcial das duas opções, elencando prós, contras, impactos no prazo da Milestone e restrições de entrega do Projeto Integrador.
Regras de Condução nos Comentários:
- Foco em Evidências e Restrições (sem ataques pessoais):
  - Incorreto: “Fazer um site é perda de tempo e vai atrasar tudo por capricho.”
  - Correto: “O tempo restante para o Check 02 é de 3 semanas. Desenvolver um front-end do zero em React consome cerca de 40% do nosso tempo útil, enquanto a API do Telegram nos permite ter a MVP rodando em 2 dias.”
- Análise de Matriz de Decisão (Custo x Benefício x Prazo):
  - Integrantes apresentaram estimativas de esforço em horas para cada opção e levantaram os requisitos cobrados na avaliação acadêmica.
Resolução e Registro (ADR):
- Decisão do Time (Agree or Commit): O grupo decidiu adotá-lo de forma híbrida/faseada — iniciar o MVP com a interface via Bot do Telegram para focar na lógica e respostas do modelo de IA e, caso o cronograma das Milestones permita, expor uma landing page/dashboard simples via Web posteriormente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

É necessário pois comunicação apenas verbal e não padronizada é suscetível a falhas por interpretação ou esquecimento de detalhes. Contratos e testes garantem que as especificações sejam todas cobertas no projeto.

A fronteira mais crítica é na integração da api e o backend do bot. Para garantir a integridade no backend foram definidos padrões rígidos de validação para validar a entrada e saída das requisições.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de perto: Comunicação próxima e frequente

Manter satisfeito: Comunicação concisa e de alto nível

Manter Informado: Comunicação transparente e contínua

Monitorar: Comunicação mínima/passiva

O professor age como avaliador de conformidade acadêmica para checar se a equipe aplicou os conceitos de engenharia de software corretamente a fim de perpetuar boas práticas de projetos. Um cliente comercial exige que tudo esteja funcionando corretamente, o professor garante que em ambiente de estudo.

Professor avaliador: professor de GPS, comunicação por marcos, alto poder e alto interesse

Usuário competidor: Alunos e professor, comunicação por marcos, baixo poder e alto interesse

Administrador da infra: API externa, comunicação eventual por patch notes, alto poder e baixo interesse

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A fórmula simula o comportamento quadrático da comunicação dos participantes pois prevê que nem todos os integrantes precisarão se comunicar diretamente, devido aos artefatos, grupos e papéis compartilhados a medida que o projeto cresce.

C(4) = 6

C(10)= 45

Uma conversa síncrona tem como base a interação imediata, útil para tratar de negociações, assuntos sensíveis, situações de urgência e descobertas, enquanto a assíncrona é mais adequada quando é possível elaborar documentos e elementos que propiciem rastreabilidade, como em mensagens por emails e relatórios.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 THALLES VINÍCIUS. (Matrícula: 20243014001, Login: @Thalles_cruz)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe deve buscar transparência com os stakeholders, explicando as soluções e também as limitações do chatbot, como possíveis alucinações, demora nas respostas e limites da API. Também devemos deixar claro que a nossa IA responde apenas dentro do escopo definido e com base nos documentos institucionais.

Serão implementadas a EAP e o cronograma, a Matriz RACI, a Matriz de Riscos com os planos de contingência e a Matriz de Stakeholders. Essas informações deverão ficar organizadas e acessíveis no GitLab, por meio dos documentos, Issues, Milestones e demais registros do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Colaborar: quando as pessoas trabalham juntas para encontrar a melhor solução. Conceder: quando uma das partes abre mão de algo para chegar a um acordo. Forçar: quando é necessário impor uma decisão para garantir a continuidade do projeto, podendo ser válido em situações de segurança. Apaziguar: quando se busca diminuir o conflito e chegar a um entendimento. Evitar: quando é melhor adiar a decisão por falta de informações suficientes.

No nosso projeto, podem surgir discussões sobre os prompts utilizados ou sobre a divisão das tarefas. Essas discussões devem ser mantidas no âmbito técnico, usando os comentários do GitLab para apresentar argumentos e registrar as decisões, evitando levar a discordância para o lado pessoal. A decisão deve considerar a responsabilidade de cada membro e o impacto para o projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

É necessário que haja contratos de registro daa decisões, somente assim é possível explicar decisões tomadas, encontrar erros e analisar e alinhar todas as expectativas do projeto! Além de testes contínuos em CI/CD para se verificar o que está sendo feito!

No nosso projeto, a principal fronteira de comunicação é entre o backend do bot e a API de IA, pois é onde os dados são enviados e recebidos. Para evitar problemas, usamos validações e testes contínuos no CI/CD, verificando se a comunicação está funcionando corretamente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de perto: pessoas com alto poder e alto interesse, mantendo uma comunicação frequente e acompanhando as decisões. Manter satisfeitos: pessoas com alto poder e baixo interesse, mantendo-as informadas sem sobrecarregar. Manter informados: pessoas com baixo poder e alto interesse, mantendo uma comunicação regular. Monitorar: pessoas com baixo poder e baixo interesse, acompanhando apenas quando necessário. O professor atua principalmente como Avaliador de Conformidade Acadêmica, verificando se o projeto atende aos requisitos e critérios da disciplina, diferente de um cliente comercial, que normalmente define necessidades de negócio e espera um produto específico.

No nosso projeto, o professor é um stakeholder com alto poder e alto interesse, então deve ser gerenciado de perto, principalmente nos marcos e entregas, usando o GitLab e as apresentações como canais oficiais. Os alunos do Cefet são stakeholders com baixo poder e alto interesse, então devem ser mantidos informados durante as validações do chatbot. Já o responsável pela API ou infraestrutura externa possui alto poder e baixo interesse no projeto, sendo mantido satisfeito e acionado quando houver algum problema ou necessidade relacionada ao serviço.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

Conforme a formula o N passa a ser quadrático, se migrarmos de 4 para 10 participantes ele salta de 6 para 45 canais de comunicação. O modelo assincro de comunicação facilita a documentação do projeto, uma vez que não necessita ambos estarem online, pode-se usar o modelo sincrono(reuniões. Whats app, slack) para discutir e alinhar expectativas e ideias, e mudar posteriormente para o modelo assíncrono, na hora de documentar e deixar registrado as decisões do projeto!

Considerando que o grupo possui 4 ocupantes, tem se 6 canais diretos e foi acordado utilizarmos os canais do gitlab, como issues para o modelo assíncrono de comunicação!

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VICTOR GABRIEL MA. (Matrícula: 20203004575, Login: @vicmagione)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe precisa declarar as limitações de forma explícita e antecipada, não deixar o stakeholder descobrir sozinho. O próprio bot já avisa no início que é um tutor socrático, não um oráculo perfeito . Em documentação e apresentações, deve ficar claro: respostas são probabilísticas, e cota/custo de API é finita. O essencial é separar o que o bot garante do que não garante.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo começa em explicitar o problema: tirar o conflito do campo implícito e colocar em palavras claras, sem acusação. Depois ouvir interesses e evidências: cada lado apresenta o porquê da posição, não só a posição em si. Em seguida decidir com responsabilidade: alguém toma a decisão, assumindo o resultado. Por fim registrar o impacto: documentar a decisão e suas consequências, pra não repetir o debate do zero depois.

As 5 posturas:

Colaborar: busca solução que atenda os dois lados, ideal quando há tempo e o problema é importante. Conceder: um lado cede no que importa menos pra ele, pra manter o relacionamento ou avançar rápido. Forçar: uma decisão é imposta sem negociação. Legítimo em emergência de segurança porque não há tempo pra debate, e a prioridade é agir. Apaziguar: prioriza a harmonia do grupo em detrimento do mérito técnico, só serve pra conflitos de baixo impacto. Evitar: adiar a decisão. Prudente quando faltam dados, porque decidir sem informação suficiente custa mais caro que esperar.

Dilema técnico real do WokMentor: escolha entre Ollama local versus API externa pro LLM, divergência entre o que o Termo de Abertura define e o que o spike já testou funcionando .

Resolução no GitLab: a discussão aconteceria numa Issue dedicada , com cada lado explicitando o argumento técnico e evidência . A decisão final vira uma ADR registrada no repositório, com o motivo documentado, assim o debate fica sobre dado técnico, não sobre quem “ganhou” a discussão, e qualquer pessoa nova no time entende o porquê sem reabrir a polêmica.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Alinhamento verbal depende de memória e interpretação humana, cada pessoa pode entender “unidade de impulso” de um jeito diferente, como aconteceu no Mars Climate Orbiter . Contrato explícito e teste automatizado eliminam essa ambiguidade: o formato é especificado por escrito e verificado por máquina a cada mudança, não por combinado de boca. Equipes diferentes não compartilham contexto tácito, então só o que está documentado e testado garante que os dois lados do contrato continuam compatíveis mesmo com o código evoluindo separadamente.

No WokMentor, a fronteira mais suscetível a erro é entre bot.py e core.py , e entre core.py e a API do LLM, é onde texto solto do aluno vira entrada estruturada pro modelo, e a resposta do LLM (texto livre, sem schema fixo) precisa ser interpretada antes de voltar pro aluno.

No estado atual do repositório, esse contrato ainda não está formalizado, não há schema Pydantic, validação de JSON nem teste de contrato no CI/CD; a troca entre as camadas é feita com string simples . Pra blindar isso de verdade, seria necessário definir um schema pro retorno do core , validar a resposta do LLM antes de repassar ao aluno, e rodar um teste de contrato automatizado no CI/CD garantindo que mudanças no core ou na API não quebrem o que o bot espera receber.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Os 4 quadrantes da Matriz Poder x Interesse:

Gerenciar de Perto : engajamento direto e frequente, reuniões, decisões consultadas com ele. Manter Satisfeitos : informado em pontos-chave, sem sobrecarregar, pra evitar que ele intervenha com poder de veto sem contexto. Manter Informados : atualizações regulares, canal aberto, mas sem exigir reunião. Monitorar (Baixo Poder / Baixo Interesse): esforço mínimo, só acompanhar se mudar de quadrante.

O professor é Avaliador de Conformidade Acadêmica, não “Cliente Comercial”, porque ele não compra nem usa o produto ,ele valida se o processo seguiu o método ensinado. Isso muda a evidência: não basta o produto funcionar, é preciso documentação e artefatos do processo provando que o raciocínio de gestão foi aplicado, não só o resultado final.

Stakeholders do WokMentor:

Professor Avaliador ,Alto Poder / Alto Interesse , Gerenciar de Perto. Cadência: por marco/entrega (checkpoints da disciplina). Canal oficial: Issues no GitLab e apresentações formais. Aluno usuário final ,Baixo Poder / Alto Interesse , Manter Informados. Cadência: no piloto/teste, via feedback direto no Telegram. Administrador da infraestrutura/API do Ollama , Alto Poder / Baixo Interesse ,Manter Satisfeitos. Cadência: monitorar mudanças pontualmente , sem contato constante.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

A fórmula C = N(N-1)/2 tem N², não 2^N ,por isso o crescimento é quadrático, não exponencial. Com N=4: C = 4×3/2 = 6 canais. Com N=10: C = 10×9/2 = 45 canais. Saltar de 4 pra 10 pessoas (2,5x mais gente) multiplica os canais por 7,5x — o esforço de coordenação explode muito mais rápido que o tamanho do time.

Síncrona (chat/WhatsApp/reunião) é rápida mas não deixa rastro, decisão se perde na rolagem. Assíncrona (Issue, Merge Request, ADR) é mais lenta, mas fica registrada e rastreável.

Decisões devem migrar pro assíncrono quando: envolvem arquitetura/trade-off (ADR), definem ou mudam escopo (Issue), ou alteram código (Merge Request) tudo que alguém vai precisar consultar depois, sem depender da memória do grupo.

Time: N=4 , C = 4×3/2 = 6 canais diretos. Incluindo o professor/orientador como interlocutor externo N=5 , C = 5×4/2 = 10 canais.

Política de comunicação assíncrona do grupo: toda decisão arquitetural vira ADR no repositório (ex.: ADR-001 sobre Telegram vs. Web), toda mudança de escopo ou risco vira Issue com label (Risco, Escopo), e qualquer código só entra via Merge Request revisado por outro integrante (RNF11) o WhatsApp fica só pra combinar horário de reunião, nunca pra registrar decisão técnica.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VICTOR OTAVIO SOU. (Matrícula: 20243001219, Login: @vsouza)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

Para alinhar as expectativas, a equipe deve adotar transparência proativa por meio de 3 ações:

Definição explícita de escopo: Tanto na interface, tanto na documentação, deve estar destacado que o Ágora.AI é um tutor socrático, não um gerador de respostas. Deixando o usuário ciente que ele não receberá código/respostas.

Avisos de limitação: Informar que os modelos de IA são probabilísticos e que podem gerar informações imprecisas, transferindo parte da responsabilidade da validação final ao aluno.

Transparência sobre a infraestrutura: A equipe deve deixar claro que o uso de APIs gratuitas, embute latências maiores e riscos de instabilidade.

Para o Check 02:

EAP/WBS: A divisão de entregas está no painel do GitLab, traduzida em Milestones(Módulo 1, Módulo 2 …) e as tarefas, divididas em Issues rastreáveis no Issue Board (Kanbam), sendo possível ver seu “status” - Open, Doing, Review, Close.

Matriz RACI: A matriz estará documentada no arquivo README.md deixando claro quem assume cada papel nas entregas técnicas e quem tem a autoridade de Reviewer.

Matriz de Riscos: Estará acessivel em um documento dedicado na pasta docs/. Nela vai conter as ameaças reais mapeadas, e os planos de contingências.

Matriz de Stakeholders: Também estará na aa Wiki do GitLab, mapeando quem tem interesse e poder sobre o projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Ciclos de Tratamento

Explicitar o problema: Foca no artefato técnic, não na pessoa (exemplo: a chamada da API demora 10 segundos, em vez de o seu código ficou lento)

Ouvir interesses e evidências: Levantar dados, logs de erro, documentação e custos. Já não se trata de opnião, e sim sobre métricas.
Decidir com responsabilidade: Autoridade da tarefa toma a decisão baseada no que gera maior valor para a Sprint atual, cortanto a paralisia decisória.
Registrar o impacto: Documentar o acordo no GirLab para que no futuro fique explicado o por que foi feito dessa forma.

Posturas Situacionais * Colaborar(Ganha-Ganha): A equipe busca a causa raiz e acha a solução ideal, exigindo alta maturidade. * Conceder/Reconciliar(Ganha-Perde parcial): Cada um cede um pouco (meio-termo). Rápido, mas gera soluções sub-ótimas. * Forçar/Impor(Ganha-Perde): Uso de autoridade. Essencial em emergências, mas destrói a moral se for a regra. * Apaziguar(Perde-Ganha): Focar nas áreas de concordância e recuar nas divergências para manter a paz. * Evitar/Retirar(Perde-Perde): Adiar o conflito para focar em coisas urgentes. O problema voltará no futuro.

Forçar pode ser interessante em momentos de emergência pois esses são os momentos mais caóticos, onde pode haver diferentes opniões e algumas pessoas podem não saber exatamente que decisão tomar, e nesse momento ter alguém para decidir pode ser importante. E o evitar também se torna importante, quando na falta de informações, você não decide modifcar nem fazer nada no momento, podendo evitar snowballs ou um problema do qual não terá solução (problema maior que o atual). 2. Até o momento não houve discussão entre os membros da equipe, porém no módulo 2 será quando definiremos sobre a gestão do limite de contexto (histórico de memória) do bot. Pode haver membros que vão querer salvar todo o histórico em um banco de dados para o bot não perder o contexto do aluno enquanto outro queira apenas algumas ultimas mensagens para economizar a franqua de tokens. Para garantir a segurança psicológica, devemos seguir: * Atacar o código, não o autor: Em vez de falar que “a ideia do banco vai ser um exagero , e vai atrasar a entrega”, o revisor pode falar “implementar o banco de dados vai adicionar uma complexidade não prevista. Que tal limitarmos em variáveis locais de sessão?”. * Argumentação baseada em evidências: O membro preocupado com o custo ao invés de só reclamar, pode anexar um print ou cálculo demonstrando que o envio do histórico estoura os limites da LLM em poucas requisições.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Sem a documentação comprovada (contrato) as equipes imaginaram que estavam alinhadas e seguiram cada um da sua forma. Se elas tivessem uma documentação oficial, não haveria essa falha na comunicação e posteriormente evoluído para a destruição do equipamento. Além disso, se eles tivessem realizado testes automatizados, haveria quebra na estrutura dos dados evitando o pior cenário (quebra no cenário real).

A fronteira mais frágil é a comunicação entre o backend e a API do LLM. Pois o LLM poded retornar uma resposta que não seja a que queremos (pois o tutor socrático não pode devolver a resposta pronta). Para blindar podemos usar uma validação estrutural de JSON (try/catch) e também utilizar validação semântica, passando o texto por um filtro de expressões regulares antes de ser enviado para a interface, impedindo que retorne uma resposta ao aluno.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

Gerenciar de Perto: Alto Poder + Alto Interesse - Tomam decisões críticas e se importam com o dia a dia. Precisam de comunicação constante e validações arquiteturais

Manter Satisfeito: Alto Poder + Baixo Interesse - É a diretoria ou coordenação. Eles têm o poder de cortar a verba ou cancelar o projeto, mas não querem saber os detalhes técnicos. Exigem relatórios executivos concisos.

Manter Informados: Baixo Poder + Alto Interesse - São os usuários finais. Eles vão consumir o produto no dia a dia, mas não decidem o rumo orçamentário. Necessitam de releases notes e tutoriais.

Monitorar: Baixo Poder + Baixo Interesse - Exigem esforço mínimo, apenas acompanhamento superficial para garantir que não migrem de quadrante.

O professor atua como Avaliador de Conformidade Acadêmica. Um cliente comercial foca no retorno sobre investimento (ROI) e no software rodando em produção. Já o professor foca na validação do processo de engenharia e na aplicação do método. Portanto, ele não quer apenas que o nosso chat bot responda as perguntas, ele quer ver toda a construção do projeto, organização dos membros da equipe e o desenvolvimento do mesmo. 2. * Professor - Gerenciar de Perto: Pois detém o poder da aprovação e alto interece metodológico em como a equipe aplica a engenharia de software. A cadência é por marco de entrega, e o canal oficial é o repositório do GitLab. * Usuário Maratonista do ICPC - Mater Informados: Os alunos que usarão o Ágora.AI para treinar programação têm interesse alto no tutro, mas zero poder de veto sobre decisões arquiteturais da equipe. A cadência poderia ser a cada fechamento de novas funcionalidades. E o canal oficial seria na interface final ao usuário. * Provedor da API (Manter Satisfeitos): O OpenRouter não tem interesse no sucesso acadêmico do grupo, mas tem poder para banir a chave de acesso ou tirar os modelos gratuitos do ar, paralisando o projeto. A cadência seria contínua, e o canal oficial seria os Logs de monitoramento do terminal e dashboard de consumo de tokens do provedor para garantir que a equipe não estoure os limites da camada gratuita.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O crescimento é quadratico pois quando tem apenas 4 integrantes, tem a necessidade de 6 canais, já quando se tem 10 integrantes, tem a necessidade de 45 canais. Na comunicação síncrona, os canais são caros e quebram o flow da programação, porém, a interação imediata pode ajudar na descoberta, negociação, urgência ou assunto sensível. Na assíncrona, o engenheiro pode ler no seu próprio tempo as issues, além de que os email e documentos favorecem a preparação, participação distribuída e a rastreabilidade.

Considerando N=4 (3 membros da equipe + professor). Aplicando a fórmula chegaríamos em C= 4(4-1) / 2 → C = 6. Para evitar problemas na comunicação o grupo definiu:

Comunicação Sincrona (WhatsApp): É usada para alertas, avisos de urgência, agendamento de reuniões.

Comunicação Assíncrona(GitLab): Se uma ideia foi discutida no chat, ela migra para o GitLab para ser validade, usando Issues para relatar bugs ou solicitar novas funcionalidade, além de merge requests(para aprovação).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VITOR EMANUEL VEN. (Matrícula: 20243000919, Login: @VitorEmanuelVS)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

É necessária uma capacidade de ancorar as expectativas dos stakeholders quando à solução. Os stakeholders não possuem apenas um perfil, de interesse e de poder sobre o projeto, além de outros fatores. Apesar disso, um ponto comum é que é dever do time explicar, de forma didática, as limitações dos modelos atuais nos pontos de interesse a cada um dos perfis dos stakeholders. São necessárias reuniões e/ou releases que demonstrem protótipos funcionais, que desmitifiquem a tecnologia passo a passo. O time pode atuar nas frentes:

Demonstração de Estresse (demonstração de cenários de como o modelo se comporta com situações fora do escopo) e Matriz de Escopo (do tipo Faz Vs. Não Faz).

Transparência na interface com o usuário, disclaimers diretos, mensagens delimitadoras para o usuário final.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

Ciclo:

Explicitar o problema: separar o pessoal do problema. Definir qual é a divergência de maneira objetiva. O foco é responder à pergunta: “Qual decisão precisa ser tomada?”

Ouvir Interesses e Evidências: dar espaço para os lados apresentarem os fatos, trade-off e restrições das opções.

Decidir com responsabilidade: a decisão deve ser tomada pelo responsável pelo dilema em questão ou por um consenso entre os envolvidos.

Registrar o Impacto: documentar o raciocínio, os riscos assumidos e as consequências que esperam. Esse conjunto de atitudes torna a decisão em aprendizado para o futuro e evita o retrabalho em problemas similares.

Posturas Situacionais: 1. Colaborar: investigar alternativas. A equipe busca a causa raíz e acha a solução ideal. Alta maturidade é necessária 2. Conceder: acordo aceitável quando prolongar custa mais. Cada um cede um pouco. Rápido, mas gera solução sub-ótimas. 3. Forçar/Impor: decisão autorizada, por exemplo em incidente. O gerente usa autoridade. Essencial em emergências, mas destrói moral se for a regra. 4. Apaziguar: enfatizar concordância ou ceder com impacto explícito. Focar nas áreas de concordâncias e recuar nas divergências para manter a paz. 5. Evitar: adiar para obter resultados ou reduzir tensão. definindo retorno. O problema voltará no futuro.

Impor pode ser necessário em cenários que não há tempo para discussão e a perda de união entre o time pode ser remediada mais facilmente que os problemas que a ausência de tomada de decisão poderia gerar.

Evitar em situações que o problema não está completamente desenhado ou há dificuldades com pontos de urgência mais altos pode ser o ideal a ser feito, voltando à demanda em um momento futuro. 2. Acredito que a padronização de commits e merge request poderia ser um problema caso o projeto fosse de natureza maior e escalável. Manter um padrão rígido seria o ideal, em contraste à maior rapidez de apenas adicionar a mudança feita, o que reduz rastreabilidade e manutenabilidade do código futuramente.

A discussão ligada a esse tipo de problema, deve ocorrer com foco nos méritos do problema e não nos indivíduos que fizeram aquilo que foge do padrão. Deve-se sempre recorrer à documentação existente e padrões estabelecidos. Deve-se ter a mente em resolver a situação e não em culpar membros do time.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

Em interfaces técnicas esse tipo de medida (contratos explícitos e testes automatizados) são extremamente necessários porque em trabalho com equipes diferentes é inerente o aumento de ruído oriundo de comunicação. Em trabalhos completamente técnicos, isso pode ser catastrófico, assim como no exemplo fornecido. O erro pode nascer do mal entendimento ou esquecimento de uma informação trazida durante o momento da comunicação verbal ou até pior, da definição de padrões por costume, não por estabelecimento dentro da regra de jogo, assim como aconteceu no cenário apresentado. Em trabalhos técnicos como esse, essas precauções são necessárias para afastar problemas, que poderiam sequer ser vistos até que um problema maior tivesse acontecido.

A fronteira entre backend e a API utilizada é o maior problema. Devido à natureza não-determinística do modelo, as respostas podem variar em seu formato, gerando falhas. Para se blindar desses problemas, serão necessários esquemas de validação da resposta fornecida pelo modelo; estruturação da saída usando de instruçõs padronizadas; testes de contrato em CI/CD.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

A matriz é formada pelo eixo X(interesse) e Y(Poder). Ela é concentrada no primeiro quadrante e partida em quatro seções:

Manter Satisfeitos (Alto Poder e Baixo Interesse): atender às expectativas sem sobrecarregá-los com detalhes operacionais;

Monitorar (Baixo Poder e Baixo Interesse): acompanhar pontuais mudanças sem alocar esforços desproporcionais;

Manter Informados (Baixo Poder e Alto Interesse): manter a motivação, colher contribuições e evitar o espalhamento de ruídos;

Gerenciar de Perto (Alto Poder e Alto Interesse): garantir alinhamento contínuo e engajamento ativo nos rumos do projeto.

Nesse cenário, o professor busca evidência de que houve aprendizagem durante o processo, através da aplicação de conceitos, cumprimento de etapas estabelecidas e seguimento de padrões de avaliação, já o cliente busca um resultado prático, algo que atenda a sua demanda. A entrega é avaliada de forma subjetiva pelo cliente, a partir daquilo que ele entende como correto no contexto do negócio, já o professor usa critérios objetivos dentro daquilo que foi estabelecido.

Dessa maneira, a ideia de “entrega” para cada um é muito diferente, para o cliente basta demonstrar um software funcionando dentro daquilo que ele deseja; para o avaliador acadêmico são necessários documentos, justificativas técnicas, rastreabilidade de requisitos e testes aprovados. 2. (Poder, Interesse, Cadência de Comunicação, Canal Oficial de Comunicação): 1. Avaliador: (Alto, Alto, Alinhado aos Marcos, Todo conteúdo de rastreabilidade e gerenciamento dentro do GitLab); 2. Usuários Finais do Assitente: (Baixo, Alto, A partir do momento que algum produto funcional esteja em teste ou produção, A própria interface ou formulário de feedback); 3. Colegas de Outros Grupos: (Baixo, Baixo, Em apresentações pontuais, Apresentações formais ligadas à disciplina).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

No modelo formal de conexões, é trabalhada a ideia de canais funcionando em pares, ou seja, comunicação: A <–> B constitue um par. Já em um modelo exponencial, o foco é a ideia de divisão em subgrupos por contexto, o que pode se tornar facilmente impossível de gerenciar à medida que o número de tarefas / trabalhos paralelos aumenta.

Agora, falando dos modelos de comunicação síncrona (reuniões, chamadas) e assíncrona (GitLab, Stack, e-mail):

Os modelos síncronos são caros e quebram o fluxo da programação. São úteias para negociação e resolução de crise

Já os modelos assíncronos, permitem que o elemento do time leia e efetue a tarefa em seu próprio tempo. São usados para emitir status e documentação.

O formato de comunicação síncrono é muito útil em vários momentos, mas é impraticável para gestão de projetos. Decisões são perdidas e podem excluir stakeholders que não estavam presentes no momento, além da alta chance de aumento de ruído de comunicação. 2. Em nosso cenário, o número n de stakeholders é 3 + 1 + 1 = 5: scrum master, project owner, developer, cliente (os três alunos) e professor. Nesse cenário, temos um número de canais diretos igual a 10. Temos como política de comunicação assíncrona: documentação atualizada em repositório do projeto, issues cadastradas no ambiente do GitLab e atualizadas ao longo do seu avanço. Toda contribuição com o projeto tem responsável e pode ou não ser aprovado pelo gerenciador.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VITOR OLIVEIRA CA. (Matrícula: 20243001059, Login: @Vitor)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: Expectativas de I.A., Limites de Escopo e Evidências para o Check 02

A equipe gerencia as expectativas dos stakeholders comunicando explicitamente as limitações inerentes dos modelos de linguagem, como alucinações, latência de rede, custos de cota e variações probabilísticas, por meio de diretrizes pedagógicas e restrições de comportamento que garantem que o usuário entenda o escopo exato do que o assistente faz e o que ele expressamente não faz, a exemplo da política de não entregar respostas prontas. Para a preparação do Check 02, o nosso grupo organizou e preparou as evidências obrigatórias de gestão no GitLab, sendo elas o termo de abertura do projeto Project Charter, o documento de requisitos estruturados, a estrutura analítica do projeto e o guia de regras pedagógicas, estando todas essas informações acessíveis diretamente na pasta docs do repositório.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Conflito Técnico como Informação de Projeto e as 5 Abordagens Situacionais

O ciclo de tratamento inicia explicitando o problema para expor divergências ouvindo interesses e evidências para separar pessoas das ideias decidindo com responsabilidade para avançar e registrando o impacto para gerar histórico técnico sendo que as cinco posturas diferem porque colaborar busca consenso ganha-ganha conceder cede para preservar a relação forçar impõe uma decisão sendo legítimo em emergências de segurança apaziguar reduz a tensão imediata e evitar recua quando faltam dados e no nosso projeto do professor agente enfrentamos um dilema técnico real sobre a definição das regras pedagógicas do system prompt e a estruturação dos dtos no backend em java spring onde a discussão ocorreu de forma transparente e estritamente nos comentários de issues e merge requests do gitlab mantendo a segurança psicológica e a despersonalização do debate com foco técnico e rastreabilidade total sem gerar atritos pessoais na equipe.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Caso Mars Climate Orbiter e os Contratos de Interface entre Partes

As interfaces técnicas entre subsistemas exigem contratos explícitos e testes automatizados porque alinhamentos verbais falham ao validar tipos unidades e estruturas de dados gerando quebras catastróficas na integração enquanto contratos rígidos e testes garantem a integridade do sistema e no nosso projeto do assistente a fronteira mais suscetível a erros de comunicação ocorre na camada de integração entre o backend em java spring e a api do gemini onde divergências no formato do json ou nos parâmetros de entrada causam falhas de resposta e para blindar esse contrato o grupo documentou as diretrizes do system prompt em arquivos markdown no gitlab estruturou os dtos de comunicação e validou a troca de dados para assegurar a consistência sem depender de conversas informais

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: Matriz Poder vs. Interesse e a Ilusão do “Professor como Cliente”

As estratégias da matriz exigem gerenciar de perto os de alto poder e interesse com reuniões semanais manter satisfeitos os de alto poder e baixo interesse com relatórios mensais manter informados os de baixo poder e alto interesse com atualizações quinzenais e monitorar os de baixo poder e baixo interesse com avisos por marco sendo que o professor atua como avaliador de conformidade acadêmica e não cliente comercial validando rubricas de engenharia de software e não mercado exigindo evidências em código versionado e issues em vez de uso comercial real e no nosso assistente mapeamos o professor avaliador em alto poder e alto interesse com entregas no gitlab o provedor da api externa em alto poder e baixo interesse com monitoramento de estabilidade e os colegas de outros grupos em baixo poder e baixo interesse com trocas semanais informais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Matemática dos Canais e a Armadilha do “Grupo de WhatsApp da Equipe”

O crescimento de canais de comunicação é quadrático porque o número de conexões segue a fórmula matemática combinatória onde quatro pessoas geram seis conexões e dez pessoas saltam para quarenta e cinco conexões mostrando que a complexidade de alinhamento explode com a informalidade do chat o que obriga a evitar a comunicação síncrona em decisões centrais e migrar para a comunicação assíncrona baseada em issues e merge requests no gitlab considerando que a nossa equipe do projeto Professor Agente possui dois integrantes gerando um canal direto único e a nossa política oficial estabelece que qualquer alteração ou definição arquitetural deve ser documentada exclusivamente via issues e solicitações de mesclagem para garantir rastreabilidade total sem duplicação de conversas paralelas

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🔴 Alunos que não entregaram (0 questões)

ANDERSON DE LIMA. (@limaanderson)
CARLOS EDUARDO (@CarlosEduardo)
FLÁVIO CORCINI DE. (@FlavioCorcini)
GABRIEL SILVA GON. (@mewndigo)
HUGO VICENTE COEL. (@hugovicente)
RAFAEL DE OLIVEIR. (@RafaelPedrosa)
SAULO DIAS DE OLI. (@Saulo)

De volta ao topo