Programador, UX, designer, chefe e todo o resto. Ou seja, como é realmente a vida numa software house
Sexta-feira parece ser um bom momento para deixar de lado por um instante a arquitetura de sistemas, as API, os deployments, os mockups, os prazos e a pergunta «podemos fazer isto ainda hoje?» e olhar para o setor de TI com um pouco de humor.
Porque uma software house não é um lugar onde dez programadores entram no escritório de manhã, todos abrem os portáteis e, à noite, sai um sistema pronto.
Bem, está certo. Às vezes, é mesmo assim... Mas só à primeira vista.
Na realidade, um bom projeto nasce graças a pessoas com competências muito diferentes. O programador constrói a solução. O profissional de UX pergunta-se se as pessoas vão sequer saber o que fazer com ela. O profissional de UI garante que não pareça um painel de administração de 2008. O marketing pensa em como falar sobre isso. A pessoa responsável pelos conteúdos tenta explicar tudo numa linguagem simples. Alguém trata dos clientes, dos prazos, das faturas e da organização. E ainda é preciso alguém se lembrar de que o papel da impressora acabou.
E é justamente por isso que as equipas de tecnologia são tão interessantes.
Programador — a pessoa que sabe falar com o computador
Um programador pode vir trabalhar com uma sweatshirt de marca, uma boa T-shirt, uns ténis fantásticos e um perfume cujo preço leva alguém da administração a perguntar-se se, por acaso, não estamos a trabalhar para uma marca de luxo. Pode trazer consigo o gadget mais recente, auscultadores que custam metade do salário e um portátil com especificações que parecem o manual de uma central elétrica. Ao pequeno-almoço? Não apenas uma sandes com manteiga e compota. Pode ser iogurte, bom pão, algo com abacate, café de especialidade ou um almoço preparado com mais cuidado do que muitos projetos da empresa.
E depois há o segundo tipo.
Sweatshirt. Auscultadores. Silêncio. De preferência, trabalho remoto. De preferência, sem câmara. Depois do trabalho, o computador fica ligado, porque ainda é preciso «jogar só mais um bocadinho». Esse bocadinho acaba por volta das 4:00 da manhã.
Claro que também existem todas as variações pelo meio — e é precisamente isso que é melhor.
Um programador não tem de parecer o estereótipo do programador. Da mesma forma, programar já não consiste apenas em passar oito horas sentado em frente ao código.
Um bom developer tem de compreender o problema que está a resolver. Tem de saber conversar com outros especialistas, compreender as limitações do projeto, prever as consequências das decisões técnicas e, por vezes, dizer: «Não, não vamos fazer isto assim, porque daqui a seis meses vamos arrepender-nos».
E é aí que começa o verdadeiro trabalho de equipa.
UX/UI — ou seja, porque é que este botão está mesmo aqui
UX não é escolher uma cor bonita para o botão.
UI também não é «vamos fazer algo moderno».
A conceção de um produto digital exige compreender o utilizador, o seu objetivo, as suas limitações, a forma como toma decisões, os seus hábitos, o contexto e aquilo que o pode impedir de avançar.
Por isso, o designer não pode olhar apenas para o ecrã. Tem de olhar para a pessoa. E um designer que também compreende a tecnologia tem ainda uma enorme vantagem. Sabe o que é realmente possível fazer. Não precisa de escrever código. Mas é bom que compreenda como o código funciona. Sabe a diferença entre frontend e backend. Sabe o que é uma API. Compreende as limitações da responsividade, os dados, as integrações, os formulários, os estados de erro, a validação, o desempenho e as questões técnicas que afetam a interface.
Porque conceber um ecrã bonito, impossível de implementar de forma sensata, é um pouco como conceber um carro que tem ótimo aspeto, mas não tem espaço para o motor. É possível. Mas para quê?
No meu caso, esta mistura é a base do meu trabalho há anos. Design gráfico, UX, UI, comunicação visual, psicologia da comunicação, marketing, conteúdo e, além disso, conhecimentos de programação e compreensão da tecnologia. Não para ser o melhor programador do mundo ao mesmo tempo. Mas para saber como todos estes elementos têm de se articular para que o produto faça sentido.
Porque um bom projeto não começa com a pergunta «como é que desenhamos isto?».
Começa com a pergunta «o que é que a pessoa deve fazer aqui e porquê?».
Designer gráfico — a pessoa que garante que nada pareça feito ao acaso
O designer gráfico recebe muitas vezes uma tarefa bem concreta: «Faz algo porreiro».
E é aí que começa a diversão.
Porque «porreiro» pode significar tudo...
Minimalista.
Elegante.
Tecnológico.
Arrojado.
Premium.
Moderno.
Ou «igual ao da concorrência, mas melhor».
Um bom designer gráfico não se limita a fazer imagens. Tem de compreender a marca, a comunicação, a tipografia, a hierarquia da informação, as proporções, o contraste, o público e o contexto. E, se trabalhar com produtos digitais, também deve compreender UX. Porque um design gráfico pode ser bonito e, ao mesmo tempo, completamente inútil. E é aqui que chegamos a algo muito importante... Numa software house, não há uma única pessoa responsável pelas «coisas bonitas».
O designer, o programador, o profissional de marketing e a pessoa responsável pelos conteúdos têm de entender-se.
Só então surge um produto que não só funciona, como também é compreensível, coerente e convincente.
Profissional de marketing — aquele que pergunta constantemente: «E como vamos vender isto?»
O profissional de marketing tem um superpoder especial.
Consegue olhar para um produto pronto e perguntar: «Ótimo. Mas porque é que o cliente vai querer isto?» — E essa é uma excelente pergunta.
Porque a tecnologia, por si só, raramente é um argumento de venda.
O cliente não compra uma API.
Não compra uma framework.
Não compra uma arquitetura de base de dados fantástica.
Compra uma solução para o seu problema.
Por isso, o marketing tem de saber traduzir a linguagem da tecnologia para a linguagem dos benefícios. E depois ainda tem de encontrar uma forma de fazer com que alguém queira sequer ler essa mensagem.
Responsável pelos conteúdos — ou seja, tradutor do tecnológico para o humano
«O sistema utiliza uma arquitetura escalável de microsserviços com comunicação assíncrona...» — Parece bem. Mas será que o cliente sabe o que ganha com isso?
Às vezes, o maior valor da pessoa responsável pelos conteúdos está em dizer: «Está bem. Agora vamos escrever isto de forma que as pessoas entendam».
Porque é possível ser um excelente profissional de tecnologia e, ao mesmo tempo, não saber explicar o próprio trabalho a alguém de fora do setor.
Afinal, o utilizador não devia precisar de um doutoramento em informática para comprar um produto, criar uma conta ou realizar uma tarefa simples.
Assistente administrativa — a pessoa que sabe tudo
Este é um cargo cuja importância não dá para reconhecer devidamente num único parágrafo.
A assistente sabe o que é preciso encomendar.
Sabe o que não foi encomendado.
Sabe que fatura está pendente.
Sabe quem tinha de fazer algo.
Sabe quem não fez.
Sabe quando é preciso lembrar.
Sabe onde está o documento.
Sabe que alguém tinha de telefonar.
E provavelmente é a primeira a perceber que o café está a acabar na cozinha.
É muitas vezes a pessoa graças a quem o resto da equipa pode dedicar-se ao seu trabalho, em vez de tentar perceber quem é que devia encomendar papel, receber uma encomenda ou tratar dos documentos.
O chefe — a pessoa responsável pelas decisões que ninguém mais quer tomar
O chefe pode aparecer um pouco mais tarde.
Tem o seu próprio escritório.
Passa muito tempo ao telefone.
Preza o conforto, mas não costuma aparecer de pijama.
Vai a reuniões.
Às vezes, sozinho.
Às vezes, leva alguém criativo.
Às vezes, o CEO dos programadores.
Às vezes, leva toda a gente, porque o cliente tem muitas perguntas.
O chefe tem de ouvir.
Tem de negociar.
Tem de gerir o dinheiro, as pessoas, os clientes e o rumo da empresa.
E às vezes só precisa de dizer: «Está bem. Vamos fazer assim». Porque até a equipa mais democrática precisa, a certa altura, de alguém que assuma a responsabilidade pela decisão final.
E é precisamente aí que se percebe que gerir uma empresa tecnológica é muito mais do que tecnologia.
E depois todos se reúnem em torno de um projeto
E, de repente, percebe-se que toda a gente tem razão.
O programador diz: «Não dá para fazer isto como está no design».
O UX responde: «Mas o utilizador tem de seguir este percurso».
O marketing diz: «O cliente não vai perceber isto».
O designer diz: «Mas isto não cabe aqui de maneira nenhuma».
A pessoa responsável pelos conteúdos diz: «Mas não podemos escrever isto desta forma».
O chefe pergunta: «Quanto é que vai custar?»
E a assistente, do outro lado do escritório: «Alguém já assinou esta fatura?»
E é precisamente daí que nasce um produto.
Não apenas do código. Não apenas dos gráficos. Não apenas do UX. Nem do marketing — mas da combinação de competências.
Uma empresa de software moderna é uma equipa multidisciplinar. Dependendo do projeto, podem fazer parte dela developers, profissionais de UX/UI, QA, PM, analistas, DevOps, marketing, conteúdo ou pessoas responsáveis pelo negócio. As funções podem estar separadas ou ser acumuladas, sobretudo nas equipas mais pequenas.
E é precisamente por isso que uma boa colaboração entre estas pessoas é tão importante.
Porque um programador pode criar um sistema que funciona muito bem.
Um designer pode criar uma ótima interface.
Um profissional de marketing pode preparar uma excelente campanha.
Um redator pode escrever um excelente texto.
Mas só em conjunto podem criar um produto que alguém queira realmente utilizar.
E depois de vinte anos a trabalhar neste mundo, há uma coisa que sei com certeza: o setor tecnológico está cheio de contrastes.
Há programadores de camisola com capuz e programadores com T-shirts que custam metade do salário.
Há pessoas que adoram o escritório e outras que preferiam nunca sair de casa.
Há perfeccionistas dos píxeis e pessoas que dizem «desloca dois píxeis e fica bom».
Há chefes que adoram folhas de cálculo e outros que preferem o telefone.
Há profissionais de UX que começam pela investigação e outros que abrem primeiro o Figma, ou simplesmente sabem o que fazer.
Há programadores capazes de passar horas a falar sobre arquitetura. E há os que só querem terminar o ticket tranquilamente.
E talvez seja precisamente isso o melhor deste setor — não temos de ser todos iguais.
Só temos de saber entregar juntos algo que funcione.
E se, pelo caminho, alguém trouxer um bom café, uns ténis novos ou umas sanduíches especialmente boas, melhor ainda.
