Blog

A Perfeita Dupla Dinâmica

Ao comentar a impossibilidade do analista de negócios perfeito sugeri que as organizações tentem montar times multidisciplinares. Elas devem tentar equilibrar conhecimentos e habilidades. Este artigo avança um pouco mais no tema, apresentando uma sugestão para a formação de duplas de analistas. O trabalho em duplas não possibilita apenas a cobertura mais ampla dos conhecimentos necessários para uma boa comunicação com os usuários e outras partes interessadas. Ele também viabiliza a distribuição de responsabilidades de forma a tornar a atuação dos analistas mais ágil e eficaz. E talvez seja esta a principal justificativa para seu uso.

?

O diagrama ao lado mostra que nossa empresa modelo tem um time de Análise de Negócios formado por nove profissionais. Cinco são formados em TI (lado esquerdo), o restante em alguma área relacionada a negócios (Administração, Contabilidade, Marketing, Economia etc).

A metade superior indica que cinco analistas apresentam maior facilidade em atividades que envolvam a interação com pessoas. A parte de baixo mostra quatro AN’s hábeis em modelagem de negócios, estruturação de requisitos, especificação de casos de uso e tarefas afins.

O artigo anterior frisou a impossibilidade de um analista de negócios perfeito. Isso não pode servir como justificativa para o profissional estacionar. Todo AN deveria buscar o centro da matriz (quadrado pontilhado), que indica a equalização ideal de conhecimentos e habilidades. Repare que os profissionais mais experientes da empresa modelo, Maria e Joana, estão próximas do perfil ideal. Mesmo assim, Maria conhece mais sobre negócios e tem mais habilidades sociais enquanto a Joana saca mais sobre TI e é mais habilidosa em atividades técnicas.

Formam as duas o par ideal? Sim, mas a empresa deveria evitar esta composição se costuma ter mais de um projeto em andamento. Pelo porte do time podemos concluir que a empresa modelo tem vários projetos simultâneos. Quais seriam, então, as duplas ideais?

Maria é o par ideal do Tonho ou do Tico. Eles são iniciantes e podem aprender muito com ela. Por outro lado, já apresentam algumas habilidades técnicas, além de serem formados (ou estarem se formando) em TI – fatores que complementam o perfil de Maria, garantindo equilíbrio para a dupla. Seguindo a mesma lógica vemos que Joana tem dois candidatos a par ideal: Zé e Mané. Na outra diagonal temos o solitário João podendo se unir à Rita ou ao Teco. Preciso dizer que o próximo analista a ser contratado pela empresa modelo deve ocupar a mesma célula do João? Óbvio, não?

A sugestão – a matriz para formação de duplas – parece mecânica, fria e simples demais? Não se deixe enganar. As duplas, para funcionar bem, precisam de afinidade e entrosamento. Coisa que só o tempo garante. Um gerente não deveria dar uma de ‘cupido-bidu’, forçando casamentos. Os AN’s, particularmente os mais experientes, saberão buscar conhecimentos e habilidades que os completem. Ao permitir a auto-organização, a montagem orgânica e natural de pares, a empresa estará de certa forma garantindo e acelerando o entrosamento. Maria e Joana, se forem ‘sêniores’ de fato, saberão que terão mais valor para a organização se trabalharem com os colegas menos experientes. Sabem que só assim o aprendizado – a troca de conhecimentos e habilidades – se dará de maneira homogênea e eficaz.

Um Caso de Uso das Duplas

O departamento de marketing da nossa empresa modelo lançou um projeto para melhoria do site. Gostaria de incluir funcionalidades que aproximassem aquele canal do que se convencionou chamar de Web 2.0. Um blog, integração com Twitter, Flickr, Youtube e outras coisas ‘da moda’. Pretendem que cada produto tenha uma página especial, um clipe no Youtube e canais de interação direta com os responsáveis por ele. Enfim, querem que o site seja menos institucional e mais vendedor – mais atencioso com clientes e prospects (termo deles).

Maria anda às voltas com uma atualização do ERP. De qualquer maneira, ela também não esteve envolvida no desenvolvimento das versões anteriores do site. Internet, em outras palavras, não é o seu forte. Mané, de todos do lado direito da matriz, é o mais indicado. Porque ele conhece a evolução do site da empresa desde os tempos em que insistiram em uma home horrorosa 100% escrita em Flash.

Joana deve estar disponível em uma semana. Mas este projeto (ainda) não é prioritário. Se depender da gerência (e depende), ela deve ajudar Maria na atualização do ERP. Sobraram Tonho e Tico. Tico, apesar de mais novo na empresa, é super entusiasmado com esse papo de Web 2.0. E já trabalhou com o Mané em outro projetinho. Pronto: Mané e Tico formarão a dupla de AN’s deste projeto.

Mané e Tico sabem que seus perfis atuais determinam as principais responsabilidades de cada um. Mané conduzirá as entrevistas, workshops de requisitos e outros eventos de socialização. Ele é ‘bom de papo’, feliz em negociações e na resolução de conflitos. Caberá a ele a elaboração da pauta de cada encontro e entrevista.

Tico está ficando bom em modelagem de negócios. Entendeu rapidamente o valor do grande retrato “2km x 2cm” que ele desenvolve logo no início dos projetos. Mas o que Maria, Joana e Mané mais valorizam no Tico é sua facilidade para estruturar requisitos e especificar casos de uso. Quase sempre ele detecta de primeira inconsistências e conflitos entre requisitos. Também se posiciona bem perante os usuários na hora de colocar uma dúvida ou apresentar algum problema.

O valor de uma dupla não pode ser avaliado apenas no contexto de um projeto. É de suma importância que eles estejam aprendendo juntos, trocando experiências. Tico aprenderá ao prestar atenção na forma como Mané conduz entrevistas e sessões JAD. Mané, por sua vez, vai ler e analisar todos os modelos e especificações elaboradas pelo Tico. Também deve aprender e melhorar suas habilidades técnicas. Mas, o mais importante: eles conversam o tempo todo. Tête-à-Tête. Não há troca mais eficaz.

A empresa deveria orientar, da forma menos intrusiva possível, o rodízio entre pares. Porque a estagnação da troca é inevitável em determinado ponto. Uma dupla pode ficar acomodada em relação ao seu aprendizado. O ideal é que uma dupla nunca trabalhe em mais do que três ou quatro projetos consecutivos.

Também é importante notar que um time de analistas de negócios é uma potencial Comunidade de Prática. Se a empresa não obstruir (ocupando de forma doentia as 44,4 horas da jornada semanal de trabalho), a tendência é que eles troquem experiências, choramingos e fofocas. Se a empresa fomentar a Comunidade de Prática (cedendo local, duas horas semanais e uma garrafa de café) ganhará um time ainda mais entrosado e equilibrado em seus conhecimentos e habilidades. Este papo sobre Comunidades de Prática merecerá mais tempo e espaço em um futuro próximo.

Relendo o texto acima percebi que faltou uma coisinha. Uma mensagem que eu gostaria que todos AN’s levassem para seus gerentes e coordenadores. É simples: “É impossível trabalhar sozinho. E não me venha com jeitinho. Se queres a Análise de Negócios muito bem feita, Então me permita formar uma dupla perfeita.” Juro que a rima (paupérrima) não foi intencional. Você acredita se quiser. Inté!

?

A fotografia da dupla de Woodys que ilustra este artigo é do Aldo Cavini Benedetti e foi obtida no Flickr.

fevereiro 11, 2011
O Analista de Negócios Perfeito
Não. Não conheço nenhum analista de negócios perfeito. E estou certo de que nunca verei um. Perfeição é uma meta impossível. Por isso estranhei a falta de questionamentos aos textos “Um Corpo de Verdade” (da Análise de Negócios) e “Coração e Mente do Analista de Negócios“. Os dois artigos sugerem a existência de um analista de negócios (AN) perfeito. Ninguém reclamou. Ninguém achou que eu estava ‘pedindo demais’. Será que acreditaram na possibilidade de um AN com pernas longas e torneadas, braços fortes e hábeis, coração aberto e mente aguçada? Este artigo trata da impossibilidade da perfeição e sobre como organizações e profissionais podem lidar com ela.

?

A pergunta que recebo com mais frequência é: “por onde começo?” Costumo apontar para o Corpo (de Conhecimentos de Verdade) e dizer: escolha. Ninguém começa do zero. Boa parte dos participantes de meus cursos tem formação relacionada a TI. Espero que eles comecem pelo que não conhecem, o negócio. Mas não forço a barra. Sempre digo que devem iniciar seus estudos escolhendo um de dois caminhos possíveis: o que mais incomodou OU aquele que mais agradou. Cada pessoa tem estilo e ritmo de aprendizado únicos. Devem saber se é o desafio (de uma área nova) ou o conforto (de um terreno conhecido) o que mais as motivará.

