Lidando com especificações ruins / incompletas / pouco claras? [duplicado]

42

Estou trabalhando em um projeto no qual nossa equipe de desenvolvimento obtém as especificações da parte de negócios da empresa. Tanto o gerenciamento de negócios quanto o gerenciamento de TI exigem estimativas e projeções de prazo, como deveriam.

O bom é que as estimativas são feitas principalmente pelos desenvolvedores reais que conseguem fazer os recursos necessários. O ruim é que as especificações geralmente são muito simples (você fica com muitos pontos de interrogação em sua cabeça porque muitas informações parecem estar faltando) ou muito complexas (até o ponto em que você pode até visualiza onde tudo se encaixa no aplicativo). Na maioria das vezes, a parte de negócios das especificações está incompleta ou inconsciente do que pode e não pode ser feito (dada a lógica de negócios implementada anteriormente).

A equipe de desenvolvimento recebe um dia por nova especificação para fornecer uma estimativa e nós tentamos eliminar as incertezas, geralmente encontrando quem fez a especificação. Na maioria das vezes, os autores de especificações não pensaram realmente em tudo, e geralmente é só quando começamos a projetar e desenvolver que acabamos em apuros, já que muitas especificações parecem ter buracos.

Como você lida com isso? Você é generoso em estimativas antecipadamente?

    
por eagerMoose 27.01.2011 / 21:54
fonte

12 respostas

12

Se você está encontrando problemas durante o estágio de design, você realmente tem um problema?

Certifique-se de que aqueles que criam as especificações não sintam que precisam fazer tudo na frente. Eles não podem pensar em tudo e nem nós podemos. Eles também precisam saber que não podem simplesmente fazer uma noite inteira em algum documento específico e, em seguida, concluir o projeto. Essa prática também faz com que eles adicionem cada pequena coisa em que possam pensar, porque "podem" precisar e, se não perguntarem agora, vão conseguir. Eles precisam estar disponíveis para revisar, testar e aprovar seus requisitos repetidas vezes.

Não tente projetar ou criar o aplicativo inteiro de uma só vez. Qualquer projeto / aplicativo pode ser dividido em algum tipo de fases, partes, módulos ou o que eles quiserem chamar. Você não precisa ser ágil se isso não é sua coisa. Comece com a peça de segurança do usuário e vá de lá.

Arranje tempo para se sentar com essas pessoas e descobrir o que elas realmente querem. Eu adoraria que alguém me entregasse especificações que me permitissem criar todo o projeto de uma só vez, mas o que eu faria no próximo ano e meio?

    
por 28.01.2011 / 01:30
fonte
20

Eu uso o Cone da incerteza Diga com uma voz estrondosa

Basicamente, você faz a melhor estimativa para fornecer as informações que você tem.
Mas você também ressalta que, dada a imprecisão nas especificações, há uma alta incerteza nessas estimativas (gerenciamento do ponto no local para que eles possam ler o princípio).

À medida que avança em direção ao alvo e aumenta as especificações, é possível atualizar sua estimativa e aumentar a incerteza.

    
por 27.01.2011 / 22:01
fonte
9

Sim, sou generoso com estimativas. Não se esqueça da lei de Hofstadter

Lei de Hofstadter: Leva sempre mais tempo do que o esperado, mesmo quando se leva em conta a lei de Hofstadter. De Gödel, Escher, Bach: Uma Trança Dourada Eterna.

    
por 27.01.2011 / 22:17
fonte
6

O processo que você está descrevendo é realmente normal. O problema é que os tipos de negócios tendem a pensar nas coisas em termos de "fase de requisitos", "fase de design" etc. Quando uma equipe está criando um produto, você realmente precisa de uma abordagem iterativa. Algumas ideias que encontrei são:

  • Defina os principais objetivos para as alterações propostas / novo aplicativo. Essas são metas relacionadas a negócios como "reduzir o custo de processamento de solicitações em 10%" ou "compartilhar pesquisas de mercado de nossos escritórios satélites para que os produtos melhorem as necessidades de nossos clientes". Isso ajuda a trazer foco para requisitos abertos sobre quais são as necessidades reais.
  • Faça o seu SWAG inicial (Seriously Wild-A ** Guess) para os requisitos ruins à medida que eles são escritos, mas documente o que você assumiu que a implementação será. Este é o feedback que as pessoas de negócios (e seu cliente) precisam para melhorar e pensar sobre essas coisas. Eles estão confiando em você por eles.
  • Se você tem uma escolha entre uma estimativa muito longa e uma muito curta, sempre vá muito. Provavelmente vai chocar quem está pedindo para você fazer o trabalho, o que é uma coisa boa. Isso forçará vocês dois a discutir o que eles realmente são depois.

