O tema começou a me chamar a atenção quando percebi que vários participantes do FAN não eram analistas de negócios (AN’s) de fato, mas luxuosos atendentes de help desk. Seu dia-a-dia não é o apoio a novos projetos mas sim o tratamento de demandas de manutenção em sistemas. Por favor, não estou dizendo que demandas de manutenção não mereçam a alocação de AN’s. Algumas poucas, que de fato representam mudanças no negócio, justificam isso. Acontece que a grande maioria delas, independente do tipo ou porte do negócio, refere-se exclusivamente aos sistemas. Pior, são fruto de sistemas de baixíssima qualidade técnica.

O imenso e incomensurável backlog de manutenção é o inferno de um sem número de departamentos de TI. Ao que tudo indica, muitos acreditaram que os AN’s representariam uma boa resposta. Caro engano. Tão dispendioso quanto aquele de um famoso instituto que registra “recomendações” numa famosa publicação tupiniquim: em um de seus últimos artigos, “ele” falou que estruturas de projeto e de manutenção não precisam ser separadas. E que tal divisão poderia resultar em acidentes. Céus!

Quando projetos e manutenção começam a concorrer pelos mesmos recursos, e dado nosso “tudo é para ontem”, é claro que a manutenção – a necessidade “indriblável” de apagar de incêndios – sempre prevalecerá. Resumindo: se a empresa nutre uma mínima preocupação com seu futuro, deveria ter uma unidade que cuide exclusivamente de novos projetos. E é aqui que os AN’s podem provar seu valor e justificar seus custos.

.:.

Mas, como antecipei lá nas categorias deste artigo, eu não quero falar apenas sobre a análise de negócios. Quero aproveitar a oportunidade para tocar n’outro tema caro e meio raro (por aqui): arquitetura. Já acreditei que SOA (Arquitetura Orientada a Serviços) era uma excelente resposta à crescente demanda por flexibilidade e agilidade. Bom, ela segue excelente. Mas está longe, muito longe de ser uma resposta universal. Muitos daqueles sistemas que conhecemos como “legados” são tão feios, frágeis e gambiarrados que impedem que o “botox” SOA surta algum efeito. Daí que de uns tempos pra cá resolvi ressuscitar um conselho daquele mesmo instituto que critiquei acima: “aposente 2 ou 3 sistemas legados por ano. Ponto.”

O conselho é anterior às ondas EAI (Enterprise Application Integration) e SOA. Mas a cada dia se torna mais necessário e urgente. O fato é que há um imenso abismo entre a arquitetura tecnológica de vários sistemas legados e as demandas atuais. A ploriferação de modernos canais digitais e a crescente pressão que eles excercem sobre aplicações antigas justificam a incorporação desse discurso de urgência. E é importante notar que não estou falando apenas de coisas de museu como Cobol², Oracle Forms, Delphi, Visual Basic, Fox ou Clipper. Tudo o que nasceu na primeira geração da Internet deve ir para o lixo. Devemos aceitar o fato de que nossos primeiros sites e aplicações Web, mesmo aqueles com “apenas” 5 ou 6 anos de vida, serviram para aprendizado. Mas hoje são pesadíssimas âncoras que impedem nossa evolução. Cada centavo gasto em sistemas antigos (feios, frágeis e gambiarrados) é centavo jogado fora. Mesmo que o centavo seja contabilizado em rubricas chiques como SOA, BPM, BI e afins.

A aposentadoria de aplicações de negócios está longe de ser uma coisa trivial. São raríssimas as empresas que utilizam um processo de gerenciamento do ciclo de vida de sistemas³. Nós desenvolvedores só falamos, através de nossas mágicas metodologias, do ciclo de vida de projetos. Pouquíssima ou nenhuma atenção é dada ao sistema entregue. Até o dia seguinte ao término do projeto, quando aquele sistema vira “legado” e um novo foco de incêndio a ser combatido diariamente.

.:.

