HTML para robôs no Women Techmakers Rio

Eis a apresentação do HTML para robôs no Women Techmarkers Rio. <3

A diversidade nos times de tecnologia

Tarsila - Operários
O CSSConf 2015 fornece bolsas para a diversidade. O ambiente hostil para mulheres em centros de tecnologia como o Vale do Silício é conhecido da população em geral. Acreditamos sim que isso se deve, pelo menos em parte, no sexismo na formação básica e universitária. No entanto, há algo no processo de recrutamento que pode estar impedindo uma maior diversidade nos times de tecnologia, não só de gênero, mas também de práticas?

Assisti uma palestra sobre gestão de recursos humanos sobre entrevista orientada a competências. Resumindo, o gestor de RH tem utilizado técnicas para filtrar candidatos de acordo com a visão da empresa. Se você já esteve em duas ou três empresas de tecnologia, já notou que a missão e a visão delas não diferem muito em conteúdo. Todas querem criar produtos bacanas e lucrativos. Uma coisa ou outra varia de acordo com a consciência dos sócios em fazer algum bem para o mundo (ou simplesmente não fazer o mal).

Além disso, o RH pode estar usando o processo de seleção como uma forma de fazer que times tenham menos conflitos ao contratar o um tipo de perfil semelhante ao gestor da área. Levei um susto quando ouvi isso de forma formalizada como técnica de entrevista. Tenho notado times extremamente homogêneos em termos de práticas e acreditei ingenuamente que isso era uma consequência natural da cultura organizacional criada na empresa. No entanto, tudo é organizado para evitar conflitos. Mas o conflito não seria também um ingrediente fundamental para a criatividade? Se todos na equipe pensarem da mesma forma, não é prejudicial para a empresa? A proposta seria resolver conflitos de modo saudável ao invés de evitá-lo?

Lembro de uma reunião de quatro horas que participei onde foi discutido apenas se o resultado de busca de um site deveria ser ou não um catálogo de produtos, conceitualmente falando. Havia dez pessoas na sala, incluindo consultores que trabalham por hora. Faltou uma atitude ali um pouco mais pragmática que encerrasse a discussão. Não fui esta pessoa e lamento até hoje. Foi um projeto que fracassou e questiono pequenos eventos como este.

Usei casos de feminismo pois é uma das mais bem documentadas na internet nos últimos tempos, mas não é só a questão de gênero que preocupa. Será que não estamos recusando profissionais mais velhos porque eles não pensam como os millennials que estão gerindo as empresas de tecnologia? Será que estamos formando times 100% pragmáticos ou 100% academicistas? Ainda discutimos muito porque certos times que possuem tudo para produzir bem não entregam. Questionamos as metodologias, mas será só isso ou a forma como montamos nossos times.

Leia também:

Doutrinação ágil

Bolo de fubá

Para aqueles que buscam uma solução rápida, uma receita de bolo de fubá exclusiva.

Uma das primeiras conclusões que se chega em um graduação em psicologia é que não há uma receita pronta para estabelecer uma melhor interação entre pessoas. Não é só jogar um ovo, meia xícara de leite, colocar no micro-ondas por dez minutos e teremos uma equipe capacitada, motivada e alinhada com os objetivos da empresa. E quanto mais olho os textos e as ementas de cursos sobre as metodologias ágeis sob esta perspectiva mais vejo que tudo é feito como receita de bolo, sendo que cada empresa demanda uma certa proporção de ingredientes que não é inicialmente dada. Antes não havia método algum, entendo, mas agora saboreamos bolo solado como se fosse ambrosia.

Costumava rir dos gerentes que não percebiam que metodologias envolviam tanto processos quanto pessoas. Não faço mais isso. Vejo mais claramente agora qual é o custo alienante para cada profissional de uma célula de desenvolvimento.

