Basicamente existem duas maneiras de organizar times: agrupar as pessoas de acordo com suas especialidades ou agrupar pessoas com especialidades mistas. Agrupar pessoas da mesma especialidade significa juntar num canto designers com designers, em outro canto devs com devs, em outro canto PMs com PMs, só para citar algumas das especialidades. Agrupando dessa forma, cada grupo executa tarefas de acordo com suas especialidades conforme as demandas chegam, com o mínimo de alinhamento com os outros grupos, mas muitas vezes as motivações de um grupo são totalmente diferentes do outro grupo. Geralmente criar times de acordo com a sua especialidade, significa que embora eles estejam trabalhando num mesmo produto, eles não estão realmente juntos, trabalhando em um mesmo objetivo.
Criar silos, ilhas, times funcionais, não importa o nome que você use para identificar times que são formados por especialistas em um assunto específico, é uma decisão ruim por vários motivos.
Em todas as empresas que já trabalhei ou que já prestei consultoria, havia o time que era identificado como o time do produto, que geralmente era formado por PM/PO e devs. Longe dali, haviam o silo de Design. Longe do time de produto. Isolados. Por que? Não sei. Ainda não descobri o que causa esse fenômeno, mas claramente isso tem se mostrado padrão para mim.
Um time de projeto precisa ser um time completo. Um PM junto de um grupo de programadores nem de longe é um time de produto, pelo simples motivo de que levar valor para usuário e para o negócio precisa de muito mais do que só esses dois personagens. O designer, como você bem sabe, tem um papel importantíssimo antes e depois da concepção do layout.
Além disso, o PM/PO precisa muito da ajuda do designer para planejar os próximos passos e para conversarem sobre novas soluções e ideias que o produto pode ou precisa ter. Eles dois pensam no usuário o tempo inteiro. Quando um designer senta-se longe, no seu grupinho, ele tem uma visão parcial e engessada de todos os problemas que ele acha que está resolvendo, já que requisições, dores e sugestões dos usuários chegam a todo momento para o time do produto e não para ele diretamente. Não importa o quão antenado ele possa estar, ele não está sentado com o resto do time para sentir na pele a energia e os objetivos que o time está correndo para alcançar.
Eu, como PM, preciso de um designer para discutir ideias o tempo inteiro. Eu preciso de alguém para me ajudar a defender e procurar argumentos para colocar uma ideia em prática.
Quando existe um silo onde designers (ou qualquer outro grupo de especialistas) se juntam, a visão deles é totalmente unilateral, focando, na maioria das vezes, em algo muito diferente do time e também que não está no radar dos PMs.
Além disso, quando há a criação de silos, esses grupos acabam virando pastelarias. O PM vira um demandador de tarefas e os designers devem entregar aquilo o mais rápido possível. Dependendo do PM/PO, que não tem apresso nenhum à experiência do usuário, ele sempre terá a tendência de publicar as features sem nem passar pelo designer. Isso quase nunca acontece quando o designer está ali do lado, acompanhando o desenvolvimento e resolvendo problemas com e perto do time e não longe dele.
O time do produto tem que ser formado por todas as especialidades necessárias para que o produto seja incrementado e evoluído constantemente. Para tanto, o time precisa se organizar, tendo visibilidade de todas as partes em andamento no produto. No board - ou seja lá o que vocês estejam usando para organizar o fluxo de trabalho do seu produto - deve haver as tarefas de hack-end
- front-end
- design, QA e qualquer outro integrante com qualquer especialidade específica.
O que acontece geralmente é que o time de design ou de front, por algum motivo que na maioria das vezes eu desconheço (ou que não faz sentido algum) decide sentar junto, separado de todo o resto do time, tentando