O programador não precisa pensar

O titulo deste topico já diz uma tendencia que há alguns anos tem se repetido nas diversas fábricas de software mundo afora, e até mesmo em projetos outsourcing.
Acreditando que haveria maior produtividade muitos gerentes assumem a postura de hierarquizar o desenvolvimento de sistemas na seguinte cadeia:

Analistas de requisitos levantam as necessidades do cliente, batem papo, fazem entrevistas, em algus casos até mesmo reversas de codigos fonte antigos em ultima instancia.

Arquitetos de software, sempre muito arrogantes com nariz em pé, belos ternos e um monte de conversa fiada a respeito de design patterns montam uma especificação técnica, diagramas e muitas informações que traduziriam o que o analista de requisitos levantou para uma linguagem técnica. O problema começa ai…

Depois deste cara, quem irá botar a mão na massa mesmo será um pobre programador, que nos dias atuais é chamado desenvolvedor. Mas neste esquema esse sujeito não pode ser chamado desenvolvedor pois ele não desenvolve nada. Ele apenas irá traduzir para a tecnologia especifica seja java, perl, php, bpel ou o que for definido na arquitetura do projeto.
Este sujeito na opinião dos gerentes não deve pensar e sim apenas seguir o que já foi estabelecido na cadeia superior.
Até ai não haveria problema a não ser pelo fato de que esses profissionais não são estagiarios ou iniciantes, muitas vezes eles sim tem curso superior em analise de sistemas, mas talvez por não terem o mesmo papo do arquiteto de falar termos dificeis e de colecionar certificações a esmo não tem a mesma oportunidade de definir as coisas…

Esta hierarquia de linha de produção além de ser uma proposta burra desperdiça talentos, pois quem é que aguenta ficar apenas traduzindo codigo sem entender nada do que está trabalhoando? Sem saber qual o contexto do que esta fazendo dentro de um ambiente maior corporativo? Sem falar que isso só leva a estagnação pessoal, já que voce não poderá sair de desenvolvedor para arquiteto jamais pois não tem essa expertise na visão dos gerentes. Sempre que houver uma oportunidade de promoção irão preferir trazer alguém de fora ao inves de tirar alguem da programação… :roll:

Afinal de contas porque arquiteto não pode desenvolver? Quem foi que disse que eles só tem que ficar criando documentos, reclamando de coisas e ficar falando bonito? :x
Arquiteto que se preza tá ali junto desenvolvendo e construindo, auxiliando os demais. Em tese é um desenvolvedor senior. E na minha visão é assim que deve ser.

olha não me leva a mal não, eu até concordo com você em muitas coisas, o desenvolvedor apenas seguir a especificação sem alterar nada normalmente acaba percebendo problemas no softwre da forma que foi especificado e seria melhor certas alterações, a pessoa que acredita que o programador não deve pensar honestamente não conhece de verdade de desenvolvimento de software mas… o arquiteto é sim uma pessoa teoricamente bem mais experiente e é função dele sim especificar como deve ser criado o software (na minha opinião o problema está no fato dessa documentação ser inalterável e ser uma verdade absoluta).

Cara em que fábrica de Software vc trabalha?? Não é bem assim que as coisas funcionam, o desenvolvedor tem um papel muito importante, se não o mais importante do processo, pois é ele que vai de fato concretizar o que o Analista e o Arquiteto planejaram, e se o mesmo é um bom programador, ele vai apontar possiveis falhas de arquitetura ou análise, O programador é o cara no projeto que tem a visão Macro, tanto da arquitetrua quanto da regra de negócio. E Arquiteto programa sim, pelo menos aqui na empresa onde trabalho, todos programam e ajudam os desenvolvedores. Se isso acontece em sua empresa, a cultura dela permite que isso aconteça.

Arquiteto tem que desenvolver e estar ali do lado da equipe sim, só que não pode ser o principal desenvolvedor da equipe.

Em empresas grandes vc fica limitado a fazer somente uma parte específica do projeto, já em empresas pequenas geralmente vc acaba realizando todas as tarefas…
Essa “peonização” tem influenciado muito na na minha decisão de sair de uma empresa pequena para uma empresa grande… claro tudo tem os dois lados, em empresas grande tem mais espaço para vc crescer, tudo é mais organizado ( na questão de projetos, documentação, o que vc tem que fazer ) ou pelo menos deveria ser =D

por isso que eu acho que um equipe deve ter 3 a 5 pessoas (eu disse PESSOAS ok?) por projeto.

dependendo da maturidade de um projeto essas pessoas podem ser alocadas em outros projetos paralelamente.

Esse esquema de Arquiteto e de Analista é furada, pior que isso é Fábrica de Software, empresa que se reconhece como Fábrica de Software merece o inferno :stuck_out_tongue:

Acho o contrário em empresa grande você tem muito menos visibilidade,
quando você trabalha em uma empresa pequena você tem mais acesso ao topo da hierarquia e geralmente os caras te valorizam bastante,
já tive experiência em trabalhar em uma empresa grande e quando sai de lá eles nem se importaram porque sempre tem gente querendo entrar lá.

[quote=luciano@@]Acho o contrário em empresa grande você tem muito menos visibilidade,
quando você trabalha em uma empresa pequena você tem mais acesso ao topo da hierarquia e geralmente os caras te valorizam bastante,
já tive experiência em trabalhar em uma empresa grande e quando sai de lá eles nem se importaram porque sempre tem gente querendo entrar lá.[/quote]

Ai ja depende dos gestores da empresa. Tem empresa que realmente, não esta nem ai mesmo. Mas esse pensamento ta mudando, e as empresas estão valorizando mais seus colaboradores, desde os estagiários até os grandes cargos. Tome como exemplo a Google, Facebook, Microsoft e por ai vai. E esse lance de visibilade depende muito do profissional tbm, se o cara é bom ele vai ser notado, simples.

Não sei acho que o esquema de fábrica de software é legal, mas em muitos lugares é mal aplicado.
Uma empresa que trabalhei por exemplo era divida em células, cada tecnologia java, .net , plsql tinha sua celula, existia um celula de projetos e uma celula de teste,
cada gerente de projetos tinha apenas que alocar o desenvolvedores que queria no seu projeto e agendar os teste com a celula de testes.
O analista de requisitos funcionava como um cliente da celula de projetos, após receber o projeto ele passava para o gerente de projetos.

O importante é q funcionava muito bem.

[quote=luciano@@]Não sei acho que o esquema de fábrica de software é legal, mas em muitos lugares é mal aplicado.
Uma empresa que trabalhei por exemplo era divida em células, cada tecnologia java, .net , plsql tinha sua celula, existia um celula de projetos e uma celula de teste,
cada gerente de projetos tinha apenas que alocar o desenvolvedores que queria no seu projeto e agendar os teste com a celula de testes.
O analista de requisitos funcionava como um cliente da celula de projetos, após receber o projeto ele passava para o gerente de projetos.

O importante é q funcionava muito bem.[/quote]

Aqui na empresa onde trabalho é assim mesmo. E Funciona muito bem, otimiza muito o processo, mas tbm pq nossos gestores aqui são bons. Como falei, tudo depende dos gestores organizarem o porcesso direito! E concientizar as equipes de que o processo deve ser seguido a risca!

Para fugir do processo tinhamos uma celula que atendia por email e sem celula de projeto \ teste , cobrava mais barato e atendia demandas pontuais.

E como ficava a rastreabilidade de possiveis falhas?? Pq um processo visa isso tbm!

Programador nada mais é do que um escritor sem licença poética.

E como ficava a rastreabilidade de possiveis falhas?? Pq um processo visa isso tbm![/quote]

Eles utilizavam está célula para clientes que não exigiam muito rigor no processo de desenvolvimento, geralmente era para pequenas manutenções. Não tinha muito controle, por isso a maior parte da galera não gostava de trabalhar nessa célula.

Bem, eu vou ser totalmente contra a maré. Eu acho que sim, o programador não deveria pensar. Deveria, a partir do projeto especificado, executar e implementar aquilo que está no projeto. Mas aí, esse cargo deveria ser ocupado por uma pessoa de nível técnico, com conhecimento de lógica e da linguagem, nada mais.

Aquele cidadão que passou 4-5 anos na faculdade, estudando estruturas de dados, arquiteturas, compiladores, banco de dados, esse sim deveria assumir o papel de arquiteto (ou engenheiro) de software, definindo as tecnologias, a arquitetura, os frameworks, etc…

O grande problema é que não existe essa figura do programador técnico, pois não há cursos técnicos para desenvolvimento. Logo, pela falta de técnicos e pela baixa demanda por arquitetos, as pessoas que fizeram curso superior têm que assumir essa posição e, por terem esse conhecimento, se acham no direito de querer “pensar” e definir algo.

Eu acredito que, mesmo sabendo que TI é diferente de engenharia civil, deveria haver também essa separação de papéis, ficando os engenheiros e arquitetos de software responsáveis por pensar e projetar o sistema, e os programadores por pegar o projeto e implementar, sem direito a dar muito pitaco.

PS: antes que alguém atire uma pedra, sim, sou formado e ‘programador’, fazendo o papel de ‘peão’.

Acho que essa é uma visão bastante antiquada, e também perigosa.

