você está aqui: Home  → Coluna do Cesar Brod


De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

O Grande Contrato

Por Cesar Brod

Data de Publicação: 12 de Julho de 2010

Trabalho com várias formas de integração de sistemas e desenvolvimento de soluções desde o final dos anos 80, sempre usando novas tecnologias. 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 a forma através da qual projetos deviam ser desenvolvidos. Quase dez anos depois comecei a estudar Extreme Programming, que usei junto com a UML (Unified Modeling Language) na gestão de desenvolvimento do projeto Gnuteca a partir de 2000. Mais adiante o Scrum passou a fazer parte não só da vida da nossa empresa como da minha forma de pensar.

Neste momento estou traduzindo, para a editora Campus Elsevier o mais novo livro do Fred, "The Design of Design", cujo capítulo quatro trata da questão do estabelecimento de contratos entre fornecedores e clientes. Já na abertura do capítulo, Fred cita um texto de Pahl e Beitz:

Qualquer tentativa de formular todos os requisitos possíveis no início de um projeto irá 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, onde uma série de coisas - como mudanças de tecnologia e requisitos - irão causar, inevitavelmente, desvios no rumo desta navegação, que 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. Desta forma, junto com a equipe de desenvolvimento, ele é capaz de avaliar, refinar o que está sendo desenvolvido, descobrir o que realmente deseja e, em especial, quais destes desejos realmente trarão as funcionalidades e vantagens realmente importantes para o sistema, todas alinhando-se 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.

Taí 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 ocorre. Idealmente, deve existir 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 na medida em que o sistema é desenvolvido e que o fornecedor não fique em desvantagem ao ter que modificar o que está desenvolvendo - muitas vezes sendo obrigado a jogar fora parte de seu código e considerar novas alternativas.

Há uma cultura muito forte, baseada na compra e 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á três anos, imaginou que estes clientes passariam a utilizar o twitter como a sua forma preferencial de elogiar ou reclamar dos produtos da empresa? Mais do que isto, eles esperam que a empresa manifeste-se também através do twitter. Mas é possível (ou mesmo vantajosa) a integração do sistema atual de relacionamento, de alguma forma automática ou semi-automática, com o twitter? Aí 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 desapercebidas.

Isto dá muito pano pra manga, mas só pra citar uma coisinha, eu sou totalmente contra a geração automática de boletins a partir de material que é colocado em sistemas de gestão de conteúdo. Por outro lado, acho legal avisar aos seguidores da empresa, no twitter, sobre a publicação de um conteúdo novo em sua página - desde que se tenha o pleno conhecimento de que estamos tratando de formas diversas de comunicação.

Mas divaguei. 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 deve auxiliá-lo a dominar 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 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 é, talvez, usar o passo intermediário de minicontratos. Identifica-se, junto com o 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) bastante grande. O limite mágico de tempo, a meu ver, é de três meses. Ainda há muitas empresas que estão começando a explorar melhor seus portais de conteúdo, sistemas de relacionamento com clientes e muitos outros para os quais há uma infinidade de sistemas plenamente customizáveis, modulares, que darão o espaço necessário para uma compreensão melhor de outras necessidades do cliente. Ao final deste período, sempre em conjunto com o cliente, explora-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, onde o fornecedor tem a tranquilidade de sua remuneração e o cliente reconhece que esta remuneração é justa e traz benefícios a seu negócio. Tal confiança suplantará, então, a necessidade de um contrato.

Sobre o autor

Cesar Brod usa Linux desde antes do kernel atingir a versão 1.0. Dissemina o uso (e usa) métodos ágeis antes deles ganharem esse nome. Ainda assim, não está extinto! Escritor, consultor, pai e avô, tem como seu princípio fundamental a liberdade ampla, total e irrestrita, em especial a do conhecimento.

Mais sobre o Cesar Brod: [ Linkedin ] | [ Twitter ] | [ Tumblr ].

Veja a relação completa dos artigos de Cesar Brod