Introdução à Arquitetura de Micro Serviços

Workshop IFRS
Workshop IFRS

Tem uns 2 anos que passei a ouvir falar de micro serviços (microservices) mas faz poucos meses que passei a me interessar realmente pelo tema, uma vez que comecei a estudar Node.js para uso em meus projetos.

Micro serviços é uma maneira particular de desenvolver aplicações de maneira que cada módulo do software é um serviço standalone cujo deploy e escala acontecem de maneira independentes da “aplicação principal”. Enquanto na arquitetura tradicional de software, chamada monolítica, quebramos uma grande aplicação em bibliotecas, cujos objetos são utilizados in-process, em uma aplicação modular como proposta na arquitetura de microservices cada módulo recebe requisições, as processa e devolve ao seu requerente o resultado, geralmente via HTTP.

A ideia não é exatamente nova, é usada em ambientes Unix desde a década de 60, mas recentemente se tornou o epicentro de uma grande revolução na forma como as empresas estão desenvolvendo software ágil baseado em equipes enxutas responsáveis por componentes auto-suficientes.

Neste post irei abordar os conceitos, detalhes, vantagens, desvantagens e principais dúvidas dessa arquitetura, bem como porque ela está sendo tão utilizada atualmente e como começar a organizar suas aplicações orientadas dessa maneira.

Veremos neste artigo:

A motivação por trás dos micro serviços

Muitas são as buzzwords do mundo de desenvolvimento de software e esta me pareceu mais uma quando a ouvi pela primeira vez. Apesar do seu nome ser auto-explicativo, é interessante estudarmos os reais impactos que uma arquitetura composta por diferentes módulos conversando via um canal lightweight como HTTP pode causar na forma como programamos e nos resultados que obtemos com software.

Resumidamente, o estilo de arquitetura em microservices é uma abordagem de desenvolver uma única aplicação como uma suíte de pequenos serviços, cada um rodando o seu próprio processo e se comunicando através de protocolos leves, geralmente com APIs HTTP. Estes serviços são construídos em torno de necessidades de negócio e são implantados de maneira independente geralmente através de deploy automatizado (pelo menos em um cenário ideal deveria ser assim). Existe um gerenciamento centralizado mínimo destes serviços e cada um deles pode ser escrito em uma linguagem diferente e utilizando persistências de dados diferentes também.

Para entender melhor a motivação por trás de microservices vale relembrar como os projetos são programados hoje, geralmente em três grandes partes: um client-side com a interface do usuário, uma base de dados com as informações do sistema, e uma camada server-side com a lógica da aplicação. A camada server-side lida com as requisições do usuário, executa a lógica de negócio, retornar e atualiza dados da base e disponibiliza informações prontas para o client-side exibir. Isto é um monólito ou aplicação monolítica, uma vez que gera uma única e grande aplicação com tudo junto. Qualquer mudança no sistema envolve em compilar tudo novamente e implantar uma nova versão do server-side inteiro no servidor.

Toda a aplicação roda em um único processo, usando uma única linguagem server-side e geralmente uma única tecnologia de persistência de dados. Para escalar esse tipo de aplicação você pode adicionar mais recursos no mesmo servidor (escala vertical) ou fazer cópias desse servidor e colocá-las atrás de um load balancer (escala horizontal).

Aplicações monolíticas não são ruins e podem ser muitíssimo bem sucedidas. No entanto, cada vez mais equipes estão frustradas com suas limitações, principalmente quando estão implantando projetos na nuvem. Nestes cenários, os ciclos de mudanças, geralmente rápidos e pontuais como os propostos no Lean Startup, acabam afetando toda a aplicação pois o deploy é monolítico, assim como a aplicação. A escala horizontal requer um custo alto, pois sempre deve ser duplicada a aplicação inteira, e não apenas a parte que necessita de mais desempenho.

Vale lembrar também que aplicações monolíticas exigem que todo o codebase server-side seja escrito na mesma linguagem de programação, o que impede que você tire o máximo proveito de cada cenário usando a ferramenta mais apropriada à ele. Também impede que cada time desenvolva com a maior velocidade possível uma vez que a base de código é a mesma entre todos times.

Estas frustrações levam à arquitetura microservices de construir aplicações como um conjunto de serviços. Como os serviços são implantados de maneira independente, a escala se dá individualmente, tanto na vertical quanto na horizontal, para os serviços que estão precisando de mais desempenho. Usando protocolos comuns e contratos (interfaces) bem definidos, você consegue usar linguagens de programação diferentes de cada serviço, bem como mecanismos de persistência auxiliares que possam ser necessários para cada um deles, como mecanismos de cache, filas, índices, etc.

Para finalizar esta seção, a imagem abaixo do blog do Martin Fowler ilustra bem a diferença da escala entre as duas arquiteturas: monolítica e de micro serviços:

Vantagens e desvantagens de microservices

Não existe uma definição formal de como uma aplicação baseada em micro serviços deve ser construída, mas depois de muito ler a respeito e estudar o assunto notam-se algumas particuliaridades frequentes que podemos denominar como um padrão comum para microservices.

Sempre existiu o desejo dentro da indústria de software de construir programas apenas plugando componentes. Os primeiros esforços neste sentido foram as bibliotecas de funções, mais tarde as bibliotecas de classes e atualmente está em voga os serviços. Note que a componentização sempre existiu, mas o que propõe-se com microservices é que cada componente seja uma aplicação separada e especializada em apenas uma parte da aplicação “completa”. A principal razão por trás dessa escolha, de serviços ao invés de bibliotecas, é que serviços podem ser implantados de maneira separada. Você já tentou atualizar seu software apenas subindo para produção uma DLL ao invés de todas (ou ao menos todas as suas)? É um risco que não vale a pena correr, pois o acoplamento entre as DLLs é muito alto e o ideal é sempre a recompilação do sistema como um todo.

Claro, existe uma desvantagem clara no uso de serviços ao invés de bibliotecas: performance. Bibliotecas rodam no mesmo processo da aplicação, usam memória compartilhada, etc. Serviços dependem de canais de comunicação, como HTTP, para conseguirem tratar e responder as requisições. Exigem também uma coordenação entre os contratos de serviço para que os consumidores consigam “conversar” com os serviço da maneira que eles esperam, bem como receber as respostas que estão preparados.

Esse problema é especialmente preocupante conforme você tenha muitas chamadas síncronas entre seus serviços, pois o tempo de espera total para seu sistema responder será igual à soma de todos os tempos de espera das chamadas síncronas. Neste momento você tem duas opções: mudar para uma abordagem assíncrona ou reduzir o máximo que puder o tempo de espera (e a quantidade) das requisições síncronas. Node.js é uma tecnologia que tenho estudado bastante recentemente e trabalha muito forte com o conceito de chamada assíncronas, muito usado pelo Netflix para não bloquear a experiência do usuário. No entanto, quando isso não é possível, como foi o caso do site do jornal The Guardian, tente limitar o número de chamadas síncronas que você vai precisar, o que no caso deles é a regra de apenas uma chamada síncrona por requisição do usuário.

Apesar desses problemas citados, os benefícios parecem superar os downsides dessa abordagem, pois cada vez mais empresas estão adotando-na.

O que você deve ter em mente

Os serviços irão falhar. Talvez não todos juntos, talvez não rapidamente, mas vaia acontecer. Sendo assim, você deve estar sempre preparado para a falha de um ou mais serviços.

Essa é uma consequência de usar serviços como componentes e sua aplicação deve ser projetada de maneira que possa tolerar a falha de serviços. Qualquer chamado a um serviço pode falhar devido à indisponibilidade de um fornecedor e você tem de saber lidar com isso de maneira amigável com o restante do sistema. Esta talvez seja a maior desvantagem dessa arquitetura se comparada ao jeito monolítico tradicional, uma vez que adiciona uma complexidade adicional significativa. Times que trabalham com micro serviços devem constantemente refletir como a falha de cada serviço afetará a experiência do usuário. No Netflix por exemplo, partes da bateria de testes diária deles inclui derrubar servidores e até datacenters para ver como a aplicação se comporta nestas situações.

Uma aplicação em micro serviços deve ser monitorada em um nível muito superior ao de uma aplicação monolítica tradicional, uma vez que os serviços podem falhar a qualquer momento e se possível, restaurar o funcionamento completo automaticamente. Monitoramento em tempo real deve ser enfático no processo de desenvolvimento, implantação e operação dos serviços. Não que você não tenha de ter esse mesmo cuidado com aplicações monolíticas, mas apenas que com micro serviços isso não é uma opção.

