Lendo este post do Guilherme Chapiewski e a discussão gerada ao redor dele, resolvi consolidar as idéais que tinha a respeito desse assunto aqui neste espaço.

Infelizmente, é muito comum encontrar empresas que bonificam/promovem seus funcionários baseados apenas em fatores relacionados a “tempo de casa” ou “tempo de experiência” - ou qualquer outro tipo de parâmetro puramente objetivo. Há empresas que procuram avaliar seus funcionários até mesmo baseado na quantidade de linhas de código, ou pontos de função que eram capazes de produzir em um determinado tempo.

A busca por métodos mais objetivos de se avaliar as pessoas tem seus bons motivos, pois são excelentes para justificar - de forma irrefutável - a bonificação e/ou a posição de uma pessoa na hierarquia da empresa. Contudo, penso que há formas também eficientes, mas menos restritivas de se fazer isso.

Porque não Meritocracia?

É engraçado ver como algumas pessoas - por se sentirem “injustiçadas” por sua posição atual em suas respectivas empresas -  agem de forma irresponsável (não-profissional) de maneira deliberada, quase como em “protesto” por uma situação indesejável.  Este tipo de atitude, ao meu ver, é muito mais prejudicial a própria pessoa em si, do que a “injusta” empresa em questão.

Um jogador de futebol de um clube pequeno, ganhando um salário irrisório, frente ao que ganham jogadores dos grandes clubes, jamais faria um gol contra em protesto aos baixos salários! Do contrário, ele se esforçaria ao máximo para que pudesse ter seu talento descoberto por um time que melhor pudesse lhe valorizar. Ou seja, ele percebeu que para que fosse, de fato, promovido, ele deveria agir como se já fosse um jogador de um nível acima. Numa empresa que favoreça o crescimento profissional de seus integrantes, não é ela quem promove seus funcionários, mas, sim, eles que promovem a si mesmos através de suas próprias atitudes.

As pessoas recebem de acordo com a sua “raridade” ou importância para a empresa. Ainda que existam vários jogadores que possam desempenhar uma mesma posição - muitas vezes até com uma excelente técnica - poucos jogadores no mundo têm a habilidade do Ronaldinho Gaúcho ou a facilidade de marcar gols do Adriano. Por serem “exemplares raros” isso faz com que sejam recompensados de maneira semelhante.

Neste caso, nenhum tipo de métrica e/ou análise quantitativa foi utilizada para definir o quanto seria justo para aquele jogador; nada foi utilizado além do bom senso. Mesmo tendo sido usados parâmetros, de certa forma, bastante subjetivos, creio que poucos duvidariam deste julgamento. Creio eu, por esses motivos, ser mais importante ter uma percepção correta do valor que o profissional agrega do que ter meios formais de comprová-lo.

Este episodio do podcast Software Engineering Radio fala justamente sobre esse assunto; traz uma visão do que é esperado de pessoas desempenhando cada um dos papéis envolvidos em um time de Desenvolvimento de Software. Tal tipo de reflexão poderia ser muito útil, não só para servir como modelo para analisar o desempenho de cada pessoa em uma organização mas, também, para ajudar pessoas que queiram alinhar seu desenvolvimento pessoal aos objetivos de sua organização.

Disseminar este conhecimento pela empresa, fazendo com que as pessoas saibam o que delas é esperado, poderia contribuir, fortemente, para seu crescimento na empresa e, também, seu desenvolvimento pessoal. Valorizando os profissionais compõem uma equipe, estaremos contribuindo, também, para a criação de um ambiente melhor, onde as pessoas têm uma maior clareza de que sua ascenção na organização e seu sucesso profissional dependem puramente de seu próprio esforço e mérito.

Dessa vez um post bem rápido; estava planejando fazer um estudo sobre servidores de hospedagem virtuais, contudo, o Rafael Lima foi mais rápido e fez essa excelente avaliação diferentes provedores especializados neste tipo de serviço.

Para qualquer um pensando em mudar de hospedagem e/ou conhecer este tipo de opção para os próximos projetos, esse post é uma grande pedida.

Um grande abraço e até a próxima!

Rails Rumble 2008!

