Erros em SEO que insistimos em cometer

No final de julho aconteceu o Search Labs 2010, um evento que trouxe a oportunidade de vermos o que há de melhor lá fora na área de search e mostrar que existem muitos profissionais de qualidade no mercado nacional. Durante dois dias, foi possível acompanhar palestras simultâneas, divididas em três salas, além de colocar em prática o networking, feito nos corredores por estudantes ou profissionais já consagrados no mercado.

O evento desenhou os cenários de search através do Brasil e do mundo. Pesquisas, pensamentos, aplicações, estratégias, conceitos e ações foram repassados ao público. Fórmulas milagrosas foram constantemente frisadas como inexistentes, o que demonstrou que o search não é uma ciência exata, mas sim um trabalho muito mais intelectual e com relações estratégicas humanizadas.

Das centenas de dicas apresentadas durante as palestras de que pude participar no Search Labs, listarei aqui quatro erros que foram expostos e que insistimos em fazer. São quatro pontos que todos os profissionais já deveriam possuir como conhecimento em suas bagagens pessoais, mas que foram constantemente apontados durante o evento - por diferentes palestrantes de diferentes áreas - como ações fundamentais que grande parte do mercado insiste em não praticar. Ou melhor: praticam de forma errada. São estes os erros:

01. Conteúdo deve ser prioridade

Muito mais importante do que técnicas mirabolantes e estratégias complexas é um conteúdo produzido com qualidade, para atrair um público de qualidade. De nada serve uma estruturação caríssima e campanhas frenéticas se não possuirmos o mínimo de particularidade para ser apresentada. Um conteúdo ruim atrai, necessariamente, um público ruim, despreparado e que não irá servir em nada para o sucesso do seu projeto.

02. Não se faz SEO para robôs

Outro ponto-chave fundamental trabalhado por muitos palestrantes foi o de que muitos profissionais de SEO ainda não têm em mente que trabalham para pessoas, não para robôs e seus sistemas de busca. Mais uma vez, de nada adianta uma estruturação caríssima se não pensarmos naqueles que realmente irão analisar nosso trabalho: nosso público-alvo.

03. Mídia social não faz milagres

Na era das novas tecnologias e das redes e mídias sociais, o tema do momento não podia ficar de fora do evento. Mídias sociais são fundamentais para campanhas bem sucedidas? A resposta é não. Mídias sociais não fazem por si só o trabalho de uma grande campanha. Redes sociais não garantem, sozinhas, o real sucesso de uma aplicação estratégica. A coqueluche do momento deve ser uma complementação do seu planejamento, não a única fonte de esperanças.

04. Engajamento é fundamental para seu sucesso

Pedro Dias, do Google, afirmou que sites são como crianças pequenas, pois ambos devem receber cuidados especiais o tempo todo. O engajamento, aliado com todos os itens anteriores mencionados, transparece uma imagem mais lúcida do trabalho que está sendo feito por trás de uma página na web.

Precisamos ter em mente que:

• um conteúdo de qualidade atrai um público de qualidade;
• todo o trabalho deve ser feito para pessoas e não para robôs;
• mídia social não trabalha sozinha;
• a garantia de um trabalho sério e de respeito com o público-alvo consiste principalmente em mostrar que há disponibilidade para este o tempo todo.

O sucesso de sites, campanhas e projetos depende muito mais de um planejamento bem alinhado do que de atitudes descontextualizadas. Os quatro pontos aqui citados são fundamentais porque demonstram que o maior evento de search do país reafirmou que burlar alguns dos mais fundamentais e simples pontos não consiste em uma tática inteligente.

E o pior: o mercado sabe disso.

Fonte: iMaster

Entenda a Certificação SCJD

Pessoal;

Vejam o que a Wiki fala sobre Certificação:

Certificação é a declaração formal de "ser verdade", emitida por quem tenha credibilidade e tenha autoridade legal (...). Ela deve ser formal, (...) ser corporificada em um documento. A certificação deve declarar (...), explicitamente, que determinada coisa, status ou evento é verdadeiro. Deve também ser emitida por alguém, ou alguma instituição, que tenha fé pública, isto é, que tenha credibilidade perante a sociedade. Essa credibilidade pode ser instituida por lei ou decorrente de aceitação social.

Mais um artigo interessante do iMaster sobre Java. Certificações são super importantes na carreira de um programador, elas comprovam - para qualquer um ver - o quanto você conhece da linguagem.

A certificação Sun Certified Java Developer - SCJD oferece uma oportunidade única para os desenvolvedores Java colocarem toda a sua bagagem de conhecimento realmente em prática. Ela é destinada para aqueles já certificados na SCJP que desejam demonstrar proficiência avançadas utilizando os leques de tecnologias existentes no pacote JSE. Por isso, seu pré-requisito é possuir no mínimo a certificação oficial de programador.

O objetivo geral desta certificação é validar conhecimentos arquiteturais, combinados com importantes conceitos de engenharia de software, juntamente com uma grande porção das tecnologias encontradas no JSE: OOP, Exceptions, Logging, Collections, Threading, Socket, Serialization, File I/O, RMI e Swing.

O conteúdo da prova oferece um ótimo ambiente de aprendizado, no qual diferentes tecnologias podem ser combinadas com uma variedade de opções de soluções. A prova foi elaborada com o intuito de simular as circunstâncias do mundo real que um profissional pode encontrar no mercado de trabalho, por isso ela apresenta determinadas situações incompletas e duvidosas, fazendo com que cada candidato apresente atitude e dinâmica para encarar e resolver os problemas envolvidos na análise, no projeto e na implementação de um verdadeiro sistema.