O quão grande é/deve ser um micro serviço?

Uma pergunta bem comum e que cai como uma luva para o próprio nome da “arquitetura’ é: o quão grande deve ser um micro serviço?

Infelizmente o nome micro serviço nos leva a perder tempo demais pensando no que exatamente micro quer dizer. Diversas empresas, de Amazon a Netflix, usam micro serviços de variados tamanhos e não há um consenso sobre eles. Especificamente na Amazon, considerando que cada micro serviço é (e deve) ser tratado como um produto separado e tem seu próprio time (squad, na verdade), eles usam a regra Two Pizza Team: se o time precisa de mais de duas pizzas por refeição para se manter alimentado é porque está grande demais, o que significa não mais de que 12 pessoas. No outro extremo, os menores times recomendados pela Amazon possuem 6 pessoas, o que eu pessoalmente, em minhas experiências como Scrum Master, acredite ser o ideal (você ainda pode chamar meus times de Two Pizza Team considerando que todo mundo gosta de comer vários pedaços de pizza!).

Resumindo, embora não exista uma regra, podemos assumir que se você precisa de uma equipe de mais de 12 pessoas para desenvolver e manter um serviço (considerando tudo: programação, infra, testes, etc), ele está grande demais e você deveria quebrá-lo em serviços menores.

Como começar com micro serviços?

Projetos usando micro serviços geralmente não nascem assim do dia para a noite. O que nota-se na maioria das implementações bem sucedidas é que elas vieram de um design evolucionários, vendo a decomposição em serviços como uma ferramenta que vai aos poucos ajudando a quebrar uma aplicação monolítica que está com problemas de escala, qualidade, etc em diversos componentes menores.

Neste cenário, o maior desafio é saber como que o monólito irá ser quebrado em serviços. O quê deve ser agrupado em conjunto? O que deve estar separado? Quais bases de dados serão usadas por quais serviços?

Um dos princípios-chave por trás dessas decisões é o de deploy e escala independentes entre os serviços. Se dois serviços sempre tem de ser colocados em produção em conjunto, eles deveriam ser um serviço só. Agora se eu tenho um serviço cujas publicações acontecem sempre por causa de alterações pequenas em um dos seus módulos internos, esse módulo interno deveria ser transformado em um serviço per se.

O site do jornal britânico The Guardian é um bom exemplo de aplicação que foi projetada e construída como um monólito e que vem evoluindo na direção de micro serviços. O monólito ainda é o core do site, mas eles têm adicionado novas funcionalidades usando micro serviços que consomem a API do site principal. Esta abordagem é particularmente interessante pra eles principalmente nos casos de módulos temporários, como um hotsite para cobrir um evento esportivo.  Estes hotsites podem ser programados rapidamente na linguagem que for mais conveniente e jogados fora uma vez que não fazem mais sentido.

E aí, motivado para trabalhar com essa abordagem? Vamos trocar experiências nos comentários!

 

Como inovar?

Inovação é um tópico constante (e importante) entre as empresas de tecnologia em geral. Não apenas na tecnologia, mas inovar em diversos setores é importantíssimo em um mundo globalizado e competitivo como o nosso, se quisermos nos manter no mercado. Como empreendedor, inovar pra mim significa trabalhar de maneira inteligente para obter resultados acima da média com menos esforço.

Mas antes de falar sobre como inovar, o que seria inovação, exatamente?

Tipos de Inovação

Muitos estudiosos separam inovação em duas categorias distintas: inovação evolutiva e inovação disruptiva.

japan-innovation

Inovação evolutiva é o carro-chefe dos japoneses. Pegar algo que já existe e deixar ele melhor, mais rápido, menor, mais barato, etc. Evoluir sobre produtos já existentes, melhorando a experiência geral com o produto. Este é o tipo de inovação “mais fácil”, pois constrói-se em cima do que já existe. É o que vemos em nossos smartphones, ano após ano, em nossos computadores, carros, etc.

Inovação disruptiva era o carro-chefe do falecido Steve Jobs e de muitas startups do Vale do Silício. É criar algo inteiramente novo ou com um conceito completamente diferente do que as pessoas estão acostumadas.

