Acho que o Alexandre mudou um pouco o foco da discussão.
Entendi o que ele disse e até concordo. Supomos que haja uma empresa de arquitetura (arquitetura mesmo), que vende os seus projetos às empresas que irão executar a obra. Nesse caso o operacional são os arquitetos, logo os arquitetos são os peões. Enquanto marketing, diretoria etc… formam as outras áreas que o Alexandre citou.
Ok, sem problemas, nesse caso nós programadores somos os peões mesmo e não há o menor problema nisso.
Mas, como eu disse, o foco da discussão foi mudado. O que estamos discutindo é especificamente no ambiente de desenvolvimento, tira-se de discussão qualquer outra parte da empresa, marketing, direção, administração, nada disso vem ao caso no nosso contexto.
E é nesse contexto específico de desenvolvimento de software que o termo peão para o programador é péssimo. Péssimo porque é usado para demonstrar a hierarquia que vai do peão ao gerente de projeto, passando pelo analista de sistemas, analista de negócios e qualquer outro papel que se ponha no meio.
E dessa hierarquia vem a ideia de que se pode contratar programador a preço de banana, guardando o “grosso” do salário para “aqueles que pensam”. E esse é um caminho curto pro fracasso, invariavelmente. Os analistas não conhecem a fundo a infra-estrutura na qual a sua solução maravilhosa será implementada, e nem se importam. Enquanto o programador não tem ideia de para que aquele código que ele está escrevendo vai servir, e nem se importa.
Isso resulta num telefone sem fio que destrói o projeto, gera stress, acusações de um lado e de outro, funcionalidades mal implementadas porque foram planejadas sem levar em conta a ferramenta com a qual vai se trabalhar ou porque foram desenvolvidas sem a ideia clara de para que vão servir. Infelizmente isso ainda é regra e não exceção hoje em dia.
E é nessas circunstâncias que o termo peão é terrível, porque serve para sustentar esse modelo fracassado. Tão fracassado que nunca funcionou, embora insistam nele pelo desconhecimento de outro. E mesmo insistindo a coisa só começa a andar quando o caos toma conta e chega um programador com experiência pra assentar a poeira e fazer a coisa andar.
Mas quando se começa outro projeto lá está o Ford de novo, e aquele programador que salvou o projeto, agora foi promovido a analista, e feliz com a promoção não põe mais a mão no código porque mexer em código é coisa de peão. E assim o ciclo se repete.
Então o problema não é o termo, mas o modelo que ele representa dentro do contexto específico de desenvolvimento de software.