Depois eu leio

Software fora de empresas de tecnologia

Trabalhar com software numa empresa cujo core business "não" é software, é um grande desafio. Já até ouvi de um colega de área que respeito bastante, que são lugares tristes para um desenvolvedor trabalhar. Realmente, ser tratado como "recurso" ou fazer parte do departamento que é "apenas custo", demonstra que o ambiente ainda tem muito o que amadurecer até se tornar verdadeiramente produtivo.

Por outro lado, é uma grande oportunidade atuar no cenário de uma empresa alheia aos processos mágicos ou tecnologias fantásticas da vez, que estão sempre nas modinhas do mundo de TI. Desenvolver um sistema de qualidade e levar a equipe a um bom nível de maturidade depende apenas da sua bagagem. Não há imposições quanto a esta ou aquela plataforma, não há processos jurássicos no meio do caminho nem submundo de disputa política entre departamentos ou programadores estrela. Mas então porque será que apesar da liberdade de atuação, implantar Scrum num ambiente destes é uma missão surreal?

Com o foco todo dedicado ao core business, a competição pela atenção dos POs no dia-a-dia dos sprints é uma causa perdida: "PO sempre presente" é lenda, horários de reunião nunca são respeitados, backlog fraco, pedidos "pra ontem" quebrando o sprint... pior que isso só em fábricas de software.

Mas antes de continuar, vamos olhar a situação pelo ponto de vista de um empresário comum. Você está lá tocando a sua loja, organizando eventos ou cuidando de um laboratório e, de repente, brotam meia dúzia de computadores e uma gente esquisita que não cumpre horário comercial começa a pedir que você explique tudo do seu negócio. O primeiro resultado são bonequinhos de palito no quadro branco e post-its coloridos enfeitando a parede, por uma pequena fortuna mensal.

Depois de uma semana (sendo muito otimista), aparecem para lhe mostrar uma tela com meia dúzia de botões que você tem certeza que seu sobrinho que "também mexe com computador" conseguiria fazer por 3 jogos de PS2 comprados no camelô. Como conseguir a colaboração genuína de alguém que só quer que as coisas se resolvam, rapidamente e sem o menor esforço para entender o valor e o background do que está comprando?

Você quer ver a mágica sem aprender o truque

Falando a partir do meu senso comum, creio em três níveis de compromisso. No primeiro, você precisa de algo mas não dá a menor importância para entender como aquilo funciona. Por exemplo, eu quero que meu carro sempre funcione, então sigo as manutenções recomendadas. Mas se quebrar, eu só quero saber quanto custa pra arrumar e quando fica pronto, e meu critério pra escolher um mecânico vai ser na base do orçamento e indicação. Neste nível eu não estou nem aí pra qual era o problema, não gosto de mecânica e não quero entender nada disso - apesar de depender do veículo diariamente.

Você tem curiosidade de descobrir o truque

No segundo nível de compromisso, as pessoas têm algum interesse em ficar boas no assunto em questão. Geralmente é aí que estão os hobbys, o estudo em áreas fora do campo de trabalho ou a prática de esportes, por exemplo. Precisa gostar e treinar muito pra ficar bom de guitarra ou não espatifar um aeromodelo veloz, mas se você quer tocar como o Joe Satriani ou abrir uma loja de modelismo, então faz parte do próximo e último nível de compromisso.

Você quer ser o mágico

E neste último nível, só entra o que é realmente a sua praia, aquilo que você consegue manter o interesse pelo tempo necessário para ficar realmente bom e fazer disso o seu ganha pão. Há um estudo que chegou no número de dez mil horas pra ficar mestre em algo, mas mestre ou não, geralmente é nessa área que você se diverte e consegue usar seu melhor potencial criativo onde outros têm dificuldade.

Voltando ao problema

Quem não é geek gosta de computadores tanto quanto eu gosto de carros, ou seja, só quer ligar e sair usando. O problema é que software não é como um carro, onde você compra um dentre um número bem limitado de marcas e modelos disponíveis e todos resolvem o problema da locomoção de forma extremamente parecida. Pouquíssimos softwares têm o mérito de estar a esquerda do 80/20, e por isso mesmo podem ser comprados numa prateleira. Basicamente são jogos ou sistemas para o cotidiano de escritórios e usuários não geeks.

O próprio mercado explica porque isso acontece: apesar de cada área de negócios ter um padrão bem definido, cada empresa busca atuar no seu ramo de um jeito que a diferencie das outras. E é daí que brotam os departamentos de TI e consultorias de três letrinhas: especialistas em reinventar a roda diariamente, fazendo e refazendo sistemas que resolvem os problemas de uma determinada área do conhecimento, porém, sob a ótica de uma empresa específica e contrato de confidencialidade.

Isto (e mais tantos outros motivos) invalida qualquer tentativa de tratar software como linha de produção. Software é artesanal (até os de prateleira), e para que os artistas expressem em seu código e usabilidade o espírito da empresa para a qual venderam a alma, digo, para a qual estão trabalhando, o desafio para o time de TI "estranho no ninho" é trazer os empreendedores - ou POs (Product Owners) - do nível 1 de interesse para o nível 2.

