Rails Rumble: Uma lição de vida

Salve todos,

Não vou ficar falando o que sempre falo: que sumi, que não tive tempo pra postar por causa da correria da Giran e blalablablba! AHE uAHEuhaeuhAE … Estou estudando bastante e agora vou ter bastante coisa pra postar por aqui. :)

Este final de semana participei do Rails Rumble 2010. O Rails Rumble é, resumidamente, um campeonato de programação que desafia as pessoas a construirem uma aplicação em Rails em 48 horas! oO E não é qualquer aplicação, pois eles avaliam beleza, estabilidade, inovação … enfim, é como se você tivesse que fazer um Twitter (ou algo tão inovador) em 48 horas. heheheh

Participei do time Shupla Hadouken dá hadouken ryu! com os brothers recursos da Giran, Almir M3nd3s (@m3nd3s), André Gligli Tagliati (@tagliati) e nosso convidado especial (e que adestrou a gente em vários lances do Rails) Reinaldo JuniorZ (@reinaldojunior).

A Giran patrocinou nosso time e mais mais dois: o Walter Fall e o Blastoise. Provemos o espaço, comida, bebida e o que foi preciso pra deixar todo mundo a vontade.

Porque falei “resumidamente”? Porque o Rails Rumble é, no final das contas, MUITO mais que uma competição.

Preparação = motivação

O  “katá” para participar do evento foi/é uma puta motivação para quem quer entrar de vez no Rails. Durante um mês o povo da Giran estudou, discutiu, leu e codou bastante em Ruby/Rails. Ver todos se mobilizando em prol de um fim comum é algo que motiva demais até o mais preguiçoso dos programadores.

É fato e até algo psicológico isso: as pessoas se transformam quando estão em grupos e é assim que avaliamos o quanto as pessoas são realmente aquilo que elas dizem ser ou que achamos que elas são. Em todas as esferas possíveis.

Estudei muito (não tanto queria), quebrei a cara, me estressei mas foi algo decisivo para meu aprendizado Railer e do pessoal do meu time:  aprenderam bastante.

Idéia saindo do papel

A aplicação que desenvolvemos foi o Cashr, um gerenciador financeiro pessoal simples. Era uma idéia que já havia implementado no Django mas que não havia levado a frente. Preguiça, falta de tempo e entusiasmo: se já tem tantas aplicações pra quem mais uma?

Foi engraçado mas um dos meninos tinha tido A MESMA idéia. A vibe foi irada e geral. Qual não foi a satisfação e alegria em ver, depois de 48 horas de codação frenética e cansaço e muitas risadas, a aplicação rodando e fazendo MUITO MAIS do que havia imaginado fazer inicialmente.

Quem quiser dar uma sacada no projeto online: http://cashr.r10.railsrumble.com/

Tá dando uns pauzin e tem umas coisas incompletas, mas foi de coração. :)

Gestão de um projeto de 48 horas = desafio!

A largada havia sido dada, todo mundo à postos … e agora? Já tinhamos a idéia do projeto na cabeça e quase saímos meio Extreme Go Horse Development se não fosse a lucidez de fazer um mini Kanban das idéias principais. Mais que uma forma de organização foi uma puta lição de desenvolver de forma ágil, coisa que acredito ser um pre-requisito muito forte para qualquer pessoa que vá participar do Rails Rumble.

Entregar uma aplicação com a pressão de 48 horas, vontade de fazer o melhor e não fazer feio foi uma das lições mais legais que tive nessa esfera. E as pessoas à minha volta também pelo que vi.

Escopamos muita coisa para pouco tempo e braços, mas valew demais todo o esforço.

Extreme Happy Hour

Desde minha época de RPG, eu não tinha oportunidade de um happy hour nerd varando a madrugada tão divertido. Compramos pizzas, 2 Red Bulls pra cada um, refri, suco, biscoitos, Mendoratos … junte tudo isso com 12 nerds tarados em programação e lesados ao extremo e você tem a combinação perfeita para uma virada de madrugada de muito riso, programação e aprendizado.

Isso tudo com direito a Twittcam (você pode ver as gravações aqui), uma flood de twitadas durante a madrugada e tudo mais. O saldo foi cansaço mas aquele sentido de trabalho quase cumprido. IRADASSO.

Um por todos, todos por um

A mobilização das pessoas, até as que não estão acostumadas em trabalhar num time Scrum ou de qualquer metodologia ágil, é impressionante. As pessoas realmente entendem o quanto seu trabalho influencia o resultado não apenas do projeto mas do que o seu colega ao lado fez.

Foi como um XP atômico: pessoas codando frenéticamente, fazendo refactoring, criticando código, complementando o código alheio. Foi sem dúvida uma experiência única no que entendo ter sido uma das mais rápidas e emblemáticas que participei e vi.

