Hoje, no mundo corporativo ainda é muito comum vermos líderes arrogantes e sem humildade. E isso leva a quê? Nada.
Veja bem, não existe projeto ou bem viver em um time que se adeque a esta forma.
O líder é o exemplo e a direção. Então, porque não começar a mudar os paradigmas?
A seguir cito os pontos que considero chaves de liderança.
São eles:
-HUMILDADE
-ORGANIZAÇÃO
-HUMOR
-EQUILÍBRIO E TRANQUILIDADE
-ACEITAR QUE EXISTEM PESSOAS DIFERENTES
-CONFIANÇA NOS LIDERADOS
-PROVER CAPACITAÇÃO
-MOTIVAÇÃO
Vocês concordam?
Abordaremos cada um de uma forma simples e rápida.
- HUMILDADE
Os Líderes devem ter humildade(Fazer auto-avaliação).
O fato de ser o líder não implica saber de tudo, achar que não pode falhar. Deve ter humildade e coerência para assumir que não é auto-suficiente para tudo.
Bom líder é aquele que transmite feedback e recebe da forma mais humilde, mesmo que este sejam críticas. Pegue-as e melhore.
Não existe mais espaço para líderes arrogantes, donos da verdade, Egocêntricos e orgulhosos.
Humildade por muitas vezes é difícil e um processo demorado, mas trabalhando, todos podemos evoluir.
- ORGANIZAÇÃO
Mesmo que muitos não percebam, o líder é o espelho e o exemplo dos seus liderados.
Mantenha a equipe afinada, onde cada membro tem uma função específica na “orquestra”.
Aprenda a organizar a equipe nos momentos de “Desespero”.
Transmita isto aos seus liderados que eles receberão e se sentirão mais seguros e organizados.
- HUMOR
Seus líderados não tem culpa dos seus problemas externos, ou de uma noite mal dormida, ou qualquer que seja a razão.
Mantenha o sorriso no rosto. O líder deve ter ciência que a criação de um clima descontraído favorece a confiança, o respeito e uma melhor aceitação por parte da equipe. Uma atmosfera mais livre e aberta encoraja a sensação de que as pessoas estão realmente engajadas no processo.
Entre no ambiente de trabalho com um sorriso radiante e diga bom dia, seu sorriso e bom humor irá transmitir alegria e tranquilidade para um dia de trabalho.
Um sorriso anima sua alma e engrandece a felicidade.
"Quem sorri estimula o cérebro a liberar endorfina e serotonina — substâncias responsáveis pela sensação de prazer e felicidade.
Essas substâncias proporcionam uma sensação de leveza e bem-estar, além de ativarem o sistema imunológico. Essa imunização ajuda a prevenir,
principalmente, doenças ocasionadas por elevado grau de estresse."
Fonte: http://belezaesaude.dae.com.br/sorrir-faz-bem-a-saude/
- EQUILÍBRIO E TRANQUILIDADE
São umas das maiores virtudes de um líder, independente do tipo de problema e das raivas que nos aflingem em determinados momentos, o líder não deve "Sair do Salto" como dizem. Transmitir o equilíbrio e tranquilidade nos momentos mais difíceis, tranquilizam os liderados e dão forças tanto a você quanto a eles a saírem da situação de forma grandiosa e sábia.
Não esqueçam: O líder JAMAIS pode perder o controle.
- ACEITAR QUE EXISTEM PESSOAS DIFERENTES
Respeitar as pessoas como são e harmonizá-los com a finalidade de alcançar um objetivo comum.Pessoas têm idades e vivências diferentes. O líder deve saber que é bom tratar o próximo como gostaria de ser tratado e a distância entre as pessoas vai diminuir bastante.
Aceitando diferenças conseguiremos coletar o que há de bom em cada um e equilibraremos nossa orquestra.
- CONFIANÇA NOS LIDERADOS
Confiar nos liderados e mostrar a confiança combina com "Projeto de Sucesso"
Vou citar um exemplo de confiança do filme "Tropa de Elite 1". Em uma das cenas, o capitão Nascimento coloca uma granada sem o grampo nas mãos do aspirante André, para que ele fique acordado. Mas isto foi uma forma de dizer, se você dormir todos nós morreremos. Ótimo exemplo de confiança e sentindo o peso do que lhe foi dado, André não dormiu e evitou que todo time(de aspirantes) morressem por um erro dele.
Coloque a granada nas mãos de seus liderados, faça-os sentir que eles são parte importantes do projeto e que você confia, eles conseguirão.
- PROVER CAPACITAÇÃO
O líder deve ser o responsável pelo aprendizado dos membros de sua equipe, verificar os pontos e melhorias e procurar encontrar formas e treinamentos
que os façam crescer profissionalmente e pessoalmente. Além disso ele deve ser uma pessoa que seja capaz de entender e acelerar a aprendizagem e, ao mesmo tempo, incentivar e integrar o pensar de seus membros e tirar deles o melhor que possuem em benefício de todos.
Treinamento é caro, mas não treinar é mais caro ainda.
- MOTIVAÇÃO
O que motiva os liderados além do óbvio?
* Familiaridade e Solidariedade em Ambiente de Trabalho.
* Valorização pela parte do Chefe quando é feito um bom trabalho
* Amar os Liderados:
Ame as pessoas e as pessoas te amarão!!
Tem bronca? Tem.
Tem puxão de orelha? Tem.
Mas deve ter amor e reconhecimento, pois o reconhecimento toca o coração das pessoas!
CONCLUSÃO
Caros colegas e leitores. Façamos por merecer essa responsabilidade maravilhosa que nos foi dada e seremos bem recompensados.
“UM EXÉRCITO DE OVELHAS LIDERADOS POR UM LEÃO DERROTARIA UM EXÉRCITO DE LEÕES LIDERADO POR UMA OVELHA”. Provérbio árabe.
quinta-feira, 24 de fevereiro de 2011
quarta-feira, 2 de fevereiro de 2011
Verificação de Escopo Método Tradicional x Metodologia Ágil Scrum
Definição: "A verificação do escopo é o processo de obtenção da aceitação formal pelas partes interessadas do escopo do projeto terminado e das entregas associadas. A verificação do escopo do projeto inclui a revisão das entregas para garantir que cada uma delas foi terminada de forma satisfatória. Se o projeto foi finalizado antes do término (abortado), o processo de verificação do escopo do projeto deve determinar e documentar o nível e a extensão do término.
A verificação do escopo do projeto ocorre em determinados momentos:
* No final do projeto
* No final de fase do projeto
* Na entrega dos principais produtos finais dentro do projeto. “
Fonte: http://www.tenstep.com.br/br/TenStepPB/open/5.4.htm
A verificação de escopo, é uma das partes mais importantes, necessárias e por muitas vezes mais esquecidas de um projeto.
A seguir uma comparação de verificação de escopo em projetos de desenvolvimento de Software utilizando abordagens diferentes.
Analisando o contexto baseado no método tradicional.
A verificação de escopo no método tradicional é focada na assinatura do cliente.
Podemos considerar a verificação do Escopo feita quando o documento está assinado?
Caros colegas e profissionais, sejamos coerentes e realistas. Quantos de nós paramos pra pensar que dependendo do tipo de documento, enviado ao cliente, ele não entende nada do que foi dito/escrito?
Por exemplo, algumas verificações de escopo das que já vi e participei são feitas através de documentos de casos de uso. Agora eu me pergunto, quantos clientes nossos sabem o que são casos de uso? O que vocês acham que uma pessoa leiga pensa quando os vê? "Oh, o que são essas bolinhas e estes bonecos aqui? Tem descrição, mas não estou entendendo nada. Vou assinar pra pular este parte chata e depois tento entender". Cômico, mas infelizmente verdadeiro. Não acontece assim em vossos projetos?
Se uma verificação de escopo feita através de documentação é realizada, devemos nos concentrar em fazer uma apresentação clara e sucinta do que queremos aprovar.
Utilizando o caso anterior, por que não reunir com o cliente e realizar uma apresentação visual do que signifa cada parte da descrição do documento?
Não falo em encher o cliente lendo 300 páginas, mas sim mostrar as funcionalidades do produto, o que vai gerar, quem irá interagir, como, quantos relatórios poderão ser emitidos, quando, etc.
Você pode me dizer: Também fazemos verificações de escopo com protótipos do produto. Sim, mas o protótipo já aparece em uma fase que o documento de requisitos e de casos de uso já foram validados, podendo assim termos perdido alguma informação importante da visão do cliente, causando assim modificações grandes no projeto.
Não devemos nos prender SÓ na assinatura da documentação, é importante sim e muito, pois temos que ter a prova de que o escopo foi aprovado, mas o mais importante é termos em mente que, para que o documento seja assinado, o que estamos querendo passar na realidade ao cliente, deve ser entendido e se, dúvidas houverem, que as mesmas sejam clarificadas, para somente depois, pegarmos a assinatura formal.
Passando para a análise em cima do método Ágil.
Verificação de escopo no método ágil é focada, na aprovação seja ela formal ou informal do cliente com o que foi mostrado(Parte do produto pronto) ao final de cada sprint.
O gerenciamento de Escopo no Scrum, não está descrito como entrega de aceitação formal, escrita, assinada, carimbada, mas vocês querem ver como funciona?
Vejam bem, no Scrum existe uma fase no meio processo que é exigida e sem ela o projeto não continua, ela se chama Sprint Review Meeting e deve ser obrigatoriamente realizada ao final de cada Sprint, seja ele de uma semana ou um mês, de acordo como o time definiu. Esta fase é mais tradicionalmente conhecido como “Verificação de Escopo”, não é legal?
Definição: “Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting.”
Fonte: http://improveit.com.br/scrum/sprint_review_meeting
O que isso significa? Reunir com o cliente ao final de cada sprint, mostrar os requisitos planejados para a sprint, os que foram realizados em forma de produto e checar se está tudo como ele imaginava. Caso não esteja, preparar os ajustes para os próximos sprints, caso apareçam novas features, inserir no Product Backlog e repriorizar.
Qual o diferencial da verificação de Escopo no Scrum? Ele não te prende a documentação, mas sim na aceitação do cliente em uma reunião em que o mesmo deve estar presente, e o mais importante, te força a não passar para um outro sprint sem que o cliente, tenha visto e aceitado o produto desenvolvido.
Não é mais fácil e inteligente termos o cliente por perto sempre, tirando as dúvidas e clarificando constantemente os requisitos presencialmente? Ao invés de escrevermos os requisitos uma vez, revisarmos e aprovarmos, e quando chegarmos no fim, descobrirmos que não fizemos o que o cliente esperava.
Pensem comigo, quantos clientes, sabem exatamente o que querem logo de primeira? Podemos revisar os requistos com ele a cada três meses ou conforme definido, a verdade é que ele nunca tem certeza do produto final esperado.
Então, não é melhor acompanharmos a evolução de suas idéias em um período de tempo mais curto e constante?
Por outro lado, temos que nos preocupar neste caso, em encontrarmos uma forma mais "amigável" de aceitação formal com o cliente. Muitas vezes clientes do Scrum confundem agilidade com falta de documentação e isso deve ser tratado logo que possível.
Conclusões
Nesses moldes e nas experiências que tive, considero que hoje em muitos dos casos utilizando o tradicional, seria bom pararmos de olhar para o Scrum com olhos desconfiados e aplicarmos as boas práticas quando necessário. O mesmo vale para os seguidores fiéis do Scrum, que já olham assustados para o tradicional e pensando em documentação desnecessária.
Os dois métodos funcionam e muito bem, mas devem ser analisados e melhorados em cada organização onde o método escolhido é aplicado, para que possamos ter a garantia de que não estamos preenchendo/assinando documento, ou reunindo com o cliente apenas com o intuito de seguir o processo obrigatório em sua empresa.
Olhemos para nossas organizações e sejamos coerentes, sugerindo ajustes ou melhorias de acordo com os objetivos de cada uma.
A verificação do escopo do projeto ocorre em determinados momentos:
* No final do projeto
* No final de fase do projeto
* Na entrega dos principais produtos finais dentro do projeto. “
Fonte: http://www.tenstep.com.br/br/TenStepPB/open/5.4.htm
A verificação de escopo, é uma das partes mais importantes, necessárias e por muitas vezes mais esquecidas de um projeto.
A seguir uma comparação de verificação de escopo em projetos de desenvolvimento de Software utilizando abordagens diferentes.
Analisando o contexto baseado no método tradicional.
A verificação de escopo no método tradicional é focada na assinatura do cliente.
Podemos considerar a verificação do Escopo feita quando o documento está assinado?
Caros colegas e profissionais, sejamos coerentes e realistas. Quantos de nós paramos pra pensar que dependendo do tipo de documento, enviado ao cliente, ele não entende nada do que foi dito/escrito?
Por exemplo, algumas verificações de escopo das que já vi e participei são feitas através de documentos de casos de uso. Agora eu me pergunto, quantos clientes nossos sabem o que são casos de uso? O que vocês acham que uma pessoa leiga pensa quando os vê? "Oh, o que são essas bolinhas e estes bonecos aqui? Tem descrição, mas não estou entendendo nada. Vou assinar pra pular este parte chata e depois tento entender". Cômico, mas infelizmente verdadeiro. Não acontece assim em vossos projetos?
Se uma verificação de escopo feita através de documentação é realizada, devemos nos concentrar em fazer uma apresentação clara e sucinta do que queremos aprovar.
Utilizando o caso anterior, por que não reunir com o cliente e realizar uma apresentação visual do que signifa cada parte da descrição do documento?
Não falo em encher o cliente lendo 300 páginas, mas sim mostrar as funcionalidades do produto, o que vai gerar, quem irá interagir, como, quantos relatórios poderão ser emitidos, quando, etc.
Você pode me dizer: Também fazemos verificações de escopo com protótipos do produto. Sim, mas o protótipo já aparece em uma fase que o documento de requisitos e de casos de uso já foram validados, podendo assim termos perdido alguma informação importante da visão do cliente, causando assim modificações grandes no projeto.
Não devemos nos prender SÓ na assinatura da documentação, é importante sim e muito, pois temos que ter a prova de que o escopo foi aprovado, mas o mais importante é termos em mente que, para que o documento seja assinado, o que estamos querendo passar na realidade ao cliente, deve ser entendido e se, dúvidas houverem, que as mesmas sejam clarificadas, para somente depois, pegarmos a assinatura formal.
Passando para a análise em cima do método Ágil.
Verificação de escopo no método ágil é focada, na aprovação seja ela formal ou informal do cliente com o que foi mostrado(Parte do produto pronto) ao final de cada sprint.
O gerenciamento de Escopo no Scrum, não está descrito como entrega de aceitação formal, escrita, assinada, carimbada, mas vocês querem ver como funciona?
Vejam bem, no Scrum existe uma fase no meio processo que é exigida e sem ela o projeto não continua, ela se chama Sprint Review Meeting e deve ser obrigatoriamente realizada ao final de cada Sprint, seja ele de uma semana ou um mês, de acordo como o time definiu. Esta fase é mais tradicionalmente conhecido como “Verificação de Escopo”, não é legal?
Definição: “Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting.”
Fonte: http://improveit.com.br/scrum/sprint_review_meeting
O que isso significa? Reunir com o cliente ao final de cada sprint, mostrar os requisitos planejados para a sprint, os que foram realizados em forma de produto e checar se está tudo como ele imaginava. Caso não esteja, preparar os ajustes para os próximos sprints, caso apareçam novas features, inserir no Product Backlog e repriorizar.
Qual o diferencial da verificação de Escopo no Scrum? Ele não te prende a documentação, mas sim na aceitação do cliente em uma reunião em que o mesmo deve estar presente, e o mais importante, te força a não passar para um outro sprint sem que o cliente, tenha visto e aceitado o produto desenvolvido.
Não é mais fácil e inteligente termos o cliente por perto sempre, tirando as dúvidas e clarificando constantemente os requisitos presencialmente? Ao invés de escrevermos os requisitos uma vez, revisarmos e aprovarmos, e quando chegarmos no fim, descobrirmos que não fizemos o que o cliente esperava.
Pensem comigo, quantos clientes, sabem exatamente o que querem logo de primeira? Podemos revisar os requistos com ele a cada três meses ou conforme definido, a verdade é que ele nunca tem certeza do produto final esperado.
Então, não é melhor acompanharmos a evolução de suas idéias em um período de tempo mais curto e constante?
Por outro lado, temos que nos preocupar neste caso, em encontrarmos uma forma mais "amigável" de aceitação formal com o cliente. Muitas vezes clientes do Scrum confundem agilidade com falta de documentação e isso deve ser tratado logo que possível.
Conclusões
Nesses moldes e nas experiências que tive, considero que hoje em muitos dos casos utilizando o tradicional, seria bom pararmos de olhar para o Scrum com olhos desconfiados e aplicarmos as boas práticas quando necessário. O mesmo vale para os seguidores fiéis do Scrum, que já olham assustados para o tradicional e pensando em documentação desnecessária.
Os dois métodos funcionam e muito bem, mas devem ser analisados e melhorados em cada organização onde o método escolhido é aplicado, para que possamos ter a garantia de que não estamos preenchendo/assinando documento, ou reunindo com o cliente apenas com o intuito de seguir o processo obrigatório em sua empresa.
Olhemos para nossas organizações e sejamos coerentes, sugerindo ajustes ou melhorias de acordo com os objetivos de cada uma.
Assinar:
Postagens (Atom)

