O programador não precisa pensar

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

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á.

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á.

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.

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.

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!

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?

bééééé …

Empresas de maneira geral, não só na área de desenvolvimento de software, tem reconhecido cada vez mais a importância das pessoas e o capital humano como o capital de seu maior valor. Isso acontece porque toda empresa precisa inovar sempre, sob o risco de tornar-se obsoleta. E para inovar penso que o caráter multi-disciplinar e a diversidade são fundamentais, de forma que cada pessoa passa a tornar-se única, e não mais parte de um processo.

bééééé …

Empresas de maneira geral, não só na área de desenvolvimento de software, tem reconhecido cada vez mais a importância das pessoas e o capital humano como o capital de seu maior valor. Isso acontece porque toda empresa precisa inovar sempre, sob o risco de tornar-se obsoleta. E para inovar penso que o caráter multi-disciplinar e a diversidade são fundamentais, de forma que cada pessoa passa a tornar-se única, e não mais parte de um processo.

As empresas em geral também estão aperfeiçoado seus processos para produzir cada vez mais e com um menor custo.
Você tem um IPad, Iphone, notebook ou qualquer outro tipo de equipamento eletrônico por perto? Veja o local de fabricação e existe uma grande chance dele ter sido produzido na China… preciso dizer o motivo? O preço que pagamos pelos produtos é baixo graças ao sacrifício da renda de milhares de pessoas e da exploração irracional dos recursos de suas terras.

Por outro lado, é verdade que as empresas estão valorizando cada vez mais os “colaboradores”. As empresas começaram a perceber que o talento de cada pessoa também deve ser valorizado, mas não pq precisam inovar( não que não precisem), mas pq precisam de lucro. Uma pessoa vale para uma empresa a quantidade de lucro que ela é capaz de produzir.

Não importa o quanto queremos acreditar no contrário, mas para as empresas as pessoas são substituiveis e assim deve ser mesmo. Uma empresa não pode(ou não deve) depender de uma pessoa. Por isso algumas dão tanta importância aos seus processos.(Inclusive em alguns mercados seria impossível sobreviver sem isso -Tente ser uma empresa de logística dando ênfase à ‘criatividade’ de seus funcionários… pra estipular um prazo qualquer seria necessário uma bola de cristal, no mínimo)

Não estou dizendo que processos não são importantes. Mesmo porque eles o são. Porém eles não valem de nada se não existirem pessoas para avaliá-los e ajustá-los. Quando eu falo da valorização do capital humano não estou falando dos funcionários da empresa em si. Mas daquilo que a máquina não pode substituir. De fato, operários são considerados substituíveis, no sentido de que eles apenas reproduzem um determinado trabalho. Tanto que são substituídos por máquinas, geralmente eles não opinam sobre a organização da linha de montagem, da organização da fábrica, etc., mesmo porque seu conhecimento não o permite. Mesmo um gerente ou supervisor, aquele que simplesmente inspeciona o processo é uma pessoa substituível, pois à medida que os processos são automatizados a inspeção também passa ser automatizada, tanto quanto a operação em si. Nesse contexto, o capital humano não está nem nos operários , nem nos gerentes nem em qualquer hierarquia, mas geralmente nos engenheiros e gestores que entendem da demanda da empresa, onde está o custo de produção, etc. e a partir daí estabelecem processos. O fato de não ser um trabalho de natureza artística não significa que não façam uso da criatividade e da inovação, mesmo que essa criatividade e inovação sejam percebidas apenas internamente. Essa estrutura ainda sobrevive na indústria, mas é cada vez mais rara em empresas que dependem exclusivamente de capital intelectual. É o que acontece no desenvolvimento de software. A figura do operário é completamente desnecessária. Podemos automatizar geração de código, testes, builds, deploys, etc. Assim, o espaço que sobrou para o programador é simplesmente resolver problemas, aprender sobre o negócio do cliente, acompanhar a tecnologia, estabelecer processos de desenvolvimento, buscar ferramentas, etc. ou seja, nesse ponto, que depende de aprendizado, educação, estudo, e tudo o mais, a máquina não pode substituir o ser humano, é o espaço que sobrou para as empresas se tornarem competitivas.

