Published

20/08/2026

Modified

20/08/2026

Relatório de Avaliação - L01

Gerado em 20/08/2026 01:52:37

📊 Resumo de Entregas

Aluno Q1 Q2 Q3 Q4 Q5 Total
ANDRÉ GUILHERME R. ✅ ✅ ✅ ✅ ✅ 5/5
ARTHUR BALTAR ELE. ✅ ✅ ✅ ✅ ✅ 5/5
CARLOS ESTEVÃO ✅ ✅ ✅ ✅ ✅ 5/5
CARLOS MATHEUS ✅ ✅ ✅ ✅ ✅ 5/5
DANYEL MARTINS ZI. ✅ ✅ ✅ ✅ ✅ 5/5
DAVI JOSÉ DO NASC. ✅ ✅ ✅ ✅ ✅ 5/5
EVELYZE PINHEIRO. ✅ ✅ ✅ ✅ ✅ 5/5
FILLIPE TOMAZ CAR. ✅ ❌ ❌ ❌ ❌ 1/5
GABRIEL CAMPOS MA. ✅ ✅ ✅ ✅ ✅ 5/5
GABRIEL PINHEIRO. ✅ ✅ ✅ ✅ ✅ 5/5
GABRYEL FERREIRA. ✅ ✅ ✅ ✅ ✅ 5/5
ISAÍAS CÉSAR SAMP. ✅ ✅ ❌ ❌ ❌ 2/5
JOÃO VÍTOR MARQUE. ✅ ✅ ✅ ✅ ✅ 5/5
LETICIA MAURICIO. ❌ ✅ ✅ ✅ ✅ 4/5
MATHEUS MATOS BOT. ✅ ✅ ✅ ✅ ✅ 5/5
NATHAN BALMANT DE. ✅ ✅ ✅ ✅ ✅ 5/5
RONALD RODRIGUES. ✅ ✅ ✅ ✅ ✅ 5/5
SABRINA EVELYN SI. ✅ ✅ ✅ ✅ ✅ 5/5
SAMUEL BRUM LELLE. ❌ ✅ ✅ ✅ ✅ 4/5
SAULO DIAS DE OLI. ❌ ✅ ✅ ✅ ✅ 4/5
THALLES VINÍCIUS. ✅ ✅ ✅ ✅ ✅ 5/5
VICTOR GABRIEL MA. ✅ ❌ ❌ ❌ ❌ 1/5
VICTOR OTAVIO SOU. ✅ ✅ ✅ ✅ ✅ 5/5
VITOR EMANUEL VEN. ✅ ✅ ✅ ✅ ✅ 5/5
VITOR OLIVEIRA CA. ✅ ✅ ✅ ✅ ✅ 5/5
——————– ❌ ❌ ❌ ❌ ❌ 0/5
ANDERSON DE LIMA. ❌ ❌ ❌ ❌ ❌ 0/5
BIANCA DA SILVA B. ❌ ❌ ❌ ❌ ❌ 0/5
CARLOS EDUARDO ❌ ❌ ❌ ❌ ❌ 0/5
FLÁVIO CORCINI DE. ❌ ❌ ❌ ❌ ❌ 0/5
GABRIEL ALVARENGA. ❌ ❌ ❌ ❌ ❌ 0/5
GABRIEL SILVA GON. ❌ ❌ ❌ ❌ ❌ 0/5
HUGO VICENTE COEL. ❌ ❌ ❌ ❌ ❌ 0/5
JOÃO CARLOS FERRE. ❌ ❌ ❌ ❌ ❌ 0/5
MARIA LUIZA PENA. ❌ ❌ ❌ ❌ ❌ 0/5
MATEUS SILVA LOPE. ❌ ❌ ❌ ❌ ❌ 0/5
PEDRO CLAUDIO JAC. ❌ ❌ ❌ ❌ ❌ 0/5
RAFAEL DE OLIVEIR. ❌ ❌ ❌ ❌ ❌ 0/5
RHUAN GABRIEL CAN. ❌ ❌ ❌ ❌ ❌ 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: Por que código bom não basta?

Um dos problemas é com as regras de negócio, sem uma gestão pra poder planejar elas é impossivel gerar um código para solucionar o problema sem um problema bem definido, e outro problema é o código bom em si não fala sobre o projeto e sem uma documentação própria pode ser díficil expandir sobre ele

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder um bug debaixo do tapete para cumprir um prazo você corre o risco de um usuário do sistema passar por esse bug na produção, o que pode causar um enxame de problemas para a empresa dependendo do bug, por isso é sempre melhor ser transparente no processo e sempre anunciar bugs

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Corrigir de forma superficial um problema para alcançar um prazo pode fazer o problema voltar de forma mais severa, com até possiveis problemas em produção que afetam diretamente o cliente

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Se é necessário atencipar o lançamento de um software em 1 mês e não é possivel aumentar o orçamento, seria necessário negociar o escopo do projeto de acordo com o triângulo de ferro, que é composto por tempo, custo e escopo, como o tempo e custo permanecem fixo a única variável nesse projeto seria o escopo dele, sendo ele o que vai definir a qualidade do projeto que é inegociavel

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

📝 Questão 1: Projetos vs. Operações na Prática

Projetos eram os trabalhos que os professores davam um tempo maior para fazer e tinham uma especificação maior e operações pode ser as listas de atividades que alguns professores passavam semanalmente, que não tinham muitas informações, eram mais simples e era algo que eu tinha que fazer constantemente cada semana

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: Por que código bom não basta?

O primeiro motivo que eu penso se deve aos ruídos na comunicação humana. O problema nesse caso não é técnico, é de alinhamento e ponto de vista. Sem formalidades, ao final do projeto vai estar tudo diferente do esperado, e com pouco ou nenhum tempo para rastrear os erros e corrigir.

O segundo motivo que eu coloco é muito psicológico, é o já citado ego. Com o tempo, as pessoas se apegam ao próprio código como uma extensão do próprio ser, então qualquer crítica ao trabalho costuma ser entendida como um ataque pessoal, porque a pessoa se enxerga como parte daquilo. Não só no trabalho, mas percebe-se esse padrão em várias áreas da vida. Portanto, o processo formal aqui é muito útil para tirar o emocional da jogada e colocar um árbitro para preservar a parte racional, então aqui entra a revisão por pares, documentação e métricas objetivas de qualidade no geral.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A diferença é que esconder o bug não ajuda em nada, só posterga a descoberta, acumulando o problema como uma bola de neve. Além disso, se não for reportado, ninguém no time vai saber que aquele problema existe, então outras partes do sistema podem ser construídas em cima dele, o que espalha o erro para mais lugares. Isso afeta a credibilidade do desenvolvedor no longo prazo.

Já reportar o bug cedo numa reunião de alinhamento permite que o time todo saiba do risco, decida junto como agir (corrigir agora, isolar o problema, ou aceitar o risco conscientemente) e evita que outras pessoas construam código dependendo de algo quebrado.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Porque fazer de qualquer jeito vai causar prejuízos no futuro. Se pularmos ou atropelarmos as etapas corretas de implementação, uma hora essa bomba vai estourar e vamos ter que voltar para arrumar. Então, o tempo ganho agora será pago no futuro de alguma forma e com juros, porque corrigir um bug em produção sempre custa mais caro do que ter feito certo desde o início.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Para se ter uma entrega de alta qualidade é necessário equilibrar 3 fatores: tempo, escopo e custo. Uma vez que vocês propõem antecipar o tempo em 1 mês, vai ser necessário balancear as outras variáveis de acordo. Porém, vocês não querem contratar desenvolvedores. Então, como se decidiu manter o custo fixo e antecipar a entrega, necessariamente precisaremos alterar o escopo do projeto. Do contrário, a qualidade do serviço ficará extremamente comprometida, o que geraria mais custos no futuro, para eventuais correções de bugs em produção e manutenção custosa.

Sendo assim, em métodos ágeis, como o Scrum, conseguiríamos construir um MVP (Produto Mínimo Viável), entregando o maior valor no menor tempo disponível, optando por cortar funcionalidades secundárias (o que vai ser cortado deve ser decidido e classificado junto com a equipe).

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

📝 Questão 1: Projetos vs. Operações na Prática

O projeto mais bem definido que vivenciei até aqui na graduação foi na disciplina de Compiladores, com a implementação de um Compilador Mini-Pascal. O escopo era fechado desde o início: as fases estavam bem delimitadas e o fim era claro. Cada etapa tinha seu próprio entregável, o que reforçava a ideia de um esforço temporário, com começo, meio e fim bem marcados.

Já em relação à operação, o exemplo que mais se aproxima foi a disciplina de Desenvolvimento de Sistemas, na qual implementamos uma biblioteca. Diferente do compilador, esse projeto não tinha um fim natural: começamos, mas era um processo contínuo de commits, ajustes e evoluções, que inclusive ainda poderia continuar sendo desenvolvido e aprimorado até hoje.

A diferença que percebo entre os dois casos é justamente essa: no compilador, o objetivo era entregar um resultado único e específico, e quando isso foi alcançado o trabalho terminou. Já na biblioteca, o objetivo era criar, manter e evoluir um sistema, sem um ponto de encerramento definido e nem tarefas sequenciais.

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: Por que código bom não basta?

