Artigos

Vamos falar de negócios!

Um ponto bastante observado em diversos trabalhos que realizei por aí é a incapacidade da equipe técnica de perceber o seu trabalho como parte de um negócio. É intrigante ver esses desenvolvedores (e aqui incluímos todos os papéis que desenvolvem um produto, não apenas os programadores) buscando a pureza técnica, o estado da arte daquilo que estão fazendo no seu dia a dia. Essa busca do trabalho pelo trabalho leva a um perfeccionismo negativo, conduzindo seu artista a pensar que sua obra jamais estará acabada.

Por outro lado também temos times que não estão comprometidos com nada, apenas com as atividades para si alocadas. Tais times (ou membros em cenários melhores) se enxergam apenas como parte de uma engrenagem maior, como parte de uma linha de produção cujo o seu papel é transformar análise em código. Eles apenas trabalham ali e antes que você os amaldiçoe, lembre que tem um desse cara dentro de você, algumas vezes por dia.

Tanto no primeiro como no segundo cenário o resultado é o mesmo: desenvolvimento desconectado do negócio, trabalho sem um propósito claro. Tudo o mais que falo aqui é sobre isso, entender o quanto o time compreende do seu lugar no mundo e se realmente compreende o propósito daquilo que estão desenvolvendo.

Usualmente quando esse é o ponto mais fraco da uma avaliação, uso técnicas que aproximam cliente do desenvolvedor, buscando diminuir a quantidade de telefones sem fio no meio do caminho. Quanto mais pontos houver, pior a comunicação como a própria brincadeira homônima ensina. O que a brincadeira não passa é que a relevância de qual problema o time está resolvendo diminui inversamente proporcional ao aumento dessa cadeia. A causa é a despersonalização do usuário. Até o termo “usuário” é ruim. Usando personas e escrevendo os requisitos como histórias de usuário ajudam a reconectar o desenvolvedor ao negócio e consequentemente ao usuário final.

O que estou tentando explicar é que na maioria dos casos que vi, o problema não era primariamente do método escolhido. Os times eram bons em desenvolver software. O software errado, mas eram bons. Não adianta você ser o Usain Bolt e correr pro lado errado da pista. É preciso aceitar que não se conhece o software que resolve o problema do usuário e você só vai descobrir isso criando esse software. Em resumo, traga para a mesma mesa desenvolvedores e usuários finais e aproxime essa conversa tanto quanto possível. Os resultados são mágicos e você só tem a ganhar.

Quem lembra de acessibilidade?

Anos atrás eu estava em um evento sobre Design para Web (sim, eu já fiz de tudo um pouco) e assistindo um dos renomados palestrantes que lá falavam. No momento das perguntas alguém questionou se a acessibilidade começaria a então entrar firme no desenvolvimento de sites. O exemplo do palestrante foi fantástico:

O buffet hoje servido no café estava excelente, cheio de petiscos e doces deliciosos. O problema é que eu não podia comer. Sou diabético. E muito provavelmente não havia nenhum diabético no buffet, pois isso não foi uma preocupação para aqueles que fizeram o buffet. Não que as pessoas que escolheram o cardápio sejam pessoas ruins, apenas não se deram conta de que haviam pessoas com necessidades especiais, provavelmente por nunca ter experimentado isso. As pessoas se tocam das necessidades dos outros quando sentem compaixão ou na própria pele essas necessidades.

Esse palestrante, do alto de sua sabedoria não poderia estar mais certo. Eu já me preocupava com questões desse tipo nos eventos que organizo pelos anos em que vivi com minha avó, que tinha algumas dificuldades de locomoção. Mas era algo superficial, não era uma preocupação forte, mas algo que se houvesse como, faria algo para melhorar a vida desses caras. Porém, esse ano tive uma experiência mais profunda.

No começo do ano, tive uma torção média no pé, repetindo a mesma torção (igualzinha, sem tirar nem por) meses depois, dessa vez com bastante seriedade. Por essa razão andei de muletas por várias semanas, seguidas de outras tantas com bengala. Só então pude perceber detalhes, que antes passavam desapercebidos. Notei o quanto é difícil para alguém com dificuldades de locomoção uma calçada irregular. O quanto é difícil descer de degraus fora do padrão. Entre outras coisinhas que fui aprendendo pelo caminho.

Se você está pensando “o que eu tenho a ver com isso?” ou ainda “ótimo para você parceiro, mas em que isso muda a minha vida?” eu posso ajudar a esclarecer. Sendo você desenvolvedor (e aqui eu abranjo todos que desenvolvem uma solução para um cliente, independente de programadores, testers, analistas…) passa os seus dias dentro de um escritório recebendo papéis e devolvendo soluções, você está fazendo isso errado. Você precisa viver a vida do seu cliente! Você precisa conhecer as suas dores de perto, ver os problemas acontecendo, sentir onde o calo aperta no sapato para saber como corrigir. Só assim você vai ter uma visão plena e realista daquilo que realmente resolve os problemas do seu cliente.

Para ficar mais claro ainda, deixo um pequeno bom exemplo, onde o pessoal levou isso ao extremo, vivendo as dores e pensando em soluções para isso.

A necessidade da visão externa

Fico feliz quando visito algum cliente, novo ou antigo, e encontro um ambiente no qual eu invejo.

Experiências centradas no usuário, foco nas pessoas, alta capacidade técnica são só algumas características que vejo por aí nessa galera.

Por isso sempre me causa espanto por que eles precisam de mim ou de meus colegas. Está tudo ali, todas as ferramentas necessárias para melhorar aquele ambiente. Até mesmo a vontade de fazê-lo está presente. Mas ainda assim, precisam de alguém que lhes aponte a direção certa.

O meu palpite é que nós estamos tão imersos em nossos problemas do dia-a-dia que não deixamos um tempo para melhorias. Mesmo times com bons conhecimentos de agilidade esquecem de deixar um tempo para se melhorar, se aprimorar. É a eterna luta para continuar cortando árvores e nunca amolar o machado.

Eficácia versus eficiência.

Bom, tem muito assunto aí. Numa próxima oportunidade falaremos mais sobre isso.

A culpa da vítima

Para quem achou que eu ia falar do caso envolvendo vídeos de whatsapp, traficantes e crimes sexuais está enganado. É que esse ano, entre as muitas epifanias que tive, resolvi compartilhar algumas em forma de post e essa é uma delas. O mais “legal” desses momentos de iluminação é que eles tem vindo de coisas a princípio ruins em minha vida, mas de todas ao menos uma boa lição eu levo. Essa daqui veio dos dois furtos que sofri nesse ano.

No primeiro eu tive a minha casa invadida por bandidos que, injustiçados pela sociedade, fizeram uma redistribuição de renda forçada. Dentre várias pequenas coisas furtadas, estavam meu notebook de trabalho, o da minha esposa, TV… enfim, todo e qualquer eletrônico que aparentava valor foi subtraído de meu lar. Chegar em casa e presenciar a bagunça é uma situação inenarrável. Me senti invadido em mim mesmo, sem chão, afinal invadiram o meu refúgio, meu porto seguro, aonde eu confio que posso deixar aquilo que com trabalho foi conquistado. A primeira reação foi então de pânico, seguido por revolta (ambas em torno de um minuto cada) e depois por um alto grau de calmaria, quase um psicopata analisando e pensando nos próximos passos para minimizar as perdas. Essas foram minhas reações. As reações das pessoas com quem eu conversava sobre o ocorrido é quem eram mais interessantes.

Me perguntaram se eu tinha alarme. Disse que não. Mas poxa cara, você tem que ter alarme, você marcou nessa…
Me perguntaram se eu tinha seguro. Disse que não. Como alguém não tem seguro da casa? É barato e ajuda muito nessas horas.

