Say Hello to the Scrum. Um breve introdução ao Scrum.

Olá colegas,

Vamos falar hoje um pouco sobre Agile, mais especificamente sobre o SCRUM.

Provavelmente você já deve ter escutado algo sobre o Scrum e metodologias ágeis, principalmente se tens alguma ligação com a área de desenvolvimento e projetos de software.

Como toda buzzwords das que surgem no dia-dia (e olha que hoje em dia isto não é privilégio somente da área de T.I.), muito se fala e admira-se mas em geral as explicações não consistentes o suficiente.

Este artigo (como outros ótimos exemplos que você pode encontrar mundo a fora) busca lhe mostrar o que é afinal o Scrum, suas vantagens e detalhes.

Vamos lá então...


Introdução - Conhecendo um pouco sobre as definições do SCRUM

Diferente do modelo de se conduzir projetos tradicional que possui uma série de áreas de conhecimento documentadas formalmente e um nível de análise e especificação enorme no início, buscando uma estrutura de conhecimento completa ou quase completa do produto final antes de seu desenvolvimento, o SCRUM fornecem algo mais prático e direto para colocar "as mãos na massa" de uma forma disciplinada e possibilitar uma enorme capacidade de adaptação às mudanças durante o ciclo de vida do projeto.

Mas afinal de contas o que é o SCRUM?

SCRUM

Visão geral e breve histórico:

O SCRUM é um framework (diga-se um arcabouço e/ou conjunto de ferramentas) utilizado para o desenvolvimento ágil de software de forma iterativa e incremental. As origens do SCRUM foram em 1986 quando Hirotaka Takeuchi e Ikujiro Nonaka descreveram uma nova abordagem veloz e flexível para os projetos de desenvolvimento fazendo analogia ao movimento no rugby (futebol americano) aonde a equipe tenta percorrer uma determinada distância como uma unidade (todo mundo junto) passando a bola entre eles (todos colocam a "mão na massa").

Quando diz-se incremental e iterativo significa que temos períodos definidos que se repetem até que o produto final fique pronto (iterativo) e que ao fim de cada período deste temos um bloco funcional do produto final (incremental).

Abaixo temos uma visão geral do andamento do projeto com o SCRUM que detalharemos adiante

Personagens principais (papéis) no SCRUM:

Vejamos quais são os papéis principais em um projeto Scrum, também conhecidos pelo apelido "brincalhão" de "Pig Roles" por serem aqueles que estão com "o 'bacon' na reta".

Product Owner:
É o representante do cliente que, sempre que possível deve ser um membro da empresa cliente e, que tem autoridade sobre o produto junto ao dever de fornecer todas a informações sobre o negócio e necessidades do cliente para o produto. Ele participa de todas as reuniões que acontecem antes de cada período fixo de trabalho (conhecido como "sprint"), ele que escreve todas as "user stories" (semelhante a casos de usos) do sistema, que define a importância de cada funcionalidade e que define as metas de negócio a serem cumpridas nos períodos de trabalho.

Este personagem além de conhecer o negócio e o que gera valor no projeto (perante a visão do cliente) irá impusionar o feedback e diálogo periódico com o cliente. No melhor caso este papel pode ser atribuído a alguém da própria empresa cliente ou, caso não seja possível, deve ser atribuído a alguém que abrace esta responsabilidade totalmente, pois ele será a via de conhecimento do negócio até a equipe, sendo assim um membro completamente comprometido (por isso é um "pig").

ScrumMaster (ou o facilitador):
O processo com o SCRUM é facilitado pelo ScrumMaster. A função principal do ScrumMaster é garantir a integridade do processo dentro dos moldes do Scrum e, utilizar os artifícios de suas habilidades técnicas e de liderança para remover impedimentos e fornecer meios para que a equipe chegue às metas de entregas.

Dentro de uma visão tradicional de gerência, o ScrumMaster não deve ser considerado o gerente pois a equipe no SCRUM é auto-organizada e tem autonomia em seu trabalho mas, cabe ao ScrumMaster sempre que necessário e possível estar educando a equipe a comportar-se assim, seguirem o processo do Scrum de forma integra e, deve também sempre, promover a melhoria contínua do processo.


Equipe:
A equipe é a responsável por botar a "mão na massa" e realizar as entregas dentro dos períodos definidos. As equipes para um processo ágil devem ser pequenas (no máximo 9 pessoas) e multi-disciplinares envolvendo as habilidades necessárias para fazer o projeto rodar plenamente (programadores, designers, testers, ...). Como já explicado deve ser auto-gerenciável o que possíbilita uma flexibilidade e velocidade de resposta às mudanças e desafios maior mas, também requer um nível elevado de responsabilidade, organização e comprometimento de todos

Ferramentas e artefatos do SCRUM

Vamos agora conhecer as ferramentas básicas oferecidas pelo SCRUM para os projetos ágeis.

