O que queria provar é que é possível desenvolver um produto de forma incremental, feature a feature, aplicando um processo 100% ágil e entregando resultado rápidamente, contando com a participação de usuários reais e não baseado em achismos. Este produto hoje se chama Yahoo! Meme e vou compartilhar aqui pouco de como foi esta experiência.

Assim que cheguei no Yahoo! tive de montar a equipe, neste quesito eu já tinha certeza dos papéis que precisava:

• um Designer que escrevesse código e fosse responsável pela implementação 100% da Interface
• Desenvolvedores que gostassem de TDD e que topassem fazer qualquer coisa: frontend, backend, costurar, cozinhar, etc
• um Product Owner (PO) que tivesse conhecimento técnico e entendesse de Internet.

Enquanto o processo de entrevistas e seleção da equipe rolava, eu já havia encontrado o nosso PO (Pedro Valente) e começamos a montar alguns processos de Ideation e Filtragem de ideias, começamos a fazer vários brainstorms e o resultado foi um “framework” (ou um arcabouço como diriam alguns teóricos brasileiros ) para selecionar e filtrar ideias de uma forma mais ou menos científica e menos baseada em achismos e sentimentos.

Alguns pontos deste framework:

• Definir um público alvo: nosso caso Jovens 16-32 anos;
• Encontrar problemas reais e de grande impacto que ainda não tenham sido totalmente resolvidos;
• Encontrados os problemas, existem Players no mercado que solucionam este problema? Podemos resolver de uma forma melhor? Podemos simplificar a solução?
• Com as possíveis soluções, começamos a esboçar em que produtos aplicaríamos as mesmas.
• Legal, tínhamos encontrado alguns problemas que poderíamos resolver e suas possíveis soluções, neste momento aplicamos alguns filtros para selecionar qual seria o produto que começaríamos a “prototipar”. Este filtros não passam de umas 8 perguntas com respostas binárias (sim e não) que aplicávamos a todas as ideias, depois ordenamos as idéias pelas que tinham mais respostas “sim”

OBS: quando eu falo prototipar estou me referindo a desenvolver as features principais do produto. A entrega do protótipo é software funcionando e não telinhas e flashizinhos ou PPTs

Em paralelo a equipe foi sendo selecionada e já estávamos completos para começar a montar nosso ambiente de desenvolvimento e a escrever as principais User Stories do nosso primeiro protótipo. Este é um dos momentos onde o fato de termos um Product Owner com conhecimento técnico é vital, pois grande parte das primeiras User Stories seriam de infraestrutura básica do produto, o desenvolvimento das provas de conceito para confirmarmos a viabilidade do produto.

A entrega deste Sprint Zero, em Dezembro de 2008, seria algo muito mais técnico e menos visual e ainda teríamos que entregar os ambientes de Desenvolvimento, Continuous Integration, Staging, etc. O PO precisa ter sensibilidade para entender o que é importante ser priorizado e que algumas vezes as entregas serão mais técnicas (mas sempre sem perder o foco no usuário final).

Com as peças em seus devidos lugares, iniciamos o desenvolvimento do nosso primeiro produto e quando participei do primeiro Sprint Review, sabia que tínhamos algo na mão que pudesse dar um bom resultado. O projeto nesse momento tinha o codename de “GoodStuff”, pois queríamos permitir que os usuários tivessem um lugar onde eles pudessem propagar coisas legais (good stuff) que eles encontrassem pela Internet de forma fácil e rápida

E assim começamos a desenvolver User Story a User Story, funcionalidade por funcionalidade e em Fevereiro de 2009 fizemos nosso primeiro release interno dentro da rede do Yahoo!, apenas alguns poucos Yahoos poderiam usar o produto e nos dar feedback. O interessante é que o produto em si, possuía apenas algumas poucas funcionalidades, o que definimos como os maiores diferenciais e precisamos saber se estávamos realmente no caminho certo, para isso nada melhor do que ouvir usuários de verdade.

Para se ter uma ideia de como o produto estava no básico do básico o thumbnail/avatar de todos os usuários era fixo (usavamos uma imagem do Vitor Fasano), que depois virou uma User Story: “Eu como usuário não quero mais ter o thumbnail do Vitor Fasano”.

Assim caminhamos por mais alguns Sprints, repriorizamos as Stories baseadas no feedback dos usuários, mas sem perder o foco no objetivo que traçamos para o Produto, sobre este assunto eu sempre gosto de citar uma frase de Henry Ford na ocasião do lançamento do Ford T.

“Se eu perguntasse para meus clientes o que eles gostariam, eles me responderiam: Cavalos mais rápidos”

É muito importante ter a visão de onde você quer chegar e depois ir adaptando o caminho que você toma com base no que seus usuários dizem e em como o mercado evolui.

Fomos aumentando o número de Yahoos com acesso ao produto, coletando mais feedback e em Abril deste ano chegamos ao ponto onde tínhamos o que classificamos como “good enough” e fizemos um lançamento que chamamos de “Friends and Family“, foi a primeira vez que o produto foi aberto para usuários externos ao Yahoo!, foi neste momento que escolhemos o nome Meme. A equipe convidou alguns familiares e amigos e cada um destes tinha o direito a convidar outros 3 amigos e assim por diante, chamamos esta fase de Private Alpha.

Agora com mais e mais usuários chegando pudemos coletar mais feedback, e assim os usuários passaram a fazer parte do desenvolvimento do produto, nos dando dicas do que eles achavam importante e como podíamos melhorar. Com estes dados repriorizamos coisas que julgávamos como não prioridade. Por exemplo, um dos maiores pedidos era a possibilidade de buscar por outros usuários, então desenvolvemos uma busca de pessoas super simples, e depois comentários, e assim por diante. Internamente o produto fez tanto sucesso que nos foi pedido para fazermos uma versão em Espanhol, que lançamos em meados de Julho e depois uma versão em Inglês que lançamos no final de Agosto. Hoje o Yahoo! Meme esta em Private Alpha em 4 países: Brasil, México, Argentina e Philippines, e quem sabe o que virá mais a frente.

Em Setembro abrimos nossa API, baseada no Yahoo Query Language (YQL), que permite desenvolvedores usarem uma sintaxe similar ao SQL para recuperar dados do Meme. Sem fugir muito do tópico mas já fugindo, este aqui é um exemplo de query YQL que devolve todas as infomações sobre o meu meme.

SELECT * FROM meme.info WHERE name=’acarlos1000′;
Clique aqui para ver o resultado no Console do YQL

Aqui tem um um outro exemplo que mostra 100 dos meus seguidores ordenados por número de seguidores;

SELECT * FROM meme.followers(100) WHERE owner_guid IN (SELECT guid FROM meme.info WHERE name=’acarlos1000′) | sort(field=”followers”) | reverse();
Clique aqui para ver o resultado no Console do YQL

Finalmente, a lição que aprendi neste último ano é que, sim possível desenvolver produtos de forma incremental e que tenham alcance mundial se o problema que você esta resolvendo for grande o suficiente e a sua solução simples o suficiente, de forma a que o produto faça sentido em diversas partes do mundo.

Por último agora em Setembro, nosso time foi eleito um dos 10 melhores times de todo o Yahoo! entre mais de 14.000 funcionários, ganhando um prêmio interno chamado de Yahoo! Super Star Award. Mais uma prova de que se você tiver foco, entregar valor consistentemente e executar com qualidade o reconhecimento sempre virá.

Yahoo Super Star Award, assinado pela CEO do Yahoo! Carol Bartz

Abs e confiram o meu Meme: http://meme.yahoo.com/acarlos1000, se precisarem de convites para entrar, escrevam um comentário com seu e-mail que eu envio mais tarde.

Adicionando um pouco de contexto, o foco deste post é conversar sobre duas formas de trabalhar em ambientes que envolvam UX no desenvolvimento de projetos Web:

Quando pensamos com mais calma sobre estas comparações, acho que a conclusão fica meio óbvia, principalmente se o objetivo é ter a melhor qualidade possível como “saída” do nosso trabalho. Explicando: ao desenvolvermos um projeto novo o que é mais fácil? Fazer pequenas partes muito bem, com foco total e com o decorrer do tempo ir desenvolvendo as outras partes enquanto se ve o software funcionando, OU fazer um grande projeto com milhões de partes de uma só vez, para depois de um tempo razoável entregar todas as telas e suas variações para a próxima área responsável? É importante lembrar que em times ágeis o que é definido como entrega é software funcionando e não um monte de telas, especificações, casos de uso ou documentações.