É extremamente difícil escapar de oferecer uma solução para uma equipe de tecnologia. Lembrando de todas as piadas de humanas versus exatas que ouvi em todos estes anos nesta indústria vital, esta diferença de pensamento existe e dificulta a comunicação. A solução de problemas é o modo de vida de um programador. Como dizer que para certas coisas no mundo corporativo não há uma solução? Ou então que a busca por uma interação pessoal ótima é uma utopia saudável para todo profissional. O mais perto de conseguir isso foi quando sugeri que alguém devesse desligar o computador para que a rede voltasse a funcionar. Não faz sentido algum, mas conseguimos chegar a um resultado favorável empiricamente!

Todos aqueles instrutores de metodologias ágeis tiveram mais sucesso do que eu. Eles apareceram com um manifesto, algumas dinâmicas de grupo e nenhuma pergunta sobre como o mundo funciona deveria ser feita. Alguns textos ou palestras são claramente doutrinações e não treinamentos. Funciona do mesmo modo que o computador com problema de rede: desliga a cultura da empresa, desfragmenta o disco e liga de novo.

O problema com doutrinas é que não é nada científico, o que torna tudo muito irônico. Enquanto tentamos provar nossas soluções com o código logicamente construído, todo o processo das metodologias ágeis que envolvem pessoas é ritualístico e dogmático.

Há pouco ouvi um astrólogo defendendo sua prática em uma recepção de consultório médico. Para ele, o método científico não dá conta de explicar todos os fenômenos e isso inclui principalmente os que são relacionados às pessoas. Deste modo, tudo que não pode ser explicado deve ser validado, tal como a astrologia!

Para qualquer bom cético, a lógica do astrólogo não faz sentido. Mas porque aceitamos então a opinião de alguém como a solução perfeita para nossos problemas de interação pessoal? E por que compramos esta solução sem questionar ou mesmo investigar qual é a formação do instrutor? O que acontece quando a metodologia falha, a empresa quebra, todo mundo é demitido? Vamos culpar a ira dos deuses?

Ainda não sabemos se a psicologia é uma ciência ou não. Alguns autores acreditam que esta é uma disciplina nova demais para ser estabelecida como ciência e que a neurociência nos trará mais indícios com os avanços da tecnologia. Mas certamente a complexidade do indivíduo não pode ser explicada por um método que usa duas variáveis para validar qualquer teoria. De qualquer forma, há muitos outros profissionais tentando fugir destas doutrinas para explicar estes fenômenos um a um, contextualizados nos meios onde eles ocorrem. Com times de tecnologia, não deveria ser diferente. O que falta então para evoluirmos de doutrina para um método ágil de verdade?

Tags: ,

O mito do pau pra toda obra em tecnologia

Nas últimas semanas, fiz uma provocação grosseira no Twitter e não consegui respostas satisfatórias: qual seria a diferença entre webmaster e full stack web developer? A complexidade do trabalho com o mercado digital, do planejamento à publicação na Web, foi incrementada absurdamente com a profissionalização do mercado e foi uma resposta às falhas grosseiras como a bolha dotcom. Por que então estamos adotando uma visão tão generalista quanto a da década de 1990?

Quando li o texto de Laurence Gellert tive a sensação de que o termo foi mal traduzido e contextualizado nos times de desenvolvimento brasileiros (ou não: Facebook aparenta ser uma empresa com uma cultura muito equivocada). Afinal, nossa visão sobre generalistas e especialistas é muito diferente da dos norte-americanos, por exemplo. A experiência da formação universitária lá é construída pelo aluno durante curso. No Brasil, estamos presos a currículos altamente especializados e herméticos. A flexibilidade de currículos universitários no exterior permite acompanhar melhor a tendência volátil do mercado de trabalho. Se a especialização foi valorizada na segunda metade do século XX, a generalização e a interdisciplinaridade são diferenciais na tal era do conhecimento.

Neste momento, vemos as universidades brasileiras buscando esta interdisciplinaridade e vejo um retorno ainda pouco útil. Ao invés de uma visão ampla de negócio que o mercado exige, os alunos dos cursos de tecnologia estão ocupando suas grades com Direitos Humanos e Qualidade de Vida (oi?). Do que adianta alterar cursos para introduzir disciplinas novas (multidisciplinaridade) se as grades não são construídas para favorecer a construção do conhecimento entre elas (interdisciplinaridade, transdisciplinaridade)?

