O que diferencia um arquiteto?

[Alexandre Valente]

Oi pessoal,

Na composição de times de nossa empresa, muitas vezes conversamos sobre qual é o perfil desejado para uma determinada posição. E aí caímos sempre na dúvida entre contratar um junior ou alguém mais senior (com obviamente um valor hora maior).

Então resolvi perguntar a vocês o que acham disto. Pegando os extremos, um arquiteto custa 2 a 4 vezes mais do que um junior. E o que diferencia um do outro? Quando vale a pena usar um ou outro perfil?

Por junior eu estou assumindo alguem que mal acabou de aprender a desenvolver aplicações simples, com somente o básico de conceitos de OO e web. E arquitetos são aqueles que dominam todos os conceitos, teorias e tem muita experiência (como os vários exemplos de participantes desta lista).

Assumindo que os dois perfis, dado um problema, irão gerar uma solução diferente, com prazos diferentes, então, de uma perspectiva da emprea, o que diferencia um do outro? Efetividade ? (ou seja, tem problemas que só arquitetos resolvem, logo para aplicações simples faz sentido usar juniores....) Produtividade? (ou seja, um arquiteto seria sempre 4x ou mais produtivo que um junior, logo sempre faz sentido se contratar sempre só arquitetos... ) Manutenabilidade ? (ou seja, a aplicação de um arquiteto é sempre mais manutenível - logo para aplicações simples que não evoluem faz sentido usar juniores). Qualidade ? (ou seja, a aplicação de um arquiteto é sempre melhor... mas melhor em que aspecto? isto faz alguma diferença pro cliente?). Alguma outra?

Abs

Alexandre Valente

MCSE+I, MCSD, MDCBA

Arquiteto Perlink (www.perlink.com.br) 

[Giovanni Bassi]

Olá Alexandre,

O que diferencia um do outro?

Efetividade ? (ou seja, tem problemas que só arquitetos resolvem, logo para aplicações simples faz sentido usar juniores....)

Não existem aplicações simples. Mesmo a calculadora do Windows, que é o exemplo mais simples de todos, envolve operações complexas, um local de armazenamento das preferências do usuário, conceitos de usabilidade, etc, etc...

 

 

Produtividade? (ou seja, um arquiteto seria sempre 4x ou mais produtivo que um junior, logo sempre faz sentido se contratar sempre só arquitetos... )

Sim, arquitetos são mais efetivos, só que você está colocando como se o arquiteto fosse codificar 100% da aplicação, o que é um desperdício de recursos, além de não se encaixar no perfil da maioria dos arquitetos, que quer programar, mas não só isso.

 

 

Manutenabilidade ? (ou seja, a aplicação de um arquiteto é sempre mais manutenível - logo para aplicações simples que não evoluem faz sentido usar juniores).

Não existem aplicações simples que não evoluem. Assuma que toda aplicação vai evoluir. O principal motivo para a existência do arquiteto é garantir o futuro da aplicação, garantir que a aplicação não vem abaixo depois de um ano. Também vale aqui dizer que o arquiteto não deve codificar a aplicação inteira.

 

 

Qualidade ? (ou seja, a aplicação de um arquiteto é sempre melhor... mas melhor em que aspecto? isto faz alguma diferença pro cliente?). Alguma outra?

Se a qualidade faz diferença pro cliente? O que você acha? O arquiteto vai garantir, através da aplicação das boas práticas de programação e arquitetura, que a aplicação vai ser mais barata para evoluir, vai dar menos erros, vai ter mais performance, etc, etc... Tudo isso é importante para o cliente.

Alexandre, não encare o arquiteto como se fosse um desenvolvedor mais senior que o desenvolvedor senior, como se arquiteto fosse uma posição a mais que senior. Arquiteto é outro bicho, não é desenvolvedor. Ele também desenvolve, mas se você quiser comparar efetividade na programação, devemos comparar um desenvolvedor junior a um pleno e a um senior.

Encare o desenvolvedor junior como um estudante de medicina que está no quarto ano e que não teve experiência prática. Ele tem toda a teoria, mas nunca foi guiado por um profissional mais senior. Você colocaria um médico quarto anista para operar um coração? Não, né? Nem mesmo para diagnosticar uma gripe. Ao final do sexto ano, já com experiência, ele pode dar receitas para gripe, mas não pode operar um coração. Para isso ele precisa de mais 3 anos. Se quiser operar cérebros, vai levar mais 6 anos. Ninguém deixa o cara "ir aprendendo" enquanto opera. O mesmo deve valer para o desenvolvimento de um software. Se você deixar um jr cuidar, o paciente (o sistema) vai morrer. Mesmo um sistema simples (uma gripe) é coisa demais para quem não tem experiência prática nenhuma (um jr).
Componha o time do projeto com perfis diversos, sr, jr, pl, e um arquiteto para auxiliá-los.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/8/1 Alexandre Valente <alexandre...@gmail.com>

[Luiz Carlos Faria]

Boa noite Alexandre,

 

A maturidade e experiência contam muito, ainda mais se tratando de algo tão pouco palpável.

 

Quanto melhor o Junior, mais “pilhado” ele é, assim, mais erros ele irá cometer por não medir os riscos do que está fazendo.

 

A experiência é fundamental para qualquer projeto. Não adianta perder tempo com soluções mirabolantes que no final das contas só aumentarão o custo. É preciso ter tato(maturidade) para saber onde deve e onde não deve aplicar esforços. Profissionais juniors não tem tanto conhecimento da plataforma, conhecem muito overview. Na prática, o overview não serve de muita coisa. Profissionais com maior senioridade rendem mais porque pensam e vêem o todo. Até quanto a política dentro das empresas. É preciso saber escutar, e falar na hora certa e com a pessoa certa. Energia deve ser gasta com eficiência senão... nada acontece.

 

Uma das grandes diferenças, e esse é o ponto que mais prezo é a capacidade de administrar restrições. Em todos os cenários possíveis e imagináveis temos diversas restrições e o que difere um profissional de outro é sua capacidade de se adaptar às restrições, sejam orçamentárias, técnicas, estratégicas. Esses são os diversos aspectos que diferenciam os profissionais mais experientes dos novatos, mas também, se não houvesse diferença estaríamos fritos!!!

 

 

MonkeyCoders

 

Duas empresas por onde passei tinham a idéia de ter macacos bem treinados para a construção de sistemas. Esse modelo funciona, mas precisa ter um ecossistema muito homogêneo para alcançar este objetivo, coisa que até então não vi. Neste caso levo em conta infra-estrutura, modelos de aplicações desenvolvidas, features suportadas. Ainda é preciso manter um time mais sênior para o desenvolvimento do que não adere ao que o time de MonkeyCoders produz. Existem diversos aspectos ruins nesse modelo, um deles é o turnover causado pelo pouco crescimento profissional.