Convidamos três pessoas: além do Reinaldo Júnior, chamamos o mestre railer Roberto Soares (@bt1) e o grande André Lima (@vixlima). Muito bacana como os três se integraram aos times e principalmente fizeram a gente perceber mais uma vez como as coisas trabalham bem quando as pessoas já tem um background ágil em suas mentes. Simplesmente fantástico. :)

Eu quero, eu posso

Uma palavra que ficou na minha cabeça desde horas antes de um desafio tão tenso, que expõe demais as pessoas no sentido técnico e psicológico (é a hora das pessoas verem até onde vai seu conhecimento e até onde você é humilde o bastante pra assumir isso ou ensinar as pessoas sem mesquinharias): superação.

Codar por 48 horas (não exatamente, mas pensar nisso por mais até que isso) não é apenas uma auto-superação física ou de stress mental. É superar o medo de não conseguir entregar a tempo, de saber que existem limites seus, de respeitar os limites dos outros de verdade. Superar a constante de que não sabemos tudo o que gostaríamos ou o quanto gostaríamos.

Não é papo de auto-ajuda: o Rails Rumble me fez sim uma pessoa melhor.

Extreme learning

Já falei tanto extreme nesse post que virou buzz. Não é a toa que dizem que uma das melhores formas de aprender Rails é participar do Rails Rumble. Muito aprendizado, muito problema real acontecendo em espaço de minutos e soluções para isso surgindo no vácuo.

Várias pessoas dos times não tinham muita experiência e chegaram no final da maratona falando e demonstrando o que aprenderam de uma forma muito coesa. Impressionante como as pessoas absorvem (e não apenas deixam na cabeça por um tempo) os aprendizados em situações de pressão e decisões que influenciam a vida das outras pessoas.

E no capítulo de hoje eu aprendi …

Nesse exato momento nossa aplicação está sendo avaliada pelos juízes e já recebemos até uma nota legal. :) O que fica aqui pra frente é que os estudos continuam e a coleta de idéias para o ano que vem já começou. SIM! VOU FAZER ESSA DOIDERA DENOVO NO ANO QUE VEM!

Para quem não fez, corra: é uma experiência tão singular quando a primeira balada, a primeira bebedeira (com a ressaca) e o que quer que seja tão significante.

Para quem gostou do Cashr, vamos continuar com o desenvolvimento dele e aceitamos colaboradores para o projeto, principalmente um designer pois tivemos que nos virar haehahe aueuah e.

Simbora! :D

#AgileBrazil 2010: Eu fui … e foi foda!

Salve pessoal,

Resumir num post apenas o impacto de um evento da importância do AgileBrazil 2010 na vida de um desenvolvedor/gestor é complexo mas vou tentar dar apenas uma pequena e humilde visão do que foi isso.

Remontando alguns fatos, a Giran hoje trabalha muito fortemente com metodologias ágeis (Scrum/XP) a mais de um ano: ou seja, desde que montamos ela. heheh Mas é com o passar dos dias, projetos, pessoas, dificuldades e experimentos é que se consegue ter as reais motivações da definição dos valores do Manifesto Ágil e das técnicas usadas para se manter uma empresa ágil…

Mas ser ágil é o quê? Implementar o Scrum, seguir tudo que o manifesto ágil prediz, fazer religiosamente todas as fases antes e durante uma sprint: não quebrar as regras que agilistas e metodologias dizem? Ou seja, respeitar o processo do início ao fim? Você se mantém assim porque sua empresa é realmente ágil ou tornou sua empresa “ágil” apenas para dar um nome mais bonito ou mais hype pro seu “processo” batido do dia-a-dia com incrementos pra tentar levantar o moral da equipe e/ou vender sua empresa como uma empresa “inovadora” ou “jovem”?

É exatamente em eventos como o AgileBrazil que a percepção em relação à isso se torna EXTRAMAMENTE palpável, visível e de um bom senso tão argumentado e lapidado que chega a ser engraçado como as pessoas e as vezes nós mesmos não conseguimos enxergar algo que está na frente do nosso nariz.

A tônica do evento foi uma: você é realmente ágil? Está nessa pela fama | grana | hype ou qualquer coisa que realmente possa fomentar algo positivo pra sua empresa? Bote a mão no coração e pergunte pra si mesmo: porque você quer ser ágil ou se acha ágil?

As flexões mentais em relação à isso foram levadas a cabo por vários dias (no meu caso por dois) e horas, ensinados, desmontados, analisados e remontados por vários e principais nomes do movimento ágil do brasil e no mundo! Sim, O Martin Fowler em pessoa abriu o início das palestras e jogou luz onde geralmente ninguém vê (ou não gosta de ver).

Com uma estrutura de tirar o chapéu, feito na PUC com uma puta estrutura, uma bolsa com caneta, bloco e até caneca, a organização foi impecável em todos os sentidos possíveis. E o networking … essa parte foi um show a parte. Como disse pros brothers da Bluesoft, é muito foda ver as pessoas fora dos quadradinhos do Twitter e ver que elas são muito mais bacanas ao vivo.

Como eram muitas palestras, eu e meus companheiros na expedição (@jeveaux o @makoto_vix) nos separamos para cobrir o máximo de assuntos. Descrever tudo o que conseguimos absorver nesses dois dias ainda está cedo e talvez vire até post mas resumidamente vi:

  • Gente usando BDD/TDD pra substituir boa parte da documentação da descrição de requisitos (coisas que o cliente quer)
  • Como otimizar bastante do processo de TDD e torna-lo mais suave
  • Como ir além no uso do kanban
  • Integrar GTD + Pomodoro + Scrum + Platão (sim, rolou até platão)
  • Nomes de vários livros e sites FODARASSOS
  • Monstros da agilidade andando ali do lado
  • Porque a Giran é ágil …
  • E porque eu quero continuar com ela SEMPRE ágil :)

Se teve partes ruins? A única parte ruim é a saudade de casa, o café que acabou MUITO rápido nos coffee breaks e o cansaço nos aeroportos. Do resto, tudo muito foda. :D

E o que senti de verdade: é MUITO bom estar entre gigantes da agilidade e reconhecer que tenho (temos) que crescer, estudar e amadurecer muito e sempre. E ainda bem que existem eventos como esse pra irmos todo ano e continuar cada vez mais humildes, felizes … e ágeis.

\\// Vida longa e próspera a todos.

Valorize pessoas, não processos

Já dizia o Manifesto Ágil (e continua dizendo) como um mantra …

Indivíduos e interação entre eles mais que processos e ferramentas

Mas até que ponto nós, não apenas como desenvolvedores mas como pessoas, levamos à cabo como agilistas ou simpatizantes de metodologias ágeis esse princípio? Mais que isso: até que ponto temos consciência de quanto esse princípio rege não apenas processos mas todo o entorno e mais dramaticamente TUDO num projeto quando pensamos que TUDO é usado, avaliado e aprovado por outras PESSOAS.

MUITO MAIS que resultantes de desempenho, produtos de qualidade e projetos mais humanamente sustentáveis, esse princípio trabalha muito intimamente com o sucesso de uma empresa, marca e seus serviços.

Dúvida?

Meu problema com travas elétricas

Quem me conhece, ouvia muito falar uma frase quando pegavam carona comigo (um carro 4 portas) e viam que as travas estava todas manuais: “Vou levar meu carro amanhã pra consertar…“.

O problema não era inteiramente meu: apesar de ser um cara enrolado, existe um processo chamado “Agendamento” da concessionária que:

  • limitava-me a levar o carro bem cedo com um dia pré-agendado
  • me fazia deixar o carro lá e conhecer, em tese, o problema real na parte da tarde e com a possibilidade de pega-lo apenas no outro dia
  • me fazia voltar pro trabalho e sair dele pra pegar o carro de busão

Apesar de tudo, o processo funcionava bem dentro de um certo contexto, pois não precisava enfrentar fila de atendimento, com sorte eles lavariam meu carro (de grátis), seria feito por profissionais (recurso ou indíviduo?) treinados pra mexer com o meu carro e existia um prazo médio (embora pouco confiável) que poderia sair com o carro consertado no mesmo dia.

Os processos são muito importantes, principalmente em empresas de maior porte onde o padrão de qualidade do produto/serviço depende bastante de um fluxo de ações e validações que certifiquem que as coisas vão funcionar bem sempre e de um modo controlado. Em pequenas empresas e pequenos grupos de trabalho, um processo pode ser substituído em partes (ou até totalmente) por indivíduos e interações.

MESMO nas grandes empresas, ainda sim, os indivíduos e interações podem fazer uma extrema diferença na qualidade: afinal, todo processo é suscetível à inconsistências e nesse ponto o indivíduo, com sua experiência e todo tipo de qualidade pessoal, vai fazer diferença.

Então qual o problema/diferencial no processo? São os indivíduos.

Indivíduo #fail: o atendente/consultor (ou quem está na frente)

Liguei para a concessionária e fui atendido por um indivíduo que atendeu-me prontamente, mas com uma certa impessoalidade incômoda, e agendara meu atendimento para as 8:30 de um dia naquela semana. O dia chegou e o alívio/sossego/esperança de não ter que sofrer mais piadas como “[tom irônico] Amanhã né Hackin?” era tão latente que o dinheiro a ser investido na resolução do problema, naquele momento, era o de menos (não, eu não sou rico … quem pode falar coisas sobre ricos é meu amigo @makoto_vix).

Cheguei para o atendimento e o indivíduo atendente me chamou pelo horário, pelo “quem chegou primeiro?” e só depois pelo nome. A contar que não era o único ali, isso passaria batido pelo meu autruísmo exagerado se não fosse pelo tratamento recheado de “Uhun”s, de “Sei”s e sem uma resposta muito convincente ou entendível ao meu “Bom dia!” recheado de dentes: aquele estava sendo um bom dia pra mim, será que pra ele não? Seja lá qual o problema, estava diante de um indivíduo totalmente guiado pelo processo.

Um indivíduo guiado pelo processo é como estar em piloto automático: não importa o que você seja, ele esta ali apenas para dar fluxo ao processo. A dispêndio de energia e atenção se limita apenas ao que é necessário para concluir o processo. Talvez quem você é po$$a significar algo e otimizar um pouco as coisas.

O indivíduo atendente então me passou o número de meu atendimento e pediu-me para que ligasse por volta das 15:00 para saber do meu problema. Será mais econômico ao processo eu ligar para saber sobre meu carro ao invés do indivíduo? Liguei e fui informado que parte do serviço tinha sido feito (tinha pedido também pra alinhar e balancear) e que o problema das travas estava sendo concluído: eu poderia pegar o carro ao final da tarde. A esperança do produto em mãos me fez deixar pra lá uma interação linear e sem contato humano com este indivíduo.

Às 18:25 chegava na concessionária e recebo a notícia de meu indivíduo atendente que o alinhamento do meu carro não tinha sido feito e que não tinham ainda descoberto o problema real das minhas travas: de acordo com indivíduo atendente, o indivíduo técnico estava com a caixa de fusiveis e tudo mais aberto lá. Como o horário de fechamento era às 18:45, apesar de muito chateado – quase puto – resolvi esperar dizendo que precisava do carro e se talvez rolasse dele descobrir algo nesses 20 min: recebi um “talvez, mas eu acho difícil…”.

5 mins depois o indivíduo atendente me informa que o problema poderia ser que as 4 travas elétricas tinham queimado simultaneamente devido a algum curto e que o valor do conserto seria de R$ 1.000,00. Questionei como 4 travas poderiam queimar ao mesmo tempo e a resposta foi um “Eu também achei bem estranho e se quiser posso conferir com o responsável pela oficina amanhã“. Amanhã? Levei o carro sem consertar as travas e voltei para fazer o alinhamento (e perder mais tempo) dois dias depois. Estranhamente uma indivíduo atendente me ligou perguntando porque não havia levado: porque não haviam me ligado assim no mesmo dia para falar sobre meu carro ao invés de me fazerem ir até lá?

A história é meio grande propositalmente para apontar bem os detalhes do atendimento. Podemos detectar alguns problemas propiciados não pelo processo, que possivelmente não tinha problemas salvo algumas melhorias, mas pelo indivíduo que disparou as ações do processo:

  • o tratamento impessoal causou um efeito anti “Efeito UAU! de atendimento” (sou programador, mas aprendi com grandes pessoas grandes coisas – valew Márcio Gomes! – que me fizeram uma pessoa e profissional melhores): não me surpreendeu, nem encantou e isso ajudaria bastante à experiência de uso num todo. Mesmo com um resultado abaixo do esperado ou sem nenhum resultado, minha experiência de uso teria sido boa se a empatia do indivíduo envolvido diretamente em minha interação tivesse sido melhor
  • as pessoas são guiadas muito mais pela sua experiência de uso do que as vezes pelo preço: 1k poderia ser um valor justo por um serviço “especializado” se minha experiência de uso estivesse sendo boa. A insatisfação inicial gerou enfim o questionamento sobre o valor e a vontade de “pexinxar”. Quem nunca parou e comprou algo na primeira loja apenas porque o indivíduo envolvido no processo era tão bom que lhe fez sentir-se seguro com a compra.
  • o indivíduo comprometeu a confiabilidade do processo quando
    • me relatou que meu carro tinha apenas o problema das travas para resolver quando nem o alinhamento havia sido feito
    • demorou 5 mins orçar e relatar um problema que em tese não tinha sido feito nem descoberto por todo um dia mas por “mágica” foi feito em 5 min
  • o indivíduo se aproveitou dos gatilhos e ações do processo para conclui-lo mas de forma a startar apenas mais um processo para quem é dependente dele.

Então, do que adianta investir num processo bem feito se os indivíduos envolvidos na sua execução não estão “comprometidos”?

