Uma Pequena Provocação aos Arquitetos

This message was edited 1 time. Last update was at 03/12/2009 18:14:18

bobmoe wrote:

mochuara wrote:Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

bixo, pior q ta chegando nesse ponto, existe gente por aí até achando que arquiteto é um cargo administrativo

Ninguém tá falando que o arquiteto não tem skill de programação e muitas vezes programa em diversas linguagens como Haskell, Erlang,Scala, Ruby, escreve DSL conhece produtos e por aí vai ...Mas porém, contudo, todavia se o mesmo ficar no ambiente de trabalho sentado sobre o código de uma aplicação específica, ele acaba perdendo o sentido de coaching por exemplo sobre a equipe. Perde a visão externa da aplicação, não consegue dar vazão aos diversos projetos da empresa.

Acredito que o bom arquiteto precisa sim saber programar, fazer pesquisas, conhecer produtos e afins e se ficar somente programando, ele vira apenas mais um programador e não terá tempo de tomar decisões, conversas com fornecedores, fazer reuniões com clientes internos e externos e por aí vai ... Esse é o ponto.

bobmoe wrote:mas a qualidade do arquiteto vai seguir o nível da empresa, é por isso que ter mais cabeças pensantes sempre vai ser melhor.
o problema desse lider moral que vc citou é a centralização do conhecimento em uma pessoa. saias justas não podem existir, tudo deve estar disseminado entre a equipe, ou pelo menos para uma parte mais capacitada do grupo (que seja mais de uma pessoa).

Bob, o problema são os "enterpresys" como diz o Akita. Você no papel de arquiteto estará sempre um passo à frente pois estuda, se dedica, tem conhecimento teórico e muitas vezes prático também, enquanto o seu colega sai às 18h e vai pro futebol e não tem a mínima idéia de quem seja por exemplo Eric Evans.

Cara já entrevistei muito "especialista SOA" que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai .... Complicado !!

Por tanto, em muitos cenários - "enterprisys", prefiro o Taylorismo.

Kenobi wrote:Cara já entrevistei muito "especialista SOA" que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai .... Complicado !!

Espero ter entendido errado, logo, sem querer ofender, mas esta coisa de exigir que um técnico saiba nomes de autores de livros e etc acho um pouco demais. É bonito, demonstra certo respeito e muitas vezes deixa o caboclo bem posicionado.

Mas...todos que conheci, sem exceção nenhuma, que ficava se gabando que leram tais e tais livros, ficavam citando nomes, passagens (como na biblia) e frases de efeito eram muuuuuito ruins tecnicamente; tremendos caras de pau. Costumavamos chama-los de vendedores, reis do xaveco. Enganavam o "gerente" tosco sem noção e conseguiam as vagas, infelizmente testes ajudam nesta hora.

Quando começavam a trabalhar era aquela coisa...não saia nada.

Portanto, quando encontro com alguem que começa a bancar o poeta ou professor de historia (estes sim sabem de nomes) perto de mim já vou logo desconfiando.

Na minha opinião tem que ser objetivo...vamos falar de problemas, soluções, novidades, formas criativas de construir software, trabalho em equipe, solução de conflitos e por ai vai.

Os nomes ajudam bastante na hora de comprar os livros na livraria - muitas vezes o vendedor pergunta pelo nome.

flws

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

fantomas wrote:

Kenobi wrote:Cara já entrevistei muito "especialista SOA" que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai .... Complicado !!

Espero ter entendido errado, logo, sem querer ofender, mas esta coisa de exigir que um técnico saiba nomes de autores de livros e etc acho um pouco demais. É bonito, demonstra certo respeito e muitas vezes deixa o caboclo bem posicionado.

Mas...todos que conheci, sem exceção nenhuma, que ficava se gabando que leram tais e tais livros, ficavam citando nomes, passagens (como na biblia) e frases de efeito eram muuuuuito ruins tecnicamente; tremendos caras de pau. Costumavamos chama-los de vendedores, reis do xaveco. Enganavam o "gerente" tosco sem noção e conseguiam as vagas, infelizmente testes ajudam nesta hora.

Quando começavam a trabalhar era aquela coisa...não saia nada.

Portanto, quando encontro com alguem que começa a bancar o poeta ou professor de historia (estes sim sabem de nomes) perto de mim já vou logo desconfiando.

Na minha opinião tem que ser objetivo...vamos falar de problemas, soluções, novidades, formas criativas de construir software, trabalho em equipe, solução de conflitos e por ai vai.

Os nomes ajudam bastante na hora de comprar os livros na livraria - muitas vezes o vendedor pergunta pelo nome.

Exactamente.
Acho que o problema é que o pessoal vive num misto de academismo/reverencialismo que é dificil de quebrar quando a pessoa não tem realmente conhecimento real. E além disso é sempre mais facil de fulano X disse porque :
1) argumento de autoridade , se x disse e x é autoridade => deve ser verdade
2) se der merda a culpa é do x.