Neste último final de semana participei do Rails Rumble 2008, a segunda edição de um concurso, de nível internacional, onde o objetivo é se desenvolver a melhor aplicação rails no em até 48 horas - do início ao fim. Não é permitido a criação de nenhum tipo de material digital. Toda a infra-estrutura do projeto, deploy da aplicação e setup do ambiente de produção também devem ser feitos dentro deste período. Ou seja, é necessário muito planejamento prévio, uma boa idéia e uma boa dose de pragmatismo.

Além destes fatores, também é necessário uma boa equipe. Posso dizer, com absoluta certeza, que, neste aspecto, tive muita sorte; a nossa equipe foi composta de profissionais profundamente comprometidos e talentosos.

A equipe January River (pra ser bem brazuca mesmo! rsrs) foi composta por:

• Bruno Dulcetti - HTML/CSS Combo Hit Master.
  
• Bruno Carvalho - Engenheiro de Software
• Vinícius Pellegrino - Designer e Ilustrador.
• Vitor Pellegrino - Engenheiro de Software

Té parece que rolou tanta concentração assim... rsrs

Bruno Carvalho, Bruno Dulcetti, Vinicius Pellegrino e eu

A ideía da nossa aplicação veio através de uma sugestão do Bruno Carvalho: uma aplicação onde fosse possível que os usuários enviassem fotos sobre o que comem. Essa idéia de se tirar fotos das suas refeições é algo que vêm sendo bastante utilizado lá fora e que tem o nome de flash diet. O próprio fantástico fez uma matéria bastante legal sobre esse tipo de dieta.

O nosso propósito era de fazer um site bem moderno, com um visual bem atual e descontraído, que fosse bem direto ao seu objetivo - ajudar pessoas a manterem um diário de sua dieta através da internet. O resultado desta aventura pode ser encontrado em http://rio.r08.railsrumble.com. (Você também pode ajudar a gente e votar através deste link :D).

Entretanto, apenas uma equipe talentosa, uma idéia legal e muita vontade de fazer não são suficientes:
Em resumo, poderia dizer que aprendi algumas lições:

1. Planeje bem o que você quer fazer ANTES. Perdemos muito tempo por chegarmos no dia que o projeto começou sem uma idéia clara e compartilhada com todos os membros da equipe. Definimos todas as telas, logos e funcionalidades no dia do projeto. Ou seja, tinha que dar errado… rs
2. Por mais simples que seja o projeto, divida em histórias (ou tarefas, ou casos de uso… ou qualquer representação de uma funcionalidade do sistema) e só parta para a próxima quando a anterior esteja finalizada e testada. Tivemos que abrir mão de diversas funcionalidades parcialmente prontas pois ao final do projeto elas não tinham condições de subir. Ou seja, trabalho jogado fora por falta de organização do time.
3. Seja pragmático. Saiba avaliar a razão entre custo x benefício de cada linha de código e/ou decisão tomada. Isso é fundamental para que não se perca tempo demais polindo uma funcionalidade específica e acabar faltando tempo para terminar o resto do sistema.
4. Teste sua aplicação.
5. Teste mais. Isso evita que bugs críticos sejam encontrados 20 minutos antes da entrega de um sistema e que tenham que ser corrigidos em menos tempo ainda.
6. Priorize e saiba priorizar. Organize seu trabalho de forma a construir as funcionalidades/tarefas que trarão maior retorno mais cedo.

Tivemos vários problemas. Infelizmente, foi necessário cortar mais que 80% do sistema poucas horas antes do final do concurso pois não conseguiríamos terminar a tempo. Um outro problema que foi muito grave, é que não tivemos qualquer tipo de planejamento antes do início do projeto. Todo o site, desde sua concepção, design, arquitetura foram construídos durante o concurso. Era permitido, às equipes, que qualquer tipo de planejamento, desenho (desde que não em forma digital) e modelagem da arquitetura pudessem ser feitos. Isso é uma vantagem enorme que não pudemos aproveitar.

Esta falta de planejamento à priori, também surtiu efeito na forma como executamos nossas tarefas - por não termos dividido em tarefas e funcionalidades de forma bem contida, nós não trabalhamos de forma muito eficiente e perdemos muito tempo fazendo coisas que não se encaixaram (e jamais se encaixaríam) bem com o produto como um todo.

