Lean em 4 minutos 13

Posted by Willi Wed, 02 Dec 2009 12:10:00 GMT

Uma interpretação muito pessoal do Lean…

 

E em inglês…

 

Maré de Agilidade com Açaí

Posted by Alê! Mon, 23 Nov 2009 10:45:00 GMT

Maré de Agilidade com Açaí



Texto produzido pelo grupo Tá Safo!

Para quem ainda não sabe do que se trata, o Maré de Agilidade é um evento itinerante que viaja pelas cidades do Brasil, apresentado assuntos como Extreme Programming (XP), Scrum, Domain Driven Design (DDD), Model Driven Design (MDD), Test-driven Development (TDD), Feature-driven Development (FDD), Gerenciamento Ágil de Projetos (GAP), Lean, e tantos outros. Esses assuntos começam a fazer parte do vocabulário do desenvolvedor de software, no entanto muitas vezes sem a devida capacitação para entendimento e aplicação de tantos conceitos.

Como as ondas de uma maré, o evento já passou por Brasília (setembro/2008 − 1° edição); Salvador (março/2009 − 2° edição) e Fortaleza (agosto/2009 − 3° edição).

Agora em sua 4° edição chegou a vez de Belém, para falar das novas tendências em gerência de projetos e técnicas de desenvolvimento de software que constiuem atualmente o grande diferencial de empresas como Apple, Google, Microsoft, Yahoo e Globo.com.

O evento está programado para os dias 26, 27 e 28 de Novembro de 2009, sendo os 2 primeiros dias de mini-cursos, sessões de Dojo e OpenSpace. O 3° dia reservado para palestras e discussões.

Acesse o site do evento: www.maredeagilidade.com.br

Agilidade & Licitações 14

Posted by Willi Tue, 03 Nov 2009 17:57:00 GMT

Estamos numa espécie de cruzada na resolução deste problema, tão maior que a gente, que é o de se trabalhar utilizando metodologias ágeis no governo. As dificuldades são enormes, e ainda não há solução satisfatória, mas em que ponto estamos no momento?

No Ágiles 2009, fizemos uma apresentação sobre este tema (abaixo).

Seguida pela entrevista do Alê pelo Luiz, da Bluesoft:

Entrevista com Alexandre Gomes da SEA Tecnologia no Ágiles 2009 from Bluesoft on Vimeo.

Resumindo a conversa, devido a uma combinação de várias Leis e acórdãos do TCU, o Governo passou a considerar desenvolvimento de software como sendo um serviço comum, sendo obrigado a ser adquirido via pregão. E a unidade de software licitada é normalmente baseada numa métrica, a maioria Pontos por Função.

Uma das conseqüências do uso de pregões para aquisição de software tem sido a diminuição da necessidade de comprovações técnicas, que ocorriam nas licitações do tipo técnica e preço. Por exemplo, onde antes se pedia MPS.BR nível A, hoje aceita-se qualquer certificação MPS.BR. O mesmo vale para o CMMI. E também já faz algum tempo que certificações de profissionais não são mais pedidas como critérios de pontuação técnica, visto que a empresa não precisa ter o profissional contratado antes do início do projeto. As comprovações técnicas dos profissionais são pedidas no momento do contrato, já definido o ganhador do pregão.

Um dos objetivos dos órgãos públicos estarem diminuindo esses critérios para participação é permitir a concorrência entre mais empresas e diminuir o preço do serviço, visto que este é considerado serviço comum. Isso tende a diminuir a força e a fatia de mercado de médias e grandes empresas dentro das áreas de Tecnologia da Informação do governo (será que estavam satisfeitos com elas?). Mas vamos analisar a questão de serviço comum por um instante.

A Lei nº 10.520/02, define que bens e serviços comuns são aqueles cujos padrões de desempenho e qualidade possam ser objetivamente descritos no edital, por meio de especificações usuais no mercado. Mas observem nos slides os “objetivos” padrões de desempenho e qualidade que caracterizam software como serviço comum (e tirem suas próprias conclusões).

Acreditamos que ainda existem algumas fragilidades nessas definições para podermos considerar desenvolvimento de software como serviço comum. Por exemplo: concordamos que haver mecanismos de gestão do projeto favorece que os projetos estejam mais sob controle e que documentação aumente as chances do sistema ser melhor manutenível, mas e se forem mal planejados? Quais são os critérios de qualidade de um plano? Ou de um documento de visão? Ou de um documento de arquitetura? Quando existem, são caracterizados pela presença de tópicos (ex: documento de visão ter definição do problema, necessidades, características e definição dos usuários) e validação de um profissional. Mas isso não seria ainda muito subjetivo? Você pode definir mal o problema, as necessidades e mesmo assim esses tópicos constarem no documento. E a documentação também pode ficar obsoleta. O profissional vai usar quais critérios objetivos para validar a documentação? O mesmo vale para os questionários e aceites normalmente utilizados.

Reiterando: consideramos todos esses mecanismos válidos para aumentar as chances da qualidade do resultado, mas ainda não podem ser considerados como definitivos para tal finalidade. Por isso proporemos novos critérios, baseados em métricas de qualidade como cobertura de testes e taxa de duplicidade do código que, assim como os atuais, também favorecerão a qualidade do software entregue, bem como manutenibilidade e documentação do código.

É claro que pode-se ter um software 100% coberto por testes e ainda assim estes testes serem ruins. Nenhuma métrica totalmente objetiva jamais será perfeita. O fato é que haver testes automatizados no software aumenta as chances de ele ter qualidade, ser melhor documentado e mais manutenível ao longo do tempo.

Observe que estes critérios não resolveriam o problema da qualidade no momento da contratação, pois as métricas só seriam aferidas nas entregas. Mas, ao longo do tempo, descartando-se as empresas que não entregam software com qualidade (por exemplo, numa eventual fase de homologação), haveria uma adaptação dos produtos e do mercado para uma realidade melhor.

Por que o interesse nesses novos critérios? Porque apesar das boas intenções, as conseqüências desse formato de contratação não têm sido boas. Os preços de fato caíram muito, mas muitas empresas não estão conseguindo entregar os sistemas. E muitas delas entregam sistemas de qualidade muito ruim, o que em muitos casos deverá resultar em nova contratação para o mesmo projeto (Isso já foi noticiado na imprensa.). Ou seja, não está havendo economia de fato. Acreditamos que esse modelo tende a colapsar. Ainda há necessidade de adaptação a esse novo formato, e acreditamos que estas métricas de qualidade de código contribuem para isso.

Outra razão (mais particular), é que nós trabalhamos com testes automatizados, sabemos que isso favorece a qualidade dos sistemas e sabemos o quanto isso melhoraria os sistemas que têm sido desenvolvidos para a população. Só que até então, não observamos nenhum retorno desse diferencial. O desenvolvimento está nivelado por baixo. Então a idéia é tangibilizar essa qualidade para que seja valorizada e requerida em editais, para que todos que trabalham como trabalhamos e agregam o valor que agregamos no código possam se beneficiar disso.

Portanto, nossa próxima batalha é essa: tangibilizar a qualidade que dizemos agregar, de forma a contribuir para aumentar a qualidade do serviço de desenvolvimento de software prestado ao Estado. Depois, tentar sensibilizar o governo em quanto a isso, para que possa melhorar seus editais de contratação (quiçá, Acórdãos e Leis!). Quem tá junto nessa?
Já existe um grupo discutindo isso. Se tiver interesse em participar, mande um e-mail para renato ponto willi arromba seatecnologia ponto com ponto br.

[]s
Willi

LinguÁgil 2009 1

Posted by Alê! Fri, 23 Oct 2009 19:49:00 GMT

LinguÁgil2009



A proliferação de tecnologias para o desenvolvimento de aplicações web vem gerando exaustivas discussões sobre qual adotá-las em seus projetos. Java, PHP e Ruby estão entre as 10 linguagens de programação mais utilizadas no mundo, segundo a TIOBE Programming Community. Em paralelo, os mesmos profissionais buscam melhorar seus serviços adotando metodologias que ao mesmo tempo permitam o controle de seus projetos, gerem valor agregado aos clientes e evitem excesso de burocracia.

Diante desse cenário, os grupos AgileBahia, JavaBahia, PHPBahia e RailsBahia realizarão em Salvador a edição 2009 do LinguÁgil - Misturando Linguagens e Agilidade, parte da XII Semana de Informática da Unime. Inédito na Bahia, o evento reune algumas das principais comunidades de TI, buscando estimular aprendizado e discussões em torno de linguagens de programação e metodologias ágeis.

Local:

Unime - Lauro de Freitas - Bahia

Palestrantes/instrutores

Alberto “Spock” Lemos (Globalcode), Alexandre Gomes (SEA Tecnologia), Dairton Bassi (Neurobox), Daniel Lopes (Área Criações), Felipe Ribeiro (UFCG), Felipe Rodrigues (Fratech), Henrique Landim (Partner Process) e outros