No Corpo sugerido, a base das duas pernas (lembrando: direita = Negócio, esquerda = TI) é formada por disciplinas fundamentais, aplicáveis em negócios ou projetos de qualquer porte ou natureza. É conhecimento que se leva para o resto da vida. O AN, mesmo iniciante, deve saber inventariar seus conhecimentos em ambas as áreas. E orientar seus estudos no sentido de equiparar as pernas. O AN é ponte entre as áreas de negócios e TI. Espera-se que ele tenha razoável domínio de ambos os lados. Só assim se comunicará de igual para igual com todos. É difícil apontar cursos ou um conjunto de livros que formem esta base para um AN. Talvez minha lista de “11 Livros ‘Obrigatórios’” ajude um pouco. Mas o AN deve saber que só o tempo (e muitos projetos e estudos) ajudará a desenvolver esta base de conhecimentos.

A parte de cima das pernas representa conhecimento mais ‘perecível’ e / ou especializado. É o tipo de conhecimento que pode ser adquirido e ter utilidade em apenas um projeto ou em projetos específicos de determinado segmento. Não sei dizer se aqui no Brasil, a exemplo do que vejo lá fora, as empresas começarão a exigir dos AN’s a especialização em determinado ramo de atividades. Mas acho que os AN’s deveriam se preocupar em mostrar um pouco de especialização em seus currículos.

As habilidades de um AN, representadas pelos dois braços, são desenvolvidas mais rapidamente. Qualquer cursinho de poucas horas que não privilegie o fortalecimento de um braço em detrimento do outro está valendo. Lembrando: o braço direito representa habilidades que o AN desenvolve para entender um Negócio; o canhoto reúne habilidades que o AN precisa para entender os Usuários. Novamente o equilíbrio e a simetria são fundamentais. Assim como é fundamental aceitar que habilidades apenas são aperfeiçoadas com muita prática. Cada braço (ou disciplina) compreende um sem número de métodos, práticas e ferramentas. O bom AN deve desenvolver e manter atualizado seu “cinto de utilidades”. Ele sabe que cada negócio, projeto ou usuário pode exigir uma combinação única de ‘brinquedinhos’ que facilitem a comunicação e o aprendizado.

O bom AN tentará manter seu corpo simétrico. Buscará a perfeição, apesar de aceitar sua impossibilidade. E as empresas? Como elas podem lidar com a imperfeição de seus analistas?

Em primeiro lugar, conhecendo-os. É crucial que a organização saiba quais são os pontos fortes e fracos de cada membro de sua equipe. Se o que foi apresentado acima foi minimamente entendido, então a empresa sabe que não realizará seu ‘inventário de conhecimentos & habilidades’ aplicando provinhas ou exigindo certificados e diplomas. Desconheço certificação ou diploma que garanta que um AN saiba falar, conversar e entender um usuário ou negócio. O buraco é mais embaixo… fica perto da camada do pré-sal.

Não pretendo tratar aqui do processo de seleção de AN’s. Talvez em um futuro artigo. Só queria salientar que uma organização deve desenvolver uma forma de avaliar conhecimentos e habilidades de todo o seu time de Análise de Negócios. Ela deve saber quais tipos de conhecimentos básicos (administração, informática, contabilidade, finanças etc) deve cobrar e ajudar a desenvolver. Em um banco, por exemplo, uma parte do time de AN’s é formada em Direito. Sim, são advogados preparados para os jargões e trejeitos de uma área jurídica. Considerando exclusivamente as pernas (conhecimentos do Negócio e de TI) tenho apenas uma recomendação: que o time de AN’s não seja composto exclusivamente por profissionais com formação em TI. A diversidade é mais que necessária. Aquele mesmo banco tem uma coordenadora formada em Letras. Em uma empresa de telecomunicações vi um AN publicitário. Se é para ser mais objetivo, cravo um número: que metade do time NÃO tenha formação em TI¹.

As habilidades (para entendimento do Negócio e dos Usuários) devem ser avaliadas e desenvolvidas em conjunto. Não faz nenhum sentido que um AN só entenda o negócio enquanto outro apenas entende o usuário. As habilidades se completam. E são sempre aprendidas, desenvolvidas e aplicadas simultaneamente. Mas todos sabemos que as pessoas aprendem de maneiras e ritmos diferentes. Assim como sabemos que as habilidades sociais podem ser bastante distintas de um analista para outro. Não devemos condenar (ou deixar de contratar) um AN que se mostre um tanto tímido e introvertido. Não se ele compensar essa aparente deficiência com boa cabeça para solução de problemas e/ou excelente comunicação escrita e/ou destreza em atividades de modelagem etc.

Metade da equipe formada em TI, metade não. Metade atualizada em relação ao negócio, a outra em relação à TI. Metade rica em habilidades sociais, outra metade tecnicamente habilidosa. Este é o retrato de um bom time de Análise de Negócios. De um time que, por se completar, exibe um Corpo mais simétrico e, por que não dizer, perfeito. Daí à conclusão de que esses profissionais sempre trabalham em duplas é um pulinho, certo²?

?

Observações:
1. Pelo andar da carruagem, talvez esteja próximo o dia em que vamos pedir que metade de um time de AN’s tenha formação em TI. Digo isso porque todo dia aparece alguém dizendo que vão faltar 200 mil ou 800 mil profissionais na área.
2. Não se preocupe se a sugestão para o trabalho em duplas não pareceu tão óbvia para ti. O próximo artigo falará exclusivamente sobre isso.
3. O Woody todo vaidoso acima, fotografando a si mesmo, é obra liberada por Sherman Tan no Flickr.
fevereiro 10, 2011
Management 3.0
Autor: Jurgen Appelo, holandês que se apresenta como escritor, palestrante, instrutor, desenvolvedor, empreendedor, gerente, blogueiro, leitor, sonhador, líder e pensador livre. Figura relativamente nova na Comunidade Ágil. Este é seu primeiro livro.

Editora: Addison-Wesley (2011).

Promessa do Subtítulo: Liderando Desenvolvedores Ágeis, Desenvolvendo Líderes Ágeis

Do que se trata: GERENCIAMENTO. O autor dirige o livro para gerentes “de linha” (de áreas de Desenvolvimento ou Departamentos de TI) reforçando que não se trata de (mais) um livro sobre Gerenciamento de Projetos. Também “filtra” um pouco mais a seleção colocando que o livro é sobre Gerenciamento Ágil. Mas parece que todo mundo que já teve o prazer de conhecer esta obra descobriu que se trata de um trabalho sobre Gerenciamento no século XXI, o século da Complexidade. GERENCIAMENTO em seu sentido mais amplo.

Três ponto zero?: O gerenciamento 1.0 foi aquele chamado de científico, caracterizado por hierarquias e originado no início do século passado. O gerenciamento 2.0 brota em meados dos anos 1980 e é caracterizado pelas manias e modismos, por patches e add-ons (TQM, BPR, TOC, BsC, Six Sigma etc) que tentavam “corrigir” a versão anterior.

Então veio a teoria da complexidade e sua aplicação na matemática, biologia, economia e sociologia. Aí chega o Jurgen, mergulha na teoria e em sua aplicação nos mais diversos domínios, e a destila em um modelo que ele chamou de Management 3.0.

Indicado para: Gerentes, líderes, desenvolvedores, empreendedores, sonhadores, pensadores livres e todos que queiram entender a razão de tudo neste mundo parecer um tanto complicado e/ou complexo e porque todo sucesso não passa de um adiamento do fracasso.

Contra-indicações: Puristas, extremistas, conservadores, preconceituosos, adoradores de ângulos retos e eleitores do Jair Bosonaro podem sentir um certo desconforto em diversos trechos do livro.

Breve Resenha: Quem lê livros técnicos sobre um mesmo tema com uma certa frequência vive com a sensação de déjà-vu. Nos últimos tempos engoli, total ou parcialmente, mais de uma dúzia de livros sobre o Desenvolvimento Ágil de Sistemas. Poucos realmente colocaram assunto novo na mesa. Dois deles mereceram entrada nesta biblioteca. O resto girou em torno dos mesmos temas, problemas e sugestões. Às vezes mudando nomes, outras tantas reciclando histórias.

Jurgen Appelo acaba de colocar o assunto “Agile” em outro patamar.

Não se trata de um reset, pelo contrário. Jurgen conhece e respeita toda a história que no próximo dia 13 de fevereiro completará dez anos (data da publicação do Manifesto Ágil). Mas ele se apresenta como um pensador livre. E é. Por isso busca coisas com milhares ou milhões de anos de idade ou situações bobas do cotidiano para ilustrar suas colocações e tornar mais palatáveis as ideias e teorias que sustentam seu modelo. Estratégia mais que necessária, porque Jurgen parte de um Corpo de Conhecimentos de Sistemas formado por coisinhas espinhosas como: Teoria Geral dos Sistemas, Cibernética, Teoria dos Sistemas Dinâmicos, Teoria dos Jogos, Teoria do Caos e Teoria da Evolução. Não se assuste ainda. Esta é apenas parte da história que ele conta para justificar o uso do Pensamento da Complexidade (ou Teoria da Complexidade ou ‘simplesmente’ Complexidade, hehe) como base para o seu modelo.

