Como escrever uma proposta de desenvolvimento de software

Como escrever uma proposta de desenvolvimento de software de sucesso.

Kevin Languedoc

O objetivo de uma proposta de desenvolvimento de software é transmitir uma solução que será lida por pessoas de negócios, portanto, mantenha-a simples e direta; fique longe dos termos técnicos tanto quanto possível. O esboço a seguir pode ser usado no estado em que se encontra para preparar uma proposta de desenvolvimento de software de sucesso. É importante ter em mente que as pessoas a quem você vai apresentar a proposta não têm muito tempo para ler um documento extenso. Você pode acreditar em mim, escrevi centenas de propostas ao longo dos meus mais de 20 anos em tecnologia da informação: os empresários querem apenas informações suficientes para que possam tomar uma decisão informada.

Se você estiver respondendo a uma Solicitação de Proposta (RFP) e deve respeitar um determinado intervalo de páginas, porque as páginas são pré-impressas ou os requisitos de conteúdo o forçam a ter uma proposta excessivamente longa, considere usar um Resumo Executivo. Eu adicionei uma seção que descreve como preparar um abaixo.

Comprimento da Proposta

Eu vi modelos e discussões que defendem propostas que duram 50 ou páginas. Acredite em mim, você perderá o interesse do executivo após a quinta página. Uma vez que a proposta seja aceita, os documentos de projeto naturalmente serão mais detalhados, pois serão destinados à equipe do projeto e serão as plantas de trabalho do sistema. Isso se aplicará à maioria dos clientes, mas (sim, sempre há um mas), se a proposta for uma resposta a uma solicitação de proposta (RFP), você deverá aderir à RFP. Além disso, um governo ou agência militar provavelmente terá diretrizes rígidas sobre como preparar uma proposta de desenvolvimento de software e pode incluir várias páginas (10, 20, 30, 50 ou mais) dependendo da complexidade do sistema.Essa regra ainda é válida para grandes organizações que podem ter um processo de proposta formal, especialmente se forem uma empresa pública e devem aderir a quaisquer regulamentos ou normas Sarbannes-Oxley ou ISO.

Sumário executivo

Se a proposta tiver mais de 20 páginas, você pode considerar a possibilidade de fornecer um Resumo Executivo, que é uma página das seções da proposta. Você pode até fornecer um Resumo Executivo em formato PowerPoint. Se você está planejando usar um Resumo Executivo na apresentação da proposta de desenvolvimento de software, apresente a proposta usando o Resumo Executivo e o executivo poderá ler a proposta posteriormente, como durante um voo comercial.

O modelo

O esboço a seguir é realmente um bom modelo que você pode usar para preparar sua própria proposta de desenvolvimento de software. Sempre mantenho a regra do Elevator Pitch em mente ao preparar uma proposta, e você também deveria. Basicamente, o Elevator Pitch estipula que sua proposta não deve ser muito mais longa do que o tempo que leva para pegar um elevador do andar térreo até o último andar de um edifício no caminho para apresentar uma proposta.

título do projeto

Com Subtítulo ou Informações Resumidas da Proposta

A proposta deve ter um título e uma subseção resumindo o contexto da proposta de software. Você também inclui o nome da divisão, serviço, departamento ou organização a que o projeto se destina.

Se você estiver respondendo a uma RFP (solicitação de proposta), inclua todas as informações necessárias ou listadas como obrigatórias na RFP. Também vi RFPs que solicitam que você coloque as assinaturas de aprovação além do título na primeira página, mas, neste exemplo, coloquei as assinaturas na página com a seção Mudanças.

Índice

Na próxima página, você deve incluir um índice listando as principais seções da proposta. Você pode opcionalmente incluir os números das páginas se a proposta exceder cinco páginas ou se for exigido pela RFP.

Aprovações

Esta seção é crucial para o processo, seja uma resposta a uma RFP ou deste modelo ou de alguma outra fonte. Esta seção documenta as confirmações de que o projeto está em andamento e fornece um acordo vinculativo entre os vários membros do projeto. Você nunca deve iniciar um projeto antes de obter todas as assinaturas necessárias e ter o compromisso do campeão do projeto e das partes interessadas em iniciar o projeto. Caso contrário, você pode se encontrar em uma situação difícil se o projeto for cancelado ou se o escopo do projeto mudar ou as entregas.

Com as aprovações em vigor, as mudanças no escopo e nas entregas são muito mais difíceis de fazer e, se houver disputas, a assinatura das aprovações proporcionará um entendimento claro do que foi acordado. Claro, sempre há uma questão de interpretação.

As Aprovações devem incluir o nome da pessoa, seu cargo, seguido de sua assinatura e por fim a data de assinatura do documento.



Nome	Título / Função	Assinatura	Encontro

Alterar

