Quarta-web: Designers são a culpa de projetos atrasarem

[Léo Hackin]

O Quarta-web dessa quarta (16/09) foi bem bacana mas sou parte da massa e resolvi botar esse tópico no sentido de fomentar a discussão levantada pelo amigo Denis Ferrari, que palestrou falando sobre pessoas e processos, sobre designers.

É recorrente que os programadores "brincam" com os designers associando seu trabalho à frescura e adornos mas foi posto uma visão diferente, associando atrasos em entregas e problemáticas de processo aos designers e suas sutilezas durante a palestra do amigo Denis Ferrari.

Muita gente ficou quieta, muita gente ficou revoltada.

Para quem foi, qual foi a opinião?

Com todo respeito, achei de um desconhecimento sem tamanho botar a culpa da falha do processo de produção no designer, dado que este é apenas parte constante no processo de criação e desenvolvimento. Se ocorre um problema tão grave, talvez seja problema de ingerência ou experiência no gerenciamento de equipe ou mesmo o desconhecimento da capacidade da equipe que ocasiona o atraso de cronograma ou até mesmo falha na definição de escopo de um projeto.

Compartilhando e dando vazão à vários comentários, tanto a menção aos designers quanto as explicações posteriores dadas pelo Denis foram insuficientes e desprovidas de números e fatos para realmente embasar a afirmação de que os designers sempre atrapalham.

Enfim, como pessoa envolvida dos dois lados da moeda, produção e gerenciamento, o que me resta pergunta é:

- quantas equipes web foram gerenciadas para chegar à essa conclusão;
- quantos anos de experiência se tem para julgar que um designer é a culpado;
- quantos projetos foram feitos com esse tipo de problemática.

Fica esse julgamento e reflexão não apenas ao Denis, que querendo ou não se torna um formador de opinião e tem SIM que pensar bem sobre o que vai falar para não polemizar sem argumentos (desculpe, mas todos foram completamente infundados no pós-desculpa), mas à todos os profissionais que são gerentes de projeto e lidam com isso no seu dia-a-dia.

Abração.

[Leo Cabral]

Vi a palestra como uma grande dinâmica sobre o assunto em si. Denis discorria
sobre relacionamentos entre membros da equipe e formas de atingir eficácia
e eficiência através da mediação apropriada das relações humanas no ambiente
de trabalho; algo que, a meu ver, é um campo do conhecimento humano
tão subempregado quanto um cabide numa praia de nudismo.

A relação designer/programador tem seus altos e baixos por serem dois extremos
disciplinares do desenvolvimento web; um lado com caráter objetivo, com cálculos,
algoritmos, processos e etapas sistemáticas; e outro com caráter subjetivo de insights,
abstrações, modelagens mentais e brainstorms. São línguas diferentes e dessa forma
é esperado que exista ruído na mensagem.

Foi comum para mim, ver ao longo da minha experiência ambos os lados subestimando,
desmerecendo e subvalorizando o trabalho da outra parte, simplesmente por não compreender
o valor daquela parte no todo. Foi comum ver o papel dos dois lados desmerecido
ou incompreendido pela gerência e, claro, também foi muito comum ver o trabalho
da equipe inteira ou empresa ser desmerecido ou incompreendido pelo cliente.
(graças a D-us surgiram coisas como Scrum para ajudar).

Como designer, gostei da palestra do Denis como um todo, o comentário não chegou
a desvalorizar as outras informações. Até me lembrou das discussões tempestivas
ou não que eu tinha com colegas que já trabalhei, profissionais de desenho industrial
e analistas/programadores sobre competências e vocações.

Abraço.

[Diego Sana]

Acho que o Leo Cabral matou a questão.

No mais, já que as desculpas já foram pedidas e a discussão não descambou pra flame war, vamos zoar: http://www.youtube.com/watch?v=8P-P364JoHw :)

[Daniel Dac]

A pergunta é: Quem tem o EGO maior? Designers ou Desenvolvedores? rs

[Giovane Barbosa Merisio]