Auren Hoffman escreveu um excelente artigo sobre “Ser Bom em Matar Coisas“. Um bom líder de TI deve saber hora e forma de matar (ou aposentar) seus sistemas. Como já falei demais, guardarei “hora e  forma” para futuros artigos. Inté!

.:.

Observações:

1. O colega Saulo Arruda citou, num comentário lá no Graffiti, que uma grande empresa de Telco ainda demanda projetos em ASP (não .Net) com uso incondicional do Windows 2000 e IE6. Falou também de uma montadora com a mesma arquitetura. Qualquer coisa feita em ASP deveria ir para o lixo incondicionalmente. E escrever projetos novos em ASP é o mesmo que “tentar apagar incêndios com etanol”, para surrupiar e adaptar um antigo dito de Fred Brooks (utilizado em outra situação, é claro).
   Pedindo licença aos letrados, tentarei explicar aos leigos porque ASP (Active Server Pages) é uma das coisas mais medonhas e perigosas já inventadas em nossa área. Pensem num texto qualquer escrito de maneira desestruturada e acidental em três dialetos distintos, todos misturados. Três dialetos mais ou menos assim: a língua de participantes do BBB, a linguagem cifrada que a geração Y usa em sites de relacionamento mais um manuscrito original de um Jack Kerouac bêbado. ASP é assim. E na mão de programadores eXpertos vira poesia pura.
2. Há quem diga que Cobol se modernizou. Tem também aqueles que defendem que ainda não inventamos nada para substituí-lo em grandes corporações (o que me faz pensar se Google, Amazon e afins são pequenas). De qualquer maneira, como não vejo a carinha dele (Cobol) há muito tempo, deixo a dúvida no ar.
3. Para falar a verdade, só conheço uma proposta formal de processo que prevê o gerenciamento do ciclo de vida de sistemas. Ele atende pelo nome EUP (Enterprise Unified Process) e foi criado por Scott Ambler. Sim, podemos dizer que é um irmão bastardo (e ainda não reconhecido) do RUP.
4. A imagem utilizada, Tändsticka, é do brandbild e foi liberada como CC-by, por isso está aqui.

Antes, os créditos: foi o André Wolff quem deu a sugestão de usar um desenho parecido com aqueles mapas que apareciam nos livros da Wrox. E algumas caixinhas acima só apareceram por causa de depoimentos (e desejos) dos colegas Leandro e Ronan.

Talvez o meu rabisco não dê esta impressão, mas ainda há muito espaço a ser preenchido ali. Tentei destacar o fundamental, inclusive no tópico ‘Formação Complementar’. E, claro, não contemplo nenhum treinamento de ‘Habilidades Sociais’ (Soft Skills). O desenho trata exclusivamente de ‘Habilidades Técnicas’ (Hard Skills). Cabe uma breve descrição de cada caixinha:

FAN – Entendendo o Negócio é o programa que ‘roda mundo’ há pouco mais de um ano. Sua versão ‘oficina’ (workshop – 7 horas) dá uma visão geral de tudo que está inserido no tema “Modelagem de Negócio”. O curso (35 horas) permite o detalhamento e prática de alguns temas, particularmente a modelagem de negócios com UML e sua extensão EPBE (Eriksson-Penker Business Extensions).

A relativa complexidade da EPBE e, principalmente, da Modelagem de Negócios, justifica a existência de um módulo avançado, o FAN – Modelando Negócios com UML/EPBE. Imagino um curso 100% prático, com a modelagem de um negócio “inteiro”. Teria algo entre 32 e 40 horas. Imagino… teria… Sim, por enquanto este módulo é só uma idéia.

FAN – Business Patterns  segue no mesmo caminho. Só o livro de Eriksson e Penker apresenta algumas dezenas de patterns. Debatê-las e praticá-las em um treinamento faz todo o sentido. O problema aqui é nosso nível de maturidade quando o assunto é modelagem de negócios. Ou seja, é idéia para a próxima Copa do Mundo. E olhe lá!

Apesar de meu “apego” à EPBE, não posso ignorar a crescente demanda por profissionais que dominem a Modelagem de Processos de Negócios com BPMN. Não tenho condições de oferecer tal treinamento. Por isso este módulo não tem a marca “FAN”. É o mesmo caso do Modelagem com Aris/EPC.

Destaquei dois módulos em Formação Complementar que estão diretamente relacionados com a Modelagem de Negócios: i) Balanced Scorecards & Mapas Estratégicos, ferramentas que enriquecem consideravelmente um modelo de negócios – facilitando o entendimento de objetivos, metas, oportunidades e problemas; e ii) BPM (Business Process Management), um universo em si. Tanto que, neste ponto, imagino apenas um treinamento de introdução ao BPM. Reparem, BPMN está em outro canto.

Segurei a tentação de colocar caixinhas SOA e Arquitetura Corporativa aqui por dois motivos: estamos tratando da Formação de Analistas de Negócios. Lotar o módulo Formação Complementar pode gerar muita dispersão de atenção. Mantive o básico. Pelo menos, enquanto as duas áreas de cima não estiverem melhor resolvidas. Vamos então ao amplo e “polêmico” módulo Engenharia de Requisitos:

FAN – Entendendo o Usuário também faz parte do programa que tenho apresentado. A oficina (7 horas) trata do básico, com ênfase no Desenvolvimento de Requisitos. O treinamento de 35 horas permite uma maior exploração de algumas técnicas, particularmente a especificação de casos de uso e a realização e facilitação de entrevistas, sessões JAD etc.

Como temos visto no fórum, o tema ‘Casos de Uso’ é mais cabeludo e incompreendido do que imaginamos. Por isso ele merece um módulo adicional, Escrevendo Casos de Uso, que desenvolvo há 2 meses. Deve se transformar em um curso prático, de 40 horas. Isso tudo? Sim, pelo que descobri, o tema merece. Mas deve existir uma versão oficina (7 horas) também.

E faz todo o sentido que o roadmap contemple também o módulo Escrevendo Users Stories. É uma alternativa aos casos de uso. Tenho lá minhas restrições, mas não posso ignorar sua adoção e eficácia em alguns projetos. Só não me habilito a formatar e oferecer tal treinamento.

Assim como, por enquanto, me manterei relativamente distante do Gerenciamento de Requisitos. É importante destacar que quando falo Gerenciamento de Requisitos estou falando também de Gerenciamento de Mudanças.Coloquei aqui apenas dois módulos: No OpenUP e No Scrum. (Obs: “No” não está em inglês, ok?).

Derivam deste último módulo duas sugestões para a formação complementar: Gerenciamento de Projetos e Scrum. Não é para o AN se bandear para o gerenciamento de projetos, please! Acontece que suas atividades se entrelaçam demais com aquelas de um gerente de projetos. É legal que ele conheça a disciplina de uma forma mais ampla.

Por fim, abri um módulo que é meu “xodó” mais recente: uma oficina que exercite exclusivamente as diversas técnicas de descoberta, aprendizado e descrição de requisitos: Entrevistas, JAD, 6 Hats…  Xodó meu, não sei se há demanda. Quero crer que sim. É outro item de meu backlog que anda clamando por atenção. Sua aparição aqui pode dar o empurrão necessário.

Aliás, a grande motivação para este post é exatamente essa: empurrões! Algumas definições & idéias! E, claro, uma deixa-provocação: será que alguém (alguma instituição) consegue oferecer todo esse roadmap como um programa único? Alguém aí quer tentar preencher as caixinhas não assinadas? E colocar novas caixinhas? É isso. Inté!

É claro que é sério. Na maioria das empresas é. O problema é mudar uma cultura de décadas de “cara-caixa-preta”. Não são poucos os exemplos de modelos, processos e metodologias que colocam TI como um fim e não um meio. Não por acaso, a Análise e Modelagem de Negócios é a disciplina mais ignorada em projetos de TI, particularmente em iniciativas para desenvolvimento ou implantação de sistemas. É comum que a Modelagem de Negócios seja vista como papo furado, desperdício ou algo do tipo.

A edição 903 da revista Exame (10/out/2007) apresenta uma série de artigos especiais. Mostra como o Brasil mudou nos últimos 40 anos. Alguns números são tão espetaculares que nos fazem questionar essa eterna mania de achar que tudo por aqui está ou dá errado. Ops… o assunto mudou ou o editor viajou? Não.

Pense nas empresas que estão aí há 40, 20 ou 10 anos. Como elas passam por tantas ondas de mudanças? Processos de negócio envelhecem e adoecem. Quando o mesmo ocorre com recursos da empresa, máquinas por exemplo, eles são trocados. E o que acontece com os processos de negócio?

Em grande parte das vezes eles são ajustados ou remendados. Várias empresas optaram pela implantação de ERP’s – grandes sistemas corporativos que em seu conceito original propunham a adoção de novos processos. Grande parte dos problemas com a adoção desse tipo de solução acontece exatamente na diferença entre processos existentes e os novos desenhos.

Mas a questão está longe de ser uma exclusividade das empresas mais velhas. Mesmo empresas muito novas convivem diariamente com a pressão por mudanças em parte de seus processos de negócio. A demanda ocorre, particularmente, nos processos primários – aqueles que lidam diretamente com o mundo exterior, com os clientes.

Processos ultrapassam as fronteiras de uma organização. Para frente, na direção dos clientes, e para os outros lados, no sentido dos fornecedores e parceiros de negócios. Na economia atual, têm nítida vantagem as empresas que oferecem processos abertos e flexíveis. Então, testemunhamos o surgimento de propostas muito boas para a realização dos requisitos de abertura e flexibilidade, notadamente SOA (Arquitetura Orientada a Serviços) e BPM (Gerenciamento de Processos de Negócio).

Mas, como quase sempre ocorre em TI, caixinhas e ferramentas monopolizam discursos, press-releases e budgets. Passa desapercebido o fato de que processos remendados, velhos e doentes seguirão remendados, velhos e doentes numa SOA ou sob os cuidados de um BPMS. É muito velha a máxima que diz que “engessamos processos equivocados”. Tão antiga quanto nossa teimosia em ignorá-la.

A Análise e Modelagem de Negócios, uma das duas macro-disciplinas que formam o corpo de conhecimentos dos Analistas de Negócios (AN’s), está longe de ser papo-furado ou desperdício. Na realidade, quando bem executada, pode ser a diferença entre um projeto de sucesso e o total fracasso.

A correta compreensão dos requisitos do negócio – seus objetivos e as metas específicas de seus processos – possibilita que projeto e produto tenham um horizonte e escopo bem definidos. Por isso a modelagem de negócios é bem mais que o mapeamento de processos. Ela pode compreender o estudo da estratégia da empresa, suas oportunidades e limitações, estrutura e relações.

O que não pode significar, de maneira alguma, que projetos de TI devem ficar ‘congelados’ por um bom tempo, aguardando a realização da tal Modelagem do Negócio. Trata-se de um mito bastante comum que acompanha a disciplina. Uma primeira visão, a primeira iteração, pode demandar apenas alguns dias. E ela ocorre de forma simultânea com sua co-irmã, a Engenharia de Requisitos (a outra macro-disciplina que forma BoK do Analista de Negócios, aquela que mereceu maior atenção do BABoK).

Ao incorporar práticas de Análise e Modelagem de Negócios em seus processos para desenvolvimento ou implantação de sistemas de informação, a organização fortalece equipes e projetos. Indica que está falando sério quando fala em alinhamento estratégico. Entende que o negócio é tudo o que importa. Afinal, quem paga a dolorosa?

Modelagem de Negócios é o primeiro módulo do curso para Formação de Analistas de Negócios, que o finito realizará em conjunto com a Tempo Real Eventos. Conheça mais detalhes sobre o curso, e veja aqui o seu conteúdo programático.

Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que “não via utilidade nos AN’s”.

Contei a “estorinha” no workshop e muitos pegaram carona na provocação: “você acredita nos AN’s e em sua aposta?” Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

“Abrir a ‘caixa preta’ que é a organização de TI das empresas”
– Gilson Silva