A seção Mudanças fornece um registro de todas as mudanças que foram feitas ou serão feitas no documento Proposta de Desenvolvimento de Software. Não documenta nenhuma mudança no escopo do próprio projeto ou em qualquer outro aspecto do projeto. A seção Mudanças deve incluir no mínimo o nome da pessoa que está fazendo a mudança, a data da mudança e um comentário ou descrição da mudança.



Autor	Data de Mudança	Descrição ou Comentário

Glossário e acrônimos

Liste todos os termos ou acrônimos e suas definições. Não presuma que todos saibam o significado dos termos ou siglas, especialmente se você estiver planejando usar consultores externos e os termos forem internos, embutidos em sua cultura corporativa e linguagem. Cada organização tem seu próprio jargão e siglas. Não há problema em usá-los na proposta, desde que devidamente documentados.

Além disso, se forem usados acrônimos específicos do setor, eles também precisam ser documentados para que todos tenham uma compreensão clara do significado dos termos e acrônimos e formulem interpretações melhores.

Os seguintes acrônimos são do modelo atual. Eles são fornecidos como um exemplo.

RFP: solicitação de proposta
ROI: Retorno sobre o investimento
CAGR: Taxa composta de crescimento anual
TI: Tecnologia da Informação
CAPEX: Despesas de Capital
UM: Unidade de Medida

Escopo

O escopo da proposta deve delinear em alto nível os detalhes gerais do projeto, o que está incluído e o que está excluído. O escopo deve fornecer uma descrição geral, a duração do projeto, os objetivos principais. O que você está tentando realizar com este investimento no projeto de desenvolvimento de software proposto.

Linha do tempo

Esta seção incluirá as datas de início e término (estimadas). Certifique-se de construir um buffer e planejar para contingências. Uma boa regra prática é adicionar um buffer de 75% à sua linha do tempo.

Membros do Projeto

Os membros do projeto devem incluir o campeão do projeto e as partes interessadas. O campeão geralmente é um executivo que conduz o projeto geral e o orçamento. A parte interessada geralmente é um promotor ou patrocinador interno. Eles também podem ser os campeões dependendo do escopo do projeto e / ou do tipo de organização que está solicitando a proposta de desenvolvimento de software. A lista restante contém funções típicas que as pessoas desempenham em um projeto.

O seguinte é fornecido apenas como um exemplo dos tipos de funções que os participantes do projeto podem ter. Algumas pessoas podem ter mais de uma função. Dependendo do escopo do projeto, a lista de membros do projeto pode ser muito longa ou a mesma pessoa pode assumir funções diferentes.

A lista deve conter todas as informações que identificam adequadamente a pessoa, sua função no projeto, como entrar em contato com ela e quais são suas responsabilidades. Você pode incluir outras informações, dependendo da RFP ou do tipo de organização com a qual trabalhará e suas políticas internas.



Membro da Equipe	Função	Informações de contato	Responsabilidades
	Campeão
	Stakeholder
	Gestor de projeto
	Arquiteto
	Analista
	Desenvolvedor

Oportunidade de negócios

A maioria dos modelos disponíveis define esta seção como “Problema de Negócio” ou “Declaração do Problema”. No entanto, freqüentemente encontro líderes de negócios que se ofendem com o fato de terem um problema em sua unidade de negócios ou processo. Lembro-me de uma diretora literalmente me expulsando de seu escritório porque eu havia declarado que estávamos consertando um processo e ela me disse que não seria alguém de TI (Tecnologia da Informação) que iria ditar se ela tinha um problema com seus processos ou não.

Portanto, tenha cuidado com o texto. Eu sempre uso o termo “Oportunidade de Negócio” porque no final, a proposta é uma resposta a uma oportunidade de negócio para melhorar um processo, apoiar um processo ou automatizar um processo



Declaração de negócios	Como o sistema irá satisfazer o requisito
Processo de negócios afetado, situação, problema	Como a solução proposta irá melhorar a área de negócios alvo
Qual necessidade está sendo atendida	Como o projeto atual vai resolver isso

Visão geral da solução

Na seção Visão geral da solução, você pode fornecer uma visão geral de alto nível do sistema. Esta visão geral pode incluir um mapa de navegação se a proposta for para um site ou aplicativo da web. Você também pode incluir um fluxograma do fluxo do processo. Além disso, você pode incluir um diagrama dos principais componentes do sistema.

O objetivo aqui é fornecer à pessoa que está tomando a decisão informações suficientes para que ela entenda o que é o sistema, como funcionará e quais são os principais blocos de construção. Claro, esta é apenas uma diretriz, pois uma organização pode ter um formato formal que defina o que você precisará fornecer na proposta, especialmente se você estiver lidando com uma agência governamental ou com o departamento de defesa.

