O relacionamento entre os analistas de negócio e desenvolvedores de software.

O problema mais difundido entre as “torres” na grande maioria dos casos está nos braços dos analistas de negócio, conforme estudo realizado pelo Phoenix Chapter of IIBA. Em 90% dos casos, os BA´s (business analysts) não conseguem comprometer os desenvolvedores de software com a real necessidade da área de negócios precisa.

Grandes organizações consideram os  BA´s, como o MAESTRO DA TI, mas o ônus de orquestrar uma área com alto valor agregado e com grandes e competentes elementos envolvidos, considero uma arte, pois lidar com toda a carga de responsabilidade em representar a área de negócios e sintonizar os Desejos x as Necessidades é seu maior desafio, e é aí que pecam os BA´s.

Os desenvolvedores de software com toda a sua expertise técnica tem uma importância ímpar no desenvolvimento das ações, sua competência sistêmica e vivência lógica agregam o devido valor quando a proximidade entre ambos é conquistada. Comparo o desenvolvedor de software ao violinista e a área de negócios à plateia, enquanto o BA ao elemento que transforma a música em arte, apenas colhendo de ambos os lados o melhor de cada um.

Segundo consultores do Phoenix Chapter of IIBA os BA´s são construtores naturais de relacionamentos. As partes interessadas no negócio tendem a valorizar suas contribuições e procuram envolvê-las nos projetos. Mas quando chega o momento de defender seu "direito" a um papel no projeto, em alguns casos os próprios membros da equipe questionam o valor que trazem à mesa.

Tudo isso me fez pensar sobre a relação dos BA´s versus desenvolvedores de software e como podemos melhorá-la. Embora gostaríamos de pensar (ou esperar) que os cuidados de desenvolvedores de software sobre a linha de fundo da organização, fosse olhar as coisas sob a perspectiva de como poderia ser melhor o contato com a área de negócios... Acrescento: Proximidade e bom relacionamento, integrando conteúdo e olhando sempre para o maior objetivo (que não são os das áreas e sim o da organização).  O de considerar que a TI é apenas um provedor de serviços, um grande fornecedor de soluções, esse sim deve ser o real sentimento comum entre de desenvolvedores e analistas de negócios.

Agora, segue o desafio:

Se eu fosse um desenvolvedor, por que eu me importaria?

Se eu fosse um analista de negócios, como eu me comportaria?

Se eu fosse da área de negócios, o que eu esperaria?

Se nós, como BA´s pudéssemos ajudar a reduzir o retrabalho, que, sem dúvida, deve ser feito, pergunto: Como mudar o sentimento da maioria dos desenvolvedores que somente é motivado por "horas trabalhadas", ou seja, dispender seu tempo em escrever e reescrever códigos, e quanto mais seu tempo é gasto no mesmo pedaço de código, menos intelectualmente interessante fica o trabalho.

Com isso, os pedidos de mudança sempre significam um cronograma de projeto ampliado, que mais frequentemente significam também horas extras de desenvolvimento, em suma o maior fator motivador dessa classe: Horas trabalhadas multiplicadas por X reais, resultando em FATURAMENTO.

Eu nunca conheci um desenvolvedor que gostava de participar de reuniões e de se integrar, muitas vezes ele está lá, envolvido em proporcionar um pouco de entrada na direção, mas realmente esperando a resposta exata de que necessitam para que possa construir a solução.

Naturalmente seu foco é perdido, e aí que mora o risco (o escopo desse post), pois exatamente nesse momento é que o MAESTRO DA TI, deve trazer a responsabilidade do momento e promover a sintonia do solicitante e do solicitado.

Como você planeja seu levantamento e processo de análise de requisitos? Você acha que um desenvolvedor de software, deve participar dessa ação? Outra pergunta a fazer é: você precisa de um desenvolvedor em uma reunião de kickoff de projeto?

Por fim, como numa orquestra o MAESTRO depende de seus músicos, esses que dependem de seus instrumentos e sua plateia, e essa que vê no MAESTRO o condutor da sinfonia, é como encaro o departamento de TI.

Deixo no ar, duas perguntas:

Você como analista de negócios, já enfrentou desafios semelhantes em ser respeitado como esse MAESTRO dentro de sua própria organização de TI?

Você como MAESTRO DA TI, já comunicou o valor de uma área de análise de negócios para um desenvolvedor de software?

Dedico este post em homenagem ao meu amigo Paulinho.

Fonte: http://www.infoq.com/

O que é Análise de Negócios?

Vídeo explica de forma simples e lúdica o que é a análise de negócios. 

Publicado por Fabrício Laguna, da Gigante consultoria.  

1ª Treinamento SCRUM aos sábados.

No último dia 04/03/2012 iniciamos nossa 2ª turma de treinamento em SCRUM, em parceria com a Athem e Sucesso-SP.

Agradeço a presença e confiança de todos.

Modelagem Ágil: aperfeiçoando a comunicação e a compreensão

Estatísticas alarmantes mostram que os projetos de TI chegam a custar 400% mais que o previsto, realizando apenas 25% dos benefícios prometidos. Embora pesquisas do Standish Group mostrem alguma melhora neste quadro, estamos ainda muito longe do sucesso em projetos de TI.

