Em um dos dias do passeio, resolvi jantar com a minha esposa e um casal de amigos numa pizzaria famosa da região. A pizzaria era bem indicada, tem um website bem legal e tudo que tem direito. Com uma estrutura linda, uma faixada de dar inveja, toda em madeira, com um lugar bem estilizado e com direito a música ao vivo. Para minha surpresa, a pizza não era a das melhores. Eu até sai satisfeito, mas a minha esposa não gostou e acabou nem comendo tudo. De fato a pizza não era tão boa.

No dia seguinte, saímos novamente para comer a noite, mas dessa vez tinha que ser algo rápido, pois era necessário dormir cedo devido ao voo ser as 5 da manhã do dia seguinte. Perguntamos ao recepcionista da pousada se havia algum lugar por perto onde tinha lanche e ele nos indicou comer uma Pizza (novamente ?!?) ali bem próximo, no quarteirão seguinte. Ele também disse que os donos da pousada eram frequentadores. Depois que ele nos explicou onde ficava a pizzaria, saímos a pé mesmo pois era muito perto. Chegando em frente ao local, percebemos ser um lugar bem simples, ao ponto de nos fazer pensar se era aquele realmente o lugar que os donos da pousada frequentavam. Para ter uma idéia, nem lembro de como era a fachada/letreiro/etc. O recepcionista do hotel havia dito que esse lugar servia apenas pizzas individuais (um pouco maior que uma pizza brotinho) e confirmamos isso, tenho assim certeza que estávamos no lugar certo. Olhei o cardápio e vi que tudo era bem barato. Fizemos o pedido e aguardamos. A pizza era simplesmente muito gostosa. Muito mesmo. Em poucos lugares eu comi uma pizza tão gostosa por um preço tão barato. E olha que não é questão de custo/benefício. Se a pizza fosse mais cara que na outra pizzaria eu pagaria certamente, mesmo sendo uma pizza menor. Saímos dali muito satisfeitos e entendi o motivo que fazia os donos da pousada frequentarem aquele local. Por sinal, nem lembro o nome do lugar, mas lembro exatamente onde fica e se eu voltar algum dia a Natal certamente irei nessa pizzaria. E o que raios essa pizza tem a ver com experiência do usuário?

Essa minha passagem pelas pizzarias não foi premeditada, simplesmente aconteceu. Como cliente (ou usuário se você preferir), fiquei mais satisfeito com a pizzaria mais simples do que com a pizzaria mais bonita, requintada, que tinha website e tudo mais. E por que eu gostei da mais simples? Será que é por que eu não gosto de coisas requintadas? Claro que não. Eu gostei do lugar simples porque eles me serviram uma pizza melhor. O mais importante de uma pizzaria é a pizza ser gostosa ora bolas. Não adianta ter uma cadeira linda, usar um iPad pra fazer pedidos, guardanapo imperial e talher de outro se a pizza não for saborosa. É simples assim. E o que isso tem a ver com a nossa área?

Vamos pensar nas aplicações que fazemos no dia a dia. O Youtube, por exemplo, tem um site bem simples. Não considero o site deles uma obra de arte, muito pelo contrário. O player de vídeos deles provavelmente é um dos mais simples e feios que existem na web. Então por que será que ele é um produto de sucesso? Simples: o youtube da muita importância para o que tem realmente valor para o usuário do site deles, que é ver e compartilhar vídeos. É muito simples enviar um vídeo e mais simples ainda ver videos. Qualquer leigo consegue fazer isso. O player de vídeos deles funciona perfeitamente bem, apesar de não ter uma aparência linda. E o usuário se importa com essa aparência não muito bonita? Alguma vez você pensou em deixar de acessar o Youtube porque o site não é lá tão bonito? Acredito que não. Eu poderia citar diversos exemplos de produtos de sucesso que são extremamente simples e as vezes feios mas que são sucesso exatamente por focarem na necessidade do usuário, mas nem preciso citar porque acho que já deu pra entender onde eu quero chegar.

Parece chover no molhado, mas é impressionante o número de vezes que me pego discutindo ou observando discussões sobre se um site/aplicação precisa de borda arredondada, gradiente, se o cinza está um pouco mais claro ou escuro, ou se o botão está 1 píxel pra direita ou pra baixo, quando por vezes o que tem mais valor para o usuário nem está ótimo ainda. Não que esses detalhes não tenham importância, muito pelo contrário. O ponto aqui é que o foco deve estar primeiro no core business e depois nos acessórios. É o exemplo da pizzaria. Me lixei pra decoração linda, música ao vivo e requinte da primeira pizzaria, pois a pizza não era tão boa (se fosse certamente eu voltaria). Ao meu ver eles se preocuparam demais com coisas secundárias e esqueceram de contratar ótimos pizzaiolos. Certamente me lembrarei muito mais da segunda pizzaria, que era um lugar bem mais simples mas tinha uma deliciosa pizza.