Palestras GRATUITAS (14/11)

Agile, Manifesto 2.0, Ruby On Rails, PHP/Frameworks, JSF 2.0/Scrum Toys, Linguagens para a JVM, Pentaho

Oficinas/Coding-Dojo (12 e 13/11)

Coding-Dojo Agile, Java/Web com Demoiselle, Integração Contínua/Maven (a confirmar), Python (a confirmar)

Mini-cursos (R$ 60 a R$ 120)

12/11 - Métodos Ágeis, JSF, Portlets com Liferay, TDD/Java, Ruby
13/11 - XP, Scrum, Pentaho, PHP/TDD, Rails

Inscrições:

Com desconto até 05/11
Preços promocionais para estudantes e membros do AgileBahia / JavaBahia / PHPBahia / RailsBahia

Programação detalhada, inscrições e mais informações em www.linguagil.com.br

SINFORM, Ágiles e RailsSummit 4

Posted by Alê! Fri, 16 Oct 2009 15:39:00 GMT

SINFORM, Agiles2009 e RailsSummit

Setembro e outubro são sempre os meses de pico de eventos no Brasil e, depois de praticamente 3 semanas pulando entre uma e outra apresentação, estamos de volta à vida real.




A maratona começou em Ilhéus/BA, com a IX Semana de Informática da UESC, na qual apresentei uma palestra sobre Computação Invisível e um mini-curso de Ruby e Rails.



Além da turma da organização do evento, que fez um trabalho sensacional, conheci outras grandes figuras: Camilo Lopes (IBM), Hugo Santana (Google) e o Prof. Aquiles Burlamaqui (UFRN). Foi um prazer, caras!


Na sequência, descemos pra Florianópolis/SC para participar do Ágiles2009, o principal evento de metodologias ágeis da América Latina, no qual falamos do Manifesto 2.0 e do paradoxo Agilidade x Licitações.



Rolou até uma sessão de dojo no evento!



Impressionou-me neste encontro a qualidade das discussões e o nível da galera presente. Em especial, encantou-me o discurso do Roy Singham, CEO da ThoughtWorks, não apenas pela presença de palco e pela habilidade de condução da palestra mas, principalmente, pela grande intersecção do que ele falou com o que nós temos falado no Manifesto 2.0.  \o/  Se alguém tiver gravado, dá um toque, por favor!

Ah, e aproveito pra mandar um salve pro Samuel Crescêncio (@screscencio), Victor Hugo (@victogh) e pro Bruno Ghisi (@bghisi). Muitíssimo obrigado pela recepção fantástica que nos deram. Vocês são foda!

Rails Summit 2009

Por fim, seguimos pra São Paulo/SP, para participar do RailsSummit 2009 que, IMHO é, atualmente, o melhor evento de TI do Brasil. Apesar de não estarmos na programação oficial da conferência, tivemos a oportunidade de novamente falar do Manifesto 2.0 como uma lightning talk, que os amigos da BlueSoft fizeram o gentil favor de filmar e publicar.

Manifesto 2.0 no Rails Summit 2009 por Alexandre Gomes from Bluesoft on Vimeo.

Como andei tuitando, blogando e já disse para vários colegas, o grande lance do RailsSummit não é o RubyOnRails, mas a comunidade que em torno dele se formou. Não sei é pelo fato de ser constituída de gente de diversos outros mundos tecnológicos ou simplesmente por ter nascido no umbigo do pensamento 2.0, mas a essência dos debates é de singular admiração. Não vou repetir aqui o que já disse no passado. @AkitaOnRails está novamente de parabéns pelo empreendimento.

E, por falar em empreendimento, deve rolar no próximo ano um evento sobre Empreendedorismo em TI. Fiz essa sugestão ao final da palestra do @viniciusteles e a galera comprou a idéia. Muito provavelmente, será no Rio. Atentem-se!

E, por falar em @viniciusteles, ele o @akitaonrails fizeram as melhores palestras do evento, em minha humilde opinião. Portanto, não percam a oportunidade de assisti-los.




As demais apresentações já estão disponíveis aqui. O @leozera nos fez um ótimo review do primeiro e do segundo dia, com links para os slides e tudo mais. Outras impressões sobre o evento podem ser vistas no TrendTime.

A turma da @sea_tecnologia foi, gostou e indica a quem se interessar.


2010

Finda a maratona, é hora de retornar à vida real, responder alguns emails e preparar o espírito para 2010 que, AFAIK, já conta com:

  • Março - Maré de Agilidade (Belo Horizonte/MG)
  • Abril - MaréDeAgilidade.Gov.Br (Brasília/DF)
  • ?? - Maré de Agilidade (Florianópolis/SC)
  • Junho - Ágil Brasil (Porto Alegre/RS)
  • Agosto - Bundle Maré de Agilidade + Oxente Rails (Natal/RN)
  • Setembro - DevInRio (Rio de Janeiro/RN)
  • Outubro - Ágiles (Lima/Peru), RailsSummit (São Paulo/SP)

Como diria o Guapo, e vamo que vamo!

[]s

Torna-te, pois, responsável 3

Posted by Alê! Mon, 27 Jul 2009 11:51:00 GMT

Torna-te, pois, responsável.

Apesar de tendência ao colapso, ainda acreditamos na Filosofia 2.0.


Definitivamente, cremos que empresas modernas devem quebrar suas barreiras egocêntricas, fomentar a opinião crítica de sua equipe, digeri-las e agir de acordo. Como dizem no mundo do Software Livre, nenhuma idéia é melhor que a idéia de todos nós juntos. Estamos falando dos princípios da Web 2.0, onde a empresa deixa de ser o núcleo emanador de verdades e torna-se a infra-estrutura viabilizadora  do desenvolvimento de sua comunidade.

Transparência vs Compromisso

Numa empresa 2.0 (por mais que não tenham ainda formalizado este conceito), a gestão estratégica do negócio recebe influências diretas de seu nível operacional. Democracia a parte, não é novidade o incômodo trazido pelo modelo. Incômodo ainda maior, quando o bombardeio de críticas é acompanhado de descompromisso. Afinal, nossa cultura é mestre em seu senso crítico evasivo.

Adoramos condenar o escalão político sem, no entanto, nos lembrarmos que nosso voto o compôs e, pior, sem nos dispormos agir de alguma forma para sua reconstituição moral. Repare em nossa sociedade. O papel acusador é vivido do mais pobre ao mais rico, do mais estudado ao menos, e todos compartilham, majoritariamente, a síndrome do ‘não é problema meu’. O problema da limpeza da cidade é do prefeito, não meu. A insegurança do condomínio é problema de seu síndico, não meu. A guerra no trânsito é culpa dos motoristas de transporte coletivo, obviamente, não meu. E, no senso comum, tropeços na gestão empresarial, é problema de seus dirigentes, não meu.

Mas não é nisso que o pensamento 2.0 acredita. O Scrum, representante deste movimento, ilustra muito bem a situação com a estória do porco e da galinha.



Não queremos crítica por crítica. Queremos crítica construtiva, preferencialmente de pessoas devidamente compromissadas com seus resultados. O poder de voz não é gratuito. Grande carga de responsabilidade o acompanha.

O que faz todo o modelo tender ao colapso é o descompromisso dos participantes. Como galinhas, muitos querem se envolver na discussão, julgando e criticando, mas poucos estão realmente dispostos às últimas consequências de seus atos. Sendo desta forma, não se atinge um equilíbrio na balança da discussão vs ação. Empresas modernas precisam muito mais de gente que faz do que de gente que fala.



Experimentamos nos últimos 4 anos a realização do planejamento estratégico da empresa com todos, absolutamente todos, os seus integrantes. Muitos gostam do processo, simpatizam-se com a disposição da empresa em a todos ouvir, mas também muitos negam-se a participar pela impressão de haver muita ideologia e pouco resultado prático do processo.

Discussão vs Ação

Passei muitos anos de minha vida em busca de idéias brilhantes e crente em sua escassez. De uns tempos pra cá, entretanto, percebi que o que nos falta não são ieias, mas capacidade de realização.

Quando se abre as portas da gestão estratégica para a discussão coletiva, o que se busca, nas entrelinhas, é maior apoio para a construção de um mundo novo. Sim, a opinião coletiva é importante mas, muito mais relevante é o apoio braçal para realização de parte do que fora discutido.

Então, críticas sem compromisso em nada contribuem. Não adianta 20 pessoas aparecerem com mil pedras e sugestões de melhorias e pensarem que 3 colegas serão suficientes para implementá-las. Queremos gente que compre a briga conosco e que lute ao nosso lado. Esta é a contrapartida ao direito de voz.

