Caí de paraquedas num projeto e sou responsável por requisitos, e agora?

Publicado originalmente em 23 de março de 2017, no Linkedin

Outro dia estava eu ali num fórum, quando uma pessoa entrou e perguntou: A partir de amanhã serei analista de requisitos, não sei por onde começo!

Parece incomum mas acontece com frequência: Quantas vezes a gente já se deparou com um desafio que não sabe nem como começar? Que tipo de ajuda você espera quando isso acontece? No fórum vi muita gente recomendando leituras. Bom, leituras são imprescindíveis para o bom conhecimento de qualquer profissional. Mas e quando você está na fogueira? Como faz? Aqui está um passo-a-passo simples de como sair do outro lado num mar de problemas.Continuar lendo “Caí de paraquedas num projeto e sou responsável por requisitos, e agora?”

Mas, afinal, o que é sucesso?

Publicado originalmente em 9 de março de 2017, no Linkedin

Primeiramente, me perdoe pelo erro de português na imagem. Se você chegou a este texto, assim como eu você duvida do conceito de sucesso dos dias de hoje. A imagem do texto menciona sacrifício, trabalho duro, bons hábitos, dedicação, pra chegar ao sucesso. Mas o que é sucesso?

Muitas frases “motivacionais” são lançadas dentro do LinkedIn e de todas as redes sociais para tentar direcionar pessoas ao sucesso. E as pessoas persistem, trabalham duro, se dedicam… Mas pra quê mesmo?

Antes de concordar com a imagem, proponho uma reflexão: Essa pessoa tem sucesso ou é feliz? Será que sucesso é sinônimo de felicidade?Continuar lendo “Mas, afinal, o que é sucesso?”

User Experience: O que a análise de negócios tem a ver com isso?

Publicado originalmente em 23 de fevereiro de 2017, no Linkedin

Para iniciarmos esta conversa, falo de experiência de usuário virtual, e não a jornada do cliente. O que a UX tem a ver com Análise de Negócios? Talvez você tenha tido essa dúvida como eu tive.

E vamos lá: Análise de Negócios tem a ver com identificar necessidades e ajudar as pessoas a desenhar soluções para aquelas necessidades. Podemos fazer Análise de Negócios com Tecnologia ou sem ela, por exemplo. Uma das competências do analista é identificar as necessidades.

Beleza, mas e a UX? A estratégia para a melhor experiência do usuário atualmente é feita por designers, psicólogos, e até o pessoal do marketing. Mas sabe o que essa galera tá fazendo? Análise de Negócios! Bingo!

A estratégia de experiência do usuário é marcada por: Identificar necessidades, Mapear os usuários, identificar os pontos de dor e realizar pesquisas para medir se uma interface está trazendo os melhores resultados.

E aí, Analista de Negócios, sabia dessa? Da próxima vez que a experiência do usuário for ser desenhada na sua empresa, leve as necessidades do usuário com você. As necessidades podem ser levantadas através de entrevista, gamestorming* ou observação. Você escolhe. Só não vale inventar necessidade do usuário, ok?

Mais sobre User Experience Strategy: UX Strategy na Alura

*Gamestorming: Gamestorming é um termo que abrange uma série de práticas que utilizam o conceito e a lógica dos jogos com o intuito de estimular o engajamento e a colaboração entre as pessoas e assim resolver problemas de design, negócio ou desafios estratégicos, de maneira criativa. (Voel Blog)

Análise de Problemas à distância: É possível?

  • Publicado originalmente em 2 de fevereiro de 2017, no Linkedin

Um dos maiores problemas que temos atualmente é a comunicação. Volta-e-meia, acontece que alguém diz aquela frase: “Mas não era exatamente isso que eu estava imaginando!”. Se você exerce análise de negócios em algum âmbito, certamente já se deparou com isso.

E é incrível, que dia após dia, apesar de nos depararmos com este tipo de problema de comunicação, algumas empresas pensarem que o levantamento de requisitos – seja por brainstorm, entrevistas, mapeamento de processos, ou o detalhamento do problema, possa ser feito por telefone ou por telepresença.

O diagrama abaixo, de Alistair Cockburn, um autor também muito recomendado, detalha a riqueza da comunicação por cada via:

O gráfico indica que face a face, num quadro branco (desenhando!), é a melhor forma de ter entendimento de todas as partes. Isso responde nossa pergunta?

