Lean, Tech and Startups

[leantechbusiness]

OKRs & Agilidade

Recentemente temos visto um grande número de empresas adotando o framework de OKRs, eu inclusive estou usando minha empresa atual. Também é sabido que atualmente cada vez mais empresas vêm adotando métodos ágeis. 

Como combinar OKRs com Agilidade?

De forma geral, a grande maioria dos métodos ágeis são focados na produção de software. Eles possuem um foco bastante foco de engenheira, focando em adaptabilidade, qualidade, velocidade e colaboração. 

Olhando os 12 valores expressos no Manifesto Ágil podemos ver isso de forma mais clara. Mas ao olhar com mais calma, fica claro que existe um gap no resultado gerado pelo software. Ou seja, existe uma preocupação clara em fazer bem feito o produto. 

Em alguns métodos, como o Scrum, temos ainda um passo a mais, onde supostamente um dos papeis do Product Owner (PO) é fazer o software certo. Ou seja, é papel do PO acompanhar as métricas do produto para entender se aquele produto está ou não atendendo ou melhor dizendo, realizando, a visão original do produto. Apesar do método não preescrever nenhum ferramental nesse sentido, existe um conjunto grande de ferramentas/técnicas que ajudam nessa tarefa (Teste AB, MVP, Customer Development, etc.) 

Em outras metodologias (como XP, FDD, ou mesmo o antigo e obsoleto RUP), esse papel era relegado a algum stakeholder do projeto (quase sempre envolvendo o cliente em algum nível).

Onde entre o OKR?

Na minha visão, o OKR é uma excelente ferramenta para preencher esse GAP. Mas para entender por quê, é importante fazer antes 1 disclaimer: se a sua empresa ainda é uma startup early-stage, sendo a empresa e o produto uma mesma entidade, essa distinção faz menos sentido do que em empresas maiores. 

Entrando no OKR.

Disclaimer feito, vamos ao que interessa. Se você tem alguns (times) trabalhando em projetos/produtos/serviços diferentes, o scrum (ou qualquer outro método ágil, mesmo o escalando com LeSS, SAFe, ou Nexus) serão ótimos para o desenvolvimento do produto, mas nesse caso a empresa é maior que o produto. 

Nesse caso, dado que o problema não é um problema de engenharia, mais sim de negócio, usar puramente métodos ágeis não vai gerar todo o levarage que você imagina, principalmente por que parte do projeto não está no produto, em um (ou dos níveis acima). Normalmente nessas empresas o problema envolve garantir que o conjunto dos produtos/projetos (ou seja, que o portfolio de produtos e serviços) esteja certo. 

E para fazer o alinhamento entre equipes (responsáveis por produtos e serviços diferentes), o framework de OKR se encaixa como uma luva. Com OKR você consegue alinhar áreas preocupadas com "coisas" extremamente diferentes em objetivos (de negócio) comuns. Caso você tenha objetivos compartilhados, você pode lançar mão de OKRs compartilhados para garantir que os mesmos objetivos sejam atingidos. 

Ou seja, pensando Top-Down, o OKR pode ajudar a garantir o alinhamento estratégico e a garantir que você esteja fazendo o produto certo, com todas as suas métricas e follow ups, quanto os métodos ágeis podem ajudar garantir que seus times estejam usando as melhores práticas de engenharia de software. 

[leantechbusiness]

Iniciativa vs Acabativa

Você ou o seu time tem problemas em começar muitas coisas sem conseguir terminar nada? 

Se isso acontece com você, saiba que esse problema é bem mais comum do se imagina.  Recentemente, me deparei com isso em uma das mentorias que eu faço. Mas o cenário geral é bem típico. Ao analisar esse caso mais de perto, seguimos o seguinte processo:

Identificamos todas as atividades que estavam sendo realizadas, tanto as operacionais quanto as atreladas a projetos,

Anotamos, para cada atividade, qual o tempo (aproximado) gasto em cada uma,

Mapeamos todos as atividades em um quadro Kanban simples, com as colunas, "Backlog", "A iniciar", "Doing", "Blocked", "Done"

Ao fazer isso, vimos que:

a. As atividades operacionais acabavam gastando mais de 60% do tempo disponível, e 

b. Muitas atividades estavam nas colunas de "Doing" e "Blocked".

O que isso significa?

De forma geral, conseguimos ter 2 diagnósticos simples:

a. você está usando mal o seu tempo. Não faz sentido, muitas vezes, um diretor ou o CEO da empresa gastar 50, 60% do tempo com questões operacionais, coletando dados para relatórios, coletando informações de projetos, etc. 

b. Se existem muitas coisas "blocked", muito provavelmente você está usando algum tipo de multi-tasking. 

Esses 2 sinais são bem importantes, e ambos acarretam você se ver começando muita coisa, sem conseguir terminar.  Por que?

Multi-tasking

Vou começar pelo mais simples. Existem diversas pesquisas indicando que quanto mais multi-tasking a gente faz, pior a nossa performance. Ou seja, para o bem de todos, o melhor que você pode fazer, é tentar começar uma única coisa (ou poucas), e ir com elas ATÉ O FINAL. E se você encontrar um obstáculo no meio? Ao invés de começar outras coisas, o ideal é empregar energia para resolver o obstáculo. Fazendo isso, você consegue terminar as coisas mais rápido. E além de terminar mais rápido, fazendo isso, você consegue ter mais qualidade nas coisas que você está entregando.

Parece contra-intuitivo. Mas não é. Existe um conjunto grande de livros e pesquisas nesse sentido. 3 livros são muito bons para entender o por que isso faz sentido. "The Goal", "Critical Chain" e o "The Project Manifesto". Você também pode ler mais nesses artigos:

How (and Why) to Stop Multitasking (HBR)Multitaskers pay a mental price (Stanford University)

Why Multitasking Doesn't Work (Forbes)

Multitasking Damages Your Brain and Career (Forbes)

Don't Multitask, your brain will thank you (Time)

Why multitask is bad for you (lifehack)

Tarefas Operacionais

Esse é outra questão bastante comum. Muitas vezes, acabamos dando muito mais ênfase ao trabalho que sabemos fazer (e que eventualmente fazemos melhor e/ou mais rapidamente do que nossos subordinados diretos), ao invés de fazer o trabalho que deveríamos estar fazendo.  Para facilitar o entendimento desse problema, vou dar um exemplo bem simples.

Você é head do PMO da empresa, e parte do seu trabalho é entrar todo dia em um determinado sistema e gerar um conjunto de relatórios de andamento de projetos para analisar a saúde dos mesmos. Nesse sentido, você gasta normalmente 3 hs por dia coletando os dados, consolidando as informações e preparando o relatório no excel, para em seguida poder fazer a análise. A análise em sí, leva 40 minutos.

