Blog do Andre Fonseca

Não é algo que eu faça com certa freqüência mas acredito que a vaga seja boa e interessante para muitos que leêm o blog. A empresa é brasileira e tem como atividade principal um produto de portal. Essa ferramenta de portal é muito interessante e concorre em igualdade com outras existentes no mercado ( Vignette, Websphere Portal, Oracle, etc) .

Desenvolvedor Junior (Projeto)

Conhecimentos necessários:

• Estar formado em Ciência de Computação, Engenharia de Computação, Informática ou
  correlatos;
• Ter 6 meses de experiência de desenvolvimento em projetos Web;
• Ter conhecimentos nas tecnologias – PHP, ASP e .NET
• Conhecer os conceitos de orientação a objetos
• Conhecer Infra-estrutura, configuração e manutenção de servidores Apache e IIS

Conhecimentos desejáveis:

• Ter conhecimento da linguagem XML, XSLT, SQL e DHTML;
• Conhecer os bancos de dados: SQL Server 2000/2005, e MySQL.

Habilidade:

1. Transformar projeto em implementação;
2. Escrever código fonte em PHP, ASP e .NET;
3. Avaliar a implementação;
4. Executar os testes;
5. Avaliar a execução dos testes;
6. Depurar problemas no código;
7. Pesquisar soluções tecnológicas;
8. Controlar e cumprir prazos de suas tarefas;
9. Alertar com antecedência sobre problemas;

10.  Comunicar dúvidas ou questões encontradas.

Atividades do Cargo:

Trabalhará alocado Analista/Desenvolvedor, com conhecimento em portais utilizando a plataforma Lumis Portal Suite (ASP). Ter alguma experiência com PHP, ASP e .NET

Estamos trabalhando com pretensão salarial

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>

A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.

Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:

“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”

Então, qual é a resposta correta?

Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.

Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:

Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Hoje, o pessoal da pythonOnRio, #horaextra, dojoRio, e muitos outros se encontraram na Myfreecomm para fazermos um Sprint Day para fazermos o site do PythonCampus. O PythonCampus é uma iniciativa da galera de levar uma caravana de pessoas apaixonadas por tecnologia para as universidades para mostrar que é possível transformar a paixão por tecnologia em uma carreira de sucesso.

Essa iniciativa vem desde do ano passado e já percorreu diversas entidades no rio e em outras cidades, sendo um sucesso por onde passa.  Mas sempre sentíamos falta de termos um canal de comunicação, mais precisamente, um site.  Um site onde pudéssemos colocar mais informações sobre essa galera, oque fazemos, como fazemos, como nos contactar, página de eventos, etc.  Tudo isso começa a se tornar possível graças a um dia como hoje.

Nesse dia, várias pessoas se juntaram no escritório da MyFreeComm, no rio de janeiro, em pleno feriado com dia ensolarado e com céu azul, para fazer um sprint de um dia onde o objetivo era fazer o máximo possível para colocar um site para a nossa comunidade no ar.

O primeiro desafio vou descobrir o que fazer. Henrique Bastos orquestrou os trabalhos e durante toda a manhã, promoveu brainstorms, backlog plaining, e outras coisas tão interessante quanto.  Apesar de termos demorado um pouco mais do que eu gostaria, o resultado não poderia ser melhor: começamos nossa tarde com um backlog muito bem definido, como a ideia geral do que queremos para o site e com todos os integrantes vibrando na mesma frequência.

Terminado nossa reunião partimos direto para colocarmos as coisas em prática.  Alguns estavam incrédulos quanto ao fato de conseguirmos entregar o site funcional em apenas um dia.  E foi exatamente isso que aconteceu.

Em breve coloco os links para as fotos do making off.     E para quem duvidou : pythoncampus.org

E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo.  [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF].   Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série.  Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e  com isso, acabei  me lembrando de uma época,  numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.

O revisor de código é o cara que após você ter implementado toda  a solução, antes de você colocar as sua alterações no CVS  (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele.  Antes que me apedrejem em praça pública,  sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.

Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender.  Essa preocupação, inclusive,  tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.

A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.

Mas então? Qual é o melhor cenário?  O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?

Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!!   Essa, no meu entender, é um bom caminho.  É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação).  O time como um todo decide o que é melhor.

Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões.  O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.

Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura.  Na velhas e empoeiradas estruturas de fábrica,  tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que  todos devem usar.  Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente.  não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …

Novamente transferir essa “responsabilidade ” para o time é a melhor coisa.  Pois se discute. Todos tem voz.  A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.

Bem esse era meu recado… aguardo as opiniões de vocês.

Hoje, na hora do almoço, tive uma conversa super legal com um colega do trabalho. Conversamos sobre a questão do conhecimento e como ele poderia ser difundido dentro da empresa.  o assunto surgiu do fato de termos identificado que muitas empresas por onde passamos de diferentes tamanhos cometeram o erro de não cuidar da “circulação” da inteligência coletiva da equipe.

Tenho certeza que a maioria que está lendo esse artigo agora tem um exemplo de algum projeto que várias soluções foram adotadas, usadas, criadas, etc e por alguma razão obscura não foram documentadas.  Daí um tempo depois um outro projeto precisa de algo parecido e ninguém lembra mais como foi feito aquela implementação e por fim, todos acabam salvos por algum tarado que guardou o código e lembrava de onde estava aquele algoritmo na montanha de classes. Exageros a parte, isso é um dos sintomas do problema que gostaria de conversar com vocês sobre.

Poucos times de desenvolvimento, pelo menos que eu conheço ou ouço falar – fora open source – tem um cuidado em manter o conhecimento. Manter conhecimento significa guardar esse aprendizado de alguma forma que permita que no futuro ele  esteja disponível e facilmente seja encontrado.  Quem pensou em base de conhecimento, acertou em cheio. Estou falando exatamente nisso.  Em tempos que a rotatividade dos profissionais nos locais e projetos é alta, guardar o conhecimento e “organizá-lo” tornou-se o diferencial, “o pulo do gato” !.  Os franceses tem uma excelente expressão para isso : “Savoir faire”…

Para fazer isso não precisa necessariamente ter uma mega ferramenta, com recursos mágicos e inteligência artificial. Podemos começar simples.  Um bom primeiro passo seria até mesmo um arquivo texto.

Antes que nossos colegas gerentes pensem que essa é mais uma oportunidade para desperdiçar seus valiosos recursos (odeio esse termo), os ganhos são grandes demais para ignorá-los.  Ao ter uma boa base de conhecimento a curva de produtividade de um novo membro é rápida; o cara novo “pertuba” menos os demais; etc.

Bem depois eu volto no assunto. Aguardo o comentários de vocês para enriquecer.

Mais uma vez, devido a uma outra troca de e-mails,  vi um outro assunto super legal que gostaria de dividir com vocês.  A um certo tempo atrás, no blog do Calcado, li um artigo sobre o fato de objetos não serem atributos + funções. Neste artigo, o Calcado, mostra que os objetos ao invés de possuírem atributos e funções, eles na verdade possuem estados e comportamentos.  Reproduzindo um trecho do artigo :

Objetos não possuem propriedades + funções, eles possuemestado + comportamento. Você provavelmente vai usar atributos (i.e. variáveis de instancia) e funções (de instancia também) para implementar isso mas é um detalhe de implementação, não algo que deva ser exposto [sic]

Uma outra coisa que penso é que além disso que ele comentou, uma outra dificuldade que vejo no pessoal que está “montando” a arquitetura de sistemas, é definir como será a interação entre objetos.  Quem nunca ficou horas pensando onde colocar determinado método – “o método calcular preço  é da loja ou do produto?“; nome do método,  se deveria expor dados por get e set, etc .  Essa dúvidas vem da nossa visão equivocada da troca de dados entre objetos.

Se considerarmos que objetos não possuem métodos ou funções( função me parece tão modular e não OO) e sim “portas de entradas”.   Essas portas são como caixas de correio por onde enviamos e/ou recebemos mensagens com pedidos ou informações.  Para ficar mais fácil de entender,  imaginemos a situação de uma grande rede de lojas.  Esse grande rede possui diversas lojas, que possuem diversos produtos e clientes.  De cara, podemos dizer que temos 3 entidades :  Cliente, Produto e Loja.

Agora a pergunta: como você implementaria a lógica de obter preço – o cliente vai na loja, pega um produto e quer saber o preço.  Tenho certeza que alguns diriam que colocariam um método getPreco na classe de produto.  Outros fariam um PrecoControlador que pegaria o custo do produto e faria a operação de cálculo pegando a margem de lucro da loja, custo da loja e por seguiria…. Outros inventariam a classe preço que diante a loja e produto se calcularia….  De novo fazendo assim ainda estamos pensando em objetos como conjunto de funções e atributos e esquecendo da troca de mensagens.

Uma forma que vejo mais simples e mais expressiva de fazer (logo fica mais claro para entender o sistema) seria de perguntar para a loja o preço. Sendo assim, o cliente teria um produto e perguntaria a loja o preço. A loja consulta sua tabela de preço e responde.

Cliente  – pega produto —  > Produto