Enfim, segui me sentindo culpado por uns dias enquanto trocava a porta de metal que usaram para invadir e ouvia que portas assim tinham que ter reforço. Que era estupidez da minha parte não ter. Reforcei a porta como pessoas sensatas dizem que deve ser.

O outro seguiu mais ou menos a mesma linha. Em viagem de trabalho com amigos, minhas malas acabaram no banco da frente, junto com minha mochila, onde eu guardei o passaporte. A minha reação foi idêntica (me permiti ser humano de novo quando estava abrigado na casa de um amigo/anjo que mora na cidade do ocorrido) e as das pessoas também. Eu fui estúpido. Deixei meus bens trancados num carro, bastava alguém quebrar a janela e levar. Dito e feito. O problema é o que o feito veio antes do dito e não deu tempo de me precaver.

Essa coisa toda me deixou bem alerta e reflexivo quando vejo esses casos de estupro, assassinato, furto, assalto de pessoas que deram a oportunidade. Todos foram estúpidos por acreditar que vivemos em sociedade e que os demais membros da já citada seguiriam suas regras de boa conduta. Todos nós somos pessoas idiotas que um dia deram a oportunidade (mesmo que você não tenha percebido) e uma pessoa que não deixa esse tipo de coisa passar, tomou vantagem disso.

A lição que tiro de tudo isso? Não dê bobeira! Não dê oportunidade! Pois mesmo se você não der a culpa é sua, o malandro só está agindo conforme a natureza dele.

Como ensinar?

Uma das coisas que mais aprendi ao longo dos anos foi como ensinar. O legal disso é que ensinar me levou a aprender, o que é um círculo virtuoso que eu quero manter pelos próximos 50 anos ou mais. Nesse humilde post vou contar como foi a minha história com aprendizagem, como comecei a ensinar e finalmente hoje treino todo o tipo de pessoas, CEOs de grandes organizações até universitários ávidos por conhecimento que os diferencie no mercado.

Sou filho de uma professora e isso foi muito impactante para essa carreira. Minha mãe, como criou a mim (e a meu irmão) sozinha fez o melhor que pode dentro dos seus recursos para nos prover uma ótima educação. Desde de muito jovem eu via como um educador fazia a diferença na vida das pessoas. Ela foi por alguns anos professora na zona rural da cidade, quando ia todas as manhãs pegar um ônibus que a levava para a fazenda, passava o dia em uma turma multiseriada (acho que era de 1º à 4º anos) e no fim do dia regressava para casa. Aquelas pessoas sentiram na educadora alguém que se importava, que lhes oferecia bem mais do que conteúdo mas valores que pautaram suas vidas. Quem não ia querer ser essa pessoa.

Eu mesmo comecei a ensinar já na infância. Na escola, o nerd/gordo/zarolho/filho da professora não tinha como ser mais zuado. Não tendo mais o que fazer na escola, com pouca interação social, me restava então me dedicar às aulas e isso eu fazia. Acompanhava as aulas e como não me distraia aprendi sempre com relativa facilidade os conteúdos. Obviamente os caras mais sociais da sala, como estavam ocupados em ser populares não tinham o mesmo desempenho. Aí que eu me tornei “popular“. As pessoas com dificuldade me buscavam querendo aprender sobre os conteúdos. Isso se dava por algumas razões. A primeira e mais óbvia: eu sabia e eles não. Simplesmente eu tinha um conhecimento que mesmo com a mesma oportunidade de aprendizado foi melhor aproveitada por mim. A segunda razão, um pouco mais sutil é: eu sabia falar a língua deles. Era mais simples perguntar ao colega de mesma idade do que para outra pessoa com 20, 30 ou 40 anos a mais que você. Fora a intimidação que a figura do professor passava, que gerava um certo temor em perguntar e ser repreendido. Outra vantagem em aprender comigo e não com o professor eram as metáforas. Eu conseguia fazer paralelos, explicar usando outros exemplos, trazer aquilo para uma realidade mais simplificada do que o conteúdo formal da sala de aula.