Acredito que as principais razões para adotar essas ferramentas são:

  • Falhas de comunicação: Muitas vezes “só falar” não adianta, é muito complexo descrever uma tarefa de desenvolvimento apenas por conversa. Essas falhas geram aquele classico problema do telefone sem fio, onde uma pessoa passa a informação para a outra conforme a sua propria interpretação. Isso gera divergencia e problemas sérios para a qualidade de um projeto.
  • Expectativas irreais: um grande problema é que nós tendemos a achar que conseguimos fazer tudo rápido. Se não tiver um planejamento bem definido, não conseguimos ver com clareza possíveis problemas que podem ocorrer durante o desenvolvimento, ocasionando em atrasos.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug durante o desenvolvimento é ignorar uma bomba que pode explodir a qualquer momento em que software estiver em produção. Isso tudo pode custar muito mais caro do que alterar a data de entrega do projeto ou reduzir o escopo para focar na solução do bug.

Ao reportá-lo imediatamente, o dev deixa os superiores cientes de que há um problema que precisa ser resolvido e que pode ocasionar em prejuisos e complicações graves no futuro.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Um código mal feito gera bugs e desorganização, fazendo o time perder tempo apagando incendios no futuro, se a aplicação estiver em produção o time vai precisar ficar corrigindo esses bugs e refatorando código em vez de focar na adição de features. A melhor forma de ajustar prazos é fazendo redução de escopo do projeto, assim é possível fazer em menos tempo com o mesmo investimento um MVP e depois adicionar as novas features aos poucos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é composto por três variáveis (Escopo, Tempo e Custo) e a qualidade é o centro. Como a diretoria reduziu o tempo, e travou o custo, a única variável flexível para não afetar a qualida é o Escopo. Portanto, eu recomendaria a redução do escopo dessa primeira entrega, dando prioridade para as funcionalidades esssenciais, e deixando as secundarias para uma versão futura.

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

📝 Questão 1: Projetos vs. Operações na Prática

Durante meu tempo na Commit Jr., participei de diversos projetos de sites e sistemas com início, meio e fim bem estabelecidos. A parte inicial consistia na coleta de requesitos com o cliente e no planejamento do projeto; o meio, na execução e desenvolvimento; e o fim, nos ajuste pontuais, entrega e implantação do sistema.

Muitas vezes também era necessário realizar operações contínuas, como atualizações de conteúdos e pequenas manutenções periódicas.

De forma geral, um projeto tende a ter datas de início e fim definidas, criando um fluxo ou produto completamente novo. Por outro lado, uma operação não tem uma data final pré-determinada, seguindo um fluxo padronizado e repetitivo voltado para a sustentação de estabilidade do que já foi entregue.

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: Por que código bom não basta?

O ego muitas vezes pode acabar “cegando” uma pessoa, não aceitando que ela não consegue resolver determinado problema sozinha. Com isso, são geradas as falhas na comunicação, pois não serão reportados os impedimentos e, como consequência, o projeto pode estagnar, causando prejuízos para a equipe.

As expectativas irreais também são problemáticas, as vezes querer demais ou buscar coisas que estão além do alcance atual pode acabar prejudicando o desenvolvimento de determinado projeto, até mesmo afetar a moral de uma equipe inteira. O sentimento de falha e de que não é “bom o suficiente para fazer aquilo” acabam afetando diretamente a disposição das pessoas, podendo gerar atrasos, falta de criatividade para resolver os obstáculos, perda da vontade de realizar o projeto, abandono.

Os processos formais ajudam a reprimir parte da natureza humana, pois seguir etapas, criar um planejamento, executar, monitorar e controlar tanto pessoas individualmente quanto uma equipe inteira, possibilitam que nada fique para trás e tudo seja visto, analisado e moldado aos poucos, permitindo que o projeto seja entregue com a maior qualidade possível.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Durante a construção de um projeto, é necessário a comunicação clara e contínua. Com isso, é essencial a humildade em reconhecer e reportar a própria situação atual, seja, principalmente, por estar travado em alguma parte do desenvolvimento por causa de erros ou bugs. Ademais, esconder as falhas podem acarretar em problemáticas futuras e que geram transtornos tanto para a própria equipe quanto para o cliente.

Sendo assim, buscar ajuda e comunicar a equipe são formas maduras e éticas de agir, permitindo alterações precisas nos planos para que tudo ainda consiga ser entregue na maior qualidade possível.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

É uma bomba-relógio porque pode acabar gerando uma dívida técnica, que são os custos futuros de soluções rápidas ou decisões abaixo do ideal tomadas durante o desenvolvimento de software. Sendo assim, sacrificar a qualidade do código vai acarretar na cobrança de altos juros no futuro com manutenções impossíveis e quedas críticas em produção.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Caro membros da diretoria, venho lhes informar que conseguiremos antecipar o lançamento do software, garantindo a exclusividade de seu produto e a liderança no mercado. Entretanto, devo-lhes explicar um conceito muito comum da área antes, para que não haja dúvidas do que será realizado. Quando estamos desenvolvendo um projeto, nós lidamos com três importantes restrições que seriam o Escopo, o Tempo e o Custo, sem que isso afete absolutamente em nada na qualidade final do produto. Tendo em vista que, o nosso objetivo é reduzir o tempo sem que ocorra custos adicionais, é necessário que abordemos uma metodologia mais ágil, sendo assim iremos realizar a criação de um MVP (Produto Viável Mínimo) para que possamos fazer uma análise do Escopo e decidir como entregar o maior valor possível no tempo disponível, com isso talvez seja necessário o corte de algumas funcionalidades secundárias. Todavia, elas poderão ser entregues em atualizações do software através de operações futuras, se assim desejarem!

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

📝 Questão 1: Projetos vs. Operações na Prática

Ainda não comecei um estágio. Entretanto, durante a faculdade participei de várias atividades e acredito que a maioria delas eram/são projetos, como trabalhos que eu iniciava no início do semestre, ia evoluindo e desenvolvendo eles conforme a curva de aprendizado de determinada disciplina (do professor que passou a atividade) aumentava com as aulas e permitia a progressão deles (Um exemplo seria o projeto de Compiladores realizado no semestre passado). Além disso, existem pequenos projetos mais simples, que eu realizei, com a produção de slides e de simples pesquisas que permitia uma entrega mais rápida, mas ainda sim concisa (Fiz isso em matérias como Otimização I).

Ademais, faço parte de uma empresa júnior chamada Commit Jr., acredito que realizei tanto projetos quanto operações até o momento nesse caso, porque eu participei de propostas que apresentavam início, meio e fim, e, após a finalização, geralmente nós cuidamos apenas de algumas manutenções periódicas!

Não acredito que eu tenha participado de “Operações” suficientes para ter uma separação tão profunda, mas acredito que eu me empenhe mais em cumprir as metas diárias que eu mesmo proponho para mim mesmo em meus projetos (fazendo ele de pouquinho a pouquinho, acompanhando os prazos para que ele consiga funcionar, ser feito de maneira correta e as vezes corrigir falhas), como: “Quero terminar essa parte até hoje e deixar essa para amanhã”, já as operações serem revisadas conforme a necessidade (se for uma vez ou duas na semana, planejar direitinho para revisar/resolver sem que comprometa quaisquer outro compromisso).

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

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

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

📝 Questão 5: Por que código bom não basta?

O uso da Gestão Ágil ou de métodos, tem como objetivo organizar toda a estrutura do projeto para que seja possível alinhar o objetivo do projeto com o que será desenvolvido, com intuito que o programador deixe desenvolva alguma funcionalidade ou desenvolva algo inútil. Assim, utilizando esses métodos é possível otimizar o tempo de produção como também organizar a equipe para que todos estejam em sincronia.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um Bug por mais que seja algo simples pode trazer consequências futuras para o projeto, erros que podem chegar em outras funcionalidades do sistema como também levar a um possível gasto de tempo da equipe para analisar e corrigir o bug. Diferente de esconder o bug, ser transparente facilitaria para a equipe em buscar uma solução com mais facilidade já que não seria necessário sofrer no futuro em algum momento e organizar a equipe com mais facilidade para corrigir o bug com mais velocidade.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Essa baixa qualidade trás diversos prejuízos a equipe e para o projeto. Ao sacrificar a qualidade do código, aumenta-se a quantidade de erros e posteriormente há uma dificuldade maior na manutenção, sendo necessário um gasto de tempo maior para implementar as correções nas próximas funcionalidades. Assim, por mais que a entrega estará dentro do prazo, trará uma dívida, que será cobrado no futuro.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Com o custo mantido e o tempo de entrega reduzido, deverá alterar o escopo que simplesmente será “piorado” ou deixará de ter algumas funcionalidades que não seriam tão importantes de imediato. Portanto, o método utilizado será o Método Ágil, na qual quando o custo e o tempo soa fixos (valor e tempo já definidos e não podem ter alterações) o escopo é o único que a ser alterado.

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

📝 Questão 1: Projetos vs. Operações na Prática

