Motivação e Agilidade à la Ratatouille

29 Setembro, 2008 by Daniel Witaro

O que um diretor ganhador do Oscar e um dos melhores chefs de cozinha dos EUA podem dizer a um desenvolvedor de software sobre motivação? Tudo começou quando, explorando os extras de Ratatouille (ótimo filme), vi uma entrevista com o escritor e diretor do filme, Brad Bird (assim como de “Os incríveis”) e o Chef Thomas Keller (que faz ponta dublando). A entrevista ocorre de forma paralela e ambos falam sobre seus trabalhos e como conseguem ótimos filmes (Bird) e pratos (Keller). Acabam mostrando como faz diferença amar aquilo que se faz, além de como envolver/compartilhar isso com uma equipe.

Fiz um resumo informal do que dizem em um mapa mental: Ingredientes para Motivação no Trabalho (se preferir ver como imagem clique aqui). Durante a elaboração do resumo tentei identificar os “ingredientes” chaves envolvidos em suas opiniões e relatos na forma como trabalham. Depois fiquei refletindo sobre tais “ingredientes” numa equipe de desenvolvimento. Creio que muitas equipes ágeis falham ou desandam por não se preocupar o suficiente com tais itens, muitas vezes subestimados e visto como óbvios, talvez por serem banalizados por todo um mercado de consultoria. Contudo, são bastante difíceis de se praticar e se manter na maioria dos ambientes de trabalho. Seria possível escrever livros sobre cada um (e de fato existem), mas vou tentar ser breve e menos óbvio.

Conexão/Prazer: Sentir prazer por uma atividade deve ser a forma mais proveitosa de se conectar a mesma. Imagine a enorme paciência e persistência dedicados a um jogo de videogame para uma idéia do que falo. Conseguir sentir prazer em fazer algo para alguém pode ser ainda mais poderoso. Seria como sentir-se conectado aos outros por meio de um trabalho ao qual está conectado. Mais que prazer, é a oportunidade de dar significado e propósito ao que se faz. Parece ser comum encontrar pessoas que dizem não gostarem do que fazem, mas ao meu ver muitas estão apenas indiferentes devido a problemas de percepção e contato. Por exemplo, imaginemos o caso de um desenvolvedor que pouco se esforça no que diz respeito a usabilidade recebendo visitas de usuários finais reclamando de dores em articulações devido a necessidade de usar muitas vezes o mouse em tarefas repetitivas que poderiam ser melhor feitas usando o teclado. Nesse momento, ele pode perceber que o que faz impacta no bem-estar dessas pessoas ao influenciar suas saúde e eficiência. Os resultados do empenho do desenvolvedor agora possuem destino, rostos e sentimentos reais. Se o desenvolvedor se importa com os usuários/clientes, acabará valorizando comunicação e feedback. É mais uma razão para a aproximação entre clientes e desenvolvedores. Infelizmente, me parece que para a maioria de nós é mais fácil entender razões que emoções. Pode parecer bobagem, mas mesmo nas tarefas mais técnicas o envolvimento emocional pode fazer diferença, por exemplo, agindo de forma apaixonada em relação ao código. E se algo no trabalho lhe frustra ou chateia, é preciso lidar com tais fontes de “desprazer” como alvos a serem resolvidos também, resolvê-los de forma criativa, como por exemplo, automatizando tarefas repetitivas (vide testes automáticos). É outra forma de entender a frase, “trabalhar para viver”.

Criação/Expressão: Espaço para criatividade e expressão pessoal. Algo de arte e liberdade. Não consigo imaginar alguém motivado em um trabalho onde só faz o que mandam e/ou repete os mesmos procedimentos eternamente. Processos burocráticos que oneram e tentam prevenir qualquer mudança também não ajudam. Fora que não dá para ser plenamente criativo em um ambiente que tenta forçar você a ser igual a todos, que não respeita sua personalidade e talento. Além disso, há outro tipo de espaço necessário para a inovação: Espaço de tempo. As pessoas precisam de tempo para refletirem sobre como estão fazendo as coisas, ao invés de simplesmente fazerem. Precisam de tempo livre para explorações de novidades e realizações de experiências que podem beneficiar enormemente o trabalho. Tempo para manterem-se conectadas ao que ocorre no mundo, mais que motivador, isso é essencial para a área de tecnologia.

Colaboração/Confiança: Em um verdadeiro trabalho em equipe teremos “co-criação”. É difícil ficar motivado quando um pequeno grupo isolado (às vezes de uma só pessoa) define e modela soluções/regras sem sequer ouvir sua opinião. Como pode haver comprometimento sem envolvimento? Principalmente numa área que envolve conhecimento é muito importante incentivar o livre pensar, a delegação de tarefas, enfim, permitir que as pessoas tomem decisões e aprendam com seus erros e acertos. Claro que para isso será necessário confiar nelas. Os reais benefícios de um trabalho em equipe só surgem quando há confiança entre seus membros, de outro modo pode-se ter muita gordura (”burrocracia”) e conflitos desnecessários. Além do mais, essa confiança mútua pode ter reflexos internos ao estimular a auto-confiança dos indivíduos. Quando as pessoas confiam em si e nos outros há mais troca de experiências e surge uma sinergia na equipe, tornando a mesma maior que a simples soma de esforços separados. Um dos desafios é saber lidar com pessoas que não sabem trabalhar em equipe e/ou não confiam em outras pessoas. Pois precisa-se de humildade, paciência e confiança para ouvir e permitir contribuições naquilo que fazemos. Muitas pessoas adoram quando superiores/donos exercitam essas qualidades com elas, mas muitas dessas mesmas já não suportam fazer programação em par, por exemplo.

Energia/Foco: Se pedem algo que pode ser feito em 2 horas, mas só vão precisar mesmo daqui dois meses, adivinha quando começará a ser feito? Sim, condições favoráveis para a síndrome do estudante. Muitas vezes é melhor estar no “acontecendo” dos eventos para aproveitar a energia do momento, onde os esforços podem ser concentrados. Para tanto, desejo e vontade precisam ser projetados em objetivos comuns, considerando tanto aquilo que cada um quer quanto aquilo que o grupo precisa, conciliando partes e todo. A idéia de fazer o cliente explicar suas necessidades e tê-lo re-priorizando a cada iteração deixa claro ao desenvolvedor o que precisa ser feito no curto tempo da iteração, que muitas vezes termina com uma entrega parcial. O comprometimento com o cliente para aquela entrega parcial ajuda naquilo que chamam na entrevista de “senso de urgência”. Vejamos “urgência” aqui mais como diz sua raiz, “urgir”, que no Houaiss também quer dizer: “ser necessário, realizar-se ou resolver-se sem demora“, o que me lembra o conceito de “agilidade”. Esse estado de foco e concentração se faz importante principalmente em grupos, ainda mais para aqueles onde é mais fácil enxergar diversão em grupo que trabalho em grupo. De qualquer forma, a motivação aqui vem de ver as coisas progredindo, de fazer aquilo que realmente importa e faz diferença, no agora.

Evolução/Qualidade: Quem se importa com o que faz, faz com esmero. Trata-se de não apenas fazer, mas estar atento a como melhorar o que se faz. Concordo com o que foi dito aqui, qualidade tem a ver com respeito para com quem irá usar seus serviços/produtos e respeito para consigo mesmo. Não a vejo em prática enquanto vista mais como obrigação do que como elemento motivador, ou seja, ela deve ser alvo principalmente de quem bota a mão na massa. Assim, há uma urgência por qualidade, ela não fica eternamente para “depois”. E quanto mais cedo visada, mais saudável e duradoura será a evolução daquilo que se faz. Para mim, não tem nada a ver com controle (”de qualidade”) e sim com consciência e aprendizagem. Pessoas conscientes sabem que são passíveis de falhas, sabem que sempre podem melhorar, sabem ouvir. Daí ser importante identificar erros e oportunidades de melhoria (consciência), e aprender com estes (aprender = compreender + adaptar). Isso que nos faz relevantes, distintos da concorrência e nos torna continuamente mais adequado aos clientes. É motivante saber que faço algo, ou estou em um lugar, que me permita/estimule crescer continuamente como pessoa e profissional.

Exemplos/Liderança: Líder aqui não é necessariamente um gerente moderno e carismático. No contexto a que me refiro, cada um pode eleger seus líderes. São ídolos ou referências que servem de exemplo, de inspiração para aquilo que queremos ser. Podem ser personagens históricos cujas biografias são admiráveis e, em alguns casos, não precisam sequer ser pessoas, podem ser histórias, mitos, livros, filmes, personagens fictícios, enfim, o papel e influência acabam sendo bem parecidos. Ambos os tipos inspiram posturas, atitudes, valores. Mas para algumas pessoas, tais referência são míticas e distantes demais, que por assim serem podem ter “qualidades superiores”. Daí a importância também de referências próximas e palpáveis: Exemplos. Nesse ponto muitos pensam no papel do Líder. Mas líder pode ser raro de se achar, já exemplo qualquer um pode ser. Na verdade, cada um de nós é um exemplo em potencial (para o bem ou para o mal), basta ter uma atitude que em algum momento em uma certa atividade seja reconhecida, daí ser importante estar sempre ciente desse potencial e responsabilidade. Esse reconhecimento e consciência de influência, por menor que seja, pode ser motivador. Assim, independente de estar ou não em um cargo superior, constantes atitudes exemplares até podem tornar alguém um líder aos olhos dos outros. Esses líderes naturais podem servir de catalizadores de grandes mudanças pessoais e culturais a sua volta, pois passam uma mensagem de transformação (ensinam) da melhor forma possível. Em um mundo melhor, seria ótimo ter chefes (ou mesmo colegas) que antes de tentarem terem “cargo de líder”, tentassem antes serem exemplos e líderes naturais. Mas é mais fácil tentar mudar os outros que a si mesmo, não?

Percebam que esses “ingredientes” não são isolados uns dos outros, como em um bom prato, eles funcionam misturados e podem ser dosados de diferentes formas, desde que se atente a importância de saber equilibrá-los. Quando se fala em foco, não se pode perder de vista o todo, o ambiente, nem muito menos deixar que as urgências tomem todo seu tempo, a idéia é dar mais urgência ao que é importante e menos importância ao que é urgente. Agilidade de entregas não deve comprometer a qualidade do código, ou a necessidade de criação individual não deve eclipsar a necessidade de padronização do código coletivo. Além disso, pessoas diferentes possuem gostos diferentes, alguns ingredientes motivarão mais que outros dependendo de seus desejos e talentos. É uma arte saber aproveitar e desenvolver o potencial alheio e/ou o próprio. E ressalto o “próprio”, pois é importante notar que não basta uma empresa dar estímulo e condições para esses itens se o indivíduo não perceber sua parcela de responsabilidade por sua própria motivação. A verdade é que não se trata apenas de trabalho, se não formos capazes de trazer algo disso tudo para nossa própria vida no dia-a-dia fica difícil ser realmente motivado. Assim, a vida pode ser bem mais saborosa, seja onde for.

Desenvolvendo software como uma Rock Band

11 Agosto, 2008 by Daniel Witaro

Há algum tempo atrás li esse post do Chapiewski sobre analogias usadas para o desenvolvimento de Software. Fiz um longo comentário lá sobre, mas, dado o tamanho que ficou, aqui teria sido o melhor lugar. Corrijo isso e aproveito para revisar a idéia original.

***

Acho que todos já ouviram falar na associação de Desenvolvimento de Software com construção de prédio (ou “construção civil”). Não gosto dela, mas ela se mostra mesmo muito atraente para muitas pessoas. É interessante por se aproximar de “negócios” e relacionar-se com uma construção coletiva. Mas além disso, ela atrai pela segurança de um modelo baseado em um “caso de sucesso”, ter relação com matemática (números…), sugerir a idéia de algo que possa ser controlado/planejado com precisão… Acontece que depois de estudar métodos agéis fica difícil ver as coisas assim. [Atualização: Além do post do Chapiewski sobre os problemas dessa analogia tem esse bem recente do Phillip Calçado]. Analogias alternativas como “Jardinagem”, “Criação de Receita” cobrem alguns aspectos defendidos pelos “agilistas”, mas não possuem a abrangência sedutora da primeira. Então, para uma analogia alternativa que seja mais adequada a minha ótica ágil e que cubra os cenários mais comuns na nossa área, penso que devemos ilustrar as seguintes dimensões:

  1. a natureza criativa e colaborativa do trabalho;
  2. o caráter iterativo/incremental da construção/descoberta das soluções;
  3. a temporalidade e a complexidade crescente dessas soluções;
  4. a necessidade de manter um negócio;

Vou tentar aqui uma analogia que me agrada mais, usando um pouco da inspiração do que já ouvi falarem na comunidade Ruby. Desenvolvimento de Software parece com composição de música. Mas se o software em questão for um sistema maior e de longa duração, algo que deve render lucro, pode ser que a melhor analogia seja com criar uma Banda de música! Sendo que criar é a parte “fácil”, difícil é gravar discos, fazer shows ao vivo, e, principalmente, manter uma carreira por um longo tempo. Tudo isso envolve arte, técnica e negócios. E, principalmente, envolve pessoas.

E falo da banda não apenas como “desenvolvedores”, mas também como parte daquilo que esta sendo “desenvolvido”. Isso se dá porque uma banda não vende apenas música, ela “vende” também a si mesma: expressões, atitude, visual, idéias, valores, etc. Gosto e acredito na idéia de que uma equipe de desenvolvimento de software tem que cuidar em se desenvolver também. Já que, em parte, colocamos a nós mesmos naquilo que fazemos…

Voltando ao que se desenvolve, neste contexto seria algo como um trabalho encomendado, onde essa “encomenda” lembra a forma como antigamente as óperas eram financiadas: Alguém com dinheiro suficiente querendo uma peça musical que atenda suas necessidades (Requiem? Lucro? Entretenimento baseado em alguma história ou tema proposto?). Os integrantes da banda então colaboram em composições e por precisarem atender a um “mecena/patrocinador” faz sentido exibirem as composições aos poucos (iterativamente) para ver se agrada/atende aos “requisitos” (muitas vezes nebulosos) e de uma forma simplificada, afinal não faz sentido orquestrar um rascunho!

[Atualização: Mesmo no caso de não haver esse "comprador" uma banda precisa de um público que a "compre". Ela ainda precisa atender a certos requisitos nebulosos (identificação do público? divertir? voz própria?). Até conseguir ter fãs e se "achar", ela erra bastante nos barzinhos da vida. Todo esse caminho (tocar em "espeluncas", para amigos, gravar demos, abrir shows, etc) é bastante iterativo e incremental na sua formação. Quanto mais simples, leve e ágil (rock?) mais rapidamente pode-se aprender e ter resultados.]

Enfim, ainda não explorei todas as possibilidades dessa analogia, mas eis alguns pontos que me ocorrem e que vejo paralelos no “desenvolvimento ágil”:

  • Ter que atender a um Produtor/Patrocinador/Gravadora (Gerentes, Analistas de negócio) e ainda por cima ao público (Usuário final) para fazer sucesso não é tarefa fácil. Ou esse intermediário faz um papel muito bom como proxy do mercado ou é melhor se aproximar mais do público para saber o que realmente desejam, ou ainda, ser alguém parecido com o próprio público. O caso é: estar bem próximo das reais fontes de necessidades e/ou anseios para responder da melhor forma.
  • Durante os primeiros rascunhos executados nem todos os trechos/músicas precisam estar no mesmo grau de maturidade, se o escopo/tempo permitir as coisas podem mudar bastante até a gravação final. Mesmo depois, se considerarmos os shows ao vivo, há variações freqüentemente.
  • Dependendo da complexidade, uma “unidade musical” (tema, melodia, canção, etc) pode ter semelhanças com uma classe ou um pacote de classes. Parece uma classe quando pode ser usada várias vezes numa mesma música e até em outras de uma mesma obra (disco? ópera?). É bem verdade que uma música de sucesso pode ter variações em discos posteriores, como se fosse transformada numa fórmula ou “modelo” promissor…
  • Novas encomendas com “requisitos” semelhantes podem reutilizar partes das soluções anteriores (ou técnicas). Muitas vezes isso extrapola a própria banda. Talvez por isso vejamos tantas bandas e/ou músicas parecidas num determinado período de tempo.
  • Várias coisas podem ser “acopladas” ao trabalho musical, tais como: clipes, capas de cd, coreografias, livros, etc. Outras vezes são pensadas juntas desde o começo com outras artes, como ocorre às vezes em trilha de filmes, musicais ou óperas. Artistas/técnicos de outras áreas agregam valor tal qual designers a sistemas baseados na web. Daí a importância de saber trabalhar com pessoas de outras áreas.
  • Treino e disciplina são importantes para dominar ferramentas, compor melhor e executar melhor em conjunto e sem erros. Não adianta crescer sozinho ou só saber tocar bem solos, é uma banda!
  • O relacionamento da banda tem que ser cultivado e mantido sadio para a banda sobreviver e continuar criativa. A saída de alguém do grupo pode prejudicar a banda/equipe, e pode haver muito trabalho para manter o tempo de resposta de quem saiu. Além disso, é preciso tomar cuidado para não perder a identidade do grupo e seu trabalho.
  • O valor não está nos instrumentos, mas em quem os usa. De pouco serve a melhor guitarra do mundo na mão de alguém que não sabe usá-la em todo seu potencial. Ou, quão bom músico pode ser considerado quem só sabe usar aquelas “Pick ups de Dj” para mixar música dos outros (”apertador de parafusos de frameworks”)?
  • A banda vai fazendo seus “discos” e vai precisando se renovar, se não fizer muitos sucessos novos o número de músicas “legado” (antigos sucessos) vai aumentando e deixando os shows mais complexos e chatos para os mesmos. A idéia é não ser uma banda de um sucesso só ou presa a um passado que não consegue superar. Se a Banda não se preocupar em se atualizar e melhorar corre o risco de só tocar em “Bailes da Saudade”… Assim como código, ela não apodrece, fica obsoleta, embora mesmo antiga ainda possa manter seu valor para muita gente. De qualquer forma, vale a pena atentar-se para o momento quando as fórmulas de antigos sucessos devem dar lugar ao novo e experimentações.
  • Quanto mais os integrantes da Banda treinarem e comporem coisas fora de sua zona de conforto melhor músicos se tornarão. Além de facilitar uma atualização contante.

Enfim, como toda analogia, há falhas. Mas não precisa ser mesmo perfeita, basta ser suficiente para ajudar na comunicação de algumas idéias.

Sobre…

28 Julho, 2008 by Daniel Witaro
Witaro = uí-ta-ro = /witɐɾɔ/
Wit
  • Inteligência, bom senso, esperteza, sutileza, talento, habilidade, sagacidade. saber (uso arcaico).
  • Web Interactive Talk (internet)
  • Wit Stwosz: Escultor polonês
Aro
Houaiss

  • linha circular cujas extremidades se ligam, formando um círculo;
  • território que circunda uma cidade ou vila ou terra importante;
  • lat. *aruum (alt. do lat.cl. árvum,i ‘terra, campo lavrado’), cog. de ará re ‘arar, lavrar a terra’;
ou
Wi
  • West Indian, West Indies. (English)
  • Wavelet Image. (Computer)
  • kana japonês que representa um tipo de som (Wikipédia).
Lembra: Wii, Wiki, We, Oui…
Taro
  • Tubérculo comestível das ilhas de Samoa (priberam)
  • Primeiro pessoa do Singular de “Tarar” (Houaiss):
  1. pesar (algo) para abater a tara;
  2. ficar louco;
  3. gostar muito; adorar;

Lembra: Tarô…

Creare

17 Abril, 2007 by Daniel Witaro