Como impedir que as especificações de desenvolvimento mudem no meio do desenvolvimento?


61

Problema : parece que em quase todos os esforços de desenvolvimento em que estou envolvido, independentemente do tempo gasto no planejamento antes de iniciar o desenvolvimento, sempre há uma grande quantidade de mudanças necessárias no meio do caminho ou no final do projeto. Às vezes, essas são grandes mudanças que exigem muito re-desenvolvimento.

Eu não trabalho para clientes que pagam dinheiro, essa é uma equipe de desenvolvimento interna em sites de desenvolvimento interno. Então, não é como se eu pudesse cobrar por isso ou qualquer coisa. E no final do dia, temos que tentar cumprir prazos.

Perguntas : Quais são algumas das melhores maneiras que vocês encontraram para minimizar e impedir que alterações nas especificações surjam no meio do caminho ou após o desenvolvimento?


9
estabeleça um marco de congelamento de recursos no desenvolvimento e organize / negocie as coisas de forma que todas as solicitações de recursos enviadas após esse marco sejam para a próxima versão e não para a atual. Ponto-chave aqui é, naturalmente, para planejar mais de uma versão frente e compartilhar esse entendimento com os clientes
mosquito

4
@gnat Você está assumindo que o OP trabalha em uma organização onde a implantação de um marco no Congelamento de Recursos seria aceitável para as partes interessadas. Com base na experiência pessoal trabalhando em equipes de desenvolvimento internas, se eu propusesse algo assim, as partes interessadas me encarariam e diriam algo como "Quem diabos você pensa que está me dizendo quando eu posso e não posso mudar?" meus recursos solicitam por capricho? Pelo que você acha que estou pagando? Conheça o seu lugar ".
Maple_shaft

29
Você já tentou salvar as especificações em um arquivo somente leitura?
orlp

14
É claro que você cobra: cada alteração nas especificações atrasa o lançamento, portanto, sua resposta a uma solicitação de mudança deve ser uma estimativa da nova data de lançamento, se a alteração for adicionada à especificação. Quem pede a mudança é responsável pelo atraso e precisa explicá-la exatamente da mesma maneira que alguém explicaria as despesas.
Simon Richter

7
Não é por isso que o Agile existe? Você não pode congelar a especificação; portanto, faça seu processo lidar com uma especificação em mudança.
Craig

Respostas:


89

Há um famoso ditado militar, atribuído a Helmut von Moltke: "Nenhum plano de batalha sobrevive ao contato com o inimigo". Na mesma linha, não acho que seja possível fazer uma especificação que não precise ser alterada - a menos que você possa prever o futuro e ler as mentes das partes interessadas (mesmo assim elas ainda não se decidiram, mesmo que eles afirmam que sim). Em vez disso, sugiro abordá-lo de várias maneiras:

  1. Faça uma distinção clara do que pode ser mudado e do que não pode. Comunique-o claramente às partes interessadas, faça-as assinar explicitamente as coisas imutáveis ​​o mais rápido possível.
  2. Prepare-se para a mudança com antecedência. Use metodologias de código que permitam alterar as partes alteráveis ​​com mais facilidade, invista em configurabilidade, encapsulamento e protocolos claros que permitiriam que as peças fossem alteradas e substituídas independentemente.
  3. Converse com as partes interessadas com frequência, solicite feedback e aprovação. Isso manteria você em sincronia e evitaria que eles alegassem "ah, não é isso que queríamos" quando é tarde demais. Conforme observado em outras respostas, metodologias ágeis e mini-lançamentos frequentes o ajudarão nisso.
  4. Coloque na programação o tempo para acomodar as mudanças inevitáveis. Não tenha medo de dizer "precisaremos de mais tempo" mais cedo, se você pensa que sim - se o cronograma que você recebe não for realista, é melhor conhecê-lo (e você está dizendo isso) no início do que em o fim.
  5. Se as alterações forem muito extensas e ameaçarem o prazo - recue e diga algo como "essa alteração é possível, mas o prazo será adiado por X tempo, faça sua escolha".
  6. Faça um processo formal de solicitação de alterações, priorizando alterações e atribuindo alterações a versões ou liberações. Se você puder dizer às pessoas "Eu não posso fazer isso neste lançamento, mas ficaremos felizes em agendá-lo para o próximo", é muito melhor do que dizer "você está atrasado demais, sua mudança não pode acontecer , adeus "e faria deles seu amigo - eles ficariam felizes em você liberar a tempo, para que você pudesse ficar livre mais cedo para chegar ao próximo lançamento, que terá a mudança deles - e não seu inimigo.

