Home / FAQs / Programa de software start-up e seleção de programas
QUESTION & ANSWER

Por que as empresas de software precisam estudar as necessidades antes de poderem oferecer?

As ofertas de software não são baseadas em tamanhos de página simples, e regras de negócios, privilégios de funções, interfaces, migração de dados, desempenho, segurança e acesso podem afetar significativamente a carga de trabalho. A pesquisa de demanda é projetada para identificar esses drivers de custos e distinguir entre intervalos definidos e riscos desconhecidos. Sem pesquisa, preços baixos são muitas vezes compensados por mudanças subsequentes, menor qualidade ou a eliminação da entrega.

Responde à pergunta.

Em primeiro lugar, dar conclusões que podem ser utilizadas para a tomada de decisões

Pesquisas efetivas podem traduzir a linguagem de negócios em um intervalo estimado, registrando as citações, não inclusão e questões a serem validadas. Projetos simples podem ser completados através de questionários e sessões curtas, enquanto projetos complexos podem exigir entrevistas no local, diagnósticos sistemáticos e protótipos.

DECISION FACTORS

Que condições precisam ser identificadas antes de se fazer o julgamento?

A mesma questão pode ter respostas diferentes em diferentes fases de negócio, dados e projetos. Sugere-se que as seguintes condições sejam verificadas e que as descobertas comuns na web sejam incorporadas em seus próprios projetos.

Número de funções, processos, estado e anomaliasInterface de terceiros, sistemas antigos e complexidade de migração de dadosRequisitos de cooperação, equipamento, conformidade e segurançaNecessidade de concepção, testes, implantação, formação e mobilidade
ACTION STEPS

Ordem de adiantamento sugerida

01

Primeiro, vamos ser claros sobre o alvo e a fronteira.

Recolha de objectivos, processos, informações e informações sobre sistemas existentes.

02

Dependência da Chave de Validação

Funções de identificação, não-funcionais, interfaces, migração e requisitos de entrega.

03

Desenvolvimento de resultados avaliáveis

Listar os pressupostos, riscos, exclusões e questões a validar.

04

Certifique-se de decidir o próximo passo com os resultados reais.

Estimativas por fase ou pacote de trabalho, com indicação de como o cálculo foi alterado.

PRACTICAL EXAMPLE

Como é que entendes isso no negócio?

Exemplo utilizado para ilustrar o método de julgamento

O número de duas páginas “member applet” é semelhante, uma mostrando apenas informações, e a outra lidando com vários inventários de lojas, reservas, reembolsos e reconciliações financeiras, com variações significativas de custos. Regras de confirmação e interfaces pré-oferta permitem a comparabilidade real de diferentes programas.

COMMON RISKS

O poço mais fácil de pisar.

Apenas para listas funcionais, sem descrição das regras de funcionamento

Selecione com a menor citação, ignore testes e implantação

Esconder todas as incógnitas no preço fixo bruto.

ACCEPTANCE

Como devemos acabar recebendo e confirmando?

A oferta oficial deve ser rastreada de volta ao âmbito, à entrega, às condições técnicas, ao pessoal, à periodicidade e ao risco, e indicar se estão incluídos impostos e encargos, recursos em nuvem, serviços de terceiros e transporte.

Ao se preparar para comunicar com fornecedores ou equipes internas, recomenda-se que processos atuais, amostras representativas, sistemas existentes, tempo de planejamento e níveis de orçamento sejam trazidos. Primeiro, os itens desconhecidos são claramente marcados, e então a decisão é tomada de usar diagnósticos, PoC, projetos de alcance fixo ou pesquisa e desenvolvimento em curso, que é geralmente mais confiável do que uma demanda direta por um preço e duração sem fronteiras.

As condições do seu projeto são diferentes dos exemplos acima?

Os objectivos operacionais, os sistemas existentes, a amostra e o tempo planeado poderiam ser reunidos antes de os consultores poderem fazer julgamentos preliminares em relação às fronteiras reais.

Consultores associados de projectos