adicionando template da visão do produto e projeto

docs/processo.md

@@ -0,0 +1,22 @@
+# **Processo de Desenvolvimento de Software**
+
+Com base nas necessidades do projeto, a equipe optou por adotar a metodologia ágil, sendo motivada pela exigência de realizar quatro entregas ao longo do semestre, o que demanda planejamento, avaliação de requisitos, desenvolvimento ágil e ajustes contínuos.
+
+O Scrum XP combina o framework Scrum, que organiza o fluxo de trabalho em sprints, com práticas do Extreme Programming (XP), focadas em técnicas de desenvolvimento de software. Fornece uma estrutura clara, promove colaboração, garante a qualidade do produto, permite flexibilidade e adaptabilidade, e mantém foco constante no cliente.
+
+No ciclo de vida do projeto, as atividades serão realizadas de forma iterativa e incremental, divididas em sprints com duração definida de uma semana. Cada sprint inclui etapas de planejamento, desenvolvimento, revisão e retrospectiva, permitindo a remodelação do projeto com base nos feedbacks.
+
+![Processo de Desenvolvimento de Software](imagens/processo/processoSoftware.jpeg)
+
+| Nome da Atividade       | Método                        | Ferramenta          | Entrega                                  |
+|-------------------------|-------------------------------|---------------------|------------------------------------------|
+| Definição de backlog    | Análise do escopo do projeto | Trello              | Atividades para serem realizadas em cada Sprint. |
+| Planejamento da Sprint  | Estimativa de esforço de cada integrante; Seleção dos itens do backlog. | Reuniões de planejamento. | Backlog da Sprint. |
+| Revisão de Sprint       | Feedback                      | Reuniões de feedback | Ajustes no backlog                       |
+| Daily                   | Comunicação das atividades do dia anterior de trabalho | Mensagens descritivas | Feitos de cada um, junto com dúvidas e outros tópicos importantes para o projeto. |
+| Definição do MVP        | Identificação dos recursos essenciais para o produto inicial. | Reunião e definição com o professor. | Lista de recursos prioritários do produto a ser entregue ao final do semestre. |
+| User Story              | Funcionalidades do sistema do ponto de vista do usuário | Kanban              | Mapa de história de usuário             |
+| Prototipação            | Criação de protótipos para validar ideias e requisitos | Figma               | Protótipos de alta, média e alta fidelidade |
+| Modelos de caso de uso | Descrição detalhada dos caso uso | Draw.io             | Diagramas de casos de uso               |
+| Desenvolvimento         | Desenvolvimento colaborativo | VsCode, GitHub, GitPage | Incremento de software funcional        |
+| Deploy                  | Preparação e implementação do software em ambiente de produção. | Heroku              | Versão do software implantada no ambiente de produção |

docs/produto.md