Cliente — informa o produto a loja –> Loja

Loja — consulta tabela –> Tabela

Loja — responde ao cliente –>

Fica bem elegante não… Mas se ainda não conseguiu ver:

class Andre  extends Cliente

…

Produto lapis = new Lapis();

double preco = lojaAbobrinha.qualEhOPreco(lapis);

..

Abobrinha extends Loja

…

double qualEhOPreco(Produto produto)

minhaTabelaPreco.qualPrecoAtual(produto);

Quem for fazer a manutenção do código,  só de ler, já começa a entender oque está acontecendo e começa deduzir as demais interações.

A um tempo atrás uma empresa entrou em contato comigo para que eu os ajudassem num projeto deles. Para este projeto, dada a dificuldade deles em encontrar bons profissionais no mercado do rio de janeiro, eu teria a responsabilidade de montar a equipe ( recrutar e treinar – caso necessário) ,  gerir o desenvolvimento da ferramenta e ainda dar suporte posterior.  eu fiquei um bom tempo pensando na proposta e depois que as coisas não foram para frente me senti tentado a contar a história e aproveitar para passar algumas visões minhas.

A primeira coisa que me chamou muito a atenção na conversa que tive com o pessoal da empresa, foi o discurso deles de que não conseguiam contratar bons profissionais no rio de janeiro (inclusive eles iriam se mudar para outra cidade em função disso).  Eu discordo disso. Existem excelentes profissionais aqui, como em qualquer outro lugar. A questão é ver qual era o perfil que eles estavam buscando e a remuneração que ofereciam.  Uma coisa que aprendi com meu pai e com meu tio Luiz é que coisa boa é cara.  Pode parecer loucura ou até presunção da minha parte, mas concordo com isso.  Se quer um profissional que faça o “feijão com arroz” tem que estar disposto a pagar o “feijão com arroz”; agora se quer o melhor você tem que estar disposto a pagar pelo melhor.  Não estou dizendo que eles não pagavam bem até porque nunca soube os valores que eles pretendiam.  Outro ponto é o perfil: vem acontecendo uma transformação nos profissionais do rio que aos poucos vão fugindo do padrão e com isso, para que os não se atualizam e vivem com os olhos tapados, parece que não existem profissionais bons.  Os bons do Rio, estão fazendo coisas muito interessantes mas não usam terno, entendeu

Não adianta vir aqui e dizer que não tem cara bom se você quer obter os melhores buscando no refugo e pagando salário de estagiário. (Peguei pesado mas é isso mesmo) .

Outro aspecto da conversa com eles foi a visão ainda de fábrica de softwares deles. Confesso que na hora que ouvi isso levei um susto. FÁBRICA DE SOFTWARE !!!  Isso não.   Não sei quanto a vocês, mas não consigo mais me ver ou compreender a razão para um modelo de fabrica de software.  Eu realmente acredito no poder dos times. No poder dos pequenos e coesos times.  Essa coisa de quebrar em etapas, e um escreve a primeira letra e outro coloca o ponto e vírgula,  já foi ! Todos devem fazer tudo e mexer em tudo. Nada de especialista de porcas, especialistas de parafusos, etc.

Não consigo mais ver vantagem na multidão.  Hoje, se fosse montar uma equipe, e tivesse o recurso necessário, montaria uma equipe pequena, com bons skills e super coesa.  Não estou dizendo que só escolheria gênios. Muito pelo contrário, escolheria pela afinidade,  pela vontade de fazer algo melhor, pela disposição, e outros fatores afins.  E faria de tudo para a equipe se manter do mesmo jeito e pequena. Nada de crescimento.  Com certeza a comunicação iria fluir muito bem; os projetos iriam sair com qualidade;  tudo iria funcionar como um “relógio” não porque existem gênios mas porque o time é unido, coeso e a famosa história do conjunto ser melhor que a soma dos indivíduos.

Por fim quero deixar algumas conclusões:  [1] Existem bons profissionais em qualquer lugar. Pode ser que esteja procurando errado.  Realinhe seu foco, procure entender o mercado e retome as buscas; [2] Para se ter o melhor, você tem que estar disposto a dar o melhor – isso implica é muito mais coisa que salário; [3] Times pequenos são melhores que multidões. A força está no entrosamento. é muito mais difícil obter coesão de conjuntos enormes.  Se o projeto é grande, quebre-o em muitos pequenos times independentes e verá que será melhor.  [4] É preciso acompanhar as mudanças do mercado até mesmo para contratar.  Os perfis são outros e com isso as empresas tem que se adaptar.

Bem é isso. Aguardo o comentário de vocês. Até o próximo !!!