Product Backlog:
É o "coração" processo do SCRUM. Trata-se de um documento de alto-nível (que não se aprofunda no mínimos detalhes) que contém todas as funcionalidades do projeto através das "user stories", estimativas "cruas" de prazo e importância de cada (fora outros parametros que podem ser incluídos para uma melhor adaptção à realidade da empresa). Este documento é de propriedade do Product Owner (ele que descreve as "user stories" e dá a importância de cada uma) mas deve poder ser visto por todos os membros da equipe (normalmente está compartilhado em um local da rede interna ou em uma planilha online).

O formato visual do documento trata-se de uma simples planilha semelhante como no exemplo a seguir:

ID	Título	Estimativa Inicial	Importância	História (Descrição)
1	cadastro de usuário	8 (story points)	120	o usuário deve encontrar no site um formulário que perguntará se ele já tem cadastro para fazer compras. Se for cadastrado deve autenticar com seu e-mail e senha. Caso contrário deve aparecer um formulário com os seguintes dados...
2	...	...	...	...

ID:
Trata-se de um código numérico sequêncial que serve para ajudar a identificar unicamente uma "user story".

Título:
Um nome ou frase que descreva claramente de qual "user story" está se falando. O nome deve estar na linguagem do negócio e não em linguagem e detalhes técnicos.

Estimativa inicial:
Como o nome já diz é uma estimativa inicial de quanto tempo a funcionalidade poderá levar. Note também que a unidade são "story points" que corresponde a dias de trabalho de um profissional. Exemplo: Se com 3 membros (vamos dizer 2 programadores e 1 designer) sem interrupções, em um bom ambiente uma funcionalidade deverá ficar pronta em 3 dias então temos 9 story points (3x3 = 9).

Tal abordagem oferece uma visão de impactos no prazo. Mas, lembre-se que trata-se de uma estimativa inicial e não deve ser encarada como uma verdade absoluta e, um outro fator a se citar é que antes de ocorrer uma "sprint" (um período fixo de trabalho da equipe), o tempo de desenvolvimento necessário para cada funcionalidade incluída se torna mais refinado e com adição de margens de risco de atraso.

Importância:
O nível de importância recebe números correspondentes ao o quanto aquela funcionalidade é crucial. Isso ajuda quais devem ser feitas logo nas primeiras sprints e a depender do ambiente na empresa aquelas que tem importância máxima podem se beneficiar de técnicas como a programação em par que aumenta o foco e reduz bastante a possibilidade de erros. Note também que os intervalos normalmente são dados de 10 em 10. Isso facilita a inserção de outras funcionalidades que são "um pouquinho" mais ou menos importantes. Exemplo: História A = 120; História B = 119.

História:
É aqui que o Product Owner descreve em alto nível como deve se comportar a funcionalidade. Note que quando se diz "alto nível" queremos dizer que deve estar na linguagem do Product Owner, ou seja, mais regra de negócio do que uma texto técnico para programadores.

Sprint Backlog:
Se o Product Backlog é considerado o "coração" de onde brota o projeto, o Sprint Backlog é de aonde brotam o movimento e detalhes para se percorrer uma jornada. Trata-se de uma saída detalhada aonde estão as "user stories" do Product Backlog que são escolhidas para desenvolver-se em uma sprint. As "user stories" escolhidas e quebradas em tarefas e as durações de cada uma são refinadas. Dentro deste documento também deve estar a meta da sprint. Exemplo: "Criar o mecanismo de vendas online beta". A criação deste documento tem a participação de toda a equipe e deve ser guiada pela conversa franca e crítica a fim de que se chegue ao que realmente é necessário.

O formato visual do documento que ficará visível para todos tanto deve ser em uma planilha ou documento de texto (que fique compartilhado na rede) como deve também estar disponível em um mural (task board ou kanban) na forma de "index cards". Um mecanismo visual chave que será explicado mais adiante mas, que podemos ver (só para adiantar) na imagem abaixo.

Burn Down Chart:
Trata-se de um gráfico que demonstra o andamento de uma sprint (período fixo de trabalho da equipe) ao longo do tempo definido para esta. Vejamos o exemplo na foto abaixo:

No eixo X temos os dias até o fim da sprint. Exemplo: Os dias úteis desde 01 de fevereiro até 15 de fevereiro (data quando o resultado da sprint deverá ser demonstrado ao Product Owner).
No eixo Y temos o quanto falta (seja em % ou story points) para que se completem todas as funcionalidades separadas para a sprint.
A cada reunião "relâmpago" diária da equipe (daily scrum meeting que veremos mais adiante) o gráfico é atualizado dando a visão de como está indo o trabalho.

Reuniões e eventos do SCRUM

Até agora citamos sobre "sprints" e "daily scrum". Vamos conhecer estes e os outros eventos e reuniões do SCRUM.

Product Backlog Meeting:
É a reunião inicial do projeto que dá o "pontapé inicial" e fornece toda a informação de alto nível necessária para que seja confeccionado o documento "Product Backog".