Até o momento não estive em nenhum estagio, portanto todos os projetos foram feitos pra faculdade, os considerados “projetos” foi o trabalho final de Desenvolvimento de Sistemas(https://github.com/Elielvitor45/Trabalho-Final-DS) e um trabalho de POO que dei uma atenção amais sobre ela (https://github.com/DanyelZini/Processamento-PGM-em-Matriz-Esparsa), esses dois são exemplos de projetos que eu tive como intuito tanto iniciar o projeto com intuito de postar no GitHub em especifico e “documentar” antes e depois da finalização do projeto. Para aqueles que eu considero “operações” são aqueles voltados a somente resolver o problema ou a entrega de algo.

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

🟢 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: Por que código bom não basta?

Processos formais não servem apenas para garantir a qualidade do código, mas também para garantir que todo o material humano que está em contato com o projeto estará na mesma página e com os mesmos objetivos. Um exemplo disso seria os possíveis problemas de comunicação. Dois bons programadores podem ter ideias diferentes para resolver o mesmo problema e em caso de cada um implementar uma parte separadamente sem ter uma comunicação clara e esclarecedora com o com outro resultará em um software com problemas, mesmo ambos escrevendo um bom código. Outro exemplo que não envolve só os programadores em si mas o cliente também são as expectativas que podem ou não ser atendidas. É comum uma pessoa de fora da área imaginar coisas para um software que não são realmente possíveis de serem feitas, sejam pela limitação técnica ou por compatibilidade com o projeto, se essas requisições forem colocadas como metas sem uma comunicação entre o cliente e o profissional é capaz de gerar um projeto com erros ou limitado.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Quando um bug é escondido ele acaba se tornando um problema futuro. Com o passar do tempo é capaz do projeto crescer e o tempo para revisitar esses erros e conserta-los diminui, até chegar em um ponto onde ele é exposto e se torna um problema real ou se torna um empecilho para o crescimento do software, podendo comprometer tudo que veio depois dele. Ao reportar o erro precocemente é mais fácil de tratar o problema e exclui a possibilidade de um problema inicialmente pequeno escalar em algo maior com o projeto já mais avançado.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Entregar o projeto “de qualquer jeito” para cumprir um prazo gera a chamada divida técnica. Esse código feito às pressas entrará em produção e será exposto a todos os ambientes reais, podendo causar bugs e problemas sérios que causaram um prejuízo maior que um adiamento, e, mesmo em caso de não haver bugs esse código com menos qualidade dificultará manutenções futuras e a implementação de novas funcionalidades, causando um efeito bola de neve que diminuirá a produtividade.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O planejamento da criação do software foi feito com base no calendário original, ou seja, toda a divisão de trabalho junto com o escopo do projeto foi planejado para se encaixar em um contexto especifico. Mudando o prazo para pior e não negociando essa mudança para a melhora de outro ponto, seja diminuindo o escopo ou aumentando a força de trabalho, se torna impossível garantir a qualidade original. Uma mudança drástica como a de diminuição de um 1 mês no prazo original pede uma realocação dos recursos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Trabalhos como o projeto em Modelagem de Sistemas que gerou um novo projeto em Desenvolvimento de Sistemas. Para mim um projeto é algo com mais potencial e demandas definidas onde é possível estimar desde o começo qual o trabalho que iremos ter.

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

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

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

📝 Questão 5: Por que código bom não basta?

Uma razão é a falha de comunicação. Cada pessoa envolvida em um projeto carrega uma imagem mental diferente do que está sendo construído. Sem um processo formal para alinhar essas imagens continuamente, cada um segue trabalhando com base na sua própria interpretação, e essas interpretações divergem silenciosamente ao longo do tempo. Um código bem escrito resolve exatamente o problema que o desenvolvedor entendeu que deveria resolver. Se o entendimento estava errado desde o início, código perfeito == solução perfeita para o problema errado. Isso não é bug de sintaxe, é falha de alinhamento entre pessoas. Processos como reuniões de refinamento, sprint reviews e documentação de requisitos existem justamente para forçar pontos de verificação regulares onde as divergências de entendimento são expostas cedo, antes de virarem código construído sobre uma premissa errada. Sem isso, você só descobre o desalinhamento na entrega final, quando já é caro demais para corrigir.

Outra razão seriam as expectativas irreais. Seres humanos são sistematicamente otimistas ao estimar prazos e subestimam a probabilidade de imprevistos. Um desenvolvedor tende a estimar quanto tempo levaria se tudo desse certo, não o tempo realista considerando bugs, dependências, reuniões, doenças, mudanças de escopo. É desconfortável admitir “não sei quanto tempo isso vai levar” ou “posso ter subestimado”. Muitos profissionais preferem dar um número otimista e “se virar depois” a admitir incerteza publicamente, especialmente diante da diretoria. Nenhuma quantidade de habilidade de programação corrige um viés cognitivo. É um problema de julgamento humano sob pressão social, não de conhecimento técnico. Por isso a gestão formal é indispensável: técnicas como estimativa em grupo e métricas históricas de velocidade no Scrum existem exatamente para corrigir estatisticamente esse viés, tirando a estimativa da opinião individual otimista de uma pessoa e baseando-a em dados reais do próprio time ao longo do tempo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Na prática, esconder o bug não o faz desaparecer, ele só fica invisível temporariamente. A longo prazo, o bug pode ser descoberto no pior momento possível, geralmente pelo cliente. Assim, pode-se ter uma queda de confiança na empresa, como também entre o time desenvolvedor com a pessoa que sabia do bug e não falou. Além disso, outros desenvolvedores podem construir código em cima da parte do bug, achando que ela é confiável, fazendo o problema crescer sem ninguém perceber.

Na prática reportar o bug, pode fazer com que a equipe o conserte a tempo da entrega. A longo prazo, permite que novas funcionalidades sejam implementadas sem erro no código e entregas sejam feitas sem bug.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Porque assim que o prazo passa, todos se mantêm ocupados com a próxima entrega urgente. Como cada novo módulo implementado depende do código mal escrito, isso aumenta o custo e o risco de consertar depois. Além disso, os problemas com o código podem ser descobertos depois do lançamento, geralmente pelo usuário final, com custo de reputação, não só técnico. Além disso, o time pode ficar mais lento porque precisa consertar e inserir novas funcionalidades no código.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Eu diria que conseguiria entregar em 1 mês, se pudermos selecionar prioridades (funcionalidades essenciais) do escopo original, propondo um produto mínimo viável em que decidiríamos o que realmente precisa estar pronto em um mês para o lançamento fazer sentido.

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

📝 Questão 1: Projetos vs. Operações na Prática

Considerando projetos da faculadade, percebe-se que escrever o Trabalho de Conclusão de Curso é considerado um projeto, pois tem início, meio e fim. Como também implementar uma nova funcionalidade pedida pelo professor em um código de Algoritmo genético da disciplina de IA também é considerado um projeto. Podemos concluir que o projeto além de possuir um início, meio e fim, possui um encerramento.

Já em outras atividades de disciplinas, revisar código de programação de colegas para construção de um site é considerado uma operação, pois é uma rotina contínua, não tem fim. Como também fazer a manutenção preventiva no meu computador é também uma operação, pois é uma manutenção, rotina contínua. A operação não possui um encerramento, as operações continuam existindo até serem descontinuadas ou automatizadas.

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

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

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

📝 Questão 5: Por que código bom não basta?

Sem resposta no comentário

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

📝 Questão 4: Esconder Bugs vs. Transparência

Sem resposta no comentário

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sem resposta no comentário

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Sem resposta no comentário

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

📝 Questão 1: Projetos vs. Operações na Prática

Na minha experiencia de faculdade, a maioria das matérias da grade curricular, incluindo a programação e o desenvolvimento de softwares, foram em matérias operacionais, na qual eram em separados os trabalhos e as avaliações especificas para cada momento do curso. Mas, houve casos específicos como na matéria de “Programação Web”, “Modelagem de sistemas” na qual matéria foi guiada em volta de um trabalho final a ser entregue no semestre.

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

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

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

📝 Questão 5: Por que código bom não basta?

É necessário adotar esses processos formais de gestão justamente para evitar falhas humanas como a má gestão, em que as tarefas são mal distribuidas sobrecarregando apenas alguns dos desenvolvedores e a falha de comunicação em que erros e bugs são deixados no código e não são comunicados com a equipe, causando problemas futuramente.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder o bug no código, ele pode causar problemas onde que outros desenvolvedores não irão achar, enquanto que reportá-lo durante uma reunião pode ajudar a entender como evitá-lo e possíveis outros bugs. Nos dois casos a produtividade da equipe é afetada.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Safricar a qualidade do código em prol do prazo pode vir a se tornar um problema para a equipe devido a como o código pode ter sido escrito podendo se tornar não legível, ou não ser escalável

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Visando utilizar o Triângulo de Ferro na negociação com a diretoria, e sabendo dos três vértices do triângulo, seria necessário negociar sobre o Escopo visando o reduzir sua quantidade para manter uma boa qualidade do software, visto que com menos tempo e menos recurso (monetário), para que o software não seja entregue com uma má qualidade, é preciso reduzir sua quantidade de funcionalidades para que seja devidamente testado e seja entregue sem bugs e defeitos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Durante experiências passadas na faculdade, os “projetos” poderiam ser classificados como os trabalhos passados pelos professores e as “operações” seriam os exercícios passados para consolidar o conteúdo.

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

🟢 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: Por que código bom não basta?

Existem duas razões humanas que fazem com que a adoção de processos de gestão sejam essenciais no desenvolvimento de um projeto. A primeira é a falha de comunicação entre as pessoas envolvidas no projeto onde o produto a ser desenvolvido pode ter seu escopo mal definido se todas as partes envolvidas no projeto (Desenvolvedores, Product Owner e cliente) não possuírem o conhecimento detalhado do que está sendo criado. Já a segunda razão é o ego da equipe onde a vergonha e medo de admitir dificuldades ou até de reportar um erro cometido pode acarretar na quebra total do código ao longo do desenvolvimento do restante do projeto devido a base do código ser totalmente instável.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder um bug a fim de cumprir um prazo durante a produção pode causar problemas graves visto que toda a equipe continuará desenvolvendo o restante do sistema em cima de um problema existente sem possuir noção dele, logo quando o erro quebrar a implementação e ficar exposto para toda equipe, a quantidade de tempo para corrigi-lo será bem maior já que também será necessário modificar todas as outras partes que foram construídas se baseando neste código com bug também terão que ser modificadas. Agora, se o problema for reportado assim que identificado, será feito um planejamento coletivo para avaliar o bug de forma que ele seja corrigido o mais rapidamente possível sem danificar futuras partes do sistema, garantido então o controle e estabilidade do projeto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código a fim de cumprir um prazo se torna uma “bomba-relógio” futuramente porque a instabilidade e os problemas deste código ruim não desaparecem com a entrega dentro do prazo e sim apenas adia estes erros para o futuro. Quando for necessário implementar algo novo dentro do código instável, é bem provável que seja necessário gastar muito mais tempo corrigindo as partes problemáticas e mal feitas para que o sistema não quebre totalmente do que necessariamente priorizar a nova funcionalidade. Este problema acarreta na redução dos prazos novamente devido ao tempo mal gasto e gera assim um ciclo vicioso de prazos curtos e códigos mal implementados.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Sabendo do prazo reduzido, do custo inalterado e conhecendo o triângulo de ferro formado por tempo, custo e escopo mantendo sempre a qualidade independentemente, eu explicaria para a diretoria a inviabilidade de manter o escopo do projeto com a redução de tempo sem aumentar gastos e, aplicando o conceito de MVP (Minimum Viable Product), faria uma lista com todas as funcionalidades a serem implementadas e buscaria tomar uma decisão conjunta com a diretoria para separar quais funções são essenciais e inegociáveis e quais podem ser adiadas para uma atualização futura a fim de manter os limites do prazo.

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

📝 Questão 1: Projetos vs. Operações na Prática

Um projeto é um atividade realizada ao longo do determinado tempo com o objetivo de atingir um resultado único como a criação de um produto. Exemplos: Trabalhos de faculdade como a criação de uma plataforma web usando Angular e Spring Boot, criação de um sistema de recomendação com todas as suas regras, montar no simulador um processador MIPS monociclo funcional.

Já uma operação se trata da realização de uma tarefa contínua e repetitiva sem um prazo definido a fim de manter algo pré-estabelecido. Exemplos: Estudar para provas a fim de manter meu nível acadêmico, realização de atividades e avaliações acadêmicas recorrentemente como questões de maratona de programação em Java, resolução de listas de exercícios, etc.

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: Por que código bom não basta?

Uma boa gestão é indispensável pelo fato da falha humana em vários âmbitos, por exemplo um desenvolvedor falar que tal estrutura funciona melhor que outra sem realmente ter o dado daquilo, o gerente do projeto não conseguir alinha com o cliente o que realmente o sistema feito precise cobrir. Temos vários outros exemplos que mostram como um alinhamento de equipe constantemente é importante para manter a coesão e sucesso do trabalho, além de uma checagem com os avanços das tecnologias presentes.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ficar escondendo bugs por questão de metas e prazo é uma prática errada e com certeza pode causar danos lá na frente que podem ser muito mais complexos de serem corrigidos. Reportar um bug precocemente em uma reunião de alinhamento é a prática correta para um desenvolvimento adequado de um projeto. Talvez a linha entre essas duas decisões seja bastante tênue.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Isso prejudica em vários aspcetos do projeto, por exemplo, futuras correções podem ser mais difíceis ou até inviáveis, pode ocorrer conflito com uma nova estrutura e novas funcionalidades, o entendimento do código por novos devs entre outros. O barato que sai caro.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Diria que não é possível entregar o projeto inteiro como especificado no escopo, adiantando o prazo de entrega e não contratando novos devs para adiantar o processo. Uma solução de entrega do sistema seria abordarmos as funcionalidades com maior prioridade para o funcionamento do sistema e depois complementá-lo , caso fosse possível.

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

📝 Questão 1: Projetos vs. Operações na Prática

Minha experiência aqui no CEFET-MG até agora foi muito mais voltada para operações do que para projetos. Considero operações, basicamente, como a resolução de um determinado problema utilizando uma estrutura de dados e linhas de código. Já os projetos, por terem início, meio e fim, envolvem muito mais organização, separação de papéis e planejamento, além de um acompanhamento, como, por exemplo, por meio de um projeto no Trello. Alguns exemplos foram os sistemas desenvolvidos nas disciplinas de Desenvolvimento de Sistemas e POO. Esses trabalhos exigiram toda a estruturação de um projeto, incluindo planejamento, acompanhamento e codificação.

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

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

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

📝 Questão 5: Por que código bom não basta?

Sem resposta no comentário

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

📝 Questão 4: Esconder Bugs vs. Transparência

Sem resposta no comentário

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sem resposta no comentário

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um conceito que utiliza da analogia de um triângulo em que as três arestas desse triângulo são: escopo, tempo e custo. Na situação em que alguma dessas arestas é puxada (no caso, aumentada), afeta as outras arestas do triângulo. No cenário em questão, o tempo é diminuído e o custo é mantido. O escopo desse projeto deve ser negociado de maneira em que se busca equilibrar com o tempo afetado. Negociaria um escopo mais simples para atender ao tempo e custo do projeto.

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

📝 Questão 1: Projetos vs. Operações na Prática

Uma atividade que foi um projeto foi o trabalho prático final do técnico em Desenvolvimento de Sistemas. Nesse caso, o objetivo era a implementação de um sistema de cadastro de clientes e consultas para um dentista, algo simples hoje em dia, mas foi bastante desafiador na época (2022). O projeto contou com toda a etapa de planejamento de sistemas: entrevista, levantamento de requisitos, design, desenvolvimento, testes, implementação e manutenção. Outra atividade que é uma operação é, no estágio que atuo, atuo na manutenção e atualização de uma aplicação web. Separo esses dois mundos principalmente pela gestão, pois no projeto o escopo é bem definido e as operações diárias com o time são bastante distintas em uma atividade do tipo operação, que o escopo é mais aberto e o objetivo não é criar, e sim melhorar algo que já existe.

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: Por que código bom não basta?

Primeiro temos as falhas de comunicação, em uma equipe quando está em um projeto de software acontece muitas falhas de comunicações como erros não reportados (como respondi na última questão) que podem trazer grandes atrasos, e interpretações de requisitos que muitas vezes pode haver ambiguidade entre os devs, por isso é necessário as reuniões para o alinhamento de visão e evitar mal entendidos.

E também as Expectativas Irreais, muitas vezes nas reuniões com os clientes eles criam expectativas muito grandes com quantidade de funcionalidades no software, eles acabam achando que é possível fazer tudo em um curto período de tempo sendo que isso é muito difícil. Por isso deve-se ter uma metodologia onde tenham reuniões, e com elas deve-se decidir prazos e mostrar as evoluções de cada etapa do projeto para o cliente.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug em baixo de um tapete para entregar o software dentro do prazo é um tiro no pé, uma hora ou outra ele vai interferir no seu projeto trazendo erros ainda maiores que podem atrasar uma próxima etapa. Isso acaba trazendo uma grande dor de cabeça para todo o time que está no projeto. Já reportar ele em uma reunião de alinhamento de equipe é o ideal, pois através desse feedback a equipe pode ser direcionada para resolver esse problema o mais rápido possível para continuar o andamento do projeto. E com isso é evitado grandes erros futuros no software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Pois isso acaba virando uma bola de neve, após essa entrega do software pode ter outras entregas, e você não consegue voltar para resolver os problemas. Quando você for mexer neles já não lembra mais qual o processo que foi feito e assim demora muito mais tempo para resolver os erros. Esses erros podem atrapalhar a velocidade do software e deixar ele mais lento. Também na nossa área as vezes os desenvolvedores acabam saindo rápido das empresas, e com o código mal feito os outros que forem corrigir acabam tendo grande dificuldade, por falta de documentação e conhecimento sobre como o software foi criado.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que não é possível entregar o software 100% com esse adiantamento. Eu poderia dar opções de como entregar ele mas com menos funcionalidades, primeiro entregaria ele com a funcionalidades mais importantes e depois com o tempo as demais, essa é a única forma que penso para poder “adiantar” o processo sem perder muito a qualidade do software.

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

📝 Questão 1: Projetos vs. Operações na Prática

Projeto é a criação de um aplicativo ou um site/sistema como fizemos em Desenvolvimento de Sistemas no semestre passado, em que nele decidimos que iriamos fazer um sistema de posto de saúde e com isso foi definido a tecnologia que íamos usar, tínhamos data de entrega e também tínhamos uma “conclusão” que era as funcionalidades que o professor pediu que tivesse para conseguirmos 100% da pontuação.

Já as operações é após já estar no ar, elas são monitorar o sistema, corrigir falhas inesperadas descobertas e aplicar atualizações para corrigi-las e também melhorar o sistema, isso tudo é uma rotina contínua.

As diferenças são que o projeto é “temporário” pois tem data de início e uma data de término planejadas e quando é alcançado o que deseja o projeto encerra, já a operação é contínua pois não tem ponto final definido, ela se repete de forma permanente enquanto o sistema ou serviço estiver funcionando.

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

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

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

📝 Questão 5: Por que código bom não basta?

Pessoas em geral tem dois grandes problemas que justificam a adoção desses processos, que são subestimar o tempo e esforço necessários para a realização de uma tarefa e o péssimo hábito de só se preocupar em realizar as tarefas quando o prazo final de entrega se aproxima, como eu nessa atividade. Sendo assim, mesmo um profissional experiente pode não considerar todas as variáveis envolvidas em determinadas etapas do projeto, o que pode ser parcialmente solucionado com a elaboração de documentação detalhada, cronogramas e análise de risco por uma equipe, trazendo diferentes visões e vivências para o projeto, considerando muitas obrigações e situações que podem surgir. Além disso, dividir um grande projeto em pequenas e frequentes entregas é uma maneira eficiente de acompanhar a evolução do software e garantir que os profissionais envolvidos não vão procrastinar eternamente, acumulando o serviço e não entregando o que foi proposto em tempo hábil.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug debaixo do tapete para cumprir um prazo imediato não faz com que o problema real desapareça e que as coisas continuem fluindo. Muitas vezes um bug em uma determinada etapa do projeto afeta negativamente todas as etapas subsequentes, gerando dois tipos de desgastes. O primeiro é que em algum momento esse bug vai ter que ser resolvido, então os desenvolvedores terão que dedicar tempo a uma etapa que já deveria estar concluída, trazendo consigo todos os problemas citados na questão 3, e a outra é que nem sempre quando alguma coisa der errado lá na frente vai ser evidente onde está o erro, então surge outro gasto de tempo e perda de produtividade que atrapalham o cronograma do projeto, uma vez que encontrar o que está gerando um erro ou bug nem sempre é uma tarefa trivial, muitas vezes não fica clara a relação entre fases já concluídas e um bug inesperado na fase atual. Em contrapartida, reportá-lo precocemente pode atrasar ligeiramente o cronograma original, mas garante que não será dedicado a essa situação mais tempo do que o estritamente necessário, com esforços dedicados para a resolução do problema, proporcionando tranquilidade e confiabilidade para o seguimento do projeto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código como “variável de ajuste” para cumprir um prazo é uma bomba-relógio para a equipe porque pode resultar em um software que não foi testado adequadamente, com bugs e falhas críticas de funcionamento que passaram despercebidas, gerando uma situação de estresse e desgaste quando esses problemas se tornam evidentes e a equipe tem que trabalhar em dobro e sob pressão para resolver os problemas em tempo recorde. Além disso, na prática, o ciclo de vida do projeto não termina na entrega do software, e a equipe que deveria focar em outras fases desse projeto ou em outros projetos fica presa a essa situação e a um projeto ou etapa que já deveria estar concluído, o que pode gerar um efeito dominó e atrasar outras fases e projetos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Existem três fatores principais atrelados à qualidade de um software: tempo, custo e escopo. Se o tempo diminui e o custo não aumenta para compensar é necessário promover mudanças no escopo do software, com o objetivo de não comprometer a qualidade, que é inegociável. Sendo assim, não é possível entregar o software completo e com qualidade diminuindo o prazo de entrega em um mês e sem contratar mais desenvolvedores, mas é possível entregar uma versão menor do software previsto originalmente, com algumas funcionalidades ou recursos a menos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Sem resposta no comentário

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: Por que código bom não basta?

Acredito que a personalidade individual de cada humano é um fator que acaba tornando a gestão algo indispensável. Muitas vezes encontramos e lidamos com colegas de equipe que não aceitam que também estão sujeitos a errarem ou que simplesmente vão repassando o erro para frente por puro egoísmo de não saber lidar com a culpa. A falha de comunicação também pode ser citada nesse sentido e muitas vezes também se relaciona com a personalidade. Percebo que muitos colegas da nossa área não são muito sociáveis, muitas vezes por receio ou vergonha de interagir com outro alguém e isso acaba criando barreiras dentro de uma equipe, que pode por consequência comprometer o projeto final. Algumas pessoas costumam deixar algo passar simplesmente para não ter que lidar com o que a outra pessoa pode falar, por acabar gerando raiva, intriga e entre outras relações ruins. Isso costuma se acumular e fatores pequenos e de pouca relevância se tornam grandes e perceptíveis.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Podemos fazer uma analogia com educação financeira. Escolher esconder esse bug seria equivalente a não pagar determinada dívida em seu determinado prazo. Essa situação gera juros que quando a pessoa se der conta, ela vai estar pagando mais juros do que o próprio valor inicial. De mesmo modo, esconder um bug ao invés de reunir e se dispor a corrigi-lo, trará problemas ainda maiores que podem eventualmente acabar se tornando tão maiores quanto o pressuposto inicialmente. A manutenção que inicialmente poderia ser simples, irá ser algo complexo, o que te torna vulnerável a mais e mais bugs em um efeito dominó.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Acredito que pode se tornar uma bomba-relógio pois essa falta de cuidado que você tem no momento em que decide entregar antes mesmo que com menor qualidade, necessariamente retorna a você e muitas vezes em uma escala maior, quando você for de fato corrigir (“depois a gente arruma”). Nesse patamar, seu cliente ja vai estar em uso do site e pode acabar encontrando dificuldades que você nem tinha sequer se preparado para lidar. Dessa forma, o trabalho que você deixou de ter ao tomar essa decisão, simplesmente foi adiado e se tornou pior do que era no passado, por pura e simples ignorância, preguiça, mas normalmente por pressão também. Código ruim, se torna difícil de ler, alterar então se pagam juros muito altos por um prazo que nem sempre costuma chegar.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro conceitua a união de 3 aspectos no âmbito da gestão de projetos: escopo, tempo e custo (formando um triangulo). Essa união implica que, ao alterar um dos lados do triangulo, altera também os outros dois e por consequência a qualidade final do projeto. No caso dessa questão, houve uma diminuição de tempo e além disso o orçamento vai se manter, pois não querem contratar mais desenvolvedores. Para negociar essa situação, o único lado do triângulo restante é o escopo, que para manutenção de qualidade, precisa ser reduzido, assim como o prazo foi, caso contrário, não será possível entregar o que foi projetado com a mesma qualidade presumida inicialmente.

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

📝 Questão 1: Projetos vs. Operações na Prática

Acredito que os exemplos mais comuns de projetos eram os próprios trabalhos práticos. Normalmente eram planejados, feitos e depois de apresentados/entregues provavelmente não voltaríamos a vê-lo (talvez era interessante fazer isso, mas nunca ocorreu). Um exemplo de operação é o ato de estudar (do mundo das ideias), pois é algo que está em constante manutenção, precisa ser feito diariamente para construir o conhecimento e não tem fim no período determinado pela faculdade e enquanto estiver no mercado de trabalho, pois enquanto um bom profissional você precisa se atualizar sobre aquilo que compõe sua bancada de trabalho, normalmente estudando.

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: Por que código bom não basta?

O primeiro ponto acredito que seja a organização, pois com a Gestão Ágil conseguimos controlar as entregas e as datas sem extrapolar e subestimar o projeto, ou seja, sempre estaremos trabalhando e finalizando tarefas de uma forma mais controlada, sendo assim muito mais fácil saber se nosso progresso vai ser o suficiente para entregar no prazo, sem isso poderíamos ficar perdido nas entregas e mantermos uma expectativa falsa que esta tudo no tempo certo. O segundo ponto pode ser uma confiança excessiva do desenvolvedor com o próprio código, mas como a gestão ágil geralmente separa o tempo para revisão em que outra pessoa vai validar o que foi feito, esse problema é mitigado.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Acredito primeiramente que dependendo do bug essa acao de esconde-lo é um grande risco a todo o projeto, pois a gravidade pode ser grande caso esse bug gere danos aos usuarios do sistema, como vazamento de dados. Em paralelo acredito que nao ajustar um bug pode gerar um acumula de códigos errados na codebase, que no longo prazo pode se tornar inviavel corrigir tudo sem fazer grandes alterações no projeto, por ultimo, podemos falar na confiabilidade e transparência que voce vai ter com a equipe, tendo em visto que todos estao la para fazer algo de qualidade e sabem que podem contar com seu trabalho.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Eu penso que em primeiro lugar pode estar a variável de segurança, acredito que sacrificar a qualidade do código pode gerar falhas e vazamentos de dados que depois podem gerar danos graves ou ate irreversíveis para empresa.Em segundo, é fato que no mes seguinte teremos retrabalho nesse codigo, so que agora podemos ja estar atuando em outros escopos, alem de que a correção de um projeto que esta em produção da muito mais trabalho, ou seja, pode ser que eu nao consiga mais chegar na qualidade de projeto que eu iria ter se tivesse ajustado o prazo de forma correta e tivesse feito uma primeira versão com qualidade.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que eles estao mexendo na variavel tempo diminuindo o tempo proposto, mantendo o custo, entao o escopo do projeto seria afetado. Com esse escopo do projeto sendo afetado alguma funcionalidade ou varias funcionalidades do sistema seriam comprometida, eu daria a sugestao de adiar a construcao de alguma parte do sistema para depois, assim eu equilibraria o escopo com tempo e custo novamente, eu vejo como a melhor solucao para nao comprometer a qualidade.

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

📝 Questão 1: Projetos vs. Operações na Prática

Em minha experiência profissional, consigo perceber que existem iniciativas que são projetos, principalmente relacionadas a coisas novas. Mais especificamente no meu contexto, poderia citar a construção de um pipeline de transformação, limpeza e deploy de um dado novo que está chegando à empresa. Nesse cenário, conseguimos identificar mais claramente um início, meio e fim.

Contudo, no meu contexto, existem também operações de atualização de dados, que têm suas datas definidas, como de mês em mês ou de seis em seis meses. Essas tarefas são mais rotineiras e contínuas. Além disso, um projeto construído que é finalizado, depois de um tempo, provavelmente passa para um status de manutenção, em que, de forma contínua, vamos conferindo seus resultados e ajustando seu fluxo.

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: Por que código bom não basta?

As falhas de comunicação são o maior motivo para a adoção de um processo formal de gestão para um projeto de software; é impossível saber o que se passa na cabeça das pessoas que estão em conjunto desenvolvendo o projeto, ou até mesmo a do cliente; a forma de implementação de uma feature pode ser passada de forma muito vaga por um superior, ou uma pessoa pode ter opiniões ou um estilo de trabalho totalmente diferente de uma outra, ou um cliente possui uma visão muito irreal sobre o que o projeto se propõe a ser. Sem uma hierarquia e processos formais bem definidos, a informação pode ficar muito concentrada em um só lugar, sem circulação e alinhamento, e o processo totalmente desajustado, gerando trabalho para todos os envolvidos. Um processo formal se mostra indispensável para ajustar e alinhar a todos.

Um outro motivo para a adoção de processos formais de gestão são os imprevistos no projeto; são comuns e, sem um método de gestão formal, esse imprevisto gera discussões entre a equipe, trabalho excessivo e mais problemas derivados a esse, se não houver uma solução eficiente. Em um processo formal de gestão, basta incluir a demanda atrelada ao imprevisto na fila de prioridades, ou reorganizá-la e reordená-la com base na capacidade atual do time (no caso de alguém sair da equipe, e não houver alguém para substituir; haverá trabalho extra mas é possível mitigar esse problema). Essencialmente, um processo formal de gestão de software é imprescindível para gerir e mitigar imprevistos em um projeto.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Embora esconder um bug pode diminuir a carga de trabalho imediatamente, isso cria um problema que inevitavelmente precisará ser resolvido mais na frente; seja ignorando-o ou simplesmente “resolvendo-o” com uma solução mal-feita, isso aumenta a complexidade de resolver o problema a longo prazo, visto que o sistema já estará mais complexo do que no momento em que o bug foi notado, além de poder quebrar outras partes do sistema completamente não-relacionados ou até gerar outros problemas derivados desse, além de abaixar muito a qualidade do software.

Reportar o problema precocemente permite traçar um plano para a correção do bug com mais pessoas de forma a não afetar o resto do sistema, agindo na raiz do problema e trabalhando em prol de um produto mais robusto. A longo prazo, isso melhora a qualidade do software entregue, permite uma maior previsibilidade, com as estimativas de entrega levando em conta esses problemas ao longo do caminho, além de promover uma maior transparência e menos retrabalho para a equipe, já que o problema vai ser resolvido uma vez, documentado, e não será necessário voltar nele; o foco poderá ser em uma nova funcionalidade.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Um código feito às pressas e sem o devido cuidado pode resolver o problema temporariamente e, embora possa bater o prazo, o ganho de tempo feito com um código frágil é totalmente perdido quando se precisa corrigir falhas e desvendar um código caótico e sem sentido.

Essencialmente, isso gera problemas futuros no sistema ao escalá-lo para algo maior, gerando bugs, dificuldade de leitura, falta de documentação adequada e falta de testes adequados, podendo quebrar partes do sistema que já existem, além do tempo alocado da equipe em sprints posteriores não estar destinado a trabalhar em novas funcionalidades para o projeto, mas sim a corrigir erros e “desvendar” (quase que literalmente) o que eles haviam feito para conseguir darem seguimento ao projeto.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um conceito da gestão de projetos que relaciona as três principais restrições de um projeto: escopo, prazo e orçamento, ao passo que, mudar qualquer um dos três inevitavelmente muda os outros dois, e também incide necessariamente na qualidade.

No caso apresentado, as duas principais variáveis em questão são o prazo e o orçamento. O problema do prazo ser antecipado pode ser mitigado ajustando uma das outras duas variáveis: o orçamento não é o caso, visto que não haverá aumento de orçamento para a contratação de mais desenvolvedores. Sendo assim, o escopo precisará ser negociado.

Não é possível manter o projeto do jeito que está (visto que, sua previsão normal seria ter um mês a mais de desenvolvimento); dessa forma, haverá a necessidade de retirar funcionalidades para entregar o projeto dentro das restrições de prazo e orçamento, focando mais nas funções principais. O valor entregue ao cliente será menor, as chances da qualidade do produto entregue ser menor do que em relação a um cenário normal são bem maiores, e talvez seja necessário implementar esses ítens posteriormente, sendo o trade-off necessário para conseguir entregar esse projeto devido às alterações nas variáveis.

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

📝 Questão 1: Projetos vs. Operações na Prática

Na faculdade, as atividades que eram “projetos” eram, principalmente, os trabalhos de alguma disciplina, como um código para resolver um problema em específico ou a modelagem de uma CPU didática: tinham um objetivo e escopo claro, com início, meio, fim e uma data de entrega; não se fazia uma manutenção ou havia algum tipo de continuidade nesse trabalho depois de entregue. Assim que finalizado, não havia mais nada a se fazer.

A atividade mais marcante de operação que fiz em projetos passados foi um pequeno bot feito em Java para a plataforma Discord, com a finalidade de tocar músicas. Como era algo mais pessoal e, principalmente, feito para amigos, não havia um escopo muito claro (embora esse não seja o caso, necessariamente, para uma operação!). Ao invés disso, toda funcionalidade que eu achasse interessante (ou que me recomendassem, ou que eu achasse engraçada), inevitavelmente acabaria sendo adicionada, além dos fatos de ter que lidar com as APIs, bibliotecas quebrando, tendo que ser atualizadas e trocadas; essencialmente, o cuidado precisava ser muito maior, e era uma checagem contínua e quase diária para garantir que o bot estava funcionando corretamente.

Essencialmente, um projeto é algo delimitado e temporário, com início, meio e fim e com a finalidade de criar algo único, e acaba assim que as metas forem atingidas. Uma operação é algo mais contínuo, sem uma data para acabar, geralmente sobre um mesmo objeto e de forma repetitiva.

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: Por que código bom não basta?

Como um projeto não é só código e envolve pessoas ele está suscetível a erros. Um deles é a falha de comunicação, por exemplo: uma funcionalidade do sistema é solicitada pelo cliente, mas mal interpretada pela equipe e, posteriormente entregam algo errado. Outros exemplo é colocar expectativas irreais, por exemplo: solicitar um tempo menor que o normal para desenvolver algo que leva tempo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Mesmo que o erro seja escondido, ele continuará existindo e com o avanço do projeto poderá se transformar em uma bola de neve e comprometer todo o projeto. Ao reportar o erro imediatamente e com transparência, a equipe consegue corrigir o problema antes que ele cause consequências maiores.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Eu acho que fazer esse código “de qualquer jeito” só para cumprir o prazo pode gerar problemas futuros, porque seria necessário mais tempo para organizar essa bagunça. O que pode gerar mais custo e tempo no projeto desse software.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro traz o conceito de tempo, custo e escopo. Nessa situação apresentada o tempo diminuiria e o custo continuaria o mesmo, sem aumento do orçamento. Ao meu ver, seria melhor priorizar o escopo, entregando inicialmente as funcionalidades essenciais para que o software funcione.

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

📝 Questão 1: Projetos vs. Operações na Prática

As atividades que se enquadram como projetos e que eu me lembro de realizar são: o projeto da matéria de DS e trabalhos da Iniciação Científica. Já as operações são: estudar para as provas, assistir às aulas e acessar o SIGAA. Nos projetos, como eles possuem um prazo maior para serem realizados, costumo dividir as atividades em partes ou etapas. Já as operações são atividades recorrentes que são realizadas com maior frequência e sem ter um fim necessariamente.

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

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

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

📝 Questão 5: Por que código bom não basta?

R: Não basta haver a competência técnica para desenvolver o software, é necessário ter certeza de que tudo o que está sendo construído está de acordo com o que é idealizado pelos clientes e projetistas, e envolvimento de toda equipe para entender como cada face do projeto está em andamento e se comporta. Além disso, esses processos mitigam o problema da criação de expectativas irreais a respeito do projeto, como propor a elaboração de um escopo muito grande para um projeto tal que não é praticável pelas limitações de orçamento, deixando o cliente ciente de tudo o que pode ou não ser desenvolvido.

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

📝 Questão 4: Esconder Bugs vs. Transparência

R: A principal diferença é que reportar de antemão um problema, seja um bug ou falha no projeto de escondê-lo da equipe para entregar o mais rápido possível é que no primeiro caso é aberta a oportunidade de toda a equipe se unir para decidir como remediar a questão sem que surjam novos problemas ou encontrar métodos para não comprometer a qualidade do software que será disponibilizado ao cliente, o que pode gerar prejuízos avassaladores, no segundo caso os bugs podem causar problemas para todos os envolvidos, escalar em bugs ou problemas maiores futuramente e dificultar a manutenção do software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

R: Porque um código mal desenvolvido tende a ser pouco ajustável para manutenções e alterações do projeto, fazendo com que a escalabilidade do que foi desenvolvido seja comprometida e que os desenvolvedores tenham o retrabalho a posterior de codificar um novo trabalho ou de lidar com a correção de bugs e problemas em larga escala, atrasando toda a cadeia produtiva.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

R: O conceito do triângulo de ferro é uma premissa de que há três pontos fundamentais na gestão de um projeto: escopo, prazo e custo do projeto. Se uma dessas grandezas sofrer aumento ou redução as demais grandezas devem ser alteradas também para que a qualidade do projeto não sofra maiores danos. Nesse caso o orçamento do software se manterá fixo ao passo que é exigido que o prazo seja diminuído. Sendo assim, é necessário diminuir o escopo do projeto pois não serão contratados novos devs para acelerar a produção e continuar com o projeto inteiro pensado para o prazo anterior.

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

📝 Questão 1: Projetos vs. Operações na Prática

Sem resposta no comentário

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

🟠 SAULO DIAS DE OLI. (Matrícula: 20203013888, Login: @Saulo)

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

📝 Questão 5: Por que código bom não basta?

Organização e boas praticas, uma equipe com pensamento mais unido e alinhada no seu trabalho consegue contornar mais facil erros e ter clara comunicação do que cada um está fazendo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder Bug

pratica: gera problemas futuros por que o bug pode interferir em outras partes do processo acarretando uma cascata de problemas adicionais.

Longo prazo: Perca financeira, confiança do cliente e/ou usuários.

Reportar Bug

pratica: O problema se resume aquele bug, economizando esforço e tempo da equipe.

Longo prazo: um trabalho bem feito gera retorno satisfatório e possívelmente financeiro já que o cliente e/ou usuário teve ótima experiencia com o produto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Basicamente o time empurrar o trabalho mais para frente, incluindo adicional de deixar o cliente e/ou usuários insatisfeitos e com pessíma impressão para a empresa, resultando também em perca financeira e até mesmo atraso de outros projetos em cascata.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Como podemos ver pelo triangulo a base representada por tempo e orçamento estão mais afastadas simbolizando menor eficiencia e saindo do escopo, que e representado no topo da piramide, quanto mais baixo o topo, mais fora do escopo está, em resumo não é possivel com menos orçamento e tempo adiantar o projeto mantendo qualidade.

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

📝 Questão 1: Projetos vs. Operações na Prática

Sem resposta no comentário

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: Por que código bom não basta?

Dois dos fatores humanos que podem afetar um projeto, mesmo quando o código é bem feito, são:

1. Falhas de comunicação: informações podem não ser passadas corretamente entre a equipe, causando erros, retrabalho e decisões diferentes sobre o que deve ser feito.

2. Expectativas irreais: clientes ou gestores podem esperar resultados em prazos muito curtos ou com poucas pessoas, sem considerar a complexidade do projeto. A gestão ajuda a alinhar essas expectativas e definir prioridades.

Por isso, processos de gestão são importantes para organizar as pessoas, alinhar expectativas e evitar que problemas humanos comprometam o projeto.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug pode até ajudar a cumprir o prazo naquele momento, mas aumenta o risco de o problema se tornar maior e mais caro de corrigir depois.

Ao reportar o bug precocemente, a equipe consegue avaliar o impacto, buscar uma solução e ajustar o planejamento antes que ele afete outras partes do projeto. Isso também aumenta a confiança entre os membros da equipe e evita surpresas no futuro.

Portanto, a transparência pode gerar um impacto imediato no prazo, mas reduz os riscos e os custos no longo prazo.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código para cumprir um prazo pode parecer uma solução rápida, mas acaba gerando problemas maiores depois.

Um código feito de qualquer jeito tende a acumular dívida técnica, tornando mais difícil corrigir erros, adicionar novas funcionalidades e fazer manutenção. No mês seguinte, a equipe pode gastar muito mais tempo corrigindo esses problemas do que gastaria fazendo o código corretamente desde o início.

Por isso, cumprir o prazo sacrificando a qualidade pode apenas adiar o problema e aumentar o custo do projeto.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Neste caso, eu explicaria à diretoria que será necessário negociar o escopo do projeto.

O Triângulo de Ferro é formado por escopo, tempo e custo. Como o tempo foi reduzido e o custo permanece o mesmo, não seria viável manter todo o escopo original sem aumentar os riscos de atraso ou perda de qualidade.

Por isso, eu priorizaria as funcionalidades mais importantes para o lançamento e deixaria as menos urgentes para uma segunda etapa. Assim, mantgendo o prazo e o orçamento com uma redução controlada do escopo.

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

📝 Questão 1: Projetos vs. Operações na Prática

Na faculdade participo de uma atividade de extensão na qual é possivel ver claramente a diferença entre esses dois mundos.

Pegamos projetos de sites e sistemas onde definimos um escopo de desenvolvimento(inicio), depois desenvolvemos o site(meio) até sua finalização, aprovação da cliente e entrega(fim). Participei de um projeto da construção do site de uma advogada, onde tive a experiência de trabalhar em equipe e participar de todas essas fases do projeto.

Já quando falamos em operações, envolve toda a parte que é necessária no dia a dia para manter a empresa, como por exemplo reuniões, elaboração de contratos, protocolos, termos, contratação de ferramentas. Durante minha participação na empresa junior, tenho participado da diretoria jurídica, onde elaborei vários contratos e termos.

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

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

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

📝 Questão 5: Por que código bom não basta?

Sem resposta no comentário

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

📝 Questão 4: Esconder Bugs vs. Transparência

Sem resposta no comentário

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sem resposta no comentário

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Sem resposta no comentário

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

📝 Questão 1: Projetos vs. Operações na Prática

Tive 2 “grandes” projetos durante a faculdade, o primeiro na disciplina de Desenvolvimento de sistemas, onde fiz um sistema de banco, em que o usuário podia depositar, sacar, transferir e criar um pix e utilizar esse PIX. E outro trabalho na disciplina de Contexto, que tive a oportunidade de fazer uma aplicação real dos meus conhecimentos, em que em conjunto com outra pessoa desenvolvemos um site para uma igreja de Timóteo, com front e back end. Foram projetos que tiveram que ser desenvolvidos com tempo e ajustes seja do professor ou da instituição que ajudamos.

Já operações sinto que o exemplo mais claro para mim são esses questionários e provas que possuem em toda matéria, que já fazem parte da rotina e surgem como manutenção.

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: Por que código bom não basta?

Dificuldade de Comunicação / Comunicação Passiva - Dificuldade em dizer não com a colegas de trabalho/ liderança com prazos e entregas irreais que não podem ser cumpridas.

Ego : Dificuldade em assumir erros e atrasos com prazos.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Pois isso poderá gerar (e provavelmente irá) um efeito bola de neve, no qual pode acabar prejudicando toda a aplicação. Esse trecho com bug, pode ser utilizado em outras funções por outros programadores, e propagar mais erros. Além de que, corrigir um erro durante o processo de desenvolvimento é mais barato do que após a entrega para o cliente.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Quando eles se reunirem para corrigir esses bugs e erros nos quais eles entregaram será muito dificil pois o código não estará “fresco” na mente deles, e estará desorganizado, mal estruturado, tornando-se um código difícil de enteder e alterar, fazendo com que um erro ou bug que poderia ser resolvido rapidamente, levasse muito mais tempo.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um modelo que afirma que 3 variáveis determinam a qualidade de um projeto, sendo elas o ESCOPO (o que precisa ser feito, funcionalidades, requisitos e módulos), TEMPO (quanto tempo o projeto vai levar pra ser entregue) e o CUSTO (quanto dinheiro e quantas pessoas serão investidos).

Na situação descrita, haverá uma redução no prazo(TEMPO), enquanto não haverá a mão de obra extra (CUSTO). Nesse caso, a unica variáavel que é possível alterar seria no escopo, ou seja, teria que mexer no escopo, removendo algumas funcionalidades e revendo alguns requisitos.

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

📝 Questão 1: Projetos vs. Operações na Prática

O projeto no qual já fiz foi uma modelagem completa de um sistema de Clínica Veterinária, onde foi feito todo o passo à passo do projeto (entrevista com o cliente, levantamento de requisitos, documentação, a modelagem) até a parte da implementação (back + front).

Outro projeto, foi a criação de um sistema de estacionamento onde apenas foi criado um sistema que registrava entrada e saída, alem de calcular o valor do mesmo. Além de era um sistema com foco em aplicação de conceitos de POO e funcionava apenas em console.

Quanto a operações, acredito nunca ter participado de alguma. Acredito que se o sistema da Clínica Veterinária fosse algo implementado no mundo real, as operações de rotina para manter o sistema em funcionamento como correções de bugs, backups do banco de dados se encaixariam bem nesse contexto.

A maneira como eu diferencio em temporalidade e objetivo. Os projetos tem data final (objetivo é entregar o sistema) e tem como objetivo criar algo novo, enquanto as operações são contínuas (duram enquanto o sistema existir) e tem como objetivo manter o sistema em funcionamento.

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: Por que código bom não basta?

  1. Falha de Comunicação: Quando não existe uma comunicação efetiva entre duas áreas diferentes ligadas ao projeto já existe uma grande possibilidade do resultado estar distante daquilo que era de fato a necessidade o cliente, que é o que realmente precisa ser satisfeito. A comunicação com o cliente é o que mais precisa ser trabalhado, entender o que ele fala e ainda mais o que ele precisa através da observação do ambiente que a aplicação se tornará parte. Um código pode estar muito bem escrito para um contexto, mas também pode estar completamente distante daquilo que seria o ideal.
  2. Expectativas Irreais: Quando um projeto impossível de ser executado, seja no sentido técnico, de custo e ou de prazo é vendido como uma realidade; um código bem executado não será capaz de suprir todas os requisitos simultaneamente. É necessário ter consciência daquilo que é ou não é real dentro do contexto que aqueles envolvidos nos projetos estão inseridos, a ausência dessa habilidade impossibilita a realização de um projeto satisfatório.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A diferença entre esconder um bug ou reportá-lo rapidamente está basicamente na grande diferença de problemas, financeiros e operacionais, que existirão para consertar esse bug, que mesmo sendo escondido, geralmente aparecerá em algum momento futuro. Quando o problema é reportado ainda em momento de desenvolvimento, os problemas serão mínimos, apenas de realmente refatorar o código ou a estrutura com pontos incorretos. Um problema escondido que é encontrado enquanto em operação, terá ser localizado de forma correta inicialmente, além de poder ter gerado outros problemas ligados a ele em série, além dos problemas sérios que aparecem quando esse problema tiver algo ligado aos dados permanentes do sistema, que podem ser muito sérios caso tenha sido populado massivamente.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Não ter a qualidade como ponto essencial desde o início de um projeto implica, com quase certeza, em sérios problemas para o futuro desse trabalho. Um projeto mal desenvolvido pode:

  • ter sérias falhas de segurança, que impactam diretamente o cliente e pode gerar problemas sérios;
  • possuir comportamentos que, em primeira instância parecem corretos mas futuramente se mostram como fora do esperado;
  • se tornar muito difícil ou impraticável de ser consertado a partir do momento que estiver funcionando, com banco de dados povoado ou implantado em um ambiente que a desativação é inviável;
  • ser um código muito mal estruturado em sua organização e escrita, que implica em baixa manutenabilidade, um sério problema para qualquer projeto que tome proporções maiores.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é uma forma de representar uma relação entre CUSTO, PRAZO e ESCOPO. Nele, afirma-se que não é possível ter uma melhoria em todos os quesitos simultaneamente, se eu quiser “melhorar” 2 deles, o terceiro tem que ser sacrificado e que, se algum dos três mudar, ao menos uma das outras variáveis terá que ser impactada também. Nesse cenário, foram impostas as restriçoes que: 1. PRAZO será diminuido e 2. Não haverá alteração no CUSTO ligado ao projeto.

Dessa forma, é necessário que o ESCOPO do projeto seja REDUZIDO para que as condições propostas sejam possíveis e a regra do Triângulo seja mantida.

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

📝 Questão 1: Projetos vs. Operações na Prática

É possível mencionar que o que foi desenvolvido ao longo da matéria de Desenvolvimento de Sistemas foi um "projeto": uma aplicação Web. Ela foi planejada, teve as etapa de desenvolvimento e chegou ao fim quando publicamos ela e foi avaliada dentro dos requisitos pedidos. Como "operações", poderia dizer que assistir às aulas de cada matéria durante todas as semanas e as entregas semanais ao longo do semestre de matérias de programação e até mesmo cálculo, podem ser mencionadas, pois ocorrem de forma gradual, planejada e sem necessariamente uma divisão de inicio, meio, fim.
Acredito que para diferenciar os dois pode-se mencionar a noção de um cronograma bem definido, com inicio, meio e fim são estipulados em um projeto e não tão necessários em operações que costumam ser menos ligadas a esse calendário determinado; um projeto geralmente é algo que após o fim, não espera continuidade no trabalho, já operações são contínuas; um projeto envolve muitas áreas diferentes normalmente, operações são mais pontuais; projetos são uma entrega específica e operações geralmente são entregas constantes e que seguem um padrão.

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: Por que código bom não basta?

  1. Expectativas irreais e falhas de comunicação: O que o cliente ou a diretoria pede quase nunca é exatamente o que eles realmente precisam, e a comunicação inicial costuma ser cheia de buracos. Sem processos formais para alinhar requisitos e validar entregas constantes, o time programa baseado em suposições, o cliente muda de ideia no meio do caminho, e o projeto afunda em retrabalho e frustração.
  2. Ego técnico e individualismo: É comum o desenvolvedor querer resolver os problemas sozinho sem pedir ajuda ou focar em construir uma arquitetura super complexa apenas pelo orgulho de usar uma tecnologia nova, esquecendo do objetivo real do negócio. A gestão entra para barrar isso, forçando o alinhamento da equipe em reuniões frequentes e garantindo que o foco seja entregar o que o usuário precisa.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A principal diferença está no custo do conserto e no impacto para o time. Esconder um bug só empurra o problema com a barriga: o erro vai silencioso para produção e, quando estourar na mão do usuário, consertar vai ser muito mais difícil e caro, já que o código cresceu e ninguém lembra direito do contexto. Por outro lado, ser transparente e relatar o erro logo de cara permite que a equipe ataque o problema enquanto ele é pequeno ou até renegocie o escopo, evitando retrabalho surpresa e garantindo a estabilidade real do software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código para cumprir um prazo é uma bomba-relógio porque cria uma forte dívida técnica que a equipe terá que pagar com juros logo no mês seguinte. Ao colocar no ar um sistema feito de qualquer jeito, o software vai para produção frágil e cheio de bugs, o que obriga o time a parar o desenvolvimento das próximas entregas apenas para apagar incêndios e focar em retrabalho. Além de travar a produtividade, mexer em um código mal estruturado faz com que qualquer nova alteração demore o dobro do tempo ou acabe quebrando outras partes do sistema, transformando a manutenção diária em um verdadeiro caos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que um projeto é equilibrado por tempo, custo e escopo, sendo impossível alterar um sem afetar os outros. Como o prazo foi reduzido e o orçamento para a equipe continua fixo, a única forma de não comprometer a qualidade e evitar um sistema cheio de falhas é renegociar o escopo, priorizando as funcionalidades essenciais para entregarmos um MVP no novo prazo e deixando os recursos secundários para atualizações posteriores.

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

📝 Questão 1: Projetos vs. Operações na Prática

Projetos têm escopo fechado e data para acabar, enquanto operações são rotinas contínuas para manter tudo funcionando.

  • Projeto (Faculdade): A modelagem do sistema de gestão prisional. O trabalho teve etapas claras de início , meio e fim.
  • Operação (Estágio): O suporte diário no TI de um escola. Resolver chamados, dar manutenção em computadores, redes ou sistemas da escola é um processo contínuo e de rotina, focado em manter a estabilidade, sem um fim definido.

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

🔴 Alunos que não entregaram (0 questões)

  • ——————– (————————–)
  • ANDERSON DE LIMA. (@limaanderson)
  • BIANCA DA SILVA B. (@biancaB)
  • CARLOS EDUARDO (@CarlosEduardo)
  • FLÁVIO CORCINI DE. (@FlavioCorcini)
  • GABRIEL ALVARENGA. (@gLx)
  • GABRIEL SILVA GON. (@mewndigo)
  • HUGO VICENTE COEL. (@hugovicente)
  • JOÃO CARLOS FERRE. (@joaocarlos.fm)
  • MARIA LUIZA PENA. (@mariluiza)
  • MATEUS SILVA LOPE. (@MateusLopes15)
  • PEDRO CLAUDIO JAC. (@pejacome)
  • RAFAEL DE OLIVEIR. (—)
  • RHUAN GABRIEL CAN. (@LapiseraHAHA)
Back to top