Alguns artigos já publicados no Webinsider se propuseram a discutir a realidade complexa dos projetos web. Conceitos, estratégias, experiências e dicas foram sugeridos para ajudar na definição de práticas, métodos e metodologias para o desenvolvimento de projetos web [1].

A comunidade acadêmica também entende que as metodologias de engenharia de software precisam ser adequadas e especializadas para atender aos projetos de sistemas de informação voltados para web [2].

Resolvi escrever uma trilogia com o objetivo de debater a natureza complexa dos projetos web, quais as suas origens, como gerenciar e quais metodologias aplicar nesses projetos, e finalmente, quais modelos de negócios são viáveis para atuar no mercado dos projetos web.

1 – Wicked Problems e a natureza complexa dos projetos web

O ponto de partida é fundamentar a natureza complexa dos projetos web e compreender suas origens. Para isso recorro à teoria de Design e Wicked Problems.

1.1 ? A árdua atividade de projetar

Design é uma palavra inglesa que pode ser entendida como o ato de projetar. Uma definição clássica para design é: ?processo de criar artefatos tangíveis para atender necessidades intangíveis do ser humano, através de um processo de decomposição e resíntese do problema, a partir de negociação e deliberação, o que fundamentalmente inclui incertezas e conflitos? [3].

Os fatores relacionados à complexidade do design estão mais associados ao processo do design do que propriamente ao artefato [4]:

• Falta de conhecimento prévio sobre todas as especificações e restrições.
• Várias alternativas surgem durante o transcurso do design, exigindo um esforço para avaliar quais delas melhor atendem às especificações sem contrapor as restrições.
• Devido à falta de informação, suposições são feitas para que o design continue. Mais tarde, se uma dessas suposições mostrar-se falha, o design deverá ser revisto, alterando as partes do design que dependiam dessa suposição.
• Para tornar o design menos complexo, um problema costuma ser dividido em subproblemas menores. Porém nem sempre esses subproblemas são independentes. Uma solução que parece ótima para um subproblema, poderá influenciar negativamente na solução de outro subproblema.

O processo de design consiste em ciclos de construção e reflexão que ocorrem em diferentes níveis, evoluindo através de discussões, desenvolvimento, reuniões de verificação, testes em protótipos, revisões, verificações formais, etc. Isso exige uma intensa atividade colaborativa que apresenta problemas de comunicação agravados pela existência de colaboradores que possuem diferentes conhecimentos e especialidades, cada um falando diferentes linguagens.

1.2 ? Design como Wicked Problems

O design pode ser descrito como um ?wicked problem?, termo sugerido por Rittel [5] para descrever uma classe de problema com as seguintes características:

• Não tem uma definição única nem definitiva. É impossível encontrar a melhor solução porque o número de soluções possíveis é muito grande. Portanto, o foco está na busca da solução que seja boa o suficiente.
• A resolução do problema é basicamente social, no qual a existência de uma resposta correta é menos importante do que a aceitação da solução pelos envolvidos no processo.
• As regras (variáveis) envolvidas na solução mudam durante o tempo. O processo de resolução do problema termina quando o tempo ou os recursos acabam.
• Não existe a definição ou entendimento claro do problema até que se desenvolva uma solução.

Estudos sobre a atividade de design [6] constataram que o que conduz o processo de design é um conjunto de fatores imprecisos, muito influenciados pelo pensamento criativo dos envolvidos no processo. O processo não linear não é caracterizado por falta de conhecimento ou despreparo, mas é baseado num processo natural de aprendizagem.

Isso contraria a tendência natural de imaginar que quanto mais complexo um problema, maior necessidade em seguir um fluxo linear. O gráfico na figura 1 apresenta o processo cascata.

Figura 1: processo cascata [6]

.

A figura 2 apresenta o processo não linear de resolução de problema utilizado pelo projetista e o compara com o processo cascata. Os projetistas ao tentarem entender o problema, já iniciam simulações em busca de eventuais soluções. A cada tentativa, novas informações vão sendo adquiridas e um refinamento dos requisitos é feito de forma gradativa, o que ficaria limitado num processo cascata onde somente após a análise de dados é possível iniciar a formulação de uma possível solução.

Figura 2: processo real de resolução de problema x processo cascata – [6].