Kenobi wrote:

bobmoe wrote:mas a qualidade do arquiteto vai seguir o nível da empresa, é por isso que ter mais cabeças pensantes sempre vai ser melhor.
o problema desse lider moral que vc citou é a centralização do conhecimento em uma pessoa. saias justas não podem existir, tudo deve estar disseminado entre a equipe, ou pelo menos para uma parte mais capacitada do grupo (que seja mais de uma pessoa).

Bob, o problema são os "enterpresys" como diz o Akita. Você no papel de arquiteto estará sempre um passo à frente pois estuda, se dedica, tem conhecimento teórico e muitas vezes prático também, enquanto o seu colega sai às 18h e vai pro futebol e não tem a mínima idéia de quem seja por exemplo Eric Evans.

Cara já entrevistei muito "especialista SOA" que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai .... Complicado !!

Por tanto, em muitos cenários - "enterprisys", prefiro o Taylorismo.

acho bobeira colocar um cara para guiar o projeto achando que design vai salvar alguma coisa....
é a mesma coisa que ir para um campeonato de artes marciais com 1 faixa preta e 9 faixas brancas... no final a academia vai levar pau!
concordo que sempre vai existir um lider natural, uma cara que se destaca. mas o problema é quando isso se transforma num cargo de mão única.
o cargo não é necessário, a decisão final de todos comprometidos é mais importante. e sempre a equipe vai saber o que é melhor para ela. bom ou ruim, o grupo só concordará com o que pode fazer... paciencia, pois foi você que esolheu estar lá. sacou ?

Só reforçando, vale a pena ler o artigo do Fowler: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Eu gosto da citação "A importância de um arquiteto é inversamente proporcional ao número de decisões que ele precisa tomar."

abracos

This message was edited 3 times. Last update was at 03/12/2009 21:38:14

fantomas wrote:

Kenobi wrote:Cara já entrevistei muito "especialista SOA" que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai .... Complicado !!

Espero ter entendido errado, logo, sem querer ofender, mas esta coisa de exigir que um técnico saiba nomes de autores de livros e etc acho um pouco demais. É bonito, demonstra certo respeito e muitas vezes deixa o caboclo bem posicionado.

Mas...todos que conheci, sem exceção nenhuma, que ficava se gabando que leram tais e tais livros, ficavam citando nomes, passagens (como na biblia) e frases de efeito eram muuuuuito ruins tecnicamente; tremendos caras de pau. Costumavamos chama-los de vendedores, reis do xaveco. Enganavam o "gerente" tosco sem noção e conseguiam as vagas, infelizmente testes ajudam nesta hora.

Quando começavam a trabalhar era aquela coisa...não saia nada.

Portanto, quando encontro com alguem que começa a bancar o poeta ou professor de historia (estes sim sabem de nomes) perto de mim já vou logo desconfiando.

Na minha opinião tem que ser objetivo...vamos falar de problemas, soluções, novidades, formas criativas de construir software, trabalho em equipe, solução de conflitos e por ai vai.

Os nomes ajudam bastante na hora de comprar os livros na livraria - muitas vezes o vendedor pergunta pelo nome.

flws

Sinceramente, pra mim é impossível o cara ter uma boa base sem conhecimento literário. Não tem como você ser bom, principalmente em Design de software sem estudar à fundo o assunto.

Se você nunca leu por exemplo um livro do Eric Evans - Domain Driven Design, ou não fez um curso referente ao tema, como sabe que está no caminho certo da modelagem ? Se nunca estudou engenharia de software, nunca leu um pattern, que é uma solução catalogada para aquele problema específico, como vai saber se seu design não vai incorrer nos problemas que muitos já passaram ?

Pra mim ir na raça, fazendo sem base alguma pode resultar em muita coisa ruim. Há também os que citam sem nunca terem lido e aí que está talvez sua má impressão ou pior, leu e não entendeu nada.

Mas se já é difícil fazer algo bom estudando muito, imaginem o cara que nunca pega um livro pra estudar....

Só pra fechar o assunto eu tenho a experiência inversa, inclusive muitos processos seletivos mais modernos pedem pra você citar seus 3 últimos livros lidos - TW, Globo.com (entre outras empresas). As pessoas mais antenadas, possuiam mais domínio do assunto.

Particularmente minha última contratação enquanto Gerente da equipe, era uma pessoa que conheci aqui no GUJ, que possui bastante experiência literária apesar da pouca idade e vi a diferença de destaque no dia-a-dia junto à equipe - Rubem Azenha.

PS: Sabe nome dos autores não é imprescindível, normalmente você o faz de forma incosnciente, pois se gosta da leitura acessa blog, artigos entre outros.