Utilizar telefone para levantamento de requisitos, além de inefetivo, pode causar sérios prejuízos ao seu projeto. É claro que em projetos onde a distância fisica impera, pode não haver outra solução. Neste caso, o melhor a ser feito é utilizar o maior número de recursos visuais possível, o que pode onerar a quantidade de documentação.

E você, o que acha? É possível fazer análise por telefone?

Perca peso com Scrum, pergunte-me como

Publicado originalmente em 17 de janeiro de 2017, no Linkedin.

Primeiramente, desculpe o trocadilho no título. É que o que eu tenho para contar dessa vez é tão sensacional, que eu queria que você visse. Quem nunca teve problemas com o peso, não é mesmo? Se você não tem, sinta-se privilegiado. Não é exatamente o meu caso.

Setembro de 2015: Eu, com herança genética, sedentarismo e má alimentação, já estava obesa nível 2. Eu precisava fazer alguma coisa. As doenças cardiovasculares já batiam em minha porta. A obesidade pode ser bem cruel, às vezes. Foi então que resolvi me dedicar totalmente à rotina de reeducação alimentar e atividade física. Com corridas e corte de calorias, a princípio, foram 6kg e tcharam! Estacionei. Não conseguia mais perder um só grama.

Fevereiro de 2016: Procurei uma nutricionista, que tinha foco em nutrição comportamental – guarde bem esse nome. Dra. Ana Scaramella olhou com reprovação para a minha dieta e começamos a fazer mudanças. Desde o primeiro dia até hoje (janeiro de 2017) foram mais 5kg e a perda de peso bastante saudável, com eliminação completa dos fantasmas das doenças cardiovasculares e uma percepção de que a perda foi muito maior.

Mas onde é que entra o Scrum na jogada? Calma, eu já vou explicar. A nutricionista – nutri – como costumamos chamá-la, tem foco em nutrição comportamental, lembra? O foco do projeto de emagrecimento é a mudança completa do mindset, e, depois da leitura do livro do Jeff Sutherland, liguei os pontos.

A nutri trabalha da seguinte forma (e você pode fazer isso em casa, se quiser!):

  1. Define uma meta a ser cumprida – um backlog. Qual é a sua meta? 1, 2, 5, 15kg? Depois da meta definida, a pergunta é: Quanto você acha que consegue nos próximos 30 dias? Daí sai a sua meta do sprint e meta do release.
  2. A nutri também define 3 metas diárias – junto comigo – que eu preciso conferir diariamente. A minha daily scrum meeting comigo mesma.
  3. A cada 15 dias, há o sprint review, onde conto como foram meus primeiros 15 dias, e existe a pesagem e tiragem de medidas. Também há a retrospectiva, onde revisamos o processo e fazemos ajustes, como por exemplo: Qual é seu principal ofensor no processo de emagrecimento? O que foi muito bom nesses 15 dias?

O processo em si é bem simples, mas trago aqui para discussão pois nessa experiência percebo que o Scrum, apesar de ter uma série de cerimônias, não necessariamente implica em um processo fechado e que não podemos mudar. Meu emagrecimento tem como objetivo a mudança de pensamento, o equilíbrio pessoal.

Vejo que o Scrum não é uma ferramenta apenas para desenvolvimento de software: ele pode ser usado como uma ferramenta de mudança de cultura, onde aos poucos vemos cada uma dessas etapas como natural, e melhoramos a cada dia.

E você, o que acha da aplicação do Scrum em projetos do seu dia-a-dia?

7 dicas para conquistar definitivamente seu cliente

* Publicado originalmente em 28 de dezembro de 2016, no LinkedIn

Este artigo é muito mais que uma simples técnica de levantamento de requisitos. Não importa qual posição você esteja: seja desenvolvedor, Gerente ou CEO da companhia, invariavelmente você poderá “estar” Analista de Negócios, e meu artigo hoje é pra te ajudar a chegar do outro lado, com base na minha experiência, é claro!

Mas Stakeholder, que bichinho é esse? Stakeholders são as pessoas ou áreas interessadas no projeto. O BABOK diz:

Uma pessoa ou grupo que tem uma participação ou interesse no sucesso 
de um projeto. 
As partes interessadas também são fontes importantes para os requisitos 
do projeto e podem ser responsáveis por uma ou mais atividades de projeto 
ou entregas.

Uma boa elicitação de requisitos começa com um mapeamento de stakeholders eficiente. Não tem mapeamento de stakeholders? Volte duas casas! Ou para o início do projeto!

