Aprenda Gerenciamento de projetos: planejamento e execução de projetos usando Microsoft Project e JIRA

1. Introdução à introdução do Masterclass: acordo com o PMI, o Project Management Institute, até 2027, boa necessidade do empregador 87,7 milhões de indivíduos que trabalham nas funções orientadas para gerenciamento de projetos. Essas extensões de trabalho são lideradas pelos seguintes setores, fabricação e construção, serviços de informação e saúde, indústria de petróleo e gás, finanças, seguros, empregos e muito mais. Existem muitos caminhos para se tornar um gerente de projeto e não há uma abordagem certa ou errada. Anualmente, os empregadores precisariam de 2,2 milhões de profissionais trabalhando na indústria de gerenciamento de projetos entre agora e os próximos sete anos. Portanto, há muitas oportunidades para você se destacar na carreira de gerenciamento de projetos. Em média, um gerente de projeto ganha entre US$65 a US$220 por hora, o que equivale a cerca de 100 mil a 200 mil por ano. Ei, sou Nikhil. Se PMP e CSM 75 Project Management Professional. Fico feliz que você tenha verificado este curso online e mal posso esperar para começar. A classe está repleta de informações. E atualmente estou trabalhando em uma das empresas Fortune 100 nos Estados Unidos. E eu orientei e treinei muitos gerentes de projeto ao longo da minha carreira. E esta é a primeira vez que estou compartilhando meu conhecimento interno da indústria, minha experiência como gerente de projetos e programas aqui na comunidade online, estou feliz que você está aqui para adquiri-los conhecimento que ganhei para o meu mandato como gerente de projeto na última década, sobre múltiplas falhas e sucessos. Eu personalizei este curso on-line de uma forma que, mesmo que você seja um gerente de projeto experiente ou iniciante, independentemente de onde você esteja em seu caminho profissional atual, você ganharia o conhecimento de que você seria capaz de aplicar em sua carreira de gerenciamento de projetos. Imediatamente após concluir este curso, você poderá entender completamente os fundamentos do gerenciamento de projetos, processos de gerenciamento de projetos, ferramentas , técnicas e como gerenciar com sucesso . Você obterá uma boa compreensão de como usar a ferramenta de gerenciamento de projetos, como o projeto JIRA e MS. Você pode usar a ferramenta certa para seu projeto. Você poderá usar essas ferramentas com confiança e poderá impressionar suas partes interessadas e equipe. Podemos conhecimento e experiência. Ele também aprenderá sobre as habilidades flexíveis que você precisa como gerente de projeto. Como rastrear e preparar o relatório de status, como criar apresentações incríveis quando você precisa pressionar seu gerenciamento superior status e cronogramas e muito mais. Você também aprenderá sobre os certificados de gerenciamento de projetos padrão do setor que agregam valor à sua suposição e como você pode se preparar para esses exames. Também compartilharei dicas sobre como prepará-lo para sua próxima entrevista de emprego no gerenciamento de projetos. Que perguntas esperar e como respondê-las. Bem, se tudo isso soa interessante para você, então assuma o controle de sua carreira e do curso. Vejo você lá dentro. 2. O que é um projeto: Olá, Nesta lição, vamos dar uma olhada na definição do projeto. O que é um projeto. Um projeto é de natureza temporária, o que significa que tem uma data de início e término definidas. Um projeto cria um resultado ou serviço exclusivo. Então, se você olhar para algo que está sendo fabricado, que eles linha de fábrica, isso não é um projeto porque ele está continuamente repetindo as etapas para produzir a mesma coisa. Portanto, se o projeto nunca produzir a mesma coisa repetidas vezes, ele produzirá algo único e pode ser serviço ou produto. Agora, o projeto concluirá o trabalho em algum momento. Completar a palavra não significa que o projeto esteja concluído. Poderíamos concluir o projeto porque ficamos sem dinheiro ou outra coisa. Pode ser que o escopo do projeto não seja mais válido e tenhamos que encerrar o projeto. Então, a qualquer momento, projeto definitivamente terminará independentemente do serviço, seja entregue ou não, todo o produto é criado ou não. Lembre-se desses três pontos. E agora vamos dar uma olhada na definição do PMI. O Project Management Institute. O projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Então, agora vamos ver um exemplo de operações de call center pela própria palavra. Ele revela que é uma operação e não um projeto. O motivo pelo qual um call center é uma operação e não um projeto é porque ele não tem início e fim. Ele vai ser configurado uma vez e os clientes vão ligar para aquele call center dia após dia. Portanto, não há fim para esse processo. Então isso é uma operação. Agora vamos dar uma olhada em outro exemplo. Pintando um quarto. Isso é um projeto ou um conjunto de operações? Então a resposta é que este é um projeto porque esse é um escopo definido, que é definido como pintar sua casa. Então, ele terminará quando a pintura for concluída, ela tem uma linha do tempo definida onde eles podem completar a pintura em uma semana ou um mês. Há um começo e um fim para pintar uma casa. Por essas razões, é um projeto que você pode pegar qualquer coisa que você vê no dia-a-dia e analisar se é um projeto ou operações. Basta lembrar que os três marcadores que eles projetam definitivamente são de curto prazo, o que significa que tem uma data de início e término. Curto prazo não significa que seis meses, pode ser talvez dez anos, mas definitivamente há um início do primeiro ano e terminando um ouvido dez. Então, por esse motivo, será um projeto. Se, se esse projeto produzir um resultado ou serviço único, então fluído que libera seu projeto e definitivamente será concluído em algum momento. Não será contínuo e repetitivo. Essa é uma boa definição de um projeto e como você pode identificar um projeto. 3. O que é gerenciamento de projetos: Nesta lição, vamos nos concentrar no gerenciamento de projetos que pode aprender sobre o que é um projeto na aula anterior. Então, hoje vamos dar uma olhada no que é um gerenciamento de projetos. Então vou mudar para o modo slide e vou me colocar na esquina. Então, vamos dar uma olhada na definição. gerenciamento de projetos é o processo de liderar o trabalho de uma equipe para atingir as metas do projeto dentro das restrições dadas. Então, falaremos sobre as restrições em um minuto. Mas a primeira seção é bem simples. É o processo de liderar o trabalho de uma equipe. Então, obviamente, como gerente de projeto, você tem uma equipe que estaria fazendo o trabalho real. E como líder em gerenciamento de projetos ou PM, você estaria liderando esse esforço para garantir que as metas do projeto sejam alcançadas. Mas vamos dar uma olhada em quais são as restrições de que estamos falando. O primeiro é obviamente o escopo. Ou seja, vamos dar uma olhada no projeto que discutimos na aula anterior, que está pintando sua casa. Qual é o escopo do projeto? Se alguém perguntar, o escopo é pintar o interior e o exterior da casa. Você pode até entrar em detalhes no escopo e, idealmente, seu ****, porque o interior e o exterior são um escopo muito vago e de alto nível. Mas você quer mergulhar fundo em repintar as paredes, estão repintando a porta. Estamos pintando o teto para que possa aumentar ou diminuir o escopo. Se você quiser sempre bloquear seu escopo, mas você tem a opção de atualizá-lo mais tarde. Mas essas são as restrições que estamos falando aqui que impactariam o projeto se não mantidas bem, são bem gerenciadas. Vamos dar uma olhada na próxima restrição, que é custo. Então, qual é o orçamento para fazer essa pintura? Você tem US $5 mil ou tem US $10 mil? Então, qual é o custo para concluir este projeto? Portanto, depende completamente do cliente, ou digamos que você seja o cliente e esteja procurando por pintores para fazer o trabalho, você teria uma quantia fixa de dinheiro que você reservou para concluir o trabalho. Poderia ser de US $1000.100000000000. Depois de começar a obter os tribunais, você pode revisitar o escopo e dizer, eu tenho apenas 1 $1000. Então, não vamos pintar o exterior. Vamos cortá-lo para o interior. É por isso que essas restrições dependem umas das outras. Então, vamos dar uma olhada com um exemplo em um minuto aqui. Mas vamos dar uma olhada no próximo que é o cronograma. O cronograma não passa da linha do tempo. Então, quanto tempo você precisa concluir esse trabalho? Ben, você precisa que este trabalho de pintura seja feito por dois? Você precisa disso antes da próxima semana ou precisa dele até o final do dia hoje? Porque se o cronograma ou a linha do tempo não forem flexíveis, o custo pode subir. Digamos que você quer que alguém complete a pintura hoje, então pode ser possível. Talvez não seja possível. Talvez alguém tenha 20 pessoas que venham completar tudo em um dia. É bem possível, mas você está pagando por 20 pessoas em vez de se você tiver um mês para concluir o projeto. E talvez você possa pagar uma pessoa e tê-la fazer em 20 dias ou mais. Obviamente, estes dependem um do outro. E se algum desses mudar, isso pode afetar a qualidade do projeto. Portanto, você precisa manter ou gerenciar seu escopo, custo e cronograma. E no mundo do gerenciamento de projetos, você ouviria isso como restrição tripla, restrições de projeto. Portanto, isso é muito básico e você sempre ouvirá no mundo do gerenciamento de projetos como as restrições triplas. Então você precisa entender que eles estão falando sobre escopo, custo e cronograma ou todos os três. Porque se algum deles mudar durante a duração do projeto, isso definitivamente afetará a qualidade do projeto. Porque se você quiser pintar sua casa e digamos que você tem apenas 1000 dólares. Então, talvez alguém que gosta de experiência qualificada ou menos possa vir e fazer o trabalho, mas talvez não seja tão arrumado quanto você está pagando alguém para chegar a casa pintado profissionalmente. Então isso é justo. Você pode relacionar esses exemplos causados pelo cronograma de curva de pontuação para pintar sua casa. Como um exemplo fácil de lembrar, veremos em detalhes em um exemplo aqui no quadro-negro. Então deixe-me pular para o Blackboard aqui. Digamos que eu tenha que pintar apenas um quarto. Você tem quatro paredes. Então sua escola é de quatro paredes. O quarto tem uma porta. Então você quer pintar a porta mais o teto? Então, quando você tem isso como seu escopo, digamos que você tenha apenas orçamento como 500. E você precisa fazer isso em uma semana. Digamos que a primeira citação que você recebeu é, ok, eu não posso fazer esse muro de $400. Só para a parede. Então ele se torna 400 para a parede, mais 100 para a porta, mais 50 para o teto. Então, obviamente, 400 mais cento e quinhentos. Portanto, esse custo é 550, que está acima do seu orçamento de 500. Então você reduz o custo e diz, ei, eu não preciso que o teto seja feito. Isso agora impactou a qualidade. Então você tem um quarto limpo, teto sujo. Isso faz sentido? Então é assim que você pode olhar para gerenciamento de projetos e a restrição tripla como um exemplo aqui, qualquer uma das restrições muda como o custo, um cronograma ou escopo, então ele vai impactar o projeto de uma forma ou de outra. Então, como um exercício de aula, quero que você olhe e pense algum outro projeto que você tem em sua casa e veja como você gerenciaria o custo e o cronograma da escola para gerenciar esse particular projeto ou eu pessoal, então isso é tudo para esta aula. Vamos pegar na próxima aula, que será metodologias de gerenciamento de projetos. Falaremos sobre as diferentes metodologias disponíveis são praticadas em comum nos dias de hoje. E vamos dar uma olhada no que são esses. Tudo bem, então vamos encerrar esta aula e eu te vejo na próxima. 4. PMO: Um PMO é um escritório de gerenciamento de projetos. Algumas organizações podem ter PMO e outras podem não estar. A ideia geral do seu escritório de gerenciamento de projetos é configurar diretrizes e fornecer aos gerentes de projeto para executar um projeto ou vários projetos. Se você tiver um escritório de gerenciamento de projetos em sua organização. Assim, o PMO forneceria essas diretrizes sobre o que os KPIs e como eles devem ser medidos, os principais indicadores de desempenho. Eles também teriam um processo em vigor para solicitar gerentes de projeto para gerentes de projeto para diferentes projetos dentro de sua organização. E esses gerentes de projeto farão parte do escritório de gerenciamento de projetos do PMO. Eles serão atribuídos ao projeto para realizar esse projeto. E uma vez que eles fizeram, eles voltam para o PMO e depois repetem esse ciclo. Se sua organização tiver um escritório de gerenciamento de projetos, normalmente é aí que a maioria dos processos está definida, como os KPIs e como o projeto foi rastreado. Todas as diretrizes e treinamento serão fornecidos pelo escritório do PMO. E, como gerente de projeto, aqueles que se reportam ao PMO devem seguir as diretrizes do escritório de gerenciamento de projetos estabelecidas. 5. Metodologias de gerenciamento de projetos: Pessoal, bem-vindos de volta à classe. Vamos dar uma olhada nas metodologias de gerenciamento de projetos. Então, principalmente, existem duas principais metodologias em notícias, especialmente em software, é ágil. Agile pode ser usado em todos os setores, mas está recebendo muita tração no lado do desenvolvimento de software. Agile e Waterfall são as duas principais metodologias que estão em vigor hoje. Vamos dar uma olhada em ambos. As duas principais metodologias que abordaremos hoje são gerenciamento de projetos em cascata e a metodologia de gerenciamento de projetos ágil. Então, vamos falar sobre cachoeira primeiro. Você pode estar familiarizado com este gráfico. Está na indústria há tantos anos e tantos projetos foram concluídos usando cachoeira. Ainda existem organizações que estão executando ágeis ainda seguem metodologias em cascata para determinado tipo de projeto. E vamos dar uma olhada em cada um desses na sessão de hoje. Então, como você pode ver pelo nome e no diagrama aqui, cachoeira é muito sequencial. Você não pode pular de um passo para outro. Como quase realmente. Você precisa completar a primeira fase e depois passar para a segunda fase, como você pode ver no gráfico aqui. Então, ele começa com o planejamento do projeto no topo. É aí que tudo começa. Portanto, o planejamento é feito antecipadamente e sempre há uma maneira de ajustar o plano. E, como sabemos mais, sempre podemos ajustar o plano. Mas em metodologias de cachoeira que é considerada como uma enorme dor de cabeça porque há muita papelada envolvida na mudança do plano de escopo, coisas assim na cachoeira. Se você tiver um escopo predefinido e ele não vai mudar, então a cachoeira é ideal. Mas se você não tem certeza sobre o que esse projeto vai ser, quanto é o esforço? E você só pode saber mais à medida que faz mais coisas do que o que a queda pode não ser a opção. E é aí que o Agile entra em jogo. Mas falaremos sobre o ágil em um minuto. Vamos passar pelas diferentes fases do modelo em cascata. Então, o primeiro no topo, como você pode ver aqui, é a fase de planejamento do projeto. Essa é a fase em que analisamos os requisitos do projeto, o que precisa ser feito, quanto custará no alto nível, quais recursos são necessários? Então, vamos dar uma olhada em todos aqueles no planejamento do projeto e, em seguida, vem a fase de exigência. Então, no requisito, analisamos um requisito detalhado do patrocinador ou cliente e vamos analisá-lo, fazer perguntas e refiná-lo antes de saltarmos para as próximas fases, queremos certifique-se, no modelo em cascata, que o requisito seja coletado o máximo pudermos antes de prosseguir para as próximas etapas. Porque uma vez que iniciamos o projeto , geralmente envolve a obtenção dos recursos reservados ou bloqueados por determinado período de tempo. Portanto, é muito difícil mudar. É sempre um esforço mais doloroso na metodologia em cascata para mudar o recurso ou mudar o escopo, o custo e coisas assim. É por isso que é muito fundamental reunir máximo de informações possível durante a fase de exigência, para que não precisemos mudar muito nos rostos que você vê seguir. Uma vez concluído o requisito , passamos para a análise. Serão envolvidos neste assunto especialistas nesta fase. E dê uma olhada no requisito de ver como podemos criar uma solução. Então esse requisito pode ser que eu precise construir uma ponte sobre este rio e duas milhas de comprimento e você tem um Carlin de quatro bits ou qualquer que seja o requisito. Dependendo do requisito, o especialista no assunto faria a análise e apresentaria o que é o melhor que podemos fazer para esse conjunto de requisitos assim que o requisito é feito. Normalmente, a análise e design são combinados em um único estágio. É apenas documentar qual é a abordagem que vamos adotar para entregar esse requisito, para entregar o produto final com base no requisito, esta é a nossa análise e é assim que faríamos projetar a solução para entregar os produtos. Então é aí que os estágios de análise e design se combinam, normalmente no projeto. E é muito crucial para a equipe de design ou para a equipe de desenvolvimento, que é demonstrado como codificação aqui. Se não for um projeto de software, então pode ser o desenvolvimento real, o que quer que estejamos construindo, essa fase de construção. É aí que o projeto e a análise são fundamentais porque o produto é construído com base no projeto. Então, se você entendeu o design errado, então. E nada pode dar errado na fase de desenvolvimento. Uma vez concluído o desenvolvimento, então o desenvolvedor ou quem quer que esteja construindo esse produto, eles fariam os testes unitários, o significa que fariam os testes básicos para ver se ele atende a isso requisito mencionado na fase dois. E também está em conformidade com os documentos de design. Então, uma vez feito isso , eles o entregariam aos testes, o que seria um grupo independente de pessoas porque eles estão tão focados na solução e no resultado e não olhando através das brechas. É aí que a equipe de testes entraria e eles farão um teste de ponta a ponta. Se seriam testes funcionais, testes integração e todos os tipos de testes diferentes que temos. Então isso será feito na fase de testes. Uma vez concluído o teste, o cliente fica satisfeito com o resultado e, em seguida, implantamos em ambiente de produção ou ao vivo. Se tivermos que dar um exemplo de um site. Então, o planejamento do projeto incluiria, ok, o que, o que o site deve servir? Ele precisa de um login e que tipo de clientes entrarão neste site. Então, tudo isso é feito no planejamento do projeto e a sessão de requisitos detalharia sobre qual método usar para verificar o login. Quais devem ser as credenciais? Eles devem usar nome de usuário e senha? Precisamos de outras informações do usuário, coisas assim. Uma vez definido durante a fase de análise e design é onde o design do site, incluindo a funcionalidade, ocorreria. E com base nesse design, o desenvolvedor, desenvolvedor web desenvolveria um site e ele estaria pronto para testes. Daremos esse produto ao cliente para fazer alguns testes adicionais, incluindo os testes alfa e beta. E uma vez que tudo pareça bom, está pronto para prever. Em seguida, eles aprovavam e implantaríamos o ambiente ao vivo de produção. Mas normalmente é assim que funciona uma metodologia em cascata. E essas etapas são seguidas uma após a outra. Tudo bem, então agora vamos dar uma olhada no processo ágil. Então deixe-me mover-me da direita para a esquerda para que você possa ver a tela. Tudo bem, acho que isso é muito melhor. Agile é tipicamente um processo iterativo que é Scrum e Kanban em ambos os casos, é uma melhoria contínua. Esse é o principal lema do Agile. Então, a razão pela qual o ágil entrou em vigor é, como você vê na cachoeira, temos uma limitação de que, se a fase de análise de projeto der errado, então, obviamente, o resto do rosto vai cair à parte. E é um processo muito demorado voltar e corrigir as coisas. No Agile, a ideia é que entreguemos cedo ou falhamos cedo, seja, no início do projeto, teríamos informações limitadas, então começaremos o projeto com essas informações. E à medida que aprendemos mais, temos a opção de melhorar iterar e construir produtos melhores. Então esse é todo o conceito de Agile. Se você olhar para o círculo 12345, você veria que todas as diferentes fases que temos na cachoeira, na verdade é feito em Agile, mas em pedaços menores. Então, o primeiro é planejamento e priorização. O segundo é o requisito. O terceiro é o design e a análise, a implementação para revisão. Então, todos esses cinco passos são exatamente iguais à cachoeira. Mas que cinco etapas são o processo principal é feito para a peça muito pequena do quebra-cabeça. Ou seja, digamos que se você estiver construindo um site, então primeiro construiremos uma página em branco. E é isso. A página em branco aplicou e veja se ela renderiza e tem as cores corretas, e coisas assim. Então, basicamente, o planejamento seria, eu quero uma página em branco com um fundo branco. Então, isso pode ser feito? Ele passará pelos requisitos de planejamento, desenvolvimento e teste e, se for feito, para que os negócios sejam concluídos. Em seguida, veremos a página de login e diremos: Ok, agora quero digitar o nome de usuário e uma senha e, em seguida ver se ele valida as credenciais e o usuário poderá fazer login. Isso passaria novamente pelos requisitos, análise, teste de projeto e implantação. Assim, o ciclo continua até que todas as pequenas peças sejam colocadas em prática, entregamos um valor menor em vez de todo o projeto como uma implantação de big bang. Então é aí que o Agile é mais eficaz. Porque se algo estiver errado, podemos identificar isso antecipadamente. E essa é uma oportunidade para a equipe corrigir isso antes de lançarmos o Big Bang. Portanto, essas são as duas metodologias de gerenciamento de projetos, cachoeira e ágil. O conselho tem seu próprio lugar no mundo do gerenciamento de projetos. Mas hoje em dia, cada vez mais setores e organizações preferiram ter agilidade porque a TI ágil é muito ágil e a equipe pode se adaptar muito cedo e muitas vezes oferecer melhor resultados do que cachoeira na metodologia de cachoeira, quando você perceber que algo está errado, será tarde demais. Enquanto no Agile, porque estamos fornecendo componentes menores, Produto Mínimo Viável ou o melhor valor que o usuário pode obter. Em um estágio muito inicial, os clientes estão satisfeitos, assim como a equipe recebe feedback que pode ser incorporado ao desenvolvimento e lançamento subsequente . Então, essas são as duas metodologias de gerenciamento de projetos proeminentes . E na próxima lição, vamos dar uma olhada nas lideranças morrem e no estilo de gerenciamento de projetos para cada uma dessas metodologias. Porque, como gerente de projeto, você lideraria o projeto completamente diferente em Cachoeira versus Ágil. E Cachoeira, é uma regra muito comandante versus uma ágil. É mais a liderança de servidores. Vamos dar uma olhada no estilo de comando ou liderança na próxima lição ou no próximo capítulo. E olhamos para a autoridade de liderança para cachoeira e ágil. Então isso concluirá esta lição e iremos para a próxima lição para analisar o estilo e a autoridade de liderança. 6. Cerimônias de gerenciamento de projetos: Na classe anterior, analisamos os estilos de liderança e hoje vamos dar uma olhada nas cerimônias em cascata e ágil. Isso deve dar um exemplo, uma ideia de por que certas autoridades de liderança são exercidas em Cachoeira versus Ágil. Então deixe-me mostrar-lhe esta apresentação de slides aqui. Na cachoeira, como olhamos na classe anterior, temos um gerente de projeto comandante autoritário que está explicando à equipe o que fazer, não necessariamente como, mas quando fazê-lo e entender por esse motivo, você tem que olhar para as cerimônias. Então, em um projeto típico em cascata, você teria grandes reuniões nas quais vários participantes participavam da reunião de status. Se você olhar para os detalhes da equipe em uma cachoeira, às vezes você teria clientes entrando na reunião. Você tem sua equipe de produto, sua equipe de projeto. Às vezes, deve haver um patrocinador do projeto participando da chamada ou de um cliente. Portanto, há vários grandes grupos de pessoas que se juntam a uma chamada. Eles podem ter interesse em peças menores dentro do projeto, mas não como um projeto geral. É claro que seu cliente e patrocinador têm a ideia de concluir o projeto ou o escopo que eles pediram para você concluir. Mas pode haver outra equipe multifuncional dentro da equipe maior onde eles estão participando para realizar determinadas tarefas no projeto. Portanto, eles podem não estar completamente cientes do seu projeto ou não estão interessados no projeto completo. É por isso que o gerente de projeto tem que estar em uma posição de comando para controlar a reunião, para garantir que as coisas sejam discutidas e apenas as coisas relevantes sejam discutidas. Então ele tem que assumir o controle. Ele tem que estar no comando para garantir que o resultado que a equipe do projeto e eu dizemos PM, o que ele ou ela está procurando que seja alcançado a partir da reunião. cerimônias típicas em cascata incluem a reunião semanal de status onde a equipe do projeto discutiria o status. O gerente de projeto analisaria o risco e problemas e veria se algum risco ou problema precisa ser tratado neste momento em decisões discutidas será logado, e se há algum outro coisas que precisam ser comunicadas, essas coisas surgirão durante a reunião de status. D controla uma reunião de status de ponta a ponta. Então é por isso que ele tem que ser autoritário. Agora vamos dar uma olhada na próxima cerimônia, que é ágil. E normalmente, como vimos na classe anterior, os Agile Scrum Masters são líderes servidores, o que significa que eles são mais como um facilitador. Então, por que esse é o caso? Porque em uma reunião ágil, mais do que status, é o stand-up diário onde a equipe vem colaborativamente e se gerencia nas tarefas em que está trabalhando. Eles não precisam de muita contribuição do Scrum master porque é uma equipe autogerenciada e sabem o que fazer e como fazê-lo. Então, se você olhar para essa equipe de cram, você tem Product Owner, Development Team e Scrum Master. Portanto, é uma equipe principal que está focada em um único motivo que é o escopo do projeto para concluir esse projeto, então não há interrupção como tal. Portanto, o Scrum Master não precisa ser tão autoritário ou comandante para cuidar de nada porque é sua equipe principal. Você não precisa se preocupar em controlar o principal. É apenas treinar a equipe para se certificar de que eles são autogerenciados. Então, em poucas palavras, é a razão pela qual o gerente de projeto versus queimado todos tem que exercer seu poder de autoridade de comando uma maneira diferente por causa da natureza do metodologia que está em uso no gerenciamento de projetos, isso é algo que você precisa ter em mente ao executar Cachoeira versus Agile. Agora, na próxima aula, vamos dar uma olhada nas diferentes estruturas dentro do Agile, as duas mais usadas uma vez ou Scrum e Kanban. E veremos como esses dois são usados e qual é a diferença. 7. Governança de projetos: Tudo bem, então agora vamos dar uma olhada na do projeto por definição, a governança do projeto é a estrutura de gerenciamento dentro da qual as decisões do projeto são tomadas. Gostaria de acrescentar que os convênios do projeto são a estrutura e a estrutura em que como esse projeto em particular será executado para que todos na equipe tenham a mesma ideia, mesmo entendimento do o que fazer quando, por definição, governança do projeto é a estrutura de gerenciamento dentro da qual as decisões do projeto são tomadas. O que isso significa é como esse projeto será executado. Qual é a estrutura geral? O que a equipe se parece? Como nos comunicamos uns com os outros? O que acontece quando temos um problema? Como escalamos um problema? O que acontece quando as decisões devem ser tomadas? Quem deve ser abordado para decisões? Quem é a autoridade para tomar essas decisões para o projeto? Como obtemos aprovações? O que acontece se houver uma mudança no trabalho de gerenciamento de mudanças de artistas de projeto que é responsável por quê? Então, basicamente, está definindo uma grande diretriz para toda a equipe do projeto. Então, todos são muito claros sobre qual é sua responsabilidade e responsabilidade. E algumas das coisas que você faz como parte da governança do projeto é a matriz RACI. O RACI não passa de um gráfico em que você lista cada membro da equipe individual e os marca como responsáveis, responsáveis , consultados ou informados. Então, se alguém tiver que fazer o trabalho real, eles seriam responsáveis por isso. Então ele nunca exemplo do projeto do site, das pessoas que são responsáveis por projetar a página da Web ou os desenvolvedores finais do amigo. Então, quando você tem uma tarefa de projeto e o plano que diz projetar a página da web front-end. Então, você atribuiria esse desenvolvedor da Web como a parte responsável. Como gerente de projeto, você se marcará como responsável por essa mesma tarefa. E então você teria a equipe de design que entregou o design a esse desenvolvedor. Eles seriam marcados como consultados e todas as outras partes interessadas dos projetos seriam marcadas como no PharMD. Então, em qualquer ponto do tempo, cada item de linha em seu plano de projeto, é bom ter um RACI responsável, responsável, consultado e informado para que todas as partes do projeto saibam o que eles são responsáveis, quem é responsável por isso, e quem deve ser consultado se tiverem dúvidas, e quem deve ser mantido na fonte. Isso é realmente fundamental para definir como uma equipe e entender e obter um acordo de que essas são as responsabilidades do projeto e é assim que vamos gerenciar a equipe e executar o projeto. Em seguida, são as aprovações. Então, digamos que você tenha um orçamento acima e planeje gastar US $100 mil, mas agora você tem que ter 150 mil. Como eu definiria a aprovação funciona? Quem aprova esse orçamento extra e quando o projeto atinge essas coisas, então você sabe exatamente como obter as aprovações e seguir em frente. Em vez de descobrir no momento da execução, você tem uma comunicação que é muito crítica. Como você se comunica entre equipe, projeto interno e externo e tudo isso. Então, na lição subsequente, vamos dar uma olhada sites de colaboração e como você os configura antes do projeto para que o membro da equipe tenha um lugar onde eles possam armazenar documentos, eles podem se comunicar e tudo isso. Então você também tem que definir o engajamento das partes interessadas, como o status do projeto seria relatado, quantas reuniões participar? Quais são as reuniões críticas? Quem deve participar dessas reuniões? Como as decisões são tomadas? Quem deve estar envolvido na tomada de decisões? Tudo isso combinado, essa é a governança do projeto. Então, uma vez que você desenvolve esse projeto linear é um bom começo porque agora você tem diretrizes adequadas. Então pense nisso como você e seus amigos vão para uma noite de cinema. Então, tendo um bom plano adiantado que vamos ligar para a Uber, vamos chegar às exibições e partir daí , receberemos os ingressos. Eles vão jantar lá fora, todas essas coisas diferentes. Então, todo mundo está meio alinhado o que precisa acontecer quando aquela noite de cinema, o dia chega. Você pode pensar na governança como semelhante a essa, para colocá-la de uma maneira fácil aqui, em alguns casos, se você não tiver um PMO, o escritório de gerenciamento de projetos, então você pode ter que configurar isso para si mesmo. Nosso amigo em determinada organização há um escritório de gerenciamento de projetos PMO. Eles teriam modelos padrão para cada um dos itens discutidos aqui, como aprovações atrevidas, Reunião, modelos e formato. Assim, você pode pedir à equipe do PMO para fornecer todos os modelos e você pode reutilizá-los. Mas mesmo que você não o tenha, é apenas definir como essas coisas acontecerão, documentando-as e compartilhando-as com a equipe para que todos estejam alinhados antes do início do projeto. Às vezes, eles podem ser requisitos do comitê de direção. Comitê Diretor podem ser os líderes interessados em seu projeto. Eles podem ter um portfólio de projetos. Digamos que eles estejam trabalhando em uma implementação digital maior da organização. E o projeto do seu site é apenas um dos projetos. Então, em geral, eles querem saber sobre todo o portfólio sob a implementação digital e o projeto do site sendo um deles. Eles podem ter um requisito específico de que você pressione o status do projeto e no final do mês. Essas coisas também precisarão ser definidas para que tudo esteja envolvido em torno da governança do projeto. E é definido antecipadamente antes do início do projeto, você pode baixar os modelos para cada desses itens listados aqui para um desses itens listados aqui para entender melhor o que significa e como ele se parece como em um projeto do mundo real? 8. Ferramentas comuns de gerenciamento de projetos: Agora que temos uma boa compreensão da cachoeira e do gerenciamento ágil de projetos, agora vamos dar uma olhada nas diferentes ferramentas usadas pelo gerente de projeto ou scrum master para projetos em cascata e ágeis. Então deixe-me pular para a apresentação de slides aqui. Portanto, gerenciando um projeto em cascata, o gerente de projeto está usando principalmente ferramentas que o ajudam a planejar e criar relatório de status, bem como mostrar dependências e fluxo de trabalho. Então, vamos começar do topo. Então, o primeiro é o Microsoft Visio. O Visio é uma ferramenta usada por gerentes de projeto e designers para mostrar a dependência em um formato de pista de natação. Você pode mostrar fluxograma e coisas diferentes em physios e isso é muito útil para mostrar quais são as dependências do projeto, como o fluxo de trabalho se parece. Aqueles que são externos ao projeto. Eles entendem uma imagem de alto nível. E vizio é uma ferramenta poderosa para demonstrar que a segunda TI mais usada no dendrito superior esquerdo, que é o PowerPoint e o Excel. Na maioria dos casos, os gerentes de projeto preferiram criar plano e projeto MS, mas é uma ferramenta tão complexa que, uma vez que você desenvolve o plano quando ele faz algumas mudanças sutis, é difícil manter que planta, então as pessoas preferem ir com excelente lugar e também é fácil compartilhar o Excel, então MS Project, porque se a outra pessoa não tiver licenciado e não puder abrir e entender isso. Como PM, você tem um bom controle sobre o projeto MS, mas para outros dentro da equipe, uma maneira melhor de olhar para o plano e uma linha do tempo seria o Excel. O Excel também é usado para manipular dados, criar tabelas dinâmicas e analisar dados, coisas assim. Então, o Excel é muito usado em um projeto em cascata. Se você olhar para o relatório de status e outras coisas que você precisa apresentar como gerente de projeto. É aí que os documentos PPT e Word são usados. Se você tiver que documentar o fluxo de trabalho ou anotar o processo, é aí que a palavra entra. Mas você precisa fazer um relatório de status ou fazer apresentação à liderança. É aí que o Microsoft PowerPoint é usado. Além disso, para armazenar todos esses documentos, costumava ser SharePoint no passado. Agora, a maior parte da organização se mudou para a Microsoft em 18. E, em alguns casos, eles podem ser Google, OneDrive e muitas outras coisas em que todos esses artefatos do projeto são armazenados. E essas são as principais ferramentas usadas para cachoeira como gerente de projeto. Em alguns casos, para análise detalhada do banco de dados e coisas assim. Microsoft Access também é usado como ferramenta, mas em casos muito raros. Agora vamos dar uma olhada no Agile. No Agile, as duas ferramentas principais comumente usadas, nosso Jira e Confluence. Jira é o seu quadro onde as notas adesivas e os sprints e o backlog do produto são mantidos. E o Confluence é semelhante ao SharePoint, onde toda a documentação relacionada a essa placa do Jira é mantida. Além da confluência GLN, a equipe ou o Scrum Master também usam ferramentas que sejam boas para planejamento retrospectivo e também para estimativa. A ferramenta que é comumente usada para apontar histórias é o planejamento de poker. Vamos dar uma olhada naqueles mais tarde na aula. Mas estas são de alto nível, as ferramentas gerais usadas pelo gerente de projeto ou scrum master para gerenciar e executar projetos. 9. Gerente de projetos VS Masters Master: Tudo bem, então na aula de hoje, vamos falar sobre os estilos de liderança no gerenciamento de projetos. Existem principalmente dez estilos de liderança diferentes, mas a classe de hoje vamos baseá-la na função de gerente de projeto versus mestre do Scrum. Assim, você pode entender melhor quando você está gerenciando um projeto em cascata, que tipo de autoridade de liderança você herda versus quando você está fazendo um papel mestre do Scrum, que tipo de função de liderança você deve ou que tipo de papel de liderança você deve exercer? Então, vamos dar uma olhada na função de gerente de projeto e na função principal do Scrum e ver como a liderança difere em ambas as funções. Então, acredito firmemente que uma imagem representa mais do que palavras. Então, para o gerente de projeto, é assim que normalmente um gerente de projeto se comporta. É que ele tem total autoridade e controle sobre a equipe. Ele comunica que o centro cai entre a equipe, o cliente, o patrocinador da parte interessada e todos, certo? Então ele se torna o único forçado a direcionar todos para alcançar os objetivos do projeto. Então é isso que você vê na foto em que o gerente de projeto está no topo. Ele está anunciando o microfone, o que precisa ser feito? Não necessariamente como, mas ele prepara o palco para a equipe. Portanto, a equipe tem a maior responsabilidade de executar a tarefa. Mas, como gerente de projeto, ele tem mais poder de comando, ele tem mais autoridade se não estiver recebendo nada feito da equipe ou equipe multifuncional. Ele tem a capacidade de escalar e obter ajuda. Ele está mais no controle do que na equipe. Agora vamos dar uma olhada na foto do ScrumMaster. Aqui. O ScrumMaster é mais como um líder servo. Ele é um treinador e facilitador em vez do poder de comando que o gerente de projeto rasgou o ScrumMaster é mais como um treinador e ele está orientando a equipe sobre como e o que fazer e a equipe tem que controlar. Então, como você pode ver, o scrum master está carregando o fardo para garantir que a equipe possa progredir bem e remover impedimentos. Então agora também falaremos sobre as cerimônias que temos no gerenciamento de projetos em cachoeira. Vamos dar uma olhada na esquerda onde o gerente de projeto tem reuniões de status onde ele passará pelo status e ele não está necessariamente resolvendo o problema, mas ele está mais coletando o status e entender qual é o problema. Você sempre pode tentar resolver o problema. Mas na maioria dos casos em cachoeira, ele ou ela da equipe precisa se comunicar com o gerente de projeto sobre qual ajuda é necessária. E o gerente de projeto tem o comando e o controle sobre a equipe. E se alguém não está fazendo o trabalho, ele pode escalá-lo ou ele pode resolvê-lo por causa de seu poder de comando. Por outro lado, é algo semelhante, mas o ScrumMaster é mais como um facilitador em um standup diário, seu status de não coleta. Nosso mestre está mais tentando facilitar as principais coisas para que a equipe possa si mesmo e gerenciar a tarefa. E o Scrum Master está lá para entender se a equipe está fazendo um bom progresso e se eles têm um impedimento Bell, eles precisam de ajuda dos mestres para resolvê-lo principalmente, eu diria que O papel de gerente de projeto na cachoeira é mais como assistir a equipe e pedir continuamente status e seu acompanhamento em um mestre do sistema. Cabe à equipe sobre como fazer isso e o que fazer. Grão-mestre está tentando facilitar o progresso geral do projeto. E ele ajuda a equipe a entender se há algo que está impedindo de fazer esse progresso e ele pode ajudar a resolver esses problemas. Então, tanto a intenção está bem, fazer a equipe fazer o trabalho e elevar qualquer problema. Mas o ScrumMaster é mais como um líder servo versus o gerente de projeto é mais como, Ei, autoridade comandante. Se você olhar para outro exemplo de como essa reunião vai na cachoeira, gerenciamento de projetos, o gerente de projeto decide qual prioridade de tarefa e ele atribuirá o gerente de projeto atribuiria a equipe. Ok, estes são priorizados e sabiam como andar sobre isso. Enquanto no Agile, a equipe tem a prioridade dependendo do que o proprietário do produto priorizou com base nessa equipe prioritária pode decidir em que deseja trabalhar. Eles atualizariam esse grande mestre que estou trabalhando nisso e é assim que ele está progredindo. Então essa é a diferença entre um líder servo desse lado dos grandes mestres em relação um gerente de projeto comandante e autoritário. Do lado das cachoeiras, é apenas uma maneira diferente de executar o projeto para progredir no projeto. Portanto, esse é um estilo de liderança rápido em cascata e metodologia ágil. Na próxima aula, veremos detalhadamente a cerimônia é que cada uma dessa metodologia de gerenciamento de projetos tem Cachoeira versus grama. E o que um gerente de projeto tipicamente cachoeira decimal e o que um ScrumMaster faz para um projeto ágil. 10. SCRUM e KANBAN: Tudo bem, nesta classe vamos dar uma olhada nas estruturas Scrum e Kanban usadas na metodologia ágil. Como é diferente e quando usar o quê? Então, primeiro vamos dar uma olhada no Scrum Framework. Scrum framework, se você se lembrar da classe anterior que discutimos sobre como iniciar, planejar, executar, monitorar e controlar e fechar o projeto. E no framework Scrum, é repetido várias vezes. É por isso que é uma abordagem iteradora em que as fases de gerenciamento de projetos são repetidas várias vezes em toda a estrutura Agile Scrum, e é repetida durante a caixa de tempo no diabo chama print. Você pode ter um sprint de uma semana ou até quatro semanas. E, normalmente, a maioria da equipe do projeto exercita um sprint de duas semanas, onde é suficiente planejar e fazer as coisas. E ao final do fio, você tem que fazer certas cerimônias. Então, uma semana será marcada para a maioria das equipes. Normalmente, o que vimos na indústria é que as pessoas passam de duas a três semanas na primavera, a maioria da equipe fazendo três semanas e alguma equipe fazendo em duas semanas, se for suporte de previsão, eles podem até ir para um sprint mensal, que é um sprint de quatro semanas. E no final do mês eles podem fazer o ciclo de lançamento. Portanto, qualquer produto que eles desenvolveram ou aprimoramentos que tenham feito , pode ser lançado em produção até o final desse mês. Agora vamos dar uma olhada neste slide mais de perto e passar por cada uma dessas imagens e o que isso significa. Tudo bem, então vamos começar pela esquerda e ir para a direita. Então, primeiro à esquerda, você pode ver o proprietário do produto. O proprietário do produto é aquele que interage com o cliente ou o cliente e coleta todos os requisitos e os coloca na lista de pendências. Backlog tem toda a lista de desejos do proprietário do produto e do proprietário do produto refinam continuamente a lista de pendências para priorizar os itens que precisam ser entregues primeiro. Portanto, qualquer requisito em que a equipe precisa trabalhar, eles têm backlog do produto como referência e geralmente a equipe pode pegá-lo do topo do backlog porque é assim que o proprietário do produto deve priorize os requisitos no Product Backlog. Qualquer coisa que precise ser entregue cedo vem por cima, e qualquer coisa que possa ser atrasada ou entregue mais tarde que vá na parte inferior da lista de pendências. Agora vamos ver se a equipe decidiu trabalhar em certas coisas e escolhe cinco itens do topo da lista de pendências do produto. Isso acontece durante a reunião de planejamento de sprint. O proprietário do produto, a equipe e o Scrum Master fizeram durante essa reunião de migalhas e planejam os itens para os quais eles querem trabalhar. Digamos que, neste caso, uma equipe tenha um sprint de duas semanas. Eles vão ver o que podem trabalhar nas próximas duas semanas. Então, eles escolherão talvez cinco itens da lista de pendências do produto e concordarão em trabalhar neles. Então, durante essa colheita, eles estimariam quanto diamante vai levar. E isso é baseado na experiência. E mais tarde, na aula, discutiremos sobre apontar histórias e quão eficaz é esse método, como usar o planejamento do poker e como a equipe amadurece à medida que passa por vários sprints. Mas, por enquanto, apenas entenda que a equipe pode escolher as tarefas que eles acham que podem terminar nas próximas duas semanas. E isso vai para um backlog de sprint. Se houver 50 itens na lista de pendências do produto, eles escolherão os cinco primeiros e se movem para algo chamado backlog de sprint. E durante a reunião de planejamento, se o proprietário do produto da equipe e o scrum master concordarem com a escola, eles iniciam esse sprint pelas próximas duas semanas. Uma vez que um sprint é iniciado, a equipe fez diariamente para olhar onde eles estão, discutir sobre o que estão fazendo, o que eles fizeram e quaisquer impedimentos que precisam de ajuda com. E isso continuará pelas próximas duas semanas ao longo do final deste sprint e, no final deste sprint, a equipe pode ganhar ganho para a revisão do sprint e para demonstrar o item concluído para o produto proprietário. Normalmente, esse é o Scrum Framework, e isso se repete até que os requisitos do produto da etiqueta final no Product Backlog sejam concluídos. Poderia levar vários sprints para concluir o backlog detalhado. No final do último sprint é onde a equipe terá um produto acabado totalmente funcional. Quando olhamos para um exemplo prático prático, você entenderia mais sobre backlog de produtos, sprint, backlog, o sprint em si. E não se preocupe muito apenas em entender terminologias diferentes neste momento. E quando fizermos um projeto prático, você terá mais compreensão de cada um desses itens. E também veremos queima e queima gráfico. Algo que não é mencionado aqui é gráfico de velocidade. Essas são métricas e relatórios que ajudam a equipe a entender como eles funcionam e o que precisam se ajustar para entregar pontos de história consistentemente semelhantes. Tudo bem, em seguida, passando para a estrutura Kanban. Na estrutura Kanban, temos um conselho semelhante ao embaralhado, mas não há ativos de backlog de primavera. É uma placa contínua, então temos um backlog de produtos à esquerda e, em seguida, equipe decide em que precisa trabalhar e colocá-lo no ToDo. Uma vez que eles tenham certos itens para esse mês específico, eles começariam a escolher um da lista de tarefas e começariam a progredir. E nesse momento eles passarão para mandados em andamento ou em andamento de que a tarefa é feita. Eles se moverão para fazer. E quando estiver completamente concluído, eles se moverão para o arquivamento ou simplesmente riscarão como completo. Então, neste caso, a equipe tem um limite. Eles só podem trabalhar em determinado número de pontos da história em um mês. Você pode pensar em Kanban como digamos, sistema de emissão de bilhetes. Então, digamos que você tenha um parque local. Se alguém tiver que entrar no parque, ele precisa pegar um ingresso. E quando eles saírem do bug, eles vão distribuir esse bilhete de volta para o segurança. Nesse caso, digamos que a capacidade do parque seja de dez pessoas. No portão de entrada, o segurança teria dez ingressos, o que significa que não há ninguém dentro do parque e do parque e permitiria que até dez pessoas entrassem. Então pense nas pessoas que entram no parque, perguntaram a tarefa, entrando no tabuleiro assim ingressos de entrada para dez pessoas forem entregues, isso significa que ele, o deus, não tem mais ingresso para entrega. Então, qualquer pessoa que espera na fila tem que esperar até que uma das dez pessoas que estão dentro do parque saia para que, quando uma pessoa sair, esse bilhete seja recolhido e possa ser entregue ao próximo pessoa. Qualquer ponto do tempo. Poderia haver apenas dez pessoas dentro da peça. Essa é a capacidade ou o limite do parque em Kanban é o mesmo conceito. Sua equipe ácida tem uma capacidade que você pode entregar para esse período de tempo. Digamos que seu período de tempo seja de quatro semanas ou um mês. Em um mês, você pode dizer, gerenciar dez pontos da história da lista de pendências, você pode pegar até dez itens ou dez pontos da história que podem ser colocados na lista de tarefas. E quando chegar a dez, você não deve mais escolher do backlog porque essa é a sua capacidade para esse mês para a equipe. Então, uma vez que você tenha a capacidade, você começa a fazer esse trabalho. E isso entra em andamento. E Dan, depois de ter concluído sua primeira tarefa, então você liberou um pouco mais de capacidade para que o tempo você possa ir e escolher de tarefas e passar para o andamento e continuar fazendo essas coisas até lá não há nada para fazer naquele momento, você pode voltar para a lista de pendências e escolher mais itens que podem ser concluídos na mesma primavera ou planejar para o próximo sprint. Então essa é a diferença entre Scrum e Kanban, onde kanban é baseado no limite, enquanto com é baseado nisso não é limite. Ou a equipe executa sprint após a Sprint, eles podem melhorar e entregar mais pontos da história, se necessário. 11. Plano de gerenciamento de escopo: Tudo bem, então nesta lição falaremos sobre o plano de gerenciamento de escopo. Mas antes de entrarmos no plano de gerenciamento de escopo, é importante saber que temos um plano geral de gerenciamento de projetos. Normalmente, você pode ter visto cronograma do projeto MS e, na maioria das vezes, isso é apenas um cronograma. Normalmente, não colocamos o escopo e outros planos de gerenciamento de projetos no gráfico de Gantt porque ele é usado principalmente para fins agendados. Então, deixe-me falar sobre os diferentes planos que temos no plano geral de gerenciamento de projetos. E então iremos para o plano de gerenciamento de escopo. Se eu compartilhar minha tela aqui, você diria que há nove planos de projeto diferentes disponíveis no plano geral do projeto. Começando com escopo, cronograma, custo, qualidade , recursos, comunicação , risco, compras e gerenciamento de partes interessadas. Todos esses planos combinados são chamados de plano geral de gerenciamento de projetos. Mas 99% da organização quando eles estão falando sobre plano de projeto, eles estão se referindo provavelmente ao plano de gerenciamento de cronogramas. Vamos dar uma olhada no plano de gerenciamento de cronogramas quando chegarmos lá. Então, nesta lição, primeiro analisaremos o plano de gerenciamento de escopo na fase de planejamento do projeto. Vamos ver onde ele pertence ao planejamento do projeto. É parte inovadora da fase de planejamento. E o que isso implica são, em geral, os requisitos. Se você pensar em um projeto que obviamente é um requisito do patrocinador ou das partes interessadas, mesmo antes do gerente de projeto estar integrado, eles têm uma ideia de alto nível do que queriam. Digamos que eles queiram lançar um site onde possam vender seus produtos online. Portanto, se esse for o requisito de alto nível, então, no plano de gerenciamento de escopo, uma vez que você engate o PM ou usaid PM, você teria que se aprofundar nesses requisitos porque quando um casos de negócios juntos, Não está no nível detalhado, é em um nível mais alto o que as necessidades de negócios são e com base na estratégia que a organização quer, o business case é montado nesse nível. Quando você entra na fase de planejamento do projeto é quando você pega esse caso de negócios e, em seguida mergulha profundamente nos requisitos. Em uma cachoeira, você teria um analista de negócios ou um arquiteto empresarial ou outra pessoa para ajudá-lo nesse processo. Caso contrário, você precisa envolvê-los para obter esses requisitos da empresa de forma muito detalhada. Este é o documento ou a saída do plano de gerenciamento de escopo seria aquele que você pode compartilhar com seus desenvolvedores é quem está trabalhando no desenvolvimento desse produto. Portanto, é muito crítico que você entenda qual é o escopo do projeto e em que nível precisamos mergulhar fundo na escola para conhecer o projeto ou a parte interessada ou os patrocinadores requisito. O primeiro ano é o requisito. Obviamente, você precisa encontrar uma maneira de coletar os requisitos. Você se encontraria com os especialistas do lado comercial. Digamos que a ideia aqui é lançar um site para vender esse produto online. Então, você iria com a equipe de marketing, equipe de vendas e coletaria os requisitos de cada uma dessas funções. Você também teria que se reunir com as finanças como o pagamento deve ser processado, tudo isso. Você precisa pensar sobre o processo completo de ponta a ponta e definir o escopo para cada função. Esse é o segundo ponto de bala aqui que, depois de identificar o requisito, você define o escopo das vendas. Essas são as coisas que você vai fazer para o marketing. Essas são cinco coisas que você faria ou que estariam disponíveis no site ou no produto. Em seguida, você divide essas coisas em componentes menores e gerenciáveis para que a equipe possa trabalhar. Então, normalmente, se for um projeto ágil, tudo isso entrará no backlog do produto e, em seguida, você poderá dividir em histórias menores e gerenciáveis. Isso é tudo. Esta seção é. Depois de ter feito isso, então você teve que fazer a linha de base, o que significa que esse é o seu ponto de partida. Então, todo mundo tem que concordar com esse ponto de partida. E então você desenvolveria uma matriz de rastreabilidade de requisitos que só é necessária se você estiver executando um projeto em cascata. Normalmente, você não faz isso em um projeto Agile porque tudo o que você tem é colocado na lista de pendências do produto. E se houver coisas novas, você trabalharia com o proprietário do produto para adicioná-lo à lista pendências do produto no final antes de eu pular para o escopo, aprovações, requisitos, rastreabilidade, se eu tiver que lhe dar no nível mais alto, o que isso significa é apenas mapear os requisitos que você coletou na primeira etapa e mapeando-os para sua solução, como esse requisito será atendido no projeto e desenvolvimento. Então é isso que é a rastreabilidade dos requisitos. É apenas o seu documento do Word ou um Excel para mostrar às partes interessadas ou ao patrocinador que cuidamos de todos esses requisitos e é assim que ele será atendido. Então diz documento direto, você pode até fazer em um PowerPoint, não um problema. As aprovações de escopo são algo que, uma vez que você tenha a linha de base do requisito ou a linha de base do escopo e todos os requisitos são mapeados para documentos de design apropriados e como entregaremos esses novos. Apresente isso de volta ao patrocinador ou stakeholder e diga Veja como vamos fazê-lo. Você prova que este é o estágio que você também mencionaria sobre a solicitação de alteração. Ou seja, se houver alguma alteração no que definimos aqui ou no que fornecemos como é chamado de linha de base, então temos que fazer uma solicitação de alteração, o significa que qualquer alteração adicional na linha de base seria incorrem em custo, tempo e esforço. Então, é melhor definir isso o que isso processa. Portanto, em um nível muito alto, plano de gerenciamento de escopo lida com a coleta de requisitos, dividindo-o em componentes gerenciáveis menores e baselinando-o como ponto de partida e obtenha as aprovações e alinhe todos para concordar que isso é o que eles vão fazer porque ajudará nas próximas fases do gerenciamento de projetos. Tudo bem, então é assim que o plano de gerenciamento do escopo do projeto é desenvolvido. Apenas certifique-se de que você identificou todas as áreas e todas as funções as incluíram no processo de coleta de requisitos para que você não esteja perdendo nenhuma função específica. Contanto que você faça isso, será muito suave na fase de execução subseqüente. Quando temos que entregar o produto. 12. Recolhemos os Gathering: Tudo bem, bem-vindo de volta. Na lição de hoje, vamos dar uma olhada na coleta de requisitos de negócios. Esta não é necessariamente uma função que você deve fazer como gerente de projeto, mas alguém da sua equipe deve fazê-lo. Se for um projeto ágil, geralmente é feito pelo proprietário do produto trabalhando com o cliente para entender quais são os requisitos de negócios. Se for uma metodologia tradicional em cascata, você teria patrocinador de negócios e o analista de negócios de sua equipe trabalhando de perto para entender os requisitos de negócios e documentados para o projeto. Então, nesta lição, abordaremos quais são os diferentes tipos de requisitos? Quais são as diferentes técnicas que você pode usar para coletar os requisitos? E também como os requisitos serão divididos em componentes menores para que você possa planejar em seu plano de projeto para atingir esses requisitos de negócios na metodologia em cascata e ágil. Então, vamos começar com os diferentes requisitos de negócios que precisamos examinar. Tudo bem, então, quando olhamos para as sessões de coleta de requisitos de negócios, você sempre tem que ter em mente qual é o objetivo do projeto. Caso contrário, pode haver fluência do escopo, que é apenas o escopo adicional que pode entrar como parte dessa coleta de requisitos. Se alguma parte interessada do projeto tiver requisitos adicionais e se você não tiver certeza se está alinhada à meta do projeto ou aos resultados, então você deve classificá-lo e depois voltar a ele mais tarde, colete todos os requisitos que você puder. Mas você só deve se concentrar naqueles que estão diretamente relacionados aos objetivos do projeto. Então, para dar um exemplo, digamos que você esteja migrando em plataforma legada antiga para uma plataforma moderna. Digamos que você tenha todos os seus aplicativos bancários ou financeiros em sistemas de mainframe legados. E você quer migrar isso para uma interface moderna baseada na Web. Pode haver limitação para o usuário que usa o sistema de mainframe para fazer alguma coisa. Digamos que eles quisessem desenhar algo na tela, que não é possível no sistema de mainframe porque esse é um sistema antiquado. E na solução moderna baseada na web, possivelmente você pode fazer isso no iPad ou no iPhone. Mas esse não é um requisito alinhado ao projeto chamado objetivo do projeto é mover o requisito ou as funções de negócios dos sistemas legados de mainframe para os modernos sistemas baseados na Web. Portanto, se esse for o requisito, então todos esses recursos adicionais que os usuários desejam, eles podem ser distribuídos para versão adicional para não combiná-lo com os requisitos do projeto, pois ele irá aumentar o escopo do projeto e você não seria capaz de entregá-lo no prazo e dentro do orçamento que você tem para o projeto que está sendo dito que vamos saltar para diferentes requisitos. Um deles é o requisito comercial. Esses são os principais requisitos da função comercial. Seja um patrocinador ou quem está se beneficiando do projeto, eles declarariam esse requisito na ideia de negócio de charter do projeto, um caso de negócios. E aqui o que estamos fazendo é dividir em mais detalhes para que possamos planejar. Fiz um nível detalhado. O exemplo de requisitos de negócios pode ser como uma companhia de seguros, quero migrar todo o meu aplicativo legado uma plataforma moderna baseada na web. Esse requisito está afirmando que o que estamos usando atualmente está funcionando, mas gostaríamos de ter mais recursos e queremos ser capazes de nos integrar com outras coisas. Portanto, adicione os Estados de negócios esse requisito, pois tem que ser uma solução baseada na Web, não há necessidade técnica de que ela tenha que ser desenvolvida em dotnet ou Java ou qualquer outra coisa. É aí que entram os requisitos técnicos. O requisito técnico poderia ser que, uma vez que nosso escritório atual suporta apenas uma solução de escurecimento, para que possamos fazer isso em dark net, certo? Então, você limitaria ou aceitaria esse requisito comercial e diria que, no lado técnico, utilizaríamos a estrutura dotnet para desenvolver esse processo. Portanto, se você tiver que pensar em requisitos técnicos, mais um passo mais profundo do que requisito técnico pode dizer que, quando o usuário fizer login, ele deve inserir suas credenciais, o nome de usuário e senha para fazer login no sistema. Mas o requisito técnico ou funcional por trás disso poderia estar nessa página, um usuário deve ter a opção de redefinir a senha, definir questionários de segurança e, em seguida obter um autenticação secundária, como uma mensagem ou algo assim no telefone. Esses são requisitos puramente técnicos ou funcionais que se relacionam com esse requisito comercial geral do usuário poder fazer login eosem algumas credenciais. É assim que você detalha o requisito comercial versus os requisitos técnicos. Eles também podem ser alguns requisitos legais que você precisa examinar. Por exemplo, certos países europeus podem ter restrição ao compartilhamento de informações pessoais fora da Europa. Então você precisa entender quando você define a solução. Existe algum requisito específico referente a um país local ou a uma região que precisa ser considerada. Portanto, esses requisitos também precisam ser pensados. E é aqui que você se envolveria com as partes interessadas, patrocinador e outras pessoas para entender quais são esses requisitos. Então, agora que entendemos quais são os diferentes tipos de requisitos comerciais, técnicos ou legais, vamos ver como podemos coletar esses requisitos? Quais são as diferentes técnicas que podemos usar para coletar tais requisitos, sejam comerciais, técnicos ou legais, principalmente, eu diria que, de três maneiras diferentes de fazê-lo, mas existem várias maneiras. Então, vamos dar uma olhada nos primários. O primeiro é brainstorming. Você facilita uma reunião com todas as pessoas importantes que estão usando o sistema ou que são os usuários do sistema e brainstorm a ideia é o que elas querem no sistema que estão usando. Digamos que, no exemplo de migração do antigo sistema de mainframe para o sistema moderno baseado na Web, você pode fazer um brainstorm para entender quais são os recursos e funções que os usuários estão utilizando hoje na plataforma legada. E se eles precisam ser migrados para a plataforma moderna, ou é só que eles estão fazendo algo por causa da restrição que eles têm com os sistemas legados. Assim, você pode ter sessões de brainstorming para analisar ainda mais os requisitos. A próxima é reunião ou entrevista individual. Você pode ter uma reunião individual com os líderes funcionais, seja finanças, logística, marketing, vendas. Cada um deles teria seus próprios requisitos ou seus próprios recursos e funções que estão usando atualmente e gostaria adicionar no novo aplicativo que está sendo desenvolvido. Essas coisas saem quando você se encontra com elas um a um. Então, para entender quais são as necessidades específicas quando se trata de requisitos. E o terceiro é um workshop de um dia onde você pode ter um ou dois dias de oficina para trazer todas as partes e usuários relevantes uma sala e, em seguida, reunir todos os requisitos. Então, quando eles interagem uns com os outros, eles entenderiam quais são as dependências e poderia haver requisitos adicionais que saem dessa sessão. Essa é outra forma de olhar. Existem vários outros métodos além desses três primários. Então, vamos pular rapidamente o que são. Algumas das outras opções que você tem, um envio de uma pesquisa, você pode enviar uma pergunta ou lista de coisas que você quer entender como um questionário ou pesquisa para as pessoas que são usando este aplicativo ou quem estaria usando no futuro para entender quais seriam seus requisitos, o que eles gostariam de ver no novo sistema que podemos coletar todo esse feedback e veja se ele se alinha à meta do projeto. E você pode incorporar isso como um requisito comercial. Outro tipo de coleta de requisitos é sombreamento ou observação do usuário. Você simplesmente poderia sombrear a pessoa de TI que está usando o sistema atualmente, digamos, neste caso, o sistema de mainframe legado, para entender o que está fazendo hoje e qual é a saída ou o resultado fazendo essa tarefa, uma vez que você entenda o que eles fazem e qual é o resultado dessa tarefa, então você pode ter uma solução. A plataforma moderna, como fazer a mesma coisa, talvez de forma diferente, ou mesmo você pode automatizar isso completamente para que o usuário não precise fazer muito. Isso é feito automaticamente no novo sistema. Então, por exemplo, digamos que no sistema legado eles tenham dez trabalhos que precisam ser enviados manualmente, digamos para processar certos artistas. Então eles tinham que fazer um de cada vez. Portanto, o primeiro trabalho é enviado, então o usuário aguarda por ele e, depois que for concluído, ele ou ela envia o segundo trabalho. Portanto, ao sombrear ou observar o usuário, você pode tirar essa nota para baixo o que eles fazem e por que eles fazem isso. E então talvez na plataforma moderna, você não precisa fazer nenhuma intervenção manual. Talvez você possa automatizar ou agendar os trabalhos de uma forma que, em determinado momento , quando o gatilho é atendido e o trabalho é iniciado automaticamente. E depois da conclusão do trabalho, ele acionará os trabalhos subsequentes. Assim, você pode automatizar todo o processo entendendo o que o usuário desk hoje e qual é o resultado dessas tarefas. Outra forma de capturar o requisito é a análise de documentos. Digamos que no sistema atual eles tenham algum tipo de documento sobre por que certas coisas são projetadas ou o que certas coisas fazem como uma função. Em seguida, você passará por esses documentos e verá e entenderá o que o sistema atual faz. E essa pode ser a sua entrada para entender e definir no novo sistema como ele deve ser tratado. Então essa é outra forma de reunir requisitos e projetar no novo sistema. Outra forma de coleta de requisitos é a análise de interface. análise de interface está analisando todos os trabalhos e lotes e outras coisas que são interfaceadas com o sistema atual, mas entrada ou saída. E entenda o que eles estão fazendo. E então você pode avaliar se essas interfaces são. Sistemas downstream ou upstream precisam ser atualizados ou o sistema moderno pode fornecer algo diferente para essas interfaces. Portanto, observando a interface que existe hoje, você pode entender o que essas interfaces funcionam hoje. E então isso se torna um requisito comercial que precisa ser projetado no novo sistema. Tudo bem, há muitas outras maneiras pelas quais você pode fazer requisitos, como prototipagem, análise de caso de uso e cenários e se, qualquer técnica que você tenha usado, isso não importa desde que você coletar os requisitos e entender o que as partes interessadas do projeto precisam desse novo sistema ou do projeto em que você está trabalhando. Então é isso que coletamos na sessão de coleta de requisitos, documentado e depois recebemos aprovação dos usuários que isso é o que vamos fazer como parte do projeto. Então, agora vamos dar uma olhada em cachoeira e ágil como dividiríamos dividiríamos esses requisitos de alto nível em tarefas menores e gerenciáveis para que possamos atribuir a duração e o esforço. Então, uma vez que você tenha um requisito de alto nível, você pode se reunir com a equipe para analisar mais. Então, se for uma cachoeira, então o que você faria é documentar tudo isso em algo chamado BRD, que é o documento de exigência comercial onde você tem todas as entradas do sessões diferentes que você teve com o negócio e documentar o que a empresa precisa, qual deve ser o resultado e qual é a expectativa do usuário. Depois que o requisito de negócios estiver documentado, você poderá entregá-lo à equipe técnica para que possa desenvolver a solução técnica para ele. Então, normalmente, a equipe técnica revisaria o BRD e criaria as pontes de documentos de especificação de requisitos de software , apenas mapeando o requisito de negócios e no alto nível, definindo no SRS como esses requisitos de negócios serão entregues tecnicamente dentro desta hora, pois você poderia ter diagramas de alto nível para mostrar como o requisito de negócios de alto nível é mapeado e como ele será entregue. Você também pode ter um design de baixo nível dividindo ainda mais esses componentes de alto nível do SLD em componentes de nível menor. E, finalmente, com base no LLDP, você teria uma estrutura de detalhamento de trabalho, que é a tarefa e a atividade reais para executar e entregar esse requisito comercial. Depois de ter a WBS, é mais fácil como gerente de projeto se reunir com a equipe e entender o esforço envolvido na conclusão dessa tarefa específica. Porque olhando para o requisito geral dos negócios, é difícil para a equipe estimá-lo. Mas se a equipe tiver feito um ótimo trabalho ao dividir os requisitos em componentes gerenciáveis menores , seria muito mais gerenciável e mais fácil para a equipe estimá-lo com precisão. Então, agora vamos dar uma olhada em como isso será feito no Agile. Na metodologia Agile, todos esses requisitos serão capturados como histórias de usuários. O modelo de história do usuário que discutimos nas lições anteriores, documentaríamos no produto ou no documento Nobu quais são as histórias do usuário para o requisito de negócios, seja qual for a persona que o usuário seja, você pode dizer como uma pessoa financeira ou líder de projeto de ativos, eu quero fazer isso para que eu possa conseguir isso. Então esse é o modelo que normalmente é mapeado ou criado em histórias de usuários para entender quem é a persona e o que eles estão tentando fazer para alcançar qual resultado. Depois de ter as histórias de usuários , você pode definir homens. Essas histórias de usuários serão entregues. Vai estar na versão uma versão , versão a ser lançada? Então, você voltaria a isso, uma vez que todas as histórias de usuários sejam identificadas na lista de pendências do produto, as versões podem ser divididas em épocas. E a partir da época você pode definir a tarefa e, em seguida, subtarefa, que equivale à o que equivale à estrutura de divisão do trabalho e à metodologia em cascata. Depois de ter um nível épico de DNA e tarefa, será mais fácil para a equipe apontá-lo porque agora é mais gerenciável. E você pode definir qual tarefa e usa histórias vai em qual sprint. E então, de acordo com isso, você pode mapeá-lo para a versão de lançada que deseja liberar essas histórias de usuários para o usuário. Portanto, é em um nível muito alto como sessões de coleta de requisitos são feitas. Novamente, como gerente de projeto, você é mais um facilitador aqui do que realmente fazer a coleta de requisitos sozinho. Se você tem uma equipe ágil , então trabalhou com o proprietário do produto para concluir a coleta de requisitos e definir as histórias de usuários. E se você tiver um projeto em cascata, então você teria negócios ou seu analista de negócios ou alguém da equipe funcional que estará ajudando com os requisitos de negócios. E, como gerente de projeto, você mapearia esses requisitos de negócios para outros componentes menores, como a estrutura de detalhamento do trabalho. Assim, você pode incluir em seu plano de projeto e, em seguida, planejar acordo com a entrega do requisito de negócios Ted. Essa é a lição para reunir requisitos de negócios. Então, agora vamos passar para a próxima lição. 13. Caso de negócios e carta: Nesta lição, falaremos sobre o caso de negócios e a carta do projeto que acontece na fase de ideia do projeto. Antes mesmo do início do projeto, o patrocinador tem que criar um business case para baseado nas necessidades do projeto e na estratégia e visão da organização, o patrocinador do projeto teria que criar um plano de negócios que estabelece o projeto em alto nível, obras que estão ativadas em investimento e todo esse detalhe. Então você tem que obter o caso de negócios do projeto e a carta do patrocinador. Mas, em alguns casos, essas fontes que engajariam o PM com antecedência. Então, quando ele tem o caso de negócios, ele consultava o gerente de projeto para ajustar qualquer coisa. E ele também pediria ajuda para fazer o charter do projeto funcionar para que fosse possível que você não fosse aproveitado para ajudar o patrocinador a criar a carta do projeto. Mas, idealmente, ele deve ser criado pelo patrocinador do projeto junto com o business case. Tudo bem, então agora vamos dar uma olhada no que a carta do projeto deve ter. Definitivamente deve ter no nível muito alto, a escola e as necessidades de negócios. O que está em um escopo externo para o projeto. Por exemplo, digamos que você esteja construindo um site, você tem que ter esse requisito claramente indicado na carta do projeto e, no caso de negócios, que o requisito é criar um site onde você pode vender produtos. Então, quando você vê a carta, ela deve entrar em detalhes sobre o que está no escopo e o que está fora do escopo. Este site é destinado apenas aos EUA ou à Europa ou a qualquer outra região ou como internacional. Então, esses deveriam estar na escola. E qualquer coisa que não esteja no escopo, digamos que seu produto não tem permissão para vender na região europeia devido a levar a uma regulamentação detalhada. Então, a Europa está fora do alcance, então você tem que ter aqueles definidos na carta do projeto. Se você está nos ajudando CAPM, então você deve colocar isso. Caso contrário, o patrocinador deve esclarecer para você, a carta do projeto deve sempre ter um cronograma de alto nível para que você entenda antes do início do projeto e conceda o prazo que você precisa entregar este projeto. Obviamente, durante a fase de planejamento, isso vai mudar e talvez tenhamos que ajustar a linha do tempo. Mas você sempre deve começar com a linha do tempo quando o projeto deve ser entregue. Também deve ter o orçamento porque, como parte do caso de negócios, o patrocinador já tinha um orçamento aprovado para este projeto junto com a contingência. Então, contingências, qualquer coisa se o projeto der errado, você tem um buffer para tirar algum custo disso. Portanto, você deve sempre procurar o orçamento do projeto no caso de negócios e colocar isso na carta. carta deve toda a base ter restrições. Se houver alguma dependência ou restrição do projeto que tenha que ser colocada na carta do projeto. Então, por exemplo, você pode se esforçar seria que talvez sua organização tenha sequela da Microsoft. Mas para este site você precisa de um artigo. É uma restrição que você precisa obter o Oracle para o banco de dados para ser bem-sucedido. E as suposições podem ser que você tenha permissão para viver com certas coisas. E talvez durante a execução ou planejamento do projeto, você validaria essas suposições se for verdade ou não. Então você também teria que destacar o risco de achar que pode acabar ao executar o projeto na carta do projeto em um nível muito alto, obviamente, o risco e os problemas obterão maior e melhor quando você começar a planejar e a execução. Mas você sempre deve ter algum alto nível de risco identificado como parte da carta. E, finalmente, a carta do projeto deve sempre dar uma ideia sobre quem são as partes interessadas, para quem estamos criando esse produto? Partes interessadas diretas e indiretas. Então, todos eles devem fazer parte da carta do projeto. E lembre-se de que deveria ter sido documentado pelo patrocinador e entregá-lo a você. Então essa é uma dica rápida para lembrar, mas em algumas organizações o patrocinador se aproximaria de você para ajudar com a carta. Às vezes, o gerente de projeto precisa ajudá-los ou criar a carta para o patrocinador. E isso acontece na ideia de fase. Antes mesmo de começar a fase de planejamento. A carta do projeto é um ponto de partida que recebe informações do business case. 14. Avaliação de riscos em planejamento de projetos: Tudo bem, então agora fizemos o planejamento, agora é hora de fazer uma avaliação de risco. Veja todos os projetos, veja como podemos mitigar o risco. O que identificamos como risco, vai impactar o projeto? Todas essas boas discussões antes de entrarmos, vamos dar uma olhada na definição de risco. A definição de risco é que é um evento incerto. Você não tem certeza se esse risco ocorrerá ou não. É um exemplo simples que poderia ser o seguro do carro. Você não sabe se vai encontrar com um acidente ou não quando você dirige um carro ou seu veículo a motor ou uma bicicleta. Mas você sabe que existe uma chance potencial de que algo possa acontecer. E se isso acontecer, ele precisa ser aceito, migrado ou transportado. Então, quando tomamos um seguro de carro, tudo o que estamos fazendo é transferir o risco ou o impacto do risco para a seguradora pagando um prêmio mensal. Então, digamos que você tenha tido um acidente e se você não tiver seguro e digamos que o dano seja de US $20 mil. Então, esse é um risco que você está disposto a aceitar, então isso é absolutamente bom. Você pode apenas tomar a apólice de seguro mínima exigida pelo estado. Mas se você estiver disposto a aceitar esse risco, que se algo acontecer, estou disposto a pagar 20 mil ou sucatear o carro e comprar um novo. Depende de você em projetos é a mesma coisa. Ao identificar esses riscos, você precisa decidir se deseja aceitar o risco ou se deseja mitigar e reduzir o impacto da lista, ou se deseja transferir completamente o risco para outra pessoa. Portanto, essas são as considerações que você quer fazer ao olhar para o plano de risco e mitigação. Então, normalmente, a maneira mais fácil de fazer é se alguma coisa, que são baixos no espectro de risco, que é o fundo inferior aqui em verde, esses riscos podem ser aceitos, o que significa que pode ser que o impacto seja baixo a probabilidade de esse evento acontecer é muito baixa. E não adianta fazer brainstorming e gastar muito tempo avaliando esse risco se as chances de ocorrer isso for muito baixo. Por outro lado, se o risco for muito alto, então você deve ter um plano B. O alto risco é porque eles impactam, se isso acontecer, é caro. Isso pode afetar o projeto, o cronograma ou o custo do projeto. Poderia ser tanto, ou muitas outras coisas. Então, no final do dia, se você não tiver certeza de que deseja impactar o projeto, esse risco deve ser atenuado. Então, isso está no alto nível, como você olha para o risco desse espectro. E se for médio, você pode ter um plano de mitigação de transferência. Normalmente, tudo isso é direcionado e avaliado em um registro de risco. Você pode criar um registro de risco no formato Excel. Então, vamos dar uma olhada no Excel e ver como ele se parece. Tudo bem, como você pode ver aqui, aqui, criei um Excel com colunas básicas que são normalmente usadas no registro de risco. Então, primeiro temos o número de série, que é apenas o número, risco número um também. À medida que identificamos mais riscos, acrescentaremos isso para começar com o risco, O que você identifica da equipe do projeto? O primeiro lugar a ser analisado é a carta comercial. Então, o patrocinador, quando ele estava propondo a ideia de se converter em projeto, ele ou ela pode já ter identificado certo risco que eles identificaram durante a descoberta. Então importe esses riscos primeiro. E então, à medida que você desenvolve a equipe, certifique-se de que você faça um brainstorm com a equipe e veja se há risco adicional. Vamos dar um exemplo. No nosso caso, estamos desenvolvendo um site para vender modelos, modelos de projeto. Então, digamos que neste caso você queira vender o modelo para alguém na Europa comprar. Portanto, existem leis na Europa que impedem sua privacidade e que tipo de dados você pode armazenar no back-end. Portanto, você precisa avaliar os requisitos globais de privacidade de dados. Assim, você pode acrescentar que, como impacto do GDPR no projeto em detalhes de risco, você pode adicionar mais detalhes, como ao vender modelo na Europa, avaliar a exigência de armazenamento de dados pessoais. Tudo bem, então, ao vender na Europa, você pode ter que considerar qualquer impacto na privacidade do armazenamento de dados, dados pessoais no back-end nos EUA ou coisas assim. Então, se algo der errado, talvez você não consiga vender ou você pode ter impacto. Você deseja avaliar todos os requisitos globais de privacidade de dados e ver se há algum impacto. E se você identificou algo, poderá adicioná-lo ao registro de risco até concluir a avaliação para garantir que não haja risco. Então aqui está, tecnologia ou privacidade de dados. Então, eu diria dados. Como o tipo de risco. E a probabilidade é que, essa é uma alta probabilidade de que isso possa impactar na Europa. Então, probabilidades em uma escala de um a cinco. Então, posso acrescentar isso nos títulos para que fique muito claro. E o impacto também está em uma escala de um a cinco. E a razão pela qual eles estão nessa escala é por causa desses dois, a probabilidade e o impacto, determinaríamos a classificação de risco. Então, neste caso, digamos que a probabilidade de qualquer problema com GDPR provavelmente seja média. Pode haver remediação. Então, nós diríamos três, se tiver um impacto e é um alto impacto, porque se você está planejando vender na Europa, você pode incorrer bem e algo assim. Portanto, o impacto é quatro. Assim, você pode ver que a classificação de risco é calculada apenas multiplicando essas duas colunas. Agora, você precisa de um proprietário de risco que possa acompanhar e ver se isso tem um impacto, se precisamos mitigá-lo e tudo isso. Então, dono do risco, digamos que temos alguém na equipe chamado Jim. Portanto, você sempre precisa ter um proprietário de risco responsável por monitorar esse risco e avaliar o que precisa ser feito. A mitigação do risco é se você vai aceitar o risco e não fazer nada ou transferir o risco de que, se isso impactar, você faça certas coisas ou vai mitigá-lo. Então, se você vai mitigá-lo, você precisa de um plano de mitigação dirá isso como risco. Podemos chamar essa coluna como abordagem de risco. Se você deseja mitigar ou transferir ou aceitar. Você pode ir em frente e fazer um dado aqui. E vamos chamá-lo de Validação de dados. E é uma lista se você pode aceitar o risco, mitigar o risco, disposta a transferir o risco. Então você adiciona essas três opções. Então, quando selecionamos uma opção neste caso, queremos mitigá-la. E então, se você planeja mitigar, é melhor adicionar outra coluna chamada plano de mitigação. Teremos isso, se isso afetar, poderemos obter uma licença de controle de exportação. E a data de vencimento para avaliar tudo isso é digamos primeiro de março antes de lançarmos e o status a partir de agora está aberto. É em um nível alto como você prepara o registro de risco. E você sempre pode filtrar pelo status aqui e revisar esses riscos durante a reunião de status do projeto. Ou você pode ter uma reunião semanal de revisão de risco para passar por todos os itens abertos e ver se você precisa tomar alguma ação, se alguma coisa está chegando, faça isso, devemos ter idealmente fechado e tudo mais. Então, é no alto nível como você criaria um registro de risco. Tudo bem, então agora vamos dizer que temos um desenvolvedor que pode sair da equipe do projeto em breve por causa de talvez motivos de saúde ou o que quer que seja. Assim, você pode ver a indisponibilidade do recurso do banco de dados de recursos após o primeiro trimestre. Isso está apenas mostrando um exemplo, o que poderia ser tipos diferentes e como você adicionaria esses detalhes e qual abordagem de mitigação você adotaria. Os detalhes de risco aqui ainda estão funcionando no banco de dados talvez não estejam disponíveis após o primeiro trimestre por motivos pessoais. Ele pode ter dado alguma dica ou para a equipe do projeto que tem que Q1, ele não está disponível. Então é isso que estamos capturando aqui como um risco. Então o tipo de risco aqui é recurso e a probabilidade é cinco porque ele já te disse que isso vai acontecer. E se isso acontecer, qual é o impacto? Você tem outros membros da equipe que podem fazer esse trabalho? Caso contrário, isso é um alto impacto. Então este você definitivamente precisa transferir. Então, você o atribuiria como gerente de projeto para si mesmo. E você quer ter um plano de mitigação. Então você digitaria mitigar. E o plano de mitigação é entrevista, banco de dados applica candidato e selecione um recurso para substituir Joe. E isso precisa acontecer antes do final do primeiro trimestre. E você precisa ter algum tempo para Joe fazer algumas transições. Então podemos dizer que até março MID, você tem tempo suficiente para Joe fazer a transição e tudo mais. Então, como você pode ver aqui, o registro de risco está sendo construído lá em cima, como você notou no slide anterior, qualquer coisa que esteja em alto risco, você quer cuidar disso. Isso é o que você faria com esse risco de recursos, porque isso será uma grande probabilidade de que isso aconteça. E o alto impacto seria se isso acontecesse. Então você quer fazer algum filme de ação, garante que o risco sempre tenha um plano de mitigação. Se isso acontecer, o que você vai fazer. Tudo bem? Portanto, o risco e os problemas estão ligados no sentido em que as eras podem potencialmente se tornar um problema no sentido, digamos, quando esse risco eventualmente aconteceu e você não identificou um recurso de substituição para Joe, então, nesse ponto, ele se torna um problema porque agora realmente aconteceu e é, impactou o projeto. Então, lembre-se de como é essa a relação entre o risco e os problemas? Sempre um risco pode se tornar um problema por problema não se tornará erros porque problema é um problema que aconteceu ou atualmente é um problema para o seu projeto. Verisk não aconteceu. Isso pode ou não acontecer. Então essa é a diferença crítica entre Aristóteles e um problema. Portanto, qualquer um dos itens que você identificou no registro de risco, pode ou não se tornar um problema potencial no futuro. Então, isso é algo que vamos dar uma olhada no log de problemas, que seria semelhante à luva de risco, mas haverá colunas diferentes, mas isso é algo que você gerenciaria durante a execução do projeto. Portanto, durante a fase de planejamento, você está avaliando todos os riscos potenciais que têm a chance de se tornar um problema durante a execução. Então é isso que todo esse registro de risco está ajudando você a fazer isso, a melhor maneira de fazer é se reunir com a equipe e avaliar todos os riscos que a equipe de ativos coletivamente o que vocês pensam, e então comece a documentá-lo, atribuir um proprietário e uma data de vencimento e sempre veja quais são as opções de mitigação que você tem disponíveis se isso acontecer. Isso conclui a fase de planejamento do projeto. Agora vamos passar para a emocionante execução do projeto. Usaremos todos os documentos que criamos na fase de planejamento, sugerimos o plano do projeto, o GW ou o registro de risco e tudo isso. E monitoraremos e controlaremos de perto toda essa documentação durante a fase de execução. Tudo bem, então você concluiu com sucesso a fase de planejamento. Agora vamos pular para a execução do projeto, que é a parte empolgante. 15. Visão geral do fluxo de trabalho de Procurement: Tudo bem, então o tópico de hoje é um pouco emocionante e às vezes você tem que fazê-lo. Nem sempre, mas é bom entender o processo que está adquirindo seus recursos. Os recursos podem ser hardware, software ou humanos. Não importa. Qualquer coisa que você tenha que comprar de terceiros envolvidos externos ou um fornecedor. É aí que você envolveria sua equipe de compras de sua organização. Ou se você fizer parte de uma organização menor, então você teria que fazer isso com uma equipe menor. Mas, normalmente, qualquer organização terá uma equipe de terceirização ou aquisição que se envolveria com a negociação e os preços finais. Mas, como gerente de projeto, você precisa dizer a eles o requisito para o projeto. E eles se envolveriam com você e negociariam e lidariam com o fornecedor para obter as melhores tarifas. Vamos dar uma olhada no que é o fluxo de trabalho de compras padrão. Antes de entrarmos no que é a aquisição e todos os detalhes, vamos entender o contextual. Digamos que você esteja criando um projeto de site e precise da Amazon Web Services. E digamos que sua organização não tenha a Amazon Web Services. Você precisa ter um contrato principal entre a Amazon e sua empresa. Isso é chamado de Contrato de Serviços Mestres. E isso teria todos os termos e condições sobre como você se envolveria com a Amazon. Depois de ter isso no lugar, você pode se envolver com a Amazon para vir e dar alguma prova de conceito ou o que quer que você esteja procurando pelo projeto, eles podem vir e mostrar o que eles têm a oferecer. Então você pode decidir se quer ir com isso ou se você tem algum outro fornecedor alternativo ou outros que possam oferecer o mesmo serviço. Digamos que neste exemplo você tenha apenas um serviço que você precisa e precisa dele da Amazon. Portanto, você normalmente solicitaria à aquisição ou à sua equipe de fornecimento para ver se eles já têm um acordo negociado ou um contrato de serviço mestre com a Amazon. E se o fizerem, então você terá que prosseguir para a próxima etapa que você pode se referir ao MSA para escrever uma SOW. Sow é a declaração de trabalho. Nesse documento, você apenas listaria os requisitos do projeto para este projeto, esse é o requisito específico que preciso da Amazon para entregar. Isso é o que SOW é apenas um subconjunto do contrato principal ou do MSE. Então, uma vez que você tenha isso, você pode envolver a Amazon. Então esse é o contexto. Normalmente, seja a Amazon ou um fornecedor terceirizado ou qualquer outro serviço ou pessoas que você esteja contratando. Pode haver um fornecedor com o qual sua organização tenha se engajado e ele pode passar por esse processo. E para que esse fluxo de trabalho seja aprovado, você precisa trabalhar com suas finanças para garantir que seu projeto tenha financiamento suficiente para apoiar isso. Então você precisa trabalhar em estreita colaboração com a equipe financeira e de compras para atender a essa necessidade do projeto. Digamos que se você tiver que comprar algo completamente novo e não tiver ideia qual empresa ou fornecedor deseja ir. Digamos que você esteja abrindo uma nova empresa ou uma parte da sua organização. E você precisa configurar serviços de e-mail. Você tem o Microsoft Exchange, você tem o Google Suite e outras variedades diferentes, onde você pode obter serviços de e-mail. Então, como você obtém esse serviço? Então, a primeira coisa que você faria é solicitar proposta. É basicamente pedir ao fornecedor que lance e veja quem pode oferecer o menor preço pelas coisas que você quer ter em seu projeto. Neste exemplo, se você estiver procurando por serviços de e-mail, diria que eu quero ter serviços de e-mail fornecidos para 100 pessoas na minha organização. Então, qual é o melhor preço que você pode dar? Eles receberão isso como uma solicitação de proposta de RFP, e enviarão sua oferta e, em seguida, ela poderá avaliar. Depois de avaliá-lo, você precisa fazer prova de conceito para ver, digamos que ambos ofereçam serviços de e-mail por US $100 por mês para 100 pessoas. Então você quer ver qual deles se encaixa melhor aos seus critérios. Talvez eles tenham, o Google tem alguns recursos que você gosta ou a Microsoft tem outros recursos. Então você quer experimentá-lo. E se você está confiante de que vai com um ou outro. Se você não quiser testar nada, então você pode pular esta etapa. Mas estou apenas colocando isso aqui para que normalmente você saiba como esse fluxo de trabalho é. Você iniciaria os dados, seria seguido por, você receberá todas as solicitações ou o preço. E então você faria um POC, então você pode determinar qual deles seguir. Depois de determinar que deseja ir com um, Microsoft ou para o Google, você contrataria a equipe de compras novamente para fazer a negociação final. Então, talvez eles tenham melhores termos e condições em que possam negociar e vincular ainda mais os termos legais sobre cancelamento, rescisão, tudo. Uma vez que isso seja feito, então a aquisição, pois se for uma nova janela entrando, eles primeiro escreveriam o contrato de serviços mestre. Depois de ter isso no lugar, você poderá criar uma SOW especificamente para o projeto. E então digamos, este é o orçamento do projeto e esse é o requisito do projeto, cronograma, suposições, dependências e tudo mais. Então é assim que você adquiriria recursos, seja hardware, software ou pessoas. Estes são genéricos em alto nível. E não entraríamos nos detalhes, mas apenas entendemos que, se você já tiver o NMAC ou uma conexão existente entre sua organização e o provedor de serviços, então você pode começar com a SOW. Mas se você estiver estabelecendo um novo relacionamento, então você passaria pelas etapas e estabeleceria a SOW da MSA para iniciar seus requisitos de projeto com esse fornecedor. Isso é algo que você teria que fazer em sua carreira de gerenciamento de projetos. Não muito frequentemente, mas na maioria das vezes, compra e financia seus amigos e eles terão que estar no site de ajuda. Tudo bem, então isso é tudo para esta lição. Então, passaremos para o próximo. 16. MVP em Agile vs POC em aquarela: Na aula de hoje, vamos dar uma olhada no enantiômero MVP. Você deve ter ouvido a palavra MVP. E vamos ver por que essa é uma palavra-chave tão importante e qual é o significado dela no Azure? Então, deixe-me mudá-lo para a apresentação de slides. E você pode ver aqui que temos entrega antecipada versus tardia, dependendo da Cachoeira versus Ágil. No Agile, você verá uma palavra-chave MVP lá, que é um produto mínimo viável. E na cachoeira à esquerda temos algo semelhante chamado prova de conceito, mas não muito próximo como MVP. Digamos que um cliente tenha a exigência de que ele precise algo para deslocar do ponto a para encontrar B em duas rodas. Então, como você pode ver à esquerda quando fazemos POC, talvez os passos de um a quatro sejam apenas projetados sobre como esse produto será. E mesmo depois disso, você só pode entregar o produto real quando ele for completamente fabricado e entregue, o que sai na etapa número seis. E naquela época o cliente teria uma moto muito boa para viajar do ponto a ao ponto B. E esse processo poderia levar em algum lugar de um mês a um ano ou dez anos dependendo de quão complexa e quão personalizada essa motocicleta deve ser. Mas digamos que o cliente estava apenas procurando um veículo de duas rodas para viajar do ponto a ao ponto B. E ele não estava realmente pensando apenas em motocicleta desde o início. É aí que o produto mínimo viável no Agile é útil. Se você olhar antes que a motocicleta seja construída no final, indique o cliente, ela sempre tem a opção de voltar e pegar um skate de nós para que eles ainda possam comungar do ponto a ponto B. Então, está entregando um valor, a coisa mínima viável que ele pode fazer com o produto que entregamos. É por isso que o Agile é muito poderoso porque o que o cliente quer, ele consegue nos estágios iniciais. Ele não precisa esperar até que o projeto seja concluído para obter sua exigência, Dan, sim, ele pode não ter a velocidade e agilidade de uma motocicleta, mas ele ainda pode se deslocar do ponto a ao ponto B usando o skate ou scooter, ou uma bicicleta ou um ciclo de motor. Então esse é o conceito chave de entrega antecipada versus tardia. No Agile, sempre entregamos cedo, enquanto na cachoeira, sempre é entregue tarde. E às vezes é tarde demais que quando você me diz onde a motocicleta pode estar, o cliente não quer essa cor ou essa não é a forma e o estilo que ele estava procurando e ele estará completamente infeliz. É por isso que o Agile é uma ferramenta tão poderosa que sempre podemos obter o feedback do cliente à medida que continuamos a entregar nos estágios iniciais do projeto. 17. O Obter JIRA gratuitamente: Na lição anterior, analisamos como obter o Microsoft Project por 30 dias gratuitamente. Hoje vou mostrar como obter o Jira e o Confluence, o que é fundamental para gerenciar projetos ágeis. Para este curso, recomendo vivamente que você acesse um site para fins de aula. Vou guiá-lo por aqui e inscrever para Jira e Confluence. Isso será muito útil quando passarmos para as outras seções desta aula, porque você pode aprender prático Jira e Confluence com o projeto que vamos discutir nas próximas aulas. Então, tudo o que você precisa fazer é pesquisar no Google pela Atlassian. E isso deve levá-lo a um site da Classe C e..com. E lá você tem uma opção para experimentar. Agora, quando você clica nisso, você tem opção para diferentes seções de plano e rastreamento onde você pode experimentar o software Jira e o software confluence. Você não precisa baixá-lo. Está na nuvem, então você só precisa se inscrever usando seu e-mail e, em seguida, isso é tudo o que é necessário. Então, como você pode ver no site do Jira, ele é totalmente gratuito por até dez anos ou mais. É ilimitado. Você pode se inscrever usando seu e-mail e você pode usá-lo por quanto tempo quiser, porque Atlassian não cobra por até dez EUA, então, por terrorista, sem custos. Então, eu recomendo que você se inscreva para isso e comece a brincar com ele. E ao longo das lições deste curso, faremos um projeto prático usando o projeto Jira e Microsoft. Portanto, é bom ter um ícone local do Jira para você, para que você possa jogar com o projeto, criar quadros e fazer muito mais atividades à medida que aprendemos mais sobre o JIRA neste curso. 18. Visão geral e passo: Olá. Nesta lição, vamos dar uma olhada na ferramenta Atlassian JIRA, que é usada para o Agile Project Management. No vídeo anterior, analisamos como obter o JIRA gratuitamente por até dez usos. Tudo o que você precisa para ter acesso à conta gratuita do Jira é se inscrever usando sua conta de e-mail no site da Atlassian. Depois de fazer isso, a página inicial básica do Gita seria algo assim. Aqui eu tenho alguns projetos que estão acontecendo, mas quando você obtém seus dados primeiro, você pode querer ir para as configurações e configurar um projeto. Se você faz parte de uma organização, o administrador do sistema de TI já configurará um projeto para você, para que você não precise fazer isso sozinho. Mas só estou mostrando para que em casa você possa criar esse projeto e começar desde o início. Normalmente, em uma organização, o acesso de administrador não é fornecido aos gerentes de projeto, portanto, você não teria acesso a esses detalhes. Você poderá ver projetos e acesso e diferentes projetos aos quais você tem acesso. Você não veria essa opção chamada Criar projeto se não tiver acesso de administrador. Uma maneira de criar projeto é clicar no projeto no menu superior e você pode criar um projeto a partir daqui. Mas, em geral, você quer fazer isso entrando na página de configurações e, em seguida, clique na seção Projetos aqui. Isso lhe dará a opção de criar um projeto. Então clique no botão azul no canto superior direito chamado Criar projeto. Quando você clica no botão Criar projeto, você receberá diferentes modelos disponíveis. Por padrão, o Java tem esse desenvolvimento de software, gerenciamento de serviços, gerenciamento de trabalho e todas as outras opções que você vê à esquerda. No nosso caso, vamos com essa plataforma de desenvolvimento de software ou o modelo. Mas porque já estamos planejando usar o web design como um projeto ao longo deste curso, que pertence ao desenvolvimento de software. Então, neste caso, você tem Kanban e Scrum e , em seguida, rastreamento de bugs. Isso é para equipe de garantia de qualidade. Mas entre Kanban e Scrum, lembre-se de que, se for um projeto, você quer usar o modelo do Chrome. Kanban normalmente é quatro operações que não há data de término, é uma operação contínua. Então, como este é um projeto, começaremos com o Scrum e você pode clicar em Usar modelo. Agora você tem um modelo de projeto por padrão e agora você pode decidir se ele é gerenciado por você ou sua empresa. Então, vou dizer que selecione um projeto gerenciado por equipe e vamos adicionar um nome de equipe. Então, o teste de desenvolvimento. E, por padrão , ele cria uma palavra-chave. E você verá isso quando tarefas e histórias forem criadas. Agora clique em Criar projeto. Depois de criar o projeto por padrão, ele criou um quadro. É por isso que quando você clica no quadro no lado esquerdo, você verá esta página agora onde começamos no JIRA está sempre com backlog. É aqui que você criaria suas histórias de usuários, tarefas e qualquer outra coisa que precisa ser feita como parte do desenvolvimento do produto. Vou pular as instruções aqui. Se você é novo, você pode seguir isso. Isso dará algumas informações sobre como usar essa ferramenta. Agora vamos começar do topo. Essas partes são diferentes. Atlassian Software está disponível. Normalmente, instalamos o JIRA para gerenciamento de projetos para usar a tarefa de histórias de usuários, coisas assim. Confluence é o repositório de documentos onde você armazenaria todos os documentos associados a este projeto. Chegaremos a isso daqui a pouco. Vamos começar com o software Jira, que é o que estamos usando agora desde que criamos o projeto, você pode ver outros projetos aqui. O que acabamos de criar é o teste de desenvolvimento web. Depois de clicar nisso, você voltará à página padrão do quadro. Agora, podemos ir em frente e criar tarefas. Mas antes de fazermos isso, vamos ver quais outras opções temos aqui. Você pode filtrar aqui para ver qualquer tarefa atribuída a você. Mas isso ainda não está pronto para nós. Então, vamos voltar aos projetos. Esses são projetos diferentes que eu criei no passado. O atual é que os filtros de teste de desenvolvimento web são consultas. Você tem um grande número de tarefas que você pode executar a consulta para filtrar as que você está procurando. Você pode usar o filtro padrão sugere os problemas abertos para analisar todos os problemas que ainda estão abertos para que qualquer coisa fechada seja filtrada. Vamos dar uma olhada no painel. Portanto, esse é o painel de exemplo que tenho acesso do projeto anterior. Mas se você não criou um painel, não veria nada aqui. Voltaremos para criar um painel mais tarde. Agora vamos olhar para as pessoas. Você pode convidar outras pessoas para este quadro do Jira se você estiver executando um projeto. Aqui é onde você convidaria os membros da sua equipe para fazer parte deste quadro do projeto. Aplicativos são outras coisas que você pode integrar com o Gita. Por enquanto, não vamos fazer isso. Então esse é o básico no topo. E novamente aqui à direita nas configurações é onde você gerenciaria seu fluxo de trabalho, suas configurações de projeto, coisas assim. Por enquanto, vamos deixá-lo como padrão e, à medida que avançarmos, vamos dar uma olhada. Se você precisar alterar qualquer coisa à direita, verá que tem opções para alterar suas configurações de perfil, suas configurações de login e alterar a senha, coisas assim. Tudo bem, agora vamos dar uma olhada no lado esquerdo aqui. Sempre começaríamos com a lista de pendências porque é aí que você criaria histórias de usuários, tarefas e coisas assim. E você clica nesse botão Criar, essa janela aparece e você verá diferentes opções disponíveis aqui. Antes de criarmos qualquer coisa, vamos ver o que é um Roteiro. Roteiro em um nível mais alto é o resumo de como os épicos estão avançando no calendário. Voltaremos ao que é um épico quando criarmos nossa primeira tarefa por enquanto para gerenciamento de projetos, ignoramos o código. Aqueles que fazem parte da equipe de desenvolvimento, precisariam acesso a isso e jogariam com isso. Normalmente, a equipe de DevOps usaria Bitbucket ou GitHub ou GitLab para gerenciar seu código. Aqui, as páginas do projeto estão vinculadas à confluência e aqui é onde você pode vincular uma confluência do JIRA e, em seguida, criar o repositório do projeto é armazenado na página do Confluence. Vamos conectar a confluência. Agora podemos criar um novo espaço que tenha o mesmo nome do projeto giga, onde o chamaremos desenvolvimento web, teste e criação. Agora conectamos o Jira e o Confluence. Então, se eu voltar daqui de volta para o Confluence, você veria que uma casa de teste de desenvolvimento web foi criada. Isso você pode pensar semelhante a um site, você pode criar um blog, você pode criar páginas. E é aqui que você armazenaria coisas diferentes. Por enquanto, não tenho páginas. Esta é a página inicial, então você pode clicar e adicionar uma página para a equipe. Vamos chamá-lo de equipe de boas-vindas. Bem-vindo à página de teste de desenvolvimento web. Então, uma vez que você publicá-lo, então qualquer um que fosse adicionado ao projeto, eles teriam acesso a isso. E você veria essas páginas na seção da página aqui. Então agora vamos voltar para o Jira por um minuto. Vá para um projeto. E quando você clica nas páginas do projeto, você veria tudo o que criamos no Confluence. Também é mostrado aqui. É assim que ele é totalmente integrado entre o JIRA e o Confluence. Em seguida, você pode alterar as configurações do projeto diretamente daqui em vez de passar pela página de configuração no canto superior direito. Então isso está tudo aqui. Então, normalmente, o que você faz quando tem acesso ao JIRA é seguir em frente para uma lista de pendências. É aqui que você criaria toda a sua tarefa e, em seguida, criaria esse sprint e moveria a tarefa de uma lista de pendências para a propagação. Então, vamos fazer isso agora. Clique em Criar. Depois de criar os diferentes tipos de tecido como histórias de usuários, tarefa, bug e épico. O primeiro nível é sempre EPEC. Para facilitar a compreensão. Digamos que tenhamos uma história de usuário. Vou criar uma e dizer página de login. Aqui, o proprietário do produto definiria qual é esse requisito. Como usuário, preciso acessar a página de login para acessar minha conta. No site. Este é um formato de história de usuário e, em outras lições, capturamos o que uma história de usuário deve ser, qual é o formato e por que é importante ter a história do usuário em um determinado formato por enquanto, iríamos em frente e criaríamos. Agora você verá na lista de pendências que temos um problema de página de login criado. E à esquerda tem um ícone que representa a história do usuário. Agora vamos criar outro que você pode criar a partir do topo ou você pode criar de baixo aqui. Quando você cria a partir daqui, o que quer que você tenha criado por último, ele é padrão para isso. E você sempre pode alterar o tipo para uma tarefa. Então, aqui, diríamos a página de login de design para esse requisito do usuário. Agora, a equipe técnica está criando uma tarefa. Para projetar a página de login, clique em Enter. Agora vamos em frente e criar uma EPEC. Se eles digitar devem ser páginas da Web. Epic é apenas uma coleção de histórias de usuários e tarefas associadas a esse épico. Você pode pensar em uma cesta grande de ácido épico onde você consolidaria e colocaria itens semelhantes nessa cesta. Nesse caso, vamos chamar esse design de página e clicar em Criar. Tudo bem, agora você veria que você não tem um épico criado aqui porque ele escolhas são criadas no topo. Então, se você olhar aqui, você veria o épico, a época que acabamos de criar. Não vai se sentar sob o atraso, vai ficar sentado à esquerda. Em alguns casos, ou na parte superior. Neste caso, temos o Epic no topo. Temos que habilitá-lo para que agora você veja a época à esquerda. Este é o épico que acabamos de criar. Você pode ver nesta época que não temos outros problemas criados porque não associamos a história do usuário para corresponder a essa época. Vou clicar em clique fora dele para que eu possa ver tudo. E digamos que chamamos todos os itens relacionados à página da Web para fazer parte desta época. Como esses dois são relacionados à página da Web, vou simplesmente arrastar e soltar naquele épico. Ele ainda permanecerá no backlog, mas é apenas uma maneira de atribuir facilmente uma tarefa ou uma história a um épico. Estamos apenas vinculando para que ele saiba qual. Estamos apenas vinculando o tipo de problema a um épico. Portanto, é fácil classificar coisas diferentes. Fará sentido se eu lhe der mais um exemplo, se eu criar outra época e vamos chamar isso de banco de dados. Banco de dados, ok? Agora, quando clico neste épico e crio qualquer coisa, ele atribui automaticamente essa tarefa a esse épico. Nesse caso, vamos mudá-lo de volta para uma história. E talvez eu o mude de volta para uma tarefa e diga a autenticação do usuário por meio de uma conexão de banco de dados. Então, estamos simplesmente dizendo que as credenciais do usuário devem ser armazenadas e autenticá-las do banco de dados. Vamos criá-lo. E pode ter criado fora do ápice. Então deixe-me clicar fora dele. E assim você pode vê-lo criado sem se vincular a um épico. Neste ponto, posso simplesmente clicar e arrastá-lo para o banco de dados épico. Mas se você quiser ver como fazer de outra maneira, então você pode clicar no botão três principais para editá-lo. Então, provavelmente, talvez essa árvore e digamos adicionar um padrão. E neste caso, vamos dizer banco de dados. Portanto, para qualquer tarefa e história, o pai é sempre um épico. Então é por isso que você está vendo apenas esses dois épicos que criamos. Então agora podemos fechar isso. Agora você pode ver que ele está associado a esse épico. Agora você pode ver a importância de um épico porque você pode ver que são coisas semelhantes agrupadas clicando no épico à medida que o projeto cresce com várias tarefas e épocas, é fácil olhar em uma sessão específica e veja apenas a tarefa associada a esse apec. É por isso que eles escolheram isso importante. Você pode pensar novamente em um item epigástrico, grande, onde vários usos, histórias e tarefas de um grupo juntos. Tudo bem, então esse é o backlog do produto e é aí que você criaria todos os tipos de problemas. E quando você terminar preparar o backlog com o proprietário do produto, próxima coisa que você faria é criar um sprint. Para fazer isso, vamos clicar no backlog e fechar o épico por enquanto. Você veria que um sprint já foi criado neste caso. Mas se não for, você teria uma opção em algum lugar aqui na parte superior ou na parte inferior que diz Create Sprint. Neste caso, temos a opção aqui. Então, tudo o que você faz para um sprint é escolher um dos itens que você deseja fazer parte do sprint para mover o problema da lista de pendências para o sprint, você sempre pode arrastar e soltar. Então deixe-me fazer isso por enquanto. Agora estou movendo o primeiro item do backlog para o sprint. Tudo bem, agora que criamos os problemas e entendemos como movê-los do backlog para o sprint. A próxima coisa que queremos analisar são diferentes campos disponíveis para esse problema. Você sempre pode ter uma descrição do usuário qual é o tecido. Você pode designar alguém da equipe. Então, neste caso, vou atribuir a mim mesmo, você pode adicionar outros rótulos. Então, neste caso, vou dizer design apenas para categorizar as coisas e apenas para categorizar as coisas para encontrar AAC mais tarde assim que o backlog crescer tremendamente, agora vamos ver quais outros itens que temos aqui além de atribuir rótulos sprint. A outra coisa importante que você deseja atualizar é que o ponto da história por tempo é apenas colocar três na outra lição mais tarde durante o planejamento de sprint, nós abordamos como inventar a história pontos, como estimamos e todos esses detalhes por tempo apenas entendem esse é o esforço. Portanto, para essa história de usuário em particular, o esforço envolvido é um ponto de três andares. Agora isso é tudo. Você pode atualizar quaisquer outros detalhes dessa tarefa. E você pode clicar na opção Configurar para adicionar campos adicionais, se necessário, você pode ter a caixa de seleção suspensa e outras coisas adicionadas. Esse item de tarefa específico, é assim que você adiciona uma tarefa da lista de pendências ao sprint. Agora vamos adicionar isso também ao sprint e fazer a mesma coisa, voltar e atribuí-lo a um membro da equipe e, em seguida, também apontar a história. Então você pode ter talvez cinco pontos da história para isso. E uma vez que você tenha esse ponto da história aqui, se você olhar para esse amigo veria que o sprint tem agora oito pontos da história porque o jira adicionará automaticamente os pontos da história para você depois que você crie mais e mais sprints, e depois de identificar qual é a velocidade da sua equipe, saberia quantos itens você pode adicionar da lista de pendências ao sprint atual antes de iniciar o sprint. Digamos que a capacidade da sua equipe seja de apenas dez pontos da história. Então, você sabe, colocando esses dois, você quase atingirá esse limiar de dez. Então você tem espaço para adicionar mais uma tarefa, que é menor ou igual a dois pontos da história. Então, isso é algo para ficar de olho medida que você adiciona mais itens à tala, depois de atingir seu limite para a equipe, você não deve adicionar além disso, e você deve chamá-lo e começar o sprint. Esse é o passo a passo no JIRA e como criar história, tarefa e épico, e como adicionar um sprint. Então, agora adicionamos um sprint. Podemos iniciar o sprint. sprints são encaixotados no tempo e devem ter uma cadência específica, ou seja, se seu amigo tiver uma semana de duração. Então, cada sprint deve começar e terminar dentro desse grande. Se o seu sprint for, digamos que três semanas de duração. Portanto, cada sprint que você criar daqui em diante deve ter esse período de três semanas para a data de início e término. Então, neste caso, digamos que nosso sprint começará em uma segunda-feira e seja um sprint de uma semana. Então, ele deve terminar na sexta-feira para que o próximo sprint possa começar na próxima segunda-feira. Portanto, teremos a data final como terceira e a meta da Sprint estiver completa. Os elementos de design. Sempre pense no que você quer alcançar com este sprint. Se alguma tarefa não estiver alinhada à meta de sprint, você sabe que essa tarefa deve ser removida do sprint antes de iniciar a divisão. Agora você criou a meta de sprint. Agora você pode iniciar o sprint. O sprint está ao vivo. Então, quando você clica na lista de pendências aqui, você veria que tem um sprint em andamento. E você tem o backlog. Depois que um sprint é iniciado, você não deseja adicionar mais tarefas porque ele já está em andamento. Se houver coisas novas que surgem agora, ela vai para a lista de pendências e, com base na prioridade, ela pode ser colocada em cima da lista de pendências. Quando esta impressão terminar, você pode colocá-la no próximo sprint. E digamos que uma vez terminado sexta-feira e tenha concluído todas essas tarefas, é aí que você iria fazer a atividade completa de sprint. Mas antes de fazermos isso, vamos dar uma olhada no quadro. Depois de ter o sprint. Agora você deve ter um quadro que deve ter essas colunas que diz que fazer em andamento e feito depois de iniciar o sprint, tudo por padrão fica na lista de tarefas. E então, na segunda-feira, quando a equipe pega a tarefa, eles começariam a trabalhar nela e passariam para o andamento. E uma vez terminados com isso, então eles se moverão para terminar. Então é assim que o progresso do sprint funciona. E você sempre pode ver o resultado do sprint. Usando os insights aqui, você pode ver que nada está concluído. E uma vez que essa tarefa for concluída, ela mostrará que você já fez 50% porque temos apenas dois itens aqui. Só outra coisa que eu queria mostrar aqui é quando um sprint começou, então você deve ser capaz de ver o gráfico de burndown. Então, vamos ver se posso mostrá-lo para outros projetos que já estão em andamento ou eu. Então, agora, para este projeto, se você olhar aqui, você tem uma opção chamada relatórios. E o relatório que tenho é o gráfico de burndown. momento, há essa tendência que eu deveria ter fechado há muito tempo, mas isso mostra o gráfico de burndown porque eu não fechei essa marca. É por isso que ele está mostrando de forma diferente, mas caso contrário, o gráfico de burndown se parece com isso, onde você tem essa linha cinza que mostra como cada tarefa deve ser concluída. E à medida que você move a tarefa, a linha vermelha aparece. E isso mostra se você está adiantado ou atrasado, qualquer coisa à direita para essa linha cinza que mostra que você está à frente do tempo. E qualquer coisa à esquerda ou por baixo desta linha cinza que mostre um traseiro. Então é assim que você leria um gráfico de burndown e outros relatórios é Sprint e gráfico de velocidade. relatório Sprint é para qualquer sprint concluído. Deixe-me voltar ao sprint um para o outro projeto. Você pode ver como ele progrediu durante esse sprint. E por último, mas não menos importante no gráfico de velocidade, o gráfico de velocidade é aquele que mostra a velocidade da sua equipe. Nesse caso, o que está me dizendo é que nos comprometemos para que seis pontos da história sejam concluídos quando fizemos o planejamento. E, na verdade, os seis concluídos. E novamente na primavera dois, então aumentamos a velocidade para oito e depois completamos oito. Na situação do mundo real, não será assim porque digamos que no sprint um, você planeja seis e completou oito, depois o próximo Sprint, Você sabe que a equipe pode fazer oito histórias pontos? Então você planejaria isso e a equipe completaria apenas quatro. Então, nesse ponto, você tomaria uma média de 64 o que a equipe completou nos dois sprints anteriores e, em seguida, tomaria mediana disso e usaria isso como sua orientação para a Capacidade de Equipes para esse sprint. Então, ao fazer de três a quatro vertentes, então você teria uma ideia melhor do quanto a equipe pode aceitar, quantos pontos da história ela pode entregar e, em seguida, planejar apenas entregar isso. E é assim que o gráfico de velocidade é fundamental entender o que a equipe pode ocupar durante uma planta de uma semana ou duas semanas. Esses são os diferentes tipos de relatório que você dá uma olhada durante e após a conclusão do sprint, esse passo a passo de segurança do que temos na ferramenta JIRA. À medida que fazemos mais projetos na ASPE, fazemos mais projetos práticos, será mais fácil de entender agora. Você só precisa entender onde coisas diferentes estão enterradas naquela página inicial do Jira e como acessar isso, como criar uma tarefa, problemas e história, e como iniciar e parar um sprint mais tarde, uma vez que tivermos um projeto fictício, passaremos e percorreremos sprint real e fecharemos o sprint para que você tenha mais ideia. 19. Carta do projeto: Bem-vindo de volta. Na aula de hoje, vamos dar uma olhada no que é um charter de projeto, por que ele é usado e a importância dele no gerenciamento de projetos e em que fase do gerenciamento de projetos ele é usado. Então, vamos mergulhar na apresentação aqui. Portanto, a carta do projeto é usada no início para documentar o caso de negócios ou as necessidades comerciais juntamente com essa estratégia, retorno sobre o investimento ou os pressupostos que eles fizeram durante o desenvolvimento do caso de negócios, qualquer organização tem sua estratégia e, a fim de alcançar essa estratégia, pode ser a razão pela qual eles estão fazendo este projeto. Quando você faz seu projeto, obviamente você tem que pensar ou não no SAP, mas o patrocinador tem que pensar em retorno sobre o investimento. Você precisa fazer um projeto para que sua empresa possa crescer ou a empresa possa suportar algo, ou é um requisito ilegal para sua empresa exista, seja qual for o caso. Lembre-se sempre, a carta do projeto não é responsabilidade do gerente de projetos. Atraso na situação do mundo real, ela deve ser entregue ao gerente de projeto para que ele possa desenvolver um documento detalhado de planejamento e escopo com base na carta do projeto. Então, vamos ver o conteúdo que temos na carta do projeto. Normalmente, ele terá metas de projeto de alto nível que o projeto tem que cumprir e a linha do tempo de alto nível. A linha do tempo é criada com base no conhecimento que o patrocinador tem ou discutindo em alto nível com outras pessoas. Então, quando você inicia o projeto, você toma isso como uma entrada e vê se ele pode atender à linha do tempo. Ou para atender a linha do tempo, qual recurso e outras ajudas você precisaria para alcançar essa linha do tempo. Às vezes, pode não ser possível, mas se for um prazo difícil, você planejaria e voltaria para o patrocinador e diria que esses são os requisitos para alcançar a linha do tempo. Eles estão dispostos a fazer isso? Então, às vezes, quando o patrocinador pensava sobre o custo, ele pode não ter pensado no custo de alcançar essa linha do tempo. Então é aí que se encontra a carta do projeto. Ele tem as metas de alto nível e uma linha do tempo que o patrocinador quer ou para as coisas que ele pode ser alcançado. Então, o próximo ponto aqui é fornecer uma diretriz de que, como gerente de projeto, você sempre pode perguntar ao patrocinador se ele tem uma carta de projeto com a qual você pode começar. Às vezes, o patrocinador envolve o gerente de projeto no início da vida do gerenciamento de projetos para criar a carta, ou pelo menos um sistema na criação de uma carta. Assim, você sempre pode pedir uma carta do projeto ao patrocinador se você já tiver ou não. Caso contrário, você sempre pode ajudá-lo a criar um. Mas a ideia da carta do projeto é obter o caso de negócios, a estratégia de requisitos de negócios, a meta do projeto e a linha do tempo antes que você possa entrar no planejamento detalhado. E você pode usar a carta do projeto como um princípio orientador em todo o projeto. Então, quando o projeto está se desviando de escopo, cronograma, custo e coisas assim, você sempre pode voltar e olhar para a carta do projeto para ver por que começamos esse projeto no primeiro lugar. E se suas metas atuais do projeto ainda estiverem alinhadas ao projeto ou ao business case. Portanto, é uma boa ideia sempre manter a carta do projeto à mão para que você possa se referir e garantir que a equipe e você como PM ainda estejam alinhados à estratégia de casos de negócios e ao projeto metas definidas na carta do projeto. acordo com o Project Management Institute, você tem um método para criar a carta do projeto. Você pode usar a entrada, como documentos comerciais nos contratos, quaisquer ativos de processo organizacional existentes para criar a carta do projeto usando as ferramentas e técnicas listadas aqui, como julgamento de especialistas, coleta de dados, entrevista ou perguntando a outras pessoas que são especialistas no campo, realizando reuniões e entrevistando pessoas. Você pode tentar reunir mais informações e criar a carta do projeto. Então, na maioria das vezes, é assim que o patrocinador poderia ter criado se ele ou ela já fez o trabalho, é assim que eles podem ter chegado à carta do projeto. Caso contrário, quando o patrocinador, os gerentes de projeto ajudam a criar um, você pode usar essas entradas ferramentas e técnicas para criar uma. Essa é a carta do projeto e por que ele é usado, como ele é usado, em qual fase ele é usado e como criar um. Tudo bem, vejo você na próxima aula. 20. Identificar e gerenciar partes interessadas: Tudo bem, então agora concluímos a introdução e os fundamentos do gerenciamento de projetos. Então, agora estamos realmente pulando para a carne do curso. E essas seções estão alinhadas acordo com o Project Management Institute. Se você está planejando e se preparando para o exame PMP , todas essas aulas daqui em diante definitivamente beneficiariam você de entender. Leia o livro, que é o livro do Corpo de Conhecimento de Gerenciamento de Projetos que você precisa estudar para o exame PMP. Por isso, está completamente alinhado a isso. Então, seria muito fácil ler esse livro assim que você passar por essas lições nesta ordem, fase do projeto, na iniciação das primeiras fases. Nesta seção, passaremos por todas as coisas que acontecem como parte da iniciação. Então, a primeira coisa é identificar e gerenciar as partes interessadas. Vamos dar uma olhada no que fazer nesta área. Portanto, identificar uma parte interessada é fácil porque quando um projeto é iniciado, o patrocinador ou quem financiou, obviamente eles serão a chave. E você pode perguntar a eles, quem é o cliente? Quem sou eu fornecendo esse valor ou produto entregue a nós para que eles se tornem o cliente. Às vezes, pode ser o próprio patrocinador, mas às vezes pode ser externo, onde o patrocinador está interessado em concluir o projeto para entregar o produto ao cliente. Então é assim que você identifica as partes interessadas e qualquer pessoa interessada em seu projeto, todas elas se tornam de alguma forma ou moldam sua parte interessada, incluindo a equipe do projeto. Tudo bem, então agora vamos dizer que, uma vez que você identifique o stakeholder, como você os gerencia? É aí que temos duas seções nos eixos x e y, que é a rede de energia e interesse. Então você tem que categorizar as partes interessadas nesses quatro quadrantes dessa grade. Então, digamos que temos no canto inferior esquerdo. Então, eles são as partes interessadas que têm baixo interesse e baixo poder. O que faz a data de juros é que eles têm algum tipo de interesse em seu projeto, mas não tão alto, quer você o complete ou não, isso não os afetará tanto. Eles têm juros mínimos, mas têm alguns interesses, então você precisa continuar monitorando-os para que eles não criem nenhum pagamento para o seu projeto. E mesmo que o façam, certifique-se de que, desde que eles não tenham poder para fazer nenhum caos em seu projeto. Então, o próximo grupo de pessoas são pessoas com alto interesse, mas não tem muito poder. Talvez eles não consigam parar ou iniciar o projeto diretamente . Eles podem ser altamente motivados ao concluir este projeto, ou são de alguma forma ou forma beneficiados com este projeto. Então, eles têm grande interesse neste projeto. Então, esses grupos, você tem que mantê-los no PharMD porque eles têm algum nível de interesse. E talvez eles tenham alguma dependência quando seu projeto estiver concluído, eles precisam fazer outra coisa. Portanto, é sempre bom ter comunicação aberta com eles e mantê-los informados durante todo o projeto. O próximo conjunto de partes interessadas são aqueles que têm alto poder e interesses um pouco bons. Então, desde que eles tenham alta potência, isso pode causar algum impacto negativo ao projeto. Então você tem que se certificar de que os mantenha satisfeitos. Então, pode ser o seu escritório de gerenciamento de projetos ou pode ser o patrocinador, alguém que tem alto poder. Você tem que se certificar de que os satisfaz. E, em seguida, o próximo conjunto de partes interessadas, aqueles que têm hiperconsciência, bem como altos juros sobre a tendência do carro. Precisamos ter certeza de que você os gerencia muito perto no sentido de que precisa cuidar deles com informações. Você tinha que ouvi-los, você precisa fornecer atualizações a eles. O que você precisa fazer para garantir que eles sejam gerenciados de perto para que não criem nenhum problema para o seu projeto. É por isso que esse grupo precisa ser gerenciado e monitorado de perto. Mas isso é de alto nível, como você identifica sua parte interessada do patrocinador e, em seguida, constrói ao longo do projeto a lista de partes interessadas e atribuindo-as ou classificando-as em um desses quadrantes. Então você sabe como gerenciá-los durante todo o projeto para que você não seja afetado pelo comportamento. 21. Kickoff do projeto: Então, agora, nesta lição, vamos dar uma olhada no início do projeto, e esta é a fase final na fase de iniciação do projeto. Após o início, iremos direto para a fase de planejamento do projeto. Então, o que é necessário para o início do projeto? O que é um pontapé inicial do projeto? Vamos dar uma olhada nisso. Deixe-me mudar para o modo de apresentação. E aqui você pode ver que, no início do projeto, temos que pensar em quem deve ser convidado. Então, basicamente, você precisa pensar nas partes interessadas que definimos anteriormente. É qualquer um que é impactado direta ou indiretamente com as mudanças do projeto. Então, definitivamente, você tem que incluir seu patrocinador, sua equipe , seus usos comerciais e quem estiver relacionado a quem está associado a este projeto, você tem que envolvê-los ou convidá-los, pelo menos no início do projeto nas reuniões futuras que podem ser seletivas sobre os participantes, que devem participar dessas reuniões. Mas para o pontapé inicial, é melhor convidar qualquer pessoa que esteja direta ou indiretamente envolvida. E se for uma liderança mais alta, mantenha-os como opcionais e eles podem se juntar ao esforço necessário. Você deve se referir como lista de partes interessadas e ver quem você deve convidar para o início do projeto, as melhores práticas para convidar a equipe do projeto e o patrocinador com certeza, no mínimo, porque eles são os únicos ou a equipe do projeto é a única que tem que fazer o trabalho. Então eles precisam saber do que se trata esse projeto. Isso está apenas preparando o palco. Você está convidando o mundo e está avisando que o projeto está chegando. Você precisa ter certeza de que eles entendam a pontuação do projeto e tudo mais. Então, vamos dar uma olhada na agenda. Então, normalmente, no início do projeto, você quer começar com a introdução da equipe porque esta é a primeira vez que você está se reunindo equipe de ativos, gerente de projetos de ativos, você pode ter interagiu com o patrocinador, mas esta é a primeira reunião onde você está trazendo um grupo maior de pessoas que fazem parte deste projeto. Portanto, é sempre uma boa ideia ter apresentações de uma equipe. Pode haver várias equipes funcionais e os membros da equipe de cada função, eles podem ou não se conhecer. Então, esta é a primeira vez que você quer ter uma introdução. Você também quer colocar na apresentação que a estrutura da equipe, como a equipe do projeto será e quais são suas responsabilidades. Raci algumas métricas que vamos dar uma olhada na aula posterior. Mas o que Apagar ele faz é listar o nome da função ou do membro da equipe e atribuí-los às tarefas, sejam elas responsáveis, expansíveis ou se forem consultadas ou informadas. Porque, dependendo do RACI, eles podem entender qual será o papel deles no projeto. Então, se possível, junte um atrevido e você sempre pode coletar feedback e reduzir a dívida durante o início ou após o pontapé inicial. As próximas coisas que você precisa pensar para apresentar o pontapé, obviamente, a linha do tempo. Portanto, você pode não ter um cronograma detalhado completo, mas você deve ter no plano Milestone quando tiver que atingir determinadas datas e você pode descer da carta do projeto. Portanto, você deve sempre ter o plano de marco e as principais datas para que todos estejam na mesma página. Você também deve compartilhar o escopo do projeto, a data de início oficial e todas as ferramentas e coisas que você planeja compartilhar com a equipe. Como discutimos anteriormente, o lado da colaboração, como eles podem acessar se forem adicionados e todos esses detalhes podem ser apresentados e compartilhados durante o início. E também se houver algum subprojeto que faça parte desse projeto principal, mas esses também podem ser iniciados durante o início deste projeto. A ideia aqui é fazer homens grandes e armados e garantir que todos estejam na mesma página. Então, talvez durante o pontapé inicial, você pode receber feedback de que deve envolver algumas outras partes ou outros membros da equipe. Então, colete esse feedback e, se necessário, adicione-os conforme necessário. Portanto, esse é o estágio final da fase de iniciação do projeto. E depois disso, você vai direto para o planejamento porque agora você tem uma equipe de projeto, você compartilhou a estrutura da equipe e todos entendem o que eles têm que fazer como parte do Gráfico RACI. Então, todos vocês se reúnem como uma equipe e planejam na próxima fase, que será a base para a execução. Então isso conclui a fase de iniciação do projeto. Então, iremos para a fase de planejamento do projeto na próxima aula. 22. Planejamento ágil com Jira: Então, agora é a parte fácil. Fizemos o planejamento com a equipe na parede. Então, pelo menos identificamos as histórias de usuários e a tarefa associada na parede. Agora é apenas o processo de transferi-lo para uma ferramenta. Se você usa a ferramenta jira Atlassian ou alguma outra ferramenta, é tudo a mesma coisa. Basicamente, se você estiver fazendo scrum, então você terá um backlog de produtos. E, em seguida, você coloca todos os itens definidos que foram identificados durante o planejamento de sprint e o planejamento da lista de pendências do produto na ferramenta. Estou usando o Gita e a maioria da organização tem JIRA ou algumas versões de outros softwares que se parecerão exatamente com o Jira, onde temos backlog, sprint e outras coisas. Então, para essa abordagem, vamos com três opções. número um é transferir as histórias de usuários da parede para o backlog do produto gyrus. Então, para fazer isso, temos que primeiro criar um projeto. Ao criar um projeto, ele pode ser um projeto Scrum ou um projeto kanban dependendo do que você está usando para sua organização. E se você estiver usando o método em cascata, provavelmente o planejamento pode não ser como um planejamento de parede, mas é uma atividade semelhante em que você liga para todos os membros da equipe do projeto e, em seguida, pergunta-lhes quais são as atividades que eles têm que fazer para atingir os objetivos do projeto? Na lição subsequente, mostrarei como dividir essas atividades e colocá-las no Microsoft Project, que é a ferramenta mais comumente usada para metodologia em cascata. Então, vamos entrar no JIRA primeiro e ver como isso é feito para um scrum. E também vamos dar uma olhada em como criar um quadro Kanban e como isso é feito em Kanban. Tenho todas as histórias de usuários na parede aqui atrás de mim. Vou pegar rapidamente um e depois fazer meu compartilhamento de tela para que você possa ver como criar um projeto e como colocá-lo em uma lista de pendências. Tudo bem, vou pegar o primeiro aqui, que é este. Esta é uma história de usuário. A persona é como gerente de projeto, eu queria baixar o modelo de plano de projeto para poder usá-lo no meu projeto. Então, o projeto que temos aqui é criar um site de comércio eletrônico onde temos todos os modelos relacionados ao gerenciamento de projetos. E como usuário, que é PM, ele ou ela queria baixar esse modelo ou comprou esse modelo e como fazê-lo. Então isso é basicamente essa história de usuário. Assim, podemos dividir isso em uma tarefa ainda menor, ou a equipe teria dividido em tarefas menores durante o planejamento da parede. Agora é apenas uma questão de transferir isso para o tabuleiro do JIRA. Tudo bem, agora deixe-me pular para a tela aqui como você pode ver, eu tenho um projeto que já tem backlog. Nesse caso, o que vou fazer é seguir em frente e criar um novo projeto. Se você estiver em uma organização onde o Jira é gerenciado por seu software ou equipe de TI fora do projeto. Em seguida, normalmente você levantaria uma solicitação e pede que eles criem um projeto do Jira Scrum ou um projeto kanban para você. Então, qual é o fluxo de trabalho mundial que eles têm, eles normalmente criariam o projeto e o dariam a você. Então, seu ponto de partida pareceria algo como um backlog e é aí que você criaria. Mas só por uma questão de mostrar a você a trás da cena sobre como criar o projeto. Vou seguir em frente e criar um projeto. Para fazer isso, no canto superior direito, você clica na barra de configurações e depois vá para Projeto. Você terá uma opção chamada Criar projeto. Como você vê aqui, criei vários projetos. Então, neste caso, vou criar um novo projeto. E naquele momento, me dá uma opção se eu quero criar um projeto kanban ou um projeto Ashcan. Então, vamos primeiro criar um projeto Scrum e ver como isso se parece. Então, seja qual for o modelo padrão que eu tenha ou o Jira esteja me oferecendo, vou usá-lo. Você tem opções diferentes aqui para modelos de projeto, vou usar o desenvolvimento de software porque é isso que estamos usando. Então, vou usar esse modelo. E isso me dá uma opção se esse projeto será gerenciado pela equipe ou pela empresa. Normalmente, o projeto será gerenciado no nível do projeto pelo TI da empresa ou pelo administrador do Jira. Você pode, você não veria todas essas opções quando estiver no nível do projeto gerenciando projetos. Então, vou criar um projeto gerenciado pela empresa porque sou dono dessa plataforma GTR para esse projeto em particular. Então, vou nomeá-lo como projeto. Site do modelo. Tudo bem, então estamos usando o Scrum e criamos projeto. Jira criou o projeto e ele voltou com as ferramentas básicas que você precisa, que é backlog e sprints. Então, a partir de agora, você não tem nada porque não criamos nenhuma história de usuário na ferramenta. O que fizemos foi o planejamento na parede. Então, isso é o que você receberá quando iniciar o projeto com seu administrador do Jira. Basicamente, você não precisaria criar um projeto porque isso será feito pelos administradores de TI. Vamos ver. Agora temos um projeto criado. Você pode clicar em Criar e começar a criar as histórias. Então, basta verificar se temos todas as informações necessárias aqui. Portanto, as configurações do projeto, como você pode ver, ele tem que fazer em andamento e isso está no sprint ativo. Backlog, tudo estará aqui. Você terá épico. E versão. A versão é o nível mais alto. Se você estiver lançando seu produto em várias versões , criaria a versão um, a versão dois. Às vezes, projetos são lançados durante as diferentes estações do ano. Então, seriam falsos da primavera e coisas assim. Seja qual for a versão que você planeja fazer, você pode criá-la. Ou se você não criar nenhuma versão, tudo bem. Você pode começar no nível épico. Então, o que faremos aqui é que começaremos a criar as histórias de usuários reais e, em seguida, decidiremos como queremos agrupá-las em um épico. Epic é um conjunto maior de atividades ou um grupo de histórias de usuários e tarefas agrupadas para manter essa organização. E épico pode ser amigo e design. E outro épico poderia ser o banco de dados. Outro épico poderia ser algo relacionado à arquitetura. Então você pode organizar, é apenas uma maneira de organizá-lo. Então você está quebrando com épico maior, as menores histórias e coisas assim. O que você quer fazer ao transferir as histórias de usuários é que você deseja ir para a lista de pendências da esquerda. E você quer criar tudo na lista de pendências porque seu sprint ainda não foi iniciado. Você está na fase de planejamento e está construindo todas as histórias de usuários, requisitos de projeto na lista de pendências. Então, vamos criar uma história que você possa digitar, começar a digitar aqui ou clicar em criar. Por padrão, você tem opções, seja uma história, bug de tarefas ou época. Então, vamos criar uma história porque o que temos na nota adesiva aqui, você diz histórias de usuários. Então, vou dizer que baixe modelos de projeto. Então aqui vou escrever a história do usuário como gerente de projeto, que é a persona. Então, neste caso, apenas para lembrar o plano de fundo é que estamos criando um site onde os usuários podem entrar e baixar o respectivo modelo para o projeto. A persona é obviamente gerente de projeto ou líder de projeto ou alguém da equipe que precisa de um modelo. Então, neste caso, a persona é gerente de projeto. Então, estou dizendo, como gerente de projeto, quero baixar o arquivo de modelo de plano de projeto e só temos que fornecer o motivo pelo qual ele precisa dele. Então, quando você olha para o requisito, fica muito claro para a equipe para que eu possa usá-lo no meu projeto. Portanto, esta é uma história de usuário muito simples, e normalmente elas precisam ser fornecidas pelo proprietário do produto e que discutimos no planejamento da parede. Agora, nesta fase, como um ScrumMaster, você está apenas tirando todos esses nós e histórias de usuários da parede e colocando no software. Então, vamos seguir em frente e olhar para qualquer outra coisa a ser adicionada aqui. Então, neste momento, se você quiser adicionar um destinatário do seu projeto, você pode fazer isso. Se você quiser classificar isso como qualquer rótulo, você pode fazer isso. Então, vou criar um rótulo chamado modelo. E se houver um épico criado , você pode vincular a época. Mas, a partir de agora, não criamos uma época. Então vá em frente e crie, como você pode ver agora na lista de pendências, deve ser uma história de usuário. E deixe-me clicar nele e ver que ele surgiu. Então, como você pode ver aqui, ele é criado como uma tarefa em vez de uma história. Talvez por engano, eu possa ter selecionado isso. Você sempre tem a opção de mudar isso. Então tudo o que você precisa fazer é clicar em Mover. E então, a partir do projeto atual, passando como uma história e diga Next, dê algumas histórias apenas por uma questão de colocar algo, digamos cinco pontos da história. E então, basicamente, está convertendo a tarefa em uma história. Confirmamos isso. Tudo bem, Perfeito. Agora voltamos para o registro bancário com o icônico e vemos que agora é uma história de usuário. Então esse é um bom erro que cometemos porque agora você sabe como converter da história da tarefa dois, sua história para tarefa ou subtarefa da Tarefa dois. Você pode fazer isso com a opção de mover isso. Então, se você quiser ver que você pode clicar no item e clicar nos três pontos aqui e se mover. E isso é um atalho, se você já se perguntar, então clique na Tarefa e digite um ponto ou ponto nela. Não forneceu todas as ações que você pode fazer contra essa tarefa específica ou histórias de usuários. Então esse é sempre um atalho que uso para criar uma subtarefa ou trabalho de log ou atribuí-lo a mim ou a um ponto de história, posso fazer tudo isso em vez entrar aqui e procurar opções. Portanto, lembre-se de que clique na história específica e digite ponto e ele listará todas as opções que você tem. Tudo bem, agora transferimos a primeira história do usuário para a lista de pendências. Então, vamos dar uma olhada neste segundo. Use uma história. Então, vou estender a mão para a parede. Esta é a segunda história de usuários, que é analista de negócios ácido. Eu queria baixar um modelo de matriz de requisitos para garantir que todos os requisitos estejam completos. Portanto, os requisitos do modelo, para que você possa seguir em frente e criar um problema. Quando você cria diretamente no Backlog, seja qual for o problema anterior, ele criará o mesmo tipo. Portanto, se o problema anterior fosse uma tarefa, ele criará o próximo tecido como uma tarefa. E você sempre pode mudá-lo, mas isso é algo para estar ciente. Agora temos outra história de usuário que é o modelo de matriz de requisitos de download. Tudo bem, então, uma vez que você clica nisso, ele criou uma mesa. Não há pontos da história aqui. Agora vamos criar um ponto e dizer, não vejo uma opção para editar aqui. Então talvez eu tivesse que ir aqui e editar na janela lateral aqui, adicionar uma descrição. Vou começar a digitar no mesmo formato, o formato da história do usuário como um analista de negócios que é a persona aqui, quero baixar o modelo de matriz de momentos silenciosos para que eu possa garantir nossos requisitos são mapeados e completos. Clique em salvar, que a descrição é salva e você pode atribuí-la a alguém a partir de agora, não há ninguém neste projeto além de mim. Então, depois de atribuir um dual, veja-o no desenvolvimento da lista de pendências. Se você tiver uma equipe de desenvolvimento, eles podem se integrar com o ponto de bitbucket Jenkins, e você pode criar branch, commit e tudo isso. Novamente, rótulos, é um modelo. Assim que você começar a digitar inteiro, ele mostrará o que já criamos esses pontos da história. Digamos que isso é três. Falaremos sobre pontos da história em um minuto e prioridade. Tudo bem, acho que somos bons aqui. Então, agora criamos duas histórias de usuários, ambos nossos modelos, e agora acho que vamos criar outra história de usuário relacionada ao banco de dados. Então, vou criar um problema aqui, História, ambiente de banco de dados. Aqui. Isso é necessário para mais do que o usuário. Isso é necessário para o administrador. Então ensaie a TI. Administre o projeto. Preciso criar um banco de dados para que eu possa armazenar todos os modelos de projeto, credenciais de usuário, etc. Tudo bem, então não estou atribuindo nenhum ponto da história e atribuindo recursos a ele que acabei de criar para que eu possa mostrar qual é a importância da apec. Então, se eu clicar na EPEC e diremos Criar EPEC a partir daqui. Digamos que eles escolham o nome são histórias técnicas e tarefas relacionadas ao trabalho técnico. Para concluir. O projeto. Agora temos uma época aqui. Agora vamos criar outra época que ela esteja relacionada ao modelo. Todo o nome escolhido é chamado de downloads de modelos. Todas as histórias de usuários e tarefas relacionadas somente se eu puder soletrar relacionadas ao modelo, baixando modelos solicitando usuários. Tudo bem, então agora você tem duas épocas criadas aqui. Então, se você tiver que olhar na lista de pendências, você veria que os épicos estão à esquerda e você precisa clicar nele. E, a partir de agora, nenhum dos problemas é mapeado. Então, a maneira mais fácil de mapear é você pode clicar nele e ir para o link aqui. Então, um pouco link e você pode procurar por um determinado. E neste caso, isso é técnico. Ele pode atribuir isso. Mas se você tiver um grande número de histórias e tarefas na lista de pendências, as maneiras mais fáceis de minimizar os nomes épicos aqui. E você pode selecionar várias histórias e tarefas, mas você pode arrastar e soltar em uma época. Assim, você pode selecionar várias histórias ou tarefas e, em seguida, arrastar e soltar no apec onde deseja mapear o mesmo que entrar na história e clicar no link e vinculá-lo dessa maneira, Acho muito mais fácil arrastar e soltar. Então agora é isso. Então, agora vamos dizer que queremos criar uma versão. Então vamos um, isso é lançar uma ou histórias de usuários ou lançar uma que eles criam. Agora ele é criado. E o que você pode fazer é mapear o épico. Acho que só permite mapear as histórias e tarefas. Você pode selecionar. Command clique até a parte inferior e, em seguida, arraste e solte para soltar um. Então, agora você tem dois problemas. Talvez eu não tenha selecionado isso, então eu tenho que arrastar e soltar isso. Tudo bem, então três problemas agora estão atribuídos à primeira versão. Então, agora cobrimos as versões, versão épica e as histórias e eles escolhem nas laterais. Então, se você quiser ver os detalhes, verá que por que é importante quando você iniciar seu roteiro, então você pode ver como os épicos são mapeados e, em seguida, eles estão sendo entregues. Essa é uma vantagem. E então você pode olhar apenas lavando um. Se você tiver vários lançamentos, poderá escolher e escolher apenas os lançamentos em que você está interessado. Quando se trata de roteiro, é muito útil ter a categorização de versão e épico associados ao uso de histórias e tarefas. Tudo bem, então agora o planejamento está feito. Nós movemos nossas histórias de usuários e tarefas da parede para o Gita. E agora é hora de pensar em como queremos um ponto da história. ponto da história é sempre relativo. Então, se eu tiver que dar um exemplo, vou pegar duas peças que tenho na mesa. Isso é algo que é quire e isso é algo pequeno. E se eu disser este item aqui, se eu apenas disser que isso está em um ponto de dois andares, e se eu perguntar se isso é dois, quanto é esse certo? Porque é tudo relativo. Então, como você pode ver, isso é quase três vezes mais alto e comprimento duas vezes, talvez 1,5 vezes. Então, obviamente, se eu disser que são pontos de dois andares em sua intuição natural é que isso seria seis pontos da história porque três vezes o tamanho disso. Então, idealmente, você quer chegar a um ponto em que você pode dimensionar a tarefa e o turista relativamente, comparou relativamente duas histórias diferentes em vez de história apontá-la com base no número de dias e horas. Então, à medida que você amadurece como uma equipe, como uma equipe Scrum, ela virá naturalmente também. Faça essa estimativa de ponto de história em relação uma à outra em vez de olhar para horas. Então é isso. E agora você tem tudo transferido para o backlog como parte do planejamento. Quando iniciamos a fase de execução do projeto, é aí que criaremos o sprint e decidiremos quais usam histórias precisam ser transferidas do backlog para o sprint e começaremos executando este lápis. Voltaremos a isso durante a execução do projeto. Agora, para fins de planejamento, tudo o que você está fazendo é transferir todos os itens da parede ou durante a sessão de planejamento o que você identificou na ferramenta JIRA ou em qualquer ferramenta que você está usando para gerenciar um projeto e estimá-lo colocando ou atribuindo pontos da história, atribuindo recursos. E então você teve que trabalhar com o gerente de produto ou o proprietário do produto para priorizar, certo? Qualquer coisa que esteja em alta prioridade, você pode colocá-lo em versões ou arrastar e soltar e dizer qualquer coisa sobre a lista de pendências que a prioridade mais alta. Assim, você pode fazer tudo isso com a equipe e o proprietário do produto. E isso conclui o planejamento usando a ferramenta. E novamente, lembre-se de que isso é apenas uma ferramenta, o planejamento que você fez com a equipe na sala. Esse é o planejamento real. E agora estamos usando a ferramenta para organizar isso de uma forma que iniciamos o sprint. É fácil ver o que está sendo concluído. E eu sei como a equipe está se saindo e tudo isso. Tudo bem, então agora vamos dar uma olhada no mesmo com, mesmo que você tenha o quadro Kanban, o conceito de backlog permanece o mesmo. É só que você não teria molas ativas e Kanban, mas o processo de transferi-lo para uma ferramenta e criar um projeto permanece o mesmo. Portanto, durante a fase de execução do projeto, vamos aprofundar a diferença entre a execução do Scrum e Kanban e gráficos e relatórios que normalmente observamos durante o Scrum e o Kanban. Tudo bem, isso cobre esta lição. E nas lições subsequentes vamos dar uma olhada em como faríamos essas tarefas em histórias de usuários no Microsoft Project. Se você tiver que fazer gerenciamento de projetos em cascata. 23. Planejamento de projetos em projeto Microsoft Project: Tudo bem, agora, como coisas empolgantes, vamos fazer um projeto simples, um projeto prático. E veremos como dividir os requisitos do projeto em tarefas menores. E antes de entrarmos na ferramenta real no MS Project ou no Jira para fazer o planejamento. Vamos dar uma olhada em um quadro-negro. Como o planejamento do projeto é normalmente como um projeto evoluiu de um estágio de ideia para um projeto real e planejamento diferente e diferentes tarefas e marcos e coisas assim. Então deixe-me voltar para o quadro aqui e espero que vocês possam me ver. Vamos chamar isso de projeto para pintar uma sala e ela tem quatro paredes. Quarto padrão típico. Então vamos dizer que você tem um quarto aqui que precisa ser pintado. Então, digamos que esse seja o escopo. Agora, para fazer essa pintura, primeiro, temos que ter recursos para fazer o trabalho. Você precisa de um pintor. Você obviamente precisa de tinta. Você precisa de acessórios e impetuosos, talvez para cobrir seu piso ou dois lá para que você não derrame tinta sobre você, então você pode precisar de luvas e produtos de limpeza. Tudo bem, então vamos dizer que essas são coisas que você precisa. Você precisa de um pintor, você precisa de uma tinta, pincel e acessórios, você precisa de luvas e materiais de limpeza. Então, digamos que se você está fazendo tudo isso sozinho, então você pode ter que se preocupar com todas essas coisas. Mas se você está fazendo isso com um pintor do que ele traria todos esses itens, você só tem que obter uma citação dele. Digamos que você esteja fazendo isso sozinho apenas por uma questão de gerenciar um projeto sozinho. Então, digamos que você não precisa pintar ou não precisa pagar pela tinta lá porque você está fazendo sozinho. Mas você tem que acomodar o custo da tinta. Você tem que acomodar o custo dos acessórios. Poderia ser materiais de limpeza de escova, uma panela para fazer a pintura são misturadas a pintura em qualquer coisa que você possa pensar. E então você, na hora, só para ver se é uma boa ideia fazer isso sozinho, ou é melhor terceirizar? É o pintor. Então, digamos, neste caso, você está fazendo sozinho ou uma ou duas latas de tinta para bronzeado acastanhado para misturar luvas. E então seu tempo, digamos que leva uma hora por parede. Se você está procurando por cronograma, você tem o custo aqui. Agora esta é a sua agenda. Esse é o seu custo. E se você se lembrar da restrição tripla, temos o escopo, o tempo e o custo para os quais afetarão a qualidade. Então, discutimos sobre o custo e o cronograma, e já temos o escopo aqui. Mas apenas para pintar uma regra, é assim que um pequeno projeto se parecerá. Você quer dividi-lo $1 por parede em uma tarefa de mais minutos. Então, diria 13 minutos para remover a pintura antiga, depois em 20 minutos para aplicar o primer e, em seguida, insira a tinta de dez minutos, aquela parede em particular. Você precisa de uma hora por parede. Você tem quatro paredes aqui. Isso significa que em quatro horas para completar a sala. Este é um exemplo muito simples de como você planejaria um projeto onde você precisa olhar para esta escola. E dependendo da escola, você precisa olhar para o custo e o cronograma. Você pode dividir esse cronograma ou pintar uma sala em pintar paredes. E dentro dessas quatro paredes, quanto você pode dividi-la, removendo a dor, aplicando primer e aplicando o primeiro código e o segundo código. Então é assim que você detalha a tarefa. Agora vamos ver como se você tiver que inserir isso em um MS Project ou Jira, como isso se parece para que você tenha uma boa compreensão de como usar a ferramenta para fazer a mesma coisa que temos discutido no Blackboard. Tudo bem, então deixe-me pular para o MS Project. Tudo bem, então temos um projeto em branco aqui. E o que vamos fazer aqui é, digamos que o nome do projeto esteja pintando uma sala. Então, quando você abre o projeto, essa é a visualização padrão que você obteria. Temos a próxima lição para orientá-lo pelas diferentes seções do projeto. E para entender em detalhes. Mas, por enquanto, exatamente o que tínhamos no Blackboard, vamos traduzir isso aqui e ver como isso se parece. Então, tivemos nosso projeto gastando seu quarto. E então temos parede 1234. Então, colocamos isso para completar a sala, temos que completar esses quatro. E você pode ir para a tarefa e fazer um intenso para que você saiba que todas essas tarefas pertencem à pintura de uma sala e dentro de uma parede, você pode simplesmente clicar com o botão direito do mouse e dizer Inserir tarefa e você pode insira-o continuamente enquanto você precisar. Então, neste caso, vou inserir três tarefas aqui, como discutimos, 123. Então dissemos para pintar a primeira parede, você precisaria remover tinta antiga. Então, remova a tinta, então você tem que preparar a parede e depois aplicar nova tinta. Estas são as três atividades para Baldwin. Você pode selecionar todos esses três e em seguida, pretendeu que, ao fazer isso, você sabe que são itens que pertencem ao Wall número um, você pode repetir a mesma coisa ou você pode simplesmente Controle C no Windows, e ele pode apenas aplicar o controle V aqui para parede para, depois da parede três, controlamos V? E depois para o controle V. Novamente, para cada parede, você tinha que fazer um intenso que essas sejam tarefas separadas sob isso, você faria a mesma coisa aqui, tê-lo. Agora, quando você olha para isso, você estabeleceu as diferentes tarefas para pintar uma sala. Você quebrou em cada parede e dentro da parede você variou uma tarefa de subnível de minuto. Nós quebramos. Isso é chamado Estrutura de divisão de trabalho, dividiu-se em detalhes. E se você clicar com o botão direito do mouse e inserir uma coluna aqui e procurar por WBS, tudo o que está fazendo é atribuir subseções para cada um desses itens. Portanto, um é o projeto de nível superior, 1.11.21.31 para a tarefa. E então está fazendo cada vez mais intimidação para criar o detalhamento de trabalho ou tarefas de nível de minutos. Então, a próxima coisa, o que você faz na ferramenta no MS Project ou Excel? O que estamos usando é criar uma dependência para, digamos parede um e parede a parede três, parede cai já que é só você quem está fazendo o trabalho, você pode não ter. Você não pode fazer multitarefa. Você tinha que terminar um para passar para o próximo. Então você diria que , para começar a parede, eu preciso completar enquanto um, certo? Então, se você olhar para a esquerda aqui, você veria um número dois. Então esse é o número de série ou os números da tarefa. Então você diria, ok, eu tenho uma dependência e isso está definido em antecessores. Então, se você olhar para os preconceitos, digamos que posso dizer que tenho uma dependência do número da tarefa até a conclusão. Então, o que o projeto faz é automaticamente a data final retirar automaticamente a data final e a tarefa dependente e , em seguida, atribui o dia seguinte como data de início. Então, aqui temos um problema. Digamos que no Blackboard dissemos que levará 20 minutos, uma hora para fazer isso, então acabará por ser concluído no mesmo dia. Mas, por uma maneira boa e fácil de entender, vamos supor que tudo isso leva um dia H removendo a tinta, preparando uma parede e aplicando nova tinta levaria um dia de idade. Então essa parede levaria três dias. Então, vou adicionar 111. Vai demorar um dia H. E, novamente, tem que ser feito sequencialmente um após o outro. Para fazer isso, você pode definir manualmente a dependência como eu disse, bem, preparando uma parede, você diria, ok, meu antecessor é três. Mas se, se for muito sequencial, você pode clicar aqui chamado link a tarefa. E isso definirá automaticamente o antecessor. Faça o mesmo por isso e diga vincular a tarefa. E faremos a mesma coisa por isso, vincule essa tarefa. Então, é apenas garantir que ele seja dependente um do outro. Então, para começar o 16, você teve que completar o 15º e para começar 17 anos para completar 16. Então esse é o plano do projeto desenvolvido. Então, novamente, você precisa adicionar tudo isso para poder selecioná-los e pressionar o controle e selecionar isso, tudo isso. E há uma maneira fácil atualizar se houver a mesma quantidade de horas ou dias que precisamos atualizar no plano do projeto. Você pode acessar as informações e fazer uma atualização em grupo de um dia. Isso aplicará isso para todos os projetos selecionados que você não precise manualmente. Economize um dia para cada um deles. Agora que temos, esse dia é definido para cada um deles, qualquer coisa que falta um antecessores para que ele possa remover a tinta em val2 somente depois de completar a parede um, que é o número cinco. Então, vou acrescentar isso aqui. mesmo com a parede Número três. Você só pode começar quando terminar com a tarefa número nove aqui. Então, vou acrescentar isso aqui. E neste caso, como você sabe, é 13, que precisa ler concluído antes que você possa iniciar essa tarefa. Agora, depois de definir as dependências, certo, você tem um projeto de dia todo. Apenas criando um plano de projeto, você saberia que para completar esse quarto, leva dois dias. Então, a próxima coisa que você deseja atribuir são recursos. Nesse caso, a coisa toda é feita por você mesmo. Você pode dizer que tudo é feito por um recurso. Caso contrário, se cada um deles for feito por recursos diferentes, você poderá adicioná-lo como um recurso. Neste caso, ele nos mostra o vermelho porque pensa em um projeto damasco coisas que Nick está fazendo esse trabalho, mas ele também está fazendo projetos mortos para que ele não tenha tempo. Então esse tipo de cabeças, digamos que, se esses recursos sobrecarregaram ou não, digamos que é uma tarefa aleatória aqui. Tarefa aleatória, mas ela precisava ser concluída, digamos no mesmo dia. Portanto, ele tem uma dependência disso é uma maneira de um dia, mas não tem dependência de nada. E eu pensei: Ok, eu posso fazer isso e atribuo um recurso aqui. Então ele lhe dirá que, Ei, lá você pode fazer essa tarefa. Tudo o que você pode fazer essa tarefa porque Buda começando e terminando ao mesmo tempo e você tomou esse recurso completamente para esse dia. Você não tem a largura de banda. Portanto, essa é uma maneira de projetar dizer que quaisquer recursos sobrecarregados, isso é chamado de nivelamento de recursos. Então, sempre que você vir o recurso sobrecarregado, você tem que nivelar o recurso ou atribuí-lo a outra pessoa, digamos Sam, então, nesse caso, você tem que contratar mais um recurso para fazer essas tarefas aleatórias porque Nick não está disponível. Tudo bem, então agora você tem um bom plano de projeto ao lado, e isso é chamado de gráfico de Gantt, onde você pode ver a referência visual de como tarefa diferente flui e o início e o fim. E, no topo, você tem uma visão da linha do tempo. E se você quiser adicionar qualquer item à linha do tempo, você pode clicar com o botão direito do mouse e dizer Adicionar à linha do tempo. Então, ele dirá enquanto alguém levaria de 1011 a 1013. E, ao mesmo tempo, você pode adicioná-lo à linha do tempo. E isso é bom acrescentar para que você possa mostrá-lo ao seu patrocinador. Só essa visão. Eles obtêm a imagem completa de quando cada uma das paredes será concluída. Agora você tem um plano de projeto completo. Com base nesse projeto simples de pintar todo mundo mau sal, você desenvolveria seu plano de projeto a partir do zero, atribuiria a duração, dividiria a tarefa em outros componentes menores. Estrutura de detalhamento de livros não S, duração de tempo e recursos atribuídos e gerenciar o projeto que temos. Esse é um bom pequeno exemplo em que agora você tem uma boa compreensão de como seu projeto básico que discutimos no Blackboard pode ser colocado na ferramenta no projeto MS. Tudo bem, então na próxima aula veremos como o mesmo projeto é feito no Agile e como ele é desenvolvido para planejamento na ferramenta GDI. 24. Como adicionar férias e tempo limite no Projeto MS: Ei lá, bem-vindo de volta. No vídeo de hoje, mostrarei como adicionar feriados em seu projeto MS dessa maneira, quando você calcular o número de dias ou a duração, os feriados são excluídos. Você também pode adicionar calendário de recursos semelhante aos feriados. Dessa forma, se você tiver recursos ou grupo de recursos trabalhando em diferentes regiões, digamos nos EUA e na Ásia. E se eles tiverem feriados diferentes, você pode adicionar tudo isso. Então, quando o projeto calcula a duração do tempo, ele exclui todos esses feriados e folga. E é uma maneira muito rápida e fácil de fazer isso. Então você só grita para configurá-lo uma vez. Você sempre pode copiar calendários entre recursos e entre o plano padrão, você pode configurá-lo para cada região. Então, vamos direto para o MS Project e orientá-lo sobre como fazê-lo. Antes disso, se você é novo aqui, sou Nikhil, um gerente de projeto certificado PNP e CSM. Estou aqui para ajudá-lo a avançar em sua carreira de gerenciamento de projetos. Então isso é algo interessante. Portanto, considere se inscrever neste canal e fique atento para mais vídeos. Tudo bem, então vamos mergulhar no MS Project aqui. Quando você abre o projeto, isso é o que você tem. Então, vou criar um projeto de teste aqui e vamos chamá-lo de feriado do projeto. Digamos que eu tenha por enquanto, deixe-me mudar tudo para o cronograma automático que calculamos automaticamente. Vamos dar uma olhada no projeto aqui. Então, as informações do projeto. Então o projeto vai começar, digamos terça, 11 de janeiro. E nos Estados Unidos, 17 de janeiro é um feriado. Então, vamos adicionar isso. Vamos dizer, ok, digamos que minha tarefa da primeira semana. Por exemplo, é uma tarefa de cinco dias. E isso cai abaixo, você pode pressionar Alt Shift e seta para pretendê-lo para que ele caia no projeto. Então, como você pode ver, se eu começar na terça-feira, ele termina no dia 17 porque o projeto não sabe que é um feriado. Então, como superamos isso? Você tem que mudar o horário de trabalho para que não haja calendário ou qualquer outra coisa que você tenha que mudar. Vá abaixo da guia Projeto na parte superior e clique em alterar o horário de trabalho aqui. Você pode adicionar todas as exceções. Por padrão, temos calendário de projeto padrão. E se você usar isso, o padrão e o dia e a hora são de oito a 121 a cinco. Se você quiser alterar isso, você pode mudar acessando Arquivo e Opções. Essa é uma opção para alterar o cronograma. Então aqui você pode alterar que oito a cinco opções são se sua semana começar em um dia diferente. Então é aqui que você o muda. E se você tiver mais um dólar por dia ou 40 horas por semana, poderá alterar tudo isso nas opções do projeto. Mas o que vamos fazer hoje não é mudar isso. Estou bem com o padrão. Vá para a guia Projeto, clique em alterar o horário de trabalho. E eu queria anúncio e quero adicionar um feriado. Então, digamos que 17º seja feriado do Dia MLK. Então clique nessa data específica e você pode dar qualquer nome. Portanto, é melhor dar o nome real do feriado e pressionar Enter. Então agora, se eu clicar em Ok, você notará que, em vez de terminar o projeto no dia 17, projeto agora sabe que 17º é um feriado e, portanto, levou a data para mais um dia. Então, desta forma, você pode incorporar todos os feriados até amigo, digamos, você sabe que alimentado pelo feriado de março AC. Então você vai para FEV, março e adiciona esses feriados. Então, o próximo feriado para nós nos EUA é o Memorial Day no dia 25. Então eu posso clicar no dia 25 e adicionar esse Memorial Day. Então, agora isso é adicionado. Portanto, sempre que o projeto calcula qualquer duração entre esses dois dias, ele ignorará os dias em que os marcamos como feriados. Então isso é ótimo. Então isso é feriado geral. E como adicionamos um calendário de recursos? Então, a qualquer momento, digamos que se eu adicionar uma tarefa e atribuir um recurso a ela, o projeto atribua automaticamente um calendário de recursos. Então, se eu for ao recurso e examinar minha planilha de recursos, deixe-me verificar aqui e ver a planilha de recursos. Não tenho nenhum recurso agora porque não atribui nada. Então, se eu voltar para o gráfico de Gantt, digamos que as tarefas da semana dois devem ser feitas pelo Nick. Desculpe, coluna errada. Tinha que adicioná-lo em recursos, então vou adicionar o Nick aqui. E como a segunda semana prossegue após a primeira semana, você pode adicionar um antecessor aqui digitando o número dois lá que, após a conclusão dessas duas tarefas, iniciamos. Então, agora, se eu for para a planilha de recursos da equipe e olhar para isso, você tem um recurso padrão aqui. Agora, o calendário para esse calendário padrão de recursos. Então, se você quiser mudar isso, tudo o que você pode fazer é voltar ao projeto, mudar o tempo de trabalho. Agora você verá que é um calendário para o Nick. Por padrão, o que quer que adicionamos ao calendário no calendário padrão, por exemplo, adicionamos o Dia MLK que falso porque estamos usando isso como o calendário base. Agora vamos dizer que Nick está tirando férias no dia 18 em 19 e ao longo dessa semana, digamos de 18 a 21. Você pode dizer PTO. Agora, se você atribuir qualquer tarefa ao pescoço, e se voltarmos ao projeto, vamos voltar e Gan Chad, você pode ver que, mesmo que essa primeira tarefa termine em 18, nada começa até o dia 24. Porque agora estamos usando um calendário de recursos para pescoço e ele sabe automaticamente que Nick está de férias durante essa semana. E, portanto, ele empurra para fora. É isso. E digamos que na segunda semana temos outra pessoa trabalhando no mesmo novo recurso. Digamos que ele também trabalhe em dois dias e mesmo antecessor. E digamos que o nome dele seja Sam. Para ele, começa no 19 porque se você olhar para o calendário Sands e ir para Project e clicar em mudar horário de trabalho e olhar para o calendário de areias. Sam não tem 18 a 21 como feriado. Por isso, tudo o que adicionamos para Nick só afeta o Nick e não o Sam. Essa é a vantagem de usar um calendário de recursos e como podemos adicionar feriados e folgas ao projeto MS. Dessa forma, quando você está planejando o número de dias ou a duração é mais precisa. Espero que isso ajude. E se você gostou deste vídeo, dê uma curtida, e eu te vejo no próximo. Tome cuidado. Tchau. 25. Rastreamento e execução de projetos: Tudo bem, então agora concluímos todo o planejamento e agora é a fase empolgante em que estamos executando o projeto. É emocionante porque na maioria das vezes nada que planejamos na fase de planejamento é executado de acordo com o plano. Se você já planejou uma noite de cinema com seus amigos ou se tiver uma consulta médica. Às vezes você vai se atrasar porque as coisas não deram certo, são as coisas não correram como planejado. Em projeto grande ou pequeno. Isso vai acontecer em algum momento. Como gerente de projeto, é quando você é força entra em jogo, quando as coisas são descarriladas. É quando você tem que organizar repensar e reestrategizar tudo. Se for tudo conforme o planejado, você não precisa de um gerente de projeto. Você pode facilmente dar a outra pessoa e executar o plano. É por isso que é extremamente importante entender que as coisas não funcionarão exatamente como planejado. Você pode sempre ter que ajustar e bordas como ego. E nesta seção veremos a metodologia Waterfall e Agile. E dentro do Agile Scrum e Kanban para ver o que precisamos rastrear, como o rastreamos e como nos ajustaríamos se algo não correr como planejado? Agora vamos mergulhar nos detalhes CSO, vamos falar primeiro sobre a cachoeira antes de saltar para o ágil. E então, dentro do Agile, vamos dar uma olhada na estrutura Scrum e Kanban e veremos como rastreamos e bordas nessas áreas. A única coisa importante a lembrar quando falamos sobre a execução do plano do projeto é que o que criamos anteriormente no planejamento é uma planta de cronograma detalhada. Então isso não é tudo. Quando você pensa em plantas, existem várias plantas que existem. A maioria enfatiza dado ao cronograma e ao custo. Porque se você se lembra nos capítulos iniciais, essas são as restrições triplas de um projeto. Se o escopo, o custo ou o cronograma forem alterados, isso afetará o projeto antes que qualquer outra coisa dê errado. Então, se você olhar para as plantas aqui, temos plano de controle de mudanças, plano gerenciamento de comunicação, iteração de custos, compras, plano de gerenciamento de projetos como um plano de qualidade geral, plano liberação , plano de requisitos , plano de recursos e planos de risco. Então, todos eles fazem parte do planejamento quando planejamos anteriormente, analisamos a avaliação de risco. Então, com base nesse risco, qual é o plano para mitigar, exceto ou transferido que você tem que pensar em todo esse plano no fundo da sua mente. Mas 99% das vezes, como gerente de projetos, só olhamos para o cronograma, que é o plano de projeto que construímos para a cachoeira. Ou se você estiver olhando para o ágil do que o backlog e como podemos concluir esses itens de backlog. Esse é puramente o escopo e a linha do tempo. Mas lembre-se de que sempre há um custo, escopo, recurso humano e todas as outras coisas listadas aqui nas quais você precisa prestar atenção. Se você tiver que enviar comunicação em determinado intervalo para as partes interessadas e outras equipes dependentes. Se você não tem um plano, então você vai perder isso. É por isso que todas essas plantas são muito críticas. Você pode não ter um MS Project Plan detalhado ou no quadro Agile, mas você definitivamente precisa ter um lugar onde você possa fazer login nos diferentes itens de ação que você precisa tomar para concluir a mudança ou comunicação ou aquisição, tudo isso. Deixe-me dar um exemplo de plano de gerenciamento de comunicação. Se você está planejando implementar algo em ambiente de previsão ou controle de qualidade, pense nisso. A organização pode ter perguntas e respostas maiores. Se você quiser fazer alguns testes, talvez queira atualizar esse ambiente de controle de qualidade com os dados de previsão mais recentes. Se você não planeja essa comunicação amigo, talvez você não obtenha o QA e o Wyman para si mesmo porque pode haver outros projetos fazendo alguns testes e tudo mais. É por isso que é importante para a Sunday Communication antes do tempo e diga, ok, neste momento teremos uma atualização de controle de qualidade. Precisamos fazer a atualização de controle a partir da previsão com base nesse estado. E precisamos fazer o teste e concluiremos o teste naquela janela de um ou dois meses. E então você pode atualizar as perguntas e respostas de volta. Ou, se você quiser um novo ambiente completamente, então você precisa planejá-lo. Então você pode ter que adquirir recursos adicionais, espaço ou outro ambiente, que inclui planejamento de gerenciamento de compras. Você precisa simplesmente, ele não pode simplesmente sair e começar a usá-lo. Talvez seja necessário solicitar um novo ambiente seja construído completamente. Lembre-se de todas essas coisas pediram para serem atendidas em algum lugar em seu planejamento ou na fase de execução porque não estará no escopo ou no plano de gerenciamento de cronogramas que construímos em MS Projeto. Então, digamos que você tenha tudo isso e vamos nos concentrar no cronograma por um tempo porque o custo de agendamento são as principais coisas que, se não for no caminho certo, seu projeto vai descarrilar. Então, como rastreamos todas essas atividades que você precisa usar como medir. Então, eles podem ser indicadores-chave de desempenho. Eles podem ser métricas de entrega, previsão de valor comercial de recursos, todos eles combinados juntos, você pode pensar como algo que você se comprometeu com ou a partir do plano do projeto. Você acha que até o final do mês um, você pode entregar essa coisa. E se isso não estiver acontecendo até meados do mês, se o 50% dessa entrega ou aquele componente não estiver completo, então você pode ter a sensação de que ele vai perder o alvo completando por fim do mês. É assim que você acompanha cada item, seja o custo da programação ou o escopo, você observa o progresso e vê se consegue atingir o alvo. Digamos que sua janela seja de um mês para entregar algo. No dia 10 do mês, você deve pelo menos completar 1 terço dessa entrega. Se a equipe não tiver completado 1 terço, você poderá ver que as coisas vão escorregar um pouco. Às vezes, a equipe pode compensar durante a execução, mas novamente, você faz um checkpoint no dia 15. Então, naquele momento, pelo menos 50% das coisas devem ser concluídas. E se a equipe não tiver concluído, talvez seja necessário reavaliar e ver se você pode realmente atender ao cronograma de entrega até o final do mês. E o importante aqui é novamente a comunicação e manter a equipe e as partes interessadas engajadas durante todo o processo. Você teria que enviar relatório de status toda semana para compartilhar o status e levar as partes interessadas a saber onde estamos. Se você acha que estamos atrasados e vamos fazer as pazes e estar no caminho certo até o dia 20. Em seguida, comunique que você tem mantê-los a par com toda a comunicação. Porque a última coisa como gerente de projeto que você quer é no dia 30, você vem e diz que, a propósito, perdemos uma entrega, isso não é aceitável. A única opção é que você tem que manter como as coisas começam a escorregar, você tem que comunicar isso e ver se precisa escalar e obter ajuda adicional. Para mim, liderança sobre você. Eles estão olhando você como um gerente de projeto para comunicar a eles qual ajuda você precisa ou de que ajuda sua equipe precisa. Certifique-se de que você está rastreando e seja qual for essa data do projeto, você está se comunicando isso de forma transparente para que todos estejam cientes do status atual do projeto. Portanto, tenha isso em mente quando você estiver se comunicando. E como coletamos, como coletamos os dados? Dissemos que vamos olhar no dia 10 do mês e ver onde estamos fazendo. Portanto, existem várias maneiras de coletar todos esses dados, mas principalmente essas coisas surgirão no Padrão Diário ou durante as reuniões de status. Então, esses são os dois aqui em cima, que é o stand-up diário e a reunião de status. É aí que você está coletando e entendendo o desempenho do projeto e vê se algo precisa ser ajustado. Portanto, lembre-se também de que, durante a fase de execução do projeto, não se trata apenas de coletar e relatar status. Isso também é contínuo. Outras áreas de melhoria que fazemos à medida que o projeto avança, refinamento de backlog. Então, quando fizemos o planejamento inicialmente, poderíamos ter colocado em todas as coisas que estávamos cientes na época. Mas à medida que a equipe começa a fazer progredir no projeto, pode haver outras coisas que descobrimos e precisamos priorizar novamente e adicioná-las ao backlog. Portanto, essas são as reuniões de refinamento da lista de pendências se algo precisar ser priorizado novamente ou adicionado de volta à pendências ou retirá-lo da lista de pendências. Você precisa se certificar de que essas discussões aconteceram na reunião de refinamento de backlog ou priorização de backlog. A próxima é a videoconferência. Conferências beta que, se você tiver que comprar um produto, por exemplo, você tem um software que precisa como parte do projeto Testing. E há vários fornecedores que estão fornecendo essa ferramenta. E você não sabe qual deles você tem que comprar. Então, se for cachoeira ou ágil, você faria uma prova de conceito ou fará uma conferência de licitantes para entender qual é o preço que Kenny oferece isso no orçamento do seu projeto e uma demonstração e tudo isso para entender com qual fornecedor você deve ir e comprar o produto. Depois, há placa de controle de mudança. Portanto, na maioria das vezes, à medida que o projeto progride, as coisas podem não correr como planejado. Às vezes, você pode estar ficando sem orçamento ou tempo. E a maior parte da organização teria um limite de dez a 15%. Então, digamos que você tenha um projeto de dez meses e esteja planejando gastar 100 mil para o seu projeto. E no mês um, idealmente você deveria ter gasto 10 mil. E no MnO2 próximos 10 mil se o cronograma for tal que todas as entregas acontecem todos os meses igualmente. Nesse exemplo, digamos que no final do mês um, em vez de gastar 10 mil, você já gastou 20 mil. Você está acima do orçamento em 10% adicionais na maioria das vezes que acionaria o painel de controle de alterações. E você precisa. Solicitações de orçamento adicional ou forneça uma explicação para o painel de controle de alterações enquanto você estiver acima do orçamento ou abaixo do orçamento. Então, esse é um exemplo. Padrão diário se você estiver executando um projeto ágil, então, obviamente, o standup diário é uma obrigação. Então é aí que eles se juntavam e discutiam o que planejam fazer para o dia, o que fizeram ontem, e se há algum impedimento de que eles precisem de ajuda de você como um projeto manager, ScrumMaster, outras opções, Iteração, Planejamento, revisão de iteração, essas podem ser opcionais, pode não estar acontecendo. A outra importante é a reunião inicial, e isso acontece o tempo todo. Então, sempre que um projeto começa, então você tem que ter uma reunião inicial para estabelecer a equipe e anunciar ao mundo em mais pesado em frente com isso. E nos comprometemos com isso. Este é o nosso plano e é aqui que vamos ser entregues. Se você tiver coisas adicionais, informe-nos agora, assim que começarmos, elas serão priorizadas de acordo mais tarde. Do lado direito, há coisas que acontecem no final do projeto, ou seja, lições aprendidas. Mas se você estiver executando projeto em cascata ou projeto ágil, o tempo pode ser diferente. Para a cachoeira, as lições aprendidas aconteceram no final do projeto. E para projetos ágeis, as lições aprendidas são a reunião retrospectiva após cada sprint. Então, no final do sprint ou no final do mês, se você estiver executando Kanban, você se reuniria e discutiria com a equipe para entender o que correu bem, o que não correu bem e o que mudanças que a equipe precisa fazer para fazer algumas melhorias e atualizar o progresso do projeto e outras coisas que listamos aqui são a fase de fechamento do projeto. Obviamente, no final do projeto, você não faria isso para a fase de fechamento. É considerado como uma execução de projeto. E outras coisas são status e reunião do comitê de direção. Portanto, pode haver alguns projetos que são os cinco principais projetos importantes para a organização. E para esses projetos eles serão comitê de direção e seu projeto precisa ser apresentado mensalmente para aquele comitê de direção, quem for o corpo disso, será partes interessadas fora de um projeto, aqueles que estão interessados na conclusão do seu projeto. Portanto, eles são uma agenda maior pode ser atingida ou suas metas maiores do programa podem ser atingidas. Então, essas são as outras reuniões que você precisa prestar atenção durante a execução do projeto. E os outros itens que você precisa gerenciar de perto além do plano do projeto, são seus registros e registrados. Existem diferentes logs na fase de execução do projeto que você precisa acompanhar. Esses estão listados aqui. Então, o importante aqui é o log alterado. Portanto, sempre que ocorrer um gerenciamento de alterações ou uma solicitação de alteração, você terá que registrar essa alteração. Por exemplo, digamos que você tenha começado com um projeto de site no nosso caso, para vender modelos. E agora digamos que o stakeholder voltou e disse, ok, a propósito, precisamos adicionar, além do modelo, também precisamos adicionar talvez um módulo de treinamento. Então, esse é um novo produto que você precisa pensar. Então isso significa que há uma alteração no escopo e isso é uma solicitação de alteração. Portanto, você precisa preencher o formulário de solicitação de alteração para solicitar alterações adicionais de recursos na linha do tempo, orçamento adicional, se necessário, tudo isso. Então, quando essa alteração aconteceu, então você precisa registrar essa alteração no log de alterações para que você tenha um controle de todas as alterações que aconteceram depois de definirmos a linha de base. O próximo importante é, obviamente, o registro de problemas. À medida que avançamos na execução do projeto, sempre haverá problemas. Às vezes, no novo usuário tem que ser ingressado e , em seguida, não temos licenças ou coisas assim. Então, depois que ele se junta, ele não consegue fazer o trabalho, então isso se torna um problema. Ou, em alguns casos, precisamos enviar um arquivo para o local do FTP e não temos as credenciais, então temos que trabalhar com isso para a equipe SFTP, equipe FTP segura para obter as credenciais e definir isso para o projeto. Então, qualquer coisa que não tenhamos planejado ou não pensado durante a fase de planejamento, essas coisas vamos voltar e nos morder durante as execuções e, na maioria das vezes isso se torna um problema para a equipe do projeto até que ela seja resolvida nela. Para manter isso nos registros de problemas e rastrear e atribuir um proprietário. Vamos dar uma olhada no registro de problemas e como coletamos o problema, como o rastreamos, como monitoramos o progresso e tudo isso. Na próxima lição, quando falamos de carro de status , os outros registros que são comumente usados no projeto são o registro de risco. Na fase inicial de planejamento, analisamos a avaliação de risco para que você possa reutilizar esse registro de risco aqui. E agora temos mais rastreamento do risco e verificamos se o item de ação atribuído ao proprietário que foi concluído ou não. Todos os outros logs aqui são registros gerais que você pode ou não usar em um gerenciamento de projeto quando estiver gerenciando seu projeto. Mas estes estão aqui para sua referência. E, claro, se você estiver executando um projeto ágil, você usará o backlog porque isso é o seu escopo ou requisito. Enquanto no projeto de cachoeira, não há backlog. É mais o documento de requisitos de negócios e o escopo e as coisas são rastreadas e capturadas nisso. Então o último é o registro de partes interessadas que depende do tipo de projeto que pode ou não ser relevante. Mas na maioria das vezes o que fazemos é criar uma matriz C, onde listamos todas as diferentes partes interessadas e entendemos qual é o papel deles no projeto. Racy representa responsável, responsável , consultado e informado. Raci é onde saberíamos quem é responsável e quem é responsável. Por exemplo, se você estiver fazendo um projeto de desenvolvimento de sites de desenvolvimento como gerente de projeto, eu sou responsável, mas para fazer o trabalho real de projetar a página da Web, o desenvolvedor, a página da Web seria responsável. Portanto, o RACI é um lugar onde nós claramente traçamos quem é responsável, quem é responsável e quem deve ser consultado e informado durante a execução do projeto. Assim, isso pode ser alcançado através do registro de partes interessadas. Vou colocar um link na descrição abaixo, onde você pode baixar um modelo para registro de partes interessadas e todos esses registros diferentes aqui e também a matriz RACI e como ela se parece. Essa é a fase de execução do projeto. Então, novamente, lembre-se de que você precisa ter certeza na fase de execução, que o que planejamos está progredindo conforme planejado. E se não, como o rastreamos e como o denunciamos às partes interessadas? E, se necessário, invoque, altere solicitações para obter orçamento adicional e estender a linha do tempo e coisas assim. Tudo bem, então isso resume a execução do projeto. Isso fará mais sentido quando fizermos as práticas e analisarmos plano do projeto e o registro de problemas e riscos nesta reunião de status. Então, normalmente, quando você executa a reunião de status é quando você tem a equipe, você vai em frente e começará a atualizar o plano do projeto, a porcentagem de conclusão, atualizar o problema e o risco e tudo isso coisa. Falaremos sobre tudo isso em detalhes, onde você entenderá mais como rastrear e como você identifica problemas e atrasos durante a chamada de status ou stand-up diário? Tudo bem, vejo você na próxima aula. 26. Chamada de status e relatórios: Tudo bem, então nesta lição vamos dar uma olhada em como acompanhar o progresso do seu projeto. E na maioria das vezes isso é feito no stand up diário se você estiver executando projetos ágeis ou em uma chamada de status semanal ou quinzenal quando você estiver executando projetos ágeis. Uma das ferramentas que venho a amar recentemente é o OneNote. Se você estiver usando produtos da Microsoft em sua organização. Então você teria um nó com certeza. E a razão é que é muito simples e, no entanto, muito poderoso. E você pode organizar coisas, especialmente se você estiver executando vários projetos. Então deixe-me compartilhar minha tela e mostrar o que eu amo neste OneNote e como você pode organizá-lo. E então vamos dar uma olhada em como normalmente um relatório de status é executado e qual é o benefício de ser executado dessa maneira? Então, como você pode ver aqui, por padrão, ele automaticamente tem seções e páginas. Assim, você pode organizar as coisas de uma maneira melhor. Então, se você tiver um a um com seus stakeholders e gerentes, novamente, adicione isso como uma seção e diga Reuniões individuais. E qualquer coisa relacionada a isso, você pode adicionar essas páginas aqui. Então, às vezes você pode querer se encontrar apenas com a equipe. E digamos que neste caso, você está se encontrando com Sam para entender se há alguma dificuldade no que ele está fazendo. Às vezes você precisa se encontrar com o CIO ou outra pessoa para entender o que eles precisam do projeto. Então, não entra em outras coisas que você tem outras seções. Então, ele permanece dentro dessa reunião individual. O que vamos fazer é aqui que temos projeto, temos aqui é que vamos adicionar uma seção para o site do modelo do projeto. Então, esse é o nosso projeto. E o que podemos fazer é ter uma página aqui e, por padrão, há uma página sem título. Então, vou fazer uso disso e vamos chamá-lo de status semanal. E você pode usar qualquer David que isso aconteça todas as sextas-feiras ou todas as segundas-feiras, qualquer dia que você possa escolher naquele dia. Então, neste caso, isso acontecerá todas as segundas-feiras. Então eu vou dizer que isso acontece em terceiro de janeiro se você tiver reuniões, então você sempre pode inserir detalhes de uma reunião aqui. Portanto, se houver um calendário que vai para a equipe quando você, em vez disso, os detalhes da reunião. Neste momento eu não tenho nenhuma reunião, então é por isso que você não vai vê-lo. Caso contrário, quaisquer que sejam os participantes que temos nessa reunião os convidam. Vamos subir aqui automaticamente. Se não acontecer, então sempre há uma maneira. Se esse não for o caso, você sempre pode adicionar algumas caixas de seleção aqui. Então, a melhor maneira de fazer isso é em vez de balas, pode apenas dizer para fazer. E você pode adicionar pescoço San Joe, quem quer que seja parte de uma equipe, podemos apenas acrescentar isso. E quando eles Jain , então você pode fazê-lo. Marca de seleção aqui. Essa é a lista de participantes. Então você pode chamar isso como participante. Suba e exclua, e digamos que os participantes. E se você quiser, você pode simplesmente ousá-lo para que você saiba que é uma seção. E a próxima é a agenda. Você deseja revisar riscos e problemas, revisar qualquer solicitação de alteração de alteração. E a primeira coisa que sempre faço quando tenho status é o fluxo de comunicação, nossas comunicações de upstream ou downstream. Então essa é a agenda. E, em seguida, faremos problemas, itens de ação, discussões gerais. Vou deixar você saber por que essas seções são importantes. Porque você só precisa criar os e então você pode reutilizá-lo toda semana. Em problemas, sempre insiro uma tabela. Então você pode copiar a pasta no excel ou coisas assim com bastante facilidade. Portanto, você terá número de série, problema, nome, detalhes do problema, proprietário, data de vencimento. E provavelmente a outra coisa é que você deseja adicionar o status. Portanto, se for um status aberto, são problemas. Risco. Você pode novamente ter a mesma coisa aqui. Agora eu preenchi a coisa toda, então este será o meu modelo. Toda vez. O que acontece é que eu apenas mantenho isso como um modelo para que eu possa simplesmente copiar e dizer copiar isso e adicionar uma página. E posso chamá-lo de modelo de status S que nós, toda vez que nos reunimos toda semana, você pode simplesmente atualizar ou copiar esse modelo e renomeá-lo para outra coisa. Então eu tenho um modelo de status aqui, então isso vai por cima. Então eu tenho uma reunião semanal. Terceiro, tenho uma reunião semanal na caneta. Digamos que estou na terceira reunião de janeiro que tenho que fazer é quando eu fizer o compartilhamento de tela, vou fazer isso como tela cheia. E então. Não se distrai nenhuma outra seção ou qualquer outro projeto. Todos os participantes veem aqui é esta página. E a melhor coisa aqui é quando as pessoas se juntaram, então eu posso dizer: Ok, Oi Nick gigante, Sam Jain. E à medida que as pessoas se juntam, posso atualizar isso na agenda. Foi assim que eu o estruturou porque uma vez as pessoas começam a ingressar e como gerente de projeto, você pode ter mais informações que o membro da equipe não teve. Então você tem que comunicar esse fluxo a jusante do que você tinha de sua liderança para a equipe do projeto. Então eu começaria com esse fluxo de comunicação e agradecerei todos por se juntarem à chamada e, em seguida, começar a reunião dessa maneira. E o próximo item aqui é a revisão do status do projeto. Antes de entrarmos nisso, perguntarei se há alguma atualização ou algo dito que a equipe queria trazê-la antes de saltarmos para os detalhes. E se houver algo crítico, adicionarei às discussões do tópico e adicionarei os detalhes. Então isso vai sob discussão geral e dessa forma você está comunicando tudo. E a parte boa é porque está em uma página e você tem uma única página para cada reunião. Ao longo do projeto, você sempre pode voltar e ver qual ação, que risco, quais decisões foram tomadas e em qual reunião. Então, algo que é realmente fácil de rastrear com a ferramenta OneNote. Agora vamos dar uma olhada na revisão do status do projeto aqui. Estamos revisando o status. Então, a melhor maneira de fazer é normalmente, vou ter os pontos marcados são as coisas que precisam ser concluídas esta semana. E então vou perguntar sobre o status na reunião. Não vou abrir o plano do projeto. Vou deixar você saber como eu faço tipicamente. Então eu vou para o projeto que criamos durante a fase de planejamento, depois qualquer coisa que seja devido para aquela semana. E preciso atualizar isso com as informações do projeto. Então é assim que você o acompanha. É assim que você sabe se está adiantado ou atrasado. Então, digamos que a reunião esteja no OneNote. Se eu voltar aqui, esta é a reunião para o VQ de 13, que significa que depois que essa semana terminar, isso vem hospedando esta reunião. Então, qualquer coisa que esteja pendente para esse 13 para o 107, é aí que eu quero obter as informações. Então, obviamente, vou adicionar uma coluna aqui e chamá-la como coluna de inserção. E dias de pessoa concluídos. Quando a equipe passar pela reunião de status do projeto, perguntarei a eles sobre o status e é assim que o rastreio. Como estou de volta e pergunto, finalizamos o escopo, o que é gasto? Está feito? Então D pode voltar e dizer: Sim, está quase pronto. Estamos 90% lá. Você precisa finalizar certas coisas. Então, obviamente, então eu posso vir aqui e dizer, ok, estamos 90% acabados. Então, como sabemos que esse 90% é bom ou ruim? Digamos que estamos na sexta-feira e eu a entrega deve ter 100%. Então é aí que entra o rastreamento. Então você pode adicionar uma coluna aqui chamada status. Você verá indicadores de status. Então, qualquer coisa que esteja no vermelho, esses são os que estão atrasados porque está verificando a data atual. Então, a partir de agora, tudo isso em Jan está marcando como atrasado. Isso não está concluído, diz que a marca de marca diz que está dentro do cronograma. O projeto está assumindo que está dentro do cronograma porque a data de término está no Fed e não em janeiro. Então, qualquer coisa em janeiro, está marcando como tarde. Então, uma maneira de ver isso com precisão, é bom projetar informações e definir a data atual como, digamos sétimo. Então, se você estiver olhando para o projeto a partir do sétimo, ele só olhará para as coisas que devem ser concluídas antes do sétimo e destacá-las como thread. Essa é uma maneira fácil de entender visualmente, porque se for um projeto grande, é difícil passar por cada data e ver que estamos adiantados ou atrasados? O projeto fará isso automaticamente fazendo o indicador de status. Este é um indicador de status interno no projeto MS. Mas o que acho difícil é que às vezes eu quero saber que algumas coisas como aqui, onde diz que isso está no caminho certo porque o sétimo não é feito porque atualizamos os dados do projeto sete. Então, literalmente, o projeto está pensando no final do dia sexta-feira para concluir isso, 90% é bom. E se fosse 80% , ainda diz que é bom. Há algum limiar aqui. Então, quando é 70% só então ele me mostra como vermelho ou não está no caminho certo. Então, em vez de projetar determinar se está no caminho certo ou não, normalmente tenho uma fórmula manual integrada que posso usar aqui. E posso ter colunas indicadas pelo status que eu quero fazer. Então, por exemplo. Se eu quisesse saber alguma coisa que está chegando nas próximas duas semanas, mostrei todas essas tarefas como um semáforo amarelo nesta coluna. Eu posso fazer isso. Então, eu abordei isso de forma detalhada no meu blog e no meu site do YouTube. Então vou colocar esse link na descrição aqui, porque você pode apenas seguir isso se quiser fazer isso. Mas isso é apenas um exemplo de como rastreamos com base no que a equipe do projeto relata. Eles disseram que está 90% completo. E se eles estiverem confiantes de que até o final da sexta-feira eles podem completar os 10% restantes. Ou até segunda-feira, pelo menos eles tomaram um 100% completo, então isso é bom o suficiente. Você não precisa denunciar isso como um problema. Mas vamos salvar a equipe do projeto no status chamado ASA que atingiu, aliás, não concluímos. Está apenas 40% concluído. E a razão pela qual não conseguimos concluir isso, porque qualquer problema XYZ, é quando você entra aqui e diz, ok, então temos um problema agora porque um escopo, então esse é o problema, escopo indefinido. Diremos que o escopo é indefinido e os detalhes do problema é que o BA não está disponível para concluir o requisito e, portanto, o escopo não finalizado. Esse é um problema que alguém tem que tomar uma ação. Portanto, neste caso, obviamente, como gerente de projeto, você deve tomar essa ação. E você talvez tenha dois ou três dias para concluir isso porque, caso contrário o projeto está saindo do caminho certo. Então você atribui uma data de folga, seja lá o que for viável. Então, vou adicionar talvez o 13º. E então veremos que o status está aberto. Então, uma vez que você tenha isso, então você teve o problema. É assim que você faz a chamada de status ou o padrão e identifica quais problemas a equipe do projeto está enfrentando. E com base no que eles estão relatando o Novo entenda que há um problema ou não. Da mesma forma, há algo, digamos, uma próxima tarefa no plano do projeto. E digamos que não seja agora, mas existe o risco de que , na próxima semana, no dia 14, se os BAs não estiverem disponíveis, então potencialmente a mesma coisa, bom, ainda mais descarrilar o projeto. Você pode acrescentar que, como o BA de risco pode não estar disponível para trabalhar no projeto e no proprietário, você pode atribuir isso e você precisa fazer isso rapidamente antes do dia 14, antes dessa data de vencimento, você tem um risco e um problema. Este é apenas um exemplo simples para mostrar como essas coisas são construídas durante a fase de execução. E o item de ação seria sobre você dizer que se reunir com títulos ou obter recursos adicionais feitos com o patrocinador antes do tempo para discutir sobre isso e depois ter alguma resolução. Portanto, esse é um exemplo simples apenas para que você entenda como gerencia o controle, coleta de informações, relata riscos e problemas à sua liderança ou seu patrocinador e tudo isso. Portanto, essa é uma maneira muito eficaz. E o OneNote realmente ajuda porque todos têm acesso a um nó. E no final da chamada, você pode apenas Controlar, selecionar e Controlar C. Coloque os itens de ação em uma tabela, em um e-mail ou você pode enviar esta página inteira. Ou se você tiver equipe e coisas assim, você tem a opção de copiar o link disso. Então deixe-me mostrar-lhe como fazer isso. Saia da tela cheia. Você pode simplesmente dizer aqui compartilhado e ele gerará um link. Nesse caso, não fiz login no MS Team. É por isso que está me dando um erro. Mas, caso contrário, você obteria um link que você pode compartilhá-lo. E então você pode simplesmente copiar colar apenas os itens de ação de pessoas que identificaram que tem uma ação e , em seguida, enviá-la. Quando você fizer a próxima semana reunião. Se ainda houver itens abertos daqui, obviamente você pode copiar colar e colocar isso nos itens estão tabelas aqui. E você pode começar a perguntar sobre o status nisso. Portanto, esse é um processo contínuo até que você feche todos os problemas ou desconexão. Então, isso é tudo sobre a captura de dados. E agora temos que ver como relatamos o status final para sua alta gerência, seu patrocinador ou outros. Então, para isso, é um simples PowerPoint de uma página. E normalmente o que fazemos é ter um PowerPoint criado. Certo. Agora, coletamos todos os detalhes durante a chamada padrão do relatório de status se for ágil onde e agora é hora de enviar o status para o patrocinador da gerência superior ou outras pessoas no projeto. Portanto, este não é o mesmo exemplo, mas apenas para dar a você como o modelo de status se parece no topo, é bom ter um resumo do projeto porque quando você envia o status, não todos perguntaram perto do projeto. Portanto, o resumo do projeto é um exemplo rápido ou maneira de QC de lembrá-los do que se trata esse projeto. Então você lista todas as pessoas-chave. Então, neste caso, patrocinador, gerente de projetos. E se você tiver que listar algumas outras partes interessadas, poderá adicionar uma coluna e adicioná-la. Você também adiciona a data de início e término do projeto para que quem estiver recebendo esse modelo, esteja em um nível alto qual é a linha do tempo do projeto. E, em seguida, se houver algum ID de projeto atribuído pela organização. O orçamento geral, o gasto acumulado do ano e quando você planeja entrar ao vivo. Portanto, essas são informações realmente críticas que tipicamente associadas ao projeto. E se houver outra coisa que você queira adicionar, você sempre pode personalizá-lo. Mais uma vez, o OneNote e o PowerPoint. Vou adicionar o link na descrição abaixo para que você possa baixá-lo se precisar consultar ou criar um para si mesmo. E normalmente o que queremos fazer em um relatório de status é que você pode pensar nisso como um bloqueador completo que tem quatro seções. Na primeira seção no canto superior esquerdo, você tem realizações. Então é aí que você está dizendo que o que a equipe alcançou durante esta semana e liste todos aqueles nessa seção. E nos próximos marcos, você pode listar todas as coisas que acontecerão nas próximas duas semanas ou quatro semanas , dependendo quais informações ou quão preciso você pode prever isso. Você colocou isso aqui. E quaisquer problemas e riscos que você precise de ajuda com esse patrocinador ou qualquer pessoa para quem você está enviando este relatório, então destaque esses riscos e problemas para que eles saibam que risco são problemas com os quais você precisa de ajuda e como eles podem ajudar a resolver isso. Se houver itens de ação do projeto com base na reunião de status, adicione isso nos itens de ação. Então, quando você faz isso no mesmo formato de coluna que tínhamos no OneNote para o PowerPoint e fica muito fácil de fazer isso. Esta página é boa o suficiente, mas se você quiser, você sempre pode adicionar uma página adicional como marcos do projeto. Dessa forma, você pode listar as diferentes tarefas e dar ao patrocinador ou quem quer que você esteja enviando isso para uma imagem completa. E talvez você possa adicionar uma linha em algum lugar aqui e mostrar esse SLI hoje para que assim eles saibam que tudo bem, hoje por aqui. E queremos terminar aqui, certo? Essa é uma outra ferramenta ou modelo que você precisa enviar no final do bico ou diariamente ou uma vez em um mês, dependendo da exigência do seu projeto. Portanto, essas são as principais coisas que temos nesta chamada de status e nos relatórios de status. E espero que essas ferramentas, você possa usá-lo exatamente assim ou você pode inspirar nisso e desenvolver seus próprios modelos e ferramentas para acompanhar o progresso do seu projeto. A principal coisa é que, durante a execução, você pode esperar problemas e como lidar com isso, como você obtém as informações sobre o problema e como você o resolve, como você faz um brainstorming e enfrenta com a equipe. Esse é um componente-chave que você faz como gerente de projeto. E você seria muito bem sucedido se fosse organizado. E você pode rastrear os problemas e abrir itens de uma forma que mostrei aqui. E o que faremos na próxima lição. Vamos dar uma olhada diferentes modelos do Excel para rastrear o item de ação, o registro de problemas e o entupimento de riscos. Dessa forma, se você precisar baixar isso e usá-lo para seu projeto, você pode fazer isso. Tudo bem, veremos na próxima lição. 27. Log de decisão de ação de risco: Tudo bem, então, nesta lição, vamos dar uma olhada em todos os registros e ações de problemas de risco alterar todos os registros e registros que precisamos para rastrear o aspecto da execução do projeto. Então deixe-me pular para a tela aqui. Portanto, temos o primeiro registro de ações. Então eu combinei todos os registros diferentes em várias guias. Dessa forma, é fácil para você baixar, mas se você quiser mantê-lo como arquivo separado, você pode fazer isso. Portanto, temos o registro de ações, o log de problemas, o log decisões, o registro de alterações e, em seguida, o registro de riscos. Um registro de risco, se você se lembrar, isso é exatamente o que usamos durante a fase de planejamento do projeto, que possamos continuar a usá-lo porque, à medida que executamos, podemos ter riscos adicionais identificado e você pode começar a capturar isso aqui. Registro de ações novamente, é a mesma ferramenta simples que usamos. E se você se lembrar do exemplo anterior ou da lição anterior em que identificamos problemas e riscos durante a reunião de status do projeto. Este Excel é basicamente copiar colando esses itens identificados no respectivo log. Qualquer coisa que identificamos durante a reunião de status do projeto como problemas que estão sob o log de problemas aqui. Então, se eu for para a guia Log de problemas, identificamos um problema que temos escopo não definido porque o ba o analista de negócios que não estava disponível para concluí-lo e quem tem a ação e qual é o status no Excel, tem a opção de filtrá-lo. Portanto, essa é a vantagem de transferir de um nó para o excel porque você pode executar relatórios que você pode rastrear e ele pode ter dados, filtro de dados e tudo mais. Assim, você pode personalizar de uma maneira fácil para você gerenciar isso. Então esse é o registro de problemas aqui. Se eu voltar, também identificamos um risco de recursos. Então, podemos adicionar isso ao nosso registro de risco para que eu possa simplesmente copiar isso. Volte para o registro de risco e diga que temos uma lista adicional que identificamos. E isso é para recursos. E você pode começar a digitar todas as cópias nos detalhes aqui. Então, diríamos recurso. E a probabilidade de isso acontecer talvez seja de alta probabilidade. E o impacto pode ser médio ou baixo a médio. E o dono que identificamos aqui é Nick. E podemos acrescentar isso e precisamos mitigar isso e identificar alguém da equipe que possa completar o requisito. E a data de vencimento que temos aqui é 114. Assim, você pode adicionar isso e até que esteja fechado, ele ainda está aberto. Então é assim que você transfere de uma reunião de status para um registro. Portanto, este é um exemplo rápido por que mantemos bloqueios diferentes no Excel, porque você pode adicionar e excluir e fazer um filtro e todas essas coisas boas. registro de alterações aqui é agora que precisamos adicionar um módulo de treinamento ao projeto que seja um escopo adicional. Então, a ação aqui é obter financiamento adicional. Então você atribui isso ao patrocinador e o mantém aberto até que isso seja resolvido. Quando o projeto estiver concluído, você poderá ver o log de alterações para ver qual era o escopo inicial da linha de base e o que tudo mudou durante a execução. Se houver alguma decisão ou neste caso, a decisão foi tomada para adicionar o módulo de treinamento que é adicionado aqui e dois são confirmados por patrocinadores ou posteriores. Se esses títulos que nosso CEO deixou a empresa e alguém olhou para a carta do projeto onde isso não foi mencionado e questioná-lo como gerente de projeto sobre, ei, por que você perguntou a este módulo de treinamento, que não está na carta ou no caso de negócios. Então, de onde isso vem? Então? Você pode mostrar que, hey, tivemos essa decisão tomada neste dia e foi feita pelo patrocinador e CIO. E também iniciamos um registro de alterações e esse é o status. É por isso que manter todo esse registro e problemas é muito crítico e importante porque a equipe pode mudar continuamente. E como PM, você precisa acompanhar as coisas, o que mudou, em que momento? Se for auditado ou outra pessoa entrar na foto, você terá os detalhes por trás das mudanças. Itens de ação é qualquer coisa que seja um item aberto que alguém tenha uma ação e precisa ser concluído. E você pode revisar tudo isso durante a reunião de status e pode filtrar pela data de vencimento e também pelo status de abertura. E você pode revisar isso com a equipe e dizer: Esses são os itens abertos. Onde estamos nisso? De que ajuda você precisa e quando podemos esperar que ela seja concluída? Portanto, esse é um bom exemplo de como você gerencia registros diferentes e a importância de cada log. Espero que você tenha entendido a importância de todos esses registros diferentes. E se você quiser, você pode baixar isso, a descrição do arquivo abaixo, e você pode mantê-lo como arquivos individuais ou você pode mantê-lo como um único arquivo com várias guias, dependendo de quão grande isso vai crescer. Tudo bem, então isso conclui as principais coisas que fazemos na execução. Agora é hora de celebrar o projeto go-live. E no próximo capítulo, vamos dar uma olhada na mudança de planejamento GO-live e coisas assim. 28. PLANNING CORTE, GOLIVE: Agora é a parte empolgante. Concluímos o projeto e estamos prontos para entrar em produção antes de dar esse salto final produção e disponibilizar seu serviço ou projeto ou produto para que os usuários consumir e usar. Você precisa se certificar de planejar sua atividade de substituição com muito cuidado. Porque esse é o rompedor de negócios. Se você mover algo para produção que não vai funcionar bem, então vai ser um desastre. Então você tinha que se certificar de que seu plano de corte é muito bem pensado. E se houver algum problema, você sempre pode reverter para um estado anterior. Vamos ver como são as atividades de substituição e o que devemos considerar ao planejar a substituição? Então, a primeira coisa é que você tem que pregar a hora exata da substituição. Quando exatamente você planeja concluir a migração para a produção? Por exemplo, se você está planejando mover alterações no site, você pode querer considerar ou identificar o momento em que o tráfego para esse site é muito baixo, de modo que o impacto dos clientes e usuários muito baixo porque o cutover não vai ser apenas virar um interruptor e pronto. É uma longa nossa atividade e pode levar talvez algumas horas ou meio dia para concluir todas as atividades de substituição. Eles serão tempo de inatividade onde os usuários não poderão acessar o site ou qualquer projeto, serviço ou produto que você planeja passar para a previsão se você tiver sua conta bancária, você pode ter visto algumas vezes surgir uma mensagem que a manutenção é neste domingo, então espere tempo de inatividade durante o voo para as 19h Leste ou qualquer que seja esse período de tempo que seja feito para garantir que o sistema, o sistema de produção é derrubado, toda a manutenção e mudanças para cima, empurre para trás e, em seguida, colocá-los novamente online. Então você tem que fazer exatamente a mesma coisa para o seu projeto. Você precisa ver quando é o melhor momento para reduzir os sistemas de previsão. Envie todas as suas alterações, seu código, seus arquivos de configuração, o que você precisa fazer para entrar em produção, faça isso durante o tempo de substituição. E uma vez que tudo é movido para a produção texturizada, você traz a previsão, mãe e backup. Normalmente, é assim que é feito. É por isso que é muito importante para você planejar a linha do tempo de substituição e também garantir que você tenha todos os recursos disponíveis para fazer todo o trabalho planejado para a substituição. Digamos que você tenha assistência necessária para o momento do banco de dados. E se você não planejou a substituição, esse recurso pode não estar disponível e isso pode afetar todo o processo de substituição se houver locais de escritórios ou site que estejam cortando, por exemplo, estamos nos movendo de um lado para um novo site. Então você precisa ter certeza de que você tem acesso a esses sites após o horário de expediente regular. Portanto, você precisa se certificar de que a segurança e outras pessoas informadas sobre isso e estão disponíveis para garantir que você possa entrar no novo escritório quando fizer a substituição. E também você precisa pensar sobre o plano de reversão. O que isso significa é que se algo der terrivelmente errado, então você deve ser capaz de restabelecer um estado anterior em que estava funcionando bem. Então você tem que identificar o que se algo der errado e como você pode reverter para um estado anterior ou para o estado dele, onde ele funcionará com algum impacto mínimo. E se houver algum requisito legal ou regulamentar dos quais você precisa obter aprovação, eles precisam ser tomados com bastante antecedência , porque provavelmente a substituição será durante o fim de semana, quando o tráfego é baixo e obter aprovações em um fim de semana será desafiador. Então você tem que pensar todos esses aspectos diferentes e, em seguida, planejar sua substituição. Eu diria que a melhor analogia que você pode pensar é quando você está se mudando de um apartamento para entrar no apartamento, ou você está mudando sua casa de, digamos, de uma parte do país para a outra parte. Você não pode simplesmente decidir um dia e se mudar porque você tem que se certificar que são empacotadores e mais piores e quando eles virão para sua casa e a que horas você completaria o movendo e depois entregue a chave para o proprietário. Portanto, existem diferentes componentes que acontecem como parte desse processo MOOC. Então, a cartografia é exatamente a mesma. Você precisa planejar hora hora ou às vezes minuto a minuto quais ações precisam acontecer para que todo o processo de substituição seja concluído. Neste exemplo de movimentação, você pode ter que planejar antecedência talvez duas ou três semanas antes do tempo para garantir que ele esteja movendo o serviço disponível e dar a eles uma janela de tempo que eles têm chegar às nove da manhã e começá-los a se mover e terminar com isso às cinco da tarde. E então, no novo local, você tem que se certificar de que às cinco horas você pode se mudar e ter eletricidade, água, todos esses serviços disponíveis e coisas assim. Portanto, você precisa ter certeza de gastar tempo suficiente para listar sobre todas as coisas que precisam acontecer durante essa janela de corte e ter um plano e recursos atribuídos a esses e tempo exato como para o que tem que acontecer e quem o fará. Então, novamente, é muito crítico que quaisquer aprovações que você precisa, você tenha que chegar à frente do tempo porque provavelmente no último minuto, você não queria concorrer a nenhuma aprovação. Se houver alguma comunicação que precise sair sobre a ou qualquer tempo de inatividade onde os sistemas não estarão acessíveis. Quaisquer pré-requisitos , como treinar os funcionários sobre o novo produto, projeto ou serviço. E tudo isso precisa ser planejado com antecedência e se comunicar quando isso precisa ser concluído durante ou antes da mudança. Você também precisa pensar em quando você quer ter sessões de treinamento disponíveis para os usuários? E você tem que se certificar de que o treinamento está preso porque se os usuários não forem treinados neste novo sistema ou como usar esse novo sistema, sempre haverá um desafio após o reclamações de substituição entrarão. Você tem que se certificar de que eles estão equipados para entender esse novo processo, a nova tecnologia ou o novo produto que estamos empurrando. E eles se sentem confortáveis em usá-lo porque outra forma, será um desafio durante o tempo de suporte de substituição. E por último, mas não menos importante, você também tem que se certificar de que você tem alguma ponte chamada de configuração para que as pessoas, se encontrarem algum problema, possam chamar essa ponte comum. E alguém que está disponível para responder, esclarecer e apoiar o usuário se ele tiver algum problema. Portanto, planeje uma ponte aberta, uma linha telefônica ou um computador, e-mail, seja lá o que for, certifique-se de que alguém esteja monitorando isso e forneça essas informações de volta aos usuários. Então, se alguém após a mudança entrar em alguns problemas e quiser ajudá-lo, ele sabe como entrar em contato e a quem entrar em contato. Portanto, é muito crítico que você dê suporte ao usuário fornecendo todos esses detalhes antes do tempo. Então, no geral, o go-live é um processo muito estressante. Mas se você planejar sua substituição e entrar ao vivo, bem à frente e listar todas as coisas que você precisa para cuidar, então as coisas correrão sem problemas e você ficará bem. É um esforço de equipe. Certifique-se de discutir com a equipe todos os itens que precisam ser cuidados, qualquer plano de reversão que precise ser discutido e documentar tudo isso para que, quando algo der errado, você saberia exatamente o que precisa ser feito naquele momento. É por isso que o planejamento de substituição é tão crítico, pois, de outra forma pode causar problemas e dor de cabeça para o seu projeto no último minuto. Portanto, na seção de recursos, você pode encontrar alguma lista de verificação de substituição que você pode usar para qualquer projeto de TI para verificar se você precisa fazer todas essas coisas e você sempre pode dizer a lista de verificação às suas necessidades. Mas hábitos, listas de verificação prontas para sua substituição para garantir que as coisas sejam mais suaves. E na próxima lição, vamos dar uma olhada no suporte do hyper case. Este é o suporte de garantia. Então, depois de nós , com sucesso , você está agora ao vivo em produção, mas tudo é novo para o usuário. Portanto, você precisa ter certeza de que a equipe do projeto está disponível para dar suporte aos usuários que ligam pelo menos por uma semana, se não duas semanas, e esses serão abordados na próxima lição. 29. Suporte para Hypercare: Tudo bem, então agora fomos ao vivo com sucesso e agora é hora apoiar os usos para responder a quaisquer perguntas que possam ter desafios que eles estão enfrentando após o go-live. Portanto, o suporte da HyperCools, este é o seu período de garantia. Depois de ir ao vivo. Você precisa apoiar a equipe e os usos nos próximos dias ou até duas semanas, se possível. Idealmente, você pode pensar nesse ativo 247 de suporte possível. Então, essa é alguém para atender à causa dependendo de onde os usuários estão ligando. Se você é uma equipe global, obviamente você poderia esperar chamadas de diferentes países durante todo o tempo. Portanto, é uma boa ideia ter alguém apoiando as pontes da ponte. Nada além de uma linha aberta onde as pessoas podem discar para esclarecer ou responder as perguntas. Então é isso que você tem que pensar sobre a Penn configurar a ponte de hiper cuidado. Então, normalmente, você pode ouvi-lo como salão de baile ou ponte aberta dedicada. Então, qualquer um pode ligar. Essas informações seriam algo que você notificaria os usuários com antecedência bem antes da entrada ao vivo para que eles estejam cientes de que há uma chamada de suporte ou ponte de suporte disponível no caso de eles serem executados em um problema para que eles possam obter o suporte que precisam com o novo sistema após GO-live para tornar o Hypercard chamado de apoio e menos desafiador de alguém é que você tem várias pessoas na sala em vez de apenas uma pessoa. E desde que você mantenha os usos com documentos de conhecimento, vídeos de treinamento e sessões de treinamento antes do Go-live, suas chamadas de Hypercard seriam muito menores porque os usuários já sabem como usar o novo sistema, então eles não precisariam de muita ajuda. Mas ainda seriam usos que perderam as sessões de treinamento e ainda o chamariam. Então, naquele momento, você pode compartilhar as sessões gravadas ou quaisquer outros recursos de treinamento que você possa dar a elas para que elas possam assistir o que fazer com o novo sistema. E isso pode resolver o problema deles, por que eles estão ligando. Portanto, essas são algumas das coisas que você precisa pensar ao configurar a sala de parede ou o suporte maiúsculo, ou uma ponte aberta onde as pessoas podem ligar se tiverem dúvidas após o Go-live. E dependendo do tamanho e da largura de banda, você pode ter isso para uma equipe global maior ou você pode ter apenas uma ou duas pessoas apoiando isso. Isso é antes da transição do projeto para a equipe de suporte. É uma boa ideia envolver uma ou duas pessoas da equipe de suporte para que elas entendam quais tipos de chamadas esperar e quais respostas você está fornecendo e onde os recursos estão localizados para que eles saibam como apoiá-lo após o período de garantia, após duas semanas. Isso é tudo para esta lição. É uma lição curta de cozinheiro e apenas dando uma ideia de como é o suporte do hyper case. O que isso significa e o que você precisa pensar antes de configurar uma chamada de Hypercard. 30. Aulas de encerramento de projetos aprendemos: Tudo bem, agora concluímos o projeto e é hora de fechar o projeto, mas não se apresse e não feche assim que terminar a última tarefa, você ainda precisa fazer certas coisas para fechar corretamente o projeto. Então, uma das coisas que eu recomendo fazer é uma sessão de Lições Aprendidas com toda a equipe. Embora você tenha a equipe, esta é a oportunidade perfeita para entender certas coisas em projetos para que você possa melhorar a execução do projeto e os projetos subsequentes. Então, antes de tudo, vamos analisar como equipe o que correu bem. Então, antes de entrar nisso, o que você quer fazer é enviar um quadro retrospectivo ou qualquer quadro onde eles possam pensar no que correu bem para capturar essas coisas antes da reunião. Se você tem um projeto de um ano, é altamente impossível para todos se lembrarem. Quais são as coisas que correram bem para dar à equipe uma semana ou duas para pensar sobre o que correu bem. Para fazer isso, quando eles se lembram algo antes de entrarem em lições aprendidas, eles têm um lugar para anotá-lo. Então eu uso uma diretoria chamada retrospectiva de fundos in.com. Vou colocar o link na descrição abaixo, mas você pode usar outros métodos, como MS Planner ou qualquer produto do Google. Então, o que você está procurando aqui é identificar as coisas que foram bem-sucedidas para que você possa repetir essas coisas em seu próximo projeto, se alguma coisa, que você fez bem, então por que não utilizar nos próximos projetos ou em qualquer outro projeto que surja? A próxima coisa que você quer pensar em equipe é o que as coisas podem ser melhoradas. Há alguma lição aprendida com a execução do projeto? Então, essas são coisas em que fizemos isso, mas poderíamos ter mudado um pouco algo para fazê-lo melhor da próxima vez. Portanto, essas coisas precisam ser capturadas e é bom ter a perspectiva da equipe, não apenas do ponto de vista do gerente de projeto. É um bom momento para documentar isso. E quando você envia o link para o quadro retrospectivo, você quer pelo menos capturar o que correu bem, o que pode ser melhorado? E por último, mas não menos importante, e isso talvez seja o mais importante. O que deve ser interrompido? O que não está funcionando bem? Se algo não estiver funcionando bem, então não faz sentido continuar isso nos projetos subsequentes ou na execução do projeto. Portanto, essas coisas são fundamentais para entender essas três coisas no mínimo, você deve capturar na sessão Lições Aprendidas ou pode chamá-la como uma sessão retrospectiva. Essas são informações valiosas que você pode coletar da equipe antes desmontar a equipe e soltá-la. Então, como exemplo, o quadro ficaria algo assim. O método de três L gostou, aprendeu, faltou, seja qual for a maneira que você quiser nomear os cabeçalhos do tabuleiro, você pode fazer isso. As maneiras mais fáceis de seguir com o que correu bem, o que devemos melhorar e o que devemos parar de fazer? Então, contanto que coletemos isso e melhoremos na próxima execução do projeto, você, como gerente de projeto e como equipe, melhoraria continuamente suas entregas e a execução do projeto. Isso é uma rápida sessão de 30 minutos a uma hora que ele pode fazer com a equipe. E no final da sessão de lições aprendidas, você pode agradecer a todos pela contribuição e também pelo trabalho do projeto que eles apoiaram até agora. 31. Transição para equipe de operações: Tudo bem, concluímos o GO-live e, nesta lição, vamos dar uma olhada em qual é o processo para entregar ao suporte de produção ou às operações. Quando o projeto é concluído agora, ele se torna parte da equipe de operações. Eles são completamente novos. Eles não fazem ideia do que O fez como parte do projeto, quais novos recursos você adicionou e qual é o produto. Então você tem que torná-los informados para que eles possam dar suporte quando os clientes ligarem para eles. A primeira coisa é, como parte do projeto, se houver alguma documentação que você possa entregar à equipe de suporte ou à equipe de operações, então você vai querer fazer isso. A base de conhecimento pode ser qualquer arquitetura de sistema de alto nível, o fluxo de trabalho ou quaisquer perguntas frequentes que você acha que possam ser úteis para eles. Então, quando o cliente os custa, eles podem lidar com isso adequadamente. Isso é muito crítico para a equipe de operação porque é quando eles se levantariam pela primeira vez, dizem o projeto e os detalhes e funções do produto. Portanto, todos os detalhes que você possa fornecer à equipe de operações que seriam benéficos para eles. Em seguida, se possível, treine as operações ou a equipe de suporte ao cliente. Então, se você estiver lançando um novo produto, obviamente, quando ele estiver ativo, as pessoas não vão ligar para a equipe do projeto, mas para a operação e dar suporte a toda a equipe de suporte ao cliente. Então você tem que se certificar de que está treinando-os e eles são bem versados no produto ou nos novos serviços com os quais você dobra ao vivo para que, quando o cliente for chamado, ele possa responda adequadamente porque a última coisa que você quer é que você tenha um projeto bem-sucedido e é um desastre depois de entrar, tão difícil garantir que o ímpeto continue mesmo depois de sua mão fora do seu serviço de produto ou qualquer outra coisa que tenha entrado ao vivo como parte do projeto para a equipe de operações. E, por último, mas não menos importante, você também precisa ter certeza de informar ao suporte ao cliente ou à equipe de operações como lidar e relatar problemas com base na documentação que você forneceu. Se você souber a maioria das perguntas comuns que eles podem receber, novamente, forneça as respostas ou como lidar com esses problemas. E dessa forma, a equipe de operações não precisa entrar em contato com a equipe do projeto. E, obviamente, uma vez que o projeto é fechado, eles podem não ser uma equipe de projeto. Portanto, torna-se responsabilidade da operação lidar com os problemas. Se houver algum membro da equipe do projeto que você possa fazer a transição para operações, isso seria melhor para que pelo menos haja um recurso experiente movendo-se do projeto ou da transição, a maior parte do diamante não é possível e a equipe do projeto ainda continua e passa para algum outro projeto. E então algo crítico entra e a equipe da operação pode entrar em contato com essa pessoa e ela pode encontrar algum tempo limite para apoiá-la. Mas, idealmente, o que você quer é que, se houver algum problema ou coisas novas que estão surgindo, você quer rastrear isso e depois lidar com isso como parte do projeto porque você pode ter um hiper tempo de suporte de casos de duas semanas ou um mês, então, se forem problemas menores ou melhoria do processo, você pode lidar com isso como parte da próxima versão. Portanto, você deseja definir um processo em que as operações possam suportar e se houver novos recursos ou bugs que precisam ser resolvidos, como você pode lidar com isso como parte do suporte contínuo de a equipe do projeto ou para a próxima versão. Lembre-se de que, em um nível alto, o que estamos tentando fazer aqui é entregar o produto ou o serviço em que você trabalhou e entregá-lo a uma equipe que vai apoiá-lo daqui para frente. Você precisa se certificar de que essa equipe esteja bem equipada para dar suporte e servir novos produtos ou serviços para o cliente para que os clientes fiquem satisfeitos no final do dia. Na próxima lição, vamos dar uma olhada em como finalmente fechar a limpeza do projeto, realizar qualquer atividade de descomissionamento e como arquivar os documentos do projeto. 32. Arquivo de documentos do projeto: Tudo bem, então agora estamos na fase final. Agora estamos prontos para fechar um projeto. Concluímos o suporte de hiper cuidado, fizemos a transição para as operações. Agora, podemos desmontar a equipe do projeto. Portanto, antes de fazermos isso, temos que nos certificar de que arquivamos todos os documentos do projeto. A primeira coisa é se você recebeu todas as aprovações, e-mails ou de qualquer forma que você recebe as aprovações, Dave, eles porque quando você for auditado e uma auditoria vai acontecer de uma maneira outro se seu projeto for auditado do que as coisas que eles procurariam é documentação sobre seus requisitos, suas aprovações, seu gerenciamento de alterações e aprovadores de solicitação de alteração, tudo isso. Portanto, quaisquer aprovações que você tenha recebido da liderança para prosseguir com o projeto, seja na escola ou no orçamento ou mudanças no cronograma, quaisquer que sejam as aprovações que você teve que obter durante a execução. Agora é hora de coletar tudo isso, salvá-lo. Idealmente, você quer salvá-lo durante toda a execução, mas se você não tiver feito, agora eu digo boa hora para passar por isso, encontrar todas as aprovações necessárias e salvá-las em algum lugar para que você possa sempre acessar isso. A próxima coisa é a documentação do projeto. Isso é muito crítico porque uma vez que você desmantela a equipe, ninguém sabe como foi feito e você perderá os especialistas. Portanto, antes de desmontar a equipe, certifique-se de que eles compartilharam toda a documentação, como as coisas são feitas, qual era a abordagem deles se houver alguma arquitetura ou diagramas de fluxo do sistema, salve tudo isso na pasta onde você pode acessá-lo. E esses documentos já estão lá ou salvos durante a execução do projeto. Agora estamos apenas nos certificando de que está tudo lá e você pode acessá-lo, se necessário. E uma vez que você tenha as aprovações e a documentação do projeto, certifique-se de ter movido isso para um local seguro para não perdê-lo. Se você tem um lado específico do projeto que será fechado e você não teria acesso que deseja salvar lá, mas também deseja salvar uma cópia de alguma forma, você sempre pode obter acesso porque a auditoria e qualquer outra coisa que vem depois, isso pode acontecer após seis meses ou um ano. Então, você vai querer acessar todos esses documentos do projeto mesmo depois que o projeto for fechado. Uma vez que tudo isso seja feito, agora você está livre. Você está pronto para desmontar sua equipe e informar ao mundo que seu projeto foi feito aqui, mudando e enviando-lhes uma nota de agradecimento por todos os esforços e colaboração que toda a equipe estendida fez por você e para a equipe do projeto. E então você está pronto para passar para o nosso próximo projeto.