Grandes tendências moldam o profissional do século XXI, como a mobilidade, as múltiplas gerações e mudanças demográficas, as novas mídias gerando novos comportamentos e novas formas de comunicação, a tecnologia com BigData, AI, Machine Learning, Blockchain, Internet das coisas, Tecnologia cognitiva, entre outras. Neste contexto, o profissional de gestão de projetos de TI precisa desenvolver Competência (com C maiúsculo, no sentido literal da palavra) para gerenciar todo o ciclo de vida do projeto.
Desde o pré-projeto, desenvolvimento, ciclo de vida e descarte, de forma que as fases finais (Ciclo de vida e descarte) dêem receita suficiente para cobrir as fases iniciais (Pré-projeto e projeto).
Com a competência corretamente desenvolvida, o gerente do projeto estará apto a dar apoio à organização para que o ciclo de vida se materialize.
E quais são os fatores que medem a competência do gerente de projetos?
Fatores que medem a competência em gestão de projetos de TI:
Os inicialmente desenvolvidos Hard Skills:
- Metodologias de gerenciamento de projetos — clássica (como estrutura gerencial) e Agile;
- Saiba fazer bem feito o plano do projeto;
- Mapear os riscos e plano de respostas com as estratégias necessárias;
- Demandar as documentações estritamente necessárias ao bom controle do projeto, sem desperdícios;
- Controle de escopo, riscos, custos, prazos, comunicações, qualidade, stakeholders, integração, recursos do projeto e aquisições.
- Para se aprofundar em cada área do conhecimento, segue um link de referência: Guia PMBOK
Os tão necessários Soft Skills:
- Uma boa liderança, conhecendo sua equipe e sabendo enquadrar cada um no projeto de acordo com seu perfil sem criar um ambiente pesado e de hostilidade.
- Administração de conflitos no geral.
- Capacidade de negociação — de todos os fatores que influenciam o projeto (vide as áreas do conhecimento acima).
- Desenvolvimento do time — quase como um treinador estimulando a equipe.
- Comunicação interpessoal — para se fazer entender e comunicar todos os aspectos entre e para as partes interessadas.
- Criatividade e a Inovação na exploração bem-sucedida de novas idéias, essenciais para sustentar a competitividade e a geração de resultados.
E…
Os menos abordados Business Skills
que fazem toda a diferença na atuação do profissional de gestão de projetos de TI:
- Tecnologia
- Mercado de atuação e sua empresa
- Fornecedores homologados, contratados e seu escopo de trabalho
- O Cliente em que está atuando
- Cultura Organizacional de sua empresa
- Estratégia da empresa de seu projeto
- Estrutura da empresa em que trabalha
- Processos organizacionais de sua empresa e de seu cliente
- Produto principal de seu projeto.
>>Leitura Recomendada:
Leia nosso artigo sobre como usar Metodologia Lean na sua gestão de projetos de TI!
As metodologias clássica e Agile
Na indústria de tecnologia, ambas as metodologias — Clássica e Agile — podem tanto conviver simultaneamente, trazendo uma gestão de projetos de TI híbrida, como co-existir separadamente em esferas de liderança diferentes dentro da empresa.
A gestão de projetos de TI clássica, apoiada no PMBok, devidamente adaptada às necessidades gerenciais da companhia – lembrando que o PMBok é um livro de boas práticas em gerenciamento de projetos e não um manual de como gerenciar um projeto.
No final do dia, quando encontrar um problema pela frente, a resposta não estará no livro. O que fará a diferença são os soft skills do gestor.
A gestão Agile, apoiada no Manifesto Ágil e muito difundida através do Scrum, este sim um framework de trabalho a ser seguido.
Veja: metodologia é um método de trabalho adaptativo, enquanto que framework é um path a ser seguido da maneira que se apresenta.
Havendo adaptação dos eventos do framework, ele perde as características originais e não pode mais ser chamado de Scrum, mas sim de framework próprio.
Para entendermos o framework, abordaremos de forma fast reading em 07 pontos os principais conceitos do Scrum Guide, disponibilizado pela Scrum.org:
Você pode baixar o arquivo aqui: Scrum-Guide
O que é Metodologia Ágil?
Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é:
- Leve
- Simples de entender
- Difícil de dominar
Três pilares apoiam a implementação de controle de processo empírico:
Transparência
Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.
A transparência requer que esses aspectos tenham uma definição padrão comum, para que os observadores compartilharem um mesmo entendimento comum do que está sendo visto.
Inspeção
Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint para detectar variações indesejadas.
Essa inspeção não deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo desviaram para fora dos limites aceitáveis e, que o resultado do produto será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios.
>>Leitura Recomendada:
gestão de projetos de TI: como ser grande profissional da área?
O Papel do PO e do Scrum Master
O Product Owner
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto, resultado do trabalho do Time de Desenvolvimento.
A forma de fazer isso pode variar amplamente através das organizações, Times Scrum e indivíduos.
O Scrum Master
O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.
O Time de Desenvolvimento
O Time de Desenvolvimento é composto por profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint.
Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.
O time DEV deve ser autogerenciável, responsável pelas próprias entregas, determinar o que consegue desenvolver dentro da sprint e também ser responsável pela qualidade dos entregáveis, através de testes.
>>Leitura Recomendada:
Métricas de TI: Como um gestor deve utilizá-las?
Papéis e responsabilidades
Nas abordagens tradicionais de desenvolvimento de software, é comum encontramos atuações bem distintas, como:
- arquiteto,
- programador,
- testador,
- administrador de banco de dados,
- prototipador,
- e assim por diante.
No Scrum é um pouco diferente.
Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.
Características do time de desenvolvimento:
- Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;
- Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
- O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento, independentemente do trabalho que está sendo realizado pela pessoa;
- O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura, operação ou análise de negócios; e,
- Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;
>>Leitura Recomendada:
Como aplicar Scrum em um projeto de teste software.
Eventos do Scrum
para descrição de todos os eventos, consulte a Scrum.org
A sprint
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado.
Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
Daily Scrum
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de Desenvolvimento.
A Reunião Diária é realizada em todos os dias da Sprint. Nela, o Time de Desenvolvimento planeja o trabalho para as próximas 24 horas.
Isso otimiza a colaboração e a performance do time através da inspeção do trabalho, desde a última Reunião Diária, e da previsão do próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade.
As três perguntas comumente respondidas pelo Time de desenvolvimento são:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?
Definição de PRONTO
Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.
Monitorando o Progresso a Caminho dos Objetivos
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado.
O Product Owner acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. Ele, então, compara esse valor com o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho previsto pelo tempo desejado para alcançar o objetivo.
Essa informação deve ser transparente para todas as partes interessadas. Várias práticas para prever tendências foram usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Essas tem se provado úteis.
Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.
A importância da retrospectiva
Cada sprint que finaliza traz com ela lições aprendidas, que não podem ser ignoradas.
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.
A Retrospectiva da Sprint ocorre depois da revisão e antes do planejamento da próxima. Essa é uma reunião de no máximo três horas para uma Sprint de um mês.
Para Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito.
O Scrum Master garante que o evento seja positivo e produtivo e ensina todos a manter o evento dentro do time-box. Ele participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum.
O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho.
O assunto é extenso, tema de MBAs, cursos de especialização, parte do conteúdo de graduações e, para aprofundamento, a título de conhecimento, ficam as referências:
Scrum.org
PMI Brasil
PodCasts sobre gerenciamento de projetos
