Tag: FAN

Rendiconti: Outubro Quente

Quentíssimo. Na última semana peguei 38°C no Rio e 34°C em Sampa. O calor de Sampa incomoda mais – falta a brisa. Mas outubro não foi* quente só no clima. Apresentei 6 oficinas em 12 dias! Quatro no Rio, em evento fechado, o que me impede de fazer uma “prestação de contas” aberta. Só posso dizer que foi em uma grande empresa. E que o que encontrei lá me deixou… vamos dizer: cabreiro. Tanto que um novo tema foi inserido na fila de artigos que estou devendo: algo como “Detonando AN’s”.

É a primeira vez que cito um evento fechado aqui no finito. Já levei o programa FAN (Formação de Analistas de Negócios) para empresas dos mais diversos portes e ramos de atividade. De empresas com 5 funcionários até “monstros” com cerca de 8k “colaboradores”. Não disfarçarei nunca minha preferência pelas menores. Além de saber o que querem, são mais corajosas. Em empresas maiores é muito comum encontrar o detestável “sempre foi assim – não vai mudar”. Um conformismo diretamente proporcional ao tamanho do abacaxi que deve ser descascado diariamente. Pior: um tipo de alienação que só faz aumentar os problemas.

Talvez eu me arrependa, mas preciso destacar outro ponto: as pessoas. Agora não falo dos eventos, mas das cidades como um todo. É um choque, particularmente para um mineiro, a transição Sampa – Rio – Sampa no intervalo de 3 dias. Não parece que as duas cidades são separadas por meros 400km. Não fosse a língua eu poderia dizer que são dois mundos totalmente diferentes. Tenho “traumas” anteriores na Cidade Maravilhosa. Mas eles estavam, de certa forma, esquecidos. As últimas visitas os ressuscitaram. Não causa espanto o fato de muitas empresas e associações saírem de lá. Ok, tô no limite (da auto-censura). Encerrarei assim: detesto o Diogo Mainardi. Salvo engano, ele vive no Rio. Então agora entendo uma obra dele: o Rio parece sim “Cronicamente Inviável”. Não fosse aquele oceano de petróleo que acham por lá… Não fosse aquele mar de beleza… Mas talvez sejam esses mesmos os motivos para tantos problemas. Ok, vamos ao que interessa.

Atendendo diversos pedidos, Tempo Real Eventos e eu programamos mais um par de oficinas do FAN em sábados (dias 11 e 18). A grande maioria dos 40 e tantos participantes contratou os dois eventos. Desta vez utilizamos uma sala da Globalcode. Apesar de legal, ainda não é a ideal para esse tipo de oficina. Engraçado, mas por que será que é tão difícil encontrar cadeiras soltas em salas de aula? Bem, o fato é que tirando um ou outro desconforto, as oficinas foram memoráveis!

Finalmente encontrei o “ponto” do módulo I, a “Modelagem de Negócios”. Halex, um dos participantes, escreveu em nosso grupo de discussão que o evento foi um “divisor de águas” para ele. Exageros à parte, realmente acredito que consegui trazer esta primeira oficina para o mesmo nível de maturidade em que se encontra o módulo II, “Engenharia de Requisitos”. Sei lá qual a contribuição da minha chatice, mas eu devo ter repetido dezenas de vezes que nós “modelamos um negócio para entendê-lo, não para gerar documentação“. Seria só retórica se as ferramentas apresentadas não fizessem sentido. Engraçado é que, em relação a todas as edições anteriores, eu só acrescentei um novo tipo de diagrama-ferramenta: o PUCS (Process Use Case Support). Mais sobre ele em um futuro (não muito distante) artigo.

No segundo encontro, sábado passado, a turma dispensou “quebra-gelos” e afins. Desde muito cedo demonstraram sua “fome”. Fui no embalo… Pois bem: tradicionalmente consigo aplicar o primeiro exercício ainda antes do almoço, lá pelas 11h30. Desta vez ele só foi possível quando meu relógio já berrava 15hs! Foi-se o “pulmão” (buffer de 1hr) e mais da metade dos exercícios. Um ponto tomou boa parte dos debates: o desenvolvimento “Iterativo e Incremental”. Mas eu consegui completar o programa, encerrando a oficina lá pelas 18h15. Em pleno sabadão chuvoso! E ninguém saiu da sala antes do fim!?! Foi realmente uma turma diferente. Boa, antenada e super sedenta. Mas eu sei que falhei feio na administração do tempo. Não tive coragem de “podar” assuntos paralelos. Na verdade, não vi o tempo passar. Tenho que dar um jeito de “pagar” os exercícios não executados. Sei que eles cobrarão…

* Obs.: Outubro “foi”? Mas ainda é dia 21! Pois é, o ritmo me fez abreviar o mês. E adiar uma oficina previamente programada para o próximo dia 30. Acontece que o backlog aqui tá vazando pelas bordas… Se eu não segurar agora, sai do controle. Inté!

21 de outubro de 2008
Hiper-mega-ultra Prestação de Contas: Sampa, Floripa e Cascavel

Quarenta e tantos dias sem nada de novo por aqui – só uns agendamentos. E, agora, uma prestação de contas? Pois é… E, infelizmente, igualmente defasada. Mas depois eu explico o sumiço. Agora um breve histórico dos 5 últimos encontros – 3 eventos (e menos vírgulas, por favor!).

