Salve!

Vamos reiniciar as atividades do DojoSEA essa semana, com uma reunião aberta (estão todos convidados).

Quarta-feira, dia 13/jan/2010

Às 17:00

Na SEA (CLN 110 - em cima do Marvin)

Nossa atividade para essa primeira reunião do ano será:

- Assistir ao Screencast de JQuery do peepcode e discutir;

- Conversar sobre as atividades para esse ano;

Sejam todos muito bem vindos !

Uma interpretação muito pessoal do Lean…

E em inglês…

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

O Bruno fez um post expetacular em seu blog pessoal relacionando vários ingredientes hackers com a tendência 2.0. Vale muito a pena conferir. Vejam:

“Nessa virada de século, o Trabalho (com T maiúsculo) passa por um processo de reformulação comparável ao que aconteceu na revolução industrial. A demanda por trabalhos criativos e a situação global como um todo mostram a necessidade de reformular os antigos processos e métodos à luz de mudanças importantíssimas que vêm ocorrendo em nossa sociedade, em especial o surgimento da Internet e todas suas consequências. O desenvolvimento de software e a cultura hacker possuem papel fundamental nessa mudança, assim como o próprio uso de computadores e programas pela sociedade. Fazem surgir - dentre outras coisas - novas técnicas, métodos, metodologias e processos de trabalho mais afins com a natureza do que estamos realizando (a sociedade como um todo), as quais cito nesse texto, por enquanto, apenas como fonte de pesquisa, motivação e conselho.”

Continue a leitura do artigo no blog eXPresso Capital.

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.

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!



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.

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

Acho que a maioria dos leitores de nosso blog já conhece a história do Maré. Começou como um projeto brasiliense, com a única pretensão de divulgar a filosofia ágil em Brasília, e acabou ganhando mundo graças à raça de uma galera que definitivamente bota pra fazer.

Christiano Milfont, um dos organizadores do Swell Fortaleza, fez uma ótima compilação de fotos, posts, tweets e slides do evento que não convém repetir aqui. No próprio blog do evento há uma série de posts sobre o que lá rolou.

Pra dar um gostinho do que aconteceu em terras cearenses, vou transcrever apenas algumas menções que circularam no Twitter. Para mais detalhes, busque no site do Milfont.

Os slides utilizados nos mini-cursos e palestras da galera da SEA (SEArences) estão no Slideshare.

Ao invés de escrever sobre nossas impressões sobre a 4a turma do minicurso “XP na Prática”, vamos transcrever aqui o feedback dado pelo Luiz Henrique Correa, originalmente enviado para a lista AgilDF@googlegroups.com (participe!), e aqui publicado com sua devida permissão.



No último dia 18/07 participei do Mini Curso XP na Prática, ministrado pelo pessoal da SEA Tecnologia. Gostaria de relatar aqui as minhas experiências e impressões sobre o curso.

Não é de hoje que eu estudo sobre metodologias ágeis, e o curso pra mim serviu como uma forma de aparar algumas arestas e experimentar de
fato um ambiente Ágil na prática. A didática utilizada é algo completamente diferente do normal, pelo menos dos cursos que eu já participei, o que na minha opinião foi um ponto muito a favor.

Início do Curso:

O curso é prático mesmo. O que faz com que os participantes mergulhem num dia de trabalho XP.
Após uma rápida (muito rápida!) apresentação dos conceitos, valores, práticas e princípios de XP, entramos de cabeça no planejamento das atividades e iterações.

Planejamento das Iterações:

Achei interessante o fato do Bruno (Instrutor) conduzir a reunião de planejamento somente “ditando” as regras (alertando o grupo sobre o tempo máximo da iteração, ajudando na quebra das histórias, etc) e não conduzindo os alunos pela mão.

A turma foi obrigada a se entender quanto aos prazos para realizar as atividades do projeto, e nesse ponto conseguimos ver o quanto é difícil estimar prazos. O problema da estimativa é “resolvido” nas retrospectivas, onde podemos reavaliar e melhorar a nossa estimativa tendo a experiência da iteração anterior. O comprometimento com os prazos também é muito mais intenso quando o próprio time é quem os define, diferente das abordagens comando-controle.