Um resultado provável disso, ou algo que não foi solucionado ainda, é a eterna busca pelo acúmulo de técnicas (techné) ao invés de práticas (práxis). Ao buscar uma vaga para times de tecnologia, é fácil encontrar uma lista gigante de requisitos que vão do domínio do Photoshop ao realização de deploy de aplicações. Não é só irreal como opressivo. As graduações não preparam este tipo de generalista e nem deveria. Quantas vezes ouvi relatos de jovens passando o fim de semana debruçados sobre tutoriais para aprender uma nova técnica enquanto não conseguem relacionar o porquê daquela técnica ser boa para o negócio. E se somente a técnica é valorizada no mercado, por que não trocar uma graduação por um curso da técnica mais quente no desenvolvimento de aplicações do ano?

O Scrum, por exemplo, não ajuda nesta questão. Os ciclos rápidos de desenvolvimento são bons para manter uma alta eficiência do time e sabemos bem que o custo disso é um corte na participação na estratégia da empresa. A alienação é tal que há desenvolvedores que agradecem quando recebem as tarefas prontas e mastigadas bastando definir complexidade.

Apesar das origens do Kanban nas fábricas da Toyota, o agile não era sobre transformar pessoas em engrenagens e sim formar times autogerenciáveis com seres pensantes e ativos. Os métodos ágeis não combinam com alienação! A motivação básica de cada um no time deveria ser entender como o produto funciona do princípio ao fim. No entanto, como fazer isso se o profissional de TI só entra em contato com o mundo fora da célula no planning e no review através dos olhos do product owner?

A cultura interdisciplinar ou transdisciplinar é algo que devemos construir nas próximas gerações de profissionais do mercado digital. É uma característica cultural intrínseca à formação de cada um de nós. Generalizando absurdamente, é como se fosse escrito em cada um de nós em uma linguagem de programação baixo nível e tal característica não se muda com dinâmicas de grupo e muito menos com o acúmulo de técnicas aprendidas.

No entanto, podemos começar conhecendo melhor cada um do time. Uma matriz de competências, por exemplo, é uma ferramenta muito mais eficaz e é de implementação rápida. Incentivar a diversidade dentro do time também é uma ótima forma de aumentar a criatividade e facilitar soluções mais integradas com a estratégia de negócio do que com as técnicas utilizadas (ou quem nunca sugeriu uma tarefa porque é fácil em fazer na linguagem da moda XPTO?).

Existem paliativos para reduzir a alienação de desenvolvedores do processo de trabalho e cada time pode ter uma ideia para compartilhar com a comunidade. Mas é essencial relembrar que o que é bom para o Facebook pode não ser bom para a sua empresa.

Outros olhares sobre o tal full stack developer:

Tags: , , ,

Sobre HTML e robôs

A convite dos queridos do Niteroi.JS compartilhei um pouco sobre a história do HTML e da sua relação com os diversos robôs da Web. Segue aí o ppt:

Obs.: esqueci de compartilhar o URL Linter, bookmark essencial para trabalhar com os compartilhamentos no Facebook. :)
Tags: , , ,

Criação + Scrum: mais uma visão sobre UX e desenvolvimento ágil

Entre o artigo anterior e este, foram seis meses onde fiz um curso para CSM, certifiquei-me, troquei de emprego e comecei trabalhar com outros projetos que integram equipes que usam metodologias de experiência do usuário e as que usam as metodologias de desenvolvimento ágil. Gostaria de compartilhar algumas destas novas experiências.

Durante o curso, surgiu o conceito de haver um time separado para ajudar o product owner a definir o backlog. Em um PO team podem estar contempladas várias competências que não estão relacionadas a desenvolvimento tecnológico, inclusive as de UX, como arquitetos de informação, designers de interfaces e até mesmo desenvolvedores front-end. Tudo depende de qual seja a definição de pronto (ou definition of readyDoR) para o dev team começar suas histórias: layouts ou código HTML.