Sprint:
A "sprint" que, citamos várias vezes até agora, trata-se de um período fixo de trabalho que a equipe irá percorrer. Essa quantidade de tempo é fixa (normalmente entre 1 a 4 semanas) e o resultado deste trabalho é um pacote de funcionalidades, testadas e prontas para o uso. Antes de uma sprint temos a reunião "sprint planning" que irá planejar e detalhar a sprint e ao fim temos a "sprint demo" aonde o resultado é testado pelo product owner.

Através desta característica fixa, iterativa e incremental aonde a equipe "abraça" o produto final aos poucos em partes iguais é que o SCRUM triunfa sobre uma metodologia tradicional onde de início (quando menos se conhece a mente do cliente) tenta-se "abraçar" tudo. Note também que através do SCRUM estamos sempre planejando junto ao cliente oque diminui os riscos de que a equipe não entenda o projeto. Chegando assim no final com algo que não gera valor e sim desgaste e retrabalho.

Sprint Planning:
Como o nome sugere, é nesta reunião periódica com todos os membros (equipe, ScrumMaster e product owner) em que definimos quais funcionalidades do "product backlog" vão ser escolhidas para que a equipe desenvolva em uma sprint. Aparentemente é simples mas, trata-se da reunião mais demorada e crucial em um projeto ágil com SCRUM.

Vejamos as atividades da reunião:

1. Definir a meta da sprint. Por exemplo: "criar a central de ajuda do site". Uma sprint não deve nunca começar sem uma meta definida em uma linguagem de alto nível.
2. As funcionalidades são escolhidas, divididas (as vezes é necessário dividir uma funcionalidade em duas ou mais para encaixar-se na sprint) discutidas e priorizadas o quanto for necessário para que as estimativas de tempo e importâncias se encaixem na sprint.
3. As "histórias" (funcionalidades) são quebradas em tarefas e o tempo para cada uma estimado. Essa informação sobre as tarefas não necessariamente precisa estar com o Product Owner pois, detalhes técnicos são de encargo da equipe, deixando o Product Owner preocupar-se com aquilo que é realmente importante para ele, ou seja, as funcionalidades.

Então, como funciona a reunião? Provavelmente a primeira coisa que vem a nossa mente é colocar todo o pessoal em volta de uma mesa de reunião com um projetor e alguém com uma planilha excel ou qualquer documento de texto. A planilha realmente ajuda pois realmente a reunião deverá ser documentada mas, se for somente por este caminho a reunião se tornará um marasmo de "tédio" pois esta não é, nem de longe, a melhor forma de estimular a participação de todos da equipe.

Veremos duas técnicas que ajudam muito a resolver este problema:

Index Cards:
Tratam-se de cartões ou post-its aonde colocamos o nome da história (funcionalidade), ou se necessário mais informações como descrição, estimativa, etc. Durante a reunião de sprint planning colocamos estes cartões sobre uma mesa ou quadro branco (de preferência) e ao longo da reunião vamos organizando-os de acordo com a importância que vai sendo atribuída a cada história pelo Product Owner. Veja o exemplo na figura a seguir:

Tal técnica é importante e melhor do que somente o conjunto "mesa+planilha+projetor" porque estimula às pessoas se levantarem e movimentarem-se. Se decide-se que alguma funcionalidade é mais importante do que a outra simplesmente alguém se levanta e muda a posição. Isso estimula o movimento e que as pessoas circulem mais pela sala criando um ambiente mais descontraído. Sendo assim teremos a ordem de importância pela qual a equipe terá um norte ao desenvolver as funcionalidades da sprint.

Planning Poker:
O que acontece quando temos uma funcionalidade e durante o "sprint planning" perguntamos o quanto tempo deve levar para que seja desenvolvida? Provavelmente aquele que sabe (ou acha que sabe) mais vai responder. Muitas vezes funciona mas em excesso isso pode ser altamente prejudicial pois não existe debate entre a equipe e ficamos presos à opinião de uma só pessoa. E se ela estiver errada ou se, aquela opinião aplique-se somente a ela sem levar em conta os outros membros da equipe? Para evitar isto, sempre que necessário utilizamos o "Planning Poker".

Funciona da seguinte forma:

1. O ScrumMaster pergunta à equipe quanto tempo ("story points") é necessário para desenvolver-se uma funcionalidade x.
2. Cada um pensa durante um tempo "quanto dias um profissional precisaria para desenvolver", escolhem o cartão com o número mais aproximado e quanto o tempo acaba colocam sobre a mesa.
3. Aqueles que colocam o maior e menor número devem explicar porque e com isso buscamos chegar a um consenso.
4. Existe também uma carta para dúvida e outra para sugerir uma pausa (o desenho de uma xícara de café).

Esta técnica faz com que todos participem e torna o ambiente mais leve e descontraído.

Sprint Demo:
Se antes de começar uma sprint temos a reunião de "Sprint Planning", ao finalizar temos uma "Sprint Demo".

Trata-se de um evento aonde o "Product Owner" (representante do cliente) se reune junto ao ScrumMaster e equipe para testar as funcionalidades que foram desenvolvidas durante a sprint e que já estão testadas internamente e prontas para o uso. Sempre que possível outras pessoas de outras áreas devem participar também.

Note que seguindo também um modelo de projetos metanóico este evento é uma ótima oportunidade para criar-se momentos memoráveis e deve ser tratado como um evento social. Isso agradará o cliente e deixará a equipe orgulhosa de seu trabalho.

Daily Scrum:
Trata-se de uma reunião relâmpago (aprox. 15 minutos ou menos) deve acontecer todo o dia em um horário e local fixos. Neste encontro todos devem estar em pé próximos ao quadro da sprint (task board ou kanban) e de um quadro branco (para possíveis explicações visuais). São tratados assunto como: "o que foi feito no dia anterior" e "o que será feito hoje" pela equipe. A cada informação que vai surgindo o quadro da sprint o gráfico "burdown chart" vão sendo atualizados por todos.

-----

Bom, ficamos por aqui e espero ter contribuído para um conhecimento do que é o Scrum e como funciona.

Como dizem: "O Scrum é fácil de entender mais difícil de aplicar".

É verdade e, o conhecimento passado aqui é apenas a ponta do Iceberg. No próximo artigo sobre o Scrum iremos abordar os desafios que surgem na implantação do Scrum.

Uma ótima semana a todos!

Abraço e sucesso!

Eduardo Levenfeld

Leia mais aqui.

O líder de projeto, as "Euquipes" e o jogo de culpas

Aproveitando o post muito legal do Ricardo Bicalho no Meio Bit, tópicos discutidos em minha certificação CSM (ScrumMaster) e minhas experiências em projetos de softwares para web como analista / desenvolvedor / observador / pensador / etc. , resolvi fazer uma síntese do mal comportamento comum de líderes e equipes em projetos.

Praticamente irá se abordar sobre três tópicos:

1. O líder de projeto "perdido" e "desolado";

2. As "euquipes" (adaptando parte do excelente post do Ricardo Bicalho) ;

3. O famoso jogo de culpas

Vamos lá...


É muito comum vermos em diversas empresas (seja em listas de condutas ou nos discursos inflamados dos líderes) a necessidade de união e trabalho em equipe. O que é recebido naturalmente e agradavelmente pelos nossos ouvidos mas, que na prática em geral, não acontece. Saturando a mensagem e alimentando o não credo entre todos.

Mas porque será que é tão raro ver na prática equipes e líderes que realmente participam e estão integrados?

As pessoas trabalham em equipes mas, se comportam como se estivessem sozinhas. Afinal de contas, trabalhar realmente como uma equipe é algo que exige saída constante da zona de conforto. Por mais que se "berra" por união grande parte na "hora h" prefere o conforto e privacidade de sua "ilha" e neste momento uma equipe se divide em várias "euquipes". Cada uma com sua forma de enxergar o projeto (brrr...).

Como podemos visualizar é um misto de problemas e atitudes a serem conhecidas a fundo e corrigidas. Vamos por partes então...

1. O líder de projeto "perdido" e "desolado"

Líder. Diante de todos os livros, artigos e discursos chegamos a uma conclusão que este é aquele que motiva, acompanha, coloca as coisas nos eixos, tem a visão do todo e que garante que os impedimentos que "emperram" a equipe sejam removidos. Além disto é aquele que se, perceber que o projeto está fadado ao fracasso, será o primeiro a "berrar".

Não é uma tarefa fácil e exige tino mas, também não é impossível. Temos exemplos de grandes lideranças mas, em maior parte (principalmente na área de tecnologia) a coisa não acontece assim.

Não se trata só de ser carismático, comunicativo, filósofo, inspirador e dar "tapinhas" nas costas dos colaboradores como também não se trata de ser o carrasco "senhor dos cronogramas". Isso exige participação e conhecimento da realidade do projeto sem precisar ter que constantemente chegar no meio do dia e perguntar se a tarefa x vai ficar pronta até as 18:00.

Desde o momento que se participa da execução, seus problemas e glórias, um líder de projetos tem a capacidade natural de deduzir o andamento e próximos eventos em um projeto e não somente ficar "bitolado" em um plano "infálivel" onde se algo não sai como o planejado alguém necessáriamente tem que ser escolhido para ser punido para satisfazer a ira dos superiores. Algo como "joga um aos leões para aliviar a tensão e depois prosseguimos".

Aliás, em minha humilde opinião através das experiências que tive, essa separação de termos "líder" e "equipe" afasta muitos líderes de sua origem como membro da equipe. O líder é um membro da equipe.

A solução é razoavelmente simples e didática:

Imagine um jogo de futebol onde o técnico do time X não está em campo observando os jogadores, tomando decisões quando necessário, dando instruções e trocando jogadores que estão com baixo desempenho. Imagine que ele está em reunião em outra cidade discutindo sobre outros assuntos do time.

Se for um time muito unido e auto organizado a coisa pode durar um jogo ou dois quem sabe mas, o resultado todos podemos deduzir facilmente.

O líder tem que estar no campo como um técnico que vibra e grita por seus jogadores. Simples assim mas exige abrir mão do conforto de uma cadeira acolchoada e sala com ar refrigerado em grande parte das vezes.

