Como vender desenvolvimento ágil para clientes (cascata)

A chave para fazer isso é usar um contrato de suporte.

Então você tem um contrato de preço fixo para o escopo do X. Então você diz ao cliente “ Olha, você vai querer fazer mudanças, e você vai precisar de nós para te ajudar a pós-produção, vamos reservar 20% do seu orçamento para essas coisas serem usadas em um precisam de base por meio de um contrato de suporte .

Caso ocorra uma mudança durante o projeto, simplesmente adie-o para ser tratado sob o contato de suporte. (Supondo que essa mudança causaria uma séria perturbação no projeto)

Os termos do contato de suporte são os seguintes: O trabalho a ser feito por hora, conforme solicitado pelo cliente, pode ser usado para solicitações de mudança ou manutenção e suporte geral do sistema . ” BAM! Você está no Agile.

Você pode continuar a estender o contato de suporte e simplesmente usar o contato de suporte como meio de executar novos projetos. Além disso, se essas horas forem compradas e pagas antecipadamente , geralmente damos ao cliente um desconto de 15%. É vantajoso para as duas partes.

O Agile não impede prazos e orçamentos. Se eu fosse um cliente e eu fosse a um desenvolvedor e eles me dissessem que não poderiam me dar um prazo ou um custo estimado, eu questionaria sua sanidade. E dizer a eles que eles simplesmente não entendem não vai funcionar: eles precisam ser capazes de orçar e planejar.

Eles não precisam conhecer seu processo de desenvolvimento. Eles precisam saber quanto tempo levará para desenvolver recursos e quanto vai custar. Dê a eles um número baseado na suposição (espúria) de que seus requisitos são 100% precisos e, quando seus requisitos mudarem, altere suas estimativas.

Isso fornece os itens de linha de orçamento e as datas de implantação desejadas e, quando as coisas mudam, seu processo permite que você pareça flexível e flexível.

Parece que seus vendedores estão criando uma camada de falta de comunicação entre suas equipes de desenvolvimento e os clientes. Se eles não estão vendendo no mercado de TI há muito tempo, eles podem ver o papel deles como "mover o produto", o que significa obter uma assinatura em um contrato "o que for necessário". Em suma, eles estão motivados a fechar, independentemente do que prometem. Em tais circunstâncias, eles rastrearão a linguagem do cliente o mais próximo possível.

Sou um disco quebrado citando isso, mas aqui está: você está na mesa de operações e, enquanto está sob controle, o cirurgião diz: 'vamos tirar você daqui a tempo e dentro do orçamento'. Ótimo. Eu vou estar vivo?

Se você está trabalhando nos órgãos internos de uma empresa, você pára em algum ponto arbitrário? Normalmente, um aplicativo é afetado por forças que nem você nem seus controles de cliente - regulamentos, clima de negócios, comportamento de concorrentes, o surgimento de algum novo paradigma etc. Se você simplesmente disser "vamos fazer" x por "preço y" o cliente voltará três meses depois e dirá - 'bem ...'. Geralmente significa que eles sabem algo que não sabiam quando você concordou com um projeto em cascata.

O que pode funcionar em tal situação é demonstrar para sua própria equipe de vendas como é uma viagem através de um desfiladeiro. Em cada turno há surpresas. Não é possível ver mais de três meses, então se um cliente estiver pedindo por um projeto de 18 meses, ele ficará irreconhecível quando você estiver perto da conclusão. Portanto, seu representante de vendas precisa começar encontrando a recompensa financeira do projeto. Isso aumentará as vendas em US $ 10 milhões? Se sim, vale a pena investir US $ 2.000.000 para fazer esse adicional de US $ 10 milhões? Se o cliente e o representante de vendas estão convergindo para um compromisso de US $ 500.000, então algo pode estar errado e ninguém pode dizer o que é - simplesmente não parece certo. O que "não está se sentindo bem" é um compromisso de fazer algo que corre o risco de ser inútil.

