Dominar os Requisitos (com Kelly Suter da BI Worldwide)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe eventuais erros ortográficos, pois o sistema automático não está correto a 100%.

Ben Aston:

Bem-vindos ao podcast DPM, onde vamos além da teoria para oferecer conselhos especializados de gestão de projetos para liderar melhores projetos digitais. Obrigado por nos acompanhar. Sou Ben Aston, fundador do The Digital Project Manager. Seja honesto: o seu cliente alguma vez terminou o projeto e disse: “Conseguiram mesmo acertar em cheio; é exatamente o que queríamos, é precisamente aquilo que disseram que fariam no início do projeto e é incrível como conseguiram captar tudo sem deixar nada pelo caminho”?

Bem, suspeito que isso não tenha acontecido. E provavelmente isso deve-se ao facto de os seus requisitos não terem sido devidamente definidos. Então, como pode gerir os requisitos para não acabar numa enorme confusão mais tarde no projeto, mas dar ao cliente e ao programador as informações necessárias para concluírem o trabalho? É disso que trata o podcast de hoje: requisitos de projetos.

A forma como definimos um projeto e as funcionalidades para os nossos clientes, para que todos saibam o que será entregue. Essencialmente, penso que os requisitos são uma ferramenta de comunicação, mas é muito difícil acertar neles, porque, se definirmos os requisitos de forma demasiado vaga, damos a nós próprios mais flexibilidade, mas talvez não recebamos exatamente aquilo que pretendíamos. E, se os definirmos de forma demasiado rígida, podemos descobrir que há muitas coisas em falta. Então, como encontramos o equilíbrio certo?

Hoje estou a falar com Kelly Suter. A Kelly é gestora técnica de projetos na BI Worldwide e uma das nossas especialistas residentes da Deakin no The Digital Project Manager. Olá, Kelly.

Kelly Suter:

Olá, obrigada pelo convite, Ben.

Ben Aston:

É ótimo ter-te connosco. Penso que este é o nosso segundo podcast, não é?

Kelly Suter:

Sim, é.

Ben Aston:

Fizemos um podcast há bastante tempo. Para as pessoas que já se esqueceram de quem és, queres dar-nos uma visão geral? Como entraste na gestão de projetos? Tiveste um percurso interessante, penso eu, embora não muito diferente do da maioria dos gestores de projetos. Nunca tencionámos ser gestores de projetos quando crescêssemos, mas conta-nos um pouco da tua história. Como é que agora és gestora de projetos digitais?

Kelly Suter:

Comecei a minha carreira profissional como repórter desportiva, na realidade. Estudei Comunicação, com especialização em relações públicas e meios de comunicação social. Quando percebi que os jornais já não eram uma área em crescimento, decidi mudar para o setor da publicidade. Fui relações-públicas durante cerca de três anos, para uma marca, o Sesame Street Live. Depois conheci alguém que trabalhava numa loja de comércio eletrónico personalizada, uma agência digital de serviço completo, focada apenas em comércio eletrónico.

Ela disse-me: “Não temos aqui um departamento de gestão de projetos. Queres ser gestora de projetos?” E eu respondi: “O que é isso?” O meu pai tinha uma agência de design gráfico, por isso conhecia suficientemente bem os processos das agências para saber que eram caóticos e intensos. Mas pensei: “Sim, parece-me interessante; vamos ver o que têm por lá.” Fui para lá e o primeiro livro que li foi People, Pixels, and Process, de Meghan McInerny. Apliquei-o da melhor forma que consegui à agência, que na altura tinha 12 pessoas.

Estávamos a criar sites de comércio eletrónico personalizados e, cerca de quatro anos depois, tinha criado uma equipa de sete gestores de projetos. Conseguimos aplicar um processo que foi evoluindo continuamente. Depois pensei: “Sinto-me confortável a trabalhar com Magento, Drupal, Cantego, WordPress e outras plataformas, mas quero expandir os meus conhecimentos técnicos.” Surgiu uma oportunidade para uma função de gestão técnica de projetos na BI Worldwide, onde ainda estou, e aceitei. Queria voltar ao mundo da gestão de projetos, envolver-me mais diretamente nos projetos e aperfeiçoar as minhas competências técnicas. É aí que estou hoje. Tem sido muito estimulante e adoro absolutamente o que faço.

Ben Aston:

Quais são os desafios que estás a enfrentar atualmente?

Kelly Suter:

Neste momento, o principal desafio é conseguir que a equipa aceite a documentação de uma forma que não seja aborrecida. Quando temos um cliente e uma equipa entusiasmados, é difícil conseguir que aceitem plenamente a ideia de que não temos de abrandar nem perder o ritmo, mas temos de documentar. Depois é necessário criar modelos para essa documentação e cobrir suficientemente todos os aspetos. Não tem de ser tão penoso quanto pode parecer, mas é preciso documentar o suficiente para que, se mudarmos de equipa, formos promovidos ou assumirmos uma função diferente, toda a lógica e todo o processo não se percam.

Tenho visto equipas a reinventar constantemente a roda, tanto na criação do produto como na documentação. Muitas vezes estão a complicar demasiado algo que poderia ser transformado num modelo ou tornado mais eficiente.

Ben Aston:

Que ferramentas utilizas para gerir essa documentação?

Kelly Suter:

Para a documentação, utilizo o Google Suite e o Google Docs. É possível partilhar documentos, definir permissões para visualizar ou comentar e manter tudo num espaço partilhado. Assim não temos de nos preocupar tanto com o controlo de versões e, mais tarde, podemos exportar o documento em PDF e transformá-lo num documento formal que pode ser assinado.

O InVision é uma excelente ferramenta para rever trabalhos criativos e fazer comentários. Os designers podem colocar os seus designs ou wireframes e o cliente ou a parte interessada pode comentar. Depois, quando os designs estão finalizados, podemos anotá-los e exportá-los para a documentação. Os elementos visuais são muito úteis quando acompanhados por documentação. Se não tiver InVision, pode utilizar o Sketch, uma ferramenta gratuita que permite fazer anotações de forma simples.

Não complico demasiado o processo. Preciso de uma forma de importar os designs, anotá-los, colocá-los na documentação e escrever o texto. É isso que tem funcionado para mim.

Ben Aston:

Qual é a diferença entre um gestor técnico de projetos e um gestor de projetos digitais?

Kelly Suter:

A maior diferença é o nível de conhecimento necessário sobre o trabalho digital que está a ser realizado. Enquanto gestora de projetos digitais, geria todas as partes móveis: estratégia de conteúdos, mapas do site, wireframes, trabalho criativo e desenvolvimento. Na função de gestora técnica de projetos, estou muito mais envolvida nos detalhes do desenvolvimento. Posso acompanhar a revisão do código e as versões lado a lado com o programador responsável e perguntar: “Estes eram os requisitos que escrevi. Como se comparam com o código que está a analisar?”

A outra diferença é que escrevo os requisitos técnicos. Quanto mais próxima estiver dos requisitos, maior será a responsabilidade e mais terá de acompanhar as conversas que surgem posteriormente. Como gestora de projetos digitais, geria os requisitos e dizia às pessoas certas o que tinham de fazer. Como gestora técnica de projetos, sou eu que os escrevo. Estou, por assim dizer, mais envolvida nas trincheiras do desenvolvimento.

Ben Aston:

Como defines os requisitos funcionais e os requisitos de negócio em conjunto com os programadores?

Kelly Suter:

No início de qualquer projeto, ou quando se entra numa nova equipa ou empresa, é importante compreender claramente os papéis e as responsabilidades. Embora possam estar definidos, podem evoluir ou mudar consoante o cliente.

Posso dizer ao programador o que preciso que aconteça, mas ele pode ter de aprofundar um nível que eu não consigo alcançar ou compreender. Não posso fingir que compreendo algo que não compreendo. Prefiro dizer: “Vou assumir a responsabilidade pelos requisitos até este ponto. Pode ajudar-me a completar os restantes, fazendo as perguntas certas?”

É preciso reconhecer o momento em que se deve dizer: “Preciso que o programador me ajude a escrever o resto dos requisitos relativos a esta função, porque não consigo fazê-lo sozinho e não quero correr o risco de deixar algo passar.” É um equilíbrio que depende da comunicação e da definição clara das responsabilidades desde o início.

Ben Aston:

O que são exatamente os documentos de requisitos de negócio e de requisitos funcionais?

Kelly Suter:

A documentação de requisitos de negócio, ou BRD, é semelhante a um curso introdutório. Contém os pontos de nível superior: precisamos de traduzir isto para espanhol e mandarim; precisamos de disponibilizar dez cursos; precisamos de ter isto pronto em abril; precisamos de suportar uma base de dados de 6 000 utilizadores.

O BRD é uma verificação formal para garantir que todos estão de acordo e a avançar na direção certa. Também indica que determinados aspetos serão definidos posteriormente e que, se algo sair do âmbito ou ultrapassar o orçamento, iremos comunicar, repriorizar e decidir o que passa para uma segunda fase.

A documentação de requisitos funcionais, ou FRD, é uma etapa posterior. Cada ponto do BRD é desenvolvido com muito mais detalhe. Por exemplo, se vamos traduzir para espanhol e mandarim, temos de decidir se utilizaremos um fornecedor externo, se será desenvolvido código para automatizar o processo ou se alguém introduzirá manualmente os conteúdos no sistema de gestão de conteúdos.