A prova está divida em duas diferentes fases chamadas de Assignment e Essay, nas quais vale ressaltar a necessidade de efetuar dois pagamentos diferentes, uma para cada parte.

1. Assignment

Consiste em o candidato receber a documentação que descreve os requisitos e as situações de um sistema real, fazendo com que ele, então, tome as devidas decisões arquiteturais que resolvam, de forma coerente, o determinado contexto. Com isso, ele deve escrever um sistema relativamente pequeno, mas que seja suficiente para atender a todos os itens descritos no documento de especificação. Juntamente com o sistema, o candidato deve entregar três tipos de documentação:

Infra-estrutura - documentação de todo o código-fonte Java implementado, utilizando a tecnologia JavaDoc.

Usuário Final - documentação destinada para os usuários finais da aplicação, descrevendo: instalação, configurações, interfaces gráficas e funcionalidades.

Decisões - documentação das decisões significativas que o candidato teve que tomar relacionadas com dúvidas, incertezas e julgamentos envolvidos no projeto.

2. Essay

Consiste em o candidato prestar uma prova escrita de 90 minutos, na qual ele terá que responder algumas questões relacionadas com o desenvolvimento de seu projeto. Esta segunda fase tem dois objetivos. Um é questionar o candidato sobre a coerência do seu entendimento nas questões que o levaram a tomar as decisões descritas no documento de decisão. O segundo é provar sua autoria no código-fonte submetido na primeira parte do projeto.

Dicas Gerais

A filosofia desta certificação consiste no candidato entrar na prova já recebendo o numero máximo de pontos, que é 400. Cada tópico cobrado tem um peso de pontos pré-determinado:

Considerações Gerais [80 Pontos] - avalia os critérios relacionados com a facilidade de manutenção do código.

Documentação [50 Pontos] - avalia os critérios relacionados com a qualidade dos documentos requisitados.

Projeto OOP [50 Pontos] - avalia os critérios relacionados com a qualidade da estrutura do projeto de classes, métodos e variáveis.

GUI [70 Pontos] - avalia os critérios relacionados com a qualidade e com a facilidade apresentada nas interfaces gráficas do usuário.

Bloqueio [80 Pontos] - avalia os critérios relacionados com a qualidade do controle de bloqueios.

Fluência da Linguagem [70 Pontos] - avalia os critérios relacionados com a língua inglesa.

Durante as duas fases da certificação, os avaliadores descontarão pontos proporcionais naqueles tópicos nos quais o candidato não conseguiu cumprir os critérios adequadamente. O numero mínimo para ser aprovado é de 320 pontos. Seguem, então, algumas dicas que eu acho importantes relacionadas com o conteúdo básico que um provável candidato deve possuir:

Inglês

Diferentemente de outras certificações, nesta o candidato deverá entregar vários documentos na primeira fase e prestar uma prova contendo somente perguntas dissertativas, nas quais ele deverá possuir o básico do inglês. Qualquer erro pode colocar o entendimento do avaliador em dúvida, fazendo com que ele facilmente desconte pontos. A minha indicação é para os candidatos sem o inglês básico adiarem essa prova, deixando-a para quando estiverem melhor na língua. Aqueles com inglês regular podem até tentar, sabendo que as coisas podem não dar certo. De qualquer forma, seguem duas dicas:

Na primeira, fase peça ajuda a outras pessoas mais experientes para revisarem e corrigirem os erros em todos os documentos submetidos.

Na segunda fase, elabore e estude algumas frases "chavões" para que possa chegar bem preparado com o objetivo de encaixar as repostas nos contextos das questões. Alguns exemplos seriam:

I decided to create?

I decided to implement?

I decided to use (X) because?

I decided to use the following?

I decided not to use?

I decided to use (X) instead of (Y) because?

In my opinion, there was no need to?

I implemented a class called (p1.p2.Nome) that?

Arquitetura de Sistemas

O candidato necessitará definir e projetar uma arquitetura para a implementação do suposto sistema. A questão complicadora é que ele deverá justificar consistentemente no documento de decisões todas as motivações que o impulsionaram para isso. Qualquer discrepância que coloque em dúvida a integridade ou a autenticidade da solução poderá fazer o avaliador descontar pontos. A minha dica aqui é para que o candidato invista em estudar livros e materiais específicos no assunto. Leitura obrigatória do livro do Martin Fowler:

Patterns of Enterprise Application Architecture

Princípios de OOP

Dentro do contexto da arquitetura, o candidato também estará sendo avaliado na qualidade da infra-estrutura de classes elaborada na solução entregue. Com isso, todo candidato tem que, obrigatoriamente, saber o mínimo dos velhos e já conhecidos princípios de OOP, denominados SOLID. A minha dica de livro aqui é o de análise e projeto OOP da Head First:

Head Fisrt Object Oriented Analysis and Design

Padrões de Projeto

Continuando a pontuação na qualidade da infra-estrutura de classes, gostaria de acrescentar um ponto importante: um bom projeto de classes sempre está recheado de padrões de projetos em sua estrutura. Além da leitura do livro do Martin Fowler já indicado, seguem outras indicações de livros consagrados:

Head Fisrt Design Patters

Design Patter Java

Java Code Convention

O projeto deve ser implementado usando os padrões formais de escrita da indústria Java, e o candidato deve estar totalmente familiarizado com eles. A dica aqui é o candidato estudar e aprender a escrever código Java 100% compatível com a convenção oficial.

Leia e estude o Java Code Convention

Java Doc

