Como vender desenvolvimento ágil para clientes (em cascata)

Nossa loja de desenvolvimento realmente gostaria de fazer projetos mais ágeis, mas temos um problema em conseguir clientes a bordo. Muitos clientes querem um orçamento e um prazo. É difícil vender um cliente em um projeto ágil quando nossos concorrentes criam prazos e preços fixos baseados em cascata. Sabemos que seus números fixos são ruins, mas o cliente não sabe disso. Então, acabamos parecendo ruins para o cliente porque não podemos fixar o preço ou um prazo, mas nossos concorrentes podem.

Então, como você pode fazer com que sua equipe de vendas venda com sucesso um projeto que use métodos de desenvolvimento ágil ou um produto desenvolvido usando esses métodos? Todas as informações que encontrei parecem se concentrar no gerenciamento de projetos e desenvolvedores.

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

Basicamente, quando você vende o cliente pela primeira vez, você o vende com base em sua experiência e faz isso em cascata. Isso significa um contrato que define o escopo e um prazo final firme. É isso que o cliente deseja. O cliente conhece mais ou menos o escopo. O Waterfall funciona muito bem, em um ambiente de escopo fixo e definido, eu diria que funciona melhor do que o ágil nesses ambientes. E, nesse caso, proporciona ao cliente um nível de conforto quando a tendência é ficar nervosa, porque ele nunca trabalhou com você antes. Tudo bem, o Agile nem sempre é melhor do que o Waterfall.

Portanto, você tem um contrato de preço fixo para o escopo X. Em seguida, você diz ao cliente: “ Olha, você vai querer fazer alterações e vai precisar de nós para ajudá-lo na pós-produção, vamos reservar 20% do seu orçamento para que essas coisas sejam usadas conforme a necessidade por meios de um contrato de suporte ".

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

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

Você pode continuar estendendo o contato de suporte e simplesmente usá-lo como meio de executar novos projetos. Além disso, se esse horário for comprado e pago antecipadamente , geralmente oferecemos ao cliente um desconto de 15%. É Win-Win.

O Agile não exclui prazos e orçamentos. Se eu fosse um cliente e fosse a um desenvolvedor e eles me dissessem que não podiam 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 com base na suposição (espúria) de que seus requisitos são 100% precisos e, quando os requisitos forem alterados, altere suas estimativas.

Isso fornece a eles os itens de linha do orçamento e as datas de implantação que eles desejam 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 clientes. Se eles não vendem no mercado de TI há muito tempo, eles podem ver seu papel como 'mover o produto', o que significa obter uma assinatura de um contrato 'o que for preciso'. Em resumo, eles são motivados a fechar, independentemente do que são promissores. Em tais circunstâncias, eles acompanharão o idioma do cliente o mais próximo possível.

Eu sou um recorde quebrado citando isso, mas aqui vai: você está na mesa de operações e, conforme o cirurgião diz: 'vamos tirá-lo daqui a tempo e dentro do orçamento'. Ótimo. Eu estarei vivo?

Se você trabalha nos órgãos internos de uma empresa, para em algum momento arbitrário? Normalmente, um aplicativo não é afetado por forças que você nem o cliente controla - regulamentos, clima de negócios, comportamento do concorrente, surgimento de um novo paradigma etc. Se você simplesmente diz 'faremos' coisa x 'pelo' 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 nessa situação está demonstrando para sua própria equipe de vendas como é uma viagem por um canyon. A todo momento, há surpresas. Não é possível ver mais de três meses; portanto, se um cliente estiver solicitando um projeto de 18 meses, ele será irreconhecível quando você estiver próximo da conclusão. Portanto, seu representante de vendas precisa começar encontrando o retorno financeiro do projeto. Isso aumentará as vendas em US $ 10 milhões? Em caso afirmativo, vale a pena investir US $ 2.000.000 para fazer esses US $ 10 milhões adicionais? Se o cliente e o representante de vendas estão convergindo para um compromisso de US $ 500.000, algo pode estar errado e ninguém sabe o que é - simplesmente não parece certo. O que "não está se sentindo bem" é o compromisso de fazer algo que corre o risco de ser inútil.