Não é criar um computador um pouco mais rápido que os antecessores, mas sim criar um notebook que pode ser guardado em um envelope ou ser passado por baixo da porta.

Não é criar um app para chamar táxi (o que seria uma evolução dos disk-táxi convencionais), mas sim um ecossistema de motoristas autônomos mundial.

Não é criar mais um site de reserva de hotéis, mas sim um marketplace onde qualquer pessoa do mundo pode alugar e pôr imóveis para alugar.

A disrupção é o que chama a atenção de verdade. É o mais arriscado de se buscar, mas que quando dá certo, é o que “dá mais certo”.

Os grandes inventores e empreendedores que todos lembramos são aqueles que inovaram pra valer, e não apenas colocaram um botão a menos ou a mais em algum produto.

Jobs inovou no PC quando todos acreditavam que computadores eram coisa pra empresas. Gates inovou no software quando todos achavam que o hardware é que era importante. Einstein inovou na física e na nossa própria concepção de realidade em meio ao tumulto das guerras, quando todos queriam apenas armas mais eficientes.

Note que existe uma linha tênue entre o que é evolutivo e o que é disruptivo. Muitas vezes a disrupção vem ao evoluirmos um produto de maneira tão brusca e impactante, que causa esse efeito “uau” de inovação que os produtos da Apple tinham no passado. Geralmente associamos este passo da inovação para a disrupção através da regra das 10x, citada por vários autores entre eles Grant Cardone.

A regra dos 10x

Essa regra diz que se você quiser ser realmente inovador (indo mais pra linha da disrupção) você deve ser 10x melhor que a concorrência.

Quando Jeff Bezos abriu a Amazon, ele não saiu do modelo de livraria tradicional com 10.000 títulos para uma livraria digital com 10.000 títulos. Ele partiu logo para 100.000 títulos. 10x mais.

Quando o Google entrou no mercado de busca ele não tinha “um pouco mais sites” que o Altavista em seu índice, ou seu algoritmo era x % melhor. Ele entrou indexando a web inteira, investindo pesado em processamento pra que os resultados realmente fossem relevantes.

Mas como inovar?

Grande parte das inovações bem sucedidas vem da resolução de problemas ou necessidades do dia-a-dia.

No mundo das startups chamamos isso de “coçar a própria coceira”. Você tem um problema, verifica se outras pessoas possuem o mesmo problema e decide resolvê-lo, sendo que em dado momento monetiza essa resolução e ganha dinheiro com isso. Essa é a receita básica da metodologia Lean Startup.

Muitas pessoas tem dificuldade de aplicar essa “receita”. Isso porque a maioria das ideias surgem quando estamos em modo de “tempo consciente”.

Tempo Consciente

Tempo consciente é um conceito que diz que no dia-a-dia fazemos muitas coisas no modo automático. Acordamos, vamos ao trabalho, vemos TV, lemos emails, etc. Tudo de maneira pouco crítica e quase sem perceber as nuances de tudo que está acontecendo.

Estar em seu tempo consciente é praticamente ver a situação em “terceira pessoa”, muitas vezes enxergando a si mesmo executando suas tarefas cotidianas. Esse exercício mental permite racionar com mais clareza sobre as falhas nos processos e produtos do dia-a-dia. É quase como olhar alguém usando seu software para ver como ele usa cada tela ou quais ele não entende. Só que consigo mesmo.

Uma dica de exercício: sempre que reclamar de algum produto ou serviço, seja físico ou digital, pare e pense como isso poderia ser resolvido. Qual seria a versão “correta” para aquele produto ou serviço? Obviamente você não vai querer resolver todos os problemas do mundo, mas este exercício de questionar a si mesmo como algo poderia ser melhor, é o caminho para se chegar nas boas ideias.

Claro, a maioria das ideias que virão à tona dessa análise em modo consciente serão ideia evolutivas em relação à coisas já existentes. Para partir daí para a disrupção é necessário ou aplicar a regra das 10x que citei antes, ou então não inovar na característica mais óbvia do problema, mas sim na essência do mesmo, que geralmente está atrelada aos desejos e anseios do usuário em relação ao produto ou serviço.

Como assim?

