Author: juliano

Palestra para o PMI-PR

Ontem tive o prazer de palestrar para o PMI falando um pouco de como usar PMBOK e Agile em conjunto. Público muito receptivo e interativo, participaram da dinâmica e fizeram excelentes perguntas durante e ao final da palestra. Essa palestra foi uma visão geral de práticas e em que momento de um projeto, em minha visão, eu poderia usar uma ou outra.

Embora os slides não sejam muito textuais, a maioria é uma imagem e uma palavra, tem algumas referências interessantes para serem seguidas ali. Follow the white rabbit.

Dúvidas, questões, discordâncias, estou por aqui para responder.

Disseminação do Conhecimento

Somos trabalhadores do conhecimento. Ponto final. Esse texto poderia se encerrar aqui e que tudo que estou escrevendo a seguir perderia o sentido porque o foco aqui é esse: somos trabalhadores do conhecimento. Nós manipulamos dados, escrevemos rotinas, organizamos mares de informações em pequenas ondas suaves que as torna compreensíveis. É importante entender, não somos os detentores do conhecimento, essa era já passou. Houve um tempo em que minha família possuir uma Enciclopédia Britânica de 1979 fez toda a diferença nos meus estudos. Não estamos mais na busca de bibliotecas ambulantes mas de pessoas que saibam organizar e processar a informação. É aqui que começa a nossa conversa.

A informação deve fluir. Organizações não podem depender de pessoas, por mais impessoal que isso possa parecer. Se a falta de um membro pode fazer a organização como um todo ruir a fragilidade é sem precedentes. E acreditem, várias estão nessa situação e já tive a oportunidade de encontrar algumas por aí.

Na sua equipe hoje, existem super heróis? Qual o seu “bus factor”?

Sempre quando vou falar do conceito de super herói eu me lembro do filme Tróia, aquele com o Brad Pitt sendo o Aquiles. Mas não quero falar de Aquiles e sim de Boaglius. Logo no começo do filme acordam Aquiles para enfrentar o campeão do exército inimigo, numa disputa um a um. Boaglius usa os seus melhores golpes e toda a sua habilidade mas acabou por cair para um único golpe de espada de Aquiles. Esse era o herói. Um herói puxa a responsabilidade para si, defende o seu grupo e no final acaba por morrer por ele. Parece bonito para as histórias românticas mas eu prefiro viver para continuar escrevendo novas histórias. O herói corporativo é importante, todos se lembram dele como a referência daquele assunto, ninguém sabe mais daquilo do que ele. Isso leva sempre que ele e apenas ele é capaz de resolver problemas daquele assunto, afinal, ele o faz em menos tempo e com mais qualidade. Me lembro de um amigo de equipe que certa vez pegou dengue, algo comum aqui no Brasil. Foram três semanas de repouso e na segunda semana o coordenador da equipe estava cogitando mandar o desktop para a casa dele para que ele continuasse o trabalho. É assim que o herói vive. Sem férias, descansos, sem o direito à ficar doente. A fragilidade desse time pode gerar problemas enormes no futuro próximo.

Qual o tempo de treinamento de um novo desenvolvedor?

Em quanto tempo ele está apto a trabalhar sozinho em demandas menores? E quanto tempo para trabalhar com as mais densas?

Li uma charge interessante que falava algo como: nossa e se treiná-los e eles forem embora? No outro quadro um gerente mais sábio respondia: e se nós não os treinarmos e eles ficarem? Hoje empresas têm diferenças bem sutis, ao menos no tocante aquelas que observo. Ter uma salinha de descompressão, vídeo games, frutas e outros mimos já não é diferencial. Bem como outros benefícios do modelo padrão também não o são. Os profissionais hoje buscam local para destaque, onde possam crescer e ser mais. Assim, se uma empresa não oferece treinamentos, capacitação e faz o profissional melhor dia após dia ela corre em sérios riscos de perdê-lo. Eu sempre digo que você não tem muita influência em motivar seus funcionários, mas sim para desmotivar.

São ofertados treinamentos no começo do trabalho? Quais são? Como é medida a eficiência desse treinamento?

As pessoas têm em si mesmas as habilidades para se motivar, é algo intrínseco que pode ser fomentado com a trinca do Dan Pink: autonomia, maestria e propósito, mas sobre isso cabe um texto separado. O foco aqui é apenas na maestria. Como podemos tornar os nossos profissionais os mais completos do mercado? Como podemos capacita-los dentro de suas aptidões para garantir explorar mais as suas potências? Essas são perguntas que um líder servidor deve se fazer o tempo todo, para o funcionário que entrou semana passada e para o que está com 10 anos de empresa.