Nada impede que este time associado ao product owner seja uma célula própria e que siga os ritos Scrum como tal.

Um cenário

Em um projeto em que estou envolvida agora, a empresa que o implementou optou por não ser obrigatório encerrar uma história ao final de um sprint. Aceitar que uma história pode precisar de mais um sprint para ser concluída significa tempo para que as tarefas que gerem dependências podem ser feitas sem sobrecarregar alguns dos membros do time, como o front-end e o QA, sem que seja encarado como uma falha do processo (e do time). A estrutura básica de uma história de desenvolvimento simples pode ter os seguintes conjuntos de tarefas:

  • Criar cenários de testes
  • Desenvolver código server-side
  • Desenvolver código HTML/CSS/JS
  • Desenvolver código server-side (dependente do código HTML/CSS/JS)
  • Testar (dependente de todas as tarefas anteriores)

É importante enfatizar o conceito de minimizar a dependência entre tarefas para não cair nos mesmos problemas de um modelo em cascata. A estrutura de um time e os processos envolvidos devem facilitar o paralelismo entre as tarefas de uma história para que idealmente se consiga iniciar e concluir uma história em um sprint. As dependências são problemas do mundo real que ficam mais explícito com a variedade de competências que uma história pode requerir. Por exemplo, para realizar testes funcionar é necessário que o desenvolvedor já tenha feito sua parte de acordo com o que foi planejado.

(De novo, o que exponho aqui são formas que alguns times do mundo real acharam para solucionar problemas. Tenho certeza que outros times por aí podem ter encontrado outras soluções bem mais fiéis ao framework.)

Neste cenário, o DoR inclui layouts e arquitetura que foram desenvolvidas pelo PO team ou por outra célula. Vemos aqui, de novo, que as histórias do designer não são as mesmas que as do programador. Muitas vezes, a visão de como o sistema deve funcionar não está completa até a aprovação do layout das telas.

Por outro lado, histórias podem ser criadas apenas para incorporar outras tarefas de UX, como testes de usabilidade. Estas histórias podem estar relacionadas a datas de releases, por exemplo.

Mais informações sobre Scrum podem ser encontradas no Agile Atlas.

Este artigo é uma continuação do texto “Criação + Scrum: como encaixar UX nas metodologias ágeis“, de 11/11/2012.

Tags: ,

Criação + Scrum: como encaixar UX nas metodologias ágeis

Andei conversando nos últimos dias com designers, arquitetos de informação e gestores que já estão trabalhando com metodologias ágeis. Notei que há muitas dúvidas de como a criação pode alinhar com desenvolvimento na prática. Vamos rever aqui alguns métodos de posicionamento das tarefas de UX dentro do modo de produção.

Obs.1: Não sou especialista em Scrum. Sou apenas mais uma parte desta engrenagem que luta diariamente para encaixar todas as etapas de crição de interfaces nas metodologias ágeis de desenvolvimento, com todas as dificuldades do dia-a-dia.

Obs.2: Esta não é uma regra e sim um estudo de caso. Cada empresa, assim como cada time, deve encontrar a melhor forma de adaptação à metodologia. Agências que possuem uma célula que lida com diversos clientes ou uma de dedicação exclusiva a um cliente devem se planejar de modo bem diferente.

Resumindo um pouco da terminologia que usamos na célula em que trabalho somente para referência:

  • Célula: grupo de pessoas com competências diversas responsáveis por entregar as funcionalidades de um produto.
  • Sprint: período de tempo para realização de uma entrega completa. Trabalhamos aqui com dez dias úteis.
  • Planning: reunião do time com o PO para tirar dúvidas sobre as regras de negócios. É realizada no primeiro dia do sprint.
  • Review: apresentação do trabalho realizado durante o sprint.