O designer cria a apresentação do sistema ou site. O programador vai trabalhar as funcionalidades da apresentação para que o sistema ou site funcione como um todo corretamente. Ambos são necessários. Um site lindo, maravilhoso, cheio de flores como o Coradini curte sem uma boa programação vai ser nada mais que uma imagem. Da mesma forma que um sistema com uma boa programção e uma má interface não dará certo vai causar a fúria de seus utilizadores.

Eu gosto de programar e gosto de pensar no design, o problema todo é a forma e metodologia de trabalho entre os dois mundos. Deve se encontrar uma forma que ambos conheçam um pouco de cada para poderem trabalhar de forma correta, sem deixar "gambiarras" de cada lado em pról da conclusão de uma tarefa sabendo que vai prejudicar o outro lado. Utilizar de padrões como MVC para aplicações e sistemas na web ajuda bastante. Ambos tem que conheçer e utilizar de metodologias e padrões para trabalharem em conjunto de uma maneira harmônica.

O design é o primeiro a causar o impacto no usuário no sentido de conquistá-lo ou expulsá-lo do site ou sistema. Design e programador são como luz e travas, bem e mal, quer queiram ou não estarão sempre em lados opostos totalmente dependentes entre sí.

[Gilber Machado]

Na minha opinião, o maior culpado é aquele q aponta o dedo pra culpar os outros, e encontra uma forma de tirar o seu da reta com a frase "fiz a minha parte!". Esse profissional é a pior espécie para atuar em projetos!

E bola pra frente, discussão no grupo serve para ajustar entendimento e respeito entre as pessoas.

E parabéns a Hackin que fez uma contribuição legítima, não ficou detonando as pessoas pelas costas! Que sirva de exemplo para boca pequena que gosta de fazer piadinha, critica mas não contribui c/ nada efetivamente.

[Igor Zon]

Concordo com o Leo Cabral e acho que o comentário do Denis não foi tão grave para desmerecer a apresentação dele, afinal, esta discussão "designer x programador" não é de hoje que rola dentro das empresas, faculdades e etc. Prefiro levar como um comentário infeliz do que um desmerecimento.

Coincidentemente, hoje saiu uma matéria no iMasters falando sobre Gestão em Design: http://imasters.uol.com.br/artigo/14238/teoria/gestao_em_design_par.... Interessante.

[Hugo Cristo]

Olá a todos. Eu participo pouco, mas leio as discussões quando posso. Depois de ler todos os argumentos resolvi contribuir de uma forma que parece agressiva, mas não é. A maioria dos meus pontos de vista estão condensados e resumidos e precisam ser sustentatos por exemplos energéticos.

Como bom designer, eu penso nos outros e marquei sete pontos em negrito que resumem todo esse texto que é bem longo. Quem não tiver tempo ou paciência de ler tudo, pode ler esses pontos e terá uma visão geral do meu ponto de vista.

Vamos lá:

Por que a discussão design x programação sempre acaba na oposição entre subjetivo x objetivo, cálculo e insights, forma e conteúdo?

1. Forma (desenho) não é design.

Não existe outro nível de discussão que possa ser atingido? Não é possível que exista tanto desconhecimento sobre a área de design no ES que provoque uma limitação tão severa nas questões de projeto.

O mercado capixaba, assim como o brasileiro, não está preparado para absorver o profissional de design. Não estava há 40 anos quando a primeira escola foi criada e não está hoje. Mas por outro lado, esse mesmo mercado despreparado já percebeu que nenhuma área produtiva pode se dar o prazer de menosprezar a realização do design na sua estrutura gerencial. Não é uma questão de simples desconhecimento, mas da lógica do mercado que prefere adotar o design em doses homeopáticas ou em ações pulverizadas, criando uma percepção reducionista sobre a atuação do designer. Tem a ver com custo, com falta de escolas, com outros profissionais apagando micro-incêndios aqui e ali.

2. Designer não é desenhista, arte-finalista, nem piloto de master collection cs4.