Fazendo um paralelo com o nosso dia a dia (pelo menos eu sou assim), quando tentamos fazer muitas coisas ao mesmo tempo, geralmente não fazemos nada com profundidade e no final acaba tudo ficando “meia boca”. Ao ir desenvolvendo novas funcionalidades ou melhorias a cada 15 dias (citando um exemplo da duração de um Sprint aqui no Yahoo!), podemos pensar bem a respeito do funcionamento de cada item e, mais importante, temos a chance de envolver todos no time nas decisões: desenvolvedores, designers, Produto, QA, etc. Com isso eu sinceramente acredito que a qualidade geral do produto e das decisões tomadas aumentam exponencialmente e ficam cada vez mais consistentes com o tempo.

Sempre que vi um projeto sendo feito da forma tradicional, existia um batalhão de Designers que faziam “milhões” de telas, para que todas as variações possíveis fossem mapeadas antes de serem entregues para a equipe de desenvolvimento, muitas vezes chamavamos estas pessoas de “replicadores de telas”. É óbvio que quando se faz um trabalho em massa, como se fosse uma fábrica, nem tudo terá a melhor solução e alguns parafusos deverão ser apertados mais tarde, algumas partes vão precisar de alguns remendos para encaixarem e com certeza várias das telas criadas nunca serão implementadas representando total perda de tempo e dinheiro. O mesmo acontece com as fábricas de software, elas fazem com que os desenvolvedores trabalhem em paralelo como se cada um fosse uma máquina (os famosos Code monkeys). Os designers “Replicadores de telas”, nada mais são do que uma versão da fábrica de software aplicada ao UX.

Estes são conceitos bem básicos sobre desenvolvimento ágil e que podem ser melhor visualizados através das duas figuras abaixo:

Figura 1: Sprints com entregas constantes

Na Figura 1, temos o modelo ágil onde ao final de cada Sprint sempre haverá uma entrega de software funcionando, ou seja, com entrega de valor para o cliente, valor perceptível e paupável, pois estes poderão ver seu produto funcionando e se tornando real de forma evolutiva. Uma situação interessante é que se o orçamento acabar no Sprint 3, pelo menos o produto terá 3 Sprints completos de funcionalidades entregues e funcionando em produção.

Figura 2: Metodologia Waterfall

Na Figura 2, temos o método tradicional, onde vemos que o produto só vai funcionar ao final de quase todas as etapas, o que pode levar a tomadas de decisão preciptadas. Aplicando a mesma situação, se o orçamento acabar na fase 2 (Arq. da Informação e Design) o que podemos entregar para o cliente é uma série de documentos e PSDs, nada de software funcionando.

Esta semana esta acontecendo em Las Vegas a maior feira de eletrônicos e gadgets dos Estados Unidos, a CES.  Há algum tempo o Yahoo! anunciou uma parceria com a Intel no qual o Y! forneceria um novo engine de widgets (Konfabulator) com foco em aparelhos de TV. Abaixo segue um breve vídeo com um demo de uma Tv da Samsung que já vem com este engine embutido.

Failblog.org

Micro-blogging: Como muitos já escreveram por aí, em 2009 o Twitter terá de se concentrar em achar um business model sem deixar de crescer sua audiência. No Brasil acredito que o Twitter já atingiu todos os early adopters e será difícil ele avançar para as massas muito além do crescimento orgânico do mercado, mas Micro-blogging veio para ficar e em 2009 vamos ver mais consolidação neste mercado. O Orkut deve lançar alguma funcionalidade que facilite o micro-blogging e a conversação assíncrona das pessoas nos meus diversos grupos de amizade.

Comunidades: Orkut continuará imbatível e gigantesco, acho que a plataforma de apps vai evoluir no segundo semestre, meio que seguindo a tendência ditada pelo Facebook que já tornou os seus apps algo secundário (em uma aba separada chamada Boxes). Haverá a grande briga para definir quem será o grande mantenedor da identidade digital (personas) dos usuários. Já não faz sentido sites e aplicações terem de criar – e manter -  seus social graphs do zero quando os próprios usuários já elegeram onde mantêm atualizados seus dados e conexões. De qq forma é um mercado bem grande e ser o número 2, atrás do Orkut, não é nada mal. Mundialmente Google, Facebook e, correndo por fora, MySpace brigarão para que suas plataformas se tornem o padrão do mercado. No Brasil, Google já sai com alguns milhões de corpos de frente e o Friend Connect deverá se tornar o padrão por aqui.