O projeto de classes deve ser completamente documentado usando a tecnologia Java Doc. A dica aqui é o candidato aprender a escrever e a utilizar adequadamente os recursos do Java Doc.

Leia e estude o tutorial oficial

Tecnologias JSE

O projeto precisará do domínio razoável de algumas tecnologias existentes dentro do JSE, como Logging, Threading, Socket, Serialization, File I/O, RMI e Swing. A minha dica aqui é para que cada candidato faça uma auto-análise realmente verdadeira e procure, assim, livros e tutoriais específicos sobre cada tópico. Um ótimo livro que faz um resumo razoável do conteúdo é o único existente específico para a prova SCJD:

SCJD Exam with J2SE 5 - Andrew Monkhouse

Engenharia de Software

Durante a implementação do projeto, o candidato deve saber lidar com alguns conceitos básicos de engenharia de software para tomar determinadas decisões relacionadas com o contexto da solução requisitada. Alguns deles seriam: Bloqueio, Concorrência, Paginação, Ordenação, Classificação, Cacheamento etc. A dica aqui é: fica a cargo de cada candidato correr atrás de artigos, tutoriais e materiais de embasamento conceitual relacionados com eles, uma vez que não existe uma única literatura reunindo todos. Um bom começa seria o livro:

POJO In Action - Chris Richardson que não tem o foco da prova, mas que aborda com sucesso a maioria dos tópicos.

Algo que eu gostaria de deixar claro é que algumas certificações de TI possuem literaturas específicas que cobrem todo o conteúdo da prova, fazendo o candidato ficar bem cômodo no momento de estudar. A prova SCJD não é assim! Nela, o candidato inevitavelmente terá que investir bastante tempo de estudo em vários conteúdos diferentes com o objetivo de acumular uma série de informações correlacionadas.

Receita de Bolo

Para organizar as idéias, eu gostaria de ajudar os candidatos interessados passando uma receita de bolo. Aqui está ela:

1. Levante o que precisa ser aprendido - junte todas as dicas e faça uma listagem bem real daquilo que você acha que precisa aprender ou melhorar.

2. Plano de estudo - com base na listagem, faça um plano de estudo para cada tópico, investindo de acordo com seu tempo útil. Invista tempo estudando livros, tutoriais e fazendo exercícios isolados de cada tópico.

3. Livro SJCD Monkhouse - depois estudar cada tópico individualmente, agora é hora de linkar todo o conteúdo. Este é o momento ideal e propício para o candidato investir tempo estudando o livro específico da SCJD, que reúne e compila todo o material envolvido na prova.

4. Projetos exemplos - após entender o conteúdo no geral, é de grande ajuda o candidato brincar com algum projeto real da prova. O objetivo deste passo é fazer o candidato ter em mãos algum projeto no qual ele possa executar, depurar, visualizar e ter um entendimento da mecânica da coisa. Seguem algumas dicas:

No livro da SCJD indicado, há um projeto chamado de DennyDVD, que foi elaborado pelo autor justamente para ser usado para estudo. Ele contém os recursos necessários que contemplam o conteúdo da prova. Qualquer um pode fazer download do código-fonte no site oficial. Para todas as informações, consulte o próprio livro.

No revista Mundo Java edição 40 (agora conhecida como MundoJ), existe um ótimo artigo escrito pelo meu brow Roberto Perillo que aborda todos os detalhes da certificação. No artigo, é implementado um exemplo que também cobre aspectos da prova que também pode ser usado como material de estudo. Veja a revista para todas as informações.

Eu posso disponibilizar o código-fonte do projeto que eu fiz quando fui aprovado nesta certificação. Para todas as informações, entre em contato comigo.

5. Projeto Oficial - depois de todos os passos acima, o candidato pode respirar fundo, tomar coragem para pagar a primeira fase, baixar a especificação e começar o seu projeto.

Mesmo depois de tudo isso, muitas dúvidas podem aparecer durante a elaboração do projeto. Um ótimo lugar para resolver isso é o fórum do JavaRanch, que é ponto de encontro de todas as pessoas que já prestaram a prova com sucesso e daqueles candidatos que atualmente estão prestando. Minha dica é, antes de perguntar algo, procure se a questão já não foi discutida anteriormente. Faça boas amizades no fórum que várias pessoas te ajudarão nas mais diversas dificuldades.

Eu também me coloco à disposição para ajudar qualquer interessado em investir na prova. Quero te adiantar que não será fácil, mas você só saberá o quanto aprendeu depois que passar pelo processo. Este é o artigo 1 de vários que eu escreverei sobre outras dicas relacionadas com esta prova. Um grande abraço e nos vemos no próximo!

Fonte: Fernando Franzini - iMaster

A produtividade da equipe de desenvolvimento

Você é programador e no seu trabalho é você quem atende o cliente no telefone para discutir regras de negócio. Recebe e-mail dos usuários pedindo suporte e ainda visita clientes com frequencia, onde você, com o seu notebook, faz programação “in-loco”. Além disso, diversos usuários vão até você para tirar dúvidas e reclamar sobre a dificuldade de utilizar o sistema.

Dos 30 clientes que a empresa possui, você tem absoluta certeza de que pelo menos 20 deles possuem versões diferentes do mesmo sistema. Quando não é versão diferente de executável é versão diferente de banco de dados.

Já aconteceu de um dia resolver um bug de um cliente e na próxima atualização descobrirem que a correção de um cliente gerou problema em outro que não tinha nada a ver com o que foi feito no passado.