Os dois últimos modelos de aviões a jato têm uma história de snafus. Healthcare.gov nem precisa de discussão. Se você pode encontrar livros ou trocar notícias da imprensa nas aeronaves, pode mostrar como foram feitas certas suposições que se mostraram otimistas e que os projetos perderam seus prazos repetidamente. Muitas vezes, isso ocorreu devido à subestimação da complexidade. Se você realmente não consegue descobrir o quão complexo é até começar a codificá-lo, precisará de uma 'rodada inicial' para ter uma idéia melhor dos problemas reais. O corte no orçamento deve ser uma fração do total de lucros adicionais (ou receitas em alguns casos), e esse número deve ser maior do que se pensa que o projeto atual custará. Se você pode mostrar como o último marco pode ser passado sem exceder o 'limite de pagamento',

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 normalmente são atualizados usando a abordagem e a metodologia Linear Waterfall.

Quatro desses pré-requisitos organizacionais típicos estão representados abaixo:

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

• Indústrias altamente regulamentadas - algumas indústrias exigem que os órgãos de conformidade e governança tenham um mecanismo de controle estrito. Podem ser, por exemplo, unidades de negócios de equipamentos médicos, aeronaves e produtos farmacêuticos de pesquisa e desenvolvimento de produtos. Embora as equipes individuais possam 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 predefinidos 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 predefinido de requisitos. Nesses casos, o grau de flexibilidade dos requisitos é pequeno, embora maior do que o inicialmente previsto. O conceito de um backlog totalmente flexível do Agile-Scrum sofre consideravelmente nesses casos.

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

Naturalmente - muitas vezes as quatro categorias discretas detalhadas acima, na verdade se misturam; por isso, é comum encontrar um produto complexo em uma grande corporação global, necessária para cumprir a regulamentação da empresa.

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

Consulte a tabela abaixo para obter orientações específicas

Fonte - Interface entre cascata linear e abordagens ágeis por Michael Nir

Montamos 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 em pontos da história durante a reunião.

Depois, vendemos ao cliente vários pontos da história. Isso é possível porque ele tem uma boa idéia 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 em funcionamento para que ele possa monitorar o progresso e obter novos insights.

Ao concordar com vários pontos da história, o cliente garante um valor pelo seu dinheiro. Se ele não alterar sua lista de pendências, ele terá seu projeto de preço fixo / escopo fixo, mas minha experiência é que ele fará alterações. Ao fazer as estimativas na presença do cliente em potencial, tentamos construir um relacionamento baseado em abertura e confiança.

Conseguimos convencer os clientes, como você descreve, que "querem um orçamento e um prazo", e eles ficaram felizes porque queríamos realmente entender o que precisavam, em vez de trabalhar com um documento. Mostramos que queríamos investir nesses projetos.

Durante as sessões de estimativa, estimamos todo o atraso. Isso deu x pontos da história. Sugerimos adicionar 25% para os recursos que ainda não eram claros ou conhecidos na época. Com a lista de pedidos estimados anexada ao contrato, eles tiveram a certeza de que receberiam tudo pelo orçamento fixo.

Originalmente, a oferta era de tempo e material. Como eles queriam ter um lance de preço fixo, sugerimos trabalhar pelo preço que damos a eles e usar os 25% de pontos extras da história para contingência. Se tudo corresse bem, a parte dos 25% que não foi usada para cobrir os atrasos que encontramos seria usada para fornecer mais funcionalidade ao cliente.

Isso os estimulou de várias maneiras: primeiro, eles fizeram todo o possível para permitir que nossos desenvolvedores trabalhassem o mais rápido possível, pois isso claramente era do seu interesse. Nunca tivemos que esperar respostas para 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 histórias e nos pediram para estimar outras histórias. Não foram necessárias negociações complicadas para isso.