Pra finalizar, pense um pouco sobre os motivos que fazem do iPhone um produto de sucesso. Provavelmente você perceberá que um dos menos relevantes é a sua beleza.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Indo direto ao ponto, meu primeiro projeto importante foi desenvolver junto com meu time um novo player de vídeos para a globo.com, o qual chamamos de Player 2.0. Pra mim isso era algo totalmente novo, pois meu contato com desenvolvimento Flash/ActionScript havia sido muito pouco, num projeto no início de 2009. Como a maioria já sabe, o desenvolvimento de um Player de Vídeos hoje em dia precisa necessariamente ser feito em flash, pois é o runtime que tem o maior alcance de usuários. A parte de vídeos do html5 ainda tem diversas lacunas a serem preenchidas e é necessário ainda um bom tempo para que a “massa” de usuários tenham seus browsers atualizados com suporte a essa tecnologia.

Nesse desenvolvimento do Player, pude perceber juntamente com meu time que desenvolver na plataforma do Flash já é o um grande desafio, pois a plataforma e o runtime tem alguns detalhes que você precisa entender e saber lidar, caso contrário você vai ter muita dor de cabeça.

Runtime e Sistema Operacional

Quando você desenvolve alguma coisa em Flash, especialmente um Player de Vídeos, um ponto onde é preciso tomar bastante cuidade é com o Runtime do Flash (vulgo Flash Player). O Runtime pode ter comportamentos diferentes em diferentes versões do próprio runtime e também do sistema operacional. Por algumas vezes nós passamos por situações onde percebemos que o Player não estava funcionando em uma versão específica do Runtime no Internet Explorer 6 no Windows XP. Isso causou uma certa correria, mas felizmente conseguimos resolver o problema antes de colocar no ar e não houve impacto.

Lições aprendidas e tivemos tomar algumas medidas, entre elas testar em Linux, Windows e Mac e nos principais browsers e Runtimes do Flash como parte do nosso Definition of Done (DoD). Na prática, hoje uma estória não é dada como pronta se não tivermos certeza que o que foi feito funciona nos diversos environments pré estabelecidos. No início isso era parte do DoD do Sprint, mas após passarmos por uma situação, onde achamos um problema no IE6 (pra variar) bem no último dia do sprint, e que iria colocar todo esse Sprint por água abaixo, movemos esse item do DoD do Sprint para o DoD das estórias. Acabamos resolvendo o problema sem impactar no sprint, mas o desfecho poderia ter sido outro.

Testes Automatizados

Nos tempos atuais, é quase unânime a importância de testes automatizados no desenvolvimento de software. Todo programador deveria saber os princípios de testes automatizados e aplicá-los no seu dia a dia. Infelizmente, existem alguns environments que não facilitam muito esse tipo de prática. Nesses casos, é necessário lidar com o problema de maneira pragmática, caso contrário as coisas não andam. Diferentemente de outras tecnologias, neste caso não podemos escolher alguma opção diferente, pois a opção é uma só (o Flash).

No desenvolvimento do Player, nós usamos o FlexUnit como ferramenta principal de testes automatizados. Dentro do que ele se propõe, faz seu trabalho bem feito, e facilita bastante os testes. Tem suporte a testes assíncronos, e sua documentação explica bem as principais funcionalidades.

Uma coisa que tem nos atrapalhado bastante são os frameworks de test doubles. Nenhum dos frameworks que testamos funcionou no nosso ambiente. Aqui, algo que percebemos no densenvolvimento para Flash foi que cada tutorial na internet pode funcionar numa minor/revision version do runtime e na outra aquele tutorial já não funciona. É bem complicado e custei a aceitar, mas é assim que funciona nesse environment. Ainda não descarto a possibilidade de que poderiamos insistir mais pra conseguir alguma coisa melhor, ou que não soubemos fazer direito, mas não poderiamos ficar empacados nisso, sem mover nosso projeto pra frente.

Mesmo com essas dificuldades, estamos conseguindo fazer uma quantidade boa de testes e isso tem nos ajudado muito.

Continous Integration Server

Outro desafio bem complicado que tivemos foi ter um build server funcionando bem e rodando nossos testes automatizados. Mais uma vez os tutoriais da internet acabam não funcioando direito. Pra piorar, pra você rodar testes ActionScript 3, que é a linguagem do Flash, é necessário levantar uma instância do FlashPlayer, que precisa de um Servidor X. Essa instância vezes não fecha, fica travada, ou apresenta alguns problemas que nada tem a ver com os testes da aplicação. Custamos a perceber isso, mas foi o que aconteceu.

No fim das contas, hoje temos nosso servidor de build e integração contínua funcionando bem, e com poucos problemas.

Estratégia de Migração

Fazer uma mudança no Player de Vídeos da globo.com não é uma tarefa simples. Não poderíamos simplesmente colocar um Player novo no lugar do antigo e ver o que aconteceria. Além de ser um baita risco seria uma baita irresponsabilidade. Precisavamos então pensar numa estratégia …

Antes  do momento de colocar o primeiro release no ar, decidimos usar um catálogo de vídeos com acesso bem pequeno. Para isso, criamos uma opção que ativa/desativa a versão nova em cada catálogo, individualmente. Dessa forma, poderiamos voltar para a versão antiga IMEDIATAMENTE, em caso de algum problema.

