Metodologia de Gestão de Projetos Definir o escopo de um projeto e a gerência de seus requisitos

Definir o escopo de um projeto Produto: Documento pode se chamar Proposta de Projeto, Visão Geral do Projeto, Anteprojeto, Estudo Preliminar ... Modo de fazer: Estabelecer com o cliente quais os requisitos do projeto que resolvem o problema ou aproveitam a oportunidade Meta: Obter aprovação preliminar do documento pela gerência superior e uso de recursos para fazer o plano completo Equipe: normalmente só o gerente do futuro projeto com os clientes.

Definir o escopo de um projeto Cinco componentes do documento Problema ou oportunidade Objetivo Geral do Projeto Objetivos Específicos do Projeto Critérios de Sucesso Pressupostos, Riscos e Obstáculos

Definir o escopo de um projeto Problema ou oportunidade Conhecimento da área onde o projeto será desenvolvido Requisitos do cliente Interesses da corporação Requisitos mandatórios Condições de satisfação do cliente

Definir o escopo de um projeto Problema ou oportunidade Exemplo Laptop de US$100 – Nicolas Negroponte (MIT) Presidência da República no Brasil – OK 30 dias para montar grupo de trabalho etc 3 anos depois, o que aconteceu? Programa "Um computador por Aluno"

Definir o escopo de um projeto Laptop de US$100 Quem vai distribuir as máquinas? Suporte técnico? Treinamento de professores? Geração de conteúdo? Reposição? Controles? Verba para os N x US$100? etc

Definir o escopo de um projeto Laptop de US$100 Após quase um ano do início do leilão, Governo espera distribuir notebooks para escolas em 2010, mas não promete que chegarão para início do ano letivo. A notícia de que o resultado dos testes sairá em 15 dias vem a público quase um ano após a realização do leilão, que ocorreu em 17/12/2008.

Exemplo O processo licitatório foi vencido pela Comsat, fornecedora dos laptops da indiana Encore, que ofereceu cada notebook por R$500. Após três meses paralisado, por determinação do Tribunal de Contas da União (TCU) para investigar supostas irregularidades, o leilão foi retomado em março/2009. No mesmo mês, o Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (InMetro) deu início a testes dos equipamentos e o resultado, negativo, foi divulgado em setembro.

Exemplo Com isso, a segunda colocada do leilão, Digibrás, passou à primeira colocação, com uma oferta final de 82.485.000,00 reais, o equivalente a um custo de R$550 por laptop. Este valor foi apresentado em 02/10/2009. Os testes de aderência desses equipamentos ficaram marcados para 13/10/09. O leilão prevê a compra de 150 mil laptops educacionais. Em 14/12/09 a empresa foi classificada para a entrega dos laptops. A vitória da Digibrás foi divulgada pelo FNDE. Nada mais havendo a declarar, foi encerrada a sessão no dia 23 de dezembro de 2009, cuja ata foi lavrada e assinada pelo Pregoeiro e Equipe de Apoio. Você teria previsto que o projeto passaria por tudo isso?

http://www.uca.gov.br

No fim das contas, computadores não vão salvar a educação Idealizado em 2005 pelo pesquisador Richard Negroponte, o computador educacional OLPC XO-1 foi criado com a nobre intenção de levar a tal da revolução digital a salas de aula de países pobres ao redor do mundo. Fonte: http://www.jornaldoempreendedor.com.br/empreendedorismo-na-web/novidades-pela-net/no-fim-das-contas-computadores-nao-vao-salvar-a-educacao?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jornalempreendedor+%28JORNAL+DO+EMPREENDEDOR%29 Em 11/04/2012 Mas, distribuído desde 2008 e com 2,5 milhões de unidades espalhadas em 42 países, ele parece não ter efeito revolucionário na educação dos locais em que está presente, pelo menos na opinião do Banco Interamericano de Desenvolvimento (BID).

No fim das contas, computadores não vão salvar a educação De acordo com a instituição, o computador não melhorou o desempenho dos estudantes das escolas públicas do Peru, país que tem uma das educações mais deficientes do subcontinente. No levantamento, foram pesquisados os resultados de alunos de 319 escolas do país. Os números mostram que o uso do OLPC não representou qualquer melhora nos índices de aprendizado de línguas ou matemática em relação às crianças que dispunham de uma educação “convencional”, com lousas tradicionais e giz. Fonte: http://www.jornaldoempreendedor.com.br/empreendedorismo-na-web/novidades-pela-net/no-fim-das-contas-computadores-nao-vao-salvar-a-educacao?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jornalempreendedor+%28JORNAL+DO+EMPREENDEDOR%29 Em 11/04/2012

No fim das contas, computadores não vão salvar a educação Além disso, os OLPC não representaram ganhos de atenção e aumento de tempo dedicado a tarefas escolares dentro ou fora de sala de aula. Mesmo carregados com 200 livros, também não aumentaram os índices de leitura: em média, cada criança leu apenas cinco livros em casa nos últimos 15 meses. “Foi sugerido que o uso de computadores iria aumentar a motivação dos alunos, mas os resultados nos apontam em outra direção”, diz o relatório do Banco. Relatório em http://idbdocs.iadb.org/wsdocs/getdocument.aspx?docnum=36706954

No fim das contas, computadores não vão salvar a educação Os resultados foram similares a levantamentos feitos por outras instituições a respeito do uso de computadores em sala de aula. Desde 2007 o estado norte-americano do Maine adotou a política de um laptop por aluno, e até agora os estudantes não apresentaram diferenças notáveis de desempenho. A constatação mais notável dos levantamentos sobre o uso de computadores em sala de aula foi feita em 2010 pelo governo de um estado australiano, que constatou que “liderança é crucial” no uso de tecnologias em salas de aula. Ou seja, para terem sucesso em sala de aula, alunos equipados com computadores precisam, olha só, de bons professores. Fonte: http://www.jornaldoempreendedor.com.br/empreendedorismo-na-web/novidades-pela-net/no-fim-das-contas-computadores-nao-vao-salvar-a-educacao?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jornalempreendedor+%28JORNAL+DO+EMPREENDEDOR%29 Em 11/04/2012

Definir o escopo de um projeto Objetivo Geral do Projeto Ser claro quanto ao alvo Estabelecer indicadores de progresso Estabelecer realisticamente o que pode ser feito com os recursos disponíveis Estabelecer quando o objetivo pode ser atingido - duração do projeto

Definir o escopo de um projeto Objetivo Geral do Projeto Características da sentença definidora do objetivo: 1. Uma saída / produto - o que vai ser obtido 2. Um prazo - uma data em que deve estar concluído / atingido 3. Uma medida - a métrica que vai determinar o sucesso 4. Uma ação - como o objetivo vai ser atingido

Definir o escopo de um projeto Objetivos Específicos do Projeto Estabelecer o mais detalhadamente possível quais são os objetivos específicos É uma abertura do objetivo geral em itens que caracterizam aspectos que devem ser atingidos pelo projeto para que o objetivo geral seja cumprido.

Definir o escopo de um projeto Critérios de Sucesso Objetivo do critério de sucesso - o que deve acontecer para nós e o cliente dizermos que o projeto foi um sucesso? Devemos partir das Condições de Satisfação que definirão, de modo geral, as bases de um critério de sucesso O critério de satisfação do cliente e da equipe do projeto precisam ser ajustadas e isso não é necessariamente fácil Mensurabilidade.

Definir o escopo de um projeto Critérios de Sucesso Expressos em termos de aumento de margens, lucros crescentes, redução de tempo de produção, melhoria de produtividade, diminuição de custo de fabricação, sempre em valores tangíveis para a empresa.

Definir o escopo de um projeto Critérios de Sucesso Se não for possível usar aquele critério: Alternativa é ter algo quantificável sobre o efeito do projeto, uma qualidade do produto entregue como ganho de eficiência ou eficácia, redução de índice de erros, tempo de resposta no atendimento, algum impacto positivo na qualidade ou satisfação do cliente.

Definir o escopo de um projeto Pressupostos, Riscos e Obstáculos Tecnológicos Meio ambiente Interpessoais Culturais Relações de causa e efeito

Definir o escopo de um projeto Adendos ao documento proposto Análise de risco Riscos Financeiros Estudos de Viabilidade Análise de Custo e Benefício - as dificuldades ou vantagens causadas pelos intangíveis Análise de ponto de equilíbrio: breakeven point Retorno de Investimento