Então, mas o fato da empresa tentar capturar todo tipo de conhecimento não pode ser algo ruim. Quando eu disse que “O importante para a empresa que adota um processo desses é se tornar completamente independente de uma pessoa” não quis dizer que as empresas não dão importância aos funcionários, até pq uma coisa não está diretamente relacionada com a outra. E também não estava me referindo à substituição por máquina, mas por outros humanos. Se temos o conhecimento de um sistema/negócio muito bem documentado, ou inerente ao próprio processo da empresa, é mais fácil para uma nova pessoa tomar de conta. Observando a incrível rotatividade em nossa área é preciso concordar que é algo sensato de se fazer mesmo.

Software não escala.

em grandes empresas cada programador faz uma coisa.
o programador recebe um readme com considerações gerais da tarefa, e um uml definindo algumas coisas (trabalhamos com POO, logo, é normal que outro programador vá utilizar algum método desenvolvido por você). você desenvolve a parte lógica da sua tarefa, sua classe tem de ser “fechada” sem bugs, então você desenvolve a lógica dos testes da sua classe. os debuggers trabalham com a mesma coisa, porém a principio não realizam testes unitários.

ao menos é assim que eu vejo o pessoal trabalhar por aqui.

Felagund:

@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.

Analise melhor: O pedreiro recebe o projeto e só tem que seguir o que está ali. Óbvio que o projeto não vai estar falando como assentar um tijolo ou quanto de cimento deve estar na coluna. Isso o pedreiro tem obrigação de saber.

Mesma analogia podemos fazer pro programador (naquele perfil que tinha dito: um cara sem nível superior, mas com um curso técnico de programação), ele deve ler o projeto e executar, sem se preocupar com detalhes da arquitetura. O programador se preocupar com isso, na minha opinião, é o mesmo que pedreiro dar palpite sobre o tamanho da parede, a posição das portas e/ou janelas e onde devem estar o canos e tubulações. Ele até pode saber fazer e pensar isso, mas não é o seu trabalho.

Outra coisa muito importante: O Engenheiro ou Arquiteto não entrega um projeto na mão do mestre de obras e some. O cara deve estar acompanhando a obra, para ver se o que foi projetado está sendo cumprido (Assim espera-se). Da mesma maneira, o Arquiteto de software deve estar sempre fazendo code review do que os programadores estão codificando, se a arquitetura do sistema não está sendo violada, se os padrões estão sendo seguidos, enfim, não só projetar o sistema, como também estar sempre “inspecionando a obra”.

E a sua frase

é muito infeliz. É por causa dessa visão que as empresas querem contratar um multiprofissional (Analista, Arquiteto, Programador, Designer) pelo valor do salário mais baixo. Se as funções estivessem bem definidas, e, acima de tudo, se houvesse a cobrança de cada cargo conforme conforme a responsabilidade, com certeza teríamos softwares de mais qualidade e menos profissionais frustrados com baixos salários.

ruivo:

Analise melhor: O pedreiro recebe o projeto e só tem que seguir o que está ali. Óbvio que o projeto não vai estar falando como assentar um tijolo ou quanto de cimento deve estar na coluna. Isso o pedreiro tem obrigação de saber.

Mesma analogia podemos fazer pro programador (naquele perfil que tinha dito: um cara sem nível superior, mas com um curso técnico de programação), ele deve ler o projeto e executar, sem se preocupar com detalhes da arquitetura. O programador se preocupar com isso, na minha opinião, é o mesmo que pedreiro dar palpite sobre o tamanho da parede, a posição das portas e/ou janelas e onde devem estar o canos e tubulações. Ele até pode saber fazer e pensar isso, mas não é o seu trabalho.

Outra coisa muito importante: O Engenheiro ou Arquiteto não entrega um projeto na mão do mestre de obras e some. O cara deve estar acompanhando a obra, para ver se o que foi projetado está sendo cumprido (Assim espera-se). Da mesma maneira, o Arquiteto de software deve estar sempre fazendo code review do que os programadores estão codificando, se a arquitetura do sistema não está sendo violada, se os padrões estão sendo seguidos, enfim, não só projetar o sistema, como também estar sempre “inspecionando a obra”.

E a sua frase

é muito infeliz. É por causa dessa visão que as empresas querem contratar um multiprofissional (Analista, Arquiteto, Programador, Designer) pelo valor do salário mais baixo. Se as funções estivessem bem definidas, e, acima de tudo, se houvesse a cobrança de cada cargo conforme conforme a responsabilidade, com certeza teríamos softwares de mais qualidade e menos profissionais frustrados com baixos salários.