Os dois modelos mais recentes de aviões a jato tiveram um histórico de snafus. Healthcare.gov nem precisa de discussão. Se você puder encontrar livros ou reportagens da imprensa comercial sobre os aviões, você pode expor como certas suposições foram feitas que provaram ser otimistas, e que os projetos perderam seus prazos repetidamente. Muitas vezes isso se deve à subestimação da complexidade. Se você não consegue realmente descobrir o quão complexo é até começar a codificá-lo, você precisará de uma "rodada inicial" para ter uma idéia melhor dos problemas reais. O corte de orçamento deve ser uma fração do total de lucros adicionais (ou receitas em alguns casos), e esse número tem que ser maior do que qualquer um acha que o projeto atual custará. Se você puder mostrar como o último marco pode ser passado sem exceder o 'limite de pagamento', deve ser possível vender o projeto como um esforço ágil.

O principal obstáculo para alcançar os benefícios do Agile-Scrum fora do desenvolvimento de software é integrá-lo aos mecanismos de controle existentes. Esses mecanismos de controle são estipulados devido a vários pré-requisitos organizacionais e são normalmente atualizados usando a abordagem e a metodologia da Cascata Linear.

Quatro desses pré-requisitos organizacionais típicos são descritos abaixo:

• Grandes corporações globais - nessas organizações matriciais hierárquicas, o controle de portfólio de cima para baixo é a regra do dia. A abordagem ágil e livre de espírito tem dificuldade em se ajustar aos controles rigorosos. Especificamente, os conceitos inerentes do Agile-free tornam o Agile-Scrum difícil para a organização engolir.

• Indústrias altamente regulamentadas - alguns setores são obrigados pelos órgãos de conformidade e governança a ter um mecanismo rígido de controle de vinculação. Estes podem ser, por exemplo, equipamentos médicos, aeronaves e unidades de negócios de pesquisa farmacêutica e desenvolvimento de produtos. Enquanto equipes individuais podem operar o Agile-Scrum, o processo de desenvolvimento deve seguir um método rígido de abordagem Linear Waterfall para rastreabilidade e governança.

• Produtos pré-definidos complexos - alguns produtos integrados que incluem hardware, software, embutidos e muito mais são desenvolvidos como um contrato com um cliente final sob um conjunto pré-definido de requisitos. Nesses casos, o grau de flexibilidade do requisito é pequeno, embora maior do que o inicialmente previsto. O conceito de um backlog totalmente flexível do Agile-Scrum sofre consideravelmente nesses casos.

• Departamentos genéricos de TI - grande parte das atividades diárias e semanais nos departamentos de TI orientados à manutenção é ad hoc. Mudanças nas programações diárias são numerosas e imediatas. Interferências constantes no trabalho das equipes são a norma. O conceito de time boxing e sem interferência é difícil de manter nessas situações.

Naturalmente - muitas vezes as quatro categorias distintas detalhadas acima, na verdade, misturam; Por isso, é comum encontrar um produto complexo em uma grande corporação global que é necessário para cumprir a regulamentação firme.

Com base na experiência prática, o método recomendado para lidar com esses cenários e outros é capacitar o PMO Agile a atuar como um facilitador, condutor e tradutor entre as equipes emergentes do Agile-Scrum e os elementos do Linear Waterfall.

Consulte a tabela abaixo para diretrizes específicas

Fonte- Interface entre a Cachoeira Linear e as Abordagens Ágeis por Michael Nir

Criamos 2 ou 3 sessões de estimativa com o cliente em potencial e nossos desenvolvedores, onde discutimos o trabalho em questão e definimos os critérios de aceitação. Os desenvolvedores estimam o trabalho nos pontos da história durante a reunião.

Depois disso, vendemos ao cliente vários pontos da história. Isso é possível porque ele tem uma boa ideia do valor dos pontos da história. Dizemos a ele que ele tem a possibilidade de ajustar seu backlog / escopo durante o projeto e que será fácil devido ao uso dos pontos da história. Também dizemos a ele que haverá uma entrega frequente de software funcional para que ele possa monitorar o progresso e obter novos insights.