Quebrar as histórias em atividades e tarefas menores, ajuda a enxergar o problema de uma forma mais realista, e com isso podemos estimar melhor e trabalhar mais focado em cada parte do projeto. Tanto gerenciar quanto trabalhar dessa forma é muito mais viável.

Mão na Massa:

Depois do planejamento inicial, o pessoal da Sea iniciou o desenvolvimento das funcionalidades programando para que a turma pudesse começar a se familiarizar com o jeitão XP de fazer as coisas. A programação foi sempre realizada em pares e usando as técnicas de TDD. Depois da primeira iteração os alunos começaram a colocar a mão na massa, também programando em pares usando TDD. Nesse momento percebemos que na prática, a teoria é outra!

TDD:

Sem dúvida o ponto alto do curso foi a utilização das Técnicas de TDD. Logo de início, pensar no teste antes de programar era difícil, e por isso muitas vezes o monitor nos chamava a atenção: “Faz o teste primeiro!”. Mas depois, em pouco tempo, já estávamos praticamente “dependentes” de criar o teste antes de programar, pelo menos no meu grupo foi assim. Não pensávamos mais na funcionalidade sem antes pensar no teste. Com isso ganhamos em foco, comunicação, simplicidade e segurança. Não chegamos a refatorar nada, em função do tamanho do projeto e do pouco tempo que tínhamos, mas certamente com a extensa cobertura de testes (acho que uns 26 testes para umas 8 funcionalidades, pelo que eu me lembro) qualquer mudança poderia ser
feita sem as tradicionais dores de cabeça e, sem precisar “debugar” o código para entender o que estava acontecendo, bastava olhar a suite de testes.

Ao final do projeto, com todos os testes automatizados que tínhamos, estávamos com uma excelente documentação dos requisitos (atual e funcional!), com uma ótima rastreabilidade das funcionalidades e dependências de código, além de uma bruta segurança para fazer qualquer modificação necessária, sem medo de quebrar as funcionalidades existentes. Tudo isso graças aos nossos Testes Automatizados, tudo isso graças ao TDD.

Programação em Pares:

Ver o pessoal da Sea programando em pares é muito bacana. A sintonia dos pares, a troca de experiências, a comunicação, tudo parece muito necessário no contexto XP. Mas confesso que eu não sou muito adepto a essa prática, prefiro uma sessão de programação pareada mais específica, para um problema ou outro, ou até mesmo escrever alguns testes ou métodos em pares. Mas sempre programar em pares eu não vejo com muitos bons olhos e não tive tão boas experiências com essa prática. Mas tenho que admitir que existem muitos benefícios nela.

Retrospectiva:

Sempre depois de cada iteração nós realizávamos uma retrospectiva: O que fizemos, o que pretendemos fazer, e onde precisamos melhor para atingir os nossos objetivos. Nessas rertrospectivas tínhamos a chance de rever o nosso planejamento inicial e adequá-lo a nossa real necessidade naquele momento. Um ponto muito interessante das retrospectivas, era quando o Time sabia que não conseguiria entregar toda a funcionalidade prometida na release, e tinha que negociar com o cliente o que era mais importante, qual era a funcionalidade que agregava mais valor ao cliente, pois era essa que receberia o foco nas
próximas iterações. Esse exercício mostrou o quanto a figura do “cliente presente” é importante para o sucesso do projeto.

Documentação? Modelos?

Normalmente eu sempre procuro ter um diagrama de classes à mão para programar. E antes de programar eu gosto de pensar no diagrama de classes. No nosso projeto não criamos e nem usamos qualquer diagrama UML, e sabe que falta eles fizeram? Nenhuma! Fui pensar nisso depois que cheguei em casa e analisei alguns pontos do curso para escrever sobre ele. E eu creio que essa total irrelevância dos diagramas deve-se ao TDD. Criando os testes e modelando via TDD acabamos por saber exatamente o que precisamos fazer a cada passo, e com isso, os nossos métodos e classes vão nascendo de acordo com a necessidade real e momentâneas do projeto. Nada de desperdício!

Lógico que em nenhum momento foi falado que diagramas e modelos não são necessários nem importantes, mas o recado é: fazer quando necessário, fazer para auxiliar na comunicação da equipe e não fazer apenas por fazer.

O Pessoal da Sea:

Eu não participei de toda a programação, a turma ficou muito grande (um ponto negativo mas sem culpa do pessoal da SEA) e eu dei espaço para outro colega programar. Aproveitei e fui trocar idéias com o Willi, Bruno e Carol. Todos são muito acessíveis, humildes em escutar as nossas opiniões e bastante generosos ao explicar muito de como eles pensam e agem no dia-a-dia dos seus projetos. A troca de experiências é sem dúvida um outro ponto fortíssimo do curso.

Minha Conclusão:

O curso foi excelente, mas não é pra qualquer um. Eu acho - opinião exclusivamente minha - que nem todos poderão desfrutar dos ensinamentos do curso, porque ele é bem diferente de tudo que normalmente estamos acostumados (além do tema também ser bem diferente do tradicional). Para aproveitar o curso eu acredito ser extremamente necessário um conhecimento, e até mesmo uma simpatia prévia, de métodos ágeis. Em alguns pontos a ficha demora a cair, e só cai realmente se você pensar no que vivenciou e analisar de uma forma “mente aberta”, tudo o que foi visto e praticado no curso.

Pra mim, o curso serviu para reforçar todas as (boas) idéias e impressões que eu já tinha sobre as metodologias ágeis. Serviu também para que eu conhecesse na prática todo o poder de TDD e de iterações curtas, aliadas com um planejamento que nasce de dentro para fora (da equipe para o Gerente). Uma mensagem bem forte também que é passada durante todo o trabalho, é que as Metodologias Ágeis devem sempre ser adaptadas a sua realidade, então, não espere mágica!

Parabéns e sucesso ao pessoal da SEA!

Um deles, Maré de Agilidade, é conhecido antigo dos leitores de nosso blog. Começou como experimento local brasiliense, ganhou estrada e já segue para sua 3^a. edição. Ocorrerá desta vez na terra do sol seguindo a mesma receita da edição soteropolitana.

Serão 3 dias de mini-cursos a preço de banana e um dia de palestras com figurinhas conhecidas da comunidade ágil. Check it out:

Mini-Cursos	06, 07 e 10/08
Gerenciamento Ágil de Projetos com Scrum	Manoel Pimentel
eXtreme Programming (XP) na Prática	Renato Willi e Bruno Pedroso
Desenvolvimento web ágil com RubyOnRails	Alexandre Gomes
Gestão Ágil de Requisitos	Manoel Pimentel
Teste de aplicações Rails	Alexandre Gomes
Planejamento e estimativas em projetos ágeis	Fabiano Milani

Palestras	08/08
Manifesto 2.0	Alexandre Gomes
Gestão Lean para desenvolvimento de Software	Manoel Pimentel
A Agilidade está no ar	Renato Willi e Bruno Pedroso
“Sou ágil, logo não planejo!”	Fabiano Milani
Governança no desenvolvimento ágil	Clavius Tales
Conhecendo o desenvolvimento guiado a testes e a comportamento(TDD e BDD)	Christiano Milfont
Onde mora a produtividade do Ruby on Rails?	Fabio Kung
Painel com todos os palestrantes: Agile na Real - Interoperabilidade, Mix e Adaptações	@ALL

E é sempre bom lembrar que o Maré é um evento intinerante, da comunidade para a comunidade. Escreva para maredeagilidade no GMail e veja como levá-lo à sua cidade.

Bem próximo ao Maré, e na mesma época, acontecerá o Oxente Rails, realizado pela comunidade local e com a presença confirmada das maiores autoridades nacionais e internacionais sobre o assunto.

O Oxente Rails vai acontecer em Natal, RN, nos dias 07 e 08 de agosto. Na programação palestras sobre Ruby on Rails, Desenvolvimento Ágil e diversos outros temas – interessantes pra quem ainda não conhece e pra quem já trabalha na área. Voici:

Palestras	07 e 08/08
Ruby on Rails: Ecossistema e Comunidade	Fábio Akita
Desenvolvimento Ágil	Tapajós e Sylvestre Mergulhão
Design de Interface para Programadores	Juarez Filho
BDD com Rails	Cauê Guerra
Deploy de Aplicações Rails	Dante Regis
A ciência por trás do Ruby	Carlos Brando
Pragmatic Thinking and Learning	Andy Hunt
Easy Rails: Ruby on Rails fácil no Windows e Linux	Régis Pires
Case de sucesso – Adotando Ruby on Rails no Tribunal de Justiça de Sergipe	Dante Régis
Scaling Rails: Redeparede.com servindo 7,5 milhões por mês	Tapajós e Sylvestre Mergulhão
Empreendedorismo e Rails em Natal	Paulo Fagiani e David William
The Hashrocket Way	Obie Fernandez

Se você é ou quer ser um Railer, não perca esta chance de unir o útil (Rails) ao agradável (Natal).

É provável que alguns estejam a esta altura do post imaginando de quem foi a brilhante idéia de fazer, na mesma semana, dois eventos tão interessantes e tão relacionados entre si. E, o pior, com empresas patrocinantes e apoiadoras em comum! Bem, realmente, foi uma lástima, mas explico.

A movimentação do Oxente Rails começou um pouco antes dos preparativos pro Maré de Fortaleza e, na época, oferecemos ajuda para criação da marca e confecção do site, que foi prontamente aceita pelo Elomar e companhia. Algum tempo depois, a turma do XPCE se empolgou na realização do Maré de Agilidade e, em parceria  com o JavaBahia e a Visão Ágil, iniciamos nosso apoio, contribuindo com experiências das edições anteriores.