Cara, vc faz testes? vc pode refatorar um codigo? Como que vc partir pra uma outra abordagem se vc tem um plano a seguir? A estrutura já vem pronta? tem certeza que o cara que definiu isso sabe o que ta fazendo? ele conheçe patterns? Ou vc é so um code monkey? É ridiculo pensar que deva existir toda a hierarquia, pela sua analogia, um programador não pode questionar uma definição do seu superior, pois “pedreiro não pode dar palpite sobre o tamanho da parede”.

Conheço alguns projetos que o pedreiro corrigiu cagadas do arquiteto, deu palpite na parede. Visões como essa que geram estruturas bizarras para pagar menos aos profissionais, o que leva um programador a virar analista ou arquiteto? Quais os atributos? A vontade da empresa? Canudo?

Se vc não pode analisar seu codigo e definir outro fluxo que seja melhor pra vc trabalhar e levar o projeto pra frente, vc não é um programador (isso envolve analise e arquitetura).
Analise não é so desenhar UML e escrever um texto dizendo o que deve ser feito. Isso não funciona, é por isso que projetos atrasam, é por isso que features são entregues sem nenhuma funcionalidade, e é por isso que existe retrabalho.

o Cliente falou X, o arquiteto entendeu Z o analista modelou Y e o programador fez T

Pronto seu fluxo está ai, dai depois o que acontece

Cliente reclama com arquiteto pq a funcionalidade não esta la que fala pro analista que fala pro programador que mostra pro analista a funcionalidade, que volta até o cliente e o cliente diz que não era isso.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

http://agilemanifesto.org/

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

http://manifesto.softwarecraftsmanship.org/

Isto é a maior furada… em todas empresas que eu vi isto sendo aplicado era completamente FAIL!!! o correto e ter um desenvolvedor que tbm é arquiteto e um analista de requisitos (ou o proprio desenvolvedor ser o analista de requisitors) pois com este sistema de construção civil traduzido para software a coisa não funciona… primeiro quanto mais gente envolvida hierarquicamente a informação final sempre tende a chegar errada ou desvirtuada a parte final da hierarquia (quem aqui não já viu aquela tirinha do balanço de pneu na arvore?), segundo em muitas coisas e problemas só depois de vc meter a mão na massa vc vai saber o que vai ter que ser feito principalmente em artefatos não funcionais… ninguem tem como prever como se tal software vai realmente ter a performace adequada ou se certa regra realmente e conveniente em certa situação sem meter a mão na massa… gerar quilos de documentação e burocracia geralmente só atrasam os projetos e fazem as pessoas trabalhar horas e horas a mais… e no final não ter a satisfação do cliente… esta do programador não pensar só fazer, isto não existe… e FAIL na certa em todos os casos… o programador deve pensar elaborar diagramar e desenvolver o software a partir dos requisitos… nunca vi um sistema fora este funcionar como deveria…

Esta frase já diz tudo:

Você entendeu pouco a minha visão. Mas vamos lá. Em nenhum momento eu disse que o ‘peão de obra’ (tanto o pedreiro quanto o programador) não podem questionar as decisões das pessoas que estão acima dele na hierarquia. O que ele não pode é, tendo o arquiteto ou engenheiro projetado algo, ele ir lá e mudar por vontade própria, ou enfiar algo no projeto, “pq assim é melhor”. E isso, em TI, isso acontece muito. O programador resolve que aquele pattern é muito complicado e o retira, ou que deveria acrescentar tal framework A ou B, pq “acha” que é melhor, e ignora as decisões que o analista e o arquiteto tomaram.

Quando você diz:

Cara, isso é muito mais simples do que parece. Se os programadores fizessem o que o cliente realmente quer, projeto nenhum atrasaria. Como que projeto atrasa 1 ano? Atrasando 1 dia de cada vez. E como atrasa 1 dia? Muitas vezes, com programadores tentando reinventar a pedra, ao invés de seguir a arquitetura e executar o projeto. Claro, se um negócio estiver absurdo (ou se ele achar absurdo), deve comunicar o arquiteto e/ou analista. Estes vão verificar com o cliente como resolver e, se assim precisar, modificar a arquitetura.

Mas o que vejo muito é programador tomando decisão unilateral, pensando somente nele, sem consultar cliente e arquiteto. Decisões essas que só vão estourar na frente, quando algo não estiver funcionando ou der errado.