10 e 24/set – Sampa: a dupla de oficinas. De todos os participantes, 40 e poucos contrataram o par. Este formato de comercialização torna as oficinas mais produtivas. Mas minha memória tem me enganado (“falei sobreisso na oficina anterior?”). O formato também me dá uma segunda chance, a oportunidade de reverter alguma situação. E como eu precisei da 2ª chance. Sei lá porque o encerramento da oficina do dia 10 foi um atropelo só. Claro que deixei uma má impressão. Como praticamente todos os participantes voltaram no dia 24, creio que consegui ‘multiplicar por menos um’ aquela situação.Foi uma turma mais ‘morna’ que a média, mas acho que a culpa é só minha. De qualquer forma, as avaliações foram muito boas.

12/set – Floripa: Só “Engenharia de Requisitos”. Na realidade, um evento ‘bandaid’ que tentou minimizar acidentes comerciais que não merecem nosso tempo. Saí de 34°C em Sampa para uns 12°C em Floripa. Na hora do almoço acusei o baque, pensando que era só cansaço. Não era! Era a 3ª gripe do ano, o que forçou uma drástica revisão de meus hábitos (e dietas). A turma, muito boa, mesclava Floripa, Blumenau, Criciúma e Itajaí. Contei com o apoio do Ronan e do Jefferson, além da visita do Kerber e seus companheiros de escritório de AN. Foi uma turma mais ‘brigona’ que aquela de Sampa – o que sempre enriquece os eventos. As ‘brigas’ tratavam dos temas de sempre: Casos de Uso, Especificação, Documentação…

Aliás, aproveitamos o evento para um breve duelo “Casos de Uso versus Estórias de Usuários (User Stories)”. O Ronan foi ‘convocado’ especialmente para esse teste. A figura ao lado mostra a estória escrita pelo Ronan. Abaixo o caso de uso (surrupiado da turma de Cascavel).

O duelo foi exaustivamente debatido em nosso fórum. A velha conclusão de sempre (“é uma questão de gosto”) é um perigo! Insisto em uma especificação de casos de uso que se limite exclusivamente ao domínio do problema – ao que o usuário precisa fazer. Assim aproximo, conceitualmente, as duas sugestões. Assim a equipe de construção não se vê constranginda por uma especificação fraca (e falsa). Mas as diferenças merecem destaque.

A estruturação da especificação de casos de uso não é uma questão de burocracia. O modelo que sugiro incentiva que o Analista de Negócios (AN) registre alguns dados básicos sobre os requisitos que estão sendo apre(e)ndidos, como seu valor para o negócio (ou Grau de Importância), o dono (responsável) dos requisitos e seu ponto de vista, o processo de negócio em questão etc. São informações que não visam a redução da comunicação da equipe. Pelo contrário, objetivam o enriquecimento dos debates e do conhecimento repassado pelo AN para o restante da equipe. E, como ilustrei no artigo O Parlamento, são informações bastante úteis em alguns processos de tomada de decisões.

O Ronan já disse que gosta de minha sugestão. Outros ‘xispeiros sem preconceito’ também devem gostar do modelo. Se for o caso, não precisa nem chamar de ‘casos de uso’. Que tal “histórias semi-estruturadas”? hehe.. ah… não dá pra colá-las em paredes? Paciência…

26 e 27/set – Cascavel: E que belíssima surpresa foi o evento de fechamento do mês. Não só porque Cascavel é muito bonita e agradável, mas principalmente porque ‘enfrentei’ uma turma muito boa – com 70 participantes! O evento foi promovido pelo APLTIC (Arranjo Produtivo Local – Tecnologia da Informação e Comunicações) do Oeste do Paraná e patrocinado pelo SEBRAE local. Aliás, devo registrar a excelente organização e agradecer toda a atenção que recebi.

O primeiro dia foi de ‘quebra-de-gelo’ – a turma ficou meio quietinha. Mas como é legal quando as oficinas ocorrem em dois dias consecutivos! O dia seguinte, um sabadão ensolarado, foi superquente. Principalmente depois que uma turma de AN’s descobriu que tava fazendo o trampo de alguns Analistas de Sistemas (AS). Foi engraçado mas, se bem entendi, ambos os lados estavam meio insatisfeitos: Os AN’s pelo excesso de trampo; os AS’s pela falta de espaço; ambos pelo volume de atritos. Não sei o que deu, mas muitos falaram que eu havia “mudado suas vidas para sempre”, hehe. Não sabem que também mudaram as oficinas para sempre… Mas isso eu conto depois. Por hora resta dizer que, por uma questão de logística (meu avião estava a 140km de distância, em Foz), a oficina teve 1 hora a menos. E a hora não fez falta? Nenhuma!

Tanto que, depois de muito tempo, tivemos uma turma completando todos os 6 exercícios propostos. E eu prometi registrar aqui qual proposta eu comprei… que dureza! Os grupos eram muito nivelados. O grupo 7, dos Paulos, elaborou protótipos bastante criativos. Mas economizou um pouquinho no caso de uso. O grupo 6, do Ricardo, caprichou mais no caso de uso e fez um protótipo bonitão (com logo da Visa?). O Grupo 9, da Fafita – o grupo que praticamente monopolizou as AN’s, também fez um bom trabalho na especificação de caso de uso. Mas não conseguiu gerar um documento de visão “vendedor”. Aliás, a objetividade do grupo 5 (Tiago) na elaboração da visão merece destaque. Assim como a especificação de caso de uso do grupo 8 (Callian). Resumindo: um grande empate técnico!…Quem faz mais barato? O grupo 5, que deu uma bela torcida na contagem de pontos por caso de uso. Quero ver entregar…

Inté!

30 de setembro de 2008
Um Roadmap para Analistas de Negócios

