terça-feira, 27 de setembro de 2011

Desvendando a burocracia

Outro dia estava conversando com um colega de outra equipe, uma equipe recém-formada na empresa, que me assegurou que iam conduzir a equipe "como uma startup". Que iam ser ágeis, lançar iterações frequentes, e que não iam ficar amarrados às burocracias da empresa. Eu achei a iniciativa louvável mas fiquei com a pulga atrás da orelha. Será que dá mesmo para conduzir uma equipe como uma startup dentro de uma empresa grande?

Quando pensamos em startups versus grandes empresas, vem a imagem de um bando de magrelas esfomeados, vestindo camisetas com dizeres engraçados, trabalhando como loucos e lançando produtos inovadores e sensacionais, contra um exército de gordos engravatados preenchendo formulários. É um fato da vida que à medida em que empresas crescem, elas se tornam menos flexíveis. Os acordos informais que funcionavam tão bem quando eram três magrelas já não funcionam com trezentos, e as coisas precisam se tornar formais. O que era bom senso é cada vez mais tornado regra na forma de políticas internas. É a ossificação dos processos.

Daí os desenvolvedores mais antigos se reunem no café para lamentar como tudo piorou desde os velhos tempos. Só que se esquecem que a agilidade de uma startup vem com um preço: a dívida. Mais especificamente, a divida técnica, que é aquela que você adquire quando faz as coisas rápido ao invés de fazer direito.

Sim, dá pra lançar uma nova rede social para corredores de kart em duas semanas. Uma startup precisa mostrar resultados o mais rapido possível, pois precisam começar a pagar as contas atrasadas do provedor de internet. Assim, não se preocupam que um dia o sistema terá de ser traduzido em quarenta línguas, que terá de comportar milhares de usuários, que poderão ser processados por algum cliente mal-amado, que o código terá de ser lido e mantido pelas dezenas de novos funcionários que farão fila na porta quando o sucesso chegar. Todas essas preocupações ficam para depois em troca da rapidez - essa é a dívida técnica. Quando chega  a hora de pagar a dívida, ela precisa ser paga com juros, pois o sistema já está em execução e as mudanças precisam ser profundas pois não foram contempladas no design inicial.

Uma empresa grande não precisa fazer esses "empréstimos". Pode se dar ao luxo de contemplar todas as facetas do sistema enquanto ele está sendo desenvolvido. Por isso há tantos processos, checklists e burocracia aparente. Seu sistema precisa ser vistoriado e aprovado por especialistas em segurança, analisado para determinar o consumo de recursos e a escalabilidade, testado para medir a usabilidade, revisado por advogados para evitar desastres, e tantas outras coisas que tomam seu tempo, dão trabalho e parecem querer impedí-lo de lançar seu lindo produto. O que está acontecendo é que você está evitando contrair uma dívida que pagará com juros depois. Você até pode rodar sua equipe como uma startup dentro de uma grande empresa, mas não deve.

Os processos aparentemente burocráticos não existem para piorar a agilidade de ninguém, mas sim para garantir que o que precisa ser feito é feito. Só que nem todos os processos são assim: na sua empresa certamente existe alguma regra que, na sua opinião, só piora a sua vida. Será que a burocracia é inevitável e que não há o que fazer a não ser continuar a ler Dilbert e a se identificar com ele? Não.

Toda vez que você avistar uma placa proibindo ou prevenindo, pense que ela com certeza foi motivada por algum evento real:


Coitado do pinguim. Da mesma forma, muitas das políticas implantadas nas empresas existem porque alguém, algum dia, fez algo que não deveria e a empresa não quer que esse algo se repita, então cria uma regra nova. Só que os tempos mudam e essas regras continuam lá. O que você pode fazer é olhar para cada regra burocrática da sua empresa e pensar, por que será que implementaram isso? será que o que era verdade naquela ocasião continua sendo verdade? será que hoje não há outra forma de se evitar o problema? será que o custo em tempo perdido devido à regra não é maior do que os danos causados pelo problema que ela existe para evitar? Responda a essas perguntas, junte os dados, proponha alternativas, leve para os responsáveis, e seja um super-herói para os seus colegas.

2 comentários:

  1. Muito legal. Concordo bastante. Desenvolver como uma startup numa empresa grande beneficia os indivíduos e não a empresa. Essas pessoas serão promovidas, mudam para outro time, filial ou até mesmo saem da empresa e as pessoas que nunca viram o código na vida terão que manter o sistema no ar e não serão promovidas por isso.

    ResponderExcluir
  2. Legal o post, mas achei simplista de diversas formas.

    Primeiro, me parece que um argumento latente eh que "agilidade causa divida e nao escala", o que eh uma afirmacao grosseira.

    Segundo, dizer q uma empresa grande pode se dar ao luxo de "contemplar todas as facetas" eh outra intrujice. Qual a diferenca entre uma empresa grande e uma start-up? Em uma empresa grande vc pode estar querendo resultados rapidos pra mostrar para um executivo, assim como numa start-up vc quer resultados pra mostrar para investidores e clientes. Os casos de start-ups desbancando empresas grandes tambem exemplificam o quao relativa a vantagem das empresas grandes eh. No fim, ambas estao no mesmo mato, com diferencas cuja relevancia eh discutivel, embora seja sim relevante.

    Os processos nao foram feitos com o objetivo de atrapalhar, mas frequentemente o fazem. Eles comumente refletem a aversao a risco de uma empresa grande. Por isso criam regras e ai o tal fato inevitavel da vida entra em cena. A agilidade falada consiste em dar mais poder as pessoas do que as pedras na qual as regras foram escritas.

    Para concluir, vale ressaltar q um fundador jovem de uma empresa grande jovem diz: "move fast, break stuff". Acho q ele mataria uns pinguins pra isso :p

    ResponderExcluir