Em um determinado ano o diretor da escola resolveu trazer um curso de informática para a cidade, algo inovador em 1989. A minha mãe, como trabalhava na escola sugeriu colocar o filho para ajudar na parte burocrática do curso em troca de um desconto nas mensalidades. E assim eu ajudava com as matrículas, com o recebimento das mensalidades, organizava a sala entre as turmas, essas coisas que uma criança pode fazer. E assim eu consegui fazer meu primeiro curso de informática. No ano seguinte o curso se renovou e então eu pude continuar trabalhando, mas agora com uma pequena renda. Foi então que aconteceu de um professor faltar um dia. E faltou outro. E mais outro. E então eu comecei a buscar novos professores de informática sem muito sucesso, afinal, era o início dos anos 90 e informática não era tão trivial como é nos dias de hoje. Consegui alguns, mas poucos se mantinham no curso. Foi então que me vi obrigado a tomar uma decisão. Levantar a bandeira branca e dizer ao diretor que não tínhamos como continuar ou ousar dar uma aula seguindo o conteúdo que eu já conhecia, mesmo que obviamente sem a profundidade de um professor. Acabei optando pela segunda. Saí petrificado da primeira aula, nervoso como um adolescente no seu primeiro beijo (sim, sou velho o suficiente para crer que isso deva acontecer na adolescência, mas enfim…) mas consegui. E a medida que os dias iam passando e os dias se tornando meses, os meses se tornaram anos e aquilo realmente ficou fácil para mim. Estudei programação nessa época, com uma apostila que um colega de classe tinha me presenteado por te-lo ajudado a concluir um software. Era em Clipper. Bons tempos. Estudei o suficiente para então começar a desenvolver meus próprios softwares e então poder ensinar a programar.

Nesse momento eu tinha entendido uma coisa interessante. Se você sabe fazer de fato, sabe o que você está ensinando na prática, o ensino se torna leve. Você não está mais ensinando um conteúdo formal vindo de um livro ou treinamento. Nada contra conteúdos formais, nem tudo dá para praticar. Mas ter vivência naquilo que se ensina te dá bagagem, exemplos, te permite ter alternativas para aquelas perguntas mais inesperadas. E assim, ensinando um curso após o outro, uma aula após a outra, eu pude ir entendendo os pequenos meandros dessa arte.

Quando eu finalmente concluí um curso universitário (iniciei 4, papo para outra conversa) eu pude perceber o valor daquele modelo de formação. Não pelo conteúdo, já me considerava um programador experiente naqueles dias (pra minha sorte o mercado também) mas pelo ambiente. É um local de estudo, um ambiente focado em aprendizagem, com pessoas que também exercem funções no mercado durante o dia, que buscam se atualizar, criando atalhos para um conhecimento que existe, está ali solto no ar, mas que eles já fizeram a coleta, processaram e te entregaram prontinho. Veja, não estou elogiando o modelo de ensino que muitos criticam por aí. É só a impressão que deixou em mim. Fiz amigos para a vida toda por lá e sempre fui humilde e respeitoso com meus professores, mesmo os mais jovens que eu. Eles deram inputs interessantes para a minha melhoria como profissional.

Após a universidade eu voltei dar treinamentos, agora ensinando como as pessoas poderiam melhorar o seu jeito de trabalhar utilizando as tais práticas ágeis que tanto falo aqui no blog. Via os discursos inflamados e cheios de paixão desses caras e os diferentes tipos de treinamentos. Alguns eram mais formais, com projeção, flip-charts e apostilas. Outros eram mais dinâmicos, com práticas, papéis coloridos, bolinhas e dinâmicas que movimentavam, divertiam, mas ainda assim ensinavam. Nesse momento eu entendi que ensino não é sobre transmissão de conteúdo, mas sim sobre levar o educando a entender um conceito. Isso significa que eu posso até te contar sobre algo, você pode entender a minha mensagem e isso seria muito bom. Agora se eu te fizer sentir, provocar a surpresa, a sensação, o sentimento que te conecte ao conteúdo o resultado é muitas vezes mais efetivo. É como se o aprendizado formal se formasse no cortex e o informal se desse no límbico.

Já havia lido sobre Teaching from the back of the room e achava suas ideias interessantíssimas para ligar aluno e conteúdo ensinado. Usei muitas delas em meus treinamentos, mas sentia que poderia fazer melhor, dar um certo polimento naquilo. Seguindo nessa linha, nesse último ano tive a grata oportunidade de me juntar com outras pessoas que assim como tinham entendido que aprender tem que ser algo que venha de dentro dos educandos e fui apresentado ao conceito de Learning 3.0. Nessa maneira de entender o aprendizado, o treinador é um mero maestro, orquestrando seus alunos na construção do conhecimento. A ideia é que, usando técnicas de aprendizagem emergente, os alunos construam um conteúdo próprio, em conjunto, que provavelmente será muito mais retido do que num modelo tradicional de estuda-decora-prova.

Hoje eu sinceramente não sei como definiria meus próprios treinamentos. Uso projeção (sem vergonha alguma de dizer isso) porém poderia talvez dar um treinamento sem ela. Uso flipcharts porque os treinandos gostam de ver que você pode construir seu próprio material sem depender de recursos como o PPT. Dá a elas a sensação de que existe um domínio forte do que está sendo apresentado. Uso o máximo de dinâmicas que posso para esclarecer o conteúdo e levar os treinandos a sentir mais do que saber. Enfim, talvez não é um estilo que se encaixe em uma descrição, mas é o meu estilo. O que sei é que os feedbacks têm sido positivos, melhorando a cada classe e cada dia que ensino aprendo um pouco mais sobre essa arte.

Portanto como se ensina algum conteúdo? Não ensine. Promova o sentir, fomente a interação e permita que eles construam o conhecimento sob sua regência. Bom aprendizado/ensino e até a próxima.

O problema não é da arquitetura

Estive recentemente palestrando na XP Conf BR, iniciativa muito legal dos meus amigos gaúchos para falar um pouco sobre “agilidade de raiz”. Essa agilidade de quem realmente faz o código, de quem escreve código e quer fazer bem feito. Falamos muito sobre as práticas da programação extrema e algumas outras coisas correlatas. É legal que, de uns tempos para cá, eu ando muito reflexivo e questionando quase tudo e todos. Talvez seja só um mal (ou bem) da idade mas o fato é que toda situação que me deparo tem me puxado um pensamento e esses eu tenho compartilhado por aqui. Foi muito bom rever meus amigos falando de Pair Programming, de Histórias de Usuário, de metáforas, entre outros assuntos legais. Assuntos teóricos, outros com casos reais de implantação, enfim, tudo ótimo. Mas a reflexão que isso me puxou é a seguinte: o problema realmente está na arquitetura?

Eu por vezes me vi tentado a pensar que sim, que como desenvolvedor eu via meus pares criando códigos de maneira quase irresponsável. Sim, irresponsável, afinal, a responsabilidade pelo código que escreviam era do gestor, do dono da empresa, ou ainda da criatura maligna do cliente que realmente não sabe o que quer, ou ainda não sabe pedir direito. Quando a gente vai num evento como esse, cheio de desenvolvedores, ávidos por escrever código de qualidade eu me questiono aonde estamos errando pois a realidade é bem distante da utopia que falamos nas palestras.

Nas palestras a gente fala de como deveria ser. De como nos fariam felizes que nossos ambientes de desenvolvimento fossem. De como seria legal que os valores ágeis, aqueles do manifesto, fossem seguidos como um código de conduta. É assim que baseio a minha vida e me parece plausível fazê-lo quando estou trabalhando. Pensar em pessoas e interações, software que funciona, colaboração com cliente e adaptação serem mais importantes que processos, documentos, contratos e planos parece fazer bastante lógica na cabeça de todo mundo que eu converso. Mas aonde estamos errando? Por que temos tanta dificuldade de convencer gestores sobre isso? Uma ideia que vem martelando na minha cabeça há tempos é que nós não entendemos o manifesto. Não entendemos a profundidade da mudança de pensamento exigida para fazer aquilo ali ser real. Vejo usualmente os desenvolvedores traduzindo “indivíduos” como “minha equipe”. É fácil se esquecer que em todos os níveis da nossa organização existem indivíduos, pessoas, seres humanos, de nossa espécie, e que esses são afetados se fizermos um trabalho mal feito.