Quem tem acompanhado nosso pequeno mas agitado Fórum deve ter reparado: ainda há muita indefinição em torno do currículo e do job description de um Analista de Negócios. Os últimos debates, particularmente com o Ronan Lúcio e o Leandro Mendonça, me deram uma grande ajuda em uma decisão: qual item deveria sair de meu backlog (de artigos e temas represados – haha) e vir para cá, para o blog. Há tempos adio esta publicação, com a falsa esperança de conseguir desenhar um mapa completo que mostre os caminhos para a Formação de um Analista de Negócios (AN). Passou da hora dessa discussão se tornar pública. Ao mapa (versão Beta):

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é!

14 de agosto de 2008
Rendiconti: Requisitos em Sampa e Curitiba

Eu sei, preciso ser breve nas prestações de contas e arrumar tempo para gerar artigos “de verdade”. Agora que consegui duas semanas de “férias”, espero tirar alguns itens de meu backlog. Não sem antes documentar minimamente os 2 últimos eventos.

Na penúltima quinta (31/jul), contamos com 73 participantes na Oficina Engenharia de Requisitos, em Sampa. Praticamente todo mundo que esteve no módulo anterior voltou. Foi uma pena, mas apenas aquele ativo participante (defensor de um processo cascata) não conseguiu participar. Gripe ou algo do tipo. Pena mesmo. Espero reencontrá-lo para fechar o debate que começamos no dia 16.

Mas isso não significa que o evento ficou menos quente. Muito pelo contrário. As interações foram tantas que ainda no período da manhã boa parte de meu buffer (pulmão) de 1hr já tinha ido para o beleléu. Isso e outra amolação que não merece espaço fizeram com que a turma não conseguisse executar os 2 últimos exercícios da oficina. Por menos que eles tenham reclamado (e as avaliações foram muito boas), eu sei que a não execução dos exercícios é um prejuízo. São exatamente aqueles que permitem que o Analista de Negócios (AN) coloque os pés, pela primeira vez, no domínio da solução. Fazem falta.

E por falar em exercícios… A sala tinha capacidade para 100 pessoas. E a turma parece ter ocupado praticamente todos os cantos disponíveis. Já escrevi aqui, não é a sala ideal para este tipo de oficina. Mas meu parceiro em Sampa tem encontrado dificuldade para encontrar um local mais adequado. A turma sofre um pouco. Mas se diverte pra caramba.

Um fato tem me chamado a atenção em todas as últimas edições desta oficina: as turmas estão assimilando muito rapidamente minha proposta de especificação de casos de uso. Apesar de continuar gerando uma certa polêmica, o pessoal pega o “espírito da coisa” muito rapidamente. Ainda careço de mais informações de quem está adotando aquela sugestão em seus projetos. Mas os produtos gerados na oficina me surpreendem. Ainda que existam algumas variações consideráveis. Por exemplo: o menor número de requisitos funcionais (ou passos em um caso de uso) foi 4, o maior foi 11. Mas o tal “espírito” (a captura exclusiva *do que o usuário precisa fazer*) foi respeitado em todos os artefatos gerados.

O amigo Kerber, que há uma semana publicou sua prestação de contas, pode ter matado a charada (da rápida assimilação do modelo para especificação de casos de uso). Depois do evento, num “bareco”, ele disse que a 1ª parte da oficina está “muito bem resolvida”. Eu também tenho gostado muito daquela sequência. Mas sua mensagem mostra que a 2ª parte, que concentra grande parte dos exercícios, ainda carece de revisões. Aliás, acho que já me conformei com o fato de que o evento é um eterno “trabalho em desenvolvimento”. Não consigo replicar nem mesmo as apostilas.
Além do Kerber, que foi de Floripa para Sampa com o colega Paulo Bernardi, contamos novamente com a presença de Suzandeise Thomé, do IIBA-SP. Foi com eles que rolou uma revisão pós-evento, ali na Alameda Santos. Papo jóia com o tradicional efeito colateral: o espaço do problema aumentou consideravelmente, hehe. Explico: o horizonte de todo este trabalho para a formação de AN’s foi expandido. Ainda não posso falar muito, só adiantar que ficou mais azul (e bonito). Revisão semelhante já está programa para Floripa: Sabadão, 23/ago. Semelhante em todos os sentidos: num “bareco”, com bom chopp e um tira gosto melhor que aquele de Sampa. Alguém aí disse camarão? Pastel de bacalhau do Box 32?

Na última segunda-feira, 4/ago, apresentei a mesma oficina em Curitiba, no evento Planeta Digital. Turma consideravelmente menor (má divulgação?), mas igualmente interessada. O evento foi legal o suficiente para gerar novas oportunidades, inclusive alguns “passeios” pelo interior do Paraná (Cascavel, Foz) que eu não conheço. Vergonha: conheço até Guaraqueçaba (que muitos paranaenses não conhecem, daí!), mas nunca tive a chance de mergulhar no interior daquele belo Estado. Me perdoem a economia, mas esgotei o espaço dedicado para uma prestação de contas. E seria muito redundante em minhas conclusões. Resta apenas dizer que São Paulo não tem um centro de convenções do nível da Expo Unimed. Um show!

Encerrando: novidades sobre o Projeto Rendiconti foram publicadas hoje no Graffiti. Belas novas, diga-se de passagem. Inté!

8 de agosto de 2008
Rendiconti: Modelando Negócios em São Paulo

No dia 26 de abril eu anunciei aqui a morte do ‘Patinho Feio’. Me referia ao evento que então era conhecido como “Análise e Modelagem de Negócios”. Sua baixa popularidade o colocou em risco. E o evento de abril foi a gota d’água. O evento demandava uma revisão. Não tanto em seu conteúdo, mas na forma em que estava sendo apresentado e comercializado. No final de maio Tempo Real Eventos e eu lançamos um “pacote” FAN: duas oficinas que, se contratadas em conjunto, significariam um pequeno desconto. Sei que é uma prática que pode ser mal recebida: configura-se venda casada? Bom, até agora ninguém reclamou e o sucesso da iniciativa fala por si: na última quarta-feira, 16/jul, tivemos uma turma com 60 participantes!

Outra pequena alteração que efetuei foi no nome do módulo: tirei a palavrinha “Análise” e dei o braço a torcer para o RUP. Esta primeira metade do programa FAN agora se chama só “Modelagem de Negócios”. Claro que faz mais sentido, já que vendo a Análise de Negócios como a junção da Modelagem de Negócios com a Engenharia de Requisitos. Aliás, visando facilitar o entendimento do escopo dos dois módulos criei uma tagline, um tipo de sobrenome para cada um deles: Modelagem de Negócios – Entendendo o Negócio; Engenharia de Requisitos – Entendendo o Usuário. Ficou meio simplista, até apelativo. Mas não tenho dúvidas que facilitou a apresentação dos módulos.

O programa FAN (Formação de Analistas de Negócios) é um eterno “trabalho em desenvolvimento”. Mas estou tratando a versão atual, publicada há cerca de 2 meses, como um release candidate. Ou seja, ela ficará ‘congelada’ nesta que considero a penúltima iteração do projeto do livro. Uma iteração longa, de 6 meses. As oficinas e cursos sempre antecedem a publicação de uma versão do livro. É o feedback que obtenho ali que direciona as alterações e incrementos que devo fazer em meu texto. A partir de agosto começo a publicar, exclusivamente para os participantes dos eventos, o release candidate de cada capítulo do livro. Minha intenção é liberar um capítulo por quinzena. Em paralelo está acontecendo o projeto Rendiconti – a loja virtual (POD – Print on Demand) que venderá meu trabalho e, se tudo der certo, o trabalho de vários colegas.

Mas, caramba… esta deveria ser a prestação de contas do evento do último dia 16. Vamos a ela. Na teoria minhas oficinas deveriam ter um público máximo de 50 pessoas. Na prática meu recorde é de 72. Coloquei o limite por uma razão muito simples: a possibilidade de interagir e dar atenção para todos os participantes.Tivemos 60 na última quarta-feira, mas acredito que todos que precisaram de atenção foram atendidos. Sem comprometer a duração do evento. Adianto para todos, logo na abertura do evento, que temos um buffer de 1 hora. E explico: se o evento for muito ruim, lá pelas 5 da tarde tá todo mundo indo embora. E confesso que isso já aconteceu uma vez, na 3ª turma do FAN “palestrão”. O tal buffer é utilizado nas interações. E foi totalmente consumido neste último evento.

Turma grande e variada, no sentido de que tínhamos ali vários ramos de atividades representados. De escolas a usinas de álcool, passando por várias empresas de desenvolvimento de sistemas com perfis bastante distintos. Esta heterogeneidade enriquece o evento, principalmente porque permite a exploração e o debate de muitas expectativas e perspectivas distintas. Os exemplos que vêem dos participantes, suas demandas e dificuldades, são parte central da matéria-prima que utilizo em meu trabalho. Tanto que não vejo mais como seria possível escrever um livro deste tipo com um processo diferente.

Apesar de insistir que os dois módulos do programa são “levemente acoplados”, por diversas vezes encerrei um papo dizendo que aquilo era tema para o evento do dia 31. Ficou feio, mas do contrário eu correria o sério risco de estourar o horário. Na verdade o que está acontecendo, intencionalmente, é uma melhor amarração das duas disciplinas. Como aprendi em nosso grupo de discussão, mesmo os participantes mais envolvidos e antenados viviam “me jogando na cara” que a formatação do programa tinha um Q de cascata. Por mais que eu insistissse que as duas disciplinas ocorrem em paralelo em um projeto para desenvolvimento de sistemas, a sensação de “quedas em cascatas” persistia. Por isso amarrei um pouco mais as disciplinas. Tento indicar onde e como há o entrelace. Fico sempre devendo o outro lado da amarração, a parte dos Requisitos. Devendo para o evento seguinte. Não vejo como fazer de outra forma.

Por falar em “cascatas”, confirmei um padrão que demanda atenção. Empresas de software que desenvolvem pacotes apresentam uma grande resistência a processos que preguem a adoção de um ciclo iterativo e incremental. Percebi isso em turmas fechadas que executei nas últimas semanas, no interior de São Paulo e em Santa Catarina. E a coisa ficou ainda mais “quente” neste evento. Os argumentos de quem defende a “cascata” neste tipo de organização são fortes, contundentes. Existem aqui duas variações principais: quem defende “cascatas” com unhas e dentes e quem pensa que iterações com 3 ou 5 meses de duração não configuram uma “cascata”. Com o segundo grupo tive tempo suficiente para descobrir que seu processo carece de revisão – foi em SC. O debate com esta turma de Sampa prosseguirá no próximo 31/jul. Espero entender e registrar melhor seus argumentos. Como a próxima oficina é bem mais prática, espaço para o debate não faltará. Claro, registrarei aqui meus achados (e perdidos).

Sempre recebo uma compilação (anônima) das avaliações. O ponto que mereceu a imensa maioria das críticas ao evento foi uma inserção comercial de 15 minutos. O evento teve um patrocinador, que ganhou um tempinho para deixar sua mensagem. A turma não gostou. Mas acho que foi só um problema de comunicação. Minha parcela é grande. Existem eventos parecidos que custam o dobro deste. A turma precisa entender que a manutenção dos valores atuais dependerá de recursos assim, de patrocinadores. Eu aviso que não endosso nenhum dos produtos ou serviços apresentados pelo patrocinador. Mas também não os ‘detono’. (Só adoro detonar mesmo o Requisite Pro, hehe). Tempo Real, Borland e eu tentaremos tornar o “reclame” mais útil e interessante para os participantes. Uma breve demonstração de produtos / ferramentas é o caminho.

Para encerrar, devo registrar a satisfação de ter contado com a presença da presidente do Capítulo São Paulo do IIBA (International Institute of Business Analysis), Suzandeise Thomé. O amigo Cláudio Kerber nos apresentou, e a convidei para os dois eventos. O Capítulo São Paulo foi fundado no dia 1º de abril deste ano. Sim, a Suzandeise brincou com a data. Além de nos informar que o trabalho ainda está em sua fase inicial, brigando com uma certa burocracia. Mas as perspectivas são boas. Em pvt ela me disse que o interesse é muito grande. Que várias empresas já os procuram para, principalmente, oferecer treinamentos para a formação de Analistas de Negócios. “Hot Commodity” é isso aí. Chute meu: os dois próximos anos serão quentíssimos!

Momento “falha nossa”: 1 mês sem atualizações do finito é muita coisa. Aos amigos que gostam de meus artigos, registro aqui um sincero pedido de desculpas. Tenho em meu backlog quase uma dezena de temas que quero tratar aqui. Mas a correria das últimas semanas mal deixa tempo para uma necessária cervejinha. E os próximos 45 dias seguirão no mesmo ritmo – até pior. Mas tentarei não deixar este espaço tão abandonado. Não por um período tão longo.

22 de julho de 2008
Rendiconti: Bauru, R/Open, Outra Gripe e outra viagem daquelas

Pôxa, duas prestações de conta consecutivas… Sinal de muita estrada e pouco tempo para gerar conteúdo novo. Peço desculpas prometendo uma sequência de artigos inéditos. Mas este rendiconti tem um atrativo especial, que atende pelo nome de “R/Open”.

Antes, porém, a viagem. É minha segunda ida a Bauru, mais especificamente para a UNESP. A primeira foi em novembro do ano passado. Um passeio maluco que resultou em quase 24 horas dentro de ônibus, de Vga para Bauru via Campinas. A experiência foi legal mas excessivamente cansativa. Desta vez eu encararia um vôo de ATR, CGH – Bauru/Arealva sem escalas. Diz o povo, mineiro não perde o trem (ônibus ou avião). Daí que o mineiro aqui só descobriu em cima de hora que perderia o vôo se não fosse para Sampa na madrugada de domingo. Imprevisto que resultou em horas e horas perambulando feito um zumbi em dois terminais, Tietê e Congonhas. Zumbi? Pois é: desde a última quinta convivo com a 2ª gripe do ano: gripe “Carlinhos Bala”. Não sei se ela pega só corinthianos, mas é devastadora! E não deixa dormir. Azar dos corinthianos que compartilharam ônibus e aviões comigo…

Quando comecei a palestra, na noite de segunda, completava 37 horas sem dormir. Alertei a turma para um risco inédito: o palestrante poderia dormir! Azar deles, não aconteceu. E até que rolou sem grandes acidentes a primeira de duas palestras. Rolou até sorteio de uma caixa de quindins, o que ajuda a “prender” uma platéia. Invertendo a ordem natural de meus eventos, começamos com Engenharia de Requisitos. A mesma turma veria, no dia seguinte, uma palestra sobre Modelagem de Negócios. E um improviso que fecharia com chave de ouro a minha participação naquele evento que é totalmente organizado e tocado pela estudantada, a exemplo da Semana Acadêmica da UFLA.

Antes da surpresa, porém, vou falar sobre a viagem de volta. Ainda zumbi (tipo aqueles coadjuvantes dos filmes do Corman sobre o tema), me enganei sobre o horário do vôo. Quando cheguei no distante aeroporto de Arealva, certo de mais de uma hora de espera, fui recepcionado por três assustados funcionários: “o senhor vai embarcar?”. Como assim? Meu vôo é o próximo. Quase gelei quando falaram que não tinha próximo… Deve ter gelado mais aquele prestativo atendente que invadiu a pista correndo e pedindo para o piloto esperar: “Tem mais um!”. Foi surreal, mas atrasaram a decolagem e abriram a porta do avião para o zumbi aqui poder embarcar. Agora só falta dizer que eu sou culpado pelo caos aéreo. Bom, para terminar a saga, corri feito louco de Congonhas para o Tietê (Portuguesa) e consegui pegar o último buzão. Lá pelas 2h30 da matina, no meio d’uma neblina igualmente “Corman” e d’um frio daqueles, desembarquei em Vga. Eu e outros 3 zumbis.

