PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Onde Mora o Analista de Negócios?

    Fiz uma breve pesquisa e continuo sem uma resposta clara. Para muitos, o AN não deveria estar diretamente vinculado ao departamento de TI. O problema com tal definição é, ao que tudo indica, sua maior justificativa: seria uma forma das áreas de negócio recebê-lo melhor. Ou seja, se ele fosse um profissional da área de TI seria visto com desconfiança.

    Mas, se a única função do AN é promover a ligação entre TI e as demais áreas da empresa, parece lógico que ele responda para alguém de TI. Evitaria assim uma certa burocracia (e perda de tempo) toda vez que um AN fosse alocado em um projeto.

    Nos meus achados & escritos proponho uma terceira forma: o PMO++. Um escritório de projetos (PMO) oferece um ‘pool’ de gerentes de projeto. Ele é, de certa forma, uma unidade independente. Alocar ali os AN’s pode fazer muito sentido.

    Antes de fechar o tema, com os prós e contras de cada modelo, pretendo fazer mais pesquisas. O problema é a (falta de) população amostral.

    .:.

    Pequenas Mudanças no Workshop

    A data do workshop, “Formação para Analistas de Negócios“, mudou: será no dia 20/junho, quarta-feira (ou zeca-feira, vocês mandam. Tem gente que gostou da notícia, hehe). E gostará ainda mais de saber que o preço sofreu ligeira queda! Aproveite. São poucas (50) vagas.

    .:.

  • Meme #015 – TI Centrada na Informação

    In the existing IT environments, I believe we moved from being Server-centric to OS-centric to Application-centric. In the next generation, we become more network-centric but fundamentally (for the first time I might note) start building Information Technology actually around the Information. This is powerful. It means that Information is no longer captive to a single application but can be leveraged across any number of applications.

    – Mark S. Lewis, VP da EMC

    Vale a pena ler toda a sua série chamada “Flat IT”.

    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Para que serve o Analista de Negócios?

    A pergunta acima, colocada num fórum de discussão há pouco tempo, foi o último empurrão que eu esperava. Volta e meia ouvimos que problemas com a compreensão do negócio e com requisitos respondem por cerca de 80% das causas das falhas em projetos. Com uma freqüência ainda maior, somos comunicados de que uma das maiores prioridades das áreas de TI nos últimos tempos é o alinhamento com o negócio. Mas, por incrível que pareça, um dos profissionais mais importantes no atendimento dessas duas demandas é pouco conhecido. Afinal, quem é o Analista de Negócios (AN)? Qual a sua formação? Quais as suas habilidades? E, mais importante, quais as suas responsabilidades em uma organização de TI e em projetos para desenvolvimento ou implantação de sistemas?

    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.

    .:.

  • Novo Berkun

    No próximo dia 15/mai será lançado o novo livro de Scott Berkun, “The Myths of Innovation“. É só o segundo. O primeiro foi “The Art of Project Management“, best seller e um dos melhores do gênero. Há pouco mais de um ano publiquei um “resumão” dele, comparando-o com o clássico “The Mythical Man-Month“.

    Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é “Criatividade e Grupos Criativos”, de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

    • Why all innovation is a collaborative process
    • How innovation depends on persuasion
    • Why problems are more important than solutions
    • How the good innovation is the enemy of the great
    • Why the biggest challenge is knowing when it’s good enough

    Sairá um “De De Masi a Berkun”? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o “Gerenciamento do Trabalho Criativo“.

    Mas fica a tentação: De Masi, em “Criativade”, conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

    .

  • CRUISE: Primeiros Passos

    Em uma das partes da série que desenvolvo sobre Ativos de Sofware e Reuso eu comentei minha estranheza em relação ao trabalho do RiSE (Reuse in Software Engineering), um grupo do CESAR (Centro de Estudos e Sistemas Avançados do Recife). Fiz contato com o grupo tentando obter referências e dicas. Um membro me direcionou para o site do IEEE (onde eu deveria comprar as tais referências!).

    Estranhei porque, salvo engano, parte da grana que sustenta o CESAR é pública. Mesmo que eles fizessem da venda de artigos uma fonte de receita alternativa, não faz sentido que a venda seja feita em dólar e intermediada por uma entidade dos EUA. Não entendi e também não obtive nenhum tipo de retorno. Ok. Registrei a crítica e esqueci a questão.

    Mas eis que agora recebo a notícia do lançamento do CRUISE (Componente Reuse in Software Engineering), uma compilação dos achados do RiSE. O livro foi lançado sob licença Creative Commons (by-sa-nc) e, claro, é distribuído gratuitamente. A porta que parecia fechada a 7 chaves agora está escancarada (no melhor sentido).

    Ainda não tive a chance de ler o livro – acabo de baixá-lo. Mas creio que será muito útil na conclusão do meu trabalho. Um trabalho que pode ganhar novo rumo: o pessoal do RiSE, com o lançamento do livro, convoca-provoca participações. Reclama inclusive que nosso meio acadêmico deveria ter mais iniciativas como essa.

    Jóia. Mas como tenho que manter minha reputação de “muito chato”, antecipo aqui uma crítica: por que em inglês? Sei que existirão mil justificativas do tipo: “é nossa língua universal!”. Sorry (haha).

    Nossa língua oficial é o português. Todo trabalho gerado em universidades públicas deveria estar em sua língua oficial. Depois viriam as traduções. Engraçado é que no e-mail de divulgação eles falam: “contribuições para melhorar a versão original são muito bem vindas. Inclusive porque inglês não é a língua nativa de nenhum dos autores.” Dá pra entender?

    De resto, agora é mergulhar no texto, aprender (muito) e colaborar (sempre que possível). Pela iniciativa, parabéns ao pessoal do RiSE. Que seu exemplo seja seguido por muitos.

  • Rendiconti*: O Seminário da Tempo Real

    * Rendiconti = Prestação de Contas

    Apesar da minha desastrada abertura, uma palestra ‘quebra-gelo’ (54 slides em 20 minutos!), o evento do último sábado foi muito bom. Cerca de 260 participantes. Algumas empresas chegaram a mandar mais de 10 pessoas. Pelo retorno que já recebi, quero crer que todo mundo aproveitou bem as 7 horas do evento.

    Destaquei na abertura de minha palestra ‘de verdade’ uma característica não-intencional do evento: nenhum dos 4 palestrantes estava “vendendo” um processo, metodologia ou afins. Novos tempos: estávamos todos compartilhando Princípios e Práticas. Lembrei que isso combinava com uma proposta que Ivar Jacobson havia publicado no Dr. Dobbs há pouco mais de um mês (“Enough of Processes: Let’s do Practices“). Adail, em sua palestra, categorizou os processos de uma forma nova: são Ferramentas. Facilitou a justificativa de que sempre existirá uma mais adequada para determinada organização, cliente ou, principalmente, projeto. Jóia!

    Uma questão que se repetiu tanto no auditório quanto nos ‘breaks’ dizia respeito ao porte das empresas. Ou seja, como utilizar / viabilizar aquelas idéias em empresas de pequeno porte? Reforço aqui o que disse no painel de discussão: utilize as idéias que mais agradaram como modelos de crescimento. Ao contrário de várias grandes empresas de TI que existem por aí, permita que sua empresa cresça e não fique simplesmente inchada. Acho que uma colocação de minha palestra que mais motivou a questão foi um modelo para formação de equipes (já apresentado aqui no finito em mais de uma oportunidade). Repito a mensagem: valorize a especialização. Copio Drucker: veja os hospitais e orquestras.

    Está aqui um dos poucos pontos em que havia um pouco de discordância entre os palestrantes, particularmente entre a visão do Juan e a minha. Para ele, há espaço / necessidade de “especialistas-generalistas”. Entendo o que ele quer dizer, mas acho que o termo gera confusão. Talvez a gente possa falar de “especialistas não-alienados”, hehe. Ou seja, estamos falando de profissionais que:

    • entendem e se comprometem com o seu negócio e o negócio do cliente;
    • conhecem e respeitam os papéis e a importância de cada colega de equipe;
    • mas que são especialistas – têm foco e entendem que “conhecimento, por definição, é especializado” (Drucker).

    Quem não pôde ficar para o painel de discussão perdeu algumas valiosas dicas. Infelizmente não conseguirei reproduzir todas aqui, então destacarei uma belíssima provocação do Adail: programação se aprende no curso técnico. Vamos valorizar os cursos técnicos e, conseqüentemente, forçar uma modernização do currículo de nossos cursos superiores. A questão que motivou a colocação foi a última do painel, e tratava do futuro da indústria de software no Brasil. Além da preocupação com a educação, vale destacar também o alerta do Juan: precisamos de mais e melhores empreendedores. (Na foto, da direita para a esquerda, Adail, Juan e este que vos escreve).

    Em resumo: o evento foi excelente. A qualidade e amplitude das perguntas que recebemos comprovavam o alto nível do público, suas dores, traumas e interesses. Pode parecer estranho ou interesseiro, mas o evento confirmou que precisamos de mais eventos assim. Por fim, eu queria destacar aqui o grande trabalho da Tempo Real Eventos e a atenção do pessoal de apoio da FIAP.

    .:.

    Crédito: As fotos são do Anderson (Tempo Real). As outras podem ser vistas aqui.

    Para a estudantada que estava lá: aguardo as suas fotos, particularmente daquele colega refrescando a cuca na casinha de bonecas, hehe..

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Última Chamada

    Consegui montar uma agenda bem legal e estou em Sampa desde o último domingo. Acho que gasto os 2 primeiros dias úteis só me adaptando ao novo fuso horário (é sério!*) e aos novos temperos. Meu estômago é muito mal acostumado…

    * Boa parte de Sampa acorda mais tarde e dorme MUITO mais tarde. A diferença, comparando com Vga, dá umas 3 horas. É muita coisa. Outra constatação (já meio antiga): preciso de 12 horas em Sampa para fazer o que faço em 8 horas em Minas. Não tô falando só de deslocamento não. Mas outro dia eu falo mais sobre ‘trabalho em casa’, produtividade, a crescente desimportância das distâncias…

    Fiquei sabendo que já temos cerca de 250 pessoas inscritas no Seminário Gestão de Projetos de Software, da Tempo Real Eventos. Considerando que o evento tomará todo o sabadão (o próximo, dia 14), o número me surpreendeu. Restam poucas vagas. Quem quiser participar deste bate-papo que deve ser muito rico, ainda tem chance.

    A gente se vê lá.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Engenharia de Requisitos: O Projeto Aslam [atualizado]


    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.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • UML e BPMN: Mutuamente Exclusivas?

    Nossa área parece ter uma ‘quedinha’ especial por polarizações. Algumas são necessárias (REST vs SOAP). Seriam menos chatas se fossem breves e mais produtivas (Open Source vs Software Proprietário ou Agile vs Classic). Mas alguns embates parecem não fazer nenhum sentido. Um que descobri só recentemente é o duelo UML ou BPMN. Taí uma discussão muito ‘nada a ver’, na minha opinião. Vamos aos fatos.

    A UML, particularmente sua versão 2.0, é muito extensa? Muito genérica? Sim. Mas isso não é um acidente – um defeito. O ponto mais forte da UML, fora a coerência e legibilidade de seus artefatos, é a sua extensibilidade. Qualidade óbvia, já que ela é genérica. Tipo: “não faz mais do que a obrigação”. Várias extensões foram desenvolvidas desde o nascimento da linguagem, no final da década passada. Uma delas é muito relevante para esta discussão: a EPBE, ou “Eriksson-Penker Business Extensions“.

    Apresentada por Hans-Erik Eriksson e Magnus Penker no livro “Business Modeling with UML” (Wiley, 2000), a EPBE cobre todos os aspectos da modelagem de negócios. Ou quase todos. É curioso, por exemplo, que ela não contemple diagramas de casos de uso. Na visão dos autores, tanto o diagrama de casos de uso quanto os diagramas de componentes e de distribuição (deployment) “são utilizados na análise e projeto de sistemas de informação, mas são pouco relevantes na modelagem de negócios”. Por não conseguir dissociar a modelagem de negócios da engenharia de requisitos (falha minha), coloquei aquele “quase” acima.

    Mas a EPBE realmente cobre o essencial na modelagem de negócios, estruturando-se em torno de 4 visões:

    • Visão do Negócio: uma visão geral do negócio, destacando aspectos estratégicos e táticos (problemas a combater ou oportunidades a aproveitar);
    • Processos de Negócio: mostra a dinâmica da organização, inclusive seu relacionamento com entidades externas.
    • Estrutura do Negócio: apresenta a estrutura da organização, a divisão de recursos e a carteira de produtos e/ou serviços;
    • Comportamento do Negócio: o comportamento individual de cada recurso ou processo no modelo do negócio.

    Apenas nesta breve descrição já fica claro que não é possível comparar UML com BPMN. Seria algo como comparar uma bela melancia com uma simpática jaboticaba. BPMN, como o próprio nome indica, é uma Notação para Modelagem de Processos de Negócio. Ou seja, cobre apenas 1/4 do que é possível realizar com a UML devidamente extendida. Mas a questão não se encerra aqui.

    Muitos lembrarão: “ah, mas o debate verdadeiro é BPMN versus o Diagrama de Atividades da UML”. De forma simples e direta: não há nada que eu faça em BPMN que eu não consiga representar em UML. Sim, com BPMN eu consigo diagramas mais ‘bonitinhos’, mas acho que este, definitivamente, não é o caso. Agora vamos elencar algumas coisas que conseguimos representar em UML e que não estão previstas na especificação BPMN:

    • Know-Why: um processo de negócio bem documentado justifica sua existência. Precisamos conhecer os objetivos e metas atrelados àquele dado processo. É fácil extender o diagrama de atividades para armazenar essas informações. Mas para que reinventar a roda? O Diagrama de Processos da EPBE já prevê e obriga a inserção desses atributos do processo.
    • Métricas: apelando para a batida máxima, “não se gerencia o que não se mede”. Pode não ser verdadeira para tudo mas, em se tratando de processos de negócio, a afirmação é mais que verdadeira. Cada tipo de processo pode ter um conjunto muito específico de medidas relevantes. Mas existem duas que deveriam estar em todo mapa de processo: Custo e Tempo de Ciclo. Para conhecer os custos de um processo é imperativo que mapeemos todos os recursos utilizados em sua realização. BPMN simplesmente ignora-os.
    • Informação: na EPBE as informações são tratadas como um tipo de recurso que municia um processo. BPMN, como dito anteriormente, não se preocupa com recursos.
    • Pessoas: ou stakeholders, também são recursos na notação EPBE.
    • Requisitos: sim, a EPBE também não contempla artefatos para a captura e gerenciamento de requisitos. Mas ela, ao contrário da BPMN, não ignora sua existência. Há um diagrama muito útil na EPBE, o Diagrama de Linha de Montagem (Assembly Line – veja exemplo abaixo), que permite associar processos de negócios (diretamente de seu respectivo diagrama), com pacotes de objetos (ou serviços!) e casos de uso. Ou seja, consigo rastrear – navegar entre o domínio do problema e o domínio da solução. Com uma vantagem imbatível: usando a mesmíssima linguagem: UML.

    Conclusão

    Não é o caso de simplesmente dizer que BPMN não é útil. Suas boas idéias, particularmente o maior detalhamento de alguns elementos (só obtidos através do uso de estereótipos no Diagrama de Atividades), podem e devem ser aproveitadas. BPMN e UML estão sob os cuidados do OMG. Acredito que num futuro próximo veremos uma mixagem das duas especificações. Ou então a transformação de BPMN em uma extensão da UML. Algo fácil e natural.

    Se BPEL é o seu sonho de consumo, saiba que já existem tradutores de diagramas de atividades para ela. Portanto, BPEL não é desculpa para a adoção da BPMN.

    Por fim é arriscado mas necessário dizer que não podemos confundir Modelagem de Negócios com a Modelagem de Processos de Negócios. A primeira é uma disciplina muito mais ampla e complexa. Que é muito importante em projetos para desenvolvimento de sistemas. E nada menos do que VITAL em iniciativas SOA.

  • Meme #014 – Tecnologia é só 1% da Solução

    Qualquer combinação de software e hardware pode ser vista como um sistema de informação que pode ser dividido, literalmente, no sistema propriamente dito e a informação, suas propriedades e contexto que trata (incluindo aí regras de negócio, gente, problemas, oportunidades…).

    O sistema, por sua vez, é uma composição das tecnologias usadas para sua construção e a capacidade de aplicação das mesmas em um dado ambiente de informação. O que normalmente significa que um grande especialista em sistemas financeiros, por exemplo, vai estar perdido se o problema à sua frente for desenvolver um sistema de e-mail. Depois de quase 30 anos fazendo software, acho que descobri as porcentagens que regem as divisões acima: um sistema de informação é 10% sistema e 90% informação. E o sistema é 10% tecnologia e 90% aplicação, o que faz com que a tecnologia, de fato, seja apenas 1% da solução.

    – Sílvio Meira (em “Mudando o Mundo. Como?“)

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.