Posts de ‘Guilherme Cirne’

[Guilherme Cirne] 7 Meses de Time Beta: Um Balanço

Wednesday, April 7th, 2010

Já se vão 7 meses que estou no Time Beta na Globo.com e vou aproveitar a oportunidade para fazer um balanço de como tem sido até aqui.  O que estamos fazendo de interessante, o que aprendemos, o que podemos melhorar, etc. Mas antes, um disclaimer: as opiniões aqui são minhas e não necessariamente refletem a opinião do time como um todo. No entanto, acredito que o time concorda com tudo que está escrito aqui.

Nesses 7 meses trabalhamos no Baixatudo, o site de downloads da Globo.com que já existia há algum tempo. Já no primeiro mês colocamos no ar uma nova versão, que foi sendo evoluída e refinada até chegar no que temos hoje.

Infra

Um dos pontos que acredito que estamos bem é na infraestrutura do projeto. Nosso time é 100% responsável por todas as questões de infra. Provisionamento de máquinas, instalação de SO, configuração de servidores de cache, de aplicação, de banco de dados, de busca, balanceamento de carga, monitoração, tudo é nossa responsabilidade. Por isso mesmo, praticamente toda a administração da nossa infra é automatizada. O grande benefício disso é que conseguimos mudar a arquitetura da aplicação, atualizar versões, mexer nas configurações, etc., com bastante segurança e agilidade. O assunto é bastante extenso e interessante e certamente merece um outro post detalhando melhor como funciona nossa infra.

Agile UX

Outro ponto que acredito que estamos bem é na questão de Agile UX, ou seja, como integrar UX com desenvolvimento ágil. É um assunto que pessoalmente me interessa muito e acredito que nesse time chegamos num ponto bastante positivo. Esse assunto também merece um post bem detalhado que pretendo publicar em breve. Mas basicamente, o que acontece é que tentamos garantir 2 coisas.

Uma é que o time esteja trabalhando junto na mesma funcionalidade. Enquanto o designer desenha as interfaces/fluxos/interações/variações de componentes, os outros membros do time já trabalham no seu desenvolvimento. A comunicação é rica e constante. Todo mundo dá palpite sobre UX e todo mundo desenvolve, inclusive o próprio designer que contribui com o html e css.

A outra coisa é que no final de cada iteração a gente tem uma funcionalidade tecnicamente pronta. Muitas vezes ela não está boa o suficiente para ser disponibilizada para o usuário final mas funciona do ponto de vista técnico. É em cima disso que a gente colhe feedback para refiná-la nas iterações seguintes e não em cima de telas ou outros artefatos não funcionais.

Testes A/B

Começamos a usar o Google Website Optimizer para fazer testes A/B e estamos empolgados com os resultados obtidos. O objetivo é evitar tomar decisões de UX e de produto baseadas exclusivamente em achismos. Queremos dados para ajudar nas nossas decisões. Até aqui fizemos 2 testes.

O primeiro foi para escolher o melhor texto no botão de download de um software. Inicialmente esse texto era ‘download’. Criamos uma variação com o texto ‘baixar’. O resultado foi que a segunda opção tinha uma conversão maior e por isso é ela que está no ar até hoje.

No segundo, experimentamos uma variação nos thumbs que consistia em exibir o número de downloads em cima do thumb. Uma alteração simples e que todos concordavam que deixava o produto mais bonito. Mas a conversão nesse caso era bem pior. Os usuários clicavam menos na variação que tinha os números de downloads. Por isso, essa mudança não foi implementada de forma definitiva.

Outros

Outros dois pontos que considero interessante mencionar.

O primeiro é que tentamos trabalhar num ritmo sustentado, sem pegar mais do que o time aguenta. Na única vez que trabalhamos de madrugada o resultado não foi bom. Os stakeholders não gostaram do que foi entregue e isso acabou refletindo temporariamente na motivação do time.

O outro é que tentamos manter nosso processo o mais enxuto possível. Praticamente não existem tarefas, reuniões, etc., que não agregam valor ao produto.

Resultado

O resultado disso tudo, aliado ao excelente trabalho da equipe de editores, é um aumento significativo na audiência do Baixatudo. E stakeholders satisfeitos.