Várias empresas da área de tecnologia e desenvolvimento ainda acreditam que investir em processos seja melhor para a empresa do que investir nos indivíduos que executam esses processos. Você como empresário ou como desenvolvedor ainda acredita nisso? Tente imaginar algumas situações como:

  • Quanto do seu processo de relacionamento é otimizado pelo indivíduo que se relaciona diretamente com seu cliente, tanto na questão de prazos e requisitos quanto em tudo o que envolve o que não é diretamente relacionado ao processo mas tem TUDO para tornar a conclusão ou qualidade dele excelentes?
  • Quantas descisões são influenciadas pela empatia dos indivíduos envolvidos no processo?
  • Quanto da qualidade final do seu produto é impactado diretamente pelo indivíduo, devido às suas idéias mais que suas certificações?
  • Qual é seu melhor quantitativo de desempenho: um processo que segue seu fluxo de forma correta ou os feedbacks positivos de seus clientes em todas as esferas possíveis?
  • Como você garante que todas as etapas/ações de seu projeto estão gerando o máximo de retorno para o seu cliente? Ligações pós-atendimento de avaliação não conseguem desfazer o pior dos estragos que é a experiência de compra abaixo do UAU! ou até mesmo abaixo do mínimo aceitável para cada cliente.

Imagine-se como um cliente e todas as situações como essas que passei e pergunte-se de forma analítica, pessoal e envolvendo o que você avalia como importante num atendimento:

Na minha empresa o que me traz diferencial são os indivíduos ou meus processos?

Indivíduo #WIN: numa oficina de 5 indivíduos funcionários

Como sou brasileiro e não desisto nunca, aproveitei o feriado para procurar uma oficina. Numa cidade ao lado encontrei uma oficina com 5 indivíduos funcionários, entre eles o indivíduo dono.

Prestativo, um indivíduo funcionário me recepcionou de forma informal mas muito pessoal, perguntando como estava o dia e como poderia me ajudar. Expliquei meu problema e ele de pronto afirmou que quando uma trava parava todas paravam e poderia ser um problema no módulo. Pediu-me 10 min para que um outro indivíduo, que “mexia melhor que ele” com travas, pudesse me atender.

Esperei por 25 mins, mas com 2 ou 3 interações dos indivíduos da oficina me dizendo que não demoraria muito. O processo até aquele momento me parecia simplista e até intuitivo, mas a interação do indivíduo me trouxe uma calma do tipo “Sem problema, vou aproveitar pra ler um livro“. Findada a espera, José me deu bom dia de uma forma humilde e pessoal, abriu o painel onde ficava o módulo, mexeu pra um lado e pro outro vários fios e em 15 min ele me disse: “Deve ter rolado um curto circuito, pois a corrente chega aqui – me apontando a porta – mas as travas não funcionam. Vamos ter que trocar as 4 travas.”.

Minha experiência de uso estava sendo muito bacana, mas lembrar dos R$ 1.000,00 me deram um amargo na boca até que ele disse “O jogo de travas e o serviço fica por R$ 280,00 e você pode pegar no final do dia“. WOW!!!!!

Pára tudo …

  • Atendimento UAU!
  • Preço UAU!!
  • Prazo UAU!!!!!!

Assenti prontamente mas às 18:00, chegando com pontualidade inglesa por sorte, meu carro ainda estava faltando a ultima trava da porta. Durante os testes, um dos indivíduos dissera que o pino da porta da esquerda estava meio enpenada e a porta não tava fechando direito mas que já tinha ACERTADO ela para mim e agora estava “filet”. 40 mins depois do horário dos indivíduos e meu carro estava pronto, com teste geral de lanternas, vidros e tudo mais. Um “Boa noite” cheio de cansaço mas sincero até a ultima vogal.

O processo estava ali escancarado no final das contas:

  • Receber o cliente
  • Verificar o problema
  • Passar orçamento e prazo
  • Executar o serviço

Algo muito próximo e parecido com o da concessionária, mas o que fez a diferença COMPLETAMENTE foram os indivíduos… o José mereceu os R$ 15,00 da gorjeta pra tomar umas na sexta a noite e a oficina minha moral eterna pela ótima experiência de uso que acabara de ter.

  • o indivíduo proporcionou qualidade a um processo que prevê ações definidas mas que cobre apenas em parte a real experiência de uso de um usuário
  • o indivíduo, mais que o processo, é quem de verdade proporcionou a validação positiva do processo
  • processos são inflexíveis, lineares e o que se poderia ter de “inteligência de decisão” são nada mais que algoritmos que não se comparam à empatia e tato que um indivíduo pode ter no momento de uma venda
  • um processo não reconhece um sorriso como um feedback válido para alteração de um fluxo
  • processos podem burlar indivíduos, indivíduos podem ser burlados pros processos, mas é bem mais difícil um indivíduo burlar outro indivíduo (as vezes hahaha)

Construindo uma marca com indivíduos