This message was edited 2 times. Last update was at 03/12/2009 22:06:36

Bob, existe um conceito no Aikidô de Sempai-Kohai, onde o faixa preta(Sempai) é responsável pelo faixa branca (Kohai) e ajuda o mesmo no seu caminho à evolução.

Ninguém vai a um campeonato com faixas brancas, daí a importância de um processo seletivo criterioso. Você vai com um Shihan (Arquiteto) e vários Yodans, Sandans e no máximo alguns Shodans (faixa-preta 1 grau). Se você tiver no seu DOJO mais de um Shihan, sorte sua, ou alunos Yodan-Sandan, legal você pode compartilhar 90% da formação dos alunos. Aquele pedacinho que falta, onde o Shiran possui maior experiência ele contribui e auxlia no processo.

Se você não pode cuidar do processo de contratação, precisa cuidar da formação da sua equipe, tentar fazê-los passar de faixa, forçando os Katas, aprendizado.

Em muitas empresas, por questões de custo, optam em contratar profissionais intermediários (Faixa Azul - Aikidô) e o Shihan precisa forçar os conceitos, ensinar as melhores práticas e vai do discípulo querer evoluir, senão estaciona mesmo na faixa por anos.

Faixa branca é estagiário, não deve ter responsabilidade sobre decisões e nem sobre o andamento do projeto como um todo, está ali para aprender, fazer suas 6h de estágio, 4h em épocas de prova, conforme a lei e prestar o exame de faixa a final do mesmo

.

kenobi wrote:Sinceramente, pra mim é impossível o cara ter uma boa base sem conhecimento literário. Não tem como você ser bom, principalmente em Design de software sem estudar à fundo o assunto.

Se você nunca leu por exemplo um livro do Eric Evans - Domain Driven Design, ou não fez um curso referente ao tema, como sabe que está no caminho certo da modelagem ? Se nunca estudou engenharia de software, nunca leu um pattern, que é uma solução catalogada para aquele problema específico, como vai saber se seu design não vai incorrer nos problemas que muitos já passaram ?

Pra mim ir na raça, fazendo sem base alguma pode resultar em muita coisa ruim. Há também os que citam sem nunca terem lido e aí que está talvez sua má impressão ou pior, leu e não entendeu nada.

Mas se já é difícil fazer algo bom estudando muito, imaginem o cara que nunca pega um livro pra estudar....

Só pra fechar o assunto eu tenho a experiência inversa, inclusive muitos processos seletivos mais modernos pedem pra você citar seus 3 últimos livros lidos - TW, Globo.com (entre outras empresas). As pessoas mais antenadas, possuiam mais domínio do assunto.

Particularmente minha última contratação enquanto Gerente da equipe, era uma pessoa que conheci aqui no GUJ, que possui bastante experiência literária apesar da pouca idade e vi a diferença de destaque no dia-a-dia junto à equipe - Rubem Azenha.

PS: Sabe nome dos autores não é imprescindível, normalmente você o faz de forma incosnciente, pois se gosta da leitura acessa blog, artigos entre outros.

De acordo...

A questão é a seguinte, eu quiz dizer que: não é porque o individuo leu o livro do Eric Evans, Martin Fowler e etc... ele será um entendido em determinada tecnologia ou será um bom arquiteto. Irá indicar, na minha opinião, apenas que a pessoa se interessa pelo assunto. Alem disso, não basta ler TEM QUE ENTENDER. Ou seja, leu 3 livros, mas aí vem as perguntas: Será que entendeu? Será que não formou pre-conceitos? Será que trocou o paradigma ou apenas adaptou? Aqui no GUJ percebo várias destas situações.

As vezes é melhor trabalhar com alguem que não conhece a tecnologia mas que tem todos os subsidios (principalmente a humildade) para aprender do que trabalhar com alguem que ACHA que sabe, pensa que porque leu o livro do Martin Fowler está salvo.

É claro que lêr é importante. Ler (e entender) livros na nossa àrea é algo que talvez não deveria ser nem questionado. Eu nunca ouvi dizer que perguntou se o carro viria com as rodas na hora da compra. Mais uma vez, eu entendo seu ponto de vista, quando participo de entrevistas procuro perceber se o candidato faz leituras, só não pergunto diretamento, porque estou em busca de conteúdo. Uma situação acaba levando a outra.

Se o arquiteto conhece bem DDD, interessa que livro ele leu? Aliás, o candidato acaba comentando mesmo sem querer.

Este teste dos 3 (é um número mágico?) livros me parece interessante, mas pelo que entendi funciona da seguinte maneira: se a pessoa leu um livro Eric Evans, um do Martin Fowler e outro do Ken Schwaber ele seria considerado profissional "antenado". Mas uma coisa me chamaria a atenção sobre o candidato: o individuo não leu nada sobre trabalho em grupo, como funciona as relações interpessoais, produtividade etc..., ou seja, posso assumir também que o cara é um porre para trabalhar em equipe; talvez não saiba ouvir e nem se expressar com objetividade e clareza.