Perdão, não há motivos para sustos. Jurgen apresenta essas teorias e conceitos para “humanos normais” como você e eu. Primeiro em um único capítulo, o terceiro, pavimentando o caminho que seguiremos. Depois em capítulos que concentram toda a parte teórica de cada Visão proposta no modelo Management 3.0. Cada uma das seis visões da Martie (o monstrinho que Jurgen desenhou para representar o modelo) é apresentada em dois capítulos, um teórico e outro prático. Essa sacada, além de facilitar a compreensão de suas sugestões, permite o planejamento de nossos estudos. Este é um livro para ser estudado, não simplesmente lido. Optei por estudar um visão por dia: o capítulo teórico na parte da manhã, o prático bem depois do almoço.

Hora de apresentar, afinal, os seis “olhos” da simpática Martie:
- Energizar Pessoas: “Penso que as pessoas são as partes mais importantes de uma organização e que os gerentes devem fazer de tudo para mantê-las ativas, criativas e motivadas.”
- Fortalecer¹ Times: “Acredito que os times podem se auto-organizar, e isto requer delegação de poderes, autorização e confiança por parte dos gerentes.”
- Alinhar Restrições: “Expliquei que a auto-organização pode resultar em qualquer coisa, portanto é necessário proteger as pessoas e os recursos compartilhados e dar para as pessoas propósitos claros e objetivos definidos.”
- Desenvolver Competência: “Também acredito que os times não podem atingir esses objetivos se seus integrantes não forem capazes, e que os gerentes devem contribuir para o desenvolvimento da competência de cada um deles.”
- Desenvolver² Estrutura: “Muitos times trabalham no contexto de uma organização complexa, por isso estou convencido de que é importante considerar as estruturas para melhorar a comunicação.”
- Melhorar Tudo: “Também penso que as pessoas, times e organizações devem continuamente melhorar tudo de forma a adiar o fracasso o máximo possível.”
- “Finalmente, acho que a apresentação acima está bem fácil de entender, o que significa que ela provavelmente está errada.”
O resumo acima é apresentado lá no finalzinho do livro, quando o autor confessa: “Sim, meu modelo está ‘errado’”. “Todos Estão Errados, mas alguns são úteis” é o título do capítulo 16. O humor e a honestidade de Jurgen, além, claro, do tanto que ele conhece e estudou, fazem deste livro um marco. Suecos (e seus 1.217 mosquitos), belgas, cubanos e eleitores do Bosonaro terão alguns motivos para reclamar do livro. Acho que nenhum relacionado ao que ele ensina sobre GERENCIAMENTO.

Alguns Trechos Selecionados, Surrupiados e Livremente Traduzidos:

“Acho que o Movimento Ágil negligenciou a importância dos gerentes (de linha). Se os gerentes não sabem o que fazer nem o que esperar de uma organização Ágil, como esperar que eles se envolvam na transição para o desenvolvimento Ágil de software? Qual é a mensagem do Movimento Ágil aqui? Se for apenas ‘não precisamos de gerentes’, então não causa espanto saber que transições para o Ágil estão sendo obstruídas ao redor do globo.”

“Lembre-se que valores Ágeis não são listas fixas com cinco, sete ou doze itens. Este livro é sobre complexidade, não sobre respostas simples.”

“Nenhum sistema³ que se auto-organiza existe fora de um contexto. E é o contexto que restringe e direciona a organização de um sistema.”

“Gerentes inteligentes sabem que devem tomar o menor número de decisões possível.”

“Acredito que um ‘ponto fraco’ do Manifesto Ágil é o fato dele não reconhecer (explicitamente) que todos os projetos de software precisam de pessoas inteligentes, disciplinadas e atentas. O paradigma ‘pessoas mais que processos’ é jóia, até você descobrir que seu time se limita a dois duendes, um papagaio, uma cabeleireira e um gerente de projetos aparentemente brilhante mas que é cego, surdo e mudo. Não há coaching no mundo que faça este time se auto-organizar e entregar um produto bem sucedido.”

“Disciplina * Habilidade = Competência”

“A melhor maneira de implementar processos Ágeis é fazê-lo do seu jeito.”

“Modelos de maturidade são pouco úteis, talvez até um pouco ofensivos.”

“Se eles podem escovar seus dentes todos os dias para se livrar de cáries, por que não podem escovar o código diariamente para se livrar dos bugs?”

“Gerentes de projetos estão ali para servir os times, não para controlá-los. Gerentes de projetos estão ali para gerenciar projetos, não pessoas.”

“Se você introduzir um novo produto de software em um ambiente, o ambiente vai mudar, consequentemente os requisitos para o produto também mudarão.”

“O valor percebido de uma mudança é proporcional à dor que se sente por não mudar.”

“Compañero, no hay camino. Se hace camino al andar.”

Observações:
1. O termo original é “empower”. Optei por “fortalecer” (times) como tradução porque empowerment normalmente é entendido apenas como “delegação de poderes”. O autor tem objetivos mais amplos e ambiciosos para a palavra.
2. Outro termo comum que ainda me atrapalha é “grow”. Simples: é crescer… ou aumentar, germinar, florescer, produzir. Optei por “desenvolver” por achá-lo mais coerente com a intenção do autor: “grow structure”.
3. A palavra “sistema” é utilizada no livro em seu sentido mais amplo. Empresas, times, pessoas e bactérias são sistemas.
4. Esta entrada ficou longa, muito longa! O livro, em cada uma de suas 413 páginas, fez por merecer. De tempos em tempos me deparo com um título que realmente me “melhora”. Muito. Não vejo a hora de estudá-lo de novo.
fevereiro 3, 2011
Coração e Mente do Analista de Negócios
Sequência da conversa iniciada na última sexta, sobre o Corpo de Conhecimentos da Análise de Negócios. A divisão não aconteceu só por uma questão de espaço. Dediquei a primeira parte aos conhecimentos fundamentais e habilidades técnicas que um analista de negócios (AN) deve estudar, aprimorar e dominar. Relacionei-os às pernas (Conhecimento do Negócio e Conhecimento de TI) e braços (Modelagem de Negócios e Engenharia de Requisitos), respectivamente. Tentarei completar o desenho do corpo hoje, apresentando o coração e a mente do analista de negócios.

?

Difícil utilizar a figura de um coração, ainda mais em um texto “técnico”, e não soar piegas pra caramba. Mas a analogia com um corpo humano não me deu alternativas. Utilizarei o coração para falar sobre Habilidades Sociais (ou “soft skills”). Havia outra opção? Ao lembrar de colegas tidos como “viscerais” a gente tem algumas ideias¹. Mas eles normalmente são péssimos exemplos quando o assunto é aquele conjunto de virtudes (qualidades) que deveríamos apresentar ao lidar com pessoas. O coração, piegas ou não, cumpre melhor a função.

Sem meias palavras: O analista de negócios GOSTA de gente. Ele curte estar entre pessoas e conversar. Gostar de pessoas é requisito fundamental para quem queira atuar como AN.

Você verá diversas derivações quando o tema for habilidades sociais (de um AN ou de qualquer outra profissão). Falam sobre: Respeito, Comunicação, Saber Ouvir, Autodisciplina, Autocontrole, Paciência e mais uma lista imensa que você, caso esteja curioso, vai encontrar em livros do tipo “Como Fazer Amigos e Influenciar Pessoas”. Nenhuma outra área do conhecimento humano concentra tanta bullshitagem e charlatanismo quanto esse papo sobre habilidades sociais. Porque, no final das contas, estamos falando de uma coisinha só: você deve gostar de pessoas – de se relacionar com elas. O resto, todas as outras virtudes, depende disso. E não há filme de hollywood “com mensagem” ou livro de auto-ajuda que converta bichos-do-mato em seres socialmente aptos. Não estou dizendo que “pau que nasce torto morre torto”. Apenas alerto para o fato de que não é tarefa simples converter Urtigão em Miss Simpatia.

O AN é elo entre todas as partes interessadas de um projeto. O que ele mais faz é se comunicar. Por isso ele precisa ser um excelente comunicador. Parece que uma parcela desta habilidade vem do berço – é inata. Mas isso nunca pode servir de desculpa para um profissional se comunicar mal, independente do meio que utilize. Boas escolas e bons treinamentos existem por aí – infelizmente em número muito menor do que precisamos. Mas existem!

A comunicação escrita parece ser um imenso problema para muitos (inclusive este que vos escreve). Há um remédio universal, comprovadamente eficaz e relativamente barato: LER! Além, claro, de praticar e praticar e praticar. Quem busca atalhos neste tema invariavelmente passa vergonha.

