O vídeo apresenta em apenas 3,5min uma visão executiva da Análise de Negócios, os conceitos que ajudam organizações a aplicar seus recursos nos investimentos certos.

Sobre a Análise de Negócios: A disciplina de análise de negócios desenvolve nos profissionais a habilidade de analisar um problema por múltiplas perspectivas e considerar diversas possibilidades de solução com base em uma visão realística de custo x benefício coerente com a visão estratégica da organização.

O principal foco da disciplina é garantir o retorno dos investimentos nos projetos realizados nas organizações utilizando técnicas adequadas para identificar e analisar os problemas, e propor a solução mais adequada para cada situação.

Para desempenhar bem o papel de analista de negócios, um profissional deve acumular competências técnicas e comportamentais que o permitam facilitar a comunicação entre as áreas clientes e provedoras de soluções. Estes conhecimentos são descritos no Guia BABOK® editado pelo IIBA®.

Ao se deparar com um novo projeto, cada profissional inicia uma linha de raciocínio sobre o que deve ser feito. Este raciocínio é baseado em sua forma de ver o mundo e geralmente ligado a sua formação.

Veja no pequeno trecho de aula a seguir, ministrada por Fabrício Laguna, as principais diferenças entre Análise de Negócios, Análise de Sistemas e Gerenciamento de Projetos, disciplinas estabelecidas nos guias BABOK, SWEBOK e PMBOK respectivamente.

Investigação das partes interessadas para identificar os requisitos.

Sempre que uma iniciativa tem chance de se tornar um projeto, logo uma voz grita do fundo da minha consciência (um lugar que fica mais ou menos entre a nuca e o tímpano direito): “-PRECISAMOS FECHAR O ESCOPO DO PROJETO!”

O tal projeto pode ser o desenvolvimento de um sistema, a viagem das férias de fim de ano, a construção de uma casa... não importa: minha mente já condicionada pelo Guia PMBOK de Gerenciamento de Projetos me diz que é preciso "fechar" o escopo.

E fechar o escopo, neste caso, é um pouco parecido com fechar uma caixa ou uma gaveta no sentido de que depois que se fecha, coisas ficam fora e outras ficam dentro. Fechar o escopo significa delimitar uma lista de “coisas” que estão dentro. Essas “coisas”, segundo a minha pobre mente também já condicionada por outro Guia, o BABOK de Análise de Negócios (às vezes questiono se ainda sou capaz de ter alguma idéia própria), são requisitos que devem ser elicitados, ou em outras palavras, levantados, investigados ou trazidos à tona.

Pergunta: Como começar a elicitação dos requisitos?

Resposta: Identificando os Stakeholders.

Stakeholder é um termo bonito e que está na moda, mas na verdade muita gente tem dificuldade em saber quem realmente faz parte desse grupo. Na tradução do BABOK para a língua portuguesa acabamos por seguir a mesma tradução que o pessoal do PMI usou no PMBOK e traduzimos stakeholder como “partes interessadas”. Embora a tradução seja hoje a mais usada no mercado, acredito que ela não ajuda muito a entender a real importância de identificar essa turma.

Andei pesquisando a origem da palavra e pela tradução literal acabei chegando a uma imagem que tem me ajudado muito a entender e a identificar os stakeholders. Siga o meu raciocínio:

Do inglês:

HOLD = SEGURAR (por consequência, HOLDER = quem segura)
STAKE = ESTACA (quem achou que era bife se enganou! Bife = STEAK)

Portanto minha conclusão óbvia: o stakeholder é um “segurador de estaca”.  Sei que a princípio isso não parece nada genial, mas acompanhe a minha visão e veja como ela pode ajudar.

Imagine que a prefeitura está precisamos delimitar terrenos em um novo bairro de sua cidade. Já viu como os terrenos são delimitados? São usadas estacas de madeira em cada vértice do polígono que forma a área do terreno. Agora imagine que para escolher a área de terreno dos seus sonhos você pede ajuda para sua família. Cada um vai segurar uma estaca e se posicionar em um determinado ponto do terreno. Para facilitar ainda mais a visualização do perímetro, você amarra um elástico de uma estaca a outra, de modo que toda vez que sua mãe ou sua irmã dão um passo para frente ou para trás o tamanho do terreno diminui ou aumenta.

Visualizou? Pois então agora veja a minha definição de stakeholder: “são todos aqueles cujo posicionamento afeta o escopo”. São eles os donos dos requisitos e é por isso que o processo de elicitação deve iniciar identificando os stakeholders.

Vamos supor que o projeto seja a construção de uma casa para você morar. Stakeholder é qualquer pessoa ou entidade que tem requisitos para essa casa:

• Sua esposa (ou marido) certamente tem uma série de expectativas com relação ao estilo e ao tamanho da casa.
• Seus filhos têm necessidades que a casa deve atender: o número de quartos, área de lazer, segurança. Veja que mesmo que seus filhos ainda não tiverem nascido e estiverem somente na intenção, eles já são stakeholders.
• Sua empregada também tem necessidades que irão definir as funcionalidades da área de serviço e deixar de fora do escopo aquela linda pia reflexiva que vai ficar fosca se ela limpar com Bombril.
• A prefeitura tem uma série de exigências que precisam ser atendidas ou você não conseguirá o alvará de construção ou a certidão de Habite-se.
• Outros prestadores de serviços também trarão uma série de requisitos para a construção de sua casa: a companhia de energia elétrica, de saneamento, de telefonia, de tv a cabo...

Deixar de identificar qualquer um desses “seguradores de estaca” significa que você não está visualizando todo o escopo e que alguns requisitos vão ficar de fora, ou seja, não serão entregues pelo projeto. Contudo, embora você não os tenha identificado, eles estão lá, e provavelmente serão foco de uma mudança de projeto num estágio mais adiante ou de um novo projeto de melhoria para cobrir os requisitos que não haviam sido identificados na construção.

Cuidado com isso! Procure identificar todos os stakeholders o quanto antes. Fica muito mais caro atender a uma norma da prefeitura de adequar a distância de recuo para a casa do vizinho depois que a casa já está construída.

Assim como a prefeitura, considero que o Fisco, o INSS e os sindicatos também estão lá com suas estacas. Se você não os perceber, eles vão ficar de fora do perímetro de sua análise de requisitos e vão aparecer somente lá na frente com suas exigências. Nessa hora não dá para alegar que o escopo mudou e que são exigências novas. Esses stakeholders sempre estiveram lá e isso sempre deveria ter feito parte do escopo. Só não haviam sido identificados.

É claro que o escopo do projeto não é totalmente identificável de início e será progressivamente elaborado e detalhado durante repetidas iterações (Contribuições do amigo Cláudio Kerber). Não acho que depois que você fechar a caixa precisa jogar a chave fora. Pode mudar depois. Mas a cada planejamento é preciso trabalhar com um escopo fechado. Pode ser cheio de incertezas e suposições que irão se confirmando no meio do caminho. Se não se confirmarem, o escopo é reavaliado e renegociado. Pode-se também trabalhar com planos mais curtos em pequenas entregas. Mas, entendo que cada entrega deve ter um escopo fechado.

O fechamento do escopo não deve ser visto como uma limitação ou uma restrição que não pode ser transposta. Mas como um entendimento combinado sobre o que faz parte de uma iniciativa para que se permita o planejamento das ações necessárias. Esse entendimento cria um acordo claro entre os stakeholders que deve ser continuamente revisto e validado a cada iteração.

Outro ponto importante e que não pode ser deixado de lado (contribuição do Jefferson Anselmo) é que, embora minha metáfora tenha se limitado a dimensão escopo, os stakeholders irão também influenciar as outras dimensões do projeto como o prazo, o custo, os riscos, as oportunidades, os recursos... Por isso mesmo, é bom começar a elicitação identificando com cuidado quem segura uma estaca para o seu projeto. 

Definição do nível adequado de documentação

Sei que este artigo talvez esteja nadando um pouco contra a corrente, mas me sinto na obrigação de discutir este assunto e buscar iluminar algumas questões obscuras e que são continuamente abordadas nas metodologias de grandes empresas.

• Devemos ou não documentar os requisitos de maneira formal?
• Qual o nível de detalhe adequado para a documentação?
• A metodologia corporativa deve determinar com detalhes quais são as entregas obrigatórias ou isso deve ser uma decisão tomada a cada projeto?
• A metodologia não está engessando nosso processo e burocratizando nossas atividades?

Para responder essas questões, antes acho necessário conceituar e discutir alguns termos e seus significados.

Metodologia e Burocracia

Em sua origem Max Weber (1864-1920) definiu a burocracia como uma forma de organização que se baseia na racionalidade, isto é, na adequação dos meios aos objetivos pretendidos (fins), a fim de garantir a máxima eficiência possível.

Uma burocracia define regras impessoais que estipulam:

•  A divisão do trabalho;
•  Rotinas e procedimentos que garantem a previsibilidade dos resultados;
•  As qualificações técnicas e meios necessários para desempenhar cada função;
• O nível de autoridade de cada função.

Partindo desta definição, o termo pode ser praticamente considerado um sinônimo de metodologia:

Vamos dividir a frase acima em duas partes e analisá-las começando pelo final:

Os “objetivos da organização” normalmente estão diretamente ligados à entrega de um produto final ou serviço aos seus clientes externos ou internos. Por exemplo, podem ser objetivos: desenvolver ou manter um sistema de TI, produzir uma campanha de marketing ou contratar um novo funcionário.

Mas os objetivos não se resumem às entregas. Também devem ser satisfeitas as necessidades de manter adequado o custo-benefício do trabalho e garantir a continuidade do negócio após a entrega. Ou seja, eficiência e retenção do conhecimento também podem ser considerados objetivos.