Agregadores e LifeStreaming: Em 2008 vimos surgir um grande número de serviços agregadores, ou LifeStreaming, outros se consolidaram como FriendFeed, SocialThing e alguns se foram como o Pownce (deprecated), entre outros. O foco destes serviços em 2008 foi o de agregar o máximo possível de serviços e sites, ênfase total no volume. Com isso temos mais do que nunca uma sobrecarga de informações sobre todas as atividades que todas as nossas conexões fazem, é impraticável. Em 2009 vamos ver muitos novos agregadores surgirem, mas acho que os Players já estabelecidos deverão investir em algoritmos que façam com que o consumo do LifeStream das nossas conexões, seja mais relevante. Aposto que o FriendFeed será o grande destaque neste front.

Metodologias ágeis: Continuaremos a ver as metodologias ágeis se espalharem pelo Brasil com mais e mais cursos e certificados em metodologias como o Scrum, e devido ao fato de estas práticas se tornarem cada vez mais populares, vamos ter um fenômeno onde várias empresas vão fazer muita besteira e  vão dizer que essas coisas de Post-its e Self Organization não funcionam, voltando para suas práticas convencionais e muito buzz vai surgir de que é o fim das metodologias ágeis, como já aconteceu em 2008. Tb vamos ver várias empresas tendo sucesso na implementação destas metodologias e com isso mais e mais material e cases vão surgir, e espero que não só no mundo de desenvolvimento Internet. É importante mencionar que vamos ter o primeiro Scrum Gathering acontendo no Brasil em 2009 e que promete trazer grandes nomes do Movimento Ágil, como Mike Cohn e Ken Schwaber. Tb acho que apesar dos esforços da comunidade não teremos muitos avanços na integração de metodologias ágeis com UX (ou experiência do usuário), ainda existem grandes barreiras culturais que segregam os profissionais de UX dos de Desenvolvimento e Engenharia. Acho que isso esta longe de se resolver, e é sem dúvida um assunto super interessante que vou acompanhar em 2009.

Celulares: Nenhuma novidade para 2009, tudo será a mesma coisa, pelo menos no Brasil, onde a maioria das pessoas faz somente chamadas de voz e no máximo manda SMS. Download de apps e software continuará sendo nicho do nicho e Internet de verdade continuará restrita ao iPhone, que por sua vez vai continuar nichado e caro.

Portais: Os portais devem começar a fazer mais personalização, se tornando “canvas” para aplicações OpenSocial, assim as apps feitas para o Orkut poderão ser tb instaladas na Globo.com, Yahoo! e outros portais. Nos mesmos moldes do que o LinkedIn e outros players estão fazendo nos Estados Unidos.

Advertising: A grana de propaganda será curta este ano e o mercado de Internet vai sentir, Google continuará o grande líder no mercado e devemos ver alguma consolidação em display nos EUA, mas no Brasil continuaremos na maior “zona”, talvez alguma Ad Exchange Network venha para cá, trazendo algum respiro de novidade para o mercado.

Video Technology: Adobe continuará nadando de braçada nesta área e o Flash Video se tornará cada vez mais agnóstico e estará presente em praticamente qq device com poder de tocar vídeo e se conectar na Internet (menos o iPhone). A Micro$oft deve continuar investindo no Silverlight, mas ela já percebeu que o jogo será muito mais difícil e de longo prazo, de qq forma como dinheiro não é um problema para a M$, ela deve anunciar uma versão mais madura do Silverlight na NAB2009, com melhores ferramentas de autoria. Sendo assim, não veremos concorrentes que incomodem a Adobe em 2009.

Acho que esta bom para uma primeira tentativa. Aqui tb tem algumas outras previsões, do John Battelle , Kara Swisher e Jason Calacanis.

