Contrato aberto ou menos detalhado

Outro dia aprendi algo bem interessante com o Rafael Sabbagh. A discussão não deve ser se o contrato é aberto ou fechado, mas sim se o contrato é menos ou mais detalhado.

Isso faz muito sentido. Quanto mais detlhado o contrato, menos flexibilidade o time terá para adequar e aceitar mudanças. No nosso mundo ágil esta é uma das premissas mais importantes: Aceitar Mudanças.

Sim, aceitar mudanças. Mudanças do mercado, de requisito, de rumo! Somos influenciados por Lean Start up. Conseguimos fazer o tal de Inspect and Adapt. E seguimos práticas de desenvolvimento que nos permitem verificar se a mudança de hoje mnão quebrou o sistema.

Daí a sabedoria do Sabbagh quando diz que devemos falar de contrato com maior ou menor nível de detalhamento. Se detalhar demais, vai ter que ou (1) mudar o contrato, ou (2) trabalhar em algo que não está no contrato e provavelmente deixar de fazer algo que estava no contrato.

Valeu Sabbagh! Neste momento estou trabalhando num contrato. Sim, o escopo é fechado, mas em um nível bem elevado, sem muito detalhamento. Permitindo assim as mudanças que hão de vir.

Comments

  1. Danny de Souza Lopes:

    E aí Paulo blz? E como vc lida com o “ponto de corte” nesses casos em que o escopo está muito alto nível? Pode ocorrer do cliente sempre achar que o requisito de alto nível não está sendo atendido.
    Parabéns pelo post, pois instiga uma discussão recorrente no Agile.

    Reply

  2. Paulo Caroli:

    Fala Danny!
    Boa pergunta.
    O ponto de corte realmente é algo difícil de definir e pode dar pano pra manga.
    Eu vejo isso em 2 cenários:
    1. Vai dar errado e vai ter discussão. Contratante e contratado vão ter de entrar em um acordo; isso independente do nível de detalhamento do contrato.
    2. Vai dar certo e vai ter comemoração! Contrato; que contrato?! Contratante e contratado vão falar dos próximos projetos. E agora com um nível de confiança e entendimento mais elevado.
    Ou seja, o sucesso ou o fracasso vai bem além do contrato. Eu sigo pensando que o contrato deve ser o mínimo necessário, e todos devem focar no relacionamento e na execução.
    Desenvolvimento de Software é muito mais empírico do que repetitivo e previsível. E todos requisitos nada mais são do que hipóteses sobre mais hipóteses.
    Abs,
    Paulo

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


3 − one =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *