BT

Rápido aprendizado em design, desenvolvimento e DevOps

| Postado por Ben Linders , traduzido por Leonardo Ribas em 11 Mai 2015. Tempo estimado de leitura: 13 minutos |

A entrega de produtos certos de forma rápida pode ser um desafio, sem dúvidas, quando há muitas incógnitas ao longo do caminho. Se quiser construir produtos de forma rápida no contexto de elevada incerteza, é preciso ser capaz de aprender com rapidez e eficiência, disse Ismaël Héry do Le Monde em sua apresentação sobre aprendizagem rápida para construir rápido, na conferência de Lean Kanban Franca 2014.

Le Monde é uma marca francesa de notícias que publica artigos e fornece conteúdo on-line através de sites gratuitos e pagos e também aplicativos móveis com milhões de leitores por mês. Eles estão à procura de maneiras de compensar a queda nas receitas de impressão com receitas online. Ao desenvolver novos produtos eles são confrontados com muitas incógnitas. Em seu mercado é importante fornecer excelentes produtos de forma rápida, por isso eles estão constantemente procurando maneiras de encurtar o caminho para entrega e satisfação das necessidades dos seus clientes.

O InfoQ.com fez uma entrevista com Héry sobre como maximizar o aprendizado na definição do produto, desenvolvimento e operações de software, desenvolvimento e operações de ferramentas, estabelecendo uma cultura DevOps e melhorando a colaboração e aumentando o ritmo de aprendizagem.

InfoQ.com: Quais tipos de problemas foram vivenciados na definição do produto e design UX?

Héry: Para alguém que está enfrentando novos desafios de desenvolvimento de produtos, as principais questões que enfrentamos são:

Quem são os nossos usuários? Quais são os seus principais problemas? Por exemplo, quando construímos o novo CMS, precisamos reconhecer e compreender os mais diversos perfis de jornalistas que temos na Le Monde, em termos de idade, os principais objetivos, afinidade com tecnologia, o nível de pressão em determinado momento, entre outros.

Será que as nossas soluções funcionarão como o esperado, uma vez na mão do usuário? Por exemplo, em 2013 foi desenvolvido uma nova página inicial privada (la "Une" em francês) para o pagamento de assinantes. Esta nova página inicial foi estruturada e desenhada de forma completamente diferente em comparação com a página inicial gratuita do site. As questões que enfrentamos foram: ele funciona a partir de um ponto de vista editorial? Com que frequência devemos atualizar o conteúdo nessa parte? Quantos jornalistas precisamos para fazer essa parte do trabalho?

E, claro, para todos os recursos utilizados pelos leitores, queremos saber se o leitor precisa desses recursos e como ele ou ela irá usá-lo?

InfoQ.com: Em relação ao desenvolvimento e operação, quais foram os principais problemas nessas áreas?

Héry: Em termos de aprendizado, qualquer esforço de desenvolvimento de software traz um monte de incógnitas que precisam ser respondidas e descobertas durante o projeto:

Devemos usar esse framework ou aquele? Recentemente, transferimos uma completa pilha em Javascript para o nosso CMS: quais são os principais frameworks, bibliotecas, ferramentas de teste em nosso contexto?

Quanto tempo leva para desenvolver esse tipo de recurso? Mesmo quando a variabilidade é muito alta, queremos saber o esforço necessário para a sua característica típica (por exemplo tela complexo médio ou interação) tão rápido quanto for possível.

É possível fazer testes automatizados com essa nova tecnologia? O quão fácil será para escrever esses testes? É possível integrá-los com o processo de integração contínua? Quanto tempo a equipe precisará para dominar a escrever esses testes, respeitando as melhores práticas (ainda desconhecido em si)?

No lado da operação, incógnitas que enfrentamos frequentemente são:

  • Qual é a melhor estratégia para manter o ritmo de atualizações dessa nova tecnologia?
  • Quais seriam os principais pontos fracos deste sistema uma vez em produção?
  • Quais são as métricas e dashboard mais importantes que devemos ter? E quanto as notificações?
  • Quando a carga do usuário aumenta no sistema queremos saber qual será o próximo gargalo quando tivermos 10x mais usuários? Na camada de banco de dados? Nos servidores web? Em outros lugares?
  • Como podemos criar um mecanismo de implantação indisponibilidade zero nesse novo sistema?

Qualquer planejamento do projeto ou produto que fazemos é implicitamente com base em uma série de suposições sobre essas questões (ou pior, ignorando a existência dessas perguntas e precisa de respostas), porém no início não temos idéia sobre a maioria deles.

Otimizando a execução com as melhores práticas tradicionais é muito sábio, otimizando o aprendizado e a descoberta sobre essas questões é fundamental!

InfoQ.com: Foi explorado diferentes maneiras de maximizar a aprendizagem no domínio da definição do produto, desenvolvimento de software e operações. Que tipo de práticas foram usadas? Pode dar alguns exemplos?

Héry: Em relação a parte do produto:

Estamos fazendo estúdios de design há mais de um ano: são sprints muito curtas, de prototipagem rápida em papel com vários usuários ou colaboradores-chave. Ele gera um monte de idéias e pode matar impasses de forma rápida!

Também fazemos mais e mais prototipagem rápida com wireframes interativos criados pelos gerentes de produtos. Aqueles (às vezes muito convincentes) protótipos nos permitem ter o feedback do usuário muito brevemente e são muito mais baratos do que codificação real.

Teste de usuário é, naturalmente, outro elemento chave na caixa de ferramentas do gerente do produto. Não fazemos de forma sistemática, mas mês após mês testamos nossas melhores suposições, observando a interação dos usuários com os nossos produtos em condições mais próximas possível de situações reais.

Essas práticas e ferramentas podem parecer bastante óbvias agora, mas há ainda uma grande mudança cultural em relação à "pensar que sabemos melhor o que nossos usuários querem e estão dispostos a pagar" e contar mais com a descoberta e testes com usuários. Essa mudança ainda está em curso, mas já tivemos melhorias realmente impressionantes recentemente!

Também favorecemos práticas que maximizem a aprendizagem para todos os atores independente se eles são de produtos, devs, ou ops:

Implantação em produção muito antes é o principal. Moldamos nossos sistemas técnicos e planos de projeto para ser capaz de implementar partes do produto final em produção rapidamente. Nesta fase, muitas vezes é realmente quebrado ou às vezes nem utilizável pelo usuário final, mas mesmo nesse caso, o aprendizado é enorme:

  • Foco em produtos para as pessoas com foco em problemas que realmente deve ser resolvido;
  • Temos muitas idéias e profunda convicção de que é o problema número um ... até que; vejamos os usuários reais, usando o nosso produto em condições reais;
  • Foco em pessoas de tecnologia sobre os problemas reais. Precisamos pensar no que pode ser o elemento mais fraco ou em qual parte o sistema irá falhar quando a carga aumentar, entre outros. Fazer a implantação o quanto antes significa testar a realidade inicial sobre esses assuntos;
  • Temos sistemas complexos que não podemos reproduzir completamente antes de entrar em produção. Do ponto de vista da arquitetura, muito do aprendizado acontece depois da implantação em produção;
  • Claro que nos deparamos com muitos incidentes com a implantação antecipada. Isso traz uma série de explicações para as falhas durante o projeto, no qual possibilita um sistema mais robusto e melhor gerenciável (monitoramento, alerta, registros) para quando o dia da entrega chegar;
  • Não em relação a aprendizagem em si, mas a forma de produzir o quanto antes, aumenta a moral e o compromisso;

Claro que a implementar o quanto antes vem acompanhado de muitos custos, principalmente em engenharia, mas também no desenvolvimento do produto, quando se gasta muito tempo e energia com os seus usuários "beta", tentando fazer com que eles usem o seu produto em fase de desenvolvimento e coleta de feedback.

E finalmente, também usamos uma prática muito poderosa para maximizar o aprendizado quando priorizamos: Quando temos a opção de escolher entre dois caminhos no qual grosseiramente retornam o mesmo investimento, preferimos escolher o caminho que tenha o máximo de potencial de aprendizagem.

InfoQ.com: Tem alguns exemplos de como se faz teste de usuário? O que foi possível aprender observando os usuários?

Héry: Para as equipes/produtos mais experientes, tipicamente identificamos uma área e a hipótese que queremos verificar (normalmente, "Esse recurso resolve o problema do nosso usuário?").

O gerente de produtos, às vezes apoiado por um especialista UX, prepara o teste em si. O teste é uma sequência de perguntas que pedem que o usuário tentar fazer alguma coisa.

Para cada exercício temos uma lista de verificação para garantir que teremos todas as informações que pudermos a partir do teste:

  • Qual é o exercício solicitada ao usuário?
  • O usuário executou esse exercício de maneira rápida/devagar? Ele precisou de ajuda (=> falha)?
  • Quantos erros ele cometeu?
  • Algum sinal oculto ou explícito de apreciação?
  • Alguma outra coisa foi observado?

Há sempre duas pessoas, uma fazendo o exercício e interagindo com o usuário de forma que não o atrapalhe, e uma pessoa que toma notas de tudo em silêncio.

Cada execução de teste de usuário nos ensinou muito. As coisas que pensávamos que seria não seria difícil acabou por ser muito difícil de entender e nas outras coisas pensávamos ser muito difícil acabou por ser óbvio para os usuários!

O aprendizado baseado em metadados mostra que nossas intuições sobre o comportamento dos usuários estão errados quase 50% do tempo.

InfoQ.com: Que tipo de ferramentas são usadas para desenvolver os produtos e fazer as implantações frequentemente?

Héry: Temos muitas plataformas técnicas: PHP para web front end, iOS e Android para aplicativos móveis e nodeJS para nosso CMS.

Usamos ferramentas customizadas para implentação web, isso faz quase o que a ferramenta de automação de servidor remoto chamado capistrano faz, mas não estamos muito acostumados a Ruby e ambos desenvolvimento e operação gostam de customizar suas ferramentas para se encaixar no contexto.