Definir o escopo de um projeto Análise de Custo e Benefício 1. Definir o problema com clareza 2. Descrever as condições de contorno do problema - o que é e o que não é o escopo do problema 3. Descrever as características e funcionalidades de uma boa solução 4. Identificar soluções alternativas 5. Ordenar soluções alternativas 6. Estabelecer recomendações com o raciocínio que orientou as suas escolhas 7. Prover uma estimativa do tempo e dos custos esperados

Definir o escopo de um projeto Aprovação da proposta - critérios Qual a importância do problema para a empresa? Quanto o projeto está relacionado com os fatores críticos de sucesso da empresa? O objetivo geral está relacionado diretamente com o problema?

Definir o escopo de um projeto Aprovação da proposta - critérios Os objetivos específicos são representações claras do objetivo geral? Há suficiente valor para o negócio como medido pelos critérios de sucesso para garantir recursos para este projeto? Está claramente estabelecida a relação entre os critérios de sucesso e os objetivos?

Definir o escopo de um projeto Aprovação da proposta - critérios Os riscos são elevados em relação aos benefícios para o negócio da empresa neste projeto? A gerência superior da empresa pode reduzir riscos identificados? Admitindo aprovada a proposta, fazer o planejamento detalhado O primeiro passo é definir as atividades do projeto.

Gerência de requisitos Conceituação Requisitos funcionais Requisitos não funcionais Requisitos inversos Restrições de projeto e de implementação Requisitos não técnicos Ambiguidade na definição dos requisitos Questões úteis Também adaptado de Gerência de Requisitos - O principal problema dos projetos de software José Roberto Blaschek

Gerência de requisitos Conceituação OK Requisito é uma condição ou capacitação necessária a um usuário / cliente / mercado para solucionar um problema ou alcançar um objetivo. É uma condição ou capacitação que um produto ou serviço precisa atender ou ter para satisfazer um contrato, padrão, especificação ou outro documento formalmente estabelecido.

Gerência de requisitos Conceituação Requisito é uma função, restrição ou outra propriedade que precisa ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do futuro sistema. A importância dos requisitos O que está contratado O que o cliente / mercado precisa O que deve ser obedecido O que é essencial no fornecimento

Gerência de requisitos Conceituação Aos requisitos estão associados os principais problemas do desenvolvimento de projetos. Quando não refletem as reais necessidades dos usuários, estão incompletos e /ou inconsistentes, haverá mudanças em requisitos já acordados e a dificuldade para conseguir um entendimento comum entre usuários e executores são as principais dificuldades relatadas, provocando retrabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes.

Regras de negócio São as decisões que regem uma organização, compreendidas por políticas recomendadas e obrigatórias que governam a interação entre empregados, clientes, fornecedores e sistemas automatizados. Expressões em diferentes níveis Informal ou textual “Todo cliente deve que ter mais de 18 anos.” Técnico Idade.cliente >= 18

Requisitos funcionais Requisitos funcionais especificam o que o produto deve ser capaz de executar Podem ser definidos: do ponto de vista dinâmico: comportamento quando executado em circunstâncias determinadas do ponto de vista estático: funções desempenhadas por cada entidade e a maneira como elas interagem

Requisitos funcionais É importante ressaltar que os requisitos descrevem “o que o produto deve fazer” - e também “o que ele não deve fazer” - sem dizer “o como fazer”. Quando o requisito é expresso em termos do seu comportamento, este item deve ser possível de ser percebido por um observador externo ao ambiente.

Requisitos não funcionais precisão confiabilidade segurança desempenho rentabilidade manutenabilidade disponibilidade recuperabilidade proteção usabilidade

Serviços “na nuvem” exigem cuidados extras perante a lei Planos de continuidade do negócio. Legislação do país sede do servidor do serviço. A preocupação que a computação em nuvem traz é a exposição inevitável de dados sensíveis no caso de a empresa acabar sendo investigada por um motivo qualquer. A infraestrutura está fora do controle da empresa, ela não tem como questionar a Justiça. E, com ordem judicial, a empresa terceira entregará os dados sem resistência.

O integrador contrata serviços de outros fornecedores A quantidade de partes é muito importante porque normalmente há mais do que um envolvido. Pode ser uma boa solução num primeiro momento, com potencial para se transformar em uma enorme dor de cabeça se houver a necessidade de um questionamento jurídico por quebra de contrato.