Nos casos estudados, contamos com os seguintes papéis e competências:

  • Product owner (PO): traz as regras de negócio, representando os interesses de clientes e usuários.
  • Scrum master: responsável por manter o ritmo da equipe, resolvendo impedimentos e atuando como mediador entre o time e outras áreas.
  • arquiteto de informação e designer de interação: elaboram as interfaces, estabelecendo a navegação entre telas ou funcionalidades.
  • front-end: responsável pelos métodos de codificação em HTML/CSS e da definição das tecnologias de interação (frameworks e plugins em JS).
  • desenvolvedor: integra o sistema o código HTML sugerido, realiza alterações no sistema e testes funcionais.

Lembro que há situações onde um profissional pode execer duas ou mais competências. Um designer de interação também pode fazer as vezes de um arquiteto de informação, assim como um front-end pode trabalhar programar em linguagens server-side.

Em teoria, teríamos que idealizar, planejar, criar e desenvolver uma funcionalidade em dez dias. Isto certamente funciona bem para a criação de uma nova microinteração ou a evolução de uma funcionalidade onde as tarefas relacionadas às diversas competências podem ser realizadas paralelamente. Vamos analisar história de uma manutenção evolutiva e suas possíveis complicações:

História: Como usuário quero participar de uma enquete com foto.
Contexto:
O time desenvolveu anteriormente uma funcionalidade de enquete em formato texto que precisa de evolução para atender uma nova necessidade do cliente.

1° cenário: um sprint
Sprint 1: O PO explica a nova necessidade e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas, enquanto os desenvolvedores alteram a funcionalidade. Após aprovação de layouts, o front-end corta em HTML/CSS e adiciona interação em JavaScript. O desenvolvedor integra o HTML ao código, publica em um ambiente de teste e todos validam.

Neste cenário, já encontramos alguns pontos de conflito. O time sente-se mais confortável em trabalhar com telas aprovadas pelo cliente/usuário. Nem sempre dentro do período de um sprint isto é viável. Consideramos que o review é o momento para a aprovação da entrega. Por que não aprovar também layouts, wireframes, fluxos de interação e relatórios de usabilidade?

2° cenário: dois sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, os layouts são submetidos para aprovação e a navegação sugerida é demonstrada.
Sprint 2: O front-end transforma o layout em HTML/CSS e adiciona interação com JavaScript. Ele também testa o modelo de navegação sugerido. O desenvolvedor integra o código HTML ao sistema e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam. Na review, a publicação de uma enquete com foto é demonstrada.

Parece que há perda de tempo neste cenário, mas isso não ocorre na prática. É possível tratar de mais histórias em paralelo. Na prática, é como se arquitetos de informação e designers estivessem em uma célula diferente que anda um sprint à frente.

(Na célula em que trabalho agora, trabalhamos boa parte das histórias em dois sprints. A diferença é que front-end faz sua entrega no primeiro sprint.)

Podem surgir outras complicações. Interações podem ficar mais complexas e demandar mais tempo de desenvolvimento exclusivo do front-end. Torna-se necessário aqui um sprint exclusivo para a montagem do layout em HTML, CSS e JavaScript.

3° cenário: três sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, são apresentadas as telas para atender à nova demanda.
Sprint 2: O front-end transforma o layout em em HTML/CSS e adiciona interação em JavaScript. Na review, são apresentados os protótipos funcionais.
Sprint 3: O desenvolvedor integra o HTML ao código e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam.  Na review, o sistema é apresentado completo.

Além disso, profissionais externos à célula, como analistas de usabilidade ou a equipe de infra-estrutura, podem demandar cortes durante o desenvolvimento para realização de testes. Os sprints mais cortados, quase que por competência, facilitam a integração com outras equipes. Nem sempre a interação leva apenas um sprint o que pode prejudicar o planejamento do time. No caso de testes de usabilidade, por exemplo, há fatores externos como seleção de usuários e agenda de laboratório. Tudo isso deve ser analisado história a história considerando os prazos negociados com clientes e usuários.

O terceiro cenário é o mais próximo do que considero bom hoje. É claro que demandaria um pré-planejamento de três sprints e nem sempre isso é possível.

