Oi Cesar, o teu artigo retrata bem a realidade, que, concordo, deveria mudar. Apesar de projetos menores (com entregas mais frequentes) ser o ideal, o problema é que o mercado não trabalha dessa forma. São contratados (e vendidos) softwares (que solucionam todos os problemas) com escopo X, valor Y, tempo Z, e era isso. Ah, e geralmente o valor Y sai mais caro... ;-)
Além disso, o que se aprende na Universidade também vai nessa mesma linha, ou seja, as raízes do problema são maiores ainda. Até que uma cultura nova seja assimilada, demora um tanto.
Não consigo imaginar o desenvolvimento de projetos como Sagu, Gnuteca, Miolo (pra ficar nesses nomes) se tivessem sido contratados com escopo "fechado". (Aliás, eu nem lembrava que já fazem 10 anos!!) A diferença é que, nesse caso, o produto desenvolvido que era originalmente para consumo interno, ganhou o mercado e por isso estava mais "pronto". Agora, sabemos que o mercado queria "mais coisas", que esses softwares ainda não tinham.
Outro detalhe importante: no fundo no fundo, o gestor também gosta de ser enganado. Ele quer ouvir a promessa de que o software ABC vai atender a sua necessidade e resolver todos os seus problemas, como num passe de mágica. Porém, isso é um pouco difícil de acontecer, ou não? ;-)
Abraço,
Vilson
você está aqui: Home → Colunistas → Coluna do Cesar Brod
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.
Veja a relação completa dos artigos de Cesar Brod
Opinião dos Leitores
Vilson C. Gärtner
29 Jul 2010, 18:11
29 Jul 2010, 18:11
Cesar Brod
18 Jul 2010, 20:11
18 Jul 2010, 20:11
Oi Leonardo! Deve sair em setembro deste ano!
Leonardo S. R.
13 Jul 2010, 15:26
13 Jul 2010, 15:26
Bom saber que sobre a tradução do novo livro de Fred Brooks Jr., já ia comprar o meu em inglês. Qual a previsão para o lançamento?
Powered by Scriptsmill Comments Script