Além de você, a empresa possui outros 17 programadores, divididos em células de trabalho que atendem produtos específicos mas pode-se observar que o problema acima acontece com todos os produtos da empresa.

Com tantos programadores, o sócio-diretor não entende porque a empresa leva tanto tempo para liberar uma nova versão ou corrigir um bug no sistema e então resolve que todo mundo deve começar a preencher uma planilha contendo a data e hora de início e fim de cada atividade que faz, a fim de ter certeza de que os funcionários não estão desperdiçando tempo com Google, Orkut e Messenger e tornar mais evidente aquilo que estão fazendo.

Após muita revolta, todos os funcionários passam a preencher esta tal planilha, ainda que com dados fictícios ou com pouca ou nenhuma fidelidade, o que mostra ao dono do empreendimento que a estratégia não funcionou.

Após conversar com alguns amigos diretores de grandes empresas e com a ajuda de uma consultoria externa, decide que é hora de implantar o CMMI para padronizar as rotinas de trabalho e também um sistema moderno de gerenciamento de helpdesk, baseado no ITIL, com medição de SLA (qualidade de serviço) etc.

Duas semanas de visitas dos consultores externos para disseminar o CMMI e ITIL e no mês seguinte entra em vigor o novo método de trabalho.

O que será que deu errado?

É o diretor quem pergunta, furioso e decepcionado por ter investido milhares de reais em siglas super modernas e ver a qualidade da sua equipe, que parecia ruim, piorar de vez.

Entenda o que poderia ter sido feito diferente.

1. Não faça microgerenciamento de funcionários

O gerenciamento do tempo é indispensável para oferecer previsão nos projetos, mas cuidado.

Estou cansado de ver empresas que não conseguem (ou não querem) alocar um gestor capacitado a coordenar toda a área de desenvolvimento, definindo quem fará o quê e quando e monitorando entregas para saber se estão ou não no prazo. Em vez disso, se limitam a delegar (ou delargar) a responsabilidade de gerente para o próprio funcionário, fazendo com que o funcionário (e não o gerente) seja o responsável por preencher planilhas com o que está fazendo, quando fez, quanto tempo durou, porque fez assim, onde mexeu, etc etc.

Sob o ponto de vista do funcionário, isto soa como microgerenciamento. Segundo o autor Mc Gregor (Teoria Comportamental do X e Y), esta técnica não deve ser empregada em atividades que requeiram criatividade, como desenvolvimento de software, pois causa desconfiança e um sentimento ruim de trabalho monitorado com controles rígidos.

Encontre um bom gestor. Se não quiser buscá-lo no mercado, desenvolva um plano em conjunto com o colaborador que tenha maior vocação para administração e gestão. Não cometa o erro de promover uma pessoa absolutamente técnica para gerente somente pelo tempo de casa, pois ao invés de gerenciar ela vai querer programar, que é o que no fundo ele gosta de fazer, pois será péssimo para a sua empresa/projeto.

2. Siglas como CMMI, ITIL e PMI não vão resolver o problema

Revistas, jornais e a internet não param de falar em siglas que melhoram produtividade, dão consistência e melhoram o controle sob os processos de desenvolvimento. Mas não cometa o erro de achar que somente a sigla vai causar uma revolução na sua empresa ou departamento.

Todas as siglas trazem sugestões de trabalho excelentes mas que nem sempre precisam ser seguidas à risca. Evite pescar algumas siglas, buscar consultores externos para implantação e achar que vai tudo ser resolvido do dia para a noite.

É a mentalidade dos colaboradores que precisa mudar e isso não vai acontecer do dia para a noite, portanto…

3. Quando for implantar uma metodologia ou modelo de trabalho, faça gradativamente

Jamais implante um modelo de trabalho do dia para a noite. Já vi caso em que a empresa fechou numa sexta-feira sem nenhum controle e quis iniciar segunda-feira com o modelo proposto pelo PMI 100% funcionando.

Não é porque você contratou um excelente gerente de projetos, com anos de experiência em diversas empresas e setores, que a implantação das práticas propostas pelo PMBOK vai acontecer do dia para a noite.

A melhor forma para permitir que a mentalidade dos colaboradores acompanhe as mudanças que serão introduzidas com as novas metodologias é fazer com que sua implantação seja feita por partes.

Inicialmente converse com a equipe. Deixe claro que mudanças vão acontecer e determine um prazo viável para concretizar a implantação do modelo de trabalho.

Esqueça a ideia de que será em semanas ou poucos meses. Trabalhe com prazos médios e, dependendo da mentalidade dos seus funcionários, seja realista. O prazo para a mudança será longo, mas ela deve acontecer, ainda que gradualmente.

O segundo passo é começar a documentar, mas ainda sem métricas ou processos muito rígidos e detalhados. Cobre documentos e exija que sejam utilizados, depois siga para a próxima etapa e assim sucessivamente, até que quando você menos esperar a produtividade da equipe estará em níveis excelentes.

Uma sugestão é segmentar ainda mais este processo implantando inicialmente somente em uma equipe ou em um projeto e depois estenda a toda a empresa. Utilize as pessoas que participaram da implantação como disseminadores de conhecimento e vendedores da ideia e de que o modelo dá certo.

Não deixe de sempre medir o resultado do trabalho, mas…

4. Não use os resultados das métricas como arma para criticar os seus colaboradores

Um erro muito comum é verificar que as métricas não estão indo bem e convocar reunião para aterrorizar os colaboradores cobrando melhoras imediatas.