Quando usamos um produto ou serviço, nosso objetivo não é o produto ou serviço em si, mas sim o que ele vai nos proporcionar. Ninguém compra um smartphone pois quer andar com ele no bolso, mas sim poque quer se comunicar com seus amigos, quer tirar fotos em momentos de alegria, quer ouvir música em momentos entediantes e por aí vai.

O smartphone é o meio, não o fim, para diversos desejos e anseios que temos.

Vamos pegar o carro, que é outro exemplo bem conhecido.

Henry-ford-and-model-T

Na época em que Ford criou seu modelo T, o mais comum eram as pessoas andarem à cavalo ou em veículos de tração animal. A inovação mais óbvia, e provavelmente mais requisitada, eram cavalos mais rápidos, carroças que quebrassem menos, etc.

Mas ao invés de fazer a inovação mais óbvia, e evolutiva, Ford entendeu que as pessoas queriam se locomover. Que elas não gostavam dos cavalos e das carroças por sua mera existência, mas pela sua utilidade. Ele entendeu que o importante não a carroça e o cavalo, mas levar pessoas do ponto A ao B de maneira rápida e segura. Ele focou na criação do seu carro.

Outra inovação que parece tola mas que faz muito sentido foi a dos espelhos nos elevadores.

elevador

Há década atrás os elevadores não possuíam espelhos. Em prédios altos como os existentes nos EUA, subir do primeiro ao último andar de elevador leva mais de um minuto, o que é um tempo longo para quem está sem nada para fazer e que gerava muitas reclamações.

Qual era a inovação mais óbvia aqui?

Elevadores mais rápidos, é claro! Para isso teríamos que dimensionar novos motores, sistemas de emergência, mexer na engenharia como um todo.

O que se compreendeu foi que o real problema não era o elevador demorar 1 minuto para subir do primeiro ao último andar. Esse é um tempo razoável e que não causava problemas à ninguém. O problema real não era a velocidade, mas sim a falta do que fazer dentro do elevador durante esse tempo, o que angustiava as pessoas. Precisávamos dar algo pra elas fazerem.

Assim surgiu a ideia de pôr espelhos nos elevadores e mais tarde até televisores, principalmente em prédios comerciais, onde você vê notícias de economia e política, bem como cotações de moedas e ações enquanto sobe para a sua reunião importante ou para trabalhar.

Ok, televisores fazem sentido, mas espelhos?

Sim. A maioria das pessoas que reclamam da demora de um elevador é porque estão com pressa, geralmente atrasadas para uma reunião, trabalho, encontro, etc. Dificilmente você reclama de um elevador quando está se divertindo em um shopping, por exemplo. E quando você está atrasado para um compromisso, qual é a sua outra preocupação? Sua aparência.

Bingo!

Um espelho te dá algo para fazer enquanto aquele longo 1 minuto não passa e ainda te ajuda a verificar se está tudo bem com sua gravata, topete, dentes ou o que quer que esteja te preocupando.

Note que tanto o carro quanto o espelho no elevador não eram inovações óbvias. Foi necessário olhar o problema sob ângulos diferentes para entender o que realmente era o problema. No caso de Ford, foi a criação de um produto inteiramente novo. No caso do elevador com espelho, foi a melhoria do produto já existente, mas de uma maneira impensável à primeira vista.

Indo além

Não existe uma maneira “certa” de inovar e nem uma receita de bolo, embora existam livros como o Game Storming e Business Model Generation com dinâmicas que você pode realizar para gerar ideias inovadoras.

Técnicas como Jobs to be Done, brain storming e design thinking também são muito utilizadas nas empresas em busca da inovação.

Mas em linhas gerais, tenho certeza que as dicas que te passei podem lhe ajudar bastante a entender o processo de criação da inovação.

Até mais!

5 segredos das pessoas altamente produtivas

hoa-agendaEu me considero uma pessoa altamente produtiva. Modéstia à parte eu vivo com as mesmas limitações de tempo que todas as pessoas: dias de 24h, mas consigo fazer muito mais que a média das pessoas com o mesmo tempo que lhes é dado. Isso vai desde a quantidade de livros que leio por ano, a conteúdos que escrevo, projetos que gerencio, etc.

