Não peça feedback, obtenha-o

Todo grande líder sabe que o feedback sincero daqueles que estão à sua volta é uma das principais ferramentas para melhoria e evolução de seu trabalho e de seu papel como líder. Receber e saber processar as críticas é fundamental para aprender e melhorar como líder, quando o feedback é um elogio é ainda melhor, nada mais gostoso do que ter a certeza que você está no caminho certo.

Mas há um grande dilema: Como consigo o feedback sincero dos membros do meu time?

A resposta parece simples, afinal, não bastaria apenas perguntar? Bom, é quase por aí, mas deve-se tomar muito cuidado com o tipo de pergunta a se fazer.

A primeira regra que deve-se ter consciência é que nunca será possível conseguir feedback sincero com perguntas idiotas. Uma pergunta idiota geralmente é uma pergunta da qual você não quer ouvir a resposta, ou uma pergunta que você espera ouvir aquilo que você quer ou, até mesmo, uma pergunta cuja resposta é óbvia.

Pergunta idiota: No meio de um jogo de futebol, pergunta-se para a árbitro: Você está ocupado?

Qualquer ser vivo pensante saberá a resposta do árbitro. Se a pergunta é idiota a resposta é tola.

Isso não significa que a pessoa não queira te dar feedback, mas que há outras maneiras mais eficazes de se conseguir feedback. Não faça uma solicitação em forma de ordem pergunta direta.

Lembre-se sempre destas palavras pois elas serão a chave para o seu sucesso como líder de qualquer time em qualquer área ou empresa, especialmente para se obter feedback sincero e colaboração das pessoas. Estas são as palavras mais poderosas que existem para obter cooperação: “Eu preciso de”. Essas simples palavras são capazes de mágicas e feitos surpreendentes.

Pedir feedback não significa que você irá consegui-lo, especialmente se o pedido começar com “eu quero”. Quando você diz a alguém de seu time que você “quer” algo, a primeira coisa que essa pessoa pensa é: “ah, claro, todos queremos algo que não podemos ter”. Mas se você começa com “Eu preciso de”, significa que você pensou sobre o que é necessário para alcançar o que você está pedindo e, para tal, precisa da ajuda desta pessoa. É incrível como as pessoas adoram sentir-se necessárias, saber que podem ajudar com algo, isso faz toda a diferença entre escutar uma resposta tola e conseguir um feedback sincero.

Aprendendo a obter feedback: Preciso de feedback específico sobre meu plano para que a próxima iteração dê certo.

Simples e indolor, certamente você terá muito a ouvir e aprender.

Um líder é qualquer pessoa que possa lhe dar apoio e orientação necessárias para alcançar seu objetivo. Às vezes o seu maior desafio como líder é saber onde e quando cada pessoa do seu time executará este papel, e cabe a você conseguir obter o feedback necessário destas pessoas.

As pessoas pedem demissão de seus chefes, não das empresas

Gerência não é liderança ou liderança não é gerência? Bom, o que importa a saber é que uma, definitivamente não é igual a outra. Se você não concordou com esta sentença certamente você é gerente =)

Infelizmente já vi muitos profissionais donos de diplomas, certificações e títulos vistosos importantes que só se preocupam em administrar, e não em liderar. Que se preocupam mais com os processos e esquecem das pessoas. Profissionais assim só se preocupam em manter a ordem e o controle, deixando em segundo ou terceiro plano coisas como: qualidade do trabalho, qualidade do ambiente de trabalho, convivência entre as pessoas e muitos outros aspectos sociais.

Na maioria das vezes as pessoas que estão sendo administradas por este tipo pedem demissão de seu chefe, isso mesmo, não pedem demissão da empresa, mas sim do chefe. Estão, de certa forma, dizendo basta à um gerente ineficaz ou incompetente.

Liderar é servir. Liderança está longe de ser uma forma de comando e controle, um líder não controla as pessoas, um líder deve favorecer a criação de um ambiente para que as pessoas criem, evoluam e tomem decisões por elas mesmas sem medo de serem repreendidas ou podadas, o líder deve inspirar confiança. Liderar significa conquistar as pessoas e envolve-las para que coloquem toda sua criatividade, emoção e coração para a realização de um objetivo em comum.