Outra característica interessante é o trabalho de arquitetura necessário para viabilizar este modelo e geralmente precede sua implantação. Um agravante nestes casos é a pouca capacidade evolutiva. Nestes cenários, a quantidade de arquitetos é drasticamente reduzida, mas acredite, é uma situação sazonal. Periodicamente você contratará ou formará o time que evoluirá seu framework de trabalho.

[Alexandre Valente]

Oi Giovanni,

Não entendi porque um arquiteto não pode codificar 100% de aplicação. Ele não é mais eficiente e rápido? Porque ele não deve codificar a solução inteira? A solução final não vai ser melhor? Vc fala como se o arquiteto fosse somente um teórico, distante de necessidades práticas, quase como um pesquisador. Se for isto ok, este tipo de perfil realmente é dificil de ser usado na prática. Vou mudar então e comparar com alguém "ultra-senior", ou seja, sabe tanto quanto qualquer arquiteto mas é capaz de programar e entregar qualquer parte da aplicação e não ficar só na teoria. Não seria melhor então ter somente "ultra-seniores"?

Agora o lance de toda a aplicação ter que ser projetada por um arquiteto pra durar e etc, vc não acha um pouco de exagero? Se vc parar para analisar, existem aplicações rodando bem ainda hoje em Clipper que nem orientadas a objeto são, se duraram mais de 15 anos, não podem estar totalmente erradas, certo? Na nossa empresa tempos aplicações ASP e ASP.NET de 5 e até 10 anos de idade que atendem perfeitamente... Nenhuma delas usou DDD, TDD (algumas nem OO) ou qualquer formalismo maior do que um simples bom senso e cuidado na hora de construir. 

Às vezes eu tenho a impressão que o arquitetos tendem a complicar demais as coisas, e colocar restrições que não necessariamente são necessárias. Talvez neste sentido o conceito de "ultra-senior" faça mesmo mais sentido. Acho que o nosso principal objetivo é entregar algo de boa qualidade a baixo custo, afinal nosso propósito é fazer sistemas. Sempre vendemos os conceitos "da moda" como se fossem imprescindíveis para a "escalabilidade" ou "manutenabilidade" da aplicação, só que se pararmos pra analisar, a maior parte destes conceitos não exisita a 1 ou 2 anos atras.... 

No nosso caso, nós temos times agile bem pequenos (até 4 pessoas), pra sistemas de pequeno ou médio porte (<2000h). Neste sentido, acho que só faz sentido trabalhar com "ultra-seniores", faz sentido? Ou você acha possivel colocar um junior em um grupo agile de alta produtividade?

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA

Arquiteto Perlink (www.perlink.com.br) 

2009/8/1 Giovanni Bassi <gig...@giggio.net>

[Alexandre Valente]

Oi Luiz Carlos,

Exatamente o meu ponto. Ou seja, não faz sentido usar juniores, já que a chance de se ter algo com problemas ou retrabalho é muito alta. Eu sinceramente não consigo ver funcionar um ambiente como o que vc citou abaixo,  de "monkey coders". O trabalho de review e recodificação deve ser imenso, provavelmente é mais simples fazer logo com menos pessoas "seniores" do que tentar fazer primeiro com juniores.

O único problema em se ter somente seniores (ou "ultra-seniores", como citei no email anterior) é que eles são muito raros. Se forem encontrados, com certeza vale a pena te-los, já que a diferença de produtividade eu acho que mais do que justifica a diferença de valor hora. Acho que a falta de pessoal com este perfil é a única justificativa para se contratar pessoal mais junior.

Agora mesmo no caso de se ter que contratar pessoal mais junior, o que talvez seja possível é montar um esquema de mestre/aprendiz. Ou seja, permitir que os seniores escolham alguém com potencial e se encarreguem de fazer o treinamento individual (e aí até usando o aprendiz como mão de obra de apoio, já que vai haver uma supervião contínua). Talvez este modelo permita, com o tempo, aumentar o número de ultra-seniores na empresa. O que vc acha?

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA

Arquiteto Perlink (www.perlink.com.br) 

2009/8/3 Luiz Carlos Faria <luizcar...@gmail.com>

[rodrigoy]

Olá a todos! Em 2007 escreví na MundoJava um artigo juntamente com
Scott Ambler e Jon Kern sobre o papel do arquiteto. Uma prévia do
artigo está aqui:

http://blog.aspercom.com.br/2007/09/20/opapeldoarquiteto/

Na minha visão, equipes altamente produtivas/ágeis não necessitam de
arquitetos em hipótese alguma. Eu atuei como arquiteto em diversos
projetos, e como tal, realmente gosto quando o papel do arquiteto
migra entre todos os envolvidos da equipe, não importando a
experiência ou qualidades pessoais. Liderança técnica é algo que
emerge dentro da equipe. Não pode ser delegado.

Abraços!

On 3 ago, 02:25, "Luiz Carlos Faria" <luizcarlosfa...@gmail.com>
wrote:

> 2009/8/1 Alexandre Valente <alexandre.g.vale...@gmail.com>

> Arquiteto Perlink ( <http://www.perlink.com.br/>www.perlink.com.br)

[Diogo Miranda]

Olá Pessoal,

 

gostaria de aproveirtar essa discurssão para compreender melhor o mundo de projetos de sistemas. Recentemente, de um ano e meio para cá decidi deixar de atuar na área

de geoprocessamento no qual, atuei durante dez anos  e decidi mudar para a área de projetos de sistemas. Então posso me considerar um Jr. na área! E gostaria daqui a

uns cinco anos me tornar um arquiteto de sistemas. Gostaria de saber o que preciso para ser esse profissional no mercado?

 

Desde já fico grato pela força

 

Diogo A. Miranda

Desenvolvedor .NET

(11) 6325-6484

 

2009/8/3 Alexandre Valente <alexandre...@gmail.com>

--
Diogo A. Miranda
Desenvolvedor GIS
(11) 6325-6484

[Alex Takitani Pires]

Alexandre, o Arquiteto e o Analista Senior, como disse o Giovanni são bichos diferentes.

O Arquiteto tem domínio em áreas de conhecimento muitas vezes desnecessárias para o Analista, ex.: Redes, sistemas operacionais, diversos SGBDs, application server etc.

O arquiteto é um especialista, portanto, caro.

Usar um arquiteto para codificar, é como usar um engenheiro civil para levantar parede.

2009/8/3 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Oi Alex,

Discordo um pouco desta visão. Esta comparação com outras engenharias não procede muito na minha opinião, e é um dos erros que o pessoal de PMP também faz. A nossa área é muito diferente. Um arquiteto (ou melhor, um ultra-senior, pois como o Giovanni falou, um arquiteto é muito teórico enquanto que um ultra-senior sabe tanto quanto, porém gosta de programar tudo) é capaz de fazer muito mais do que um engenheiro civil em construção.

Lembre-se que um ultra-senior é capaz de criar mecanismos para fazer com que tarefas repetitivas ou "maçantes" possam ser automatizadas. Por exemplo, se tenho que gerar 20 telas de CRUD, ao invés de fazer a mesma coisa 20 vezes, um ultra-senior pode usar um gerador de código ou criar uma classe abstrata e reusar quase 100% do código. É como se o engenheiro-civil pudesse parar, gastar 1 ou 2h e criar um "gerador de paredes" que o permitisse criar todas as paredes, com mais qualidade que os pedreiros, com um clique!  :-).

Acho que isto é o que é diferente em desenvolvimento das outras engenharias. O que fazemos é muito maleável, temos muitas opções. E temos que ter criatividade para usar isto (esta semana mesmo tivemos uma conversa sobre isto em um dos eventos desta lista). E a experiência é fundamental para saber o que usar ou quando, para se evitar que trabalhos "maçantes" ou repetitivos existam. Um junior nunca conseguiria fazer isto, ele iria fazer 20, 50 telas iguais.... 

Assim, não vale sempre pagar a diferença do valor hora, mesmo para trabalhos simples?

Abs

Alexandre Valente

MCSE+I, MCSD, MDCBA

Arquiteto Perlink (www.perlink.com.br) 

2009/8/3 Alex Takitani Pires <atp...@gmail.com>

[Alex Takitani Pires]

Não, o arquiteto no seu exemplo cria o "criador de telas", e os juniores/plenos usam o criador.

[Alexandre Valente]

Oi Alex,

Porque? O arquiiteto vai sempre fazer mais rápido, vai identificar outros eventuais pontos de otimização... Por que não só usar arquitetos?

abs

[Alex Takitani Pires]

Pelo mesmo motivo que vc não usa um Engenheiro no lugar de um pedreiro, ele sabe fazer o trabalho, mas custa caro demais.

Pq não montar um time de futebol com 11 Kakas?

[Weverton Gomes]

Galera,

Estou gostando da discussão e vou deixar minha opinião também.

Com relação à questão dos arquitetos codificarem, não vejo problema, apesar de achar que eles deveriam ficar focados no backend do desenvolvimento, ou seja, na estrutura que possa deixar o trabalho da equipe está desenvolvendo a solução final para o cliente o mais rápido possível, de forma que eles não precisem "perder tempo" com problemas relacionados à tecnologia e possam se concentrar no negócio. Até mesmo pq, quando se colocar um arquiteto pra codificar, se ele não conhecer as regras daquele sistema, ele vai levar um tempo pra se ambientar e, como vcs sabem, tempo é dinheiro, o que no caso do arquiteto, significa um gasto maior.

Com relação à desenvolvedores junior, acho que existem muitos que tem capacidade de entrar num projeto e, usando um esquema de Peer Programming, conseguirem se desenvolver rapidamente. É claro que depende do Jr, pois com o nível de alguns cursos universitários hoje, os caras nem chegam a Jr, mas isso é assunto pra outra discussão :D. E também tem o ponto de que, se os Jr. não tiverem como evoluir, ou seja, não tiverem oportunidades, daqui a algum tempo não teremos sêniors.

Abraços a todos,

--
Weverton Gomes de Morais
Tecnólogo em Redes de Comunicação
Desenvolvedor Delphi
Entusiasta Ruby/Rails
"Todos juntos somos fortes"

[Alexandre Valente]

Mas então, o que estou querendo dizer é que a comparação não é a mesma. Na engenharia, o pedreiro e o engenheiro civil vão fazer a parede no mesmo tempo! No software não! A experiência e a criatividade fazem com que um arquiteto seja muito mais eficiente! Ou vc não acha que se tivese que fazer 20 telas de CRUD,um arquiteto não faria as 20, com mais qualidade, em 1/3 ou menos do tempo de um junior? 

Abs

[Rodrigo Kumpera]

Tudo bem Rodrigo,

Minha experiência é a mesma. Um time de pessoas bem capacitadas, altamente motivadas e pagas acima
da média é muito mais produtivo e barato que um pelotão de gente 9-18. Com a vantagem que se o time for
exceptionalmente motivado, os salários não precisam nem ser acima da média.

Arquiteto é um papel que deveria ser puramente meritocrático e efêmero, de preferencia transiente dentro do time
entre áreas dos conhecimento.

2009/8/3 rodrigoy <rodr...@gmail.com>

[Alex Takitani Pires]

Pode até fazer, mas vai custar mais caro do que deveria.

Com uma arquitetura bem definida, metodologia e as ferramentas certas vc controla a qualidade de um projeto. Esse é o trabalho do arquiteto definir, projetar, planejar. Ele pode executar, nada impede a questão é $.

2009/8/3 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Oi Alexandre,

É uma questão de perfil. O arquiteto deve gostar de codificar, mas não só isso.
O arquiteto não é só um teórico. É o que eu chamo de "arquiteto astronauta", aquele que inventa as coisas lá do alto da sua torre de marfim, e manda os "pobres coitados" desenvolvedores codificarem. Acho que o arquiteto deve codificar sim, mas somente o suficiente para ajudar a equipe a evoluir nos conceitos da aplicação. Tão importante quanto a codificação é a revisão de código junto aos desenvolvedores, por exemplo.
O Yoshima e o Kumpera defenderam o arquiteto como posição no projeto, não como cargo. Na verdade, sugeriram que a posição pode até mesmo ser compartilhada pelo time. Acho que é possível, desde que o time tenha pessoas capazes de exercer essa posição. Nesse caso, você sequer precisa de alguém com o título de arquiteto, que muitas vezes deixa o profissional com o ego inchado demais...
Não acho que existam ultra-seniores. Existem seniores, e existem plenos. Na verdade, o que temos hoje no mercado são profissionais com o cargo de seniores, e que não são seniores de verdade. Três niveis devem ser suficientes. Acima disso, talvez precisemos buscar outros nomes, e não "desenvolvedor". Na verdade essa é uma questão dificil, definir níveis dentro de uma equipe.

Quanto às aplicações feitas em Clipper e que duram até hoje, sim, conheço algumas. A questão é que desenvolvimento de software 15 anos atrás era algo absolutamente diferente do que é hoje (o de 5 anos atrás já é diferente). O perfil do desenvolvedor médio era muito diferente, os requisitos para longevidade da aplicação também eram outros. A aplicação era procedural, tinha vários problemas, e tinha uma manutenção cara. Só que isso não era problema. Hoje é. Hoje a concorrência é maior, a exigência e a expectativa sobre os sistemas é muito maior. Estamos neste exato momento na chamada terceira camada computacional, a primeira era onde a computação era feita só na sua máquina, em aplicações como o Word de 1995. A segunda é aquela que ficava, além da máquina, também na rede interna da empresa, como o Sharepoint (por volta de 2000). E a terceira é quando tudo está distribuído, parte na máquina, parte na rede, parte na nuvem, como no Sharepoint Online. Se você tentar atender esse tipo de exigência sem se preocupar com a arquitetura você vai ser absolutamente ineficiente, e o mercado vai te engolir. Se você for uma empresa seu produto não vai ter competitividade, se você for o gerente do departamento que toca o desenvolvimento desse jeito, você vai perder o emprego eventualmente devido à pouca entrega, baixo ROI.
Preocupação com arquitetura hoje é questão de sobrevivência. Esse é o motivo que leva a maioria dos meus clientes a demandarem meus serviços.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/8/3 Alexandre Valente <alexandre...@gmail.com>

[Rodrigo Vieira]

Arquiteto é um cargo.

Então se vc usar só arquitetos pra desenvolver todo o sistema, eles
estarão atuando como desenvolvedores sênior a maior parte do tempo,
não como arquitetos. Vc não vai ter 5 arquitetos, vai ter 5 caras
trabalhando um pouco como arquitetos, e a maior parte do tempo como
desenvolvedores-sênior, e a qualidade final do projeto vai ser
basicamente a mesma que vc teria se tivesse usado 1 arquiteto e 4
desenvolvedores sênior, afinal arquiteto não faz milagre nem escreve
código melhor do que um bom desenvolvedor sênior, ele simplesmente tb
se especializou em outros aspectos _complementares_ em TI.

[Alexandre Valente]

Será? Se ele conseguir fazer em metade do tempo (e eu acho que ele faz até mais rápido!), então ele é mais barato para empresa! Afinal um arquiteto não custa o dobro de um junior (um junior está na faixa de 30, eu não vi nenhum arquiteto pedindo mais de 60, nem em SP! :-)). 

Assim, de uma perspectiva economica, usar só arquitetos é muito melhor  certo? :-)

[Rodrigo Kumpera]

2009/8/3 Giovanni Bassi <gig...@giggio.net>

Oi Alexandre,

É uma questão de perfil. O arquiteto deve gostar de codificar, mas não só isso.
O arquiteto não é só um teórico. É o que eu chamo de "arquiteto astronauta", aquele que inventa as coisas lá do alto da sua torre de marfim, e manda os "pobres coitados" desenvolvedores codificarem. Acho que o arquiteto deve codificar sim, mas somente o suficiente para ajudar a equipe a evoluir nos conceitos da aplicação. Tão importante quanto a codificação é a revisão de código junto aos desenvolvedores, por exemplo.
O Yoshima e o Kumpera defenderam o arquiteto como posição no projeto, não como cargo. Na verdade, sugeriram que a posição pode até mesmo ser compartilhada pelo time. Acho que é possível, desde que o time tenha pessoas capazes de exercer essa posição. Nesse caso, você sequer precisa de alguém com o título de arquiteto, que muitas vezes deixa o profissional com o ego inchado demais...
Não acho que existam ultra-seniores. Existem seniores, e existem plenos. Na verdade, o que temos hoje no mercado são profissionais com o cargo de seniores, e que não são seniores de verdade. Três niveis devem ser suficientes. Acima disso, talvez precisemos buscar outros nomes, e não "desenvolvedor". Na verdade essa é uma questão dificil, definir níveis dentro de uma equipe.

Várias empresas brasileiras já possuem o cargo de especialista, que é um cargo técnico do mesmo nível de um gerente. A maioria das grandes empresas fora também possuem outros cargos, como distinguished engineer, que são cargos de nível de diretoria.

Esses cargos podem não fazer muito sentido para um VAR, mas faz todo sentido para um ISV ou IHV.

[Alexandre Valente]

Oi Giovanni,

Sim, é isto que eu tinha entendido também. Acho que os arquitetos que ficam na torre de marfim são péssimos para a indústria, pois pregam conceitos teóricos que nem ele mesmo conseguiria colocar em prática.

Mas aí, voltando à questão. Se um arquiteto faz melhor e mais rápido, porque ter juniores? Como vc falou, ter juniores significa ter um code review muito mais forte, ter treinamento, ter todo um processo que no final fica mais caro do que fazer do que se o próprio arquiteto fizesse tudo!

A impressão que eu tenho é que estamos tentando criar uma maneira de trabalho destinada a tentar ensinar juniores a usar conceitos que eles não estão preparados para usar. Por isto que os projetos ficam tão caros. Isto está relacionado ao próprio descrédito do PMI (como citado na outra thread), já que em projetos grandes isto é comum, de se ter equipes mistas com um arquiteto tentando fazer o resto do pessoal trabalhar da maneira certa. 

Aparentemente ter equipes ágeis pequenas, só de arquitetos (ou seniores reais), com conhecimentos nas várias áreas de TI, seja um caminho economicamente muito mais viável para se desenvolver software com sucesso, não?

abs

Alexandre

2009/8/3 Giovanni Bassi <gig...@giggio.net>

[Leo D]

Olá Alexandre,

Talvez o que você esteja chamando de arquiteto seja na verdade um
desenvolvedor sênior. Da mesma forma que o Rodrigo, eu não consigo ver
uma equipe com 5 arquitetos, pois tenho a mesma visão de que o arquiteto
é um cargo, não um nível hierárquico ou de conhecimento que está acima
do desenvolvedor sênior. Os níveis de conhecimento técnico de um
desenvolvedor sênior e um arquiteto são muito semelhantes. Talvez o
arquiteto abra um pouco mais seu o foco, dê um zoom out na sopa de
letrinhas de tecnologias que existem, mas em matéria de escrever código,
são muito semelhantes.

Onde eu trabalhava eram de 4 a 6 desenvolvedores. Todos com bom
experiência (e a palavra "sênior" no cargo). Não existia arquiteto,
apenas gerente funcional (o que carimbava férias, contratava, demitia, e
dava a cara pra bater para o diretor geral). Mas tecnicamente, todos
revezavam nas decisões arquiteturais, dependendo do envolvimento no
projeto. Muita coisa era discutida em reuniões técnicas, mas na prática
a gente tinha propriedade sobre alguns projetos, tinha um envolvimento
maior com os stakeholders de determinado projeto, então quem tinha essa
propriedade tomava as decisões arquiteturais, e os outros
desenvolvedores trabalhavam com aquilo em comum acordo.

