You are currently browsing the archives for the agilidade category


Gerenciando times autogerenciáveis no OxenteRails 2010

Há alguns dias tive a oportunidade de falar uma ou duas palavras no OxenteRails 2010 sobre gerenciamento de times de desenvolvimento de software, em especial, os autogerenciáveis. Foi uma experiência bem bacana, havia mais gente interessada no assunto do que eu imaginava que haveria.

Demorei um pouco, mas cá está, subi minha apresentação pro SlideShare.

O que achei do evento?

Achei o evento muito arretado, como de fato era sua proposta. (háh!)

Bem, mas sendo um pouco mais especifico, deixo um destaque especial para a organização do evento, que foi impecável; muito acima da média mesmo; o pessoal da comunidade lá de Natal está de parabéns. Annaysa Melo, Paulo Fagiani, Maximiliano Guerra e todos os demais, muito obrigado pela receptividade!

Presença da Locaweb

Esse ano, um coisa peculiar que rolou foi que, além de mim, outros quatro locawebers também palestraram: Fábio Kung, Nando Vieira, Rafael Rosa e Daniel Cukier. Me senti em casa!

Palestras

A maioria das palestras que assisti foram muito boas, em especial a do Tapajós que, como já era de se esperar, mandou super bem falando de CouchDB. Queria muito ter visto também a do CV, mas infelizmente não pude, porque palestramos no mesmo horário. Fica pra próxima.

A palestra do Geoffrey – com aquela voz de peepcoder – foi no mínimo divertida; mas a do José Valim acho que ficou devendo um pouco – talvez porque, IMHO, soou um tanto quanto marketing da Plataforma. Já a do Akita me surpreendeu. Nem tanto pelo conteúdo – apesar de indiscutivelmente relevante –, mas mais pelo formato e desenvoltura. Bem legal mesmo.

Não gostei da palestra do Carlos Brando, achei muito auto-ajuda; mas deixo um ponto positivo pro trecho de Assembly e C que ele codou ao vivo. Aliás, falando em codar ao vivo, a palestra do Nando foi muito boa, com seus slides super descolados e coloridos, mas ele não codou ao vivo. Tadinho do Murphy e sua lei, não paparam essa.

Dessa fez o Kung também não codou ao vivo, como de costume, mas sua palestra foi legal, bem contextualizada, dinâmica e totalmente #devops. Aliás, ela fez tanto sucesso que, depois de terminá-la, ele ficou um tempão trocando idéia e codando com a galera no open space.

Não pude ver a palestra do Rafael Rosa, meu colega de Locaweb, porque estava na do Hugo Baraúna sobre Project Rescue. Não gostei muito, pra ser sincero, então acabei ficando meio frustrado.

Henrique Bastos deu um show de humildade, numa palestra que, sinceramente, eu não esperava muito do tema. Foi excelente. Já a palestra do Daniel Lopes, não gostei não. Gostei do Steak, que eu ainda não conhecia, mas achei a palestra dele meio bala de prata no que diz respeito a testes de aceitação.

A palestra do Vinícius Teles foi legal, mas como eu já tinha visto ele palestrar nos dois últimos anos, na Rails Summit, não foi muito novidade pra mim. Mesmo assim, uma boa palestra.

Nessa linha de empreendedorismo – também seguida pelo Rafael Lima, o Alê Gomes, cara muito gente fina, fez uma apresentação meio reworkeana, mas mega divertida. Casquei o bico com ele.

Vi também a palestra da Thaís, falando sobre seu dia-a-dia no trabalho, comprometimento e respeito aos colegas. Foi legal.

E por fim, rolou um Q&A com todos os palestrantes, quando foi revelado que somente eu, Akita, CV e Juan Bernabó não terminamos a faculdade. Aliás, falando nesse Q&A, rapaz, como tem gente que gosta de falar, hein? Teve palestrante que pegou o microfone e não quis mais largar. Fiquei impressionado.

Balanço final

Valeu bastante a pena ter participado dessa conferência, em especial pelas discussões e bate-papos informais.

Ano que vem, quem sabe, nos vemos por lá outra vez!

Minha palestra no OxenteRails 2010

Nos dias 6 e 7 de agosto acontecerá em Natal a segunda edição do evento de Rails mais arretado do planeta, o OxenteRails 2010, com palestras técnicas [e não técnicas] de diversas personalidades da comunidade de desenvolvimento de software brasileira e internacional.

Se você estiver por lá e quiser ver uma palestra nada técnica, logo depois do coffe-break, às 16:00, na sala B, vou falar sobre “gerenciamento de times auto-gerenciáveis”.

Uma introdução ao assunto da minha palestra são os posts:

Review da XP 2010

Quem me acompanha no Twitter sabe que mês passado estive na 11ª Conferência Internacional de Desenvolvimento Ágil de Software, a.k.a. XP 2010 – que este ano aconteceu na longínqua Trondheim, na Noruega –, junto com meu companheiro de Locaweb, Alexandre Freite, figurinha conhecida da comundade ágil de São Paulo.

Bate papo antes do painel

Bem, aos poucos temos escrito sobre o evento (review, palestras, etc) no blog da Locaweb e também coloquei uma porção de fotos no meu Flickr.

Divirtam-se!

Como vi Scrum ser completamente rechaçado em uma grande empresa

Esse foi o tema da minha apresentação na Agile Brazil 2010 em Porto Alegre, como havia relatado em outro post aqui no blog.

Um pequeno review

O evento foi muito bacana, teva ótima organização, boas palestras, tudo muito legal mesmo. Parabéns ao Danilo Sato, ao Hugo Corbucci, à Mariana Bravo e aos demais organizadores.

Palestras

As palestras foram boas, mas em geral não trouxeram nada de muito novo. Mesmo o keynote do Martin Fowler, que tocou no assunto de deploy contínuo, não trouxe nada de muito novo. O Guilherme Silveira, da Caelum, havia blogado em março e feito uma apresentação em maio sobre esse tema no evento Maré de Agilidade, em BH.

Gostei bastante do tutorial do Paulo Caroli, da ThoughtWorks, sobre Agile Card Wall; da palestra do Franscico Trindade, também da ThoughtWorks, sobre Coaching de Guerrilha; achei interessante a palestra do Manoel Pimentel, da Visão Ágil, sobre Coaching para Liderança de Equipes Ágeis, mas fiquei um pouco entediado com suas dinâmicas; e infelizmente, não pude ver o workshop do Rodrigo Yoshima, da Aspercom, e do Phillip Calçado, da ThoughtWorks, sobre Modelagem Ágil, porque eles baleiraram a sala!

O keynote do Klaus Wuestefeld foi bem divertido – feito no Notepad! – e, como sempre, subversivo!

Networking

Mas apesar das boas palestras, a parte mais interessante mesmo, na minha opinião, foram os papos informais nos intervalos das palestras, almoço e final do dia. Papos informais são uma excelente maneira de trocar experiências, ter insights e conhecer pessoas talentosas. Rolou de tudo: liderança de times ágeis, auto-gerenciamento, débito técnico, desafio de lidar com sistemas legados, gerenciamento de iterações, Kanban, métricas, e por aí vai. Muito proveitoso.

Dicas de reviews

Sugiro fortemente que você leia os reviews feitos pelo Rafael Rosa, um dos meus colegas de Locaweb que também estiveram por lá.

Outra dica de leitura é o review que o Alan, também da Locaweb, fez do curso de CSPO que ele fez na prévia da conferência.

Mais produtividade com uma área de trabalho maior

Já faz um tempão que li um post do Martin Fowler que falava sobre o aumento de produtividade resultante do uso de dois monitores grandes, em lugar de um único e pequeno monitor. Na época, achei bem interessante a idéia, mas como estava totalmente fora do meu alcance ter uma área de trabalho dessas – em meu emprego da época –, preferi simplesmente deixar pra lá. Mas ultimamente, mesmo adorando a tela do meu MacBook 13.3” – que passei a levar pro meu emprego atual –, de tanto ver pessoas ao meu lado usando dois monitores grandes, de maneira tão inteligente e produtiva, passeir a querer testar isso também.

A deixa final

Como já disse algumas vezes aqui no blog, em meus times, além de alguns legados, lidamos basicamente com Ruby on RailsC#/ASP.NET MVC e Git como DVCS. Então, além de um bom editor de textos e um terminal, precisamos também de um Visual Studio – com ReSharper, porque sem isso, ele não é nada – que, infelizmente, para usuários de Mac e Linux, só roda em Windows. Tentei resolver isso usando Mono, mas acabei desistindo – por enquanto, porque vai ter revanche!

Bem, resolvi então usar o Parallels Desktop 5 para rodar o Visual Studio 2010 no conforto do meu Mac e, de tabela, adicionar mais um monitor à minha área de trabalho.