.

1.3 ? Não torne seu projeto um Wicked Project

Segundo Rittle [5], o contrário de um Wicked Problem é um ?Tame Problem?, uma classe de problema que pode ser resolvido a partir da aplicação de técnicas bem definidas. Um processo linear pode ser aplicado para resolver o problema durante um período definido de tempo, e a resolução do problema pode ser claramente identificada a partir de um resultado final previsível.

A regra a ser aplicada é: não torne seu projeto web um Wicked Project, complexo e sujeito a problemas devido às características de um wicked problem. Trabalhe sempre tentando manter seus projetos com características de um ?Tame Problem?. Seguem alguns pontos a considerar para tornar isso possível:

Identificação: identifique o mais breve se o seu projeto possui falta de consenso, falta de entendimento sobre o problema, interesses incomuns, ou simplesmente não pode ser resolvido a partir da aplicação de metodologias e técnicas. Nesse cenário, não existe uma resposta correta ou ideal, a busca é pela solução adequada ou possível.

Taming: na minha visão essa é a vantagem competitiva de uma empresa de projetos web: possuir equipe, processos e metodologias capazes de lidar com essa natureza complexa em larga escala. Tecnologia para adaptar o ?wicked? em ?tame? é fundamental. Esse tópico é tão importante que será tratado num próximo artigo Metodologias para Projetos Web.

Adaptação: Wicked Projects não podem ser tratados como ?Tame Problems?. Desta forma, alguns projetos não poderão ser resolvidos seguindo a cartilha da empresa sobre qualidade, gerência de projetos e metodologias de desenvolvimento. Será preciso adaptar a forma de trabalhar para tratar essa classe de projetos, mas sem esquecer a rentabilidade das empresas. Esse tópico será abordado em detalhes no artigo Projetos Web e Negócios Sustentáveis.

1.4 ? Considerações finais

Compreender os projetos web como um processo de design e um wicked problem é o ponto inicial para nossa discussão sobre como manter qualidade, clientes satisfeitos e rentabilidade. Esse é um conhecimento de uso prático que serve para nortear o pensamento de toda organização e serve como filosofia para o desenvolvimento de metodologias. É um conhecimento que também pode ser ensinado aos clientes, afinal de contas, eles também fazem parte da engrenagem social que origina e mantém toda essa complexidade. [Webinsider]

1.5 ? Referências:

[1] Lista de Artigos publicados no Webinsider:

• Sobre o excesso de trabalho nas agências de internet
• Metodologia e desenvolvimento no 8P da Globo.com
• Gerência de projetos em aplicações web é diferente
• A dinâmica do mercado e as exigências de prazo
• Como lidar com a briga qualidade versus prazo
• Uma abordagem prática para projetos em crise

[2] PRESSMAN, R. S. Engenharia de Software. 6a edição, Parte 3 ? Aplicação de Engenharia da Web. Editora McGraw-Hill, 2006

[3] MORAN, T. P. AND CARROLL, J. M., Overview of Design Rationale. In Moran, T. P., and Carroll, J. M. (Eds.) (eds.) Design rationale: concepts, techniques, and use. Lawrence Earlbaum Associates, Mahwah, NJ ? 1996

[4] BROWN, D.C. & BIRMINGHAM, W.D., Guest Editor?s Introduction: Understanding the Nature of Design, IEEE Expert,12(2), pp. 14-17 ? 1997.

[5] RITTEL, H. AND WEBBER, M. “Dilemmas in a General Theory of Planning,” Policy Sciences 4, Elsevier Scientific Publishing, Amsterdam, pp. 155-159, 1973.

[6] CONKLIN, J. Wicked Problems and Social Complexity (Revised April 2, 2003), In http://cognexus.org/wpf/wickedproblems.pdf, Setembro de 2004. Chapter 1 of the forthcoming Dialogue Mapping: Defragmenting Projects through Shared Understanding.

.

Gilber Machado

<strong>Gilber Machado</strong> (gilber@e-brand.com.br) é diretor executivo da <strong><a href="http://www.e-brand.com.br" rel="externo">e-brand</a></strong> e consultor de inovação da <strong><a href="http://www.inbate.com.br/" rel="externo">InBate</a></strong>.