Atualização em 15/jan: Link que faltava para o evento "Análise e Modelagem de Negócios".


Antes de mais nada: que 2008 seja um ano muito jóia para todos, cheio de realizações. E, principalmente, de muita paz e saúde.

Em 2008, finalmente, o FAN (Formação de Analistas de Negócios) começa a ultrapassar as fronteiras de São Paulo. RJ e PA* estão na mira, mas a "estréia" acontecerá na Região Sul, mais precisamente na belíssima Florianópolis.

A colega, promotora e organizadora, será a Innovit. E o evento chegará em seu formato completo, ou seja, dividido em dois módulos. O primeiro é "Análise e Modelagem de Negócios", programado para o dia 29/fev.

No dia 28/mar (um dia após o lançamento oficial do livro) acontece o "Engenharia de Requisitos". Floripa receberá o novo formato do FAN, desenhado para ser extremamente prático. As oficinas (conhecidas como 'workshops' antes daquela proposta do deputado) são compostas assim: 50% de teoria e 50% de exercícios. Os ares de Floripa farão muito bem ao conteúdo. Espero retribuir da melhor maneira possível.


Mas Sampa segue Sampa e, claro, eu sigo por lá. No próximo dia 31/jan acontece a 2ª turma da oficina "Engenharia de Requisitos". Via Tempo Real Eventos, como sempre.

E a estréia da oficina "Análise e Modelagem de Negócios" ocorrerá em São Paulo, dia 26/fev.

Como a turma que passeia por aqui já sabe, esta é a parte mais "polêmica" da Formação de Analistas de Negócios. Há aqueles que pregam que essa atividade ocorra ANTES de um projeto de TI. E, mais ainda, que não seja uma responsabilidade da área de TI. Procuro mostrar neste evento que não é bem assim. E traço o limite que separa a Análise e Modelagem de Negócios de iniciativas de reengenharia e afins. O objetivo aqui, para dizer de maneira bem resumida, é a compreensão do problema, o entendimento do negócio. O programa do evento está nesta página.


Bye Bye, Blogger

Pois é, este é o penúltimo post do finito neste espaço. Passou da hora dele ter um espaço um pouco mais "nobre". E bem mais rico. Estou maravilhado pelo Wordpress e portando todo o blog para um domínio próprio. Todo o histório de quase 4 anos será transportado para lá. Mas eu não desativarei este endereço tão cedo. Acontece que o Google favorece seus endereços em alguns casos. Mas.. penúltimo? Sim. O último será a comunicação dos novos endereços. Novos? Pois é, terei variações de feeds RSS por assunto (categoria). Por isso serão vários endereços. Mas prometo uma transição tranquila.


* Região Sul, Rio, Pará. Gostaria muito de descobrir também um parceiro no nordeste. No próximo dia 31, por exemplo, terei um participante da Microsoft de Recife! Pô, ele gastará mais com avião e estadia do que com o evento.

Mas, o que mais me chateia é a confirmação de que "santo de casa não faz milagre". Não tenho nada programado para minha querida terra natal, Minas! E olha que, tirando São Paulo, é o estado que mais participa dos eventos. Já tive gente de BH, Uberlândia, Lavras, Santa Rita do Sapucaí e Alfenas nos eventos. Pena, mas seguirei procurando um bom parceiro mineiro.

Marcadores: análise_de_negócios, analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, evento

2.600km em 3 semanas. Tudo via asfalto (e buracos). Nos últimos 15 dias, dois workshops em Sampa: a 4ª turma do FAN (Formação de Analistas de Negócios) e a 1ª turma do 1º filhote do FAN: Engenharia de Requisitos. O cansaço é grande, mas valeu o esforço. Valeu bem mais do que eu esperava.