Treinar é uma arte, a arte de passar conhecimento de maneira direcionada, levando um conteúdo pré determinado para outras pessoas. Longe de ser a única ou melhor maneira, mas é uma das mais tradicionais e a mais valorizada nas organizações. Apesar de ser tradicional e tudo o mais o problema não é necessariamente no treinamento em si, mas como medir o retorno do investimento. Se avaliar o quanto foi aproveitado, absorvido de conhecimento num treinamento é um assunto polêmico é difícil, se imagine em cima disso descobrir em quanto tempo o valor investido no treinamento lhe trará o retorno esperado. É um desafio e tanto e não há uma resposta aqui. O importante é estabelecer entre ambas as partes, colaborador e organização, qual será a meta e como ela será atingida.

Conhecem o conceito de pair programming? Com que frequência costumam colaborar (do latim, trabalhar juntos), não apenas ajudar-se, uns aos outros? Existe algum tipo de cadência para isso ou é feito apenas sob demanda?

Embora o nome me apareceu pela primeira vez em programação, o conceito é aplicável em várias áreas. Já vi até mesmo ser aplicado até mesmo em manufatura de carros, portanto temos evidência de sua aplicabilidade em outros meios diferentes de software. A ideia básica é bem simples, ao invés de ter um único profissional realizando uma tarefa, temos dois, alternando em intervalos regulares quem faz as vezes de piloto e de navegador, numa analogia ao rally e outras atividades do gênero. Embora a princípio pareça ser mais caro para o empregador a longo prazo a coisa se paga. Se medido no intervalo de dias e até semanas, o custo pode realmente não valer, mas com um período maior ganha-se em foco e principalmente em qualidade de entrega e redução de retrabalhos. Vou explicar isso melhor num post separado e quando o fizer, deixo linkado aqui.

Ao final do projeto, o time é mantido? Como o que foi aprendido nesse projeto é passado para os demais times?

A última etapa da evolução de um time é passar o seu conhecimento adiante. Em vários modelos que lemos, Tuckman por exemplo, mencionam algo semelhante. Se formos mais além, encontraremos o famoso artigo dos professores Takeushi e Nonaka mencionando como times de alta performance realizavam o que foi chamado de transferencia organizacional do conhecimento. Assim, é de se admirar que ainda existam empresas que não investem em reter a informação gerada em seus projetos, que não investem em ter uma memória viva daquilo que foi aprendido e mais ainda, evitar a tornar as variáveis que levaram aos problemas do passado estejam presentes de novo em projetos futuros.

O conhecimento é o novo ouro. Precisamos ser sábios em mantê-lo, dado que seu custo de manutenção é baixo, mas o de aquisição bem elevado.

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 avaliar a agilidade da sua empresa?

Essa semana meus colegas e eu entregamos mais um trabalho de assessment ágil em uma grande empresa em SP. Foi muito interessante como sempre poder olhar para um outro ambiente diferente do seu, sem as paixões do dia a dia no intuito de ajudar outro a não cometer os mesmos erros que você já fez. Esses momentos sempre me fazem pensar em coisas que vi e coisas que vivi. Vou comentar algumas nesse texto.

Ah, como é bom fazer esse tipo de trabalho! Você se torna um avaliador, passando para aquela empresa contratada a sua visão sobre o seu processo atual. O quão legal é isso? É fantástico! Afinal é sempre mais legal ajudar os outros a resolver os seus problemas do que resolver os seus próprios. O modelo de avaliação que usamos eu criei baseado em outros que vi por aí, juntando um pouco de cada um que vi, colocando um pouco de meu próprio estilo e passando para o resto do time ágil validar. Considero um bom modelo, pois avalia quatro aspectos que considero importante para uma empresa possa ser considerada ágil: cultura, organização, técnica e negócio. O número quatro não é a toa e tem forte influência do manifesto ágil e como a empresa endereça cada um dos quatro valores ali presentes. Em textos futuros pretendo escrever um pouco mais sobre cada aspecto.