Mas, peraí, a comunicação está no coração? Não, ela depende dele, mas não pode ser classificada simplesmente como “habilidade social”. Está aqui um erro que cometo há tempos. A boa comunicação depende de nossas habilidades sociais (respeito, saber ouvir etc) tanto quanto depende de uma série de habilidades técnicas (domínio da língua, domínio do meio etc). Entram neste mesmo balaio (cinza) outras características desejáveis em AN’s, como negociação, resolução de conflitos etc. Não adianta ser bom no blablablá mas não dominar alguma técnica ou ferramenta necessária em determinada situação. E o domínio de técnicas e ferramentas vale zero se não estiver acompanhado de boa educação e bons modos.

E a Mente? O que sobrou para o cérebro do corpo de conhecimentos da análise de negócios? Oras, o Poder de Análise, além de um mecanismo de orientação e coordenação de tudo o que vimos até agora.

Sem meias palavras: o cérebro do AN é totalmente orientado para a solução de problemas. Ao analisar o negócio ele orienta as pernas (os conhecimentos sobre o negócio e sobre TI) e coordena os braços (modelando negócios e desenvolvendo requisitos) para ajudar uma organização a resolver determinado problema. Não interessa se é um problema bom (uma oportunidade de negócio) ou ruim (uma área ou processo da empresa gerando dores de cabeça), o fato é que o cérebro do AN atua para ajudar a entender o problema e encontrar uma solução. Explicando a ênfase em ajudar: não podemos esperar que o AN sozinho resolva um problema. Quando ocorrer será exceção. O que se espera é que ele ajude a encontrar uma solução.

E o que nos ajuda a resolver problemas? Como o AN prepara seu cérebro? Quais disciplinas existem com este fim? Entramos agora em uma área ao mesmo tempo apaixonante e assustadora.

Eu costumava destacar, de maneira equivocada (e/ou simplista) e em um único slide, a 5ª disciplina conforme descrita por Peter Senge²: o Pensamento Sistêmico. Mais errada era sua classificação como “habilidade social”. Mas há um tanto de cinza por aqui também. Questões que (ainda) não merecem destaque.

A Solução de Problemas é uma área tão ampla e complexa que não pode ser condensada em apenas uma disciplina (por excepcional e ampla que ela seja, como o Pensamento Sistêmico). Se mergulhássemos um pouco mais no assunto veríamos coisas como: Teoria dos Sistemas Complexos, Teoria das Restrições (TOC), Teoria dos Jogos, Teoria do Caos, Cynefin, Pensamento Visual, Sistemas Adaptativos Complexos (CAS) e até a Teoria da Evolução de Darwin, dentre várias outras sugestões e teorias. Acho que acabei de te assustar. Mas será que você vai se apaixonar?

Só saberemos depois dos dois próximos artigos. Inté!

?

Observações:
1. Algumas ideias que tive quando visualizei colegas ‘viscerais’:
  1. O cara conduz workshops de requisitos com o fígado!
  2. Ela colocou todo o seu estômago naquele documento de visão.
  3. Aquilo não é um caso de uso – é a radiografia de um pâncreas!
  4. Saiu do projeto porque só fez m***a na reunião com o cliente.
2. “A Quinta Disciplina – Arte e Prática da Organização que Aprende”
  Peter M. Senge. Editora Best Seller (2000).
  Edição revista e ampliada. A original é de 1990. Mas sei que já foi lançada uma nova edição, mais revista e ampliada ainda…
3. “Muß i’ denn“, a versão do Woody que ilustra este artigo, é de Tony Eccles.
janeiro 31, 2011
Um Corpo de Verdade
Como prometi no último artigo, vou tentar liberar uma série de textos mais construtivos sobre Análise de Negócios. E por onde eu deveria começar? Já tinha uma ideia. O colega Jefferson Velasco deu o empurrão que faltava ao comentar que o processo de seleção de analistas de negócios (AN’s) costuma ser um tanto confuso e muito exigente. Como não há uma definição amplamente aceita sobre o papel de um AN, pedem e buscam de tudo nos currículos e testes. Esta é a questão que tentarei responder neste artigo: o que devemos cobrar de um AN? O que um AN estuda, aprimora e domina? Afinal, qual é o CORPO de conhecimentos que o define?

?

A sensação de eterno reset me incomoda também. Estou cansado de ver artigos sobre o mesmíssimo assunto. Acontece que boa parte dos problemas que reportei no artigo anterior tem a ver com isso, com a má compreensão do papel e responsabilidades de um AN. Por isso decidi voltar ao básico e arriscar o desenho de um CORPO de conhecimentos. Por favor, esqueça o BABoK por enquanto. Lá no final do artigo eu falo sobre ele e suas diferenças em relação ao corpo aqui proposto.

Começamos com as duas pernas. São elas que dão sustentação e movem todo o corpo. A perna direita de nosso simpático Woody (O AN Vitruviano) representa o Conhecimento do Negócio. Se a pessoa será analista de Negócios, parece lógico que iniciemos a jornada por aqui, certo? Acontece que “negócio” é um termo tão amplo e abstrato que há o sério risco desta perna ficar superdimensionada ou atrofiada. Precisamos separar dois tipos de conhecimentos do negócio. O primeiro, que vou chamar de básico (mas alguns chamarão de horizontal), é formado por disciplinas… básicas. Disciplinas que são aplicáveis em negócios de qualquer ramo ou porte. Sim, estou falando de Administração de Empresas, Contabilidade, Finanças e Marketing, principalmente. Calma! Ninguém em sã consciência vai passar a exigir dos AN’s diplomas de curso superior nessas áreas. Mas devem cobrar sim que o AN conheça: planos de contas, lançamentos contábeis, matemática financeira e um monte de etc. Esta é a primeira metade da perna, aquela que vai do pé ao joelho.

A segunda é menos chata (hehe) e mais cheia de carne e músculos. Aqui podemos utilizar o termo “vertical” para identificar este tipo de conhecimento do negócio. Prefiro chamá-lo de conhecimento especializado. Refere-se à especialização em determinada empresa, área ou ramo de atividades. O AN pode ter experiência no ramo de seguros ou no varejo de drogas lícitas, por exemplo. É relativamente comum, particularmente em anúncios estrangeiros, que as empresas exijam este tipo de experiência, de conhecimento de um tipo específico de negócio. Reparem que citei também a especialização em “determinada empresa”. Neste caso o profissional tem tempo de casa suficiente para “saber tudo” sobre ela. Tipo de domínio muito caro em tempos de pouca fidelidade.

A perna esquerda representa Conhecimentos de TI. Desenhei assim porque estou falando com AN’s que atuam exclusivamente em projetos de TI. Novamente é necessária uma divisão. O conhecimento básico (do pé até o joelho) condensa: conceitos fundamentais de informática, lógica de programação, modelagem de sistemas, modelagem de bancos de dados, operação de ferramentas de produtividade e colaboração e alguns etc. Há quem questione parte desta lista, principalmente os itens que falam de programação e modelagem. Insisto que um bom AN deve ter tal conhecimento para conseguir se comunicar de maneira mais eficaz com os times técnicos. Pode não ser mandatório, mas sempre será desejável. Dado o perfil de 80% dos AN’s que conheço (com formação em algum sabor de TI), não creio que isso represente um problema.

A segunda parte desta perna, a exemplo do que aconteceu com a direita, também representa conhecimentos específicos. No caso de AN’s que atuam apenas em uma organização, estamos falando do conhecimento sobre a Arquitetura Corporativa daquela organização. Conhecer a plataforma tecnológica, os principais repositórios de dados e aplicações. Mas é importante destacar que aqui podemos ver o desenvolvimento de outra categoria de especialização: AN’s que atuam exclusivamente em projetos de determinado tipo, de BI (Business Intelligence), por exemplo.

Como já coloquei, são as pernas que sustentam e movem o corpo. Deficiências em qualquer dos dois tipos de conhecimentos significam dificuldade de locomoção e de aprendizado. CALMA! Todos os AN’s que conheço apresentam alguma dificuldade de locomoção. É natural. Ninguém sabe tudo, e nós estamos falando de conhecimentos muitas vezes voláteis e dinâmicos (particularmente aqueles que chamei de especializados). O bom AN saberá diagnosticar e diferenciar uma unha encravada de um menisco estropiado. E saberá sanar o problema ou encontrar um bom médico. Só deve preocupar mesmo aquele AN que chega manco no fim de um projeto.

Não estamos aqui para conversar sobre o que um AN carrega no abdômen, então pularemos diretamente para os dois braços. Não foi o acaso que decidiu a posição de cada disciplina no desenho acima. O braço direito de um AN é a Modelagem de Negócios. Porque esta é a disciplina que o ajuda a Entender um Negócio. Reparem que o lado direito dele é só negócio, perna e braço. A modelagem, o entendimento de um negócio, é condição primordial para um bom entendimento dos usuários. Coisa que conseguimos através da Engenharia de Requisitos, o braço canhoto do AN. Todo analista precisa dos dois braços. Mas muitos ainda utilizam apenas sua mão sinistra¹!

