Nada de ovo ou galinha. A questão de um milhão de dólares em desenvolvimento de produtos de internet ainda gera polêmica. Historicamente designers são de Marte e desenvolvedores são de Vênus, mas os dois planetas nunca estiveram tão próximos.
Os defensores de fazer o design primeiro têm algumas boas razões para isso. A programação é a fase mais pesada da construção de um aplicativo web. Isso quer dizer que é também a mais cara e onde a mudança é mais custosa.
A fase de design, ao contrário, é relativamente menos custosa, e esse é o motivo pelo qual algumas pessoas defendem que o melhor é projetar todas as telas antes de partir para o código. Nesse caso, só se codifica o que não vai mais mudar.
Mas quem defende que a programação deve preceder o design também tem ótimos argumentos. Quem desenha as páginas antes corre o risco de acabar com lindas telas que nunca serão codificadas. Isso acontece porque o Photoshop aceita qualquer solução, mas você nunca tem certeza do que vai realmente conseguir desenvolver. A natureza da atividade de design tende a ignorar limitações técnicas e de prazo.
Você deve estar pensando, assim como na anedota do ovo e da galinha, que nosso caso não tem solução. Mas tem. É simples: faça tudo ao mesmo tempo. Ponha o designer sentado ao lado do programador e chame-os de ?time?. Estabeleça uma tarefa para os dois. Não uma grande tarefa, como ?redesenhar o site todo? ou ?criar uma área nova?. Peça uma pequena unidade de tarefa como ?deixar o usuário fazer upload de uma foto? ou ?permitir que o editor publique uma notícia?.
Você vai perceber que a colaboração entre designer e programador vai reduzir a frustração de ambos por perceber que algo não cabe no prazo. Também vai sentir que o re-trabalho vai diminuir, pois estamos falando de uma pequena tarefa sendo realizada por duas pessoas com formações complementares se comunicando. É muito rico.
O efeito telefone-sem-fio já me deixou perplexo em vários projetos que pareciam organizados. O briefing da equipe de produto chega até o arquiteto da informação, que faz um mapa de arquitetura e manda para o designer de interface, que desenha o wireframe e manda para o designer gráfico, que envia uma tela de Photoshop para implementação do html, que finalmente chega até os programadores.
É enorme a chance de informações acabarem perdidas ou distorcidas durante esse processo e é certo que se perde um tempo excessivo documentando o que ainda não precisa ser documentado. Isso é o que acontece quando os membros de um time de desenvolvimento estão distantes, isolados em suas equipes técnicas.
Trabalhar em times multidisciplinares é um dos fundamentos das ?agile methodologies?. Elas também indicam que diminuir a documentação para o mínimo necessário melhora a velocidade do projeto.
Em vez de criar documentos para que o projeto circule entre áreas da empresa, é melhor juntar essas pessoas e deixar que elas se comuniquem. Vai deixar os designers felizes com suas criações funcionando 100% num curto espaço de tempo.
Vai melhorar o astral dos desenvolvedores, que poderão participar das soluções em vez de receber um pacote pré-determinado. E vai economizar preciosas horas de trabalho no seu balanço mensal. [Webinsider]
.
18 respostas
Fellipe Cicconi disse:
# Atendimento > Planejamento > AI / Especificação
# > Design > Interface > Programação. Qual o
# problema nesse modelo?
Este modelo é o que, em desenvolvimento de software, chamamos de cascata, ou waterfall. Este modelo, superado há muitos anos, ainda vigora em boa parte do mundo da prática, em virtude da fácil e falsa analogia com processos industriais de produção.
O problema com o método industrial é que o processo de produção de software – e a construção de um site – não é linear e determinístico como processos industriais. Logo, as mesmas premissas não podem ser tomadas como verdadeiras. O que o autor propõe, com a quebra do projeto em pequenas atividades, é um ciclo de vida conhecido como iterativo-incremental. Este ciclo parte da premissa de que a produção de software é um processo eminentemente criativo e envolve aprendizado, tanto da equipe técnica quanto do stakeholder (cliente). Processos iterativo-incrementais não fogem das mudanças, mas as acolhem como aprendizado e melhoria. Assim, diferentemente do modelo cascata, o retrabalho aqui é visto como melhoria do projeto. Uma vez que o processo é projetado para acomodar mudanças, estas nunca são motivo de desgaste ou trauma.
Procure na Internet por iterativo-incremental e agile software development e você verá o que desde sempre se critica no waterfall.
Interessante Post.
Estamos vivendo na prática uma experiência com todas as áreas juntas (não só desenvolvimento ou design) e o resultado está sendo muito bom. Algumas vantagens: minimiza o lateness do retrabalho (retrabalho sempre há, mas o quanto antes for identificado, melhor); faz com que as pessoas abram a mente em relação a outras atividades; diminui a perda de informações; toda a equipe foca no mesmo objetivo, fazendo com que o compromisso, a qualidade e o resultado final fiquem melhores.
Seu artigo é muito bom, firmou mais ainda minhas teorias. Agora sei que não é apenas eu que pensava deste jeito. Para mim ainda tenho a praticidade de ter tido uma boa formação em WebDesign e programação(PHP). Mas já trabalhei e ainda trabalho com equipes. Sou autónomo, mas quando há uma demanda por sites e manutenção tenho que formar parceirias com outros designers e programadores. E sempre faço questão da máxima comunicação e aproximação.
Nas agências por onde passei o processo de trabalho é bem parecido, primeiro se planeja o website e é justamente nesta fase que entram os designers e programadores, juntos desenvolvem o ideal, depois disso ai sim a criação prepara o layout e depois o programadores criam as linhas e linhas de código. Só é possível um entendimento pleno do projeto quando ambas as áreas estão envolvidas, se for diferente disso é óbvio o desencontro entre os lados do cérebro.
AndyMontoya.com
Gostei da matéria!
É engrassado que no começo da matéria eu mesmo fiquei respondendo qual era o melhor modelo é … até por já ter trabalhado com as duas situações mais usadas mas que, quando o trabalho sai junto o que ocorre é uma solução mais rápida e os dois focados ao mesmo tempo em uma solução chega ao ser explorada com mais eficácia e eficiência e a chance de re-trabalho e menor. É um modelo a ser pensado.
Vamos pensar um pouco em outro tipo de situação: Temos vários CMSs sendo usados em todos os lugares. Inclusive aqui no webinsider. Joomla, Mambo, WordPress e assim por diante. Boa parte de todo projeto que se queira fazer está pronto nesses CMSs. O que resta em muitos casos é somente o desenvolvimento de uma interface para a programação funcionar de forma personalizada. Enquetes, Blogs, Álbuns de Fotos, Textos de acesso restrito, Controles de Projetos, WiKis, FAQs, agendas, calendários, Lojas Virtuais, sistemas de cobranças. Posso passar o dia aqui listando soluções prontas para praticamente 90% dos problemas e necessidades dos clientes. E o que falta então? Templates?
Nem tanto à água, nem tanto ao vinho. Penso eu que falta entendimento do funcionamento e das possibilidades de uso dessas ferramentas já existentes e de uma forma de agregar conjuntos de funcionalidades em um produto final de qualidade.
Mas a idéia que tenho é que a programação pode sim funcionar perfeitamente sem layout. Penso que a programação é algo totalmente à parte e funciona de forma fechada independente de layouts e design.
Não estou falando que layout e design sejam de menor importância. Muito pelo contrário, têm uma importância bem maior porque são a parte visível do sistema. O cliente não sabe que tipo de componente ou biblioteca está sendo usado num projeto. Mas sabe com certeza onde quer ver o menu e que cor é sua logomarca.
Então acho que a solução deve ser exatamente o inverso do sugerido neste artigo: Primeiro temos o sistema, aplicativo ou projeto programado. Depois entram o design e layout porque aqui já sabemos exatamente o que o programa em si deve fornecer de informações e aí sim vamos montar onde essas informações serão usadas e de que forma queremos apresentar tais informações. É um sistema que eclode. Do seu núcleo, do seu core para fora até a interface com o usuário e desse ponto para as telas de apresentação.
Marcelo, muito bom o artigo.
Recentemente eu escrevi um artigo que fala um pouco sobre o trabalho conjunto entre designer e programador, mas com outro enfoque. O título dele é Eu pedi um site e você me propõe um aplicativo?, que também está aqui no Webinsider.
Penso que o que vem antes do código ou do design é a IDÉIA. Muitas vezes a idéia nasce a partir de uma necessidade. Outras vezes ela nasce a partir de uma inspiração. A idéia na cabeça de alguém vai mover todo o motor de criação.
E o trabalho conjunto entre programador e designer é que vai conseguir materializar essa idéia. Sem disputa, sem desmerecimento. Com colaboração.
Valeu mesmo pelo artigo.
Abraços.
Vinicius Assef.
edy, o que o Marcelo está falando não é sobre a importância de cada área. Ele mesmo disse que as áreas são igualmente importantes. O que ele está dizendo é a realidade de que se você for terceirizar alguma dessas áreas, com certeza o mais caro será a programação. Isso é uma realidade.
Eu ainda confio bastante num sistema multi-disciplinar separado, assim como o Fellipe. Onde trabalho existem vários versáteis, e eu sou um deles, mas a maioria é especializada em apenas uma área. O que faz nossa metodologia funcionar? Como o Fellipe disse, mesmo que alguns sejam especialistas em apenas uma área, eles conhecem as dificuldades das outras áreas, e por isso, já fazem seu trabalho pensando no próximo que irá tocar no projeto.
Assim, não há o desgaste de um ficar metendo o dedo no trabalho do outro e o projeto corre redondo.
Fellipe, e quem ensina os programadores?
Marcelo, conhece o trabalho do Eduardo Recife?
– Imagina, depois do projeto pronto, você ter que colocar a mão no trabalho desse cara.. o custo arrebenta.
A identidade gráfica, design ou interface, como preferir, é o que define de fato, o resultado de um projeto web, por assim dizer. É quem dá a cara a tapa.
O sistema rodando lindo e redondo e a interface com conceito fora do escopo ou feita sem uma direção adequada? É bomba na certa!
É claro que não dá para colocar no ar um sistema quadrado com o design mais perfeito do mundo..
De qualquer maneira, existem casos e casos. Existe o projeto que custou X em uma área e Y em outra. Dependendo de qual, é PT na certa.
Cada um tão importante quanto o outro, senão, já era. Imagina a empresa sem a copeira, coitada.. só recebe 1 salário mínimo ao mês!
Já eu, tenho uma outra opinião…não sei se é plausível, mas para mim tem funcionado muito bem.
Eu acredito que as funções devem trabalhar juntas e separadas ao mesmo tempo!
Como?
Simples! Acho que uma reunião com todos para que o responsável pelo projeto passe o briefing e para digerir o briefing, rolar um brainstorm também com todos (existem muitos modelos interessantes de brainstorm). Ai todos dão seus pitácos e idéias inválidas são cortadas logo ai.
Assim, depois de tudo filtrado, cada um se reserva em sua tarefa, para a sequência que o Fellipe Cicconi passou de fato funcionar.
EX:_________
Vou dar um exemplo bem tosco para ilustrar o que disse. Mas já assistiram aquele programa PimpMyRide?
Reparou como funciona?
O XZbt (comercial) traz o briefing para o diretor de projetos da WestCostummers, entao este se reune com todos da equipe para passar quem é o cliente/perfil do cliente e qual o projeto. Então inicia um brainstorm e cada membro da equipe diz o que quer fazer no projeto e ali eles vao rabiscando e modelando até ter a customização em mente.
Após isso, cada um já tem suas tarefas e trabalham separados no carro, até a finalização e o cliente gritar de felicidade quando vê sua marca ser tunada ao extremo.
Bom, eh o que eu acho…
🙂
A preucupação de balancear a atuação de designers e desenvolvedores é sempre constante, na empresa em que trabalhei por dois anos como designer de interação, tivemos os mesmos problemas que qualquer outra empresa desenvolvedora de software.
A aproximação entre designers, desenvolvedores e os demais envolvidos no projeto se fez gradualmente de acordo com as necessidades que iam surgindo e as dificuldades vencidas para ambos os lados. Porém há de se comentar que isto leva tempo, uma solução encontrada por nós foi em conjunto desenvolver uma metodologia para desenvolvimentos dos softwares, e podem ter certeza que ela ia muito mais longe do que a ordem das atividades, mas também objetivo, desafios, limitações e outros detalhes que tantas vezes passam despercebidos.
O artigo está muito bom em minha opinião, e fico contente de ver pelas respostas do pessoal que existem empresas vencendo essa barreira e amadurecendo em relação a processo e conhecimento. Aos que ainda estão lutando em empresas que passam por essas dificuldades, não desistam, colham informações de concorrentes que já venceram esta etapa, e logo logo os responsáveis vão desejar implementá-las também.
Poxa! Demorou pro povo perceber que não basta só estes dois. Toda a equipe sabendo do que se trata cada etapa do job acelera o processo, e todos ficam felizes. Bom artigo! t+
Nex
Discordo.
Atendimento > Planejamento > AI / Especificação > Design > Interface > Programação. Qual o problema nesse modelo?
Tive a felicidade de ver esse modelo que descrevi funcionar muito bem em várias grandes agências de São Paulo. Lógico, algum retrabalho SEMPRE aparece, mas é mínimo. A mágica? Basta compartilhar entre as pessoas envolvidas no projeto um pouco das dificuldades que a próxima equipe vai sofrer.
Os programadores ensinam os Interfacers, que ensinam Designers e Arquitetos, que por sua vez ensinam atendimento e planejamento. Pliiiim! Tudo funciona bem.
Com essa descrição, deixo implícito que AI/Design deve vir ANTES de Interface/Programação e já MUITO BEM DEFINIDA E APROVADA PELO CLIENTE.
Quando faço freelas, sempre contrato a mão de obra de um amigo AI/Designer anteriormente ao meu trabalho. Quando o design está aprovado, aí sim, mãos a obra. Pô! Assim eu acho muito mais plausível.
Já tive experiências em compartilhar uma mesa com um designer e, depois de um tempo com um tentando induzir e argumentar sobre o trabalho do outro, nossa relação ficou totalmente desgastada.
Design antes / Programação depois (e pra sempre)
Concordo.. tanto que é meu sonho trabalhar com uma equipe de verdade, unida, em tempo de produção.
e não fulano faz o layout e depois entrega pra ciclano montar o html e programar
ciclano depois ve que fazer o html se torna inviável, ou também encontra melhores soluções, que se fossem ditas antes, resolveriam muitos problemas :}
então fulano fica fulo por que ciclano vêm com várias alterações que acha necessária.
ou seja, quanto mais comunicação entre as partes na hora de desenvolver, melhor.
Ótimo artigo, Marcelo. Você acabou descrevendo o que eu penso há muito tempo, mas não conseguia visualizar funcionando. Obrigado, aprendi muito!
Edy,
Não disse que design é mais fácil do que programação. Não faria sentido. Minha formação é de designer e acho que fazer um bom design (sobretudo em web) é um desafio enorme.
O que eu disse, e pode ser provado por números, é que no processo de desenvolvimento de produtos interativos o desenvolvimento do software é relativamente mais representativo em termos de custos.
A 37 Signals, renomada empresa de criação e desenvolvimento para a Web, fundamentou seu processo (Getting Real) nessa premissa: http://gettingreal.37signals.com/toc.php. E trata-se de uma empresa essencialmente de designers. Sugiro a leitura do Getting Real, embora não concorde com alguns princípios dele. É só clicar no link acima.
Abraços, Marcelo Gluz
Concordo plenamento com o você!
marcelo, concordo quando vc defende que o trabalho deve ser concebido com a equipe toda junta.
aqui desenvolvemos ano passado um portal onde tudo foi feito em equipe, desde AI, design, programação, conteúdo, redação, etc..
a coisa saiu porque somos uma equipe de verdade, cada um ajuda o outro em sua especialização.
agora, sair dizendo que trabalho de um é mais fácil que o trabalho de outro, é um belo erro. uma mudança em layout é tão custosa quanto uma alteração no código, assim como o conceito textual produzido pela redação ou toda a organização de AI.
para se ter uma idéia, mude uma corzinha, ou uma curvinha do logotipo da globo e leia os números com produção de uniforme, papelaria, manual de aplicação da marca, etc..
não fica nem tão caro nem tão barato quanto alterar de php pra java.
tudo depende do impacto da mudança.
pense nisso 😉