A primeira parte da frase sobre a metodologia refere-se a estipular um “caminho racional”. Este caminho é geralmente descrito por uma sequência de etapas ou atividades que devem ser cumpridas num determinado processo. Cada atividade deverá ser desempenhada por um profissional, que no momento da execução assume um papel específico e utiliza uma técnica específica para elaborar uma entrega, artefato ou documento.

Como exemplo de caminho racional podemos pensar num restaurante por quilo, onde o cliente se serve no buffet, um funcionário pesa o prato e gera a comanda e outro cobra pelo serviço no caixa ao final. Papéis e responsabilidades distribuídas.

Processos mais complexos podem ter diversas etapas e entregas intermediárias, como por exemplo a construção civíl com Croqui, Planta Arquitetônica, Hidráulica, Elétrica, Estrutural, Alvará de Construção, Habite-se, Guia de Recolhimento de INSS, Cronograma, Fluxo de Caixa...

Críticas à burocracia (e consequentemente à Metodologia)

Essas entregas intermediárias compõem o chamado “papelório”. No conceito popular é considerada “burocrática” a organização onde o papelório se multiplica e se avoluma, impedindo soluções rápidas e eficientes. Burocracia é reconhecida, portanto, como um termo perjorativo.

Nessas organizações os funcionários têm tal apego e comprometimento aos regulamentos e rotinas e que as entregas finais deixam de fazer parte do “objetivo da organização”. A conformidade com as regras passa a ser o novo objetivo que guia as atividades.

Os funcionários acostumam-se tanto com as regras e com a atuação em seu papel que eliminam a criatividade do seu modo de agir e limitam-se a atuar no preenchimento dos campos obrigatórios dos “templates” de suas entregas intermediárias. Qualquer mudança nas regras em vigor passa a ser vista como uma ameaça à sua segurança e são sempre recebidas com resistência explícita ou implícita.

Como a definição formal dos papéis busca a impessoalidade para a definição de responsabilidades, esta impessoalidade é também tranferida para os relacionamentos que tornam-se despersonalizados e frios. Uma organização burocrática é tida como uma organização fria e “chata”.

O funcionário torna-se por fim, tão voltado para as regras internas da organização, que se desvincula completamente do cliente e suas necessidades.

Métodologias Tradicionais (Cascata)

Em metodologias tradicionais (cascata) uma etapa só inicia quando a etapa anterior é concluída. A conclusão de uma etapa geralmente é formalizada com uma entrega intermediária. Por exemplo a construção de uma parede precisa da planta aprovada, ou a contratação de um gerente para um novo departamento pode depender do organograma atualizado.

Cada entrega pode ser verificada para garantir a qualidade da execução daquela etapa do projeto, que ocorre evolutivamente até a entrega final. Na obra de construção de uma usina hidreelétrica, por exemplo, nenhum tijolo é comprado antes que sejam avaliados os impactos ambientais e todas as licenças necessárias sejam aprovadas.

Os projetos que seguem metodologia cascata sofrem demais com os efeitos “nocivos” da burocracia. Os envolvidos tendem a se comprometer mais com as entregas intermediárias (o tal “papelório”) do que com a entrega final. Muitas vezes o conceito de agregar valor ao cliente e a empresa se perdem totalmente e são substituídos pela rotina de cumprir sua tarefa de maneira automática.

Fuga da Burocracia – Processo Ad hoc

Como estratégia para não cair nas armadilhas da burocracia muitos gerentes têm buscado flexibilizar totalmente a forma de trabalho. Alguns optam por não definir metodologia alguma e serem totalmente flexíveis para atender quaisquer necessidades que venham a surgir. O método de trabalho é definido “ad hoc”, ou seja, a cada caso.

Essa estratégia pode funcionar bem em organizações onde existe uma equipe de profissionais excelentes, experientes e capazes de se adaptar a cada situação. Contudo, deve-se ter claro que a maturidade dos profissionais não reflete a maturidade da empresa. Ou seja, a empresa não é adaptada a lidar com qualquer situação. Os profissionais é que são. Sem os profissionais, a empresa não é capaz de reter o conhecimento.

Por não definir um processo padronizado, geralmente a empresa também não possui meios próprios de garantir a qualidade de todas as entregas. O próprio conceito de qualidade pode ser questionado quando não há padrão.

Metodologias Ágeis

Outro caminho para fugir dos problemas da burocracia tem sido apresentado pelas metodologias baseadas no manifesto ágil (www.agilemanifesto.org). Essas metodologias têm como valores e princípios:

• Valorizar indivíduos e interações acima de processos e ferramentas.
• Priorizar a satisfação dos clientes com entregas contínuas de produtos úteis em pequenas iterações.
• Usar como medida de desempenho a quantidade de itens do produto final entregue a cada iteração.

