7 de abril de 2014

Otimização prematura: não é apenas sobre código

Quando falamos sobre desempenho, não devemos olhar apenas para desempenho da execução de código. Existem mais tipos que devemos prestar atenção, como tempo para mercado, tempo de desenvolvimento e processos. Na verdade, não devemos olhar qualquer uma destas medidas de desempenho de uma única perspectiva. Penso que todas estas medidas se unificam para constituir um único valor de desempenho de negócio.

Existem muitas coisas que podem desacelerar seu negócio, e se você tiver um negócio devagar, será difícil acompanhar o ritmo de seus concorrentes. A partir do momento que você vê que algumas áreas da sua empresa podem estar te atrasando, você pode sentir-se tentado a adicionar indicadores de desempenho em cada passo, tentando espremer todo valor possível de cada parte do seu processo. Isto pode trazer um monte de novos problemas, seu negócio pode ser visto como um sistema complexo e ele irá se adaptar para mostrar bons resultados mesmo em cenários caóticos. [1]

Então, para evitar ficar maluco com indicadores para todos os lados, você decide evitar gargalos desde o princípio. Para cada coisa nova que você precisa entregar, começará uma rotina de planejamento preciso, escolhendo entre uma infinidade de fornecedores, tecnologias e unicórnios para evitar a todo custo ter um novo gargalo no futuro. Isto é o que gosto de chamar de otimização prematura de desempenho de negócio.

De forma simples: você não pode ter um negócio se você não tiver um negócio. Como você pode saber de todos os eventos futuros que irão impactar na decisão que você toma hoje? Você não pode. Não estou dizendo que planejar é errado ou uma Coisa Ruim™. O que eu realmente quero é evitar perder energia em coisas que não farão a menor diferença. Você pode gastar um ano inteiro escolhendo entre maçãs e laranjas, e no final ser esmagado por algum maluco brincando com tecnologias esquisitas. Por quê? Porque ele não estava preocupado com gargalos futuros. Ele estava realmente tentando fazer algo legal, e ele fez isto enquanto você estava discutindo em intermináveis reuniões sem propósito.

Você sempre está escolhendo entre medidas de desempenho. Por exemplo, todo mundo está falando a respeito de arquitetura orientada a serviços (SOA), mas o que isso significa em termos de negócio? Significa uma troca entre desempenho de execução de código e outros benefícios para o negócio como um todo, como crescimento descentralizado e entrega contínua. Ou, você pode olhar nas diferenças entre os modelos da App Store da Apple e a Play Store do Google. Existe uma troca gigantesca entre garantia de qualidade e tempo de mercado entre estes dois jogadores: um oferece a seus clientes (donos de smartphones), aplicativos com qualidade assegurada; o outro oferece a seus clientes (usuários do sistema operacional), tempo para lançamento ao mercado acelerado para seus aplicativos.

A grande questão realmente é: o quê você está tentando entregar ao seu cliente? Você está tentando entregar software sobre tempo ou valor sobre tempo? Eu aposto que a maioria de vocês estão tentando entregar valor sobre tempo, então por quê se preocupar com otimização prematura de tecnologias ou processos? Deixe que as coisas ruins morram por si só: falhar rápido é dezenas de vezes melhor do que não fazer nada. E deixe que as coisas boas te acompanhem para onde você quer ir.

Não gaste seu tempo adivinhando o futuro, abrace a incerteza da vida: você não pode prever como um sistema complexo irá se comportar, você não pode saber como seus sistemas, serviços ou seja lá o que você esteja fazendo, irão se comportar no mundo real. Coloque eles para funcionar, receba as reclamações e ajuste o que for preciso (ou jogue tudo fora), isto é um processo constante. [2]

Comece a medir quanto você está entregando em determinado tempo e pare de planejar tanto. Seu objetivo final é entregar coisas. O mundo não poderia se importar menos com o que você consegue fazer, ele só se importa com o que você faz.

Referências

  1. Complex Systems and Key Performance Indicators - Márcio Geovani Jasinski
  2. Complaint-Driven Development - Jeff Atwood

Nenhum comentário:

Postar um comentário