Métricas ruins em geral são sinais de que o modelo implantado não está de acordo com o nível de maturidade da empresa. Reavalie imediatamente o que está sendo cobrado e verifique se os colaboradores sabem exatamente como funciona o processo e se a qualidade e o nível das documentações que estão sendo geradas estão de acordo com o esperado pela equipe de desenvolvimento.

Não deixe de verificar o nível de envolvimento da equipe com o projeto e principalmente a motivação do gestor da área.

Utilize o resultado das métricas para descobrir onde estão as falhas no processo e corrija-as imediatamente.

5. Participe com toda a equipe da implantação

Não faça reuniões fechadas apenas com os líderes para saber como está a implantação. Em geral, se existir algum problema e eles não se sentirem plenamente seguros em relação as mudanças, eles tentarão acobertar por medo de saber qual será a reação da empresa.

Convoque todo o batalhão de colaboradores para discutir e deixe claro que o objetivo não é criticar o erro mas sim detectar falhas que possam ser aprimoradas para que o projeto de melhoria contínua possa seguir adiante e jamais desista no primeiro obstáculo.

fonte: Webinsider de Renato Ucha

Faça parte deste artigo compartilhando comigo experiências de implantação de metodologias e modelos de trabalho enviando e-mail para falecom@renatoucha.com.br.

Comunicação versus documentação em projetos

Todos os que se interessam por gerenciamento de projetos já ouviram que entre 80 e 90% do tempo de um gerente de projetos é gasto em comunicação.

O PMBOK em sua 4ª edição (versão 2008) afirma, na página 338 (versão em português) que: “A comunicação foi identificada como a maior razão de sucesso ou fracasso de um projeto”.

Apesar disso, dentro da gigantesca bibliografia de gerenciamento de projetos, é extremamente difícil encontrar bons livros falando sobre o assunto. Confirmei isso recentemente, ao iniciar a orientação de uma aluna em seu TCC de Pós Graduação em Gestão de Projetos. Mesmo o PMBOK, depois de afirmar a sua importância através da frase citada acima, dedica apenas 21 de suas 336 páginas ao gerenciamento da comunicação – e vale ressaltar que isso significa um avanço em relação à versão 2003, que dedicava apenas 14 páginas…

O grande problema que percebi em várias metodologias de desenvolvimento / gerenciamento com as quais trabalhei é que se confunde documentação com comunicação.

Documentação é importante sim – para que todos saibam o que está acontecendo, para nivelar informações e para sinalizar o acompanhamento do projeto.

Dentro da área de conhecimento de gerenciamento da comunicação, o PMBOK em sua 4ª Edição (2008) define cinco processos:

1. Identificar partes Interessadas

2. Planejar as comunicações

3. Reportar o desempenho

4. Gerenciar as expectativas das partes interessadas

5. Distribuir Informações

Em minha experiência de projetos, gerenciando e sendo gerenciado, pude perceber que os processos que recebem maior atenção são reportar o desempenho e distribuir informações, muito provavelmente porque esses elementos são, basicamente, processos de documentação.

Ouvi certa vez de um superintendente, em reunião para gerentes de projeto, a seguinte frase: se falharmos na documentação do que ocorreu durante o projeto, ficamos sem defesa, nas mãos do cliente…

Realmente isso é verdade, se não está documentado, não temos defesa, mas… precisamos mesmo nos defender sempre?

Para mim essa metodologia devia se chamar COASS (Cover Our ASS!).

Essa frase parece afirmar que o projeto terá problemas, que o cliente ficará insatisfeito e que precisamos nos resguardar. Fiquei com vontade de perguntar (mas não o fiz, eu um raro momento de lucidez):

- Não seria melhor evitar a insatisfação do cliente? Gerenciar suas expectativas, para que no final, pelo menos na maioria dos projetos, não ser necessária uma defesa?

Não estou dizendo que a documentação não é importante, apenas que existem outros processos tão (ou mais) importantes que a documentação.

O grande problema é que documentar é fácil (chato e trabalhoso, mas fácil). Basta ser metódico e organizado, atualizar um cronograma, escrever um report e disponibilizá-lo, fazer atas de reunião… Não existe um segredo para isso, um bom template e algumas explicações e qualquer gerente flanelinha consegue realizar.

Já o processo “gerenciar as expectativas das partes interessadas” é muito mais complicado. Afinal, é preciso primeiro saber quem são as partes interessadas e quais são suas expectativas. E também se são viáveis e estão dentro do escopo do projeto.

Note que o verbo empregado é gerenciar e não atender e muito menos superar.

Gerenciar expectativas exige uma atitude muito difícil. É preciso se relacionar com a parte interessada, é preciso saber negociar, influenciar e, raras vezes, impor limites.

E se, e sempre tem um “e se…”, com tudo isso, o cliente ainda tiver uma expectativa inviável, seja em termos de prazo, em termos de custo ou de escopo?

Infelizmente essa situação é mais comum do que o desejado. O gerente de projetos é alocado pela organização executora, que vendeu a um cliente um projeto inviável, ou o cliente solicitou um produto e na verdade deseja outro…

Esse é um caso clássico de conflito de expectativas. É exatamente nesse contexto que o gerenciamento das expectativas é fundamental. As partes precisam saber que as expectativas são incompatíveis – é preciso negociar, tentar influenciar ou até mesmo impor limites.

Claro que tudo isso precisa ser documentado, mas se as expectativas forem gerenciadas, a documentação pode sim funcionar como defesa. Mas pelo menos nenhuma das partes interessadas poderá dizer que foi uma surpresa.

É mais complicado que simplesmente documentar? Sim, muito mais complicado. Talvez por isso gerentes de projeto ganham mais que documentadores.

