Dezembro, 2004.

O Caos e a conexão,

Tornar o simples complicado é fácil,

tornar o complicado simples, isto é
criatividade (Charles Mingus).

Já acreditei mais no PMI, no RUP e no CMM. Quando revejo essas teorias fico
confuso. Não estou dizendo que as mesmas sejam confusas. Não digo que esses
modelos sejam ruins, pelo contrário os vejo com lógica e fundamento. As vejo
muito bem estruturadas e coerentes com um “pensamento analítico” e guiadas por
teorias (algo como um roteiro que basta seguir). Minha confusão vem exatamente
disso, pois propositadamente tenho questionado esses modelos lineares.

O PMI tem sua origem com a engenharia civil. Normalmente o produto a ser criado
com um projeto deste segmento é muito diferente do produto gerado através de
um projeto de software. A grande diferença está exatamente na concretude do
produto que será entregue. Quando iniciamos um projeto para construção de uma
casa, por exemplo, na fase de concepção temos condições de definir com muita
precisão o que deverá será feito. Neste tipo de trabalho o imaginário, ou
criatividade, é mais requerido, normalmente, na primeira fase, a do arquiteto. As
fases seguintes são realizadas a partir de premissas muito estáveis.

Diferentemente de um projeto de software que, no meu entendimento, só teremos

certeza do que exatamente vamos fazer depois de termos andado um bom
caminho na construção dos mesmos. Em outras palavras, a construção de
software é um processo de criação constante que acompanha todo o ciclo de
desenvolvimento como um modelo evolutivo.

Outro ponto que me preocupa é a burocracia exagerada que estes modelos

impõem (ao querer se utilizar as práticas preconizadas para o desenvolvimento de
software). Tenta através de um corpo conceitual um tanto volumoso, no detalhe,
transformar uma coisa caótica, que é por natureza a construção de software, em
uma ciência exata.

Vejo as duas outras como muito semelhantes, ao PMI, um roteiro a ser seguido
para que chegar no “céu”.

Tive oportunidade de conversar com um conhecido que trabalha com projetos de

software do segmento privado do mercado financeiro, diga-se, este profissional é
muito valorizado e respeitado, fiz a seguinte pergunta: “como você estima os

1
custos dos seus projetos?”. A sua resposta; ”feelings”. Aí fiz outra pergunta: “Tah!
Bem. Mas como você cumpre os prazos dos seus projetos?” Sua resposta: “com
paixão”.

Mais adiante na conversa, entendi que ainda não temos técnica para estimar um
projeto de software com a precisão que o pessoal da engenharia estima os seus.
Isso é conseqüência da grande intensidade do imaginário existente nos projetos
de software.

Agora voltando às tecnologias, ou boas práticas, apresentadas no inicio, a sua

utilização traz que benefício? A utilização intensiva destes modelos consegue uma
maior profissionalização dos envolvidos, o que não é sinônimo de maior eficiência.
Pois a burocracia tem exatamente o papel de profissionalizar, para tal normatiza
as coisas de modo que qualquer um possa desempenhar tais funções. Essas
conseguem fazer-nos chegar em um nível mediano de competência. Vejo que as
tecnologias são muito frias o que dificulta o trabalho com “paixão” ou “brilho nos
olhos”. Não consigo pensar em soluções de software revolucionárias sem essas
últimas variáveis.

Estas tecnologias jamais conseguirão provocar uma revolução. Talvez consigam

fazer com que uma organização, cujo produto seja soluções de software, se
aproxime das intermediarias. Mas não acredito que isso consiga fazer com que
uma organização seja uma organização de ponta. Para ser uma referência estou
convicto que o caminho passa por algo mais simples e mais ágil, ou como disse o
meu amigo: trabalhar com “paixão”.

Sempre vi meus projetos de software com algo próximo do caos. Meus planos
sempre foram ótimos, mas isso só eram verdadeiros até um dia antes de
iniciarmos os projetos. Sempre tive que improvisar muito no desenvolvimento
desses. Replanejar sempre foi minha prática diária. Meus desafios raramente
tiveram uma linha a seguir, pelo contrário, na maioria das vezes o caminho era
nebuloso. Isso sempre me incomodava. Esse incomodo que me fez procurar
entender os modelos, como tentativa de encontrar uma luz.

Não posso deixar de dizer que nestes meus quinze anos trabalhando com projetos
de software, me orgulho de dizer que tive o prazer de gerenciar muitos projetos.
Nunca tive um projeto fracassado. Também sempre consegui, com a ajuda de
muitas pessoas, cumprir os prazos. Agora entendo que realmente só cumprimos
os prazos por que trabalhávamos com paixão, durante o expediente, depois do
expediente, nos finais de semanas e feriados. Era com paixão mesmo, pois
éramos alegres e felizes.