Agilidade envolvendo Experiencia do Usuário, ou simplesmente UX, é um dos assuntos mais quentes no “mundo ágil” nos últimos tempos, como fazer para integrar o desenvolvimento de software com a Experiência do Usuário e Design. O Jakob Nielsen fez um ótimo post a respeito (com um viés um pouco “nós contra eles”) com direito a um post resposta bem legal do Alistair Cockburn. E alguns dias atrás o Guilherme Chapiewski fez um excelente post sobre como tem sido a experiência na Globo.com até o momento. Eu passei por este problema lá e quando vim para o Yahoo! resolvi tentar um novo “approach”, que na verdade era o que eu sempre quis fazer na Globo.com.

A primeira diferença que notei é que no Yahoo! não existem as diversas camadas de responsabilidades na parte de Interface/UX/Design. Na Globo.com existem três camadas que são responsáveis pelo visual e UX de um projeto: Os designers, os Arquitetos da Informação e os desenvolvedores Client Side. Claro que os problemas são muito amenizados quando estes três profissionais são alocados no mesmo time ágil. Mas agora olhando de fora, eu sinceramente acho que isso não resolve o problema.

No final o problema principal é a comunicação, como todos sabemos e já foi mencionado por Jack Welch (veja o quote abaixo) quanto mais camadas vc tiver pior será a comunicação, maior será a burocracia e principalmente o comprometimento com o produto final, podendo gerar os mini-waterfalls.

The more layers in a business, the more spin, meddling, and worst of all, delays

Quando estava formando meu time no Y! uma das principais premissas era não criar silos de especialização, ou seja, ter desenvolvedores que queiram mexer com todo o ciclo de desenvolvimento desde BackEnd, Banco de dados até Frameworks Javascript e TDD; um Product Owner que queira entender a importância dos desenvolvimentos de infra-estrutura e processos de qualidade e, neste mesmo contexto, eu tb estava procurando um Designer que não tivesse medo que meter a mão em código e desenvolver a parte Client Side quando fosse necessário. A primeira parte não foi tão difícil, existem muitos desenvolvedores multifuncionais e que tem a cabeça aberta para assimilar que eles devem entender de todo o ciclo e não apenas de uma ou outra parte. Mas achar um Designer/UX que também entenda de implementação não é nada fácil. Apesar de que todos os Designers que conheço (ou quase todos) fazem “freelas” que envolvem escrever código e muitas vezes desenvolvimento usando PHP ou Ruby, quando estão trabalhando na empresa muitos deles se limitam a gerar um PSD, muitas vezes não porque queiram, mas devido a forma como o processo foi estruturado.

No meu time atual tive a sorte (e bota sorte nisso) de encontrar um Designer que gosta de desenvolver toda a experiência, e tem a função de garantir que a visão de funcionamento e design do produto esta sendo bem executada do início ao fim. Neste caso o Designer ou UED (User Experience Designer) tem a responsabilidade de criar a experiência usando sua ferramenta favorita (Fireworks no caso) e depois implementar este design em código garantindo que tanto o visual quanto a experiência será a mesma em todos os browsers que suportamos e de que as boas práticas de implementação estão sendo seguidas.

O que sempre ouvi dizer é que não é possível fazer a interface/design sem pensar no produto todo, na experiência que estou tendo nesse momento posso dizer que isso é meia verdade. A visão do produto precisa estar clara: o que é o produto, quais as funcionalidades chave, qual o público que ele se destina, etc. Mas estou podendo constatar que não é preciso ter todos os detalhes para desenhar a experiência, e que sim podemos fazer a implementação da experiência aos poucos junto com a evolução do produto. No nosso caso estamos apenas no segundo Sprint e o desenvolvimento da interface/design e UX estão seguindo as histórias priorizadas no Backlog, e é muito legal ver a interface ganhando forma de uma maneira iterativa, posso dizer que a interface do nosso protótipo mudou umas 10 vezes (totalmente) e isso em nada impactou os desenvolvedores.

Isso acontece porque decidimos separar totalmente a “camada de apresentação” da “camada de negócios”, o UED é responsável pela camada de apresentação codificando e comitando os templates Django diretamente no SVN. Com isso o UED tem total controle da interface e pode alterar totalmente a usabilidade sem necessitar de outras pessoas (camadas) para isso.

