Definição do escopo do projeto

Atividades relacionadas - definição do escopo do projeto

Em projetos com atividades sequenciadas (em cascata), a definição do escopo é realizada pelo gerente de projeto. Em projetos ágeis, é realizada pelo dono do produto (product owner). O processo inclui atividades como:

■ A1. Examinar em profundidade os objetivos do projeto a partir das demandas do cliente (ou de seu representante), os problemas que o site procura resolver, os processos que atualiza. (Ver Objetivos do projeto (briefing))

É importante estimar o valor que o projeto vai criar e avaliar aspectos como:

◊ Estratégia web do site ou, se for o caso, do conjunto de sites aos quais está integrado, como será lançado, como vai evoluir. (Ver Estratégia web e Linhas de ação relacionadas à estratégia)

◊ Retorno sobre o investimento aplicado (valorização da imagem organizacional, número de acessos, veiculação de publicidade, número de usuários cadastrados, vendas de produtos, criação de produtos).

◊ Competitividade do site no ambiente de negócios (concorrentes, parceiros, clientes, ambiente político mais amplo, etc.)

-> Um site que oferece arquivos de músicas ou gravações de palestras ou conferências precisa se adaptar ao uso de dispositivos móveis, para que, no carro ou andando na rua, o usuário encontre rapidamente um arquivo.

O acesso a arquivos sonoros via dispositivos digitais conectados é um desafio ainda em aperfeiçoamento. É difícil recuperar informações como músicas com mais de um autor, ou que pertençam a mais de um gênero. A indústria fonográfica está criando padrões para a criação e inserção de metadados nos arquivos sonoros.

◊ Enfoque editorial inovador ou conservador, popular ou não do preparo do conteúdo.

◊ Comunicação e interlocução do site com os usuários.

-> Por exemplo, um site que oferece serviços de impressão de fotos digitais pode precisar se adaptar às necessidades dos usuários de armazenar e indexar as fotos online.

O uso de bibliotecas de fotos personalizadas levou à criação de sites como o Flickr, que atende à necessidade dos usuários de armazenar e encontrar fotos dentro do conjunto de suas fotos digitais.

■ A2. Examinar os recursos para realizar o projeto, como tempo, pessoas e verbas. Se desde o início os recursos forem subestimados ou se os prazos de entrega das primeiras versões forem muito curtos, é melhor lidar com estas limitações no início, e não quando o produto já estiver mais desenvolvido e mudanças nestes aspectos forem interpretadas como rompimento do acordo inicial.

A linha do tempo do projeto mostra em perspectiva como o produto deve evoluir ao longo do lançamento de cada versão, semanal, quinzenal ou mensalmente, e o valor de negócios de cada uma.

■ A3. Estabelecer uma visão geral do produto final e definir o nome do projeto. (Ver Visão geral do escopo - modelo resumido)

■ A4. Realizar uma ou mais reuniões com os principais stakeholders (opcional), incluindo a equipe de desenvolvimento, para clarificar a visão sobre o produto, criar consenso entre os integrantes e estabelecer os limites da atuação. Neste encontro, pode-se discutir alguns requisitos (features) de alto nível para o produto.

■ A5. Elaborar o product backlog, com os requisitos dos principais produtos do projeto que tenham funcionalidades genéricas com valor claro para o cliente. É preciso examinar caso a caso a necessidade de desenvolver, nesta lista de requisitos, os itens do project charter. (Ver mais em Product backlog - modelo genérico)

Outras atividades relacionadas à definição do escopo:

■ Preparar o escopo para mudanças e adaptações. Na prática de métodos ágeis como o Scrum, redefine-se constantemente o escopo nas reuniões de planejamento, em especial nas reuniões de planejamento inicial de cada sprint, em que se procura atualizar o project backlog.

Assim, na medida em que o dono do produto (product owner, cliente) tenha revisado, testado e aceito a última versão realizada, faz alterações no escopo, ou no product backlog para que este se adapte à nova percepção do produto. O ambiente externo também pode mudar e exigir a reformulação dos problemas de negócio originais, com novas soluções.

■ Prever as ressalvas ou produtos não contemplados pelos escopo do projeto, de modo a evitar mal-entendidos em relação aos produtos que serão desenvolvidos.
Texto publicado em 23.11.2008.

Assuntos relacionados
► Mudanças do escopo
► Abordagens do escopo
► Elementos do Termo de Abertura do Projeto
► Visão geral do escopo - modelo resumido
► Estratégia web
► Recursos disponíveis
► Cronograma
► Testes

Referências
► Agile contracting, de Jen Girdish (Projects@Work acesso em 15.1.2008)
► Twelve emerging best practices for adding UX work to Agile development, de Jeff Patton (AgileProductDesign.com, acesso em 12.1.2009)
► The sotware project manager´s bridge to agility, de Michelle Sliger e Stacia Broderick. Arquivo PDF com trechos do livro com este nome (Informit, acesso em 23.11.2008)
► Livro: Mirando resultados - uma metodologia para planejamento e gestão de projetos de e-business, de Ricardo Almeida e Marcelo Oliveira. São Paulo: Novatec Editora, 2002
► Risks of quantitative studies, de Jakob Nielsen (AlertBox, acesso em 26.8.2005)

Mais informações sobre o assunto (links externos)
► Bringing user centered design to the agile environment, de Anthony Colfelt (boxesandarrow, 31.1.2010, acesso em 19.3.2010)
► Micro scope, de Mike Donoghue (Gantthead, acesso em 2.11.2008)
► Successful web development methodologies, de Martin Bauer (SitePoint, acesso em 16.4.2006)
► Between the lines, James A. Bahensky (Projects@Work, acesso em 23.12.2005)
► Experience IS the product... and the only thing users care about, de Peter Merholz (Core 77, acesso em 7.6.2007)
► Risks of quantitative studies, de Jakob Nielsen (AlertBox, acesso em 26.8.2005)
► Five common errors in requirements analysis (and how to avoid them) (TechRepublic, 1.2.2007)

• Quem somos
• Glossário
• Receba o boletim mensal