Recursos e produtos a serem entregues

Esta seção fornece um mecanismo para mapear um recurso do sistema proposto para uma entrega tangível. Também vi esta seção que contém uma estimativa de tempo para concluir a entrega, mas não gosto de usar isso porque é muito restritiva e cria um empate. Ao trabalhar no projeto, as entregas podem não se alinhar exatamente como escrito, então, se você se comprometeu no papel a terminar uma entrega em um determinado tempo, isso remove ou diminui qualquer elasticidade mais tarde, quando você estiver realmente fazendo o projeto.

Outra coluna que pode ser adicionada é o Release ao qual o Entregável pertence. Isso é útil se o projeto for entregue por um longo período de tempo e houver vários lançamentos. Isso também pode se aplicar a um projeto baseado em Agile ou Lean em que cada recurso ou história de usuário pertence a uma versão.

O conceito é simples; para cada recurso no sistema, forneça o nome do recurso, uma breve descrição e qual entrega irá satisfazer o requisito do recurso.



Característica	Descrição	Entregável

Orçamento e ROI

O orçamento e o ROI são provavelmente a parte mais importante para alguns executivos. Todos estão ansiosos para saber quanto custará o sistema ou quanto impacto este projeto terá no orçamento do departamento. Isso é especialmente verdadeiro se o projeto não foi incluído no Capex no início do exercício.

Às vezes, mesmo que o projeto tenha sido orçado, outro projeto pode ter precedência sobre a proposta atual e os fundos podem ser desviados de sua fonte pretendida. Freqüentemente, há uma pequena disputa política acontecendo no nível executivo e gerencial para fazer um projeto decolar e, muitas vezes, há circunstâncias imprevistas que podem ter precedência sobre os projetos planejados.

Portanto, esteja preparado para trabalhar com suas partes interessadas para ajudar nas negociações ou seja flexível e proativo para fornecer uma solução de trabalho se uma situação de orçamento der errado. É melhor adaptar o projeto à realidade orçamentária, mesmo distribuindo os produtos do sistema por um período maior de tempo ou até mesmo afastando-se do projeto. É muito melhor ir embora do que ter trabalhado em um projeto e não ser pago e ter que recorrer a processos judiciais no caminho.

A tabela a seguir é para fins de demonstração apenas para dar uma ideia de como preparar um orçamento. Naturalmente, você precisará adicionar seus próprios itens de linha para se adequar ao seu projeto. Em seguida, você preenche a quantidade, o preço unitário, a unidade de medida e o total do item de linha. Em seguida, some os totais do item de linha na parte inferior.

Isso fornecerá uma boa imagem do investimento necessário para fazer o projeto de software. A maioria dos executivos com quem trabalhei gostaria de saber qual será a taxa de retorno ou quanto este projeto vai custar ao longo do tempo, então eu também incluo um valor de ROI simples e um CAGR, usando minhas próprias estimativas e suposições (que devem ser explicado) na proposta ou usando as estimativas e premissas fornecidas.



Item de Projeto	Montante	Preço unitário	UoM	Total
Licença de software
Máquina (s)
Licença de Servidor
Licença de banco de dados
Consultor de Desenvolvimento
Gerenciamento de projetos
Treinamento (Tempo + Materiais)

ROI

O cálculo do ROI é muito fácil. Basicamente, a fórmula é ganhos - custo dividido pelo custo. A fórmula é fornecida abaixo:

A única desvantagem é que o cálculo não leva em conta o tempo, então o ROI é bom para projetos de curto prazo, mas para projetos de longo prazo geralmente incluo uma CAGR (Taxa de crescimento anual composta). O cálculo CAGR é uma taxa de retorno ano após ano para um determinado momento no tempo.

CAGR

A fórmula CAGR é:

A primeira parte é a divisão do valor final pelo valor inicial. O resultado é elevado à potência de 1 ao longo do número de anos investidos. O valor resultante é subtraído por 1.

Benefícios

Nesta seção, você relaciona os benefícios comerciais que o projeto de software proporcionará. Eles podem ser listados em formato de marcador, desde que correspondam aos objetivos gerais. Eles devem demonstrar como o software ou sistema aumentará o valor do negócio.

Em suma, como a solução proposta vai ajudar a empresa a ter mais sucesso e atingir os objetivos de sua declaração? Use palavras e frases positivas.

Restrições

A seção de restrições deve listar todas as restrições tangíveis e intangíveis que você pode prever. Isso pode estar relacionado ao equipamento, algum fator de sazonalidade, como o desligamento de uma planta de produção, que a maioria das plantas faz pelo menos uma vez por ano, por exemplo.

Tente minimizar as restrições ou pintá-las como mínimas. Não liste nenhum aspecto negativo do software ou sistema ou, se for necessário, forneça soluções alternativas.