O Triângulo de Desenvolvimento da Web

Todos os nossos contratos com nossos clientes são compromissos mensais contínuos. Muito raramente perseguimos um projeto fixo e quase nunca garantimos o cronograma. Isso pode parecer assustador para alguns, mas o problema é que a meta não deve ser a data de lançamento, mas sim os resultados do negócio. Nosso trabalho é obter os resultados comerciais de nossos clientes, não tomar atalhos para definir datas de lançamento. Como Healthcare.gov está aprendendo, esse é um caminho que levará a expectativas perdidas.

Para tentar manter os projetos dos clientes na hora, separamos os requisitos em obrigatórios (atendendo aos resultados de negócios) e bons de ter (aprimoramentos opcionais). Também não programamos a conclusão no momento do lançamento, pois sabemos que sempre haverá algumas mudanças necessárias.

Robert Patrick é CEO da Laboratórios de PhD, uma agência que projeta, constrói e lança sites para muitas das principais empresas da Fortune 500. Robert está monitorando as dificuldades que o Healthcare.gov encontrou e forneceu 5 razões principais para o fracasso no lançamento.

  1. Nunca, jamais viole o Tempo, custo e recurso Defina a regra. Pense nisso como um triângulo, você deve escolher um ponto para ser fixado e as outras duas variáveis. Neste mundo, quase tudo pode ser criado, desde que haja tempo e dinheiro suficientes. No entanto, qualquer pessoa que esteja criando um aplicativo da web deve escolher, desde o início, qual é a prioridade mais alta. Isso define o tom e o foco de como um projeto deve ser lançado. Por exemplo,
    • Deve ser lançado apenas quando recursos específicos forem concluídos (dinheiro e tempo são variáveis).
    • Deve ser lançado rapidamente (dinheiro e recursos são variáveis).
    • Deve ser lançado com um orçamento em mente (tempo e recursos são variáveis).
  2. Iniciando com o linha de chegada em mente, em vez da linha de partida. Os aplicativos da Web devem ser vistos como um projeto que irá começo e depois evolui. Construir o que é importante e obrigatório para hoje com crescimento e evolução em mente é sempre melhor do que construir com a intenção de terminar do ponto de partida.
  3. Muitos fornecedores envolvidos. Foi relatado que o site Obamacare teve cerca de 55 fornecedores envolvidos. Adicionar vários fornecedores a qualquer projeto pode ser uma ladeira escorregadia. Você pode quase garantir que haverá problemas com controle de versão de arquivo, discrepâncias de arquivo de arte, discrepâncias de opinião de arte, abandono de projeto e a lista continua indefinidamente. Imagine se tivéssemos 55 senados com a tarefa de resolver uma parte do problema geral.
  4. Arquitetura da Informação não levado a sério. Freqüentemente, grandes agências pedem aos fornecedores que enviem uma oferta em uma RFP e pule completamente o processo de Arquitetura da Informação, saltando direto para o desenvolvimento, sem entender ou concordar com um escopo. Este é um erro enorme e feio, uma perda de tempo, perda de dinheiro. É extremamente valioso arquitetar o aplicativo tanto quanto você pode antecipadamente e estar preparado para ser ágil e flexível nas coisas que não poderiam ser previstas bem antes de começar a programá-lo (é como construir uma casa sem projetos). Os fornecedores estão destinados a ficar sem orçamento e começar a cortar custos se isso não for feito corretamente.
  5. Não há tempo suficiente para Garantia da Qualidade. É óbvio que essa foi uma grande queda para o lançamento do HealthCare.Gov. Eles estavam trabalhando em uma data de lançamento difícil (o tempo é a variável fixa do triângulo, neste caso) e os recursos e o orçamento deveriam ter sido modificados para atender a data de lançamento com tempo para a garantia de qualidade adequada incorporada ao plano. Este é um erro crucial e provavelmente custou o emprego a muitas pessoas.

O que você acha?

Este site usa o Akismet para reduzir o spam. Saiba como seus dados de comentário são processados.