Mas se você tem o mapeamento de stakeholders, aí vão minhas dicas para que você saia do outro lado no escopo do seu projeto.

Ouça

Veja só: Você foi chamado porque alguém tem um problema. Você é responsável por entender o problema e ajudar a resolvê-lo. O que você deve fazer neste momento? OUÇA! Deixe as perguntas para depois. Ouça, mesmo que não entenda o todo. Grave se possível. Mas deixe as pessoas falarem.

Formule questões diretas

Com base naquilo que você ouviu, faça abordagens diretas. Não faça perguntas abertas ou amplas, como “Mas o problema é esse mesmo?” ou “E se a gente não fizer o que você está falando?”. Continue tentando entender o problema do stakeholder.

Você não sabe mais que seu stakeholder

Seja humilde. As pessoas estão trabalhando e talvez você tenha uma abordagem melhor do que a deles e que possa vir a ajudá-los. Talvez você possa parecer só um arrogante mesmo. Então cuidado com a abordagem e se coloque sempre como aquele que vai ajudar. Do contrário, seu stakeholder vai te deixar – literalmente – falando.

Exercite a empatia

Coloque-se no lugar do seu stakeholder. Perceba as expressões faciais quando o stakeholder estiver te explicando algo. Geralmente eles dão dicas de linguagem corporal daquilo que mais os incomoda. É claro que existem abordagens de priorização, técnicas para medição de ROI, etc. Porém, no momento da entrevista, você identifica a dor do stakeholder quando ele está falando sem parar naquilo que o incomoda.

Às vezes, seu stakeholder só precisa de um sistema para ajudá-lo porque está trabalhando todos os finais de semana… Às vezes, uma mudança simples de processo ajuda. E se você deixa passar esse tipo de ‘desabafo’, pode perder algo importante a respeito do seu stakeholder.

Não use a palavra usuário

Ok, essa é bem particular. Nós de sistemas, tendemos a chamar as pessoas das áreas de negócio de ‘usuários’. Particularmente, quando deixei de usar o termo obtive melhores resultados nas minhas elicitações. Em minha opinião, a palavra usuário coloca um limite entre TI e Negócio que não pode existir. A palavra coloca as pessoas em patamares distintos. O negócio é nosso parceiro, eles são os exímios conhecedores daquilo que estamos trabalhando. Nós é que estamos servindo-os, e não o contrário.

Seja transparente

Quando um stakeholder te fizer uma pergunta, seja transparente na resposta. Seja a respeito do andamento do projeto, sobre a possibilidade de implementação de um requisito, seja sobre escopo inverso ou qualquer outro tema. Avise seu stakeholder se ele estiver sonhando alto demais durante uma reunião de elicitação. Isso vai ajudar criar um clima de confiança entre você e ele.

Se possível, faça amizade

Você pode não ser do tipo que é super aberto a amizades, mas quando você alcança um nível de proximidade maior com seu stakeholder, pode conseguir mais informações e atingir níveis excepcionais de satisfação do cliente.

E você, já conquistou seu stakeholder? O que você faz para atingir a excelência no atendimento ao seu cliente final?

Um framework para requisitos ágeis

*Publicado originalmente em 2 de dezembro de 2016, no LinkedIn

Em 12 anos de Análise de Negócio, passei pelos mais diversos projetos. Projetos grandes, projetos pequenos, programas inteiros ou apenas manutenções.

Todos eles possuem algo em comum: a grande quantidade de frameworks a serem utilizados. Casos de Uso, Tabelas de Caso de Uso, protótipos. Tudo previsto em metodologias como RUP e como o Waterfall Clássico. Mesmo assim, os problemas seguiram aparecendo: Problemas de entendimento, problemas com desenvolvimento… Já não dava mais pra seguir desse jeito. Pausa.

2016. Nesse ano eu passei a trabalhar com metodologias ágeis e as primeiras dúvidas começaram a surgir: Como escrever as histórias? Como garantir que os requisitos foram 100% capturados? Em minha mente sempre ecoou o fato de que a responsabilidade pelas perguntas certas era minha. Eu possuo o domínio da técnica. O BABOK também diz: Essa responsabilidade é do Analista de Negócios. E agora?

