Meio Bit - Scope Creep: Projetos que mudam DEMAIS durante o desenvolvimento - O cliente é o inimigo? - Comentários

Re: kotter disse:você ficou

Tuco — Sun, 06 Apr 2008 00:12:47 +0000

Google Docs?

Re: acdesouza disse: As

acdesouza — Sat, 05 Apr 2008 22:34:47 +0000

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

Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvolvim

bazaglia — Sat, 05 Apr 2008 12:39:13 +0000

É 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

acdesouza disse: As

Ricardo Bicalho — Sat, 05 Apr 2008 03:45:43 +0000

acdesouza disse:

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.

kotter disse:você ficou

Ricardo Bicalho — Sat, 05 Apr 2008 03:34:36 +0000

kotter disse:

você ficou traumatizado com essa história de excel, fala a verdade Bicalho.

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.

Re: Mas vc adapta a metodologia

anibalsolon — Fri, 04 Apr 2008 23:06:07 +0000

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!

Nem todo projeto se encaixa

carloshp — Fri, 04 Apr 2008 22:04:00 +0000

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.

Re: Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvo

carloshp — Fri, 04 Apr 2008 21:59:36 +0000

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.

Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvolvim

kotter — Fri, 04 Apr 2008 21:46:25 +0000

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.

Mas vc adapta a metodologia

avontz — Fri, 04 Apr 2008 21:23:08 +0000

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

Bicalho, As metodologias

acdesouza — Fri, 04 Apr 2008 21:00:34 +0000

Bicalho,

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

Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvolvim

TheDarkMaster — Fri, 04 Apr 2008 20:40:48 +0000

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

Re: Re: DICA: Projeto pequeno/médio

wallck — Fri, 04 Apr 2008 19:50:17 +0000

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

Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvolvim

EulerGui — Fri, 04 Apr 2008 19:46:06 +0000

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

Re: Scope Creep: Projetos que mudam DEMAIS durante o desenvolvim

Rodmalkav — Fri, 04 Apr 2008 19:28:59 +0000

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

Scope Creep: Projetos que mudam DEMAIS durante o desenvolvimento - O cliente é o inimigo?

Ricardo Bicalho — Fri, 04 Apr 2008 16:42:46 +0000

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