Mas é um erro pensar que as metodologias ágeis são ad hocs. Para que tenham sucesso é essencial a definição de processos, regras, papéis e responsabilidades. Portanto, são também burocráticas por natureza (no sentido original da palavra e não no perjorativo).

A grande “sacada” é a divisão das entregas finais em pequenas iterações, não permitindo que os envolvidos percam de vista os objetivos do negócio. A produção de produtos intermediários não representa resultado. No limite, poderia até ser zero. O importante é a entrega do produto final pronto para agregar valor ao negócio.

Risco aos objetivos da organização

Diminuir o papelório, substituindo-o por comunicações mais frequentes e eficazes entre os diversos envolvidos no projeto é mesmo uma excelente estratégia para otimizar o trabalho e aumentar a integração de todos com foco nos resultados para os clientes. Mas aqui há um perigo que muitas empresas não tem dado a devida atenção.

Nem toda documentação é papelório intermediário ou burocracia inútil. Muita documentação deve fazer parte das entregas finais juntamente com o produto final. O manual do usuário, a certidão de habite-se, o documento de posse de um veículo ou um modelo de dados atualizado são exemplos de papelório que precisam fazer parte do resultado final juntamente com a entrega. Nas metodologias tradicionais estes documentos são (ou deveriam ser) entregas de alguma das etapas intermediárias. Isso deveria garantir que estivessem disponíveis ao final do projeto. Mas nem sempre isso acontece.

Muitas vezes a documentação criada em cada etapa tem somente o foco nos benefícios para o projeto. Por exemplo, indicar minuciosamente quais mudanças devem ser realizadas em um software. Embora esta informação seja útil para a próxima etapa do projeto, ela não pode ser considerada documentação do produto. A documentação do produto deve garantir o atendimento de outros objetivos que extrapolam os limites do projeto:

• Retenção do conhecimento sobre o produto
• Auxiliar na análise de impacto em futuras manutenções
• Agilizar o treinamento de novos funcionários
• Possibillitar a contratação de novos fornecedores

Conclusão

As metodologias que buscam maior agilidade em projetos não podem comprometer a estabilidade do negócio. Alguns documentos atualizados devem ser exigidos como parte das entreguas finais de todos os projetos.

Em projetos de software, por exemplo, as regras de negócios e alguns tipos de requisitos devem ser atualizados e versionados juntamente com o código fonte. A release 3.14.216 de um produto está associada a um grupo de requisitos e regras de negócios diferentes da versão anterior.

A decisão de quais são estes documentos e a forma como devem ser elaborados não pode ser tomada em cada projeto. Esta decisão deve ser tomada num nível de governança corporativa que irá definir a burocracia adequada para que os objetivos da organização possam ser atendidos de maneira adequada.

A burocracia pode ser flexível exigindo diferente documentação e diferente nível de detalhamento para cada produto, com base no que agrega valor para suas futuras manutenções. Por exemplo, para um determinado sistema de TI pode ser essencial manter atualizado o modelo de dados, para outro os fluxos de processos e para outro o mais importante são os casos de uso descritos passo a passo.

Importante é que esta definição não seja tomada no âmbito dos projetos, mas sim com uma visão de mais longo prazo, e os requisitos exigidos pela burocracia escolhida passem a ser mantidos de maneira formal em todos os projetos.

Artigo publicado originalmente no IIBA BA Connection como BABOK^® Guide 2.0 now in Portuguese.

Recebi um email de Kevin Brennan, Vice Presidente do IIBA, me pedindo que escrevesse um artigo para descrever como foi o processo de tradução do BABOK 2.0 para o português e que enviasse juntamente com o artigo uma foto da equipe que participou do projeto. O artigo não deve ser difícil, pensei, mas a foto... A maior parte dos participantes do projeto está esparramada pelo Brasil, um país de escala continental, e alguns estão ainda mais longe, em outros continentes. Foi então que me dei conta de algo realmente interessante neste projeto: todo o trabalho ocorreu sem que houvesse sequer uma reunião presencial entre os membros da equipe. Discutimos diariamente a tradução de termos e as expressões mais usadas no mercado brasileiro a fim de não perder o sentido original de cada conceito apresentado pelo BABOK. Pontos de vista foram apresentados, idéias avaliadas e ao final, quando não foi possível o consenso, valeu o princípio da democracia. Toda essa interação ocorreu por meio de ferramentas de colaboração virtual e com o excelente resultado que agora pode ser baixado em formato PDF do site do IIBA e em breve estará disponível também para compra em formato impresso para toda a comunidade de analise de negócios de língua portuguesa.

A tradução começou em 2009, logo após o lançamento da versão 2.0. A parte do trabalho que realmente tomou mais tempo foi a de revisão. Para esta etapa o IIBA exigiu que a equipe de revisores fosse formada por Analistas de Negócios experientes e de várias formações diferentes. Abrimos duas chamadas de voluntários para conseguir formar uma equipe com o perfil desejado em abril de 2010.

