A abordagem linear tradicional para o gerenciamento de projetos deixou você acima do orçamento com um produto subdesenvolvido e um tempo de entrada no mercado prolongado? Uma abordagem ágil oferece maior flexibilidade, transparência e responsabilidade para gerentes com projetos complexos que requerem várias fases de feedback e revisão. Com este Gerenciamento de Projetos Ágil deck, concentre-se nas necessidades do cliente com uma abordagem iterativa para maximizar o sucesso do projeto.
Ask follow up
No processo de desenvolvimento ágil, um gerente recebe requisitos, e a equipe desenvolve soluções possíveis e libera várias iterações até a aprovação final ou lançamento do produto. (Slide 7)
Scrum é uma metodologia ágil comumente usada. Os papéis da equipe de scrum podem ser classificados como um organograma para detalhar os principais stakeholders na equipe de gerenciamento de projetos. (Slide 9)
Visualizações de pesquisa de cliente do quadro Kanban podem ser usadas como uma forma de gerenciamento ágil para limitar o trabalho em andamento, gerenciar fluxos de trabalho e criar loops de feedback positivo. (Slide 12)
Ask follow up
O método ágil de gerenciamento de projetos pode ser usado por organizações de qualquer tamanho. Para grandes organizações com um problema legado, o ágil poderia especialmente levar a um fluxo de trabalho mais eficiente do que o modelo tradicional de cascata.
Com o ágil, os gerentes podem adotar uma abordagem iterativa e colaborativa para o desenvolvimento de produtos e a organização de projetos. O foco do ágil está nas necessidades do cliente e minimiza os recursos e a sobrecarga necessários para criar um produto com verdadeiro ajuste de mercado. A flexibilidade aumentada e o ritmo rápido também criam tempos de retorno mais rápidos — o maior benefício para os gerentes de projetos.
Ask follow up
Começamos com uma visão geral da metodologia ágil e como ela é usada no gerenciamento de projetos. Agile Method for Digital Product foi originalmente desenvolvido como uma abordagem mais recente para o desenvolvimento de software, mas seu ethos foi traduzido e aplicado ao gerenciamento de projetos, desenvolvimento de produtos e até mesmo ao gerenciamento organizacional. Para qualquer equipe ser responsiva e rápida para se adaptar, o ágil pode ser um método muito mais forte a seguir em oposição ao método tradicional de cascata, onde as tarefas são realizadas em uma sequência linear.
Ask follow up
Entre os métodos tradicionais e ágeis de gerenciamento de projetos, existem algumas diferenças-chave. O ágil é muito centrado no cliente, pois foca o desenvolvimento do produto no usuário final por meio de várias rodadas de feedback e revisões. Ele também é flexível, o que é um ponto-chave que o separa da falácia do custo afundado que pode ocorrer nos modelos tradicionais.Este é o ponto onde os gestores pensam que só porque um plano foi feito, ele tem que ser executado mesmo que sinais de alerta apareçam no processo. O Agile, por outro lado, dá aos stakeholders e participantes a chance de pivotar conforme apropriado, e criar uma nova iteração ou começar do zero.
Ask follow up
O método tradicional também se concentra na documentação e em detalhes administrativos demorados que os membros da equipe se sentem obrigados a completar, mas que podem exigir um overhead custoso. Isso pode facilmente tirar horas valiosas de tarefas de execução produtivas.
O Agile busca soluções funcionais e máximo valor de negócio no menor tempo possível. Projetos que são gerenciados com uma abordagem ágil normalmente têm ciclos de lançamento mais curtos, o que acelera o tempo de entrada no mercado. É por isso que o Agile é especialmente aplicável ao desenvolvimento de produtos ou recursos de produtos. (Slide 3)
Ask follow up
A seguir, passamos para algumas vantagens chave do Agile, que incluem melhor gestão de prioridades, maior visibilidade do projeto, maior moral da equipe, melhor alinhamento entre as necessidades de negócios e TI, aumento da produtividade e tempo de entrada no mercado mais rápido. As porcentagens aqui são gráficos editáveis que um gerente de projeto pode usar para avaliar como essas áreas chave melhoraram após a mudança para o Agile. (Slide 4)
Ask follow up
O processo de gerenciamento de projetos ágil pode ser visto em etapas: o pré-trabalho, o início do projeto com o conjunto inicial de requisitos (vamos agrupá-los como requisitos A aqui), feedback para este primeiro conjunto de requisitos e requisitos B, depois feedback e requisitos C. Os requisitos do projeto são às vezes também conhecidos como tarefas a serem concluídas em cada estágio.
Ask follow up
A etapa de pré-trabalho não é exclusiva do Agile. Todo projeto precisa de um plano para começar, independentemente de sua metodologia de gerenciamento. A etapa de pré-trabalho pode ser onde os gestores definem a visão do produto, o que o projeto envolve, as principais tarefas necessárias, acordos contratuais com stakeholders externos e um plano de lançamento proposto. Como o ponto principal do Agile é permitir a pivotagem, o plano de lançamento original é mais como um esboço geral de para onde você pode ir, mas pode ser ajustado.
Ask follow up
Por exemplo, você quer adicionar um recurso de compras ao vivo a um site de comércio eletrônico. O pré-trabalho seria o desenvolvimento da visão do produto e como ele se integrará ao seu site existente e base de usuários, os acordos contratuais preliminares com o talento que estará envolvido na primeira onda de conteúdo ao vivo que será lançado com o produto, e seu plano de lançamento original e recursos.
Ask follow up
Agora você inicia o processo ágil e se propõe a cumprir os requisitos do "Grupo A" do projeto. Para este recurso de Livestream, vamos dizer que seus requisitos do Grupo A são criar um wireframe de baixa fidelidade de como a interface do usuário funcionará.No desenvolvimento do wireframe, você precisará criar três versões possíveis, depois desenvolver um protótipo de baixa fidelidade para alguns usuários testarem.
Ask follow up
Depois de coletar feedback do seu grupo de teste, é hora de implementá-lo nos requisitos do "Grupo B" para criar sua próxima iteração. Uma de suas primeiras tarefas neste ponto poderia ser analisar e sintetizar os resultados do estudo e fazer sentido deles. Outra poderia ser discutir mudanças de UX com a equipe de software, modificar o protótipo de baixa fidelidade e criar mockups de alta fidelidade para outra rodada de feedback. Agende outro grupo de usuários para entrar para feedback, depois sintetize e implemente suas contribuições nos requisitos do "Grupo C" para enxaguar, repetir e liberar.
Ask follow up
Agora, para comparação, como seria este projeto se seguisse o modelo tradicional, e não o Agile? Sua equipe de desenvolvimento esboçaria a interface do usuário, criaria um protótipo de alta fidelidade, o enviaria para a equipe de desenvolvimento para criar a versão perfeita e a lançaria totalmente formada apenas para descobrir que confunde os usuários. Neste ponto, é muito mais difícil e lento fazer mudanças porque muitos elos na cadeia já se juntaram. Para cada pequena mudança, uma cascata inteira de outras mudanças poderia estar envolvida. É por isso que o agile pode ser muitas vezes mais bem-sucedido e pegar erros antes que eles se tornem mais irreversíveis.
Ask follow up
Um processo ágil mais detalhado divide o pessoal envolvido no ciclo de vida. O projeto começa com as partes interessadas, que podem ser tanto internas quanto externas, um executivo ou investidor, ou até mesmo uma persona de usuário com uma solicitação de desenvolvimento. Suas demandas são comunicadas e depois traduzidas em especificações do projeto. As especificações do projeto são então gerenciadas pelo proprietário do projeto ou produto. Este líder de equipe prepara relatórios que serão usados para gerenciar o backlog de requisitos a serem desenvolvidos e despachados.
Ask follow up
Neste exemplo, existem três versões principais. Após o lançamento de cada versão, haverá um backlog de áreas para melhoria (com base no feedback) a ser implementado antes do próximo lançamento. (Slide 6)
Scrum é um método comum de gestão de projetos ágeis. O Scrum Process tem seis elementos-chave.
O primeiro é o backlog do produto, ou a lista de requisitos que são priorizados e frequentemente divididos em pacotes de trabalho. Outro elemento do scrum são os sprints, que dividem o trabalho em duração fixa (geralmente alguns dias) que se concentra hiperativamente em um pacote de trabalho específico para um resultado funcional.
Ask follow up
Esses sprints são então revisados em uma reunião onde a equipe apresenta o resultado para feedback que é implementado no próximo sprint. Um backlog de sprint é então usado para dividir o trabalho em pacotes menores ou alocado a equipes menores e documentar o trabalho restante para cada pacote.A ideia é moldar o produto em incrementos de melhoria para que cada sprint realize algum nível de funcionalidade potencialmente entregável. Finalmente, as reuniões diárias de scrum, muitas vezes lideradas pelo scrum master, confirmam que tudo está indo na direção certa.
Ask follow up
Para segmentar por perfil psicográfico, divida seus clientes por estilo de vida, personalidade, valores e interesses. Por exemplo, digamos que seus clientes-alvo sigam o estilo de vida de um profissional urbano. Sua personalidade é curiosa, com amor por novas inovações e os gadgets mais recentes. Eles valorizam a estabilidade, a fluidez e a facilidade de uso, e têm interesse em tudo, desde artes e entretenimento até tecnologia. No entanto, seu interesse unificador é facilitar as tarefas diárias.
Ask follow up
Digamos que você queira usar essa visualização como parte de sua reunião diária de scrum. Você pode realmente editar essas informações para listar os detalhes que deseja revisar sob cada elemento. Por exemplo, sob o backlog do produto, você pode substituir os pontos de bala pelos requisitos que ainda precisam ser implementados. Sob sprint, você pode resumir o status atual do sprint. Seu cartão de backlog do Sprint cobrirá o que ainda precisa ser realizado. (Slide 8)
Ask follow up
Outro método ágil útil é o Kanban. Kanban Methodology visualiza um fluxo de trabalho enxuto em um formato de cartão, com colunas que correspondem às etapas do processo de desenvolvimento e cartões atribuídos para tarefas individuais.
Kanban torna as políticas explícitas com uma definição coletiva do processo e diretrizes acordadas, e naturalmente cria um ciclo de feedback para melhoria contínua por meio de reuniões regulares. Além disso, o Kanban facilita a gestão de fluxos de trabalho através da redução de gargalos, pois todos podem ver onde está o atraso na cadeia. E porque limita o trabalho em andamento para evitar multitarefas, o Kanban não sobrecarrega os membros da equipe.
Ask follow up
Você pode usar as cores para representar membros individuais da equipe e as tarefas que lhes são atribuídas. O quadro Kanban é composto por um backlog de tarefas, tarefas que foram aceitas e tarefas que devem ser implementadas, testadas e concluídas.
Com nosso recurso de compras ao vivo, o backlog seria todas as tarefas que definimos anteriormente, como o desenvolvimento de wireframe, os recursos de UX e qualquer coordenação com talentos ou grupos de teste que precisam ser gerenciados. Como gerente de projeto, você pegará tarefas do backlog e as atribuirá a membros individuais da equipe. Como você pode ver, talvez o principal desenvolvedor de software seja verde claro. Aqui eles têm três tarefas em seu a fazer e uma em andamento. O coordenador de parcerias, que é responsável por gerenciar talentos, está em verde escuro.Neste caso, todas as suas tarefas relacionadas à aquisição de talentos são concluídas, pois os contratos foram todos assinados com os influenciadores que testarão e fornecerão feedback e, em seguida, lançarão conteúdo no lançamento. (Slide 11)
Ask follow up
Um roadmap ágil pode ser usado como uma linha do tempo do projeto para acompanhar o progresso ao longo de vários anos. Nesta visualização, três diferentes fluxos de trabalho podem ser acompanhados ao longo dos anos e são codificados por cores de acordo com o nível de risco do projeto. O Risk Management do projeto é importante, pois podem ocorrer eventos ou condições incertas que interrompem o processo de um projeto. A consciência de possíveis resultados ou possíveis interrupções prepara melhor tanto o gerente quanto o stakeholder.
Ask follow up
Para projetos ou tarefas de alto risco, você pode ver onde focar sua atenção, ou ajustar as prioridades das tarefas para que outra tarefa chave não dependa inteiramente do sucesso de uma tarefa de alto risco. Idealmente, uma tarefa que segue uma tarefa de alto risco pode ser realizada independentemente do sucesso ou fracasso da tarefa de alto risco.
Ask follow up
No caso do nosso recurso de compras ao vivo, um atraso para inscrever criadores de conteúdo pode levar a um lançamento fraco, sem conteúdo suficiente para manter sua base de usuários engajada, ou mesmo saber como esse novo recurso funciona. Outra tarefa de alto risco poderia ser a criação do painel do criador, onde os criadores fazem upload de seu conteúdo. Se este backend não estiver configurado corretamente, ninguém poderá fazer upload de seu conteúdo ou assistir transmissões ao vivo, o que efetivamente mataria seu lançamento. (Slide 13)
Ask follow up
Alternativamente, um plano de lançamento ágil é outro tipo de roadmap que os gerentes de projeto podem usar para acompanhar cronogramas em diferentes versões e lançamentos. É mais uma visualização baseada em fases que acompanha tarefas e progresso ao longo de iterações, o que pode ser uma variação útil dependendo das informações que você precisa acompanhar ou comunicar com os principais stakeholders em várias etapas do projeto.(Slide 15)
Ask follow up