Os braços representam habilidades técnicas que um AN deve desenvolver. É o tipo de habilidade (e conhecimento) mais fácil de ser transferido. É aqui que se posiciona, por exemplo, o programa FAN. Mas é importante notar que o domínio dessas duas disciplinas facilita a evolução das pernas (o desenvolvimento de conhecimentos sobre o negócio e sobre TI). Quem malha – quem faz musculação ou algo parecido – sabe que existem exercícios específicos e outros que movimentam pernas e braços. A analogia se aplica aqui. Por exemplo: quanto mais você praticar a modelagem de negócios, mais conhecerá sobre um negócio ou ramo de atividade.

Mas braços e pernas são suficientes para a formação de um bom AN? Claro que não. Como o desenho acima ilustra, um AN também tem Coração e Mente. Sobre eles a gente conversa na próxima semana. Inté!

?

Se este é, como o título adianta, um “Corpo de Verdade”, então o BABoK seria um corpo de mentira? Não, não há (muitas) mentiras no BABoK. Mas, como você já deve estar cansado de saber, não vou muito com a cara e o jeito daquele Corpo de Conhecimentos. Se você fizer uma comparação minimamente isenta em relação ao que foi apresentado acima, verá que o BABoK praticamente se resume a um braço esquerdo. Portanto, quem entende a profissão só pelo que viu no BABoK está contratando, formando ou se transformando em um braço esquerdo¹.

Observações:
1. Nada contra o braço esquerdo, por favor! Sou canhoto e gosto disso (jogando bola, principalmente). Mas houve um tempo em nossa história que canhotos eram queimados em fogueiras. Tô brincando não. Alguns acreditavam que canhotos eram “coisa do demo”. Daí o surgimento de um termo utilizado até hoje. Em meu certificado de reservista, no campo “Sinais Particulares”, está escrito: sinistromano. Sinistro!
2. A classificação apresentada neste artigo foi levemente inspirada neste trabalho.
3. O uso de um Corpo Humano como metáfora para um Corpo de Conhecimentos foi totalmente inspirado (leia-se: surrupiado e adaptado) em uma classificação feita por Jurgen Appelo no livro “Management 3.0“. A diferença é que ele desenhou um “Corpo de Conhecimentos de Sistemas”. E utilizou uma bonequinha medonha para representá-lo. O livro, excepcional, vai furar fila e aparecer muito em breve aqui na Biblioteca do finito.
4. O “Woody Witruviano” é obra do Aldo Cavini Benedetti e foi disponibilizada no Flickr com licença CC (by-nc-sa).
janeiro 28, 2011
Análise de Negócios – 4 Anos Depois
Há quatro anos iniciava meu mergulho na Análise de Negócios, estudando o mercado e desenvolvendo o programa de treinamento que seria lançado em junho/07. Muita coisa parece diferente agora, particularmente a difusão da disciplina. Infelizmente, muita coisa parece inalterada ou ter mudado para pior. Neste artigo pretendo discutir alguns problemas que impedem o uso pleno e eficaz da Análise de Negócios pelas organizações.

?

Naquela época algumas pessoas diziam que o bafafá sobre Análise de Negócios não passava de uma moda. Sempre admiti que a disciplina vivia seu momento, algo semelhante ao que havia acontecido com o Gerenciamento de Projetos a partir da segunda metade da década de 1990. E completava: “antes tarde do que nunca”. Porque já tinha muito tempo que diversas fontes, ao analisar as razões de tantos fracassos em projetos de TI, apontavam o mau entendimento de um problema e questões de comunicação entre times técnicos e de negócio como algumas das principais causas de tanto insucesso.

Surrupiei e uso desde então uma colocação que Fred Brooks fez em seu artigo “No Silver Bullet” (publicado originalmente em 1987 e disponível como capítulo adicional do livro “O Mítico Homem-Mês“, Campus – 2009):

“A precisa definição sobre o que precisa ser feito é a parte mais difícil da construção de um software. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.“

A Análise de Negócios, por definição, ataca exclusivamente¹ a “parte mais difícil da construção de um software”. Por isso eu dizia e repito: “antes tarde do que nunca”. Que a disciplina tenha vindo para ficar. Ou, melhor dizendo, que a “moda” (assim, entre aspas) tenha vindo para ficar. Porque a disciplina está conosco há um tempão.

O problema é que sua presença não era percebida como sendo uma disciplina, um único corpo de conhecimentos. No RUP, por exemplo, surgia em dois lugares: Modelagem de Negócios e Requisitos. Em outras propostas e métodos dava sua cara sob o disfarce de “<verbo> Requisitos” (Levantamento (sic) de Requisitos, Coleta (10x sic) de Requisitos, Gerenciamento de Requisitos etc). Esta ligação direta, Análise de Negócios -> Requisitos, é tão comum e pouco questionada que contamina não só a forma como muitas empresas interpretam e usam a disciplina, marca também os mais graves enganos do BABoK.

Por incrível que possa parecer, muitas empresas (algumas bem grandinhas) entendem que o analista de negócios é aquele cara que senta na frente de um usuário e anota tudo o que ele pedir. Não são analistas de negócios, são “tiradores de pedidos”. É fácil identificar empresas com tal grau de miopia: basta pegar a média de idade e de tempo de casa de seus analistas. Em outras (poucas) organizações tive a surpresa e felicidade de encontrar analistas com mais de 20 anos de casa². É nítida a mensagem que elas passam: “essas pessoas conhecem como pouquíssimas a organização, por isso elas têm melhores condições de analisar nosso negócio”.

A atenção exclusiva ao incêndio nosso de cada dia – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios pode trazer.

Como em toda “moda”, há aqueles que compram sem saber o que estão comprando. Nem sabem se precisam daquilo. “Como o vizinho da grama mais verde está usando analistas de negócios, então eu também quero”. Não são poucos os profissionais que me procuram reclamando que foram contratados como AN’s mas que só fazem o trabalho de analistas de sistemas ou de suporte. Na realidade, como já chorei por aqui, a atenção exclusiva ao “incêndio nosso de cada dia” – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios poderia trazer. Cheguei a pensar no seguinte título: “Parem de Contratar Analistas de Negócios!“. Mas acho que soaria alarmista demais… e incompleto. Quem dera o problema fosse “só” esse.

A alta rotatividade de profissionais – tema que tenho debatido no GRAFFiTi (1,2) – é particularmente nociva quando atinge analistas de negócios. Sei de empresas que perderam mais da metade de seu time de AN’s em menos de dois anos. Desenvolver as habilidades técnicas de um AN é relativamente rápido e barato. O mesmo não pode ser dito sobre o Conhecimento do Negócio. Dependendo das experiências anteriores do analista – se já atuou naquele ramo de atividades, por exemplo – pode ser demorada e custosa a aquisição deste conhecimento. É difícil justificar a adoção de uma política de retenção específica para AN’s. Mas as empresas precisam entender que cada AN perdido (ou demitido) pode ser um desperdício que não se recupera em 12 meses.

O que mais me angustia é a sensação de que boa parte dos participantes de meus treinamentos não poderá utilizar ou praticar muito do que aprendeu (ou que eu espero que ele tenha aprendido). Por quê? Porque a Análise de Negócios é apenas uma peça do complexo quebra-cabeças chamado “Desenvolvimento de Sistemas”. Como desenvolver requisitos de maneira iterativa e incremental se a empresa ainda está casada (através de muito papel passado) com o modelo Waterfall? Por isso algumas de minhas sugestões sempre são recebidas da mesma maneira: “meu ‘chefe’ (sic) deveria estar aqui ouvindo isso”. AN’s trabalhando em duplas? AN’s dedicados a apenas um ou no máximo dois projetos? Esquece…

As empresas vivem aturdidas e um tanto perdidas. Significa dizer que seus objetivos nem sempre ou quase nunca são conhecidos (ou entendidos). Jogue na mesma cumbuca departamentos de TI que, de tanto não entregar, desaprenderam a dizer “não” ou perderam o direito de dizê-lo. Pronto: está criado o ambiente maluco de gente que acredita (na marra) que é possível atender e entregar 20 ou 10 projetos simultâneos.

Mais triste é saber que a Boa Análise de Negócios, se bem aplicada, ajudaria a reduzir essa sensação de não saber o que fazer. Ajudaria tanto a área de TI quanto a organização como um todo. Acontece que são raríssimas as organizações que percebem a disciplina desta forma. As outras, mesmo que percebessem, agora veriam uma área repleta de “tiradores de pedidos” com rostos assustados.

?