Ou seja, você está gastando um tempo enorme para uma tarefa que poderia estar sendo feita por outra pessoa. E pior que isso, na prática você está deixando de fazer outras coisas que provavelmente você DEVERIA estar fazendo nesse tempo, mas não está por que está envolto em tarefas operacionais. 

Uma questão de perfil

Outro diagnóstico bastante comum é o associado ao perfil da pessoa. É sabido que as pessoas são diferentes, respondendo a estímulos e recompensas distintas. Ou seja, existem pessoas que sentem muito mais prazer (e tem um instinto natural) em abrir muitas frentes de trabalho, perdendo o entusiasmo conforme as atividades vão ficando mais operacionais. 

Existem outras que tem o instinto natural em dar sequência ao trabalho até finaliza-lo, mas que normalmente esperam que as coisas sejam iniciadas por terceiros. 

Entender qual o perfil de pessoas a gente tem em cada posição, pode ajudar bastante a área como um todo ser mais produtiva. 

Onde entra a "acabativa"?

Nesse sentido, a "acabativa" entra em tentar minimizar todas as atividades que você não deveria estar fazendo, para conseguir terminar as coisas que você deveria estar terminando. 

Usei o neologismo (e o trocadilho) mais para focar na questão que terminar as coisas é tão importante como inicia-las. Mas, muitas vezes, isso acaba sendo pouco valorizado.

[yahoohadoop]

Apache Storm Roadmap at Yahoo

By Bobby Evans and the Apache Storm team at Yahoo

Yahoo uses Apache Storm for large scale distributed stream processing. Think of stream processing like Apache Hadoop but instead of batching the data first, it processes the data as it arrives.  Stream processing gives Yahoo the ability to take action on data in near real-time, and we use it for just about everything that is latency sensitive.

Storm is commonly used when lower latency is required to deliver a better user experience. These use-cases include identifying a breaking news story and promoting it, showing trending search terms as they happen, helping to identify and block SPAM, or letting advertisers see the impact of their campaigns as quickly as possible.

In my opinion, the most interesting use cases are feedback loops. One of my favorites is ad budgeting. We have multiple data centers with ad servers all around the globe.  Advertisers give us a budget for how much they want to spend on a particular campaign. If we show too few ads we are leaving money on the table and if we show too many ads, we cannot charge for the excess ad impressions that we could have sold to someone else. Storm gives us the ability to globally adjust to changes as they happen, and accurately control the number of ads shown in a campaign. So, for example, when Yahoo live streams an NFL game and England unexpectedly goes crazy over it, we can shift ad budget from US data centers across the pond and maximize our revenue in real-time.

Our Storm deployments have grown dramatically over the last few years, with the number of nodes we have doubling in the last six months alone.

Fig 1. Storm cluster growth

Fig 2. Storm topology growth

Much of this growth is made possible by our previous development effort to add security and multi-tenancy to Storm. We are very excited to announce that this is now in open source under storm-0.10.1-beta. This is a critical milestone for many enterprise use cases with security concerns in adopting Storm.

It is not just Yahoo that sees the power of stream processing. There seem to be new announcements about stream processing showing up all the time: Twitter publishing their results on Heron, and DataTorrent announcing that they will release their core as open source under the name Apex. It is great to see so much competition happening in the market. I am a firm believer in competition driving positive change.

Recently, I gave a talk at Hadoop Summit 2015 on our efforts at Yahoo to scale Apache Storm to 4000+ nodes (96,000 cores) in a single cluster. The question I was asked the most after the talk was “When will this be in open source?” I was also frequently asked “How can we help out?” As a result, we are shifting our development efforts to better align with open source and to reduce the amount of time it takes for this work to be made available to end users.

To help with the debuggability and management of Storm, we will be pushing back STORM-902 to allow for easy searching of the logs out of the box; STORM-901 so that developers can get access to heap dumps, gc logs, or anything else a topology may want to export for debugging; and STORM-412 to let devs change the logging config for a topology on the fly. Additionally, in 0.10.0 we switched the logging framework to log4j2 with support for RFC5424 to help external tools consume the logs produced.

We are adding in resource aware scheduling through STORM-893 to let users get better utilization of their clusters and better predictability in the execution of their topologies. We are going beyond what YARN and Mesos currently can do by adding in network as a resource, which can solve huge problems on shared clusters or very large topologies. We have some groups that want to consume 6 GBytes/sec that, if scheduled poorly, can saturate a 40 gigabit TOR downlink. I recently talked with some people working on the Large Hadron Collider. They were exploring if Storm could be used to process the 4 TBytes/sec that they deal with. I would love to see Storm working at that scale, and I firmly believe that we will get there.

We are pushing back STORM-411 to let users distribute more than just a single jar to their topology with a distributed cache like API, while additionally giving them the ability to update items in the cache without bringing down a topology. This also sets the groundwork for STORM-167 to let users do a rolling upgrade of a topology.

To make life simpler for users to meet SLAs, we are exploring intelligent backpressure through STORM-886 and STORM-907, and automatic topology scaling through STORM-815 and STORM-594.

We are exploring failure monitoring to detect and blacklist bad nodes thought STORM-909, and plan to help with STORM-166 to ensure Nimbus is not a single point of failure.

We are also committed to making sure Storm is competitive with other streaming technologies in performance and stability through things like STORM-889.

And longer term we plan to drive STORM-911 giving Storm the ability to run topologies on bare hardware, YARN, Mesos, or just about any other system.  

We intend to up-merge to the master branch on a weekly basis. This combines with our continuous integration and continuous deployment environment so that after a feature goes into open source, we will have it deployed to a staging/development environment at scale within two weeks, and to a production environment after another few weeks. This should give end users a lot of confidence in using Storm for business critical use cases.

Yahoo loves Storm. Adoption is growing and Storm is solving real world use cases all the time.  We want to share the phenomenal success we have been seeing with the rest of the open source community.  Expect to hear more from us as our development efforts continue.

[leantechbusiness]

Como transformar um mau PO em um bom PO.

Disclaimer: Esse post faz mais sentido em um ambiente onde se usa Scrum ou onde existe claramente esse papel.

Recentemente participei de um treinamento de Scrum, para a certificação de Scrum Master. Por mais que eu já tivesse estudado agilidade de forma geral, e Scrum em particular, o treinamento foi bastante proveitoso. Um dos pontos altos do treinamento foi entender o quão fundamental é ter um bom PO em um time. 

Apesar de não existir hierarquia (falando especificamente de um time scrum) o papel que pode mais minar a agilidade dentro do time (sem outros contra-pontos) é o do PO. Como já comentei em outro artigo, de nada adianta você ter um método ágil se você não tem o mindset ágil. 

Nesse caso em particular, o PO pode "estragar" o time (como um todo) de diversas formas:

Não conseguindo dar uma boa visão de produto,