Ao concordar com vários pontos da história, o cliente tem a garantia de obter valor pelo seu dinheiro. Se ele não mudar seu backlog, ele tem seu projeto de preço fixo / escopo fixo, mas minha experiência é que ele fará mudanças. Ao fazer as estimativas na presença do cliente potencial, tentamos construir um relacionamento baseado na abertura e confiança.

Conseguimos convencer clientes como você descreveu, que "querem um orçamento e um prazo", e eles estavam felizes em saber o que eles precisavam, em vez de trabalhar em um documento. Mostramos que queríamos investir nesses projetos.

Durante as sessões de estimativa, estimamos todo o backlog. Isso deu x pontos de história. Sugerimos adicionar 25% para os recursos que ainda não eram claros ou conhecidos no momento. Com o atraso estimado associado ao contrato, eles ficaram seguros de que receberiam tudo pelo orçamento fixo.

Originalmente, o lance era tempo e material. Como queriam ter uma oferta de preço fixo, sugerimos trabalhar pelo preço que lhes demos e usar os 25% de pontos extras da história para contingência. Se as coisas corressem bem, a parte dos 25% que não foi usada para cobrir os atrasos que encontramos seria usada para fornecer mais funcionalidades para o cliente.

Isso os estimulou de várias maneiras: primeiro, eles fizeram tudo que podiam para permitir que nossos desenvolvedores trabalhassem o mais rápido possível, já que isso era claramente de interesse deles. Nós nunca tivemos que esperar por respostas a perguntas. Em segundo lugar, eles realmente entenderam o conceito dos pontos da história. Antes do início do projeto, eles já haviam removido algumas das histórias e nos pediram para estimar outras histórias. Nenhuma negociação de contrato complicada era necessária para isso.

Nós os mantivemos informados sobre o progresso e mantivemos uma comunicação muito aberta. Eles obtiveram um relatório de progresso a cada duas semanas: x% dos pontos da história feitos em y% do tempo estimado deixa z% dos pontos extras da história disponíveis. Tivemos um começo difícil, mas conseguimos alcançar as estimativas no final do projeto, o que deixou 100% dos pontos extras disponíveis para desenvolvimento extra. O cliente estava feliz porque ele tinha tudo de que realmente precisava (e isso era um pouco diferente de seus recursos inicialmente solicitados, ele removeu alguns e adicionou outros).

O cliente também ficou feliz porque tudo foi entregue no prazo previsto (onde ele também fez todo o possível para nos ajudar a perseguir ingressos, respondendo a perguntas imediatamente, envolvendo os usuários em reuniões semanais de análise e também envolvendo-os em testes funcionais).

Minha empresa ficou feliz porque entregamos a tempo e dentro do orçamento. Minha empresa também ficou feliz porque o sucesso desse projeto abriu as portas para mais projetos. Nós até fomos mencionados na revista mensal do cliente que foi enviada para pessoas em todo o mundo.

Fazer boas estimativas foi a parte mais difícil do projeto, mas ter as sessões de estimativa na frente nos ajudou a entender a dificuldade e os riscos. Permitiu-nos dar uma estimativa baseada em fatos e removeu muitos dos desconhecidos.

Tentar usar métodos ágeis em um ambiente de consultoria / licitação é muito difícil quando o cliente não está a bordo.

Se eles estão acostumados com o estilo Waterfall ", aqui estão nossos requisitos, quanto e quanto tempo levará?" tipo projetos, e estão colocando para fora para concurso, não há realmente qualquer momento para convencê-los de que Agile ou de qualquer outra forma é melhor.

O Agile tem sua vantagem (e desvantagens, é claro), mas, francamente, o cliente muitas vezes não sabe ou não se importa com os detalhes nos bastidores.

Eles querem duas coisas - custo e escala de tempo. E quando você diz isso, eles querem mais barato e mais cedo. E você sabe o que, nós queremos tudo. Todos os requisitos. Ninguém pode esperar ou ser picado.