3
Você também pode 'congelá- los ' em fases e enviar as alterações para a 'próxima versão' .
Grant Thomas

3
Formalizar o processo de mudança e ter clareza no escopo é um ótimo conselho - se você estiver executando um contrato de escopo / preço fixo. Em outras configurações, essa abordagem mói, pois fornece precedência de cronograma e preço sobre o escopo e a qualidade. Talvez seja isso que você precisa em uma determinada situação. Mas, novamente, talvez não seja ...
atrasado 26/01

3
+1 para o número 6. Tive uma excelente experiência com o PM implementando esse requisito sozinho.
27712 Joshua Drake

3
Ciclos curtos são fundamentais. As pessoas estão muito menos chateadas com o fato de algo ser empurrado para o próximo sprint de duas semanas do que quando o "próximo lançamento" estiver daqui a seis meses.
Adam Jaskiewicz 26/01

11
"investir em configurabilidade, encapsulamento" é muito, variar conselhos perigosos. Pode facilmente levar ao efeito da plataforma interna e a camadas vazias de abstração, as quais na verdade dificultam muito a alteração de um sistema. O sistema mais facilmente alterável é o mais simples.
Michael Borgwardt

40

Entregue alguma coisa (hesito em usar a palavra qualquer coisa) cedo e entregue com frequência. Ou seja - use algum tipo de metodologia de desenvolvimento iterativo.

Essa é a base do desenvolvimento Agile, mas pode ser usada com (quase) qualquer metodologia.

Ao dividir o projeto em uma série de mini-projetos, você obtém mais controle, pois pode colocar algo na frente do cliente mais cedo, não fica preso a um longo cronograma de desenvolvimento que fica desatualizado quando o cliente muda de idéia (como elas vão).

Quando eles vêem o sistema evoluir, alguns requisitos mudam, alguns se tornam redundantes e outros aumentam em prioridade. No entanto, com um ciclo de vida curto do projeto, você poderá lidar com essas mudanças.


22

A teoria de que é possível especificar completamente um projeto de software de qualquer tamanho significativo é uma fantasia completa. Verificou-se que essa teoria não funciona em organizações de grande a pequeno porte por praticamente toda a história do desenvolvimento de software.

Você DEVE encontrar uma maneira de acomodar as alterações à medida que avança! Eles vão acontecer, porque a maioria das partes interessadas, mesmo que digam 'sim, é isso que eu quero', na verdade não tem ideia do que querem até que esteja na frente delas. É por isso que temos tantas pessoas adotando métodos iterativos.

Independentemente de você repetir o produto ou o que for, você DEVE encontrar uma maneira de acomodar essas alterações, porque tentar encontrar maneiras de não ter alterações é apenas pedir para que a gravidade se desligue por alguns minutos para poder voar.


2
A NASA faz isso com alguns de seus softwares, ou pelo menos bons o suficiente para enviar ônibus espaciais para o espaço. O fato é que eles realmente seguem o modelo em cascata. As especificações estão realmente congeladas. Pelo menos esse é meu entendimento de fora da organização.
Joshua Drake

5
Já trabalhei em vários projetos em que fomos capazes de especificar completamente sistemas razoavelmente significativos (acessórios para comutadores telefônicos). A chave em todos esses casos é que estávamos direcionando para o hardware que já havia sido desenvolvido e desenvolvendo para especificações publicadas (ITU), para que nenhum deles pudesse mudar. Portanto, seu argumento não se aplica a todos os projetos - apenas 99% deles! ;)
TMN

@ TMN: Também não concordo com 99%. Eu acho que o desenvolvimento em cascata é muito, muito mais bem-sucedido do que os agilistas dão crédito. Caso contrário, não seria mais usado. A maioria dos projetos em que trabalhei foram como cascatas. A chave é definir uma linha de base, e as alterações que surgirem serão estimadas para tempo e dinheiro adicionais. O cliente decide se deve incluir a alteração ou não, e a programação e os dólares deslizam de acordo.
Dunk

