Há um monte de software ruim lá fora. Eles não são confiáveis, são inseguros e inutilizáveis. Tornou-se tão ruim confiar em desenvolvimento de software, que algumas pessoas estão exigindo regulamentação para desenvolvimento de software e que os desenvolvedores de software possuam licenciamento como “engenheiros de software”, para que o software possa ser desenvolvido dentro de certos padrões profissionais e que processos por negligência ou imperícia, em caso de problemas, possam ser evitados.

O licenciamento garantiria que todos que desenvolvem software têm pelo menos um nível básico de conhecimento e um nível aceitável de competência. Mas os desenvolvedores licenciados não vão garantir um bom software. Mesmo que sejam bem treinados, experientes e comprometidos, nem sempre poderão construir bons softwares. Porque a maioria das decisões que impulsionam a qualidade do software não são feitas por desenvolvedores – são feitas por outra pessoa na organização.

Gerentes de produto e donos de produtos, gerentes de projeto e gerentes de programas. Patrocinadores executivos. CIOs, CTOs e VPs de engenharia. Estas são as pessoas que decidem o que é importante para a organização, o que é feito e não o que faz e quem faz – em quais problemas as melhores pessoas devem trabalhar, qual trabalho é enviado ao largo ou terceirizado para economizar custos. As pessoas que fazem a contratação e a demissão, e que decidem quanto dinheiro é gasto em treinamento e ferramentas. As pessoas que decidem como as pessoas se organizam e quais os processos que se seguem. E em quanto tempo elas começam a fazer o seu trabalho.

Gerentes – e não desenvolvedores – decidem o que significa qualidade para a organização. O que é bom e o que é “bom o suficiente”.

Erros de gestão

Como gestor, eu cometi um monte de erros e tomei más decisões sobre a minha carreira. Cortei qualidade para cortar custos. Dei para as equipes prazos que não puderam ser cumpridos. Fiz controle sobre horários e prioridades, tentando espremer os recursos para tornar o cliente ou um executivo de marketing feliz. Fui intransigente com desenvolvedores e testadores que me disseram que o software não estava pronto e que eles não tinham tempo suficiente para fazer as coisas corretamente. Deixei dívidas técnica se acumularem, insistindo que teríamos que entregar agora ou nunca, e que de alguma forma nós faríamos tudo certo mais tarde.

Mas eu aprendi com esses erros. Acho que sei o que é preciso para construir um bom software agora. E eu tento me segurar a isso. Mas eu continuo vendo outros gestores cometendo os mesmos erros. Mesmo nas maiores empresas de tecnologia e mais bem sucedidas do mundo, como Microsoft e Apple.

Essas são as organizações que controlam seus próprios destinos. Começam a decidir o que vão construir e quando precisam entregar. Elas têm alguns dos melhores talentos de engenharia do mundo, têm todas as boas ferramentas que o dinheiro pode comprar – e, se precisarem de melhores ferramentas, simplesmente as escreverão. Elas estão na ativa há tempo suficiente para saber como fazer as coisas direito, e têm o dinheiro e a escala para realizá-lo.

Elas devem escrever software bonito. Software que é uma alegria para usar, e que o resto de nós pode seguir como exemplos. Mas elas nem sequer chegam perto. E não é culpa dos engenheiros.

Qualidade Microsoft

Problemas com a qualidade do software na Microsoft são de tão longa duração que o termo “Qualidade Microsoft” tornou-se um termo reconhecido para software que é apenas “bom o suficiente” para ser marginalmente aceito – e às vezes nem isso é bom o bastante.

Mesmo depois que a Microsoft se tornou um fornecedor global e uma empresa dominante, a qualidade continuou sendo um problema. Um artigo de 2014 da revista Computer World, chamado “Na Microsoft, a qualidade parece não ter nenhum emprego“, aborda as reclamações sobre problemas graves de qualidade e confiabilidade em versões anteriores do Windows 10. Mas o Windows 10 supostamente representa uma mudança radical para a Microsoft sob o seu novo CEO, a chance de compensar os erros do passado, para fazer as coisas certas. Então, o que está acontecendo de errado?

A cultura e o legado de software “bom o suficiente” está em vigor há tanto tempo que a Microsoft parece estar presa, incapaz de melhorar, mesmo quando reconheceram que bom o suficiente não é bom o bastante. Esse é um problema organizacional e cultural profundo. Um problema de gestão. Não é um problema de engenharia.

Problemas da qualidade de software da Apple

A Apple se define para além da Microsoft e do resto do campo da tecnologia, e cobra um prêmio com base em sua reputação de design e excelência em engenharia. Mas, quando trata-se de software, a Apple não é melhor do que ninguém.

Do tombo épico do Apple Maps até constantes problemas no iTunes e a App Store, os problemas com as atualizações do iOS que não conseguem ser instaladas, dados perdidos em algum lugar no iCloud, sérias vulnerabilidades de segurança, mensagens de erro que não fazem sentido, e incoerências desconcertantes nas restrições à usabilidade nos produtos da Apple são demasiado decepcionantes em seus aspectos fundamentais.