De novo, não acho que o problema seja de arquitetura, tenho plena fé que meus amigos desenvolvedores são extremamente hábeis técnicamente para resolver os problemas que surgem e se não forem são capazes de evoluir a ponto de superar os obstáculos. Eventos como o XP Conf me mostram isso. O problema é que nós não nos importamos com as pessoas. Nem mesmo aquelas dentro da nossa organização, quem dirá aqueles que vão usar o nosso código para solucionar problemas em suas vidas.

A culpa é sua!

É interessante como esse texto ficou em rascunho por quase um ano! Refleti muito antes de escrever algo que realmente fosse de valor para nós desenvolvedores.

Eu pensei quando estava escrevendo esse artigo em falar de modelos de arquitetura sustentáveis, que funcionam mesmo. Aqueles que ajudam empresas, equipes e clientes a ter uma boa entrega de valor. Mas achei que isso seria irrelevante.

Também pensei em falar sobre alguns patterns e sua importância, como isso ajuda a se focar somente naquilo que ainda não tem solução. Os problemas conhecidos já têm uma solução proposta e basta aplicar. Embora isso seja mega importante, acho que é um assunto já bem batido e tem pessoas extremamente mais bem qualificadas para falar sobre o assunto.

Eu poderia continuar falando aqui das ideias que me passaram pela cabeça quando estava pensando nesse post mas vou direto ao ponto. Você! Você é o elemento que faz a diferença no desenvolvimento de software. Não adianta você ser excelente tecnicamente e não ser um ser humano legal. Parece papo de psicólogo (nada contra psicólogos, adoro vocês) ou ainda de livro de auto-ajuda (tá, esses eu não gosto mesmo, diferente dos psicólogos) mas é o ponto central de fazer software de qualidade.

Quando escreveram o tão citado manifesto, colocaram como valor primário “indivíduos e interações entre eles”. De novo, não é porque isso é bonito ou todos os caras que assinaram eram “paz e amor”. Não! Eles só perceberam que não é meu empregador que vai usar o software, não é a empresa cliente que vai usar o software, não é o departamento de suporte que vai usar o software. É a Maria, mãe de uma filha pequena, sem marido; aquela analista de suporte que precisa preencher rapidamente (e sem erros) uma chamado para o Jorge, funcionário público, de meia idade e pouco entende de software ou informática em geral, aquele cliente dela que está com problemas e precisa da ajuda da empresa na qual a Maria trabalha. Sacou a diferença? São pessoas! Seres humanos! Da sua própria espécie! Gente como eu ou você!

E por favor, não coloque a culpa na sua empresa ou no “sistema”. Sim, entendo o que o sistema quer dizer e o quanto ele influencia no comportamento das pessoas. Mas se o sistema te obriga a agir contra seus princípios e valores, o que você está fazendo aí? Busque um novo sistema ou crie o seu próprio! Médicos não pedem se podem lavar suas mãos antes de um procedimento, faz parte da sua profissão. Sua profissão supera o que o sistema lhes impor. Por que desenvolver software seria diferente?

Sim, amiguinhas e amiguinhos, quando falamos que as pessoas são mais importantes que tudo, é sério. Em última instância, estamos escrevendo software para as pessoas. Se você coloca isso na cabeça e começa a se importar com elas, dar um nome para elas, pensar em quais problemas delas você está resolvendo eu duvido que a solução que você está desenvolvendo agora não sairá de qualidade. Ou no mínimo muito mais preocupada com aquilo que a Maria e o Jorge precisam.