Lembre-se de que sua primeira estimativa não pode ser exata. Baseie suas estimativas em interpretações razoáveis dos requisitos obtidos e documente suas suposições / interpretações. Haverá mais requisitos derivados por causa dos buracos que você descobriu. Isso é normal.

    
por 27.01.2011 / 22:15
fonte
3

Ser generoso em estimativas pode parecer bom, mas que problema isso resolve? Não melhorará a especificação, não facilitará o planejamento. Está dizendo 'não pode ser muito pior que X', ao invés de dizer 'pode ser Y'. A verdade é que você não sabe. Descubra o que você pode.

Se os analistas de negócios precisarem envolver desenvolvedores mais cedo, informe-os. Um relatório escrito não é realmente o melhor método de comunicação. Se você puder ter uma ajuda do desenvolvedor com a coleta de requisitos iniciais e um analista de negócios ajudando com o desenvolvimento e o teste, seus resultados serão melhores.

Acabei de ler o Cone of Uncertainty; é bom, mas é fácil errar. A gerência pode olhar a primeira foto e dizer: 'ok, nós temos os requisitos de negócios, então sua estimativa deve ser com 50% de precisão de acordo com o seu cone. Conte-me'. Isso não vai ajudar.

Analogia do carro: alguém pergunta quanto custa um carro e lhe dá um papel com os requisitos dele. O jornal diz que deve pesar cerca de 1200 kg, ter quatro rodas e pelo menos duas portas, mas talvez quatro, devem acomodar quatro pessoas, e bons faróis são realmente importantes. A cor deve ser cinza (mas o preto também é possível?).

Você pode dizer $ 25K, e se acontecer mais tarde, ele quer um novo Range Rover que você está ferrado. Isso não o torna mais correto, ou mais útil dizer que custa US $ 100 mil. Ele pode precisar apenas de um Prius usado (desculpe, usado). Se você não tem tempo para descobrir o que, você nunca saberá.

    
por 28.01.2011 / 00:26
fonte
2

Most of the times it turns out that spec writers haven't really thought everything through, and it's usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.

O uso de mais está incorreto.

Não é possível para os criadores de especificações pensarem em tudo . Período. Se eles pensassem em tudo , saberiam quantas linhas de código escrever e quais linhas de código estavam corretas.

Como a especificação deve estar incorreta, não há muito o que fazer sobre isso.

O acaba com problemas é o problema.

Both the business management and the IT management require estimates and deadline projections, as they should.

Talvez não. Estimativas e prazos gerais não são as coisas mais úteis.

Daí o desenvolvimento de métodos ágeis.

O ponto é este. Todas as estimativas baseadas em especificações devem ter erros. Eles só estão certos pela sorte. Metade do tempo, a estimativa está abaixo e metade do tempo que a estimativa está acabando. Essa é uma consequência lógica de tentar prever o futuro com informações incompletas.

Já que isso tem que acontecer, você não deve acabar com problemas quando estiver errado. Você tem que estar errado. E você tem que estar consistente e aleatoriamente errado. Caso contrário, você está falsificando os números.

    
por 27.01.2011 / 22:18
fonte
1

Você deve explicar à gerência que, com especificações vagas, há baixo grau de confiança na estimativa. Ou seja, você estima que pode variar em 30% ou 40% ou 50% ou o que você pensa. Então, se algo é estimado em 2 dias, na verdade é um intervalo de 2 a 3 dias.
Em seguida, crie um registro de problemas de projetos (pode estar em um wiki ou Jira, etc.). Crie todas as suas perguntas como problemas e faça com que a empresa responda à sua pergunta. Enquanto uma questão permanece não resolvida, a estimativa permanece incerta. Se possível, faça com que um analista de negócios seja conduzido para facilitar isso e fazer melhores exigências. Peça à equipe de teste para revisar as especificações, pois elas precisam criar casos de teste em relação às especificações. Muitas vezes, seu envolvimento pode levar a escrever melhores especificações. Informe diário / semanalmente ao gerenciamento de quantos problemas não resolvidos você tem. Quanto mais resolvido, melhores serão suas estimativas. Sempre apresente métricas para o gerenciamento, já que os números os fazem pensar objetivamente e o coloca em terreno firme também. Além disso, dependendo do tamanho do projeto, coloque 1-4 semanas para a fase de projeto da solução, onde você discute os principais problemas (requisitos e técnicos). Ter muitos workshops com PMEs de negócios e tentar entendê-los e, por sua vez, explicar seus pontos de vista para chegar à conclusão. Somente após os principais casos de uso terem sido compreendidos e suas estimativas atingirem cerca de 80% de confiança, você deve proceder para o estágio de criação.

    
por 27.01.2011 / 22:44
fonte
0