[]s

Leo D

[Rodrigo Kumpera]

Eu acho que o maior defeito do cargo de arquiteto é que ele infantiliza os demais
desenvolvedores. Assim como gerentes que ficam "chefando" o tempo todo e
pilotando o time do MS Project.

2009/8/3 Leo D <l...@codigofluente.com.br>

[Leo D]

Talvez seja esse o maior defeito. Ou aquele do Arquiteto Astronauta, já
apontado pelo Giovanni e descrito no excelente artigo do Joel Spolsky (
http://www.joelonsoftware.com/articles/fog0000000018.html ), o arquiteto
que não sabe a hora de parar de abstrair, que "sobe" tanto nas
abstrações que perde o oxigênio, que define arquiteturas cheias de
caminhos indiretos e complexidades desnecessárias, depois delega para
desenvolvedores de menor hierarquia a implementação destes sonhos furados.

Mas tenho certeza que neste grupo não temos arquitetos dessa natureza ;-)

[]s
Leo D

[Luiz Carlos Faria]

Acredito nesse modelo de mentoring por incentivar os profissionais mais novos, mantendo um ciclo de crescimento.

Valorizar prata da casa é um diferencial para o mercado e o resultado é muito bom.

[Luiz Carlos Faria]

Alexandre,

 

O operacional obriga imersão assim o profissional fica submisso ao projeto onde está alocado não possibilitando render da melhor forma para a empresa.

A transição e acompanhamento de diversos projetos faz-se necessária para que a empresa consiga absorver o melhor do profissional, pois temos meios de identificar aspectos para unificação e equalização de conhecimento, na medida que conhecemos mais de um cenário.

Depende de cada empresa, mas lembre-se: toda escolha, uma renúncia.

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Alexandre Valente
Enviada em: segunda-feira, 3 de agosto de 2009 10:50
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto?

 

Oi Alex,

[Luiz Carlos Faria]

Na verdade você não vai encontrar tanta diferença em tarefas mais simples, você vai encontrar uma diferença relevante na medida que precisar de algo mais rebuscado.

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Alexandre Valente
Enviada em: segunda-feira, 3 de agosto de 2009 11:00
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto?

 

Mas então, o que estou querendo dizer é que a comparação não é a mesma. Na engenharia, o pedreiro e o engenheiro civil vão fazer a parede no mesmo tempo! No software não! A experiência e a criatividade fazem com que um arquiteto seja muito mais eficiente! Ou vc não acha que se tivese que fazer 20 telas de CRUD,um arquiteto não faria as 20, com mais qualidade, em 1/3 ou menos do tempo de um junior? 

[Fernando Bichara]

Oi Pessoal,

 

Na minha opinião não é o que “diferencia um arquiteto” e sim a responsabilidade do Arquiteto. Há uma subjetividade muito grande para determinar o que é o Arquiteto. Essa thread é uma conseqüência disso. J

 

Na prática a gente nunca consegue ter só arquiteto ou sênior em equipes. E lembrem-se, não existe uma fornada que diz: este nasceu arquiteto e esse não... J Temos que formar. O que estamos buscando são perfis profissionais, autoditadas, com boa formação, ...

 

O Alexandre citou, já que o arquiteto é mais rápido e produz melhor pq não usá-lo para toda construção? Fato, se financeiramente for melhor, OK. Mas na prática o arquiteto é mais rápido até um determinado ponto, existe trabalho repetitivo. Ah, e pq o trabalho repetitivo não é automatizado? Na prática não é assim que funciona. Para automatizar o custo aumenta absurdamente e não se paga em um projeto (geralmente!).

 

O arquiteto é mais que um braço, é um cabeça que precisa tomar decisões baseadas em uma série de variáveis temporais. Uma decisão pode significar redução em 10x, 20x o tempo de desenvolvimento e uma boa decisão hj pode ser uma péssima amanhã.

 

Acho que foi o Alexandre também que citou  que o arquiteto pode fazer uma ferramenta para automatizar e fazer mais rápido, legal! E as outras 20 funcionalidades iguais? Pq não ser atacada por um Jr?? Custo muito mais baixo!!! Vejo que na prática existe um ganho absurdo de qualidade, produtividade em coisas que são feitas na “primeira vez” pelo arquiteto. Depois disso, o tempo apesar de mais rápido não compensa $$$$$.

 

Essa thread se encaixa para qq perfil L O que é um Jr para vcs? O que é um Pl para vcs? Ainda é muito subjetivo.....

 

Abs,

Fernando Bichara

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Alexandre Valente
Enviada em: segunda-feira, 3 de agosto de 2009 11:50
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto?

 

Oi Giovanni,

[Marcel Castilho]

Alexandre,

 

Na minha opinião, o melhor é contratar o desenvolvedor mais sênior que você encontrar no mercado, o que hoje em dia não está assim tão fácil. Se o cara se classifica como "Arquiteto" e não quer por a mão na massa, como você sugere, pelo que eu entendi o perfil já não é o que você está procurando.

 

Não sei quão complexa é a sua aplicação mas um desenvolvedor realmente bom (melhor se forem vários deles) provavelmente terá conhecimentos suficientes para atender as suas necessidades de arquitetura.

Eu concordo, de certa forma, com um post que eu li neste fim-de-semana (http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/07/28/succeeding-with-mediocrity.aspx): o que não dá é desenvolver com programadores ruins (code monkeys), ou alguém provisório só para quebrar um galho. Se você quer contratar um júnior, você tem que ter em mente que ele não está pronto, talvez nunca estará. Ao contrário de um senior que na entrevista você já consegue verificar se o cara tem o conhecimento desejado. Parafraseando um pouco o autor do artigo: se o time não tem condições de atingir certo nível técnico, provavelmente é uma boa idéia começar a baixar as expectativas agora.

 

Abraço,

 

Marcel

[Giovanni Bassi]

Oi Rodrigo,

Pois é, eu acredito muito nesse modelo, que é o da carreira em V.
Já vi algumas empresas adotando ele com sucesso. É muito bom ver que o profissional não é forçado a sair da área técnica e virar gerente só porque quer ganhar mais.
Já vi nomes como "fellow", e na industria farmacêutica vi "scientist". E tinha vários níveis dentro de fellow e scientist, por exemplo.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/8/3 Rodrigo Kumpera <kum...@gmail.com>

[Giovanni Bassi]

Alexandre,