Podemos classificar o fracasso dos projetos em duas categorias:

• Técnico:
• A solução não atende aos requisitos do projeto (escalabilidade, performance, confiabilidade, custo etc.);
• Devido aos desafios técnicos, prazos são ultrapassados, até que os patrocinadores perdem a confiança e encerram o projeto.

• Funcional:
• A equipe não compreende os requisitos fornecidos;
• Os requisitos fornecidos não são os requisitos corretos.

Parte dos problemas se deve a um pensamento simplista de causa e efeito entre os domínios do problema e da solução. Acredita-se que, compreendido o problema, basta encontrar uma solução.

A Modelagem Ágil é coerente com o Manifesto Ágil e seus princípios. Portanto, é uma prática que pode fazer parte do seu repertório de ferramentas ágeis.

Entretanto, os atuais projetos de TI são maiores em escopo, custo e prazo, além de serem mais complexos, envolvendo muitos sistemas e departamentos de uma ou mais empresas. A compreensão do problema e da solução caminham juntos, ou seja , à medida que são propostas soluções, compreende-se melhor o problema.

Esse processo iterativo de análise nos domínios do problema e da solução é ainda mais complexo do que a visão simplificada anterior, por envolver divers a s partes interessadas com pontos de vista e capacidades de compreensão diferentes.

A figura acima resume as causas de fracasso do ponto de vista funcional mencionadas no início. E o fracasso funcional é uma das grandes causas dos fracassos técnicos. Portanto, as seguintes dimensões são cruciais para o sucesso nos projetos:

• Compreensão
• Compreendemos o domínio do problema?
• Compreendemos o domínio da solução?
• Compreendemos a transição entre esses dois domínios?

• Comunicação
• As partes interessadas são capazes de comunicar os requisitos para aqueles que irão desenvolver a solução?
• Os membros da equipe que desenvolverá a solução são capazes de comunicar os detalhes da solução entre eles?
• A equipe de desenvolvimento é capaz de comunicar os desafios e alternativas para as partes interessadas? 

Os ideais básicos do Agile (manifesto , princípios e bom senso) surgiram da necessidade de reforçar as dimensões de compreensão e comunicação.

A figura anterior ilustra o Manifesto Ágil, em que (nunca é demais lembrar):


Indivíduos e interações são mais importantes que processos e ferramentas; 
Responder a mudanças é mais importante que documentação; 
Colaboração com o cliente é mais importante que negociação de contratos; 
Software funcionando é mais importante que seguir um plano.

Embora a modelagem seja uma técnica importante em desenvolvimento de softwarem inclusive em metodologias ágeis, frequentemente é subestimada ou mal entendida. Na luta contra o desenvolvimento centrado em processos burocráticos e contra o desenvolvimento baseado em ferramentas, a modelagem acabou sendo atacada também. Precisamos corrigir essa má impressão.

Um bom começo é definição de modelagem, basicamente, a modelagem é a simplificação da realidade. Não significa utilizar determinada notação, ferramenta ou processo, permite compreender e focar nos aspectos importantes, sem detalhes desnecessários.

Considerando essa definição, podemos avançar e descrever a ideia de modelagem ágil. Isto posto, adotamos uma abordagem ágil usando modelos que nos auxiliam a compreender e comunicar.

Aspectos relevantes de Modelagem Ágil:

• O processo de modelagem e os modelos suportam comunicação e compreensão;
• A Modelagem Ágil busca criar modelos simples usando ferramentas simples (adote a simplicidade);
• O foco é entregar software, não modelos. Modelos devem ser usados quando e onde adicionam valor. Se eles não agregam valor nem nos auxiliam no sentido de entregar software funcionando, então não devem ser utilizados;
• Modelos devem ser mantidos pelo tempo necessário. Se um modelo serviu ao seu propósito e deixa de ser necessário, jogue fora. Isso permite manter a agilidade sem burocracia. Por outro lado, se seu modelo pode ainda ser útil, guarde ou recicle.
• A Modelagem Ágil utiliza múltiplos modelos para diferentes perspectivas, níveis de abstração e públicos. Cada modelo é criado a partir de um objetivo e para satisfazer determinado público.
• A Modelagem Ágil combina modelos formais e informais conforme a situação, público-alvo e objetivos. Por exemplo, um modelo poderia ser composto de formas simples desenhadas a lápis ajudando o essencial de um sistema, ou utilizando diagramas detalhados de classes do UML.

Conclusões

Para valorizar pessoas e suas interações é preciso fortalecer a comunicação. Em vez de investir em novas ferramentas ou adotar processos prescritos, sugerimos uma abordagem diferente, a Modelagem ágil. A utilização de métodos de modelagem facilita a compreensão do problema e da solução, além de melhorar a comunicação entre os stakeholders e resposta a mudanças.


Fonte: INFOQ

Pra que serve o analista de negócios?

Quem já trabalhou em um projeto complexo e demorado de desenvolvimento de software sabe que o envolvimento de um analista de negócios pode significar a diferença entre o sucesso e o fracasso de um projeto.