11
@ Dunk: Eu sei que grande parte do nosso sucesso foi a nossa adesão a uma metodologia desenvolvida no Bell Labs. Era uma engenharia real, com rastreabilidade completa, desde requisitos a especificações, até projetos, para testar planos, codificar e testar resultados para entregas. Quando um teste falhava, era possível ver exatamente quais requisitos não estavam sendo atendidos e você sabia exatamente onde procurar o código com falha (ou design com falha). É preciso muita disciplina e supervisão para fazer a cachoeira funcionar, mas você está certo, pode funcionar bem.
TMN

11
@ TMN Gostaria de saber então qual é a chave para o sucesso. O uso do modelo em cascata ou sua abordagem disciplinada? Eu estou pensando que o mais tarde é o mais importante dos dois.
Ross Goddard

19

Não tente impedir a mudança, aceite -a. Quanto mais você planejar com antecedência, maior a probabilidade de seu plano mudar. Portanto, planeje menos , não mais. Adote uma metodologia de desenvolvimento ágil, na qual você fornece pequenos pedaços de código de trabalho com frequência, dando ao cliente a chance de alterar as especificações a cada duas semanas.


Não sei por que isso não me ocorreu mais cedo, mas a idéia de que ter código permite aceitar mudanças mais fáceis não pode estar correta. É mais fácil e menos demorado alterar alguns diagramas ou alterar o código? Especialmente quando a mudança é grande. Concordo que você não tenta impedir mudanças, basta apontar os impactos e aplicá-los de acordo com o cronograma. Os abraços ágeis não mudam mais do que métodos em cascata. Eu até acho que ele lida com mudanças pior do que a cascata, pois pode ser um pouco mais caro fazer alterações (dependendo de quando a alteração ocorre).
Dunk

6
@ Dunk Você está certo, pois é mais barato alterar um diagrama do que um código, mas como você descobre que essa mudança precisa ocorrer? Muitas vezes, isso só ocorre depois que você dá ao usuário algo para usar e ele percebe que ele comunicou a ideia errada, isso não é o que ele queria, ou existem outras coisas que ele também queria. O truque é descobrir como descobrir essas mudanças o mais rápido possível.
Ross Goddard

@ Ross: Essa é uma das razões para protótipos. Você cria uma espécie de sistema de trabalho e obtém feedback. É um mito que, em cascata, o cliente não saiba o que está recebendo até que esteja pronto. Estive em projetos que eram grandes o suficiente, nos quais a pessoa / pessoas da interface do usuário passa os primeiros meses zombando de um protótipo representativo para garantir que o cliente esteja obtendo o que deseja. Pode-se afirmar que usar o sistema real é melhor, mas se ele demorar muito mais para terminar porque o código precisa ser redesenhado com frequência, então não é uma boa opção.
Dunk

12

Você está fazendo a pergunta errada. As alterações nas especificações sempre acontecerão em projetos de desenvolvimento de software de qualquer tamanho.

Muitas vezes, é porque os requisitos de negócios mudam, mas também vi isso acontecer porque os clientes (internos ou externos) podem ter dificuldade em visualizar o que é possível sem ver algo para iterar, para que tenham uma visão que muda lentamente à medida que se envolvem com o solução em desenvolvimento.

A pergunta que você deve fazer não é "como posso bloquear as especificações", é "como posso estruturar meu código e processos para responder a um ambiente em mudança sem jogar fora tudo o que já escrevi?"

Isso leva você à arena do bingo da palavra-chave: metodologias ágeis, desenvolvimento iterativo e soluções técnicas, como codificação modular / baseada em componentes, integração contínua ... a lista continua.

Não estou dizendo que isso seja uma bala de prata para todos os seus problemas, mas todos surgiram por causa de um desejo de gerenciar a mesma situação que você está descrevendo, pelo menos vale a pena investigar.

Desculpe se isso não está oferecendo soluções concretas, mas eu acredito que uma mudança de mentalidade para aceitar e gerenciar mudanças trará dividendos maiores do que tentar evitá-las.


Sim. Para reformular a pergunta original: "Como podemos garantir que entregamos o que o cliente queria no início do projeto, e não o que ele queria no final?"
Steve Bennett

5

Uma mudança é apenas uma surpresa ... se é uma surpresa!

Sugiro pensar em:

  • De onde diabos essas mudanças vêm?
  • por que você não os conhece antes?
  • por que você não está contribuindo para essas mudanças (e potencialmente fazendo ainda mais)?

Mudança é a natureza do que fazemos. Desde quando você codificou um algoritmo exatamente como previsto no dia 1?

Mas se você deseja evitar perpetuamente ser o desenvolvedor frustrado "surpreendido" pelas mudanças, acho que precisa encontrar o caminho mais próximo da ação de onde as decisões são tomadas. Afinal, tenho certeza de que você tem um monte de idéias de como você pode melhorar o produto. Sente-se à mesa ou aceite para sempre que você terá que lidar com essas "mudanças surpreendentes".


+1 "Mudar é a natureza do que fazemos" - gosto de mudar. Mudança pode ser uma coisa boa. Isso me dá a chance de ver se minhas habilidades de design estavam boas ou não. Se a mudança causa muito trabalho, fiz um design ruim. Também oferece a oportunidade de tornar o design mais genérico. Dá uma desculpa para consertar o que você correu para cumprir o cronograma. Isso me permite voltar e consertar o lixo de outras pessoas. Basta acompanhar as solicitações de mudança e incorporá-las na agenda, para que você entregue depois da agenda original, tenha evidências para mostrar o motivo.
Dunk

4

Bem, isso é uma ligação, os clientes sempre querem mais, mas aqui estão alguns pontos que você deve considerar:

Modelos em HTML: sempre crie modelos em HTML para definir a parte da interface do usuário de um aplicativo, mostre a eles como será e solicite suas opiniões. Se você encontrar algo razoável para mudar, faça isso acontecer no protótipo HTML. Com isso, você resolverá várias coisas, como problemas de interface do usuário, fluxo básico e alguns complementos (como Classificação, Paginação, número de registros a serem exibidos etc.)


Participação ativa do outro lado: isso é muito importante se você estiver desenvolvendo para uma organização comercial, entrar nos negócios deles e pedir que eles esclareçam suas dúvidas.


Liberação modular: libere seu código de forma modular, libere, teste, obtenha feedback e libere novamente.


4

É por isso que é quase impossível planejar com muita antecedência, mas não é uma desculpa para não planejar. Não se apaixone muito por seus planos e não terá que se preocupar com eles partindo seu coração.

Dentro da sua empresa, há um custo no uso dos recursos de TI, independentemente de alguém o admitir, acompanhar ou ter que fazer um orçamento para isso ou não. A realidade é que sua equipe pode criar tanto código em um determinado período de tempo. Todos os departamentos e projetos estão compartilhando esse orçamento.

Você não pode impedir que alguém queira alterar os requisitos, mas eles não podem escapar das consequências. As alterações podem aumentar significativamente os tempos de desenvolvimento. É um fato que eles precisam lidar ou decidir não fazer a mudança. Uma solicitação de um departamento afeta outro? Pode ser necessário mover completamente o projeto para outros departamentos, pois a solicitação de alteração invadirá o cronograma de outro grupo.


4

O envolvimento ativo do usuário ao longo do ciclo de desenvolvimento e o uso da maior metodologia possível, realmente nos ajuda com nossos produtos.

As alterações nas especificações são inevitáveis, mas, ao serem transparentes com os usuários e, sobretudo, consultá-las com frequência significa que a maioria das alterações é capturada o mais cedo possível.


3

Para mim é bem fácil.
Diga a ele, o "Dono do produto" , que solicitou os recursos que está correto, mas ele precisa escolher alguns dos recursos planejados que ele poderia ficar sem nesse prazo.
Pense nisso como uma reunião de meio sprint com o OP, onde você diz a ele que o sprint não queimará até 0.

Ps. Se não for o "PO", eu diria que não fale comigo, vá até o "PO"


1

Quais são algumas das melhores maneiras que vocês encontraram para minimizar e impedir que mudanças nas especificações surjam no meio do caminho ou após o desenvolvimento?

Não há melhores maneiras. Cabe à gerência limitar as alterações às especificações em determinada fase do desenvolvimento.

No entanto, você deve projetar seu software de forma a esperar as alterações. Então o impacto das mudanças seria muito menor. Desenvolvimento iterativo e incremental é um bom começo.


1

Descobri que, direta ou indiretamente, os clientes são a causa da maioria das alterações (e também dos bugs mais críticos, BTW). Portanto, a solução óbvia é eliminar os clientes. (Que bom eles são afinal?)


