PROJETO 001

Agora estou no Kudoos!

noreply@blogger.com (Rafael Buzon) — Tue, 05 Mar 2013 13:48:00 +0000

Pessoal, a partir de agora estou escrevendo no blog kudoos!

http://blog.kudoos.com.br

Que busca melhorar a gestão ágil no Brasil.

Kudoos para vocês! Nos vemos lá!

O Kanbanzão é um kanbalacho

noreply@blogger.com (Rafael Buzon) — Tue, 11 Sep 2012 01:58:00 +0000

http://zooa.files.wordpress.com

Já percebeu algumas pessoas comentando "Ah! Vamos fazer um kanbanzão mesmo" como se o kanban fosse a coisa mais fácil do mundo. O reduto dos que querem se livrar de processos, cerimônias e tornar as coisas "mais fáceis". Como se o Kanban foi a bala de prata!

O fato é que, todo kanbanzão é um kanbalacho! Preste atenção, pois o Kanban vem com um dispositivo acelerador que te conduz rapidamente: tanto para o sucesso quanto para o fracasso! (E não estou falando de fail fast)

"Eu só queria dizer" ;-)

Daily Kanban: As 3 perguntas revisadas do Scrum

noreply@blogger.com (Rafael Buzon) — Mon, 10 Sep 2012 01:42:00 +0000

improveit.com.br

Recentemente, na Abril, temos migrado algumas equipes de Scrum para Kanban ou aplicado Kanban sobre o Scrum em alguns casos. Quando esta migração, ou adição, acontece, sempre surgem as dúvidas sobre manter ou não as cerimônias do Scrum e, se forem mantidas, o que teriam de diferente.

Neste post busquei abordar a cerimônia do daily aplicado num contexto Kanban e sugiro a revisão das 3 perguntas do daily Scrum para refletir princípios Kanban.

O daily (ou reunião diária) do Scrum, visa reunir o time em torno do trabalho em andamento, durante até 15 minutos, para ouvir de cada membro:

O que fez até aquele momento;
O que fará em seguida; e
Se há algo o impedindo de progredir.

Esta cerimônia também busca manter o time em sinergia com a meta do sprint, pois é de interesse de todos que a meta seja atingida. Por isso compartilham suas atividades diárias.

Håkan Forss, consultor de Kanban da Suécia, influenciado pelo livro Toyota Kata de Mike Rother, sugeriu que no Kanban também haveria a necessidade do daily, que elencou como um de seus três kata.

Kata is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs. The term form is used for the corresponding concept in non-Japanese martial arts in general. (Wikipedia)

O daily como um dos kata seria a cerimônia que provocaria eventos locais de kaizen [melhoria contínua]
(fonte: InfoQ Brasil)

Sendo o daily, então, importante também no método Kanban: Como seria o ritual do time em torno do quadro nesta cerimônia?

David Anderson, pioneiro na utilização e propagação do método Kanban para o desenvolvimento de software, apresenta em seu livro Kanban, o que chamou de Filtros de decisão Lean:

Valor é mais importante que fluxo;
Fluxo é mais importante que eliminação de desperdício;
Eliminação de desperdício é mais importante que melhorar a eficiência.

Com base neste "filtro de decisão Lean" escolhi algumas perguntas que poderiam ser realizadas, portanto, durante o daily Kanban. São elas:

O que fez de valor até agora?

Está seguindo as políticas explícitas?

O que pode fazer pelo gargalo?

Como é uma reunião diária é importante que continue não passando dos 15 minutos, mas aproveite-os ao máximo com sua equipe.

Acredito também que num contexto Kanban, que busca a perfeição, cada assunto pode gerar discussões importantes sobre como otimizar o processo, mas cabe ao moderador (Kanban Master?) controlar o tempo, tomar nota e conduzir outras sessões específicas, se houver necessidade.

Cada perguntas tem um apelo único:

A pergunta, o que fez de valor até agora, indaga de forma séria e leva à reflexão sobre estar diariamente com foco na entrega de valor ao cliente.

A segunda pergunta busca disciplinar e potencializar o fluxo focando as políticas já definidas. Tem uma proposta mais focada e menos reflexiva.

A última pergunta oferece uma oportunidade para os membros pensarem no todo, em estágios diferentes dos que trabalha comumente, além de criar ações para também melhorar o fluxo.

Ao pensar nas três perguntas do daily, outras me vieram à mente, mas que acredito que possam ser feitas com uma frequência menor (semanalmente, por exemplo), como:

Quais e como tratar os desperdícios que estou enxergando no fluxo?
Mudaria alguma política explícita?
Nosso limite de WIP para cada estágio está adequado?
O fluxo do meu estágio está contínuo?
Estamos entregando valor?
O que o gráfico CFD nos diz?
Estamos ouvindo o quadro?

Em outros posts tentarei abordar mais perguntas e cerimônias adaptadas do Scrum para o kanban.

Você teria sugestões diferentes para as 3 perguntas no daily kanban? Compartilhe!

Kanban: Como começar?

noreply@blogger.com (Rafael Buzon) — Tue, 24 Jul 2012 12:00:00 +0000

Minhas anotações do Dia 01 com David Anderson

O mapa mental ao lado é o compilado do primeiro dia de treinamento com David Anderson: o pioneiro no mundo na aplicação do método Kanban para desenvolvimento de software.

O método vem se popularizando e muito se discute sobre ser o próximo passo após o Scrum.

O fato, porém, é que o Kanban não encerra, em si, uma metodologia completa. É, como costumo dizer, suficientemente incompleto.

Uma aplicação Kanban é (numa tentativa de criar uma boa metáfora) um "vírus do bem" com o qual você contamina seu atual sistema. O vírus começa gerando um sintoma imediato em seu sistema que é a visualização do todo e permite um entendimento e compreensão melhor de como o trabalho flui em sua cadeia de valor. Em seguida o "vírus" começa atacando células não-saudáveis, como células de gordura (desperdícios); órgãos em dessintonia; e auxilia no fluxo sanguíneo (no fluxo de valor).

Metáforas a parte, David Anderson recomenda o seguinte, quando for aplicar o método Kanban:

Comece com o que você já tem
O Kanban pode (e é recomendado) ser aplicado sobre a metodologia que você já usa e com que sua empresa já está acostumada. Como comentado, o kanban atuará como um vírus, ressaltando pontos falhos e melhorias a serem feitas no seu atual processo. Isso também auxilia na mudança, uma vez que não há intervenções radicais no modo como as pessoas fazem seus trabalhos.

Busque melhorias incrementais
Uma vez inserido o vírus, ouça o que ele tem a dizer. Realize pequenas melhorias, uma de cada vez, permitindo que o entendimento das mudanças colabore com a aceitação das mesmas.

Respeite os atuais papéis e cargos
Mais uma vez, o Kanban não precisa ser intrusivo. É possível e recomendado manter a atual estrutura organizacional até que o Kanban explicite o contrário. Quando e se isso acontecer, veja quais as melhorias alternativas para unir papéis, criar desenvolvimento concorrente, otimizar a equipe e, por fim, revê-los.

Incentive a liderança em todos os níveis
A liderança em todos os níveis diz respeito a autonomia e coragem para realizar as mudanças que precisam ser feitas. Sem a liderança seria mais difícil manter um ambiente Kaizen onde toda simples melhoria contribui para o todo.

E você? Tem aplicado Kanban em sua organização? Como tem sido?

O Kanban no atendimento do McDonald's

noreply@blogger.com (Rafael Buzon) — Wed, 18 Jul 2012 19:32:00 +0000

http://www.malaguetanews.com.br

Já reparou no sistema Kanban que existe no atendimento ao cliente do McDonald's?

O fluxo todo é puxado pelo cliente assim que ele faz o pedido. Um lanche, por sua vez, só é produzido se houver um pedido realizado (ou trabalham com estoque mínimo com objetivo de ter pronta entrega, mas também não permitindo a entrega de lanches frios ao cliente).

O valor que o cliente almeja é ter um lanche padronizado, de qualidade e entregue rápido (modelo fast food).

A cadeia de valor pode ter as fases abaixo [minha sugestão simplificada]

Realização do pedido
Produção do lanche
Montagem do combo [na maioria dos casos]
Entrega ao cliente

Agora veja como o sistema visual funciona:

http://jbchost.com.br

O limite do trabalho em progresso (Work In Progress) é dado pela quantidade de bandejas que cabem ao lado do caixa (geralmente umas 4).

Cada bandeja representa um slot para ser preenchido que irá "puxar" todas as demais fases. Uma vez preenchido o espaço para as bandejas (limite da fase de Realização do pedido) é possível observar que acontece um swarming (que @leonardocampos prefere traduzir como "mutirão") em que o atendente sai de sua posição para auxiliar a fase de Montagem do combo, pois não faz mais sentido continuar gerando pedidos para um sistema que está "engargalado" na entrega dos combos já pedidos.

Por certo trabalham também com políticas explícitas em cada fase para manter o padrão de qualidade e procuram otimização contínua dos processos revendo o que está sendo gargalo e eliminando desperdícios.

Achei bem interessante esta perspectiva, de um kanban sem o quadro tradicional, mas com todos os efeitos visuais importantes. Acho que tem até um Kanban Master por lá. :)

O Kanban Master

noreply@blogger.com (Rafael Buzon) — Tue, 17 Jul 2012 12:00:00 +0000

O Kanban não prescreve papéis, mas diz somente o mínimo necessário para você ter uma aplicação Lean eficaz. Entretanto, recomendo fortemente que você tenha um, assim chamado, Kanban Master (em analogia ao ScrumMaster, do Scrum).
Apesar de ser um framework (se posso assim dizer) mínimo, o Kanban exige uma disciplina muito grande e uma postura proativa mais forte que em outras práticas. A questão gira toda em torno dos princípios Lean, em se Limitar o trabalho em progresso, identificar gargalos, revisar constantemente a cadeia de valor, conduzir o fluxo puxado pelo cliente, ou seja, todas atitudes conscientes e ativas das pessoas que trabalham sob estas filosofias.

Além disso, o Kanban é incompleto por natureza. Requer algumas cerimônias, práticas, abordagens complementares que serão necessárias para se adequar ao contexto organizacional e ao time. Logo, arrisco dizer que o Kanban Master aqui proposto, na verdade, é um Agente de Mudança, pois sua atuação precisa ir além de apenas Kanban e atuar em tudo o que é desperdício, gargalo, política empresarial e pessoas.

Como você tem usado Kanban em sua organização? Você tem Agente de Mudanças no seu projeto Kanban?

Ouvindo o quadro kanban

noreply@blogger.com (Rafael Buzon) — Mon, 16 Jul 2012 11:00:00 +0000

http://www.metro.co.uk/

Mostre-me seu quadro e te direi quem és!

Tenho trabalhado com algumas implementações Kanban para desenvolvimento de software e tenho percebido que um bom indicador para se averiguar a "saúde" de um projeto é a analise do quadro kanban do time.

O quadro espelha não somente o andamento dos itens na cadeia de valor, mas é possível "sentir", até mesmo, o ânimo do time no projeto.

Em uma olhada rápida e superficial já é possível observar o zelo do time pelo quadro: se mantêm os cartões (ou post-its) organizados, alinhados e bem escritos; se está sujo com traços antigos de pincel, se as marcações e políticas explícitas estão realmente explícitas, enfim, se pelo menos a disposição visual dos elementos estão adequadas e bem mantidas.

Parece exagero, mas são detalhes que fazem (e expressam) a diferença. Ter as políticas explícitas, por exemplo, apagadas ou parcialmente visíveis, pode ser um indicador de que o time não dá a mínima para elas e algo pode estar errado no projeto. Ou ainda pode dizer que as políticas explícitas já não fazem mais sentido e nem precisariam estar no quadro. Este último exemplo mostra que o time está se questionando pouco e não aplicando melhoria contínua bem.

"Ouvir o quadro" é algo essencial. A partir do momento que você mapeia sua cadeia de valor e dispõe os itens de trabalho no quadro kanban, o quadro começa a sussurrar o que precisa ser feito. Mas é preciso estar atento para ouvi-lo.

Em dado momento o limite de trabalho em andamento está ultrapassado (limite do WIP); as colunas começam a ficar cheias sem a devida atenção; alguns princípios começam a ser ignorados para dar uma "falsa" sensação de progresso, como ignorar gargalos importantes; o quadro não é revisado e a cadeia de valor se mantem a mesma, mesmo não fazendo mais sentido... Em pouco tempo, se não tomar os cuidados devidos, você terá um quadro kanban caótico ou pior: será apenas um mero quadro de post its na parede.

Implementar Kanban, na minha humilde opinião, exige mais disciplina e cuidado que implementar outras práticas, como Scrum. Isso porque o Kanban é pouco prescritivo, ou seja, defini poucas regras, mas que devem ser estritamente cumpridas.

O kanban necessita, em muitos casos, complementos para se adequar ao time, ao contexto organizacional e a planejamentos e revisões importantes. Ou seja, é um framework mínimo que dita algumas leis importantes, mas requer complementos, liderança e disciplina. Uma das leis é a melhoria contínua e isso só acontece abrindo bem os ouvidos para ouvir o quadro que sussurra dicas importantes.

E você... já parou para ouvir seu quadro kanban?

Lean Coffee São Paulo: A origem

noreply@blogger.com (Rafael Buzon) — Sun, 17 Jun 2012 22:08:00 +0000

Ontem (16/06) realizamos o primeiro Lean Coffee São Paulo, o primeiro encontro deste tipo no Brasil.

O Lean é uma filosofia originada na Toyota na década de 40, que visa a eliminação de desperdícios e tem, na versão adaptada ao contexto do software, 7 princípios:

Eliminar desperdícios
Amplificar o aprendizado/conhecimento
Decidir o mais tarde possível
Entregar o mais rápido possível
Dar autonomia ao time
Construir integridade
Visualizar o todo

Uma aplicação da filosofia Lean é o método Kanban [sinal visual, em japonês] e que vem ganhando espaço no cenário de desenvolvimento de software e gerando discussões na comunidade ágil sobre seu uso substituíndo o Scrum, em alguns casos.

Polêmicas à parte, ontem foi um dia muito interessante, pois conseguimos reunir algumas pessoas que estão estudando e aplicando práticas Lean na comunidade de desenvolvimento de sistemas e pudemos trocar ideias e compartilhar experiências valorosas.

Vejam as fotos do encontro, curta nossa página no Facebook e se sinta convidado a participar do próximo Lean Coffee dia 21/07/12. Acompanhe as próximas notícias no blog do evento.

As histórias e requisitos limitam pensar "fora da caixa"?

noreply@blogger.com (Rafael Buzon) — Fri, 11 May 2012 02:13:00 +0000

Sabemos hoje que realizar um planejamento completo e detalhado do projeto antes de efetivamente realizar alguma coisa, é perda de tempo [não veja este link]

Hoje buscamos compreender melhor o que gera valor ao cliente, antes de sair escrevendo e detalhando como iremos fazer a coisa errada.

No Scrum, por exemplo, buscamos realizar o planejamento do que será feito [e como será feito] o mais tarde possível e de forma iterativa, a fim de que seja possível ter e vivenciar uma maior quantidade de cenários, que irão retroalimentar os novos planejamentos.

E o que direciona o planejamento de um sprint, no Scrum, é a Meta.

A Meta retrata um objetivo claro e busca trazer propósito ao Sprint a fim de motivar e fundamentar o time possibilitando-o tomar micro-decisões diárias em prol do alcance da meta. A meta é a coisa mais importante no sprint e pela qual o time emprega seu tempo e conhecimento diariamete. A meta é mais importante que o plano feito para atingi-la.

Munido de uma meta nobre, clara e desafiadora, o time busca então planejar o sprint [na cerimônia de Planning] transcrevendo a meta em itens menores, concretos e factíveis. Em algumas práticas damos o nome de história a este item que representa uma unidade valorosa, independente, testável, factível e pequena.

As histórias representam um planejamento mais "leve" do quê será feito, mas que não deixa de ser um planejamento preliminar. E aqui chegamos ao ponto que quero questionar: Estariam as histórias, por serem definidas, criadas e detalhadas no início do sprint, tendo o mesmo efeito daquele antigo plano de projeto fixo que limita possíveis ações "fora da caixa"?

Recentemente presenciamos uma epifania interessante em um dos sprints de um projeto: Após o planejamento ser feito e o sprint iniciado, o time encontrou uma maneira mais simples, rápida e eficaz para atingir a meta proposta, sem, contudo, realizar todas as histórias planejadas para atingi-la. O que me levou a pensar: porventura não estaríamos em todos os demais sprints, muito condicionados à realização das histórias planejadas que deixamos de pensar "fora da caixa" em busca de soluções mais simples e completas? Quanto tempo e dinheiro poderíamos ter poupado, olhando mais a meta que as histórias? De fato, não é a meta a coisa mais importante a ser feita?

E você? O que acha? Também acredita que as histórias podem limitar ações excepcionais, inovadoras que contribuem para realizar a meta de maneira mais rápida e menos custosa? Como estimular o pensamento "fora da caixa" neste caso?

Business Model Canvas: Entendendo um modelo de negócio já existente

noreply@blogger.com (Rafael Buzon) — Sun, 22 Apr 2012 18:34:00 +0000

Business Model Canvas - Entendendo um modelo existente

Recentemente utilizei o Business Model Canvas com minha esposa com a finalidade de entender, pela perspectiva do marketing, um modelo de negócio já consolidado.

Optamos pelo Business Model Canvas, pois minha esposa fora recém contratada em uma empresa e precisava entender rapidamente a base conceitual e estrutural do produto para o qual iria realizar ações de marketing.

Além de entender como o produto é, também foi possível gerar drivers sobre como melhorar o produto e como explorar oportunidades.

Realizamos o Canvas (figura acima) em aproximadamente 3 horas focadas, com um intervalo de 15 minutuos. Neste período, discutimos e avaliamos cada hipótese e cada cenário possível, a fim de que, mesmo não sendo exatamente o modelo real (que se averiguaria posteriormente), fosse possível pelo menos criar condições para uma discussão e para o refinamento do modelo com os demais colegas de trabalho.

Abaixo um foco melhor na área direita do Canvas:

Lado direito do BMC - Segmentos de Clientes, Valores, Canais e Relacionamento

Introdução a Gestão Ágil de projetos de software

noreply@blogger.com (Rafael Buzon) — Wed, 11 Apr 2012 23:45:00 +0000

Esta apresentação foi feita para explicar como as práticas ágeis de gestão vieram para solucionar problemas da nova era do conhecimento.

O software é algo criativo e artístico e precisa ser gerido como tal. Os fatores motivacionais de times que trabalham com software e a própria forma de trabalho são diferentes e precisam de abordagens diferenciadas para se obter os melhores resultados.

Caso contrário, para um martelo, todo problema é um prego!

Introdução gestão agil de projetos de software

Veja mais apresentações de Rafael Buzon

Lei de software - Inovação - Startup

noreply@blogger.com (Rafael Buzon) — Sat, 07 Apr 2012 13:06:00 +0000

From wikepedia

Existe (ou existiu) uma grande discussão sobre o software ser protegido por uma lei de direito autoral ou de patente. No caso do Brasil, a Lei de Software 9609/98 diz que a natureza de um software é mais parecida com a de um livro que com a de um produto passível de patente. E eu admito concordar com isso...

O resultado final de um software é a expressão de uma ideia, de um conceito, de uma aplicação para determinado fim. É uma obra literária de interpretação de máquina. O que é protegido é a reprodução integral do mesmo código. Não a ideia em si.

Não se pode proteger uma ideia. Aliás, elas não querem ser protegidas... A base da inovação são ideias compostas a partir de outras ideias... Nenhuma é única por si só e todas elas são, ao mesmo tempo.

Em uma palestra de Ash Maurya, sobre seu livro Running Lean, ele encoraja que você pegue a segunda ou terceira ideia mais legal que você tenha (para não expor a primeira ideia mais legal :)), é faça de tudo para que seja roubada...

Nenhuma ideia persiste por si só. Elas são um conjunto de ações, modelos de negócio, vantagens competitivas, esforço de seus idealizadores, etc... o resto, é só código!

Youp - Ideia para plataforma de ensino na internet

noreply@blogger.com (Rafael Buzon) — Mon, 26 Mar 2012 11:41:00 +0000

Youp foi uma ideia que tive em 2007, que visava oferer uma plataforma de ensino na internet para que qualquer um pudesse ensinar e aprender, em modelos gratuitos e pagos. Na época ainda era incipiente a ideia. Hoje já existem similares, como o stoodos.com
Alguém a fim de investir?

__________________________________________________________________________

Youp - Plataforma de ensino

Veja mais apresentações de Rafael Buzon

Dinâmica de riscos: Velório do produto

noreply@blogger.com (Rafael Buzon) — Fri, 23 Mar 2012 17:16:00 +0000

Uma das dinâmicas que temos praticado nos projetos em concepção é o Velório do Produto. A dinâmica consiste em, posto que o produto "morreu", quais teriam sido os motivos para que isso acontecesse.

O exercício visa identificar possíveis riscos, dúvidas e anseios dos envolvidos, gerando uma lista de issues a serem tratados durante o projeto.

Sem contar o fato de ser divertido!

ScrumMaster certificado

noreply@blogger.com (Rafael Buzon) — Fri, 23 Mar 2012 01:31:00 +0000

Recentemente eu fiz o curso e tirei minha certificação de Certified Scrum Master, o que significa que eu conheço os conceitos de Scrum e do papel do ScrumMaster em equipes ágeis. Aliás, recomendo o curso dado pelo Alexandre Magno, na Adaptworks.

Entretando, ser certificado em algo é como tirar uma foto de um momento. O tempo passa, a foto envelhece, e o que conta mesmo, são os vídeos que você faz.

O papel do Scrum Master

noreply@blogger.com (Rafael Buzon) — Wed, 21 Mar 2012 12:04:00 +0000

Nesta conversa rápida, Hamilton Fontes, da Editora Abril, comenta um pouco sobre sua experiência no papel de ScrumMaster em um contexto em que a cultura ágil, nos clientes, ainda não está consolidada.

Resiliência em times ágeis

noreply@blogger.com (Rafael Buzon) — Tue, 20 Mar 2012 15:19:00 +0000

Nesta "conversa rápida" promovida pela Adaptworks, comentei sobre gestão de riscos e resiliência em times ágeis. Como a resiliência está embutida na filosofia ágil e nas práticas Scrum e XP, para desenvolvimento de software?

7 opções para lidar com interrupções em Scrum e outras práticas ágeis

noreply@blogger.com (Rafael Buzon) — Thu, 19 Jan 2012 02:02:00 +0000

Primeiro artigo próprio no InfoQ
http://www.infoq.com/br/news/2012/01/7opcoes-para-evitar-interrupcoes

Abs,
Buzon

Novos posts no InfoQ

noreply@blogger.com (Rafael Buzon) — Thu, 05 Jan 2012 13:07:00 +0000

Novos posts no InfoQ:

Desenvolvimento de software como gerenciamento de riscos?

http://www.infoq.com/br/news/2011/10/desenvolvimento-risco

Projetos de TI: 400% acima do orçamento e 25% dos benefícios esperados

http://www.infoq.com/br/news/2011/11/software-alto-risco

Adoção de Agile em ambientes de Medo

noreply@blogger.com (Rafael Buzon) — Wed, 03 Aug 2011 14:48:00 +0000

Mais uma tradução minha para o InfoQ Brasil
http://www.infoq.com/br/news/2011/08/agile-medo

Abs,
Buzon

O legado de Eli Goldratt

noreply@blogger.com (Rafael Buzon) — Thu, 28 Jul 2011 22:14:00 +0000

Mais um artigo que traduzi para o InfoQ Brasil.
http://www.infoq.com/br/news/2011/07/LegadoEliGoldratt

Abs,
Buzon

Scrum Alliance reforça a certificação de CSP e anuncia exame Beta

noreply@blogger.com (Rafael Buzon) — Tue, 19 Jul 2011 01:40:00 +0000

http://www.infoq.com/br/news/2011/07/ScrumAllianceStrengthensCSP

Meu primeiro post (tradução) no InfoQ Brasil.

Abs,
Buzon

Torre de Babel nos guetos organizacionais

noreply@blogger.com (Rafael Buzon) — Tue, 12 Jul 2011 17:03:00 +0000

http://franciscogaristo.blogspot.com

Todos conhecem a estória da Torre de Babel: Depois de ver a pretensão do homem em construir uma torre que chegasse ao céu, Deus confundiu suas línguas para que não se entendessem e, com isso, o projeto da torre também não avançou mais. Isso aconteceu por volta de 200 a.C. (wikipedia)

O que poucos sabem, entretanto, é que esta intervenção divina aconteceu também na construção de software, que até hoje nos faz buscar o entendimento mútuo para realizar coisas até menos pretensiosas que uma torre, como lançar um site.

Se falar outras "línguas", todavia, dificultou nosso entendimento e nosso progresso como um todo, por outro lado nos abriu os olhos para resgatar e refletir sobre aquilo que pretendemos construir juntos. É a oportunidade de analisarmos a natureza daquilo que queremos realizar. É a oportunidade de firmarmos práticas e valores e avaliar a forma como medimos nossas ações. Detalhe: JUNTOS!!

É nítido e real este fenômeno de construção conjunta. A Web 2.0, redes sociais, Wikipedia, etc... são provas que o mundo tende a ser mais colaborativo. Mas, indo na contra-mão das tendências comportamentais e muitas vezes se mantendo inertes e enraizados à modelos ultrapassados, estão algumas áreas conhecidas como "guetos organizacionais".

Estes "guetos" falam "línguas" diferentes, tem "crenças" diferentes, defendem ações diferentes, vivem rotinas diferentes e enxergam somente pela perspectiva que os convém. São órgãos isolados em um organismo vivo. São eternos mantenedores da instituída Torre de Babel.

Mas tem jeito...

Se na Torre de Babel o homem se desorganizou e dispersou através da diferença da língua, é no falar de várias línguas que ele se reúne novamente, como narra nos Atos dos Apóstolos em Pentecostes (ainda explorando citações bíblicas). Mas qual a diferença?

Sem querer me apegar a questões religiosas, a diferença está no elemento comum envolvido nas línguas de Pentecostes: o amor. A amor, assim como a simplicidade, a valorização da pessoa sobre processos, o estar preparado para mudanças ao invés de seguir um plano, software funcionando ao invés de documentação extensa, são valores que fundamentam as ações. Logo, não importa que língua você fale, desde que entenda e busque os mesmos valores em conjunto.

O egoísmo derrubou a torre de babel. Em gestão de projetos, ou em qualquer outra gestão, é a defesa de valores que irá destituir os guetos e criar sinergia entre áreas. Nada menos que isso resolve!

Veja também:
http://projeto001.blogspot.com/2009/10/cultura-como-sabedoria-organizacional.html

Transcenda!!
Buzon

O terror para as reuniões improdutivas

noreply@blogger.com (Rafael Buzon) — Mon, 11 Jul 2011 11:00:00 +0000

Senhoras e senhores, lhes apresento a revolução da gestão do tempo, o "pulo do gato" no controle de pauta, o suprassumo da objetividade, o terror para as reuniões improdutivas, ele, o timer de tomate.

Ele não é um timer qualquer. É um timer em formato de tomate (o que faz toda a diferença!!). Nem é simplesmente um tomate, o que faria sentido nenhum. E eu explico o porquê...

1) Primeiro, o timer é vermelho, e, de acordo com o estudo de cores, influencia na ação, na atenção e aguça os sentidos e o foco nos objetivos da reunião.

2) E segundo, o tic, tac do timer lembra uma bomba relógio, que traz um efeito psicológico de urgência nas discussões. E, por ser um tomate, parece que vai explodir e espirrar molho em todo mundo a qualquer momento. :)

OK! Parece um pouco terrorismo, mas time is money. Você tem o dever moral de respeitar o tempo das pessoas ali presentes. Começar e terminar pontualmente uma reunião, discutindo tudo o que fora planejado, muitas vezes com pessoas de perfis bem variados, é um desafio grande. Mas com o timer de tomate, sua vida fica mais fácil.

O ministério da gestão adverte: Muitas reuniões podem tonar sua vida improdutiva! Não adianta controlar o tempo de reuniões que nem deveriam ter nascido. Pense nisso!

Referências:

Técnica Pomodoro - Gestão do tempo
http://www.pomodorotechnique.com/

Jason Fried: Why work doesn't happen at work
http://www.youtube.com/watch?v=5XD2kNopsUs
Caso tenha o poder para isso, cancele a próxima reunião e seja feliz.

Frase do dia

noreply@blogger.com (Rafael Buzon) — Sun, 06 Feb 2011 15:27:00 +0000

Premissa: é tido como verdade para apoiar uma ação - Restrição: limita a ação, pois é uma verdade!