Depois de tudo isso, podemos ter uma noção melhor do quanto o indivíduo pesa muito mais numa empresa que um processo. Empresas grandes e flácidas tem um grande problema quando trabalham com zilhões de funcionários e não conseguem detectar de forma enfática e hábil quando esses indivíduos fazem perder todo o processo ou pior: não conseguem enxergar quando esses indivíduos é que fazem toda a diferença no atendimento.

Podemos citar aquele garçom que você sempre procura no bar, aquele mecânico que você conhece pelo nome e não pela oficina em que ele trabalha… os indivíduos são nossa referência nos lugares em que vamos e mantemos um link de confiança e segurança. Quando temos pontos qualitativos sob a forma de indivíduos exemplares em nossas empresas, nossa empresa se torna mais pessoal, mais próxima de quem faz nossa empresa crescer: os usuários.

Agora, se a sua empresa é ainda pequena ou seu centro de produção ainda é restrito a um grupo menor, porque você ainda valoriza mais processos do que indivíduos?

É incrível como varios empresários ainda acreditam que os indivíduos são todos substituíveis, como porcentagens num planilha ou recursos no gráticos Gantt, e que os processos da empresa são o suficiente para a empresa continuar saudável … mas será que estabilidade é sinônimo de sucesso ou apenas de “acomodação”. Empresas não quantificam de forma efetiva o quanto de capital social e humano perdem quando deixam de aumentar um salário em R$ 100,00 ou proporcionar um ambiente de trabalho bacana para um indivíduo que pode representar a qualidade que seu processo tenta emular ou manter de forma artificial e não tão efetiva.

Exemplo clássico é a Giran, empresa em que trabalho e que me serve de inspiração para muito do que sempre pensei com meu sócio Jeveaux.

A Giran é construída pelas pessoas que a compõem: idéias, confabulações, inovações, melhorias de gestão, contratações e até o café que tomamos é uma decisão tomada pelos INDIVÍDUOS que temos em nosso time. Nada escapa ao julgamento das pessoas e nossos processos é quem acabam trabalhando a favor dos indivíduos e felizmente não o contrário.

O que a empresa é hoje lá fora é o reflexo do comprometimento e profissionalismo das pessoas que estão lá dentro. A “marca” Giran não é fruto de um processo admirado por todos: as pessoas admiram uma marca pelo que ela proporciona à elas. Em nosso caso, as pessoas sempre nos elogiam pela nossa abordagem, às coisas e problemas que estão à nossa volta de forma transparente, sincera e fluída. E quem faz isso são nossos indivíduos. :)

Indivíduos, Indivíduos …

Depois dessa Bíblia, a flexão mental sobre o quão importante um indivíduo é antes do processo tomou um bom rumo, mas longe de chegar ao tremendo brainstorm que isso pode se tornar dentro de sua empresa, entre seu time ou mesmo com parceiros, sócios e quem mais seja importante.

Alguns funcionários, pessoas ou “recursos” não tem a real noção do que eles são dentro de um organismo tão complexo quanto a experiência de uso que deve ser proporcionada às pessoas que se relacionam com ela.

  • um e-mail áspero de um programador, pode gerar um sentimento nada bacana com um cliente na frente
  • o modo como seus funcionários se comunicam com seus fornecedores e cliente pode estar gerando maus sentimentos
  • um “Bom dia … tudo certo” e um  “Abraço” no final de um e-mail pode fazer a diferença (para melhor ou pior)

Agora imaginou o quanto você, do outro lado da moeda, já passou por isso e sabe (sinceramente) o quanto isso fez a diferença?

Pense nisso. :)

Programação em par … 1+1=3

1+1=3

Aloha! O cálculo parece ser uma piada, mas na prática é o que este pequeno post vai tentar explanar e pontuar: programação em par rende e faz bem ao projeto, seja você uma equipe ágil ou não.

Programação em par (pair programming) é uma das práticas pregadas pela XP (eXtreme Programming) e metodologias ágeis em geral. Pra lá de polêmica (principalmente entre os gerentes de projeto e de “recursos”) a programação em par é o terror das empresas com poucas pessoas e/ou projetos com escopos malucos e sem vivência ágil, mas é exatamente ai que ela pode ser tornar uma puta aliada ao time, à empresa e aos projetos.

Como o próprio nome já diz, a programação em par descreve a prática de desenvolver software em par no mesmo computador: enquanto um programa o outro fica de “papagaio de pirata”, apontando erros, sugerindo coisas e pentelhando o amigo que está desenvolvendo. Elas se revezam no teclado de tempos em tempos e os objetivos disso são muitos.

Um segura, o outro bate

Esse é meu bródi!

João e Joca prontos!

Na vida real isso seria uma covardia, mas estratégicamente falando o fato é que se você entra numa briga com um amigo (principalmente que já chega na voadora) tudo fica MUITO mais fácil: você intimida o inimigo, aumenta a auto-confiança e a chance de ganhar a batalha de forma muito mais rapida e efetiva aumenta dramaticamente.

Num projeto isso soa da mesma maneira: a troca de experiências, fundamentos e principalmente sinergia de aptidões e especialidades eleva o nível de programação. O programador menos experiente ganha experiência e macetes. O programador mais experiente, refina seu conhecimento, encara novas possibilidades apresentadas pelo mais novo e lapida de forma fina conceitos da forma mais didática possível. :)

Então, existem vários pontos e consequências muito positivas quando você, gestor, e você , desenvolvedor “super-homem” e “lobo solitário”, programa em par:

  • a troca de conhecimentos fica transparente entre o par e o modo mais bacana de implementar aquele regra de negócio que “só o João é que sabia”  agora é sabida pelo Pedro, Joca e José;
  • a abdução pelo MSN/Talk/Twitter (ou as coisas que distraem) será bem menor devido à presença do par ao lado pensando “Coé! Vai trabalhar ou não p*rra?”
  • essa é pros gestores não ágeis: programação não é apenas digitação (= trabalho mecanizado) e sim um trabalho de escolha (tentativas corretas ou erradas). E nisso duas pessoas se saem BEM melhor (seja a caminho do #epicwin ou #epicfail).
  • o vínculo pessoal aumenta entre o par e com isso a confiança se fortalece, acabando ou diminuindo o “se fosse eu teria saido melhor”
  • com a confiança aumentada, o par passa a se comprometer ainda mais com o resultado final de forma muito natural, afinal a pessoa não quer deixar seu novo amigo na mão (e nem a oportunidade de fofocar um pouco durante o pareamento)
  • as soluções encontradas tendem a serem melhores documentadas/implementadas
  • psicologicamente, o par sempre vai querer mostrar “o seu melhor” para o outro
  • quando o par não souber resolver nada ele não vai conseguir passar O DIA INTEIRO abrindo e fechando a mesma tela enquanto pensa numa solução: o parceiro geralmente ou auxilia ou no mínimo vira mais um na pesquisa pela solução correta.
  • as barreiras pessoais caem e as pseudo-picuinhas ou viram picuinhas de verdade ou viram uma grande piada entre o par (e com sorte o time) depois de algum tempo
  • é uma das melhores formas que vi até hoje de fazer as pessoas entenderem o que é trabalhar em grupo
  • e por aí vai… :)

Mas eu não tenho time, eu tenho recursos

Muitos amigos/parceiros de outras empresas sempre perguntam pra mim e o pro povo aqui da Giran como trabalhamos porque eles mesmos já tentaram, tentam ou tem curiosidade de implementar metodologias ágeis em seus ambientes de trabalho. Geralmente o que me falam é que lá as pessoas são tratadas como recursos e não como um time.

Num dado momento as pessoas tem suas 8 horas/dia (hellllooow! aumenta isso ai tio!) de trabalho e isso no M$ Project fica lindo: afinal, podemos colocar o Joca alocado 70% do seu dia numa tarefa e 10% em outra e mais 20% numa outra completamente distinta. Ou melhor: podemos fazer o João entregar em 2d 4horas aquele módulo de detecção de XSS NO SITE INTEIRO.

Parte do problema que tento passar pros meus amigos é que as pessoas da empresa não são engrenagens mas sim pessoas, com seus problemas pessoais, limitações técnicas, dias ruins (que não rendem nada) e que nem deveriam ter começado. A partir do momento que os recursos não são considerados como produtores de porcentagens em planilhas mas sim pessoas que implementam escolhas e entregam produtos (resultado dessas esperadas BOAS escolhas), uma parte grande do problema se desfaz e o mundo fica até mais claro. :)

Mas, mesmo enquanto “recursos” (afinal, seu chefe não quer que os cronogramas os enxerguem de forma tão humana porque isso é perder dinheiro), ainda sim a programação em par se apresenta como uma ótima alternativa para driblar algumas limitações impostas pelo modelo manufatureiro (e antiquado) de produzir software:

  • você pode botar um recurso que está produzindo pouco para parear com outro mais “ativo” (ui ui ui) ou com mais moral da equipe interna: o recurso que está “patetando” vai se ligar rapidin e começar a “magicamente” trabalhar mais seja pela pressão do par, seja pelo poder de liderança que esse par vai ter sobre ele (as vezes o cara considera o amigo mais chefe do que você que em tese deveria ter esse poder)
  • liderar é servir: essa dica acima é muito importante quando você desejar criar um líder natural de equipe que faça as peças funcionarem sob alta temperatura sem rangir ou quebrar
  • faça seus recursos parearem ao menos no início de um novo projeto: assim, o alicerce ficará bem conhecido e a tendência do João levantar uma parede de gesso onde o José deveria colocar o quadro ultra-pesado diminui bastante. “Mas você não me falou que tipo de parede era e eu achei que essa iria dar conta do recado… p*rra, você nem pra me dizer que o quadro era tão pesado né?” (sinto cheiro de re-trabalho)
  • fazer par com aquele programador/designer/pessoa-difícil que todo mundo fala que faz tal coisa errada, mal-feita ou que poderia ser melhor vai ser uma maneira muito efetiva de faze-lo começar a trabalhar direito a partir de então
  • juntar dois recursos-difíceis assim pode ser uma ótima oportunidade de fazê-los melhorar em conjunto ou você matar dois coelhos com uma caixa d’água só

Passos de bebê para a programação em par

Bacana, legal! Mas tem gente que vai se perguntar: “Putz! Mas como transformar 8 pessoas em 4 da noite pro dia”. Tem muita gente doida (acho que essa é a palavra) que acha que radicalizar da noite pro dia vai adiantar ou ajudar em algo. Em se falando de programação em par então, isso fica ainda mais frenético. Na Giran mesmo ainda adaptamos continuamente nossa forma de trabalho com SCRUM/XP com idéias vindas do time, de coisas que lemos por ai e que descobrimos durante o dia-a-dia de trabalho. A programação em par foi uma dela e que nos deixa hoje muito contentes em levar à cabo.

Então, gostaria de compartilhar algumas dicas que podem ajudar você a fazer seu time ou seus N recursos a trampar em par e trazer um retorno de produção bacana num curto espaço de tempo, bem como você descobrir que isso NUNCA vai dar certo na estrutura da sua empresa (isso também num curto espaço de tempo):

  • faça pares com um iniciante e um mais experiente para que os conhecimentos trocados seja mais efetivos;
  • num escopo de uma semana, faça as pessoas parearem ao menos uma vez por dia por projeto;
  • se você trabalha com tarefas de um dia, faça as pessoas parearem em ao menos duas delas por semana;
  • um ótimo recurso para temporizar um pareamento é faze-lo em Pomodoros, que são boxes de tempo de 25 min (1 pomodoro = 25 min) em que as pessoas tem que manter o foco. 2 pomodoros são uma ótima pedida para começar um pareamento;
  • pareie pessoas com rendimento baixo com pessoas de rendimento maior (independente do nível técnico) para dar um choque de realidade neles;

Para começar isso já deve dar um pouco de “trabalho” para você, gestor ou líder na equipe, implementar isso de uma forma bacana. Uma forma legal de ajudar nisso, e em vários outros pontos, é você praticar reuniões rápidas matinais de 10 minutos em pé (prática conhecida na XP como Stand-up Meeting) para revisar o que foi feito no dia anterior: nesse ponto você vai identificar até que ponto os pares não apenas trabalharam juntos mas também fomentaram novas idéias e alternativas.

Por enquanto é só pe-pe-pessoal! Boas programações em pares e lembrem-se: programar não é apenas digitar. :)

Maré de Agilidade em VIX

<pseudo-sufista>
A vibe nerd vai ficar frenética em VIX em Maio. A Faesa vai ficar crowdeada de brothers e ninguem vai mandar o kaô.  :) Por isso eu vou mandar a pala, tá ligado?
</pseudo-surfista>

Acontece no próximo 29 de maio (um sabadão) na FAESA (Av.Vitória) o primeiro Maré de Agilidade em Vitória, carinhosamente chamado de Maré Vix. O evento vem uma semana depois do evento que rolará em BH no dia 22 de maio.

O Maré de Agilidade, que está chegando à sua sexta edição, é um evento itinerante que tem como objetivo disseminar as metodologias ágeis em todo o Brasil. Além do conhecimento, é claro que rolará muito networking entre desenvolvedores e gestores de projetos, negócios sendo fechados, muito café rolando e claro aqueeeeeeeele clima de evento de comunidade que todo mundo conhece. #win

Parafraseando meu brother-sócio-irmão Paulo Jeveaux, “O Maré Vix contará com uma programação bastante recheada e enriquecedora: teremos um dia inteiro com muitas palestras e uma mesa redonda com todos os palestrantes ao final do evento. Dentre os nomes confirmados para o evento, temos: Guilherme Silveira, com a palestra Um produto em duas semanas, Guilherme Chapiewski, Denis Ferrari sobre Domain-Driven Design, Fabrício Vargas Matosfalará sobre TDD e Jeveaux, sobre Negociação de contratos.“.

O evento contará com vários patrocinadores e apoiadores. Entre eles, com muito orgulho estará a Giran. :) #epicwinever

Para quem quiser ver mais detalhes do evento e coisas do tipo, visite o site do evento: www.mare-vix.com.