Ciclos de entrega curtos são uma das chaves para garantir que o sistema está resolvendo satisfatoriamente as necessidades dos interessados. Por isso o artigo começou falando de Scrum, seus ciclos curtos, bom suporte para comunicação eficaz e simplicidade somados a ênfase em pessoas sobre processos (do manifesto) ajudam bastante a fazer as pontes para os POs participarem cada vez mais da ilha de TI. Mas o Scrum, por si só, não resolve nada e é aí que o artigo acabaria no "surreal" do segundo parágrafo.

Na verdade, nenhum processo é capaz de resolver o problema do nível de compromisso. Sozinhos, processos apenas tornam centros de custo toleráveis como um cunhado que pede dinheiro emprestado. É na cultura da empresa que devemos cativar o nível de compromisso e qualidade que buscamos, pois o próprio Scrum sem a cultura do manifesto ágil é tão fraco quanto qualquer outro processo e falha na mesma proporção.

A literatura clássica diria que é hora de mapear os stakeholders e fazer o planejamento da comunicação. Eu gosto da teoria sobre o mapa de poder, legitimidade e urgência, mas como não estamos falando de guerra fria, prefiro pensar que existem contadores de histórias adormecidos.

Poder, legitimidade e urgência - Mitchell, Agle, Wood (1997)

Mitchell, Agle, Wood (1997)

POs rebeldes não têm a obrigação de entender de sistemas, mas são os únicos capazes de explicar como as coisas funcionam de um jeito que nós de TI, conseguimos entender como elas poderiam ser mais simples. Perceber que estão substituindo n planilhas em excel, x formulários e y horas de ligações telefônicas diárias por um sistema que tornará vários de seus processos instantâneos, facilmente auditáveis e principalmente, mais simples, transforma os donos do negócio em verdadeiros "contadores de causo".

Com os POs no nível 2 de interesse, um gerente que fez a lição de casa sobre agile (idealmente o próprio PO) tem condições de planejar um bom backlog e proteger a equipe das quebras de ciclo. Agora sim a equipe passará a entregar o que interessa e as histórias irão refletir um alto nível de detalhamento no sprint corrente, diminuindo gradualmente até épicos conforme se afastam na linha do tempo.

No fim, é bem gratificante ver pessoas que apenas delegavam responsabilidade e culpa do alto de uma montanha descerem até o quadro branco pra fazer uns rabiscos na reunião de planejamento. Ter a consciência de ser tão responsável pelo sucesso ou fracasso do sistema quanto o desenvolvedor faz toda a diferença.

E se um dia aparecesse uma oficina mecânica no meu quintal, pode ter certeza que em poucos dias minhas mãos também iam ficar sujas de graxa.

No comments

Código legado e débito técnico

Trabalhar num código legado, é como fazer uma viagem no tempo ou atravessar um dos portais Stargate. É ali que está a verdadeira história de uma empresa de tecnologia: a pressa em lançar antes do concorrente, a atenção (ou falta de) que se dá para um capacity planning, a qualidade da comunicação interna, o perfil das equipes de desenvolvimento, a clareza das regras de negócio, etc. Está tudo ali, pra quem souber traduzir os hieróglifos também conhecidos como débito técnico.

Ward Cunningham foi o primeiro a utilizar o termo “débito técnico”, para explicar que sempre que uma empresa de software opta por um design que visa resultados rápidos - abrindo mão da qualidade - ela insere no sistema uma complexidade que tornará seu custo maior no longo prazo. Para mais detalhes sobre a parte teórica, recomendo ir direto ao site do Mestre dos Magos.

No primeiro parágrafo eu misturei propositalmente os termos “legado” e “débito técnico”, mas será que são realmente a mesma coisa? Segundo este outro cara, legado é simplesmente qualquer código sem testes. Seguindo esta linha, sou levado a crer que débito técnico e legado são dois bichos diferentes.

Legado é aquele código caixa-preta, que ninguém sabe o que será afetado se mudar uma linha e ninguém se atreve nem a indentar (ou endentar, pro dicionário ficar feliz) o código. Normalmente, o sistema foi feito por pessoas que nunca ouviram falar do termo “débito técnico”, pois se soubessem o conceito, também saberiam como fazer um design que favorecesse sua manutenção futura.

Este é o resultado da mistura entre cowboys e gerentes caricatos. Eles acreditam estar fazendo um bom trabalho sendo pragmáticos ao extremo, mas, sem bons alicerces teóricos e um mínimo de estratégia é quase impossível fazer um sistema que não seja uma bomba-relógio - a chance de acerto é pura sorte.

Já em relação ao débito técnico legítimo, a equipe têm consciência de que para aproveitar uma oportunidade de mercado ou algo parecido em tempo hábil, não será capaz de implementar a arquitetura mais desejável a tempo. Porém, é perfeitamente capaz de trabalhar com foco no mínimo necessário e ao mesmo tempo se manter aderente a princípios de design que favoreçam a refatoração no momento adequado. E claro, o sistema obrigatoriamente terá alguma cobertura de testes, e ser testável é sinal de mais boas práticas no pacote.

Minha dica aos desenvolvedores que precisam dar manutenção a algum sistema legado: vistam o chapéu de Indiana Jones e divirtam-se. Arqueologia de sistemas é um ótimo exercício para refatoração e desenvolvimento da programação como arte. Afinal, como na arte, o sistema perfeito é o que atingiu a simplicidade onde não há mais nada a ser removido.

No comments