O mito do pau pra toda obra em tecnologia

Nas últimas semanas, fiz uma provocação grosseira no Twitter e não consegui respostas satisfatórias: qual seria a diferença entre webmaster e full stack web developer? A complexidade do trabalho com o mercado digital, do planejamento à publicação na Web, foi incrementada absurdamente com a profissionalização do mercado e foi uma resposta às falhas grosseiras como a bolha dotcom. Por que então estamos adotando uma visão tão generalista quanto a da década de 1990?

Quando li o texto de Laurence Gellert tive a sensação de que o termo foi mal traduzido e contextualizado nos times de desenvolvimento brasileiros (ou não: Facebook aparenta ser uma empresa com uma cultura muito equivocada). Afinal, nossa visão sobre generalistas e especialistas é muito diferente da dos norte-americanos, por exemplo. A experiência da formação universitária lá é construída pelo aluno durante curso. No Brasil, estamos presos a currículos altamente especializados e herméticos. A flexibilidade de currículos universitários no exterior permite acompanhar melhor a tendência volátil do mercado de trabalho. Se a especialização foi valorizada na segunda metade do século XX, a generalização e a interdisciplinaridade são diferenciais na tal era do conhecimento.

Neste momento, vemos as universidades brasileiras buscando esta interdisciplinaridade e vejo um retorno ainda pouco útil. Ao invés de uma visão ampla de negócio que o mercado exige, os alunos dos cursos de tecnologia estão ocupando suas grades com Direitos Humanos e Qualidade de Vida (oi?). Do que adianta alterar cursos para introduzir disciplinas novas (multidisciplinaridade) se as grades não são construídas para favorecer a construção do conhecimento entre elas (interdisciplinaridade, transdisciplinaridade)?

Um resultado provável disso, ou algo que não foi solucionado ainda, é a eterna busca pelo acúmulo de técnicas (techné) ao invés de práticas (práxis). Ao buscar uma vaga para times de tecnologia, é fácil encontrar uma lista gigante de requisitos que vão do domínio do Photoshop ao realização de deploy de aplicações. Não é só irreal como opressivo. As graduações não preparam este tipo de generalista e nem deveria. Quantas vezes ouvi relatos de jovens passando o fim de semana debruçados sobre tutoriais para aprender uma nova técnica enquanto não conseguem relacionar o porquê daquela técnica ser boa para o negócio. E se somente a técnica é valorizada no mercado, por que não trocar uma graduação por um curso da técnica mais quente no desenvolvimento de aplicações do ano?

O Scrum, por exemplo, não ajuda nesta questão. Os ciclos rápidos de desenvolvimento são bons para manter uma alta eficiência do time e sabemos bem que o custo disso é um corte na participação na estratégia da empresa. A alienação é tal que há desenvolvedores que agradecem quando recebem as tarefas prontas e mastigadas bastando definir complexidade.

Apesar das origens do Kanban nas fábricas da Toyota, o agile não era sobre transformar pessoas em engrenagens e sim formar times autogerenciáveis com seres pensantes e ativos. Os métodos ágeis não combinam com alienação! A motivação básica de cada um no time deveria ser entender como o produto funciona do princípio ao fim. No entanto, como fazer isso se o profissional de TI só entra em contato com o mundo fora da célula no planning e no review através dos olhos do product owner?

A cultura interdisciplinar ou transdisciplinar é algo que devemos construir nas próximas gerações de profissionais do mercado digital. É uma característica cultural intrínseca à formação de cada um de nós. Generalizando absurdamente, é como se fosse escrito em cada um de nós em uma linguagem de programação baixo nível e tal característica não se muda com dinâmicas de grupo e muito menos com o acúmulo de técnicas aprendidas.

No entanto, podemos começar conhecendo melhor cada um do time. Uma matriz de competências, por exemplo, é uma ferramenta muito mais eficaz e é de implementação rápida. Incentivar a diversidade dentro do time também é uma ótima forma de aumentar a criatividade e facilitar soluções mais integradas com a estratégia de negócio do que com as técnicas utilizadas (ou quem nunca sugeriu uma tarefa porque é fácil em fazer na linguagem da moda XPTO?).

Existem paliativos para reduzir a alienação de desenvolvedores do processo de trabalho e cada time pode ter uma ideia para compartilhar com a comunidade. Mas é essencial relembrar que o que é bom para o Facebook pode não ser bom para a sua empresa.

Outros olhares sobre o tal full stack developer:

Por | Tags: , , , | Alterado em 19/05/15 às 15:05

Comentários

  1. Igor disse:

    O artigo é muito bom, só não gostei muito da implicância específica com o full-stack, pois acho que o profissional alheio a produto/negócios não é exclusivo o full-stack. A grande maioria de backends e frontends que eu conheci também tem essa tendência a se isolar no seu quadrado de tecnologia e esquecerem totalmente do resto, de forma que achei que o título de mito do full-stack foi meio infeliz.

    O ágil e posteriormente (mais ainda) o lean se propuseram a reduzir o gap entre negócios e desenvolvimento para criar soluções enxutas, mas aterrisaram em um terreno onde as pessoas culturalmente se departamentalizaram, acabando por transformar um modelo potencialmente transformador mais um filão de consultoria de gestão para dar um sabor moderno ao velho mercado. Os desenvolvedores “ágeis” se defendem afirmando que está tudo perfeito na parte técnica (segurando dogmaticamente o Clean Code embaixo do braço), e dificilmente percebem que estão afundando tudo porque a suíte perfeita de testes demora semanas para ficar pronta e enquanto isso o produto não é lançado.

    A administração aborda de forma recorrente a dicotomia entre eficiência x eficácia (Peter Drucker), afirmando que: “eficiência consiste em fazer certo as coisas: geralmente está ligada ao nível operacional, como realizar as operações com menos recursos – menos tempo, menor orçamento, menos pessoas, menos matéria-prima. Já a eficácia consiste em fazer as coisas certas: geralmente está relacionada ao nível gerencial”, porém concordo que falta muito disso na formação do profissional de computação (e de outras áreas também). Na verdade discordo até da necessidade dessa dissociação entre a técnica e a estratégia, que é uma característica do capitalismo rudimentar, porém hoje prova-se cada vez menos apropriada mesmo em um modelo capitalista de produção.

    É uma grande pena os novos métodos terem sido mal interpretados e distorcidos. Poderiam ser ferramentas que ajudariam a romper este modelo de chefe (estratégia)/peão (execução), porém as pessoas resolveram usá-los de forma defensiva e acuada para manter um modelo recorrente que separa essas duas classes. Discordo até da necessidade dos product owners que eu vejo por aí, boa parte gerentes de produto (PMBok) escamoteados na roupagem ágil.

    Enfim, é a atual leitura que eu tenho já há algum tempo dos profissionais e do mercado de tecnologia brasileiro.

    PS: Bola tá aqui do meu lado e mandou um beijo.

    • Muito obrigada pelo comentário, Igor! Acho linda esta relação também com a administração. Sinto falta disso. Me perdoe a implicância, mas só sei começar a argumentar a partir de um caso. 🙂
      E manda um beijo pro Bola!

Faça um comentário

*