Meu space de programação

Pra mim ficou fantástico! Porque no meu space de programação deixei o Visual Studio maximizado na tela grande (à esquerda), rodando no Windows, que por sua vez está rodando no Parallels Desktop, em tela cheia e com look & feel de Mac OS X; e na tela do Mac (à direita) – que eu adoro! –, deixei o terminal, onde posso interagir com o Git e tudo mais. Yay!

Mac + VS

Visual Studio 2010 no Windows (à esquerda); Terminal no Mac OS X (à direita)

E tem mais: quando não precisar usar o Visual Studio por um longo tempo, tenho duas alternativas:

– desligar o Windows;
– ou simplesmente pausá-lo no Parallels Desktop.

E se for o caso, arrastar o TextMate pra tela grande.

Ficou muito bom isso, o Parallels Desktop é demais!

Meus outros spaces

Uma área de trabalho dessas não serve só pra programação. Hoje mesmo precisava editar um wiki enquanto olhava dados em uma planilha. Sem problemas! Planilha na tela grande e wiki sendo editado na tela do Mac. Fantástico!

Só faz um dia que estou com essa área de trabalho expandida e sinto que não posso mais trabalhar sem ela. hehehe

Minha apresentação na Agile Brazil 2010

Há dois meses postei aqui minhas duas propostas para o evento Agile Brazil 2010. Uma delas foi aceita — “Como vi Scrum ser completamente rechaçado em uma grande empresa”.

Qual a idéia dessa palestra?

Bem, nem só de acertos vive um agilista – os contadores de “case”, sim; os agilistas, não. Aliás, pelo contrário, frequentemente aprendemos mais com nossos erros do que acerto. Porque muitas vezes nossos acertos são frutos de pura sorte e sequer conseguimos reproduzi-los novamente.

Dito isto, minha palestra não é sobre “dar carrinho” nos amigos que estiveram comigo nessa experiência, nem apontar culpados ou citar nomes. Não! Minha palestra é sobre apontar erros que cometemos – óbvio, querendo acertar; é sobre lições aprendidas – boas e ruins.

Essa apresentação é a visão e opinião de todos?

Não sei exatamente. Vou falar única e exclusivamente da minha visão e opinião sobre os fatos.

Que mais?

Nos vemos lá, ué! \o/

Você ainda acha que programação em par é desperdício?

Como o Vinícius Teles sabiamente disse há alguns anos, “Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming. Emprestando mais algumas de suas palavras, o motivo é que:

“Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.

À primeira vista, a programação em par parece ser uma prática fadada ao fracasso e ao desperdício. Afinal, embora possa haver benefícios, temos a impressão de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento. Entretanto, não é exatamente isso o que ocorre.”

Não, não é isso mesmo!

Nossa experiência

Há quatro meses decidimos, de uma vez por todas, levarmos realmente à sério esse negócio de programação em par aqui nos times de desenvolvimento dos sistemas centrais da Locaweb. De imeditato, optamos pelo caminho mais eficaz: reduzimos pela metade o número de máquinas dos times. Sim, quase que do dia para a noite, passamos a ter apenas e  tão-somente uma máquina para cada dois desenvolvedores.

Estações de pareamento: como é que é isso?

Desde que fizemos a redução de 50% de nossas estações de trabalho, passamos a ter as chamadas estações de pareamento, máquinas destinadas exclusivamente para trabalho.

Galera de Sistemas Centrais pareando

Estações de pareamento precisam ter:

– usuário genérico para login;
– script para settar no git o dupla atual;
– configuração padrão de desktop, diretórios e ferramentas;
– apenas o instante messager de trabalho;
– apenas o cliente de e-mail de trabalho;
– acesso total à Internet;
– idealmente: 2 teclados, 2 mouses e 2 monitores (grandes!).

Mas não devem ter:

– arquivos pessoais;
– programas de distração.

Outra dupla de Sistemas Centrais

Bem, não está diretamente associado ao modelo de estações de pareamento, mas é bem importante também que as duplas tenham ao seu lado o monitor da integração contínua de seu time, para ter sempre à vista o feedback dos builds. No nosso caso, temos monitores suspensos como o que pode ser visto na foto ao lado – de preferência, sempre verdinhos!

Estação de relax: tem isso, é?

Junto com a idéia das estações de pareamento também adotamos a idéia de estação de relax. Atualmente temos apenas uma, dado o tamanho de nossa equipe.

A estação de relax é uma máquina com acesso total à Internet para a galera relaxar um pouco durante a jornada de trabalho, acessar e-mail pessoal, redes sociais, internet banking, enfim, o que quiserem e bem entenderem. Acesso total à qualquer hora do dia!

O que temos colhido com isso?

Até agora só ganhamos! Ganhamos produtividade, qualidade, propriedade coletiva de código, padronização, e por aí vai.

Desperdício isso? Não, acho com certeza não.

Rápidos conselhos para gerentes humanos

Gerenciar um time de desenvolvimento como um verdadeiro líder – e não um despota, ditador, que micro-gerencia cada passo – não é um tarefa fácil, acredite. Você não tem que lidar apenas e tão somente com Ruby, C#, Java, ou seja lá qual for a linguagem de programação que você use em seus projetos. Você tem que lidar na maior parte do tempo com algo muito maior e mais complexo do que isso. Você tem que lidar com “pessoas”.

Lidar com pessoas não é uma tarefa fácil. Não é mesmo!

1- Por causa das diferenças

Porque as pessoas são diferentes umas das outras; umas mais, outras menos, mas todas são.

Isso é muito bom [e dispensa dizer o porque], mas ao mesmo tempo é bem desafiador, porque você precisa aprender a maneira adequada para lidar com cada pessoa. Às vezes, o que deixa uma pessoas feliz e motiva, pode inesperadamente deixar outra completamente desmotivada.

2- Por causa das expectativas

Porque inevitavelmente as pessoas criam expectativas a seu respeito, que muitas vezes não podem ser correspondidas, seja por sua causa ou por causa do sistema no qual vocês estão inseridos. E infelizmente, a reciproca é verdadeira – afinal de contas, você também é uma pessoa –, o que quer dizer que você também corre o risco de acabar decepcionado, tanto quanto elas.

3- Por causa dos anseios

Porque as pessoas possuem seus próprios anseios, que algumas vezes são bem parecidos com os seus, mas outras tantas vezes são tão diferentes quanto o dia e a noite.

Uff! É preciso dizer mais? Acho que não…

O que fazer então?

Não. Tornar-se um ermitão não é uma opção. Esqueça isso!

1- Aceite, você não vai acertar sempre

Na verdade, algumas vezes você vai errar até mesmo quando pensa estar fazendo o maior acerto da sua vida. E a bem da verdade, talvez seja exatamente isso que torne esse trabalho tão interessante, tão humano e tão pouco tedioso.

2- Aprenda o máximo que puder com seus erros

É bem verdade que podemos aprender bastante com os erros dos outros. No entanto, algumas de nossas mais ricas experiências de aprendizado são provenientes de nossos próprios erros.

Não despreze seus erros e simplesmente passe uma borracha neles. Se você os apagar, haverá uma grande chance de cometê-los novamente.

3- Não tenha a ilusão de que sempre haverá consenso entre você e as pessoas as quais você lidera

Acho que essa é uma das coisas que mais preocupam um líder, porque a bem da verdade, todos nós – pessoas que somos – temos algum grau de dificuldade de lidar com opiniões divergentes das nossas, quer seja quando lideramos ou quando somos liderados.

A melhor coisa a fazer então é tentar compreender muito bem as opiniões das pessoas as quais você lidera e tentar chegar com elas a decisões convergentes. No entanto, quando não houver convergência de opiniões em decisões que cabe a você tomar, tome-as de acordo com o que você acredita realmente ser o melhor.

Lembre-se: você é o líder e é o responsável por suas decisões, quer partam de você ou não.

Se você é humano, gerente…

Deveria considerar esses rápidos conselhos. IMHO.

Duas propostas para o Agile Brazil 2010

Submeti hoje duas propostas de palestras para o Agile Brazil 2010, um evento bem bacana que acontece em Porto Alegre em junho. Esse ano o evento conta também com a presença de Martin Fowler, da ThoughtWorks.

Segue abaixo o resumo das minhas submissões e, se você quiser, além de poder deixar comentários aqui, também pode fazer isso no próprio site de submissões do evento.

Espero te ver lá! :)

Como vi Scrum ser completamente rechaçado em uma grande empresa

Ouvimos por aí muitos relatos de sucesso de implementação de métodos ágeis em empresas grandes. Nós mesmos temos alguns. Mas onde estão os relatos de derrotas?

Nesta palestra vou contar uma história real em que vi Scrum ser completamente rechaçado em uma grande empresa que trabalhei.

Essa não é uma palestra sobre apontar culpados, mas sobre identificar falhas que comprometeram completamente a adoção de métodos ágeis nesta empresa.

Princípios de Agile Coaching

O que faz um coach ágil? Quais são suas ferramentas? Em que se baseia seu trabalho?

Essa palestra é sobre alguns princípios do coach ágil e como ser eficaz nessa missão. Vou abordar temas como:

– educação
– facilitação
– feedback
– percepção
– apoio

Além de falar sobre as atitudes esperadas de um coach:

– liderança por exemplos
– equilibrio emocional
– respeito ao ritmo do time
– linguagem que vence barreiras
– deixar o time aprender com seus erros

Tchau, tchau gerente, agora sou Scrum!

Já que Scrum define apenas três papéis: Scrum Master, Product Owner e Time, onde é que fica o papel do Gerente de Desenvolvimento? Será que é hora de dizer adeus?

Contextualizando

Há pouco tempo assumi uma posição na Locaweb como gerente da equipe de desenvolvimento responsável pelos sistemas centrais da empresa. É uma equipe relativamente grande, dividida em três times de multi-talentosos desenvolvedores, um para cada domínio de negócio que lidamos: Provisionamento, Cobrança e Atendimento; além de dois sysadmins que dão suporte a estes times em tempo integral.

Os times atualmente estão organizados como times de Scrum tipicos, com os tais multi-talentosos desenvolvedores, um Scrum Master e um Product Owner – que no nosso caso, é um gerente de produtos que trabalhar fortemente conosco, extremamente comprometido com os interesses de negócio da empresa.

Desde então, comecei a buscar me interar um pouco mais sobre assuntos de gerenciamento e liderança ao melhor espírito ágil, com a preocupação de não me tornar aquele tipo de gerente que simplesmente “delarga” e vive alienado; ou pior ainda, aquele que comanda e controla o tempo todo, e queno final das contas, mais caroça e atrapalha do que ajuda.

Novo release: Gerente 2.0

Bem, além de conversar com vários amigos – muito mais experiêntes do que eu nesse papel –, também naveguei bastante pela Web e acabei chegando num artigo muito interessante de Pete Deemer, da Scrum Training Institute, que tem me ajudado bastante. Se você também tem interesse no assunto, acho que vale a pena ler.

Pete sugere no artigo, de maneira bem coerente, 14 atividades de um gerente de desenvolvimento. Vamos dar uma olhada no resumão delas:

1- Ajuda a remover impedimentos que o time não tem condições de resolver por si só

Enquanto o Scrum Master remove impedimentos hora-a-hora, dia-a-dia, coisas referentes ao projeto, o gerente precisará focar seus esforços em resolver impedimentos mais sistemátivos, mais corporativo, digamos assim.

Estes impedimentos, frequentemente, são os mais desagradáveis; e que requerem alguma influência, alguma autoridade, para lidar com eles de maneira efetiva.

2- Dá ao time conselhos e sugestões sobre dificuldades técnicas que aparecem

Gerentes deveriam estar disponíveis para dar conselhos e assitência técnica ao time sempre que solicitado.

Nota minha: é que claro que, volta e meia, o gerente vai precisar ir a reuniões estratégicas, corporativas – ou seja lá como chamemos em nossa empresa –, e não poderá atender às solicitações do time de imediato. É preciso tratar isso de maneira bem madura com o time, colocando na mesa as limitações impostas por suas outras atividades e buscando uma maneira de mitigar isso, para que nem o time fique na mão quando precisar, nem o gerente seja crucificado quando não estiver à pronta disposição.

3- Regularmente conversa com os membros do time, um por um, para dar coaching e mentoring

Gerentes deveriam gastar tempo com os membros do time, individualmente, com certa frequência (que cada um deve achar a melhor para si), para dar coaching e mentoring. Veja: não é para pedir status report; é para ensinar, ajudar, guiar, etc, menos cobrar.

Alguns gerentes gostam de fazer isso pareando e escrevendo código junto.

4- Dá sugestões sobre como fazer features melhores

Estas sugestões são endereçadas diretamente ao Product Owner, geralmente, durante a Sprint Review.

Nota minha: o ideal é que isso aconteça sempre, mantendo o máximo de proximidade possível com o Product Owner. No meu caso, por exemplo, sento de frente para o gerente de produtos de sistemas centrais e bato-papo com ele o tempo todo. Ou seja, se tenho algo a sugerir, não preciso esperar a cerimonia de revisão.

5- Mantem-se pari passu do desenvolvimento de ferramentas, tecnologias e técnicas que o time está usando

Esta é uma atividade muito importante e frequentente negligenciada pelos gerentes. Gerentes não podem ficar congelados no tempo. Mesmo porque, a atividade 2 é sobre estar apto a dar conselhos técnicos ao time.

Nota minha: não tem coisa mais irritante do que um gerente que não entende nada do trabalho que você está fazendo, dando palpites furados, e ainda querendo que você explique para ele algo que ele não tem um mínimo de base técnica e conceitual para entender.

6- Planeja treinamento e outros skills de desenvolvimento para os membros do time

Gerentes deveriam pensar cuidadosamente sobre onde o time poderia usar seu skill; e também, cláro, que capacidades o time precisará ter quando for desenvolver determinados itens do Product Backlog.

7- Mantem-se atualizado sobre as novidades e evoluções da indústria

Novamente, uma atividade importante, mas frequentemente neglienciada. Sem ela, a atividade 2 fica fortemente comprometida.

8- Antecipa ferramentas, skills e futuras necessidades

Outra atividade importante, que tem tudo a ver com a atividade 6, e que é frequentemente negligenciada. Converse com seu time a respeito, peça sugestões.

9- Planeja e gerencia orçamento e caixa

Outra vez, algo muito importante, mas muito negligenciado por diversos gerentes.

Nota minha: qual foi a última vez que você colocou no seu orçamento um din-din para cursos, eventos, livros, e outras coisas que melhoram o skill do seu time? Ou você é do tipo que não se preocupa com isso e que, pior ainda, até acha ruim que seu time vá a eventos, faça cursos ou leia livros no horário de trabalho?

10- Dá sugestões de que features o time deveria construir

Vale o mesmo comentário do item 4, não vale? Acho que sim, tem tudo a ver.

11- Faz avalição de performance e dá feedback aos membros do time

Isso é algo necessário em muitas empresas, apesar de bastante subjetivo. Mas o ponto aqui é que gerentes deveriam basear suas avaliações em suas próprias observações, bem como no feedback de outros membros de time.

12- Faz planejamento e desenvolvimento de carreira com os membros do time

Oportunidade de carreira é uma das mais significantes formas de compensar pessoas por seu trabalho. Além de din-din, é lógico!

13- Recruta, entrevista e contrata novos membros para o time

Uma das melhores (mas às vezes, aterrorizantes!) ações de gerenciamento é tomar decisões de contratação. Isso porque boas contratações dão lucro desde o primeiro dia, enquanto que más contratações são uma “taxa” invisivel na habilidade do time entregar valor de negócio.

14- Remove membros que não são capazes de fazer um bom trabalho no time

Se mesmo depois de extenso coaching um membro do time não é capaz de contribuir, de trabalhar harmoniosamente com os outros membros do time, ou de fazer seu trabalho na qualidade esperada, ele precisa ser removido do time, ou mesmo da empresa, rapidamente. Tipicamente, gerentes precisam guiar esse processo de maneira coordenada com o RH da empresa.

Nota minha: não deixe a moral do seu time e o dinheiro da sua empresa ir para o ralo. Cuidado! Há uma linha muito tênue entre “vou dar mais uma chance” e a omissão. Não tenha medo de fazer uma demissão, mesmo que tenha sido você que fez a má contratação. Contratações são quase que como loterias! Na verdade, quem fez a má contratação é o que menos importa; o que realmente importa é a performance e moral do time, que no final das contas, se traduz em mais dinheiro para a empresa.

Conclusão

O papel do gerente de desenvolvimento 2.0, como diz esse artigo de Pete Deemer, traz um mix de habilidades de liderança técnica e de gerenciamento de pessoas – pelo amor de Deus, não chame as pessoas de recursos!

A mim faz todo sentido; e está bem alinhado com as atribuições que recebi, quando contratado pela Locaweb. Aliás, acho que vale citar que, uma das coisas que Pete diz no artigo é que esse “novo” papel do gerente de desenvolviemnto precisa ter uma bênção formal do diretor de direitor TI, ou alguém com poderes equivalentes.

Mas e você, o que acha? Deixe um comentário…