finito

Categoria: Biblioteca

Dicas de livros e outras referências.

  • Modelagem de Negócios: A Encruzilhada

    Se não vai no atacado, vai no varejo mesmo!1 Há tempos ameaço retomar a publicação de artigos técnicos aqui no finito. Tardei. Espero não falhar.

    Já comentei por aqui: a modelagem de negócios é, entre todas as disciplinas que dão forma para a engenharia de software, a menos compreendida. Consequentemente é pouco e mal utilizada. No entanto, surgem evidências e suspeitas de que esta situação deve mudar. Iniciativas SOA, BPM e de Arquitetura Corporativa, em níveis diferentes, exigem a existência ou a criação de modelos de negócios. Mas não se trata de outra demanda ‘falsa’, parida exclusivamente nos domínios de TI. O pessoal do mundo do negócio também começou a perceber os benefícios de bons modelos de negócios. O que nos traz para a encruzilhada do título. Neste artigo vou apresentar duas alternativas de modelagem, uma bem TI e outra bem “negócio”. Ambas foram apresentadas em livros lançados recentemente. E indicam um momento crítico para a evolução da disciplina.

    Encruzilhada

    Modelando Negócios, segundo TI

    Acabou de sair, pela Morgan Kaufmann/OMG (Object Management Group), o livro “Business Modeling – A Practical Guide to Realizing Business Value“, de David M. Bridgeland e Ron Zahavi. Como obras que tratam exclusivamente a modelagem de negócios ainda são raríssimas, este lançamento merece destaque. E vai receber. Repare, não se trata de um livro sobre BPM e afins. O papo aqui é apenas sobre modelagem. Os autores, otimistas, começam mostrando que a tendência é de uma crescente adoção da disciplina. E apostam que por volta de 2011 ela atingirá “massa crítica”2. Justificam suas apostas de forma simples: “a Modelagem de Negócios se tornou mais popular porque transformações em negócios se tornaram mais comuns“. E explicam que “modelos ajudam na implementação de mudanças. Se nada muda, você não precisa de modelos, assim como não precisa de mapas se não pretende viajar para lugar nenhum“.Business Modeling

    Os autores mostram que a modelagem pode gerar valor para o negócio de oito maneiras: i) Comunicação entre pessoas; ii) Treinamento e Aprendizado; iii) Persuasão e Vendas; iv) Análise de alguma situação do negócio; v) Gestão de Conformidade; vi) Desenvolvimento de Requisitos de Software; vii) Execução direta dos modelos através de mecanismos de software; e viii) Gestão do Conhecimento e Reuso.

    A lista, apesar de extensa, me parece incompleta. Neste ponto os autores não citaram a possibilidade de simulação e experimentação de novas ideias e a identificação de oportunidades de outsourcing de processos (BPO), por exemplo. Mas as omissões são relativamente pequenas. O que me preocupa de verdade são as sugestões apresentadas no livro.

    Bridgeland e Zahavi partem do princípio de que não há um padrão completo para a modelagem de negócios. E não deixam de reclamar em diversos momentos do texto a total ausência de ferramentas que contemplem uma “completa” modelagem. Eles apresentam a modelagem como um conjunto de 4 disciplinas: Modelagem da Motivação do Negócio, da Organização, dos Processos e das Regras. Completo, na visão deles, seria um padrão que possibilitasse a criação de modelos das 4 disciplinas. Eu acredito que o problema foi criado pelos próprios autores, no “quebra-cabeças” de padrões que eles selecionaram.

    Para a modelagem da motivação do negócio eles optaram por um novíssimo e único padrão existente, o BMM (Business Motivation Model), um trabalho do BRG (Business Rules Group) aceito pelo OMG em agosto de 2008. Como os próprios autores acusam, o OMG cometeu grave pecado ao aceitar e liberar o padrão antes de definir seu perfil visual – um padrão para os diagramas. O BMM cuida da visão (fim) e da missão (meios) de um negócio, de maneira abrangente e consistente. Mas parece uma ilha isolada do resto do mundo. Não se relaciona com nenhum padrão existente. Talvez o OMG tente incorporá-lo futuramente a algum metamodelo. No entanto, quando o assunto é o OMG e seus constituintes, tudo é incerto.

    Há tempos eu joguei todas as minhas fichas na EPBE (Eriksson-Penker Business Extensions). E sempre reconheci que a forma como essa extensão trata dos objetivos (motivações) do negócio é fraca. Por isso apresento mapas estratégicos e BSC’s (Balanced Scorecards) como complementos. Como a EPBE é extensível como sua base, a UML, não tive nenhuma dificuldade em incorporar a ela o BMM. Oportunamente eu falo mais sobre BMM e EPBE. Mas se você não aguenta de curiosidade, relembre aqui o metamodelo EPBE e obtenha aqui uma visão geral (bem alto nível) do BMM.

    O problema dos autores aumenta quando eles entram em sua segunda disciplina, a Modelagem da Organização. Eles afimam que não haveria um padrão para a construção desses modelos. Quem diria, nossos velhos e bons organogramas carecem de um padrão. Mas a questão não é só essa. Bridgeland e Zahavi ignoram outros recursos, outros elementos da estrutura de um negócio. Não citam, por exemplo, a necessidade de modelagem de produtos, serviços etc. A EPBE fala em Visão da Estrutura, não de Modelagem da Organização. A EPBE contempla, portanto, a modelagem de qualquer tipo de recurso.

    É fácil entender a omissão ao vermos o padrão que eles selecionaram para a Modelagem de Processos. Sim, eles optaram pela BPMN. Um padrão cheio de promessas e com um futuro promissor, mas que entrega muito pouco quando o assunto é *Modelagem de Negócios*.Sigo aguardando ansioso pelo dia em que uma boa alma apareça dizendo: “gente, BPMN é só um fluxograma 3.0 – um falso padrão3 sacaneado por ilustres fornecedores que deveriam defendê-lo. Um falso padrão que tem pouco ou nenhum valor quando nossa preocupação é entender um negócio“.

    Os autores justificam sua não opção pela UML dizendo que esta é muito ‘complicada’ para usuários finais. Concordo. Mas, apesar deles citarem o trabalho de Eriksson e Penker, “Business Modeling with UML“, ignoram por completo a EPBE. Ao relacionarem UML exclusivamente com o diagrama de atividades, demonstram desconhecer todas as outras opções de diagramas apresentadas no trabalho da dupla escandinava. Sigo desconfiado de que é este pequeno detalhe geográfico que segue fazendo da EPBE uma ilustre desconhecida.

    Problema dos autores, que tiveram que se revirar ainda mais no momento de fixar um padrão para sua última disciplina, a Modelagem de Regras. Acertam na escolha do SBVR (Semantics of Business Vocabulary and Business Rules), outro padrão adotado pelo OMG em 2008. Mas não conseguem deixar de mostrar a fragilidade das ligações desta com as outras 3 disciplinas que formam sua proposta. Eles reclamam muito da deficiência de ferramentas. O buraco é mais embaixo: os 4 padrões sugeridos pelos autores carecem de um alicerce único, de um metamodelo. Ao jogarem todas as suas fichas em padrões do OMG, implicitamente os autores apostam que esta entidade será capaz de suprir essa imensa necessidade. Ao ver os probleminhas que o OMG tem enfrentado só com a BPMN 2.0, sou obrigado a ‘mineiramente’ desconfiar. Com seus passos de cágado, talvez lá em 2037 o OMG apresente uma bela sugestão de metamodelo para uma completa modelagem de negócios. Vamos esperar sentados?

    O Negócio pelo Negócio

    É um livro de modelagem?!?Aí vem aquele “velho” cara de negócios e pergunta: “meu caro, diz aí, o tal OMG entende de negócios?” Antes que uma resposta (ou desculpa) pinte em nossas cabeças, o velho saca de sua estante um estranho livro quadrado: “The Back of the Napkin“, de Dan Roam (Portfolio – 2008). O velho nos diz: “Parece que o tal do Dan aí entende de negócios, e presta serviços de consultoria para empresas como Google, eBay, GE, Wal-Mart…”

    Se o livro de Dan Roam usou o termo “modelagem” em algum momento passou despercebido. Ele prefere o termo “Pensamento Visual”. Mas seu livro é só sobre isso: Modelagem de Negócios. Saca só o subtítulo: “Resolvendo Problemas e Vendendo Ideias com Figuras”. Não espere ver nada sobre UML, BPMN e coisinhas afins. Dan é um cara de negócios. E, por isso mesmo, insiste que devemos fugir de ferramentas informatizadas: “mão, caneta e guardanapos são suficientes para resolvermos qualquer problema de negócio!” Radical? Não, prático e pragmático mesmo. E, preciso dizer, ágil!

    Dan apresenta uma metodologia completa, formada por 4 elementos. Ele a apresenta como um “canivete suiço”. Sua primeira parte é formada por “3 ferramentas básicas para o pensamento visual”: nossos olhos, mente e mãos. Na sequência ele apresenta as 4 fases do pensamento visual: Ver, Observar, Imaginar e Mostrar4.Aí vem o SQVID5, uma série de 5 perguntas que “nos ajuda a abrir os olhos da mente: simples ou elaborado, qualitativo ou quantitativo, visão ou execução, individual ou comparações, mudança ou ‘as-is’?” Por fim as 6 formas como enxergamos que também são as formas como deveríamos mostrar, os 6W’s: “Who/what, hoW much, Where, When, hoW e Why”. Parece bobinho, não? Se você não reparou, até a sequência como o “canivete” é apresentado é “simplificadora”: 3 (ferramentas básicas), 4 (passos), 5 (perguntas) e 6 (formas de ver/mostrar).

    Parece bobinho, mas Dan escora suas sugestões em bases muitos fortes, como pesquisas muito recentes no campo da neurobiologia. Os 6 W’s, por exemplo, realmente representam a sequência pela qual nossos olhos passam informações para o cérebro. Por isso seriam intuitivas, naturais. Logo no início do livro o autor se preocupa em “escorar” suas sugestões. Em três páginas quase consecutivas ele nos convida a visitar o apêndice A, “A Ciência do Pensamento Visual”. Justamente para derrubar nossas possíveis desconfianças e mostrar que, apesar de simples, suas propostas são sérias. Aliás, a simplicidade é uma grande qualidade de seu trabalho. Porém, mais que o alicerce científico, são os casos reais apresentados que atestam a utilidade e força de seu método.

    O ‘Codex’ do Pensamento VisualAcontece que, a primeira vista, as sugestões de Dan Roam parecem totalmente incompatíveis com a disciplina que conhecemos como Modelagem de Negócios. Em nenhum momento ele cita o OMG ou coisinhas mais ‘pop’, como BPMN. Trata-se realmente de outro mundo.

    O diagrama acima mostra do “CODEX” do Pensamento Visual, uma grade que cruza os 6 W’s com as 5 decisões que tomamos no SQVID. Repare que, para cada W, Dan sugere apenas um tipo de desenho: retrato para o “quem/o que”; gráfico de barras para o “quanto”; mapas para o “onde”; cronograma ou linha de tempo para o “quando”; fluxograma para o “como”; e um gráfico comparativo (plot) para o “porque”. O SQVID ajuda a definir uma versão diferente para cada tipo de desenho.A única sugestão de Dan que se aproxima minimamente de nosso mundo é o fluxograma. Todos os outros desenhos parecem distantes de tudo que conhecemos para a modelagem de negócios: retratos, mapas, gráficos de barras…

    Precisa ser assim? Digo, TI e negócio precisam ser tão distantes até nisso, numa disciplina que deveria ajudar um a compreender melhor o outro? O mundo de TI precisa seguir insistindo em padrões lentamente definidos e sistematicamente desrespeitados?

    Como a Modelagem de Negócios é uma disciplina ainda em fase de definição, acho que é hora de revermos alguns caminhos, particularmente aqueles trilhados pelo OMG e fornecedores de ferramentas como SAP, IBM e Oracle.

    Em paralelo, os Analistas de Negócios, principais usuários da Modelagem de Negócios, devem procurar uma base que combine o melhor dos dois mundos. No próximo artigo apresentarei uma sugestão, um ‘remix’ das ideias de Dan executado na vitrola da EPBE/UML. Inté!

    Notas:

    1. O “atacado” seria o livro, que já toca neste assunto (com outras palavras. Aliás, muito mais palavras e figuras). Mas, como eu já disse em um pequeno post-agenda, não se trata apenas de um livro, mas também de um novo negócio e um sistema. Adiei o lançamento para costurar melhor todas as partes. Conto com a compreensão e paciência de todos.
    2. Em dinâmica social, massa crítica é a mentalidade de um grupo que é suficiente para, em quantidade e qualidade, permitir, propiciar e sustentar determinada ação ou comportamento. (Wikipedia).
    3. Digo que BPMN é um falso padrão porque ele não é respeitado por quase ninguém. Grandes fornecedores, como IBM, Oracle e SAP, insistem em ter seu “sabor” do padrão. Claro, assim eles dificultam a debandada de clientes insatisfeitos. Nada de novo no front de TI: SQL, HTML, COBOL e várias outras coisinhas também nasceram um dia para serem “padrões”.
    4. Minha tradução livre para Look, See, Imagine e Show.
    5. SQVID é uma sigla estranha mas de fácil compreensão: Simple, Quality, Vision, Individual e Change (D é de delta, mudança). O SQVID é apresentado como um seletor ou equalizador. O nome indica as primeiras opções. O contraponto, na mesma sequência, é: Elaborate, Quantity, Execution, Comparison e As-is.  Como o gráfico acima ilustra, para cada um dos 6 W’s escolhemos um lado do SQVID. Simples ou Elaborado, por exemplo.

    A foto utilizada neste artigo é de Kevin Slavin (Flickr). Aliás, vale a pena olhar o curioso jogo “Crossroads” que ele montou com GPS, usando Manhatan como tabuleiro.

  • Você não pode julgar um livro pela capa

    Título surrupiado / traduzido de “You Can’t Judge a Book by its Cover”, de Willie Dixon. Um blusão gravado originalmente por Bo Diddley, em 1962. Pura verdade. Não fosse, eu nunca teria conhecido aquele que citei no último artigo como o melhor livro de TI e gerenciamento de projetos que já li, “The Art of Project Management“, de Scott Berkun. Saca só a capinha aí do lado: mais feia e enigmática impossível, não?

    Mas a frase do Willie não deve servir de desculpa para que a capa e toda a programação visual de um livro sejam relegados ao 2º plano. Estética, beleza – são preocupações que devemos ter em tudo o que fazemos. Não sou bom nisso, mas sei apreciar um trabalho bonito. E criticar a feiúra alheia…

    Há tempos contatei uma empresa de design “maluca”, que participa do SP Fashion Week, decorou alguns dos principais restaurantes de Sampa e tem um espírito criativo sadiamente distante do nosso insípido e gelado mundinho de TI. Meu único requisito: não quero que meu livro se pareça com um livro de TI, particularmente os tupiniquins. Tem bobo aí que vai dizer que isso é papo de boiola e coisa e tal. Breve e única resposta para eles: a forma deve refletir e valorizar o conteúdo. Não é só uma questão de linhas e cores, mas de conceito, de integridade. Mas eu não quero falar só de programação visual, e sim de tudo que gira em torno do formato de um livro.

    O livro impresso é uma das invenções mais longevas da humanidade – de Gutenberg pra cá já se foram 572 anos! A tecnologia de impressão mudou bastante, mas o produto final quase nada. E nenhuma edição digital conseguiu nos dar a manuseabilidade de um livro ‘normal’. Uma leitura de verdade se faz com um livro em mãos, passando suas páginas de uma forma que para outros olhos parece ser uma coisa aleatória e desprovida de lógica. Um livro ‘de verdade’ pode ser marcado, rabiscado, anotado. Um livro de fato lido fica gasto, meio manchado. E não raro tem memória: costuma abrir exatamente naquelas páginas mais necessárias em determinados momentos. Ok, meu papo soou um tanto romântico. Mas quem lê de verdade sabe do que estou falando. E apronta com seus livros algo parecido com o que faço com os meus. Meus livros não recebem o mesmo cuidado que os discos e DVDs. Mas sua valorização, por visitas e amigos, é realmente inversa. Os mais surrados são aqueles de maior valor. Meus amigos sabem. E os livros não me deixam mentir.

    Livro lido é livro gasto.Durante o projeto do livro fui confrontado com duas questões que, a princípio, estavam totalmente fora do meu escopo. A primeira referia-se ao modelo do negócio, a forma como eu esperava comercializar e distribuir o livro. Dela brotou o projeto Rendiconti, cujo lançamento obedece ao mesmo cronograma do livro: lançamento em 25 de março do ano que vem.Sobre isso eu já falei em duas ocasiões:

    Nos últimos meses, já prestes a entrar na última curva do projeto, outra questão passou a me incomodar: o formato do livro. Desde o início trato este projeto como se fosse um projeto de software. Aí, quando vislumbrei o produto final, algumas dúvidas surgiram como baldes d’água morna: como se atualiza um livro texto? Caso sejam necessárias as publicações de patches e service packs, como elas seriam? Daqui derivei outras dúvidas, e delas requisitos.

    Todos os livros que tenho morrem em si: apesar da possiblidade de erratas e extensões mais modernas, como web sites, aquele produto é fechado. O leitor pode rabiscar e corrigir. Mas o autor não consegue fazer mais nada com sua própria obra. Normalmente os autores lançam novas edições. Scott Berkun, por exemplo, chegou a trocar até o título na última edição de “The Art of Project Management”. Agora sua obra-prima se chama “Making Things Happen“. Que baita service pack, não? Acontece que os dois volumes que tenho aqui comigo não podem ser atualizados…

    Mergulhei nessas questões e fui aumentando o ‘espaço do problema’. Meu livro é de fato um guia, um guia de referência. Quero que ele esteja sempre à disposição do Analista de Negócios, para consultas pontuais. Daí imaginei que o AN queira fazer suas intervenções no próprio livro. Ao invés dos famigerados (e temporários) post-its, por que não um espaço para notas e observações? Melhor: e se o AN puder inserir páginas inteiras em seu livro texto (da mesma forma como ele pode customizar um bom software)? Se este requisito for atendido, ele facilita demais a realização de outro: a possiblidade de atualizar trechos do livro. Saca só o caso de uso: o chato autor aqui resolver atualizar o capítulo sobre Desenvolvimento de Requisitos. Ele publica a atualização (na loja Rendiconti. lógico) e a deixa disponível para todos que já adquiriram o livro. O cliente pode baixar a versão digital (gratuitamente) ou adquirir a versão impressa (daquele único capítulo). O próprio cliente encaderna o novo capítulo, substituindo a versão que ficou defasada. Jóia, não? Puxa, como eu gostaria de ter tal alternativa em meus livros. Mas… como realizar tal requisito?

    Um livro atualizável: por que não?É claro que a encadernação tinha que ser totamente diferente. Nova? Quem conhece a IOB sabe que isso tá resolvido há muito, muito tempo. Não consegui descobrir, mas acho que as “pastas Z” têm quase 100 anos. Mas, por favor, não pensem naquelas pastas antiquadas e feiosas que você vê no escritório do seu contador. Dê uma olhada na pastinha ao lado. Que tal?

    E se ela for também a capa das apostilas? Assim, todos os participantes dos cursos e oficinas, caso se interessem, compram só o miolo do livro. E aquele espaço ali para um DVD… e se tiver uma edição com uma versão integral de uma palestra ou curso? E se… Ok, as possibilidades são várias.

    Mas, é claro, tanta conveniência tem um preço. E eu não posso simplesmente ignorar aquele público que quer a opção de um livro “normal”. O jóia é que na loja virtual Rendiconti ele poderá escolher a encadernação que mais lhe agrade.

    Entendem agora como um projeto atrasa tanto? Olha como o escopo mudou. Será que eu conseguiria pensar nisso tudo lá no início, quando estava só preocupado em escrever o livro? Não sei. Mas não me arrependo de nenhuma decisão. O atraso de (quase) um ano será compensado com um produto muito, muito melhor. Ops… bom, quem vai dizer isso são os leitores. Ops.. leitores não, Usuários do Livro.

  • É o Negócio, Beócio!

    Todos os participantes de meus eventos se defrontaram com o título acima. Como era o penúltimo slide e pintava lá no finalzinho do dia, nunca mereceu muita atenção. Pouquíssimos sabiam o que significa beócio. Também foram poucos os que ficaram curiosos. Segundo o Houaiss:

    be.ó.cio adj.s.m. 1.  que(m) é natural ou habitante da Beócia, região da antiga Grécia. 2. p.ext. infrm.pej. (indivíduo) grosseiro, ignorante ou ingênuo.

    Não sei se dei sorte ou realmente não fui mal interpretado, mas nunca ninguém se sentiu ofendido com o título. Realmente os participantes de meus eventos nunca foram alvo da exclamação. Pelo contrário, minha intenção era dar-lhes de presente um clichê: É o negócio, beócio! Uma frase-projétil útil toda vez que alguém se esquece quem paga a dolorosa de nossos projetos. Resolvi hoje contar as origens e explicar o codinome do meu livro.

    Bill Clinton, em um dos últimos debates contra Bush pai, bofeteou-o: É a Economia, Estúpido! Saiu vitorioso e construiu um superávit inédito na história daquele país. Bush filho assumiria a mesma cadeira tempos depois e deixaria como legado o maior déficit que aquela nação já viu. Mas essa é outra história…

    Desde que criei coragem para escrever meu primeiro livro já tinha claro quem seria o maior homenageado: meu pai, Paulo Fernando Nogueira, que nos deixou há 12 anos, quando tinha só 49 anos de idade. Contador, foi o cara que me colocou na carreira de TI e a influenciou em diversos momentos chave. Qualquer dia falo mais sobre ele. Hoje nos interessa o beócio. O “velho” era meio erudito. Herdei dele a paixão pela leitura – de jornais (de papel), livros policiais e nossos quase sempre chatos tratados técnicos. Mas ele não gastava sua erudição em papos sérios. Não, usava-a apenas como pequenas alegorias em seus papos divertidos e xingamentos. Insulto favorito: beócio! Era dirigido, principalmente, contra jogadores perna-de-pau, juízes pouco honestos e motoristas barbeiros.

    Quando defini o tema do livro, um Guia para a Formação de Analistas de Negócios, surgiu quase que imediatamente a frase-arma: “É o Negócio, Beócio!”. Tente pronunciá-la em voz alta;jogue-a na cara dos caras que começam projetos de software pelos ferros, caixinhas e código, hehe. É de fato um belo presente que ganhei e repasso. Sem custos!

    Mas, obviamente, “É o negócio, beócio” não ficaria muito bem como título de um livro para analistas de negócios. Aliás, seria de certa forma um desperdício. Penso em utilizá-la como título de uma série! Sim, uma série de livros que terá um tema em comum: a eliminação da distância entre TI e o negócio. Ou, para usar uma casa do ‘embromation bingo’ , uma série sobre “Alinhamento Estratégico”. Qual será, então, o nome do livro? Por mim ficaria “Guia para a Formação de Analistas de Negócios”. Mas uma consulta ao nosso grupo de discussão deve ser feita antes do fechamento da questão.

    Ok, Mas Cadê o Livro?

    Quero crer que minha arrogância nunca foi tão longe: logo no início do trampo de escrever o primeiro livro fui lá e cravei um prazo: 27/mar/2008. O divulguei aqui e em todos os eventos que apresentei até o final do ano passado. Influência dos processos ágeis, onde prazos e custos são “imexíveis”? hehe.. Não importa, o fato é que foi realmente um grande erro. Trata-se de um tipo de projeto que enfrento pela primeira vez. Pior: falando de um tema que ainda está em fase de ebulição / definição. Que não sirva como desculpa, mas o próprio BABoK V2 já apresenta aproximadamente 1 ano de atraso. E olha que o trabalho deles é feito a n mãos! Mas, como eu disse, não é desculpa.

    Agora sim eu consigo trabalhar com um prazo definitivo: 25 de março de 2009. É uma quarta-feira e um pequeno evento acontecerá em Sampa. Para quem gosta de curiosidades: é dia de São Dimas, o “Bom Ladrão”. Achei coerente com um texto que ‘rouba’ boas idéias de diversos autores (também ladrões). E fica a 2 dias de completar exatamente 1 ano de atraso! Mas eu quero compartilhar um pouco da experiência de se escrever um livro, agora e em futuros artigos.

    Desde o início decidi que utilizaria um processo iterativo e incremental. Tinha a intenção de tratar o projeto do livro como se deve tratar um projeto de software. Como eu não tinha um cliente pré-definido, com o tempo criei uma comunidade de clientes para o meu ‘software’. Todos os participantes dos eventos foram convidados a participar de um grupo de discussão. Hoje somos 357 pessoas de praticamente todo o Brasil. Tem até um ilustre participante em GMT -11. Quase todos os debates ali servem como feedback direto ou indireto ao meu trampo. Tanto que até acho a troca um tanto injusta… mas o grupo não reclama. No entanto, o retorno não vem da forma como eu esperava. Não vem tão mastigado, tão diretamente relacionado ao livro, que o grupo já conhece em uma versão bastante preliminar. Mas, é claro, não posso reclamar.

    Reclamo só de mim: já escrevi o livro 3 vezes! Escrevi mesmo, do zero. Uma das versões, a 0.7, saiu do computador direto para o lixo.Não á fácil achar um ponto de equilíbrio. Explico: o texto é técnico. Mas não precisa ser chato. Minha principal referência neste ponto é “A Arte do Gerenciamento de Projetos“, de Scott Berkun. É um texto moderno, sério mas leve. Digo sem medo de errar que é o livro de TI que mais gostei de ler. E, claro, gostaria que o meu tivesse o mesmo tom e utilidade. É quase uma arte, e equilíbrio é a palavra-chave. Por exemplo: a tentação de mergulhar um pouco mais em uma parte ou técnica que mais me agrada é muito grande. Mas assim eu deixaria o texto ‘cambeta’. Quem já viu meus eventos sabe que defendo (teimosamente! hehe) alguns pontos de vista (leia-se conceitos, processos, práticas e ferramentas). Mantenho o tom (teimoso!) no livro. Mas não me esqueço que equilíbrio é a palavra-chave. Aliás, esqueço e lembro, esqueço e lembro, de uma forma iterativa e incremental. É o próprio Berkun quem diz: “Planeje voltar – escrever é editar.”

    Pois bem, início agora a última etapa do processo. Liberarei os capítulos individualmente para o grupo, até meados de fevereiro. É a versão 0.9, que também está sendo chamada de “release candidate”. Haverá um prazo para críticas e sugestões. As revisões ortográfica e gramatical, a cargo do mano jornalista Luiz Gustavo, acontecerão em paralelo. A única coisa que não será revelada nesta versão é a programação visual . Uma surpresa que só será revelada na versão 1.0, no próximo dia de São Dimas, 25/mar/09.

    Notas:

    1. Para quem não viu, o ‘embromation bingo’ é tema de uma hilária e provocativa campanha publicitária da IBM. Está no ar em alguns canais pagos, inclusive ESPN Brasil.
    2. Diversos participantes do grupo deram uma contribuição danada ao meu trabalho. Sem demagoria, considero-os co-autores. É claro que compartilharei com eles a responsabilidade de escolher um nome para meu (nosso!) primogênito.
    3. Além do conteúdo, a forma do livro me incomodou bastante. Se ele está sendo tratado como um software, como seriam realizadas as atualizações? Como aplicar patches e service packs em um livro texto? Apresento as respostas no próximo artigo. Amanhã! Inté!

  • Rendiconti :: O Projeto

    Vamos conversar agora sobre como o negócio Rendiconti será desenvolvido. Pode não ter ficado claro no post anterior, mas a iniciativa é composta por duas grandes partes: a fábrica-gráfica, de tijolo, cimento e tecnologia; e o site.

    A primeira já recebeu, há cerca de 2 meses, a maior parte do investimento necessário. Uma grande impressora laser já está em operação; o processo de produção já foi delineado; a pequena grande equipe já foi treinada. Esta parte foi antecipada exatamente para que a adequação à nova tecnologia aconteça bem antes da demanda que será gerada pelo site. Com um calculado efeito colateral bastante positivo: a gráfica (que, como eu já disse, pertence aos manos Cacá e Guz) ganhou outra fonte de receitas. Agora ela presta um tipo de serviço (popularmente conhecido como “gráfica rápida”) que é inviável quando se tem apenas impressoras ‘off-set’.

    Merece destaque o maior (e, de certa forma desejado) risco: se a demanda proveniente do site for muito grande teremos problema de escala – e o prometido prazo médio de 3 dias úteis para a entrega das obras pode ser comprometido. Como a aquisição de mais impressoras está, por enquanto, fora de cogitação, foram traçadas duas alternativas:

    1. Outras gráficas da cidade (Vga!) possuem tecnologia similar. Receberão a demanda excedente;
    2. Se a demanda for grande também para elas, de duas uma: ou é boa o suficiente para justificar mais investimentos (impressoras), ou forçará uma parceria com uma gráfica de maior porte (no interior de São Paulo).

    Só quando esta parte mais crítica e de certa forma mais cara foi resolvida é que teve início a 2ª parte do projeto: o site.

    Há uns 4 anos sou um satisfeito freguês da Locaweb. Não tinha nenhum motivo para buscar outro hospedeiro. Meu servidor contratado, claro, é Linux. E isso gerou o primeiro requisito não-funcional do projeto: a arquitetura tecnológica do site se baseará em PHP e MySQL. Esta opção já cria um necessário filtro de eventuais fornecedores. Vale dizer também que o PHP me deixou muito bem impressionado desde o dia em que converti o finito para o WordPress. PHP 5, Ajax, MySQL, talvez algumas ‘frescurinhas’ em Flash – estes são os principais componentes da arquitetura tecnológica do site.

    Também não tive nenhuma dificuldade para definir o arquiteto-desenvolvedor: Hailton Ferraz, de Lençóis Paulista e estudante da UNESP de Bauru. Ágil, enviou uma proposta objetiva e bastante clara. Profissional e rápido como poucas grandes e médias empresas sabem ser. Mas eu tinha outras motivações para ‘cravar’ este projeto no meio do interior e no meio acadêmico:

    • Como um Quixote bêbado espero dar uma contribuição, por menor que seja, para que o pessoal pare de “ir a São Paulo pra trabalhar”. O fluxo ganhou um “U-Turn” (tks! Stone, que passou no Intercine de ontem). Estamos no século XXI. Temos Internet. Temos banda larga (capenga mas temos). Ninguém precisa estar em Sampa para desenvolver projetos. Que nossas viagens para lá sejam só para passeio e encontros (profissionais ou não). Ou, no pior cenário, para breves estadias. E só!
    • O projeto do site é um excelente experimento. Por isso o 2º requisito não-funcional é fundamental: o projeto será 100% “open source”. Espero que ele seja estudado. Torço para que ele sirva como exemplo em diversas aulas. E vou utilizá-lo para trocar conhecimentos com a turma de Analistas e Desenvolvedores que convivem comigo no nosso grupo de discussão e no recém-nascido Fórum FAN.br. Imagine que exercício legal: estarei fazendo o papel do freguês! Vamos praticar: a modelagem do negócio e seus processos; o desenvolvimento e gerenciamento de requisitos; gerenciamento de projetos; um processo de desenvolvimento enxuto e ágil, iterativo e incremental; etc etc. Tudo de forma aberta: como eu já escrevi aqui, todos os artefatos gerados serão públicos – e liberados para uso.

    Ô FUQ! (Frequently Unasked Questions):

    • Bah! Então o projeto vai demorar pra caramba, não?
      Não! Há um negócio aqui, não se esqueça. Por mais que pareça uma brincadeira, o negócio é sério. Aliás, parecer uma “brincadeira” – no sentido de ser divertido – é uma qualidade que todo projeto de software deveria ter. Desde que seja uma diversão séria!
      Então o projeto tem um prazo sim: que flutua* entre setembro e outubro de 2008.
      * Flutua tanto quanto o custo: a forma de aquisição (que ainda tratarei naquela esquecida série “Trabalhando em Casa”) é formalmente conhecida como “Aquisição Progressiva”. Há um chute inicial (como em 100% dos projetos), mas valores e prazos serão ajustados na medida em que o projeto evoluir.
      * Tento provar assim que aquele “mantra” que diz que só o escopo pode flutuar é pura “forçação de barra”.
    • E qual é o escopo do projeto?
      Mostrei no post de ontem que ele tem duas partes principais: o cadastramento de obras e a venda delas. Pouca coisa além disso já foi debatida. Como ocorre em praticamente 100% dos projetos de software, é impossível ter uma visão de todo o escopo em seus momentos iniciais. Neste momento (que em alguns processos é conhecido como “Incepção”) buscamos uma visão que chamo de “2km de extensão e 2cm de profundidade”. É parte dos exercícios.
    • Tanto barulho para um projeto de um cara só?
      O Hailton é o contratado, arquiteto e principal responsável pela execução do projeto. Mas quem disse que é um projeto de um cara só? Claro que estou pessoalmente envolvido em sua execução, não apenas como o (chato) freguês. Mas já tivemos a colaboração de uma dezena de “voluntários”. Talvez tenhamos contribuições de dezenas, centenas de pessoas. Quem pode dizer? O projeto é aberto e livre. Se for um bom imã, atrairá esforços até de onde menos esperamos. É esperar e ver no que dá.
    • E como se gerencia um projeto assim?
      Honestamente? Não sei. É meu primeiro projeto de verdade que nasce “open source” – livre. Ferramentas para a estruturação e gerenciamento do conhecimento (requisitos!) adquirido serão necessárias. Mas essa parte até que é facilmente resolvida com os repositórios conhecidos. O maior problema estará no processo de gerenciamento. Taí uma bela oportunidade de aprendizado.
    • Qual processo de desenvolvimento será utilizado?
      Enxuto e ágil, Iterativo e Incremental. Talvez a gente crie um nome para ele, mas isso não importa. Surrupiaremos as boas idéias (e práticas) de propostas como OpenUP, FDD e até XP. Mas não seguiremos nenhum processo de forma cega, como algumas pessoas (ainda) acreditam que seja possível. Neste momento só há um princípio (ou requisito) escrito em pedra: o processo deve facilitar o aprendizado, em todos os sentidos. Só!
    • Os modelos, tanto do negócio quanto do projeto, são um tanto românticos, não?
      Como dizia uma bela psicóloga que um dia me deu um tratamento (informal), “não há altruísmo”. É claro que eu espero ganhar muito com o projeto, em todos os sentidos. Há a perspectiva de um belo retorno financeiro. Há a publicidade “orgânica” – tanto do negócio propriamente dito quanto do meu livro que, claro, representa a nova ponta-de-lança do meu “lucro” (daquele papo “Troco – Lucro – Truco”). E, obviamente, espero aprender muito – particularmente com o projeto. Ou seja, não sou assim tão “bonzinho e generoso”.
    • E se der tudo errado?
      Tudo é muita coisa. No pior cenário todos os envolvidos terão aprendido alguma coisa. O projeto é relativamente simples e “barato” (não estou apostando minha vida nele – meu negócio principal (meu lucro), o finito, seguirá com ou sem o Rendiconti). Mas, de certa forma, “aposto” meu nome aqui. Falhas no projeto ou no negócio, com certeza, gerarão uma péssima impressão. Mas… como dizia o saudoso e vitorioso Vicente Matheus: “quem sai na chuva é pra se queimar”.

  • Rendiconti :: O Negócio

    Artigo publicado originalmente no Graffiti. Talvez lhe interesse conhecer toda a (pré) história que o antecedeu. Então, segue o índice:

    Trato aqui de um novo negócio. Antes, porém, uma necessária explicação sobre o nome. Rendiconti é um termo italiano que significa “Prestação de Contas”. O utilizo com frequência neste espaço para prestar contas de todos os eventos abertos que realizo. A sacada do Guccia na escolha deste nome para sua revista é genial. Surrupio-a sem medo de ficar com a cara vermelha de vergonha.

    Aprendemos com os outros, com experiências de outras pessoas. Em aulas, livros, bate-papos presenciais ou virtuais – não importa. Todo aprendizado é um evento social, por solitário que seja. “Social”? É, eu quis dizer que tudo que aprendemos vem de outras pessoas.

    Quando invertemos este fluxo, tentando ensinar outras pessoas, de certa forma estamos fazendo uma “Prestação de Contas”. É uma retribuição – mas sempre seremos avaliados pelo que agregamos àquele conhecimento adquirido. Por isso o periódico do Círculo Matemático de Palermo se chamava Rendiconti. O conceito é genial. A provocação, impagável!

    Por isso não pensei duas vezes ao selecionar o nome desta nova empreitada. Aliás, depois de tantas idéias jogadas aqui, está aqui a primeira que pego para realizar. O título original daquele livro do Domenico de Masi, “Criatividade e Grupos Criativos“, é “La Fantasia e la Concretezza“. Sabe-se lá porque a Sextante, seguindo o (mau) exemplo das distribuidoras de filmes, não fez uma tradução literal do nome. Não importa. Para De Masi, o criativo não apenas fantasia. Ele também deve ser capaz de concretizar suas idéias. Antecipando a confissão de que não estou sendo nada criativo, topei o desafio.

    Para quem pulou o prólogo, explico que tudo começou porque vou publicar meu primeiro livro. Ia fazê-lo da forma tradicional (que tem mais de 500 anos!). Imprimiria uns 1000 exemplares e ficaria aguardando que generosas almas os levassem para casa (ou escritório). Modelo pra lá de ultrapassado: Muita grana parada. Considerando que incentivo a cópia e a distribuição de versões digitais do texto; considerando que as centenas de pessoas que participaram de meus eventos já garantiram (sem custos adicionais) sua cópia digital; e considerando que hoje em dia se lê muito pouco, qual demanda eu teria? Quanto tempo levaria para esvaziar aquela pilha de 1000 volumes?

    Mas a questão não é só essa, meramente comercial (ou financeira, como queiram. Aliás, já disse por aqui, não espero ganhar $ nenhum com a venda do livro). A principal questão é outra: trato o livro como se trata um software: ele é vivo – tem versões. A última versão pública é a 0.6. Em breve soltarei capítulos de uma versão que estou chamando de “release candidate”. A versão comercial será, obviamente, a ‘um ponto zero’. Mas morrerá ali? Duvido…

    Agora mesmo trabalho com 3 ferramentas (técnicas) novas, de modelagem, que espero incorporar ao trabalho. Outras surgirão, motivando a publicação das versões 1.1, 1.5, 2.0 e assim por diante. Com tal processo de desenvolvimento, a impressão de grandes volumes (a única que se justifica financeiramente em gráficas tradicionais) seria um tiro no pé. Motivações mais do que suficientes para a criação de um novo negócio. Nasce assim a Rendiconti!

    O Modelo do Negócio

    Como eu disse, não é nada original. Surrupia sem dó nem medo partes dos modelos da lulu.com e do SafariU, do grupo O’Reilly. Trata-se de uma gráfica e editora do século XXI: só gasta papel e tinta quando o cliente confirma a aquisição de um livro (ou artigo, apostila, revista, etc). Existem dois processos principais:

    1. O autor publica uma obra.
      Ele faz o upload de um arquivo com toda a obra. E tem a possibilidade de configurar diversos parâmetros como: preço, material, tipo de capa, opção de venda da versão digital, extensões da obra etc.
      Quando aprovada pelo editor, a obra passa a integrar o portfólio da loja Rendiconti. Aparecerá na ‘vitrine’, de acordo com sua classificação.
      Restrições: i) a Rendiconti trabalhará exclusivamente com livros técnicos das áreas de TI (Tecnologia da Informação) e Negócios; ii) a editora se reserva o direito de recusar obras que não atendam o padrão mínimo de qualidade esperado ou que fujam de seus temas principais (veja considerações abaixo).
    2. Um cliente adquire uma obra
      A loja Rendiconti opera como uma loja virtual comum. Há o inevitável “carrinho de compras” e coisa e tal. Claro, brigaremos para criar metáforas mais interessantes e originais. Mas não há muito o que inventar aqui.
      Ops, há sim! O cliente pode personalizar a obra adquirida: capa, tipo de papel, dedicatória, logo da empresa… sempre respeitando as restrições configuradas pelo autor.
      A “contribuição” do SafariU: o cliente pode montar um livro ou apostila inédito, selecionando capítulos das diversas obras disponíveis na loja. Poderá inclusive fazer o upload de algum material seu para ser incorporado. Invenção pequena é bobagem. Personalização tímida é enganação!
      Outra novidade, o processo: a obra só será impressa após a confirmação do pedido. Toda a operação estará baseada em Varginha, Minas. Mas o prazo médio de entrega dos pedidos girará em torno de 3 dias úteis – prazo equivalente ao das lojas tradicionais.

    Imaginem, então, as diversas possibilidades (cenários):

    • Um professor pode elaborar um material, mixá-lo ao conteúdo disponível na Rendiconti e gerar apostilas muito especiais para seus alunos;
    • Uma empresa pode elaborar um material de treinamento e terceirizar sua confecção (e até a revisão!). Desta forma, pode configurar para que sua obra não seja pública – ou seja, não aparecerá na vitrine da Rendiconti;
    • Claro, meu livro e seus 12 (?) capítulos estarão ali, exclusivamente ali na loja Rendiconti. Nas mais diversas versões: quer só a parte de modelagem de negócios, ou só o módulo de engenharia de requisitos? Tudo bem. Quer comprar apenas um capítulo? Só a versão digital? Só a apostila? Definitivamente: o cliente manda. E a gente tratará de entregar exatamente o que ele precisa.

    É óbvio, espero que vários autores vejam na Rendiconti uma oportunidade de prestar contas, de dar à luz as suas obras. Aliás, neste início de empreitada, é este o meu maior desafio: atrair autores. Claro, respeitarei tudo o que caracterizou a Rendiconti original. Não importa se você é professor ou estudante, doutor ou iniciante. Não importa se você está em Quixeramobim, na Mutuca ou na Lagoa dos Patos. E não importa se você é desenvolvedor, coordenador de projetos, administrador, consultor, professor, estagiário ou estudante. Saca a cauda longa? Então, há mercado para tudo – há espaço para todo mundo.

    Considerações semi-finais

    • “Não temes que lhe roubem o modelo de negócio?”
      Tsc… que papo mais anos 2000, pré-bolha. Conheces o dito “ladrão que rouba ladrão”? Então, não disse que surrupiei e remixei idéias de duas empresas estadunidenses? Então pq eu deveria reclamar se alguém buscar inspiração aqui?
    • Aliás, espero que busquem bem mais. Como mostrarei com mais detalhes no próximo post, este é um projeto 100% aberto. Todo o código e demais artefatos gerados (inclusive o modelo do negócio) serão disponibilizados com licenças Creative Commons e GPLv3.
    • Portanto, quem quiser copiar, poderá obter bem mais que uma simples idéia. Quer montar sua própria loja? Que tal uma especializada em livros “Boa Vida Boa” (culinária, viagens, esportes etc)? Que tal uma só com obras de cultura inútil? Que tal uma só para escritores renegados? Como eu disse (depois do Chris Anderson), há espaço e mercado para tudo. Já sugeriram até que eu escrevesse um livro só para contar essa história. Pode? Rss… até o próximo!

  • Aprendizado Interprojetos

    Quinze meses mergulhado em um mesmo assunto, mesmo que ele seja amplo e saboroso, cansa. Aproveitei o feriado e meu 3º aniversário para “oxigenar” o cérebro. Trouxe de Sampa, na semana passada, a última edição da MundoPM. Não curto muito a (cara) revista, mas uma chamada de capa me pegou: “Gestão do Conhecimento Interprojetos: como evitar custos imensos de reinvenção e oportunidade a cada projeto“. Caramba… há 4 anos eu não via nada sobre o tema. Este foi o assunto do primeiro trabalho que publiquei aqui no finito, resultado de um estudo que fiz entre 2003 e 2004 (compilado neste PDF de 240kb e 21 páginas – versão revista hoje!).

    O artigo publicado na MundoPM é de Naomi Brookes, diretora do centro de práticas de gerenciamento de projetos da Aston University (UK), e Michel Leseure, professor de gerenciamento de operações na Escola Comercial de Negócios de Plymouth. Desnecessário dizer, são de um universo totalmente diferente do meu. Mas, caramba, como dois trabalhos sobre um mesmíssimo (e específico) assunto podem ser tão diferentes? Até na bibliografia não há uma única referência em comum! O único texto que conheço na lista deles é “The Knowledge Creating Company”, clássico de Takeuchi e Nonaka que não cito em minhas referências.

    O trabalho da dupla compila os resultados de uma pesquisa que fizeram com 14 empresas européias, dos mais diversos ramos. Sua conclusão não difere muito da minha:

    Os estudos de caso mostraram deficiência nos processos formais de gestão do conhecimento explícito para transferir conhecimentos de um projeto para outro.

    …

    Isto ilustra uma falta de consciência sobre o conceito de gestão do conhecimento nas empresas deste nível.

    Mas uma palavrinha da citação acima resume toda a diferença entre o trabalho deles e o meu: “explícito” (conhecimento). Para eles, “conhecimento tácito é difícil de transferir”. E concentram boa parte de seu trabalho na indicação de mecanismos que promoveriam ou facilitariam o aprendizado interprojetos, dentre eles intranets, bancos de dados e bancos de dados de intranets… (não brinquei – está na figura 2 daquele artigo).

    Todo o meu trabalho gira em torno de eventos de socialização, ou seja, na troca de conhecimentos tácitos. Sugiro o uso de dois mecanismos, as “Comunidades de Prática” e as “Histórias de Aprendizado”. Não acredito que intranets e bases de dados promovam aprendizado de verdade. Mas entendo que eles têm sua utilidade em uma empresa que leve a sério o papo sobre gestão do conhecimento. Se bem construídos, são excelentes “guias de referência rápida”.

    Assim como o artigo de Naomi e Michel, que guardarei com carinho. Não só pela sua qualidade, mas também porque me permitiu ressuscitar um assunto há muito ignorado por aqui.

  • Sobre o Livro (e uma Oferta)

    Quando decidi escrever meu primeiro livro, não tinha a menor idéia de como seria o processo. Escrever artigos, mesmo aqueles longos, é uma coisa. Um livro é totalmente diferente. Seth Godin e Scott Berkun, em seus blogs, costumam contar um pouco sobre seu processo. Ariano Suassuna, Chico Buarque e Luis Fernando Veríssimo me assustaram um tanto com seus depoimentos sobre o trampo. Mas, no final das contas, cada um tem seu processo, suas manias e traumas. Resolvi desenvolver meu próprio processo (e manias). Espero não colecionar muitos traumas. Mas sei que alguns serão inevitáveis.

    Começando do começo, fixei alguns princípios:

    • Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
    • O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
    • Peça de marketing não pode significar um livro “marketeiro” (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
    • O livro é um esforço “solo”. Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro “míope” (ou “caolho”) é muito grande.
    • Apesar de conhecer a tendência, o livro não será do tipo “como passar na prova”. Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.

    Na seqüência desenhei a extensão do livro, uma visão de “alto nível”. Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 “convidados”). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

    Por isso os workshops que estou realizando com a Tempo Real Eventos são tão importantes. Não pelo contato de 1 dia, mas pelas conversas que acontecem depois. Por isso montei um grupo de discussão “fechado”. Ali posso receber críticas e sugestões. Ali nós trocamos idéias sobre o conteúdo, práticas, processos…

    Pois é, adotei um processo Iterativo & Incremental para o desenvolvimento do livro. Sendo assim, posso dizer que nos encontramos na fase de construção, na 7ª iteração. O produto, o texto, já está na versão 0.6. Chegamos em uma fase em que as iterações precisam ser mais curtas. Mas o cronograma segue rigorosamente em dia.

    O trabalho de escrita, com todas as revisões, se encerra em dezembro. Já divulguei até a data oficial de lançamento: 27/mar/2008 (quinta-feira) Um dia eu explico a data e o codinome do rebento, “É o Negócio, Beócio“.

    .:.

    Do mesmo conteúdo gerei uma palestra (1h30), o workshop (7hs) e um curso (80hs, dividido em dois módulos de 40hs: Modelagem de Negócios e Engenharia de Requisitos).

    Segue aqui uma oferta para escolas, universidades e entidades sem fins lucrativos (de Sampa ou Varginha): quem quiser levar a palestra ou workshop para suas organizações (em outubro ou novembro), não terá custo nenhum. Demais localidades podem ser incluídas, dependendo da distância e das despesas de deslocamento. Todos os participantes receberão uma cópia (digital) do livro (que ainda é uma apostila) e outros artefatos. Se interessou? Então, fale comigo.

    .:.

  • Meme #016 – Diversidade faz Bem

    When solving problems, diversity may matter as much as, or even more than, individual ability.

    – Scott Page (professor na Universidade de Michigan e autor de “The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Society“).

    .:.

    Meme achado-forçado, que ajuda no debate sobre ‘Especialistas Generalistas’.

    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #015 – TI Centrada na Informação

    In the existing IT environments, I believe we moved from being Server-centric to OS-centric to Application-centric. In the next generation, we become more network-centric but fundamentally (for the first time I might note) start building Information Technology actually around the Information. This is powerful. It means that Information is no longer captive to a single application but can be leveraged across any number of applications.

    – Mark S. Lewis, VP da EMC

    Vale a pena ler toda a sua série chamada “Flat IT”.

    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Novo Berkun

    No próximo dia 15/mai será lançado o novo livro de Scott Berkun, “The Myths of Innovation“. É só o segundo. O primeiro foi “The Art of Project Management“, best seller e um dos melhores do gênero. Há pouco mais de um ano publiquei um “resumão” dele, comparando-o com o clássico “The Mythical Man-Month“.

    Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é “Criatividade e Grupos Criativos”, de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

    • Why all innovation is a collaborative process
    • How innovation depends on persuasion
    • Why problems are more important than solutions
    • How the good innovation is the enemy of the great
    • Why the biggest challenge is knowing when it’s good enough

    Sairá um “De De Masi a Berkun”? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o “Gerenciamento do Trabalho Criativo“.

    Mas fica a tentação: De Masi, em “Criativade”, conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

    .