E, como a Microsoft, a Apple parece que perdeu seu caminho:

Temo que a liderança da Apple não percebe o quão profundamente suas falhas de software têm danificado sua reputação, porque não perceberam que alterações importantes não parecem estar acontecendo. Em vez disso, o oposto parece estar acontecendo: o ritmo de atualizações rápidas em várias linhas de produtos parece estar se expandindo e acelerando. Eu suspeito que o rápido declínio de software da Apple é um sinal de que o marketing é a mais alta prioridade na Apple hoje: ter grandes e novos lançamentos a cada ano é claramente impossível para as equipes de engenharia do ponto de vista de manter a qualidade. Talvez seja um problema de engenharia, mas eu não acho. Eu duvido que qualquer equipe de engenharia coesa poderia se manter com essas exigências e manter uma qualidade significativamente superior desde que a Apple perdeu o terreno elevado funcional. Marco Arment, em 2015/01/04.

Os recentes anúncios na WWDC deste ano indicam que a Apple está tomando algum tempo extra para se certificar de que seu software funciona. Mais acabamento, menos enfeites. Nós vamos ter que esperar e ver se essa é uma pausa temporária ou um sinal de que a gerência está começando a entender (ou lembrar) como qualidade e a confiabilidade são realmente importantes.

Gerentes: parem de cometer os mesmos erros

Se empresas como a Microsoft e a Apple, com todo seu talento e dinheiro, não conseguem construir software de qualidade, como o resto de nós deveria fazer isso? Simples. Não cometendo os mesmos erros:

1. Colocar a velocidade de chegada ao mercado e o custo disso na frente de todo o resto. Empurrar as pessoas para metas difíceis de bater. Ir tão rápido quanto possível, não dando o tempo de a equipe fazer as coisas direito ou sequer uma oportunidade de fazer uma pausa e refletir e melhorar algo. Nós todos temos que trabalhar com prazos e orçamentos, mas na maioria das situações de negócio não há espaço para tomar decisões inteligentes. Métodos ágeis e entrega incremental fornecem uma maneira de entregar material quando você não pode negociar prazos ou custos, e não pode controlar o escopo. Se você não pode dizer não, pode dizer “ainda não”. Priorize o trabalho impiedosamente e certifique-se de que você irá entregar os itens mais importantes o mais cedo possível. E uma vez que essas coisas são importantes, certifique-se de que você irá fazê-las direito.
2. Deixar os testes para o fim. Isso significa deixar a correção de bugs para o final, resultando na entrega tardia e com muitos bugs. As práticas ágeis e disciplinadas dependem de testes – e correções – de forma que você execute testes TDD, e até mesmo força você a escrever os testes antes de escrever o código. A integração contínua garante que o código funcione cada vez que alguém fizer o check-in. O que significa que não há nenhuma razão para permitir que os erros se acumulem.
3. Não falar com os clientes, não testar ideias cedo. Não aprender por que eles realmente precisam do software, como eles realmente irão usá-lo, o que amam sobre isso e o que odeiam a respeito. Entregar de forma incremental e obter feedback modularmente. Agir sobre esse feedback, e melhorar o software.
4. Ignorar as boas práticas de engenharia fundamentais. Fingir que sua equipe não precisa fazer essas coisas, ou não pode se dar ao luxo de fazê-las ou não têm tempo para fazê-las, mesmo que a gente se conheça há anos é fazendo as coisas direito que irá ajudar a oferecer melhor software mais rápido. Como um gestor de programas ou proprietário de uma empresa, você não precisa ser um especialista em engenharia de software. Mas também não pode tomar decisões de trade-off inteligentes sem compreender os fundamentos de como o software é construído, e como deve ser construído. Há um monte de boas informações lá fora, sobre como fazer desenvolvimento de software da maneira certa. Não há nenhuma desculpa para não aprender isso.
5. Ignorar sinais de alerta. Escute os desenvolvedores quando lhe dizem que algo não pode ser feito, ou não deve ser feito, ou tem que ser feito. Os desenvolvedores estão geralmente dispostos a trabalhar muito, para chegar longe. Então, quando eles dizem que não podem fazer algo, ou não devem fazer algo, preste atenção.

E quando você cometer erros – e você vai cometê-los e aprender com eles -, não desperdice-os. Quando algo der errado, faça o time a analisá-lo em uma retrospectiva ou execute um post mortem irrepreensível para descobrir o que aconteceu e por quê, e ainda como você pode melhorar. Aprenda com testes de auditorias e pegue sua caneta. Dê feedback negativo dos clientes a sério. Isso é importante, uma informação valiosa. Trate-a adequadamente.

Como gerente, a coisa mais importante que você pode fazer é não enviar sua equipe para o fracasso. E isso não é pedir demais.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/07/dont-blame-bad-software-on-developers.html