Para fazer tudo isso funcionar, temos usado também o Kanban (que podemos ver em mais detalhes em outro artigo).

O importante antes de estabelecer uma forma de trabalhar é fazer as perguntas certas sobre o tempo e o nível de envolvimento entre todos os interessados. Além disso, nada impede que variáveis deste modelo podem ser usados como regra em todas as histórias, em histórias de um determinado sprint ou caso a caso. O melhor momento para esta definição é quando a demanda chega ao time que pode ser durante o planning ou em uma reunião anterior de priorização.

Como você e sua equipe trabalham? Tem alguma dúvida? Sugestão? Comente aqui!

Outras reflexões:

  • A formulação da estratégia de experiência do usuário pode ser incompatível com o processo do desenvolvimento ágil. Deve-se concluir toda a pesquisa e desenvolvimento de UX em um Sprint 0 antes de começar o desenvolvimento.
    Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?, por Paul Bryan (UX Matters).
  • Por outro lado, o time de UX deve sentir-se confortável para parar o desenvolvimento e reavaliar conceitos mais amplos. No artigo Fitting Big-Picture UX Into Agile Development (Smashing Magazine), Damon Dimmick introduz o conceito de design spikes.
Tags: , , , , , ,

A informação ubíqua

Desde a onda de popularização dos smartphones iniciada com o iPhone, os grandes publicadores acharam que a solução ideal para o conteúdo nos dispositivos móveis estava nos aplicativos. A premissa era que a marca seria forte e apelativa o suficiente para fazer com que o usuário baixasse um app e o abrisse diariamente em busca de informação. O custo de desenvolvimento e publicação de um aplicativo na Apple Store ou no Android Market seria recompensado através de um investimento no fortalecimento da marca ou por assinaturas. Esta premissa foi válida para algumas empresas por algum tempo.

No entanto, o usuário se acostumou a acessar a informação de vários modos num dispositivo móvel. Por RSS, a informação chega a aplicativos agregadores de conteúdo gerenciados pelo usuário, como Flipboard e Newsify. O conteúdo pode ser compartilhado e pré-visualizado em diversos mecanismos de busca, Facebook e Twitter. Inclusive, há protocolos específicos para visualização de dados nestes sites como Schema.org, Open Graph Protocol e Twitter Cards. Se o usuário não dispuser de tempo, aplicativos como o Pocket (antigo Read it later) e Instapaper armazenam o link para ser lido (ou não) depois. Podemos mencionar também outros agregadores como displays em elevadores, shoppings e ônibus. A relação entre produtor e consumidor de conteúdo torna-se mais complexa a cada mês, a cada novidade no mercado.

E, por outro lado, o custo e o tempo prolongado para o desenvolvimento e a publicação de cada aplicativo para cada tipo de dispositivo torna todo o modelo frustrante para o publicador.

Website do The Boston Globe: reformulado ano passado para ser inteiramente responsive.

É irônico que os velhos e conhecidos websites ressurjam como a opção mais viável para os grandes publicadores através de metodologias como responsive design e mobile first. Ao que parece, os mesmos profissionais que lidam constantemente com as diferenças de renderização dos navegadores são os mais qualificados para lidar com os diversos tamanhos de telas dos dispositivos móveis e com as diferenças de interação de um aparelho para outro.

Há um ano, o Financial Times abriu mão dos aplicativos para investir em um web app. A Folha de São Paulo seguiu pelo mesmo caminho. O conteúdo do Terra abre diretamente no web app não importa a origem (mecanismo de busca, rede social ou agregador de conteúdo). Todos estes publicadores de conteúdo e vários outros estão procurando neste exato momento um modo de que a informação exista e possa ser vista em todo o lugar, dentro e fora dos sites oficiais, conservando a força da marca e fortalecendo seu modelo de negócio.

A informação pode ser acessada de vários modos. Ela deve estar disponível de modo completo e através da melhor experiência possível. É o dispositivo que determina a interface e não o local de publicação do conteúdo.