Nosso projeto foi oficialmente concluído em janeiro de 2011 e estou certo de que nossa experiência poderá ajudar futuras iniciativas de tradução do BABOK para outras línguas ou de outros conteúdos. Compartilho a seguir um pouco da metodologia que desenvolvemos para este projeto, em especial as ferramentas de colaboração e a estrutura de revisão em etapas.

FERRAMENTAS DE COLABORAÇÃO

 Portal colaborativo de termos

Criada pelo nosso principal tradutor, Cláudio Kerber, esta ferramenta Web permitiu a nossa equipe discutir a melhor tradução para cada termo e armazenar discussões em uma espécie de blog do termo com os comentários de cada membro da equipe sobre sua perspectiva. Foi fundamental para o alcance de consenso entre os revisores e serviu como base de consulta durante a revisão.

 Google Groups

Criada exclusivamente para este projeto, o grupo de discussão facilitou o compartilhamento de arquivos e principalmente a troca de mensagens entre todos de maneira ágil e sem burocracia.

Controle de alterações do MS Word

Essa excelente funcionalidade do MS Word permite que se visualize o histórico de alterações sobre um documento indicando quem fez cada alteração. Assim um revisor pode sugerir uma nova tradução de um trecho consultando no histórico o que outros já sugeriram e alteraram anteriormente no mesmo trecho.

Gestão de versões e arquivos

Assumi a responsabilidade de controlar a distribuição dos arquivos aos revisores e coletar e compilar as novas versões. Não foi necessário nada mais elaborado que uma planilha dizendo com quem e em qual situação se encontrava cada arquivo e uma organização de versionamento em pastas, uma para cada etapa da revisão como explicado a seguir.

ETAPAS DE REVISÃO

Com a equipe formada, o projeto de revisão foi definido em etapas com objetivos distintos:

Alinhamento de termos:

Antes de iniciar o processo de revisão, os principais termos utilizados pelo BABOK foram identificados, listados e cadastrados no portal juntamente com a sua tradução sugerida e a justificativa. Cada um desses termos foi revisado pela equipe a fim de identificar a sua melhor correspondência no Português.

Esta lista foi formada inicialmente com base no glossário de análise de negócios (apêndice A), áreas de conhecimentos, nomes de tarefas e técnicas do BABOK e depois complementada com palavras onde os tradutores tiveram qualquer insegurança.

Muitas palavras em inglês podem ter significados múltiplos em português, outras podem ser traduzidas de diferentes formas e algumas outras definitivamente não têm tradução. Chegar a um consenso entre todos os membros da equipe sobre qual tradução usar para cada termo foi passo fundamental para garantir a qualidade e consistência do resultado final.

Revisão 1ª etapa – Alinhamento de termos

Com a tradução de cada termo definida no portal, revisamos todo o BABOK já traduzido para garantir que o termo correto foi utilizado. Nossos tradutores facilitaram este trabalho, pois já deixaram os termos grifados.

O BABOK foi dividido em arquivos menores e distribuído entre os revisores. Cada um se responsabilizou por uma parte.

Para próximos trabalhos sugiro que façam o alinhamento dos termos antes da tradução. Isso poupará esforços e evitará retrabalho.

Revisão 2ª etapa – Revisão espelhada

Usando a mesma divisão de arquivos anterior, mas agora com os termos já revisados, redistribuímos uma parte para cada revisor que assumiu a meticulosa tarefa de comparar, frase a frase, o original em inglês com o em português para garantir a conformidade do significado da tradução.

Esse processo de distribuição dos arquivos foi também utilizado em todas as etapas seguintes, o que deu agilidade ao processo. Uma regra, contudo, foi estabelecida para evitar vícios: “um mesmo revisor não revisa o mesmo arquivo mais de uma vez.”

Revisão 3ª etapa – Clareza e consistência

Nesta etapa os revisores foram orientados a ler o texto diretamente em português e a fazer ajustes para garantir a coerência e a adequação lógica do texto à língua portuguesa. O original em inglês seria consultado somente caso ainda restassem dúvidas quanto ao sentido original. Na prática, pouquíssimos trechos não exigiram esse tipo de consulta e várias melhorias foram indicadas.

Revisão 4ª etapa – Gramatical

Diferentemente das demais etapas esta não foi feita por Analistas de Negócios, mas por uma especialista em língua portuguesa, para garantir a correção gramatical.

A língua portuguesa passou recentemente por um novo acordo entre os países que falam português o BABOK 2.0 em português já está aderente às novas regras.

Diagramação

Esta etapa ficou sob responsabilidade do IIBA Internacional que além de colocar o texto no estilo de formatação do IIBA, gerou as versões finais das figuras, índice e capa.

Revisão Final

O processo de diagramação mesmo que sem intenção acaba introduzindo alguns erros ao texto final. Esses erros exigiram novas revisões. Ao todo, mais 4 revisões foram feitas após a diagramação.