Não é raro ouvir que “aqui nesta empresa, muito se fala, mas pouco se faz” sem que o interlocutor, inadvertidamente, se dê conta que grande parcela do “muito se fala” e da responsabilidade pelo “pouco se faz” está em seu poder. Então, antes de muito propor, verifique sua capacidade de contribuição com a proposta.  E, antes de criticar a pouca realização, examine sua consciência e confirme sua isenção de culpa. Se sua incapacidade de contribuição em ideias está limitada por questão financeiras ou sociais, busque-as, viabilize-as. Se sua contribuição com planos do passado não tem sido expressiva, reinvente-se. Se todo o fardo do desenvolvimento corporativo estiver sobre seus ombros, reivindique! Tudo isso faz parte das responsabilidades cotidianas do chamado “gestor” que agora, quer compartilhá-las com todos.

Há aqueles que acreditem que novas ideias ou modelos de trabalhos só serão implementados se promulgados pela alta gestão do negócio. Nada mais 1.0 a dizer. Esses ainda acreditam no poder e certamente estão alheios aos novos valores da adminsitração moderna que define a autoridade e a liderança como palavras de ordem. A gestão moderna não é uma atividade resumida ao preenchimento de planilhas e acompanhamento de gráficos. É a arte da socialização, da articulação política e da resolução de conflitos.

Portanto, pare de culpar o mundo pelas suas mazelas. Culpe a si mesmo. Busque no alto escalão apoio para a eliminação de obstáculos, e não decretos imperativos de transformação. Faça amigos e influencie pessoas. Desenvolva sua capacidade de convencimento. Seja líder. Seja um empreendedor


Tu te tornas eternamente responsável
por aquilo que cativas.


Como bem já disse o Serge, não basta só a Empresa ser 2.0. É preciso que seu Pessoal também o seja. É preciso que se desenvolva a Aptitude 2.0.

Nota pra mim mesmo: discutir no próximo post como incentivar a Aptitude 2.0.

[]s

O Movimento Agil 2

Posted by Alê! Mon, 13 Apr 2009 16:29:00 GMT

Agilidade em Ilheus Hoje pela manhã eu estava conversando com o colega Paulo Merson e, a certa altura da conversa, ele disse:

“If you’re not having fun, you’re not doing it right.”


Esse dito é perfeito e dá continuidade ao post da Carol. Afinal, por que estava eu, em meio às minhas férias, em plena Itacaré/BA, falando de tecnologia com amigos? Por prazer. Simples assim. E é com este mesmo prazer, que mais logo, também em plenas férias, conversarei sobre tecnologia com os alunos da Universidade Estadual de Santa Cruz, em Ilhéus/BA.



“Faça algo que ame e nunca mais trabalhe na vida.”

Vamos pra Bahia?

Posted by Willi Fri, 06 Mar 2009 20:55:00 GMT

Vamos pra Bahia?



No tabuleiro do Maré tem…

Scrum, Olodum

XP, TDD, FDD, DDD e Dendê

Acarajé, Vatapá e programação em Par

Caruru e Kanban

Pelô, Lean e muita história pra contar.

Ô Bixinho, você não pode perder!



Mais informações: http://www.maredeagilidade.com.br/

Oxi!

PS: Gostou mas não pode ir? O Maré de Agilidade agora é nosso Road Show oficial. Se quiser que ele aconteça na sua cidade, entre em contato conosco!

PPS: Quer colocar banners no seu site ou blog? Entre aqui.

Case Encceja: Projeto de nível nacional no governo utilizando Agile

Posted by Willi Thu, 13 Nov 2008 19:43:00 GMT

Olá pessoal,

Vou aproveitar a entresafra bloguística do pessoal pra deixar uma notinha.

No começo de outubro, publiquei no Blog da Visão Ágil um artigo sobre uma consultoria de Agile que demos no INEP para desenvolvimento do Encceja.

Foi uma experiência muito interessante pra gente, além de considerar um marco muito importante para as metodologias ágeis no Brasil, pois se trata de um projeto de nível nacional e no governo! (Além de outras coisas, como ter utilizado um servidor de aplicação feito em Software Livre).

Espanta um monte de crenças e preconceitos a respeito de Agile.

Leia o artigo na íntegra aqui.

Ah, e pra quem ainda não leu sobre nossa Saga na Aeronáutica,apresentada no Falando em Agile, o Case Sigadaer descrito em maiores detalhes aqui.

Grande abraço, [                  ]

Willi

 

Construindo um Brasil Melhor: Lançamento do Scrum e XP Direto das Trincheiras 12

Posted by Willi Thu, 06 Nov 2008 18:51:00 GMT