Lembre-se de que, toda vez que a especificação é alterada para adicionar novas funcionalidades ou para esclarecer dúvidas, é hora de rever a estimativa. Não é tanto que nossa estimativa original seja ruim, dado o que nos disseram, mas que não recuamos e dizemos não, precisamos disso quando mais detalhes forem disponibilizados. Se eu fosse um empreiteiro construindo uma casa e eu estimasse o custo com base no uso de uma bancada lamiante e um mês depois o cliente quer um granito, você pode apostar que eu estaria revisitando a estimativa de custo com ele. Nós deixamos nossos clientes escaparem com os requerimentos de má qualidade e, em seguida, não recuar quando acontece que há muito mais coisas para fazer do que o previsto originalmente.

    
por 27.01.2011 / 22:23
fonte
0

Por que você aceitaria uma especificação de requisitos que está incompleta, contém requisitos conflitantes ou é inviável? Eu recomendaria que o seu processo inclua uma maneira de avaliar as especificações e enviá-las de volta para as correções antes de aceitá-las e fornecer estimativas.

    
por 30.01.2011 / 04:17
fonte
0

Convencer a gerência / cliente que vale a pena investir em melhores especificações. Tente envolver mais pessoas com conhecimento de domínio . No final, todos irão lucrar com isso.

    
por 30.01.2011 / 04:47
fonte
0

Elimine as especificações.

Convença os negócios a experimentar o Agile (ou pelo menos um processo Agile-ish) para um projeto.

Em vez disso, escreva as especificações

  • reunir-se com as pessoas de negócios para identificar recursos
  • trabalhe com eles para identificar o conjunto mínimo de recursos / funções que seriam úteis (mesmo que apenas para uma versão interna)
  • cardar o trabalho
  • defina uma data para o trabalho (quanto menos recursos / trabalho, mais fácil deve ser estimar com precisão uma data).
  • trabalhe com os negócios para priorizar o trabalho, certifique-se de que eles tenham a capacidade de mudar de idéia sobre a ordem dos cartões, dizer como isso afeta a data
  • com cada recurso concluído, o sistema de trabalho deve ser exibido para que eles sejam exibidos e concluídos em cada parte do trabalho, conforme é feito
  • lançamento
  • enxaguar
  • repita

Exibindo recursos à medida que são concluídos. Liberte cedo e frequentemente. Seja transparente e responsivo. Descobri que isso levará à eliminação de prazos inúteis.

Editar para arquitetura

Quem é o líder deve ter uma reunião inicial para comunicar aos desenvolvedores qual deve ser a arquitetura. O líder também é realmente a pessoa que deve devido diligência para se certificar de que todas as necessidades estão sendo atendidas.

Se você precisar de etapas adicionais em seu processo do que adicioná-las. Há um processo para facilitar a capacidade da equipe de realizar o trabalho. Se algo não está funcionando, mude isso. Adicione a ela, remova-a e altere-a para atender às suas necessidades. Se você precisa estar especialmente preocupado com a segurança, adicione etapas para isso.

    
por 29.01.2011 / 07:54
fonte
0

A comunicação geralmente ajuda, pelo menos em uma organização saudável.

Isso não é uma bala de prata, mas o que tentei fazer (e funcionou na nossa empresa) é convencer os empresários a explicar o problema, em vez de sugerir uma solução imediatamente. Portanto, nossos pedidos de recursos começam com uma descrição do problema ou da meta que eles desejam alcançar.

Então, um desenvolvedor com algum conhecimento de domínio tenta desenvolver uma solução, enquanto consulta com alguém do lado comercial das coisas. Normalmente, esse processo produz várias soluções alternativas, completas com estimativas.

Cabe aos negócios, neste momento, escolher um com base no custo e na conclusão de uma solução. É também assim que você pode vender esse método para eles, que aqui eles têm opções, não apenas um número de mandays, pegar ou largar. Claro, também precisa de mais recursos do seu lado, mas se você está tendo problemas com estimativas e especificações, é um investimento que vale a pena.

    
por 30.01.2011 / 20:29
fonte