A idéia não é dizer que vc está certo ou errado...só não concordo totalmente com a idéia no momento.

E mais ainda, alertar que o mundo da tecnologia é maior do que a maioria pensa.

O mercado indica que o mais difícil não é encontrar alguem que conheça a tecnologia; o difícil é encontrar alguem que saiba se comportar, ser produtivo em grupo sem falar da questão de ser confiável no sentido de assumir justos compromissos.

flws

JavaBaby Membro desde: 18/09/2004 11:10:06 Mensagens: 90 Offline

No Encontro Ágil 2009, Jutta Eckstein (http://www.jeckstein.com) disse que era importante ter em equipes uma pessoa que seja responsável pela visão de negócio e uma pessoa responsável pela visão técnica, claro que essa visão deve ser transmitida e compartilhada por toda a equipe, mas esses seriam, segundo ela, respectivamente, o papel (!= cargo), do product owner e do arquiteto.

Essa é outra definição interessante:

The architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile architect must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organisation.

Fonte: http://www.agilearchitect.org/agile/role.htm

Eu creio que a necessidade, desde papel em uma equipe, assim como o papel de scrum master, por exemplo, está diretamente relacionado com a maturidade da equipe e das necessidades do projeto. Não acho que exista uma regra absoluta que seja aplicada a qualquer tipo de projeto ou equipe, entretanto, investigar o real valor deste papel em uma equipe é muito válido e pode ser tentado, desde que isso possa de alguma forma realmente agregar valor ao resultado final.

Outra referência interessante: http://martinfowler.com/articles/designDead.html#id73363

In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in "I'm not just a mere programmer - I'm an architect". This may translate into "I'm an architect now - I'm too important to do any programming". The question then becomes one of whether separating yourself from the mundane programming effort is something you should do when you want to exercise technical leadership.

Creio que Martin Fowler na frase acima realmente apresentou o real motivo de arquitetos estarem tão na moda. (e olha que este texto é de 2000).

mochuara wrote:Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

sergiotaborda wrote:Em lado nenhum eu falei que o arquiteto programava mais ou menos que o desenvolvedor. Eles programam quanto for necessário quando for necessário. Como falei, arquiteto é um role. Designer é outro, tester, etc... todos programam. dizer que um programa mais que outro não faz sentido.

Estamos falando da mesma coisa, mas em palavras diferentes.

Talvez eu não esteja sabendo me explicar.

Olá

fantomas wrote:...

Parabéns pelo que escreveu.

Apesar de geralmente não ler com atenção mensagens anônimas, isto é, de quem não se identifica, li a sua e gostei muito.

Ler também é uma questão de gosto e de hábito. Leio desde criança e acho que minha geração lia mais do que as atuais. Alguém que diz que lê impressiona mas é como você escreveu. Há gente que aprende e gente que dá uma lidinha rápida. Posso falar por mim. Tenho um monte de livros. A maioria dei uma lidinha rápida ou li com atenção só uma parte do livro.

fantomas wrote:alertar que o mundo da tecnologia é maior do que a maioria pensa.

O mercado indica que o mais difícil não é encontrar alguem que conheça a tecnologia; o difícil é encontrar alguem que saiba se comportar, ser produtivo em grupo sem falar da questão de ser confiável no sentido de assumir justos compromissos....

Aqui então você matou a pau. Não basta saber. Tem que ser produtivo e construir um bom ambiente.

[]s
Luca

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

garcia-jj wrote:

mochuara wrote:Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a "arquitetura da aplicação" (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

This message was edited 2 times. Last update was at 04/12/2009 11:40:11

mochuara wrote:

garcia-jj wrote:

mochuara wrote:Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a "arquitetura da aplicação" (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia...Aí, não tem tempo mesmo pra fazer qualquer telinha que seja.

O arquiteto tem q ser uma mistura de ler muito e saber colocar em prática (e quando colocar). Além disso ele precisa saber justificar bem as suas decisões para a equipe, acho que o status "pra que explicar se pode mandar" não cai bem nesse papel.

Eu lembro ter escutado num podcast que o responsável de TI do site Digg disse que recebia 100 currículos de pessoas com Doutorado em TI, mas pessoas que haviam gerenciado mais de 100 servidores ele nunca recebia, e era o que ele mais procurava.

Como já comentaram aqui, já peguei uma entrevista com esses picaretas que adoram falar bonito e citar livros. Bastou algumas perguntas mais técnicas, mais do conteúdo desses livros que a verdade apareceu. Esse tipo de gente faz parte do mercado infelizmente, e garanto que engana muito gerente por aí até hoje.

Notícias, artigos e o maior fórum brasileiro sobre Java