PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: BABoK

  • Os Arquitetos (de Negócios) estão Chegando

    Os Arquitetos (de Negócios) estão Chegando

    Estão chegando os arquitetos (de negócios). E a tendência (nova moda?) estava tão fácil de ser percebida que não me perdoo. Fiquei uma hora batendo minha cabeça no teclado e berrando, entre gritos de dor, “beócio! É a arquitetura (de negócios), beócio!”. Brincadeirinha. E nem posso me condenar tanto assim. Afinal, em outubro do ano passado eu já estava falando sobre Arquitetura do Negócio. O assunto estava tão gelado na época que mereceu dois comentários, além de minhas respostas. Agora, oito meses depois, acho que ele sai do frio para o morno rapidinho. Justifico minha suspeita neste artigo.

    ?

    Anteontem, dia 14/junho, o InfoWorld publicou uma lista com as seis “mais quentes” novas profissões em TI¹. Hottest job nº 1? Arquiteto de Negócios. Peço desculpas antecipadas pelo veneno que escorrerá na sequência, mas o InfoWorld não ajudou: o trabalho mais quente em TI não é de TI?!? Está lá no texto: “o arquiteto do negócio é um membro da organização do negócio e reporta-se ao CEO”. E o que ele faz? “fashionaliza (ai!) a estratégia de alto nível da empresa com a tecnologia em mente”. Perdão, mas nem o Google Translate conseguiu trazer “fashioning” para o português. E como temos vários adoradores de termos chiques e da moda aportuguesados nas coxas, porque não fashionalizar? O problema é o Tite começar a se preocupar com a fashionabilidade de seu time. Chega! Meu corretor ortográfico não suporta mais neologismos bestas.

    O advento da Computação na Nuvem (leia-se, aplicativos muito sexy e algumas vezes úteis que estão a um clique de distância) deixa gerentes de negócios com água na boca e coceira nos dedos. Por que esperar meses ou anos por um projeto da área de TI se posso contratar um serviço na Internet em questão de minutos? Segundo o artigo da InfoWorld, “o trabalho do arquiteto de negócios é armar os gerentes com o conhecimento que eles vão precisar para fazer boas escolhas “. Seria, em outras palavras, “adeus CIO, tchau departamento de TI, bye bye, so long, farewell…”? O texto não responde. Aliás, ele nem faz a pergunta. Afinal, onde entram CIO e sua área neste negócio? (Perdão pelo trocadilho).

    Quem tem ou começa a ter cabelos brancos, como este que vos escreve, já viu este filme antes. Em preto e branco, digo, em fósforo verde. Tem início lá na segunda metade dos anos 1980, quando a microinformática começou a invadir as empresas. Foi assim que nasceu o que hoje conhecemos como “planilhódromo”, outro neologismo besta que resume aquela incomensurável quantidade de planilhas eletrônicas que tapa buracos dos softwares empresariais. Aquele foi o primeiro grito de independência de nossos queridos usuários insatisfeitos com nossa agilidade em atender suas demandas. Pelo visto, a Nuvem e suas suculentas e fáceis ofertas dão argumentos para o segundo grito. Seria esta a justificativa para a “invenção” de um arquiteto de negócios? Segundo a InfoWorld, sim. Se for, salve-se quem puder. E para o mundo porque eu vou descer agora.

    Eu acho, e apenas acho, que eles acertaram o remédio mesmo com um diagnóstico muito equivocado da doença. Como escrevi naquele velho artigo, temos duas grandes motivações para desenhar e cuidar da arquitetura de um negócio: i) Entendê-lo; e ii) Avaliar a prontidão de TI (ou de qualquer outra área de apoio). E não é de hoje, nem de ontem, que tento mostrar que os analistas de negócios desempenham esta função. Querendo ou não, de forma estruturada e pensada ou não. Avaliar se determinada tecnologia, aplicativo ou brinquedinho (gadget) é adequado para um negócio é, desde o início dos tempos, uma das diversas atribuições que podem ser delegadas para analistas de negócios.

    Não tem muito tempo que inventamos o Arquiteto Corporativo. Agora, chega esse Arquiteto de Negócios. Até quando seguiremos inventando falsas especializações e acreditando que este tipo de trabalho é coisa para uma pessoa só?

    O BABoK® vem na Cola?

    Um passarinho me contou que sim². Disse que o IIBA estaria trabalhando em uma nova extensão para o BABoK, uma extensão que falaria exclusivamente sobre Arquitetura do Negócio. Outra bullshitagem passageira? Pergunto porque, um ano atrás, anunciaram uma tal “Extensão Ágil”. Depois de um comedido bafafá e um ridículo draft de 24 páginas, não vi mais nada sobre o assunto. Espero estar errado. Aquela extensão é necessária.

    Assim como é necessário que o BABoK saiba falar sobre Modelagem de Negócios. Mesmo que isso se dê pela via torta (e pelo chique nome da moda) da Arquitetura de Negócios. Só é uma pena que a comunidade de AN’s, particularmente a tupiniquim, gaste tanto tempo com picuinhas, festinhas e eventos chuchu (que repetem ad nauseam as maravilhas do BABoK). Se gastassem 10% de seu precioso tempo na evolução daquele “corpo de conhecimentos” o mundo seria um lugar melhor para se viver.

    Os Arquitetos já Estão entre Nós

    Chegaram em um dos meus clientes. Mas ele não sabia que InfoWorld e IIBA falariam sobre isso. Na realidade, por uma série de motivos, o cliente resolveu dividir o papel dos analistas de negócios em dois: Arquitetos de Negócios e Analistas de Requisitos. Os primeiros atuariam de forma mais próxima ao negócio, apoiando desde a definição do portfólio de projetos até o ponto em que um trabalho mais braçal possa ser delegado para os segundos. Não gosto do desenho, mas entendo e respeito as justificativas para ele. Como é um trabalho que mal começou, ainda não posso falar sobre os resultados. Espero poder fazê-lo em breve.

    Conclusão?

    Preciso mesmo concluir? Meu encosto-writer acha que sim. Posso dar uma de Dr. House? Então, lá vai: Se você é ou pretende ser um Analista de Negócios, então esqueça o papo sobre Arquitetos de Negócios. É só outro nome que inventaram para você que já foi, é ou pretende ser: analista de requisitos, analista de processos, analista de processos de negócios, business designer, use-case specifier, requirements reviewer etc³. Mas, atenção: siga com curiosidade e carinho tudo o que se refere a Arquitetura de Negócios. Inté!

    Observações:

    1. As outras cinco profissões também parecem ser bem divertidas. Não me segurei e as apresento brevemente, e sem tanto veneno, lá no GRAFFiTi.
    2. Apesar de confiar bastante no passarinho, fui dar uma conferida (preguiçosa) no amigo Google. Não encontrei nada sobre a extensão, mas vi muito evento do IIBA (ou de gente do instituto) falando sobre Arquitetura do Negócio. Separei dois exemplos: 1, 2.
      Ganha um picolé de chuchu o primeiro que começar a falar por aqui sobre como um AN pode “alavancar” a Arquitetura de um Negócio. Depois da crise de 2008, o termo “leverage” e seu risível correspondente tupiniquim “alavancar” deveriam ser banidos dos dicionários.
    3. Se assustou com a extensão da lista? Saiba que um dia ela já pintou, por exemplo, no RUP. E aceite que é assim, e talvez agora como Arquiteto de Negócios, que muitas empresas tratam e seguirão tratando aquela(e) que por aqui é conhecida(o) como Analista de Negócios.
    4. “sigurd lewerentz, florist, 1969“, a imagem utilizada neste artigo, é de seier+seier e foi liberada sob licença CC-by.

     

  • O Analista de Negócios Perfeito

    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.
  • Coração e Mente do Analista de Negócios

    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.
  • Um Corpo de Verdade

    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).
  • Análise de Negócios – 4 Anos Depois

    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).

  • Museu de Grandes Novidades

    Finalmente encerro a série de artigos onde tentei transcrever a palestra “O Futuro Não é Mais como Era Antigamente“. Este trabalho foi desenvolvido para o Seminário Engenharia de Software promovido pela Tempo Real Eventos. Para minha surpresa ele foi encomendado por algumas empresas, o que resultará em sua promoção para o status de Produto. Não do finito, mas de seu co-irmão que está brotando das cinzas com renovados propósitos. Assunto para outra hora.

    Hoje quero falar sobre o terceiro e último módulo daquela palestra, sobre o nosso “Museu de Grandes Novidades”. O primeiro módulo falava de pessoas e times e foi registrado aqui nos artigos “O Clube da Esquina Globalizada” e “O Cubículo Global“. O segundo tratou de tecnologias e arquitetura corporativa, tema que mereceu duas entradas: “(Pensando Alto sobre) Arquitetura Corporativa” e “Arquitetura do Negócio“. O prato quente é servido no final e o tal “Museu” foi a figura selecionada para puxar assunto sobre processos (metodologias) e projetos. Sim, eu esperava reações ruins entre as boas e indiferentes: “No size fits all!” Aliás, quem abre o tema com o slide abaixo não pode esperar coisa muito diferente, né?

    O “outras relíquias” do título indica a existência de um slide anterior. Verdadeira jóia: a certidão de nascimento do modelo ‘Cascata’. Mas, peraí: queria eu requentar debate tão chato e batido? Não era a intenção. E tento aplacar ânimos dizendo se tratar de um ‘Museu’, não de uma lixeira. Guardamos em um museu coisas que merecem ser vistas, lembradas e estudadas. Mostramos em um museu peças que têm valor. Preciso reforçar a questão que repeti várias vezes na palestra e que rotulei como ‘retórica’ (só pra tentar provar o contrário): nossas teorias (sobre engenharia de software) resistem ao confronto com as pessoas e tecnologias de hoje? Quantas ou quais sobreviveriam de fato? Minha cara e meu caro, se eu tivesse a resposta não estaria aqui, gastando o seu e o meu tempo.

    Também não se trata da elucubração isolada de um mineiro de Varginha que desfila lorotas nas horas vagas. O SEMAT (Software Engineering Method and Theory), que tem entre seus signatários algumas das pessoas que mais contribuíram com a área em todos os tempos, afirma com todas as letras em sua “chamada para a ação” que aquilo que conhecemos (conhecemos?) sobre engenharia de software encontra-se num perigoso e escuro mato sem cachorro porque:

    • Está repleta de modas e tendências, coisa que não combina com *engenharia*;
    • Está carente de uma base teórica forte e amplamente aceita;
    • Está abarrotada de métodos e variações com diferenças pouco compreendidas e artificialmente aumentadas;
    • Está pobre-pobre-pobre-de-marré-marré-marré em termos de avaliações e validações. Cada um fala que seu “método” funciona e pronto; e
    • Há uma divisão entre práticas da indústria e pesquisas da academia.

    Não consigo pensar em nenhuma outra área do conhecimento humano que tenha passado por algo semelhante. Repare bem: um grupo de pessoas que escreveu os livros e nos ensinou engenharia de software nos últimos 40 anos concordou com um diagnóstico nada favorável do nosso estágio atual. Repare também que entre os signatários existem representantes de todas as “escolas” relevantes, da extrema-direita até a extrema-esquerda. Hã.. ok. Alguns caras da extrema-esquerda que inicialmente concordaram com o diagnóstico tiraram o time de campo quando viram que o papo centro-direitista não os agradaria nem um pouco. Não importa. E também não creio que o SEMAT, pelo andar da carruagem, gere algum resultado. Mas o estrago está ou deveria estar feito. Ou alguém não concorda com o diagnóstico apresentado?

    .:.

    Definitivamente, minha intenção não é promover o bilionésimo papo besta sobre “cascateiros X agilistas”. Acontece que, tanto no evento aberto quanto em um fechado, teve gente que se sentiu pessoalmente atacada pelo conteúdo e, desconfio, pelo tom utilizado.

    Uma pessoa que participou da edição fechada desta palestra no último dia 9/11 manifestou enorme descontentamento com o evento. Detalhe: ela registrou sua insatisfação na forma de um comentário no último artigo publicado. Outros detalhes: utilizando nome falso, insinuando uma insatisfação geral e, indevidamente, registrando um link para o site da empresa contratante. Empresa que solicitou a remoção do comentário ou, no mínimo, do link que a identificava. Nunca cogitei a censura ao comentário (blog que é blog não modera nem censura). Mas, claro, retirei a referência para a empresa. Pela atenção, pelo time e pela rapidez na resposta, a empresa não merecia ver seu nome associado a comportamento tão feio e desonesto.

    Já fui atacado de quase tudo quanto é jeito pelas ideias que defendo e pelo que critico. Na grande maioria das vezes o ataque ou resposta, mesmo os mais agressivos, não é covarde. Não é anônimo. É o mínimo que se espera, certo?

    .:.

    Já escrevi por aqui que esta palestra é uma coletânea de temas que, por vários motivos, repousavam em minha gaveta. Pra ser sincero, não acreditava na viabilidade dos temas (em termos econômicos e políticos, hehe). Estouro champanhe quando erro assim. Além da apresentação para quase 100 profissionais de uma mesma empresa, ontem tive a chance de levar o mesmo papo para um território que parecia ser, no mínimo, inusitado. Ganhei um belíssimo presente da Profa. Renate Landshoff: a oportunidade de apresentar “O Futuro não é mais…”  para duas turmas do curso de graduação em Biblioteconomia da FESPSP (Fundação Escola de Sociologia e Política de São Paulo). Além da bela e antenada turma, contei com a enriquecedora presença de Sérgio Storch. Não vou tentar explicar agora o exótico mashup que se desenha. Mas algumas pistas você encontrará neste artigo da Profa. Renate (e respectivos comentários).

    “Beans“, a foto utilizada neste artigo, é de autoria de Naomi Ibuki e foi obtida no Flickr.

  • Arquitetura do Negócio

    Sequência de “(Pensando alto sobre) Arquitetura Corporativa“. Naquele artigo vimos que a arquitetura corporativa pode ser vista como um conjunto formado por quatro camadas: Arquitetura do Negócio, Arquitetura de Aplicações, Arquitetura de Informações e Arquitetura Tecnológica. Sugeri que sua elaboração só faz sentido se iniciada pela Arquitetura do Negócio. É sobre este desenho o texto de hoje.

    .:.

    A representação de um negócio, qualquer  negócio, na forma de modelos não é nada trivial. Mesmo quando pequeno e aparentemente simples, um negócio pode apresentar particularidades que dificultam o seu desenho. Não se engane: a elaboração da arquitetura do negócio é um trabalho árduo. Por isso precisamos justificá-la de maneira adequada. Quais são as principais motivações para este trabalho? Relaciono abaixo aquelas que considero mais sensatas:

    • Entender o negócio – compreender todos os seus principais componentes (recursos, processos e regras) e as forças que os definem e guiam (objetivos);
    • Avaliar a prontidão de TI – e assim justificar o desenho de toda a arquitetura corporativa. Queremos aqui mostrar o alinhamento (ou descobrir buracos) entre o negócio e todas as peças, trecos e trampos oferecidos pela TI.

    A primeira razão, “Entender o negócio”, pode ser tratada como uma iniciativa única ou espalhada em diversos projetos. Defendo que um analista de negócios entenda bem um negócio, pelo menos a parte afetada por um projeto. Só assim ele consegue contextualizar e, consequentemente, avaliar os requisitos aprendidos. Este *entendimento* se dá através de uma disciplina conhecida como Modelagem de Negócios. Se a empresa conhecer bem seu portfólio de projetos e planejar adequadamente o uso desta disciplina, ela pode elaborar gradativamente o que chamamos aqui de Arquitetura do Negócio. Devo admitir que nunca vi tal possibilidade sendo aproveitada. Sim, diariamente as empresas estão desperdiçando uma oportunidade de ouro.

    Por isso veremos um número considerável de projetos guiados pela segunda motivação acima, “avaliação da prontidão de TI”. Claro que o nome da iniciativa vai variar bastante. O termo aqui sugerido é pouco “pop” e muito comprometedor: “como assim, cara pálida, gastar dinheiro para avaliar se tu tá pronto pra me atender?!? Cê tá maluco?” O fato é que vimos surgir nos últimos tempos não só o termo e a necessidade, mas até um papel. Nasceu o arquiteto corporativo, o novo braço direito do CIO ou diretor de TI. E o que você acha que esse cara vai fazer?

    Sim, ainda são poucas (e grandes) empresas que demonstram preocupação com o tema. Mas acho que ele vai se espalhar. E isso é bom. Daí a motivação para estes dois artigos. Voltemos então ao que nos trouxe aqui: como desenhar a Arquitetura de um Negócio?

    Escrevi acima que o entendimento de um negócio significa o domínio das quatro partes principais que o definem: recursos (estrutura), processos (dinâmica), regras e objetivos. O diagrama ao lado exibe a visão de nível mais alto do “metamodelo” do qual derivamos todos os modelos de um negócio. Pois é, um negócio pode demandar vários modelos para sua correta demonstração e entendimento. Modelos ou conjuntos deles nos ajudam a montar visões, perspectivas diferentes. Podemos ter, por exemplo, um modelo que se preocupe exclusivamente com a estrutura de um negócio, seus recursos. Ou um conjunto de diagramas que trate apenas de sua parte dinâmica, seus processos.

    Recomendo o uso da EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios, para a elaboração desses modelos. Neste artigo mostro os principais diagramas que podem ser elaborados através desta linguagem. Quero dizer, então, que a Arquitetura de um Negócio é representada por um conjunto de diagramas. E que estes diagramas são estruturados em visões. Mas eu tenho um probleminha.

    Falta naquela proposta um diagrama-sumário, um modelo que represente em apenas uma página a visão geral do negócio. Normalmente eu desenho (e recomendo) um grande mapa de processos. Consigo representar neste tipo de diagrama todos os elementos fundamentais de um negócio. Mas eu não consigo explicar, não sem um certo esforço, o negócio em si. Aqui é importante lembrar o estágio em que se encontra esta disciplina que chamamos de Modelagem de Negócios. Ela está renascendo. De certa forma, podemos dizer que está sendo redefinida. Este artigo ilustra um pouco o surreal (e interessante) momento atual¹. Acontece que nenhuma das duas obras comentadas no artigo apresentam uma solução para meu probleminha. Relembrando: precisamos de um modelo que explique um negócio da mesma forma que um A3² explica e justifica um projeto, em uma folha apenas. Mas não se trata da concisão pela concisão. Esta “folha” deve ter uma lógica de leitura, uma estrutura bem definida. E deve, acima de tudo, explicar um negócio.

    Encontrei em outro livro “estranho” uma possível alternativa. Estou falando de “Business Model Generation”, de Alexander Osterwalder e Yves Pigneur (publicação própria, BusinessModelGeneration.com, 2010). Um dos elementos do método proposto no livro é o Canvas, que vou adaptar aqui para tabuleiro. Não é tradução e sim uma adaptação, ok? Tabuleiro porque é onde colocamos as peças do jogo. Em nosso caso, do jogo do negócio. O tabuleiro não é um metamodelo nem uma alternativa para a EPBE/UML. Trata-se apenas de um modelo. Mas não interprete mal o ‘apenas’. É um modelo que pode sintetizar ou até mesmo guiar a elaboração de outros modelos. Vamos dar uma olhada no tabuleiro vazio.

    No centro do tabuleiro colocamos a proposição de valor do negócio, o que ele está prometendo para seus clientes. No lado esquerdo colocamos as peças que os autores remetem ao lado esquerdo do cérebro – aquilo que deve ser otimizado. Estão ali seus parceiros, processos e recursos principais, além da estrutura de custos. Concluímos então que o lado direito do tabuleiro representa a mesma porção do cérebro, mais quente e subjetiva – mais criativa. Ficam ali as quatro áreas que completam o tabuleiro: clientes, relacionamento com clientes, canais e fontes de receitas.

    Conseguimos mostrar ou entender um negócio através do tabuleiro? Sim, e os exemplos do livro – mostrando empresas como Apple, Amazon, Google, Procter & Gamble e Gillette, dentre outras – não deixam dúvidas quanto a isso. A ferramenta parece ser útil tanto para o desenho ou redesenho de um negócio existente quanto para a elaboração de um negócio totalmente novo. No processo sugerido, o tabuleiro seria desenhado em um quadro branco ou equivalente e preenchido com post-it’s ou desenhos. Estou usando termos condicionais ou dizendo que “parece ser útil” porque, a exemplo do que ocorreu com o método do Pensamento Visual um ano atrás, ainda não tive a chance de testar a nova ferramenta. Testá-la em campo. Porque desenhei o modelo do finito em poucos minutos e me diverti bastante. Mas este tipo de teste não conta. Espero em breve poder transcrever aqui outros testes e explicar melhor o uso do tabuleiro.

    Por enquanto, como de costume, não posso deixar passar alguns “poréns” ou possíveis correções. No meu modo de entender não basta a fixação da proposição de valor de negócio. O entendimento de sua motivação é crucial. Por isso eu colocaria naquele espaço central a visão, os grandes objetivos do negócio (e respectivos prazos) e também a missão da empresa (caso não esteja redundante com a proposta de valor). Também é cara ao processo de entendimento uma classificação mínima dos processos principais. Quais são primários, de apoio ou de gestão? Aliás, me parece que o espaço dedicado para processos e recursos é muito pequeno. Mas, enfim, apenas um bom volume de testes pode confirmar a utilidade da ferramenta e possíveis correções ou adaptações.

    Agora devemos retomar o ponto principal: este desenho, o tabuleiro, pode representar a arquitetura do negócio? Pelo menos em parte, sim. E tal possibilidade é sugerida no livro, na seção “Outlook – Aligning IT with Business” (pág. 272). Em relação ao sanduíche sugerido no artigo anterior o livro só não considera a Arquitetura de Informações (pelo visto, combinando-a com a Arquitetura de Aplicações). É uma pena que o livro dedique apenas duas páginas ao tema. Mas, claro, não era seu foco. Fica com a gente então o trabalho de testar a sugestão e, se for o caso, implementá-la. Tentarei fazer minha parte aqui. Inté!

    .:.

    Observações:

    1. Surreal? Sim, tanto que o BABoK 2.0, lançado no ano passado, ignora por completo a existência de uma disciplina chamada Modelagem de Negócios. Todas as obras citadas neste artigo e artigos relacionados sinalizam o renascimento da disciplina. O que nos permite concluir que o BABoK comeu bola. Ou você acredita que o assunto não interessa aos analistas de negócios?
    2. O “A3” é uma ferramenta criada na Toyota para solução de problemas. O nome vem do tamanho do papel utilizado na sua elaboração. Oportunamente mostrarei como ele pode completar ou até mesmo substituir o documento de visão de um projeto.

  • Identificando Partes Interessadas, Interesseiras, Indiferentes e Encrenqueiras

    Ao seguir o método do Pensamento Visual, a segunda¹ questão que o analista de negócios deve responder é “Quem / O quê?”. A pergunta é repetida n vezes se o analista trabalha de forma iterativa e incremental. Mas desde as primeiras ocorrências ele deve se preocupar em identificar todas as partes interessadas – as pessoas que terão algum tipo de relacionamento com o projeto ou seu produto. Este artigo é sobre o processo de identificação e ferramentas que podem ajudar analistas e equipe a gerenciar o relacionamento com clientes e usuários.

    Um dos problemas mais frequentes e irritantes com requisitos é a sua não estruturação. Eles são listados de maneira ad hoc em documentos de texto, cartões ou planilhas eletrônicas e carecem de mínimos atributos que os qualifiquem. Uma das informações essenciais para a contextualização de um requisito é sua origem, sua fonte. Quem pediu? É claro que não basta registrar o nome da pessoa e sua posição na empresa. Por isso a correta identificação de todas as partes interessadas de um projeto é tão cara para a Análise de Negócios.

    Cara e complexa, porque a identificação não será produto da aplicação de um simples questionário ou check-list. A equipe, particularmente o analista de negócios, dependerá de seu poder de observação para identificar, avaliar e classificar cada pessoa envolvida com o projeto. Algumas informações serão fornecidas naturalmente, logo no primeiro momento. Outras aparecerão com o tempo, através da convivência (atenta e atenciosa). O mínimo que se espera de um Mapa de Partes Interessadas² é uma tabela com os seguintes atributos:

    • Papel / Função na organização;
    • Papel no projeto. Podemos completar esta informação com a Matriz RACI sugerida no BABoK:
      • esponsável – executa o trabalho;
      • ccountable – tem a última palavra (só deveria existir uma pessoa com tal poder);
      • onsultado – deve ser ouvido pela equipe;
      • nformado – deve ser comunicado sobre o projeto e algumas decisões.
    • Impacto que o projeto terá no dia a dia da pessoa. Pode ou deve ser simples como Alto, Médio, Pequeno e Nenhum;
    • Influência que a parte interessada exercerá no projeto. Pode usar mesma classificação sugerida acima;
    • Receptividade ao projeto: Contrário, Indiferente, Favorável ou Entusiasmado;
    • Razões para a resistência ou apoio.

    As três primeiras informações podem ser obtidas logo no primeiro momento. Elas devem compor aquele grande mapa que chamo de ‘fotografia com 2km de extensão e 2cm de profundidade’. As outras três informações – Influência, Receptividade e Razões – só surgirão com razoável confiabilidade no decorrer do projeto.

    É interessante notar que o Mapa das Partes Interessadas, quando completado com os últimos três atributos, é um dos únicos artefatos do tipo ‘caixa preta’ de uma equipe de projetos. Ou seja, ele deve ser confidencial. Não interessa a mais ninguém as percepções e cuidados que a equipe tem com cada pessoa envolvida.

    Sim, o mapa servirá para que a equipe saiba com quem está falando e evite riscos de mal entendidos ou até mesmo de conflitos. Sejamos mais visuais. A matriz ao lado sintetiza três informações fundamentais para que uma equipe gerencie seu relacionamento com as partes interessadas. O eixo X indica o Impacto que o projeto terá na vida das pessoas envolvidas. No eixo Y demonstramos a Influência que cada pessoa terá sobre o projeto. E quatro ícones ilustram a Receptividade de cada um ao projeto.

    O gráfico indica, por exemplo, que Joaquim e Carlão são contrários ao projeto. Pode ser por resistência às mudanças ou gosto de ser encrenqueiro. Joaquim pode exercer forte influência no projeto, o que o torna fonte de potenciais problemas. Apesar do pequeno impacto que o projeto terá em seu cotidiano. A equipe deve ‘pisar em cascas de ovos’ quando se relacionar com ele. Carlão, por outro lado, não tem tanta influência assim. Mas terá sua rotina muito impactada pelo projeto. Merece especial zelo quando entregas forem realizadas.

    Três pessoas, José, Dedé e Terezinha, são favoráveis ao projeto. José será muito impactado e terá forte influência no projeto. Dedé será muito impactado, mas não apitará nada. E o apoio da Terezinha pode ter efeito moral, mas nenhum benefício prático: ela tem muito pouco a ver com o babado. Quase como o Euclides, que se mostra indiferente. O que não fará muita diferença. Já a indiferença do Tonho deve ser percebida pela equipe com preocupação. Afinal, ele pode exercer forte influência e será muito impactado. Qual a razão de sua indiferença? O que pode motivá-lo? São questões que deveriam preocupar a equipe, particularmente o gerente do projeto e os analistas de negócios.

    Assim como Magda e João, entusiasmados com o projeto. Magda tem pouca influência, mas o João é relativamente influente. A equipe deve tratá-los como aliados e fazer de tudo para não desagradá-los. Afinal, seu entusiasmo pode contagiar outras partes interessadas. O que nos leva para outra questão: quais são as relações entre os envolvidos? Quem influencia quem? Se o número de pessoas envolvidas no projeto for relativamente grande, talvez se justifique a elaboração de um Mapa de Relacionamentos, como mostra o diagrama ao lado. Nas linhas indicamos o poder de influência de cada pessoa sobre as demais. Ele pode ser: Forte, Médio, Pequeno ou inexistente (“-“).  Vemos, por exemplo, que Euclides e Terezinha não influenciam ninguém. E que a Maria, que não é influenciada por ninguém, tem poder sobre todo mundo. Então ela não pode permanecer tão indiferente (alienada) em relação ao projeto, certo?

    Carlão e Joaquim são contrários ao projeto. É importante que a equipe saiba ‘blindar’ de alguma maneira todas as pessoas que estão em seu círculo de influência. Deve preocupar, principalmente, que Magda e Dedé não se deixem levar pelo pessimismo ou possível jogo sujo do Carlão.

    É claro que estou brincando com a simplicidade. Relações humanas são de uma complexidade absurda e nunca serão resumidas em uma ou duas matrizes. Mas isso não pode significar que a equipe se isente de sua responsabilidade de gerenciar o relacionamento com todas as partes interessadas. É sabido que boa parte dos problemas que ocorrem em projetos derivam de deficiências na comunicação e conflitos de interesses. As ferramentas aqui sugeridas podem ajudar equipes a cuidar melhor de suas relações com clientes e usuários. Faz bem ter a resposta na ponta da língua toda vez que alguém perguntar: Você sabe com quem está falando?

    .:.

    QuiProQuó

    Aproveitando os exemplos acima, alguns desafios:

    1. Das dez pessoas apresentadas qual seria o melhor candidato para a função de Dono do Produto (Product Owner) caso o projeto seja guiado pelo framework Scrum? Por quê?
    2. Há um conflito de informações entre as duas matrizes apresentadas. Qual é o conflito e qual a possível razão da inconsistência?
    3. Qual diagrama pode ilustrar e complementar a Matriz de Relacionamentos?
    4. Quais quadrantes podem significar requisitos mais ricos? Por quê?
    5. Seria a Magda carente ou influenciável demais?
    6. O que é que o Euclides tá fazendo no projeto?!?

    Observações:

    1. No método original, “Quem / O quê” é a primeira e não a segunda pergunta. Na adaptação que fiz para a Análise de Negócios transportei “Por que” para o início do questionário. Quer saber por quê?
    2. Mapa de Partes Interessadas?!? Pois é, o nome é ridículo. Sugestões?
    3. “Key-People” é o cartoon do HikingArtist.com utilizado hoje.

  • Muita Areia no Caminhãozinho do AN

    De todas as sugestões que apresento no FAN, a que causa mais espanto e suspiros é: um analista de negócios (AN) não deveria cuidar de mais de dois projetos ao mesmo tempo. Dois projetos pequenos! Invariavelmente a casa cai neste momento. E o burburinho parte, principalmente, de profissionais que atuam em médias e grandes empresas. Alguns deles são responsáveis por 10 ou mais projetos. Maluquice pura.

    Não entendo como eles podem tocar tantos projetos simultaneamente. E, considerando que essas empresas contam com algumas dezenas de AN’s, não entendo como elas conseguem disparar e cuidar de tantas iniciativas.

    O burburinho vira debate quando emendo uma segunda recomendação: AN’s deveriam trabalhar sempre em duplas. Uma rápida conta de padaria, que tanto caracteriza a matemática dos novos tempos, deve deixar todos aturdidos: “Hoje tenho 100 projetos e 10 AN’s. Você está sugerindo que eu contrate 190 analistas?!?” Isso sim seria uma bela política para geração de (bons) empregos. Mas reconheço sua inviabilidade.

    É fato que a sobrecarga insana de trabalho não é um privilégio dos AN’s. Infelizmente, é outra característica do século XXI. Mas ninguém deveria aceitar isso como um fato consumado e pronto. No caso específico dos AN’s não é difícil descobrir e tentar corrigir as razões de tanto trabalho¹.

    Em primeiro lugar é preciso dizer que nenhuma empresa tem tantos projetos assim. Projetos, com ‘P’ maiúsculo, devem representar apenas algo entre 10% e 20% de toda a demanda. O restante trata de alterações ou evoluções em soluções existentes, nos famigerados sistemas legados. E por que as empresas estariam utilizando analistas de negócios para cuidar de solicitações de manutenção em aplicações?

    Uma desculpa razoável seria a competência desses profissionais para o desenvolvimento de requisitos. O que muitas organizações não entendem é que não existem, na grande maioria dessas solicitações, requisitos. Não no sentido de existirem necessidades verdes o suficiente para justificar todo o processo de maturação intrínseco à Análise de Negócios. Noventa e tantos por cento das novas necessidades dos usuários são simples e diretas, como por exemplo: “coloca um novo campo assim nesta tela”. Gastar AN’s com solicitações dessa natureza é um belo desperdício.

    Sabe-se lá por que cargas d’água inventaram um novo nome para atendentes de help-desk. Sim, porque solicitações de manutenção deveriam ficar no âmbito daquele grupo que um dia batizamos “help desk”.

    Ouço de algumas empresas que parte das solicitações tem real necessidade de Análise do Negócio. Ok, mas quantas? Duvido que sejam 10% delas. E insisto: é desperdício. Mas entendo: começaram a colocar AN’s para desempenhar essa função na vã esperança de melhorar um cadinho a qualidade do atendimento. Acontece que a solução virou um tiro de bazuca no pezão: AN’s estão aprendendo a desenvolver um monte de coisa. Leem o BABoK ou participam do FAN e absorvem dezenas de ferramentas que podem tornar seu dia a dia menos desagradável. Pena que sejam coisas que agregam muito pouco ou nada quando o trampo é só de manutenção de sistemas. Pior: são coisas que custam tempo e dinheiro.

    Uma grande, imensa empresa tupiniquim se prepara para experimentar um novo desenho. Deve instituir a figura dos Analistas de Demandas ou algo parecido. Seria o meio termo entre analistas de negócios e atendentes de help-desk. Não sei se a solução não deveria ser simplesmente uma melhor preparação do pessoal de suporte. Uma preparação que passasse obrigatoriamente pela especialização. Por exemplo: o cara que atende chamados sobre impressoras não pode ser o mesmo que recebe solicitações para o SAP/R3. Parece óbvio, mas não é tanto assim em alguns lugares que conheço.

    Não há processo ou ferramenta que substitua um simples “Não!”

    Um segundo fator que contribui muito para a sobrecarga de AN’s é a incapacidade que algumas organizações têm de falar “Não”. Em tempos de nervos à flor da pele, competição interna sanguinolenta, políticas demasiadamente corretas e grave miopia onde deveria existir só *Visão*,  a impressão que fica é que todas as demandas e projetos são prioritários, vitais e pra ontem. Uma peneirinha meio esburacada já ajudaria muito. Gastamos tanto com soluções para gestão de portfólios, PMO’s e afins, e seguimos sem a mínima capacidade de dizer qual projeto merece mais atenção e recursos. Enquanto uma organização não aprender a colocar suas iniciativas e demandas em uma fila indiana (uma atrás da outra, sem exceção) ela seguirá com a sensação de sempre ter mais trabalho do que recursos disponíveis para executá-lo².

    Justificando as Sugestões

    “Que tal sugerir que cada dupla de AN’s tenha um mordomo ao seu dispor?” Já ouvi algo parecido, de um colega que interpretou de maneira um tanto precipitada minhas sugestões. Não defendo sombra e água fresca para AN’s. Apenas insisto que eles não conseguirão provar seu valor se: i) Trabalharem em mais de um projeto (ou dois projetos pequenos); e ii) Não trabalharem em duplas. Por favor, me permita justificar.

    Defendo que todo projeto de software seja desenvolvido seguindo um modelo Iterativo e Incremental. Deve estar implícita nesta sugestão a necessidade dos AN’s permanecerem no projeto do primeiro até o último dia. E, a menos que o projeto seja pequenininho, é impossível que os AN’s cuidem (bem) de mais de um. Repito: impossível.

    Pense nas principais tarefas desempenhadas por um AN: entender um negócio e determinado problema ou oportunidade; e entender o usuário, suas necessidades e restrições. Ambos “entendimentos” ocorrem simultaneamente, em diversas situações. Vamos simplificar e usar o modo mais corriqueiro: o AN entrevistando um usuário. Ele deve prestar atenção em seu interlocutor e conduzir a entrevista. O “olho no olho” é importante, assim como a leitura de sinais, caretas e tiques. A explicitação da conversa, seu registro na forma de diagramas, especificações de casos de uso etc, é igualmente importante. E demanda a mesma fatia de atenção. Como um AN pode desempenhar bem, simultaneamente, duas funções tão distintas?³

    Já experimentei de tudo para substituir a explicitação anotada: gravação de áudio, vídeo etc. Nada substitui uma segunda cabeça. Ao término de uma entrevista, no momento da análise dos requisitos aprendidos, ela completa o entendimento, ajuda a destacar pontos obscuros e dúvidas. Enfim, duas cabeças sempre serão melhor que uma.

    Outra justificativa para o uso de duplas é o melhor aproveitamento das habilidades de cada um. Tem analista que parece ter nascido para a socialização: é bom de papo, transmite segurança e sabe lidar com usuários e clientes. Outros são talentosos na redação e desenho. É relativamente raro encontrar um AN que faça muito bem as duas coisas. Como é impossível que ele faça bem as duas coisas simultaneamente, por que não equipá-lo com seu par ideal?

    Eu sei, a implementação dessas sugestões tem que entrar na fila. As empresas que pretendem obter o máximo da Análise de Negócios devem ter outras prioridades: i) Aprender a dizer “Não!”; ii) Colocar os projetos em fila indiana; e iii) Separar o hoje (operação) do amanhã (projetos). E não é que a Análise de Negócios pode ajudá-las até nisso? Bom, acabei de arrumar mais areia para os abarrotados caminhõezinhos dos AN’s. Inté!

    .:.

    Observações:

    1. Eu quis dizer que a identificação dos problemas é fácil. Sua solução, nem tanto.
    2. Perguntinha retórica mas necessária: capacity planning só vale para máquinas?
    3. Vira e mexe me deparo com uma solução curiosa: o AN diz que anota tudo rapidinho, priorizando o contato “olho no olho” com o usuário ou cliente. Depois volta para casa e “passa tudo a limpo”, inclusive escrevendo os casos de uso. Esforço total: 4 horas, por exemplo. Se ele tivesse um par que o isentasse da anotação, ciente de que “passar a limpo” é desperdício e que especificações de casos de uso são construídas na frente do usuário, consumiria as mesmas 4 horas.
    4. A imagem utilizada, “Colorful toy trucks parked in a circle“ é de Horia Varlan e foi obtida no Flickr.

  • O Mundo Mudou

    Terceira parte da nossa conversa sobre “O Novo Gerente de Projetos”.

    O mundo mudou. E não me lembro qual foi a última vez que utilizei um título tão “fraquinho”. Como o antecipei nas duas partes anteriores, seguirei com ele.

    O mundo muda todo dia. Em negócios e TI a impressão que temos e deixamos é de uma dinâmica quase caótica. Uma volatilidade que, segundo experts, gera uma população repleta de pessoas inseguras, ansiosas e desconfiadas. Não raro, exageramos os possíveis impactos de determinado acontecimento. Outras tantas vezes subestimamos tendências. Como a imensa maioria das pessoas é desprovida de dons proféticos e bolas de cristal, é natural que seja assim. Como é normal que indivíduos apresentem reações muito diferentes quando defrontados com uma mesma mudança. Mas o papo aqui é ou deveria ser sobre projetos e seus gerentes.

    Projeto é mudança. Talvez esta seja a verdade absoluta mais ignorada ou desprezada. Quando uma organização dispara um projeto ela está implementando uma mudança. Aqueles que foram selecionados para o trabalho devem estar preparados para lidar com todos os reflexos gerados por ela. Esses reflexos, com maior ou menor intensidade, fazem com que os projetos sejam naturalmente instáveis. Ainda bem que eles têm data para acabar, não é mesmo?

    Porque é natural do ser humano o gosto ou necessidade de estabilidade. Mesmo aqueles viciados em adrenalina, como os praticantes de esportes radicais, valorizam muito os períodos de calmaria. O fato é que estabilidade perene apenas é possível em processos – em ações que repetimos ad infinitum. Projetos são únicos em seus objetivos e restrições. Eles sempre são inéditos de alguma maneira. Por isso é estranha uma certa obsessão por projetos estáveis. Surrupiando um dito de Michael Hammer¹, “projeto instável” é um oxímoro em vias de se tornar um pleonasmo. Por isso é equivocada a crença em planos. Ou, melhor dizendo, a crença na certeza dos planos. Mas, antes de “atacar” os planos (se é que vou fazê-lo), vamos falar sobre a crença. De onde ela vem? O que a alimenta?

    Durante muito tempo jogamos praticamente todas as nossas fichas em padrões e metodologias que, de uma forma ou de outra, prometem estabilidade e previsibilidade. Apesar das promessas raramente cumpridas, particularmente em projetos de TI, essas propostas se espalharam como notícia ruim. As falhas, quando reconhecidas, raramente eram atribuídas aos padrões e metodologias adotados. Quase sempre a culpa é de quem os implementou. Mercados foram criados em torno dessas propostas. E elas se solidificaram. No mau sentido.

    Temos hoje um imenso “sistema legado” de processos de gerenciamento e desenvolvimento. Usei o termo “sistema legado” exatamente porque ele nos remete aos nossos legados mais famosos – igualmente caros e não muito “simpáticos” a mudanças. O “sistema” que aqui trato é composto por treinamentos, certificações, ferramentas, corpos de conhecimento e, principalmente, cultura. Ou, para voltar ao termo utilizado anteriormente, crença.

    Em determinado momento da história alguns componentes do “sistema” se iludiram com sua pretensa estabilidade. Algumas palavrinhas que guiam os tempos modernos, como inovação e criatividade, são simplesmente ignoradas pelo “sistema”. O próprio sentido de mudança e o entendimento de que não se trata de algo indesejável, mas necessário e inevitável, não encontra respaldo real em algumas das peças mais relevantes do “sistema legado” de processos de gerenciamento e desenvolvimento.

    Seria então o caso de jogar todo o “sistema” no lixo? Claro que não. Sugestões assim são ingênuas (mas pouco inocentes). Ingênuas por não perceberem que o “legado” criado, assim como seus pares, é complexo e caro, mas não deixa de ter seu valor. Acredito que, de todos os seus componentes, o primeiro a ser questionado deveria ser a crença ou cultura. Questão de coerência: como um gerente de projetos – um profissional especializado na implementação de mudanças – pode resistir tanto em mudar?

    Ao questionar a crença, ao adotar um perfil mais cético, o profissional tomará os outros componentes do sistema com outros olhos. Ele tenderá a ser mais cuidadoso e desconfiado. Mas será também mais curioso.

    Não se iluda. Mudar cultura ou questionar a crença não é nada fácil. Também não é algo que possa ser implementado como um projeto. Mas é fácil apontar a trilha. Aliás, é até meio besta: 1) Aceitar que mudanças são inevitáveis; 2) Questionar certezas absolutas; e 3) Não ter medo do novo e muito menos de aprendê-lo.

    O Argumento Derradeiro

    Há poucos dias, Scott Berkun, autor de “A Arte do Gerenciamento de Projetos” (Bookman, 2008), retomou um tema que vou traduzir da seguinte maneira: Gerenciamento de projetos é chato? Berkun responde que “o gerenciamento de projetos é tão chato quanto a coisa que está sendo gerenciada”. Por favor, me desculpe a chatice, mas releia a frase negritada.

    Em um artigo anterior Berkun já havia comentado sua impressão de que o Gerenciamento de Projetos não é muito respeitado. E, em outras palavras, não é uma função ou profissão sexy, atraente. Você não vê nenhuma criança ou adolescente dizendo: “Quando eu crescer quero ser gerente de projetos”. Mas Berkun argumenta que diretores de cinema, técnicos de futebol, produtores de discos e várias outras profissões são variações de gerentes de projetos. A diferença é que eles usam outros termos. Nomes que tornam explícita a coisa que gerenciam. E fazem daquela função algo mais atraente, com certeza.

    Me lembro quando chegou a hora de definir minha profissão. Meu velho, como de costume, deu um conselho rápido e nada rasteiro: “Escolhe qualquer coisa, menos contabilidade”. Ele era contador. Dos bons, diga-se de passagem. Trabalhava 30 horas por semana e fazia de tudo para tornar sua rotina menos chata. Mas ele sabia que estava aprisionado em uma função que é, por natureza, 90% do tempo enfadonha.

    Gerenciamento de projetos pode ser tudo, menos chato. Mas, por incrível que pareça, conseguimos torná-la uma profissão dura e carrancuda. Quadrada mesmo. E me parece claro que os ângulos retos de todos os componentes do nosso “sistema legado” são os maiores responsáveis por isso.

    .:.

    Nome aos Bois e Pingos nos ‘is’

    Ao bom entendedor que por aqui navega ficou claro que dentre os componentes do “sistema legado” tratado acima figuram: PMBoK, CMMI, Prince2, MPS.br, ITIL, afins e derivados. Manada devidamente nomeada, resta agora esclarecer alguns pontos:

    • PMBoK e BABoK não tratam de nenhum tipo específico de projeto. Então, pode parecer equivocada uma crítica que considere apenas projetos de TI. Não na minha opinião. Ainda avalio se vale a pena um artigo sobre “O Problema com os BoK’s”. Vale a pena ou a espada?
    • Não estarei aqui para ver a aposentadoria do “sistema legado”. Ele resistirá e sobreviverá por um bom tempo. A torcida, de certa forma otimista, é para que ele encontre e beba de um tipo de fonte da juventude. O tipo de ‘service pack’ que o BABoK receberá, por exemplo², é uma de várias possibilidades de rejuvenescimento. Os únicos pré-requisitos são humildade e olhos e ouvidos abertos.
    • Por ser longevo, o “sistema legado” não pode ser ignorado por nenhum profissional razoavelmente sério. Há muito conhecimento ali.
      Mas é um pecado iniciar a profissão pelo lado quadrado da força. Quem quer iniciar uma carreira em gerenciamento de projetos deveria, antes de qualquer coisa, estudar alguns documentos que ainda são meio “apócrifos”. Eu iniciaria por “A Arte do Gerenciamento de Projetos” (Scott Berkun. Bookman, 2008) e “Agile Project Management – Second Edition” (Jim Highsmith. Addison-Wesley, 2010). Necessariamente nesta ordem. Eu não tive essa sorte. Mas também não virei contador³.

    .:.

    Observações

    1. Michael Hammer utilizou aquela frase para falar sobre mudanças corporativas. A original é: “Mudança corporativa é um oxímoro em vias de se tornar um pleonasmo“.
    2. Em dezembro fiquei sabendo que o IIBA está preparando uma “Extensão Ágil” para o BABoK. Quem viu a “Leitura Crítica” que fiz já sabia que era uma correção mais que necessária. Apesar da tentativa da versão 2.0 em atender os mundos “Plan-Driven” e “Change-Driven”. Mais do que qualquer coisa, devemos elogiar a humildade e iniciativa do IIBA.
    3. Por favor, prezados contadores, não me levem a mal. Além do meu velho, tenho vários outros parentes que assumiram e gostam desta honrosa profissão. Só não dá para discutir o fato dela ser  90% do tempo chatinha. Sabem o que meu velho fazia quando queria um pouco de diversão? Pegava a contabilidade de uma empresa pra lá de enrolada com fisco e afins. Ou então contratava o filho para desenvolver o sistema de contabilidade daquela empresa encrencada. Pois é, eu não estaria aqui se não fosse a contabilidade.
    4. O desenho utilizado neste artigo, flikr0675, é do flikr.