O integrador contrata serviços de outros fornecedores Preocupações na hora de assinar os contratos: onde estão os fornecedores; que atividades vão realizar; que tratamento darão aos dados da empresa; que nível de controle os clientes terão sobre seus dados; como será possível acessar os dados em caso de falência do fornecedor, ou suspensão de serviço, por atraso de pagamento, ou exigência judicial, como no caso do Wikileaks.

Requisitos inversos Significam o que o produto não deve fazer A questão da ambiguidade das funcionalidades A questão dos limites e a importância de não se deixar uma expectativa falsa sobre o que o produto vai fazer.

Restrições de projeto e de implementação São condições que limitam como o produto poderá ser implementado Representam condições que deverão ser obedecidas pelos projetistas e na implementação do projeto Estas restrições podem ser de limitações do tempo, espaço, custo, ambiental, equipamento, processos, legislação, ética, tecnologia etc

Requisitos não técnicos Acordos Condições contratuais Representam limitações para a gerência do projeto, como prazo, recursos humanos e orçamento do projeto, datas, legislação, etc.

Ambiguidade na definição dos requisitos Requisitos incompletos Palavras de significado impreciso Custo da ambiguidade (exemplo para SW) Requisitos 1 Projeto 3-6 Fabricação 10 Testes de desenvolvimento 15-40 Testes de aceitação 30-70 Operação 40-1000 Fonte: Barry Bohem - Software Engineering Economics

Boas práticas Documentar Uma vez compreendidos, analisados e aceitos, os requisitos devem ser documentados com um nível de detalhamento adequado, produzindo a especificação. São boas práticas da documentação de requisitos a adoção de formulários adequados para coleta de dados e registro da especificação dos requisitos; a identificação das fontes de informação; a atribuição de um rótulo para todos os requisitos e o registro das regras de negócio.  

Boas práticas Validar Após terem sido documentados, é necessário que os requisitos sejam cuidadosamente validados, principalmente quanto à consistência e a completude. Esta atividade visa identificar problemas nos requisitos, antes do início da construção. A importância desta atividade é caracterizada pelo fato de que a correção de um erro nesta fase possui um custo muito inferior do que a correção nas fases mais adiantadas do processo de desenvolvimento.

Boas práticas Na validação dos requisitos podem ser utilizadas técnicas para inspeção e revisão da especificação de requisitos; redigidos casos de testes a partir dos requisitos e definidos os critérios de aceitação do produto. prazo? custo? qualidade?

Boas práticas Seleção de um modelo de ciclo de vida apropriado, Elaboração do plano do projeto com base nos requisitos - é comum começarem sem sequer terem escopo definido; Renegociação dos compromissos tão logo se perceba que eles não possam ser cumpridos, Gerenciamento dos riscos associados a requisitos e a criação de condições para que os requisitos possam ser rastreados ao longo do projeto.

Questões Úteis Quem é o cliente? O que uma solução muito bem-sucedida significa para este cliente? Qual é a razão real para desejar solucionar este problema? Devemos usar uma equipe de projeto com quais características? Qual o prazo que temos para fazer o projeto? Onde mais pode ser obtida solução para este problema?

Questões Úteis Podemos copiar algo existente? Que problemas este produto resolve? Que problemas este produto pode criar? Que ambiente este produto provavelmente encontrará? Qual o grau de precisão necessário ou desejado ao produto? Quais os aspectos relevantes do problema a resolver? Quem são as pessoas certas para responder as perguntas?

Questões Úteis As respostas dadas são oficiais? Os requisitos estão sendo documentados e obtidas as aprovações de quem os forneceu? É possível ver o local onde se processam as ações do processo? Existe algo mais que possa ser perguntado para esclarecer o funcionamento do processo e evitar ambiguidades? Há incoerências entre as respostas?

Questões Úteis Quais os outros processos que se relacionam com esse? Como este processo é relacionado com outros? Quais os resultados do projeto que são fundamentais para sua avaliação positiva? Quais os indicadores do processo? Quais os produtos intermediários do processo?