Não queria abrir a temporada de artigos em tom tão pessimista. Mas eu entendo que é minha obrigação publicar esse tipo de alerta. Espero já ter esgotado as principais notícias ruins acima. Porque sei que também é minha obrigação tentar dar algumas dicas que ajudem as organizações a combater o mau uso da Análise de Negócios. Ou, colocando de forma mais positiva, tentarei mostrar como é o bom uso da Análise de Negócios. Inté!

Observações:
1. Antes que atirem pedras: eu escrevi acima que a “análise de negócios, por definição, ataca exclusivamente ‘a parte mais difícil da construção de um software’”. Claro que estou falando da Análise de Negócios aplicada *exclusivamente* em projetos de software.
2. Por favor, entenda que não estou defendendo que todo AN deve ter 10 ou 20 anos “de casa”. Apenas ilustrei um caso extremo e bastante específico. Por outro lado reforço sim que uma empresa que leve a sério a Análise de Negócios deve ter um bom número de analistas com considerável experiência naquela organização ou mercado. O que chamo de “considerável experiência”? No próximo artigo a gente conversa sobre isso.
3. A imagem utilizada, “4“, foi liberada por rosmary com licença Creative Commons (by).
janeiro 26, 2011
2 0 1 1
Apesar de tentar obedecer o padrão, minha noção de “Ano Novo” não ocorre entre dezembro e janeiro. Começo a visualizar o próximo ano ‘letivo’ em julho ou agosto. Até dois meses depois eu preciso ter um bom desenho sobre como eu quero estar quando o próximo ano acabar. Tão ou mais importante que as metas financeiras (que, no final das contas, nunca se realizam mesmo) são os objetivos de estudo e das conversas que ele pode gerar. Há uma década adquiri o hábito de desenvolver um tema por ano. Faço uma imersão e depois tento repassar o que aprendi em artigos e eventos. Como já fiz no ano passado, neste artigo vou escancarar (um pouquinho) meus planos para 2011.

Planos que devem ser especiais porque em 2011 completo 25 anos de relacionamento com esta área chamada genericamente de Tecnologia da Informação. Pois é, Bodas de Prata! No namoro fui programador. Noivado na marra se deu quando me converteram em gerente de projetos. Há cinco anos, quando voltei para minha terra natal e me converti em consultor independente (sem patrão nem sogra), resolvi que era casório mesmo.

Ano especial significa um pouco mais de ambição. Boa ambição. Ao analisar a evolução histórica das visitas ao finito foi fácil perceber uma inevitável estabilização. Não posso forçar a barra ou questionar convicções e estilo para tentar conquistar quem não gosta de meu trabalho. Não. Em relação ao finito a minha principal preocupação será não perder quem eu consegui atrair. Para isso eu sei que devo continuar entregando o que eles esperam, em torno dos temas já consolidados (Análise de Negócios, Gerenciamento de Projetos e Engenharia de Software, principalmente).

Mas quem me conhece sabe que esse papo de estabilização e mesmice não tem nada a ver comigo. No início do ano passado tentei explorar algumas ideias diferentes, em artigos e eventos. Falo principalmente dos fracassados “Jogo dos 7 Erros” e do épico do “Seu Moreira”. Quebrei a cara. Como sou teimoso como um bom burro mineiro, tentarei lançar o jogo novamente. Motivado principalmente por participantes do FAN que falaram: “eu quero”. Mas meu cardápio, como eu antecipei em meados de 2010, tem novas opções:
- FDP – Formação de Donos de Produtos: único produto que já testei em 2010 (com resultado pra lá de positivo). Ele seguirá em testes beta por mais duas ou três edições. O que eu não havia contado até agora é que este evento foi um chute de longa distância para testar outro lançamento, o
- FAN4Scrum: sim, a formação de analistas de negócios para trabalho específico com o framework Scrum. Ele se sobrepõe de certa maneira ao FDP, mas tem um perfil bem diferente. Enfatizo técnicas de desenvolvimento de requisitos e histórias. O ‘4’ no nome tem outro significado: celebra o 4º ano do programa FAN. A primeira versão (aberta) será uma oficina com 7 horas de duração.
- FLiP – Formação de Líderes de Projetos: há tempos ensaio meu retorno ao tema Gerenciamento de Projetos. É meu tiro mais arriscado porque se trata de uma área em fase de estranha ebulição. O alto risco justificará uma estratégia de testes diferente daquela que utilizei no lançamento do FDP. Conto mais em breve.
- Análise de Negócios – Linguagem Chave para Executivos: oficina que desenvolvo a quatro mãos com o Sérgio Storch, da ContentDigital. Em quase todas edições do FAN ouvi o seguinte: “Queria muito que meu gerente estivesse aqui”. Este evento foi desenhado para eles e outros executivos, de TI ou não. Melhor dizendo: está em fase de desenho. Mas sairá ainda no primeiro semestre.
Outros temas ‘xodó’ passaram todo o ano de 2010 clamando por um pouco de atenção: Gestão do Conhecimento; o “i” de TI; Software como Negócio; Software como Ativo; e, jogando no ventilador, TI, Vida Digital, Carreira e Negócios de uma maneira geral. Confesso que não sei o que pode sair daqui. Talvez eu lance alguns artigos e palestras sobre alguns desses temas. Minha única certeza é que ressuscitei o GRAFFiTi para que ele possa servir como um repositório de assuntos aleatórios. Conto neste artigo um pouco das minhas intenções. Aquelas que já conheço, hehe. Ah, migrei para lá a sequência da conversa que comecei ao comentar o livro “Capital Intelectual“. Aquele papo sobre fábricas de software e coisa e tal. Está em “Cadeia, Rede ou Oficina de Valor?”

Muita coisa para uma cabecinha só? Depende: 2011 é o ano do Coelho, e Coelho é símbolo de agilidade e fertilidade. Saber aproveitar e utilizar melhor o tempo é uma qualidade cada vez mais necessária (particularmente depois de determinada idade). E, como já dizia o poeta, “Disciplina é Liberdade”. Aquele modelinho que utilizo há tempos – Lucro | Troco | Truco – ajuda bastante. O novo GRAFFiTi ainda é apenas um “truco”. Merecerá só 10% de meu tempo. O restante seguirá aqui, nos estudos, artigos e eventos do finito. Precisa dizer que seguirei contando com você? Feliz 2011. Inté!

.:.

Observações:
1. É muito difícil escrever e pensar de verdade em um “Feliz 2011” vendo o terror dos últimos dias na região serrana do Rio, em São Paulo e aqui no Sul de Minas. Entristece mais a certeza de que daqui poucos dias a grande mídia mudará de assunto (Carnaval!) e só voltará a se preocupar quando desgraças começarem a marcar o próximo verão. Quem pensa que é o “4º Poder” e que como tal tem poder de fiscalização deveria entender que é tão responsável pela inexistência de políticas de prevenção quanto os governos. Repito: tão responsável quanto. Nossa “grande” mídia não é só babona, interesseira e pobre não. É irresponsável também.
2. A imagem utilizada, No 11 – black on white, é da Kirsty Hall.
janeiro 14, 2011
Capital Intelectual
Quando publiquei minha lista com “11 Livros ‘Obrigatórios’” confessei uma dúvida: deveria colocar “A Economia da Informação“, de Carl Shapiro e Hal Varian, ou “Capital Intelectual“, de Tom Stewart. Um não serve como alternativa ao outro – eles são totalmente complementares. O primeiro, que acabou ganhando a posição na lista, fala de Economia. O livro de Stewart trata de ativos intelectuais e gestão do conhecimento. Já nem me lembro mais o critério que usei para decidir pelo livro de Shapiro e Varian. Mas desde então, folheando e relendo os dois trabalhos de Stewart, fiquei incomodado com a injustiça que cometi. Daí esta nova entrada em nossa biblioteca.

.:.

Original: Intellectual Capital (Doubleday, 1997).

Autor: Thomas A. Stewart é CMKO (Chief Marketing and Knowledge Officer) da Booz & Company. Quando publicou o livro era membro da equipe de editores da revista Fortune. Depois, entre 2002 e 2008, foi editor e diretor da Harvard Business Review (HBR). É um dos papas em Gestão do Conhecimento e um dos principais nomes da administração moderna.

Editora: Campus, 1998. Tradução (acima da média) de Ana Beatriz Rodrigues e Priscilla Martins Celeste.

Assunto (direto da orelha): O conhecimento se tornou o fator mais importante da vida econômica. É o principal ingrediente do que compramos e vendemos, a matéria-prima com a qual trabalhamos. O capital intelectual – não os recursos naturais, equipamentos ou até o capital financeiro – tornou-se um ativo indispensável para as empresas.

