Eficiência ou eficácia ao desenvolver software?
Então turma, depois de ver a imagem acima você deve estar pensando que eu vou fazer um paralelo de GoT com software certo? Você QUASE acertou.
Game Of Thrones foi sucesso de público e crítica anos após ano e infelizmente na última temporada acabou desagradando sua legião de fãs de forma muito feroz. Não, eu não vou entrar no mérito de qualidade da série, porque realmente acredito que tem muito de opinião pessoal que influenciam finais de obras fictícias. Conheço até hoje pessoas dizendo que “você não entendeu o final de Lost”.
Porém, algo bastante curioso ocorreu na última temporada da série (que até então era quase unanimidade entre seu público) que foi o próprio público fazer uma petição pedindo para que a HBO refizesse a última temporada, que acabou sendo assinada por milhões de pessoas e repercurtindo bastante no cenário pop por esses dias.
O que era pra ser uma brincadeira em forma de protesto (pelo menos eu acredito nisso) ganhou proporções assustadoras e obviamente chegou até a produção e o elenco da obra. É exatamente nesse momento que nossa história começa.
Sophie Turner (da foto) que representou uma das “protagonistas” (sim, entre aspas porque a série tinha muitos protagonistas pela estrutura da história), deu uma declaração para o The New York Times que repercurtiu bastante. No Brasil, por esses dias lí no site do UOL (e alguns outros) a tradução do que ela teria dito. Confesso, eu não fui buscar a declaração oficial e vou ficar por aqui acreditando que a tradução feita foi de fato o que ela falou. Disse a atriz:
“Todas essas petições e coisas do tipo — eu acho que é desrespeitoso com a equipe, e os roteiristas, e os produtores que trabalharam sem descanso por mais de 10 anos, e por 11 meses gravando a última temporada”, lamentou Sophie.
Teria muita coisa pra discutir sobre essa declaração e onde eu acredito que ela falha miseravelmente, mas vou primeiramente completar o restante da declaração:
“Tipo 50 e alguma coisa de noites de gravação. Tantas pessoas trabalharam tão, tão pesado nisso, para as pessoas apenas tratarem isso com desprezo, porque não é o que elas queriam ver, é desrespeitoso”, adicionou a atriz.
Aqui eu começo um paralelo com o desenvolvimento de software e tudo o que eu comentar abaixo, já entra no tema.
“Trabalhar muito” e “trabalhar duro” é diferente de “resultado com qualidade”
Olhe pra imagem acima e veja que Chaplin deve ser eficiente, afinal a linha de produção do qual ele fazia parte necessitava que o trabalho dele fosse cumprido de forma correta no menor tempo possível, a fim de otimizar a linha de produção. Isso está certo porque uma linha de fábrica tem um processo já bem definido e o trabalho em questão se torna automático e braçal.
A menos que você trabalhe em uma grande linha de produção, você deve buscar eficácia antes de buscar eficiência. Em termos gerais, considera-se eficiência “fazer certo as coisas”, enquanto que a eficácia é “fazer as coisas certas”. Normalmente, quando trabalhamos duro para entregar um trabalho e damos o nosso melhor e copnseguimos fazer tudo o que nos foi colocado a frente, podemos dizer que fomos eficientes, porém se o resultado do trabalho não agregou valor real a ninguém, ele não foi eficaz. Perceba, um não exclui o outro e nós sempre devemos buscar ambos, mas se for pra escolher um eu lhe indico que você escolha sempre primeiramente (isso é importante frisar) a eficácia.
É aqui onde Sophie comete um pequeno deslize, pois pela óptica dela, a crítica à obra não poderia ser feita porque eles trabalharam duro. Eu daria outro motivo em defesa e darei agora apenas para não parecer que estou criticando a declaração por criticar.
Eu não acho que a última temporada deve ser refeita e é isso aí. Explico. Uma obra fictícia acaba como tem que acabar, ela é do autor, do roteirista e do produtor e como tal acabou como eles queriam. Você pode reclamar do final, pode reclamar da qualidade, pode achar furos de roteiro e amaldiçoar a família de quem conduziu a sua obra favorita por esse caminho, mas não tem o direito de pedir pra que essa pessoa refaça, já que assistir uma obra que você não tem o controle sobre o final é sempre um risco, pode ser bom ou não, de acordo com a sua ótica de qualidade e expectativa, mas você terá que conviver com isso.
Só que usar o motivo “eu trabalhei duro e dei o meu melhor” não “dá bom”. Se você está indo pra algum lugar para construir uma pilha de cocô e ao final do seu trabalho duro (de horas ou dias) para montar a pilha de cocô no meio de uma praça, alguém vier reclamar de você ter feito uma pilha de cocô no meio da praça, você não pode simplesmente dizer que aquela pessoa não pode reclamar já que você trabalhou muito duro por aquele monte de bosta.
E é aqui que acaba meu paralelo com o que a atriz falou. Todo o resto não vou me ater nesse artigo, você pode perguntar minha opinião se um dia me encontrar pessoalmente, tirando isso, não discutirei jamais sobre GoT na web, aprendi a lição.
O que sabemos sobre eficiência e eficácia no desenvolvimento de software
Trabalho com software desde 2004. De carteira assinada e no mercado formal, apenas desde 2007 e já fui negociante e apenas mero executor do que foi negociado.
Meus piores software nem de longe foram os primeiros que eu desenvolvi. Se formos falar apenas de qualidade de código, sim, foram sem dúvida os piores com folga, mas em se tratando de quem eles atendiam e quais objetivos cumpriam, estão muito longe de terem a alcunha de ruins.
Por questões comerciais e contratuais eu não poderia expor meu primeiro grande software desenvolvido, mas mesmo que eu quisesse eu perdi o código. Sim, perdi, na época eu não trabalhava com SCM, eu não tinha grana pra ter backup em HD e não usava o Google Drive e ele sumiu em uma queima de HD, pois nem no meu e-mail ficou :-(.
Minha última manutenção nesse código foi em 2008 alterando um trecho do código direto na máquina do meu cliente.
Basicamente ele era um sistema desktop Java que auxiliava representantes comerciais a gerenciarem suas vendas a seus clientes e seus estoques. Meu primeiro cliente foi meu pai e as primeiras iterações do software foram feitas diretamente com ele. Basicamente eu desenhava um protótipo no papel de pão, ele aprovava ou sugeria melhorias e nós refazíamos até chegar a uma versão aceitável pra eu começar a desenvolver.
A cada pequeno avanço, eu mostrava pra ele como estava, recebia o feedback e continuava com o combinado ou voltava atrás na próxima feature refazendo o que eu tinha que refazer.
Após 3 ou 4 meses de trabalho duro, pus o software pra rodar no nosso computador, com um ícone no desktop e não mais executando pelo Netbeans.
Lembro que a primeira, e uma das únicas mudanças que precisei fazer pra ele, ocorreu depois de uns 6 meses de uso por conta da forma que ele passou a interagir com os clientes. Logo eu havia negociado o software com mais 3 representantes que usavam aquela versão do SisRep.
Logo em seguida, meu pai insistiu para eu pegar um emprego formal. Ele dizia que eu iria aprender um monte de coisa que eu jamais aprenderia trabalhando sozinho daquela forma e que ia ser bom pra mim.
Talvez, se eu não tivesse seguido o conselho do meu sábio e conservador pai naquela época, eu não teria material suficiente pra poder afirmar com tanta certeza o que afirmarei nesse artigo: busque ser eficaz, antes de ser eficiente.
Sophie em um trecho da entrevista disse: “…porque não é o que elas queriam ver…” e no nosso caso, o software precisa ser exatamente o que o seu público (cliente) quer ver. É ele quem vai usar e é exatamente por isso que ele é que tem que decidir como tem que ser.
Todo esse movimento recente de startups validando suas ideias cedo é exatamente para que não construam negócios da sua cabeça com suas ideias “maravilhosas”. A ideia é diminuir o risco de por um produto no mercado e gastar energia e $$ em algo que ninguém vai usar/comprar.
Não importa o quão duro você trabalhou em uma ideia se teu cliente não gostar dela e não estiver disposto a pagar por ela. Você não vai poder dizer: “nossa, que falta de respeito para com o meu produto, eu dei duro pra fazê-lo sabia?”… Nobody care my friend…
A tal transformação digital
Logo as startups começaram a difundir esses conceitos e todo mundo começou a transformação digital. Você vai achar várias definições desse conceito por aí e eu darei o meu.
É importante falar isso para que vocês entendam meu ponto de vista em relação a dar prioridade para a eficácia ao invés de priorizar a eficiência.
Transformação digital, foi algo que surgiu para todo e qualquer ramo da sociedade, incluindo as empresas que já eram digitais, e que foi forçado a acontecer porque empresas que nasceram com conceitos de startup, focadas nas pessoas que iriam usar suas soluções, conseguiram criar uma afinidade muito grande com seus consumidores a ponto de elevar o nível de exigência de qualidade por parte desses.
Antes não havia opção. Comprávamos softwares que tinham no mercado e tínhamos poucas opções de escolha de customização, além delas serem caras e demoradas.
Grandes empresas faziam seus clientes de refém, muitas vezes com soluções toscas, pensadas por pessoas “especialistas” que desenvolviam software ‘in house’ dentro de grandes fábricas de software, definindo grandes funcionalidades e regras que ninguém iria usar, mas que eram negociadas pelas lideranças de ambas as partes.
Exemplificando, suponhamos que eu, dono da empresa “A” que vende algum produto, negocio com o Fulano, dono da fábrica de software “X”, líder de mercado, e presente em mais de 20 países, a customização de um software que deve fazer o papel de melhorar as minhas vendas.
Em algumas reuniões com meu gerente de vendas e alguns meses depois, a empresa X tinha quilos de papéis, que eu e meu time deveríamos ler e assinar concordando que o software que iria resolver meus problemas era aquele software que estava escrito naquele arquivo .doc digitado por uma outra pessoa que não estava presente nas reuniões originais.
De repente alguns anos e depois de muito stress, xingamento e ameaças de processo, o software estava nas mãos do meu vendedor (que nunca foi consultado no processo de criação pra saber quais eram suas dores reais no dia a dia) e ai dele que não usasse o novo software que eu paguei caro pra “melhorar a vida dele”.
Você consegue enxergar o problema? Horas e horas de trabalho duro, que não eram capazes de resolver a vida do ator para o qual o produto foi construído.
Se você adentrasse no time que estava desenvolvendo o software, ele estaria sendo cobrado constantemente por eficiência, entregas nos prazos estipulados (quase sempre por quem não ia fazer e nem sabe como faz), adequação do software ao que estava escrito no arquivo .doc (esse é a lei maior) e uma demanda sem fim desconsiderando a premissa básica de um software que é: “Software SEMPRE MUDA… SEMPREEEEEEEEEEEEEEEE…” <- [É exatamente essa a premissa, com letras maiúsculas como um berro mesmo ;-)]
Enquanto que o coitado do meu vendedor, que usaria o Software no final, que se dane, não é ele que está pagando pelo software não é mesmo?
Então, as startups chegaram e começaram a criar uma área que até antes ninguém tinha visto, mas que mudou a perspectiva da tal era digital e meio que corrigiu os rumos da mesma, que foi a tal da User eXperience (UX), em tradução livre: Experiência do usuário.
Eu não sou muito fã de nomear algumas coisas, acho que elas deveriam ficar apenas nos conceitos sem um nome, mas o mercado as vezes precisa disso pra começar a entender alguns conceitos que parecem óbvios.
Logo que eu comecei a ler e interpretar alguns conceitos de UX, me veio um Dejavu. Em 2004 pra 2005, eu praticava UX junto com meu pai no desenvolvimento do SisRep.
Eram as necessidades dele que guiavam a evolução do software, nada do que eu incluia no software entrava sem antes ser validado por ele, cada mudança tinha que refletir diretamente uma “dor” dele e pra cada tela ou regra codificada, era necessário um propósito claro.
A eficácia estava alí presente, embora a eficiência estivesse cada vez mais comprometida, pois o código macarrônico e mal escrito estivesse adicionando toneladas de débito técnico que cada vez mais complicavam as manutenções futuras. Mas me perdoem, eu era apenas “um mero desenvolvedorzinho inexperiente tentando sobreviver”.
E aqui entra o problema de darmos nomes a algumas coisas. Os nomes trazem uma carga de autoridade que muitas vezes não existe. Digo isso porque hoje conheço algumas empresas que continuam fazendo coisas sem se importar com seus usuários, mas que tem em seus times os profissionais de UX.
Os tais (coitados) recebem a missão de fazer exatamente o que o usuário precisa, mas o trabalho tem que “estar pronto até segunda que vem porque senão o prazo do software vai estourar”.
Se o que usuário realmente precisa for descoberto depois disso, já era, tudo porque a tal empresa precisa dizer que ela tem um profissional de UX.
A única coisa
Não, não estou fazendo referência ao livro que tem esse título (quem já leu indica?), mas sim dizendo que se você tivesse hoje que fazer somente uma única coisa para fazer seu software para seus clientes, essa única coisa seria “ser eficaz”. Chame do que quiser, crie técnicas que você quiser, contrate quem precisar contratar, realinhe com quem tiver que realinhar, jogue fora, o que precisar jogar, mas apenas faça o que é o certo a se fazer. Só assim seu software trará o real valor ao seu cliente.
Sophie se chateou certo pelos motivos errados. Seu trabalho duro não importa, já a qualidade e o valor gerado do que você entrega no final, sim.
A indústria de software evoluiu muito nos últimos anos e começo a enxergar alguma luz no fim do túnel quanto a isso, porém ainda há muita bullshit e fumaça que atrapalha o caminho. Discussões difusas sobre técnicas, a crença infantil ainda de alguns de que existe bala de prata, migração em massa de empresas e profissionais para as buzzwords do momento sem avaliação da necessidade e o pobre coitado do usuário do sistema, que precisa de um sistema eficaz, sendo sacrificado no processo, enfim.
Então, seu eu pudesse lhe indicar “a única coisa” que importa hoje para o seu sistema, se você ainda não o iniciou ou se tem a oportunidade de mudar os rumos da execução, é que você se concentre na eficácia do seu produto.
Pegue o usuário final do seu software pelo braço e valide com ele o que está sendo entregue, faça ciclos de feedback curtos e ouça o que ele está lhe dizendo, mude o caminho se necessário, mas no final, entregue valor.
Eficácia é diferente de “podemos fazer de qualquer jeito desde que atenda”
Preciso urgentemente porém alertá-lo disso, antes que programadores furiosos venham a minha caça com foices, tridentes e tochas porque o chefe deles agora disse que não precisa mais perder tempo com organização, porque o que importa é entregar o que o cliente precisa.
De forma alguma focar na eficácia quer dizer que você vai fazer de qualquer jeito, não é disso que se trata. O SisRep é meu orgulho como modelo de entrega, mas é minha vergonha como produto escrito. Eu jamais faria de novo coisas que fiz naquela época a nível de código fonte, pois sei que se o sistema fosse maior, ele rapidamente se tornaria um elefante branco difícil de dar manutenção, todavia isso também não quer dizer que eu procuraria a arquitetura perfeita já na primeira iteração do produto.
É importantíssimo um alinhamento entre o time que está produzindo o software (quando eu disser time a partir daqui, pode ser apenas você como autônomo, apenas entenda que time é quem está produzindo) para que as expectativas sejam dadas corretamente.
Definir o “que” será entregue deve vir do cliente, já o “quando” e o “como” preferencialmente do time.
Aqui a eficiência entra na história, porque ela não é menos importante, apenas não pode ser o guia do seu processo.
Práticas de desenvolvimento, padrões de artefatos e definições arquiteturais do projeto são todos as ferramentas que nós temos para garantir que a roda gire de forma saudável e as expectativas sejam alinhadas corretamente entre quem está produzindo e quem vai usar. Elas nos ajudam a ter métricas e nos dão a capacidade de entregar cada vez mais, ou seja, ser mais eficientes.
Logo, dar tempo ao time para adequar práticas de mercado e encontrar sua própria forma de trabalho saudável, é uma questão de sobrevivência, de forma que é fundamental para que a tal da “transformação digital” ocorra de forma simples e duradoura.
Começar a melhorar o “como” da entrega continuamente, dará a seu time a capacidade de cada vez mais otimizar o “quando” sua entrega ocorre. Assim você transforma seu modelo de entrega em algo que cada vez mais confiável, já que o cliente sempre recebe exatamente o que quer em um prazo quase sempre combinado e caso não seja no prazo acertado inicialmente ele nunca se sente enganado pois as expectativas são sempre realinhadas.
Para terminar
Não critico a Sophie por mais nada do que ela tenha dito que não o (em minhas palavras): “trabalhamos muito duro, logo não podemos ser criticados”.
Entendo a frustração dela e entendo a chateação de ter dado o seu melhor e no final ouvir alguém dizer “nossa, que bosta de resultado”.
Porém é a vida, eu mesmo já ouvi de um usuário a seguinte frase: “custa muito pra vocês pelo menos uma vez fazer algo que funcione como a gente precisa?” depois de um trabalho duro. Dói, mas o cara está reclamando porque pra ele também dói não ter o que ele esperava. Atrapalha o trabalho dele.
E aí, o que vocês acham?