Primeiro, porque muitas empresas que a adotam também adotam o ciclo de cascata waterfall. Enxergam o projeto com a analogia de que ele é uma obra.
Segundo, porque o custo de manter documentação atualizada pode ser, na maior parte das empresas, impeditivo. Acho que tirando sistemas de gestão muitíssimo gigantescos, como o SAP, ou sistemas muitíssimo críticos, poucos softwares hoje justificam a existência de uma burocracia tão pesada.
Terceiro, porque muitos trabalhos técnicos são muitíssimo complexos, e achar que o arquiteto, por mais experiência que tenha, será capaz de prever os detalhes de baixo nível do problema estando afastado dos bits e bytes é um muito erro grave. Um bom arquiteto deveria estar preparado para feedback e, mais do que isso, pró-ativamente colhe-lo na empresa para refinar seu projeto.

Por fim, isso cria uma noção de hierarquia, que na prática não deveria existir. O cargo de arquiteto é importante, mas ele não é exatamente “chefe” do programador, ou do um engenheiro de software, do DBA. São apenas papéis distintos e etapas diferentes do ciclo desenvolvimento, mas sem hierarquia. Nós podemos, claro, ter programadores que desempenham tarefas menos estratégicas, mas um bom arquiteto deverá saber ouvi-los.

Arquitetos tem que ter uma boa relação com programadores. Uma relação de confiança e de troca de idéias mútua. Ele deve ser respeitado por sua capacidade técnica e organizacional. Mas o que se vê em muitos lugares é que empresas assim não só adotam o modelo hierarquico no desenvolvimento, como o reforçam na hierarquia de cargos, salários e atribuições. E, não é à toa, muitos arquitetos se tornam arrogantes por conta disso.

@ruivo

discordo da sua opnião, seria a mesma coisa que passar um texto corrido a um pedreiro e querer que ele contrua o prédio, não precisa pensar, só seguir os passos, já imaginou o tipo de predio que seria?

com Software é a mesma coisa, vc precisa conhecer o problema pra poder implementa-lo, não vai ser 2 ou 3 linhas escritas por alguem que vai te ajudar a compreender.

e acho essa divisão, de arquiteto, analista, programador, acrescente-se ao final de cara um junior, senior e pleno, uma putaria, ninguem precisa disso, é so uma desculpa pra pagar valores diferentes e so te aumentar salario por tempo de serviço, então não existe programador que não faz analise, se existe então: You are doing it wrong.

Se vc não sabe programar, analisar e arquitetar um software, vc não é programador, é não é o titulo que faz você, não é pq no teu crachá está arquiteto que você o é, vc precisa saber arquitetar um software para tal, e claro vc precisa escrever codigo, consequentemente fazer analise, são coisas que andam juntos, não tem como separar em etapas.

Quanto mais etapas, mas informação se perde e pior fica.

Essa “hierarquia” por assim dizer é o maior erro que uma empresa pode cometer, a tal ponto de comprometer todo o projeto como o vini falou. Justamente pela falta de visão do que acontece no nível mais baixo. Todos sabemos aqui que um código pode ser implementado de várias maneiras(que não podem nem mesmo ser contabilizadas). O modelo que vejo dar certo é o da equipe que elege um membro como arquiteto ou engenheiro justamente por este ter conhecimento maior que os outros em um “caso específico”. Esse papel a cada projeto é repassado aos outros membros.

Não tem cabimento executar um projeto de um “arquiteto” que não entende de compiladores ou imagens digitais, ou algo bem mais específico.
Cada profissional tem aptidão e experiências variadas.

Essa divisão por papeis é inspirada em dijkstra, o famoso “Dividir para conquistar”

O objetivo da empresa ao separar os papeis de arquiteto, analista, projetista, programador e etc. não é para definir importância ou salário ou mesmo hierarquia.
Na verdade, em uma empresa que esteja bem evoluida no processo, esses papeis teriam a mesma importância e a mesma dificuldade.
O importante para a empresa que adota um processo desses é se tornar completamente independente de uma pessoa. Se um arquietto, projetista, analista, programador sair da empresa o outro que vier pdoerá assumir o mesmo papel com pouca dificuldade.

Todos os papeis vão seguir um roteiro muito bem definido… não é só o programador que vai ter a ‘criatividade limitada’ mas todos os outros papeis.
O arquiteto também vai estar limitado aos artefatos criados pelo analista assim como o analista também vai estar limitado pelo que é especificado pelo cliente.
A ideia é suportar os projetos somente através do processo e dos artefatos que sao gerados por eles. No lugar de existir uma pessoa que tenha profundo conhecimento sobre o funcionamento de determinado modulo, as pessoas assumem papeis que tem bastante conhecimento sobre os artefatos que recebe como entrada e que produz como saída. A preocupação não é mais com o projeto, mas com o processo.

Já falei que o que amo nos ciclos/metodologias/whatevah agéis é o poder que se dá ao desenvolvedor/equipe?