Juniores não custam 30/h, custam uns 20/h ou até menos.
Já vi arquiteto pedindo 80, 90, 100... e até mais. Um arquiteto pode custar mais que 5 jrs...
Depende do perfil do profissional. Varia muito.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/8/3 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Mas isso é uma questão de perfil, não é?
Eu me vigio o tempo todo pra não fazer isso. Quando fizeram isso comigo foi horrível, então tomo muito cuidado para não fazer com ninguém.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/8/3 Rodrigo Kumpera <kum...@gmail.com>

[Giovanni Bassi]

É mesmo um grande diferencial. Num mercado mercenário como esse, não adianta só pagar bem. Tem que valorizar o profissional.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

[Rodrigo Kumpera]

Eu acho que é mais uma questão estrutural e cultural da empresa que do perfil individual de cada um.
Mas também acho que é uma coisa que exige treino se você está na posição maior.

2009/8/3 Giovanni Bassi <gig...@giggio.net>

[Giovanni Bassi]

Com certeza se a estrutura incentivar, o risco é muito grande. Se o profissional já tem um ego expansivo... fica complicado. Já vi casos em que o título influenciou muito na maneira da pessoa se relacionar...

[edmilson hora]

Pessoal,  Minha contribuição.... uma equipe composta apenas por Desenvolvedores Juniors não consegue fazer  algo com real qualidade  para mim isso é obvio, falta maturidade experiência, etc.  Uma equipe  composta só de "ultra seniors" no meu ver deve ser  como um time  com vários "Ronaldo fenomeno" provavelmente terá seus problemas  pois cada um vai querer mostar que é melhor que o outro e eventualmente atritos podem ocorrer e até comprometer a entrega. Os 3 níveis de desenvolvedor deveriam ser bem mescaldos  em uma boa equipe, onde os mais Seniors  ajudariam a conduzir o desenvolvimento desenvolvendo as partes mais criticas do sistema, e os juniors  cuidando das rotinas mais simples e ao mesmo tempo aprendendo com quem tem mais experiência.  O problema é que quando os desenvolvedores atingem o nivel de "Senioridade" não querem mais desenvolver,  muitos querem ser Arquitetos, Engenheiros, Gerentes de Projeto, querem  cuidar do MS-Project e informar aos desenvolvedores menos experientes  que o cronograma esta atrasado e que  os Diagramas  feitos  no MS-Visio (de forma parcial)  tem que virar  um sistema  completo do banco de dados até a interface de usuário, com tudo que tem direto. []´s Edmilson   --- Em seg, 3/8/09, Marcel Castilho <marcel....@gmail.com> escreveu:

De: Marcel Castilho <marcel....@gmail.com> Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto?

---

Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes

[Cássio Rogério Eskelsen]

Concordo quase com tudo, apenas ressalvo que nem todos seniors querem deixar de programar. Conheço muitos que gostariam de morrer codificando, mas são obrigados a mudar de cargo para conseguir um aumento de salário.

at

Cássio Rogério Eskelsen
 

2009/8/3 edmilson hora <edmils...@yahoo.com.br>

[Alexandre Valente]

Oi pessoal,

Muito obrigado por todas as respostas. Vou tentar fazer uma compilação do que foi escrito:

- Arquitetos apresentam o risco de se "afastarem" da realidade (arquiteto astronauta), o que é nocivo. Foi levantada a idéia de não se ter a figura do arquiteto, e fazer este papel estar disseminado pelos mais experientes das equipes.

Confesso que esta idéia me agradou muito. Como foi citado em um dos blogs, eu também acho que a figura do arquiteto na empresa faz com que os outros desenvolvedores se acomodem (no discurso "arquitetura não é comigo, eu faço o que alguem define"). Assim, pra mim faz muito sentido não se ter mais este papel explícito e fazer com que isto seja uma responsabilidade implicita no desenvolvimento.

- O consenso é que ter uma equipe só de arquitetos ou seniores não é produtivo, seja porque uma equipe deste tipo teria muitas "estrelas", dificultando relacionamento, seja porque existem tarefas que um junior faria na mesma velocidade (e portanto seria mais barato) ou seja porque os seniores e arquitetos se recusam a fazer certos tipos de código.

Nesta eu confesso que ainda não estou convencido. Acho que este tipo de estrelismo tão nocivo quanto o arquiteto astronauta. E acho também impressionante este elitismo em que alguns não queiram codificar certas tipos de tarefas. Afinal, nosso negócio é entregar software pronto, não só a infra ou só a interface super legal. Fazer crud, objetos básicos e etc. de maneira rápida e com qualidade é tão importante quanto o resto. E sei, por experiência, que quando seniores querem fazer algo, eles normalmente fazem mais rápido (eu mesmo não consigo lembrar de exemplos em que eu teria a mesma velocidade de um junior... até pra debugar a experiencia conta!). Assim, se tiramos esta questão do estrelismo e elitismo, ainda acho que uma equipe só de seniores é muito mais economicamente eficiente do que uma equipe mista.

- Finalmente, foi levantado que os juniores são importantes para formar de novos seniores (que são poucos) e no sentido da motivação / valorização dos professionais.

Concordo. Porém o custo de se treinar pessoal não é desprezível, e isto deve ser considerado quando se escolhe incluir juniores em projetos com esta finalidade. Talvez o modelo de mestre/aprendiz seja uma alternativa a ser considerada para este modelo. Definitivamente acho que um conjunto de juniores sob gestão de um senior não seja economicamente viável.

Isto? Deixei passar algo?

Abs

Alexandre Valente

MCSE+I, MCSD, MDCBA

Arquiteto Perlink (www.perlink.com.br) 

2009/8/3 Cássio Rogério Eskelsen <eske...@gmail.com>

[Cássio Rogério Eskelsen]

Alexandre,

Não sei quanto tempo você é desenvolvedor, mas se for a pouco tempo, vai perceber que a medida que você madurece fica com menos paciência de fazer coisas que qualquer junior faz (ou mesmo uma ferramenta automatizada). Querer manter um Senior para fazer CRUD vai resultar em no mínimo 2 coisas: um profissional desmotivado e um custo elevado.

Pelo que percebi no link da sua assinatura, sua empresa é Fábrica. Concordo que em uma fábrica a visão da necessidade de seniors não é tão clara pois em tese uma fábrica recebe quase tudo pronto (em termos de análise), deve seguir a arquitetura do cliente e não precisa se preocupar com manutenção de produto.

No nosso caso (sou Líder de Desenvolvimento na Benner Logística) temos muito clara a divisão de papéis: programadores seniors, juniors e arquiteto.  Para o dia a dia, para resolver coisas simples como relatórios, telas CRUD, pequenos ajustes, nada melhor que um junior. Agora, quando o negócio começa a pegar para o lado de integrar com uma balança, catraca, coletor de dados, NF-e, CT-e, SPED, integração com ERPs, entram em cena os seniors. 