Relevante para:
- Todos que lidam de alguma maneira com a tal “Gestão do Conhecimento”;
- Empresários e empreendedores envolvidos com produtos ou serviços que i) são conhecimento; e/ou ii) são enriquecidos com conhecimento;
- Trabalhadores do conhecimento;
- Em suma, o livro deve servir para todo mundo.
Tenta ensinar:
- O que é Capital Humano, Capital do Cliente e Capital Estrutural;
- Como mapeá-los e gerenciá-los como Ativos de Conhecimento da organização;
- Como utilizar esses ativos para se diferenciar;
- Como lidar com aquele tipo de capital que vai embora todo dia, ao fim do expediente;
- Como o detentor daquele tipo de capital tem sua vida pessoal e profissional afetada neste ‘novo’ mundo dos negócios.
Prós:
- Texto muito bem fundamentado e amparado. Stewart não abre mão nem de citar Peter Pan ou Alice no País das Maravilhas. Ou seja, sua cultura ampla e diversificada torna o texto agradável e rico – isento de jargões e armadilhas efêmeras (lembre-se, o texto é de 1997);
- As pesquisas e estudos de caso também ajudam a apoiar o texto e a tese de Stewart;
- Não reinventa a roda: o trabalho de Takeuchi e Nonaka na área são fundamentais? Então apresente-os como tal!
- E, sempre que possível ou necessário, estenda outros trabalhos provando que você não está simplesmente copiando e colando boas ideias.
Contras:
- A Campus raramente é tão infeliz na escolha das fontes e na diagramação. Não chega a comprometer a leitura, mas fica feio pra chuchu.
- Não sei se é correto dizer que Stewart negligenciou o tema “arquitetura do negócio” (como o valor é criado – em alto nível) neste trabalho. O fato é que ele ‘corrigiu’ a falha no livro seguinte, “A Riqueza do Conhecimento” (mais sobre ele abaixo).
Gotas (de conhecimento):

“Os mercados são implacáveis. Recompensam o que cria valor e ignoram ou castigam o que não cria. Nada pessoal.”

“O Capital Intelectual é o conhecimento útil em nova embalagem.”

“As ideias são livres. são também um recurso abundante, provavelmente infinito. Qualquer pai ou mãe que já tenha deixado um filho de dois anos sozinho por um minuto sabe que ter ideias é uma característica humana inata que não requer treinamento nem educação especiais; o desafio gerencial está no desenvolvimento organizado de ideias construtivas.”

“Estamos acostumados a pensar em funcionários em termos de seu salário – seu custo. Mas qual é o seu valor? Quanto vale realmente um emprego?”

“Há um paradoxo no âmago da organização da Era da Informação: enquanto os empregadores enfraqueceram os laços da segurança no emprego e da lealdade, mais eles dependiam do capital humano.”

“Quando o conhecimento é o principal recurso e resultado – a entrada e a saída, a matéria-prima e o produto acabado – a propriedade desse conhecimento torna-se indistinta, compartilhada: o trabalhador é parcialmente proprietário, assim como o capitalista e o cliente.”

“As empresas precisam muito mais dos trabalhadores do conhecimento do que eles precisam delas.”
(Stewart citando Peter Drucker)

“Há um paradoxo na economia da informação e tanto o comprador quanto o vendedor estão sujeitos a ele: o comprador não pode julgar se vale a pena pagar por um pedaço de informação antes de possuí-la; mas, depois que a possui, ele não precisa mais comprá-la.”
(Ah, como eu gostaria que alguns prospects entendessem isso…)

“Quando se trata do trabalho criativo, não existe correlação econômica significativa entre o insumo do conhecimento e o produto do conhecimento: o valor do capital intelectual não está necessariamente relacionado ao custo de sua aquisição, o que impossibilita o uso de uma medida do que você faz como um meio de revelar como você está se saindo.”

Agora, de bons e necessários que são, vou citar dois trechos do outro livro do Stewart, “A Riqueza do Conhecimento“:

“As empresas são organismos vivos; os documentos são como defuntos.”

“Conexões primeiro, coleções depois: esta é a essência da gestão do conhecimento.”

A Riqueza do Conhecimento

Como sempre acontece, um bom trabalho puxa outro. Thomas Stewart publicou, em 2001, uma sequência obrigatória para “Capital Intelectual”. “A Riqueza do Conhecimento” (Campus, 2002) completa o primeiro trabalho, com mais casos e exemplos e, principalmente, com um fator que era mais nebuloso em 1997 (data do primeiro): a Internet (e respectivas intranets, groupwares, páginas amarelas etc). Como chamei atenção acima, Stewart também aproveitou o novo trabalho para explorar um pouco mais os modelos para criação de valor. Seu primeiro livro trabalha com profundidade as Redes de Valor. Aqui ele compara este ‘meta-modelo’ com as Cadeias e Oficinas de Valor. Este será o tema de um dos meus próximos artigos.

Aperitivo: fábricas de software (e várias outras organizações) estruturam-se como cadeias de valor. Segundo Stewart, esta é “uma metáfora tão poderosa que, por vezes, até nos esquecemos que ela aplica-se sobretudo aos contexto de fabricação e que não se adapta muito bem a muitos setores. Estendê-la a serviços, principalmente àqueles intensivos em conhecimento, pode envolver distensões, amputações e entorses tão procustianas que acabam confundindo em vez de esclarecer a situação real”. A gente vai conversar mais sobre isso. Inté!
dezembro 17, 2010
FDP – Sprint Review II
Prometi esta segunda revisão para a semana passada. Mas a agenda e o medo de que meu entusiasmo contaminasse a avaliação me impediram. Entusiasmo? Sim – o evento foi bom pra caramba! Tanto que só consegui baixar a adrenalina lá pelas duas da matina, depois de incontáveis rodadas de chopps. Agora, com o espírito crítico devidamente calibrado, tentarei escrever uma honesta prestação de contas.

.:.

Tivemos cinquenta participantes. Me lembrei das primeiras edições do FAN. Já chegamos a atender setenta pessoas, um número pra lá de exagerado em eventos desta natureza. Mas a quantidade de pessoas não comprometeu em nada o curso, pelo contrário. Criou um clima de trabalho onde todos pareciam realmente motivados. E mesmo aqueles que tradicionalmente gostam de ficar quietos em seu canto colocaram a mão na massa. Grupos de 6~8 pessoas emulavam times Scrum. E em um time Scrum é difícil alguém fingir que está trabalhando.

Comecei o evento confessando um ‘frio na barriga’ mais gelado que o normal. Era uma estreia. De um programa que fez algumas apostas arriscadas: i) ‘Esticar’ o framework Scrum de forma a contemplar as etapas de Visualização e Especulação (criação da Visão do Produto; planejamento de Releases; definição da primeira versão do Backlog do Produto); e ii) Reapresentar componentes básicos do Scrum, criticando alguns pontos dos checklists oficiais.

Não eram pré-requisitos para participar do evento o conhecimento ou experiência com o Scrum. Pouco mais da metade da plateia já trabalhava com o Scrum. Foi de parte deles que ouvi alguns “ah’s!”. Tipo: “não foi bem assim que nos ensinaram, mas acho que é disso mesmo que a gente tá sentindo falta”. Como coloquei na revisão anterior, os trabalhos clássicos sobre o Scrum partem de uma Visão pré-estabelecida. Apesar dos alertas (que não são poucos), muitos acreditam que o trabalho começa ali, traçando histórias e empilhando-as em um backlog. É preciso reforçar que um backlog frouxo, fruto de uma visão embaçada, é um dos principais suspeitos em implementações Scrum que “não vingam”.

Mas eu errei na segunda aposta. Não na reapresentação (dos componentes básicos do Scrum), mas no momento. Segundo avaliação da própria turma – ao vivo e tête-à-tête – eu deveria ter concentrado tal apresentação no início do curso, quando optei por um simples “Scrum em 15 minutos” Ao salpicar estas revisões no decorrer do curso e, principalmente, por acumular boa parte delas no finalzinho do dia, acabei quebrando o ritmo (e o clima). A turma vinha quente de três atividades consecutivas, com a mente centrada no projeto e, de repente, vê seu pique freado por uma sequência de “blá-blá-blás”. Insisto: bla-blá-blá necessário, porém mal posicionado. Mensagem que não esquecerei nunca mais: coloque toda a parte “chata” do evento no período da manhã – o pessoal prefere “chatice” concentrada do que diluída. Mas não abrem mão dela, da tal “teoria”.

Assim como não abrem mão de exemplos. Alguns participantes sugeriram a apresentação de resultados pré-elaborados. Não curto isso, porque eles são naturalmente artificiais (hehe!). Mas entendo a necessidade. E tentarei saciá-la através da demonstração dos resultados pelos próprios grupos. Contribuo mais criticando os resultados do que apresentando um só meu. O problema é o cronograma…