Não ouvindo o time na hora de quebrar as histórias de forma a conseguir, mesmo em sprints pequenos, ver valor na entrega

Não se colocando como integrante do time,

Fomentando a segregação de papeis (não vou fazer por que isso não é meu papel).

Não conseguindo priorizar o trabalho,

Não conseguindo entender o caso de uso das histórias,

Cobrando o time entregar as historias de qualquer forma, sem se preocupar com a qualidade do que está sendo entregue / ou não ouvindo o time quando da necessidade de se gastar mais energia para fazer melhorias estruturais necessárias.

Enfim, são diversas formas como eu comentei antes. Então como fazer no caso de você ter um PO ruim? 

Como fazer um PO ruim se transformar em um bom PO?

Vejo algumas alternativas, umas mais traumáticas do que outras, e acho que a melhor estratégia depende muito do que faz o PO ser ruim. Então vamos analisar alguns casos.

Caso 1. O PO não entende o negócio e não consegue entender - de verdade- os casos de uso do produto

(Uma variante desse caso é quando o PO não consegue priorizar o backlog, mudando o mesmo constantemente). 

Nesse caso, normalmente uma boa seção de coaching e de treinamento (no negócio), além de um processo de imersão junto aos clientes normalmente tende a resolver. Eventualmente o próprio time pode sugerir ao PO ele passar mais tempo com os clientes e/ou participar de congressos e seminários sobre a indústria na qual o produto se insere. Mas de forma geral acho que é um caso solucionável, se o PO realmente tiver interesse. 

Caso 2. O PO acha que é chefe do time, tenta a todo custo definir as soluções técnicas, muitas vezes micro-gerenciando no detalhe das atividades.

Nesse caso existem algumas abordagens para entender da onde vem a necessidade de comando-e-controle do PO. Elas podem vir:

de insegurança do PO, 

baseadas em falta de confiança do PO no time, ou as vezes é simplesmente o fato do PO querer ajudar, se metendo além do que o devido. 

Opção a. Insegurança do PO: Se o scrum master for bom, ele pode ajudar o PO a resolver essa questão. Isso pode ser de cunho profissional apenas, ou pessoal (ou dos 2). Mas como um bom facilitador, muitas vezes o scrum master (e o próprio time) conseguem ajudar.

Opção b. Falta confiança: Nesse caso o problema é um pouco menos trivial. De novo acho que o SM pode ajudar bastante, porém em muitos dos casos a falta de confiança é mútua (Time-PO), e muitas vezes é necessária a intervenção de alguém de fora para ajudar o time a resolver o "ranço" que desencadeou a falta de confiança. 

Não vou entrar em maiores detalhes, mas a falta de confiança pode vir de vários fatores diferentes, e essa análise de "causa-raiz" precisa ser feita com alguém imparcial.

Eventualmente, a alternativa pode ser mudar o conjunto Time-PO (trocando o PO de time).

Opção c. O PO só quer ajudar. E ao querer ajudar, ele tenta absorver mais coisas do que ele deveria, ou tenta participar e influenciar decisões do time onde muitas vezes ele não deveria tentar se meter. Isso normalmente acontece quando o PO se acha um "all-star" dentro do time (ou simplesmente quando ele se acha melhor que o time). A boa notícia é que nesses casos, o time pode trabalhar diretamente com a ajuda do SM para resolver essas questões. Assim, mesmo que no curto prazo o time tenha muitos atritos, no médio/longo prazo esse problema tende a ser resolvido. 

Caso 3. O PO não gosta de agilidade: Bom, esse caso é mais complicado. Minha abordagem seria tentar sensibilizar o PO, mas sabendo que muitas vezes isso é inviável, não vejo muito alternativa a não ser trocar o PO.

Caso 4. O PO não tem cabeça de produto. (As vezes ele se acha responsável apenas por dizer o que outras áreas ou clientes querem, sem nenhum tipo de filtro). 

Esse é outro caso complicado, por que como o nome diz, o papel é de "Dono" do produto. Se o ele era para ser dono, mas ele não entende de gestão e desenvolvimento de produto, a vida realmente fica difícil. E por incrível que parece, esse é um problema bem comum no Brasil quando estamos falando de produtos de tecnologia. Por que? Simples! Temos muita tradição desenvolvendo sistemas e entregando serviços de tecnologia, mas a criação de produtos é relativamente nova no Brasil. A boa notícia é que dá para se treinar pessoas em gestão e desenvolvimento de produtos. Existem alguns bons livros sobre gestão de produtos, e outros que tem um foco grande em startups (tipo o Lean Startup, Lean Metrics, Business Canvas Model, etc), mas que podem ser facilmente usados para criar a cultura de desenvolvimento de produto.  

A situação realmente complica quando você tem um misto de todos esses problemas em uma mesma pessoa. Nesse caso, eu particularmente não vejo outra saída a não ser trocar o PO. 

Conclusão

Existem muitas formas de ajudar um PO a ser um bom PO, tanto do lado técnico de desenvolvimento de produto, quanto do lado de negócios (em termos de entendimento e visão da indústria/negócio). 

Porém existem poucas formas de ajudar um PO quando ele não quer ser ajudado (seja por que ele não quer mesmo, seja por que ele prefere trabalhar no modelo não-ágil - acredite, conheço gente assim).

[leantechbusiness]

O conceito de entregar valor para o usuário

Essa é outra pegadinha no mundo ágil. Principalmente para aqueles que vêem a filosofia ágil com maus olhos (ainda tem muita gente que não gosta). 

O que significa entregar valor?

Muitos acreditam que entregar valor é o mesmo que entregar uma funcionalidade completa "em produção" (ou pronta para o usuário final usar). Conceitualmente estamos bem, mas o problema com essa "definição" é que se a sua funcionalidade leva 3 semanas, essas pessoas "defendem" que não dá para quebrar em entregas menores uma vez que você não vai entregar nada antes para o usuário...Logo ele não vai obter valor da funcionalidade.

E é ai que mora a pegadinha.. Na minha opinião, devemos entender valor de forma mais "fluída"... Se a gente vai levar 3 semanas para entregar a funcionalidade completa, significa que já nos primeiros dias (primeira semana talvez) já conseguimos mostrar algum progresso que sirva para termos algum feedback ou que sirva para mostrar a evolução da funcionalidade. 

A questão de estar pronto para subir ou não para produção é fora de contexto nesse sentido, muitas vezes sendo muito mais uma decisão de marketing/produto do que técnica (da funcionalidade estar ou não pronta). 

Vou dar um exemplo que eu considero típico. Numa das startups que eu trabalhei, criamos um market-place de compra-venda de conteúdo. Esse market-place tinha uma "divisão" bem simples: tinha o lado comprador, o lado vendedor e o market-place propriamente dito (com as engines de pagamento, etc).

