Como contratar projetos com metodologia SCRUM

Este blog abre espaço hoje para reproduzir o excelente artigo de Rafael Ramos, do blog Conhecimento e TI: “SCRUM: Qual a melhor forma de contratar?“. O uso desta metodologia cresce rapidamente. Rafael dá dicas para não fazer feio e nem gastar excessivamente com estas contratações.

————————–

SCRUM: Qual a melhor forma de contratar?

Contratos com preço fechado? Valor hora? Escopo aberto? Neste post você terá um overview a respeito dos tipos de contratos que podem ser definidos para times que usam SCRUM. Confira!

Confesso que sempre achei que as metodologias ágeis demandam uma nova cultura na empresa, sobretudo, nas formas de contratação de projetos junto aos seus clientes. Pense comigo, se você tem uma metodologia que diz que seu planejamento será quinzenal, por exemplo, como você pode chutar (digo CHUTAR com muita convicção) que um projeto vá durar 2000 horas? Por mais que você utilize sua experiência acumulada em anos de profissão, isso não passará de uma previsão. PREVISÃO!

Após conferir a apresentação do José Papo com o título “Contratos e SCRUM: The Good, The Bad And The Ugly”, me motivei a escrever esse post pois acredito que o SCRUM nunca será utilizado de fato em uma empresa se os contratos não forem adaptados ou refeitos.

Na apresentação, José Papo aborda três tipos diferentes de contratação: os contratos com escopo variável (a forma boa), os contratos com preço fixo (a má) e a aquisição progressiva e por pontos de função (a “feia”).

Irei me concentrar nesses três tipos, fazendo uma análise sobre cada um:

Contratos com escopo variável

Os contratos com escopo variável, ao meu ver, são os que melhor se encaixam na proposta de trabalho do SCRUM. Obviamente, nenhum cliente estará disposto a gastar milhares de reais com a sua empresa se você não der uma previsão do que ele receberá em troca deste valor. Isso faz parte do processo de troca em uma negociação: eu te darei X, você me dará Y.

O grande problema, senão o maior, reside no fato de que software é algo imprevisível, obscuro e os requisitos, muitas vezes, só são descobertos no decorrer do desenvolvimento. Isso sem contar na indecisão do cliente sobre quais requisitos realmente são necessários.

Sendo assim, um planejamento inicial se faz necessário no que diz respeito à previsão do que será entregue. Porém, o que será entregue e como será entregue será definido junto ao cliente nos Sprints Plannings.

Nem tudo são flores. Este tipo de contratação requer transparência na relação entre fornecedor e prestador de serviços. Essa transparência em muitas das vezes não é vista nessas relações, provavelmente por fracassos em projetos passados. Porém, já que o objetivo é uma mudança cultural, por que não propor uma experiência de dois meses com seu cliente?

P.S.: Este é o tipo de contrato que utilizo atualmente e por isso sou muito seguro quando afirmo que dá certo.

Contratos com preço fixo

Gostaria muito de não ter que comentar a respeito deste tipo de contratação e, infelizmente, a mais utilizada no mercado de TI. Nesse tipo de contratação, prestadores de serviço incluem gorduras no orçamento, justamente prevendo uma eventual (e bem provável) falha no planejamento e levantamento de horas. O cliente, como muitas das vezes só quer um número, fica satisfeito.

O José Papo tem uma frase muito interessante sobre este tipo de contratação:

“Quando o custo, cronograma e escopo são fixos o que variará para baixo? A qualidade!”

Aquisição progressiva e por pontos de função

Nesta modalidade, o cliente compra um “tamanho” de software. Esse tipo de contratação também se casa com o SCRUM, por ser flexível às mudanças .

Conclusão

Posso afirmar que a negociação contratual é uma das etapas mais difíceis na implantação de um processo ágil. No meu caso, por exemplo, as coisas foram muito mais fáceis pois, na nossa equipe, o contrato já era regido no tipo H/H. Porém, o que fazer quando não há alternativas? Tente! Mostre para o cliente vantagens de um novo tipo de contratação. Utilize exemplos reais. Não jogue o risco para o lado do cliente somente. Peça um voto de confiança em troca de parte do risco. Divida os riscos!

Qual é sua experiência com contratos e SCRUM? Conte para a gente!

Rafael Ramos trabalha na área de TI há mais de 8 anos, onde desempenhou os papéis de analista de sistemas, coordenador de fábrica de software e Scrum Master.
Anúncios

7 responses to this post.

  1. Olá Lucas,

    Obrigado pela recomendação. Posso dizer que nossos blogs são complementares e ainda vamos trocar muitas figurinhas nesses assuntos.

    Um grande abraço!

    Responder

  2. Lucas, parabéns pelo site.
    Pelo jeito deve ser muito útil para os que estão ligados à área.

    Um abraço

    Frank

    Responder

  3. Olá,

    Realmente na teoria a negociação por escopo aberto fica muito mais atrativa para ambos os lados. O fato é que no Brasil as empresas ainda engatinham no que se diz respeito a projetos de software. Digo isto no range que nossa empresa atinge que é de médias e grandes.

    Na minha opinião existe dois tipos de projetos :

    1 – Projeto / Produto

    O cliente deseja seu “produto” e para isto ele quer o número (como mencionado acima). Para estes casos que normalmente são conceitos definidos ( ex: automação da minha equipe de vendas ) fica bastante complicado aplicar “time / materials”.

    2 – Projeto de Desenvolvimento

    O cliente tem uma idéia do que deseja ( normalmente empresas de software que quer verticalizar uma solução e repassar para seus clientes ) mas não tem a definição final do seu “produto”. Para estes casos não temos dificuldade de implantar o “time / Materials ou h/h. O interessante é que estes projetos para nós são sempre provenientes do exterior, onde obviamente a aquisição de software é bem mais madura.

    Clario que nosso esforço será caminhar cada vez mais para a contratação do escopo aberto principalmente porque estamos voltados para metodologia agil.

    Abs

    Responder

  4. Artigo muito bom.

    Tenho usado muito o site http://www.inkplanner.com para acompanhamento e gerência de meus backlogs, isso me dá uma maior confiança nas estimativas e projetos gerados para rodar em SCRUM. Tem uma interface muito amigável de arrastar as anotações para organizá-las, mais fácil e rápido de usar que muitas outras ferramentas por aí.

    Pra quem se aventura no SCRUM vale a pena dar uma olhada no InkPlanner.

    Abraços,
    Daniel

    Responder

  5. Posted by Christine on maio 3, 2011 at 5:55 pm

    Oi Lucas,

    Obrigada por esta experiência, é exatamente a minha questão neste momento. Eu sou do lado Cliente (na gestão de TI), querendo implantar um modelo SCRUM com o nosso fornecedor, e preciso encontrar uma forma de contratação com os jurídicos.

    Tenho uma questão, pois vc coloca:

    a terceira opção por ponto de função como “feia”, e no final escreve:
    “Nesta modalidade, o cliente compra um “tamanho” de software. Esse tipo de contratação também se casa com o SCRUM, por ser flexível às mudanças .”

    Qual é o ponto “feio” no seu ver ? pois não tenho experiência com pontos de função.

    Agradeço muito pela sua resposta.

    grata
    Christine

    Responder

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s

%d blogueiros gostam disto: