Você já percebeu que, em qualquer grupo, algumas pessoas são naturalmente levadas a sério, e outras não? E isso raramente tem relação com ser ou não sisudo – o indivíduo de gravata com mais cara de brabo e sem graça numa equipe pode não ser levado a sério por ninguém, e o colega que está sempre de bom humor pode ser visto com respeito por todos.

E o que os outros vêem em nós, por intermédio das nossas atitudes, começa nas nossas escolhas e no modo como nós mesmos nos vemos – em outras palavras, o caminho começa quando nós mesmos começamos a nos levar suficientemente a sério. O artigo “5 Reasons People Don’t Take You Seriously and How to Fix It” apresenta uma série de razões pelas quais as pessoas podem não estar levando você a sério, e convido você a passá-las rapidamente em revista neste meu resumo.

Vamos a elas:

Não manter a palavra

Não dar continuidade

Não separar trabalho e vida pessoal

Dar mais desculpas do que resultados

Andar com a turma errada

Por decisões pessoais e por não mais compartilhar do mesmo sonho, estou me desligando com muito pesar da eBehavior.

Foi um ano de muito aprendizado, várias amizades feitas e principalmente de muito trabalho.

Sinto tremendo orgulho e honrado por ter passado por todas as áreas da empresa, entrei como desenvolvedor onde pude conhecer por dentro a magia da recomendação acertiva de produtos e cross-intelligence que a eBehavior tem. Com o crescimento do time de dev assumi a Coordenação da equipe e gerenciamentos dos projetos, onde melhorei o meu gerenciamento de pessoas, prazos, escopos e riscos que envolvem projetos de alta escalabilidade e disponibilidade como os da eBehavior. A empresa continuou a crescer então assumi com orgulho a posição de Gerente de Produto com a grande responsabilidade de ditar o direcionamento dos produtos da eBehavior que cumpri com muita dedicação e chatisse com os devs para o conseguirmos o melhor para o cliente, e à uns dois meses atrás com a saída do diretor comercial, assumi a responsabilidade de atuar frente aos clientes os ajudando no entendimento das ferramentas, na melhor configuração e otimização delas para suas lojas, estudando e entendendo cada empresa, cada loja, cada consumidor para essa otimização. Foi um ano muito intenso para mim e para todos que estavam ao meu lado.

Agradeço enormemente ao André pela oportunidade de ter participado do projeto eBehavior durante esse um ano e principalmente por ter tido a possibilidade de passar de ponta a ponta na empresa.

Saio com a grata sensação de dever cumprido e desejando muito sucesso a esse time de guerreiros da eBehavior. Que um dia irá mudar o rumo do ecommerce brasileiro e mundial.

Meus planos são de continuar atuando como desenvolvedor e consultor para eCommerce, uma área que me aprofundei muito durante esse um ano de casa.

Deixo aqui o meu muito obrigado a todos com que eu conversei pessoalmente, por telefone, por email e até para quem não conheci mas que de alguma forma participou do meu trabalho. Pois cada um de vocês contribuiram de forma significativa para o meu crescimento pessoal e profissional.

Mais uma vez, obrigado e até logo!

Igor Musardo

Ontem, 1º de Setembro de 2010, foi realizado o 1º #HoraExtra Ágil de Curitiba.

Primeiramente quero agradecer a todos que foram ao #HoraExtra, e dizer para você que não foi, “PERDEU”!

No #HoraExtra foram discutidos vários temas onde o foco central ficou sempre em “PESSOAS” e como melhor gerenciar o maior ativo das empresas.

Como essa foi a primeira edição, lógico que algumas coisas foram esquecidas, como por exemplo câmera fotográfica, e bloco de anotações para os papos relevantes, epic fail, mas vou tentar lembrar de alguns.

Começamos conversando sobre o conceito ágil em Desenvolvimento de Software, Scrums e afins, o papo evoluiu para o Kanban, e comparamos com o Kanban de fábrica, a origem do Kanban em software.

X

Passado um tempo o papo foi para o lado das métricas de velocidade de times ágeis, com a seguinte pergunta: Você, gerente ágil recém chegado para facilitar um time que você desconhece, quais métricas você pediria para conhecer de modo geral a capacidade do time?

Depois aproveitamos a experiência internacional de vários participantes para discutir a diferença cultural entre os profissionais brasileiros e europeus.

E o encontro encerrou com o debate sobre a Geração Y e a liberdade de internet para os funcionários, os gerentes comando-controle, como treinar os colaborados para utilizar com consciência os recursos fornecidos pela empresa ao invés da punição pura e simples.

Aproveite! Pois não é sempre que temos eventos bacanas em Curitiba! Por isso, não perca a chance de fazer network e netweaving no encontro da Locaweb, eu particularmente já vou a 3 anos seguidos, e sempre é muito bacana o evento em geral, e as palestras sempre agregam conhecimento e despertam novas idéias!

Data: 06/05/2010 (Quinta-feira)
Horário: 08h00min às 17h30min
Local: Estação Embratel Convention Center (Rua Sete de Setembro, 2775)

Inscrições: R$ 50,00 Clique aqui e faça a sua inscrição.

Nos encontramos lá!

Na continuação do post De Júnior à Sênior, o Sérgio Taborda vai além da comparação entre analista júnior e sênior e aborda a “evolução” dos analistas sêniores à cargos de gerentes, o texto também leva a reflexão, por isso também está na íntegra logo abaixo.

Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é difícil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escrúpulo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperar-se-ia que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue.

Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente - o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é demérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é demérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?

Encontrei no blog do Sérgio Taborda um excelente texto sobre as diferenças entre analistas júniores e sêniores, como concordo com sua abordagem resolví compartilhar com você. Abaixo segue o texto na íntegra.

Vivemos uma época transformadora no desenvolvimento de software. A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir pro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoníaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluírem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiência. O trabalho é que traz experiência. O sênior sabe que desenvolver software é uma arte e um arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa

Achei muito interessante o post que o Augusto Campos do site Efetividade.Net fez sobre as razões pelas quais os gestores de TI que não são valorizados pela equipe e por isso reproduzi o post na íntegra.

Fonte: http://www.efetividade.net/2008/07/03/7-razoes-pelas-quais-o-gestor-de-ti-nao-e-valorizado-pela-sua-equipe/

A tarefa do gestor de TI é repleta de obstáculos, e obter o respeito e o apoio da equipe muitas vezes é crucial para que os objetivos sejam alcançados com menos turbulência.

É difícil definir objetivamente o que faz o gestor aproximar-se verdadeiramente da sua equipe, mas a revista CIO.com, especializada em gestão de TI, resolveu fazer a abordagem oposta: identificou um conjunto de razões pelas quais o gestor de TI das organizações (ou CIO – Chief Information Officer) deixa de ser valorizado pela sua equipe.

O artigo original está disponível em “9 Reasons Why Application Developers Think Their CIO Is Clueless“, de Mike Gualtieri (da Forrester Research), mas preparei uma versão tropicalizada com as principais razões, e suas contextualizações, que você encontra abaixo.

Se você é gestor de TI e puder contar com a colaboração de pessoas de confiança na sua equipe, pode aproveitar os 7 quesitos para fazer um rápido exercício adaptado das janelas de johari, tentando identificar como você se vê, como imagina que os outros o vêem, e como eles de fato o vêem. Se estiver se sentindo particularmente confiante, permita a eles que eles se manifestem sem se identificar!

E se você faz parte de uma equipe de TI, não ceda à tentação de parar após avaliar o seu próprio CIO. Aplique os mesmos critérios para avaliar a você mesmo, e reflita sobre como evitar estas armadilhas no seu próprio plano de carreira!

Vamos aos 7 critérios:

1. O gestor de TI é maníaco por controle: ou, mesmo sem ser maníaco, ele controla tudo assim mesmo, porque os gerentes que respondem a ele não cumprem sua função – ou não recebem a autoridade necessária. Neste caso, segundo a CIO.com, reforçar o controle não é a solução – o gestor precisa substituir os gerentes que não estão desempenhando, ou então dar a eles a autoridade necessária.
2. O gestor de TI é distante: não basta ter uma excelente equipe, ótimas ferramentas e uma infra-estrutura que funciona. O gestor de TI precisa dar o rumo, e isso não pode ser feito a partir da quadra de tênis, ou por telefonemas após uma sessão de rápida leitura de relatórios.
3. O gestor de TI se identifica demais com os fornecedores: quando o gestor veste excessivamente a camisa do fornecedor de ferramentas de desenvolvimento, bancos de dados, armazenamento, sistemas integrados, etc., ele pode se colocar em posições em que a análise técnica fica comprometida, e em que os argumentos que constam no folder trazido pelo representante da empresa favorita são aceitos como se fossem a verdade, toda a verdade e nada mais que a verdade, sem o ceticismo naturalmente aplicado a todos os demais materiais de vendas, e justificando decisões tomadas antes mesmo do processo de análise ser iniciado. Essa influência da marca predileta, como se fossem os faróis de um carro ofuscando os olhos do gestor paralisado no meio da auto-estrada, é percebida por todos.
4. O gestor de TI é um dinossauro tecnológico: ter experiência é importante, mas a tecnologia mudou bastante desde os tempos dos programas em Clipper para DOS. Mesmo quem entrou em cena mais recentemente, com o VB, Delphi e Java, precisa saber que o palco tecnológico é um alvo móvel em alta velocidade, cujos fundamentos precisam ser compreendidos pelo gestor a ponto de ele entender as metáforas e outras figuras de linguagem nas comunicações com sua equipe, e falar no mesmo idioma.
5. O gestor de TI é muito ligado às ferramentas: a equipe de técnicos respeita quem fala o idioma dela, mas o trabalho do gestor é definir o objetivo e as regras do jogo claramente, e aí sair do caminho para que a equipe possa lhe apresentar alternativas e soluções. Nenhum técnico oferece seus melhores resultados quando o gestor quer definir até mesmo como devem ser os loops, as linhas de código, a forma como o cabo deve ser conectado, o endereço IP da máquina. O gestor precisa confiar tecnicamente na sua equipe. Se ele confia mas age assim, ou ele é maníaco por controle (veja o item 1) ou há algo muito errado com a equipe.
6. O gestor de TI acredita em mudanças instantâneas: o progresso não se completa da noite para o dia, e as varinhas mágicas tendem a funcionar muito mais na ficção dos planos e relatórios do que na realidade objetiva percebida pelas pessoas da equipe – e pelos clientes.
7. O gestor de TI não sabe a diferença entre recursos e talento: e por isso age como se todos os técnicos da equipe fossem intercambiáveis, agrupando-os em novos projetos considerando especialmente a questão quantitativa, como se fosse possível afirmar que o projeto X precisa de 2 analistas e 3 programadores, e que na ausência de algum deles, quaisquer outros podem ser incorporados a qualquer tempo. Talento e espírito de equipe fazem maravilhas pelos resultados, e tratar as pessoas como recursos é uma forma segura de não desenvolver nenhum dos dois.
8. O gestor de TI está em permanente campanha para alcançar o cargo máximo da organização: alguns CIOs chegam a ser CEOs (Chief Executive Officer, o administrador de mais alto nível hierárquico), mas não é muito freqüente. Mesmo assim eles tentam, ou aspiram secretamente – e todo mundo percebe. A equipe precisa saber que o gestor está lá para ficar, que *quer* ficar lá, e que as ações dele são guiadas pela estratégia da área de TI, alinhada à da organização, e não a uma campanha secreta em prol da carreira do seu chefe.

Depois de computar sua pontuação (ou a do seu chefe), pare para refletir. Existem muitas formas, estilos e fontes de liderança, mas os líderes reconhecidos de forma duradoura compartilham entre si um atributo: ter conquistado e mantido o respeito de suas equipes.

Identifique os pontos que precisam de melhoria, e faça sua parte na busca por uma equipe melhor, com um líder à altura.

Leia também

• Liderança: saber os conceitos não é o suficiente.
• Liderança e Motivação: como liderar nos momentos difíceis
• Liderança e motivação: 7 dicas sobre como NÃO motivar uma equipe
• Liderança e motivação: quer ser levado mais a sério?
• Liderança: Aprenda a ser um bom ouvinte
• Política do escritório: como sobreviver – e vencer
• Como liderar seu chefe – a dica de Stephen Covey
• Os papas da qualidade

Fonte: http://blpsilva.wordpress.com/2008/06/06/gestao-de-conhecimento-do-time/

Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

O site Efetividade.NET postou recentemente um artigo onde foram relacionadas algumas atitudes e posturas de pessoas que são levadas a sério. Eu particularmente gostei muito do artigo e por isso resolvi linká-lo aqui.

Boa leitura.

Liderança e motivação: quer ser levado mais a sério?