A outra dica / reclamação principal eu já esperava: um dia é muito pouco! Praticamente não tivemos atropelos – cancelamos apenas uma atividade prática – e todo o programa (“teórico”) foi cumprido. Eram 17h55 quando a turma foi “dispensada”. Mas ficou – se não em todos, na grande maioria – a sensação de “quero mais”. Eles queriam tempo para debater cada exercício, ver exemplos e trocar experiências entre os grupos. Apenas estes pequenos reviews exigiriam algo em torno de duas horas adicionais. Por um único motivo (custos!), meu parceiro e eu gostaríamos de manter o FDP com carga de 7 horas. Somos voto vencido. Precisarei de um tempinho para redesenhar a oficina – não gostaria de repetir a fórmula dos dois dias consecutivos já consagrada no FAN. Sei lá porque mas não gostaria.

Um ponto chamou a atenção de quem já tinha mais experiência com Scrum: a preocupação com a definição e medição do *Valor*. Em uma pequena grande série de artigos, publicada no meio do ano, eu já havia adiantado parte de minhas ideias. Surrupiei sugestões do Jim Highsmith e as misturei com técnicas que já utilizava (particularmente com a Matriz hiper-mega-super Simples de Priorização). A montagem e priorização do backlog do produto não é uma atividade trivial. Tentei mostrar como a definição do Valor e o debate sobre a complexidade ou riscos técnicos podem (ou devem) acontecer no mesmo momento e com envolvimento de todos – DP, ScrumMaster e Time – inclusive de outros representantes das áreas usuárias. Aquela tal matriz nasce neste encontro. E facilita demais a montagem de um Backlog.

Por incrível que possa parecer, a percepção do *Valor* (do que o negócio ganhará com aquele produto) parece ser difícil. A impressão que fica é que as pessoas não têm o costume de falar sobre isso. Muito menos de tratar tal definição como O fator crítico de sucesso para um projeto. Aliás, a própria definição de sucesso ou fracasso depende desta definição. Eu até tentava compreender quando notava essa dificuldade em Analistas de Negócios. Agora, falando com Donos de Produtos, a luz vermelha piscou e a sirene berrou.

.:.

A estreia do FDP ficou muito acima de minhas expectativas. Com certeza foi “sorte de estreiante”. E não tenho dúvidas de que a turma destoou: era muito boa e muito participativa. Já encontrei várias assim no FAN. E é pela experiência com ele que sei que encontrarei turmas mais arredias, selvagens, sonolentas ou simplesmente meio-desligadas. Só espero que elas não apareçam logo na segunda ou terceira edições. Prefiro encontrá-las quando a oficina estiver um pouquinho menos verde.

Assim como aconteceu com o FAN, tentarei registrar aqui todo o processo de maturação. Transparência ingênua? Não! A certeza de que só o seu feedback pode fazer o FDP amadurecer de fato. Aos que já participaram e seguirão participando meu sincero agradecimento. Inté!

.:.

Observações:
1. Cometi uma injustiça danada na lista de referências bibliográficas publicada na primeira revisão. Me esqueci de mencionar o livro “Scrum Product Ownership“, de Bob Galen (RGCG, 2009). Foram os seus escritos que motivaram e inspiraram boa parte das “licenças poéticas” do FDP. Forma, com”Agile Project Management“, de Jim Highsmith, e “Agile Product Management with Scrum“, de Roman Pichler, a base para a Formação de Donos de Produtos. Ou seja, a base (teórica) do FDP.
2. Todas as fotos publicadas neste artigo foram tiradas pelo fiel escudeiro e parceiro Anderson Oliveira, da Tempo Real Eventos. O cara tá ficando bom nisso! Outras fotos podem ser vistas no Flickr.
dezembro 7, 2010
FDP – Sprint Review I
No artigo que escrevi sobre “O Dono do Produto” prometi mostrar um pouco mais sobre a oficina “Formação de Donos de Produtos“. Vou fazê-lo em duas partes. Na próxima semana, logo após a estreia, publicarei uma prestação de contas com avaliações dos participantes. Hoje, neste primeiro Sprint Review, tentarei explicar a mecânica e filosofia do evento.

.:.

Um treinamento sobre Scrum ou fortemente baseado nele, como é o caso do FDP, deveria ser planejado, construído e apresentado como produto de um esforço guiado pelo próprio Scrum. Sem artimanhas ou enfeites baratos – ou até com alguns deles, como mostrarei na sequência – mas preocupando-se e ocupando-se com a experiência e a contínua melhoria do produto. Daí a necessidade de aparição aqui e das possíveis conversas que virão. Daí o fato da última atividade prevista, de um total de sete, ser uma revisão informal do próprio evento. As fichas de avaliação, por exigência do parceiro, seguirão existindo. Mas todos os participantes serão convidados para um Sprint Review no final do dia. Papo informal que deve escorregar para um etílico happy-hour. Mas é papo sério!

Ainda são poucos os trabalhos, livros e eventos dirigidos especificamente para os Donos de Produtos (DP’s). Meu trabalho de exploração, além das experiências práticas, se baseou principalmente em dez títulos (apresentados no final deste artigo). Como adiantei no programa e em outros lugares, esta oficina está repleta de “licenças poéticas”. Explico: apesar de respeitar integralmente as diretrizes do Scrum e práticas mais aceitas (ou comuns), precisei adaptar e incluir várias coisinhas que são ignoradas pela gramática oficial do framework.

Dediquei especial atenção ao momento inicial de um projeto. E incorporei elementos do framework APM (Agile Project Management) apresentado por Jim Highsmith no livro homônimo. As etapas de Visualização (Envision) e Especulação (Speculate) são cruciais para o DP. Mas elas são ignoradas em trabalhos clássicos sobre métodos ágeis ou mesmo sobre Scrum. A grande maioria deles parte de uma Visão já existente e não se preocupa em mostrar como ela é construída. Por isso dediquei dois “capítulos” do programa só para isso, “O Produto” e “Roadmaps, Releases, Sprints…”. Os participantes vão elaborar a Visão de um produto e derivar dela o Backlog do Produto. Das seis atividades práticas, quatro têm esta finalidade.

Outro relativo “buraco negro” da gramática oficial do Scrum é a definição do Valor: a relevância de determinada funcionalidade, requisito, história ou tarefa para o negócio ou para a realização do produto. Incorporei parte do método que sugiro no FAN, mas o temperei com o algoritmo de definição de Pontos de Valor também sugerido por Jim Highsmith. Gostei tanto da brincadeira que adaptei o Planning Poker para o debate sobre o Valor de cada item do Backlog. Os participantes ganharão um jogo de cartas personalizado. Para a definição de pontos de valor utilizamos um conjunto menor da escala de Fibonacci. Mas, como já estava com a mão na massa mesmo, fiz um baralho que pode ser utilizado no Planning Poker tradicional.

Aliás, o baralho é um dos “enfeites baratos” que citei acima. Aquilo que chamei de “Kit do DP Moderno” também é composto por fichas para anotação de Histórias de Usuários, um modelinho para especificação de Casos de Uso (mesmo utilizado no FAN), um Risque & Rabisque com um Quadro Scrum e, claro, post-it’s.

Os enfeites, que pra falar a verdade não são assim tão baratos, evitam improvisos e perda de tempo. E são ferramentas que o DP utilizará em seu dia a dia. Mas ai de quem aparecer na oficina só para ganhar brinquedinhos.

Não é fácil consolidar em um evento com sete horas de duração uma boa simulação da vida de um DP em um projeto. Só a primeira execução me dará uma boa noção da distribuição do tempo, mas eu estimo que teremos algo entre 2h30 e 3 horas de atividades práticas. É pouco, eu reconheço. E está aqui o principal ponto de extensão (para uma possível versão com carga horária maior).

Já sei que estamos com sala praticamente lotada (40+ inscritos). Levarei também alguns convidados – gente que não pisa em cascas de ovos quando vai me criticar. É um feedback mais que necessário para um evento totalmente novo. Resta torcer para que eu não tenha cometido muitos erros. Na próxima semana eu conto o resultado. Inté!

.:.

Os Principais Livros Utilizados:
- Agile Project Management – Second Edition
  Jim Highsmith | Addison-Wesley (2010)
- Agile Product Management with Scrum
  Roman Pichler | Addison-Wesley (2010)
- Kanban e Scrum – Obtendo o Melhor de Ambos
  Henrik Knibert e Mattias Skarin | InfoQ (2009)
- Succeeding with Agile
  Mike Cohn | Addison-Wesley (2010)
- Agile Estimating and Planning
  Mike Cohn | Prentice-Hall (2006)
- Coaching Agile Teams
  Lyssa Adkins | Addison-Wesley (2010)
- Subject to Change
  Peter Merholz et al | O’Reilly (2008)
- REWORK
  Jason Fried e David H. Hansson | Crown Business (2010)
- Sistema Toyota de Desenvolvimento de Produtos
  James M. Morgan e Jeffrey K. Liker | Bookman (2006)
A imagem utilizada neste artigo, “Walking in Circles“, é de HikingArtist.com.
novembro 26, 2010

Blog

?

Um Caso de Uso das Duplas

?

?

?

?

?

?

?

?

?

A Riqueza do Conhecimento