A 4ª turma do FAN marcou a despedida de um formato. Quando ele voltar, em fevereiro de 2008, será direcionado para coordenadores de projetos e gerentes de TI. A intenção será mostrar a criticidade e importância dos Analistas de Negócios (AN's) em projetos e organizações de TI. Será o primeiro de uma nova série sobre Alinhamento Estratégico. A série será composta de maneira 'bottom-up': começarei dos AN's, passarei por processos de desenvolvimento até chegar em arquitetura corporativa. (Estou pensando alto, mas é meu primeiro plano para 2008).

E a prestação de contas (rendiconti) da 4ª turma (07/nov)? Sem querer, ela serviu como experiência para um novo formato. A turma era menor. As interações foram mais freqüentes e ricas. Aliás, minha grande "derrota" foi a terceira turma. Não consegui criar "liga" com a platéia, e o evento terminou com uma hora de antecedência. Na 4ª, repetindo o mesmíssimo roteiro, o resultado foi consideravelmente superior. O problema com a redução do número de participantes é o custo. E, sinceramente, não queria que esses eventos ficassem caros. Estamos, Tempo Real Eventos e eu, analisando possibilidades.

Uma certeza: a "oficina" de Engenharia de Requisitos merecerá uma 2ª turma já em janeiro, dia 18. O FAN, em 2008, aparecerá como dois eventos "levemente acoplados": Modelagem de Negócios (1ª turma dia 31/jan) e Engenharia de Requisitos. Como no evento de ontem, pelo menos 50% da carga horária será composta de exercícios. Ou seja, "oficina" de verdade.

Não preciso esconder, temia muito pelo evento de ontem. Lotação esgotada, era a primeira aparição pública do "Engenharia de Requisitos". Na quinta-feira da semana passada, retornando para Vga, deu um "estalo" e resolvi remontar todo o evento (que até então pegava carona nos exercícios que eu havia elaborado para o curso completo de Formação de Analistas de Negócios). Minha preocupação: o negócio e respectivo projeto-exemplo eram relativamente complexos. Eu temia que tal complexidade desviasse o foco de meu principal objetivo: reforçar conceitos, práticas e métodos que formam a Engenharia de Requisitos. Passei sexta e sábado remontando praticamente metade dos 120 slides do evento.

Para minha satisfação, o workshop foi um grande sucesso. O que não significa que foi perfeito. Três participantes reclamaram a não execução integral do roteiro que estava no site do evento. Na revisão, acabei reforçando os exercícios em detrimento de algumas partes exclusivamente teóricas. Mas, na conta final, os participantes gostaram muito. Os exercícios, simulando entrevistas, workshops, sessões de brainstorming e a elaboração de casos de uso, se provaram bem legais. Eficazes no reforço de conceitos e práticas. Em outro post (que só virá depois que eu pagar uma certa dívida com a série sobre EPBE) comentarei um "acidente" que enriqueceu demais a "oficina". No meio do acidente, perdidos numa imensa nuvem de fatos, idéias e requisitos, um participante concluiu: "Isso acontece em todo projeto!". Sem perder muito tempo, vimos como é possível "domar" o projeto mesmo naquela fase mais "selvagem". Mesmo em projetos que requerem muita "selvageria" (aka Criatividade). Mas, como eu disse, é assunto para outro post.

Para a realização do workshop pedi o reforço de 5 "monitores": pessoas que haviam participado de turmas do FAN e que me ajudariam nos exercícios. A turma foi dividida em 5 grupos. O evento não teria o mesmo resultado não fosse a imensa colaboração de Celso Cândido, Jean Streleski, Nilton Nakate, Rafael Kiss e Reinaldo de Oliveira Castro. Registro aqui meu sincero agradecimento. Devo agradecer também toda a turma que participou. O nível era excelente, o que ficou evidente logo nas primeiras discussões. Eles enriquecem demais os eventos relatando suas experiências, dores e necessidades.

Portanto, nesta reta final para a liberação de todo o material desenvolvido para a Formação de Analistas de Negócios, só tenho uma coisa a lamentar: a não realização do curso de Modelagem de Negócios que estava previsto para o início de novembro. Como eu não seria nada honesto se 'podasse' o material, fazendo com que o curso tivesse uma carga horário menor que 35 horas (70 no total, considerando o módulo II sobre Engenharia de Requisitos), tenho que rever a oferta. Realizá-lo aos sábados? Oferecer como treinamento remoto? Sinceramente, ainda não descobri o melhor formato. Mas, tenho certeza, ele sairá ainda no início de 2008.


E ainda não fechei a agenda de 2007 para os eventos gratuitos em escolas, faculdades (públicas ou privadas) e entidades sem fin$. Para minha felicidade, talvez eu finalmente consiga promover um deles em minha terra natal, Minas. Mais precisamente em Lavras (UFLA). Tô torcendo muito por isso. Outra oportunidade é São Carlos. Estou torcendo para o Reinaldo achar uma data. Final de ano é difícil, mas estamos brigando para viabilizar outras viagens do FAN. Mais 2 mil e tantos kilômetros de asfalto farão muito bem para o conteúdo.

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos

Como eu disse no último post, começo agora o último sprint do processo de redação do livro "É o Negócio, Beócio!". De acordo com o cronograma, no dia 31/dez entrego os originais para a gráfica. Como previsto, preciso aumentar o número de stakeholders-colaboradores. Por isso a agenda de eventos ganha outras datas, novas praças e novos formatos.

Para o dia 7 de novembro (quarta-feira) está programada a 4ª edição do FAN - Formação de Analistas de Negócios - em seu formato tradicional. Quarta edição em Sampa, novamente no Centro de Convenções Pompéia. Provavelmente será a última turma do ano em terras paulistas.

A turma da região Sul terá outra oportunidade. A Innovit promoverá uma turma do FAN em Floripa-SC, no dia 5 de dezembro (quarta-feira). Provavelmente o workshop será encaixado em um evento maior. Com desconto para a estudantada e tudo o mais. Em breve divulgo maiores detalhes.

Antes dele, brotará em Sampa o primeiro filhote do FAN: um workshop sobre Engenharia de Requisitos, também promovido pela Tempo Real Eventos. Está agendado para o dia 13 de novembro (terça-feira), no Centro de Convenções Pompéia. Engenharia de Requisitos ocupa 50% do material de Formação de Analistas de Negócios. Mereceu um workshop exclusivo para que a disciplina seja explorada com maior profundidade (uma antiga solicitação). Será repleto de exercícios de desenvolvimento e gerenciamento de requisitos. Simulações de entrevistas, workshops e sessões de brainstorming estão previstas. A confecção de casos de uso e documentos auxiliares também. Os participantes terão a chance de usar vários "bonés" durante o evento: Analistas de Negócios (claro!), usuários, desenvolvedores, coordenadores... O workshop deve ser encerrado com a elaboração de um belo, memorável, objetivo e "vendedor" Documento de Visão.

Mas a parte prática da outra metade do FAN, a Análise e Modelagem de Negócios, não foi esquecida. Ainda em novembro, também em Sampa, acontecerá um treinamento de 35 horas (!). Imersão total nesta disciplina que é tão negligenciada em projetos. Maiores detalhes sobre o treinamento eu divulgarei em breve. Mas anote aí na agenda: será em novembro (apesar dos 3 feriados!).



Apesar da agenda meio lotada, segue disponível a oferta de levar qualquer variação dos eventos acima para escolas, faculdades e universidades. Vascão* (ou seja: na faixa, grátis, zero800...). Quem se interessar, por favor, fale comigo.

* Depende da localidade e de não causar nenhum tipo de prejuízo para outros profissionais ou empresas.

Marcadores: análise_de_negócios, analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, gerenciamento_de_projetos

Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido "pensá-lo"? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN's! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN's certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

Para começar, a forma muito legal que o Ambler apresenta o AN:

Na teoria, a idéia de ter AN's tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela "poluição informativa" - lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN's claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os "tech weenies" de TI e os "business morons" para os quais o sistema é construído.

Jóia né? Mas aí apareceram os "poréns". Comento abaixo cada um deles, na seqüência original:

1. AN's não apresentam as habilidades corretas
   pv: Natural, afinal ainda não temos um mínimo 'corpo de conhecimentos' consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
   AN's são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN's não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos "analistas-programadores". Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
   
   
2. AN's podem ter uma influência muito negativa no projeto
   pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN's que não funcionam como canais, mas sim como uma "parede" entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
   
   
3. AN's podem ficar desatualizados
   pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito... muito jeito.
   
   
4. AN's podem ser uma barreira para a comunicação
   pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a "tradução livre". Explico: o AN começa a contar apenas "boas notícias" para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
   
   
5. AN's podem reduzir a influência dos stakeholders
   pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de "firewall" para a equipe.
   
   
6. AN's analisam MUITO
   pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da "analysis-paralysis". Simplificando: se o AN for jogado em um processo baseado no ciclo "cascata" (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
   Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo [1]. Se ele resolver executar seu trampo "numa tacada só", só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
   * São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).
   
   
   
7. AN's reduzem o feedback
   pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers [2], um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
   
   
8. AN's reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
   pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue "tirar o pé da jaca". Ou, colocando d'uma forma menos agressiva: "não tira o boné de jeito nenhum". Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN's. E aprender muito com os bons AN's.
   

Notas:

1. Agility and Discipline made Easy: Practices from OpenUP and RUP
   Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
2. More About Software Requirements
   Karl Wiegers. Microsoft Press (2006).

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios

Seqüência de "Tácitos & Explícitos".

Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em "More About Software Requirements" [1], faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que "coletamos, descobrimos, inventamos e entendemos". Espero ter passado a correta amplitude do trabalho.

No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção...) de requisitos nestes dois grupos. Veja o gráfico abaixo [2]:


As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o "Fone" ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

• Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
  Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
• Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
  Novamente o cenário ideal exige a presença de dois AN's, um conduzindo a reunião e outro registrando os achados.
• Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
• Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os "agilistas" não erram quando dizem que nada substitui o "tête-à tête". Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O "mapeamento psicológico e sociológico" dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades "sociais" (soft skills): comunicação, negociação, intermediação, e por aí vai.

Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O "Email" aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

• Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
  Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como "análise Caixa-Branca". Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
  Código Executável: ou "análise Caixa-Preta", mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
  Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então...)
• Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos "workshops" (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
  Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
  Versões de Testes: ou o "processo Google" de validação, com suas quase eternas versões "beta". Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.
  

Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns "agilistas") gera um certo tipo de miopia no projeto.

Um AN "completo" desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.


Notas:

1. More About Software Requirements
   Karl E. Wiegers. Microsoft Press (2006).
2. Gráfico foi inspirado neste, extraído de
   The Enterprise Unified Process: Extending the Rational Unified Process
   Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).
   

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos

Há uns 6 anos me 'cansei' do estudo de engenharia de requisitos. Técnicas e métodos mudavam, mas mantinham uma sensação de déjà vu. As mudanças eram cosméticas ou uma questão de nomenclatura. As propostas "ágeis" (aspas não tornam o termo pejorativo) colocaram o Conhecimento Tácito na "coluna esquerda" (leia-se: nomearam-no o mais importante). Essa talvez tenha sido a mudança mais significativa nos últimos 10 anos da disciplina. Mas, basta olhar os métodos e técnicas sem muita paixão para descobrir que tem muito 'revival' ali, pouca coisa original.