Um diferencial que a Objective tem sobre as demais empresas do mercado parece até meio contraditório porém depois que eu conto a história toda passa a fazer sentido. Não somos uma empresa de consultoria. Ou ao menos não éramos. A empresa nasceu como desenvolvimento e assim se mantém até hoje. Porém temos resolvido muita coisa, tivemos muitas dores no caminho é isso nos tornou mais fortes. Contando essas histórias de guerrilhas para os amigos, esses nos pediram para contar mais e então passamos a palestrar. As palestras nos aproximaram de pessoas que queriam saber de como resolvemos nossos problemas e então passamos a oferecer-lhes consultorias e assessments. Veja, todo esse empirismo não quer dizer que não estudamos e não buscamos conhecimentos de fontes externas. Muito pelo contrário. Estamos buscando conhecimento a todo tempo, lendo livros, blogs, conversando com outras referências e participando ativamente de eventos. Nós mantemos em constante evolução e gostamos disso. Porém, somos desenvolvedores como a maioria de vocês (eu particularmente trabalho com iOS) e compreendemos os problemas que vocês passam pois passamos por eles também em algum ponto da estrada. O Agile que falo não é algo que simplesmente li num livro ou vi numa palestra, mas sim algo que vivi e vivo a todo tempo, é como solucionei os meus problemas e como sanamos nossas dores. Enfim, falar de agilidade é um enorme prazer, contar meus casos é algo que realmente me fascina. Ser pago para isso é melhor ainda.

O processo de assessment é relativamente simples. Vamos até a empresa, conversamos com pessoas chaves no processo, observamos algumas evidências é baseado no que vimos e ouvimos redigimos um relatório mostrando os principais pontos de alavancagem, aqueles que com o menor esforço geram o maior resultado. Isso é extremamente pessoal e depende da avaliação de cada agilista. Tento ser imparcial e para isso sempre busco um par que me complete nesse trabalho. Minha visão pessoal busca sempre aspectos culturais e de negócio, por isso preciso de alguém técnico para me ajudar. Esse meu par tem o trabalho de olhar para onde eu não olhei, fazer as perguntas que eu não fiz, olhar os aspectos que eu deixei passar. É belo ver que o mesmo princípio do pair programming são aplicáveis aqui também. Já escrevi algo sobre isso por aqui, recomendo a leitura.

Após essa avaliação inicial vamos até a empresa e de posse do relatório, explicamos ponto a ponto da nossa visão sobre o processo para os membros da equipe e discutimos as diferenças de visão. Expomos então um plano de ação que consideramos ser o mais interessante. Esse é um aspecto que julgo ser um dos mais legais. Normalmente, quem trabalha com consultoria já faz isso como parte do processo. Você não chega numa empresa e joga um modelo pronto. Você avalia os pontos em busca da onde se pode atuar. A diferença é que numa consultoria isso funciona como uma venda casada, você coloca essas horas dentro do seu trabalho de consultor e as vende num pacote só. Gosto mais de como fazemos porque se você se sentir capaz de implementar essas melhorias propostas vá em frente! Se sentir que precisa de ajuda com alguma delas estamos aqui de qualquer forma. Nem precisa nos contratar para ajudar em todas, somente para os aspectos que sentirem que precisam de apoio. Isso sai muito mais barato para o cliente e logo estamos livres para pegar um próximo projeto e aprender e ensinar mais em um novo contexto.

Você pode estar pensando nesse momento que serviços assim devem ser caros e contratar profissionais de uma empresa de consultoria pode ser um passo grande em direção à melhoria contínua portanto, podemos deixar para depois. A parte legal é que caso queira começar com um modelo mais simplificado e auto aplicável o meu amigo Klaus Wuestefeld escreveu um template chamado os 9 registros da agilidade. Nesse trabalho, disponível aqui, você encontra uma planilha para compartilhar com sua equipe e tem 9 aspectos que vocês devem dar notas entre 1 e 5, dependendo de como a equipe se avalia. É importante que se visualize o modelo como sendo um grande cano é que os nove registros estão ao longo desse cano. Com esse modelo em mente pode se ter certeza que a vazão desse cano se limita pelo registro que está mais fechado. Assim se em vários aspectos a sua nota for 4, mas em colaboração por exemplo a sua nota for 1, então a nota final do seu processo é 1. O seu sistema se limita pelo elo mais fraco e esse é o ponto de alavancagem, pois ele desobstrui o seu sistema para crescer.

Querendo conversar sobre avaliações de sua equipe ou querendo conhecer um pouco mais sobre os modelos da torneira, me procure que terei o maior prazer em explicar.