Mesmo com todos os problemas, não tenho dúvidas que participar de um projeto como esse foi uma das melhores experiências em minha vida profissional; uma verdadeira aula de porque os projetos dão e não dão certo. Muitas das coisas que vemos nos longos projetos por aí, foram refletidas nestas 48 horas. Numa competição como esta, é necessário fazer escolhas a cerca de escopo, de composição da equipe (já que o número de participantes é limitado de até 4 pessoas), de processo de desenvolvimento e - ainda que  inicialmente desprezado por nós - gerência de projeto propriamente dita.

Depois do railsrumble, a vontade de realizarmos este projeto foi multiplicada. Portanto, aguardem surpresas e, podem ter certeza, que o picmydiet não vai ficar só por aí

Um grande abraço e até a próxima!

Pois é. Depois de um breve hiato deste blog, resolvi escrever este post para marcar a “reinauguração deste espaço”

Desde a útlima vez em que escrevi algo por aqui, muitas coisas aconteceram: finalmente, concluí a graduação!!

PUC-Rio goodbye, farewell, see you later! :)

Essa é a primeira razão pela qual me faltou o tempo para dar a devida atenção que este espaço requer. O final da faculdade foi algo que me exigiu uma dedicação enorme - tenho certeza que vocês compreendem Terminada a graduação, hoje carrego, comigo, a certeza de ter conhecido pessoas fantásticas que tenho orgulho de chamar de amigos.

Neste meio tempo, participei, junto com o Tiago Peczenyj, de um workshop fantástico com Bruce Eckel, realizado pelo pessoal da Python Brasil, onde foi possível discutir com o criador do primeiro livro de Java que li. Foi uma oportunidade singular para trocar idéias, discutir conceitos e aprender diretamente com esse cara que é referência em arquitetura e desenvolvimento de software. Além de tudo, serviu para aumentar, ainda mais, a certeza de que estamos trilhando o caminho certo lá na Globo.com.

Workshop thinking in patterns

Um grande abraço pro Luciano Ramalho, Hugo Corbucci, Leandro Lameiro, Ramiro, pessoal da Python Brasil, pro Rafael da PUC de campinas e toda a galera que conheci durante o workshop. Sobre as coisas aprendidas no evento - e ainda melhor compreendidas após ele - dedicarei alguns posts em breve.

Até a próxima!

Hoje em dia, a idéia de Intraempreendedorismo (ou intrapreneurship, do inglês) está cada vez mais em evidência. Este profissional, capaz de tomar decisões importantes e identificar pontos fortes e oportunidades de melhoria, mesmo que ainda que não ocupe cargos de gerência, é cada vez mais procurado pelas empresas, indicando que este é um caminho a ser seguido.

Mas o que é intraempreendedorismo?

Como ponto de partida, tomemos a definição da wikipedia:

Intrapreneurship is the practice of entrepreneurial skills and approaches by or within a established organization.

Ou seja, intraempreendedor é aquele que trata a empresa onde trabalha como se fosse a sua. Usando de todo o espírito empreendedor que possua, em busca de oportunidades para o negócio, é aquele que não se atem somente aos limites de sua “função” dentro da empresa, mas que, sim, procura ter a noção do todo e, principalmente, de como melhor contribuir para que a organização atinja seus objetivos.

Mas o que o Scrum tem haver com isso?

Absolutamente tudo! Na verdade, o Scrum depende, fortemente, que os integrantes compartilhem desta visão intraempreendedora.

Hoje aconteceu o segundo e último dia do Workshop de Modelagem Ágil e DDD organizado pela Fratech.

É bem legal a oportunidade de trocar experiências e bater um papo com um pessoal bem legal aqui de São Paulo. É muito bom ver como a adoção de metologias e processos ágeis se dá “no mundo real” além das fronteiras da Globo.com - que era, até então, um dos pouquíssimos lugares em que eu conhecia (direto de quem faz rs) histórias do pessoal que trabalha com agile no Brasil.

O primeiro dia do Workshop foi dedicado aos processos Agile: maneiras de usar modelos UML e extensões dele como forma de comunicação em um projeto ágil. O Manuel Pimentel também apresentou uma proposta de um template para a modelagem e documentação de um projeto de software usando Mapas Mentais para a melhor visualização de diferentes aspectos envolvidos na construção do mesmo. A idéia - a qual ele chama de Mind Map Modeling, ou M3 - pode ser interessante para dar um overview do que acontece em um sistema específico, tanto no aspecto de tecnologia/design quanto no aspecto do domínio da aplicação.

