Este ano foi injusto com quem ministra aulas nas sextas feiras, pois tivemos 2 feriados e uma greve geral, na qual a universidade teve a sensibilidade de não exigir presença e evitar provas ou trabalhos, posto que não haveriam ônibus, trens e o risco de movimentação urbana com bloqueios de ruas e eventual violência.
Mas após um mês sem aulas, retomamos com uma boa revisão da matéria, os grupos tiveram um tempo para relembrar seus projetos, que ainda estavam em fase de modelagem inicial das ideias. A seguir retomamos de onde paramos, de lá para cá foram duas aulas e a realização da primeira prova, com boa média.
05/05/17 – 6ª AULA DE GP
Na quinta aula tínhamos chegado até o Termo de abertura do grupo de processo de Iniciação, usando para isso o artefato de Project Model Canvas. Aqui seguimos com a apresentação dos nossos stakeholders, oportunidade para discutir empatia além da formalidade, não só quem é, mas o que sente e quer.
A abordagem da empatia, trazendo uma visão típica do Design Thinking é porque gerenciamento de projetos de software no século XXI é fazer certo a coisa certa, inicia desde o entendimento do problema, da necessidade e não da solução. Então personas, empathy canvas e value proposition canvas são sim técnicas de GP, ou seguiremos com as mesmas charges infames do século XX sobre a galera de TI:
No último slot da aula fiz uma provocação sobre a área de INTEGRAÇÃO e seus processos, sobre o Termo de abertura da aula passada, sobre o plano de gerenciamento de projetos, as características do gerenciamento de mudanças e ao final as lições aprendidas. Discutimos especialmente o Plano de Gerenciamento para que na próxima aula após a prova entrássemos direto em ESCOPO.
12/05/17 – P1 (PROVA)
Entre a sexta e a sétima aula, tivemos a P1, onde ocupei dois créditos com estudo em grupos de três e uma revisão geral da matéria – conceitos de portfólio, programa, projetos, sub-projetos, operações, tipos de estrutura organizacional, governança, PMO, os 5 grupos de processos do PMBOK, diferenças entre o GP tradicional e ágil, as 10 áreas de conhecimento/planejamento do PMBOK.
19/05/17 – 7ª AULA DE GP
A sétima aula foi muito pegada, pois após feriados, greve e prova, tínhamos muito o que fazer para colocarmos a pauta em dia. Em linhas gerais, discutimos alguns dos fundamentos mais importantes sobre planejamento de escopo:
- desenho de processo
- funcionalidades
- categorias de requisitos
- épicos e histórias
- tarefas
O exercício realizado logo no início que começamos a discutir requisitos é o clássico planejamento de um churrasco da turma, quer no formato de uma jornada de usuário, com pacotes de trabalho e estrutura semelhante a uma WBS ou em rede. O exercício ajudou a acordar os alunos mais cansados em uma noite de sexta.
A aula foi bem prática, evoluímos bem no entendimento por cada grupo sobre as funcionalidades possíveis em cada um dos projetos, alguns discutindo a nível de requisitos, outros em épicos e histórias. A meta era um grande brainstorming para que na próxima aula tenhamos a WBS/User Story Mapping materializadas.
Faltando ainda uma hora e meia para o final, optei por um quebra gelo famoso por produzir muita adrenalina, conhecido como Kaa e Bagheera no escotismo ou Snakes como Team Building Games. Descemos do terceiro para o térreo, fiz um briefing sobre sistemas empurrados e puxados, organizei as filas, expliquei o objetivo, as regras e usei uma tira de papel de 50 cm x 15 cm como rabichos.
A adesão e empenho foi muito legal, todos voltaram à aula muito acordados e dispostos a mais uma hora para o braisntorming de escopo … a opção pelo jogo me fez postergar a dinâmica de pitchs e reconstrução, mas valeu a pena. Na próxima aula cada grupo/projeto terá 30 minutos para organizar seu escopo e apresentá-lo, permitindo que todos os outros cinco grupos possam questionar, sugerir, ajudar.
Durante a aula relembrei a charge das árvores sobre requisitos em um projeto, insisti na minha abordagem de profissionais de perfil T ou Pi, sobre nem só fazer errado a coisa certa, nem fazer certo a coisa errada, nossa meta é fazer certo a coisa certa. É entender o problema, para mapear alternativas e trabalhar a solução.
- Pizzaria – O cliente liga e pede o tamanho, a massa, o recheio, a borda, não cabe à pizzaria ficar questionando se por acaso o pedido é inadequado, se vai sobrar, se alguém é alérgico, …
- Médicos – O paciente não chega pedindo uma injeção de terramicina, é o médico que deve levantar dados o suficiente para diagnosticar e receitar a melhor medicação (ou não) para o momento.
Quem você é? O que você faz? Você ainda faz software como no século XX, quando o cliente dizia o diagnóstico e especificava o que queria ou você faz levantamentos, discute, levanta alternativas para só então trabalhar naquela que parece ser a melhor solução, mesmo assim receita e pede que o paciente volte dali a duas semanas após tomar a medicação para certificar-se de que esta certo?
Jorge Horácio "Kotick" Audy 