Nós os mantivemos informados sobre o progresso e mantemos uma comunicação muito aberta. Eles recebem um relatório de progresso a cada 2 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 um pouco difícil, mas conseguimos acompanhar as estimativas até o final do projeto, o que deixou 100% dos pontos extras da história disponíveis para desenvolvimento extra. O cliente ficou satisfeito porque conseguiu tudo o que realmente precisava (e isso foi um pouco diferente dos recursos solicitados inicialmente, ele removeu alguns e adicionou outros).

O cliente também ficou satisfeito porque tudo foi entregue no prazo previsto (onde ele também fez todo o possível para nos ajudar a buscar tickets, responder perguntas imediatamente, envolver os usuários em reuniões semanais de análise e envolvê-los em testes funcionais).

Minha empresa ficou feliz porque entregamos dentro do prazo e do orçamento. Minha empresa também ficou feliz porque o sucesso desse projeto abriu as portas para mais projetos. Chegamos a ser mencionados na revista mensal do cliente, enviada a pessoas em todo o mundo.

Fazer boas estimativas foi a parte mais difícil do projeto, mas ter as sessões de estimativa antecipadas nos ajudou a entender a dificuldade e os riscos. Isso nos permitiu dar uma estimativa baseada em fatos e removeu muitas das incógnitas.

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 ao estilo Waterfall "aqui estão nossos requisitos, quanto e quanto tempo levará?" digitar projetos e colocá-lo em leilão, não há realmente tempo para convencê-los de que o Agile ou qualquer outra maneira é melhor.

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

Eles querem duas coisas - custo e escala de tempo. E uma vez que você diz isso, eles querem mais barato e mais cedo. E você sabe o que, 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 esferas da vida, não seja muito duro com os vendedores. Esse é um trabalho difícil.

Eles não constroem software, geralmente não têm idéia de como tudo funciona além das palavras da moda.

No entanto, eles precisam criar escalas de tempo e custos com base em alguns requisitos de lã. Talvez eles tenham alguns técnicos para reinar, mas precisam fazer uma venda para manter as coisas funcionando.

Então, como você pode fazer com que sua equipe de vendas venda com sucesso um projeto que use métodos de desenvolvimento ágil ou um produto desenvolvido usando esses métodos?

Ao ter sua força de vendas, leve o cliente ao escritório. O objetivo principal do agile é obter feedback imediato do cliente para que você possa produzir o que ele deseja (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 o progresso e explique que esse tipo de iteração é o que você gostaria de fazer para que eles obtenham exatamente o que desejam.

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

Eu 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, tentava me concentrar mais nos produtos e clientes Agile e tentava fazer essa parte crescer mais.

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

Outra idéia é tornar o Agile seu diferenciador. Eu sei que muitas, se não a maioria das grandes organizações, não estão fazendo o Agile. No entanto, a maioria (a grande maioria na minha experiência) de pequenas empresas é. Eu acho que o Agile está crescendo rapidamente e isso continuará. A vantagem dessa rota é que você está lançando o que mais deseja fazer aos 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 uma venda mais fácil para alguns clientes. Um livro que estou achando útil nessa área é 'Teste Ágil', de Adison Wesley Press.

Você também pode usar eventos atuais para apoiar seu caso. Por exemplo, o site atual de assistência médica (escrevendo isso em outubro de 2012) é um excelente argumento para NÃO lidar com as alterações necessárias duas semanas antes da entrada em operação. Além disso, o aparente excesso de engenharia provavelmente teria sido melhor abordado por métodos mais ágeis.

Entre em contato com clientes anteriores que estão felizes com seu trabalho. Especialmente se eles são convertidos em Cachoeira para Agile. No mínimo, converte que não eram seus clientes.

Seus depoimentos (como cliente) superam qualquer coisa e tudo o que você poderia dizer. Eles podem lidar com as preocupações e medos do seu novo cliente mais do que você jamais poderia.

Do ponto de vista gerencial, um orçamento e um prazo final são uma necessidade comercial do projeto. Você precisa se certificar de que está atendendo a essas necessidades e, se procurar os depoimentos de uma empresa sobre a mudança, perceberá que isso ocorre diretamente. Se você observar os depoimentos dos desenvolvedores sobre a mudança, notará que muitas vezes isso não ocorre.