Durante essas revisões algumas melhorias ainda foram sugeridas pelos revisores em relação às etapas anteriores do projeto.

Não desaparece nunca a sensação de que poderíamos melhorar ainda mais e que encontraremos frases na versão final que ainda gostaríamos que fossem melhores. Mas é hora de publicar o resultado.

Eu espero que a comunidade em língua portuguesa se beneficie de nosso trabalho e que o BABOK 2.0 possa, com essa tradução, ser difundido mais claramente como o padrão internacional para a prática da análise de negócios.

Fabrício Laguna, CBAP, PMP, Vice Presidente do IIBA Capítulo São Paulo, Gerente do Projeto de Tradução

Após muito esforço e trabalho o Guia BABOK está disponível empara os membros do IIBA no endereço:
http://community.theiiba.org/library.htm?mode=view&did=139641&lid=87753&wf=87754

Para quem não é associado e quizer consultar pode acessar o Guia BABOK no google books em:
http://books.google.com/books?id=wZvSEEg39N4C&printsec=frontcover&dq=babok&hl=en&ei=byNtTaiTJMSltwfFjoXDBQ&sa=X&oi=book_result&ct=result&resnum=3&ved=0CDwQ6AEwAg#v=onepage&q&f=false

Os voluntários que tornaram essa faça possível:

Tradutores:
▶ Claudio Brancher Kerber (Coordenador da tradução)
▶ Flávio Augusto Serra Kauling

Revisores da Análise de Negócios:
▶ Alfonso José Izarra Molina, MBA
▶ Aline Vicente So
▶ Cárin Cristina Orsi Duarte, PMP
▶ Celso Luiz Bicca
▶ Fabrício Costa Moraes, MSc
▶ Fabrício Laguna, MBA, CBAP, PMP (Coordenador da revisão e do projeto de tradução)
▶ Fernando Carvalho, MSc
▶ Marcelo Menezes Neves
▶ Rafael Oliveira Cardoso
▶ Suzandeise de Almeida Inácio Thomé, MSc, CBAP
▶ Tatiana Pereira
▶ Judith Pavón, PhD

Revisão do gramatical, sintática e ortográfica:
▶ Marina Mello

Coordenação Geral:
▶ Ana Teresa Sant´Anna Laguna, PhD

Em nome do Projeto de Tradução, do Capítulo IIBA São Paulo e de toda a comunidade de análise de negócios de língua portuguesa,

"Muito obrigado a todos vocês."

Fabrício Laguna

Divisão de papéis e responsabilidades em Projetos de TI

Organizações que buscam aumentar sua maturidade devem se esforçar em entender e definir papéis e responsabilidades de forma clara. Esta definição orienta as atividades e garante o cumprimento de objetivos específicos. Em outras palavras, a sobrevivência de um peixinho de aquário depende de que algum membro da família assuma a responsabilidade de alimentá-lo diariamente na quantidade apropriada. Se o papel não for claramente definido, o peixinho certamente irá morrer de fome ou de congestão.

Tenho acompanhado organizações que desenvolvem ou mantém sistemas de TI. Nestas organizações há objetivos diferentes a serem alcançados e que justificam a definição de responsáveis específicos. Por exemplo, enquanto o programador foca seus esforços em concluir o código fonte e a integração dos componentes, o gerente de projetos replaneja o cronograma buscando formas de cumprir o prazo. São objetivos diferentes, que exigem ações e habilidades diferentes, mas que são igualmente importantes.

Os nomes e responsabilidades dos papéis podem ser diferentes em cada organização dependendo de seu tamanho, de sua metodologia e do seu grau de maturidade, mas gosto de pensar na divisão dos papéis em dois grandes grupos: Orientados a Projetos e Orientados a Processos.

O grupo que trabalha orientado a projetos pode ser chamado de turma do “Vamos que vamos!”, pois são altamente comprometidos com o cumprimento dos prazos estabelecidos. Este grupo é o responsável por entregar o produto final e é protagonista no planejamento e execução de cada projeto. Possui um papel de agente de mudanças, uma vez que projetos geralmente alteram sistemas e modificam a forma de trabalho atual da organização para uma forma nova ou otimizada.

Os profissionais orientados a processos fazem parte da turma do “Muita calma nessa hora!”. São mais comprometidos com a qualidade das entregas intermediárias e com a estabilidade dos processos. São guardiões da documentação e dos sistemas e devem garantir a integridade das informações e ambientes utilizados pela organização.

Uma lista de alguns papéis que considero em cada um dos grupos:

É fácil perceber que a própria natureza desta divisão de papéis causa conflito. Em muitas organizações estes grupos agem como duas equipes competindo uma contra a outra. Enquanto um grupo promove mudanças, o outro luta para manter o ambiente estável e seguro. Um prioriza o prazo; o outro a qualidade. No meio deste conflito a área de Governança de TI atua como árbitro da partida dando razão e apoio a um ou outro grupo em cada situação, de modo a garantir que os interesses corporativos estejam acima das disputas locais. Não raramente estes conflitos extrapolam os projetos e se materializam nos relacionamentos interpessoais de forma destrutiva.