2. As "euquipes"

Se por um lado temos um líder "perdido no mapa" em grande parte temos equipes que são "euquipes". Cada um para um lado, como se num jogo de futebol parte do time estivesse no campo olhando para lados diferentes e outra parte comendo pipoca na arquibancada. Uns seguem o projeto, cada um de sua forma e visão, outros assistem passivamente esperando a "bomba explodir" (Oba! Mais um aos leões!).

É muito comum quando falamos em Scrum e sobre a liberdade que as equipes auto-gerenciáveis tem, o pessoal adorar e achar o máximo. O que acontece é que na maioria das vezes está liberdade maior não é associada naturalmente com um nível de responsábilidade maior gerando oque eu chamo "carinhosamente" de "Sindrome da equipe de Lan House". Diga-se achar que agora tá tudo liberado, tranquilo e que se as metas não forem atingidas simplesmente se deixa pra lá e tá tudo entre amigos (e sabadão vamos todos a um churrasco).

Primeiramente devemos pensar, para que existem as equipes auto-gerenciáveis...

Em um ambiente de comando e controle, onde cada passo é apenas executado com o "gatilho do chefe", além de engessarmos a fluidez de nosso processo operacional, privamos na maioria da vezes a capacidade da inovação e criatividade em equipe. Afinal de contas várias cabeças cultas (ou não como diria o Caetano) pensando juntas e se ajudando possuem uma capacidade de realização acima da média.

"Acima da média", repito. As equipes de pessoas boas no que fazem e que, possuem liberdade de escolha, servem para combater a mediocridade dos produtos e entregas pois assim temos mais mentes buscando novos caminhos e consequentemente mais mentes analisando criticamente o trabalho feito, buscando algo acima da média.

O que acontece é que para alcançarmos algo acima da média, "fora da caixa" ou até atingir algo no "extremocristão" como diria o Taleb é preciso dedicação, responsabilidade e organização.

Fórmula mágica?

Educação e foco nas pessoas por parte da liderança. É preciso constantemente estar alinhando a equipe e mostrando que eles têm a liberdade de tomar novos caminhos mas que, se a equipe é auto gerenciável quem são responsáveis são todos. Todos devem buscar o melhor. Se algo está impedindo o andamento e, por acaso ainda não saltou à vista do líder, eles devem exigir que este impedimento seja retirado. Se algo está abaixo da média, deve haver crítica construtiva (note o desafio da franqueza).

E por incrível que pareça, este processo de educação não significa apontar os membros culpados...é...por incrível que pareça...

3. O jogo de culpas (a.k.a Food for the lions)

Se temos um problema com algum elemento da equipe, este problema está na equipe e não no "Ciclano-Incompetente-Que-Não-Fez-Um-Backup-Do-Schema-Do-Database".

É muito fácil, em um final infeliz de projeto (sem churrascão no fim de semana) ou período (uma sprint por exemplo) dizer que não foi atingida uma meta por causa de X ou de Y e, dizer algo como "quando eu expliquei pra ele tava tudo ok!". O que é díficil para grande parte é entender que desde quando se trabalha em equipe, o desempenho de cada membro também é, em parte, responsabilidade de cada um. Seja do líder ou de um programador.

Se o fulano X estava tendo dificuldades e ninguém tentou ajudar ou alertar, ou o líder não gerenciou este problema, temos de concordar que o prolema não está só nas costas do fulano x mas, muito mais na passividade e comodismo de todo o restante em só "assistir de camarote".

O jogo de culpas só frustra, alimenta mágoas e o não credo entre todos. Voltando à analogia do time de futebol, é muito comum quando um time tá péssimo, quase caindo pra segunda divisão, vermos cenas de brigas e acusações entre os membros. Por que será?

Um caminho a tomar?

Nós como líderes e membros de uma equipe auto-suficiente encaramos e resolvemos os problemas e impedimentos. Digo os problemas e impedimentos e não punir e desmoralizar pessoas. Se temos um membro com baixo rendimento, tentamos ajudar no possível para ele ter um bom rendimento. Se ele não tem um bom rendimento (tá numa péssima fase não marcando nenhum gol) negociamos uma troca de tarefas com alguém que esteja com maior rendimento e repassamos outras para ele também sentir-se útil.

Se em último caso ele começou a marcar gols contra e não está demonstrando interesse em mudar. colocamos na reserva ou repassamos para outro time (nem que seja para o time do RH resolver) mas, o importante é focar é que estamos removendo impedimentos e não punindo pessoas abertamente ou diretamente.

Desde o momento que partimos para o lado pessoal de forma nociva, atingimos de forma negativa o relacionamento pessoal que, gera efeitos também nocivos no operacional. Lembre-se, estamos lidando com pessoas que possuem seus sentimentos e valores internos em um ambiente profissional e, este ambiente profissional requere uma franqueza forte mas, neutra. Algo que é bem diferente de um "esporro" que você dá em um irmão seu em casa.

------