Assim, a organização de ambos eventos correram de forma independente e surpreendentemente rápida ao ponto de que, quando alguém se tocou da possibilidade de conflito entre as iniciativas, já era tarde demais. Os locais de realização já haviam sido (ao custo de muito suor) reservados e a maior parte dos palestrantes já havia sido contactada. No caso específico do Maré, além do Oxente Rails, tínhamos até outras justificativas para mudança da data (como uma indisponibilidade na agenda do Alexandre Magno), mas ainda assim não foi possível :-(

Resta-nos então lamentar profundamente. Os eventos Maré de Agilidade e Oxente Rails são eventos amigos que se complementam totalmente. Seria um baita marco para o Nordeste se tivéssemos nos organizado melhor a fim de realizá-los em sequência. Mas enfim, ç’arrive. O Paulo Fagiani, um dos organizadores do Oxente é colega antigo do mundo Java e isso só piora as coisas. Mas uma razão pra não haver desculpas. Foi uma baita falta de comunicação *mesmo*.  Talvez seja a hora de revermos alguns valores do XP… Nossas sinceras desculpas, comunidade.

[]s

Pois é pessoal… Faz um ano (e um dia) que lançamos o post convocando voluntários para ajudarem na tradução do “Scrum and XP from the Trenches”. Não tínhamos a menor idéia se alguém teria interesse ou se a tradução daria certo.

   

Em pouco mais de um mês e com a ajuda de um monte de gente, o livro foi traduzido, e seu lançamento foi dia primeiro de novembro, no lançamento da InfoQ Brasil.

Ao longo desse ano recebemos grandes presentes por esse trabalho, como ter conhecido pessoalmente quem ajudou na tradução e os depoimentos de quem foi “ajudado” de alguma forma por ele.

De lá pra cá muita coisa aconteceu:

• Participamos de diversos eventos, como Encontro Ágil, Falando em Agile, Scrum Gathering Brazil, Agile Weekend, etc;
• Até criamos um evento, o Maré de Agilidade, que está indo para a 3a edição e tem perspectivas de outras mais;
• Fizemos diversas apresentações, para empresas e vários órgãos do governo;
• Começamos 2 Dojos;
• Criamos um curso, que está na 4a turma (com lista de espera para pelo menos mais 3!);
• Aparecemos em revista;
• Entre outras coisas.

Enfim, temos visto que a comunidade ágil tem crescido e ganhado força. E somos felizes por contribuirmos e fazermos parte dela.

Parabéns! E desejo que tenhamos muitos anos ainda melhores e mais produtivos que esse!

[]s Willi

Que redondo que nada.

O fácil é ser  quadrado.

Há muito que tentamos na SEA desenvolver um modelo diferenciado de gestão, no mínimo, mais divertido e sustentável que as formas tradicionais que vemos por aí. O percurso, entretanto, é árduo e, depois de tantos tropeços, começa-nos a ficar bastante clara a razão pela qual a grande parte das empresas optam pelas receitas de sempre, chatas, burocráticas e quadradas. É muito mais simples.

Já fizemos vários relatos aqui no blog de iniciativas internas rumo à Emrpesa 2.0 e até fomos reconhecidos oficialmente por algumas dessas investidas. A proposta é de extremo romantismo e nos custa vários novos cabelos brancos a cada dia. Para cada nova proposta inovadora de gestão, um mol de desafios e questões nos saltam à frente a espera de solução. E, depois de alguns anos acreditando e insistindo nesta filosofia, percebemos o porquê de empresas lideradas por pessoas tão modernas renderem-se a modelos tão antigos, industriais, hierarquizados, centralizados e de comando e controle.

Talvez um dos nossos principais discursos internos seja o fomento à atividade empreendedora (lembrando que empreendedor é diferente de empresário). Há bastante tempo atrás lançamos o primeiro programa interno de incentivo ao desenvolvimento de idéias pessoais. Não necessariamente estejamos nos referindo ao modelo 70-20-10 do Google, mas gostaríamos que o pessoal da SEA pensasse além de suas rotinas operacionais.

Infelizmente, já faz algum tempo dessa primeira proposta e até hoje o modelo não se consolidou. Não sabemos ao certo a verdadeira razão e por isso viemos a público abrir a discussão na certeza de que suas consequências terão grande poder transformador na qualidade de vida de todos nós.

O Colapso 2.0

A filosofia ágil e suas generalizações e derivações, sob a luz do Manifesto 2.0, sugere a maior independência e autonomia das equipes de trabalho. Na SEA, vamos além, promovendo esses atributos democráticos aos níveis mais estratégicos da organização. E, para alegria de uns e tristeza de outros, cada vez mais este processo parece ser irreversível. Alegria pois é de conhecimento público desde os estudos de Maslow, e recentemente reforçado por Asproni, que os  fatores de satisfação profissional e pessoal não estão essencialmente fundados nas premiações financeiras, mas em elementos subjetivos relacionados à percepção do indivíduo à sua condição de trabalho, favorecidos pela manutenção de um ambiente democrático, fértil ao desenvolvimento e crescimento profissional. Tristeza pois cada nova liberdade dada aumenta o poder das pessoas no processo produtivo, tornando a máquina, aos olhos 1.0, vulnerável a muito mais riscos que outrora.

Quando as pessoas se envolvem num processo de tomada democrática de decisões e definição estratégica, de transparência de todos os ciclos empresariais, de autonomia dos grupos e de total liberdade de expressão, é natural sua maior cumplicidade junto à empresa. Para quem busca maior comprometimento (e não apenas envolvimento) de seu time, essa é uma receita de mão cheia. Por conseguinte, quanto maior a cumplicidade, menor é a extensão vertical da pirâmide organizacional e maior é o sentimento de igualdade entre todos, até que se percebe que todos são iguais, mas uns são mais iguais que outros, e aí começam os problemas.

No processo de comprometimento crescente das equipes, naturalmente, aos poucos, desenvolve-se o senso crítico a respeito da distribuição de responsabilidades e de lucros, da propriedade do patrimônio em construção e das práticas até então em uso. E é aí que eu digo. Ser transparente, dói. Ser democrático, dói. Tratar todos com indistinção de [coloqueaquitudooqueestiverprevistono_Art.3^oda_constrituição] mais formação profissional e cargo na empresa, é um sofrimento. Abre-se margem para as mais severas críticas e questionamentos sobre tudo aquilo até então estabelecido. E você, gestor 2.0, deve estar totalmente disposto a ouvir e discutir.

Acontece, no entando, que o modelo começa a tender ao colapso. Pois, quanto mais 2.0 a empresa for, mais poder seu pessoal terá. Quanto mais poder, mais críticos serão. Quanto mais críticos, mais tenso será o ambiente e mais insustentável tornar-se-á a situação, até o ponto em que uma grande decisão há de ser tomada: corta-se as asinhas assanhadas de todos e retorna-se ao estilo padrão de empresa, ou acata-se a todos os bombardeios e promove-se uma grande revolução interna. Você, como empresário, que tanto suou pra chegar até aqui, o que faria?

[]s