O modelo ideal é o das organizações que posicionam estes papéis como parceiros para o sucesso de toda a organização e de seus projetos. Em vez de equipes competindo entre si, a visão propagada é a de uma única equipe, colaborando com competências e habilidades complementares, totalmente comprometida com o resultado da organização. O conflito destrutivo dá lugar ao conflito produtivo, e o papel da Governança, neste caso, é o de atuar como técnico da equipe.

Nenhum time marca gol sem ter no ataque a força motivadora do “Vamos que vamos!” empurrando todo mundo para frente e apertando o passo para cumprir o escopo dentro do prazo e do orçamento combinado. Mas também não se ganha o jogo sem se preocupar com a defesa com “Muita calma nessa hora!” exigindo o cumprimento de processos essenciais e definindo jogadas ensaiadas que irão aumentar a previsibilidade dos resultados.

A definição clara dos papéis e responsabilidades pode facilitar o encontro de soluções ganha-ganha, pois os objetivos ficam claros e mais facilmente compartilhados pelos envolvidos.

 Trabalhando com sinergia, a turma do “Muita calma nessa hora!” pode entender e se mobilizar para auxiliar o cumprimento dos prazos e atendimento dos requisitos de projetos, embora estes não sejam seus principais objetivos. De outro lado os “Vamos que vamos!” podem entender que não basta ter sucesso num projeto, mas é preciso garantir a melhoria contínua dos processos organizacionais rumo aos objetivos estratégicos.

Em outras palavras, a equipe vencedora disputa com garra cada jogo, sem perder de vista a estratégia elaborada para ganhar o campeonato.

Analistas de Negócio têm muito a comemorar com a nova versão do BABOK[1], lançada em 31 de março de 2009 pelo IIBA[2].

O lançamento em 2006 da primeira versão do guia representou um grande avanço para esta área que há tempos vem sofrendo de crise de identidade. Espremida entre Análise de Sistemas, Gerenciamento de Projetos, Engenharia de Software, Qualidade e outras, a Análise de Negócios pôde, pela primeira vez, afirma-se como o elo entre os diversos envolvidos, com tarefas e técnicas específicas. O BABOK formou um vocabulário comum e orientou a formação de profissionais, servindo como base para o exame de certificação CBAP[3], aos mesmos moldes dos já consagrados PMBOK[4] e PMP[5].

Mas a primeira versão era incompleta e não agradou a todos. Alguns pontos abordados pelo guia ainda estavam um pouco confusos, havia repetições de alguns assuntos e outros estavam assumidamente incompletos, prometidos no próprio texto do guia para as próximas versões.

A nova versão 2.0 está mais simples de usar e mais fácil de entender. Todas as tarefas seguem uma estrutura rígida e bastante clara com entradas, saídas e técnicas muito bem definidas. As redundâncias foram corrigidas e os assuntos condensados de 76 tarefas para apenas 32, mais genéricas e aplicáveis a qualquer organização ou metodologia. Embora a especificação de requisitos de sistemas de TI ocupe um bom espaço do BABOK, as competências do analista de negócios estão mais claramente direcionadas para o encontro da solução de forma mais ampla, seja por meio de TI ou não. Podem ser facilmente mapeadas a diversas Metodologias e Frameworks, incluindo Desenvolvimento Ágil, CMMi, BPM e outras.

Quem trabalha com planejamento estratégico, solução de problemas, atendimento de expectativas, gestão de escopo e requisitos vai poder aproveitar o BABOK 2.0 como sendo um guia de referência para estruturar suas tarefas diárias e orientar o desenvolvimento das competências essenciais para o desempenho de suas funções.

[Artigo publicado originalmente em novembro de 2008 no Fique Experto - O Jornal da Expertise] 

Muitas organizações, atentas às tendências de mercado, estão em dúvidas sobre como implantar a Análise de Negócios no organograma de sua empresa. As principais dúvidas são: O analista de negócios deve ser subordinado a TI ou a área de negócios? Devemos criar uma área de Análise de Negócios ou somente o papel do analista dentro das demais áreas? Onde termina o trabalho do analista de negócios e onde começa o do analista de sistemas? O mesmo vale para o conflito com o trabalho de outras funções: gerente de projetos, analista  financeiro, usuário, garantia da qualidade...

Este artigo expõem algumas considerações importantes para ajudar a esclarecer estas dúvidas. A primeira e mais importante é que não há uma única estrutura organizacional que sirva para todas as empresas. 

“A implantação do papel do analista de negócios em uma empresa terá sucesso se considerar as várias variáveis envolvidas e for escolhida a estrutura mais adequada à cada necessidade específica.”

 (veja as variáveis e estruturas mais adiante)