Liderar não é necessariamente o papel do seu chefe. Não é preciso ser chefe ou hierarquicamente superior para ser um líder e influenciar as outras pessoas a terem mais empenho e dedicação. Liderança é a capacidade de influenciarmos as outras pessoas para um bem comum.

Se você está disposto a se tornar ou melhorar como líder, lembre-se que precisa estar mais disposto ainda a mudar e aceitar mudanças. É impossível evoluir e melhorar sem mudar, seria loucura esperar um resultado diferente fazendo a mesma coisa de sempre. Você está disposto a mudar?

É muito fácil responder que sim, que se está disposto a mudar, mas a prática é muito difícil. Conseguir sair do seu pequeno universo, sua zona de conforto e entrar num mundo completamente novo e desconfortável é um desafio enorme e requer muita força de vontade e dedicação. Um líder não nasce líder, um líder se faz com muita dedicação, sinceridade, honestidade e força de vontade.

Lembre-se sempre: Gerência é o que fazemos, liderança é quem somos!

Será que você tem sido um bom líder? Olhe a sua volta, veja como estão as pessoas que você liderou, estão bem? Evoluíram e cresceram? Se tornaram pessoas ou profissionais melhores? Ou será que pediram demissão de você? Você saberá o resultado da sua avaliação rapidinho.

Certified Scrum Master: 1º curso oficial no Espírito Santo

A Giran está trazendo o 1º Curso Oficial de Certified Scrum Master (CSM) para terras capixabas, fruto da parceria entre a Giran e a AdaptWorks. Com certeza esta é uma grande oportunidade para todos que querem aprender mais e se especializar em SCRUM e, claro, dar um belo upgrade no currículo.

banner_scrum

As inscrições já estão abertas e o curso será ministrado nos dias 05 e 06 de novembro, em Vitória, dependendo do número de inscritos atingir a quantidade mínima. Ele será ministrado num lugar compatível com o número de inscritos e tem duração de 16 horas.

O curso inédito no Espírito Santo será ministrado pelo instrutor Alexandre Magno, da AdaptWorks, único instrutor certificado pela Scrum Alliance no Brasil. O curso é um sucesso no Brasil inteiro e altamente requisitado em vários estados, tanto pelo fato de ser um curso oficial quanto por ser a porta de abertura para quem deseja não apenas conhecer mas também se certificar nessa metodologia ágil.

O participante ganha ao final do curso um certificado de Scrum Master, que é o início para a especialização na metodologia e associação na Scrum Alliance.

Para garantir sua vaga, envie um e-mail para contato@giran.com.br com seus dados de contato. Entraremos em contato para informar sobre o curso, preço, modos de pagamento e outros detalhes.

Mais detalhes sobre o curso no blog da Giran.

Escopo, o inimigo do sucesso

Os grandes e temidos arquitetos de sistemas adoram quando precisam especificar um escopo de um grande projeto, geralmente este trabalho é tido como o supra-sumo da empresa, onde somente o melhor dos melhores pode executar, onde a responsabilidade de sucesso ou fracasso está em jogo e no entender da empresa nada deve ser apressado, o arquiteto precisa de tempo para pensar em todos os detalhes, de todos os recursos que precisar para esmiuçar o escopo ao máximo, pensar em tudo que o cliente irá desejar, tudo mesmo.

O que muitos não vêem é que, com isso, a receita para o fracasso já está praticamente concluída. O trabalho e esforço de semanas ou até meses onde o arquiteto deu tudo de si, não passa, simplesmente, da pura arte da adivinhação, de previsão do futuro, de achismo e nada mais. O que ele achou que o cliente desejaria, o tempo que ele achou que iria demorar, os prazos que ele tirou da cartola e os resultados que ele sonhou acontecer dificilmente serão alcançados. Isso não acontece por falta de capacidade do arquiteto, pelo contrário, em alguns casos ele é realmente O cara da empresa e possuidor de vasta experiência, mas tentar prever o futuro não é uma ciência exata.

Apenas uma observação aqui: Não sou contra o levantamento de requisitos e especificação de escopo, pelo contrário, acho que é um trabalho de extrema importância, apenas não concordo com a forma que este trabalho é feito na grande maioria dos projetos, onde o pensamento e a organização em cascata impera.

O fracasso numa situação dessas poderá vir quando o cliente, no meio do projeto, resolver mudar tudo. O arquiteto terá que trabalhar mais alguns meses em um novo escopo? O cliente entenderá que deverá pagar por mais alguns meses de replanejamento de escopo? Como o seu escopo reagirá a mudanças, ele foi preparado para isso?

Ou quando ao final do projeto, somente ao final do projeto, uma versão usável for apresentada ao cliente e ele achar que você se enganou e apresentou a solução de um outro cliente a ele, tamanha a discrepância entre as expectativas do cliente e da empresa. E agora, como fica a situação? Inicia-se um novo projeto!? E quem pagará por isso?

Ou no pior dos casos, durante o desenvolvimento do projeto vê-se que o que o arquiteto previu para 10 meses de trabalho com uma equipe de 5 pessoas estava completamente furado, você vai precisar de 20 meses. Então qual é a brilhante ideia? Aposto a minha sacola de mendorato: “- Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo pela metade e assim ficaremos dentro do esperado”. É tiro-e-queda, será um grande fracasso. Ter um escopo flexível e incremental seria muito melhor do que incrementar a equipe para seguir o escopo. Afinal de contas, desde quando nove mulheres juntas são capazes de gerar um filho em um mês? Manusear prazos, expectativas e custos de um produto desta forma, definitivamente não dá certo.

Existe ainda um outro lado, aquelas pessoas que não querem se preocupar com problemas de escopo, que não querem ter problemas ao final do projeto se tiverem que discutir com o cliente sobre determinada funcionalidade está certa ou errada ou se deveria existir ou não, estas pessoas são as adeptas do escopo fixo.

Eu costumo dizer que, em projetos com escopo fixo só têm uma certeza: ele irá fracassar!

O fracasso nestes projetos não precisa ser necessariamente a não entrega do produto. Isso quase sempre acontece, mas milagres podem acontecer e o projeto pode ser concluído e entregue no tempo, mas ainda assim será um fracasso. Será um fracasso para o seu cliente, que demandou o projeto. Assim como dois mais dois são quatro, eu aposto o meu mendorato de novo que o seu cliente certamente mudou de idéia em vários pontos durante o desenvolvimento do projeto, mas você, esperto que é, já tinha o seu escopo fixo e para não sacrificar a “entrega” e seguir o maldito escopo, esfregou na cara do seu cliente que ele não poderia mudar nada, que ele não tinha esse direito, que estava escrito no escopo assim como é gravado em pedra e nada daquilo poderia mudar, em hipótese alguma, e mais, se ele fosse teimoso e insistisse em mudar teria uma saborosa multa à sua espera.

Sem dúvida esse cliente não estará com você num próximo projeto. Este é um tipo de fracasso que é muito pior que o anterior, certamente. Seria preferível não entregar tudo o que estava no escopo, renegociar o escopo, incrementá-lo ou decrementá-lo, mas entregar tudo o que o cliente pediu durante o projeto do que ignorar e trocar a sua opinião por um documento que foi feito em alguns dias ou horas numa tentativa de prever o futuro, que acaba quase sempre de modo frustrante para ambas as partes – para a empresa que trabalha desta forma, nem tanto, pois a essa altura ela já terá recebido todo o orçamento do projeto.

Trabalhar com o escopo de forma iterativa e incremental não é nenhum bicho de sete cabeças, seu pescoço não estará na corda desde que todas as expectativas estejam alinhadas, insira o seu cliente no projeto, faça-o participar de todas as etapas e ele mesmo verá e terá consciência de que em determinados pontos o escopo precisa mesmo ser alterado – para mais ou para menos. Aprenda a negociar e gerenciar expectativas com o cliente e o escopo passará a ser o grande amigo do seu projeto.

Além dos links dos artigos no último parágrafo, o Manoel Pimentel disponibilizou uma ótima apresentação sobre Gestão de Requisitos através de práticas Ágeis e Enxutas, que mostra extamente algumas das formas de se trabalhar com escopo incremental e iterativo.

Tentar ou continuar na mesma?

Qualquer tipo de mudança na organização e pseudo-metodologias de desenvolvimento de qualquer empresa de tecnologia costuma ser um grande pesadelo. Isso é assim por vários motivos.

Geralmente os gerentes e diretores (na maioria das vezes) serão duros e contra qualquer tipo de mudança simplesmente pelo fato de a empresa ter gastado centenas de milhares de dinheiros, logo, pensarão por muito tempo que isso (metodologia customizada) deverá dar algum resultado, o que acaba não acontecendo na maioria da vezes. Essa negligência e fraqueza em assumir logo o prejuízo e tentar mudar – para melhor – acaba acarretando em prejuízos muito maiores no futuro, demissões em larga escala, troca de diretoria e por aí vai, já vi isso antes.

Outra justificativa muito usada para evitar mudanças será a falácia de que “em time que está ganhando não se mexe. Grande parte das vezes falta coragem ou maturidade para enxergar que o time não está ganhando e que precisa ser modificado, sim. Também não é incomum encontrar situações onde a mudança não é vista com bons olhos pois as metodologias pra inglês ver, as certificações (de parede) e demais honrarias são mais valorizadas do que às pessoas e o produto que a organização entrega, então, nesses casos pouca importa se está bom ou ruim.

Mas onde eu quero chegar com esse post? Todas estas situações que falei até agora são conhecidas pela maioria dos desenvolvedores e sabemos que são situações difíceis de serem vencidas, eu mesmo já fracassei em algumas tentativas de mudança diante de tais situações e felizmente já obtive muitos sucessos também.

Recentemente, almoçando com um grande amigo acabamos caindo no papo sobre as nossas empresas e clientes e falamos sobre um caso em especial. Um cliente em que já haviámos trabalhado, onde enfrentamos todas aquelas situações anteriores de uma só vez – acreditem! – continuava na mesma. Com os mesmos problemas de sempre (atraso), mesmos gerentes/diretores e as mesmas pseudo-metodologias e regras internas, a única coisa que não era a mesma eram os clientes, nem preciso dizer o porque.

Mas a disucssão não chegou a ser prática ao ponto de “seja ágil”, “você precisa praticar TDD/BDD”, “agarre-se ao PMBok” ou “se você não aderir ao Scrum não vai ter jeito”, nada disso, não estávamos questionando a metodologia, nem as regras em si, mas sim a resistência em mudar. Fazendo uma breve retrospectiva vimos que 100% dos últimos projetos não haviam sido entregues na data prevista, desses 100%, 100% tiveram o orçamento o estourado e, desses 100%, 100% não atenderam a todas as expectativas do cliente e foram entregues com features a quem do esperado.

Diante de um cenário como esse, por que não deveríamos tentar mudar? Por que não tentar fazer alguma coisa diferente? Se estamos “sendo ágeis com scrum+xp” por que não tentar um modelo mais lento!? Se o RUP/MPS.Br/QualquerCoisa não está dando certo, por que não mudar e tentar outro? Se as metodologias e regras internas não estão sendo suficientes, por que não deveríamos tentar outra? Com um histórico de atrasos e fracassos, o que poderia acontecer de pior, atrasar 9 semanas ao invés de apenas 7!?

Não fique na mesma por muito tempo, mesmo que o seu time esteja ganhando e esteja realmente na frente, experimente mudar, tente melhorar, evoluir. Avalie sempre não só as mudanças, mas veja o que elas poderão fazer por sua organização, por seus projetos, se algo pode ser melhorado, vá em frente, se algo pode piorar, avalie o seu presente e passado e veja se vai, de fato, piorar, ou se você já estava “na pior” e não estava se dando conta. Não seja cético correndo atrás do que está na moda, na crista da onda, isso nem sempre será bom pra você, mas procure sempre avaliar sua situação e ver o que você pode tentar melhorar e o que pode, sem prejuízos, continuar na mesma.