No post de hoje vou ensinar alguns truques que uso e que você também pode usar. Obviamente a maioria deles eu não inventei, eu aprendi com outras pessoas produtivas! E nenhum é segredo na verdade, é apenas um truque sensacionalista pra atrair sua curiosidade. 😉

Os 5 segredos são:

  1. Mantenha registro
  2. Crie uma rotina
  3. Tome decisões que eliminem decisões
  4. Foque no que importa
  5. Delegue o resto

Segredo 1: Mantenha registro

Sabe a boa e velha agenda? Todo mundo que é produtivo possui uma. Desde o presidente dos EUA até os artistas famosos que fazem 20 shows por mês. Obviamente algumas agendas são mais importantes que outras, mas isso não vem ao caso.

Não quer usar uma agenda de papel? Use uma online. Eu uso o Google Calendar para todos os meus compromissos e tarefas que eu quero/preciso fazer, sincronizado no meu smartphone, para ter acesso em qualquer lugar. Reunião no serviço? Calendar. Viagem em família? Calendar. Presente do amigo secreto? Calendar. E por aí vai.

Até aqui nenhuma novidade, mas você sabia que existe um segredo aqui? Ter uma agenda não é apenas uma questão de organização dos seus compromissos (embora eu não coloque apenas “compromissos importantes” como reuniões, mas TUDO que eu preciso fazer), faz bem para o cérebro. Já foi comprovado cientificamente (não achei uma fonte melhor no momento, mas acredite) que “exteriorizar” (pôr pra fora) as suas tarefas lhe dá uma visão mais clara delas, permite que você priorize-as melhor, fique mais fácil de realizar trocas e claro, de se lembrar de tudo que precisa ser feito. Nosso cérebro ocupa muitos neurônios e gasta muita energia mantendo as informações dentro dele. Quando você coloca-as em uma lista, você alivia ele dessa carga desnecessária de informação e isso obviamente reflete na qualidade da execução das tarefas.

Conheço amigos que usam Trello, outros que usam Google Keep, Wunderlist, Ta-Da List e por aí vai. Não importa. Quer ser produtivo? Mantenha registro do que deseja produzir.

Segredo 2: Crie uma rotina

Todo mundo reclama da rotina, que a rotina é chata, que devemos sair da rotina, etc. Mas sabe o fator que mais contribui para minar sua produtividade? Tomar decisões (que falarei mais adiante). Sabe o que mais contribui para você avançar nos seus objetivos? Uma rotina bem construída, criar e seguir um plano.

As dietas mais bem sucedidas que eu conheço, como a Low Carb do Tim Ferriss, baseiam-se na rotina de refeições pré-estabelecidas para funcionar. Os treinos de musculação mais bem sucedidos que eu conheço, como o Stronglifts 5×5, baseiam-se na rotina de exercícios.

Absolutamente todos os meus ídolos possuem rotinas. E eu obviamente possuo uma também.

Pegue sua agenda e adicione os compromissos ordinários, aqueles que não tem como negociar, como dar aulas de segunda à quinta das 19h às 22h, um exemplo meu. Entre um compromisso ordinário e outro, tem uma janela de 1h? Aqui você pode colocar uma atividade como um exercício físico (musculação) ou mental (ler um livro). Mas não faça essa atividade apenas de vez em quando, coloque-a em sua agenda também, faça-a parte da sua rotina.

O princípio pelo qual ter uma rotina ajuda-o a ser produtivo é simples: consistência (Scrum fala muito disso). Você acaba se acostumando a realizar aquelas tarefas e depois de ter a agenda ajustada, você nem mesmo precisa se preocupar mais em ter tempo para elas, pois elas fazem parte do seu tempo. O conhecimento empírico é claro em mostrar que se você deixar para estudar quando sobrar tempo, ir na academia quando tiver tempo ou brincar com seu filho nas horas vagas, isso não vai acontecer. Se você leva uma vida moderna “cheia” como a maioria das pessoas com mais de 20 anos, você tem emprego, faculdade, família, etc, resumindo: nunca tem tempo sobrando. Ou você pega o que quer fazer e encaixa na sua agenda, ou jamais vai fazer.

Uma rotina consistente vai fazer com que você progrida rumo aos seus objetivos. Ou você toma a decisão de fazer o que realmente deseja, ou alguém vai decidir por você coisas que você não deseja fazer.