Qualidade na indústria A melhoria da qualidade de produtos e processos, em todo o mundo, tem decorrido da adoção de normas e padrões de referência que, garantido a confiabilidade do produto adquirido, têm protegido mercados, assim como o consumidor final, de fraudes ou danos de naturezas diversas. O sucesso das normas ISO é o seu melhor exemplo. Proteção à indústria de software BENITO PARET   A melhoria da qualidade de produtos e processos, em todo o mundo, tem decorrido da adoção de normas e padrões de referência. Essas normas ou padrões não só têm garantido a confiabilidade do produto adquirido como têm protegido mercados, assim como o consumidor final, de fraudes ou danos de naturezas diversas. O sucesso das normas ISO é o melhor exemplo disso. A certificação de produtos, processos ou serviços é indicação evidente do grau de desenvolvimento de uma economia. No ano passado foram emitidos, no mundo, 561.690 certificados pela série ISO 9001. O Brasil participa com menos de 3% deste total, e a área de Tecnologia da Informação (TI), com pouco mais de 450 certificados. Isso evidencia a falta de padrões organizados numa área de tecnologia de ponta, vital para o funcionamento da economia, do serviço público e das instituições. O Brasil tem tomado iniciativas para melhorar o padrão de qualidade de processos e produtos na área de software. Em dezembro de 2002, a Sociedade Softex instalou um grupo de trabalho com a participação de universidades, centros de pesquisa e entidades empresariais. Como resultado, foi criado o MPS.BR, sigla do modelo denominado “Melhoria do processo de software brasileiro”. É um modelo inspirado nos padrões ISO 12.207 e 15.504 e foi elaborado com processos semelhantes aos definidos pelo Capability Maturity Model Integration (CMMI), o modelo de qualidade de processos de software adotado pelas empresas americanas. A principal vantagem de se ter desenvolvido um modelo brasileiro é o custo das avaliações. O CMMI é um modelo proprietário e não custa menos de US$ 25 mil, podendo chegar a US$ 100 mil, dependendo da complexidade do processo avaliado. Um custo inviável para a maioria das empresas nacionais. O MPS.BR também é um modelo proprietário, que se propõe a realizar avaliações nos moldes do CMMI, mas a um custo muito mais acessível. Como o CMMI, não fará certificações, mas avaliações por critérios que seguem padrões de exigência internacional, sem valor legal, já que não é uma norma obrigatória, o que prenuncia uma disseminação lenta e limitada. O CMMI só foi consagrado pelo mercado americano porque o Departamento de Defesa passou a exigir maior confiabilidade dos produtos que adquiria e encomendou à Carnegie Mellon a criação de um modelo de avaliação pelo qual deveriam passar as suas compras. Esse modelo foi posteriormente adotado por outros países como a Índia, importante fornecedora mundial de desenvolvimento de programas. Criar um modelo nacional é uma forma de quebrar o monopólio do CMMI no mercado brasileiro. Outros países já buscaram alternativas. O México, na América Latina, é um bom exemplo. Em 2004 aquele país criou uma norma própria e obrigatória, o Moprosoft, como maneira de proteger sua indústria do poder econômico das empresas americanas, que só precisavam atravessar a fronteira para abocanhar o mercado. Criar uma norma brasileira não equivale a nenhuma reserva de mercado, mesmo porque a lógica seria diferente, já que qualquer multinacional poderia se ajustar às normas definidas, por serem aderentes aos padrões internacionais. O Brasil precisa trilhar o caminho da qualidade para conquistar a respeitabilidade no cenário mundial, mas temos que definir se queremos uma norma legal de uso obrigatório ou apenas um modelo recomendado. Qualquer que seja a opção escolhida, após uma discussão ampla e democrática, não pode demorar. As empresas brasileiras pagam muito caro pela falta de instrumentos de certificação local, num mercado cada vez mais global e competitivo. BENITO PARET é Membro do Conselho de Administração da Sociedade Softex, Diretor Executivo da Riosoft e presidente do Sindicato das Empresas de Informática do Rio de Janeiro. Fonte: Globo Online http://oglobo.globo.com/jornal/opiniao/189845093.asp

Metodologias... SMART Specific (específico) Mesurable (mensurável) Achievable (alcançável) Realistic (realista) Time bound (limitado pelo tempo)

Por que fazer um protótipo para o produto a prover? Uma experiência dos anos 70...

Como o cliente explicou ... Como o líder de projeto entendeu ... Como ficou o projeto ... Como o cliente explicou ...

Como o consultor de negócios o descreveu Como foi construído

Como o projeto foi documentado O que foi cobrado do cliente Funcionalidades implantadas ...

Como foi mantido ...

O que o cliente queria!