Foi quando decidi olhar a estranha disciplina "gestão do conhecimento" com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre "Gestão de Conhecimentos Inter-Projetos" [1], que acabou inspirando meu trabalho sobre "Aprendizado Inter-Projetos". Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.


O trabalho que me 'pegou' foi o clássico "Theory of Organizational Knowledge Creation", de Hirotaka Takeuchi e Ikujiro Nonaka [2]. Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):

• Socialização: pessoas trocando idéias, de forma direta, conversando. É um canal rico, já que nossa comunicação não se limita a palavras, gestos e desenhos. Um sorriso pode ter n significados.
• Externalização: pessoas transferindo seus conhecimentos para o papel (ou disco rígido, não importa). Estamos registrando idéias e experiências, de forma que elas possam ser úteis para outras pessoas.
• Internalização: quando são (úteis), acontece a internalização. Ou seja, as pessoas aprendem ao ler um documento, diagrama ou rabisco.
  
• Combinação: por fim temos a combinação, a transformação de um conhecimento explícito (texto, por exemplo), em outra forma de conhecimento explícito (diagrama ou código, por exemplo).
  

Quando trato especificamente de engenharia de requisitos, gosto de dividir o diagrama acima em duas partes: o hemisfério esquerdo trata da coleta, descoberta e invenção de requisitos (estamos aprendendo). O hemisfério direito cuida de como analisamos, modelamos e comunicamos* os requisitos.
* Observação: a comunicação também envolve o quadrante 'socialização'.

Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas "ágeis". É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz "apenas". Mas, infelizmente, muitos interpretam assim.

Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado "meet in the middle":



Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento "mágico" eles "se encontram no meio do caminho", confrontando requisitos, realidades, verdades, mentiras e restrições.

Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.