@@ -0,0 +1,45 @@
+# **Visão Geral do Produto**
+
+## **Problema**
+
+Uma empresa nacional especializada na entrega de soluções de software e hardware mantém um extenso cadastro de técnicos em seu banco de dados, os quais são encarregados de realizar reparos requisitados por seus clientes. Esses serviços frequentemente requerem prazos de execução curtos.
+
+No momento em que um chamado é aberto, a empresa precisa localizar um técnico em sua base de dados e estabelecer contato para averiguar sua disponibilidade para a execução do serviço. No entanto, a empresa enfrenta uma lacuna crítica, pois não dispõe de um sistema ágil para a comunicação com seus técnicos.
+
+Atualmente, todas as operações são conduzidas manualmente através de uma planilha Excel, o que contribui para uma maior burocracia e prolongamento do tempo necessário para o processo. Para entrar em contato com os técnicos, a empresa realiza uma série de chamadas telefônicas até localizar um profissional disponível, resultando em um considerável desperdício de tempo e, por conseguinte, retardando a solução das demandas dos clientes.
+
+Adicionalmente, a empresa é obrigada a cumprir estritamente os prazos de atendimento dos chamados, para evitar repercussões graves, como danos à sua reputação e possíveis penalidades monetárias substanciais.
+
+Por fim, a empresa ainda enfrenta a carência de um sistema para comunicação regular, seja semanal ou mensal, com os técnicos, a fim de verificar continuamente sua disponibilidade e comprometimento com a prestação de serviços. 
+
+Este déficit resulta na necessidade de designar um funcionário para realizar contatos individuais com cada técnico cadastrado na planilha Excel, a fim de confirmar sua viabilidade para novos serviços. Tal processo consome recursos consideráveis, tanto em termos financeiros quanto de tempo.
+
+Todos esses desafios surgem da falta de uma interface que facilite e automatize a troca de informações entre os técnicos e a empresa.
+
+### _Diagrama espinha de peixe_
+
+![Diagrama Espinha de Peixe](imagens/produto/espinhaDePeixe.jpeg)
+
+## **Declaração de Posição do Produto**
+
+O produto se destaca por oferecer uma solução ágil e automatizada para a comunicação e coordenação de técnicos para realizar um determinado serviço, eliminando a necessidade da maior parte dos processos manuais. 
+
+Através de uma interface intuitiva e eficiente, o produto permite localizar rapidamente técnicos disponíveis, estabelecer contato imediato e acompanhar o progresso dos serviços em tempo real. Além disso, oferece funcionalidades de gestão de prazos e notificações para garantir a entrega pontual dos serviços, evitando consequências graves para a empresa, como atrasos nas entregas, danos à reputação e multas elevadas.
+
+O cliente-alvo é uma empresa especializada na entrega e manutenção de soluções de software e hardware que enfrentam desafios na logística de técnicos para o atendimento de chamados abertos pelos clientes da empresa. A empresa busca uma solução tecnológica que simplifique e agilize o processo de comunicação com seus técnicos, permitindo atender às demandas de forma rápida e eficiente.
+
+O produto se diferencia dos concorrentes pela sua abordagem abrangente e integrada para a gestão de técnicos. Enquanto muitas soluções do mercado se concentram apenas em aspectos específicos, como localização de profissionais disponíveis, o nosso produto irá oferecer uma solução completa que abrange desde a busca e contato inicial com os técnicos até o acompanhamento em tempo real do processo dos serviços.
+
+Além disso, o produto se destaca pela sua facilidade de uso e interface intuitiva, que permite uma integração suave com os próprios processos existentes na empresa. Com funcionalidades de gestão de prazos, notificações automáticas e relatórios detalhados dos serviços para ambas as partes do processo, o produto proporciona uma experiência superior aos usuários, ajudando-os a otimizar seus processos operacionais e aprimorar a qualidade de serviço oferecido aos clientes.
+
+![Tablea Declaração do Produto](imagens/produto/tabelaDeclaracaoProduto.jpeg)
+
+## **Objetivos do Produto**
+
+Com base no chamado registrado pelos clientes na Plataforma de ServiceDesk, o sistema realiza a correlação do problema identificado com a base de técnicos, buscando alocar o recurso mais próximo e com a competência necessária para o atendimento. 
+
+Os técnicos são filtrados de acordo com suas competências, localização geográfica, preço do serviço, atividade atual e proximidade do local de serviço, sendo então plotados em um mapa para visualização fácil dos disponíveis na região do chamado. 
+
+Uma vez selecionado o técnico, é disparada uma comunicação para que este atenda ao chamado, enquanto uma interface permite tanto ao técnico quanto à empresa acompanharem o andamento do serviço. 
+
+O sistema tem como objetivo reduzir o tempo de resposta dos chamados, oferecendo também uma interface para a confirmação da coerência do chamado. As competências dos técnicos são constantemente atualizadas, e caso não haja contato com o técnico escolhido inicialmente, o sistema é capaz de acionar automaticamente outro técnico para o atendimento.

docs/projeto.md