O projeto inteiro foi "estimado" em 4 semanas. Em cada semana focamos em uma ponta. Ou seja, no final da primeira semana tinhamos uma versão inicial do lado "comprador", na 2a uma versão inicial do lado "vendedor". Claramente não fazia sentido colocar a primeira parte no ar (dado que o resto ainda não estava pronto). Mas ainda assim, conseguimos pegar um conjunto grande de feedbacks conforme o projeto foi andando, mesmo antes de ser lançado. 

Então é "mentiroso" dizer que por que você ainda não pode lançar, você ainda não está entregando valor!

Da onde esse conceito vem?

Se você lembrar do modelo waterfall, fica muito claro por que existe essa "ênfase" em ter alguma coisa funcional, e chamar isso de "valor". No passado, ao longo da primeira semana (usando o meu exemplo acima), teríamos no máximo um diagrama "completo" de caso de uso, mas nenhum pedaço de software construído de fato... E é exatamente isso que a definição busca: foco em construir software de fato, mesmo que seja um subset bem inicial da funcionalidade como um todo. 

Ou seja, na prática, é sempre possível entregar valor.

[leantechbusiness]

Detecção e Correção de Problemas ao longo do processo de desenvolvimento de Software

Recentemente voltei a ler o livro “High Output Management” e logo no início do livro ele comenta um ponto que apesar de óbvio, é muitas vezes negligenciado no mundo de software, particularmente no Brasil:

“A common rule we should always try to heed is too detect and fix any problem in a production process at the lowest-value stage possible”

Por quê eu digo que é negligenciado? Muitas das vezes, ao se deparar com problemas de qualidade em um software, a primeira coisa que vem a cabeça é fazer testes ANTES DE ENTREGAR O SOFTWARE PARA O CLIENTE. Ou seja, se faz o teste no ponto onde é mais caro corrigi-lo. 

O que precisa ser feito, é termos um processo de identificação de causa-raiz, e para as causas detectadas, instaurar um conjunto de planos de ações e medições de qualidade ao longo de todo o processo de desenvolvimento. 

Outra abordagem complementar é a utilizada por métodos ágeis, onde você faz todo o ciclo em 2-3 semanas, e com isso você consegue pegar os problemas de forma bem mais rápida e antes que eles se tornem muito caros. O seu ciclo de feedback curto faz com que os problemas mais estruturais surjam de forma mais rápida.

Além disso, existe um conjunto bastante grande de práticas e ferramentas de engenharia de software que podem auxiliar nesse processo. Mas o importante é ter em mente que testar só no final (apesar de funcionar no curto prazo) não funciona no longo prazo. 

Esse não é o trabalho da Integração Contínua?

Sim e não. Sem dúvida a integração continua ajuda bastante a detectar os problemas rápido (assim que eles forem "introduzidos"). Porém, para a integração continua funcionar, você precisa ter um conjunto relevante de testes (em todos os níveis: unitários, de integração, de interface, etc), de forma que os bugs introduzidos sejam detectáveis. E é ai que eu vejo problema na realidade brasileira.

De forma geral, a grande maioria das startups de tecnologia no Brasil tendem a relegar a prática de testes, como sendo um trabalho melhor. Pouquíssimas empresas levam a disciplina de testes a serio. Poucas empresas pensam em arquitetar o software de forma que seja mais fácil testar. Normalmente o teste vem no final (no processo e no mindset do developer). 

Assim, o que eu vejo acontecendo é que apesar de você colocar todo o processo de integração continua no ar (seja com Jenkins, com TFS ou com qualquer outra ferramenta), as coisas que você testa no processo de integração se constituem no maior gargalo para a detecção precoce dos bugs.

Outro ponto importante é que a integração contínua só endereça uma classe de problemas. Se você tem um problema sério de UX, enquanto seu código estiver correto, sua integração continua estará indicando um software OK. O mesmo para problemas ocasionados na concepção da história ou dos use cases (ou das especificações, caso você use um modelo tradicional). Ou seja, a integração contínua não é a solução de todos os problemas. 

Como resolver esse problema?

Infelizmente não existe receita de bolo para isso. O que existe são as famosas melhores práticas.

Para identificar problemas de UX você pode usar ferramentas como teste A/B, testes de usabilidade, análise de mapa de calor de click, etc. O mesmo acontece com problemas de especificação. Para testar se você está resolvendo de verdade o problema que você quer resolver você pode usar protótipos funcionais, desenvolvimento iterativo, MVPs, entre outras.Para entender onde sua arquitetura está falhando você pode fazer alguns testes/entrevistas com os usuários para validar os limites dos casos de uso, por exemplo. 

O importante é entendermos que a forma de resolver o problema é estrutural, e não pontual. Você precisar estar constantemente monitorando e avaliando o seu processo de desenvolvimento buscando formas de detectar o problema o mais cedo possível. É uma jornada e não um destino.

[leantechbusiness]

Por que você deve classificar e priorizar os bugs do seu produto?

Esse é um daqueles assuntos que muitas vezes pode parecer óbvio, mas na prática pode ser mais complicado do que parece. De forma geral, o que está em discussão aqui é conseguirmos responder 3 perguntas:

Quando você precisa ter algum sistema de classificação de bugs?

Por que isso é importante?

Como você deve estruturar isso?

Quando priorizar?

Se você tem pouquíssimos bugs, muito poucos mesmo E se esses bugs são extremamente simples de corrigir, você não deveria se preocupar muito com isso.  

Porém, isso dificilmente acontece. Qualquer sistema/programa/site um pouco mais complexo já pode gerar bugs suficiente para deixar o time atarefado por algum tempo. 

Ou seja, com raras exceções, você deve sempre priorizar e classificar os bugs.

Por que é importante classificar e priorizar? 

A classificação e a priorização são importantes por várias razões, entre elas para ajudar o time a focar nos bugs mais sérios primeiro e para ajudar a organizar o processo de correção. 

Sem uma classificação/priorização adequada você passa a ficar dependente do bom senso de quem vai corrigir, na hora da correção. E assim você corre sérios riscos de corrigir os bugs na ordem "errada".

Por exemplo, entre começar a corrigir um problema que impacta o billing e começar a corrigir um problema que é um typo na página, muito provavelmente você vai querer começar a corrigir o do billing. Mas se você não tem uma forma de priorizar isso, eu te garanto que muitas vezes você vai começar pelo typo (por exemplo por ser mais rápido).

Existe uma outra razão para você usar um sistema de classificação. Ele te ajuda a equilibrar o balanço entre corrigir um bug e implementar uma funcionalidade nova. 

Por exemplo, você pode instituir algumas "regras" tipo: só corrigirmos bugs de impacto/prioridade médio/baixo quando terminarmos essa nova funcionalidade, ou ainda, sempre que tivermos um bug de prioridade muito alto paramos tudo para resolver o problema. 

Como funciona um sistema de classificação e priorização?

Via de regra, você sempre classifica os bugs quanto ao seu impacto, prioridade e/ou severidade (ou uma combinação qualquer desses 3).

Algumas empresas usam um simples ranking de 1 a 5, outras um de ranking de 1 a 3. O importante é que o critério que define o que é bug de prioridade 1 e o que é um bug de prioridade 3 ou 4 esteja claro para todo mundo. 

A regra deve ser simples, e tangível para todos. Algo na linha da lista abaixo.

Impacto 1 - Todo o sistema está fora, ou com sérias degradações de performance.

Impacto 2 - Os componentes principais estão degradados, e não temos nenhum workaround (solução de contorno) OU temos funcionalidades-chave degradas.

Impacto 3 - Componentes principais degradados, mas com workaround OU Componentes Secundários Degradados  e não temos nenhum workaound) 

Impacto 4 - Componentes Secundários Degradados mas temos workaround

Impacto 5. Demais problemas. (typo, pixels desalinhados, etc)

Com uma lista dessa podemos classificar os bugs de forma mais simples e mais objetiva. Por exemplo:

Se o portal saiu do ar, claramente é um bug de impacto 1.

Se você tem um portal de conteúdo, mas o bug impede que seu usuário veja conteúdo, isso também deve ser um bug de impacto 1.

Mas se o problema é que o usuário não consegue compartilhar o conteúdo nas redes sociais, isso já não é de impacto 1, provavelmente ele foi "rebaixado" para impacto 2 ou 3 (dependendo de quanto o compartilhamento é importante para o negócio).

Se você tem um e-commerce, e seu usuário não consegue comprar ou pagar, isso é claramente um bug de impacto 1.

Mas se por outro lado, ainda no billing, ele não consegue parcelar o pagamento, isso é um bug de impacto 2 ou 3.

E quando uma dimensão não é suficiente?

Dependendo do caso você precisa ter uma 2a dimensão para ajudar na classificação. Imagina que você tem um produto que pode ser usado na nuvem (no modelo SaaS) ou on-premisses (quando é instalado na infra-estrutura do cliente). Nesse caso, talvez faça sentido você entender como o impacto (conforme o exemplo acima) é sentido pelos clientes. Para isso você pode usar uma segunda dimensão como ilustrado abaixo:

Prioridade 1 - Afeta todos os clientes

Prioridade 2 - Afeta os principais clientes

Prioridade 3 - Afeta muitos clientes

Prioridade 4 - Afeta poucos clientes

Prioridade 5 - Afeta apenas 1 cliente

Dependendo do sua situação você pode ainda ter outras dimensões. Você pode classificar os bugs ainda por aspectos como:

Se os bugs são Funcionais vs UX vs Tradução.

Se os bugs são Funcionais vs de Performance vs de "Arquitetura" vs de "Especificação".

Quando a complexidade técnica.

Quando a frequência do caso de uso envolvendo o bug.

Bugs vs Times (essa é muito usada quando seu time começa a crescer e se especializar).

Juntando todas as partes

Dado que você pode trabalhar todos esses aspectos, como juntamos isso tudo? Minha dica aqui é : "Keep it Simple". Ou seja, por mais que seja tentador colocar tudo em uma forma que faz mil e 1 cálculos e te informa A lista priorizada, eu normalmente sugiro uma abordagem mais simples.

No caso da classificação por time, eu normalmente a uso simplesmente para direcionar os bugs para os times mais adequados. As únicas "dimensões" que eu acho que pode fazer sentido calcular são o impacto e a prioridade. E nesse caso podemos ter uma multiplicação simples.  Algo na linha abaixo:

Ou seja, você deveria se preocupar com os pontos "vermelhos", e de forma geral se preocupar pouco com os pontos "verdes".. O que normalmente eu adoto é a regra de não ter bugs "vermelhos". Ou seja, sempre que temos um bug "critico", paramos o time para resolver. Se o bug é moderado, ele pode ser resolvido em outra oportunidade.

Resolvendo bugs não críticos/urgentes

Se você resolver adotar a minha sugestão de não parar tudo quando um bug de prioridade/impactos moderados for identificado, fica a questão de quando esse bug será efetivamente resolvido. Para isso podemos adotar algumas estratégias: 

Dedicar uma pessoa do time só para corrigir bugs;

Dedicar um dia na semana para todo o time resolver bugs (bug fix day ou housekeeping);

Dedicar um sprint ou um time-box para a correção dos bugs;

Sempre antes de começar uma funcionalidade nova, você corrigi um bug de baixa prioridade;

Ou uma combinação das alternativas acima.

Das 3 primeiras, eu particularmente já utilizei quase todas, e de forma geral elas funcionam bem para dar conta dos bugs legados. Não recomendo porém que essa abordagem seja utilizada para dar conta dos bugs "novos", pois a forma mais eficiente de corrigir um bug "novo" é na hora que você percebe ele (é também o ponto mais "barato" uma vez que você não precisa mudar de contexto).

Concluindo...

Como eu disse antes, pode-se escolher desde o mais simples até o mais complexo. A questão é entender qual o sistema mais se adequa a sua necessidade e ter em mente que quanto mais simples melhor.

[leantechbusiness]

9 Perguntas a serem feitas antes de você aceitar a oferta de uma startup

Já escrevi um pouco sobre esse assunto, mas essa semana vi um artigo nessa mesma linha no Tech Crunch (aqui você acessa o artigo original em inglês). Claramente no mercado americano é diferente do nosso, mas achei o artigo apropriado a nossa realidade (com algumas adaptações). 

Ao que interessa. Quais as 9 perguntas:

1. O CEO da startup já montou algum outro negócio antes?

De cara já precisamos adaptar a pergunta, dado que o movimento empreendedor aqui ainda é bastante jovem. Mas se você pensar no track record do CEO, isso pode sim te ajudar. 

2. A empresa tem um "funding" sólido.

Ter um funding sólido é fundamental para o sucesso da startup. Nesse sentido é sempre bom entender o momento da empresa. Se você está entrando na empresa com a expectativa de ser um funcionário em um startup que acabou de ser criado, a chance de você se frustrar é bastante grande. Se a empresa é muito jovem, você pode se juntar de outras formas (como por exemplo trabalhando como freela).

3. Você acredita na visão da empresa

O CEO consegue ter uma visão clara e consegue agregar as pessoas em volta dessa visão. O fato de você acreditar na visão da empresa, principalmente no estágio inicial da empresa, faz toda a diferença, uma vez que nesse estágio você acredita muito mais na capacidade do CEO de implementar a visão do que qualquer outra coisa.

4. Você acredita no "last valuation"?