E por mais que eu não goste de vendedores na maioria das áreas de atuação, não seja muito duro com os vendedores. Essa é uma tarefa difícil.

Eles não criam software, eles geralmente não têm ideia de como tudo funciona além das palavras de zumbido.

No entanto, eles têm que chegar a escalas de tempo e custo com base em alguma reunião de requisitos de lã. Talvez eles tenham alguns dos caras da tecnologia com eles para reinar, mas eles precisam fazer uma venda para manter as coisas funcionando.

So, how can you get your sales force to successfully sell a project that uses agile development methods, or a product that is developed using such methods?

Por ter sua força de vendas trazendo o cliente para o escritório. O objetivo da agile é obter feedback imediato do cliente para que você possa produzir o que ele quer (e não mais). Traga-os, pergunte o que eles querem. Duas semanas depois, traga-os e mostre-lhes uma demonstração / protótipo. Venda-os nessa interação. Mostre-lhes progresso e explique que esse tipo de iteração é o que você gostaria de fazer para que eles tenham exatamente o que desejam.

Forneça estimativas para a quantidade de trabalho necessária (afinal, é um orçamento), mas deixe que eles tenham o poder (leia-se: responsabilidade) para incluir o que desejam encaixar no orçamento deles .

Acho que a resposta é que, na maioria dos casos, você provavelmente não. Eu tentaria ver isso inicialmente como uma pequena parte do seu negócio - talvez 20%, com o restante sob um modelo tradicional. Com o tempo, eu tentaria me concentrar mais nos produtos e clientes ágeis e tentar fazer com que essa parte crescesse mais.

Outra parte da abordagem talvez seja tentar usar ambas as abordagens. Use a abordagem em cascata com a gerência sênior e pessoal de negociação de contrato. Por exemplo, "um sistema para permitir que os clientes mantenham portfólios e tomem decisões de investimento usando dispositivos baseados em navegador e dispositivos móveis (Apple e Android)". ou algo assim. Em seguida, use o Agile para o desenvolvimento da equipe de desenvolvimento sobre os recursos mais detalhados, por exemplo, Criar Página Inicial, Criar Página de Login, Criar Histórico de Gerenciamento de Portólio, Criar Login Móvel, etc.

Outra ideia é tornar o Agile seu diferencial. Eu sei que muitas organizações, se não a maioria, não estão fazendo Agile. No entanto a maioria (a grande maioria na minha experiência) de pequenas empresas são. Eu acho que o Agile está crescendo rapidamente e isso vai continuar. A vantagem desta rota é que você está lançando o que mais deseja fazer para os clientes que já a reconhecem. Essa abordagem exigirá algum trabalho ao longo do tempo sem garantia de sucesso.

Você também pode encontrar alguma tração se seus clientes gostarem de testar. Ter produtos bem testados pode ser mais fácil de vender para alguns clientes. Um livro que estou achando útil nesta área é 'Agile Testing' da Adison Wesley Press.

Você também pode usar eventos atuais para dar suporte ao seu caso. Por exemplo, o atual (escrito este em outubro de 2012) site de cuidados de saúde é um grande exemplo de como não lidar com as mudanças que eram necessárias 2 semanas antes do início da vida. Além disso, a aparente engenharia excessiva provavelmente teria sido melhor abordada com métodos mais ágeis.

Entre em contato com clientes anteriores que estejam satisfeitos com seu trabalho. Especialmente se forem convertidos em cascata para ágil. No mínimo, os convertidos que não eram seus clientes.

Os depoimentos deles (como cliente) superam tudo e qualquer coisa que você possa dizer. Eles podem abordar as preocupações e os medos do seu novo cliente mais do que você jamais poderia ter feito.

De uma perspectiva de gestão, um orçamento e um prazo é uma necessidade do negócio para o projeto. Você precisa ter certeza de que está lidando com essas necessidades e, se observar os depoimentos de uma empresa sobre a mudança, perceberá que isso acontece diretamente. Se você observar os depoimentos do desenvolvedor sobre a mudança, perceberá que muitas vezes isso não acontece.