em #Ágil
Gestão Comercial Ágil: compra e venda de projetos ágeis
Todos os dias, na busca incessante pelo conhecimento, nos deparamos com uma gama cada vez maior de desafios. Encontramos cada vez mais e mais informação, esse poço de onde extraímos a tal sabedoria parece nunca ter fim e mergulhamos em artigos, conceitos e uma gigantesca quantidade de conteúdo.
Como podemos aplicar explicitamente tudo o que chega ao nosso encontro? Qual a melhor maneira de armazenar e compartilhar todo esse conhecimento? Produtividade e foco estão sempre em evidência quando abordamos esses assuntos e conceitos que são os protagonistas de muitas análises, discussões e prerrogativas.
Dominar seus próprios conceitos, auto controle e uso adequando do conhecimento, o transformando assim em sabedoria, talvez isso seja o Santo Graal da Sabedoria mas, precisamos mesmo de tudo isso?!
Lembro que quando criança as aventuras e os desafios nos eram apresentados de outras formas. O conhecimento era inerente ao fazer, descobrir algo era comum e esse comum transformava algo simples em algo muitíssimo interessante, nos nutrindo de informações e nos ocupando por horas e horas com a mesma “distração”.
Durante pesquisas mais recentes, focadas em nutrir ainda mais o conhecimento pessoal e do nosso time, encontramos informações que nos serviram como elos em uma parte muito importante do nosso cenário como empresa de tecnologia: modelo ágil de contratos aplicado na compra, venda e gestão de projetos.
A seguir, ilustro o comentado acima, com uma tradução que fiz do Artigo (muito bem escrito) do Patrik Malmquist, onde o mesmo fala de forma simples e com muita clareza sobre o assunto.
Compra e Venda com Projetos Ágeis
Ao falar sobre projetos ágeis, muitos livros parecem ser escritos sob a suposição de que você trabalha com todo o ciclo de vida, desde a sua concepção inicial até a manutenção e suporte do sistema. Mas muitas vezes, partes do projeto são feitas por outro fornecedor. Este outro fornecedor pode ter uma motivação subjacente diferente e sua atividade pode não ser a mesma. O preço unitário mais comum no trabalho do conhecimento é, provavelmente, o preço por hora, direto ou indireto.
O modelo de renda do comprador é, provavelmente, diferente e pode se basear na redução de custos, ou em qualquer receita, ou novas oportunidades emergentes do produto (ou transação), ou intervalo de base, como o preço por mês. Portanto, um conflito interno pode existir entre o modelo de receita do comprador e o do fornecedor.
Quem deve assumir o risco comercial?
O comprador pode lidar com o projeto por conta própria e apenas contratar alguns consultores que irão trabalhar em uma base por horas, caso em que o risco integral permanece com o comprador. Porém, o comprador pode terceirizar uma parte do projeto de um fornecedor, que também terá uma parcela acordada ao risco como parte do negócio.
Isso é muitas vezes tratado com uma fase inicial que produz um documento, exigência de que um ou mais fornecedores usa ao desenvolver uma tentativa para ganhar o contrato do comprador. Os contratos geralmente incluem o custo total, algumas opções (geralmente add-ons) e a data em que a entrega deve ser feita.
O problema é que isso não facilita as mudanças e prejudica a flexibilidade de aplicação do conhecimento que se ganha durante o projeto. No início do projeto, manter o plano original se torna mais importante para ambas as partes, em vez de maximizar o valor do negócio. Isso impede que incorram a qualquer uma das partes, custos ou excessos de cronograma que poderiam transformar sua participação no contrato, uma proposta perdedora.
Esta inflexibilidade nega os benefícios do desenvolvimento ágil aos projetos, que são adaptáveis, de forma a maximizar o valor de negócios. Mas existem alternativas para tipos de contratos: fixed-scope/fix-price. Vou falar sobre os diferentes tipos de contratos em breve, mas primeiro gostaria de explicar o valor máximo focado.
Máximo Valor de Negócio
Se só temos uma idéia do que poderia criar o benefício que esperamos de uma solução de software específico, se torna difícil criar um plano preciso e detalhado de como alcançar esse objetivo. Projetos complexos têm soluções múltiplas, não há uma melhor maneira de executar um projeto de software. Nós não podemos prever as melhores soluções. Mas, se conduzimos o projeto como uma viagem exploratória à procura de melhores oportunidades que nos aparecem ao longo do caminho, melhoramos a chance de maximizar o valor do negócio. Isso ocorre porque quem realiza o projeto, provavelmente nunca fez este tipo de trabalho antes. Ele deve se concentrar na aquisição de conhecimento e fazer o melhor para a situação atual.
Ao mesmo tempo, o projeto deve permanecer no alvo para melhor visualização à longo prazo do que está acontecendo, fornecendo ao cliente a vantagem competitiva que ele está buscando.
O Princípio de Pareto
O princípio de Pareto (também conhecido como regra 80-20), indica que para muitos eventos, cerca de 80% dos efeitos são provenientes de 20% das causas. É uma regra comum no mundo dos negócios, por exemplo, “80% de suas vendas vêm de 20% dos seus clientes”.
A fim de ser capaz de analisar corretamente um projeto como comprador, uma abordagem eficaz pode ser o fornecedor primeiro mostrar como eles estimaram o trabalho, seguido de um diálogo entre comprador e fornecedor. Ao fazer o projeto inicial de um projeto de grande escala, é bastante comum que os requisitos sejam finalizados e priorizados antes sequer do fornecedor estimá-los. Mas como você pode saber se ele custa mais antes a estimativa?
Mostrando como a estimativa é feita, criando confiança entre ambas as partes. Em seguida o comprador recebe uma segunda chance para priorizar, tendo aprendido a partir do diálogo com o fornecedor, que algumas coisas poderiam criar mais valor do que outras. Os fornecedores não querem revelar suas estimativas para os seus concorrentes, mas essa questão pode ser resolvida com um acordo de confidencialidade. Lembre-se do recurso “usado em projetos fracassados”, que indica que 45% dos recursos nunca foram utilizados!
Quais são os contatos preço fixo?
Contratos a preço fixo são empregados quando a contratada assume um risco comercial a fim de completar uma quantidade pré-definida de trabalho. Esse risco vale um bônus, portanto, um prêmio ao risco é adicionado à estimativa inicial. O preço poderia ser 20% mais elevado do que a estimativa para cobrir o risco financeiro se as estimativas estiverem erradas.
Porque não usar contratos de preço fixo o tempo todo?
A resposta é estimativa, estimativa e estimativa! Se estimar fosse fácil e sempre feito corretamente, os compradores poderiam facilmente fazer uma análise custo elevado de confiança por si mesmos. Mas em situações complexas, onde as coisas dependem de muitas variáveis, estimativas iniciais precisas são quase impossível. Você precisa entender realmente em que nível você deve colocar o seu esforço. A solução pode ser desenvolvida de muitas formas diferentes e não há nenhuma abordagem universal ou “melhores práticas”, tudo depende do contexto do problema. Portanto, você como um fornecedor precisa realmente entender o contexto do problema e em que nível de qualidade este comprador espera as soluções.
Qual é o propósito de um contrato?
Os contratos devem definir os parâmetros básicos para um projeto, criando as condições ideais para concluir o mesmo com sucesso tanto para o comprador, quanto para fornecedor. Mas na prática, os contratos são muitas vezes vistos como competitivo e não cooperativo nos quais o objetivo é colocar a outra parte em desvantagem, especialmente se as coisas não vão de acordo com os planos.
Normalmente quando as pessoas dizem preço fixo, isso significa preço, tempo e escopo fixos. E tal conjunto requer requisitos documentados e detalhados, estáveis e precisos, além de tecnologia conhecida. A vantagem da abordagem ágil é lidar com o desenvolvimento quando os requisitos são mais confusos e não refletem adequadamente a realidade subjacente do negócio. Muitas empresas têm a idéia de escrever um contrato que fixa o âmbito e o preço, isso porque eles acreditam que irá reduzir o seu risco, mas quando começam a desenvolver o software, inevitavelmente as coisas mudam.
Na realidade, ter o escopo fixo, o custo fixo e o tempo fixo é muito arriscado tanto para fornecedores quanto para compradores, pois praticamente garante a entrega de software que a empresa não quer. Ou seja, entregasse sistemas com todos os requisitos implementados, no tempo previsto e dentro do orçamento, só para ver que os usuários não estão satisfeitos. Com o tempo se descobriu que não era só uma questão de nós “os fornecedores”, aprendermos mais sobre o cliente durante o projeto, os usuários perceberam que eles realmente são necessários durante o projeto. Ao final do projeto, eles não querem o que originalmente tinham exigido mas sim, um sistema que reflita sua nova representação do sistema até o final do projeto.
Se os compradores querem reduzir o risco e obter mais valor pelo seu dinheiro, os projetos devem se tornar repetitivos, e em seguida, o contrato terá que refletir isso. O que os compradores muitas vezes precisam é de um contrato de preço fixo ou um teto de preço para que eles possam tomar uma decisão de investimento.
O que inicialmente parece ser um contrato mais flexível, pode na realidade produzir dois benefícios: ajudar a elevar o valor do negócio e diminuir o risco. Nem você nem seu mecânico iria concordar com um preço fixo, com tudo incluso para reparar o seu carro antes de olhar sob o capô. Então, por que colocar uma camisa de força em algo que é muito mais complexo, mais caro e leva muito mais tempo como um projeto de desenvolvimento de software? Aqui estão algumas idéias de como você pode criar diferentes tipos de contratos, de acordo com cada situação…
Diferentes tipos de contratos
O tipo mais comum de contrato usado quando um fornecedor externo for entregar uma parte do processo é colocando um conjunto específico de requisitos em licitação. O licitante vencedor se torna o fornecedor, cujo trabalho é, então, regido por um contrato de preço fixo.
Gostou do Material?! Confira o nosso Taller Book sobre Gestão Comercial Ágil:
Além desta primeira parte, no e-book você irá encontrar a segunda parte desse artigo onde Patrik Malmquist descreve os tipos de contratos.