Esse ponto é difícil ainda no Brasil, dado que muitas vezes essas informações ou não existem ou não estão disponíveis... Mas de qualquer forma é válido pensar se com o dinheiro que a empresa levantou você conseguiria fazer algo melhor do que está sendo feito. De forma geral, esse ponto ainda é muito relegado no Brasil, por um conjunto de fatores. De qualquer forma, essa análise pode te dar uma perspectiva nova em relação a empresa e ao mercado.

5. O que você pode aprender?

Acho esse ponto um dos mais relevantes. Mesmo que tudo dê errado, se você está em uma startup que no final vai de deixar um profissional muito melhor do que antes, o trabalho parece promissor. E se der tudo certo você ainda pode ganhar muito dinheiro! 

6. Como é a relação dos sócios fundadores?

Eles se dão bem? Eles mal se falam? Isso pode ser um ponto de inflexão importante na vida de uma startup dado a grau de incerteza que a startup vivencia dia-sim-dia-também.

7. Como é a indústria onde a startup se insere?

Se o mercado como um todo está crescendo, as chances são grandes que mesmo com problemas na gestão, a startup tenha algum sucesso.

8. Qual a estratégia de saída?

Nos Estados Unidos muito se fala em IPO de startups. Aqui no Brasil isso ainda é bem raro. Mas de qualquer forma, é importante entender como os sócios encaram o longo prazo. Eles estão no negócio simplesmente pelo dinheiro de uma potencial saída (seja via fusão/aquisição, seja via venda), ou para realmente construir alguma coisa no longo prazo?

Pode não parecer, mas existem pesquisas que indicam que se os sócios tem um propósito maior que o dinheiro, as chances da empresa dar certo aumentam bastante.

9. Existe um caminho para o Lucro?

Esse é outro ponto muito comum nos Estados Unidos, mas pouco aqui no Brasil. Lá fora é extramente comum você criar empresas sem modelo de receita. Pinterest, Quora, Twitter, Facebook, Google, Whatsapp são alguns exemplos de empresas que nos seus primeiros anos de vida não faziam a menor idéia de como gerar lucro (algumas ainda hoje estão nessa situação). Por que isso é importante? Se a empresa não tem um modelo de negócio sustentado, ela vai continuar precisando de novas rodadas de funding. E nem sempre isso é garantido. 

Resumindo, existem algumas coisas que podemos avaliar quando/se faz sentido ou não aceitar a oferta de trabalhar em um startup. Nenhum dessas perguntas devem ser encaradas como eliminatórias, mas elas podem te ajudar na decisão.

[leantechbusiness]

Priorizando com M.O.S.Co.W

Ontem passei por um artigo bastante interessante, que dizia respeito sobre o processo de priorização de Backlog baseado no critério conhecido por “MOSCoW”, sendo “M.O.S.Co.W” é o acrônimo para:

M - Must Have

O - Ought Have

S - Should Have

Co - Could Have

W - Won’t Have.

De forma geral, é de fato, uma ferramenta bastante poderosa principalmente por forçar a separação nesses níveis, e com isso, clarificar bastante o que é o core do produto/funcionalidade e o que é desejado.

O mais curioso é que eu já usava isso, em 2011, em um mercado completamente diferente; o de Recrutamento e Seleção. Na época nós usávamos esse processo para conseguir elicitar o perfil desejado dos candidatos. De forma geral, usávamos o mesmo modelo, com uma “modificação”: limitávamos o número de itens no Must entre 3 e 5. 

Por que? Porque ao limitar o número você consegue extrair o que é fundamental, e quando falamos de perfil de pessoas, esse fundamental é o que faz a diferença.

[leantechbusiness]

Métricas de Qualidade e de Produto

Esse é um assunto interessante. Recentemente terminei uma especialização em Data Science e acabei mergulhando bem fundo em questões de métricas, dados e estatísticas.

E a verdade é que não existe métrica perfeita para tudo. Não existe, de forma geral, A métrica. As métricas devem evoluir junto com a sua capacidade de analise do cenário.

Alguns exemplos:

1. Se você tem um problema sério de bugs no seu software, faz todo sentido você acompanhar a métrica de bugs (ou as métricas) criados, fechados, cancelados. Mas a partir do momento que você passa a entender melhor o seu contexto, normalmente você tem a necessidade de quebrar essas métricas, por exemplo em termos de prioridade, módulos, equipe, etc. 2. Você está acompanhando uma métrica e para entender o impacto da métrica você acaba precisando acompanhar outra métrica. Por exemplo, você está acompanhando a métrica de entrega de pontos por sprint, mas isso por si só não diz se o seu time está sendo mais ou menos produtivo. Muitas vezes você precisa acompanhar as métricas que vão indicar se esses pontos estão sendo entregues as custas de mais ou menos dívidas técnicas.

Ou seja, normalmente as métricas te dão uma perspectiva do problema ou da situação. É claro que existem algumas métricas obvias (quando estamos falando de desenvolvimento de software), mas ainda assim, para você ter uma visão completa da saúde técnica do seu código e do seu time, normalmente você precisa olhar um CONJUNTO de métricas. 

O mesmo acontece para as métricas de produto.

Vale a pena ressaltar que definir bem as métricas é muitas vezes uma arte. Na grande maioria das vezes o problema é escolher quais das métricas são realmente as métricas chave, e que melhor representam a saúde do negócio. Para isso, você precisa antes de qualquer coisa, entender bastante o mercado/industria que você atua e principalmente entender como o seu negócio gera valor para o seu usuário. Parece simples, mas na prática existem diversas nuances e pegadinhas que fazem o trabalho ser mais espinhoso.

Minha dica é começar. Mesmo que suas métricas iniciais sejam ruins, se você realmente prestar atenção nelas, você rapidamente vai começar a identificar onde e quais métricas precisam mudar, e a partir de então você consegue ajustar as métricas de forma as mesmas fazerem mais sentido para o negócio. 

[leantechbusiness]

Desenvolvimento de Produto vs Projeto - Parte II

Já falei um pouco sobre as diferenças entre desenvolvimento de produto e de projetos, particularmente no que tange o Scrum. 

De forma geral, considero que são 2 mundos bem diferentes. 

Se você atua em uma empresa de serviços, (mesmo que fazendo um produto que suporta o serviço), o foco da empresa não é produto em sí. Na prática, o produto acaba sendo acessório, suportando a entrega dos serviços da empresa. Ou seja, nesse cenário faz sentido você avaliar se determinada oferta é melhor coberta no produto ou se faz mais sentido ter uma oferta de serviço, eventualmente mais barata.

Por exemplo: se você faz uma consultoria de BI, e você tem um produto que te ajuda, na hora de entregar um relatório A, faz todo sentido analisar se é melhor você ter um consultor preparando (eventualmente até "programando por fora do produto") o relatório, ou se é melhor incorporar esse novo relatório no produto. Ai, nesse caso, vai depender de uma análise envolvendo um conjunto de outros fatores como se esse relatório pode ser usado em outros projetos, qual o custo de colocar o relatório dentro do produto vs o custo de fazer só para o projeto, etc, etc.