Na última semana, foi até engraçado, pois estavamos todos trabalhando com uma interface na cabeça e de um dia para o outro o UED do time mudou totalmente o funcionamento da interface – para melhor claro. Neste momento me lembrei de como seria se tivessemos as três camadas envolvidas (designer, arquiteto, clientside) … acho que levaria alguns dias/semanas para discutir tudo e no final provavelmente a interface seria vetada por se tratar de uma mudança muito radical. Neste ponto vale lembrar que não adianta ter pessoas de qualidade se vc não deixar que elas tomem decisões, neste caso quem possui a última palavra em termos de UX é o nosso UED.

Voltando aos principios ágeis, onde pensamos iterativamente, sempre entregando software funcionando a cada sprint, posso dizer que se fossemos utilizar a forma antiga onde o UED investe 20 dias (no mínimo) pensando em todos os fluxos possíveis do produto, mais a identidade visual, mais toda a teoria. Com certeza hoje estariamos jogando grande parte deste trabalho fora, pois a idéia do funcionamento do produto evoluiu muito nos últimos 15 dias, e ao incluirmos evoluções iterativas do design/UX conseguimos fazer os ajustes necessários e o impacto foi mínimo. Claro que estou contando com possíveis grandes alterações no futuro, mas pelo menos estas alterações serão fruto da visualização do design aplicado na prática e não de um monte de PSDs e Fluxos de arquitetura.

Ainda não sei o quanto esta forma de trabalhar vai escalar no futuro, mas o ganho que tivemos na agilidade e na qualidade neste início estão valendo a pena.

Em todos os eventos relacionados a desenvolvimento de software sempre tem uma pergunta da platéia sobre que ferramentas são usadas para gerenciar as equipes que usam métodos ágeis. Algumas estão aqui:

- Como gerar relatórios e ver como estão as coisas?
- Como ter certeza de que um release será entregue? Eu consigo ver isso quando uso o M$ Project!
- Como podemos controlar as pessoas que são alocadas parcialmente em diversos projetos sem uma ferramenta?

Ai quando penso nas respostas vejo que o título deste post não esta sendo verdadeiro, na verdade não é que eu não goste de ferramentas de gerenciamento, eu não gosto de ferramentas de uma forma geral. Isso é tão verdade que tenho uma resistência muito grande para aceitar tools nas minhas equipes, isso aconteceu recentemente quando minha equipe no Yahoo! sugeriu usarmos o Campfire para registrar os bate papos da galera e os links que são trocados, assim todos podem ter um log do que aconteceu durante o dia. Tenho uma grande preocupação de que uma ferramenta vá efetivamente adicionar valor ao trabalho das pessoas e não apenas gerar mais um passo no dia a dia delas que não seria necessário se não fosse o relatório para o gerente ou diretor, que na maioria das vezes nem lê estes relatórios.

O que mais me chateia neste tipo de pergunta é que existe um fato que muitas vezes não admitimos,  as pessoas preferem acreditar muito mais no que uma ferramenta mostra do que se um “humano” apresentasse a mesma informação. As pessoas preferem conversar por um chat ou IM do que levantar e ir conversar cara a cara ou no pior dos casos por telefone. Com o decorrer dos tempos e a popularização de diversas tecnologias passamos a nos apoiar nessas ferramentas de forma desmedida, em detrimento do relacionamento e do trabalho em equipe. Neste ponto acho importante fazer uma mea culpa, eu sou viciado em tecnologia e uso meu iPhone o dia todo, o tempo todo, twittando, mandando SMSs e navegando, mas isso não me tira o dever de interagir com meus colegas e amigos entre uma twitada e outra

Quando falamos em desenvolvimento ágil estamos falando de pessoas (vejam o vídeo do Danilo Bardusco),  nestas equipes preferimos usar a comunicação verbal do que documentos com happy paths e paths alternativos e preferimos desenvolver o que sabemos com clareza do que tentar prever o futuro por seis meses, acredito muito na premissa que li em uma entrevista do J Allard (head de games da Microsoft e responsável pelo projeto do Xbox) “if it’s a possibility that you may fail, then fail fast and learn“.