“Alinhar TI com o negócio”

• “O Alinhamento deve mostrar evoluções no plano de negócios”
• “O Alinhamento se mantém atualizado na medida em que o negócio evolui”
• “O Alinhamento ultrapassa obstáculos aos seus propósitos”
• “O Alinhamento é planejado”

– Paul Strassmann

E aí vieram SOA, BPM, ITIL, SOX… todas buscando, de uma forma ou de outra, o tal “alinhamento”. Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN’s e AN’s de TI são “negócios” diferentes estão um tanto equivocados . Negócio é negócio. Ponto.

Momento “Catorze Zero Meia”

Leitores do finito interessados em participar da próxima edição do workshop “Formação para Analistas de Negócios” acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

1406 + “modelito vivarina”: todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

“Desgraça pouca é bobagem”, como a gente costuma falar aqui nas Geraes.

* Válido para os 20 primeiros.
(ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas…)

1. Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul…
2. The Squandered Computer
   Paul A. Strassmann – The Information Economics Press (1997).
3. UML for the IT Business Analyst
   Howard Podeswa – Thomsom / PTR (2005).

O IIBA segue os passos do PMI. Ou seja, lança um ‘guia para o corpo de conhecimentos’ e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
.

Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

“Enterprise Analysis”, segundo capítulo do BABoK, é descrita como “uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução “.

Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham “momentos”, independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

Quero crer que, com a demanda gerada pelas ‘ondas’ BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

Há muito tempo o tema me persegue. Em 98, logo que cheguei em Sampa, entrei numa briga surreal para conseguir justificar, contratar e treinar 2 Analistas de Negócios. Minha primeira palestra aberta, realizada nos idos de 2002, foi sobre um dos dois principais conjuntos de disciplinas que devem ser dominados por um AN: a Engenharia de Requisitos. Nos últimos tempos, com a confirmação das propostas SOA e BPM, a importância e a necessidade de Analistas de Negócios cresceram ainda mais. Ainda assim, suspeito que pouco se sabe sobre eles e suas funções.

Por isso comecei a compilar minhas experiências e meus achados com o intuito de lançar um workshop e um treinamento. Eles apareceram no meu ‘cardápio’ deste ano. O primeiro workshop aberto, chamado “Formação para Analistas de Negócios“, será realizado pela Tempo Real Eventos. Acontecerá no próximo dia 19/junho (uma terça-feira), em Sampa. Dura o dia todo e tem 50 vagas.

Update: a data mudou. O workshop será no dia 20/junho (quarta-feira).

Há tempos um pessoal mais próximo me cobra: “por que você não escreve um livro?”. Minha resposta era sempre a mesma: “não tenho assunto”. Caramba, nesta semana completo 3 anos de blogs. Só no Graffiti são mais de 1400 posts. Mas eu realmente nunca tinha achado uma “lacuna”. Não iria “chover no molhado” com mais um título sobre gerenciamento de projetos, apesar de achar que existem boas oportunidades e áreas pouco cobertas (TOC, OpenUP, Scrum), particularmente em língua portuguesa. Também não tenho como escrever sobre reuso e gerenciamento de ativos de software. Careço de mais e melhores experiências.

Mas quando vi que a minha apostila para o curso “Formando Analistas de Negócios” estava ficando grande demais – o curso tem 80 horas – a ficha caiu. Caramba, está aí meu primeiro livro. Era tão óbvio, estava tão ‘colado no nariz’, que quase perco a oportunidade.

Utilizarei um ‘draft’ do livro como apostila, tanto para o workshop quanto para os treinamentos. Será uma forma legal de validar os escritos – um tipo de “versão beta”. Alguns exercícios e exemplos que pintarem nos eventos devem ser incorporados ao texto final. E, claro, utilizarei este blog para breves pesquisas, sugestões, críticas e também para documentar o andamento do processo.

Conteúdo programático e outras informações sobre o workshop já estão no site da Tempo Real Eventos. Se quiserem conversar comigo sobre o evento ou o livro, fiquem à vontade.