Inclusive essa é uma das formas que muitos produtos nascem no Brasil. Você tem uma empresa de serviço que para ser mais produtiva começa a "automatizar" parte do serviço via componentes de software, e aos poucos esses componentes viram uma biblioteca, depois um framework, e depois eventualmente um produto.

Porém quando você vira uma empresas de produto, a sua cabeça deve mudar. Essa análise, por exemplo, se faz sentido ter um consultor fazendo o "last-mile" ou se deve ser incorporada no produto, não faz o menor sentido em uma empresa de produto, uma vez que como produto, o mesmo deve sempre ser autônomo.

Acho que do ponto de vista de negócios, o mindset produto vs serviço é diferente. Como comentei no outro post, as métricas são diferentes. As estratégias para desenvolvimento do produto (em empresas de produto e em empresas de serviço) são diferentes. A forma de vender é diferente. 

Uma empresas de serviço, desenvolve o produto como uma forma de facilitar a venda do serviço (seja fazer o serviço mais rápido, com menos erros, etc). Mas na grande maioria dos casos, o foco é o serviço. Uma empresa de produto não. E você pode pegar exemplos em qualquer indústria.

1. A "Consul" faz o ar condicionado, e não espera vender nenhum "serviço" de instalação. Quem faz esse "serviço" é a loja (normalmente).

2. A "Oracle" desenvolve (entre outras coisas) o banco de dados. E a área que desenvolve o banco de dados não se preocupa com o que o consultor (da área de "professional services") vai fazer. O produto é auto-contido. Não tem um diretor que pensa "essa funcionalidade eu vou colocar no produto, e essa vou vender como serviço". Na IBM é a mesma coisa, a área de "professional services" usa o produto. Mas o produto é pensando por uma área que pensa o produto como um todo, e não pensa que a funcionalidade A ou B será feita por um consultor. Eventualmente eles até pensam nisso, mais com o foco de implementar funcionalidades que agregam mais valor e não com o foco em ter uma pessoa fazendo o trabalho.

3. A Accenture não tem produto, então, a preocupação dela é como usar os produtos para habilitar novas vendas, ou para entregar melhor os projetos. 

Tive uma experiência legal nesse sentido. Em uma das empresas que eu trabalhei, a IBM tinha um produto que concorria diretamente com o nosso. E acabamos fazendo um projeto com a IBM em um cliente mundial. A área de "professional services" da IBM, acabou optando por fazer o rollout da nossa solução em nível global, por que ia fazer com o que o projeto deles fosse entregue de forma muito mais rápida (eles iam reduzir o tempo de projeto de 2 meses para 3 semanas). 

Em empresas que tem produtos e serviços, normalmente o que deveria acontecer é que enquanto o produto não tem a funcionalidade A ou B, a empresa de serviços poderia "fazer por fora", mas isso não deveria (em principio) ser usado como priorização do roadmap do time de produto, e sim como uma forma de workaround até o produto fazer.

[leantechbusiness]

Caminho crítico e Cadeia Crítica

Quem trabalha com gerência de projetos normalmente conhece o conceito do "caminho crítico". Sem me alongar, o caminho crítico é ao mesmo tempo o caminho mais longo e o mais curto para você determinar o prazo final do projeto. 

Na prática, o caminho crítico é determinado em razão das escolhas de sequenciamento das atividades do projeto (lembra do dependências inicio-fim, inicio-início, fim-fim?). Quando você determina o caminho critico, significa que:

Se as atividades que pertencem ao caminho crítico atrasarem, seu projeto como um todo atrasará

Se você tem um projeto com muitos caminhos críticos, ou com muitas atividades do projeto (percentualmente falando) no caminho crítico, você tem um projeto que corre muito risco de atrasar

Dado o sequenciamento que você configurou, aquele é o menor tempo para se entregar o projeto.

Existem muitas informações que podem ser obtidas simplesmente analisando o caminho crítico do projeto. E na grande maioria das vezes, a dica para se diminuir os prazos dos projeto sempre passa por reconfigurar a rede (mudando assim as atividades do caminho crítico) ou por alocar melhor os recursos (de forma a diminuir as durações das atividades). Duas técnicas famosas são o crashing (quando você analisa o conjunto prazo-custo de forma a identificar o melhor prazo com o menor custo) e o fast-tracking (onde você analisa a viabilidade de fazer tarefas em paralelo que originalmente seriam feitas em série).

Onde entra o Critical Chain?

Critical Chain (ou método da cadeia crítica) segue por uma abordagem um pouco diferente. A idéia é você submeter toda a sua rede de atividades a uma análise de troughput tentando entender onde está o "gargalo" da sua rede, e a partir desse ponto, tentar aumentar o fluxo do gargalo. Existe toda uma teoria (a Teoria das Restrições) por trás desse método. Mas de forma geral e bem simplista, o que é feito no critical chain é o seguinte:

Ao invés de se estimar as atividades com 90% de certeza, o time de projeto estima com 50% de certeza

Todas as atividades são sequenciadas de forma a começarem o mais tarde possível

Ao se começar uma atividade, não se faz nenhum multi-tasking nela. 

As limitações (restrições) de recursos são consideradas inputs fundamentais no sequenciamento das atividades

Ao final dos milestones principais, colocamos um "buffer" que tem por objetivo garantir o cumprimento dos prazos

