2ª EDIÇÃO
Cesar Brod
Novatec
Copyright © 2013, 2015 da Novatec Editora Ltda.
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.
É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização,
por escrito, do autor e da Editora.
Editor: Rubens Prates
Assistente editorial: Priscila A. Yoshimatsu
Revisão gramatical: Viviane Oshima
Editoração eletrônica: Carolina Kuwabata
Capa: Carolina Kuwabata
ISBN: 978-85-7522-441-0 IG20150625
Histórico de impressões:
Julho/2015
Agosto/2013
Segunda edição
Primeira edição (ISBN: 978-85-7522-376-5)
Novatec Editora Ltda.
Rua Luís Antônio dos Santos 110
02460-000 – São Paulo, SP – Brasil
Tel.: +55 11 2959-6529
E-mail: [email protected]
Site: www.novatec.com.br
Twitter: twitter.com/novateceditora
Facebook: facebook.com/novatec
LinkedIn: linkedin.com/in/novatec
capítulo 1
Contratos em tempos ágeis
Preço e escopo fixo não
combinam com dinamismo.
Não se aprisione a contratos que
tornarão seu trabalho inútil e seu
cliente infeliz.
29
30
Scrum 2ª edição
Trabalho com várias formas de integração de sistemas e desenvolvimento
de soluções desde o final dos anos 80, sempre usando tecnologias novas e
emergentes. Fui apresentado ao livro O mítico homem-mês, do Fred Brooks
Jr., em 1988, e ele foi fundamental na formação do meu pensamento sobre
os meios pelos quais os projetos devem ser desenvolvidos. Quase dez anos
depois, comecei a estudar Extreme Programming, que usei junto com a
UML (Unified Modeling Language) no de desenvolvimento do projeto
Gnuteca1 (um sistema de gestão de acervo e circulação para bibliotecas) a
partir de 2000. Mais adiante, o Scrum passou a fazer parte não só da vida
da minha empresa como também da minha forma de pensar.
Em O projeto do projeto, outro livro de Fred Brooks Jr., o autor cita um
texto de G. Pahl e W. Beitz, especialistas em projetos de engenharia:
Qualquer tentativa de formular todos os requisitos possíveis no
início de um projeto falhará e causará atrasos consideráveis.
Mais adiante, o próprio Fred conclui:
A pressão por um conjunto de requisitos completo e acordado
provém, em última instância, do desejo – com frequência, uma
demanda institucional – por um contrato de preço fixo para
uma entrega específica. Ainda assim, esta demanda está baseada frontalmente na evidência concreta de que é essencialmente
impossível especificar um conjunto completo e preciso de requisitos para qualquer sistema complexo, a não ser através da
interação iterativa com o processo de modelagem.
Parece-me que todos aqueles que desenvolvem alguma experiência com
gestão de projetos acabam chegando a conclusões parecidas. Jeff Sutherland, em sua apresentação “As raízes do Scrum”, comenta que é importante
levar em conta que as metas de um projeto são alcançadas a partir de um
“espaço de navegação” dinâmico, em que uma série de coisas – como mudanças de tecnologia e requisitos – causarão, inevitavelmente, desvios no
rumo dessa navegação, os quais devem ser constantemente considerados.
Eu defendo, sempre, o desenvolvimento de protótipos prematuros, mesmo que não totalmente funcionais, que permitam ao cliente experimentar
seus próprios requisitos e seu atendimento. Dessa forma, junto à equipe de
desenvolvimento, ele é capaz de avaliar, refinar o que está sendo desenvolvido, descobrir o que realmente deseja e, em especial, quais desses desejos
1 http://www.gnuteca.org.br
Capítulo 1 ■ Contratos em tempos ágeis
31
realmente trarão as funcionalidades e vantagens realmente importantes
para o sistema, todas se alinhando cada vez mais a seu negócio, dentro do
espaço de navegação que está sendo explorado.
Vou além. Piamente acredito que contratos de desenvolvimento são absolutamente inúteis e apenas amarram o cliente a definições que ele fez sem
o total conhecimento do que ele realmente desejava. Infelizmente, hoje, os
contratos mais penalizam o cliente do que o auxiliam. Eles dão a desculpa
aos fornecedores de entregar, protegidos por um contrato, exatamente aquilo
que o cliente não conseguirá utilizar na forma em que foi entregue.
Aí está um problema cuja solução não é fácil, e, ainda que exista, ela
não pode simplesmente ser replicada em todas as situações em que tal
problema ocorre. O ideal é que exista uma relação de confiança absoluta
entre cliente e fornecedor, de forma que o cliente não tenha receios em
mudar seus requisitos ao descobrir novas necessidades à medida que o
sistema é desenvolvido e que o fornecedor não fique em desvantagem ao
ter de modificar o que está desenvolvendo – muitas vezes, sendo obrigado
a jogar fora parte de seu código e considerar novas opções.
Há uma cultura muito forte baseada na compra e na venda de produtos finalizados. Infelizmente, tais produtos, especialmente tratando-se de
software, existem cada vez em menor quantidade.
Será que uma empresa que adquiriu uma solução de gestão de relacionamento com seus clientes, há alguns anos, imaginou que esses clientes
passariam a utilizar o Twitter ou o Facebook como a sua forma preferencial
de elogiar ou reclamar dos produtos da empresa? Mais do que isso, eles
esperam que a empresa se manifeste também por meio das redes sociais.
Mas é possível (ou mesmo vantajosa) a integração do sistema atual de
relacionamento, de alguma forma automática ou semiautomática, com
essas redes? Há uma série de outras questões e críticas relativas a graus de
automação e integração entre sistemas. Eliminando humanos de certos
processos, coisas importantes passarão despercebidas.
Isso dá muito pano pra manga, mas, apenas para citar uma coisa, sou
totalmente contra a geração automática de boletins informativos a partir
de material que é colocado em sistemas de gestão de conteúdo em uma
empresa. Por outro lado, acho legal avisar aos seguidores da empresa, no
Twitter, que há publicação de um conteúdo novo em seu portal – desde
que se tenha pleno conhecimento de que estamos tratando de formas
diversas de comunicação.
32
Scrum 2ª edição
Mas divago. A oferta de uma solução que atenda a um cliente deve passar
por uma fase de aquisição de conhecimento de seu negócio. Não total, é
claro. O cliente sempre dominará seu negócio e qualquer ferramenta tecnológica que entregarmos a ele deverá auxiliá-lo a dominá-lo ainda mais.
Ter a pretensão de que entenderemos totalmente o negócio do cliente é a
mesma coisa que imaginar que o cliente virá a dominar a linguagem de
programação, frameworks e métodos que usaremos para desenvolver uma
solução. De novo, devemos navegar, em conjunto com o cliente, no espaço
do projeto, da modelagem e da criação de seus sistemas.
Uma forma de se começar a migrar dos grandes contratos para uma
solução de plena confiança mútua é usar o passo intermediário de minicontratos. Identifica-se, junto ao cliente, uma área específica de seu negócio
para a qual possa ser desenvolvida (ou melhorada) alguma solução, com
segurança e compromisso de ambas as partes e um limite de tempo (e consequente limite de funcionalidades) suficiente. O limite mágico de tempo
é três meses. Ainda há muitas empresas que estão começando a explorar
melhor sua presença web, seus sistemas de relacionamento com clientes
através de aplicativos para dispositivos móveis e muitos outros para os
quais há uma infinidade de opções plenamente customizáveis, modulares,
que darão o espaço necessário para uma compreensão melhor de outras
necessidades. Ao final desse período, sempre em conjunto com o cliente,
exploram-se novas oportunidades. No decorrer do tempo, a navegação
pelo espaço de projetos e soluções torna-se um processo contínuo e de
confiança, em que o fornecedor tem a tranquilidade de sua remuneração
e o cliente reconhece que essa remuneração é justa e traz benefícios a seu
negócio. Essa confiança suplantará, então, a necessidade de um contrato.