Original: Information Rules(Harvard Business School Press, 1999).
Autores: Carl Shapiro é professor de Estratégia de Negócios na Haas Scholl of Business e do Depto. de Economia da Universidade da Califórnia, em Berkeley. Hal R. Varian é professor da School of Information Management da Universidade da Califórnia e colega de Shapiro na Haas.
Editora: Campus, 1999. Tradução de Ricardo Inojosa.
Do que se trata: defesa consistente e bem amparada de uma tese: “A tecnologia muda. As leis da economia não“.
É um belo presente para:
Executivos de qualquer negócio baseado em informações;
Gente que vende software;
Profissionais que precificam produtos ou serviços de informação.
Recomendações:
“A Economia da Informação é o primeiro livro a explicar a economia em rede, a nova economia de nossas vidas. Shapiro e Varian explicam as loucuras que ocorrem todos os dias no Vale do Silício e em outras partes do mundo. Este livro é leitura obrigatória para toda pessoa de negócios do novo milênio.”
– Eric Schmidt, quando ainda era CEO da Novell.
“Excelente livro! Ao combinar uma linguagem clara e sem jargões, com exemplos bem definidos e específicos do mundo real, A Economia da Informação mostra como os princípios econômicos aplicam-se à era da Internet.”
– Andrew Grove, presidente do conselho da Intel.
Prós:
Leitura fácil, clara e objetiva.
Repleto de exemplos reais.
Bem estruturado em seus 10 capítulos e 400 páginas.
Contra:
A tradução, pra variar, peca. Ver commodity aparecendo como “mercadoria” o tempo todo irrita. Se estava tão preocupado em trazer tudo para o português, por que manteve inalterado o termo “feedback”, que aparece até em título de capítulo?
Trechos:
“Ao gerir sua propriedade intelectual, você deve ter por objetivo escolher os termos e as condições que maximizem o valor de sua propriedade intelectual, não os termos e condições que maximizem a proteção.” (pág. 18)
“A infraestrutura está para a informação assim como a garrafa está para o vinho: a tecnologia é a embalagem que permite entregar a informação aos consumidores finais.” (pág. 21)
“O que há de novo é nossa habilidade de manipular informação, não a quantidade total de informação disponível.” (pág. 22)
“Não deixe que seu produto de informação se transforme em mercadoria .” (pág. 42)
Acompanhamentos:
A Vida Digital
Nicholas Negroponte. Companhia das Letras (1995).
Wikinomics – Como a Colaboração em Massa pode Mudar o seu Negócio
Dan Tapscott & Anthony D. Williams. Nova Fronteira (2007).
Cultura da Convergência
Henry Jenkins. Editora Aleph (2008).
Autor: Jim Highsmith é um consultor e escritor, especialista em engenharia de software e gerenciamento de projetos. Além do livro apresentado aqui, escreveu também “Adaptive Software Development” (Addison-Wesley, 2000), dentre outros. Foi co-autor do Manifesto Ágil.
Editora: Addison-Wesley | The Agile Software Development Series. Primeira edição de 2004. Esta entrada é sobre a segunda edição, publicada em 2010.
Do que se trata: Criação de produtos inovadores através do APM – Agile Project Management, ou Gerenciamento Ágil de Projetos. Apesar da intenção de atender um público mais amplo, é claro que Highsmith concentra-se no desenvolvimento de software.
O autor sugere um Agile Enterprise Framework composto por 4 camadas:
Governança do Portfólio
Gerenciamento de Projetos
Gerenciamento de Iterações
Práticas Técnicas
O livro só não cobre a última camada, que pode ser composta por práticas sugeridas em frameworks como XP (eXtreme Programming), OpenUP etc. Highsmith defende que a estrutura proposta “facilita a construção de métodos ágeis híbridos que atenderiam necessidades específicas de uma organização”.
O destaque para o Gerenciamento de Iterações não é novo, mas Highsmith coloca o tema em um novo patamar. O Planejamento Avançado de Releases é uma das principais atualizações desta segunda edição. As outras são: Valores Ágeis; Escalando Projetos Ágeis; Governança de Projetos; e Medição de Performance.
A quem se destina: Líderes de projetos.
Mas também pode ser muito útil para:
Gerentes de projetos insatisfeitos com sua situação atual;
Gerentes de produtos cobrados por inovação, qualidade, valor, agilidade…
Qualquer um que queira conhecer o Mundo Ágil de maneira ampla e sem dogmas ou extremismos. É particularmente indicado para executivos e gerentes.
Prós:
Isenção. Highsmith não defende nada específico como Scrum, XP ou FDD, por exemplo. E justifica sua posição lembrando que um dos princípios do desenvolvimento ágil é a adaptação para diferentes situações.
É esta isenção que possibilita que Highsmith critique alguns caminhos e descaminhos do Mundo Ágil.
O livro é muito bem estruturado e ilustrado. O que torna a leitura das 370+ páginas um estudo agradável.
Contras:
As alterações em relação à primeira edição são muito grandes. Desconfio que o “segunda edição”, apresentado em letras garrafais na capa, faça com que muitos que conheceram a primeira edição ignorem este lançamento. Não deveriam.
Aliás, que capinha mais feia, hem?
Destaques Aleatórios:
“Qualquer um que pratique o desenvolvimento ad hoc sob o disfarce ‘ágil’ é um impostor.” (pág. 9)
“Olhando de fora, um time gerenciado e um time liderado podem parecer a mesma coisa. Dentro eles são muito diferentes.” (pág. 48)
“Princípios guiam práticas. Práticas instanciam princípios. Não dá para separá-los”. (pág. 86)
“O reconhecimento de que a iteração 0 (zero) não entrega valor para o cliente pressiona o time a mantê-la breve”. (pág. 147)
“… ‘Como você consegue estimar o desconhecido?’ A resposta é: ‘Você não consegue’. Quando há o desconhecido você está chutando, não estimando – e isso é o melhor que podemos fazer. É por isso que tempo e custo são vistos como restrições, e não estimativas, em projetos ágeis.” (pág. 153)
“A falta de um bom planejamento de releases é endêmico em partes da comunidade ágil”. (pág. 157)
“Existem duas estratégias fundamentais para o gerenciamento de mudanças – antecipação e adaptação – e o bom design leva ambas em consideração.” (pág. 218)
“Muita gente, inclusive algumas da comunidade ágil, pensa que o gerenciamento ágil de projetos significa menos gerenciamento. Em minha experiência, o gerenciamento ágil pode ser diferente, mas com certeza não demanda menos tempo.” (pág. 225)
“O intercâmbio de pessoas é muito mais eficaz que o intercâmbio de papelada.” (pág. 283)
“Os relatórios do Standish Group NÃO são bons indicadores da pobre performance do desenvolvimento de software, eles SÃO bons indicadores das sistêmicas falhas de nossos métodos de planejamento e medição.” (pág. 334)
“Quem nunca cancela projetos nunca corre riscos. Quem não corre riscos não sobrevive. não é fracasso, é bom gerenciamento.” (pág. 334)
“Previsibilidade ou agilidade: escolha uma.” (pág. 336)
Trilha de Estudo:
Como prometido, uma trilha curta (em número de títulos). Esta entrada completa a anterior, “Agile Product Management with Scrum“, de Roman Pichler. Diz aí, você precisa de 2 dias, 2 semanas ou 2 meses para estudar ‘isso tudo’? Inté!
Autor: Roman Pichler é um especialista alemão em Scrum e gerenciamento Ágil de produtos. Este é seu primeiro livro em inglês. Anteriormente publicou “Agiles Projektmanagement erfolgreich einsetzen”(Scrum – Applying Agile Project Management Successfully) pela dpunkt.verlag, em 2008.
Editora: Addison-Wesley | Mike Cohn Series (2010).
Tema: Gerenciamento Ágil de produtos através do Scrum (dã!). É mais que isso: é o único livro que conheço dirigido especificamente para Product Owners (Donos de Produtos), o papel mais complexo e controverso em projetos guiados pelo frameworkScrum.
São no mínimo curiosas algumas contradições do Universo Ágil, particularmente aquele que defende e dissemina o uso do Scrum. Por muito tempo deram atenção quase exclusiva para a formação de ScrumMasters. Só agora começamos a ver a devida preocupação, através de cursos e deste livro, com aquele que de fato é o papel mais crítico e complexo em um projeto Scrum, o Product Owner (PO).
A quem se destina: Todos que desempenham, sonham em desempenhar ou caíram de paraquedas no role (hole?)Product Owner.
Dê de presente para:
Super-usuários e / ou especialistas destacados para o papel de PO;
Gerentes de Projetos;
Gerentes de Produtos;
Analistas de Negócios (principalmente se estiverem atuando em projetos guiados pelo Scrum).
Contra-indicações: Só não é indicado para quem apresenta reações alérgicas ao termo Agile.
Prós:
Texto objetivo (o livro tem só 133 páginas);
Bem ilustrado com exemplos e casos reais;
Não fica “em cima do muro” em alguns pontos polêmicos sobre o uso do Scrum. (Mais sobre isso abaixo).
Contra:
O que é uma vantagem (a objetividade) pode ser percebida como superficialidade. Roman poderia ter explorado um pouco mais alguns pontos mais complexos, como a criação da Visão do Produto (capítulo 2, “Envisioning the Product”). Apelo para Fred Brooks¹ para justificar minha crítica: “A fase mais complexa e crítica de um projeto de software é aquela onde definimos o que precisa ser feito.” Na trilha de estudo, abaixo, apresento uma sugestão para preencher um certo ‘vazio’ deixado por Pichler.
Cutucando Feridas (alguns trechos):
“Minha experiência sugere que um Product Owner não consegue cuidar de mais de dois times de maneira sustentável”. (pág. 12)
“A criação da Visão é melhor compreendida como um processo de descoberta, um processo de aquisição de conhecimento e aprendizagem que requer experimentação”. (pág. 37)
“O Scrum não dita como um requisito deve ser descrito”. (pág. 53)
“As atividades de manutenção e evolução² da primeira iteração (sprint) tratam de itens da segunda iteração, e aquelas da segunda iteração têm como foco os item da terceira iteração, e assim por diante.” (pág. 60) Destaquei este trecho porque ele toca em um ponto que gera estranhos debates. Quem cuida do desenvolvimento de requisitos, seja o PO ou um analista de negócios, sempre estará pelo menos uma iteração à frente do restante do time. Pichler sugere que, dependendo dos riscos e incertezas acerca do projeto, o PO trabalhe com até três iterações de distância. O planejamento de cada iteração depende da existência de um conjunto de itens adequadamente entendido e detalhado.
“Product Owner e ScrumMaster não devem fazer estimativas nem influenciá-las”. (pág. 67)
“A fixação do prazo, orçamento e escopo não é possível; pelo menos uma das três restrições deve ser tratada como uma ‘válvula de escape’”. (pág. 76)
“Seu papel durante o planejamento de uma iteração é ajudar o time a entender o que precisa ser feito. O time decide quanto pode ser entregue e como será feito”. (destaques em itálico do autor, pág. 98)
Trilha de Estudo:
Será simplificada desta vez: “Agile Project Management – Second Edition”, de Jim Highsmith (Addison-Wesley, 2010), é um complemento mais que necessário e natural para o livro do Pichler. Por isso será a próxima entrada desta biblioteca, a ser publicada ainda nesta semana.
Observações:
No artigo “No Silver Bullet” (1987), republicado como capítulo adicional do clássico “The Mythical Man-Month” (“O Mítico Homem-Mês”, Campus, 2009).
Utilizei os termos “manutenção e evolução” como tradução de “grooming”, termo amplamente utilizado por Pichler. Perdão, mas não consegui encontrar tradução mais adequada. Sugestões?
Autor: Dan Roam é presidente da Digital Roam Inc., empresa que consultoria que já atendeu clientes como Google, eBay, GE, Boeing e Wal-Mart. Seu método já foi apresentado no Senado dos EUA e em canais de TV como CNN, MSNBC e Fox News, dentre outros.
Editora: Portfolio (EUA, 2008).
Do que se Trata: “Resolver problemas e vender ideias com figuras” (subtítulo do livro). Roam apresenta o Pensamento Visual, um método que se baseia na seguinte premissa: uma imagem vale mais que mil palavras. Aprendemos aqui que a imagem certa vale bem mais que mil palavras.
A quem se destina: Todo mundo que resolva problemas e / ou venda ideias.
Dê de presente para:
Analistas de Negócios e de Sistemas
Líderes de Projetos
Desenvolvedores
Executivos
Seu colega que fala e / ou escreve demais.
Contra-indicações: Nenhuma. E Roam prova que todo mundo pode aprender a desenhar.
Prós:
Leitura fácil e muito agradável.
Roam é muito didático. E os exemplos utilizados são bons.
A diagramação esperta evita idas e vindas.
Contras:
A base da neurobiologia, relevante que é, não deveria estar no apêndice. O autor nos convida a visitá-lo várias vezes no início do livro. Aceite o convite.
Os exemplos são bons mas poucos. Por isso o autor se apressou em lançar um complemento, “Unfolding the Napkin” (mais sobre ele abaixo).
Quem já tem o costume de desenhar para entender ou explicar pode achar o livro meio “basicão”. Mas, inexplicavelmente, anda raro encontrar pessoas com tal hábito. Mais difícil ainda é encontrar quem o faça de maneira sistemática, amparado por um método consistente.
Unfolding the Napkin
Dan Roam – Portfolio (2009).
Um método “hands-on” – um workshop de 4 dias com vários exemplos e exercícios. Complemento obrigatório de “The Back of the Napkin”.
Business Modeling with UML
Hans-Erik Eriksson e Magnus Penker – Wiley (2000).
Aqui pisamos em solo pedregoso. Livro indicado apenas para quem quer megulhar de cabeça no uso da UML para a modelagem de negócios. Para analistas de negócios, considero um caminho inevitável. É interessante notar que, a exemplo do que acontece no FAN, o método de Dan Roam facilita bastante esta viagem. Dois artigos de minha autoria mostram um pouco deste ‘casamento’: Modelagem de Negócios: Uma Sugestão Modelagem de Negócios: Os Diagramas
Business Modeling – A Practical Guide to Realizing Business Value
David M. Bridgeland e Ron Zahavi. Morgan-Kaufmann (2009). Citado anteriormente por aqui. Não concordo nem um pouquinho com as sugestões dos dois autores: 4 linguagens ou padrões de notação diferentes para cada aspecto do negócio (BPMN se encaixa aqui). Prefiro o uso de uma única língua, UML. Mas preciso dizer que é um caminho alternativo para analistas de negócios e afins.
.:.
PS: Eu prometi uma trilha por mês. E falhei em abril. Portanto, aguardem outra entrada em nossa Biblioteca ainda em maio.
Autores: Jason Fried e David Heinemeier Hansson, fundadores da 37signals, empresa que fornece soluções para gerenciamento de projetos, colaboração, CRM dentre outras.
Editora: Crown Business (2010).
Do que se trata: Negócios de uma maneira geral. Mas pertence à nobre categoria “Tapa na Cara”. Um safanão em todos que continuam fazendo negócios no século XXI com mentalidade de século XIX.
A quem se destina: Todo mundo, mas principalmente para quem tem ou pensa em ter seu próprio negócio.
Dê de presente para:
Você, micro, pequeno, médio ou grande empresário
Seu sócio “conservador” ou “medroso”
Seu patrão “conservador” ou “medroso”. Neste caso, recomenda-se que o presente seja anônimo. E permaneça assim até que o chefão manifeste suas impressões sobre a obra.
Contra-indicações:
Se o leitor for ultraconservador (bitolado), o livro será arremessado para bem longe. Mantenha uma distância segura.
Entusiasmados podem gerar uma tsunami de mudanças (todas sugeridas no livro) que não conseguirão administrar. O livro não tem posologia, mas use-o com moderação. Particularmente se você e sua empresa estão muito distantes do que é sugerido ali.
Prós:
Leitura agradável e fácil.
Buzzwords e modismos só aparecem para ilustrar seu próprio lado nefasto e bobo.
Não é todo livro de negócio que usa termos como “fuck” e “shit” com tanta naturalidade.
Eddie Van Halen e John Bonham (Led Zeppelin) não são referências tradicionais em livros de negócios (tradicionais).
Contras:
Perdão, mas sigo no entusiamo de uma leitura recém-terminada. Ainda não consigo apontar nenhum “contra”.
Alguns Trechos:
Todas empresas têm clientes. As sortudas têm fãs. Mas as mais felizardas têm uma audiência. E audiência pode ser sua arma secreta.
…
Ao invés de correr atrás de pessoas, você quer que as pessoas venham atrás de você. Uma audiência sempre retorna – por vontade própria – para saber o que você tem a dizer. E este é o mais receptivo grupo de clientes ou clientes potenciais que você vai ter.
…
Se eles gostarem do que você tem a dizer, muito provavelmente gostarão também do que você tem a vender.
…
Quando você constrói uma audiência, não tem que pagar pela atenção dela – ela a dá para você. E isso é uma baita vantagem.
É interessantíssima a lista de pessoas que mereceram um “thank you” no final do livro: Frank Lloyd Wright, Warren Buffett, Steve Jobs, Kent Beck, Seth Godin, Jeff Bezos, Thomas Jefferson e Kathy Sierra, dentre outros. E pinta ali um brasileiro, Ricardo Semler, empresário e autor de alguns livros que, com certeza, inspiraram a dupla da 37signals.
Obras Relacionadas:
Hoje não vou apontar uma trilha. Poderia citar alguns textos do Seth Godin e do Guy Kawasaki, por exemplo. Mas trocarei as indicações por algo que pretendo fazer: ler “REWORK” de novo. O livro é curto (279 páginas, sendo que dezenas são apenas imagens que abrem os capítulos e subcapítulos) e merece algumas REleituras.
Subtítulo: Relevância, Concisão e Simplicidade na Comunicação Empresarial
Autor: Normann Kestenbaum, pós-graduado em administração de empresas pela FGV. Sócio da Baumon, onde presta consultoria para grandes empresas.
Editora: Elsevier / Campus (2008).
Do que se trata: Comunicação empresarial. No popular, um pequeno (108 páginas) grande guia para todo tipo de conversa que rola em uma organização.
A quem se destina: Todo mundo. Claro, todo mundo que conviva de alguma forma em empresas e outros tipos de organizações.
Dê de presente para:
Líderes e gerentes de projetos
Analistas de Negócios
Analistas de Sistemas
Todos os chatos que não conseguem transmitir uma simples ideia em 5 minutos ou linhas
CIO’s, gerentes e afins
Contra-indicações: Nenhuma.
Prós:
Texto leve e agradável.
Coerente – Conciso e objetivo.
Bem fundamentado, apesar da curta bibliografia (apenas 9 títulos citados).
Contras:
Como em praticamente todo título nacional, falta um índice remissivo.
E alguns gráficos são muito ruins. Mereciam melhor trato.
Um trecho (escolhido aleatoriamente entre aqueles que destaquei com um marca-textos):
Outro ponto sobre a concisão que merece comentários é a percepção errônea de que apresentação é a parte mais importante de um encontrou ou o único elemento importante a preenchê-lo. Muitas vezes uma pessoa tem 30 minutos para fazer uma exibição, ocupa integralmente esse tempo e é obrigada a ir embora porque seu tempo expirou. E o que pensa o lado de lá? Quais são suas sugestões e contribuições? Para mim, é na troca de idéias que o encontro acontece de fato. Portanto a regra é ser o mais breve e objetivo possível na apresentação, de forma a deixar o máximo de espaço de tempo possível para uma saudável troca de ideías e opiniões.
Uma citação:
É importante ter distanciamento para olhar o jogo inteiro, uma visão panorâmica que permita traçar estratégias. Poucos conseguem virar esta chave. Garry Kasparov, ex-campeão mundial de xadrez.
Uma piada:
Kestenbaum surrupiou o trecho a seguir de uma matéria da Exame (jul/2005), que por sua vez surrupiou o tema de “Por Que as Pessoas de Negócios Falam como Idiotas” (apresentado abaixo). Trata-se de um exemplo de como não falar nada usando muitas palavras:
Precisamos adotar as melhores práticas. Mas com foco no cliente? É claro! Sem isso perderíamos nossa vantagem competitiva, afetando o bottom line no longo prazo. Mas, se não nos alinharmos às stakeholders, vamos deixar de estar agregando valor ao negócio.
Trilha de estudo para quem quer mergulhar no tema:
Por Que as Pessoas de Negócios falam como Idiotas
Brian Fugere, Chelsea Hardaway & Jon Warshawsky
Editora BestSeller (2007).
The Back of the Napkin – Solving Problems and Selling Ideas with Pictures
Dan Roam
Portfolio (2008).
Extensão: blog Digital Roam
Presentation Zen: Simple Ideas on Presentation Design and Delivery
Garr Reynolds
New Rider Press (2008).
Extensão: blog Presentation Zen
Prováveis extensões da trilha (ainda não lidas / testadas):
Blink – A Decisão num Piscar de Olhos
Malcolm Gladwell
Rocco (2005).
Confessions of a Public Speaker
Scott Berkun
O’Reilly (2009).
Extensão: blog do autor.
.:.
Observações:
Como prometido, inicio aqui uma série de artigos sobre Biblioteca Básica e Trilhas de Estudos. Prometo a publicação de pelo menos uma trilha por mês.
Os títulos citados na trilha ou como prováveis extensões merecerão artigos específicos. Só não seguirei uma ordem pré-fixada para não tornar a série muito chata ou repetitiva.
As trilhas não são estáticas nem se pretendem fechadas. Qualquer sugestão será muito bem vinda. A única coisa que garanto é que só vou recomendar títulos que eu tenha lido e, quando for o caso, testado.
Resoluções retardatárias? Pois é, meu planejamento atrasou um pouco. O ano começou diferente dos anteriores, com turma fechada do FAN acontecendo em Sampa. E a maioria das minhas ideias para 2010 requer um tempo de maturação e até versões ‘beta’. Como de costume, vou escancarar aqui algumas delas. Para quê? Uai, o feedback antecipado de potenciais usuários e clientes é sempre bem-vindo, certo?
O Blog
Alguns costumes e manias não resistem a um bom teste unitário. Sei lá porque um dia decidi que publicaria aqui apenas artigos mais trabalhados que, invariavelmente, também são longos (quase sempre com mais de 1000 palavras). Artigos assim costumam demandar algo entre uma e quatro semanas de elaboração. Não de redação e edição, claro, mas de pesquisa e compilação. O problema com este enfoque é que deixo de falar sobre um monte de assuntos que, desconfio, também interessariam aos leitores fiéis ou ocasionais. Portanto, aguardem mais e menores blues, digo posts. O que não significará o fim daqueles verborrágicos, para tristeza dos apressados.
Outro velho projeto que deve finalmente vingar é a criação de outras seções aqui no finito. Duas aparecem no topo do blog backlog: 1) Bibliografia Comentada, com dicas de leitura e trilhas de estudo; e 2) Bate-papo com profissonais da área e usuários. Penso na transcrição totalmente sem edição de prosas facilitadas por IM’s e afins. O primeiro convidado parece não ter gostado muito da ideia mas insistirei. As duas novas seções pretendem trazer vozes e pontos de vista distintos deste que aqui rabisca.
Cursos e Palestras
Não foi o que planejei 4 anos atrás, quando iniciei a carreira solo. Mas os Cursos e Palestras se transformaram em minha vaca leiteira – no Lucro e não no Troco¹. Ao invés de nadar contra a maré, é preferível que eu reforce minhas ofertas. Principalmente para tentar me distanciar do oceano vermelho de sangue que caracteriza esse mercado. Gosto do modelo utilizado no FAN – eventos curtos e práticos. Mas a estabilidade dos times que estão ganhando é uma perigosa ilusão. Está aqui o desafio que mais tem ocupado meu tempo nas últimas semanas.
Devo lançar simultaneamente, ainda neste primeiro trimestre, dois novos eventos. Serão dirigidos para públicos diferentes mas vão compartilhar o mesmo formato e nome: “O Jogo dos 7 Erros“. Um será voltado para líderes de projetos e outro para meu público-xodó, os analistas de negócios. O formato é de um jogo realmente. Cada erro merecerá uma hora. Os exercícios tomarão metade do tempo. O restante será utilizado na apresentação do erro, casos e para o debate com a turma. Como o formato é muito novo os eventos serão lançados como ‘beta’ e terão preços especiais. Aliás, tudo será novo e o teste é mais que necessário. Inclusive ou principalmente do material didático. As primeiras turmas devem acontecer em São Paulo.
As novas ofertas não significam que o FAN irá para escanteio, pelo contrário. Novas turmas serão abertas, a partir de abril, em São Paulo e Brasília.
Serviços
É curioso como meus “patinhos feios” atraem atenção quando apresentados de maneira menos formal. Particularmente o conjunto de serviços que identifico como Administração de Ativos. Ou seja: erro feio na mensagem que transmito aqui e no material de marketing que desenvolvi. Duas providências: 1) Alterar a apresentação “formal” dos serviços; e 2) Lançar, no segundo semestre, eventos que mostrem de maneira mais clara a importância de alguns temas, particularmente a Administração de Ativos e a Engenharia de Processos. Pacotes de treinamento + consultoria devem ser a melhor resposta. Mas eu tratei de deixar bem baixas minhas expectativas para 2010.
E o livro, sai ou não sai?
Transparência é jóia e dá retorno. Mas também pode te deixar assim, sem ter onde esconder a cara quando alguma coisa não vai bem. Hoje eu entendo porque Nicholas Negroponte e Louis Gerstner resolveram nunca mais escrever depois de lançarem seus primeiros livros. “É o Negócio, Beócio!” é de longe o pior projeto que já assumi em minha vida. E eu tratei de torná-lo cada vez pior, prometendo prazos mesmo quando não era cobrado por isso. Acabei por transformá-lo em um verdadeiro pesadelo quando deixei os alvos ficarem móveis. Justo eu, que insisto com os 4 ventos que um projeto não pode dar certo se não tem objetivos bem claros.
Pois bem, o livro já foi escrito 4 vezes. Acho que já contei isso aqui. Duas versões não mereceram a luz do sol e foram direto para o lixo (shift+del mesmo). Alguns capítulos da última versão foram publicados. Mas, apesar do feedback relativamente favorável, alterei a estrutura e me perdi novamente. Tudo fica um tanto surreal quando me lembro que em apenas 4 meses, no longínquo 2007, eu escrevi uma versão quase completa. Hoje tenho a sensação de estar muito próximo da estaca zero.
E olha que até capa(s) ele já tem²!
Inicialmente o livro seria um “Guia para a Formação de Analistas de Negócios”. Quando comecei a aceitar que este deve ser também o meu último livro resolvi que ele podia ser um pouco mais abrangente. Ambiguidade é risco. E aquele “pouco” da penúltima frase virou um imenso problema. O lado bom do desabafo aqui é que, além de tirar um grande peso de meus ombros, dá ânimo para pegar no trampo de novo.
Epílogo?
Que nada! Prólogo para um 2010 que promete. Mas antes de começar eu preciso agradecer a todos que fizeram de 2009 um ano bem legal e produtivo: Leitores do finito, participantes do FAN e do grupo AN.br, clientes, parceiros e amigos. Espero que tenhamos boas desculpas para novos encontros.
Observações
Lucro | Troco | Truco é uma versão tropicalizada daquele esquema “70% 20% 10%” que seria utilizado pela Google. Dedico 70% do meu tempo em ofertas que representam meu negócio principal, o Lucro. O Troco, que ocupa 20%, é aquela receita básica e normalmente pequena que serve para pagar despesas fixas. E o Truco é uma ideia maluca qualquer que só merecerá mais de 10% do tempo quando mostrar potencial para virar Lucro ou Troco. Junto com o esquema Conteúdo -> Conversas -> Transações, este conceito dá forma ao núcleo do modelo de negócios do finito.
Pois é, formalizei lá em cima que Cursos e Palestras passam a merecer 70% do meu tempo. Pelo menos até o início do 2º semestre.
As capas foram desenvolvidas pela Sabiá. Me apresentaram 6 sugestões e até hoje o máximo que consegui foi eliminar duas. É provável que o livro saia com 2 capas oficiais, uma para descolados e outra para… hmm… menos descolados, hehe…
O finito ganhou chaves?!? {finito} Têm algum significado?
Minha caixa postal amanheceu repleta de mensagens de amigos avisando: Brooks estará no Brasil na próxima quarta-feira, 21/out! A preocupação dos colegas tem uma única explicação: eles sabem que sou fanzaço do cara. Não só de sua obra prima, “O Mítico Homem-Mês” (lançada originalmente em 1975 e finalmente disponibilizada em PT-br), mas também de seus artigos que seguiram, particularmente “No Silver Bullet” (1987. Este e outros artigos aparecem na edição do livro lançada pela Elsevier-Campus).
Seguem os convites:
Se você quiser entender um pouquinho mais a importância do cara, veja a série de artigos que publiquei aqui no finito em 2006. Se gostar, não deixe de comprar o livro. Se comprar o livro, lembre-se de uma provocação do Brooks:
Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!
A pesquisa que disparei 15 dias atrás só permite concluir uma coisa: nosso povo não gosta muito desse tipo de coisa. Coloquei uma meta muito modesta: 150 participantes. Consegui apenas 131. Entendo que é uma amostra muito pequena, que não permite conclusões. Mas dá boas pistas. E possibilita a elaboração de alguns palpites.
O pessoal que define “o que precisa ser feito”, os analistas de negócios, empatou com a turma do “como será feito”, os analistas de sistemas. 22% de participação de cada um. Em segundo lugar vieram os coordenadores de projetos, com 15% das respostas. Desenvolvedores e analistas de processos aparecem com 10% e 9%, respectivamente. De curioso aqui nosso coringa, que disse ser analista de negócios, de sistemas, de requisitos, desenvolvedor e arquiteto! Será que o salário é compatível com tantas responsabilidades?
Um participante cobrou, não perguntei sobre rendimentos. Falha minha. Não sei se por sorte ou azar, no mesmo período, a revista Você SA da Abril liberou uma pesquisa sobre o assunto. Cobre mais de 130 profissões, sendo 14 específicas da área de TI. Vou destacar aqui apenas um ponto: analistas de sistemas ou analistas-programadores (chamados naquela publicação de analistas de desenvolvimento) ganham praticamente a mesma coisa que analistas de negócios. Até os 5 anos de experiência. Depois disso, mostra a pesquisa, os analistas de negócios apresentam salários consideravelmente maiores. A diferença chegaria a R$ 5 mil entre profissionais com mais de 15 anos de experiência. Nesta faixa de tempo de estrada, o salário de analistas de negócios em pequenas e médias empresas seria maior até do que dos gerentes de projetos. Estranhei muito o número, mas não tenho como questioná-lo. A empresa que executou a pesquisa, a Robert Half, fez mais de 30 mil entrevistas. É uma pena que tenha se limitado aos mercados de São Paulo e Rio de Janeiro.
São Paulo de fato concentra a grande maioria das vagas. Em minha pesquisa, 58% dos participantes são de lá. Rio, Santa Catarina e Minas aparecerem na sequência, com quase 10% cada um. Profissionais do sexo masculino também confirmam outro tipo de concentração: são 81%, contra 19% de mulheres. 70% dos participantes têm idade entre 23 e 34 anos. Com mais de 40 tivemos 11%. Curiosidades: 44% disseram se apresentar como “Sêniores”, contra 39% que são “plenos (ocasionalmente vendidos como sêniores)”; 5% estão “loucos(as) para mudar de profissão”.
Mais da metade dos participantes, 57%, trabalha em empresas de TI. 30% em serviços de desenvolvimento e manutenção de sistemas. A maioria, 28%, conta com mais de 100 profissionais na área de TI. Mas, que espanto, 48% de todas as empresas contam apenas com algo entre 1 e 5 profissionais trabalhando com análise de negócios. Na questão eu ainda tive a preocupação de especificar que seria qualquer profissional que executasse: modelagem de negócios, modelagem de processos, desenvolvimento de requisitos etc. O desequilíbrio parece ser muito grande.
Sobre Projetos
Repetiu-se neste levantamento um número que tem cara de “default”: 62% dos projetos têm algum tipo de problema. 21% seriam “muito mal sucedidos (muito atrasados e gerando prejuízos)”. Para dizer a verdade, o número até que é um pouquinho melhor do que aqueles que vemos em outros lugares. Mas ainda é muito comprometedor.
Nada de novo também no front dos principais problemas: mudanças de requisitos (18%), requisitos mal definidos (17%) e mudanças de regras de negócios (13%) são os principais. Pouco envolvimento de clientes e usuários, metodologia mal aplicada e equipe mal preparada respondem por 9% cada um.
61% das empresas estão cientes dos problemas e tomando providências. As principais seriam: treinamento da equipe (31%), implantação de novas tecnologias e ferramentas (23%), implantação de nova metodologia (21%).
E quais metodologias, processos ou padrões são utilizados? Algumas surpresas: PMBoK (23%), Scrum (18%), RUP (16%), CMMI (10%) e XisPê (8%) são os destaques. Fiquei com pulgas atrás do orelhão: com tanto Scrum, como ninguém se apresentou como ScrumMaster ou Product Owner? O número do RUP também surpreendeu.
O que não surpreende é que 71% ainda utilizem editores de texto para tarefas de descoberta, descrição e gerenciamento de requisitos. E 61% depositem suas esperanças em planilhas eletrônicas. A relação não fica explícita, mas tenho certeza que essas ferramentas colaboram diretamente com os problemas listados acima.
Mas 68% utilizam especificações de casos de uso. Parece um bom sinal. Mas o número não bate com os levantamentos informais que faço em meus eventos. Será que estão falando de casos de uso de verdade, ou daquelas extensas descrições de telas e de como a solução deve ser construída? Infelizmente seguirei sem resposta. Mas desconfiado de que estamos falando de casos diferentes.
Perguntei se praticavam a modelagem de negócios. 38% disseram que sim, “e percebem o valor dela”. 35% disseram que praticam, mas “só um pouquinho”. 73% praticam a modelagem de negócios?!? Outro número que não bate de forma alguma com o que vejo nos eventos e empresas. Ainda mais com 59% dizendo utilizar a UML para tal. Para se ter uma ideia, são 23% aqueles que utilizam a BPMN. Pouco mais que os 20% que já estariam utilizando o método do “Pensamento Visual”.
Uai cara pálida: você faz uma pesquisa para depois questionar os números obtidos? Entendam, por favor: a culpa é da pesquisa e do número de respostas. Minha críticas acima servem apenas para destacar pontos da pesquisa que parecem estar bastante distorcidos. E uma das causas das distorções é óbvia e também foi levantada: 55% de quem participou da pesquisa já participou de algum evento FAN.
Mas, de qualquer maneira, pistas e palpites podem ser observados e colocados. Resta esperar que futuras iniciativas como esta sejam melhor elaboradas e mereçam um número bem maior de participantes. Aos que aceitaram meu convite e doaram preciosos minutos, registro aqui meu muito obrigado. E boa sorte no sorteio!
Antes de mais nada, um alerta: se seu interesse pelo BABoK limita-se à obtenção da certificação, então este artigo não vai ajudá-lo muito. Poupe seu tempo. Eu sei, é chato, mas este artigo também merece um prólogo-escudo: não tenho interesse nenhum em depreciar o IIBA (International Institute of Business Analysis) ou seu principal produto, o BABoK® Guide (A Guide to the Business Analysis Body of Knowledge). Há tempos apresento, aqui e ali, críticas àquela que deveria ser a principal referência para a formação de analistas de negócios (AN’s), o BABoK. Meus objetivos sempre foram apenas dois: i) ajudar os AN’s em seu processo de formação; e ii) contribuir para a evolução do BABoK. Ressalvas e alertas devidamente colocados, vamos ao que interessa. Este artigo trata da última versão do BABoK, a 2.0, publicada em 2009.
A Estrutura do BABoK
Alguma coisa muito estranha aconteceu entre a liberação da versão para revisão pública, em março/2008, e a versão definitiva publicada agora. A estrutura básica do BABoK foi mantida, com suas 6 disciplinas (KA’s ou Knowledge Areas), mas a ordem de apresentação sofreu consideráveis alterações. Se alguma justificativa para tal foi apresentada, não percebi. O fato é que complicaram a leitura. Em meu entendimento, desnecessariamente.
Na versão 2.0 liberada para revisão as duas primeiras disciplinas apresentadas eram aquelas de perfil mais gerencial e tático: “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”. Era uma alteração necessária em relação à versão anterior, a 1.6, que começava pela “Análise da Organização” (ou “Enterprise Analysis”). Necessária por agrupar, mesmo que de maneira implícita, as disciplinas cuja aplicação se diferencia substancialmente das outras quatro. (Mais sobre elas no decorrer do artigo).
A versão atual do BABoK inseriu “Elicitação” entre as duas, comprometendo uma certa lógica de leitura. E a “Análise da Organização”, que um dia foi a primeira disciplina apresentada, agora aparece apenas no quinto capítulo. Uma estrutura que parecia bem resolvida, como ilustra o gráfico abaixo, virou um diagrama de difícil entendimento.
As disciplinas no BABoK 2 (public review)A nova estrutura do BABoK
No primeiro diagrama percebemos claramente uma sequência lógica de 4 disciplinas, além da informação de que outras duas guiam e/ou dão suporte à análise de negócios. O segundo desenho quebra essa lógica e não faz nada mais do que confundir. Realmente é incompreensível a mudança.
Além disso, ainda sobre a estrutura do BABoK, é preciso dizer que a forma como as disciplinas são apresentadas é boa. Destacam-se as entradas, tarefas e saídas principais de cada disciplina. Depois, para cada tarefa, são descritos: entradas, elementos (que são específicos para cada tipo de tarefa), técnicas, partes interessadas (stakeholders) e saídas. A sequência é lógica e didática, apesar dos deslizes que serão discutidos abaixo.
Armadilhas
Saca aquele sujeito que, aéreo e desastrado, acaba caindo em armadilhas que ele próprio armou? Essa imagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia do IEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definição de requisitos. Logo depois, ainda no capítulo 1, alerta que “é vital que o termo ‘requisito’ seja compreendido no mais amplo sentido possível”. Ao tentar ilustrar o que seria essa amplitude toda, confundem: “em uma iniciativa BPM, requisitos podem ser uma descrição dos processos de negócio atualmente em uso pela organização”. Além de comprometer a definição do IEEE utilizada na página anterior, criam um tipo de saco sem fundo onde tudo é ou pode ser um requisito. Armadilha armada no primeiro capítulo faz vítimas no decorrer de todo o BoK. Quando apresentando a técnica de “Análise de Regras de Negócios”, por exemplo, é dito que “regras de negócios devem ser separadas de outros requisitos…”. Ou seja, dão a entender que regras de negócios também seriam um tipo de requisito.
Um analista de negócios deve aprender cedo que a distinção entre elementos do negócio (recursos, processos, eventos e regras) e elementos da solução (requisitos) é crucial para o bom desenvolvimento de seu trabalho. Ele sabe que há uma única interseção entre esses dois conjuntos e ela atende pelo nome de Requisitos do Negócio. O BABoK os define corretamente, como “grandes objetivos, metas e necessidades de um negócio”. De tão importantes, mereceram uma disciplina só para eles, a “Análise da Organização”. O que torna ainda mais indecifrável a bagunça apontada no parágrafo anterior.
A segunda armadilha bastante notável no BABoK é a necessidade de manutenção de uma certa “compatibilidade retroativa”. O BABoK tenta colocar e manter os pés em dois mundos muito distantes. Ele os chama de “Plan-driven” e “Change-Driven” – nomenclatura criativa usada para diferenciar o mundo clássico¹ de projetos daquele universo que surgiu após o big-bang do Manifesto Ágil. Se num primeiro momento – no capítulo 2, que trata do “Planejamento e Monitoramento da Análise de Negócios” – ele se mostra muito atencioso com o enfoque “change-driven”, na parte que seria mais cara e necessária tal atenção evaporou. Em “Gerenciamento e Comunicação de Requisitos” (capítulo 4), por exemplo, quase nada é falado sobre a forma como requisitos são gerenciados quando é adotado um processo ágil qualquer (Scrum, XP etc).
O referido capítulo é repleto de procedimentos para revisão e aprovação de requisitos, baselines, documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar de clássico. Se mantido o mesmo balanceamento (de preocupações) apresentado no capítulo 2, aqui deveríamos ver no mínimo uma vez a expressão “software rodando”, ou “solução rodando” ou algo do tipo. Não vemos. O que permite dizer que o BABoK firma o pé mesmo é no mundo clássico, a exemplo de seu primo não muito distante, o PMBoK. E por falar nele…
O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!
Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e muito menos do gerente de projetos. Deveria ser só do arquiteto e ponto. Mas isso é tema para outra hora. Aliás, atenção piratas! Vou lançar o FAS – Formação de Arquitetos de Soluções. Preparem suas copiadoras! hehe..
Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crítica ao BABoK é o fato dele ignorar por completo a disciplina conhecida como Modelagem de Negócios. O problema se torna mais perceptível na versão 2.0. Porque de fato ele não ignora a necessidade da modelagem. Sugestões para o uso de técnicas de modelagem aparecem a todo momento, em diversas disciplinas. Mas elas surgem de forma tão solta e desestruturada que é difícil imaginar que sejam utilizadas em sua plenitude. Pior: é difícil imaginar que gerem algum valor. Aos fatos.
Ainda na primeira disciplina, “Planejamento e Monitoramento da Análise de Negócios”², são apresentadas como técnicas gerais a “Modelagem da Organização” e a “Modelagem de Processos”. Em “Análise da Organização”, o 5º capítulo, são elencadas as técnicas “Benchmarking”, “Análise de Regras de Negócios”, “Decomposição Funcional” e “Análise SWOT”. No sexto capítulo, “Análise de Requisitos”, o assombro: além de diversas das técnicas acima, sugerem inclusive o uso de “Diagramas de Fluxo de Dados” na tarefa que deveria ser apenas “Organizar Requisitos”. Dentre os elementos desta tarefa aparece uma breve explanação sobre cada um dos 5 conceitos que, segundo o BoK, “garantem a total cobertura do domínio do negócio”. Aliás, os 5 conceitos são: 1) Classes de Usuário, Perfis e Papéis; 2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.
Nada mais é necessário para confirmar que a Modelagem de Negócios é fundamental para o entendimento de um negócio. Colocando de outra maneira: é fundamental para a Análise de Negócios. O BABoK sabe disso. Acontece que, ao invés de tratá-a como uma disciplina – como um corpo – preferiu esquartejá-la e distribuí-la em pedacinhos em diversas de suas KA’s. É grave quando percebemos que a Análise de Requisitos, uma disciplina por si só complexa e crítica, vira uma espécie de monstro de Frankestein no BABoK.
Essa armadilha se torna mais visível quando percebemos que em outros pontos do BoK é apresentada como entrada para determinadas tarefas uma tal “Arquitetura Corporativa” (um documento que, segundo o BABoK, “descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos de negócio, sistemas, informação etc”). Esse input já existiria de alguma maneira na organização. Duas coisinhas: 1) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é factível supor que seu desenvolvimento e manutenção, mesmo que parcial, sejam atribuições dos analistas de negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na Análise de Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a compor uma “Arquitetura Corporativa”. Vai entender…
Conclusão
No final das contas o grande problema com o BABoK é esse: entendê-lo. Se por um lado sua estrutura geral é desenhada com esse fim, e é bem desenhada, por outro o conteúdo ainda apresenta inconsistências demais. Pouco adianta o reuso de conhecimentos bem consolidados, como definições do IEEE e diagramas UML, se eles são contraditos ou diluídos de tal forma que perdem seu sabor e valor.
Joe Gollner publicou em julho último um artigo chamado “O Curioso Caso da Análise de Negócios“. Brinca com o título do filme estrelado por Brad Pitt, “O Curioso Caso de Benjamin Button”. Joe erra feio ao dizer que não estaríamos prontos para definir um corpo de conhecimentos para a análise de negócios. Tenho certeza de que já temos conhecimento e maturidade suficientes para delinear um BoK. Mas ele acerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.
A necessidade de manutenção de uma “compatibilidade retroativa” é, sem sombra de dúvidas, a grande culpada. Como justificar, em 2009, o uso de técnicas como a elaboração de DFD’s e diagramas de contexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim o BABoK só faz confirmar uma fama dos AN’s: seriam consumidores vorazes de papel. Não digo com isso que ele deveria se ater aos princípios pregados no Manifesto Ágil. Afinal, a análise de negócios não se limita a projetos de software. Mas é imperdoável que um BoK para análise de negócios se lembre de DFD’s e ignore por completo balanced scorecards, mapas estratégicos, conceitos Lean etc etc etc.
Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obtenção da certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar o BABoK. Além de ter boa experiência prática. Mas o analista deve ter consciência de todas as armadilhas e inconsistências que o BABoK apresenta em sua versão atual. Para não correr o risco de comprometer seu trabalho e até sua carreira.
.:.
Nota aberta ao IIBA
A lei de imprensa morreu, o finito não é imprensa, mas ética e educação não precisam ser regidas por leis. Caso o instituto julgue necessária uma resposta ao artigo acima, eu garanto o mesmo espaço e mesmo destaque. E reafirmo: não tenho interesse nenhum em criticá-los por criticar. Muito pelo contrário. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com um BABoK forte e consistente. Todos sabemos que um debate franco e aberto é o melhor caminho para a realização desses objetivos.
Entenda como “Mundo Clássico de Projetos” aquele que brotou e cresceu no século passado. Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ou waterfall e que sustenta seus métodos e práticas em diferentes níveis de comando e controle. Não há nada de pejorativo nessa definição. E não há nada de errado com esse modelo, desde que ele não seja utilizado em projetos de software.
O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework do SEI?