Na boa, por mais democrático, lindo e maravilhoso que possa ser, não vou botar um senior para fazer relatório ou um cadastro de cidade. Sei que vou ter um profissional desmotivado que na primeira oportunidade (e oportunidades aqui em Blumenau não são raras) vai pular fora do barco.

Isso acontece em qualquer área. Não tente pedir, por exemplo, para um Mestre de Obras assentar tijolo.

Cássio Rogério Eskelsen

[Rodrigo Morais]

Pessoal,

 

Eu vejo o arquiteto mais como um papel do que como um cargo. Então dentro de uma mesma equipe em projetos diferentes podemos ter pessoas diferentes atuando nesse papel conforme a sua experiência com o negócio e a tecnologia do projeto. Acho impossível um arquiteto cobrir 100% de conhecimento dentro de empresas que trabalham com negócios diferentes. As vezes a empresa tem um projeto que utiliza uma tecnologia diferente da maioria dos projetos e um outro desenvolvedor tem maior conhecimento do que o arquiteto atual e nesse caso ele seria o mais indicado a ser arquiteto nesse projeto.

 

Sobre utilizar juniors, eu sou a favor de equipes sejam montadas com as necessidades do projeto. Quando fazemos o levantamento de requisitos de um projeto identificamos atividades criticas e de risco e outras simples. As atividades simples devem, na minha opinião, ser desenvolvidas por desenvolvedores menos experientes e com custo mais baixo sempre guiados pelo arquiteto, projetista e etc. Acho que quanto mais estavel é a arquitetura do sistema mais fácil é de utilizarmos desenvolvedores menos experientes. Além disso, utilizar juniors é uma questão politica dentro das empresas e não só técnica.

 

Valeu,

 

Rodrigo Morais

--
Rodrigo Morais

[Marcos Dell Antonio]

Alexandre,

- O consenso é que ter uma equipe só de arquitetos ou seniores não é produtivo, seja porque uma equipe deste tipo teria muitas "estrelas", dificultando relacionamento, seja porque existem tarefas que um junior faria na mesma velocidade (e portanto seria mais barato) ou seja porque os seniores e arquitetos se recusam a fazer certos tipos de código.

Isso é fato quando estivermos pensando em um projeto específico. Porém na organização como um todo, não vejo problema algum em existir uma equipe só de arquitetos. Já passei por isso na empresa antiga (era um deles, apesar de ter outra nomenclatura) e hoje, em outra empresa, trabalho com tecnologia desenvolvida pela equipe de arquitetura. Não existem "estrelas" e muito menos dificuldade no relacionamento. E o mais interessante, talvez até injusto: recebem o mesmo $ que os outros desenvolvedores.

--
Marcos Dell' Antonio
http://www.marcosdellantonio.net

[edmilson hora]

Alexandre,     Do modo como vc colocou o primeiro trecho deste post  fica parecendo que uma equipe de desenvolvimento pode ser  composta de 3 programadores Júrior sem nenhum acompanhamento de alguém mais experiente, é claro que  se vc colocar só gente sem expediência  vai sair m@$%!a  ,  agora,  contratar  4 caras a R$ 45,00/hora  para construir  um sistema  onde normalmente  mais de 50% do trabalho é CRUD é desperdicar recursos concorda?  Um  "junior  bom"  não um "porra loca" que so sabe usar wizard que  recebe  em média R$ 25,00/hora  mesclar  uma equipe  com 2 Seniors e 2 Juniors  ou 1 Senior 1 Pleno  e 2 Juniors,  vc tem uma economia consideravel,  sem falar que a qualidade será a mesma, pois o projeto  será "tocado"  pelos Seniors  os juniors  trabalharão sob  orientação  e supervisão do que estão fazendo, e ao mesmo tempo  estarão se formando  para serem Plenos  e Seniors.      Eu acredito que  estamos,  neste tópico, confundindo o papel  do Arquiteto  com a função do desenvolvedor  Senior.   O Giovanni  já falou  no inicio  da discussão  "Arquiteto  é outro bicho", não é desenvolvedore Senior.   ===========================================================

"Oi Luiz Carlos, Exatamente o meu ponto. Ou seja, não faz sentido usar juniores, já que a chance de se ter algo com problemas ou retrabalho é muito alta. "

==========================================================   []´s   Edmilson --- Em seg, 3/8/09, Alexandre Valente <alexandre...@gmail.com> escreveu:

De: Alexandre Valente <alexandre...@gmail.com> Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto? Para: dotnetar...@googlegroups.com

Data: Segunda-feira, 3 de Agosto de 2009, 10:09

Oi Luiz Carlos, Exatamente o meu ponto. Ou seja, não faz sentido usar juniores, já que a chance de se ter algo com problemas ou retrabalho é muito alta. Eu sinceramente não consigo ver funcionar um ambiente como o que vc citou abaixo,  de "monkey coders". O trabalho de review e recodificação deve ser imenso, provavelmente é mais simples fazer logo com menos pessoas "seniores" do que tentar fazer primeiro com juniores. O único problema em se ter somente seniores (ou "ultra-seniores", como citei no email anterior) é que eles são muito raros. Se forem encontrados, com certeza vale a pena te-los, já que a diferença de produtividade eu acho que mais do que justifica a diferença de valor hora. Acho que a falta de pessoal com este perfil é a única justificativa para se contratar pessoal mais junior. Agora mesmo no caso de se ter que contratar pessoal mais junior, o que talvez seja possível é montar um esquema de mestre/aprendiz. Ou seja, permitir que os seniores escolham alguém com potencial e se encarreguem de fazer o treinamento individual (e aí até usando o aprendiz como mão de obra de apoio, já que vai haver uma supervião contínua). Talvez este modelo permita, com o tempo, aumentar o número de ultra-seniores na empresa. O que vc acha?

abs Alexandre Valente MCSE+I, MCSD, MDCBA Arquiteto Perlink (www.perlink.com.br)

2009/8/3 Luiz Carlos Faria <luizcar...@gmail.com>

