Lá no início desta longa série, em +Requisitos do Negócio, foram apresentadas as questões que normalmente utilizamos na abertura de um projeto. Lembrando:
A sequência acima nos ajuda a desenvolver uma linha de raciocínio. Mas, claro, existem infinitas variações. Não é todo entrevistado que tem autonomia ou conhecimento para responder algumas questões. E a natureza do projeto vai impor outras perguntas, mais específicas. O mais importante é sempre se lembrar de que é nos primeiros momentos de um projeto que muitas suposições são construídas. Ao repetir o questionário para pessoas diferentes reduzimos os riscos de interpretações equivocadas.
Vimos no artigo anterior que temos três grandes tipos (ou classes) de eventos: Abertura, Exploração e Fechamento. É na exploração (de requisitos) que esgotamos praticamente todo o nosso arsenal de perguntas. São apresentadas abaixo os tipos de perguntas que fazemos seguidas de alguns exemplos.
Foco é a palavrinha mágica aqui. É muito fácil, particularmente em momentos iniciais de um projeto, que uma pessoa viaje na maionese, se perca no emaranhado de questões relativas ao projeto (e até de fora dele). Por isso precisamos elaborar perguntas que direcionem os participantes. Exemplos:
A última questão é uma interessante e didática piadinha. A penúltima, uma deixa para um alerta. Devemos evitar, particularmente nas fases iniciais de um projeto, questões que direcionem para respostas binárias (sim/não). Sendo assim, evitamos o uso de variações do é (são, foram, estão). Obtemos requisitos mais ricos ao utilizar que, quais e como. Aquela penúltima pergunta ficaria melhor assim: Como vocês identificam seus produtos?
Lembre-se, toda resposta carrega, além de informação, algum tipo de confirmação e alguma quantidade de ruído. Quando fazemos perguntas abertas, como no exemplo acima, forçamos a colocação de algum tipo de confirmação. O entrevistado tende a falar mais, explicar melhor.
Há momentos em que as viagens devem ser evitadas. Mas também existem aqueles momentos e projetos em que tudo o que buscamos são bons e criativos devaneios. Há o tipo certo de pergunta para motivá-los. Alguns exemplos:
Existem eventos que exigem apenas foco. Outros, como os famigerados torós de parpites (brainstormings), demandam generosa porção de questões criativas. O mais comum será o uso de um questionário que saiba combinar os dois tipos de questões.
Estas devem ser evitadas a todo custo. Só criam mal estar e nunca geram informação. Alguns exemplos:
Pior que a combinação da última questão só uma mistura de reunião post-mortem, questões retóricas e jogo de culpa.
Por fim, temos as metaquestões – perguntas sobre nossas perguntas. Elas nos ajudam a avaliar uma reunião ou até mesmo o processo de desenvolvimento de requisitos. Aos exemplos:
Sim, algumas delas são perigosas, particularmente as três últimas. Mas são necessárias, principalmente quando estamos prestes a encerrar um encontro e o gelo permanece intacto. Ou, pior ainda, quando as respostas são ruins a beça.
Opa!, quase me esqueci da manga. Segue o derradeiro exemplo: Eu deveria estar falando sobre mangas contigo?
E assim, depois de um longas férias de verão, recomeça a série +Requisitos +Conversas. Espero: i) Seguir contando contigo; ii) Que 2013 seja um ano muito produtivo para todos nós; e iii) Que você não tente combinar manga com pinga e licor de menta.
Três livros serviram como base para este artigo:
]]>
Nenhum projeto ocorre sem comunicação. Santa obviedade, diria Robin. Mas o quão bem nos comunicamos em um projeto? Por favor, não me venha com templates de documentos, atas e que tais. Para início de conversa, precisamos conhecer os canais disponíveis, suas vantagens e desvantagens.
O diagrama ao lado¹ sugere a classificação dos canais de comunicação levando-se em conta duas variáveis: Riqueza do Canal e Tipo de Mensagem.
A riqueza é definida pelo volume de informações que trafega em determinado canal. Lembre-se, “informação é a diferença que faz diferença”. Boletins e relatórios são os mais pobres. Qual a razão? Simples: palavras, números e eventuais gráficos raramente ou nunca comunicam o contexto, história, sentimentos etc. Estas informações (ou confirmações ou ruídos – todos igualmente necessários) só são capturadas no tête-à-tête, em tempo real. Por isso, desde que a gente é gente, a forma mais rica de troca de informações e conhecimentos é o cara a cara. As vídeo-conferências são boa alternativa quando o encontro pessoal não é possível. Mas elas não têm o mesmo potencial das reuniões que permitem apertos de mão e abraços.
Como nosso tema central são os requisitos, a segunda variável é ainda mais relevante. O bom analista sabe que todo requisito nasce com considerável dose de ambiguidade, de incertezas. Se tudo o que precisássemos fosse uma confirmação binária – sim ou não – então os outros canais seriam suficientes. A maior parte do trabalho com requisitos – da descoberta ao desenvolvimento – não pode se dar esse luxo. Trocando em miúdos: a maior parte do trabalho com requisitos deve se dar na base do cara a cara. O “maior parte” soou ambíguo demais para ti? Então, crava aí: de 50% a 80%, dependendo do ineditismo do projeto².
Existem inúmeras ferramentas sociais – ferramentas que utilizamos para trocar informações e experiências, apresentar soluções, debater problemas, fofocar, avaliar, motivar e conviver. Nos interessam aquelas que fazem uso do canal mais rico, o cara a cara. Nesta categoria, praticamente todas as ferramentas derivam de dois únicos modelos: Reuniões e Observações.
Não faria muito sentido, dados o espaço e o foco desta série, que eu inventariasse e classificasse cem, vinte ou mesmo dez ferramentas sociais. Existem bons livros que já fizeram isso por nós³. Portanto, limitarei este artigo à apresentação dos dois modelos principais.
O que trato aqui como reunião é qualquer encontro que envolva duas ou mais pessoas. No trabalho com requisitos é comum o uso do termo entrevista, que não deixa de ser uma reunião. Temos apenas três tipos de reuniões:
É importante que tenhamos um modelo para a configuração das reuniões, independentemente de seu tipo. Um dos melhores que já conheci é apresentado como framework 7P’s4. O desenho ao lado ilustra seus componentes:
As reuniões nunca foram tão visuais como hoje. Nos livros citados³, praticamente todas as ferramentas são visuais. Tim Brown, em Change by Design (Harper Business, 2009), tem uma boa explicação para isso: “Palavras e números são bons, mas é desenhando que podemos revelar simultaneamente as características funcionais e o conteúdo emocional de uma ideia“.
Cabe um último alerta sobre reuniões. Deve existir um e apenas um condutor (ou facilitador. De Bono chama de presidente!) da reunião. E é humanamente impossível que esta pessoa conduza e simultaneamente faça os registros necessários (desenhos, especificação de casos de uso, histórias, lista de atributos etc). Por isso sempre recomendo a presença de um segundo profissional, responsável pela externalização (conversão, mesmo que parcial, em conhecimento explícito) daquilo que está sendo debatido ou apresentado.
Nós sabemos mais do que podemos dizer. -Michael PolanyiA observação é uma ferramenta em fase de redescoberta. Como ilustrado no artigo anterior, Diderot lançou mão dela para aprender diversos ofícios. Agora, séculos depois, estamos aprendendo a aprender observando o trabalho ou o cotidiano dos outros. Porque começamos a entender que “sabemos mais do que podemos dizer”.
Existem dois tipos principais de observações:
Extraímos requisitos das observações? Sim, e o curioso é que a fonte daqueles requisitos é o próprio analista-observador e não o usuário que foi observado. Porque é impossível que o analista faça uma observação totalmente isenta. Ele carregará as necessidades e restrições percebidas com sentimentos seus, não do observado. Isso não é um problema quando a observação é de fato atenta e atenciosa.
A observação pode criar de forma mais rápida e natural um componente fundamental para boas comunicações: empatia. Infelizmente, acho que não tenho muito mais a dizer sobre essa ferramenta. Veja bem: a melhor maneira de ensinar alguém a observar é convidando-a para observar um trabalho de observação. Sacou?
Então, depois de extrapolar e muito o limite auto-imposto de mil e poucas palavras por capítulo, só restam um lembrete:
Comunicação = Informação * Relacionamentos * Feedback
e uma provocação5: “Para criar bons relacionamentos você deve convencer as pessoas de que se preocupa com elas. A única maneira de convencê-las é se preocupando realmente.”
Estou prestes a encerrar a “primeira temporada” da série. Como ela é muito longa, você e eu merecemos um descanso. Mas há outro motivo: estou iniciando uma nova bateria de testes de boa parte das sugestões que ainda serão apresentadas. Dependo desta confirmação para seguir o trabalho. Conto com sua compreensão.
]]>
Para esta sequência precisamos recuperar duas citações do artigo anterior:
De carona nas afirmações acima conclui que “requisito é conhecimento produzido por conhecimento”. Estamos falando de aprendizagem – aprendizagem organizacional. Como uma organização aprende? Como ela gera (produz) e dissemina conhecimentos¹?
A resposta exige que saibamos que existem apenas dois tipos de conhecimentos²:
O conhecimento tácito reside nos corações e mentes das pessoas. É aquele que vai embora da empresa todo dia lá pelas cinco ou seis da tarde³. O explícito fica – persistido em documentos, sistemas, bancos de dados, pôsteres, mensagens em correios eletrônicos e redes sociais etc.
A aprendizagem organizacional – a geração e disseminação de conhecimentos – se dá nas conversões de conhecimentos ilustradas no diagrama ao lado.
Na socialização – de conhecimento tácito para tácito – a troca se dá através de conversas e da observação ou experiência direta, tête-à-tête. É como se inicia um processo de aprendizado. Aqui temos razoável largura de banda – quantidade de informações transmitidas. Por outro lado, temos também um problema de escalabilidade. Pense em uma reunião com dezenas ou centenas de pessoas. A eficácia do aprendizado via socialização é inversamente proporcional ao número de participantes.
Ao sintetizar conhecimento tácito em explícito temos a externalização. Quando critico as verborrágicas especificações funcionais estou apontando para este quadrante. São notórias nossas dificuldades neste tipo de conversão de conhecimento. Mas não são novas. Diderot também penou bastante para transcrever naquela que seria nossa primeira enciclopédia um conhecimento que até então (circa 1750) era exclusivamente tácito. Ele queria explicar pelo menos o básico sobre todos os trabalhos artesanais da época. Descobriu que a observação ativa (para aprender) e as imagens (para explicar) eram as ferramentas mais eficazes. Hoje, no trabalho com requisitos, Diderot ainda tem muito a nos ensinar.
A conversão de conhecimento explícito em outro formato explícito é o que acontece na combinação. É o que faz um desenvolvedor, por exemplo, quando parte de modelos e especificações para criar código. É importante entender que combinação é síntese – criação de um novo todo a partir de partes distintas – e não uma mera tradução de formatos (ou o fatídico e dispendioso passar a limpo). Na combinação não há conhecimento novo sendo gerado. Por isso cada conversão deste tipo deve ser avaliada com carinho. O produto da conversão deve ter inequívoco valor para alguém ou para a organização. Um modelo ou documento que só existe porque “a metodologia exige” é grana que escorreu pelo ralo.
Por fim, temos a internalização – a conversão de conhecimento explícito em tácito. É o aprendizado que se dá a partir do que está escrito, desenhado ou registrado de alguma forma. Ao contrário da socialização, aqui temos grande potencial de escala (de atingir grande número de pessoas). Por outro lado, a banda não é tão larga – a quantidade de informações passíveis de transmissão é consideravelmente menor.
Essas conversões não ocorrem de maneira isolada ou única. A sequência descrita acima acontece infinitas vezes dentro de uma organização, formando uma espiral. Pois é, a aprendizagem organizacional é naturalmente iterativa (iterar = repetir) e incremental (construída a partir dos produtos das etapas anteriores). Dá pra imaginar o espanto e desalento dos papas dessa matéria quando apresentados aos cansativos debates sobre processos plan-driven versus change-driven. Porque essa divisão não existe!
O modelo SECI, nome do diagrama acima, não é uma proposta de processo ou método. É a conclusão de uma pesquisa²: é assim que as organizações aprendem, intencionalmente ou não. Reconhecer o modelo é o primeiro passo para uma conversa séria sobre aprendizagem organizacional e gestão do conhecimento.
Sintetizando: Nós conversamos sobre necessidades e restrições com nossos usuários e clientes (socialização); Durante e depois das conversas nós transcrevemos parte daquele aprendizado – estruturando requisitos, redigindo especificações de casos de uso, rabiscando modelos etc. (externalização); Criamos outras derivações dos requisitos – como mockups, storyboards, protótipos ou versões alpha e beta – de forma a confirmar que todos os envolvidos compartilham o mesmo entendimento (combinação); o confronto com esse conhecimento explicitado na forma de modelos ou versões de um sistema (internalização) nos dá novas certezas e dúvidas – novas necessidades e restrições – sobre as quais vamos conversar, o que nos remete ao início deste parágrafo.
Desta vez ficou fácil cravar o tema da próxima parte. Será sobre canais de comunicação e ferramentas sociais.
Porque tudo começa na socialização. Até lá!
]]>
Como a conversa no artigo anterior ficou bem “matemática”, segue mais uma fórmula:
Requisito = (Informação * Confirmação) – Ruído
Vimos na introdução desta série que a informação representada por um requisito é uma “condição necessária para alcançar certo fim”. Depois, vimos que este “certo fim”, em nosso contexto, é um conjunto de objetivos do negócio. Objetivos que podem ser detalhados e organizados na forma de requisitos do negócio. É suficiente, para o desenvolvimento e condução de um projeto, que se conheça apenas essas informações (condições e fins) devidamente confirmadas e livres de ruídos? Sim, desde que interpretemos a variável “informação” da fórmula acima de uma maneira bem ampla.
Se você não aprender corretamente os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto. -Karl WiegersÉ relativamente comum que se conheça muito pouco sobre um requisito. Assim como são irritantemente corriqueiras as longas e amorfas transcrições textuais transmitidas e recebidas como sendo os “requisitos” de um projeto. É difícil encontrar bons requisitos nesses catataus.
Assim como será praticamente impossível encontrar um cliente ou usuário que, durante a exposição de seus objetivos e condições, aja mais ou menos assim: “Vou relacionar os requisitos funcionais, anota aí. Prepare-se para os não funcionais. Agora, às restrições. Por fim, falemos sobre regras de negócio”. Este usuário não existe. E não precisa existir!
Cabe ao analista os processos de estruturação e enriquecimento dos requisitos. Aliás, se ele fizer só isso por um projeto já terá justificado seu salário. Se você acha que isso é muito pouco, por favor, continue lendo.
Estruturar significa organizar – separar os mais diversos tipos de requisitos e demais informações. Porque cada um deles merecerá um destino diferente. Porque cada um pede tratamento e ferramental específicos. Veremos isso nos capítulos sobre Funções, Atributos, Preferências e Restrições.
Enriquecer significa obter mais informações e confirmações (feedback) sobre cada requisito. O diagrama ao lado ilustra sete atributos que todo e qualquer requisito (de todo e qualquer projeto) deveria merecer.
Aqui simplesmente colocamos cada requisito em sua devida caixinha. Na classificação mais básica possível teríamos: Requisitos do Negócio, Funções, Atributos e Restrições. Quem quiser ser mais específico pode diferenciar requisitos de usabilidade, de dados, telas, relatórios, integração, transição, segurança etc. No modelo proposto por Suzanne e James Robertson¹ existem apenas: Restrições, Requisitos Funcionais, Não Funcionais e de Tecnologia. Com certeza há uma separação e nomenclatura mais adequadas para sua organização ou projeto. Esta série utilizará a primeira lista acima em todos os exemplos.
O nome de quem manifestou aquele requisito pela primeira vez. A tabelinha² Fonte pode, obviamente, ser completada por outras informações como cargo, departamento etc. Em alguns casos não é possível identificar uma pessoa. Quando tudo o que um analista tem em mãos é um edital, por exemplo. Nessas situações (terríveis) registramos apenas o documento e, eventualmente, capítulos e páginas.
Só não recomendo que se registrem aqui informações sobre o impacto que o projeto terá sobre a pessoa e sua influência. Porque são informações do tipo caixa preta que deveriam ser persistidas em um local menos público.
É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:
Além dessas, podemos ter perspectivas que não participam diretamente do negócio. Legal, por exemplo, para representar o corpo jurídico da empresa; Técnico para diferenciar todos os requisitos que vieram de TI e assim por diante. Em cada organização ou projeto podem existir pontos de vista diferentes que merecem destaque.
Repare no diagrama acima que, apesar de qualificar a Fonte, a Perspectiva é um atributo do Requisito. É o primeiro mecanismo do modelo que visa a resguardar a história do projeto. Quando uma pessoa for promovida, mudando assim sua perspectiva, não levará consigo seus antigos requisitos. Fica registrado que, quando aquela pessoa manifestou determinado requisito ainda defendia o ponto de vista “operacional”, por exemplo.
Todo requisito tem um valor (benefício) e um custo. Representamos aqui qual é a contribuição de determinado requisito para a realização dos objetivos do negócio. Podemos utilizar uma escala bem simples, como:
Quem precisar de uma escala maior pode utilizar, por exemplo, a sequência de Fibonacci. Costumo recomendar um pequeno subconjunto: 1, 2, 3, 5, 8, 13. Em situações que envolvam quatro ou mais interessados (proponentes de requisitos), sugiro também o uso do Planning Poker para a valorização das necessidades e restrições apresentadas. Geralmente esta ferramenta é utilizada apenas para estimativas de esforço, o que é um desperdício. Quando utilizamos unidades relativas, é importante que valor (benefício) e estimativas (custo) sejam medidos com a mesma régua. Tanto melhor se utilizarmos o mesmo método. No capítulo sobre estimativas e planejamento isso será melhor explicado.
Este assunto merece livros inteiros. Porque está aqui boa parte dos problemas que presenciamos em projetos. Quanta grana se desperdiça com funções que raramente ou nunca são utilizadas; Quanto tempo é perdido em requisitos que representam nada ou muito pouco para a solução do verdadeiro problema; Enfim, como faz falta uma visão compartilhada sobre aquilo que realmente interessa em um projeto.
Em praticamente tudo o que compramos ou construímos há prioridades e alternativas. Na lista do supermercado, no carro ou na casa nova pensamos em itens fundamentais, importantes e supérfluos ou opcionais. É curioso como no mercado de software sobrevive, por muito tempo, um jogo de tudo ou nada. Curioso porque software é infinitamente mais maleável que casas, carros e listas de supermercado.
O que deve ficar, neste ponto, é a consciência de que esta pergunta – “Ilmo. Sr. Usuário, quanto vale esta solicitação?” – deve ser feita. Imediatamente após a apresentação do requisito. O cliente ou usuário pode se enganar ou, em raros casos, tentar ludibriar o analista. Momento este que aciona o lado crítico do analista: “Me explique, caríssimo Usuário, como a função X (ou o atributo Y) ajudará a ACME a aumentar em 30% o faturamento”. Sim, os objetivos e requisitos do negócio devem balizar todos os demais requisitos. Não há outra maneira de analisar e de fato criticar e priorizar requisitos. Não há!
Se através do Valor rastreamos cada requisito na vertical (entendendo sua contribuição para a realização dos objetivos do negócio), está naquele pequeno círculo incompleto a rastreabilidade horizontal. Ou seja, o tipo de relacionamento que determinado requisito tem com todos os demais. Quando existe, a relação pode ser de:
Há outro tipo de rastreabilidade, igualmente necessária mas não contemplada nesta sugestão. Ela trata do relacionamento entre requisitos e elementos da solução. Quem sabe usar (direitinho) a UML não precisa se preocupar com isso. Os demais ficarão com uma bela pulga atrás da orelha.
É bastante provável que neste momento lhe tenha caído uma ficha: “Caramba! Quanto trabalho!” Entendeu agora porque um analista de negócios ganha tão bem? Brincadeirinha… A mensagem é outra.
O diabo está nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo se lambuza.É impossível – repito, é impossível realizar este trabalho de análise em um lote muito grande de requisitos. O bom profissional deve saber que boa parte do trabalho de análise de requisitos ocorre em paralelo à elicitação (sic 100x!), ou seja, no momento em que um requisito aparece ele já começa a ser analisado (estruturado, enriquecido, relacionado… você entendeu). A outra boa parte do trabalho de análise de requisitos ocorre imediatamente após um evento de coleta (sic 1000x!)³. Enquanto as informações ali aprendidas ainda estão frescas na memória dos participantes e, principalmente, dos analistas.
Outra mensagem: se o analista envolvido com requisitos não faz este trabalho ele não está fazendo seu trabalho. Ponto!
Não há análise, seja de requisitos ou de negócios, feita no atacado, por cima, nas coxas…
E por falar nas coxas… Hora de conversar um pouco sobre testes. Lembra-se da fórmula que abriu este capítulo?
Requisito = (Informação * Confirmação) – Ruído
Os testes são os grandes responsáveis por gerar confirmação e também por subtrair ruídos dos requisitos. Não por acaso, é o único atributo do modelo sugerido que mantém relação de muitos para muitos com os requisitos. Este tema também merecerá um capítulo só seu. Por enquanto, é importante o entendimento de que os testes ocorrem em diversos momentos e com propósitos distintos. No início, durante uma entrevista, por exemplo, testamos um requisito no sentido de confirmar i) Nosso entendimento; e ii) Sua (do requisito) real necessidade. Nos momentos seguintes, de forma isolada ou em conjunto, os requisitos são submetidos a baterias de testes que visam a i) Confirmar nosso entendimento; e ii) Confirmar a sua (do requisito) realização.
Teste é sinônimo de confirmação, feedback, refinamento e aprendizado. Não deveria estar relacionado com coxas.
Enfim, o último atributo básico que todo requisito deveria merecer. Aqui simplesmente posicionamos o requisito em um momento de seu ciclo de vida. Podemos utilizar a mesma nomenclatura das divisões de um quadro kanban, por exemplo: Em Espera; Em Execução; Em Testes; Entregue. Claro, sua organização ou projeto pode requerer uma visão diferente, mais detalhada. O importante é que se saiba, a qualquer momento, qual o estado de cada requisito.
A tabela² Requisitos possui, além das diversas chaves estrangeiras (ligações com outras tabelas), alguns campos próprios. Mantendo o padrão, relaciono abaixo o que considero o mínimo necessário:
Depois deste tour de force, quem sabe o que virá a seguir?
]]>
Em tempos de big data pra cá e muito ruído e contação de histórias vazias pra lá, é sempre bom relembrar o básico, (porque talvez ele já não seja assim tão) óbvio e intuitivo. Do começo: o que é informação? Difícil ser mais direto e eficaz que Bateson: “informação é a diferença que faz diferença“. A fórmula ao lado¹ nos diz a mesma coisa, de um jeito diferente.
Na prática: o previsível, o corriqueiro, o redundante e o repetitivo não nos ensinam (informam) nada ou praticamente nada. (Esta frase parece querer confirmar o que ensina.) E o valor daquilo que pouco informa é irrisório ou nulo. Particularmente em projetos, porque informação é sua principal matéria-prima.
Choque de realidade: talvez você já tenha visto por aí um catatau com dezenas ou centenas de páginas chamado “especificação funcional” (sic) ou algo parecido. Aplique a fórmula ou regrinha acima para ter uma rápida noção do valor, da quantidade de informação de verdade que aquele documento carrega. Lembre-se das redundâncias, ambiguidades, contradições e encheção de linguiça ali persistida. Agora considere quanto aquele entregável (sic 10x) custou: as horas gastas em entrevistas, reuniões, revisões do documento etc. O quão economicamente útil é um documento assim?
Vale dizer, o problema nem é necessariamente o formato. Tem muito quadro kanban por aí que mal vale uma nota de três reais, apesar da sua belezura e pseudo-modernidade. Antes da forma, deveríamos nos preocupar com o conteúdo.
O Houaiss nos ensina que comunicação é a “transmissão de uma mensagem”. A crença na eficácia desta comunicação de uma via tem causado sérios problemas. Até no frio relacionamento entre computadores há a preocupação com a recepção – com a garantia da entrega de uma mensagem. Na comunicação entre pessoas a questão é um tanto mais complexa.
Existem diversos modelos² que ilustram todo o processo de comunicação entre pessoas. Vou apelar para um básico³:
Em nosso dia a dia, em todo tipo de comunicação, o processo pode ser interrompido em qualquer ponto acima. Você pode, por exemplo, entender o que está escrito aqui e não aceitar e consequentemente não fazer nada a respeito. No trabalho com requisitos é importante que o analista busque o quinto estado – a conversão em ação – de toda informação de fato relevante para o projeto.
Quando trabalhamos em projetos, particularmente com requisitos, deveríamos ver comunicação da seguinte maneira4:
Comunicação = Informação * Relacionamentos * Feedback
A informação vale por si só, por ser “a diferença que faz diferença”. Mas sua simples transmissão não tem valor nenhum. A fórmula acima sugere que a comunicação vai de fato ocorrer se existir um bom relacionamento entre os interlocutores. Mas não basta. Mesmo no mais harmonioso dos ambientes, a comunicação exige mecanismos de feedback que garantam que a mensagem transmitida seja recebida, entendida, aceita e, de alguma maneira, convertida em ação.
O alcance da definição acima ultrapassa e muito o escopo desta série. Tentarei mostrar apenas a relevância daquela fórmula nos trabalhos de desenvolvimento e análise de requisitos.
Para tanto, que tal outra fórmula5?
Resposta = Informação + Confirmação + Ruído
A confirmação verbal do entendimento é a melhor depois da telepatia. -Jurgen AppeloA confirmação é o tal mecanismo de feedback da fórmula anterior. Precisamos dela, mas nem sempre a conseguimos na primeira resposta. Independentemente da qualidade da pergunta. Por isso consideramos que uma resposta sem confirmação está incompleta. E formulamos a questão seguinte com o único propósito de obtê-la.
Entre informações e confirmações, invariavelmente recebemos ruídos. Merece este nome – ruído – aquela palavra, gesto, olhar, sussurro ou tic nervoso que não conseguimos decifrar em um primeiro momento. Pode não ser nada. Mas pode ser uma informação ou mesmo uma confirmação carente de atenção. Decifrar ruídos no sentido de obter boas respostas e excelentes requisitos é uma das artes (secretas?) dos bons analistas.
Esta série ainda merecerá um ou mais capítulos específicos sobre conversas, perguntas , respostas e ruídos. O básico do básico sobre informação e comunicação foi colocado. No próximo artigo conversaremos especificamente sobre informações em requisitos. Te espero lá.
]]>
Na introdução desta série foi apresentado o caso da empresa ACME que servirá como base para todos os exemplos¹. Ele é repetido abaixo, de forma melhor estruturada:
Quanto luxo!, você diria. Afinal, quantas empresas você conhece que apresentam suas necessidades na forma de um Balanced Scorecard (BSc)? Minha intenção com o exemplo acima é outra. É mostrar que esta ferramenta pode compor o cinto de utilidades de um analista mesmo em organizações que não fazem uso dela. Além de relativamente simples, o BSc é útil na busca pela verdadeira raiz de um problema (ou real motivação de um projeto). Acompanhe o diálogo abaixo :
S: Precisamos de um sistema que torne nosso processo de vendas mais eficiente e mais eficaz.
A: Por favor, defina eficácia.
S: Número de negócios fechados, principalmente. Mas também miramos um aumento no valor médio das vendas.
A: E o que significa um processo de vendas mais eficiente?
S: Seria um que possibilitasse um número maior de visitas. Trabalhamos com a possibilidade de um aumento de aproximadamente 50%. Menos tempo seria gasto em cada cliente e mais clientes seriam visitados.
A: Quantas visitas cada vendedor realiza hoje?
S: Mais ou menos quinze. Acreditamos que um bom sistema viabilize o aumento para cerca de vinte e quatro visitas.
A: Resultando em mais visitas aos mesmos clientes ou em novos clientes?
S: Em novos clientes, claro! Hoje não atendemos parte considerável das zonas norte e oeste. E para lá que precisamos crescer.
A: Aumento que pode ou deve se refletir no faturamento, certo?
S: Claro! Nossa intenção é um ganho de 30% em um prazo de dois anos.
O diálogo acima tenta ilustrar a lógica de construção de um BSc. Ele se desenvolve em ordem inversa e o analista tenta chegar na grande motivação para o projeto (no caso, um aumento de 30% no faturamento). Existem ferramentas de uso mais genérico que têm o mesmo objetivo. Uma das mais conhecidas se chama 5 Whys e foi inventada na Toyota. O nome vem da sugestão de que são necessários, em média, 5 “porquês” para que se alcance a raiz de um problema.
Vejamos agora como esse papo poderia se desenrolar com a aplicação das questões sugeridas no capítulo anterior:
A: Qual ou quais problemas você precisa resolver?
S: Precisamos tornar nossas visitas de vendas mais rápidas e mais eficazes. Ou seja, preciso que meus vendedores façam um número maior de visitas por dia e também que vendam mais em cada cliente.
A: O que vocês estão buscando? (Qual a motivação para solução destes problemas?)
S: Acreditamos que podemos atender um número bem maior de clientes. Hoje praticamente não atuamos nos bairros um pouco mais afastados das zonas norte e oeste. Se nossos vendedores forem mais produtivos, então poderemos cobrir uma área bem maior.
A: Uma base maior de clientes pode significar mais faturamento…
S: Nossa meta é aumentar o faturamento em 30%.
A: Não bastaria contratar mais vendedores? (Qual solução está fora de cogitação? Por quê?)
S: Não, por favor, não! Você já gerenciou vendedores? Sabe o quanto é difícil? Isso também significaria comprar e administrar mais carros e mais celulares… Definitivamente, não pretendemos aumentar o número de vendedores. O que nós queremos, isso sim, é que eles sejam mais produtivos.
A: Mesmo com esse trânsito caótico?
S: É aí que vocês entram, não? Afinal, tecnologia é inventada para tornar nossas vidas menos ordinárias, certo?
Não há uma estratégia ou formato de entrevista melhor ou pior. Nos dois exemplos acima conseguimos resultados semelhantes (e furos idem!). O importante é que haja uma estratégia e que o entrevistador sempre busque pela motivação principal de um projeto. Porque, no final das contas, um projeto só será considerado um sucesso se este grande requisito – o fato motivador – for plenamente atendido.
E o que fazer se o fato motivador aparecer de imediato, logo na primeira resposta do solicitante? Percorremos o caminho natural do BSc, tentando entender como a empresa espera alcançar o objetivo colocado. Recomendo a lógica do BSc porque ela permite a cobertura das questões mais relevantes. Veja:
Como colocado no início desta série, é nesta última perspectiva que representamos os novos projetos. “Desenvolver um sistema de automação da força de vendas” é uma possível resposta que apareceria ali. É o momento em que normalmente nós de TI somos envolvidos. Insisto: não faremos um bom trabalho se não buscarmos a motivação verdadeira. Ninguém pede um sistema por pedir. Bom, pelo menos ninguém em sã consciência e com boas intenções.
Se ambiguidade é nociva para qualquer tipo de requisito, para os requisitos de negócio ela pode ser fatal. Os exemplos acima estão repletos de solicitações ambíguas: Aumentar a base de clientes de quanto para quanto? Quanto tempo dura uma visita? E qual seria o tempo aceitável? Qual é o valor médio das vendas atuais? E qual seria o valor ideal?
A boa notícia é que este tipo de ambiguidade é fácil de matar. Com base em números correntes, que nem precisam ser muito precisos, os representantes do negócio podem projetar suas necessidades e desejos. Por exemplo: se uma visita leva em média 20 minutos (quando bem sucedida, ou seja, quando resulta no fechamento de uma venda), é factível supor uma visita com duração de 15 minutos?
Temos em mãos um exemplo que prova de maneira inequívoca o valor da modelagem de negócios. É incrível, mas até hoje recebo profissionais que dizem “eu não faço modelagem. Meu trabalho começa nos requisitos”. Por não entender a simples operação ilustrada ao lado, seguem produzindo requisitos de qualidade questionável, para dizer o mínimo. Vamos lá: ao subtrair a situação atual (as is) do modelo projetado (to be) obtemos os requisitos. Conta boba e óbvia, não? Então por que ela ainda causa tanta surpresa?
Um velho e bom fluxograma pode mostrar com razoável precisão como um vendedor gasta 20 minutos em cada visita de venda. Dados o número de vendedores (20) e a variabilidade do processo (o processo pode mudar dependendo do perfil do cliente), o analista deveria optar pela observação direta como método de estudo. Ele acompanharia 4 ou 5 vendedores munido de um cronômetro e de algo que lhe permita rabiscar diagramas e notas.
Cronômetro? Rabiscos? Fluxogramas?!? Minhas caras e meus caros: se essas ferramentas resistem, ainda que com nomes (BPMN) e formatos (BPMN!) mais modernos e bonitinhos, é porque não inventamos nada melhor. E se este trabalho lembra muito o trabalho dos extintos analistas de organização e métodos não é mera coincidência. É pura necessidade!
Nosso caso específico apresenta como um dos maiores desafios o ganho de produtividade dos vendedores. Além da grana, será necessário medir o tempo gasto em todos os processos relacionados. E a medição in loco é a melhor maneira de eliminar ambiguidades e falsas suposições.
Aliás, vale a pena destacar que os métodos de observação estão ganhando espaço novamente. Trabalhos como Subject to Change (Peter Merholz et al – O’Reilly, 2008) e Change by Design (Tim Brown – Harper Business, 2009) ilustram a criticidade desses métodos para o desenho de sistemas e produtos. Fabrício Teixeira², também das áreas de UX (User eXperience) e design, escreveu sobre isso recentemente. Gerald Weinberg já apresentava sugestões bastante parecidas no distante 1990, no livro Redefinindo a Análise e o Projeto de Sistemas (McGraw-Hill).
Poucos projetos podem ser piores do que aqueles originados de uma única cabeça. Um projeto saudável considera a perspectiva de diversas pessoas. No entanto, como nos ensinam Gause e Weinberg³, “cada novo ponto de vista produzirá um novo desajuste”. Porque interpretações e requisitos conflitantes surgirão. Porque novos desejos, necessidades e restrições serão manifestados. Ainda assim, devemos buscar (o quanto antes!) por novas perspectivas.
Imaginem um dos vendedores da ACME, o Gracindo, entrando na conversa:
V: O Dilermando (gerente entrevistado anteriormente) acha que somos preguiçosos, né? Mas ele já foi pra rua comigo e viu como é duro o nosso trabalho.
A: Não é isso. Ele acredita, e nós também, que é possível aumentar a produtividade de vocês vendedores. E, pense só, sua comissão pode aumentar em até 50%!
V: Será? Sei não. Talvez eles mudem a política. Já ouvi falar em premiação dos mais produtivos e coisa e tal…
A: Mas a premiação de uns não significará a penalização dos outros. Questão de meritocracia. Sejamos mais objetivos: Gracindo, o que te impede de visitar mais clientes?
V: Tirando os congestionamentos? A lenga-lenga de alguns clientes. Nossa venda tem que ser feita na hora. Conferimos o estoque de um cliente e sugerimos a reposição. Tem uns poucos que são bem rápidos, aceitam nossa sugestão e pronto. Mas tem outros… até parece que estão decidindo uma compra de milhões de reais. Pensam, pensam, pensam… e no fim, na maioria das vezes, acabam alterando muito pouco as quantidades que sugerimos.
A: E sobre a possibilidade de vender mais nos clientes atuais, você acredita nela?
V: Nem um pouco. A menos que a gente atualize e aumente nossa carteira de produtos.
O diálogo acima não ilustra apenas a resistência do Gracindo, que é comum e natural. Ele também está questionando a viabilidade de um dos requisitos de negócio apresentados (aumentar o valor médio das vendas). Seu ponto de vista será considerado? O que o Dilermando pensa sobre isso? E os outros vendedores?
Outro ponto que merece toda a atenção: Gracindo teme por mudanças (nunca cogitadas oficialmente) em regras de negócio que tratam do cálculo das comissões. De onde veio essa informação/fofoca? E o que há de verdadeiro nela?
Novos pontos de vista = novos desajustes.
Cada evento de aprendizado e desenvolvimento de requisitos deve ser imediatamente seguido de uma bateria de testes. Desta forma caçamos ambiguidades, contradições e dúvidas. Relaciono abaixo dúvidas que criei e ainda não consigo resolver:
Artigos mais curtos!, prometeu este que vos escreve. E agora empurra-lhes pouco mais de 2000 palavras. Peço desculpas, mas não vi muito sentido em entregar a história acima em pedaços. E as redundâncias (e eventuais contradições) têm fins didáticos.
Farei o possível para manter o padrão de um artigo com exemplos seguindo um de conteúdo teórico. Sendo assim, o próximo capítulo retoma a teoria. E leva o papo para longe: precisamos conversar sobre Informação, Ferramentas Sociais e… Conversas! Espero não espantá-la(o). Inté!
]]>
Falhamos muitas vezes não porque não conseguimos resolver os problemas que encaramos mas porque encaramos o problema errado. –Russel AckoffRequisitos do negócio são requisitos de alto nível que explicam necessidades do negócio e justificam a execução de um ou mais projetos. Requisitos do negócio representam objetivos do negócio. Muito dificilmente esta representação se dará em uma relação de um para um. E raramente este trabalho – a verdadeira definição de um problema – chegará pronto para a equipe que deve encontrar e desenvolver a solução.
Não se trata de má vontade ou trabalho mal feito, pelo menos não na maioria das vezes. Não há um protocolo universal para comunicação de problemas e requisitos. Assim como não há nem nunca haverá um processo único, uma receitinha de bolo que nos ajude a entender e comunicar requisitos do negócio. Porque, como escreveram Donald Gause e Gerald Weinberg¹, “é impossível definirem-se os problemas naturais do dia-a-dia de uma forma simples, única e totalmente não ambígua”.
O mapa que orienta esta série indica que a definição dos requisitos do negócio antecede o(s) projeto(s) que deve(m) satisfazê-los. Não estou sugerindo que este seja o processo e sim afirmando que é assim que as coisas acontecem, mesmo na mais bagunçada das empresas. Uma organização, ao reconhecer um problema ou identificar uma oportunidade², decide efetuar uma ou mais mudanças. Mudanças que podem ser planejadas e executadas através de projetos.
Portanto, o início de um projeto marca o fim do reconhecimento e aceitação de um problema. Colocando de outra forma: o início de um projeto indicaria o término da fase de descoberta e entendimento dos requisitos do negócio. Este é o momento em que a porca torce o rabo e nossos primeiros desafios dão as caras. Veja no pequeno inventário abaixo quais situações lhe são familiares:
Repare no diagrama acima que TODOS os requisitos de um projeto derivam dos requisitos do negócio. É fácil concluir que a ausência ou o desconhecimento destes torna um projeto um bate papo entre malucos, uma viagem sem destino nem mapas. Assim como deve ser fácil entender que suposições e decisões acerca dos requisitos do negócio viverão até o término do projeto e além.
Antes que muitos saibam alguma coisa, um deve sabê-lo. – Henrik IbsenÉ de fato natural que o início de um projeto seja marcado por muitas incertezas. Mas é inaceitável que a equipe não saiba o que perguntar e para quem. A primeira grande pergunta é: por que este projeto é necessário? Claro, ela pode ser formulada de outras maneiras. E seguida por outras questões abertas que ajudarão a formar uma primeira visão do projeto. Seguem algumas sugestões³:
As duas últimas questões nos ajudam a iniciar o mapeamento de todas as partes interessadas, interesseiras, indiferentes e até as encrenqueiras. Todas as pessoas que surgirem como resposta para a última questão devem ser submetidas ao mesmo questionário acima. No bololô das redundâncias (desejadas), buscaremos por contradições, mal entendidos, suposições tácitas (escondidas) e dúvidas.
Aliás, criar e semear dúvidas é uma forma de elaborar, amadurecer e testar os requisitos do negócio. Gause e Weinberg sugerem a regra das três interpretações¹: “Se você não puder achar pelo menos três coisas que possam estar erradas com sua compreensão do problema é porque não entendeu o problema”. Depois, ao apresentar essas interpretações aos envolvidos, caminhamos no sentido de eliminar ambiguidades e mal entendidos.
Este trabalho de reflexão e questionamento não combina com a pressa. Por isso será sempre recomendável que ele ocorra antes que um projeto seja disparado. Desta forma, ele não sofrerá a pressão de um cronograma. Por favor, não me interprete mal. Não estou sugerindo que esta etapa seja longa e demorada. Mas também não vou vender a ilusão do “separe 10% do cronograma para esta fase” ou o engano das iterações 0, -1 etc. Todo projeto é único. Alguns pedirão por algumas semanas de reflexão. Outros serão definidos (ou abortados) em poucas horas. C’est la vie…
Todos os trabalhos sobre requisitos que mostram alguma preocupação com este momento inicial concordam em algumas recomendações: vá devagar; seja redundante; tenha mente de iniciante; procure por todos os pontos de vista relevantes; ouça e pense, ouça e pense… (repita n vezes antes de abrir a boca). Sugestões que parecem contradizer alguns mantras do mundo moderno. Estariam ultrapassadas? Veremos no próximo capítulo, através da apresentação de um exemplo prático. Inté!
]]>
Esta série será elaborada em paralelo a uma revisão do material didático de dois treinamentos, {FAN} +Requisitos e {FAN} +Conversas. Os capítulos devem ser um pouco mais curtos e aparecer com mais frequência do que o normal. Nesta introdução aponto o caminho que será seguido e os principais tópicos abordados.
Faz tempo que uso o nome Base de Conhecimentos para apresentar o diagrama ao lado. A primeira intenção é didática, como tentarei mostrar no restante deste artigo. Mas, ah como eu gostaria de vê-lo devidamente implantando em uma empresa. Porque está ali praticamente tudo o que é preciso saber sobre projetos e requisitos. Porque não há caixinhas soltas – nenhuma informação que não possa ser rastreada. Enfim, deixa pra lá (por enquanto).
No lado esquerdo do diagrama temos os quatro elementos fundamentais que compõem qualquer negócio: Objetivos, Recursos, Processos e Regras. Trata-se de um metamodelo de negócio cujo detalhamento está fora do escopo deste trabalho. Se você quiser entender um pouco mais sobre ele, dê uma olhada na série Pensando Negócios. Nos interessam aqui as duas ligações principais entre o modelo de negócios e os requisitos: 1. Requisitos do Negócio representam objetivos; 2. Funções suportam a execução de processos de negócios.
O diagrama sugere que objetivos de negócio podem ser quebrados em um ou muitos requisitos do negócio. Vejamos como isso poderia ou deveria acontecer.
Dirigentes da empresa ACME decidem que um de seus maiores objetivos para o próximo biênio é aumentar a lucratividade em 30%. Sabem que este ganho será produto de duas iniciativas principais: a) Aumento da base de clientes; e b) Redução dos custos de vendas. Ambas iniciativas apontam para uma única grande mudança: o processo de vendas deve ser totalmente revisto. Os vendedores devem ser capazes de realizar no mínimo 30 visitas por dia, um aumento de 50% em relação à média atual. A ACME está ciente de que precisa aprender duas coisas de forma que possa realizar o ganho de produtividade dos vendedores: i) Tornar as visitas de vendas mais eficazes (indicadores: número de negócios fechados e valor médio das vendas); e ii) Tornar as visitas mais eficientes (indicador: duração média de cada visita).
Utilizei uma poderosa ferramentinha para descrever os objetivos do negócio acima: o Balanced Scorecard. Como sugeri em outra oportunidade, sua última perspectiva (Aprendizado & Desenvolvimento) pode ser tratada como fonte (riquíssima) de Requisitos de Negócio. Repare que temos dois grandes requisitos neste momento: aumentar a eficácia e a eficiência das visitas de vendas. No próximo capítulo conversaremos bastante sobre eles.
Requisitos de negócio, dependendo de sua amplitude e complexidade, podem exigir o lançamento de diversos Projetos. Aqui poderíamos engatar uma conversa sobre programas e portfólios. Mas não é esta a intenção do artigo. Basta entender que determinados requisitos de negócio podem requerer n aprendizados e mudanças (leia-se n projetos).
Cada projeto é um conjunto de Requisitos. E talvez seja a hora de, pela milionésima vez, apresentar uma definição para essa palavrinha tão maltratada. Antes, uma definição que você só deveria utilizar como piada ou se quiser enrolar alguém (um belo exemplo de maltrato)¹:
“Ao ler o Guia BABoK® é vital que ‘requisito’ seja tomado pelo sentido mais amplo possível. Requisitos incluem, mas não estão limitados a condições ou capacidades passadas, presentes e futuras em uma organização e descrições de estruturas organizacionais, papéis, processos, políticas, regras e sistemas de informação. Um requisito pode descrever o estado presente ou futuro de qualquer aspecto da organização.”
Um requisito é simplesmente a expressão de uma necessidade ou restrição. Ponto. Se preferir uma definição mais formal, apele ao Houaiss: re.qui.si.to s.m. condição necessária para alcançar certo fim. PONTO! Para que complicar?
O que é necessário, isso sim, é uma visão bem estruturada dos principais tipos de requisitos. Como ilustra o diagrama acima, eles são três:
Estas definições, nada menos que fundamentais, não deveriam mudar dependendo da escola, metodologia ou ferramental empregado. Uma função será sempre uma função, não importa se ela foi descrita na forma de uma user story, uma especificação de caso de uso ou em um documento pra lá de formal.
Pretendo bater forte nos conceitos. Martelá-los mesmo. Mas não ignorarei o lado prático, o trabalho real com requisitos. A série obedecerá a sequência sugerida neste artigo, ou seja: Requisitos do Negócio, Requisitos, Funções, Atributos e Restrições. Cada tema merecerá no mínimo dois artigos. Semana que vem: Requisitos do Negócio – Os únicos que podem manchar para sempre o seu currículo. Soou dramático? Foi esta a intenção. Inté!
]]>
O pessoal que define “o que precisa ser feito”, os analistas de negócios, empatou com a turma do “como será feito”, os analistas de sistemas. 22% de participação de cada um. Em segundo lugar vieram os coordenadores de projetos, com 15% das respostas. Desenvolvedores e analistas de processos aparecem com 10% e 9%, respectivamente. De curioso aqui nosso coringa, que disse ser analista de negócios, de sistemas, de requisitos, desenvolvedor e arquiteto! Será que o salário é compatível com tantas responsabilidades?
Um participante cobrou, não perguntei sobre rendimentos. Falha minha. Não sei se por sorte ou azar, no mesmo período, a revista Você SA da Abril liberou uma pesquisa sobre o assunto. Cobre mais de 130 profissões, sendo 14 específicas da área de TI. Vou destacar aqui apenas um ponto: analistas de sistemas ou analistas-programadores (chamados naquela publicação de analistas de desenvolvimento) ganham praticamente a mesma coisa que analistas de negócios. Até os 5 anos de experiência. Depois disso, mostra a pesquisa, os analistas de negócios apresentam salários consideravelmente maiores. A diferença chegaria a R$ 5 mil entre profissionais com mais de 15 anos de experiência. Nesta faixa de tempo de estrada, o salário de analistas de negócios em pequenas e médias empresas seria maior até do que dos gerentes de projetos. Estranhei muito o número, mas não tenho como questioná-lo. A empresa que executou a pesquisa, a Robert Half, fez mais de 30 mil entrevistas. É uma pena que tenha se limitado aos mercados de São Paulo e Rio de Janeiro.
São Paulo de fato concentra a grande maioria das vagas. Em minha pesquisa, 58% dos participantes são de lá. Rio, Santa Catarina e Minas aparecerem na sequência, com quase 10% cada um. Profissionais do sexo masculino também confirmam outro tipo de concentração: são 81%, contra 19% de mulheres. 70% dos participantes têm idade entre 23 e 34 anos. Com mais de 40 tivemos 11%. Curiosidades: 44% disseram se apresentar como “Sêniores”, contra 39% que são “plenos (ocasionalmente vendidos como sêniores)”; 5% estão “loucos(as) para mudar de profissão”.
Mais da metade dos participantes, 57%, trabalha em empresas de TI. 30% em serviços de desenvolvimento e manutenção de sistemas. A maioria, 28%, conta com mais de 100 profissionais na área de TI. Mas, que espanto, 48% de todas as empresas contam apenas com algo entre 1 e 5 profissionais trabalhando com análise de negócios. Na questão eu ainda tive a preocupação de especificar que seria qualquer profissional que executasse: modelagem de negócios, modelagem de processos, desenvolvimento de requisitos etc. O desequilíbrio parece ser muito grande.
Repetiu-se neste levantamento um número que tem cara de “default”: 62% dos projetos têm algum tipo de problema. 21% seriam “muito mal sucedidos (muito atrasados e gerando prejuízos)”. Para dizer a verdade, o número até que é um pouquinho melhor do que aqueles que vemos em outros lugares. Mas ainda é muito comprometedor.
Nada de novo também no front dos principais problemas: mudanças de requisitos (18%), requisitos mal definidos (17%) e mudanças de regras de negócios (13%) são os principais. Pouco envolvimento de clientes e usuários, metodologia mal aplicada e equipe mal preparada respondem por 9% cada um.
61% das empresas estão cientes dos problemas e tomando providências. As principais seriam: treinamento da equipe (31%), implantação de novas tecnologias e ferramentas (23%), implantação de nova metodologia (21%).
E quais metodologias, processos ou padrões são utilizados? Algumas surpresas: PMBoK (23%), Scrum (18%), RUP (16%), CMMI (10%) e XisPê (8%) são os destaques. Fiquei com pulgas atrás do orelhão: com tanto Scrum, como ninguém se apresentou como ScrumMaster ou Product Owner? O número do RUP também surpreendeu.
O que não surpreende é que 71% ainda utilizem editores de texto para tarefas de descoberta, descrição e gerenciamento de requisitos. E 61% depositem suas esperanças em planilhas eletrônicas. A relação não fica explícita, mas tenho certeza que essas ferramentas colaboram diretamente com os problemas listados acima.
Mas 68% utilizam especificações de casos de uso. Parece um bom sinal. Mas o número não bate com os levantamentos informais que faço em meus eventos. Será que estão falando de casos de uso de verdade, ou daquelas extensas descrições de telas e de como a solução deve ser construída? Infelizmente seguirei sem resposta. Mas desconfiado de que estamos falando de casos diferentes.
Perguntei se praticavam a modelagem de negócios. 38% disseram que sim, “e percebem o valor dela”. 35% disseram que praticam, mas “só um pouquinho”. 73% praticam a modelagem de negócios?!? Outro número que não bate de forma alguma com o que vejo nos eventos e empresas. Ainda mais com 59% dizendo utilizar a UML para tal. Para se ter uma ideia, são 23% aqueles que utilizam a BPMN. Pouco mais que os 20% que já estariam utilizando o método do “Pensamento Visual”.
Uai cara pálida: você faz uma pesquisa para depois questionar os números obtidos? Entendam, por favor: a culpa é da pesquisa e do número de respostas. Minha críticas acima servem apenas para destacar pontos da pesquisa que parecem estar bastante distorcidos. E uma das causas das distorções é óbvia e também foi levantada: 55% de quem participou da pesquisa já participou de algum evento FAN.
Mas, de qualquer maneira, pistas e palpites podem ser observados e colocados. Resta esperar que futuras iniciativas como esta sejam melhor elaboradas e mereçam um número bem maior de participantes. Aos que aceitaram meu convite e doaram preciosos minutos, registro aqui meu muito obrigado. E boa sorte no sorteio!
.:.
A foto utilizada acima, “Torcedor Solitário“, foi devidamente surrupiada do Rodrigo Moraes.
]]>Gere conteúdo. Se ele for bom, conversas surgirão em torno dele. As conversas serão duradouras, se forem boas. Elas gerarão transações, se forem realmente boas.
A simplicidade do modelo não deveria enganá-lo. Sua implementação não é nada fácil nem rápida. Mas não pense que é a geração de conteúdo a parte mais complicada. Apesar de alguns poucos preguiçosos que vivem de surrupiar material alheio sinalizarem o oposto, o fato é que criar conteúdo – ter assunto – é a etapa mais simples do modelo acima. Ainda mais numa área fervilhante e diversificada como a nossa.
Difícil mesmo é iniciar e manter conversas. Mesmo que o assunto seja bom e promissor. E as razões para essa dificuldade são óbvias: conversas demandam tempo, e tempo é um recurso muito escasso atualmente; conversas requerem atenção, e como andamos distraídos e/ou sobrecarregados!
A boa administração do que é escasso e do que é abundante é tema recorrente tanto do JP quanto de Seth Godin, outro provocador obrigatório. A lei existe desde que nos entendemos por gente: o que é escasso é obrigatoriamente mais caro. Então, por favor, valorize seu tempo! Valorize meu tempo! No bullshit!, diriam nossos amigos do norte.
O programa FAN (Formação de Analistas de Negócios) foi desenhado de acordo com esse modelo. Eu não queria que as conversas terminassem depois das 7, 14 ou 20 horas de um evento. Cerca de 25% dos participantes também não. Por isso aceitaram participar de um grupo de discussão que tinha só essa grande missão: esticar o papo.
Em 2 anos e 3 meses nós trocamos 4.166 mensagens. Hoje somos pouco mais de 500 participantes. Impossível mensurar o que aprendi e quanto enriqueci o conteúdo a partir dessas conversas. Só sei dizer que é muita, muita coisa. Também não sei dizer o quanto os outros integrantes do grupo ganharam. Mas quero desconfiar que não é pouco. Se fosse, já teriam abandonado o barco.
O curioso dos grupos, de todos eles, é que a grande maioria dos integrantes é relativamente silenciosa. Quando provocados, costumam dizer “não sou muito ativo(a), mas gosto muito das discussões”. Confesso um certo incômodo com tamanha passividade, mas já desisti de achar uma forma de reduzi-la.
O grupo sempre foi um diferencial do programa FAN. Até hoje ele era exclusivo para os participantes dos eventos promovidos por mim. E a razão da trava nunca foi comercial: eu queria apenas uma uniformidade de interesses e vocabulário. Essa homogeneidade não faz mais sentido e o grupo topou ser aberto para o público em geral.
Portanto, se você aceitou esse lero-lero até aqui, talvez aceite também nosso convite para participar do AN.br, uma comunidade virtual que debate a Análise de Negócios, profissões correlatas, Modelagem de Negócios, Pensamento Visual, Engenharia de Requisitos e Viabilização de Projetos. Se for o caso, por favor, solicite sua inscrição através deste link, informando que recebeu o convite através do finito.
E, já que estamos aqui, posso surrupiar mais 15 minutos de seu escasso tempo? É que estou fazendo uma pequena pesquisa sobre projetos e a Análise de Negócios no Brasil. São apenas 23 questões, a maioria demandando apenas um clique. Quem participar terá acesso integral ao resultado da pesquisa, além de concorrer aos seguintes prêmios: 3 vagas em eventos FAN e 5 agendas personalizadas (desenhadas especificamente para analistas de negócios e product owners). Para tanto, basta que você envie um email para [email protected], confirmando que respondeu ao questionário. Clique aqui para participar.
É conversando que a gente se entende. E se estou com orelhas tão grandes, é só pra te escutar melhor. Inté!
.:.
A imagem utilizada, FOWA Sketch, é de KaiChanVong, e foi surrupiada legalmente, se é que você me entende.
]]>