Data de Publicação

28/09/2026

Data de Modificação

28/09/2026

Questionário e Gabarito - Aula 7: Comunicação e Stakeholders (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 7 (Aula 7: Comunicação e Stakeholders). O prazo final geral (Milestone) é 04/10/2026 (Domingo).

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

Due Date: 2026-10-04

Texto da Issue

Em projetos de software, a ilusão da comunicação informal (“resolvemos tudo no WhatsApp”) cobra um preço alto conforme a equipe e os envolvidos crescem. O modelo formal de conexões estabelece que a quantidade de pares de comunicação é dada por:

\[C = \frac{N(N-1)}{2}\]

  1. Explique por que o crescimento de canais de comunicação é quadrático (\(O(N^2)\)) e não exponencial, demonstrando o que acontece quando o número de participantes salta de 4 para 10 pessoas. Em seguida, estabeleça o contraste técnico entre comunicação Síncrona e Assíncrona, apontando em quais situações as decisões do projeto devem obrigatoriamente migrar para o modo assíncrono (Issues, Merge Requests e ADRs) em vez de permanecerem no chat.
  2. A regra de fluxo no repositório do seu time: No projeto do seu Assistente I.A., calcule o número de canais diretos considerando os membros da equipe e os principais interlocutores externos. Descreva qual política oficial de comunicação assíncrona o grupo definiu para garantir rastreabilidade das decisões arquiteturais sem gerar sobrecarga ou conversas duplicadas.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente conceituais sem os dados reais do seu grupo não atingirão a nota máxima.)

Gabarito / Rubrica de Correção

  • Excelente (10): Demonstra rigor matemático ao refutar o crescimento exponencial (provando que é quadrático), calcula corretamente o salto de 6 para 45 pares; fundamenta os critérios de síncrono vs. assíncrono com foco em rastreabilidade; detalha a política real de governança de comunicação aplicada no repositório do time.
  • Bom (7): Conhece a fórmula, mas confunde crescimento exponencial com quadrático, ou apresenta regras genéricas de equipe (“tentamos avisar todo mundo”).
  • Insuficiente (0): Erra a conceituação de canais e defende que canais informais de mensagens instantâneas substituem o rastreamento em repositório.

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

Due Date: 2026-10-04

Texto da Issue

A Matriz de Poder vs. Interesse não é um rótulo estático ou imutável, mas uma hipótese inicial de engajamento que deve ser revisada sempre que requisitos, riscos ou recursos mudam. Além disso, uma falha clássica em projetos universitários é confundir os papéis de Professor/Avaliador, Cliente, Patrocinador (Sponsor) e Usuário Final.

  1. Detalhe as estratégias de comunicação recomendadas para os 4 quadrantes da matriz (Gerenciar de Perto, Manter Satisfeitos, Manter Informados e Monitorar). Explique por que o Professor da disciplina atua primordialmente como Avaliador de Conformidade Acadêmica e não como “Cliente Comercial”, e como essa distinção altera o tipo de evidência que deve ser entregue.
  2. O Mapa de Stakeholders do seu Assistente I.A.: Mapeie 3 stakeholders reais do seu projeto integrador (ex: Professor Avaliador, Usuário Competidor do ICPC, Administrador da Infraestrutura/API externa, Colegas de outros grupos). Posicione cada um na matriz justificando a cadência (diária, semanal, por marco) e o canal oficial de informação.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Articula com clareza a dinâmica dos 4 quadrantes; desconstrói o mito do “professor-cliente”, compreendendo o papel de auditor/avaliador que exige evidências formais; mapeia stakeholders legítimos do Assistente IA com canais e cadências proporcionais.
  • Bom (7): Descreve a matriz, mas mantém uma visão ingênua do professor como “cliente que pede funcionalidades” ou mapeia stakeholders genéricos.
  • Insuficiente (0): Confunde os quadrantes ou ignora o mapeamento prático no projeto integrador.

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

Due Date: 2026-10-04

Texto da Issue