Boa noite Alexandre,   A maturidade e experiência contam muito, ainda mais se tratando de algo tão pouco palpável.   Quanto melhor o Junior, mais “pilhado” ele é, assim, mais erros ele irá cometer por não medir os riscos do que está fazendo.   A experiência é fundamental para qualquer projeto. Não adianta perder tempo com soluções mirabolantes que no final das contas só aumentarão o custo. É preciso ter tato(maturidade) para saber onde deve e onde não deve aplicar esforços. Profissionais juniors não tem tanto conhecimento da plataforma, conhecem muito overview. Na prática, o overview não serve de muita coisa. Profissionais com maior senioridade rendem mais porque pensam e vêem o todo. Até quanto a política dentro das empresas. É preciso saber escutar, e falar na hora certa e com a pessoa certa. Energia deve ser gasta com eficiência senão... nada acontece.   Uma das grandes diferenças, e esse é o ponto que mais prezo é a capacidade de administrar restrições. Em todos os cenários possíveis e imagináveis temos diversas restrições e o que difere um profissional de outro é sua capacidade de se adaptar às restrições, sejam orçamentárias, técnicas, estratégicas. Esses são os diversos aspectos que diferenciam os profissionais mais experientes dos novatos, mas também, se não houvesse diferença estaríamos fritos!!!     MonkeyCoders   Duas empresas por onde passei tinham a idéia de ter macacos bem treinados para a construção de sistemas. Esse modelo funciona, mas precisa ter um ecossistema muito homogêneo para alcançar este objetivo, coisa que até então não vi. Neste caso levo em conta infra-estrutura, modelos de aplicações desenvolvidas, features suportadas. Ainda é preciso manter um time mais sênior para o desenvolvimento do que não adere ao que o time de MonkeyCoders produz. Existem diversos aspectos ruins nesse modelo, um deles é o turnover causado pelo pouco crescimento profissional. Outra característica interessante é o trabalho de arquitetura necessário para viabilizar este modelo e geralmente precede sua implantação. Um agravante nestes casos é a pouca capacidade evolutiva. Nestes cenários, a quantidade de arquitetos é drasticamente reduzida, mas acredite, é uma situação sazonal. Periodicamente você contratará ou formará o time que evoluirá seu framework de trabalho.

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Giovanni Bassi

Enviada em: sábado, 1 de agosto de 2009 15:23 Para: dotnetar...@googlegroups.com

Assunto: [dotnetarchitects] Re: O que diferencia um arquiteto?

Olá Alexandre,

[Alexandre Valente]

Oi Edmilson,

Não concordo, justamente a minha opinião é que 4 caras seniores (45) seriam o melhor time, para qualquer sistema! :-) - desde é claro que eles não tivessem as questões de "não querer ou não gostar de trabalhar com isto ou com aquilo". Nos ultimos meses, o meu time está mudando de uma filosofia orientada a projetos clássicos (PMP, com arquitetos e equipes mistas) para um desenvolvimento agile (Scrum) com equipes de 2 ou 3 desenvolvedores. E o interessante é que quanto mais senior a equipe, aparentemente melhores são os resultados (eu sei que isto é aparentemente óbvio, mas isto está tão expressivo que estamos considerando justamente fazer os extremos, ou seja somente muito-seniors - eu me referi a arquitetos porque seriam os mais seniores, mas o termo foi ruim, já que como foi colocado, muitos arquitetos não gostam de desenvolver tudo....). E mesmo para as coisas "simples" como CRUD, objetos de base, relatórios etc, o resultado com seniores tem sido muito melhor e mais rapido (e por fim, mais barato, mesmo com o valor hora superior).

A idéia do post foi justamente colher outras informações sobre a experiencia da galera sobre isto. Interessante que as respostas indicam que em geral o pessoal acha que equipes mistas são economicamente melhores. Mas nenhuma das razões colocadas me convenceu (aliás, pareceu-me que pouca gente tem experiencia em trabalhar só com seniores, a maior parte está integrada em equipes mistas mesmo), e na prática eu continuo não observando. Bom, vou continuar observando e coloco os resultados aqui.

Abs

Alexandre Valente

2009/8/5 edmilson hora <edmils...@yahoo.com.br>

[Daniel Moreira Yokoyama]

Ora, mas se foi apresentado aqui de que colocar um junior e um senior para codificarem CRUD, obtem-se o mesmo resultado com uma diferença enorme de valores, de que Seniores são usados para codificar peças mais complexas como serviços e que arquiteto é um papel exercido por um Senior que pode (e normalmente quer) continuar desenvolvendo alguma peça (mas espera fazer algo além do CRUD básico por que procura justificar o próprio valor que cobra devido sua vasta experiência). Não sei exatamente do que se pode discordar, no entanto você continua discordando.

O fato é que você já lançou a questão no grupo com uma opinião formada a respeito e parece muito mais disposto a convencer do que ser convencido. (Por favor, ignore qualquer impressão de ofensa aqui por que não é esta a intenção, mas eu sei como as palavras podem soar durante a leitura).

O que eu quero dizer é que as opiniões aqui são baseadas em fatos de experiência de profissionais... CRUD sempre vai ter aquele jeitão, então você sempre vai contratar um Júnior pq ele vai fazer igual e vai fazer com gosto. E não é porque o Senior ficou fresco... o Senior gosta de fazer por onde valer a hora que ele mesmo cobra... ele espera por fazer algo que lhe confira o nível de senioridade para o qual ele se candidatou na empresa e espera que a empresa saiba usar bem o recurso que ele mesmo oferece. Já saí de uma empresa por achar que tinha mais o que fazer em qualquer outra. E saí justificando "Vocês perderiam menos dinheiro contratando um recém-formado ou até um estagiário para fazer o que estou fazendo".

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.blogspot.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/8/6 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Oi Daniel,

Desculpe se passei esta impressão... Apesar de eu ter minha opinião, de maneira nenhuma ela está formada. Nossa experiencia em agile é recente, e este assunto tem gerado polemica interna também. Meu objetivo foi exatamente este, colher outras impressões. E o post foi muito válido neste sentido, agradeço mais uma vez a todos.

Então, sobre esta questão de CRUD, foi falado que é o mesmo resultado. Mas eu já observei diferente. Esta semana mesmo, tivemos um pequeno sistema com umas 6 telas de CRUD que foi feito por um senior em prazo reduzidíssimo. E sistema novo envolve mais do que só "copiar e colar". Não tenho dúvidas que se este caso fosse tocado por um junior, não seria nem perto do tempo total levado. Pode ser que seja um caso específico, mas o ponto é que eu tenho visto cada vez mais exemplos como este. E não muitos exemplos onde um "exemplo" é feito por um senior e podemos colocar um junior pra só copiar. Mas isto é só a minha experiência. 

Tudo que foi colocado aqui indica que temos que ter ainda mais cuidado na composição de times, e vou tentar fazer algumas comparações com equipe mista para avaliar os dois casos, assim que possível. Eu só quis dizer que não houve nada absolutamente convincente e que o argumento de que cruds são feitos no mesmo tempo não me convenceu muito porque na prática eu tenho observado diferente. Mas vou continuar observando, com certeza! :-)

abs

2009/8/6 Daniel Moreira Yokoyama <moreira....@gmail.com>