De um modo geral, a maioria dos analistas de negócio possui os requisitos e a competência como principal linha de conduta em sua apresentação e abordagem. Se você acredita que para que um projeto de software tenha sucesso ou fracasso com base na qualidade dos requisitos, então você também deve acreditar que para esses mesmos projetos a base é ter em seu cenário o analista de negócios.

Todos concordam sobre a importância do papel do analista de negócios, mas poucos sabem exatamente o que eles fazem qual o seu papel. Em síntese: são responsáveis pela comunicação e colaboração entre a área de negócios e a TI, tendo como um de seus principais atributos a responsabilidade de agir como um canal entre as partes e a equipe.

No intuito de entender melhor o mundo dos analistas de negócio, a http://requirementssolutions.com/ realizou uma pesquisa global a fim de identificar quais são as principais atribuições de um analista de negócios e considerando que o tempo integral de um profissional desse gabarito corresponde a um “mix” de atividades apurou que: Gerenciar requisitos (70%), Elaborar casos de uso (55%), Remodelar/redesenhar os processos de negócio (50%) e Desenvolver protótipos/telas da aplicação (40%) fazem parte de um único dia de trabalho, e concluem que, 100% do dia não é suficiente para executar suas principais atividades. (Entrevista realizada com 1700 profissionais)

Muito se enganam os que pensam que nas metodologias ágeis o analista de negócios deixou de existir, na verdade, fundamentalmente as atividades por eles exercidas são mais variadas, ou seja, o quadro de atribuição cresce e ao mesmo tempo diversifica (tema que abordarei em outro post), mas o objetivo crucial desse elemento sempre será melhorar a comunicação entre desenvolvedores, arquitetos de sistemas e participantes do projeto. Tradicionalistas consideram que a atuação de um analista de negócios independe do método (ágil ou tradicional), é imprescindível, e afirmam que sua presença é a garantia do sucesso e no caso de ausência o fracasso do projeto.

Outros estudos comprovam que os melhores analistas de negócio são organizados e grandes comunicadores, têm a capacidade de destilar as informações críticas das partes interessadas do projeto, muitas vezes pelo seu talento nato ou por uma ampla gama de técnicas de abordagem e modelagem do cenário.

Quando comecei a atuar com TI, percebi que o analista de negócios seria a profissão que tornaria esse profissional em um dos mais essenciais de toda uma organização, o único que realmente têm a competência para ver os dois lados sem os vícios peculiares e que cuja meta seria aplicar a tecnologia para apoiar iniciativas de negócios que ajudariam a empresa em aperfeiçoar recursos, aumentar lucros e diminuir os custos operacionais.

Como opinião pessoal, acredito que uma organização possa formar sua área de análise de negócios (inclusive sou líder e formador de um time na entidade que atuo), porém desenvolver as capacidades e as habilidades de um analista de negócios remete a tempo e maturação, não é qualquer um que tem a condição de exercer essa função e apenas com muito treinamento e “ritmo de jogo” que lapidamos esse profissional.

• Os analistas de negócios devem ser capazes de facilitar a aplicação conjunta de design nas sessões que envolvem grupos compostos de negócios e técnicos. Eles precisam ativamente encorajar as pessoas a contribuir com suas idéias;
• Precisam fazer o mapeamento do processo, isto é, concentrar as conversas e formatar em um contexto geral a lógica seqüencial das ações e a continuidade operacional das atividades;
• Aplicar os dados de modelagem para organizá-los e fazer fluir as informações através dos processos de negócios, na verdade, uma modelagem de dados lógica.

Construir a credibilidade

O analista de negócios atua como um rosto do cliente para a equipe de desenvolvimento, ele deve ser suficiente credível à equipe e a mesma deve ter fé absoluta em suas ações.

Após vários anos de carreia atuando em uma fábrica de software, aprendi que a equipe de desenvolvimento deve confiar plenamente no analista de negócios, essa confiança se adquire com a devida transparência, proximidade e coerência.

• Interagir com desenvolvedores regularmente e manter uma relação direta e sadia, ele deve saber que você esta lá e em qualquer momento pode ser acionado para os devidos esclarecimentos dos requisitos;
• Compartilhar com a equipe de desenvolvimento e com a área de negócios o contexto de sua atividade/detalhamento realizada, pois essa será sua sustentação “técnica/funcional”, e crédito será percebido quando comprometer ambos os lados no atendimento de seus desejos, necessidades e satisfação de suas expectativas.
• Pode ser considerado um diferencial, explicar aos times de desenvolvimento e qualidade de software a regra de negócio, e demonstrar seu domínio da informação, essa atitude reflete sua segurança e capacidade de garantir o contexto dos requisitos.
• Por fim, ser honesto e direto em assumir o desconhecimento de determinado assunto e humilde em solicitar quantas vezes for preciso à devida explanação do tema.

Esse é um tema muito rico e caloroso, a oportunidade que tive de estudar sobre o assunto e dissertar minha opinião reforçam como é bom ser um analista de negócios.

Fonte: http://www.businessanalyst.com/, http://www.agilemodeling.com/ e http://www.cio.com/