Me lembrei da história de um cara que visitou uma enorme construção e perguntou a um operário o que ele estava fazendo. Ele respondeu que estava assentando tijolos. Perguntou pra outro e esse respondeu que estava levantando uma parede. Perguntou a mesma coisa a um terceiro, que estava fazendo a mesma coisa que os outros dois, e ele disse que estava construindo uma catedral.

É nesse sentido que coloquei no título o “Construindo um Brasil Melhor”.
Muita gente pode achar que o que fizemos foi só uma tradução de um livro, mas acredito que estamos fazendo mais que isso.
Estamos favorecendo a popularização das metodologias ágeis. Com isso, favorecemos a produção de mais software de qualidade, a compreensão dos prejuízos causados por contratos de escopo fechado, deixando melhores legados para nossos colegas, diminuindo os tantos sistemas inteiros que são jogados no lixo todo ano para serem refeitos por fortunas cada vez maiores, fazendo com que os recursos sejam melhor utilizados, ajudando o país a enriquecer de uma forma sustentável, para gerar mais impostos, para sobrar mais dinheiro pra educação, pro povo aprender a ter senso crítico, pra votar melhor, pra daqui a um bom tempo ocorrer uma limpeza real no nosso sistema e o Brasil ser um país melhor pra todos nossos tataranetos.

Viajei? Se deixar chego até a contribuição para a diminuição do aquecimento global! :)

Mas toda essa jornada começa com um simples passo, e esse passo foi dado por 30 pessoas que ao melhor estilo bazar construíram a catedral.

Não me lembro quando a idéia apareceu, mas apareceu depois de terminarmos de traduzir as tirinhas do Why’s Poignant Guide to Ruby. Mandei um e-mail pro Henrik Kniberg com a idéia de traduzir o livro pra português, depois de um tempo ele me respondeu topando, e em seguida mandou o livro em formato editável. Dividi o livro em 114 pequenos pedaços, e dia 16/07/08 lançamos um post  convocando nossos leitores e a galera da comunidade no Brasil, e explicando o procedimento. No mesmo dia, três pessoas já apareceram. Pra gente já foi uma vitória. Quem poderia imaginar que ao total iriam aparecer 30? São eles:
 

  • Acyr José Tedeschi
  • Adam Victor Brandizzi
  • Alexandre Gomes
  • Álvaro Maia
  • Bruno Pedroso
  • Cássio Marques
  • Daniel Wildt
  • Eduardo Bobsin Machado, que traduziu todas as imagens
  • Emanoel Tadeu da Silva Freitas
  • Fernanda Stringassi de Oliveira
  • Francisco M. Soares Nt.
  • Gustavo Grillo
  • Ian Gallina, cuja mãe ajudou na revisão do português
  • Israel Rodrigo Faria
  • José Inácio Serafini
  • Juliana Berossa Steffen
  • Marcos Machado
  • Marcos Vinícius Guimarães
  • Mauricio Vieira
  • Pablo Nunes Alves
  • Rafael Benevides
  • Rafael Recalde Caceres
  • Renato Willi
  • Rodrigo Palhano
  • Rodrigo Russo
  • Taiza Sousa
  • Victor Hugo Germano
  • Vinícius Assef

 

Em 21 dias, mais de 150 e-mails depois, a idéia virou realidade. Todo o livro já estava traduzido, dia 07/08. Cada pedaço levou em média 2,22 dias pra ser traduzido. No total, entre tradução e revisão, levamos apenas 1 mês e 1 semana. O Cássio Marques e Vinícius Assef juntos traduziram quase 50% dos pedaços.
Parabéns novamente a todos. Foi um trabalho excepcional. Comemorem!!!

Convencer, ensinar, vender… são todos processos internos (acontecem no espaço entre 2 orelhas). Teremos muito mais sucesso se agirmos no sentido de motivar as pessoas para que se convençam, motivar pra que aprendam ou para que comprem alguma coisa. Parece apenas um jogo de palavras, mas a idéia por trás é bastante forte! Apenas 2,5% da população é de pessoas inovadoras, que são naturalmente ávidos por mudança e não têm aversão ao risco. Quer dizer que de cada 100 chefes que você tentar convencer, só 2 irão te dar ouvidos.

Os demais irão agir provavelmente assim:

Se você riu é porque já passou por isso. Eu tive uma crise de riso! :)

Vejam que um dos padrões para introduzir novas idéias é plantar sementes.

Eis a semente!

[                       ]
Willi