Mas novamente, vou enfatizar. Eu penso que o programador deveria ser uma pessoa com nível técnico, sem a necessidade de um curso superior. As decisões macro devem ser feitas por uma pessoa (ou equipe) que tenha conhecimento de padrões, arquiteturas, frameworks, da mesma maneira que decisões macro, nas outras áreas, devem ser feitas por pessoas que estudaram e têm conhecimento pra aquilo. Se o pedreiro vai usar um mangueira ou uma regua pra verificar se o nível da parede está ok, isso é decisão dele. Agora, se a parede vai ter 2 ou 3 metros, isso deve ser decisão do engenheiro ou arquiteto.

Acredito que nossa discussão está encerrada, tempos pontos de vistas diferentes, quem sabe um dia vc entenda melhor o que eu disse, ou eu compreenda melhor sua visão. Mas no momento, acho toda essa hierarquia uma merda

Ainda vai ter que existir uma sintese entre as idéias da cultura/processo ágil e a ‘tradicional’.

As duas apresentam os problemas que consideram ponto chave e mostram a soluçoes, mas as duas são incompletas.
Existem buracos nas duas abordagens, e em vários pontos. Em alguns casos isso fica claro em alguns casos quando vemos conceito e prática indo em direção contrária.

Nos processos ageis, por exemplo, onde o foco é o ROI. Como avaliar quando passar por cima do processo vai ser de fato mais vantajoso para o cliente? Em uma visão imediata, na entrega de um projeto, pode até ser. Mas em uma visão macro, se não houver um preocupação também com o processo, a empresa terá dificuldade para estimar orçamentos futuros e etc.
Além disso, o valor de venda do produto passa a ser o tempo de desenvolvimento e não a real valor que ele agrega à empresa. Algumas vezes o sistema vai de fato valer mais do que foi pago e em outros casos vai valer menos. Economicamente falando isso é péssimo. É, literalmente, um prejuizo incalculável para quem produz o produto. Quando o valor de um produto se perde dessa forma, isso não é bom para ninguém, nem mesmo para o cliente que teve um ROI absurdo, isso pq a perda de valor do produto afeta a concorrencia, afeta a economia, afeta as empresas, afeta os empregados… afeta todo mundo. OK, isso ocorre em outros mercados também. Mas existe um problema conceitual nesse aspecto pois o tal do pensamento no ‘ROI’ parece ser unidirecional. Como eu posso estar com o foco no ROI do meu cliente e esquecendo meu próprio lucro? E se meu foco é o ROI do meu cliente, meu lucro não deveria ser proporcional ao valor que ele agrega?

Talvez seja pelo meu pouco conhecimento e falta de prática com os processos ágeis, mas esse é só um dos pontos que parecem estranhos, existem outros.

ruivo:

Felagund:

Cara, vc faz testes? vc pode refatorar um codigo? Como que vc partir pra uma outra abordagem se vc tem um plano a seguir? A estrutura já vem pronta? tem certeza que o cara que definiu isso sabe o que ta fazendo? ele conheçe patterns? Ou vc é so um code monkey? É ridiculo pensar que deva existir toda a hierarquia, pela sua analogia, um programador não pode questionar uma definição do seu superior, pois “pedreiro não pode dar palpite sobre o tamanho da parede”.

Conheço alguns projetos que o pedreiro corrigiu cagadas do arquiteto, deu palpite na parede. Visões como essa que geram estruturas bizarras para pagar menos aos profissionais, o que leva um programador a virar analista ou arquiteto? Quais os atributos? A vontade da empresa? Canudo?

Se vc não pode analisar seu codigo e definir outro fluxo que seja melhor pra vc trabalhar e levar o projeto pra frente, vc não é um programador (isso envolve analise e arquitetura).
Analise não é so desenhar UML e escrever um texto dizendo o que deve ser feito. Isso não funciona, é por isso que projetos atrasam, é por isso que features são entregues sem nenhuma funcionalidade, e é por isso que existe retrabalho.

o Cliente falou X, o arquiteto entendeu Z o analista modelou Y e o programador fez T

Pronto seu fluxo está ai, dai depois o que acontece

Cliente reclama com arquiteto pq a funcionalidade não esta la que fala pro analista que fala pro programador que mostra pro analista a funcionalidade, que volta até o cliente e o cliente diz que não era isso.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

http://agilemanifesto.org/

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

http://manifesto.softwarecraftsmanship.org/