Fonte: [Webinsider]

Google abre inscrições para seu campeonato mundial de programação

Primeira prova do Google Code Jam 2010 está marcada para 7 de maio.

Final do desafio internacional reunirá 25 melhores em julho, na Irlanda.

O Google abriu nesta quarta-feira (7) as inscrições para o Code Jam, campeonato mundial de programação promovido pela companhia. Realizado desde 2003, o Google Code Jam é uma competição na qual programadores devem resolver desafios de algoritmos complexos, em um período de tempo predeterminado.

As primeiras etapas serão disputadas on-line e a primeira prova acontece em um mês, no dia 7 de maio. Os 25 programadores mais bem colocados participarão da final, prevista para ser realizada no dia 30 de julho, em Dublin, na Irlanda.

O vencedor ganhará um prêmio de US$ 5 mil, o segundo colocado embolsará US$ 2 mil, e o terceiro lugar, US$ 1 mil, enquanto os outros 22 finalistas levarão US$ 100 cada.

Saiba mais no site oficial do Google Code Jam 2010.

Fonte: G1 - Tecnologia

Key dates for 2010.

Wednesday, April 7, 2010	19:00 UTC	Registration Begins
Friday, May 7, 2010	23:00 UTC	24 hr Qualification Round Begins
Saturday, May 8, 2010	23:00 UTC	Registration and Qualification Round End
Saturday, May 22, 2010	01:00 UTC	Online Round 1: Sub-Round A
Saturday, May 22, 2010	16:00 UTC	Online Round 1: Sub-Round B
Sunday, May 23, 2010	09:00 UTC	Online Round 1: Sub-Round C
Saturday, June 05, 2010	14:00 UTC	Online Round 2
Saturday, June 12, 2010	14:00 UTC	Online Round 3
Friday, July 30, 2010	TBD	Onsite Finals

Práticas de aplicativos web com Java

Amigos,
Achei um artigo sobre desenvolvimento Java muito legal, escrito pelo Fernando Franzini.

No mundo conceitual da engenharia de software vemos inúmeras teorias, diretrizes, abordagens, idéias, teoremas etc... tudo isso relacionado com todas as partes envolvidas na produção de um sistema. Entretanto, na realidade nua e crua, vemos que a prática pode se distanciar um pouco desta almejada "Realidade Conceitual Ideal". Neste artigo, quero falar um pouco sobre práticas reais relacionadas a situações que eu tenho vivido na construção, teste e homologação de sistemas web usando java. Então vamos lá =).

Independente de qual filosofia, metodologia, abordagens ou frameworks que se possa usar no desenvolvimento do aplicativo web em java, nos últimos anos tenho sentido que não consigo fugir de dois problemas: consumo de memória e performance.

Consumo de Memória

Não é novidade para ninguém que, em java, a memória é automaticamente gerenciada através de um recurso chamado Garbage Collection, que a cada versão da JVM tem sido melhorado e incrementado. Este fato traz, para qualquer desenvolvedor, a falsa idéia de que ele pode deitar e rolar na implementação do sistema que o "Sr. pancudão coletor de lixo" vai limpar toda a sujeira que ele deixar para traz.

Na prática, percebo que os responsáveis pelos sistemas em geral - gerentes, projetistas, programadores etc., não tem colocado isso como um fator de preocupação nos ciclos de desenvolvimento, deixando "o pau torar" na programação. O resultado é que em ambiente de testes e homologação o sistema funciona lindo e maravilhoso, mas depois que entra em produção, mesmo após apenas alguns dias em que o serviço está no ar, começam as runtime exceptions apontando a falta de memória. E agora? O que fazer se o sistema está gastando mais memória do que a suportada pela configuração da JVM?

"O aumento de memória das máquinas e JVM,

ou mesmo o aumento de máquinas nos clusters,

não é a solução, e sim uma prorrogação do problema!"

Qualquer pessoa poderia facilmente sugerir que aumentássemos a memória da máquina e JVM. Entretanto, vemos que isso não é uma solução, e sim uma prorrogação do problema, porque quanto mais pessoas usando, ou quando novos processos forem acrescentados no sistema, maior será o gasto. Solucionar o problema seria perguntar para o sistema se ele não está gastando memória mais do que o necessário!!! Depois dessa certeza é que se delega mais memória para JVM, sendo que a aplicação realmente está precisando. Não quero entrar em detalhes sobre regiões de memória da JVM e nem sobre escalabilidade vertical e horizontal, pois fogem do escopo do artigo. A questão é que vejo muita gente tentando escalar a aplicação sem nem ao menos avaliar o seu consumo real.

Performance

A velocidade da aplicação em executar os processos e apresentar algum resultado está intimamente ligada com a experiência do usuário final, que vai passar horas e horas do seu dia ali na frente do sistema que foi maravilhosamente escrito para ele. Na prática, vejo que, novamente, os responsáveis pelos sistemas em geral - gerentes, projetistas e programadores, também não têm colocado isso como um fator de preocupação nos ciclos de desenvolvimento. O resultado é o mesmo de sempre, em ambiente de testes, homologação e durante algum tempo inicial de produção, o sistema funciona lindo e maravilhoso, mas depois de algum tempo começam as reclamações relacionadas com a lentidão crescente.

Seguem abaixo algumas das práticas que venho utilizando como se fosse uma "receita de bolo", mais ou menos um "pente fino" que é passado nas aplicações para corrigir as duas situações problemáticas acima citadas.

1. Acesso ao banco de dados - reduzir ao máximo o número de vezes que a aplicação faz acesso ao banco de dados.