Voltando a questão de gerenciamento por ferramentas, é importante dizer que nunca trabalhei com equipes espacialmente distribuídas, já vi várias aqui no Yahoo!, mas eu nunca gerenciei uma delas. Então toda a minha experiencia vem de trabalhar com equipes alocadas no projeto, fora quando eu trabalhava com empresas terceiras de três letrinhas, onde experimentei na própria pele o pesadelo das malditas fábricas de software.

Sendo assim, quando desenvolvemos algumas coisas, eu basicamente uso o Quadro branco com post-its ou cartões (como prefere o Phillip Calçado). Mas em alguma situações admito que é preciso gerar algum tipo de report para áreas gerenciais. Na minha opinião não existe nada melhor do que ver o quadro, nada é mais claro para ver como as coisas estão andando do que o quadro com as Histórias, tarefas e o burndown chart.

Atualmente estou usando um Twiki que gera os principais gráficos de acompanhamento do sprint, é exatamente da mesma forma que usava quando trabalhei na Globo.com, lembro que na época existia uma vontade ensandesida de comprar alguma ferramenta para que as equipes pudessem atualizar suas tarefas e assim gerar relatórios fantásticos de custos e performance, bugs por pessoa, por linha de código ou por piscada de olho do desenvolvedor.

O problema na verdade não esta no relatório ou na ferramenta, o problema real é que as pessoas não confiam umas nas outras, e elas se apóiam em tecnologias e ferramentas para se blindar e muitas vezes se armar e poder desmascarar uns aos outros. Agora como é que se pode trabalhar em um ambiente em que não existe confiança, onde as pessoas ficam falando pelas costas umas das outras. Este é O PROBLEMA, e as ferramentas de gerenciamento não resolvem isso, só agravam. Não é pagando US$566.40 dólares por usuário/ano em uma ferramenta que se resolve esse isso, porque nenhuma ferramenta pode arrumar isso, só uma conversa clara, limpa e verdadeira é que pode ajudar a resolver essa situação.

Havendo transparência e confiança, pode-se trabalhar para arrumar os nossos defeitos e outros problemas, afinal de contas somos humanos e não máquinas.

Muitos podem não concordar comigo, não tem problema, acho que todos temos as nossas opiniões e acho legal que tenhamos divergências, mas eu já sofri muito e tentei muito usar ferramentas na minha vida. Mas cansei, elas nunca funcionaram comigo, e olha que já trabalhei com diversas empresas CMM5 e com três letrinhas que são super premiadas internacionalmente e não adiantou, os M$ Projects nunca diziam a verdade e tínhamos sempre que “gambiarrar” o projeto, onde geralmente o que era cortado de cara era a qualidade e as pessoas eram tratadas como utensílios. “Ah este recurso aqui esta alocado 13% em requisitos deste projeto, mas ele atua como tester 35% neste outro projeto aqui” QUEM é que em sã consciência acredita que um humano consegue se controlar desse jeito (13% para um lado, 35% para outro, 26,5% para tal coisa) isso é muito idiota.

Por ter errado muito na minha vida e ter caído no conto da carochinha muitas vezes, pensando que selos e certificados significavam alguma coisa, eu aprendi a ter aversão a ferramentas e processos burocráticos, pesados e principalmente mentirosos. Tem uma frase que uso muito e que ouvi pela primeira vez de um diretor de uma grande empresa de comunicação: “Cachorro mordido por cobra, tem medo de salsicha!“.

Hoje em dia o que mais vale pra mim é estar bem com o que estou fazendo, discutir de forma construtiva com minha equipe e outras pessoas e poder trabalhar com coisas legais, mesmo sabendo que nem sempre fazemos coisas legais 100% do tempo. #prontofalei.

O Yahoo! liberou hoje um experimento legal feito pela equipe de Barcelona com base no conceito “wisdom of the crowds” chamado Y! VideoTagGame, há vários produtos por ai que utilizam este conceito, o mais famoso na minha opinião é o Amazon’s Mechanical Turk , mas tem também o Google Image Labeler e o reCAPTCHA.

O conceito é fazer com que as pessoas ajudem a taggear os vídeos coletivamente, só que no formato de um jogo o que torna a ação muito mais divertida.