Você entendeu pouco a minha visão. Mas vamos lá. Em nenhum momento eu disse que o ‘peão de obra’ (tanto o pedreiro quanto o programador) não podem questionar as decisões das pessoas que estão acima dele na hierarquia. O que ele não pode é, tendo o arquiteto ou engenheiro projetado algo, ele ir lá e mudar por vontade própria, ou enfiar algo no projeto, “pq assim é melhor”. E isso, em TI, isso acontece muito. O programador resolve que aquele pattern é muito complicado e o retira, ou que deveria acrescentar tal framework A ou B, pq “acha” que é melhor, e ignora as decisões que o analista e o arquiteto tomaram.

Quando você diz:

Cara, isso é muito mais simples do que parece. Se os programadores fizessem o que o cliente realmente quer, projeto nenhum atrasaria. Como que projeto atrasa 1 ano? Atrasando 1 dia de cada vez. E como atrasa 1 dia? Muitas vezes, com programadores tentando reinventar a pedra, ao invés de seguir a arquitetura e executar o projeto. Claro, se um negócio estiver absurdo (ou se ele achar absurdo), deve comunicar o arquiteto e/ou analista. Estes vão verificar com o cliente como resolver e, se assim precisar, modificar a arquitetura.

Mas o que vejo muito é programador tomando decisão unilateral, pensando somente nele, sem consultar cliente e arquiteto. Decisões essas que só vão estourar na frente, quando algo não estiver funcionando ou der errado.

Mas novamente, vou enfatizar. Eu penso que o programador deveria ser uma pessoa com nível técnico, sem a necessidade de um curso superior. As decisões macro devem ser feitas por uma pessoa (ou equipe) que tenha conhecimento de padrões, arquiteturas, frameworks, da mesma maneira que decisões macro, nas outras áreas, devem ser feitas por pessoas que estudaram e têm conhecimento pra aquilo. Se o pedreiro vai usar um mangueira ou uma regua pra verificar se o nível da parede está ok, isso é decisão dele. Agora, se a parede vai ter 2 ou 3 metros, isso deve ser decisão do engenheiro ou arquiteto.

E nos casos onde o programador sabe o certo mas segue a arquitetura errada do arquiteto pois assim esta a especificação… o projeto não atrasa? sendo que aquele que mete a mão na massa tem uma visão tecnica geralmente melhor daquele que não faz isto… geralmente é o contrario que acontece… o arquiteto não tem uma visão de tão baixo nivel… ele tem uma visão, mas mais de alto nivel dai então especificar bytes é mais complexo para ele, mesmo sendo muito experiente… e a chance do mesmo errar é alta…

Se as coisas funcionassem desta maneira, não iria mais ser necessário programadores ou desenvolvedores, apenas precisariam de um programa para traduzir especificação em codigo… talvez algo como o maker :twisted: , que seus problemas acabaram-se… mas quem desenvolve software sabe que a coisa não funciona assim…

Se voce quer ser estagnado na sua vida profissional trabalhe em uma fábrica de software. Ninguem verá o resultado do seu serviço e outros tomarão seu crédito.
FElizmente já pulei fora dessa. :lol: mas sempre tem empresinhas de meia tigela oferecendo soluções e oportunidades ‘ótimas’. :roll:

Bem, eu não devo estar conseguindo expressar a minha opinião. Mas vou tentar ser mais claro desta vez.

Atualmente, a função de programador exige que a pessoa tenha conhecimentos de análise, design, arquitetura… Sem esses conhecimentos, provavelmente não terá sucesso na carreira.

Mas, na minha opinião, deveria ser de outra maneira. A função de programador poderia ser desempenhada por alguém que tivesse só o conhecimento técnico, isto é, conhecesse Java, um pouco como usar o DB, lógica. Alguém que, com um curso de 1 ou 2 anos, com o básico mesmo, pudesse ler uma documentação e pôr em prática o que estiver descrito.
Alguém que termine o ensino médio, com 17 ou 18 anos, e consiga ler um UML, uma documentação de API e desenvolva seguindo um projeto, planejado por um Arquiteto ou Analista.

E essa figura do Arquiteto e Analista seria o responsável por consultar o cliente, verificar as suas necessidades e, com base nisso, se preocupar com as decisões Macro do projeto em relação à arquitetura. Essa pessoa seria a responsável por analisar cada framework a ser utilizado, fazendo os prós e contras, pensar cada parte do sistema olhando o todo e desenvolver alguns módulos mais complexos, com base no conhecimento adquirido por mais anos (e experiência) que o simples conhecimento das ferramentas.