A partir de agora estamos partindo para outro produto. Sabemos que ainda temos muito a evoluir, mas acredito que estamos no caminho certo. Estamos conseguindo mostrar o valor de times pequenos (4-5 pessoas no nosso caso), autônomos, ágeis.

[Guilherme Cirne] 7 Meses de Time Beta: Um Balanço

Wednesday, April 7th, 2010

Já se vão 7 meses que estou no Time Beta na Globo.com e vou aproveitar a oportunidade para fazer um balanço de como tem sido até aqui.  O que estamos fazendo de interessante, o que aprendemos, o que podemos melhorar, etc. Mas antes, um disclaimer: as opiniões aqui são minhas e não necessariamente refletem a opinião do time como um todo. No entanto, acredito que o time concorda com tudo que está escrito aqui.

Nesses 7 meses trabalhamos no Baixatudo, o site de downloads da Globo.com que já existia há algum tempo. Já no primeiro mês colocamos no ar uma nova versão, que foi sendo evoluída e refinada até chegar no que temos hoje.

Infra

Um dos pontos que acredito que estamos bem é na infraestrutura do projeto. Nosso time é 100% responsável por todas as questões de infra. Provisionamento de máquinas, instalação de SO, configuração de servidores de cache, de aplicação, de banco de dados, de busca, balanceamento de carga, monitoração, tudo é nossa responsabilidade. Por isso mesmo, praticamente toda a administração da nossa infra é automatizada. O grande benefício disso é que conseguimos mudar a arquitetura da aplicação, atualizar versões, mexer nas configurações, etc., com bastante segurança e agilidade. O assunto é bastante extenso e interessante e certamente merece um outro post detalhando melhor como funciona nossa infra.

Agile UX

Outro ponto que acredito que estamos bem é na questão de Agile UX, ou seja, como integrar UX com desenvolvimento ágil. É um assunto que pessoalmente me interessa muito e acredito que nesse time chegamos num ponto bastante positivo. Esse assunto também merece um post bem detalhado que pretendo publicar em breve. Mas basicamente, o que acontece é que tentamos garantir 2 coisas.

Uma é que o time esteja trabalhando junto na mesma funcionalidade. Enquanto o designer desenha as interfaces/fluxos/interações/variações de componentes, os outros membros do time já trabalham no seu desenvolvimento. A comunicação é rica e constante. Todo mundo dá palpite sobre UX e todo mundo desenvolve, inclusive o próprio designer que contribui com o html e css.

A outra coisa é que no final de cada iteração a gente tem uma funcionalidade tecnicamente pronta. Muitas vezes ela não está boa o suficiente para ser disponibilizada para o usuário final mas funciona do ponto de vista técnico. É em cima disso que a gente colhe feedback para refiná-la nas iterações seguintes e não em cima de telas ou outros artefatos não funcionais.

Testes A/B

Começamos a usar o Google Website Optimizer para fazer testes A/B e estamos empolgados com os resultados obtidos. O objetivo é evitar tomar decisões de UX e de produto baseadas exclusivamente em achismos. Queremos dados para ajudar nas nossas decisões. Até aqui fizemos 2 testes.

O primeiro foi para escolher o melhor texto no botão de download de um software. Inicialmente esse texto era ‘download’. Criamos uma variação com o texto ‘baixar’. O resultado foi que a segunda opção tinha uma conversão maior e por isso é ela que está no ar até hoje.

No segundo, experimentamos uma variação nos thumbs que consistia em exibir o número de downloads em cima do thumb. Uma alteração simples e que todos concordavam que deixava o produto mais bonito. Mas a conversão nesse caso era bem pior. Os usuários clicavam menos na variação que tinha os números de downloads. Por isso, essa mudança não foi implementada de forma definitiva.

Outros

Outros dois pontos que considero interessante mencionar.

O primeiro é que tentamos trabalhar num ritmo sustentado, sem pegar mais do que o time aguenta. Na única vez que trabalhamos de madrugada o resultado não foi bom. Os stakeholders não gostaram do que foi entregue e isso acabou refletindo temporariamente na motivação do time.

O outro é que tentamos manter nosso processo o mais enxuto possível. Praticamente não existem tarefas, reuniões, etc., que não agregam valor ao produto.

Resultado

O resultado disso tudo, aliado ao excelente trabalho da equipe de editores, é um aumento significativo na audiência do Baixatudo. E stakeholders satisfeitos.