Problema: Muitos programadores têm a mania de ir desenvolvendo classes, componentes e módulos sem antes e/ou durante fazer uma análise organizada de como estas partes do sistema estão fazendo estes acessos. Com isso, vemos como resultado aplicações com baixa performance devido aos vários e desnecessários acessos à base que se multiplicam na aplicação a medida do número de usuários simultaneamente conectados.

Solução: Analisar quantas vezes a aplicação está acesssndo o banco, o porquê do acesso, e assim tentar uma forma de evitar este acesso. Neste momento, muitos profissionais pecam por não conhecerem recursos básicos de banco de dados e de SQL-ANSI, principalmente pelas propagações de frameworks ORM. Qualquer meio é válido, alguns recursos usados para alcançar isso são o uso de VIEWS, JOIN e SUBQUERYS. Todos os programadores têm que possuir um lema em mente: "O acesso remoto é que mais degrada a performance de uma aplicação e o acesso ao banco de dados é um deles, então eu tenho que fazer de tudo para evitar ou minimizar ao máximo."

2. Índices adequados - Criar índices para as todas as tabelas que sofrem consultas na aplicação.

Problema: Muitos programadores não têm o mínimo de fundamentos de banco de dados, criando bases sem nenhum índice de busca para as tabelas que sofrem alto número de SELECT WHERE CAMPO. A questão problemática é que quando uma tabela sem índice sofre um SELECT WHERE CAMPO, o registro é buscado, na maioria das vezes, da pior e mais demorada forma possível, que é o "seqüencialmente". A pior notícia é que isso é um problema cumulativo, ou seja, quanto mais registro existente, mais demorada fica a consulta. Já tive experiências de diminuir o tempo de um procedimento de fechamento mensal em 50% do tempo, pelo simples ato de criar os índices nas tabelas usados pelo processo.

Solução: Para cada SELECT que o programa faz, em cada tabela, verifique os campos de busca colocados no WHERE e, assim, crie um índice para cada um deles.

3. Consultas Gigantescas - Sistemas que permitem o usuário consultar e trazer do banco de dados um alto número de registros.

Problema: Algumas situações comumente ocorrentes em sistemas no modelo desktop, ou mais conhecido como "FAT CLIENT", não se encaixam em aplicativos web. Um destes casos é quando sistemas permitem aos usuários filtrar e trazer do banco de dados consultas com um alto número de registros complemente desnecessário. Em casos em que o modelo era desktop, isso não acarretava problemas devido à própria natureza da solução. Entretanto em sistemas web, onde recursos de execução são limitados e o numero de acesso simultâneos é ilimitado, o sistema estará gastando um alto e precioso numero relevante de memória.

Explicando de forma prática, eu já peguei sistemas nas redondezas onde os programadores juniores estavam replicando a arquitetura que continha uma camada de persistência CRUD. A questão problemática era que o framework replicava um método que sempre retornava todos os registros existente. Isto estava sendo propagado para todo o sistema e seus processos relacionados. Se paramos para analisar, mecanismos de busca são disponibilizados ao usuário para que ele tenha autonomia de buscar registros individuais ou grupos lógicos deles. Qual seria o motivo, ou o que poderia fazer um usuário com 500 linhas de resultados de uma consulta? Que ser humano na face da terra gostaria de visualizar 500 registros em uma olhada? Mesmo que a regra de negócio ainda apoiasse o caso, o usuário final, sendo um humano comum, não teria tamanha visibilidade para isso.

Solução: Os processos do sistema em questão devem ser analisados e devem ser implementadas validações lógicas corretas, que não permitam executar consultas que retornem uma alto número de registros no banco de dados. Duas práticas neste tópico são bem comuns - o uso sistemático de paginação, e a implementação de filtros inteligentes, baseados em regra do próprio negócio, que não deixassem a ocorrência de grandes intervalos. Como tudo na vida, existem exceções, e podemos, sim, encontrar situações em sistemas que teriam a necessidade de consultar grandes volumes de registros, mas isso já está mais que comprovado que é uma porcentagem pequena e restrita do total da automação.

4. Ordenação de Tabelas - Ordenar as tabelas em memória usando java ao invés de usar ORDER BY.

Problema: Uma funcionalidade muito comum é disponibilizar a ordenação das tabelas apresentadas na aplicação pelas suas próprias colunas. A questão problemática é quando a aplicação efetua um acesso ao banco a cada ordenação requisitada. Ou seja, o programador usa o recurso de SELECT ORDER BY para fazer a ordenação.

Solução: Transformar as linhas da tabela em objetos java e, assim, ordená-los usando recursos do JSE, evitando gasto com tempo, acesso ao banco e recursos de memória. Esta solução pode ser facilmente implementando com a interface Comparable.

5. Usar Pool de conexões - usar a abordagem de Pool como paradigma de acesso ao banco de dados.

Problema: Eu realmente não sei o motivo, mas já peguei alguns aplicativos web por aí que abrem e fecham objetos de conexão com o banco de dados a cada requisição. Ou seja, a cada pedido enviado ao web container, no mínimo 2 chamadas remotas são efetuadas, uma autenticar o usuário/senha e outra para efetuar a comando SQL desejado. Esta opção é uma das piores gafes que um programador web pode fazer para deixar o sistema com a pior performance possível, sem falar que o sistema pode "baleiar" o banco quando o número de acesso simultâneos exceder a capacidade de resposta do determinado banco de dados.