Vou repetir o que escrevi depois da primeira ida para Bauru: queria descobrir uma forma de ‘importar’ aquele espírito empreendedor aqui para minha terrinha. Como na semana anterior estive com a estudantada de Lavras, as diferenças ficaram ainda mais nítidas. Não é demérito da turma de Lavras, não é isso. Mas é muito visível a diferença. Todos os participantes do evento de Bauru, do 3º e 4º anos, já trabalham. Na área! E muitos ainda têm fôlego para buscar projetos “por fora”, inclusive iniciativas de software livre. São mais dinâmicos e, de certa forma, mais “famintos” por novos conhecimentos e experiências. Precisa dizer que tal espírito se reflete na universidade e até na cidade? O interior de SP não é mais desenvolvido que o interior das Geraes por acaso, sorte ou força política. Triste (para os mineiros), mas este é outro assunto. Voltemos ao nosso.

Aquele improviso que rolou no evento de ontem é fruto de uma longa história. História de quase 1 ano. Um dos pontos principais de meu trabalho para a Formação de Analistas de Negócios é uma sugestão para a Estruturação de Requisitos. Dois participantes das primeiras edições do FAN, Jean Streleski de Bauru e Reinaldo Castro de São Carlos, gostaram da idéia e começaram a desenvolvê-la. Ontem fomos apresentados, platéia e eu, ao R/Open, uma versão “alpha” de uma aplicação que pega, remixa e estende minhas sugestões. Jean e Hailton, o desenvolvedor que transformou nossos requisitos na bonita ferramenta que aparece aí do lado, fizeram a apresentação. O R/Open (ou RequisiteOpen, nomes ‘temporários’?), foi todo desenvolvido com a dupla dinâmica PHP+MySQL. Usa Ajax e foi arquitetato, de nascença, para atender um nobre requisito: ter seu código aberto. Ou seja, a solução tem uma arquitetura robusta, que soube lidar muito bem com eventuais limitações do PHP. Nas palavras do Hailton, “é bem OO (Orientada a Objetos)”.

A ferramenta respeita integralmente aquele meu rabisco. Ou seja, parte dos Objetivos e Processos de Negócio. E organiza o escopo como um conjunto de casos de uso. E, antenadíssima, sugere a adoção de um processo de desenvolvimento que seja iterativo e incremental. Para tal Jean se baseou no OpenUP para traçar o método de desenvolvimento. Me arrisco a dizer que nenhuma outra ferramenta para desenvolvimento e gerenciamento de requisitos tem um enfoque tão rico, natural e prático. Não sei se a platéia notou, mas fiquei boquiaberto com aquilo que eles chamaram de “versão alpha”.

Claro, ainda há muito por fazer. Jean e outros voluntários de Bauru devem aproveitar as férias de julho para fechar uma versão “beta”, a primeira que deve ser disponibilizada para o público. Espero apoiá-los nesta etapa, inclusive na documentação da aplicação. Mas vou elaborar também uma sugestão de ‘roadmap’, uma coletânea de provocações: a primeira forçará um reencontro com a turma de São Carlos: será que conseguimos acoplar uma ferramenta CASE desenvolvida lá ao R/Open? Outra: vale a pena aproximar o R/Open do Eclipse? Caramba, são tantas possibilidades que só espero não ‘bagunçar o meio de campo’. Estamos todos cientes de que, tão logo seja publicada como software livre, a ferramenta ganhará vida própria. Que seja longa e resulte em produtividade e qualidade para todos os seus usuários.

Momento TKS!: Jean, Léo, Rafael, Hailton e toda aquela cambada que organizou e participou dos eventos merecem os parabéns. A UNESP e todos os seus professores (BSI e BCC) merecem os parabéns por abrir espaço e motivar uma turma tão especial.

Para encerrar, repetirei uma provocação que fiz para todos que vivem atolados em intermináveis congestionamentos: prestem atenção na riqueza que brota longe das capitais. Valorizem quem está gerando talento de verdade. Mas, por favor, valorizar não é plantar “fábricas de software caça-níqueis” em locais onde o salário é mais baixo, ok? Pensem grande. Da mesma forma como a estudantada da UNESP pensa. Inté!

18 de junho de 2008
Analistas de Negócio Valem Ouro

Quem diz é a CIO Magazine: Analistas de Negócios valem Ouro. O artigo, que comenta uma pesquisa da Forrester, foi publicado lá fora no dia 16/abr e mereceu outro título: “Why Business Analysts Are So Important for IT and CIOs“. Why? Uai…

Por duas décadas, o CIO foi visto como o elo central entre as funções de negócio e tecnologia. Embora esta talvez seja a percepção exata da sala da diretoria, nos bastidores os analistas de negócio são os encarregados de fazer essa ligação ao elaborar os business cases para desenvolvimento de projetos de TI, suavizando as relações entre concorrentes e impulsionando projetos.

Nos “bastidores”? O Analista de Negócios (AN) atua “nos bastidores”? Parece que ele faz coisas “por baixo dos panos”, não? Quanta infelicidade. A Madame Katyusha (prima da Natasha do Gaspari) acha que a nobre publicação pretendia dizer o seguinte: “é o AN que põe a mão na massa!” E, creiam, os tais “business cases” não têm, por si só, o poder de fazer a tal ligação entre TI e o negócio. Muito menos de “impulsionar projetos”. E “suavizar relações”? “Entre concorrentes”?… sem comentários.

Nossa área, pelo visto, nunca perderá a mania de criar Super-Heróis que resolvem todos os problemas. Há pouco eram os Coordenadores de Projetos. Como a coisa não andou como prometido, agora elegem AN’s como a bola da vez. Apesar de um certo gelo na barriga, acho que a turma já está vacinada. E não cairá nessa reciclada armadilha.

AN’s são importantes, mas não mais ou menos que qualquer outro integrante de uma equipe de TI. Se eles valem ouro, então todos valem. Perdão turma, mas não se trata de demagogia, ok? Apenas um lembrete que, vez por outra, se faz necessário.

O AN ganha importância (e espaço na prensa “especializada”) porque sua área de conhecimento foi paulatinamente reduzida e negligenciada nas últimas duas décadas: o Domínio do Problema. A academia e as empresas passaram a valorizar o domínio da solução: e foi uma enxurrada de “analistas-programadores”, de anúncios pedindo “analistas de sistemas com 10 anos de experiência programando em C# e Java” e assim por diante. Agora estamos aprendendo que, sem um correto domínio do problema, não há solução que vingue. Entram os AN’s!

Mas quem são os AN’s? O artigo fala que eles valem ouro e, no parágrafo seguinte, confessa:

Todo mundo concorda com a importância do papel do analista de negócio, porém pouca gente sabe exatamente o que faz um profissional como esse.

Não é hilário? Não é uma coisa bem típica da nossa área? Engraçado é que a mesma publicação, há quase 1 ano, já falava que o AN era uma “hot commodity” e apresentava, com relativa felicidade, o seu job description. Felicidade que sumiu no segundo parágrafo do artigo atual: “a maioria dos analistas de negócio bem-sucedidos mescla o temperamento e a habilidade de comunicação de um diplomata com o talento analítico de um oficial do serviço secreto.” Céus, pra que dourar tanto a pílula? Madame Katyusha sugere: “O AN é bom no entendimento de problemas e na percepção de oportunidades.” Para tanto, é claro que o cara deve ser um excelente comunicador. Mas esta não é a única ‘soft skill’ que ele deve desenvolver / apresentar.

Encerro o azedume com minha maior preocupação: sei lá porque cargas d’água, insistem em Analistas Orientados ao Negócio e Analistas Orientados para TI. Na publicação original ficou um tanto pior. Falaram em “Business-Oriented Business Analyst”… já pensou se vira sigla? BOBA! Céus! 10x Céus!! Quem nada entende tudo complica, né? Analista de Negócio é Analista de Negócio. Ponto! Se ele é subordinado ao CIO ou qualquer outra área é outro papo. Mas o nome é o mesmo! Deveria ser… o artigo fala que o pessoal da Forrester achou uma solução: Analista de Tecnologia do Negócio! Céus!!! 1000x Céus!! Detalhe: este é o nome adotado por um grande banco tupiniquim para o departamento de AN’s: DTN: Depto de Tecnologia do Negócio. Então… corre o risco de vingar. Céus…

Mas não importa. O que importa é que finalmente os AN’s estão ganhando um certo espaço, a devida atenção. Deixemos o “ouro” para nossos compatriotas que irão para Pequim e vamos falar sério sobre a função-profissão.

Quer saber quem é o AN, onde ele mora, qual a sua formação, habilidades e responsabilidades? Quer saber porque ele pode ajudar na concepção e entrega de projetos? Quais matérias ele deve dominar? Os motivos pelos quais ele se tornou tão importante? Segue o convite:

No dia 31 de maio, sábado, apresento uma edição especial do evento “Formação de Analistas de Negócios“. Será em Sampa, na Av Paulista. Programação, localização, inscrição e demais informações você encontra no site da Tempo Real Eventos.

20 de maio de 2008
Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
Seqüência obrigatória do último post. A motivação é a seguinte afirmação: “Os passos em um Caso de Uso são Requisitos Funcionais“. A questão parece simples mas esconde alguns “probleminhas”. Minha intenção aqui, além de justificar minha afirmação, é debater os tais “probleminhas”.

Variações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.

Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.

A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.

Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.

As variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.

No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):
1. Coloca uma moeda
2. Seleciona o tipo de bebida
3. Retira o copo
O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?

Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.

Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.

Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: “It’s not what the software does. It’s what the user does.” Deveria virar um poster-lembrete na sala-mesa de todo AN.

Atualização:

Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!

Bibliografia:
1. Writing Effective Use Cases
  Alistair Cockburn. Addison-Wesley (2001).
2. Software Requirements
  Karl E. Wiegers. Microsoft Press (1999).
3. More About Software Requirements
  Karl E. Wiegers. Microsoft Press (2006).
4. Use Case Modeling
  Kurt Bittner e Ian Spence. Addison-Wesley (2003).
14 de maio de 2008
Rendiconti: A Morte do Patinho Feio, a Gripe Terremoto e outras novas

Várias novas. Tanto que precisarei d’outro post para apresentá-las por inteiro. Mas antes, nossa tradicional prestação de contas. Aconteceu na última quinta (24/abr), a 2ª turma da oficina “Análise e Modelagem de Negócios” em Sampa. É o meu “patinho feio”. Explico: ao contrário de sua co-irmã, a oficina “Engenharia de Requisitos”, esta não está sexy o suficiente – não é atraente. Tanto que o público foi “só” 1/3 da média apresentada pelo outra. Sigo sem entender (“elas são indissociáveis!”, é meu choro frequente), mas não insistirei no modelo. Teimosia tem limite. Senão vira burrice, hehe. Mas falarei sobre as mudanças depois.