Além disso, temos uma caixa de ferramentas clássica com Git e Jenkins. Escrevemos diversos de testes de unidade sobre os mais recentes stacks, e testes de ponta a ponta que simulam usuários na interface.

Usamos Graphite / Grafana e Kibana para métricas e logs de análise e M / Monit e PagerDuty para alertas. Os dashboards que temos com essas ferramentas são fundamentais para manter a produção com muita frequência e ser capaz de detectar problemas facilmente, com base nos logs e métricas e buscar correlações entre os eventos (normalmente de um empurrão para produções e uma mudança de desempenho).

InfoQ.com: Existem outras práticas técnicas que está usando e vale a pena mencionar?

Héry: Não fazemos muita programação em pares, mas fazemos revisões sistemática de código que agora é parte da nossa cultura e nossos hábitos.

InfoQ.com: Uma vez que os domínios mencionados estão relacionados foi necessário equilibrar o aprendizado. Como isso foi feito?

Héry: Quando responsável por obter o design de produto, construir e operar, não estamos interessados em ter o melhor desempenho do mundo da equipe de UX, se os devs e ops não são capazes de levar para a produção pelo menos uma vez por semana. Pelo contrário, qual é o ponto de se efetuar uma entrega e até mesmo uma implantação de software "funcionando" todo dia se experiência do usuário é uma piada?

Achamos que as equipes e os gerentes tem grandes responsabilidades em ter uma compreensão holística do que é necessário para obter o produto feito, e manter um olho sobre as melhores formas para fazer essas atividades (não ser obcecado apenas por Lean UX, Desenvolvimento Ágil de Software ou DevOps). Preferimos ter um nível coerente de aprendizagem nesses domínios diferentes.

InfoQ.com: Pode dar alguns exemplos do como os gestores fazem para apoiar a colaboração entre desenvolvimento e operações?

Héry: Como gestores tentando aumentar a colaboração entre dev e ops, primeiro removemos os atritos e capacitamos os devs e segundo elevamos o trabalho em equipe e a empatia.

Para remover os atritos e capacitar os devs, tentamos evitar depender de ops quando os devs podem fazê-lo corretamente e com segurança por si só:

  • Dê aos desenvolvedores à habilidade de elevar a produção;
  • Dê aos desenvolvedores a habilidade de usar e gerenciar dashboards monitorados;
  • Dê aos desenvolvedores o acesso aos servidores de produção;
  • Tenha alguns desenvolvedores de plantão (para alguns de nossos produtos).

Ainda temos uma série de melhorias pela frente, especialmente ser capaz de criar ambientes desenvolvedores e teste mais facilmente e sem ops precisar realizar enormes esforços.

Para aumentar a empatia:

  • Organizamos reuniões de arquitetura com ambos quando temos a sensação de que eles podem pode evitar ou simplesmente esquecer uns aos outros em um determinado ponto;
  • Operadores são convidados para reuniões de projetos regulares e projetos principais (reuniões em pé, rituais de sprint ...);
  • Desenvolvedores são convidados a palestras técnicas de operações e ops para palestras técnicas de desenvolvimento;
  • Esses momentos são realmente excitante do ponto de vista do gerente, porque observamos a incrível criatividade, colaboração e equipe de trabalho que levam a contrariar medidas ou melhorias que ninguém teria pensado em isolamento!

É claro que estamos olhando para uma colaboração natural, sem contar com as intervenções da gestão, mas, por vezes, a administração precisa apoiá-lo.

InfoQ.com: Pode compartilhar como essa iniciativa de aprendizagem ajudou a estabelecer uma cultura DevOps e melhorar a colaboração entre desenvolvimento e operações?

Héry: Isso tem haver principalmente em relação à fazer o deploy em produção o mais breve possível durante o projeto e, em seguida, fazer isso constantemente. Assim dev e ops terão mais tempo para enfrentar problemas típicos dev / ops para resolvê-los juntos ao longo de todo o projeto, e não apenas no último momento em que dev está sobrecarregado com bugs e solicitações de recursos, e ops em pânico com incidentes e aumento de carga. É uma maneira de evitar um efeito típico que realmente prejudica o relacionamento.

Mas esta abordagem necessita de treinamento e atenção da administração, pois ainda é difícil de aceitar para alguns devs e ops que gostam de se evitar o contato até o último momento possível.

InfoQ.com: Quais os principais aprendizados obtidos na Le Monde que as pessoas pode usar para aumentar o ritmo de aprendizagem em suas organizações?

Héry: Implantação em produção gera de longe, a maior quantidade de conhecimento para todos os atores (produto, dev, ops) e por uma ordem de magnitude.

Aproveitando as práticas e ferramentas que favorecem tanto a execução quanto a aprendizagem é muito importante.

Pessoalmente, após anos de gestão e coaching de equipe de designers, desenvolvimento e operação de novos produtos, vejo que o lado da aprendizagem da equação é tão importante quanto o lado da execução, mesmo se os clientes e partes interessadas pagam por aquilo que tenho executado no final, é claro!

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
BT