finito

Tag: Alinhamento

  • Grandes Times de Verdade

    Grandes Times de Verdade

    Há boa ciência por trás dos grandes times. Existem princípios que guiam o desenho e a evolução de times de verdade. É um trabalho sem atalhos. Passa longe da simples imitação de um modelo – seja o modelo Spotify ou qualquer outro. É um desafio que vale a pena porque times de verdade não enganam nem enrolam, eles entregam valor de verdade. 

    De Verdade

    “De verdade” se tornou um sobrenome necessário porque vulgarizamos a palavra “time”. Qualquer grupo de pessoas é tratado como time. Não é bem assim. 

    O primeiro requisito crucial para a formação e identificação de um time é um objetivo. Apesar de seus diversos interesses – e é importante que um time seja formado por pessoas com interesses diversos¹ – os integrantes do time compram a mesma briga. Isso não se dá de imediato. Em um mundo cada vez mais complexo, objetivos quase nunca são cristalinos nem unânimes. A definição do problema – do objetivo – é parte do problema. E é o primeiro passo para a formação de um time. 

    Buscamos a cooperação – o pleno acordo em relação aos fins e aos meios para alcançá-los. Mas sabemos que a competição, agora e em outros momentos da iniciativa, é mais que necessária. Porque só assim podemos explorar a melhor maneira de realizar aquele objetivo. Da matriz ao lado, o único quadrante que deve incomodar, ainda mais quando recorrente, é o conflito. Os demais fazem parte do dia a dia de um time saudável².

    Um time de verdade não se caracteriza apenas por buscar e alcançar os objetivos – por realizar resultados. Isso um bando (pseudo-time) consegue fazer, mesmo que de vez em quando. Em times de verdade há relacionamentos saudáveis e motivadores. Ou seja, nesta matriz, apenas um quadrante nos interessa. Não queremos estar em alianças temporárias – onde todos os comparsas se dão muito bem e entregam muito mal – e muito menos em celas.

    Por entregar resultados enquanto nutre bons relacionamentos, um time de verdade tende a desenvolver uma identidade única. Às vezes ele ganha até nome, marca e mascote. No entanto, a identidade que interessa – a que fica – geralmente é a sua principal característica: entregador, cascudo, corajoso, atencioso, maduro e por aí vai. 

    Este é o primeiro CDP (Core Design Principle) ou Princípio Fundamental para o desenho de times: Forte identidade e senso de propósito. 

    Princípios Fundamentais

    Elinor Ostrom³, Nobel de Economia em 2009, encontrou em um conjunto com oito princípios uma resposta para a Tragédia dos Comuns4. Estamos começando a descobrir que esses princípios podem explicar a diferença entre times bem e mal sucedidos5. Um time aumenta suas chances de sucesso se:

    1. Desenvolver uma forte identidade e senso de propósito
    2. For justo no rateio de benefícios e custos
    3. Tomar decisões de forma justa e inclusiva
    4. Monitorar o comportamento que foi acordado de antemão
    5. Aplicar sanções progressivas 
    6. Sanar conflitos de maneira rápida e justa
    7. Contar com autonomia local
    8. Tiver a garantia de que todos os demais times e níveis da organização utilizam os mesmos princípios de governança listados acima

    Cada princípio será detalhado oportunamente6. Neste momento é interessante destacar o seguinte: Os princípios 1~6 tratam das questões internas de um time; os princípios 7 e 8 tratam da relação do time com a organização e demais equipes. 

    Releia a lista de princípios fundamentais com calma, por favor. É importante.
    Obrigado.

    Repare como o CDP#7 – contar com autonomia local – é chave. Porque é o grau de autonomia conquistado pelo time que vai guiar a configuração de todos os CDPs anteriores. Autonomia não é carta branca. A auto-organização não acontece quando fronteiras não são definidas. Ou seja, a organização propõe ou impõe limites. A partir deles, cada time desenvolve sua própria cultura – seu jeito de fazer as coisas. 

    Existem três fatores principais delimitando o grau de autonomia que será oferecido aos times. O primeiro é subjetivo: confiança. Cabe aqui um pitaco direto de Hemingway: “Só há uma maneira de saber se você pode confiar em uma pessoa: confiando nela.” Se vale pra gente, vale para times.

    Os outros dois fatores são objetivos: as necessidades de integração e padronização da organização. O grau de autonomia possível é inversamente proporcional à essas necessidades. Considere, por exemplo, quanta autonomia há em uma agência bancária. Ou até onde vai a liberdade de um squad do Spotify ou de um time do Google para escolher ou criar as suas próprias ferramentas. 

    Um time de verdade sabe de cor e salteado o que busca. Ou seja, seu alinhamento é total. Ele estará no quadrante A ou B da matriz ao lado, dependendo da cultura e das necessidades da organização. Que fique claro: um time de verdade sempre persegue o espaço A. Porque é sinceramente comprometido com a melhoria contínua. Mas ele compreende e aceita eventuais restrições. 

    Um time de verdade exala maturidade. Tema do próximo post. Até lá!

    Notas

    1. Porque, como já vimos, “só a variedade absorve variedade”.
    2. O modelo de (Bruce) Tuckman, de 1965, se equivoca ao fixar o estágio Storming (confrontação) como o segundo de um total de cinco que caracterizariam o ciclo de vida de um time. As tempestades são relativamente frequentes e isso não é necessariamente ruim nem indesejável em um time saudável. Sobre o modelo: https://pt.wikipedia.org/wiki/Modelo_de_Tuckman
    3. https://pt.wikipedia.org/wiki/Elinor_Ostrom
      Ela também nos presenteou com a Lei de Ostrom: “um arranjo de recursos que funciona na prática pode funcionar na teoria”.
    4. https://pt.wikipedia.org/wiki/Trag%C3%A9dia_dos_comuns
    5. David Sloan Wilson em This View of Life: Completing the Darwinian Revolution (Patheon, 2019) e Herb Bowie no artigo Agile Software Development and the Core Design Principles for Teams.
    6. Converso sobre todos eles na aula Grandes TIMES Pequenos.
    7. Foto de Shane Rounce no Unsplash
  • Quem Escreve a Partitura?

    Quem Escreve a Partitura?

    Uma conversa sobre organização, times, alinhamento, autonomia e a nossa eterna busca pela batida perfeita.Estou me atualizando com os “novos modelos” :)))
    O cara do     Spotify explicando a cultura da empresa. Autonomy. Squads são equipes multifuncionais que funcionam em modo ágil. Aí ele agrupa os squads em tribes. E as tribes são alinhadas à infraestrutura, aplicações de suporte e de negócio. Hahaha. E você, num squad, se une aos seus pares de outros squads por capabilities. Hahaha. Incrível.
    Aí ele descreve o     squad como uma banda de jazz, onde cada um é autônomo no seu instrumento. Mas esqueceu de mencionar a partitura!!!!! Quem escreve a partitura nesse mundo novo??

    O desabafo veio do outro lado do mundo, de Hong Kong. Foi feito por um colega de longa data. Ele puxou o papo porque lembrou de nossos embates filosóficos de uns dezessete anos atrás. É fácil ficar confuso com alguns novos modelos. Aliás, como disse Tom Peters, “quem não está confuso não está prestando atenção”.

    Também me atualizando em relação ao novos modelos, há poucos dias me deparei com a Teoria da Promessa. WTF?, de Tim O’Reilly, me levou para o trabalho de Mark Burgess, Thinking in Promises (O’Reilly, 2015). Criador da tal teoria, Burgess a apresenta como “uma linguagem para descrever e discutir o comportamento cooperativo entre diferentes agentes ou atores”. Se esses agentes ou atores são homens ou máquinas (algoritmos), não faz diferença. Aliás, esta seria a força da proposta: um único modelo a guiar as pessoas e tudo o que elas constroem.

    A teoria explicaria o funcionamento e a eficiência da Amazon, por exemplo¹. Um agente só pode prometer algo que está 100% sob seu controle. Cada agente é uma caixa preta – não importa como ele mantém ou cumpre a promessa. O que interessa é o que foi prometido. Se prometo e cumpro, mereço confiança. Se todos os agentes fazem o mesmo, temos um perfeito ambiente colaborativo.

    Burgess alerta que não está propondo um manifesto nem uma agenda filosófica ou política. Mas é difícil não associar a proposta ao liberalismo. Como não pensar assim ao perceber que o modelo é 100% bottom-up, uma declaração da autonomia incondicional de um agente? O autor é claro: ninguém pode fazer promessas em nome de outro(s). Um componente Java não pode prometer a disponibilidade do banco de dados. Um gerente não pode prometer a eficácia do designer nem a pontualidade do projeto. Cada agente só se compromete com aquilo que está totalmente em seu domínio. Convenhamos, a teoria é simpática. E a prática?

    Como isso funcionaria numa cultura como a brasileira, onde cada vez mais brasileiros detestam (ou, amenizando, desconfiam dos) outros brasileiros? Parafraseando O’Reilly, para cada Webgoal ou Nubank temos milhares de empresas que se caracterizam pela absoluta falta de confiança N:N – de todos para todos, na horizontal, de cima para baixo, de dentro para fora e vice-versa.

    Meu colega está distante de nossas mazelas e aguarda uma resposta: afinal, quem escreve a partitura?

    Burgess diz que “organizações são redes de promessas”. O que orienta a elaboração das promessas? Há uma partitura? Ela é uma promessa? De quem?

    O autor fala sobre um conjunto de agentes, um Super Agente que faz promessas coletivas. Um Super Agente é “um fantasma e, como tal, não possui um canal de comunicação”. Nesse ponto interrompi a leitura².

    Autonomia X Alinhamento

    O debate, que deve ter começado quando éramos apenas caçadores-coletores, é bom e merece a nossa atenção. Ele recebe outros nomes, como Centralização X Descentralização, Hierarquia X Holarquia (ou Holacracia) etc. O problema nunca esteve nos fatores. Está no operador – no OU.

    Faz sentido que a gente busque autonomia E alinhamento. O melhor exemplo é o nosso corpo. Nossos subsistemas são autônomos. Não há ninguém microgerenciando o coração ou o esôfago. Nosso cérebro-CEO não fica ditando ao pulmão: inspira, expira, inspira, expira… Mas, em sã consciência, estamos no controle. Todos temos uma partitura, ainda que mal escrita. Apesar (por causa!) da autonomia, nossos subsistemas funcionam alinhados. Ou, como escreveu Jurgen Appelo³, “sistemas complexos sobrevivem e prosperam porque o controle é distribuído”.O gráfico ao lado tenta ilustrar o desafio. Num extremo, aquelas empresas que seriam modelos. No outro, o famigerado Dilbert e sua organização sem pé nem cabeça. Quantas empresas passaram por reestruturações que ora puxavam a corda na vertical, ora afrouxavam a corda horizontal; Quebravam a cara e começavam tudo de novo, numa interminável e improdutiva valsa?

    Há Partituras

    Na Amazon, por exemplo, a construção de um novo serviço (ou microserviço ou funcionalidade) só é autorizada depois de uma Rich Discussion Up Front. Essa discussão se dá em torno de uma documentação elaborada pelo proponente do novo serviço. Essa proposta geralmente é composta por um Press-Release, FAQ, Protótipos e, quando necessário, até um manual do usuário.

    Quem escreveu a partitura-documentação? Um time autônomo. O que garante o alinhamento? Aquela tal rica discussão prévia. Se aquela proposta (promessa) não fizer sentido para a organização, ela não recebe luz verde. Quem participa das discussões? No caso da Amazon, dependendo da proposta, até o próprio Bezos. Foi assim, por exemplo, que nasceu a AWS. É como no nosso corpo: quando o caso – ameaça ou oportunidade – é realmente sério, ele merece a alocação do cérebro-CEO.

    Os “Novos Modelos”

    Não são poucos os que, como meu colega, demonstram ceticismo em relação aos novos modelos. Desconfio que seja porque 1) O que se proclama novo, muitas vezes, não é tão novo assim. A ideia de escrever um manual antes de qualquer coisa, por exemplo, pode ser rastreada até The Mythical Man-Month que Fred Brooks publicou em 1975! Squads, chapters, tribes, guilds?! Apelidos pós-modernos e uma certa complicação para ideias que estão por aí há tempo. Capítulos e guildas, por exemplo, são releituras das velhas Comunidades de Prática; 2) Muitas empresas não precisam, não podem ou simplesmente não querem ser como Amazon, Spotify, Uber ou afins. Nem todo mundo precisa ou quer ostentar um chifre.

    Por fim, um parágrafo que insistiu em permanecer: A montagem de times deveria respeitar apenas três leis: a de Ashby e a de Conway sempre, e a de Brooks toda vez que um projeto atrasar. As outras, até a “regra das duas pizzas”, podem ser ignoradas dependendo do contexto e das intenções.

    Meu colega é exigente. Desconfio que ele não se dará por satisfeito. Nem você. Que o papo prossiga. Inté!

    Notas

    1. WTF? What’s the Future and Why It’s Up to Us – Tim O’Reilly (HarperBusiness, 2017).
    2. Que ainda vou retomar. Não posso desconsiderar toda a proposta só porque não concordo com uma afirmação. Mas preciso deixar claro o seguinte: no meu entendimento, um super agente – seja ele um time, unidade, serviço, filial etc – é, necessariamente, um Sistema Aberto. Como tal, é claro que ele tem não apenas um mas vários canais de comunicação. Posso não entender como ele funciona – é uma caixa preta – mas sei me comunicar com ele, colocar meus pedidos e requisitos, chamar suas APIs, entender e negociar suas promessas. Não sei se entendi errado. Mas aquele “fantasma” me assustou.
    3. #Workout – Happy Melly Express, 2014
    4. “Online” Sheet (Tweet) Music é o criativo achado de John Dyer que ilustra este artigo.

    Gostou da conversa? Ela é esticada e enriquecida na oficina Design de Negócios Viáveis.

    A próxima edição acontece em São Paulo no próximo dia 2/2.

    Posso fazer alguma coisa para viabilizar a sua participação? Fale comigo!

  • Quem Escreve a Partitura?

    Quem Escreve a Partitura?

    Uma conversa sobre organização, times, alinhamento, autonomia e a nossa eterna busca pela batida perfeita.Estou me atualizando com os “novos modelos” :)))
    O cara do     Spotify explicando a cultura da empresa. Autonomy. Squads são equipes multifuncionais que funcionam em modo ágil. Aí ele agrupa os squads em tribes. E as tribes são alinhadas à infraestrutura, aplicações de suporte e de negócio. Hahaha. E você, num squad, se une aos seus pares de outros squads por capabilities. Hahaha. Incrível.
    Aí ele descreve o     squad como uma banda de jazz, onde cada um é autônomo no seu instrumento. Mas esqueceu de mencionar a partitura!!!!! Quem escreve a partitura nesse mundo novo??

    O desabafo veio do outro lado do mundo, de Hong Kong. Foi feito por um colega de longa data. Ele puxou o papo porque lembrou de nossos embates filosóficos de uns dezessete anos atrás. É fácil ficar confuso com alguns novos modelos. Aliás, como disse Tom Peters, “quem não está confuso não está prestando atenção”.

    Também me atualizando em relação ao novos modelos, há poucos dias me deparei com a Teoria da Promessa. WTF?, de Tim O’Reilly, me levou para o trabalho de Mark Burgess, Thinking in Promises (O’Reilly, 2015). Criador da tal teoria, Burgess a apresenta como “uma linguagem para descrever e discutir o comportamento cooperativo entre diferentes agentes ou atores”. Se esses agentes ou atores são homens ou máquinas (algoritmos), não faz diferença. Aliás, esta seria a força da proposta: um único modelo a guiar as pessoas e tudo o que elas constroem.

    A teoria explicaria o funcionamento e a eficiência da Amazon, por exemplo¹. Um agente só pode prometer algo que está 100% sob seu controle. Cada agente é uma caixa preta – não importa como ele mantém ou cumpre a promessa. O que interessa é o que foi prometido. Se prometo e cumpro, mereço confiança. Se todos os agentes fazem o mesmo, temos um perfeito ambiente colaborativo.

    Burgess alerta que não está propondo um manifesto nem uma agenda filosófica ou política. Mas é difícil não associar a proposta ao liberalismo. Como não pensar assim ao perceber que o modelo é 100% bottom-up, uma declaração da autonomia incondicional de um agente? O autor é claro: ninguém pode fazer promessas em nome de outro(s). Um componente Java não pode prometer a disponibilidade do banco de dados. Um gerente não pode prometer a eficácia do designer nem a pontualidade do projeto. Cada agente só se compromete com aquilo que está totalmente em seu domínio. Convenhamos, a teoria é simpática. E a prática?

    Como isso funcionaria numa cultura como a brasileira, onde cada vez mais brasileiros detestam (ou, amenizando, desconfiam dos) outros brasileiros? Parafraseando O’Reilly, para cada Webgoal ou Nubank temos milhares de empresas que se caracterizam pela absoluta falta de confiança N:N – de todos para todos, na horizontal, de cima para baixo, de dentro para fora e vice-versa.

    Meu colega está distante de nossas mazelas e aguarda uma resposta: afinal, quem escreve a partitura?

    Burgess diz que “organizações são redes de promessas”. O que orienta a elaboração das promessas? Há uma partitura? Ela é uma promessa? De quem?

    O autor fala sobre um conjunto de agentes, um Super Agente que faz promessas coletivas. Um Super Agente é “um fantasma e, como tal, não possui um canal de comunicação”. Nesse ponto interrompi a leitura².

    Autonomia X Alinhamento

    O debate, que deve ter começado quando éramos apenas caçadores-coletores, é bom e merece a nossa atenção. Ele recebe outros nomes, como Centralização X Descentralização, Hierarquia X Holarquia (ou Holacracia) etc. O problema nunca esteve nos fatores. Está no operador – no OU.

    Faz sentido que a gente busque autonomia E alinhamento. O melhor exemplo é o nosso corpo. Nossos subsistemas são autônomos. Não há ninguém microgerenciando o coração ou o esôfago. Nosso cérebro-CEO não fica ditando ao pulmão: inspira, expira, inspira, expira… Mas, em sã consciência, estamos no controle. Todos temos uma partitura, ainda que mal escrita. Apesar (por causa!) da autonomia, nossos subsistemas funcionam alinhados. Ou, como escreveu Jurgen Appelo³, “sistemas complexos sobrevivem e prosperam porque o controle é distribuído”.O gráfico ao lado tenta ilustrar o desafio. Num extremo, aquelas empresas que seriam modelos. No outro, o famigerado Dilbert e sua organização sem pé nem cabeça. Quantas empresas passaram por reestruturações que ora puxavam a corda na vertical, ora afrouxavam a corda horizontal; Quebravam a cara e começavam tudo de novo, numa interminável e improdutiva valsa?

    Há Partituras

    Na Amazon, por exemplo, a construção de um novo serviço (ou microserviço ou funcionalidade) só é autorizada depois de uma Rich Discussion Up Front. Essa discussão se dá em torno de uma documentação elaborada pelo proponente do novo serviço. Essa proposta geralmente é composta por um Press-Release, FAQ, Protótipos e, quando necessário, até um manual do usuário.

    Quem escreveu a partitura-documentação? Um time autônomo. O que garante o alinhamento? Aquela tal rica discussão prévia. Se aquela proposta (promessa) não fizer sentido para a organização, ela não recebe luz verde. Quem participa das discussões? No caso da Amazon, dependendo da proposta, até o próprio Bezos. Foi assim, por exemplo, que nasceu a AWS. É como no nosso corpo: quando o caso – ameaça ou oportunidade – é realmente sério, ele merece a alocação do cérebro-CEO.

    Os “Novos Modelos”

    Não são poucos os que, como meu colega, demonstram ceticismo em relação aos novos modelos. Desconfio que seja porque 1) O que se proclama novo, muitas vezes, não é tão novo assim. A ideia de escrever um manual antes de qualquer coisa, por exemplo, pode ser rastreada até The Mythical Man-Month que Fred Brooks publicou em 1975! Squads, chapters, tribes, guilds?! Apelidos pós-modernos e uma certa complicação para ideias que estão por aí há tempo. Capítulos e guildas, por exemplo, são releituras das velhas Comunidades de Prática; 2) Muitas empresas não precisam, não podem ou simplesmente não querem ser como Amazon, Spotify, Uber ou afins. Nem todo mundo precisa ou quer ostentar um chifre.

    Por fim, um parágrafo que insistiu em permanecer: A montagem de times deveria respeitar apenas três leis: a de Ashby e a de Conway sempre, e a de Brooks toda vez que um projeto atrasar. As outras, até a “regra das duas pizzas”, podem ser ignoradas dependendo do contexto e das intenções.

    Meu colega é exigente. Desconfio que ele não se dará por satisfeito. Nem você. Que o papo prossiga. Inté!

    Notas

    1. WTF? What’s the Future and Why It’s Up to Us – Tim O’Reilly (HarperBusiness, 2017).
    2. Que ainda vou retomar. Não posso desconsiderar toda a proposta só porque não concordo com uma afirmação. Mas preciso deixar claro o seguinte: no meu entendimento, um super agente – seja ele um time, unidade, serviço, filial etc – é, necessariamente, um Sistema Aberto. Como tal, é claro que ele tem não apenas um mas vários canais de comunicação. Posso não entender como ele funciona – é uma caixa preta – mas sei me comunicar com ele, colocar meus pedidos e requisitos, chamar suas APIs, entender e negociar suas promessas. Não sei se entendi errado. Mas aquele “fantasma” me assustou.
    3. #Workout – Happy Melly Express, 2014
    4. “Online” Sheet (Tweet) Music é o criativo achado de John Dyer que ilustra este artigo.

    Gostou da conversa? Ela é esticada e enriquecida na oficina Design de Negócios Viáveis.

    A próxima edição acontece em São Paulo no próximo dia 2/2.

    Posso fazer alguma coisa para viabilizar a sua participação? Fale comigo!

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

  • (Pensando alto sobre) Arquitetura Corporativa

    Segunda parte da palestra “O Futuro não é mais como era Antigamente“. O título original desta seção era “O Cérebro Eletrônico faz (quase) Tudo”. Mas vou poupá-los do resumo da saga¹. Este artigo vai tratar especificamente do tema que não consegui articular como gostaria no Seminário Engenharia de Software. Vou escrever (ou pensar alto) sobre Arquitetura Corporativa – aquela coisa abstrata que normalmente vem acompanhada de uma piadinha: “parece cabeça de bacalhau; Todo mundo sabe que existe mas ninguém nunca viu”.

    .:.

    Arquitetura, segundo o Houaiss, é 1. “arte ou técnica de organizar espaços e criar ambientes para as diversas atividades humanas”, ou 4. fig. “conjunto de elementos de um todo; estrutura, natureza, organização”. Uma arquitetura corporativa deveria representar todos os elementos da organização. É esta última frase que bagunça o coreto. Como representar “todos os elementos de uma organização”? Seria a arquitetura corporativa um tipo de documentação, de representação de coisas que existem no mundo real? Se for a representação de *todas* as coisas, não espanta que ninguém tenha visto uma. Por isso peço sua atenção para a primeira definição acima. “Arte ou técnica” – 97,8% técnica, em nosso caso; “de organizar espaços e criar ambientes” – estruturando todos os elementos de um conjunto; “para as diversas atividades humanas” – para as atividades e fins de um negócio, se estamos falando sobre Arquitetura Corporativa.

    Lá nos idos de 40 a.C. um tal de Vitrúvio, arquiteto e engenheiro romano, cismou em fixar algumas regrinhas para construções. Pelo jeito fez um bom trabalho, já que é ensinado até hoje. Dos dez volumes que ele batizou “De Architectura” só nos interessa aqui uma pequena definição: a tríade vitruviana. Ela fixa três elementos fundamentais da arquitetura:

    • Firmitas: solidez e estabilidade;
    • Utilitas: conveniência e utilidade. (Funcionalidade!);
    • Venustas: beleza, gosto estético.

    Se um dia resolvemos trazer “arquitetura” para nosso meio (TI), deveríamos ter importado também um comprometimento com as três características listadas acima. Afinal, elas são peças fundamentais da disciplina que incorporamos. Portanto, uma arquitetura corporativa deveria ser sólida, estável, útil e bela. Agora, faça uma breve análise dos negócios que você conhece. Faça de conta de que existe uma radiografia que sintetiza a arquitetura de uma determinada organização. Ela passaria pelo teste da tríade vitruviana? Não precisa responder. A menos que sua resposta seja ‘sim’. Assim vou pedir referências, CNPJ, “nada consta” e RG de todos os envolvidos.

    Não se trata de um julgamento negativo demais e sim de um “choque de realidade”. Um negócio, qualquer negócio, é feito de muita adaptação e improviso. O dinamismo que só faz crescer desde o início do século passado impõe uma dificuldade que a arquitetura “clássica” nunca enfrentou. Pelo que sei, nunca foi solicitada uma edificação que: i) se adaptasse instantaneamente às mudanças em seu ambiente; ii) influenciasse seu ambiente; e iii) suportasse os usos e mal usos mais improváveis e inconsequentes.

    Devemos concluir então que esse papo sobre “arquitetura corporativa” é pura balela e ponto final? Acho que não. Equivocada é a intenção de documentar extensivamente a arquitetura total de um negócio. Mais bola fora ainda é a documentação pela documentação, mera burocracia. A primeira pergunta que deveria ser feita é: por que precisamos falar sobre arquitetura corporativa?

    Todo negócio é uma viagem. Claro que não no sentido pejorativo que ficou comum nos últimos anos. Um negócio é uma jornada sem fim (pré-determinado) que de tempos em tempos renova seu destino (sua Visão). Condições do tempo e do terreno, cada vez mais instáveis e movediços, tornam a viagem e seu planejamento cada vez mais difíceis. A arquitetura corporativa, se bem elaborada, pode funcionar como mapa e bússola. Mas, afinal, o que é arquitetura corporativa? Como ela é desenhada, se é que é desenhada?

    Uma busca na Internet pode lhe dar dezenas de boas sugestões. O Zachman Framework, por exemplo, sugere um consistente modelo para a elaboração da arquitetura corporativa. Aqui vou apelar para uma visão mais simples, para o que chamo de “básico do básico”. Gosto de ver o desenho de uma arquitetura como se fosse um belo sanduíche. Belo mas simples, um cheeseburger. Que é formado por quatro partes apenas:

    • Arquitetura Tecnológica: ou “o que eu tenho”. São os ferros (hardware) e caixinhas (software) que compõem a infraestrutura tecnológica da organização;
    • Arquitetura de Informações: ou “o que eu sei”. Trata de dados, informações e conhecimento explícito, aquele que está registrado de alguma maneira no negócio.
    • Arquitetura de Aplicações: ou “o que eu faço”. Compila todas as funcionalidades oferecidas ao negócio na forma de sistemas aplicativos.
    • Arquitetura do Negócio: ou “Por qual razão e pra quem?”. Dá sentido para as três camadas (arquiteturas) inferiores. Justifica (ou não) cada aplicação, informação e componente de infraestrutura.

    Esta visão de alto nível atende parte da definição de arquitetura que vimos no início do artigo. Os “espaços” estão organizados. A partir dela conseguimos entender “estrutura, natureza e organização” dos elementos que formam a arquitetura corporativa.

    O desenho permite até algumas elocubrações e provocações. Por exemplo: Nicholas Carr (aquele do “IT Doesn’t Matter”) defende no livro “A Grande Mudança” (Landscape, 2008) que é questão de tempo para as empresas se livrarem da camada mais baixa do sanduíche, a arquitetura tecnológica. Aqueles “serviços” seriam oferecidos por grandes empresas, em um modelo muito parecido com o das distribuidoras de energia elétrica. Sua tese faz um certo sentido, mas qual o impacto nas camadas de cima? Ah, elas seriam terceirizadas também.  Opa, elas já são. Mas em fatias verticais, da mesma forma como repartimos um sanduíche de verdade. Ofertas assim são conhecidas como BPO, ou Business Process Outsourcing. Deixando as infinitas possibilidades de lado, voltemos ao tema central.

    Como são formadas cada uma das arquiteturas? As três camadas técnicas – Arquitetura Tecnológica, de Informações e de Aplicações – podem ser representadas por um ou mais diagramas específicos. A UML, por exemplo, oferece diagramas que podem representar muito bem cada uma delas. Importante aqui é o bom senso para se limitar a representar apenas os elementos principais, fazendo vista grossa para detalhes finos (sic). Desafiadora aqui é a ligação entre as quatro camadas, as relações entre elementos de infra, informações, aplicações e do negócio. Desafiadora porque é aqui que encontramos incontáveis ligações ponto a ponto (macarrônicas), vergonhosas redundâncias e incômodos buracos negros. Mas não é por aqui, pelas três arquiteturas técnicas, que o trampo deve começar.

    As três camadas técnicas só existem para suportar um negócio. Parece lógico que o desenho de uma arquitetura corporativa comece pelo entendimento e delimitação da arquitetura do negócio. Como estourei meu limite de 1000 palavras, uma sugestão para o desenho desta arquitetura fica para o próximo artigo. Inté!

    .:.

    Observações:

    1. Ok, tá aqui o resumo da saga: Era uma vez… lá na nossa pré-história acreditávamos em um colossal e monolítico “cérebro eletrônico”. Décadas depois testemunhamos o esfacelamento e distribuição do “cérebro” em peças cada vez menores e em locais dos mais inusitados. O que nos traz para uma das cinco supertendências apontadas pelo ZapThink: a interoperabilidade profunda. Em poucas palavras: esses pequenos cérebros ou pedaços de cérebro devem aprender a interagir e conversar entre si da maneira mais natural possível. Talvez este não seja o principal desafio dos novos tempos, mas com certeza é o mais instigante: “Como assim, meu tênis vai conversar com meu carro, minha casa e meu iPod?!?”
      A pergunta que fiz e não respondi naquela palestra foi: nossas teorias e práticas (sobre Engenharia de Software) resistem ao confronto com as novas pessoas, tecnologias e arquiteturas?
    2. A imagem utilizada neste artigo foi desenhada para o trabalho “De Architectura”, de Vitruvius, e obtida na Wikipédia.

  • Priorizar

    Priorizar v. {mod. 1} t.d. tratar de (algo) em primeiro lugar e com mais empenho (Houaiss).

    Nos três primeiros capítulos da série determinamos o valor que cada iniciativa tem para o negócio, para a realização de seu grande objetivo (aumentar em 30% a rentabilidade das vendas). O último artigo mostrou como o valor, o peso de cada iniciativa, pode ajudar a determinar o rateio do orçamento¹. Finalmente chegou a hora de definir prioridades.

    .:.

    Valor e custo são as duas variáveis predominantes quando o assunto é classificação e priorização de projetos. Mas não são as únicas. A complexidade técnica das soluções e as oportunidades de aprendizado também podem interferir na sequência de desenvolvimento de projetos.

    Facilitamos a vida da turma do “como” (equipe técnica) ao isentá-la de boa parte do trabalho de estimativas. Seguindo uma ‘filosofia’ mais moderna, trocamos estimativas por restrições. Como vimos nos capítulos anteriores, prazos e limites de custos foram pré-fixados. A equipe técnica foi desafiada a encontrar três alternativas de solução para cada grande requisito apresentado.

    A seleção das melhores alternativas deve seguir a mesma lógica que define as prioridades. Aliás, seleção e priorização podem ocorrer no mesmo momento. Veja a matriz ao lado. Nela a equipe técnica posicionou as alternativas de solução para cada necessidade do negócio. O eixo Y, como nos diagramas anteriores, apresenta o valor para o negócio. Os custos são representados no eixo X. Podemos utilizar ícones ou símbolos para indicar as outras variáveis, a complexidade técnica e possibilidades de aprendizado. Neste exemplo usamos apenas o tamanho do círculo para indicar a complexidade² de cada alternativa.

    Os quadrantes nos ajudam a tomar algumas decisões de forma rápida. Ninguém deseja pesadelos, por exemplo. Pesadelos são alternativas caras que apresentam baixa ou nenhuma possibilidade de retorno. Eles aparecem quando o “limite do bom senso”, apresentado no artigo anterior, não é respeitado. Qualquer alternativa que caia ali deve ser automaticamente descartada pela equipe.

    As bobeiras, por outro lado, são baratas. Mas também têm baixo valor para o negócio. Por isso merecem sempre ficar no fim da fila (de projetos e também do processo de seleção e priorização).

    Sonhos são raros. Deveriam ser melhor aproveitados. São aqueles projetos que, apesar do baixo investimento, apresentam grande capacidade de gerar valor para o negócio.

    E os desafios são aquelas alternativas ou projetos de alto custo e alto valor para o negócio. É aqui que começamos. Três alternativas, duas para a “Captura de Pedidos em Tempo Real” (h) e uma para a “Melhoria do Sistema de Agendamento” (f) aparecem neste quadrante. Neste ponto do processo a equipe técnica deve apresentar as vantagens e desvantagens de cada alternativa sugerida. Representantes das áreas de negócio envolvidas devem ter a palavra final sobre a melhor ou mais viável solução. Em nosso exemplo, a objetiva empresa fictícia escolhe o óbvio sonho (h1) como melhor opção para a captura de pedidos em tempo real. Decide também pela alternativa f3 – a mais sofisticada (e cara) para a evolução do sistema de agendamento dos vendedores. Aliás, para aplacar o chororô dos vendedores, eles também estudam a possibilidade de tocar a iniciativa cd2, que envolve a “aquisição de aparelhos GPS” e a integração destes com o sistema de agendamento. Antes, fecharam que i1 é a melhor alternativa de “sistema de logística”. Sabem que é uma solução meia-boca em termos de funcionalidades, mas representa um bom ponto de partida para uma empresa que nunca teve de lidar com algo parecido.

    Relembrando: no processo descrito no parágrafo anterior nossa exemplar empresa fictícia escolheu: h1, f3, i1, cd2. Esta é a sequência determinada pelo valor gerado para o negócio. É a sequência ideal de desenvolvimento? Não. Nossa tão aguardada “fila indiana” de projetos fica assim: f3, h1, i1, cd2³. Como dita o senso comum, devemos sempre começar um trabalho pela parte mais difícil. A matriz utilizada acima nos ajuda a determinar a sequência ideal de desenvolvimento: Desafios, Sonhos, Bobeiras (e nada de Pesadelos).

    .:.

    Epílogo: Outra Provocação de nossa Exemplar Empresa Fictícia

    Você deve se lembrar, nossa honorável empresa fictícia fixou um orçamento de R$ 300 mil para todas as iniciativas. Ao selecionar as alternativas de solução as equipes técnica e do negócio baixaram seu teto para R$ 245 mil:

    • h1 = R$ 60 mil
    • f3 = R$ 70 mil
    • i1 = R$ 50 mil
    • cd2 = R$ 65 mil

    O que será feito com os R$ 55 mil economizados? Durante os projetos eles ficam reservados, como um fundo de garantia. Se algo não sair como o previsto (nunca sai), é neste fundo que a empresa buscará recursos. A grana que sobrar após a conclusão dos projetos será dividida entre todos os participantes dos projetos. Em espécie ou na forma de uma belíssima festa (churrasco, balada etc).
    Para quando está agendada a sua?

    .:.

    Observações:

    1. Curioso o biorritmo desta série. A audiência, forçada ou não, foi praticamente a mesma para todas as quatro partes já publicadas. Não posso dizer o mesmo da divulgação voluntária. Alguns capítulos mereceram elogios e indicações via Twitter. O último passou em branco. Justo aquele que, segundo meu pretensioso julgamento, deveria merecer mais atenção e debate. Por quê? Porque ele propõe a inversão de duas coisas muito comuns em nossas organizações: a) Um orçamento é definido antes que a equipe de TI conheça o(s) problema(s). Os limites são pré-fixados de acordo com o retorno esperado para o negócio; b) Ao invés de falar de “Custos X Benefícios” o artigo fala de “Benefícios / Custos”. E nem chega perto da matemática financeira que costuma “poluir” este tipo de discussão.
      No mundo do gerenciamento de projetos vivemos bombardeados por siglas e termos como VPL (Valor Presente Líquido),  TIR (Taxa Interna de Retorno), Payback e afin$. Até Mike Cohn, em “Agile Estimating and Planning” (Prentice-Hall, 2006), lança mão de sua calculadora financeira na hora de falar de priorização de projetos (temas, no caso dele) com base em grana. Na realidade ele surrupia e resume os escritos de Steve Tockey em “Return on Software: Maximizing the Return on your Software Investment” (Addison-Wesley, 2004). No caso do Mike há um probleminha que precisa ser mais estudado. Um probleminha que vou chamar de TMNUF (“Too Many Numbers Up Front”.. hehe, algo como “Números Demais, Cedo Demais”.
      Resumo (a ser melhor trabalhado futuramente): Trabalhando em um processo iterativo e incremental eu não consigo prever (com precisão de 50 dólares, como faz Mike) o fluxo de caixa líquido de 8 trimestres!!!
    2. Muitos autores preferem falar de “riscos” ao invés de “complexidade”. Como me acostumei a falar de “riscos” para dizer “riscos do negócio”, utilizo “complexidade” para representar os riscos técnicos. Na realidade, “complexidade” pode abranger também a quarta variável citada no artigo, “oportunidades de aprendizado”.
    3. Este artigo “esconde” uma pegadinha e uma provocação. Quem matar as duas, em comentário aqui registrado, garante uma vaga em uma das próximas turmas do FAN. Vaga impessoal e transferível! Promoção válida até o dia 25/agosto/2010.
    4. Hoje encerro o tema principal: Priorização de Projetos. Depois devo publicar alguns artigos isolados para quitar alguns débitos deixados pela série, particularmente sobre BSc’s e seu uso no Planejamento Estratégico.
    5. “Creating Solutions” é o cartoon do HikingArtist que encerra a série.

  • Benefícios / Custos

    No capítulo anterior vimos como atribuir valor para projetos. Aprendemos que as possíveis iniciativas devem ser avaliadas como um conjunto e nunca de forma isolada. Nosso foco até agora esteve no peso, na contribuição de cada iniciativa para que a empresa alcance seu objetivo maior. Neste quarto artigo da série vamos olhar para o outro lado da moeda, aquele formado pelos custos.

    .:.

    Antes, porém, vale a pena revisar o caminho que trilhamos até aqui. No segundo artigo eu sugeri o uso de um diagrama que nos ajuda a classificar processos de negócio e, consequentemente, seus respectivos projetos. Sinto ter tratado esse trabalho de forma um tanto rápida, como se ele fosse natural em nossas organizações. Não é.

    O diagrama ao lado já exibe o resultado do trabalho de valorização que vimos no último artigo. Mas, antes de explicar o conteúdo, preciso elucidar o rabisco. É um mapa de processos desenhado em uma matriz de classificação. A matriz é um recurso mais didático do que prático. Pretende apenas criar o costume de diferenciar tipos de processos e tipos de processos primários logo no início de um projeto. Como vimos anteriormente, a coluna à direita exibe os processos mais relevantes para a proposta de valor da empresa. São os processos primários do tipo operacional que aparecem no exemplo que estamos desenvolvendo. Porque a proposição de valor de nossa empresa fictícia é a excelência operacional (“vender baratinho”).

    Estou utilizando a UML e sua extensão para negócios EPBE. No mapa destaquei apenas os recursos de TI diretamente afetados pelas iniciativas que a empresa pretende disparar (Aqueles rabiscos ao lado das letras são os ‘pacotes’ da UML e representam sistemas ou módulos de um sistema) . Os recursos são organizados por processos. Temos então uma derivação dos diagramas de processos que na EPBE é chamada de “diagrama de linhas de montagem”. Claro, estou mostrando uma versão absurdamente simples deste artefato.

    Três processos serão alterados de alguma maneira para que a empresa possa realizar seu objetivo de aumentar em 30% a rentabilidade das vendas. São eles: “Vendas”, “Entrega” e “PGV – Planejamento e Gerenciamento das Vendas”. Foram vinculados a eles três condições (requisitos) apresentados pelas áreas de negócio envolvidas:

    f) Melhorar o Sistema de Agendamento;
    h) Capturar Pedidos em tempo real; e
    i) Adquirir / Desenvolver sistema de logística.

    Os itens c (Comprar sistema GPS) e d (Integrar GPS com sistema de Agendamento), classificados no capítulo anterior como os menos relevantes, foram descartados neste momento do trabalho.

    Antes de prosseguir, preciso de sua atenção para o seguinte: a “Captura de Pedidos em tempo real” (h) é a iniciativa que deve merecer 43% de nosso tempo e recursos. Opa… 43%?!? De onde veio esse número? No artigo anterior, utilizando a sequência de Fibonacci, valorizamos as iniciativas em 2, 2, 8, 13 e 5 pontos, respectivamente. Total = 30 pontos de valor. A iniciativa h vale 13 pontos, 43% de 30. Já já mostro a utilidade destes números.

    Só quando temos uma visão clara e compartilhada sobre o que precisa ser feito é que devemos envolver a turma do ‘como’ – a equipe responsável por determinar a melhor maneira de atender cada um dos requisitos apresentados¹. A partir de agora a equipe técnica precisa estudar e avaliar alternativas de solução para cada solicitação. Apresentar uma só alternativa é arrogância; Cinco ou mais sugestões é exagero que não se paga. Três é o número mágico. Mas a elaboração das 3 alternativas não carece de magia nenhuma. Basta mostrar: a mais simples; a mais sofisticada; e a intermediária.

    Não há nada que justifique que a equipe técnica não conheça a ordem de importância das iniciativas. Aliás, seu trabalho será muito melhor se desenvolvido a partir pleno entendimento das decisões estratégicas que deram origem aos requisitos apresentados. Só isso permitirá que a equipe técnica desenvolva uma linha de raciocínio representada pelo gráfico ao lado.

    É o valor, a relevância de cada solicitação (requisito) para realização do objetivo maior, que deve determinar o rateio do orçamento.  Ele está representado pelo eixo Y do diagrama. No eixo X podemos distribuir o orçamento (os custos). Vamos supor que a nossa empresa fictícia tenha destinado R$ 300 mil para todo o programa (conjunto de projetos). Isso significa que a iniciativa h (Capturar pedidos em tempo real) poderá consumir até R$ 130 mil, ou 43% do orçamento total. Indica também que a equipe terá apenas R$ 50 mil para “Adquirir ou desenvolver um sistema de logística” (i). E justifica o descarte dos projetos c e d: com apenas R$ 40 mil ela não conseguiria adquirir aparelhos GPS e integrá-los ao sistema de agendamento. Ou conseguiria? Não importa. Não neste momento.

    A linha pontilhada representa o “limite do bom senso”. Traduzindo: é muito difícil justificar qualquer projeto que a ultrapasse. Lembre-se: o eixo X representa os custos. Se, por exemplo, a contribuição dos aparelhos GPS para o aumento da rentabilidade das vendas é marginal ou questinável (2 pontos de valor, 7%), como justificar um investimento de R$ 50 mil (16% do orçamento) para a sua aquisição?

    Municiada com esses limites lógicos a equipe técnica não perderá tempo “viajando na mayonaise”. De cara ela descartará, por exemplo, a consulta àquele maravilhoso fornecedor de soluções de logística que apresenta custos de licenciamento começando em R$ 200 mil. Pra que perder tempo? O limite de R$ 50 mil está colocado e não é negociável.

    Eu sei, esse papo todo é óbvio demais. Mas quantas vezes você teve a oportunidade de discutir um orçamento amparado por tamanha obviedade? Lá na primeira parte da série eu prometi “apresentar sugestões que ajudem a definir o que é prioritário, o que pode aguardar na fila e o que não passa de bullshitagem sem valor”. Estou quase chegando lá. O problema é que eu também havia prometido ser mais prático e… direto! Mas ainda precisarei de um quinto capítulo. Só torço para que as sugestões apresentadas estejam servindo para alguma coisa. No mínimo como provocações. Inté!

    .:.

    Observações:

    1. Iniciei aquele parágrafo com um medo danado de ser mal interpretado. Uma “visão clara e compartilhada do que precisa ser feito” não significa  BDUF (Big Design Up Front), uma tonelada de documentos nem nada do tipo. Os artefatos mostrados até o momento são mais do que suficientes para mostrar: Porque os projetos são necessários; Quem está envolvido; Quanto valor pode ser gerado por cada iniciativa; Onde mudanças são necessárias; Quando elas ocorrerão; e Como elas serão implementadas². Forcei a barra? Então aguarde o próximo capítulo.
    2. Você já viu essa sequência de perguntas antes, não?
    3. Não sei porque o tipo de análise apresentado neste artigo é universalmente conhecido como “Análise Custo X Benefício“. Prefiro “Benefício / Custo”. Pode parecer preciosismo de minha parte, mas prefiro ver os Benefícios antes de debater e definir Custos. Gastei 3 das 4 partes desta série preocupado exclusivamente com os Benefícios, com o Valor que devemos gerar para o negócio. Só agora comecei a falar de custos.
    4. “Almost There” é o nome do cartoon utilizado. Como sempre, do HikingArtist.com.

  • Valorizando Projetos

    Previously on Lost (e bota ‘lost’ nisso): uma empresa fictícia que tem como proposta de valor a excelência operacional – ela “vende baratinho” – apresenta um grande objetivo para o próximo ano: o aumento de 30% da margem (rentabilidade) das vendas. Quatro metas, que serão reapresentadas abaixo, explicam como se dará a realização da visão, do grande objetivo. Cada meta pode significar a necessidade de um ou mais projetos. A questão que ficou aberta no último capítulo foi: como priorizá-los? Mistério que tentaremos desvendar neste terceiro artigo.

    .:.

    Nossa querida e bem administrada empresa fictícia concluiu¹ que a realização de seu grande objetivo, o aumento de 30% da margem das vendas, depende do sucesso de quatro iniciativas: i) Aumentar base de clientes; ii) Reduzir giro de clientes (aumentar fidelidade); iii) Reduzir prazo de entrega; e iv) Reduzir o turn-over (rodízio) de vendedores. Ciente de que iniciativas desprovidas de indicadores e prazos são tão firmes quanto prego no angu, a empresa fixou as seguintes metas para cada uma: 15%; 25%; 2 dias úteis; e 50%, respectivamente. O prazo conhecido para a realização do grande objetivo é o ano que vem . Deve estar claro que requisitos para realização dos indicadores apresentados devem estar satisfeitos antes do início do ano. Considerando que este artigo foi escrito em agosto, vamos entender que temos cerca de 4 meses de prazo.

    Todas as áreas do negócio responsáveis pela realização das metas apresentam suas condições – seus requisitos (!). O rabisco ao lado nos mostra que foram apontadas 13 solicitações. Elas são listadas abaixo, estruturadas nas 4 metas:

    Meta #1 – Aumentar base de Clientes em 15%
    a) Contratar mais 2 vendedores
    b) Ampliar área de atuação
    c) Comprar sistema GPS
    d) Integrar GPS com sistema de Agendamento

    Meta #2 – Reduzir giro de Clientes em 25%
    e) Aumentar frequência de visitas (2 para 3 visitas mensais)
    f) Melhorar sistema de Agendamento
    g) Criar programa de Fidelidade

    Meta #3 – Reduzir Prazo de Entrega de 5 para 2 dias úteis
    h) Capturar pedidos em tempo real
    i) Adquirir / Desenvolver sistema de Logística
    j) Adquirir caminhões pequenos
    k) Alugar armazém de médio porte na zona leste

    Meta #4 – Reduzir Turn-over de Vendedores para 50%
    l) Mudar esquema de comissionamento e bonificações
    m) Fixar áreas de atuação exclusivas

    Esta série de artigos tem como principal preocupação os projetos de TI. Então, por uma questão de simplificação, a partir de agora vamos nos ater apenas às condições (requisitos!) que representam ou podem representar demandas para o departamento de tecnologia da informação. Revendo a lista acima concluímos que os itens C, D, F, H e I são demandas diretas. Os itens L e M podem significar alterações em sistemas existentes. E o item G, dependendo de seu desenho, também pode respingar em TI. É trabalho pra chuchu.

    Lembram-se de uma provocação colocada no artigo que virou estopim para esta série? As empresas devem colocar seus projetos em “fila indiana”. Neste ponto da história, todas as 13 (5 para TI) condições apresentadas são prioritárias. A empresa tem condições de conduzi-las e gerenciá-las simultaneamente? A empresa precisa executá-las simultaneamente? Um provável *não* para a primeira pergunta e um definitivo *não* para a segunda. Chega a hora de falarmos novamente sobre valor.

    Durante muito tempo o mind-set tradicional de gerenciamento de projetos nos prendeu no triângulo custos, prazos e escopo. Quando elevada para a gestão de portfólios de projetos esta filosofia aumenta de maneira exponencial seu poder de estrago. Reparem, ainda estamos muito distantes de qualquer informação (ou preocupação) relativa aos custos das iniciativas. O que nos trouxe até aqui foi a relevância estratégica dos processos e a visão – os grandes objetivos de uma empresa.

    Perdida no artigo anterior estava uma questão até agora não respondida: Quem define o valor? Quem define o grau de importância de cada condição (requisito!) apresentada? Não pode ser ninguém que não esteja diretamente envolvido com a realização das metas colocadas. Acontece que clientes e usuários, de mal atendidos ou mal acostumados que são, costumam atribuir o mesmíssimo (alto) valor para tudo o que solicitam. O que difere muito este momento é o fato de suas solicitações (condições ou requisitos!) estarem exclusivamente em seu domínio – são requisitos do negócio. Mais: todas, de uma maneira ou de outra, possuem indicadores (de negócio) atrelados. Traduzindo: seu julgamento de valor não depende de intervenções ou restrições de terceiros (particularmente de TI ou afins). Mas nós podemos ajudá-los².

    A quantificação do valor, seja de projetos, requisitos ou histórias de usuários, segue merecendo o rótulo de “puro achismo” em diversas organizações. De certa forma, é melhor que a ignorância completa e absoluta que cerca o tema em tantas outras empresas. Uma certa complexidade do tema, principalmente de algumas propostas, talvez explique a situação atual. Mas não justifica. Existem métodos mais simples para avaliação do valor. Utilizarei neste artigo uma proposta apresentada por Jim Highsmith em “Agile Project Management – 2nd Edition“. Sua sugestão, Análise de Pontos de Valor, foi aplicada em histórias e funcionalidades. Utilizarei o mesmo método para a avaliação de projetos.

    Se a avaliação de custos é facilitada pelo uso de valores absolutos (money!), o mesmo não pode ser dito sobre a avaliação do valor (ou benefício, se desejas um sinônimo mais corriqueiro em solo tupiniquim). Para entender o problema, veja o item C de nosso exemplo: “Comprar sistema GPS”. Como quantificar seu valor para o negócio? Ou ainda, como mostrar em termos absolutos sua contribuição para a realização da Meta #1 – Aumentar base de clientes em 15%? Difícil, né? Para não dizer impossível.

    O maior erro que podemos cometer neste momento é tratar cada condição (requisito!) de maneira isolada. Não podemos nos esquecer que é o conjunto de condições que fará com que nossa estimada empresa fictícia aumente em 30% a rentabilidade de suas vendas. Dada a impossibilidade de uso de valores absolutos, devemos apelar para valores relativos. São os tais “pontos de valor” propostos por Highsmith. Ele sugere o uso da sequência de Fibonacci para fixação dos números relativos. Com um importante detalhe: a sequência deve ser finita. Em nosso exemplo utilizaremos {1, 2, 3, 5, 8 e 13}.

    Vou resumir em poucas linhas um processo que pode durar horas ou até mesmo dias. Todas as partes interessadas devem atribuir um valor para suas condições. O consenso sobre a contribuição (peso) de cada solicitação (requisito!) para a realização do objetivo maior deve ser obtido. Nossa empresa fictícia, exemplar em tudo, rapidamente concordou com o seguinte:

    c) Comprar Sistema GPS: 2 pontos
    d) Integrar GPS com sistema de Agendamento: 2 pontos
    f) Melhorar Sistema de Agendamento: 8 pontos
    h) Capturar Pedidos em Tempo Real: 13 pontos
    i) Adquirir / Desenvolver sistema de Logística: 5 pontos

    Atenção para o que a classificação acima nos diz. Por exemplo: a captura de pedidos em tempo real (h) dá uma contribuição 6 vezes maior que a compra de um sistema GPS (c) para a concretização da visão da empresa (o aumento de 30% na rentabilidade das vendas). Isso significa que este é o projeto mais prioritário entre os prioritários? Ainda não. Mas sinto informar que precisarei de outro(s) artigo(s) para concluir a série³. Inté!

    .:.

    Observações:

    1. Não está no escopo desta série a explicação de todo o processo que levou nossa honorável empresa fictícia a determinar que aquelas 4 metas, se ou quando plenamente atendidas, resultarão em um aumento de 30% da margem ou rentabilidade das vendas. Mas é preciso dizer que ele, o tal processo, faz parte daquela mistura de arte e ciência que convencionamos chamar de “Planejamento Estratégico”. Também devo confessar que raramente pude testemunhar elaboração tão clara, rápida e objetiva quanto a ilustrada neste artigo. Por isso nossa empresa fictícia é tão exemplar.
    2. Olha o fio da meada aqui: “Nós podemos ajudá-los”. No contexto: TI pode ajudar as áreas de negócio no processo de definição do valor das iniciativas e projetos. Como? Através da aplicação da *boa* Análise de Negócios. Não através daquela lenga-lenga pequenininha dos “tiradores de pedidos”, mas através da *real* Análise de Negócios – aquela que ajuda a empresa a definir o que precisa ser feito. A isenção em relação à todas as áreas de negócios confere aos *bons* analistas uma posição privilegiada que os permite facilitar e intermediar todo o processo de planejamento e priorização de projetos. E vocês não sabem como fiquei satisfeito quando dois de meus clientes, gerentes ou diretores da área de Análise de Negócios, me contaram que estavam assumindo também o PMO. Ah, se fosse uma tendência…
    3. Meu processo de elaboração de artigos é bem caótico e imprevisível. Sério! Quando escrevi o primeiro capítulo não tinha a menor idéia de que viraria uma série, muito menos que seria uma sequência com tantas partes. Por isso mesmo não sei se ainda precisarei de um, dois ou mais artigos até considerar o assunto concluído.
      Outra curiosidade: já escrevi tudo o que vocês estão vendo aqui em outro lugar, no meu fatídico e atrasado livro. Mas eu nunca faço ‘copy & paste’, nem de cá pra lá nem vice-versa. Cada um tem um estilo de redação e exigências de edição bem específicos. Mas é a elaboração cruzada que me dá uma produtividade muito boa.
    4. Se chatearam com minha insistência em escrever (requisitos!) assim, entre parênteses e fechados por uma exclamação? Foi para lembrar e lembrar e lembrar que metas e objetivos do negócio são requisitos. Só isso.
    5. Promessas feitas em capítulos anteriores e ainda não cumpridas: falar um pouco mais sobre BSc’s (Balanced Scorecards) e sobre projetos que, apesar de apresentarem baixo ou nenhum valor, são prioritários. Promessa é dívida. Pago na sequência da série.
    6. “Economist Fortress“ é a imagem do HikingArtist.com utilizada hoje.

  • Classificando e Priorizando Projetos

    Continuação de “Como Priorizar Projetos, Influenciar Decisões e Não fazer (muitos) Inimigos“.

    Encerrei o último artigo sugerindo que todos os projetos que toquem, melhorando ou criando, processos primários do tipo diretamente vinculado à proposta de valor (perfil estratégico) de uma organização devem ser considerados prioritários. Esta decisão, por si só, joga para um segundo plano algo entre 70% e 90% das demandas que uma empresa costuma apresentar. Basta? Claro que não, e por isso estamos aqui.

    Antes, que tal tornar a sugestão acima um pouco mais visual? O diagrama ao lado apresenta três blocos horizontais, cada um representando um tipo de processo de negócio. Mostra também três colunas, A, B e C, que devem ser utilizadas para separar os três tipos de processos primários: Operacionais, de Gestão de Clientes e de Inovação. Ficará na coluna A aquele mais relevante para a empresa. Por exemplo: se sua proposta de valor é o menor custo total (“vendo baratinho”), então a coluna A representará os processos primários do tipo Operacional.

    Portanto, o eixo X representa a relevância estratégica dos processos de negócio. O eixo Y, em três estágios, representa o valor daquele processo e respectivos projetos para o negócio. Quanto mais alto no gráfico, maior é o valor daquele processo ou projeto. Valor? O que é isso? Quem o define?

    Segundo o Houaiss, além de representar o “preço de um produto ou serviço”, valor também pode significar a “importância que se atribui a algo ou alguém”. É esta segunda definição que nos interessa aqui. Um processo de negócio e seus respectivos projetos podem ter maior ou menor importância para uma empresa. Mas, afinal, o que determina a importância (valor) de um processo? Os grandes objetivos do negócio. Aqueles que, formalmente ou não, representam a Visão do Negócio.

    Sinto ter que fazer um breve desvio aqui, porque acabo de entrar em um tema que ainda suscita algumas dúvidas. Ainda há uma certa confusão entre os termos Visão e Missão. Visão é o fim; Missão é o meio. A visão sempre tem um prazo de validade – ela deve ser renovada de tempos em tempos. A missão deve representar apenas a razão social de uma organização, o que ela está prometendo fazer pela sociedade. O exemplo que mais cito de declaração de missão eficaz e clara é da Google: “Organizar todas as informações do mundo e facilitar o acesso a elas”. Se a empresa de Mountain View durar cem anos, é provável que mantenha intacta sua declaração de missão. Já sua visão é renovada a cada triênio ou trimestre, dependendo de suas necessidades e de seu sucesso.

    Mesmo quando uma empresa não formaliza seus objetivos na forma de uma Visão, o fato é que um fim existe. Reside aqui boa parte dos problemas que afetam muitas empresas hoje em dia. A falta de uma visão consistente e bem divulgada faz de uma organização uma bagunça. Ela pode estar repleta de colaboradores bem intencionados, mas é uma bagunça. Serei o milionésimo cara a citar “Alice”, de Lewis Carroll: “Se você não sabe para onde quer ir, então é indiferente o caminho que venha a seguir”. E colaboradores bem intencionados e pró-ativos trilharão caminhos mil. Perdidinhos da silva.

    Uma boa visão deveria listar poucos objetivos de forma clara e não ambígua. Objetivos de negócio são melhor organizados na forma de árvores hierárquicas¹, onde ilustramos a contribuição de metas e objetivos menores para a realização de algo maior. A visão deveria concentrar apenas aqueles itens que formam a raiz desta árvore. Ou, no máximo, o primeiro nível de quebra.

    É muito mais fácil gerenciar e medir o sucesso de projetos que se comprometem com objetivos de negócio bem claros.

    Vamos supor que um dos objetivos expressos na visão de uma determinada empresa seja o aumento de 30% da margem ou rentabilidade das vendas. É um de seus objetivos para 2011. Não há neste caso uma iniciativa única que possa atingir este alvo. A empresa sabe que só um conjunto de projetos e mudanças² pode ajudá-la nesta realização. Utilizando o último diagrama como apoio, vemos que a empresa precisa disparar quatro grandes iniciativas e cada uma tem uma meta específica. Só o completo atendimento dessas metas resultará no aumento de 30% da margem das vendas. Neste exemplo as metas são:

    1. Aumentar base de clientes ativos em 15%
    2. Reduzir giro de clientes em 25%
    3. Reduzir prazo de entrega de 5 para 2 dias úteis
    4. Reduzir o turn-over de vendedores em 50%

    Se considerarmos que o único grande objetivo desta empresa exemplo para 2011 é o aumento de sua margem de vendas, devemos aceitar que todo e qualquer projeto que não contribua diretamente para a realização de uma das metas acima é de baixo valor. Repito: todo e qualquer projeto³. Por outro lado, todas as iniciativas que provarem de maneira inequívoca sua relação com uma ou mais das quatro metas acima devem ser classificadas como prioritárias.

    Agora você, atencioso que é, deve estar pensando: “Ok, já aprendi a separar o que tem valor daquilo que é bullshitagem pura. O autor apelou, utilizando como exemplo uma empresa que tem um único grande objetivo para o próximo ano4. Tudo bem, facilitou o entendimento. Mas, se eu entendi bem aquele último rabisco, eu vejo ali 13 ‘bolinhas’ que devem representar outras metas e, possivelmente, outros projetos. Esses 13 projetos são prioritários? Devo tratá-los da mesma maneira?”

    A pergunta é boa. A resposta, só no próximo capítulo. Inté!

    .:.

    Observações:

    1. Eu prefiro um tipo bem especial de ‘árvore hierárquica’ que atende pelo nome de Balanced Scorecard (BsC para os íntimos). Aliás, legal mesmo é  a representação de BsC’s com UML. Se você conhece a ferramenta, percebeu que no exemplo utilizado, mais precisamente na lista de 4 metas, apliquei a lógica de construção dos BsC’s. Hehe.. bobeira: só utilizei a sequência de perspectivas. No próximo capítulo eu falarei um pouco mais sobre isso.
    2. “Projetos e mudanças”. Este trecho deveria ser considerado um pleonasmo: todo projeto representa uma mudança. Toda mudança deveria ser administrada como um projeto? Creio que sim.
    3. Calma. O fato de um projeto ser de baixo valor não significa que ele não seja prioritário. Por exemplo: uma exigência legal ou para atendimento de algum padrão. Seu valor para o negócio é baixo mas ele será prioritário. Mais sobre isso no próximo artigo.
    4. Desconfio que toda boa empresa, independente de seu porte ou ramo de atividades, mantém algo entre 4 e 6 grandes objetivos. E os revê e renova anualmente, mesmo em tempos de turbulência. Mas eu gostaria de ver exemplos que comprovem ou detonem essa desconfiança.
    5. Utilizei outro free-cartoon de HikingArtist.com, desta vez “Looking for a Needle”.

  • Motivação, Parte 2

    Se você perdeu, a parte 1 está aqui.

    Hoje vou falar sobre motivação em projetos “custom”, aqueles desenvolvidos especificamente para uma organização. O entendimento da motivação para esse tipo de projeto é um pouquinho mais complicado. Em artigos anteriores (1 e 2) eu falei sobre alienação (da equipe de desenvolvimento) e problemas de comunicação. A *motivação* desta série é a dificuldade que equipes apresentam para decidir o que é prioritário em um projeto. A *tese* aqui defendida é que todas as decisões sobre priorização deveriam se basear nos requisitos do negócio – nos objetivos que *motivaram* o projeto. Parece papo de maluco, né? Afinal, não é natural ou óbvio que seja assim? Envergonhadamente devemos admitir que não, não é natural.

    Chegamos em um estágio em que o usuário pede, “faz uma tela assim e assado”, e a equipe vai lá e faz. Aquela “tela”, que aos olhos do usuário parece algo banal, logo vira uma dor de cabeça coletiva: não se comunica bem com outras aplicações ou módulos de um mesmo sistema; quebra a ordem conhecida de um processo de negócio; apresenta regras de negócio conflitantes com outras previamente implementadas; recebe frequentes pedidos de alterações etc. Mas o que nos interessa aqui, agora, é que demandas deste tipo carecem de sentido: O que o negócio ganha com isso? Ou o que ele perde se a solicitação não for atendida? E quando chegarem dúzias de demandas parecidas, quais merecerão o início da fila?

    O processo não pode ser mecânico assim. TI não é padaria, com todo respeito às padarias. E usuário, mesmo quando guiado pelas melhores das melhores intenções, não deveria invadir o domínio da solução como no exemplo acima. Ele não deveria pedir uma tela, um módulo ou um sistema. Ele deve explicar suas dores, os seus problemas. Se a solução para eles será uma tela ou um sistema, quem dirá é a organização de TI. E TI toma boas decisões quando as fundamenta através da Análise de Negócios.

    O bom analista de negócios não começa seu trabalho em um projeto anotando os requisitos de um usuário para determinada tela, módulo ou sistema. Ele começa tentando entender e diagnosticar as dores do usuário. O bom analista sabe que nem sempre a solução será um sistema. E é aqui que o trabalho em projetos “custom” se diferencia demais daqueles que na parte anterior chamamos de “pacotes”. Aqui há um problema específico a ser diagnosticado e sanado.

    A necessidade de um diagnóstico rápido e eficaz é o que justifica minha cara de pau de sugerir uma sensível alteração na sequência de perguntas proposta por Dan Roam em “The Back of the Napkin” (Portfolio, 2008). “Por quê” é a primeira pergunta que o analista faz: “Por que este projeto é necessário?”. A resposta e toda a conversa que se desenvolve a partir dela nos ajudam a criar uma das três visões que compõem um modelo de negócios básico, a Visão do Negócio. Esta perspectiva, que pode assumir diversos estilos e formatos, compila todos os objetivos do negócio. Colocando de outra maneira, ela documenta a motivação para o projeto.

    É importante que ela, a Visão do Negócio, não seja confundida com o Documento de Visão. Este apresenta a visão (oh!) da solução. Ao desenvolver a Visão do Negócio, o analista ainda está relativamente distante da solução e sua respectiva visão.

    A visão do negócio pode ser representada por uma única linha em um documento, como por exemplo: “Dobrar o número de visitas realizadas pelos vendedores“. Mas ela também pode ser mais elaborada, como tenta mostrar o diagrama abaixo. A complexidade de um negócio ou a amplitude e criticidade de suas dores determinarão o formato mais adequado para entendimento e documentação¹ dos requisitos do negócio.

    Pois é, apelei para o causo do seu Moreira para dar um pequeno exemplo de diagrama que pode formar a visão do negócio. As duas áreas destacadas mostram todos os requisitos de negócio. O que pode ser apenas uma frase, “Dobrar o número de visitas”, em um diagrama mais elaborado pode ganhar a forma de uma hierarquia de objetivos ou requisitos de negócio. Repare que o “Dobrar nº Visitas” é quebrado em vários objetivos menores. E ele próprio deriva de outro, ou, colocando de uma maneira diferente, é condição para a realização de outro requisito, “Dobrar Faturamento”.

    Muito se fala sobre rastreabilidade de requisitos: “Toli Toli Tolá…” – e a cobla ficou lá², vendendo matrizes de rastreabilidade. Perdão. Para o analista de negócios é fundamental que o aprendizado e desenvolvimento dos requisitos obedeçam uma lógica parecida com a ilustrada no diagrama abaixo:

    A visão do negócio é a representação direta de todos os objetivos e metas, o que chamamos de requisitos do negócio. Todos os demais requisitos, independente do tipo ou nível de granularidade, devem derivar deles. Ou seja, devem mostrar seu *valor* – como apoiarão, direta ou indiretamente, a realização dos objetivos do negócio. Cada caso de uso, por exemplo, deve exibir de forma clara quais são os objetivos atendidos por ele. E estes objetivos devem ter uma ligação nítida com os requisitos de negócio maiores.

    Quando este conceito é bem implementado, a equipe consegue perceber com relativa facilidade o que é e o que não é prioritário em um projeto. No próximo artigo desta série falarei especificamente sobre valor e a priorização de todos os requisitos. Inté!

    .:.

    Observações

    1. Documentação! Palavrinha que causa arrepios, não? Chuto e sugiro que 80% dos artefatos gerados por um analista de negócios vá para o lixo tão logo tenha cumprido sua missão: facilitar o entendimento. Sua manutenção não se justifica na maioria das vezes porque: 1) É cara; 2) É muito frequente. Negócios mudam todo dia. É difícil manter documentos assim 100% sincronizados com a realidade. Acredito que para a maioria das organizações, um diagrama representando cada perspectiva (do Negócio, da Estrutura e dos Processos) seja suficiente. Mas, eu sei: cada caso é um caso.
    2. Não entendeu? Então você não passou sua infância ou juventude no início dos anos 80. Paciência. O “toli toli tolá” era cantarolado pelo Honolável Besoulo Japonês toda vez que ele dava um drible a la Neymar em seu arqui-inimigo, a Cobrinha Azul. Hehe… Ok, sei lá porque me lembrei disso agora. Cobra, Azul, eternamente driblada, Matrizes de Rastreabilidade… há um conjunto aqui… eu sei que tem…
    3. Abstract é outra foto que surrupio da Tanakawho.