Outro ponto de reflexão importantíssimo é que a Análise de Negócio não vai começar a ser feita em sua empresa somente após a criação de um papel formal para o analista de negócios. A Análise de Negócios já vem sendo feita há muito tempo. Sempre que sua empresa precisou desenvolver soluções para os problemas do negócio, alguém atuou entendendo os problemas, identificando as necessidades e estruturando a solução que pareceu ser a mais adequada naquele momento. Em outras palavras, realizou tarefas da área de Análise de Negócios. Definir formalmente o papel não é pré-requisito para que as atividades aconteçam. É sim um passo importante para que ele possa ser melhor estruturado com o uso das técnicas e métodos mais adequados.

Níveis de maturidade da Análise de Negócios na organização

Muitas empresas começaram assim sua área de desenvolvimento de sistemas, apenas com um programador ou uma equipe de programadores. Este profissional assumia uma série de atividades além da codificação, entre elas levantamento com os usuários, estudo de viabilidade técnica, análise, design, documentação, gestão de projetos, testes, treinamento aos usuários e etc.

No posto de saúde, esta precariedade de recursos foi suficiente por muito pouco tempo. Tão logo o posto se tornou conhecido e os primeiros doentes foram tratados, muita gente ficou interessada no “postinho” e o número de pacientes aumentou exponencialmente.

Contrataram logo mais um médico, mas mesmo assim os pacientes se amontoavam na porta para serem atendidos. Um grande avanço na qualidade do atendimento se deu quando contrataram uma recepcionista que atendia os pacientes num balcão próximo à porta do posto e ficou encarregada das atividades de agendar consultas e controlar o arquivo de prontuários e o estoque de medicamentos. Com uma pessoa assumindo estas tarefas, os médicos puderam dedicar todo o seu tempo de trabalho nas consultas aos enfermos, o que aumentou muito a eficiência do posto de saúde.

Aquele posto de saúde, hoje, já é um hospital e conta com vários profissionais de diferentes especialidades. Os médicos, que inicialmente eram apenas dois clínicos gerais, hoje são  pediatras, cardiologistas, oftalmologistas, neurologistas e ortopedistas. Desta forma, hoje é possível tratar doenças mais complexas e em maior escala.

A formalização de um papel de analista de negócios em uma empresa de desenvolvimento de sistemas é um passo natural, a partir de um certo nível de maturidade, exigido por projetos mais complexos ou de maior volume. Tratar a Análise de Negócios como uma especialidade, com técnicas, ferramentas e conhecimentos específicos, permite um salto de qualidade nos projetos de desenvolvimento de sistema, minimizando o retrabalho e garantindo o retorno adequado dos investimentos da organização.

Variáveis envolvidas e estruturas possíveis

Empresas com este perfil, em geral, possuem uma estrutura projetizada e os analistas de negócios são alocados por projeto, sendo ali os responsáveis por definir quais serão as técnicas e atividades mais adequadas para gerenciar os requisitos.

Já nas empresas onde o número de projetos é muito alto, os analistas tendem a ter uma atuação mais padronizada e limitada ao início dos projetos, elaborando estritamente os artefatos definidos pela metodologia para a especificação dos requisitos necessários para fechar o escopo do sistema e, com isso, estimar prazos e custos. Neste modelo, o analista de negócios pode atuar simultaneamente em vários projetos.

Complexidade dos projetos

Empresas com projetos de alto grau de complexidade podem demandar a criação de uma área independente de Análise de Negócios formada por diversos especialistas. Um especialista em Análise Financeira projeta fluxos de caixa e calcula o retorno para vários cenários de negócio, um designer talentoso cria esboços de telas e auxilia na elaboração de protótipos e requisitos de usabilidade, um condutor de JAD atua de forma neutra na negociação entre diversos stakeholders, enquanto isso, uma equipe de especificadores descrevem documentos de requisitos de softwares na forma de casos de uso.

Estes especialistas podem ser alocados aos diversos projetos em momentos pontuais, contribuindo com suas especialidades de forma a permitir a realização de atividades de Análise de Negócios com maior profundidade.

Caso não se dê a devida atenção a isso, a empresa corre o risco de fazer Análise de Negócios de forma amadora, pois o amadurecimento das técnicas de análise não será o foco das áreas onde se encontram os analistas de negócios.

Cultura organizacional

Para definir como será a atuação do analista de negócios, a empresa deve avaliar de que forma está acostumada a trabalhar e buscar o menor impacto em seus processos atuais. Entre as questões culturais estão:

• A estrutura de comando: Projetizada, Funcional ou Matricial.
• Qual a área de maior força política: áreas de negócio ou desenvolvimento de sistemas.
• De que forma são gerados os requisitos: reativa pelas reclamações dos usuários ou pró-ativa em busca de melhorias de desempenho.
• Atualmente quem especifica os requisitos: TI ou área usuária.