E por que digo isso? Porque vejo muitos profissionais, que passaram 4-5 anos na faculdade, aprenderam como funcionam, em detalhes, compiladores, sistemas operacionais, computação gráfica, grafos, complexidade algorítmica e no final não passam de “code monkeys nível 3”, que, particularmente, acho um desperdício de tempo e talento.

Será que não é possível treinar alguém em Java e UML em 1 ou 2 anos, para executar essa tarefa de codificação? Será que não é possível colocar pessoas que estudaram mais, que fizeram faculdade e estudaram a fundo a teoria e tecnologias, para fazer o trabalho de arquitetos e analistas, direto?

Eu acredito que, se ao invés de inventar um curso fuleiro que enche linguiça por 4 anos, pra no final o cara mal saber programar, houvesse uma aceitação maior de profissionais de nível técnico, que não teriam um conhecimento aprofundado mas soubessem utilizar bem as ferramentas, não teríamos profissionais menos frustrados?

É essa visão que tentei mostrar. Dar mais valor àquele que estudou mais e se aprofundou, mas também dar mais chances para àqueles que conhecem bem as ferramentas, mas não tem tanto conhecimento da teoria de como as coisas funcionam (ou deveriam funcionar). E também evitar que alguém tenha que enfrentar 4-5 anos de estudos, para, no final, se frustar por estar somente programando, quando poderia estar utilizando seus conhecimentos de maneiras mais desafiadoras.

Ruivo,

eu entendi seu ponto de vista, e eu discordo dele, prefiro varios programadores que saibam o que fazem, do que ter uma hierarquia e um bobalhao que so vomita codigo, quem que vai conseguir entender se o cara não se aprofundou?? Se o cara se manteve no mesmo nivel a vidade toda, ele vai escrever codigo do mesmo jeito.

e se vc quer aprender algo de verdade não é a Faculdade seu lugar, o ensino superior é mais pra ensinar teoria que pratica, por isso existem escolas como a Caelum que ensinam muito sobre programação, é errado vc achar que a faculdade deve te ensinar a ser um Analista/Arquiteto, vc aprende uma gama de coisas, e escolhe aonde vai seguir, tenho amigos que fizeram Sistema de Informação e hoje trabalham com Redes, por que gostaram mais.

Enfim pra mim so existem programadores numa empresa, dependendo do projeto cada um assume um papel distinto

não sei se fui claro ou se fiquei viajando aqui enquanto escrevia, mas me questione que tento ser mais claro do meu ponto de vista.

abraços

Muita gente ainda valoriza demais a programação e as linguagens e tem dificuldade em aceitar ela como um simples meio.

Falaram do Maker, mas existe ferramentas corporativas muito mais avançadas onde a necessidade de digitar código na mão é quase nula. Veja alguns ERP’s da vida, por exemplo, que muitas vezes cumprem seu papel muito bem e quase nunca exige intervenção de baixo nível no sistema. O desenvolvimento nesses ambientes é algo completamente diferente do que a maioria está acostumado. Digitar linha de código é algo que só irá acontecer em casos excepcionais. A programação em baixo nível é evitada ao máximo, apesar de não poder ser excluida completamente (Ainda assim é com base em toda estrutura e padrões do próprio sistema).

É impossível encontrar um só profissional que tenha um conhecimento tão grande nessas áreas que você citou. Por que? Porque elas são muito extensas e é preciso estudar a vida inteira para ter gabarito no assunto. É aí que se formam os Doutores, e mesmo assim em menos da metade das que você citou.

Esse modelo de “arquiteto genérico” é uma falha grotesca de algumas empresas.

@juliocbq

Não disse em momento algum que a pessoa tem que saber TUDO de TODAS as áreas. Da mesma maneira que o médico e o engenheiro, que aprende um apanhado do todo e depois escolhe uma área e se especializa nela, assim devia com os profissionais de TI.

O cara aprende na faculdade Sistemas Operacionais, Sistemas Distribuídos, Compiladores, Computação Gráfica, termina a faculdade e depois se especializa numa área e poderia virar um Arquiteto de Compiladores, por exemplo.

Eu acredito que o generalista tende mais a perder que o especialista. Pode acontecer de aquela área sumir? Pode, mas aí vai do profissional estar atento e sempre se reciclando.

E concordo com vc no seguinte ponto:

O que é o programador atualmente senão um arquiteto genérico? Por isso defendo a idéia de que os arquitetos devem ter mais estudos e se especializar, enquanto o programador ficar naquela função que melhor lhe compete, que seria conhecer bem a ferramenta e saber usá-la para desenvolver o que foi projetado.