No segundo dia, foi a vez de Felipe Rodrigues apresentar a parte dedicada ao Domain Driven Design e como este se encaixa neste contexto ágil, melhorando a comunicação entre time de desenvolvimento e Domain Experts. Esta palestra foi muito interessante pois, o conhecimento da turma sobre o assunto era bastante heterogêneo mas, mesmo assim, no final das contas, deu pra sentir que a galera conseguiu absorver grande parte do conteúdo, ainda que fosse bem extenso.

As discussões, ao meu ver, foram o melhor da apresentação; foi muito produtiva toda a movimentação que o assunto proporcionou entre os participantes do workshop. As questões e observações que foram aparecendo foram fundamentais para solidificar o conteúdo apresentado. Muito bom mesmo.

Para mim, particularmente, foi uma grande oportunidade, uma vez que pude aprofundar um conhecimento que era, até então, meio superficial. Agora, com certeza, irei tirar o livro do Eric Evans da estante e ler até o final desta vez! rs

Foi muito legal, também, ver o interesse de pessoas que não são de tecnologia, mas, sim, de negócios, por métodos mais eficazes de fazer software que os atenda plenamente - uma prova de que os cases de sucesso das metodologias ágeis e novas formas de desenvolvimento de software já estão chegando aos ouvidos de quem paga por ele, não apenas de quem o produz.

Um grande abraço aí pra galera de sampa - super gente fina - que aguentou esse carioca maluco durante os dois dias em que aconteceu este Workshop!

Ahh… amanhã tem Falando em java e a galera da globo.com aqui, com certeza, estará presente mais uma vez!

Grande abraço e até breve!

Nesta quinta-feira, iremos um pessoal aqui da Globo.com (Bruno Carvalho, Guilherme Chapiewski, Guilherme Cirne entre outros rs) a São Paulo para participar de alguns eventos: o primeiro deles é um Workshop sobre Modelagem Ágil e Domain-Driven Design que acontecerá na sexta e no sábado. Já, no domingo, estaremos no Falando em Java 2008.

Vai ser uma oportunidade bem legal para conhecer esse pessoal de Sampa e rever antigos amigos! Se estiver por perto, dê uma passada lá pois, com certeza, serão grandes eventos!

Um grande abraço e até a próxima!

Atualmente, a empresa mais notória por este tipo de prática, sem sombra de dúvidas, é a Google; é inevitável chegar a conclusão de que, mesmo “trabalhando somente 80% do tempo” (como alguns poderiam pensar) estes caras são muito bons em matéria de produtividade e criatividade.
Este tipo de ambiente (tão almejado pelos desenvolvedores e pessoal de tecnologia) muitas vezes, se torna difícil de se justificar perante a diretoria da maioria das empresas; executivos são pessoas que estão acostumadas com números resultados mais “palpáveis”.

Mas será que este tipo de incentivo se torna  válido apenas quando projetos como Orkut ou o Google Reader emergem da criatividade de seus funcionários? Será que existem somente benefícios diretos desta prática?

Desde que a Atlassian (empresa que criou o Jira, o Confluence dentre outros projetos muito interessantes) anunciou publicamente que iria investir na criação de um projeto de incentivo à criatividade de seus funcionários, os liberando de 20% da sua carga horária para que estes pudessem investir em seus projetos pessoais, muita gente vem comentando por aí.

Este artigo traz excelentes considerações sobre os benefícios diretos e indiretos que este tipo de incentivo pode causar numa organização. Além de todos estes pontos, eu gostaria de ressaltar algumas outras coisas, do ponto de vista de quem trabalha numa empresa onde existe este tipo de política :

Conhecimento gera conhecimento.

Se um funcionário não trabalha em um projeto específico durante 20% do seu tempo, isso não quer dizer que ele não esteja produzindo nada para a empresa - conhecimento, ainda mais hoje em dia, vale ouro. Certamente, através da experimentação nestes projetos pessoais, este mesmo funcionário adquire um conhecimento prático que poderá ser muito útil no seu próximo projeto para a organização.

