O segredo das grandes companhias na Era Digital se resume a ser uma plataforma de tecnologia self-service que integra o físico e o online com produtos que satisfazem insights capturados no comportamento dos clientes.
Não existem mais empresas de serviços ou produtos
Não existem mais empresas de varejo, viagens, hotelaria, comidas, aluguel ou transporte.
Todas as compahias dessa nova era são empresas de tecnologias que entregam a melhor plataforma de varejo, viagens, hotelaria, comidas, aluguel ou transporte de forma transparente não importando qual canal o seu cliente acessa em busca do serviço ou produto.
Este é o momento do ponto de virada
O homem mais rico do Brasil, o bilionário Jorge Paulo Lemann, declarou no início de 2018 que era um dinossauro apavorado e acordou o mercado nacional de que a fórmula de atrair talentos, ter preços baixos e extrema eficiência na redução de custos não seriam mais suficientes.
O mundo plano dos negócios ainda entende essa fórmula como o modelo de atingir o sucesso mesmo enfrentando a mudança cultural tecnológica que chega pela concorrência.
Em um mundo de rápida inovação de produtos e diversos canais de vendas o diferencial é trazer a visão do consumidor para frente do negócio e entregar a melhor experiência Self-service.
Permita seu cliente não precisar de você
Antigamente você construía um serviço apoiado por tecnologias, agora você constrói tecnologias que entregam serviços.
As diretorias tradicionais sempre conduziram tecnologia como suporte de operações ou Core em apenas determinado ponto estratégico da empresa, isso está superado, as empresas não tem mais essa opção.
Não tem opção de não serem empresas de tecnologia.
Você dá bom dia ou boa tarde por educação enquanto os carros não são ainda autoguiados quando pede um serviço particular de transporte.
Você se hospeda em uma residência particular sem precisar interagir com o proprietário e aluga um imóvel sem pisar em um cartório.
Ao mudar seu processo de entrega, transforma as pessoas
Você não muda as pessoas em uma transformação, você muda o processo para elas se adaptarem.
Para inverter o Mindset de criar serviços para apoiar operações precisamos automatizar todas as operações para as pessoas apoiarem as plataformas.
Não se cria processo baseado em pessoas, se cria em pessoas apoiando o processo.
Em vez de criar um processo baseado em serviços que pessoas executam, o processo automatizado precisa de pessoas na tomada final de decisão.
Além do fato das empresas tradicionais possuírem um legado que se apegam (como Mainframe) fragilizando a automação seja pelo preço ou na própria velocidade de entrega.
Sim, transformamos a porta giratória em uma peça de museu. E, cá entre nós, o lugar dela sempre foi lá. Essa exibição foi única, mas você também pode se despedir dela pra sempre na agência bancária mais próxima e mandar pra gente uma foto aqui na thread #SouNupic.twitter.com/weEApsj98R
Olha como o Nubank nasceu com outra impressão digital, criou uma plataforma de auto-serviço pra seus clientes que desafoga a operação de atendimento.
Com um atendimento desafogado se torna muito mais humanizado, os atendentes podem ser especializados (porque diminui a vazão e pode contratar menos e melhor) que escrevem cartinhas de próprio punho aos clientes, além de resolver problemas no 1:1.
Empatia
Trazer a visão do consumidor pra frente num atendimento de auto-serviço torna os próprios funcionários nos maiores nos maiores influenciadores, quem se preocupa em atender bem e da melhor forma, cria empatia com todos os envolvidos.
Quem imaginaria que um dia amaríamos uma instituição financeira ao ponto de fazer Unboxing no youtube no recebimento do cartão?
3 Chaves da Transformação
Em resumo:
Trazer o cliente pra frente da missão, o segredo é como o atender automaticamente;
Criar plataformas modernas e ágeis guiadas por produtos que façam sentido pro sucesso do cliente;
Direcionar os produtos por dados.
No próximo Post (esse já ficou grande) vou falar sobre a estratégia de como fazer isso.
Após um ano trabalhando e divulgando PWA, preparei um upgrade do BeerSwarm com mais fôlego, mesclando Server-side Rendering, conteúdo e otimizações de SEO e performance que construiremos juntos nesse Workshop.
Acontecerá nos dias 15, 16, 17, 18 de maio de 2018 iniciando todos esses dias as 19h até as 21:00h. Dia 19 de maio de 2019 das 9h as 18h, com intervalo de 12 as 14h.
Utilizaremos o https://zoom.us/ para as aulas, os vídeos será disponibilizados para os inscritos após o curso.
Conteúdo
Experiência SPA e Content Centered 1.1 Criar estrutura no Heroku para Server-side Rendering 1.2 Setup e deploy com expressjs e Babel 1.3 Criar estrutura de views com create-react-app 1.4 Criar engine de template com react-dom/server no server side 1.5 Exemplo de código isomorfico usando redux 1.6 Criar estrutura de Hosting no Firebase para SPA
Mobile First e UX Design Patterns 2.1 Conceptual model 2.2 Complexion Reduction 2.3 User Journey Simplification 2.3.1 Linear User Flow com React Routes 2.4 Progressive Disclosure 2.5 Responsivo 2.5.1 Responsive Logos 2.5.2 Progressive Enhacement e Graceful degradation com Material Design
Offline First 3.1 Criando estrutura de dados no IndexedDB 3.2 Entendendo Service Workers, upgrade e migrate de versões 3.3 Criando Sagas (Middleware redux) para funcionar offline e online 3.4 Configurar https local pra validação
Web Instalável 4.1 Manifest, tags e configurações 4.2 Usando usuario anonimo com Firebase 4.2.1 Aprendendo generators e redux-saga 4.3 Vinculando usuario anonimo com login OAuth do Google 4.4 Pedindo localização do usuário 4.5 Integrando GMaps, Leaflet no App 4.6 Acessando a câmera e salvando fotos 4.7 Processos de sincronização e notificação com Web Workers 4.8 Compartilhando itens com Web Share API
Não existe uma fórmula pra isso, mas tem como trabalhar.
Disclaimer
Não existem dois times iguais simplesmente porque não existem dois seres humanos iguais, cada mudança de um membro você tem um time completamente diferente.
Portanto já saímos com o Mindset de que experiências passadas ou paralelas no máximo “ajudarão” a guiar o nosso instinto com tendências que deram certo ou errado.
Apelando para o bordão: “O todo é maior que a soma das partes”.
Desespero-me?
De maneira alguma, vamos aprender com a história, sobre o que deu certo e utilizar valores, princípios e práticas que garantam um monitoramento da saúde do coletivo e construa a cultura e motivação adequada a cada indivíduo.
Como eram os projetos de produtos de software nos anos 70/80
O formato que as equipes trabalhavam era a produção de um software seguindo um modelo tradicional de gerenciamento de projetos, uma equipe desenvolvia e outra recebia para manter.
O que se percebeu na época foi que esse modelo de “On-going” produzia diversos efeitos colaterais no produto final dado que o time que implementava não tinha o mesmo compromisso em qualidade de quem manteria pro resto do tempo em produção.
Além do fato de que projetos usavam times diferentes até na construção antes da ida pra produção, principalmente entre as fases de concepção e implementação.
Como a grande maioria dos projetos atrasavam e os testes ficavam como fase final, era comum serem relegados em prol da data de entrega.
Eram comuns também projetos demorarem 2 anos até serem colocados em produção, alguns levavam quase meia década (em off, eu trabalhei em um que levou uma década pra entrar em produção).
Vários profissionais experientes estavam desenvolvendo um modelo alternativo no início dos anos 90 (alguns iniciaram até um pouco antes), trocando informações entre si e por volta do final da década você tem algumas metodologias e métodos bem definidos e maduros.
Em 2001 nasce o famoso Manifesto ágil, que seria o contrato de valores fundamentais que definia o comum que esses modelos traziam para resolver os problemas na construção de Software.
Em resumo, daqui pra frente a abordagem de pensar em produto em vez de projeto e um time que deveria ter o compromisso na qualidade e ciclo de vida deste produto foi algo que deveria permeiar entre eles.
Entre outras coisas, conceitos como trazer os testes pra frente, já sabemos que sempre vai atrasar algo, então que a qualidade não seja comprometida.
Ultimamente Deploy contínuo, colocar em produção desde o primeiro dia pra ir ajustando a arquitetura com ferramental, monitoramento e Status Check.
“Ultimamente” entre aspas duplas, isso já tem pelo menos uma década.
Quem falou primeiro em equipes multidisciplinares
Vários autores da era Agile estavam referenciando times multidisciplinares e desenvolvimento de produtos.
Você tem um claro viés da transição nessa época no tópico “Production Support Team” no livro do Kent Beck, chamado Planning Extreme Programming de 2000.
Trecho desse tópico:
Two or four programmers volunteer to focus on fixing bugs. Each programmer spends a couple of iterations in production support, then rotates back to development. Every iteration there is at least one devel- oper doing their first iteration and at least one doing the second. This works well in that there is a pair that has the responsibility for dealing with support issues and this (usually unpleasant) work is rotated around the team. Actually it’s not the rotation that is key, it is the fact that the team decides themselves how to handle it.
Em tradução livre:
Dois ou quatro (1) programadores voluntários para focar no conserto de bugs. Cada programador levaria um par de iterações no suporte em produção, então rotacionam (2) de volta ao desenvolvimento. Cada iteração tem pelo menos um dev fazendo sua primeira iteração e outro fazendo a sua segunda. Isso funciona bem quando um par tem a responsabilidade de lidar com questões de suporte e este (geralmente desagradável) trabalho é rotacionado em torno do time. Na verdade, não é a rotação que é a chave, é o fato de que o time decide por si só como lidar com isso.
(1) Observe que número par, pra trabalhar no princípio de Pair Programming do XP.
(2) XP tem algumas práticas como Move People Around pra todos no time trabalharem em praticamente todos os requisitos e tecnologias.
Projeto tem começo, meio e fim. Mas um produto de software por ser maleável e evolutivo se difere do produto clássico das literaturas anteriores, dificilmente você vai matar um legado e na minha experiência nem faz sentido.
Afinal se aquela folha de pagamento está funcionando em Cobol, não temos tempo e dinheiro suficiente que demande uma mudança em vez de trabalhar em prol de novas abordagens de negócio.
Modelo Squads e Guildas
Não poderia deixar de citar o Spotify que chamou a atenção ultimamente para seu modelo multidisciplinar em torno da abordagem de construção de produtos. Uma evolução do pensamento dessas últimas duas décadas no mínimo.
Existem 3 tipos de profissionais quando falamos sobre evolução de uma produto em relação a tecnologia com times multidisciplinares:
Aqueles que por algum motivo se apegam a uma tecnologia e a defenderão com qualquer argumento para não haver mudança;
Aqueles que são Early Adopters e não querem trabalhar de forma alguma com legado;
Aqueles que entendem a necessidade e compromisso de ter que manter o legado, mas se sentem incomodados e gostariam de evoluir pra próxima tendência.
Existem Trade-offs nas 3 abordagens na minha experiência, na média desses profissionais você tem as seguintes características respectivamente:
São extremamente especialistas, conhecem a plataforma como ninguém e são mais aptos a solucionar problemas do presente, mas alimentam a ojeriza de qualquer mudança e até podem sabotar de forma inconsciente;
São especialistas em multi plataformas, estão preparados para o novo, mas contribuem pouco durante a evolução em relação a manutenção do legado, em contrapartida são os guiadores do processo de substituição;
São generalistas que podem atuar nas 11 posições (tomando analogia do futebol), não guiarão o processo de mudança, mas também não serão uma barreira de adoção.
Não quero “defecar” regra de qual tipo você deve dar atenção, acredito que é inevitável ter os 3 formatos no seu esquadrão, portanto é saber liderar e dosar o posicionamento correto de atuação entre os perfis.
Colocar o generalista ou o especialista do legado por exemplo pra puxar uma migração vai ser um tiro contra todos, vai conseguir desagradar a gregos e troianos.
Da mesma forma que colocar o Early Adopter pra manter legado e corrigir bugs vai só provocar ciúmes em quem ama a tecnologia e deveria ser o “dono”.
Mas claro, não são conselhos preditivos, existem graus entre os tipos e mais uma vez saber dosar requer um pouco de trabalho.
A melhor seleção brasileira de futebol considerada pelos críticos foi a de 82/86 com craques do porte de Zico e Sócrates perdendo penalti.
Você tem vários experimentos que unir muitas estrelas com o ego inflado vai provocar mais danos na moral do time do que resultados, além do que você provavelmente tem o Budget apenas pra montar um time coeso e defensivo com um bom artilheiro na frente e ganhar o tetra.
Feedback e Cultura
Como citei antes, dificilmente você vai conseguir matar um legado inteiro, então ter um time que consiga atuar bem em torno dos objetivos do produto demanda cuidar da cultura e um processo de Feedback que consiga identificar que tipo de profissional trabalha com você e não confiar apenas no instinto na hora de delegar responsabilidades.
Muitas vezes você atribui que alguém está acomodado ou não gostaria de evoluir uma plataforma, mas a cultura do seu ambiente não privilegia ou piora o desenvolvimento pessoal.
Algumas vezes o sujeito só está na hora errada em relação as suas motivações pessoais ou no time errado para suas habilidades.
Mas não quero dizer que você não deve ter profissionais caros e bons, claro que precisa, só que não precisam e dificilmente serão todos ou ter que remontar o time inteiro (aqui existem dezenas de variáveis a se discutir).
É fácil?
De forma alguma, mas temos literatura suficiente já “antiga” pra utilizar.
Em resumo o formato que melhor funciona durante toda a história do desenvolvimento de software é um time multidisciplinar com multisenioridade construindo um produto com autonomia completa se preocupando com todas as práticas de engenharia em prol da entrega, mas pensando ciclicamente na evolução constante e qualidade total.
Então para montar esse time crie uma jornada interessante, convoque múltiplos perfis adequados para ela e os motive com o objetivo certo, que é construir um produto sem defeitos e que entregue valor adequado a quem tem o problema que ele se dispõe a resolver e está disposto a utilizar!