Isso acontece não só com o jornal que virou um site que virou um app ou um web app. É uma tendência midiática por vezes reconhecida como transmidia storytelling. É o programa da TV a cabo que você só assiste quando precisa de uma receita para o almoço de domingo.

Decretaram a morte da web cedo demais?

Sir Tim Berners-Lee na cerimonia de abertura das Olimpíadas de Londres 2012: “This is for everyone”

Mais:
Forbes: More Mobile News Consumers Choosing Web Over Apps
Folha de São Paulo: Ao encontro do que leitores preferem, ‘NYT’ adota HTML5

Tags: , , , ,

Compras coletivas se embolam no luxo

MINI One CooperDois sites de compras coletivas promoveram esta semana um produto diferente. Longe dos milhares de cupons para tratamentos de beleza, jantares e hospedagens, estes sites venderam carros MINI Copper com 50% de desconto. A compra era possível para o primeiro mortal com um cartão de crédito com limite acima de trinta mil reais (ah, quem me dera ter um destes!).

Mas, como você já deve estar imaginando, os sistemas deste tipo de sites não suportam bem demandas muito altas ou promoções-relâmpago como estas porque não foram planejados para isso.

Para furar o Grupon, que divulgou a promoção alguns dias atrás, o ClickOn liberou a venda ontem um pouco antes da meia-noite com desconto de 57% no preço final do produto. Sem planejamento adequado aconteceu o (im)previsto: trinta usuários compram um mesmo carro no mesmo segundo sendo que apenas uma compra foi validada. Entre tantas acusações de fraudes, não vejo aquela que poucos têm coragem de fazer: quem foi que teve esta ideia?

Grupon promoveu a mesma compra, sim, mas não sem antes criar um concurso cultural. Aquele que enviasse a melhor frase teria o direito a saber o horário da liberação da venda do carro. Concurso cultural é uma saída nada criativa, eu sei, mas funcionou! A promoção só não foi um sucesso completo pois o usuário vencedor não é o comprador do carro. Mas não há ninguém questionando a empresa, a venda ou o ganhador nas mídias sociais.

Promoções são válidas para promoção de marcas, produtos e serviços, mas requerem um planejamento adequado. E não há planejamento sem tempo, sem brainstorm, sem infraestrutura, sem consultar todos os departamentos envolvidos (sim, a tecnologia também, por que não?) e, principalmente, sem um plano alternativo. O timing de uma promoção é apenas um dos elementos a serem considerados e talvez nem é o mais importante.

Mais aqui: ClickOn fura Groupon e vende MINI One por R$ 29.999, mas processo gerou desconfiança

Tags: ,

O luxo na era das compras coletivas

Recebi agora um cupom-desconto do MyHabit  um novo e-commerce da Amazon com ofertas de grifes como Dolce & Gabbana e Puma. Babei na experiência do usuário com sua vitrine em vídeo e interface minimalista. Há algum tempo tenho acompanhado o Fab.com, que possui a mesma proposta só que com itens de design.

Tela de produto do Fab.com

Estes sites fazem parte de uma tendência de evolução comercial dos de compras coletivas como Grupon e Peixe Urbano. A empresa fecha um acordo com produtos que precisam de visibilidade ou estão encalhados. A oferta fica disponível de um a três dias na loja virtual. Os usuários podem assinar a newsletter com as ofertas do dia. E sim, o email marketing será ainda por muito tempo uma das fontes primordiais de vendas no e-commerce.

Aqui podemos ver diversas oportunidades para investir no mercado de luxo. É uma indústria estável, com consumidores fiéis e que não entra em crise nunca. Vinhos, maquiagem, jóias, acessórios e gadgets, são vários os produtos que se encaixam em negociações de alto nível bem longe do perrengue dos salões de beleza e restaurantes. Mas será que esta será uma boa ideia para o mercado nacional, principalmente com a nova classe média que emergiu nos últimos anos? O que você acha?

Tela de produto do Fab.com

Tags: ,