Certamente, o conhecimento adquirido durante estes projetos pessoais, se multiplica na empresa: aqui na Globo.com, temos os Techtalks, palestras dadas pelos próprios funcionários sobre tecnologias, abordagens ou qualquer coisa que seja relacionada à tecnologia. Seja na forma de palestras, quanto no seu emprego em outros projetos este valioso momento para experimentação e iniciativa pessoal não é perdido - de maneira alguma.

Grandes idéias surgem de onde menos se espera

Este, sem dúvidas, é um dos  argumentos mais comuns para a adoção deste tipo de política. Entretanto, é importante ressaltar que boas idéias vêm em forma de produtos - as vezes uma grande idéia pode surtir efeito na mudança de uma metodologia que pode representar valor para a empresa da mesma maneira.

Pessoas talentosas e auto-motiváveis precisam de um ambiente adequado.

Como nunca, as empresas começaram a ver que para ter um time produtivo de verdade, é preciso investir - e muito! - na qualidade do pessoal, bem como na qualidade do ambiente de trabalho deste. Wiis e Xboxes são elementos cada vez mais comuns nos escritórios por aí (na globo.com temos os dois rsrs) :).

Não somente contratar talentos, é preciso retê-los na organização. Dar um voto de confiança aos funcionários pode ter resultados surpreendentes; formar um ambiente onde a iniciativa pessoal é valorizada e fomentada, realmente, ajuda  bastante tanto na contratação quanto na retenção destes.

Além de implementar esta política, o pessoal da Atlassian resolveu documentar o que for acontecendo neste blog e neste feed. Fica aí a dica para quem quiser saber como é um ambiente deste tipo mais de perto.

Um grande abraço e até a próxima!

Código incompreensível, complexidade desnecessária são problemas que qualquer pessoa que trabalhe com desenvolvimento de software já encontrou e, provavelmente, irá encontrar ainda por diversas vezes em sua vida profissional. Muitas das vezes, nos pegamos pensando de forma já não tão ética: “como é que alguém me escreve um código assim!?” ainda pior é quando nós mesmos é que contruimos código que não somos capazes de manter - “sei lá o que isso aqui faz, é que eu dei um control + c e um control + v naquela função lá e mudei pro que eu precisava”.

Precisava criar uma outra página na aplicação que tinha algumas semelhanças com uma outra já existente - “ah é só copiar o que beltrano fez, retirar a parte do votação, retirar a parte dos comentários, e acrescentar mas umas duas ou outras coisinhas”, me disse o líder técnico. O somatório disso tudo era claro - de igual, só tinha a listagem de produtos mesmo. Beleza, consegui fazer o que precisava mas não entendia muito bem o que estava fazendo.

Dia seguinte, um outro colega que precisava fazer uma outra listagem que não tinha nada a ver com produto, mas tinha algo que lembrava o que tinha feito no dia anterior. Como era comum naquele projeto, este recebeu o mesmo conselho “só copiar o que o Vitor fez e mudar umas coisinhas!”. Era evidente que aquilo não tinha como dar certo, tentei avisar mas não deu muito certo, afinal, “o projeto já estava atrasado”.

O sistema foi desenvolvido quase todo baseado nessas “implementações de referência”. Refactor? Ninguém na equipe cogitaria fazer isso num projeto que nem testes tinham pois “não dava tempo pra fazer essas coisas, o prazo era curto”. O código era absolutamente ilegível e, por diversos momentos, eu me indagava como aquiloa sequer compilava. Naquela situação, nada que eu dissesse adiantaria

As vezes parecia que ía desmoronar…

Depois de tantos ctrl+c e ctrl+v a torto e a direito, mal dava para lembrar que o código que serviu como “referência” para as outras funcionalidades, tinha sido feito às pressas , pela pessoa com menos experiência do time, inclusive. A situação era tão crítica que até alguns comentários de “TODO: Refactor this” foram copiados de um lugar para o outro - refactor este que, logicamente, nunca aconteceu.

Meu conselho é simples, na próxima vez que tiver um código de referência, não faça um copy and paste de tudo, mas o escreva com suas próprias mãos - isso faz com que seja muito mais fácil encontrar trechos que não são necessários na sua solução e ainda ajuda no melhor entendimento do código. Ahhh… e quando for fazer isso, não se esqueça dos testes unitários, claro.