Bom pessoal, fico por aqui e não pretendo trazer soluções prontas com este texto. O objetivo meu com este texto é focar em como funcionam as pessoas em equipes e olhar profundamente em busca de reflexões e novos caminhos. Em minha opinião, por em grande parte das situações não enxergarmos e analisar aos outros e a nós mesmos como pessoas que, permanecemos com nossos vícios e comodismo.

Espero que seja de bom proveito e convido aos colegas a fornecerem suas opiniões!

Grande abraço e sucesso!

Eduardo Levenfeld

Leia mais aqui.

Desenvolvimento Profissional como Oportunidade na Crise

Olá caros leitores!

Primeiro vamos começar com uma visão geral de como as empresas comportam-se perante uma crise...

O rosto do líder fica mais ou menos assim...brincadeira! risos!


Vamos ao assunto!

Durante o período de crise e recessão é muito comum ver diversos líderes cortando gastos sem distinção e distribuindo mais estresse para seus colaboradores buscando com isso mais produtividade com menos investimento.

O que acontece normalmente é que, com a euforia que domina, são cortados imediatamente os gastos relativos aos investimentos de longo e médio prazo que tem valor estratégico e, são priorizados os os gastos operacionais que focam o curto e imediato prazo. Exatamente neste ponto se produzem desperdícios no exagerado foco do curto prazo e se esquece do que gera valor no futuro. Aquele valor que, quando a crise abaixa a poeira, ninguém pensou e que você adicionou à sua empresa.

Cortar um e deixar o outro com o foco? Definitivamente não. O que deve haver é um equilíbrio sensato aonde o que reina é a calma, razão e (SIM!) busca por diferenciais.

Agora vamos ao desenvolvimento profissional...

Como sabemos, o desenvolvimento profissional mesmo em períodos de "vaca gorda" muitas vezes é deixado de lado para visar assuntos "imediatos". Desta forma pessoas são promovidas geralmente sem nem saber ao certo o que fará em sua função e novas portas são abertas sem ao menos saber-se algo sobre que desafios se encontram a seguir.

Em período de crise então?

Provavelmente o colaborador ou líder vai disparar algo como: "Em crise o importante é render mais com menos e desenvolvimento seria um gasto desnecessário ou luxo.".

Provavelmente até o leitor ao olhar pra sua vida e carreira pense algo assim.

É nesse ponto que mora o perigo e, a oportunidade.

Desenvolvimento profissional é sem dúvida um investimento de médio (e as vezes até longo) prazo de um valor estratégico enorme. É exatamente no período de crise em que todos estão preocupando-se em manter-se iguais e estáveis que, aquela empresa que conseguir ser estável e diferente vai se destacar.

É exatamente neste momento em que todos acham que diferencial e desenvolvimento é um luxo que a sua empresa deve procurar o desenvolvimento de novas capacidades e melhora de processos. Evidentemente tal atitude deve estar alinhada com a estratégia real da empresa e focar uma base de equilíbrio para a crise mas, é exatamente este pensamento e atitude que, mesmo com a crise, levará sua equipe a um patamar superior.

Sendo assim, quando a poeira abaixa, aquelas que sobreviveram à crise continuam as mesmas (ou menores) e a sua empresa com um, ou vários, passos além.

Pense nisso!

Um abraço a todos os leitores!

Sucesso!

Eduardo Levenfeld 

---
fontes de leitura e referência:
Havard Business Review - Dez/2008

Leia mais aqui.

Oque você lidera?

Pense rápido. Oque um líder lidera? Se sua resposta foi algo como equipe, empresa ou colaboradores você está no caminho mas, precisamos ir mais a fundo no óbvio que muitas vezes é omitido em nosso cotidiano.

Realmente, como líderes estamos representando equipes, empresa, colaboradores, etc. Mas, afinal oque são equipes, empresas ou colaboradores?

Profissionais?

Também mas, podemos definir isto melhor enxergando que estes são pessoas.

Isso mesmo. São pessoas e, apesar de ser óbvio, grande parte dos gestores (que são apenas gestores e não líderes) perdem este foco ocasionando o brotar da raíz de praticamente todos os tipos de problemas que possam ocorrer em projetos ou corporações.

Estes dias em uma das conversas que tenho diariamente na empresa em que trabalho, um grande líder e amigo ressaltou em nossa conversa que apenas 5% do que faz realmente diferença em nossa vida profissional e pessoal estão ligados à objetos e assuntos técnicos. Os outros 95% estão ligados à pessoas.

Apesar de ser uma conclusão relativamente fácil de se chegar, no mercado vemos que grande parte daqueles que se dizem líderes ( e que até possuem um discurso parecido com este ) se focam praticamente 100% nos assuntos técnicos, ou seja, se esgotam plenamente em um esforço que só abocanha 5% do que faz a diferença.

Em grande parte do nosso dia-dia podemos visualizar gerentes que apenas se focam no cronograma e requisítos como se gerir equipes fosse apenas a atividade de acertar prazos e a partir de aí cobrar e punir quando algo sai errado. Tal atitude nós leva à imagem do ser humano como se apenas um máquina que basta apertar o botão e aguardar.