Notas:

1. Knowledge Management in Inter-Project Learning
   Daniel Fitzek. ITEM-HSG Universität St.Gallen (2002).
2. Theory of Organizational Knowledge Creation
   Hirotaka Takeuchi e Ikurijo Nonaka.
   Publicado em "Knowledge Management - Classic and Contemporary Works". MIT Press (2000).
   

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos

Pois é, já vamos para a 3ª turma do workshop "Formação de Analistas de Negócios". A Tempo Real Eventos já abriu a página de inscrições. Contando as duas turmas, já tivemos 114 participantes. 79 estão participando de um grupo de discussão exclusivo.

Honestamente, eu não esperava um retorno tão positivo. O tema é relativamente novo. Ainda não vejo tanta demanda. Mas, a necessidade, por incrível que pareça, é uma "tendência". Foi isso que li na divulgação de outro treinamento com tema similar. Que seja!

Então seguem aqui algumas dicas e palpites aleatórios:

• Atenção escolas, quem lançar um curso que mire a certificação CBAP (do IIBA) pegará um belo filé. Mas, por favor, cursos sérios! Sem gambiarras.
• Aliás, não sei como se tropicaliza um 'chapter'. Quem trouxe o PMI para o Brasil deve ter o caminho das pedras. Em se confirmando a demanda, o IIBA precisará de uma representação em solo tupiniquim.
• Profissão em fase de criação sofre com muita desinformação. Como já registrei aqui, o BABoK (do IIBA) se concentra em Engenharia de Requisitos. IMHO, Modelagem de Negócios é tão importante quanto. Mas vão existir muitas variações de currículo, tenham certeza. No início, tudo bem. Desde que saibamos a hora de 'desacoplar' (coisa que o PMI, IMHO, não soube fazer).
• A primeira especialização nítida: Desenhista de Processos (com ênfase em BPMS). O nome, com certeza, não será esse. Mas será um cara com muita demanda. Aliás, já é. Mas, cabe ressaltar, não dou muito espaço para ele no workshop. Falta tempo.
  
• [to be continued...]

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios

Aconteceu na última quinta (2/ago), a 2ª turma do workshop "Formação de Analistas de Negócios", promovido pela Tempo Real Eventos. 60 participantes! 10 além do limite esperado. Um tanto além das expectativas iniciais. Ainda não recebi a compilação das avaliações mas, pelos papos pós-evento, tudo indica que foi tão legal quanto a 1ª turma. Uma coisa posso dizer: foi mais dinâmico. O que acabou gerando um pequeno atraso. Felizmente a greve do metrô não nos atrapalhou muito.

[Aos participantes: consegui a proeza de informar o endereço errado do grupo de discussão!! Céus... Por favor, aguardem até a próxima semana (quando receberei a lista com seus emails), para que eu repasse endereços e arquivos. Quem não quiser esperar, me mande um email.]

Como na turma anterior, aguardarei as avaliações para fechar esta prestação de contas. Por enquanto me limitarei a apontar coisinhas que devo providenciar para as próximas turmas (devemos ter pelo menos 3 em setembro, 2 em Sampa):

• Iterativo & Incremental: ainda é uma dificuldade para muita gente. Acho que facilito a vida de todo mundo se levar um exemplo prático completo. Tenho certeza de que o Sr Antonio voltou para casa com a mesma opinião: "É uma cascata disfarçada". Infelizmente não sobrou tempo para brigar com a certeza dele. Mas, se ele ficou com um pouquinho de dúvida, já me considerarei um pouquinho satisfeito.
• Vou reduzir descrições de processos (particularmente o RUP) e deslocá-los para a parte final do workshop. Espero assim abrir mais espaço para exercícios.
• Aliás, vou forçar um pouco mais os exercícios. Alguns deixarão de ser opcionais. Talvez eu até monte algumas "dinâmicas de grupo" (argh!). O único problema é realmente o tempo.
• Foram vários participantes, de ambas as turmas, que sugeriram que o evento aconteça em 2 dias! Passei a bola para a turma da Tempo Real Eventos. Talvez a gente lance uma versão diferente: um dia só para Modelagem de Negócios e outro só para Engenharia de Requisitos. Talvez! Antes disso vou buscar a redução dos temas "menos relevantes". A redução do espaço dos processos é meu primeiro alvo.
• Mas não deixarei de brincar com o POREM e outras bullshitagenzinhas ágeis.
• Tipo: "É difícil saber por onde começar" (trecho de um livro sobre User Stories).
  
• Se a turma sai com boas pistas (sobre onde começar), considero que parte dos meus objetivos foi atingida.
• Talvez assim fique mais fácil entender e aceitar o "É o negócio, Beócio!"

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios

Última parte de uma pequena série que tratou dos problemas da Anne, uma Scrummaster que foi ligeiramente afetada por um curso de Análise de Negócios. Como adiantei na semana passada, vou criar caso questionando algumas estórias.


Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião[1] popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos[2], as User Stories são formadas por três elementos:

• Cartão: onde escrevemos as estórias [3];
• Conversas: que nos levariam a entender e detalhar as estórias; e
• Confirmação: o 'the end', o fim da estória.
  

A motivação para tamanha invenção gira em torno da palavrinha 'documentação' (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo [4] reforça: "os cartões representam os requisitos do cliente, mas não os documentam". Vai na linha de um mestre-pacificador (mezzo tucano) [5] que vive insistindo: "gente, modelagem não é documentação... modelagem não é documentação... isso é um mito". Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: "Nós organizamos as cento e poucas estórias por processos de negócios...". Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) [2]: "É difícil saber por onde começar".

[Nuvens negras fecham o céu. Dois relâmpagos, como flashes do último modelo da Nikon, iluminam a figura de longas barbas esvoaçantes que, do alto da montanha, proclama: "Véio, se tu não sabe por onde começar, já começou errado!"]

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de "organização de estórias". Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo [6].


Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador [7], "um caso de uso é o nosso constructo para um processo de negócio"; "[os modelos de casos de uso] descrevem o negócio e o seu ambiente".

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso [2]:

• Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
• Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
• Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD's e afins por aí.
• Estimáveis: ok, UCP's são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
• Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado - regrinha básica;
• Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que [8]: "Se um requisito não pode ser testado então ele não é um requisito".
  

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de 'casa de ferreiro... espeto de bambu' (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas...



... começando do começo: o Negócio.



Notas:

1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
   
2. User Stories Applied: For Agile Software Development
   Mike Cohn. Addison-Wesley (2004).
   Obs: Mesmo autor do artigo sobre UCP referenciado acima.
3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre "estória versus história"? Pois é, me lembrei deles na hora de traduzir stories.
4. The Power of Stories
   Rachel Davies. XP 2001.
5. Debunking Modeling Myths
   Scott W. Ambler. Software Development (Agosto/2001).
6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
7. The Object Advantage - Business Process Reengineering with Object Technology
   Ivar Jacobson. Addison-Wesley (1995).
8. Requirements-Led Project Management
   Suzanne e James Robertson. Addison-Wesley (2005).
   

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios

Seqüência deste post, onde a Anne, uma Scrummaster, tenta justificar seu desejo por um pouquinho de 'planejamento up front' em seu projeto. Reforço o 'pouquinho' para dizer que não se trata do combatido BDUF (Big Design Up Front). BDUF, BPUF, SPUF... ufs...


Um sintoma que indica que o trabalho da equipe da Anne começa 'muito solto' pode ser identificado na seguinte sentença: "Nós organizamos as cento e poucas estórias por processos de negócio..."

Parece que as estórias são coletadas de uma forma aleatória. Os tais 'workshops para coleta de estórias dos usuários' não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.

Se o AN começar seu trabalho "do início", ele não terá o trampo de "organizar estórias por processos de negócio". Ele[1] realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro - em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.

Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.

Me desculpem o rabisco[2], mas usando uma variação da UML[3] o mapa de processos pode ficar mais ou menos assim:



Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?

Nota: Mapa = um 'pouquinho' de planejamento up front'.


Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as 'estórias'. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.


Observações:

1. Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
2. Todos os diagramas da apostila/livro, por enquanto, estão no padrão "rabisco". Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
3. EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro "Business Modeling with UML", de Hans-Erik Eriksson e Magnus Penker - Wiley/OMG (2000).
   

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios

Uma turma da universidade Anhembi Morumbi está realizando uma extensa pesquisa sobre Engenharia de Requisitos, particularmente técnicas de levantamento.

Repasso aqui o convite para que todos os *praticantes* participem da pesquisa. O 1º questionário já está disponível no site que eles desenvolveram especificamente para o projeto.

Parabéns para a turma. Trata-se de uma importante iniciativa. Rarírissima por essas bandas. Espero ter a chance de conhecer os resultados e comentá-los aqui no finito.

Update: Prazo foi prorrogado para 12/Abril.

Marcadores: engenharia_de_requisitos, estudantada, pesquisa

Extensão do capítulo "Etiquetando Ativos de Software", penúltimo capítulo publicado até agora na série "Gerenciando Ativos de Software".

Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos -- ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: "Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor" [1].

As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou 'forçando' este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?

A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa "nova" demanda?

Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção - observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.

As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.

Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.



O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe "Artefato". O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o "Requirements Knowledge Model" de Suzanne e James Robertson [2], e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker [3].

Todos os requisitos são associados aos casos de uso do negócio que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.

Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso do produto ou serviço que, segundo o padrão RAS, também são cadastrados como "Artefatos". Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.

Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.

É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.


Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no 'padrão de escrita' da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.

* Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de "requerimentos".


Referências:

1. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
2. Requirements-Led Project Management
   Suzanne Robertson e James Robertson
   Addison-Wesley (2005).
3. Business Modeling with UML - Business Patterns at Work
   Hans-Erik Eriksson e Magnus Penker
   Wiley (2000).
   
   

Marcadores: engenharia_de_requisitos, gerenciamento_de_ativos, mps, reuso, soa, spi