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 sobre atividades da definição do escopo do projeto
► Make this independent contractor agreement your own (CreativePro, acesso em 4.7.2010)
► 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)