Já utilizei os 2 métodos, e acredito que o método do Critical Chain fornece ao mesmo tempo prazos menores e mais confiáveis. Para mais detalhes sobre o Critical Chain, sugiro fortemente a leitura dos livros do Eliyahu M. Goldratt (principalmente o "A meta" e o "Corrente Critica).

[leantechbusiness]

Lições Aprendidas

Todo mundo fala de melhoria contínua. Em muitos dos métodos ágeis você escuta o tempo retrospectiva. Mas o conceito por trás disso é mais o menos o mesmo.

O que é uma lição aprendida?

É a oportunidade que você tem para analisar e entender o que deu certo, o que deu errado, o que precisa ser melhorado, o que pode ser capitalizado, e principalmente por quê as coisas aconteceram do jeito que aconteceram.

De forma geral em uma sessão de "Lições Aprendidas", o objetivo é esse. Entender o que pode ser aprendido com tudo o que deu certo e com tudo o que deu errado. John Allspaw escreveu um artigo excelente a esse respeito (que pode ser lido - em inglês - aqui).

A melhor forma de encarar uma sessão desse tipo é sempre pelo lado do que se pode aprender:

Se deu certo, e você sabe por que; significa que você pode tentar fazer de novo, tentando maximizar os efeitos positivos.

Se deu errado, você precisa entender o que deu errado, o que deveria ter sido feito diferente, por quê deu errado, e principalmente; como você pode identificar situações semelhantes no futuro de forma a evitar cometer o mesmo erro.

Quando você faz isso?

Depende. Eu recomendo fazer de forma periódica ao longo das fases principais dos projetos (ou, se você usa algum método ágil, ou alguma forma de time-boxed), ao final de cada sprint (ou ao final de cada time-boxed).

Por que? Por que provavelmente é a melhor hora para refletir sobre o que pode ser aprendido. Se você esperar o projeto (ou o release) inteiro terminar, é bem provável que você esqueça de muitas coisas.

Qual o maior benefício?

Se você acha que achar os "culpados" dos problemas que aconteceram é o maior benefício, você não entendeu nada. O maior objetivo é você aprender para não cometer os mesmo erros novamente. Esse é o objetivo. Simples assim! Pode não parecer, mais esse tipo de aprendizado no longo prazo pode te pagar juros compostos, e pode fornecer inúmeros insights sobre onde melhorar o seu processo.

[datanewoil]

Big Data Processing Technologies

Major Hadoop technologies grouped by workload type, batch and/or real time.

For more information, click here.

[leantechbusiness]

Gestão de expectativa de clientes

Ao longo da minha experiência como gerente de projetos, acabei percebendo que além de toda a parte técnica da gestão de projetos, existe 1 fator fundamental para conseguir sucesso. E esse fator é conseguir alinhar e gerenciar de forma adequada a expectativa dos clientes/stakeholders.

(E é curioso notar, que desde a 2a ou 3a versão do PMBok, esse tópico vem ganhando cada vez mais destaque. Na 3a versão era um ou dois parágrafos, na 5a edição é uma área de conhecimento inteira).

Acho que esse trabalho é importante por várias razões, mas principalmente por problemas de comunicação que acontecem. Já participei de projetos onde tecnicamente tivemos um sucesso estrondoso, mais o cliente ficou extremamento insatisfeito, e já participei de projetos onde o mesmo acabou estourando mas prazo, escopo, e com baixa qualidade, mas o cliente acabou ficando satisfeito com o projeto (e em alguns casos acabou comprando/contratando outros projetos).

Vejo alguns pontos importantes para fazer essa gestão de forma bem feita:

Transparência: quanto mais transparente e honesto o time de projeto for, mais fácil vai ser o trabalho para gerar a expectativa dos stakeholders

Comunicação: quanto melhor for a comunicação (mais eficiente, eficaz, falando as pessoas certas, do jeito certo, na hora certa) melhor

Empatia: Quando o time de projeto consegue se colocar na posição do stakeholder, e consegue entender o que está acontecendo, porquê as coisas são importantes ou por que não são, por quê isso ou aquilo é necessário,etc, melhor.

Espirito de time: se o time de projeto entender que o cliente e os stakeholders são parte do time de projeto, os 3 pontos de cima ficam mais simples. Acaba a necessidade de ficar se defendendo, do nós-contra-eles, etc.

Busca da excelência e volta de resolver as coisas: quando o time busca dar o seu melhor, e o cliente consegue perceber isso, o ambiente do projeto muda, mesmo com problemas. Nesses casos, o cliente/stakeholder consegue perceber que está todo mundo querendo resolver o problema e não transferir o problema. 

Existem ainda outros pontos que ajudam, mas considero esses os principais. Isso é fácil de fazer? Não necessariamente, mas é simples. A pegadinha é conseguir fazer isso dia sim, dia também, e conseguir vencer as inúmeras pequenas batalhas que acontecem no dia a dia.

[leantechbusiness]

Trabalho remoto funciona?

Esse tópico é polêmico.

Acho que antes de qualquer coisa é importante definir o que significa “funcionar”. Porque dependendo de como você definir “funcionar”, a resposta pode mudar de sim para não (e vice-e-versa).

Você pode definir “funcionar” de algumas formas. Vou comentar 2 das mais comuns:

1. Funcionar = você consegue entregar as coisas que você precisa Nesse caso, eu diria que funciona sim, e para a grande maioria das pessoas. Ou seja, se você der uma tarefa para a pessoa, normalmente ela vai te entregar a tarefa.

2. Funcionar = máximizar a produtividade dos funcionários Nesse caso eu acho que a questão passa a ser bem mais complexa. E para entrar em mais detalhes vou separar alguns aspectos:

maturidade/disciplina: nem todo mundo tem maturidade para conseguir ser mais efetivo trabalhando remoto (ou em home office).

ambiente: nem todo mundo tem o ambiente adequado para se trabalhar remoto.

tipo de trabalho: nem todo mundo tem o tipo de trabalho que facilita a questão remota.

Perfil pessoal: algumas pessoas tem mais facilidade do que outras para trabalhar remoto, se importam menos em ficar sozinhas, com menos interações do que outras.

Vou dar alguns exemplos:

I. Se você não tem disciplina/maturidade, trabalhar remoto vai fazer você ter (na grande maioria das vezes) menos produtividade. Você vai parar no meio do dia, por exemplo, para ver o programa que está passando na TV, ou você vai aproveitar para resolver pendências em casa. E aí entra a disciplina. Se você não tem, muitas vezes é complicado “compensar”. O oposto também acontece. Você pode acabar começando a trabalhar muito cedo, e terminando muito tarde. Muito mais tarde do que normalmente você ficaria, e com isso sua vida pessoal acaba sendo prejudicada, o que no longo prazo acaba sendo prejudicial para a empresa também.

II. Se você tem filhos pequenos, ou tem uma família grande, e não tem um ambiente calmo e isolado onde você pode trabalhar, dificilmente sua produtividade vai ser boa. É um tal de um entrar no seu quarto, ou passar na sala e querer trocar uma ideia com você aproveitando que você está ali, que na prática reduz muito sua produtividade. Filhos pequenos são outra distração. Mesmo que tenha alguém com eles em casa, na grande maioria das vezes eles preferem “brincar” com os pais do que com a babá.E acabam te interrompendo frequentemente.

III. Seu tipo de trabalho envolve falar constantemente com várias outras pessoas, ou você está em um time onde o trabalho de um envolve e impacta direta e continuamente o trabalho dos outros. Nesse caso trabalhar remoto é mais difícil, simplesmente pela natureza do trabalho. 

Em quase todas as empresas que eu já trabalhei, era permitido algum tipo de trabalho remoto, e pela minha experiência, poucos são os casos e as pessoas que realmente são mais produtivas trabalhando de casa/remoto.

Conclusão: Trabalhar remoto pode funcionar muito, muito bem, dependendo de uma série de fatores. Ou pode simplesmente ser uma troca ruim (onde você acaba trocando mais produtividade, por menos produtividade).  

[leantechbusiness]

Without data, you are just another person with an opinion

W. Eduard Deming