Os requisitos ideais estão voltando

Em partes passadas

Na primeira parte, anunciei uma série de artigos sobre o trabalho do analista no pré-projeto. Ele listou os problemas, soluções e princípios que você precisa lembrar ao iniciar um projeto de TI.

Na segunda parte, falei sobre os problemas frequentes do pré-projeto.

No último post, discutimos a primeira parte dos princípios básicos:

• O design dos sistemas de TI e a classificação dos produtos de TI.
• Níveis do modelo V e ciclo de vida do sistema.
• Uma olhada no sistema como um ativo financeiro.

Nesta nota, terminaremos com uma descrição de "como fazer", para discutir melhor o que fazer se não funcionar corretamente.

O que você aprenderá com esta nota:

• No cone das fases de incerteza e design.
• Sobre como funciona a avaliação.
• Sobre o escopo completo das tarefas da fase de pré-projeto e os valores realizados ao mesmo tempo.
• Sobre como obter recursos suficientes para um pré-projeto.

Se não quiser esperar as próximas partes do ciclo, assista ao vídeo do meu relatório, com base no qual esta série de artigos está escrita.

Ciclo de vida do sistema e cone de incerteza

O Cone da Incerteza é um dos conceitos centrais do design e do gerenciamento de projetos modernos. A essência do conceito: quanto menos informações tivermos, maior será a incerteza que pode ser expressa na forma de um spread nos termos e no custo do projeto.



Cada fase da construção de um sistema remove parte da incerteza. Ao passar por fases típicas de um projeto, a incerteza diminui exponencialmente:

• Quando temos uma ideia expressa em um resumo de meia página, a dispersão no custo e no retorno pode atingir várias ordens de magnitude.

• Quando existem requisitos de negócios, enquanto o plano ou modelo de negócios é desenvolvido, reduzimos o spread no custo / retorno ao pedido.

• Para reduzir ainda mais a dispersão, você precisa tomar decisões importantes sobre a aparência e o design do sistema. Este estudo reduz a propagação para metade da ordem. Apesar de a dispersão ainda ser grande, uma análise da relação entre retornos e custos dá a principal decisão - se vamos construir um sistema ou procurar algo mais rentável.

• Ao especificar as condições sob as quais o sistema será construído (quem o fará e em que prazo), podemos reduzir a propagação do custo a valores que podem ser trabalhados com o uso de métodos de gerenciamento de projetos, reservas e tratamento de riscos. As condições especificadas são registradas na declaração de trabalho.

• Somente o projeto técnico fornece uma estimativa quase precisa com um erro aceitável para os negócios.

O que segue a seguir:

• Do ponto de vista da alocação de recursos, precisamos ter tempo para reduzir o projeto antes de gastar uma parcela significativa do custo se ele deixar de ser lucrativo. As fases do resumo ao projeto técnico devem ocupar uma pequena fração do custo total do sistema.

• Você também precisa entender que não pode ter uma ideia e definir imediatamente o custo. Quando você é informado de que existem 20 milhões aqui e isso é certo, tendo apenas um resumo - não acredite, não é.

• Os requisitos de negócios e o desenvolvimento conceitual precisam ser feitos, pois removem a incerteza, mas isso pode não ocorrer se o projeto não for iniciado. Como resultado, as fases devem ser o mais baratas possível, mas aliviar a incerteza de uma maneira de qualidade.

Como funciona a avaliação?

Existe um equívoco comum que impede o lançamento normal do trabalho pré-projeto: se não podemos fornecer rapidamente uma avaliação precisa, não devemos nos preocupar com os requisitos. Isto não é verdade. A soma de estimativas imprecisas, mais precisamente, é um fato da teoria das probabilidades.



Nesse caso, o estudo de pré-design deve dividir o sistema e o plano de trabalho em várias dezenas de partes comparáveis, e a avaliação de cada parte deve ser feita por analogia ou por um método mais preciso. A soma das classificações terá um spread menor que cada classificação individual.
Se a qualidade do estudo conceitual não nos permite obter uma divisão do sistema em partes aceitáveis ​​para avaliação, não reduzimos a dispersão da avaliação e não há sentido em nos conectar com esse estudo.

As fases do projeto, do ponto de vista do modo de avaliação, são as seguintes:

• Quando há uma ideia expressa em um resumo de meia página, somos capazes de avaliar por analogia.

• Quando elaboramos os requisitos de negócios, o plano de negócios ou o modelo de negócios, podemos destacar os principais parâmetros do sistema e realizar uma avaliação por analogia, usando um fator de grande escala.

• O conceito divide em várias dezenas de partes e obras, o que permite resumir as estimativas feitas por analogia e calcular o principal plano de gerenciamento de riscos.

• Os termos de referência substituem a avaliação de partes do sistema por analogia com as obrigações dos fornecedores por tipo de trabalho. As estimativas de peças feitas por analogia são convertidas em estimativas de especialistas. Os riscos de erro na avaliação são repassados ​​aos fornecedores.

• O design técnico permite dividir o sistema em centenas e milhares de partes, cada uma avaliada com habilidade ou com o uso de estatísticas sobre a implementação de projetos anteriores.

Se a essência descrita acima não estiver definida no trabalho de pré-design, é melhor não fazê-lo. Para obter uma redução real da incerteza, é necessário não apenas aumentar a espessura do pacote de documentação do sistema, mas também garantir que sejam estabelecidos requisitos e soluções mensuráveis ​​e viáveis.

Outra idéia comum é: "Os requisitos de negócios não devem ser mensuráveis". Lembre-se - isso é uma mentira!

O que você precisa alcançar no pré-projeto

Nas partes anteriores, isso foi mencionado em termos de problemas. Agora repita brevemente quais tarefas devem ser definidas e concluídas em qualquer pré-projeto:

1. Entenda o tempo e o custo para planejar custos e tomar uma decisão de ir / não ir. É aconselhável prever o efeito e retornar para acelerar esta decisão.
2. Para vender o sistema:
   
   
   • Mostre ao cliente uma compreensão de seus objetivos.
   • Mostre aos usuários a solução para seus problemas.
   • Conclua com êxito o lance para o orçamento (ele está sempre lá).
3. Para criar uma base de aceitação (um contrato para o volume e a qualidade do resultado é uma tarefa técnica), não se esqueça de colocar no plano a validação do sistema resultante do ponto de vista da justificação prática das expectativas de todas as partes.
4. Decida sobre os recursos: tipos, etapas, cronogramas, volumes de trabalho e fontes de recursos para confirmar as estimativas dos executores e fixar o custo do sistema.

Se essas tarefas não forem definidas explicitamente e sua solução não for planejada, é melhor não perder tempo - esse projeto pode ter êxito apenas por acidente.

Por que não pode (ou mesmo não pode) funcionar

Como resultado de todas as considerações anteriores, temos três condições conflitantes:

1. A análise de pré-design precisa ser feita rapidamente.
2. A análise de pré-design deve ser feita de forma barata.
3. A análise de pré-design deve ser feita qualitativamente.

Quem conhece a regra do triângulo do design entende que isso não acontece.

Existem algumas dificuldades adicionais:

1. A análise pré-projeto pode mostrar um baixo retorno sobre a solução proposta, e isso não será interessante para o cliente e o patrocinador.
2. Uma análise pré-projeto pode aumentar o volume do projeto ou o custo total de propriedade em relação às premissas iniciais, e isso novamente se tornará desinteressante para o cliente e o patrocinador.
3. A análise pré-projeto pode reduzir o volume do projeto com relação às premissas iniciais, e isso geralmente não é interessante para o contratado externo.

Em conexão com todas essas dificuldades, quero que você e eu entendamos uma coisa: os problemas do pré-projeto são insolúveis se não apoiarmos o patrocinador e não considerarmos o projeto de TI como um ativo financeiro.

Nos comentários anteriores ao artigo, a opinião foi expressa: “O pré-projeto deve ser aberto o mais cedo possível, mas deve-se ter em mente que o escopo do pré-projeto é limitado por sua eficácia. Esse pré-projeto é considerado eficaz, após o qual o projeto será lançado. Este é o principal indicador-chave da eficácia do pré-projeto. ” (c) WizardryIB

Esse é um ponto de vista bastante comum entre os gerentes de projeto, porque se algo lhe é confiado, você deve se matar, espremer uma equipe até a última gota, virar os braços para os fornecedores antes de quebrar, estuprar o cliente, mas atingir a meta.

Por outro lado, se o gerente de projeto fechar seu próprio projeto, ele reduzirá seu próprio local de trabalho.

A abordagem correta é se livrar de um ativo ruim o mais rápido possível. A tarefa do analista e gerente no pré-projeto é fazer isso.

Como obter um orçamento para um pré-projeto

Para trilhar o caminho para uma remoção construtiva e consistente da incerteza em torno de um projeto de TI, é necessário esclarecer com o cliente e o patrocinador a posição geral em relação à atitude em relação ao projeto como um ativo financeiro.

A imagem mostra a proporção normal de incerteza, investimento e retorno.



Enquanto a incerteza for grande, devemos investir pouco e reduzi-la.

Quando a incerteza com a proporção de investimentos e benefícios se tornar um nível aceitável, você poderá investir a maior parte dos recursos para obter um retorno. No final de cada fase, uma decisão honesta deve ser tomada: trabalhar ou fechar o projeto.

Para fazer isso, no final de cada fase, deve haver uma avaliação da proporção de investimentos e retornos no nível de precisão natural da fase atual.

O cliente precisa mostrar o atual nível de incerteza, a atual avaliação razoável dos benefícios e custos. Se os benefícios excederem o custo, faz sentido discutir a remoção adicional da incerteza.

A retórica pode ser a seguinte: "Vemos uma previsão de benefícios que excedem significativamente o custo do sistema, vamos gastar uma pequena fração do valor ou benefícios previstos para refinar as estimativas e decidir sobre o início do sistema".

Minhas recomendações (muito médias) sobre a proporção do custo de partes do pré-projeto:

• Tudo o que acontece antes da construção não deve custar mais que 10 a 30% do projeto.

• Um pré-projeto deve custar uma ordem de magnitude menor - isto é 1-3% do custo projetado do sistema.

• Nos estágios iniciais, desde que não haja requisitos de negócios, pode não haver valor previsto e precisa ser repelido a partir do retorno calculado - você pode levar 0,1-0,2% para a vida útil do sistema no orçamento para criar requisitos de negócios (levando em consideração que ele não inicia cada projeto proposto).

Por exemplo, se vendermos um sistema que custa ~ 100 milhões (por analogia). Isso faz sentido se o retorno de sua operação for de pelo menos ~ 300 a 500 milhões, dada a baixa precisão de todas as estimativas.

Nesse caso, os seguintes custos podem ser considerados normais:

• Requisitos de negócios - 0,5-1 milhão de rublos.

• O conceito é de 1-3 milhões de rublos.

• Projeto técnico - 10-30 milhões de rublos.

Desvios em qualquer direção são possíveis aqui. Mas o princípio geral é este: os recursos investidos devem ser correlacionados com o lucro previsto e a probabilidade de recebimento, dependendo do nível atual de incerteza.

Breve resumo

Aqui, concluímos a revisão do pré-projeto correto e repetimos o mais importante:

1. O projeto deve ser considerado como um ativo financeiro arriscado.
2. O nível de incerteza deve ser conhecido por todos e discutido entre todas as partes interessadas.
3. Os custos da análise devem estar relacionados ao benefício previsto e à probabilidade de recebimento.
4. No decorrer do desenvolvimento, é necessário atingir a qualidade dos requisitos suficientes para avaliar o custo e os termos com a precisão inerente à fase atual.
5. Em particular, os requisitos de negócios já devem ser mensuráveis.
6. É necessário lembrar a lista completa de tarefas da fase pré-projeto, cuja omissão de cada uma aumenta a probabilidade de falha do projeto em ordens de magnitude.

A vida mostra que, por várias razões, nem sempre é possível observar esses princípios. Em alguns casos, um projeto danificado antes do lançamento pode ser salvo ou, pelo menos, ligeiramente aprimorado. Falaremos sobre isso nas próximas partes da série.