A partir de agora estamos partindo para outro produto. Sabemos que ainda temos muito a evoluir, mas acredito que estamos no caminho certo. Estamos conseguindo mostrar o valor de times pequenos (4-5 pessoas no nosso caso), autônomos, ágeis.

[Guilherme Cirne] Lei de Demeter e Ruby

Tuesday, December 8th, 2009

Na semana passada tivemos uma discussão bem interessante na Globo.com sobre Lei de Demeter e ruby. Basicamente a questão era: faz sentido se aplicar a Lei de Demeter quando se está usando uma linguagem dinâmica como ruby?

(Para entender o que é a Lei de Demeter, vale a leitura do artigo na Wikipedia).

Ao seguir a lei de Demeter o código escrito tende a ter um acoplamento mais baixo e, portanto, é mais fácil de manter e evoluir. Por outro lado, quando a lei é violada, o acoplamento aumenta. Isso independe se a linguagem utilizada é dinâmica ou não. Ao enviar uma mensagem para um colaborador do colaborador você está aumentando o acomplamento.

Na minha opinião, a questão correta para se discutir é somente: faz sentido aplicar a Lei de Demeter? E, nesse caso, a resposta é a já manjada “depende”.

Assim, sem nenhum contexto, aplicar Demeter faz sentido. Acoplamento baixo é algo desejável. Mas, dependendo do caso, o custo de aplicar a lei pode não compensar. Por exemplo, se o modelo de domínio é muito simples, com pouquíssimas regras de negócio, podemos ser mais pragmáticos, não aplicando a lei, sem que isso tenha maiores consequências.

Como quase tudo que fazemos no nosso dia a dia, trata-se de uma questão de entender o conceito e pesar seus prós e contras dentro de um contexto para então decidir o que fazer.

[Guilherme Cirne] Lei de Demeter e Ruby

Tuesday, December 8th, 2009

Na semana passada tivemos uma discussão bem interessante na Globo.com sobre Lei de Demeter e ruby. Basicamente a questão era: faz sentido se aplicar a Lei de Demeter quando se está usando uma linguagem dinâmica como ruby?

(Para entender o que é a Lei de Demeter, vale a leitura do artigo na Wikipedia).

Ao seguir a lei de Demeter o código escrito tende a ter um acoplamento mais baixo e, portanto, é mais fácil de manter e evoluir. Por outro lado, quando a lei é violada, o acoplamento aumenta. Isso independe se a linguagem utilizada é dinâmica ou não. Ao enviar uma mensagem para um colaborador do colaborador você está aumentando o acomplamento.

Na minha opinião, a questão correta para se discutir é somente: faz sentido aplicar a Lei de Demeter? E, nesse caso, a resposta é a já manjada “depende”.

Assim, sem nenhum contexto, aplicar Demeter faz sentido. Acoplamento baixo é algo desejável. Mas, dependendo do caso, o custo de aplicar a lei pode não compensar. Por exemplo, se o modelo de domínio é muito simples, com pouquíssimas regras de negócio, podemos ser mais pragmáticos, não aplicando a lei, sem que isso tenha maiores consequências.

Como quase tudo que fazemos no nosso dia a dia, trata-se de uma questão de entender o conceito e pesar seus prós e contras dentro de um contexto para então decidir o que fazer.

[Guilherme Cirne] Novos Desafios…

Sunday, September 27th, 2009

… na Globo.com!

Desde o início do mês estou fazendo parte de um novo time. Trata-se do Time Beta (Peleteiro, Meyer, Bruno Neves e eu), responsável pelo desenvolvimento de novos produtos (ou novas versões de produtos existentes). Nosso primeiro produto é o Baixatudo, cujo release inicial já está no ar. Consideramos esse release uma versão bem básica do produto. Temos muito trabalho ainda pela frente e esperamos nos próximos releases entregar um produto cada vez melhor.

O lado ruim dessa mudança é sair do time de webmedia, onde tive a oportunidade de trabalhar com pessoas fodas e aprendi bastante! Nesse tempo que estive lá, trabalhamos em projetos bem interessantes. Além disso, acredito que tivemos algumas evoluções significativas, como:

  • Melhor preparação do backlog, envolvendo os especialistas de UX junto com o PO para deixar as histórias prontas pro time implementar (ainda há muito que melhorar nisso, mas acredito que foi dado um importante primeiro passo). Mais sobre isso em um post que já está tempo demais no meu drafts;
  • Cultura de deixar bem explícito os problemas que estamos enfrentando, com dados concretos, mostrando os impactos no projeto;
  • Grande preocupação com práticas ágeis como programação em par, desenvolvimento outside-in, TDD, BDD, integração contínua, etc. Sempre feito de forma pragmática, ou seja, focado em melhorar o desempenho do time e não por se tratar da última moda.