Muitas pessoas confundem “ter uma rotina” com “fazer a mesma coisa sempre”, mas não é bem assim e eu poderia escrever um post inteiro a respeito. Guardar as terças pela manhã das 10h às 11h para fazer reuniões com o time não é fazer sempre a mesma coisa, pois cada reunião é única. Assim como guardar 30 minutos antes de dormir todas as noites para ler um capítulo de um bom livro não é sempre a mesma coisa, pois lemos livros diferentes. E se isso soa estranho para relacionamentos, saiba que funciona extremamente bem e é a recomendação número um para casais em crise: colocar na agenda um horário para conversarem, saírem juntos, etc.

Segredo 3: Tome decisões que eliminem decisões

Temos uma gíria aqui no sul que diz “me caiu os butiá do bolso!”. Butiá é uma fruta que temos por aqui, uma bolinha pequena que enchemos os bolsos quando encontramos para comer depois e a ação de derrubá-los significa extrema surpresa. Me surpreendi essa semana com uma descoberta que eu já sentia, mas que não conhecia respaldo científico: temos um número limitado de decisões que podem ser tomadas por dia com qualidade.

Óbvio que este limite varia dependendo da capacidade cognitiva de cada pessoa, assim como a importância da decisão consome mais dessa “energia decisória” que nosso cérebro tem. No entanto, saber que não posso tomar infinitas decisões boas em um mesmo dia me assusta, pois nos cargos de liderança que assumo frequentemente (de gerente de projeto até subsíndico do condomínio) eu tenho que fazê-lo a todo momento.

Sabe porque pessoas em cargos importantes como Steve Jobs, Mark Zuckerberg e Barack Obama usam a mesma roupa todos os dias? Para não gastar uma “decisão do dia” em algo tolo como escolher uma roupa para vestir. Sendo assim, eles possuem (ou possuíam, no caso do Jobs) guarda-roupas com pouquíssima variedade. Zuckerberg só usa camiseta cinza, jeans e moletom. Obama só usa o mesmo modelo de terno com gravatas de tom azul. Jobs usava apenas jeans e blusa preta.

Parece loucura? Mas não é. Tem a ver com o poder de ser consistente, a produtividade que isso traz. A decisão de vestir sempre o mesmo tipo de roupa, quando tomada apenas uma vez, elimina todas as decisões diárias do tipo “o que vou vestir hoje?”.

Eu uso camisa polo e jeans. Quase todos os dias, exceto quando estou de folga. Mudam as cores e padrões, mas quem vê no trabalho sempre me vê de polo e jeans. Eu abro o roupeiro de manhã, pego uma polo de uma pilha e um jeans da outra, em segundos já estou vestido.

Claro, esse é apenas um exemplo, um tanto excêntrico, admito. Mas é válido, do ponto de vista da produtividade. Em ocasiões que preciso me vestir diferente, minha esposa escolhe a roupa (segredo 5, mais adiante). 😀

Outras decisões que eliminem decisões são almoçar no restaurante da empresa. Comer sempre o mesmo café da manhã. Ler livros ou ver séries indicados por pessoas de confiança (isso te poupa decidir o quê vai ler ou assistir, além de diminuir as chances de erro). Focar o rumo da sua empresa em um mercado que você conhece. Definir uma “persona” para o seu produto. Escolher pessoas de confiança para lhe dar conselhos. E por aí vai.

Eu sei, você deve estar me achando um chato. Mas ninguém disse que ser produtivo era igual a ser um cara legal! 😉

Segredo 4: Foque no que importa

Aqui entra uma questão muito delicada. Foco.

O que importa na sua vida? Qual o seu objetivo pra sua carreira? Pra sua vida pessoal? O que planeja estar fazendo daqui a 5 anos?

Essas perguntas são muito complicadas de responder. O mega investidor Warren Buffet diz que é somente “pensar em como você quer estar aos 70 anos e depois fazer a engenharia reversa”, mas sabemos que não é tão fácil assim. Eu mesmo planejei muito bem os meus últimos 10 anos e agora estou com dificuldade para planejar os próximos 10, que não são tão óbvios.

