Demorei mais do que deveria para esse novo post. E não foi por falta de vontade, nem de tempo (tempo é uma questão de prioridade!). Foi por indecisão mesmo. Chegamos num ponto já suficiente, acho, para compreender em linhas gerais o que vem ocorrendo com o fortalecimento do Software Livre e o "fenômeno" (não aquele!) Web 2.0. Pensei em vários títulos e temas, mas só nessa semana veio "o estalo".
Estou lendo o livro sobre a história do Google. Simplesmente fantástico saber um pouco mais sobre essa empresa que tem como carro-chefe uma ferramenta de busca altamente eficiente e bem-humorada. Num trecho que fala dum acordo de cooperação entre Google e Ask Jeeves (hoje Ask.com), duas supostas concorrentes. Daí veio o termo "coopetição". Esse acordo é um exemplo de que é possível competir e cooperar ao mesmo tempo. Mas não vou explicar os detalhes, sugiro a leitura do livro!
Mas, e o que isso tem a ver com o Bazedral? Bom, estamos tentando descobrir meios de trabalhar colaborativamente dentro das empresas. A partir de agora vamos discutir como isso é possível. Não tenho a petulância de procurar verdades absolutas, mas vou emitir minhas opiniões com base em experiëncia prática, algum estudo e boas leituras.
Tomando como exemplo as áreas ou departamentos de uma organização, vamos pelo raciocínio inverso: O que impede o trabalho colaborativo? Citando apenas alguns fatores: Falta de direcionamento claro da alta direção; processos ultrapassados, burocráticos e não integrados; comunicação pouco eficiente; ferramentas de trabalho ruins, desintegradas ou inexistentes; deficiências na capacitação gerencial; ambiente de trabalho pouco favorável à criatividade e inovação; cultura do "manda quem pode, obedece quem tem juízo"; falta de delegação; muitos níveis hierárquicos; clima organizacional ruim.
Se diz que toda equipe reflete o comportamento do seu líder. É como filhos que copiam os pais. Acho que a frase é de Einstein: "O exemplo não é uma das formas de educar; É a única.". Se o líder condena o erro, ao invés de encará-lo como oportunidade de aprendizado e melhoria (isso também não quer dizer "passar a mão pela cabeça"), investe pouco em capacitação (própria e do time), não se preocupa com qualidade/efetividade da comunicação, dá mais importância a processos do que a pessoas, o que podemos esperar da equipe? As chances são muito grandes de se preocuparem "apenas com o meu pedaço". Setores que deveriam ser parceiros, viram concorrentes, cada um querendo indicadores de desempenho melhores do que os outros, escondendo o jogo para ficar "na vantagem". De que adianta um departamento de engenharia maravilhoso se as vendas estão despencando? É preciso buscar a visão de unidade, todos alinhados em prol das diretrizes/metas da empresa.
Medições e análises em diversas escalas (desde as equipes pequenas, até os setores e departamentos) são, certamente, muito importantes para melhorar a tomada de decisões e alavancar os processos de gestão. É sadio haver uma certa competição, cada um tentando superar seus próprios limites, desde que não se percam os objetivos maiores. Quem, nos tempos de colégio, nunca comparou seu boletim com um colega e ficava torcendo para ter uma nota superior? Isso muitas vezes nos impulsionava a estudar até um pouco mais, né? Normal, mas desejar que o colega perca o ano ou fique em recuperação já é um pouco demais...
Nas comunidades de software livre também existem pessoas (líderes e liderados), portanto, egos, vaidades, orgulhos, expectativas, frustrações, mau-humor, problemas pessoais, crenças, religiões. Também há competição por quem produz o melhor código, ou quem é o mais carismático, ou quem apresentou a melhor idéia. Mas há, em geral, uma certa pré-disposição bem maior em colaborar. Por que na empresa tem que ser tão diferente?! Será medo de errar e ser punido? Será o medo de "entregar" o conhecimento a outro e tornar-se inútil para a empresa? O importante não é tanto o quanto se sabe, mas a rapidez com que se aprende...
Enfim, acredito que a coopetição deve ser estimulada e constantemente monitorada. Aos primeiros sinais de competição destrutiva, ações imediatas do corpo gerencial. A equipe espelha seu líder. Colabore, comunique, aceite sugestões e críticas, peça desculpas, cobre e aceite cobranças, busque ser transparente. Dê o exemplo! Sua equipe está de olho em você...
quarta-feira, 28 de maio de 2008
quarta-feira, 30 de abril de 2008
Quem deveria ir ao FISL
Que o Fórum Internacional de Software Livre atrai apaixonados pelo assunto, isso não é nenhuma novidade. Que esse público cresce a cada ano, tampouco. Estive lá pelo segundo ano consecutivo, blogando para o JavaBahia, e pude constatar ao vivo a quantidade de aficcionados circulando pelas paletras e stands, exibindo as camisas de seus sistemas operacionais/aplicativos/tecnologias favoritos e, visivelmente, se divertindo.
Mas, na minha opinião, a maioria dessas pessoas já está "conquistada". Conhecem bem as 4 liberdades do SL, os tipos de licenciamento, sabem diferenciar Linus de Linux e já romperam a barreira do "uso porque é gratuito". Chega a ser sem graça "ensinar padre a rezar missa" .
Nas empresas, quando vão selecionar quem serão os "felizardos" que terão tudo pago para ir pro FISL, quem é que eles mandam?! Normalmente, "envia esses caras do software livre para deixarem a gente em paz um tempinho". E os resistentes continuam resistindo...
Durante o evento, pensei na minha própria empresa. A maioria dos que lá estavam eram os diretores que já militam na causa há algum tempo ou membros dos Comitês Regionais do Software Livre, implantados como forma de disseminação da cultura. Mas tem que haver a ligação com aqueles que não tem nem idéia do que está acontecendo no mundo, presos no seu cotidiano apagando incêndios, respondendo e-mails vazios e participando/promovendo reuniões infundadas (tenho a impressão de já ter escrito isso!). Onde estavam os Superintentes, Gerentes de Área ou Divisão, enfim, a liderança média que realmente tem poder transformador nas organizações?
São essas pessoas que deveriam ir pro FISL, para quem sabe estando lá - vendo, ouvindo e sentindo - pudessem começar a perceber que "é verdade.... esse tal de software livre existe mesmo, não é apenas brincadeira...". De forma alguma estou negando a importância do patrocinador, do direcionamento claro vindo da diretoria nem de um planejamento estratégico vivo e efetivo. Mas mudança de cultura não é um simplemente processo Top-Down. Ela ocorre gradativamente e depende muito das gerencias intermediárias. O trabalho colaborativo dentro das empresas passa por aí. Mas que catequizar os ateus é uma tarefa árdua, lá isso é!
Mas, na minha opinião, a maioria dessas pessoas já está "conquistada". Conhecem bem as 4 liberdades do SL, os tipos de licenciamento, sabem diferenciar Linus de Linux e já romperam a barreira do "uso porque é gratuito". Chega a ser sem graça "ensinar padre a rezar missa" .
Nas empresas, quando vão selecionar quem serão os "felizardos" que terão tudo pago para ir pro FISL, quem é que eles mandam?! Normalmente, "envia esses caras do software livre para deixarem a gente em paz um tempinho". E os resistentes continuam resistindo...
Durante o evento, pensei na minha própria empresa. A maioria dos que lá estavam eram os diretores que já militam na causa há algum tempo ou membros dos Comitês Regionais do Software Livre, implantados como forma de disseminação da cultura. Mas tem que haver a ligação com aqueles que não tem nem idéia do que está acontecendo no mundo, presos no seu cotidiano apagando incêndios, respondendo e-mails vazios e participando/promovendo reuniões infundadas (tenho a impressão de já ter escrito isso!). Onde estavam os Superintentes, Gerentes de Área ou Divisão, enfim, a liderança média que realmente tem poder transformador nas organizações?
São essas pessoas que deveriam ir pro FISL, para quem sabe estando lá - vendo, ouvindo e sentindo - pudessem começar a perceber que "é verdade.... esse tal de software livre existe mesmo, não é apenas brincadeira...". De forma alguma estou negando a importância do patrocinador, do direcionamento claro vindo da diretoria nem de um planejamento estratégico vivo e efetivo. Mas mudança de cultura não é um simplemente processo Top-Down. Ela ocorre gradativamente e depende muito das gerencias intermediárias. O trabalho colaborativo dentro das empresas passa por aí. Mas que catequizar os ateus é uma tarefa árdua, lá isso é!
quarta-feira, 9 de abril de 2008
O que muda com a Web 2.0
Nessa "odisséia" bazedral pela busca do trabalho colaborativo nas empresas tradicionais, já demos uma passeada por alguns conceitos de software livre, passando por estratégias de atuação, tipos de projeto e motivações pessoais. Ainda seguindo a teoria do Gargalo está na gestão procurei usar uma linguagem simples para auxiliar pessoas não-técnicas a entender um pouco melhor esse mundo, de uma forma imparcial e desprendida de paixões filosófico-políticas. Continuo acreditando que o gestor (ou líder, gerente ou chefe, como queira chamar) precisa compreender como a colaboração ocorre da porta da empresa pra fora (internet) para encontrar os meios de alavancar de fato a cooperação interna.
Nesse contexto, ainda falta abordar uma nova realidade que nos cerca, representada pelo buzzword (espécie de jogada de marketing) Web 2.0. Usado pela primeira vez em 2004, chegou a se tornar o artigo mais citado da Wikipedia na língua inglesa em 2007. Se você "googlar" o termo, obterá mais de 70 milhões de páginas como resposta. Talvez dê um trabalhinho encontrar uma boa definição (até porque não existe um consenso sobre ela), mas pode valer a pena dar uma olhada no Wikipedia e no artigo What Is Web 2.0, da própria empresa (O'Reilly Media) que o criou. Numa linguagem mais fácil, sugiro Entenda o que é Web 2.0, da Folha On-line, e O que é Web 2.0, do Webinsider.
Como não queremos nos tornar especialistas no assunto, mas sim entender o que a Web 2.o tem a ver com trabalho colaborativo, tomarei emprestadas três definições curtas encontradas no ótimo Conceituando o que é Web 2.0:
Nesse contexto, ainda falta abordar uma nova realidade que nos cerca, representada pelo buzzword (espécie de jogada de marketing) Web 2.0. Usado pela primeira vez em 2004, chegou a se tornar o artigo mais citado da Wikipedia na língua inglesa em 2007. Se você "googlar" o termo, obterá mais de 70 milhões de páginas como resposta. Talvez dê um trabalhinho encontrar uma boa definição (até porque não existe um consenso sobre ela), mas pode valer a pena dar uma olhada no Wikipedia e no artigo What Is Web 2.0, da própria empresa (O'Reilly Media) que o criou. Numa linguagem mais fácil, sugiro Entenda o que é Web 2.0, da Folha On-line, e O que é Web 2.0, do Webinsider.
Como não queremos nos tornar especialistas no assunto, mas sim entender o que a Web 2.o tem a ver com trabalho colaborativo, tomarei emprestadas três definições curtas encontradas no ótimo Conceituando o que é Web 2.0:
“Web 2.0 usa a web como plataforma de socialização e interação entre usuários graças ao compartilhamento e criação conjunta de conteúdo." (Guilherme Felitti - repórter do IDG Now!)
“Web 2.0 é um novo paradigma na utilização e criação de web sites mais participativos e colaborativos.” (Fabio Seixas, criador do Camiseteria)
“Sinaliza uma fase na web onde se pratica a liberdade de falar e ser ouvido. É uma consequência natural do desenvolvimento da internet.” (Vicente Tardim, editor do Webinsider)
“Sinaliza uma fase na web onde se pratica a liberdade de falar e ser ouvido. É uma consequência natural do desenvolvimento da internet.” (Vicente Tardim, editor do Webinsider)
Esse comentário resume tudo: "Web 2.0 não é uma inovação, é uma mudança de paradigma da web centrada no EGO, para a web centrada no usuário, uma evolução natural que comecou quando “descobriram” que o elemento mais importante da internet não era quem criava os sites e sim o usuário que o visitava. A mudança passou da simples apresentação de conteúdo para a interação básica e hoje a interação das multidões, o já previsto conceito de inteligência coletiva previsto por Pierre Levy. A evolução é muito rápida, basta um piscar de olhos para perder uma fração do processo e ter a nítida sensação de que houve uma revolução." (João Carlos Caribé)
Portanto, independente das tecnologias envolvidas (que são várias, não necessariamente novas), o essencial é que o usuário passa de um mero leitor passivo, para alguém com voz ativa, que produz e consome informações de uma forma fácil, colaborativa e alucinante. Diferentemente do desenvolvimento de software de código aberto, no mundo da Web 2.0 praticamente não é preciso conhecimento técnico (Já experimentou criar um blog no blogger.com? Você não leva mais que 3 minutos!!).
São pessoas acostumadas a contar seu dia a dia e emitir suas opiniões em blogs, postar fotos de viagens no Flickr, resolver problemas usando fóruns de discussão, publicar seus vídeos no YouTube, criar comunidades e se relacionar através do Orkut, bater papo no MSN ou Skype, editar documentos em conjunto usando Wiki ou Google Docs, divulgar suas músicas no MySpace, trocar arquivos usando e-Mule ou BitTorrent, permanecer 100% do tempo conectado usando seus celulares, enviando mensagens enquanto assistem aula. Esses são apenas alguns poucos exemplos do que está acontecendo nesse mundo de total interconectividade.
Esses também são os profissionais que estão nas empresas, a cada dia em maior quantidade. Os mais novos são de uma geração que praticamente nasceu nessa realidade e não percebe o mundo de outra forma. Dentre os mais experientes, alguns conseguem se atualizar. Outros vão ficando pra trás.... De um jeito ou outro, são eles que trabalhan na sua empresa, cujo principal meio de comunicação ainda é o correio eletrônico. E o chefe fica em sua mesa, distribuindo ordens por escrito, ou então convocando reuniões longas e que não levam a lugar algum. E quando ele sai de férias, manda um e-mail para a equipe: "Fulano de tal estará me substituindo e monitorando minha caixa de correio". Fala sério!!! Como se administrar fosse limitado a isso....
Portanto, os executivos devem atentar prioritariamente para dois aspectos:
1) É preciso fornecer infra-estrutura tecnológica interna para possilitar as várias formas de interação que existem na internet (existem ferramentas livres e proprietárias para isso). Se você não fizer isso, os funcionários o farão. E sem você saber. Não duvide que existem hoje, "clandestinos" instalados em num servidor arranjado e colocado num canto qualquer, pelo menos um servidor Wiki ou um fórum de discussão.
2) É fundamental capacitar as lideranças para "falar essa linguagem", conhecer essas ferramentas e propiciar as novas formas de colaboração da Web 2.0. Existem CEOs fazendo isso em grandes empresas, publicando em blogs suas decisões, transformando a gestão em algo mais moderno e transparente. Mas isso precisa chegar na gerência média, aquela que "fica perto do pião". Já li uma vez que os funcionários comumente não demitem-se "da empresa", e sim do seu chefe imediato.
Espero ter ajudado a mostrar que, modismo ou não, a Web 2.0 está mudando as formas tradicionais de comunicação e colaboração. Temos que estar preparados!
São pessoas acostumadas a contar seu dia a dia e emitir suas opiniões em blogs, postar fotos de viagens no Flickr, resolver problemas usando fóruns de discussão, publicar seus vídeos no YouTube, criar comunidades e se relacionar através do Orkut, bater papo no MSN ou Skype, editar documentos em conjunto usando Wiki ou Google Docs, divulgar suas músicas no MySpace, trocar arquivos usando e-Mule ou BitTorrent, permanecer 100% do tempo conectado usando seus celulares, enviando mensagens enquanto assistem aula. Esses são apenas alguns poucos exemplos do que está acontecendo nesse mundo de total interconectividade.
Esses também são os profissionais que estão nas empresas, a cada dia em maior quantidade. Os mais novos são de uma geração que praticamente nasceu nessa realidade e não percebe o mundo de outra forma. Dentre os mais experientes, alguns conseguem se atualizar. Outros vão ficando pra trás.... De um jeito ou outro, são eles que trabalhan na sua empresa, cujo principal meio de comunicação ainda é o correio eletrônico. E o chefe fica em sua mesa, distribuindo ordens por escrito, ou então convocando reuniões longas e que não levam a lugar algum. E quando ele sai de férias, manda um e-mail para a equipe: "Fulano de tal estará me substituindo e monitorando minha caixa de correio". Fala sério!!! Como se administrar fosse limitado a isso....
Portanto, os executivos devem atentar prioritariamente para dois aspectos:
1) É preciso fornecer infra-estrutura tecnológica interna para possilitar as várias formas de interação que existem na internet (existem ferramentas livres e proprietárias para isso). Se você não fizer isso, os funcionários o farão. E sem você saber. Não duvide que existem hoje, "clandestinos" instalados em num servidor arranjado e colocado num canto qualquer, pelo menos um servidor Wiki ou um fórum de discussão.
2) É fundamental capacitar as lideranças para "falar essa linguagem", conhecer essas ferramentas e propiciar as novas formas de colaboração da Web 2.0. Existem CEOs fazendo isso em grandes empresas, publicando em blogs suas decisões, transformando a gestão em algo mais moderno e transparente. Mas isso precisa chegar na gerência média, aquela que "fica perto do pião". Já li uma vez que os funcionários comumente não demitem-se "da empresa", e sim do seu chefe imediato.
Espero ter ajudado a mostrar que, modismo ou não, a Web 2.0 está mudando as formas tradicionais de comunicação e colaboração. Temos que estar preparados!
segunda-feira, 24 de março de 2008
Software Livre: Caridade?!
Às vezes percebo, naqueles que pouco ou nada conhecem (e portanto não compreendem) o Software Livre (SL), uma certa discriminação. Para esses é difícil compreender que não se trata de uma questão de caridade, embora alguns realmente se colocarem como "fanáticos religiosos". Executivos resistentes precisam começar a enxergar que os modelos de negócio estão mudando. Existem outras formas de ganhar dinheiro (consultorias, treinamentos, serviços de valor agregado), além de vendendo licenças de um produto proprietário.
Não é à toa que muitas empresas tem bancado seus funcionários para trabalharem tempo parcial (às vezes, total), em projetos de código aberto. Ou até, como aconteceu com o Eclipse, simplesmente "doam" milhares de linhas de código, atribuindo uma licença livre ao seu software. A Sun seguiu o rastro, comprou a empresa que construiu o NetBeans e vem investindo pesadamente nos últimos anos. Não satisfeita abriu o Java como GPL e recentemente comprou a MySQL por 1 bilhão de dólares (veja em seu blog o que o próprio CEO fala sobre a aquisição). Quem ganha com a competição? Nós, desenvolvedores, com certeza. Mas você acha que eles não?!
Eric Raymond diz que "Para resolver um problema interessante, comece achando um problema que é interessante para você.". Pode parecer um pouco egoísta, mas faz bastante sentido. Se eu resolvo cooperar com algo é porque tenho interesse naquilo, serei beneficiado com os resultados. Não lhe parece lógico que a maioria dos desenvolvedores do Linux sejam também usuários? Quem ganha se o Linux evoluir rapidamente? Em primeiro lugar, eles próprios!
Apresentando essa visão "interesseira" não estou, de forma alguma, minando o princípio da colaboração e ajuda mútua. É claro que também tem muita gente imbuída - e isso deve ser louvado - do espírito social e investem seu tempo em fazer algo em benefício do próximo. Mas, no mundo do software, minha impressão (principalmente com relação à Bahia) é que, em geral:
1) Ainda somos "sanguessugas" - queremos usar SL, mas pouco contribuímos. Queremos participar de eventos, mas não ajudar a organizar.
2) Desenvolvedor é um "Ser Oso" - orgulhoso, vaidoso e teimoso. Tende a se achar melhor do que os outros, não gosta de receber crítica e termina "fazendo do meu jeito que é melhor". Conclusão: Retrabalho e pouca colaboração.
3) Gastamos muito tempo precioso - ninguém reclama em passar horas no Orkut, MSN ou jogando PlayStation. Nada contra a diversão, mas para participar ativamente de projetos/comunidades livres, "não tenho tempo".
4) Queremos tudo mastigado - vejo isso nas empresas. Muitos esperam sentados que caia do céu um treinamento que, quando chega, "foi muito fraco". Estudar constantemente é essencial e precisa de vontade pessoal. Hoje todo mundo tem no mínimo pós-graduação (falo do "canudo", porque o conhecimento, sei não...). Então, qual o seu diferencial?
5) Somos condicionados a competir, não a colaborar - Na escola, família, colégio, vestibular, universidade, temos que ser "os melhores". Trabalhar bem em equipes, sem subir nas costas dos outros, é um grande desafio. Quando algo dá errado ouvimos "a minha parte está ok" ao invés de "vamos trabalhar juntos na solução".
Então, fica aqui essa análise: De um lado o mundo está mudando e as principais empresas de TIC do mundo estão atentas (e agindo) quanto a isso. Do outro, continuamos como dizia Raul: "com a boca escancarada cheia de dentes, esperando a morte chegar". Profissionais diferenciados, além de todo o know-how técnico, desenvolverão mais cedo as habilidades necessárias para atuar nesse novo cenário. E quando os gerentes perceberem o que está ocorrendo, aí sim as empresas começarão a mudar significativamente.
Não é à toa que muitas empresas tem bancado seus funcionários para trabalharem tempo parcial (às vezes, total), em projetos de código aberto. Ou até, como aconteceu com o Eclipse, simplesmente "doam" milhares de linhas de código, atribuindo uma licença livre ao seu software. A Sun seguiu o rastro, comprou a empresa que construiu o NetBeans e vem investindo pesadamente nos últimos anos. Não satisfeita abriu o Java como GPL e recentemente comprou a MySQL por 1 bilhão de dólares (veja em seu blog o que o próprio CEO fala sobre a aquisição). Quem ganha com a competição? Nós, desenvolvedores, com certeza. Mas você acha que eles não?!
Eric Raymond diz que "Para resolver um problema interessante, comece achando um problema que é interessante para você.". Pode parecer um pouco egoísta, mas faz bastante sentido. Se eu resolvo cooperar com algo é porque tenho interesse naquilo, serei beneficiado com os resultados. Não lhe parece lógico que a maioria dos desenvolvedores do Linux sejam também usuários? Quem ganha se o Linux evoluir rapidamente? Em primeiro lugar, eles próprios!
Apresentando essa visão "interesseira" não estou, de forma alguma, minando o princípio da colaboração e ajuda mútua. É claro que também tem muita gente imbuída - e isso deve ser louvado - do espírito social e investem seu tempo em fazer algo em benefício do próximo. Mas, no mundo do software, minha impressão (principalmente com relação à Bahia) é que, em geral:
1) Ainda somos "sanguessugas" - queremos usar SL, mas pouco contribuímos. Queremos participar de eventos, mas não ajudar a organizar.
2) Desenvolvedor é um "Ser Oso" - orgulhoso, vaidoso e teimoso. Tende a se achar melhor do que os outros, não gosta de receber crítica e termina "fazendo do meu jeito que é melhor". Conclusão: Retrabalho e pouca colaboração.
3) Gastamos muito tempo precioso - ninguém reclama em passar horas no Orkut, MSN ou jogando PlayStation. Nada contra a diversão, mas para participar ativamente de projetos/comunidades livres, "não tenho tempo".
4) Queremos tudo mastigado - vejo isso nas empresas. Muitos esperam sentados que caia do céu um treinamento que, quando chega, "foi muito fraco". Estudar constantemente é essencial e precisa de vontade pessoal. Hoje todo mundo tem no mínimo pós-graduação (falo do "canudo", porque o conhecimento, sei não...). Então, qual o seu diferencial?
5) Somos condicionados a competir, não a colaborar - Na escola, família, colégio, vestibular, universidade, temos que ser "os melhores". Trabalhar bem em equipes, sem subir nas costas dos outros, é um grande desafio. Quando algo dá errado ouvimos "a minha parte está ok" ao invés de "vamos trabalhar juntos na solução".
Então, fica aqui essa análise: De um lado o mundo está mudando e as principais empresas de TIC do mundo estão atentas (e agindo) quanto a isso. Do outro, continuamos como dizia Raul: "com a boca escancarada cheia de dentes, esperando a morte chegar". Profissionais diferenciados, além de todo o know-how técnico, desenvolverão mais cedo as habilidades necessárias para atuar nesse novo cenário. E quando os gerentes perceberem o que está ocorrendo, aí sim as empresas começarão a mudar significativamente.
terça-feira, 18 de março de 2008
Os 5 Tipos de Projeto Open Source
Procurando informações sobre tipos de projeto de código aberto, achei um texto muito interessante de Josh Berkus, membro do time do PostgreSQL desde 2002. Em The 5 Types of Open Source Projects, ele procurou uma classificação organizacional, focando em quem toma as decisões, quais são objetivos estratégicos, como alguém pode se juntar ao projeto, dentre outros. Farei aqui um breve resumo, dando uma pitada da minha visão.
1 - Solo. Um ou dois colaboradores mantém 100% do código e tomam todas as decisões. Normalmente é fácil contribuir, afinal eles abriram o código com objetivo de compartilhar, portanto sentem-se meio que emocionados quando alguém oferece ajuda. A maioria (mais de 90%) dos projetos está nessa categoria.
2 - Monarquia. É um "Solo que deu certo". Mesmo tendo uma criado uma comunidade grande em torno do projeto, as decisões principais ainda são tomadas pelo seu líder ou um pequeno grupo por ele indicado. Contribuir (e obter retorno) é relativamente fácil, ainda mais quando há aproximação com o líder ou o núcleo principal.
3 - Comunidade. Com um número significativo de contribuintes, existe um processo social intenso (fóruns e listas extremamente ativos) e as decisões são tomadas numa combinação de meritocracia e concenso. A"voz" de cada um é proporcional à qualidade e quantidade das contribuições.
4 - Corporativo. Geralmente código fechado de uma empresa, que mesmo após aberto ainda não se desvencilhou dela. A maioria dos colaboradores ainda é empregado da companhia, portanto sujeita aos seus direcionamentos. Contribuir é frequentemente difícil, por isso os programadores independentes não se sentem muito atraídos. Um suporte de melhor qualidade pode ser obtido através de um contrato ou licença comercial.
5 - Fundação. O ponto máximo de organização formal em um projeto open source bem sucedido, que necessita das vantagens de uma estrutura legal e a possibilidade de empregar funcionários e receber doações. O ingresso (individual ou de empresa) normalmente passa por um processo formal. Existem patrocinadores que também dão sustentação comercial.
A classificação de 1 a 5, acima, indica uma tendência crescente de formalismo. Os Solo são mais informais e menos burocráticos, enquanto os Corporativos e de Fundação possuem exigências e regras documentadas, inevitável aos seus participantes. Berkus enfatiza que essa é uma classificação subjetiva, sugerindo que verifiquemos as coisas por nós mesmos.
Finalizando, entender como funciona o mundo do Software Livre nos ajudará a encontrar os caminhos para promover uma maior colaboração interna às organizações. Nada melhor, porém, que participar ativamente de algum tipo de comunidade ou grupo de usuários, para perceber o quanto estamos perdendo tempo em aplicar esses princípios no nosso dia-a-dia. Escolha um tema do seu interesse e comece já!!!
1 - Solo. Um ou dois colaboradores mantém 100% do código e tomam todas as decisões. Normalmente é fácil contribuir, afinal eles abriram o código com objetivo de compartilhar, portanto sentem-se meio que emocionados quando alguém oferece ajuda. A maioria (mais de 90%) dos projetos está nessa categoria.
2 - Monarquia. É um "Solo que deu certo". Mesmo tendo uma criado uma comunidade grande em torno do projeto, as decisões principais ainda são tomadas pelo seu líder ou um pequeno grupo por ele indicado. Contribuir (e obter retorno) é relativamente fácil, ainda mais quando há aproximação com o líder ou o núcleo principal.
3 - Comunidade. Com um número significativo de contribuintes, existe um processo social intenso (fóruns e listas extremamente ativos) e as decisões são tomadas numa combinação de meritocracia e concenso. A"voz" de cada um é proporcional à qualidade e quantidade das contribuições.
4 - Corporativo. Geralmente código fechado de uma empresa, que mesmo após aberto ainda não se desvencilhou dela. A maioria dos colaboradores ainda é empregado da companhia, portanto sujeita aos seus direcionamentos. Contribuir é frequentemente difícil, por isso os programadores independentes não se sentem muito atraídos. Um suporte de melhor qualidade pode ser obtido através de um contrato ou licença comercial.
5 - Fundação. O ponto máximo de organização formal em um projeto open source bem sucedido, que necessita das vantagens de uma estrutura legal e a possibilidade de empregar funcionários e receber doações. O ingresso (individual ou de empresa) normalmente passa por um processo formal. Existem patrocinadores que também dão sustentação comercial.
A classificação de 1 a 5, acima, indica uma tendência crescente de formalismo. Os Solo são mais informais e menos burocráticos, enquanto os Corporativos e de Fundação possuem exigências e regras documentadas, inevitável aos seus participantes. Berkus enfatiza que essa é uma classificação subjetiva, sugerindo que verifiquemos as coisas por nós mesmos.
Finalizando, entender como funciona o mundo do Software Livre nos ajudará a encontrar os caminhos para promover uma maior colaboração interna às organizações. Nada melhor, porém, que participar ativamente de algum tipo de comunidade ou grupo de usuários, para perceber o quanto estamos perdendo tempo em aplicar esses princípios no nosso dia-a-dia. Escolha um tema do seu interesse e comece já!!!
sábado, 1 de março de 2008
V0
"Libere cedo. Libere frequentemente. E ouça seus fregueses.". Para mim esse é um dos trechos mais inteligentes e profundos da Catedral e o Bazar e se aplica a diversos casos, não só a produção de código. Analisemos uma situação típica nas empresas, para interpretar o conceito.
Está em elaboração um novo processo interno, inspirado em algum modelo de referência ou conjunto de melhores práticas (PMBOK, CMMI, ITIL, XP ou RUP, por exemplo). Até aí nenhum problema, afinal modelar/reavaliar processos é fundamental para uma organização em crescente melhoria. Mas como sua empresa o faria? Provavelmente contrataria uma consultoria e colocaria para trabalhar junto com meia dúzia de "papas do conhecimento", pessoas com (teoricamente) vasto conhecimento sobre o assunto, ou pelo menos gosto por aprendizagem. Depois de alguns meses (às vezes, anos), a primeira versão está disponível para uso. Políticas, normas, diagramas, manuais de procedimentos, templates de artefatos, tudo pronto! Agora podemos usar! Palestras, reuniões de sensibilização, equipes de auditoria, grupos de trabalho, todo mundo mobilizado (espera-se!) para internalizar a nova realidade. Sucesso absoluto?! Raramente...
Quantas vezes você viu programas desse tipo fracassarem? Qual são normalmente as maiores falhas? Esquecem de ouvir as pessoas! Aqueles que de fato executam os processos e teriam muito a contribuir. Estabelecem uma divisão entre os teóricos ("aqueles que definem os processos mas não sabem nada do dia a dia") e os práticos ("os que trabalham"). Nem 8 nem 80, né!? Os dois tipos de perfil são necessários, mas eles precisam trabalhar juntos.
Voltemos. Se ao invés de trabalharem "trancados" e só envolverem as pessoas com um processo teoricamente pronto, fosse liberada uma primeira versão ainda bem insipiente (libere cedo), mas que permitisse a crítica e validação do corpo funcional, quantos problemas seriam evitados?
Com várias revisões coletivas (libere frequentemente), o quão rápido chegaríamos numa primeira versão estável? Aliás, seria necessário esperar tanto para começar a praticar? Pensou nos benefícios em partir para avaliar a prática executando um piloto em um departamento ou projeto?
E o principal, oferecendo (e incentivando) a oportunidade de contribuição das pessoas (ouça seus fregueses) o quanto se queimam etapas? As pessoas começam a conhecer, praticar, identificar falhas e pontos de melhoria e aos poucos passam a acreditar, pois sentem-se comprometidas com o resultado. Como está no texto de Raymond, os usuários são constantemente mantidos "estimulados pela perspectiva de estar tendo um pouco de ação satisfatória do ego, recompensados pela visão do constante (até mesmo diário) melhoramento do seu trabalho.".
Portanto, precisamos estimular a cultura da Versão Zero. Até pela velocidade com que as coisas mudam, não dá para esperar modelar o mundo perfeito para depois divulgar e envolver o restante da empresa. "O bom é inimigo do ótimo", mas começando pelo "quase bom" (V0) - liberando cedo, frequentemente e ouvindo seus fregueses - é possível chegar lá!.
Está em elaboração um novo processo interno, inspirado em algum modelo de referência ou conjunto de melhores práticas (PMBOK, CMMI, ITIL, XP ou RUP, por exemplo). Até aí nenhum problema, afinal modelar/reavaliar processos é fundamental para uma organização em crescente melhoria. Mas como sua empresa o faria? Provavelmente contrataria uma consultoria e colocaria para trabalhar junto com meia dúzia de "papas do conhecimento", pessoas com (teoricamente) vasto conhecimento sobre o assunto, ou pelo menos gosto por aprendizagem. Depois de alguns meses (às vezes, anos), a primeira versão está disponível para uso. Políticas, normas, diagramas, manuais de procedimentos, templates de artefatos, tudo pronto! Agora podemos usar! Palestras, reuniões de sensibilização, equipes de auditoria, grupos de trabalho, todo mundo mobilizado (espera-se!) para internalizar a nova realidade. Sucesso absoluto?! Raramente...
Quantas vezes você viu programas desse tipo fracassarem? Qual são normalmente as maiores falhas? Esquecem de ouvir as pessoas! Aqueles que de fato executam os processos e teriam muito a contribuir. Estabelecem uma divisão entre os teóricos ("aqueles que definem os processos mas não sabem nada do dia a dia") e os práticos ("os que trabalham"). Nem 8 nem 80, né!? Os dois tipos de perfil são necessários, mas eles precisam trabalhar juntos.
Voltemos. Se ao invés de trabalharem "trancados" e só envolverem as pessoas com um processo teoricamente pronto, fosse liberada uma primeira versão ainda bem insipiente (libere cedo), mas que permitisse a crítica e validação do corpo funcional, quantos problemas seriam evitados?
Com várias revisões coletivas (libere frequentemente), o quão rápido chegaríamos numa primeira versão estável? Aliás, seria necessário esperar tanto para começar a praticar? Pensou nos benefícios em partir para avaliar a prática executando um piloto em um departamento ou projeto?
E o principal, oferecendo (e incentivando) a oportunidade de contribuição das pessoas (ouça seus fregueses) o quanto se queimam etapas? As pessoas começam a conhecer, praticar, identificar falhas e pontos de melhoria e aos poucos passam a acreditar, pois sentem-se comprometidas com o resultado. Como está no texto de Raymond, os usuários são constantemente mantidos "estimulados pela perspectiva de estar tendo um pouco de ação satisfatória do ego, recompensados pela visão do constante (até mesmo diário) melhoramento do seu trabalho.".
Portanto, precisamos estimular a cultura da Versão Zero. Até pela velocidade com que as coisas mudam, não dá para esperar modelar o mundo perfeito para depois divulgar e envolver o restante da empresa. "O bom é inimigo do ótimo", mas começando pelo "quase bom" (V0) - liberando cedo, frequentemente e ouvindo seus fregueses - é possível chegar lá!.
segunda-feira, 18 de fevereiro de 2008
E esse tal de Software Livre?
Software Livre, na definição do Wikipedia, é qualquer programa de computador que pode ser usado, copiado, estudado, modificado e redistribuído sem nenhuma restrição. A maioria dos softwares livres é distribuída através de uma licença, como a mais conhecida GNU GPL.
Algumas das características marcantes do desenvolvimento do SL envolvem: Desenvolvimento descentralizado via internet - apoiado por ferramentas de comunicação e colaboração; Interesse pessoal do autor - por também ser usuário do software tem, portanto, motivação pessoal na sua criação e manutenção, apoiando seus usuários e fazendo esse grupo crescer; Usuários participantes - é comum que os usuários finais se comuniquem com alguma regularidade, entre si e com os desenvolvedores, comunicando problemas e trocando experiências; Liberdade de escolha - os desenvolvedores podem escolher o trabalho que desejam realizar.
Agora pense na sua empresa. Não seria bom trabalhar em projetos com essas características? Mas no mundo real nem sempre é possível. Você às vezes é obrigado a trabalhar usando tecnologia ultrapassada, num sistema que não gosta, com ferramentas inadequadas, em atividades que não escolheu e com prazos que não assumiu. E, pior ainda, aturando um chefe "mala" ultrapassado tecnicamente e sem a menor habilidade gerencial. Vai falar pra ele que quer desenvolver colaborativamente, usando termos bonitos como Open Source, Meritocracia e Wiki. No mínimo você vai ouvir: "Ô meu filho, deixa de gracinha e vai trabalhar, vai!".
Segundo Raymond, "um coordenador ou líder de um projeto no estilo Bazar deve ter boa habilidade de comunicação e relacionamento. Isto deve parecer óbvio. Para construir uma comunidade de desenvolvimento, você precisa atrair pessoas, fazer com que se interessem no que você está fazendo, e mantê-las alegres sobre a quantidade de trabalho que estão fazendo. O entusiasmo técnico constitui uma boa parte para atingir isto, mas está longe de ser toda história. A personalidade que você projeta também importa. Não é uma coincidência que Linus é um rapaz gentil que faz com que as pessoas gostem dele e que o ajudem. Não é uma coincidência que eu seja um enérgico extrovertido que gosta de trabalhar com pessoas e tenha um pouco de porte e instinto de um cômico. Para fazer o modelo Bazar funcionar, isto ajuda enormemente se você tem pelo menos um pouco de habilidade para encantar as pessoas". E ele diz ainda: "Eu penso que não é crítico que o coordenador seja capaz de originar projetos de excepcional brilho, mas é absolutamente crítico que o coordenador seja capaz de reconhecer boas idéias de projetos de outras pessoas."
Portanto, se você é diretor ou gerente de uma empresa, minhas sugestões são: Participe de alguma comunidade ou projeto de código aberto, pois você vai começar a entender a dinâmica da coisa; Escolha melhor seus líderes e discuta com eles as formas de trabalhar colaborativamente; Estimule a colaboração nas pequenas coisas, seja parar o que está fazendo para auxiliar um colega, registrar num Wiki ou blog interno a solução para um problema que você enfrentou ou desenvolver um código/componentes sempre pensando em reutilização; Estude continuamente, pois as coisas mudam rápido.
Finalizo com uma dica de leitura: Producing Open Source Software - How to Run a Successful Free Sofware Project, de Karl Fogel. É um livro sobre o lado humano do desenvolvimento Open Source, que descreve como projetos bem sucedidos operam, a expectativa dos usuários e desenvolvedores e a cultura do software livre. O livro é distribuído usando o Open Copyright e você pode baixar o PDF.
Até a próxima!
Algumas das características marcantes do desenvolvimento do SL envolvem: Desenvolvimento descentralizado via internet - apoiado por ferramentas de comunicação e colaboração; Interesse pessoal do autor - por também ser usuário do software tem, portanto, motivação pessoal na sua criação e manutenção, apoiando seus usuários e fazendo esse grupo crescer; Usuários participantes - é comum que os usuários finais se comuniquem com alguma regularidade, entre si e com os desenvolvedores, comunicando problemas e trocando experiências; Liberdade de escolha - os desenvolvedores podem escolher o trabalho que desejam realizar.
Agora pense na sua empresa. Não seria bom trabalhar em projetos com essas características? Mas no mundo real nem sempre é possível. Você às vezes é obrigado a trabalhar usando tecnologia ultrapassada, num sistema que não gosta, com ferramentas inadequadas, em atividades que não escolheu e com prazos que não assumiu. E, pior ainda, aturando um chefe "mala" ultrapassado tecnicamente e sem a menor habilidade gerencial. Vai falar pra ele que quer desenvolver colaborativamente, usando termos bonitos como Open Source, Meritocracia e Wiki. No mínimo você vai ouvir: "Ô meu filho, deixa de gracinha e vai trabalhar, vai!".
Segundo Raymond, "um coordenador ou líder de um projeto no estilo Bazar deve ter boa habilidade de comunicação e relacionamento. Isto deve parecer óbvio. Para construir uma comunidade de desenvolvimento, você precisa atrair pessoas, fazer com que se interessem no que você está fazendo, e mantê-las alegres sobre a quantidade de trabalho que estão fazendo. O entusiasmo técnico constitui uma boa parte para atingir isto, mas está longe de ser toda história. A personalidade que você projeta também importa. Não é uma coincidência que Linus é um rapaz gentil que faz com que as pessoas gostem dele e que o ajudem. Não é uma coincidência que eu seja um enérgico extrovertido que gosta de trabalhar com pessoas e tenha um pouco de porte e instinto de um cômico. Para fazer o modelo Bazar funcionar, isto ajuda enormemente se você tem pelo menos um pouco de habilidade para encantar as pessoas". E ele diz ainda: "Eu penso que não é crítico que o coordenador seja capaz de originar projetos de excepcional brilho, mas é absolutamente crítico que o coordenador seja capaz de reconhecer boas idéias de projetos de outras pessoas."
Portanto, se você é diretor ou gerente de uma empresa, minhas sugestões são: Participe de alguma comunidade ou projeto de código aberto, pois você vai começar a entender a dinâmica da coisa; Escolha melhor seus líderes e discuta com eles as formas de trabalhar colaborativamente; Estimule a colaboração nas pequenas coisas, seja parar o que está fazendo para auxiliar um colega, registrar num Wiki ou blog interno a solução para um problema que você enfrentou ou desenvolver um código/componentes sempre pensando em reutilização; Estude continuamente, pois as coisas mudam rápido.
Finalizo com uma dica de leitura: Producing Open Source Software - How to Run a Successful Free Sofware Project, de Karl Fogel. É um livro sobre o lado humano do desenvolvimento Open Source, que descreve como projetos bem sucedidos operam, a expectativa dos usuários e desenvolvedores e a cultura do software livre. O livro é distribuído usando o Open Copyright e você pode baixar o PDF.
Até a próxima!
Assinar:
Postagens (Atom)