Por outro lado, no novo time estou bastante empolgado pois volto a exercer um papel mais de desenvolvimento. Tenho certeza que vou aprender e evoluir bastante e espero poder contribuir para o sucesso dos nossos projetos.

Ah, não se esqueça, estamos contratando!

[Guilherme Cirne] Novos Desafios…

Sunday, September 27th, 2009

… na Globo.com!

Desde o início do mês estou fazendo parte de um novo time. Trata-se do Time Beta (Peleteiro, Meyer, Cainã Nunes e eu), responsável pelo desenvolvimento de novos produtos (ou novas versões de produtos existentes). Nosso primeiro produto é o Baixatudo, cujo release inicial já está no ar. Consideramos esse release uma versão bem básica do produto. Temos muito trabalho ainda pela frente e esperamos nos próximos releases entregar um produto cada vez melhor.

O lado ruim dessa mudança é sair do time de webmedia, onde tive a oportunidade de trabalhar com pessoas fodas e aprendi bastante! Nesse tempo que estive lá, trabalhamos em projetos bem interessantes. Além disso, acredito que tivemos algumas evoluções significativas, como:

  • Melhor preparação do backlog, envolvendo os especialistas de UX junto com o PO para deixar as histórias prontas pro time implementar (ainda há muito que melhorar nisso, mas acredito que foi dado um importante primeiro passo). Mais sobre isso em um post que já está tempo demais no meu drafts;
  • Cultura de deixar bem explícito os problemas que estamos enfrentando, com dados concretos, mostrando os impactos no projeto;
  • Grande preocupação com práticas ágeis como programação em par, desenvolvimento outside-in, TDD, BDD, integração contínua, etc. Sempre feito de forma pragmática, ou seja, focado em melhorar o desempenho do time e não por se tratar da última moda.

Por outro lado, no novo time estou bastante empolgado pois volto a exercer um papel mais de desenvolvimento. Tenho certeza que vou aprender e evoluir bastante e espero poder contribuir para o sucesso dos nossos projetos.

Ah, não se esqueça, estamos contratando!

[Guilherme Cirne] Dev in Rio 2009: Eu Vou!

Sunday, August 30th, 2009

No dia 14/09 vai rolar um evento aqui no Rio de Janeiro que promete ser um sucesso: Dev in Rio 2009. E, claro, eu não poderia deixar de estar presente. Organizado pelo meu amigo Guilherme Chapiewski e pelo Henrique Bastos, contará com a presença de grandes nomes nacionais e internacionais falando sobre Open Source, Java, Ruby on Rails, Django e Desenvolvimento Ágil.

Nos vemos lá!

Dev in Rio 2009

[Guilherme Cirne] Dev in Rio 2009: Eu Vou!

Sunday, August 30th, 2009

No dia 14/09 vai rolar um evento aqui no Rio de Janeiro que promete ser um sucesso: Dev in Rio 2009. E, claro, eu não poderia deixar de estar presente. Organizado pelo meu amigo Guilherme Chapiewski e pelo Henrique Bastos, contará com a presença de grandes nomes nacionais e internacionais falando sobre Open Source, Java, Ruby on Rails, Django e Desenvolvimento Ágil.

Nos vemos lá!

Dev in Rio 2009

[Guilherme Cirne] Scrum Gathering Brazil 2009

Monday, May 11th, 2009

Nesta terça (12/05) e quarta (13/05) estarei no Scrum Gathering Brazil 2009. O evento promete, com apresentações de profissionais nacionais e internacionais.

O que rolar no evento vou postar aqui ou no meu twitter.

[Guilherme Cirne] Scrum Gathering Brazil 2009

Monday, May 11th, 2009

Nesta terça (12/05) e quarta (13/05) estarei no Scrum Gathering Brazil 2009. O evento promete, com apresentações de profissionais nacionais e internacionais.

O que rolar no evento vou postar aqui ou no meu twitter.