Mas vamos dizer que você sabe o que quer fazer da sua vida pelo menos nos próximos 12 meses. Quais tarefas, conhecimentos e pessoas que podem lhe ajudar a chegar nesse objetivo? Foque neles(as) e o resto deixe de lado. Ok, algumas coisas não dá pra “deixar de lado”, mas falarei deles depois.

Você quer se tornar um programador nos próximos 6 meses? Foque nos conhecimentos de programação (livros, cursos, disciplinas), foque no seu networking nessa área (colegas de curso, professores, empresas) e inclua na sua agenda tarefas como desenvolver sistemas de exemplo, pegue desafios reais que você acha que pode resolver, como trabalhos freelancer.

Ser produtivo não é simplesmente estar ocupado 100% do tempo. É estar ocupado fazendo o que importa para os seus objetivos. E isso são duas coisas bem diferentes. E não precisa ser 100% do tempo, mas na maior parte dele. Afinal, fazer coisas que você gosta também é parte dos seus objetivos, certo?

Vejo alguns alunos da graduação gastando tempo e dinheiro fazendo um curso que eles não gostam. Você não precisa gostar de todas suas disciplinas, mas ao menos do curso em “linhas gerais”. Eles estão ocupados, mas não estão indo rumo aos seus objetivos, estão desfocados. Se você quer ser um chef de cozinha, você tem de investir em utensílios, tem de praticar diariamente, etc. E não fazer um curso de computação! Jamais avançará rumo ao seu objetivo fazendo coisas não relacionadas, não focando no que importa.

Segredo 5: Delegue o resto

Mas o que você faz com as tarefas que não são o seu foco, mas que devem ser feitas? Tipo, a grama do pátio ainda precisa ser cortada. Os relatórios precisam ser produzidos. Aquela tela chata do sistema precisa ser desenvolvida.

A solução ideal é: delegar.

Já falei sobre delegação em outras oportunidades, sobre como terceirizar desenvolvimento de software ou criação de capas para livros. Basicamente você pega as coisas que precisam ser feitas, mas que você não tem tempo ou não quer fazer (porque não é o seu foco) para alguém capacitado. Usando conceitos como geoarbitragem e um pouco e Inglês, isso se torna fácil, rápido e barato de fazer quando o assunto envolve tecnologia.

Mas e seu eu não tenho dinheiro para pagar por profissionais terceirizados?

Ainda assim você pode delegar tarefas. Na verdade você deve delegar tarefas, se quiser ser um profissional de destaque, um bom chefe ou alguém que queira causar um grande impacto na sua área de atuação. Demorei anos para entender que somos muito limitados quanto aos resultados que conseguimos produzir em vida, mas somente se trabalharmos sozinho. O melhor programador do mundo não conseguirá escrever mais do que uma quantia limitada de linhas de código em um dia de 24 horas. Mas se ele souber delegar tarefas, consegue que muito mais pessoas, sob seu comando, produzam muito mais linhas de código.

Outro exemplo: quantos pratos um chef de cozinha consegue preparar sozinho em uma noite? Mas e se ele tiver a seu comando uma equipe de cozinheiros, e só tenha de delegar os pratos e talvez revisar a qualidade dos mesmos? As maiores empresas do mundo só chegaram no patamar em que estão devido aos diversos níveis de delegação de atividades que elas possuem, afinal, o Jorge Paulo Lehmann não tem tempo para cuidar pessoalmente da fabricação de suas cervejas, são muitas fábricas ao redor do mundo. Ele delega para pessoas de confiança, pois o seu foco é a estratégia da empresa em um nível mais alto, foca nos números, e não no sabor da cerveja, que fica a cargo dos mestres cervejeiros.

Mas e seu eu não tenho ninguém sob meu comando para delegar?

Então você terá de usar o seu networking, a sua rede de contatos. Quem na sua equipe pode fazer aquela tarefa chata por você? Lembre-se: o que é chato para você pode ser muito legal para outra pessoa.

Note que a dica de delegar tem tudo a ver com a dica sobre tomar decisões que eliminem decisões. No momento que você decide delegar uma tarefa, isso lhe livra de uma série de micro decisões que caberão ao novo encarregado por aquela tarefa. Também permite que você foque no que importa (segredo 5).

E você, qual dica você tem que lhe faz produzir ainda mais?