Tenho lido algumas teorias ligadas à psicologia organizacional escrita por Bastos
(2004), onde tive contato com conceitos relacionados com a cognição. Um termo
genérico usado para designar todos os processos envolvidos no conhecer. A
atividade de conhecer envolve a aquisição, a organização e o uso do
conhecimento. Nestas teorias existem duas correntes para explicar o processo do
conhecer. A primeira é a “arquitetura simbólica” que descreve os processos

2
controlados em que o indivíduo encontra-se engajado, conscientemente, na
solução de um problema, valendo-se de regras e procedimentos. A segunda é a
arquitetura conexionista que fala de um processamento implícito que é automático
e inconsciente, que envolvem muitos processos perceptuais, que geram
conhecimento tácito e estão largamente presentes na vida cotidiana.

O Quadro 1, a seguir, compara as duas arquiteturas a partir de duas situações

hipotéticas.

Quadro 1 Arquitetura simbólica versus conexionista: um exemplo aplicado

(Bastos, 2004)

Arquiterura simbólica Arquitetura conexionista

Processamento serial Processamento paralelo/distribuido
Pensamento analítico, guiado pela teoria. Pensamento não-analítico, automático.

Após trabalhar muitos anos em uma empresa, Após trabalhar muitos anos em uma empresa,
participo de uma reunião de trabalho para um colega me fala sobre as dificuldades de
tomar a decisão sobre uma mudança ampla na relacionamento na sua equipe de trabalho.
estrutura organizacional.
• Ao ouvi-lo, processo simultaneamente
• Codifico o problema. Busco informações comportamentos verbais, não-verbais,
que delimitem o problema. dicas afetivas, normas culturais,
• Recupero da memória todo o experiências passadas.
conhecimento armazenado relacionado • De forma automática, faço comentários
com o problema. sobre o que possivelmente está ocorrendo
• Avalio todas as alternativas, na sua equipe.
confrontando-as com as estruturas de • Sem esforço cognitivo, utilizo regras
conhecimento prévio que possuo. prontas pra fazer julgamentos sobre
• Peso os prós e os contras cada pessoas, ações, relações, fazer
alternativa em função de esquemas que julgamentos, fazer recomendações.
possuo (normas e valores sobre como • A simples questão desencadeia cognição
deve ser uma organização). e comportamento como se eles já
• Formulo a decisão que considero mais estivessem prontos e disponíveis para
adequada. usar em um a situação conhecida.
• Armazeno esta nova informação,
incorporando-a com conhecimento já
disponível.

Depois de ter conhecido o quadro acima percebi que quando tentei utilizar as
teorias propostas (PMI, RUP, e CMM) na construção de uma solução de software,
o que fiz foi exatamente seguir algo como o modelo da “arquitetura simbólica”.
Como se seguindo um roteiro preciso, certo será o nosso porto de chegada. Quem
já teve o privilegio de fazer software e tentou, como eu, utilizar essas técnicas
sabe que a coisa é bem mais complicada.

A minha surpresa foi ver que a “arquitetura conexionista” é muito parecida com a
maneira que sempre utilizei para construir software. Neste ponto fiquei mais
animado. Então a minha técnica caótica tem fundamento. Faz sentido. Sempre fiz

3
software desta maneira. O que antes me incomodava agora tem lógica. Estou
acreditando no meu método. Encontrei uma conexão.

Posso estar enganado, mas algo me diz que se conseguirmos compreender, ver e
entender esse caos, vamos encontrar um caminho para simplificar e
desburocratizar o processo de desenvolvimento de software. Isso nos possibilitará
a liberação de muito dos nossos recursos para criar e inovar.

Na minha opinião para fazer software, basta termos um objetivo claro; um líder
carismático que consiga inspirar as pessoas para atingir um desempenho
excepcional que reconheça quando isso ocorrer e que comemore cada pequena
vitória; uma equipe motivada, comprometida e sem estrelas; um prazo factível
definido através de “feelings”; e um clima de sinceridade e abertura entre todos
(incluído o cliente). Com isso será muito fácil cumprir os prazos, pois todos irão
trabalhar com paixão. Ainda, sobrará tempo para que todos possam buscar
rapidamente os conhecimentos necessários, pois estaremos livres de quase toda
a burocracia impostas pelas siglas que mencionei.

by Elton Pedro Curtarelli

Referências Bibliográficas

Bastos, Virgílio Bittencourt. Cognição nas Organizações de Trabalho. Em J. C.

Zanelli; J. E. Borges-Andrade e A. V. B. Bastos (Eds.). Psicologia, organizações e
trabalho no Brasil. Porto Alegre: Artmed, 2004.

Charles Mingus, www.professorsoares.adv.br/pensamentos6.html, consultado em

22.12.2004.