O costume de sempre elicitar os requisitos – e ser a única responsável por eles -, me deixava preocupada o tempo todo. Então, resolvi procurar o treinamento de Requisitos Ágeis com o Marcelo Neves. Meu objetivo com o curso era descobrir frameworks para escrita de histórias de usuário, épicos, técnicas, essas coisas.

E o que aconteceu foi um belo de um tapa na cara. Tapa na cara porque, além do INVEST, não há mais nada que determine se uma história está bem escrita ou não. Porque quem define se a história está bem escrita é o Time de Desenvolvimento. Porque no Scrum, o Time ajuda a definir se a história tem tudo o que precisa.

Porque em metodologia ágil, a interação entre pessoas é mais que processos e ferramentas.

Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano - Manifesto Ágil

Então, se você veio até aqui buscando uma indicação de framework para requisitos ágeis, eu só tenho uma ajuda pra você. O INVEST. Uma história de usuário deve ser:

Independente, Negociável, Ter Valor, Estimável, Pequena (Small) e Testável.

Já adianto que conseguir todos eles ao mesmo tempo não é uma tarefa fácil. Mas confie em você e no time. Aos poucos, a prática leva à maturidade – e à perfeição.

Será que você faz parte da Geração Mimimi?

Originalmente Publicado em 9 de setembro de 2016, no Linkedin.

Nas últimas semanas, tem aparecido nas timelines tanto do Facebook quanto do LinkedIn, alguns textos bem interessantes sobre vida profissional. E claro, estes textos viralizaram.

Um texto é o da Ruth Manus, que fala sobre toda uma geração que pede demissão e vai ser feliz fazendo outra coisa. Outro, da Yasmin Gomes, fala sobre a realidade de pessoas da mesma geração que não podem pedir demissão, por serem responsáveis por famílias e terem em seu trabalho a principal fonte de renda.

Outro texto fala de Bernardinho e sua mudança no estilo de liderança, atribuindo a ele a fala:

” Quando eu gritava com a geração passad a, eles se sentiam estimulados em me provar que eram capazes. Esse time não, se eu passar a tensão pra eles, eles absorvem, ficam nervosos e não respondem bem.”

Mais um episódio ocorrido em meados de agosto de 2016, fala de uma planilha com depoimentos anônimos de publicitários e jornalistas sobre como é o ambiente de trabalho em uma agência ou redação jornalística. A repercussão negativa da planilha foi inevitável. Haviam diversas denúncias de violações a leis trabalhistas por lá.  O texto teve como resposta a postagem no site Meio&Mensagem dizendo:

Você já motivou seu chefe hoje? É preocupante ver uma geração quase inteira desmotivada, reclamando de tudo, sem parar para pensar que motivação é uma via de duas mãos.

Descritos os fatos, chamo a atenção para algo que todos eles têm em comum: Pessoas insatisfeitas com seus trabalhos, ambientes de trabalho ou carreiras. Frequentemente vejo pessoas abandonando carreiras ou ambições por “isso não é pra mim”, “quero ir embora deste país”, “é só porque eu preciso…”, etc.

Pessoas que se identificaram com o texto da Ruth Manus também se identificam com essa ideia central, a de que é preciso equilíbrio na vida social e profissional. As pessoas descritas pelo texto da Yasmin Gomes também querem equilíbrio, mas não tem nem como requerê-lo, pois estão em situação desprivilegiada.

É fato e já foi publicado em mais de um veículo de comunicação que os melhores colaboradores não deixam suas empresas, deixam maus gestores. As reclamações são muitas: Falta feedback, excesso de trabalho, gritos e assédio moral fazem parte da lista.

Entretanto, na postagem sobre o Bernardinho várias pessoas afirmavam que Bernardinho “perdeu a mão” e que a nova geração é a “geração do mimimi”. Gabriela Hunnicutt, CEO da Bold, afirma em seu texto na Meio&Mensagem que a geração reclama de tudo, que os “chefes” também precisam ser motivados.

O termo “Geração mimimi” remete a reclamações desnecessárias, corpo mole. O próprio termo “mimimi” quer dizer “não quero te ouvir”, ou “o que você diz não é importante para mim”.

Mas será que estamos sendo justos? Será que as reclamações realmente não tem procedência? Será que não falta empatia por parte de quem ouve a reclamação? Veja, se há alguém reclamando, não seria esta uma excelente oportunidade de melhoria?