@@ -0,0 +1,70 @@
+# **Visão Geral do Projeto**
+
+## **Organização do Projeto**
+
+
+| Papel                    | Atribuições                                                                | Responsável | Participantes                |
+|--------------------------|-----------------------------------------------------------------------------|-------------|------------------------------|
+| Desenvolvedor Front-end | Codificar o projeto; realizar refatoração                   |             | Arthur, Diego, Gabriel, Luiza, Marcos, Pedro, Victor |
+| Desenvolvedor Back-end  | Codificar o backend; realizar refatoração                                  |             | Arthur, Diego, Gabriel, Luiza, Marcos, Pedro, Victor |
+| Analista de Testes       | Codificar testes unitários e testes de integração                         |             | Arthur, Diego, Gabriel, Luiza, Marcos, Pedro, Victor |
+| Dono do Produto          | Atualizar o escopo do produto; organizar o escopo das sprints; validar as entregas | Luiza       | Luiza                        |
+| Analista de Qualidade    | Garantir a qualidade do produto; garantir o cumprimento do conceito de pronto; realizar inspeções de código |             |              |
+|Cliente|   |   | Mauro Moura|
+
+
+## **Planejamento das Fases e/ou Interações do Projeto**
+
+| Sprint | Atividade | Produto (Entrega) | Data Início | Data Fim |
+|--------|-----------|-------------------|-------------|----------|
+| Sprint 1 | Definição do Produto; Reunião com Cliente | Lista de Requisitos primários | 22/03/24 | 04/04/24 |
+| Sprint 2 | Documentação | Documento de Visão do Produto e Projeto parcial | 05/04/24 | 11/04/24 |
+| Sprint 3 | Revisão e finalização do Documento de Visão do Produto e Projeto; Construção do GitPages do Projeto | Documento de Visão do Produto e Projeto; GitPages do Projeto | 12/04/24 | 18/04/24 |
+| Sprint 4 | Levantamento de Requisitos; Reunião com o Cliente | Lista de Requisitos detalhada | 19/04/24 | 25/04/24 |
+| Sprint 5 | Definição do Backlog do Produto | Backlog do Produto | 26/04/24 | 02/05/24 |
+| Sprint 6 | Declaração de Requisitos | Requisitos estruturados em Épicos, Features e User Stories. | 03/05/24 | 09/05/24 |
+| Sprint 7 | Atualização do documento de Visão; Reunião com o Cliente | Documento de Visão do Produto e Projeto atualizado; Definição do MVP | 10/05/24 | 16/05/24 |
+| Sprint 8 | Prototipação | Protótipos de telas | 17/05/24 | 23/05/24 |
+| Sprint 9 | Refinamento do Backlog; Reunião de validação com o Cliente | Backlog do Produto refinado | 24/05/24 | 30/05/24 |
+| Sprint 10 | Priorização do Backlog; Preparação do ambiente de desenvolvimento | Backlog do Produto priorizado | 31/05/24 | 06/06/24 |
+| Sprint 11 | Atualização do documento de Visão; Desenvolvimento | Documento de Visão do Produto e Projeto atualizado; US | 07/06/24 | 13/06/24 |
+| Sprint 12 | Desenvolvimento | US | 14/06/24 | 20/06/24 |
+| Sprint 13 | Desenvolvimento | US | 21/06/24 | 27/06/24 |
+| Sprint 14 | Atualização do documento de Visão; Desenvolvimento; Reunião de validação com o Cliente | Documento de Visão do Produto e Projeto atualizado; US Entrega e apresentação do MVP | 28/06/24 | 04/07/24 |
+
+
+## **Matriz de Comunicação**
+
+| Descrição                                                       | Área/Envolvidos     | Periodicidade | Produtos Gerados                           |
+|-----------------------------------------------------------------|---------------------|---------------|--------------------------------------------|
+| Acompanhamento das Atividades em Andamento                      | Equipe do Projeto   | Diário        | - Daily escrita                           |
+| Acompanhamento dos Riscos, Compromissos, Ações Pendentes, Indicadores | Equipe do projeto   | Semanal       | - Ata de reunião; Relatório de situação do projeto|
+| Acompanhamento do cliente das atividades em andamento           | Equipe de projeto; Cliente    | Quinzenal     | - Feedback ; Aceitação|
+| Comunicar situação do projeto                                   | Equipe do projeto   | Quinzenal     | - Ata de reunião; Relatório de Situação do Projeto|
+
+## **Gerenciamento de Risco**
+
+Em projetos de desenvolvimento de software, devemos reconhecer e enfrentar as incertezas inerentes que podem surgir ao longo do processo. Desde requisitos inicialmente mal definidos até mudanças frequentes nas necessidades do cliente, as equipes de projeto enfrentam uma série de desafios que podem impactar negativamente o sucesso do projeto. 
+
+Além disso, estimar com precisão o tempo e os recursos necessários para o desenvolvimento do software pode ser uma tarefa complexa, e as diferenças nas habilidades individuais da equipe também podem representar riscos potenciais.
+
+Ao antecipar e avaliar os riscos potenciais, é possível compreender melhor seu impacto sobre o projeto, o produto e até mesmo o negócio como um todo. Dessa forma, torna-se possível adotar medidas proativas para evitar ou minimizar esses riscos. 
+
+Diante disso, apresentaremos os principais riscos identificados pela equipe, bem como os critérios estabelecidos para o replanejamento do projeto:
+
+| Descrição                   | Causa                                                                                                            | Probabilidade | Mitigação                                                                             |
+|-----------------------------|------------------------------------------------------------------------------------------------------------------|---------------|---------------------------------------------------------------------------------------|
+| Redução da equipe           | Trancamento da disciplina ou qualquer questão pessoal dos membros que impossibilite a realização permanente ou temporária das atividades de desenvolvimento. | Média         | Compensar por aumento na carga de trabalho dos membros restantes.                    |
+| Falha na comunicação externa | Falta de comunicação com o cliente por indisponibilidade do mesmo ou perda de contato.                         | Baixa         |                                                                                       |
+| Falha na comunicação interna | Falta de comunicação entre os membros da equipe que possam levar a uma conclusão equivocada ou por outras questões como falta de internet ou energia. | Média         | Repensar a metodologia de comunicação e redistribuir temporariamente as atividades.  |
+| Atraso do cronograma        | Falta de competência da equipe de desenvolvimento com as ferramentas propostas.                                 | Média         | Promover treinamentos para a equipe nas ferramentas em questão.                       |
+| Dimensão do projeto         | Escopo de projeto muito grande para ser desenvolvido em tempo hábil com a competência da equipe de desenvolvimento. | Média       | Redefinição do escopo do projeto.                                                    |
+| Desvio de foco              | Conflito de responsabilidades da equipe com faculdade, trabalho, família e etc. ou falta de motivação dos membros. | Alta          | Comunicação frequente entre os membros da equipe.                                      |
+| Enfermidades                | Incapacitação dos desenvolvedores por questões de saúde.                                                         | Média         | Compensar por aumento na carga de trabalho dos membros restantes.                    |
+
+## **Citérios de Replanejamento**
+
+- Redução da equipe de modo que haja menos de 5 desenvolvedores;
+- Escopo maior que o esperado;
+- Atraso nas entregas finais de cada módulo;
+

mkdocs.yml

@@ -5,7 +5,12 @@ nav:
     - Facção: faccao.md
     - Missão 1:
         - Entrega 1 - Seminário: seminario.md
-        - Entrega 2 - Visão de Produto e Projeto: visaoPP.md
+        - Entrega 2 - Visão de Produto e Projeto:
+            - Produto: produto.md
+            - Projeto: projeto.md
+            - Processo de Desenvolvimento de Software: processo.md
+            - Lições aprendidas - Unidade 1: licao1.md
+
     - Missão 2: missao2.md
     - Missão 3: missao3.md
     - Missão 4: missao4.md