Liderar é mais que isso. Muito mais. É estar envolvido na execução, é conhecer como as pessoas funcionam oferecendo melhores caminhos, é saber atribuir as reponsabilidades certas às pessoas certas, dando autonomia para que soltem seus talentos, reconhecendo as que cumprem suas responsabilidades (e que até superam-se no dia-dia) e, quando algo sai errado, é buscar saber oque deu errado e o porquê para tentar corrigir (ou ajudar a corrigir), antes de punir de alguma forma.

Nada do que está escrito por este humilde autor é novidade. Muito se escuta sobre tudo isto mas, grande parte parece que entra por uma orelha e sai pela outra como se liderança, comprometimento, valores virtuosos e ética fossem apenas estandartes para carregar-se no peito ao invés de algo que se deve aplicar em 100% do nosso dia-dia.

Pense sobre isto.

Grande abraço e sucesso a todos!

Eduardo Levenfeld

Leia mais aqui.

Auto Ajuda: Gerenciando melhor o seu tempo

Fala Pessoal, tudo bem? Espero que sim!

Hoje vamos falar sobre um assunto que atinge não somente a sua vida profissional como também a sua vida pessoal e qualidade de vida. O tempo.

Constantemente reclamamos por falta de tempo ou que o tempo passa muito rápido e não dá para fazer as atividades que gostamos e que nos geram qualidade de vida. Não é mesmo?

O escopo deste artigo não é acabar com todos seus problemas de tempo como um "0800 ligue já" (alguem se lembra daquele anuncio do walter mercado? risos) e sim fornecer dicas que possibilitem você gerenciar melhor a si mesmo no tempo que lhe é disponível cada dia, ou seja, otimizar as 24 horas de seu dia.

Vamos lá!

Compreenda que gerenciar completamente o tempo é um mito:
Por mais que sejamos organizados ao extremo, existem no seu dia sempre 24 horas. Em vez de querer dominar o tempo, domine e organize a si mesmo no tempo que lhe é possível, ou seja, saiba dividir suas tarefas e esforços com disciplina e inteligência nas 24 horas de seu dia.

Veja aonde você está desperdiçando seu tempo:
Eis um ponto crítico. Muitos de nós geralmente desperdiçamos tempo diariamente em atividades que não agragam valor nenhum em nossa vida. Se você quer começar a alavancar seu tempo com atividades que agreguem valor essa é uma análise valiosa. Se por acaso você tiver muita dificuldade peça a pessoas que te acompanham diariamente (como sua esposa e colega de trabalho) para que mantenham o olho em você. Pode ajudar, mas saiba que a sua auto análise é a melhor de todas.

Crie metas a serem cumpridas e acompanhe-as:
Lembre-se que seu foco é mudar e otimizar seus comportamentos e não mudar o tempo. Depois de identificar os vilões que desperdiçam seu tempo crie metas especificas a serem cumpridas e mantenha disciplina para cumprir-las durante uma ou duas semanas por exemplo. Após isso ficará mais fácil para você analisar os resultados de seus esforços e, consequentemente, se motivar mais ainda.

Tendo então cumprido as primeiras metas, verifique sempre oque pode otimizar para lhe dar mais produtividade e menos stress. Assim você terá um processo iterativo de planejamento de como usar seu tempo.

Use ferramentas de gerência de tempo se possível:
Existem diversas ferramentas (softwares) bacanas para facilitar e agilizar seu planejamento do uso de tempo. Antes de usar uma destas saiba oque você tem para fazer no momento e, se possível, posteriormente. Após levantar essas atividades é hora de delinear como você irá gastar seu tempo para cumprir-las. Se utilizando de um bom software como o Essential PIN (que você verá como baixar e usar ao fim neste mesmo artigo) ficará mais facil de construir um modelo visual de como será gasto seu tempo e, consequentemente, estimular este planejamento constante.

Tenha disciplina e saiba priorizar as tarefas certas:
Começe seu dia com uma sessão de planejamento priorizando as tarefas para o dia e de olho na sua performance. Por exemplo: Se você tem muitas tarefas para um determinado dia, qual delas você realmente tem que cumprir no dia? Isso vai lhe ajudar a manter o equilibrio entre sua performance e qualidade de vida (menos stress e mais tempo para gastar com a familia ou um hobby).

Aprenda a delegar e trabalhar em grupo:
Muitas vezes a gente prefere dar uma de "lobo solitário". Em certa dose as vezes é bom para ver como andam suas "estratégias de sobrevivência" e melhorar-las mas, quando isso se torna um vício você pode adquirir a mania de "super herói" que existe em muita gente (inclusive no autor aqui as vezes, risos).

Não importa o tamanho de seu negócio ou tarefa. Nem sempre é preciso ser um "exército de um homem só". Veja sempre as tarefas que não agregam muito valor e que podem ser delegadas a outras pessoas. Além disto sempre que possívem trabalhe em equipe a fim de otimizar o seu tempo e o desempenho na tarefa.

Adquira o costume de estipular limites de tempo para tarefas:
Certas tarefas cotidianas como ler os novos e-mails e ver oque seus amigos postaram no seu orkut, myspace, facebook e por ai vai, podem tomar seu dia inteiro se você quiser. Estipule um tempo limite para realizar tais tarefas diariamente (uma hora por exemplo) e não estique mais que isso.

Seja organizado:
Seja no sua casa, local de trabalho e até no seu computador a falta de organização pode levar muito do seu tempo precioso. Quem nunca ficou alguma vez rodando a casa atrás das chaves tendo algum compromisso em cima da hora. A desorganização causa isso.

Procure uma vez ou outra tirar um tempinho para organizar seu ambiente de trabalho, lar e até os arquivos de seu computador. Estando todas as coisas importantes e muito usadas em locais de fácil acesso, você irá economizar um bom tempo.

Não desperdice tempo apenas esperando:
É verdade que é impossível não enfrentar alguma espera uma vez ou outra durante nosso dia. Muitas vezes você está aguardando um cliente e ele te dá aquele "chá de cadeira" mas nem por isso você deve apenas ficar lá sentado desperdiçando seu tempo valioso.

Acostume-se a sempre levar algo de suas tarefas que você possa adiantar durante uma possível espera.

Um exemplo: Você está esperando o Dr. Fulano terminar uma reunião não notificada a você por ele para apresentar um proposta de serviço. Você atravessou a cidade para falar com o "bendito" e marcar para outro dia não seria interessante para você. Se você estiver com seu notebook, que tal adiantar algum documento ou e-mail pendente? Tem alguns telefonemas para fazer e está com seu celular? Esta pode ser a hora.

Espero que as dicas acima sejam valiosas para vocês que querem dar uma alavancada no tempo disponível!

Vamos agora falar do EssentialPIM como prometi!

Breve tutorial do EssentialPIM

Como prometi durante o texto acima, quando estava falando sobre ferramentas para gerenciar o tempo disponível, vamos conhecer agora o EssentialPIM que é uma ferramenta que tem uma versão gratuita acima da média.

Uma visão do programa

Na imagem acima que você podem clicar e conferir está a tela inicial do EssentialPIM. Na divisão esquerda podemos ver o de ações seguido do menu de sub-módulos (funcionalidades) e por fim um calendário do mês. Na divisão central estão os eventos para o dia atual e o de 2 dias seguintes com seus horários e icones de prioridade. Finalmente na divisão direita estão suas tarefas ou metas.

Baixando o programa
Agora que já vimos a "cara" do programa, podemos baixar a versão gratuita no seguinte endereço: http://www.essentialpim.com/download/essentialpim2.exe

Se quiser antes dê uma olhada no site do programa: http://www.essentialpim.com/

Mudando o idioma:

Clicando na foto acima podemos ver que para mudarmos o idioma para português (br) basta ir no menu superior e:

1. Clique em Tools (ferramentas);
2. Clique em Language (idioma);
3. Na lista que será exibida, clique em português (Brasil);

Pronto estamos com nosso programa em português! Vamos agora a mais algumas dicas.

Visualizando a agenda e inserindo um evento:

Para visualizar a sua agenda de eventos, clique no botão "agenda" do menu da divisão esquerda como mostra a foto. Ele abrirá na visão do dia. Veja que na divisão esquerda aparece lá em cima uma lista com as possiveis visões (dia, semana, mês, ano e tabela). Bacana não?

Para inserir um novo evento você pode clicar no botão adicionar que tem na divisão esquerda (na lista de ações) ou simplesmente clicar e arrastar o mouse sobre a linha de tempo (divisão principal) selecionando o periodo e depois soltando. Em ambos os casos aparecerá o seguinte formulário como na figura a seguir.

Veja que o formulário oferece uma gama de dados bem completa (titulo, prioridade, local, categoria, etc.). Dê uma olhada em cada opção e preencha o necessário. Após ter feito isto clique em ok e seu evento será inserido (você o verá representado visualmente na linha de tempo).

Vamos agora por último ver como inserir uma tarefa ou meta (task).

Inserindo uma tarefa ou meta
No mesmo menu da divisão esquerda onde você clicou no botão "agenda", logo abaixo, você verá o botão tarefas. Clique nele e você verá uma tela semelhante à da próxima imagem.

Para inserir uma tarefa clique e adicionar no alto da divisão esquerda. Após isso ira surgir um formulário semelhante ao que usamos para inserir um evento. Após preencher-lo devidamente a tarefa será adicionada na listagem que aparece na divisão principal (tarefas). Após isso ela (a tarefa) ficará lá até que você a apague ou clique na caixinha de seleção ao lado dela para indicar que já já foi cumprida.

Bom pessoal, além destas funcionalidades que mostrei existem ainda a agenda de contatos e repositório de anotações (notas). Explorem bem o programa se acharem que precisam e verão que em termos de programa gratuito ele é uma solução bem completa e bem feita.

Espero ter ajudado a todos com este artigo. Até ao próximo!

Um abraço e sucesso a todos!

Eduardo Levenfeld

Leia mais aqui.