Solução: Na web existe uma única solução comprovada que é o uso efetivo da abordagem de Pool de conexões. No momento da disponibilização - deploy da aplicação, o sistema deve abrir um numero X de conexões com o banco de dados que sera posteriormente usado em toda a aplicação. Esta abordagem mistura o conceito de compartilhamento e concorrência, sendo que pedidos em tempos diferentes reutilização a mesma conexão e pedidos simultâneos usarão diferentes conexões. Este numero X deve ser levantando e configurada de forma parametrizada de acordo com o perfil da aplicação e do modo/quantidades que os usuários estarão gastando conexões durante utilização do sistema.

6. Usar Cache - Cachear informações que sofrem alto índice de acesso e baixa ocorrência de alteração.

Problema: Sistemas em geral implementam administração de informações na qual poderíamos classificar em 2 tipos: dados de manutenção/parâmetros e de processos:

a. Manutenção/Parâmetros - informações que os sistemas têm que guardar, usadas como parte do processo, que não possuem um fim nelas mesmas. Estes tipo de formação frequentemente sofre um baixo índice de manutenção e um alto número de acesso. Ou seja, no escopo da aplicação, estes dados raramente são alterados e muitos usados.

b. Processos - informações resultantes de processos com regras de negócio do escopo da aplicação. Estes podem ou não sofrer alterações e podem ou não ser altamente acessados. Tudo depende da natureza do negócio da aplicação. A situação complicada seria o sistema fazer um acesso ao banco de dados a cada momento que diferentes usuários (concorrentes ou não) necessitam usar informações de manutenção, que na grande maioria dos casos são iguais. Ou seja, teríamos vários usuários acessando o banco de dados repetidas vezes para pegar as mesmas informações, gastando assim tempo e memória de forma desnecessária.

Solução: Analisar cuidadosamente e cachear as determinadas informações que se encaixam de alguma maneria no perfil de dados de "Manutenção/Parâmetros". Conceitualmente, é fácil visualizar o mecanismos de cache: o primeiro usuário que necessitar da determinada informação efetuará um acesso ao banco e cacheará os dados em algum lugar na memória, fazendo com que os próximos usuários não precisem gastar tempo e memória repetindo o ciclo. O cache é atualizado quando estes dados forem atualizados de alguma maneira no sistema, bem como o perfil deles já mostrou que seria um caso difícil de acontecer.

A prática do cache, entretanto, não é algo simples ou trivial, demandando tempo e esforço para ser implementado. Eu poderia sugerir implementações prontas como o EhCache, ou serviços de cache disponibilizados pelos frameworks ORM. Veja que a utilização só vale a pena se os dados realmente possuírem um alto índice de acesso. Com esta abordagem, a aplicação consegue reduzir em média até 40% o acesso ao banco de dados. Uma sugestão bem simples e que deu bastante resultado é simplesmente implementar um mini cache usando o "application context" da aplicação que, com algumas classes estáticas, se consegue cachear/alterar estes dados, reduzindo em um porcentagem considerável o acesso ao banco de dados.

7. Controlar a criação de objetos: controle efetivo da criação de objetos durante a execução do programa.

Problema: Algo que precisamos sempre lembrar durante a programação é que o operador new aloca fisicamente o objeto da memória, gastando espaço no HEAP da aplicação. A primeira questão problemática é que percebo que os programadores usam o new de forma displicente, sem nem ao menos parar para pensar em que contexto da aplicação está usando. Tudo é motivo para fazer um new, eu já vi casos em que para reiniciar o estado do objeto, o programador dava um new na referência.

Solução: O programador tem que sair desse comodismo e começar a analisar todos os seus new! Duas perguntas resolvem o problema: 1. Por que estou alocando esse objeto? 2. Quantas vezes esse código vai ser executado? Estas duas perguntas vão consciencializar o programador daquela situação, levando-o no mínimo a tomar uma das duas decisões abaixo:

- Reutilizar Objetos - ao invés de ficar sempre fazendo new, ele pode aumentar a visibilidade do escopo daquele objeto e assim reusá-lo, restartando seu estado.

- Reduzir o Escopo - reduzir o escopo dos objetos vai deixá-los disponíveis mais rápido para o coletor de lixo. Se for preciso, use escopos lógicos menores com { }. Esta solução é uma das mais difíceis a serem implementadas, porque invadem a "cultura" do programador de se autocriticar. Mas quero animá-los dizendo que a batalha da economia de memória e performance se ganha na somatória de detalhes!

8. Controlar objetos String - controlar o gasto com os objetos Strings.

Problema: Outra coisa que sempre precisamos lembrar é que os objetos String chamados de "wrappers" são imutáveis, ou seja, uma vez instanciados eles nunca mudam. Qualquer operação com a String gerará uma terceira String. O problema aqui é o uso abusivo, desnecessário e inconsciente das String durante a execução do programa.

Solução: Segue a mesma idéia do tópico 5. O programador deve analisar a questão da necessidade e entender o porquê daquele uso. Duas opções surgem para contornar a situação:

- usar final static para as Strings que se encaixam no contexto de estáticas (SQLs, mensagens). Ou seja, somente será gasto um objeto para todas as execuções do programa.

- usar StringBuffer/StringBuilder para as String que sofrem alterações constantes ou para situações de manipulação de arquivos.

9. Aumentar as configurações de memória da JVM

Problema: Mesmo depois de todas as precauções tomadas, a aplicação ainda pode gastar mais memória do valor default previamente configurado na JVM.

Solução: Neste casos, é preciso fazer um estudo, apurando a média de memória gasta pela aplicação, usando alguma ferramenta de profile e, assim, configurar um adequado número razoável de memoria.

Fonte: IMaster