Em 1999, a sonda espacial Mars Climate Orbiter foi destruída ao entrar na atmosfera de Marte devido a uma discrepância de unidades de medida: o software de solo da Lockheed Martin calculava impulsos em libras-força segundo (imperial), enquanto o sistema de navegação da NASA JPL esperava newtons-segundo (métrico). Engenheiros de software experientes sabem que esse desastre não foi uma simples falha de conversa, mas sim a ausência de contratos de interface verificáveis e testes de integração.

  1. Sob a perspectiva da gestão da comunicação e qualidade, por que interfaces técnicas entre subsistemas desenvolvidos por pessoas ou equipes diferentes exigem contratos explícitos e testes automatizados, em vez de dependerem de alinhamentos verbais?
  2. A interface verificável do seu Assistente I.A.: No seu projeto (que conecta a interface do usuário — Telegram/Web —, o backend do bot e as APIs de LLM/Gemini):
    • Onde se localiza a fronteira mais suscetível a erros de comunicação entre dados/módulos?
    • Como o grupo documentou e blindou esse contrato no repositório (ex: contratos OpenAPI/Swagger, schemas Pydantic, validação de JSON, testes de contrato em CI/CD)?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Analisa com maturidade técnica o caso Mars Climate Orbiter como falha de especificação e verificação de interfaces; identifica a fronteira exata de integração do Assistente IA e descreve a solução técnica de contrato adotada no código/GitLab.
  • Bom (7): Entende o problema das unidades da NASA, mas trata a solução no projeto como “conversar mais com os colegas” em vez de mecanismos formais de engenharia de software (schemas/validações).
  • Insuficiente (0): Desconhece a lição do caso da NASA ou não identifica interfaces no próprio projeto.

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

Due Date: 2026-10-04

Texto da Issue

Em times ágeis e de engenharia, conflito não deve ser suprimido nem tratado como desvio pessoal: o conflito é informação valiosa sobre incertezas, restrições ou visões divergentes do projeto. O segredo está em despersonalizar o debate e adotar uma estratégia adequada à situação.

  1. Explique o ciclo de tratamento: Explicitar o problema \(\rightarrow\) Ouvir interesses e evidências \(\rightarrow\) Decidir com responsabilidade \(\rightarrow\) Registrar o impacto. Em seguida, diferencie as 5 posturas situacionais: Colaborar, Conceder, Forçar, Apaziguar e Evitar, justificando por que “Forçar” pode ser legítimo em emergências de segurança e “Evitar” pode ser prudente quando faltam dados.
  2. Resolução de conflitos no GitLab: Apresente um dilema técnico real que ocorreu (ou que é iminente) na sua equipe (ex: SQLite vs. Banco Vetorial, limites de contexto do prompt, divisão de tarefas do Check 02). Como a discussão ocorreu (ou deve ocorrer) nos comentários do GitLab para manter a segurança psicológica sem transformar discordâncias técnicas em atritos pessoais?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Descreve as 5 posturas desmistificando rótulos morais (entende o contexto de cada uma); fundamenta o papel da segurança psicológica e da transparência em code reviews/issues; relata um dilema técnico autêntico do time.
  • Bom (7): Cita as abordagens, mas julga que “Colaborar é sempre a única opção certa” ou traz um exemplo fictício sem aderência ao repositório.
  • Insuficiente (0): Enxerga conflito como briga de ego ou sugere que divergências devem ser abafadas pela liderança.

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

Due Date: 2026-10-04

Texto da Issue

A Inteligência Artificial Generativa sofre com o “Efeito Demonstração”: quando os stakeholders veem uma demonstração inicial rápida, criam a falsa expectativa de que o assistente responderá a qualquer pergunta com perfeição instantânea. Contudo, protótipos rápidos não substituem engenharia de requisitos, testes e tratamento de limites.

  1. Como a equipe deve comunicar e gerenciar as expectativas dos stakeholders sobre as limitações inerentes dos LLMs (alucinações, latência de rede, custos de cota e variações probabilísticas), garantindo que o usuário entenda o que o bot faz e o que ele expressamente não faz?
  2. Preparação para o Check 02: Na próxima aula ocorre o fechamento do Módulo 2. Liste as 4 evidências obrigatórias de gestão que o seu grupo já preparou e organizou no GitLab (ex: EAP/WBS e cronograma rastreável em Milestones, Matriz RACI de responsabilidades, Matriz de Riscos com plano de contingência e Matriz de Stakeholders). Indique onde essas informações estão acessíveis no repositório.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Articula estratégias maduras para gerenciar o gap entre hype de IA e restrições reais de engenharia; lista com exatidão as entregas gerenciais do Check 02 e aponta suas localizações concretas no GitLab (Wiki, Docs, Issues, Milestones).
  • Bom (7): Reconhece que LLMs têm limites, mas é vago quanto às evidências gerenciais exigidas pelo Check 02.
  • Insuficiente (0): Acredita que o assistente não possui limitações a comunicar ou ignora as evidências exigidas pela disciplina.
De volta ao topo