:) Se os clientes quiserem uma personalização maluca, pagarão com dinheiro e tempo. Se o pessoal de vendas absolutamente tiver que fazer promessas de oferecer recursos que ainda não existem na maioria das vezes em que faz uma venda, a empresa tem um problema maior: ela tem muitos concorrentes e não está no topo de seu jogo, por exemplo, Fornecedor de banco de dados SyBase. Ele se tornará irrelevante como empresa ou precisará de um CEO e deputados revolucionários.
Job

1

Como você não pode impedir a mudança, é necessário adotá-la. Acho que a coisa mais importante que você pode fazer é: você precisa receber as solicitações de alteração do cliente o mais cedo possível , porque é menos dispendioso alterar as coisas quando há pouco código. Portanto, você precisa apresentar seu projeto o mais cedo possível ao cliente usando protótipos (talvez até um protótipo de papel), usar métodos ágeis e assim por diante.


1

Você pode considerar introduzir alguma disciplina no processo de desenvolvimento usando uma metodologia como SCRUM. No SCRUM, uma equipe faz um plano inicial dividindo a implementação de recursos em histórias e atribuindo a cada história uma estimativa de esforço (número de horas ou dias úteis necessários para implementar essa história).

Se uma alteração tardia for solicitada (para uma história que já foi implementada), você precisará criar uma nova história e estimar o esforço de implementação. Depois, você pode ir ao seu gerente (o proprietário do produto ) e simplesmente explicar que o novo recurso custará esse tempo extra. O gerente de projeto tem a responsabilidade de aceitar o esforço extra e ajustar o cronograma (possivelmente cancelando outras histórias ainda não implementadas).

Mesmo que sua equipe não implemente totalmente o SCRUM ou outro processo de desenvolvimento, você pode pelo menos introduzir o planejamento com base em histórias , estimar o esforço de desenvolvimento para cada história e ajustar o cronograma à medida que novas histórias forem solicitadas.


0

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Passei muitas noites após o trabalho estressado e infeliz, porque outro sujeito não entende nem se importa com o funcionamento dos negócios de software. Não tenho problema em confrontar alguém de cima, mas não tenho o apoio de meus colegas nerds. Ter filhos é uma merda, não é? Eu provavelmente vou sair em breve.

Francamente, eu gostaria que os programadores em geral tivessem mais bolas. Vamos olhar para isso:

"" "Não trabalho para clientes que pagam dinheiro, é uma equipe interna de desenvolvimento em sites de desenvolvimento interno. Portanto, não é possível cobrar por isso ou qualquer coisa. E no final do dia, nós temos que tentar cumprir prazos. "" "

Se você estava lidando com um cliente pagador de dólares e se cobertas por um contrato (http://vimeo.com/22053820?utm_source=swissmiss), as alterações nas especificações custariam a esse cliente mais tempo e mais dinheiro ( ou potencialmente igual ou menos tempo, mas exponencialmente mais dinheiro). Sua empresa está tentando mudar as especificações sem incorrer no custo de mais tempo e mais dinheiro.

Nesse meio tempo, tentar cumprir prazos causa um estresse desnecessário a você e seus colegas de trabalho; você não pode passar um fim de semana de qualidade com amigos / família. É realmente desnecessário, porque quem está jogando trabalho para você provavelmente nem o conhece, o que é triste.

Minha solução proposta: coletivamente, tem a coragem de enfrentá-los e explicar que não há almoço grátis e tudo custa, que um mecânico de automóveis levaria mais tempo e cobraria mais se as especificações fossem alteradas no meio do trabalho, que uma agência contratadora levaria mais tempo e cobrar mais se as especificações foram alteradas no meio do trabalho, e há uma boa razão para isso. Se eles não estiverem dispostos a trabalhar com você de uma maneira razoável, você, como um grupo, se levantará e sairá, e eles terão que contratar desenvolvedores que possam pegar o projeto onde ele foi deixado e entregar dentro do prazo.

Depois, há também uma promessa de desenvolvimento ágil, que não implica prazos rígidos.

Ainda estou para ver os programadores entrarem em greve, mas isso teria sido alguma coisa. Gerentes incompetentes são muito abundantes em empresas de software. Muitas pessoas querem algo por nada, no Craigslist ou dentro de uma empresa real. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Os programadores precisam ter mais bolas.


0

Uma abordagem que eu descobri que funciona bem (não com todos os gerentes obviamente) é "Acho que posso fazer isso, sim. Depende - quanto tempo extra você está atribuindo a este projeto? É uma mudança bastante importante que você está solicitando ".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.