O BRD confirma que estamos todos alinhados; o FRD é o projeto detalhado daquilo que será desenvolvido.

Ben Aston:

Como equilibras a documentação de requisitos com uma abordagem ágil?

Kelly Suter:

O equilíbrio começa por uma compreensão inicial do processo. É importante documentar que vamos utilizar uma abordagem ágil, explicar o que isso significa e definir o que precisamos do cliente e internamente.

Nem sempre temos tempo para documentar tudo antecipadamente. Nesse caso, definimos o objetivo final e trabalhamos semana a semana. Nas reuniões diárias, cada programador sabe em que área está a trabalhar. A cada duas semanas fazemos uma versão e uma apresentação ao cliente. O cliente sabe que aquilo que está a ver ainda não está polido; estamos a validar a funcionalidade.

As reuniões são fundamentais. O gestor de projetos pode documentar o que foi apresentado, o que se espera para a semana seguinte e quais são as questões que precisam de resposta. Assim, quando o cliente identifica algo que não corresponde às suas expectativas, há confiança suficiente para discutir o assunto e criar um plano.

Ben Aston:

Como transformas os requisitos em tarefas?

Kelly Suter:

Quando o FRD está concluído, toda a equipa o reviu e o cliente o aprovou, utilizo o JIRA para a gestão das tarefas. Algumas equipas preferem que o gestor de projetos crie as tarefas; outras preferem defini-las por si próprias. É importante perguntar à equipa qual é a sua preferência.

Crio uma tarefa para cada item dos requisitos e organizo as histórias por tipo de página: registo, página inicial, página de produto, entre outras. Depois crio subtarefas para cada item desse tipo de página. Os programadores devem estimar o próprio trabalho, idealmente as pessoas que vão efetivamente desenvolver a funcionalidade.

Se estiver a trabalhar de forma ágil e quiser que cada tarefa seja testada, inclua uma linha que indique como verificar se foi concluída com sucesso.

Ben Aston:

Como elaboras estimativas quando ainda não conheces todos os requisitos?

Kelly Suter:

Quando me pedem uma estimativa inicial, começo por perceber o que já fizemos anteriormente. Procuro projetos semelhantes em termos de dimensão, base de utilizadores ou tipo de solução e utilizo-os como referência. Uma estimativa inicial deve ser apresentada como uma faixa, não como um compromisso definitivo.

Também gosto de fazer dois exercícios. O primeiro consiste em pedir ao cliente que ordene por importância o âmbito, o prazo e o orçamento. Todos dirão que os três são igualmente importantes, mas é necessário escolher. Essa prioridade pode mudar durante o projeto.

O segundo exercício é o de bom, melhor e excelente. Se surgir uma integração ou uma funcionalidade fora do âmbito, podemos explicar o custo adicional ou indicar o que terá de ser retirado. Assim, o cliente participa na decisão e escolhe o equilíbrio mais adequado.

Ben Aston:

Qual é o primeiro passo para alguém que nunca escreveu requisitos?

Kelly Suter:

Não comece por procurar um modelo técnico e tentar preenchê-lo sem contexto. Dê um passo atrás e pense no que está a construir. Divida o trabalho nos elementos da página e pergunte: “O que faz isto? Como funciona em dispositivos móveis e em computadores?”

Explique tudo em voz alta como se estivesse a falar com alguém que não percebe de tecnologia. Depois confirme com o programador: “Estou a assumir isto corretamente?” Mesmo que faça perguntas muito básicas, o programador vai apreciar que esteja a tentar definir as coisas de forma suficientemente clara para permitir um desenvolvimento bem-sucedido.

Os requisitos consistem em fazer perguntas e transformar as respostas numa compreensão partilhada. Nada deve ser considerado óbvio. Se conseguir explicar o que está a ser construído, todos ficarão alinhados sobre o trabalho a realizar, haverá menos retrabalho e o cliente terá menos probabilidades de receber algo diferente do que esperava.

Ben Aston:

Kelly, muito obrigado por te juntares a nós. Foi ótimo ter-te connosco.

Kelly Suter:

Obrigada. Foi um prazer.

Ben Aston:

A Kelly também participa no nosso curso Dominar a Gestão de Projetos Digitais. Se precisa de formação em gestão de projetos, visite dpmschool.com. Para participar na conversa sobre requisitos, visite a secção de recursos do thedigitalprojectmanager.com e junte-se à nossa equipa no Slack, ou deixe um comentário nesta publicação. Até à próxima. Obrigado por nos ouvir.