Assine
21900 assinantes- Feeds completos
- Feeds dos comentários
- Feeds do fórum
- Receba o Meio Bit via e-mail
Fórum
Últimos tópicos no fórumÚltimas respostas no fórum
- Listagem de DDD, Operadores, e Prefixos de Celular no BR
- HD com amnesia!
- Windows Server 2008 Standard 60-day trial
- montar computador para jogos.
- mp9: vale a pena comprar ?
- O Dia em que a Terra Parou - Remake
- Sequestro de DNS - Agora é a Brasil Telecom...
- Encontraram o Padre Baloeiro ....
- Da pra iniciar carreira em TI depois dos 35 anos?
- Windows para Eee PC 4G
- Blogueiro iniciante, o que faço pra melhorar meu blog e dar mais visibilidade!!
- Fuji ou Canon
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
Categorias
Áudio Vídeo Fotografia
Análise
Anúncios
Apple e Mac
Artigo
Blog
Celular
Computação móvel
Comunicação Digital
Destaque
Dicas
Download
Entrevista
Games
Google
Hardware
Indústria
Internet
Linux
Miscelâneas
Open-Source
Periféricos
Podcast
Produtividade
Propaganda & Marketing
Publicidade
Seguranca
Software
Tutorial
VoIP
Web 2.0
Wireless e Redes
Scope Creep: Projetos que mudam DEMAIS durante o desenvolvimento - O cliente é o inimigo?
Enviado por Ricardo Bicalho
em 4 Abril, 2008 - 13:42
Você acaba de ser chamado para participar de um novo projeto. A tecnologia a ser usada, será de ponta, já que o cliente deseja alterar uma aplicação e pediu, especificamente, para usar o que há de mais moderno.
O problema é que o prazo está curto demais e o Gerente Noçãoless™, prometeu que tudo seria feito dentro do prazo acordado, com o desenvolvimento iniciando-se imediatamente. E como o tempo é curto não foi especificado direito o que a entrega deveria conter. E como o sistema precisa estar pronto para ontem, não é feito um protótipo de tela. O código começa a ser feito imediatamente, com base em vários "print screens" fornecidos do sistema anterior.
Feito o pagamento inicial, a equipe começa a desenvolver algumas telas, código de acesso à base de dados e quando já se passaram 20% do tempo, já existe uma versão funcional do sistema. O mundo é perfeito e estão todos felizes, mesmo virando algumas noites e perdido 2 ou 3 finais de semana. Chega o dia para mostrar 1 mês de trabalho duro...
E a primeira coisa que o seu cliente diz é: "Cadê o gráfico em pizza e a importação/exportação para Excel?". A primeira coisa que se passa pela cabeça do desenvolvedor é: "PQP!" ou "[Frase auto-censurada, o Meio Bit é um blog família]!". Com tantas outras funcionalidades e componentes complicados que deram um trabalhão, o cliente se preocupou com algo nunca antes mencionado. O gerente noçãoless entuba tudo e diz que isso estará feito na próxima entrega, antes do prazo final. Entubar é o termo técnico usado em tecnologia para aceitar tudo e qualquer coisa, sem avaliar custo, tempo, recursos e ainda com areia. Só há um problema: ninguém JAMAIS havia mencionado gráficos em pizza ou importação/exportação de planilhas até aquele momento.
O requisito do projeto mudou e o ciclo se repete a cada entrega. O prazo final se aproxima, e por mais que a equipe se esforce, a quantidade de pedidos cresce semanalmente, sempre faltando alguma coisa. A interface muda o tempo todo também, com mais e mais recursos "essenciais" sendo requisitados. Muitas vezes, pessoas diferentes pedem funcionalidades conflitantes. Enquanto a atenção é fortemente focada em pontos como esse, a criptografia de arquivos, importantíssima, ficou de lado.
O Scope Creep, que poderia ser traduzido de diversas formas como escopo arrastado, deformação de escopo, escopo movediço. Para quem está começando na área, escopo de projeto é uma espécie de lista do que será entregue, e ainda mais importante, uma lista do que não será. É um documento simples, que define limites do que deve ser feito e uma vez que ele está fechado, você terá um prazo e custo. Mudanças são necessárias e serão pedidas, mas se elas saírem de controle, você terá um frankensoft, um cliente insatisfeito e nenhuma compensação/reconhecimento pelo esforço,
Moral do Post:
- Ninguém deve achar nada em um projeto. Converse bastante com as pessoas responsáveis por usar o seu programa e anote suas expectativas.
- Nada de prazos-mandrake: a perda de confiança irá minar completamente futuros projetos.
- Coloque tudo em papel, assinado por 3 pessoas, com visto em todas as páginas. Por menor que seja o seu projeto, ele precisa de um acordo mínimo.
- Se o escopo mudar, avise-o sobre prazo e custo: você não está fazendo um favor, mas prestando um serviço profissional.
- Crie, junto com o seu cliente, uma lista de prioridades. Se ela mudar, avise-o sobre prazo e custo.
- Não tenha medo de informar que aquele botãzinho novo para mandar arquivos "com senha" irá demorar 200 horas para ser criado e testado. Aproveite as reuniões para redefinir as prioridades.
- Lembre-se: não é preciso usar metodologias complexas para evitar problemas. Um simples e-mail pode evitar enormes dores de cabeça depois.
Fonte: Bicalho´s Memory About Fraked Up Projects
- Ueba
- Rec6
- entre com seu usuário e senha ou registre-se no site para enviar comentários
- Envie esta página
Notícias relacionadas
Conexão
Opções de conexão
Entrar
Mais comentados
- A última liberdade do Administrador de Sistemas (151)
- CPI da pedofilia ameaça fechar o Google (115)
- O caos na cidade de São Paulo (101)
- Juiz exige que YouTube entregue TUDO! (93)
- 1/4 do Mundo estará online em 2012. Grande coisa. (77)
- A última cartada da Motorola (67)
- Microsoft descobre que as Ilhas Fiji estão 14 anos no passado (59)
- Salsas e Caretas (XVII) (59)
Extreme Programming também é algo bem interessante a se estudar, principalmente caso o cliente se interesse por tecnologia de ponta.
______________________________________________
"É uma cilada Bino"
Meus US$0.02 sobre Extreme Programming:
Particularmente, eu acho XP uma metodologia que não se aplica à realidade da maioria dos projetos de médio e grande porte, por um motivo muito simples: ela assume que o cliente é um "parceiro", que está "do lado" do desenvolvedor, que compreende e vai participar de forma proativa do levantamento dos problemas e etc. Se tem uma coisa que eu sei é que, tanto no setor corporativo como no público, o cliente trata as equipes de análise e desenvolvimento (principalmente se forem terceirizadas) como adversários. O objetivo do cliente nestes casos é invariavelmente arrancar o máximo pagando o mínimo no menor prazo possível. Daí eu achar que adotar o XP (que é uma metodologia que despreza fortemente documentação formalizada e análise intensiva ANTES de qualquer codificação em prol de fazer vários ciclos de prototipagem-validação-alteração) para lidar com um cliente que age como eu descrevi acima, é simplesmente fatal. Neste caso, a única coisa que pode deter essa sanha enlouquecida do cliente de alterar e empurrar novas funcionalidades é o bom e velho termo de aceite do escopo dos requisitos iniciais, feito após uma boa análise e assinado pelo próprio.
Mas note bem: não quer dizer que XP não se aplique à nenhum cenário. Pequenos projetos desenvolvidos por equipes internas da organização, ou mesmo desenvolvimento de jogos podem ser candidatos mais adequados ao uso de XP. E também não quer dizer que não se aproveite nada da metodologia XP: o conceito de desenvolvimento em dupla e revisões pares tem benefícios indiscutíveis seja qual for a metodologia adotada. Apenas ele está longe de ser a "bala de prata" que resolveria qualquer problema, como foi vendido até algum tempo atrás.
---
Tecnologia deve ser o meio, não o fim.
Meu conhecimento é XP é mais alguns cases que li da http://www.thoughtworks.com . Supondo que eu fosse o Gerente de um grande projeto, dificilmente eu escolheria também trabalhar com XP. Documentado e assinado é muito mais seguro(ainda mais para quem conhece a capacidade do ser humano(usuário) em pedir funcionalidades na entrega de produto, seja ele qual for.
Sobre cooperação com cliente, acho que TI vai acabar virando uma mega guerra de cracha.
Mas obrigado pela resposta e desculpe não dar um retorno tão embasado.
______________________________________________
"É uma cilada Bino"
Mas vc adapta a metodologia a suas necessidades...seguir 100% a risca vc fica com um peso morto nas mãos..
Você também pode usar Scrum para isso.. ou seja.. usa a melhor parte de cada metodologia..
*******************************
Música eletrônica + atitude -> sabotagem.org
Como Freud concluiu que precisa criar uma abordagem para cada paciente na psicanalise, precisamos criar metodologias diferentes que se adequem a cada projeto
--
You don't know the powa of da geek side!
Gerente Noçãoless é ótimo! tem a versão NoNotion, também.
------
Vaca amarela, pulou a janela.
Nossa nem me fale, isso acabou de aconetecer aqui, o cliente me passou dados iniciais e disse que a unica coisa que falta me passar era um pequeno detalhe nas formulas matematicas, quando recebi a formula descobri que o projeto todo deveria ser jogado no lixo e refeito já que mudava todo o foco e o processamento das informações.
Nunca mais caio nessa.....
_____________________
Muita Pimenta para sua vida!
Primeiro Pro-Commenter da Blogosfera Brasileira.
A parte de levantar requisitos a partir de conversas com cliente é mesmo uma etapa terrível... mas extremamente importante. Estou curtindo essas suas memórias de projetos fraked, vai ser um aprendizado e tanto!
http://giseli.wordpress.com
Resumindo: Isso é o básico da organização.
Essa parte do "ainda com areia" foi ótima!
Eu me via nos seus relatos! Só rindo pra não chorar!
--
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
EDIT: Mais um post no lugar errado. Desculpas.
______________________________________________
"É uma cilada Bino"
DICA:
Projeto pequeno/médio => XP
Projeto grande/gigante/MOR => Dimensione o sistema com PF (pontos de função) e PCU (pontos de caso de uso), compare o resultado de ambas e tome uma decisão mais próxima da realidade.
Adepto Lordware
http://www.lordware.com.br
wallace@lordware.com.br
O problema é que sem requisitos e escopo bem definidos qualquer projeto pequeno pode ficar enorme.
Acho que XP é válido se o cliente ou usuário contratar na modalidade Time & Materials, aí o escopo do projeto é controlado pelo tamanho do bolso dele.
yawara.br além da tecnologia.
Depende muito a experiência da equipe. XP é uma "coisa" que quanto mais XP (mod game on) melhor!
Mas é interessante ver um confronto direto, acesse a entrevista com Alex Prado abaixo, muito interessante:
http://www.lordware.com.br/2008/03/31/entrevista-c...
Adepto Lordware
http://www.lordware.com.br
wallace@lordware.com.br
Isso acontece aqui mas de uma maneira um pouco diferente. Os projetos de onde trabalho são focados em pesquisa, sendo assim o escopo nunca é bem definido mesmo. Porém, temos uma metodologia bem desenvolvida para controlar alterações ao escopo e até mudanças radicais (quando os próprios resultados obtidos ao longo da pesquisa mostram que são necessárias mudanças no projeto, por exemplo).
O perigo é quando o próprio pesquisador que propôs o projeto perde o foco e o escopo vai mudando de uma tal forma que fica totalmente diferente do inicial. Tal situação já culminou em projetos cancelados.
Agora, lendo o post e os comentários me veio Scope Crap na cabeça
.
Se descobrir que está caindo na loucura, Mergulhe
Realmente... tem horas que não há nada melhor que um papel assinado.
De uns tempos pra cá eu entrei numas de pedir para o cliente colocar no papel exatamente o que ele quer que seja feito... tudo na linguagem dele e como ele espera ver funcionando. Com essa "ferramenta" em mãos eu começo a discutir com o cliente sobre os itens que ele descreveu para realmente entender tudo que ele quer e como ele quer e, depois disso, faço um pequeno contrato tendo como ANEXO-I o tal papelzinho passado à limpo e assinado pelo cliente e por mim. Rapaz... isso foi uma maravilha pra mim!!!! Em alguns casos perde-se um tempo danado no início, mas depois de tudo acertado e o projeto iniciado, é tranquilidade até o fim!
Téchne Lógos
http://blog.euler.eti.br
Não considere isso perder tempo. Pelo contrário, isso é ganhar bem mais à frente, justamente evitando as surpresas mencionadas no artigo. Quando o cliente vê o resultado disso, ele passa a confiar mais no que você fala e faz. É bom para todos.
---
Tecnologia deve ser o meio, não o fim.
O meu atual projeto nunca ficará "pronto" hehehe, é uma criatura em constante evolução. Mas felizmente o cliente está ciente disso, ele vai fazendo os pedidos de funcionalidades e eu conforme o tamanho de cada um vou fazendo-os na hora (se é algo pequeno e não têm nada já em andamento) ou vou fazendo "pacotes" e vou entregando estes pacotes aos poucos para aí ele poder fazer novos pedidos. Em suma, é um constante mudar de funções mas ao menos todas as partes envolvidas estão cientes das consequências para os prazos e etc.
Se você consegue ler esta mensagem então o seu computador irá se auto-destruir em dez segundos, tenha um bom dia
Bicalho,
As metodologias ágeis, como Scrum e Extreme Programming, dizem que não é possível avaliar tudo o que precisa ser feito antes de começar o desenvolvimento. A idéia é que não dá para prever o futuro. Você concorda com isso?
A sugestão para o problema, é definir um espaço fixo de tempo, como duas semanas, e negociar funcionalidades a serem desenvolvidas, testadas e entregues neste período. Desta forma, o cliente pode avaliar o desempenho da equipe de forma mais gradual, ele terá funcionalidades úteis no final deste tempo e poderá decidir se continua ou não com o projeto. O que você acha desta abordagem?
[],
AC
Nem todo projeto se encaixa neste modelo. Frequentemente o cliente quer (e precisa) de prazos e custo determinados de antemão para justificar o projeto perante suas gerências/diretorias/whatever. Apresentar uma estimativa de 2 em 2 semanas simplesmente não é uma opção. Daí eu dizer que XP não atende o perfil da maioria dos projetos corporativos e governamentais de médio/grande porte. Novamente, não quer dizer que XP não possa ser aplicado com sucesso em outros cenários.
---
Tecnologia deve ser o meio, não o fim.
As metodologias ágeis, como Scrum e Extreme Programming, dizem que não é possível avaliar tudo o que precisa ser feito antes de começar o desenvolvimento. A idéia é que não dá para prever o futuro. Você concorda com isso?
Concordo, com ressalvas. Mudança de escopo faz parte de qualquer projeto. O que muda é a forma como o profissional lida com a mudança. E é isso que essas metodologias todas pregam: formas de gerenciar mudanças.
O Extreme Programming é bom em partes. Por exemplo, prototipação de projetos, é possível usar essa metodologia para criar propostas. O pair programming na resolução de bugs e refatoração do código é bastante eficiente.
Eu gosto, particularmente, de uma metodologia chamada ICONIX. A maioria das empresas adota ele sem saber, pois é o meio termo entre o Extreme Programming e o RUP.
Pelo o que eu já vi do Scrum ele tenta criar, no início, uma lista de funcionalidades que o cliente deseja. Esta lista servirá de base para o Product Backlog.
E é do Product backlog que saem as funcionalidades a serem implementadas a cada duas semanas. Assim o cliente possui uma visão melhor do que ele está pedindo e os desenvolvedores do que ele pode querer.
O que você pensa sobre esta abordagem?
[],
AC
você ficou traumatizado com essa história de excel, fala a verdade Bicalho.
muito bom o post, e principalmente as dicas no final do texto.
se você não elabora um 'contratinho' e coleta assinaturas em cada etapa, não conversa com o cliente e etc, com certeza a culpa não é do cliente, é toda sua.
algumas etapas de projetos parecem muito chatas e as vezes inúteis, principalmente o planejamento. mas essas coisas chatas e inúteis que garantem o bom andamento das coisas.
Já tive minha cota de dores de cabeça com sistemas legados tendo que dar suporte completo ao Excel. Inclusive ouvir de clientes: "o que eu quero, de verdade, é o Excel funcionando no Internet Explorer." Dois meses de trabalho depois.
Google Docs?
É mais difícil, mas por vezes a coisa pode se inverter: combina-se algo relativamente detalhado, assina-se contrato, são feitos os pagamentos iniciais, e a empresa contratada para o desenvolvimento acaba relaxando, e a solicitação de cada item não implementado acaba soando como pedido de favor...
:: bazaglia