O design não tem a ver com desenhar interface, com estética de layouts nem muito menos apresentação de nada. Design é projeto, é mediação cultural. Isso pode ter a forma de um software, de um banco de dados, de uma placa de trânsito ou da calcinha da Deyse Tigrona. Tanto faz.

A problemática do designer não está nos produtos, mas nos processos. Interessa pouco (ou nada) discutir o design de alguma coisa com base na sua aparência final, uma vez que é impossível concluir, a partir da superfície, o conjunto de questões de projeto (sociais, políticas, econômicas, semióticas) que a geraram.

3. O design não está na superfície dos objetos, mas na articulação das demandas do projeto.

Então, faz menos sentido ainda considerar que existe uma oposição qualquer entre designers e programadores, subjetividade e cálculo ou coisa do gênero. Vale lembrar que a grande maioria dos conceitos fundamentais utilizados nas novas mídias resultam de iniciativas de equipes híbridas de designers e engenheiros, ou de profissionais que acumularam funções de design e programação nos projetos. MIT, Xerox Parc, Apple ou mesmo a RnP no Brasil: centros de excelência que compreenderam antes de todo mundo o quanto as áreas (que estão separadas em vários argumentos nesta lista) não só estão intimamente ligadas como são indissociáveis no nosso momento histórico.

4. O design não está no extremo subjetivo, irracional, anti-metodológico de nada.

As tão revolucionárias (pro povão, porque as propostas não são nada novas) computação ubíquia, mídias locativas, pervasividade computacional e afins são áreas onde qualquer produto final é entendido como um design, não porque são bonitinhos, mas pela natureza do processo que o gerou e pelo tipo de interação que está sendo planejada com os indivíduos.

5. O designer projeta interações; não telas, botões ou maçanetas.

Quanto ao gargalo atribuído aos designers nas equipes de projeto, só posso dizer que o problema é anterior à própria formação da equipe. Podemos contar nos dedos as equipes que consideram a participação na tomada de decisões desde o início, de forma que fica complicado pedir que o designer resolva todas as questões da superfície de um objeto que ele não pôde contribuir na essência. Olhem o exemplo da IDEO, Ikea e afins. Não é uma participação conceitual, não decorativa.

6. O design deve fazer parte da estratégia gerencial da empresa/equipe/projeto.

É muito curioso ver a popularização de tantas metodologias de desenvolvimento ágil, colaborativo, participativo e tudo mais, quando justamente essa área vista como subjetiva, cosmética e "complementar" tem no centro das suas discussões esse tipo de questões metodológicas desde o século XIX.

Existe, inclusive, uma rejeição enorme às metodologias por parte dos designers contemporâneos. Muitos falam que são camisas de força, limitam a criatividade e assim por diante. Mas essa é uma discussão interna do campo profissional e não significa que os designers não possuem método. Ao contrário, o design por natureza define o método a partir contexto de projeto, e não o inverso. Parece pouco razoável escolher um método genérico primeiro e encaixar qualquer projeto nesse esquema, mas essa também é uma questão dos designers. Em outras áreas, isso pode funcionar bem.

7. O design emerge do contexto, dos usuários, da cultura.

Por fim, endosso o comentário do Scapin, sugerindo que as discussões se mantenham nas respectivas áreas de conhecimento. O mercado já é complicado e despreparado o bastante para inventarmos outros pontos de conflito.

Sugiro a todos que ainda não entendem bem o papel de um designer a visitarem uma aula de projeto numa escola superior de design ou arquitetura. Há pelo menos cinco períodos desse negócio onde ninguém aprende estética, desenho ou corte e costura. Muito menos ensinam a ter insights ou a serem *mais* subjetivos.

Se os designers presentes acham que o episódio é uma oportunidade importante para marcar um território nas quartas web, discutindo com outras áreas as questões que são fundamentais na nossa atuação, podem contar com a minha presença. Qualquer outro tipo de debate que aborde contradições entre arte e tecnologia só me me motivam a ficar em casa assistindo a novela nova.

Abs a todos e desculpem pelo post quilométrico.