Essa estratégia foi perfeita, pois conseguimos pegar diversos pontos de melhoria, e fazer os ajustes necesários sem gerar impacto para os usuários. Com os ajustes feitos e uma nova versão no ar, resolvemos então colocar em mais um catálogo de vídeos, dessa vez um com mais acessos. Nesse momento nosso player ainda não suportava vídeos ao vivo, portanto ainda não podiamos colocar em catálogos como o do Globo News, pois caso contrário teriamos problemas. Isso provou como a nossa escolha de criar uma opcão de ir habilitando sob demanda se mostrou bastante acertada, pois assim que terminamos a funcionalidade de vídeos ao vivo, habilitamos essa nova versão do Player para o Globo News.

Hoje, estamos já com quase todos os catálogos de vídeos usando esse Novo Player. Em breve, todos os vídeos da Globo.com serão servidos por ele. Isso só não aconteceu ainda porque temos algumas estórias com alguns detalhes que tornam viável a substituição completa do Player que está no ar hoje. O mais interessante de tudo é que estamos tendo impacto e stress zero, graças e estratégia bem traçada por todo nosso time.

Conclusão

Esse começo na equipe de Webmedia está sendo ótimo. Criar um Player de Vídeos do zero tem sido uma experiência fantástica, apesar de todas as dificuldades.

Algumas das coisas mais importantes que estou tirando de lição desse projeto é que (1) nem sempre dá pra fazer tudo certinho com todos os testes automatizados, etc, etc etc, (2) as vezes estamos num vendor lock-in onde não dá pra sair e ai você tem que saber superar com os problemas do enviroment dessa tecnologia e (3) migrar uma aplicação que afeta quase todos os sites de uma empresa do tamanho da globo.com sem causar impacto em ninguém é difícil, mas não impossível.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Sobre a melhoria contínua, vou focar aqui nos aspectos (1) errar e (2) compromisso com a mudança.

Errar

O erro sempre foi um tabu nas empresas. Errar sempre foi considerado sinônimo de fraqueza ou incapacidade. No modelo que estavamos acostumado a trabalhar, erros geralmente eram punidos com severas advertências, demissões e/ou humilhações. No modelo em que estamos tentando trabalhar, os erros devem ser vistos como oportunidade para crescermos e melhorarmos como indivíduo e como profissional. Dessa forma, errar faz parte do processo, já que inevitavelmente erraremos algumas vezes ao longo da jornada.

Compromisso com a mudança

Quando pensamos em compromisso com a mudança no nível da empresa, talvez seja mais fácil, mas quando pensamos para o nível pessoal, complica um pouco. Mudar manias, paradigmas pessoais e outras coisas mais, geralmente é um processo bemmmm complicado. Porém, essa é a oportunidade que temos para aplicar na prática o que aprendemos com os nossos erros.

O compromisso em melhorar é fundamental para que haja resultados práticos. Errar e não melhorar, repetindo os mesmos erros, faz com que de nada tenha servido a oportunidade de reflexão.

Nosso papel quando os outros erram

Quando um colega seu errar, ajude. Criticar, humilhar, querer ver o mau dessa pessoa, de nada ajudará. Isso só fará com que você esteja piorando como profissional e como pessoa. Se for possível, ajude, se não for, torça para que essa pessoa consiga usar seu erro como uma oportunidade de melhoria. E não se esqueça: você também erra e vai continuar errando.

Testemunho pessoal

Recentemente, tive a infelicidade de cometer um erro. Foi um pequeno erro, mas que aconteceu e então isso me entristeceu bastante. No momento em que percebi essa falha, tratei de resolver o que precisava ser resolvido de forma mais urgente e deixei a reflexão para o primeiro momento oportuno.

Passado pouquíssimos dias, fiz uma profunda reflexão sobre a falha para que ela não viesse a ocorrer novamente. Dessa forma, além de melhorar como pessoa, acredito ter melhorado como profissional.

Talvez você pense: mas assumir assim um erro? Não tem vergonha disso não?

Digo com toda naturalidade: NÃO!!!

Quem erra é porque está evoluindo, quem erra é porque tenta alguma coisa, quem erra é porque pensa, quem erra é porque raciocina … quem erra, é porque está vivo. A diferença está em aproveitar isso como oportunidade.

Conclusão

Eu erro, você erra. Logo, nós erramos. Portanto, a melhoria contínua começa em nós!!!

Referências:

[1] http://visaoagil.wordpress.com/2009/01/06/melhoria-continua-e-efetiva-atraves-do-hansei-e-kaizen/

[2] http://www.slideshare.net/Comunidade_Lean_Thinking/melhoria-contnua

[3] http://en.wikipedia.org/wiki/5_Whys

[4] http://pt.wikipedia.org/wiki/Kaizen

[5] http://en.wikipedia.org/wiki/Hansei

Post Footer automatically generated by Add Post Footer Plugin for wordpress.