Turma pequena é turma privilegiada. Posso atender todo mundo de uma forma mais frequente e pessoal. As interações tendem a ser um pouco mais ricas. E que sorte tivemos neste último evento! Experiências com Aris; AN’s (Analistas de Negócios) de uma grande empresa que utiliza XP (eXtreme Programming) como seu principal processo de desenvolvimento (!); um “Dino Coboleiro” (em suas próprias palavras); e, pela segunda vez, uma profissional de marketing interessadíssima na matéria; quatro participantes já haviam participado da outra oficina, o que também enriquece o evento – dois são professores (!); três pessoas foram de Curitiba exclusivamente para o evento; empresas importadoras e pequenas e médias empresas que desenvolvem sistemas. Ou seja, a turma era pequena mas eclética, variada, rica. O evento ganha muito com a diversidade – podemos conversar sobre vários modelos de negócios, estratégias, processos, problemas e oportunidades. Tanto que eu não via a hora de publicar esta “rendiconti”. Tanto que nem esperei pelas fotos. Quando elas aparecerem, publico aqui.

Pelo resumo das avaliações que recebi, posso concluir que todos gostaram muito do evento. Mesmo assim, recebi 3 belos “puxões de orelha”. Vou aproveitar este espaço para comentá-los e, quando for o caso, rebatê-los.

Aris

O Aris vem no SAP R/3; é uma “linguagem” madura; “todo mundo usa”; “o usuário não precisa de treinamento para entendê-la”; “você não pode ignorá-la”. Pois bem, é a primeira vez que alguém me cobra isso. O que, definitivamente, torna o “todo mundo usa” um exagero. Quando iniciei este trabalho, há mais de um ano, naveguei brevemente pelo “mundo Aris”. O ignorei por completo por um simples motivo: meu trabalho simplesmente não cita nada que não seja um padrão aberto. Mesmo que a tentação (e as justificativas acima) sejam muito fortes, não cometerei o pecado de amarrar os conceitos e práticas que apresento em uma tecnologia ou ferramenta proprietária. Seria um suicídio. No mais, trata-se apenas de outra linguagem, assim como BPMN e a EPBE (UML) que apresento. Assim como eu falo sobre UML, deve ser fácil aprendê-la em um treinamento de 4 horas, mais ou menos.

UML (e a extensão EPBE) seguirão no núcleo de meu trabalho sobre análise e modelagem de negócios. Mas vou considerar seriamente a inserção de um capítulo sobre outras notações. Mais que isso, deixarei em aberto a possibilidade de uma versão deste evento que utilize o Aris ao invés de EPBE. Mais sobre as extensões do programa FAN (Formação de Analistas de Negócios) abaixo e em futuros artigos.

Inovação

Veio do mesmo (simpático) crítico que sugeriu Aris: “esperava algo novo”. Ele falava especificamente da parte onde mostro a elaboração de um balanced scorecard (BSC) em EPBE. Juro, sigo achando que isso é novo! E me esqueci de perguntar se isso seria possível em Aris. Agora, se ele esperava uma alternativa ao BSC, acho que seguirei devendo por um bom tempo. Não vi surgir nada – com exceção do irmão do BSC, o Mapa Estratégico – que represente melhor a estratégia de uma empresa. Sério – não vejo nada no horizonte. Posso estar enganado. Mas, como não foi colocado nada no lugar, seguirei com minhas sugestões.

XisPê

A dupla (de AN’s) de uma grande empresa nos mostrou como eles trabalham com XP (ou XisPê ou eXtreme Programming). Foi muito legal. Usam stories (e não casos de uso); pair programming; TDD (Test-Driven Development); ou seja, todas as práticas fundamentais de XP. Detalhe: exceto uma! São eles que se sentam ao lado dos programadores, não os usuários. Meio na brincadeira (e meio sério), alertei-os que os “radicais” falarão que então não se trata de XP de verdade. Afinal, os “radicais” detestam AN’s! Não importa: estão felizes com o processo e, mais importante, está funcionando! Atenção pessoal que vive sendo cobrado (inclusive por este que aqui rabisca) por casos de sucesso na implantação de XP: taí um belo caso. Com AN’s!

Gripe Terremoto

Tive uma reunião logo após a oficina. Quando ela se encerrou, lá pelas nove, o primeiro tremor. Sinto uma gripe chegando de longe. E esta resistiria até a uma dose cavalar (e perigosa) de Resfenol. Só sei que não tem nada a ver com Dengue e afins porque estou quase sem voz, parecendo um poço artesiano e tremendo mais que prédio de Sampa na última terça. Ou seja: trata-se da gripe terremoto. Problemão: tenho vários compromissos na próxima semana. Se a overdose de chás e outros remédios não adiantar, não sei o que vou fazer. Só sei que o final de semana será diferente, com o note na barriga acompanhando meus tremores, hehe..

Cadê o Cisne?

Pois é: se o patinho feio se foi, cadê o cisne? Bom, ele precisa de alguns dias para concluir sua metamorfose. O coração do programa não sofrerá alterações, é lógico. Mas a oficina sofrerá grandes alterações, inclusive na forma como é comercializada. Preciso deixar mais nítida a amarração entre “Análise e Modelagem de Negócios” e a “Engenharia de Requisitos”, mesmo que um dos meus requisitos fundamentais seja o “leve acoplamento” dos eventos (ou seja, um não é e não será pré-req para o outro). Complicado, não? Bom, acho que já tenho a solução, e espero apresentá-la em breve.

26 de abril de 2008
Quem Paga a Dolorosa?

O negócio não interessa. O que interessa, isso sim, são os maravilhosos badulaques, frameworks, caixinhas-caixões e código. Adoramos esquecer que, no final das contas, quem ‘morre com a dolorosa’ é o tal do negócio. Há mais de uma década o Gartner estampa no Top 5 das preocupações dos CIO’s: “Alinhamento Estratégico“. Perdemos o novelo ou o papo sobre alinhamento não é sério?

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

.:.

18 de outubro de 2007