Original de 13/7/2010: Gestão 2.0 - este artigo está ultrapassado na interpretação, depois de mais pesquisas, aplicações práticas, cheguei à conclusão que expliquei nestes outros dois artigos. Quando escrevi o artigo ainda não compreendia todos os aspectos e contexto. Não entendam errado: a história da Semco é extremamente interessante e as idéias são muito sedutoras. Mas considerem o contexto.

Quem me conhece há algum tempo sabe que um dos cases que mais me interessa é o grupo brasileiro Semco. É difícil definir essa empresa que existe desde a década de 50 e passou as últimas décadas se reinventando, passando desde fornecedor da indústria naval, passando por serviços imobiliários com a Cushman & Wakefield, serviços e consultoria ambiental com a ERM, informatização de inventário com a RGIS, investimentos com a Tarpon, soluções de gerenciamento postal de documentos com a Pitney Bowes. Ela acredita em diversificação de negócios, fez diversas joint ventures, já revendeu várias delas. Em seu pico chegou a ter mais de 5 mil colaboradores.

Hoje, fiz minha primeira visita à sede da Semco, em Santo Amaro. O vídeo abaixo foi feito durante o horário do almoço, por isso parece tão vazio Espero poder retornar e inclusive visitar as outras filiais e fábricas.

Original de 10/10/2010: Gestão 2.0

Por incrível que possa parecer, não existe uma boa definição, simples, clara e curta que pode definir o que é ser um “gerente”. Gerente não é uma profissão. Você não pode “aprender” a ser um gerente numa escola ou curso. A única forma de aprender é tentando, errando, melhorando, continuamente e indefinidamente.

Uma das melhores definições que encontrei é de ninguém menos que o professor Henry Mintzberg, em seu recente livro “Managing”, publicado em 2009. Uma leitura madura e leve.

Recomendo a leitura desse livro. Se você é um gerente iniciante ou quer ser um gerente, talvez este livro lhe dê alguma visão do que vai enfrentar à frente. Se você já é um gerente, vai ficar surpreso pois muitos livros teóricos pintam cenários que você nunca viu na prática – fazendo-o se questionar se você está fazendo a coisa certa ou não – e este livro talvez defina melhor os problemas reais que você enfrenta.

Quero trazer alguns trechos da primeira metade do livro.

Original de 24/11/2010: Gestão 2.0

Se você acompanha as discussões sobre metodologias de gerenciamento de projetos de software Ágeis, já deve ter ouvido falar sobre o hype a respeito de Kanban. Eu já conversei com algumas pessoas da área explicando que eu não discordo do conceito em si, mas que acho confuso chamá-lo de “Kanban”.

Para os que não entenderam, Kanban é uma técnica derivada do processo “Lean” que é uma generalização do Sistema Toyota de Produção, o famoso processo industrial criado pela Toyota décadas atrás e que ajudou a revolucionar a Toyota. Criar hype sobre a técnica Kanban não é novidade e a área de Engenharia de Produção já passou por isso antes.

Um dos problemas de se usar o nome “Kanban” é que ela se associa com “Lean” e isso leva a toda uma discussão sobre Agile-Lean que eu particularmente desgosto, especialmente porque o Kanban aplicado a software não tem muito a ver com o Kanban de produção e, portanto, também não tem a ver com Lean.

Para realmente entender o Sistema Toyota de Produção é importante ir às raízes, estudar sobre Taiichi Ohno, W. Edward Deming. Também recomendo a leitura do livro “O Sistema Toyota de Produção do Ponto de Vista da Engenharia de Produção“, escrita por Shigeo Shingo, que atuou como consultor externo e ensinou cursos de engenharia industrial desde 1955. Desse livro, quero parafrasear um trecho do Prefácio da Edição Japonesa:

Vendas pela Internet

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipados com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à ARPA ( Advanced Research Projects Agency ) e ao DoD ( Departament of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para DARPA ( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do INWG ( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP ( Internet Protocol ) e o TCP ( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Estou abrindo alguns backups realmente antigos, trabalhos que eu tenho guardado desde 1995 até 2001, meia década de história. Se ver minha página no Facebook vai encontrar alguns exemplos que acabei de publicar. Em particular quando estava na faculdade comecei a escrever um livro (que nunca acabei nem nunca publiquei) sobre computação em geral e sobre os primórdios da Internet.

O texto a seguir está exatamente como deixei num arquivo Word, em 3 de Agosto de 1996, 9:52AM, entitulado "CAP12.DOC". Vejam como eu via a internet 17 anos atrás.

Original de 3/4/2011: Gestão 2.0

Elo Perdido

Depois de tanto tempo falando de metodologias, processos, procedimentos, existe uma coisa que já deveria ser óbvia mas que a maioria das empresas ignora: metodologias nunca vão substituir bons profissionais.

Se eu disser isso a qualquer um, todos vão dizer: “mas isso é óbvio”. E minha vontade é retrucar: “então porque diabos você está tentando implantar essa metodologia?”

Antes de mais nada, vamos a algumas definições:

  • Metodologia: um sistema de métodos usados em uma área particular de estudo ou atividade.
  • Processos: uma série de ações ou passos tomados para atingir um determinado objetivo.
  • Procedimento: uma maneira estabelecida ou oficial de se fazer alguma coisa.

Original de 24/4/2011: Gestão 2.0

O texto a seguir é uma tradução do excelente artigo Standards: excellence vs mediocrity, escrito por Jason Yip, consultor da Thoughtworks, que tive o prazer de conhecer pessoalmente ano passado.

Antes de iniciar o texto traduzido, uma pequena introdução: todos sabemos como muitos conceitos que temos como fundação no mundo ocidental podem ser radicalmente diferentes no mundo oriental. Um desses conceitos difíceis de transpor do mundo oriental para o ocidental é justamente o de “padrões”. No mundo ocidental “padrão” é um denominador comum, estático, rígido, difícil de mudar, o status quo. No mundo oriental, a idéia de “padrão” é “o melhor”. Se amanhã aparece outro “melhor”, este deve ser considerado o novo padrão. Não é algo inatingível, que admiramos de baixo para cima sabendo que dificilmente vamos alcançar, como um “recorde”.

Imagine um mundo onde o “recorde” é o “padrão”. Eu falei sobre isso em outro artigo chamado Padrões, Commodities e Inovação, recomendo ler. Agora sim, segue a tradução do artigo do Jason:

Caso ainda não saiba, o bom e velho Ruby 1.8 desempenhou seu papel muito bem nos últimos anos e chegou a hora de aposentá-lo. Ele não receberá mais manutenção ou mesmo correções de segurança a partir de Junho deste ano (2013). Significa que seu irmão-gêmeo, o venerado Ruby Enterprise Edition 1.8.7, que nos apresentou a funcionalidade de Copy-on-Write e a possibilidade de refinar os parâmetros do garbage collector, também ser tornará obsoleto em breve.

O que acontece hoje é que existem muitos aplicativos ainda rodando em Ruby MRI ou REE 1.8.7, desenvolvido em Ruby on Rails 2.3, em produção, que ninguém sabe o que deve fazer. A resposta mais comum, caso pergunte aleatoriamente a um desenvolvedor, será "reescrever" em Ruby 2 e Ruby on Rails 3.2 (ou já arriscando para o Rails 4.0 que sairá em breve).

Minha resposta é diferente: se seu aplicativo está hoje em produção, com usuários acessando, minha primeira opção sempre será explorar a possibilidade de realizar o que chamamos de "migração técnica". Uma migração técnica:

  • não envolve mudar funcionalidades ou criar novas;
  • no máximo retirar funcionalidades desnecessárias;
  • e apenas realizar a atualização para as versões mais recentes de Ruby e Rails.

Uma das gems que eu mais uso em projetos é o ActiveAdmin, de todas as opções de admin para Rails que surgiram até hoje, esta foi a que melhor se adaptou na maioria dos projetos. Longe de ser perfeita, mas o suficiente para atender bem as necessidades de uma simples coleção de CRUDs.

Outra vantagem é que pouco a pouco um pequeno ecossistema surgiu em torno do framework, adicionando funcionalidades como granularidade de permissões com CanCan, e eu já bloguei sobre sua excelente integração com o Best in Place. Desta vez experimentei outra extensão que gostei muito, o ActiveAdmin-WYSIHTML5.

ActiveAdmin-Dragonfly

Alguns anos atrás escrevi diversos artigos num outro blog fora daqui entitulado "Gestão 2.0".

Na época me faltou tempo para escrever lá então ele ficou parado. Como ficou parado todo esse tempo, decidi transferir os posts que eu mais gostei para cá para garantir que meus textos estão (quase) todos num lugar só. Atualmente estou colaborando como colunista na Startupi, então não deixe de visitar lá também.

Separei uma dúzia de posts do Gestão 2.0 que já estão programados para aparecer na home...

Original de 27/4/2011: Gestão 2.0

Meu último artigo de tradução sobre “Padrões: Excelência vs. Mediocridade” gerou uma discussão separada interessante especificamente sobre “Design Patterns”.

Para quem não é de programação, nos anos 70 (e foi reforçado nos anos 90 pelo “livro do Gang of Four”) surgiu um termo chamado “Design Pattern” que, segundo a Wikipedia, em engenharia de software, um “design pattern” é uma solução reusável geral para um problema que ocorre comumente em design de software. Um design pattern não é um design fechado e acabado que pode ser transformado diretamente em código. É uma descrição ou template para como resolver um problema que pode ser usado em muitas situações diferentes.