Agora chegou a vez do Brasil sediar o Open Hackday, o evento acontecerá nos dias 08 e 09 de Novembro na Centro Universitário Senac – campus Santo Amaro, totalizando mais de 36 horas de Hacking, TechTalks e muita diversão podem ter certeza. É importante lembrar que, assim como no RailsRumble, os hackers possuem um determinado tempo, no nosso caso 24 horas, para desenvolver suas aplicações.

Na verdade, o Open Hackday é parte de uma estratégia bem maior do Yahoo! que tem o objetivo de abrir seu social graph (mais de 270MM de usuários logados) e suas propriedades (Flickr, Delicious, Yahoo Mail, Profiles, Updates, Upcoming, MyBloglog, entre outros) para desenvolvedores e usuários e assim permitir que estes criem e construam novas aplicações e mashups sobre a infra estrutura do Yahoo. Esta iniciativa de abertura, chamada de Yahoo Open Strategy ou Y!OS, foi anunciada alguns meses atrás, mas esta sendo desenvolvida e preparada internamente há pouco mais de um ano. A primeira versão do Y!OS será lançada nesta semana (27 de Outubro) e conta com muitas coisas legais que tornarão o Open HackDay no Brasil ainda mais legal, pois uma série de recursos novos estarão disponíveis para os hackers Brasileiros em primeira mão.

Não deixe de consultar o Site oficial do HackDay aqui: http://hackday.org

E de dar uma olhada nas documentações das APIs no Yahoo Developer Network: http://developer.yahoo.com

No Twitter sigam o: @brhackday

A primeira impressão é de que tudo é grande, realmente grande, os projetos de infra-estrutura são projetados para suportar volumes imensos de acessos. Mas uma coisa que impressiona, apesar de nao ser novidade é a extensão do uso de softwares Open Source, desde o óbvio como Linux, FreeBSD, Apache e MySQL até o Asterisk, XMPP e Twiki, este último suporta toda a documentação da empresa mundialmente, e o melhor é que todos usam o Twiki, pessoal de Marketing, Engenharia, Produção, etc. Em algumas empresas as pessoas acham um absurdo se sujeitarem a escrever no Twiki, mas no Yahoo! todo mundo usa.

Outra coisa nova para mim é a questão da distância entre os times, aqui alguns projetos são tocados por times em vários países e algumas vezes em continentes diferentes. Para suportar este ambiente uma série de tecnologias são usadas, mas a que achei mais legal foi o Adobe Connect – pena que não é Open Source, as apresentações e treinamentos acontecem através desta ferramenta e é bem legal, realmente funciona. Mas ainda acho que a distância é um fator importante durante o desenvolvimento de software.

É importante também lembrar que estes últimos anos o Yahoo! iniciou um processo de abertura de sua infra-estrutura, seus dados e suas propriedades para que desenvolvedores possam criar em cima de seu Social Graph e de produtos. Isso vem ocasionando uma série de mudanças internas e de desenvolvimento para suportar esta abertura e tornar o Yahoo! o ponto de partida dos internautas. Esta iniciativa é conhecida como Yahoo Open Strategy ou Y!OS, e as primeiras entregas começaram a ser disponibilizadas recentemente como o o BOSS (Build Your Own Search) que expõe todo index do Yahoo para que qq desenvolvedor faça o que desejar com os resultados, SeachMonkey para criar novas formas de enriquecer os resultados de busca, Social Directory, Contacts/Address Book, Updates, fora todas as outras APIs que continuam disponíveis como Flickr, Delicious, Upcoming, GeoPlanet, YUI, etc. De tudo isso o que acho mais legal é o YQL (Yahoo Query Language), feito pela mesma equipe que criou o Yahoo! Pipes, esta ferramenta vai possibilitar que o Yahoo! seja um grande banco de dados que poderá ser consultado facilmente usando um padrão de queries muito parecido com SQL, muito legal.

Enfim, existem muitas coisas novas e vou continuar postando a respeito, até agora as primeiras impressões são positivas, apesar do momento de pressão pelo qual a empresa vem passando

PS: este post foi quase totalmente escrito através do iPhone com o WordPress app.

• Link direto para a AppStore (precisa ter o iTunes):

http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=281970154&mt=8

• Link para a página oficial do Yahoo oneConnect para iphone:

http://mobile.yahoo.com/oneconnect/iphone

Yahoo oneConnect for iPhone