Quando um arquiteto elabora uma planta de construção, ele precisa definir todas as especificações antecipadamente, sem poder alterá-las posteriormente. Não é possível simplesmente lançar a fundação e depois decidir se serão construídos cinco ou doze andares. Caso contrário, todo o projeto pode literalmente desmoronar.
Na TI, é exatamente o oposto. Embora no início de um projeto desenvolvamos os termos de referência e criemos protótipos, tudo pode mudar durante a implementação; por exemplo, o cliente pode começar a oferecer um novo serviço que exija criar uma seção adicional no site. Então na TI, nunca se sabe realmente o que está por vir em termos de gestão de projetos.
O gerente de projeto é o responsável por todo o processo desde a primeira reunião com o cliente até a entrega final. Suas responsabilidades incluem:
- Comunicação com o cliente
- Planejamento do fluxo e orçamento do projeto
- Atribuição de tarefas
- Controle de implementação
- Aceitação e entrega do projeto
Todos esses processos dependem muito da metodologia de gestão de projetos escolhida. E é aqui que começa a incerteza, pois é difícil prever antecipadamente qual método funcionará melhor.
Escolha da metodologia
Existem várias abordagens para gestão de projetos, mas as mais comuns são Waterfall e Agile. Embora o Agile tenha surgido originalmente como uma metodologia independente, tornou-se uma espécie de termo guarda-chuva para todos os modelos flexíveis que diferem do tradicional Waterfall, como scrum, kanban, scrumban, etc.
A metodologia Waterfall é um modelo de gestão clássico com uma sequência linear de etapas, onde uma segue a outra em cascata (daí o nome). Esta abordagem envolve uma lista predefinida de tarefas que não devem mudar significativamente durante a implementação. Em outras palavras, tudo segue conforme o planejado.
Na Toimi, usamos Waterfall para projetos padrão com orçamento fixo onde a lista de tarefas e os prazos aproximados estão mais ou menos claros desde o início; por exemplo, este é o caso de lojas online e catálogos de serviços.
No entanto, projetos grandes e não convencionais são muito difíceis de prever antecipadamente. Nesses casos, é melhor usar métodos mais flexíveis onde o conteúdo de cada etapa pode variar de mês a mês. Isto é, enquanto trabalhamos em um conjunto de tarefas (no scrum, isso é chamado de "sprint"), simultaneamente discutimos o tempo e conteúdo do próximo sprint. Na abordagem scrum tradicional, cada sprint dura duas semanas, mas na realidade as empresas costumam estabelecer seus próprios prazos com base na carga de trabalho.
Esta abordagem oferece mais flexibilidade e permite adaptação a fatores externos. Por exemplo, se o cliente quer lançar um serviço de entrega enquanto trabalhamos em seu site, ele só precisa priorizar esta tarefa. Assim, começaremos a trabalhar no serviço durante o próximo sprint, não seis meses depois de completar todas as outras etapas.
Além disso, metodologias flexíveis de gestão de projetos são ótimas para projetos com um longo processo de autorização. Isso é relevante para grandes empresas, onde cada mudança precisa ser aprovada por vários executivos. No modelo tradicional, esse processo pode se estender por muito tempo, mas com a abordagem flexível você pode trabalhar em um conjunto de tarefas enquanto discute simultaneamente a próxima etapa.
Negociação
Em muitos casos, a escolha da metodologia de gestão de projetos depende do cliente. Se o cliente tem conhecimento de TI e está profundamente envolvido no projeto, ele pode participar do gerenciamento de processos e priorização de tarefas, ou seja, trabalhar sob um modelo ágil. Mas as empresas frequentemente solicitam taxas fixas, o que implica na abordagem tradicional. Geralmente há uma boa razão para isso: o gerente precisa reportar aos acionistas ou ao CEO e planejar o orçamento. E como o contratado não pode insistir em uma metodologia diferente, as duas partes precisam encontrar juntas as soluções mais otimizadas.
Na gestão de projetos, a comunicação com o cliente geralmente requer boas habilidades de negociação do gerente. A visão do projeto por parte do cliente costuma ser muito diferente de como a equipe técnica o vê. O cliente se preocupa com resultados, orçamento, vendas e leads, enquanto a equipe de desenvolvimento precisa de um conjunto claro de tarefas. E cabe ao gerente de projeto unir essas duas visões. Seu objetivo não é impor seu ponto de vista, mas encontrar um terreno comum e ajudar a entender o valor do projeto, permitindo que as partes busquem as melhores soluções possíveis.