Vejo que ao invés de tentarmos melhorar nossas relações de trabalho, estamos simplesmente “pedindo demissão” e “aceitando as coisas do jeito que são”. Acredito que este seja o momento certo de tentarmos transformar nossas relações de trabalho.

O que você acha?

Elicitação de Requisitos: De quem é a responsabilidade?

*Originalmente publicado em  1 de setembro de 2016 no Linkedin.

As atividades de elicitação são definidas, pelo BABOK, como: trazer à tona, descobrir requerimentos ou recebê-los diretamente dos stakeholders ou de outras fontes, e é a principal atividade de um analista de negócios no que tange a descoberta de necessidades dos stakeholders e formas de desenhar um software ou projeto.

As atividades de elicitação são definidas pelos seguintes processos:

  • Preparar;
  • Conduzir;
  • Validar (confirmar);
  • Comunicar;
  • Gerenciar colaboração.

E a linha fica tênue entre as responsabilidades do gerente de projeto e do analista de negócios, pois em muitos projetos o planejamento, a abordagem, a agenda e o tempo necessário para a elicitação e escrita dos requerimentos fica a cargo do gerente de projetos. Mas o que diz o BABOK?

O BABOK diz que as atividades de preparação da elicitação envolvem a abordagem a ser utilizada pelo analista, o levantamento dos stakeholders,  e cada perfil, incluindo também o nível de engajamento no projeto, localização, logística, etc. Também define quais serão os entregáveis e delimita expectativas entre stakeholders e o analista (ou time de analistas).

A condução das atividades também fica a cargo do analista. Aqui, a técnica pode ser variada e pode envolver os stakeholders ou não. Por exemplo, as principais técnicas de elicitação utilizadas são: Entrevistas e Brainstorming. O analista pode utilizar de experiências, pesquisas ou Provas de Conceito (POC) para elicitar uma necessidade sem a participação direta dos stakeholders, mas validada por eles. Afinal, todas as atividades devem ser validadas por todos os stakeholders.

O plano de comunicação dos requisitos também deve ser responsabilidade do analista, definindo por exemplo qual será o modelo de comunicação, e quando ou como esta informação deve ser apresentada.

Como podemos ver, o BABOK e o BACCM (Business Analysis Core Concept Model) dá autonomia ainda maior ao analista de negócio na condução de atividades de análise de negócio, ficando a cargo do analista todo o planejamento e execução das atividades.

Neste cenário, o gerente de projeto atua como par do BA e facilitador, garantindo que todos os recursos estão disponíveis de acordo com o planejamento e abordagem do analista.

Onde você se vê daqui a 5 anos? Quais são seus planos a longo prazo?

*Publicado originalmente em 25 de agosto de 2016 no LinkedIn.

Depois de um período de pausa em minha carreira, estou retornando ao mercado de trabalho.

Sempre lido com este tipo de situação da forma mais descomplicada possível. Se eu domino algum assunto, tudo bem, se não domino, procuro estudar. Procuro sempre estudar novos nomes, novas tecnologiasmesmo que a nova tecnologia não se enquadre em meu cargo atual ou tenha tido quaisquer experiências com tal tecnologia. Quem sabe?

No entanto, nas últimas semanas, fui surpreendida com uma pergunta bem comum nos ambientes corporativos e principalmente de RH: Onde você se vê daqui 5 anos? 10 anos? Quais são seus planos a longo prazo? Me lembro que tentei ser o mais sincera possível, dizer algumas coisas que pretendo fazer ou pretendo estudar, mas o principal: Que pretendo ser melhor do que sou hoje.

Há 5 anos atrás eu possuía um plano para minha carreira, e não correu bem como o esperado. Não estou no lugar onde esperava estar, e nem quero mais estar nesse lugar. No meio do caminho os planos mudaram, eu mudei.

Aprendi a criar planos de curto prazo, de médio prazo. Cinco anos para quem trabalha com Projetos de TI é muita coisa. Vive-se 5 anos em 5 meses, temos experiências que nos tiram o fôlego, que são apaixonantes, que nos destroem e que nos reconstroem em um curtíssimo espaço de tempo. Conhecemos pessoas que temos contato diário, e no ano seguinte são apenas mais um contato de trabalho, cuja distância é ampliada pelos longos horários de expediente e prazos a serem cumpridos.

Aprendi que tirar planos do papel é executá-los ainda hoje, e que o amanhã é um reflexo do que faço todos os dias. Que o que vale de verdade é a trajetória.

E você, o que pensa sobre isso?