PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Conversas

  • +Requisitos: Perguntas?

    +Requisitos: Perguntas?

    O capítulo anterior apresentou os principais canais de comunicação e ferramentas sociais que utilizamos no trabalho com requisitos. Antes, em +Requisitos +Informação, vimos que uma Resposta = Informação + Confirmação + Ruído. Buscamos requisitos em respostas. Mas, como as obtemos? O que perguntamos?

    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:

    • Qual ou quais problemas de negócio você precisa resolver?
    • Qual é a motivação para que se resolva este problema?
    • O que pode acontecer se ele não for resolvido?
    • Que tipo de solução está fora de cogitação? Por quê?
    • Você entenderá que este projeto foi um sucesso se…
    • Quanto vale esta solução?
    • Quais pessoas ou áreas serão afetadas pela implantação desta solução?
    • Quem poderá influenciar a construção desta solução?

    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.

    Perguntas Direcionadoras

    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:

    • Qual problema você está tentando resolver?
    • Quanto tempo temos para a realização deste projeto?
    • Quanto você espera gastar?
    • Ao concluir esta operação, para onde o usuário vai?
    • Vocês utilizam códigos de barras para a identificação de produtos?
    • Manga com leite faz mal?

    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.

    Perguntas Criativas

    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:

    • Há outra forma de resolver este problema?
    • De quais maneiras o usuário pode receber essa informação?
    • Você pensou na possibilidade de uso de dispositivos móveis?
    • Quais outras áreas da empresa veriam utilidade nesta ferramenta?
    • O que combina com manga?

    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.

    Perguntas Retóricas

    Estas devem ser evitadas a todo custo. Só criam mal estar e nunca geram informação. Alguns exemplos:

    • Então, você só tem 10 mil pra gastar, né?
    • Por que não procurou a gente antes?
    • E você não sabia que fulano é do contra?
    • O usuário ignora o aviso, clica aí e espera, né?
    • E você achou que manga com pinga e licor de menta cairia bem?

    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.

    Metaquestões

    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:

    • Estou perguntando demais?
    • Me esqueci de perguntar alguma coisa?
    • Você quer me perguntar alguma coisa?
    • Minhas questões são relevantes?
    • Você é a pessoa certa para responder isso?
    • Há mais alguém que deveria participar desta conversa?
    • Você me receberia novamente?

    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.

     

    Notas

    Três livros serviram como base para este artigo:

    • Exploring Requirements – Quality Before Design, de Gerald Weinberg e Donald Gause (Dorset House, 1989).
    • Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990).
    • A Arte do Gerenciamento de Projetos, de Scott Berkun (Bookman, 2008).

     

  • +Conversas: Canais & Ferramentas

    +Conversas: Canais & Ferramentas

    No capítulo anterior vimos, em linhas gerais, como uma organização aprende. A conversa de hoje é sobre socialização, mais especificamente sobre canais de comunicação e ferramentas sociais.

    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².

    Ferramentas Sociais

    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.

    Reuniões

    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:

    • Abertura / Apresentação: de uma ideia, proposta ou de um problema. Normalmente é configurada para motivar uma primeira rodada de debates acerca do tema exposto.
    • Exploração: de ideias e alternativas. É neste tipo de encontro que acontece a maior parte do desenvolvimento de requisitos. E é este tipo de reunião que apresenta o maior número de variações.
    • Fechamento / Prestação de Contas: acerca de um projeto, iteração ou tarefa específica. É uma conclusão que, em alguns casos, resulta em nova abertura ou no planejamento desta.

    É 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:

    • Objetivo: todo encontro deve ter um objetivo bem colocado. Ou, no máximo, um pequeno conjunto de objetivos. Ao convidar as pessoas – recomendo que isso ocorra com sete dias de antecedência – os objetivos devem ser comunicados. E reforçados logo na abertura da reunião.
    • Pessoas: a lista de quem deve participar da reunião. É importante, para a produtividade do encontro, que a lista seja a menor possível. Se, por exemplo, a matriz RACI informa que fulano espera apenas ser informado, então ele não deveria ser convidado. Se contentará com um resumo (ata não!) daquilo que foi decidido no encontro. Reuniões de abertura ou fechamento, que por definição envolvem um número menor de informações (e discussões), podem acomodar (incomodar não!) um público maior. Reuniões de exploração são mais produtivas quando envolvem um número pequeno de participantes.
    • Processo: cada tipo de reunião requer um processo diferente. Eventos de abertura ou fechamento são mais simples e apresentam poucas variações de processos. Já as reuniões de exploração podem ter variações mil. Existem diversos formatos de brainstormings e reuniões visuais, por exemplo. Sou fã de carteirinha de um meta-modelo que pode ser aplicado em todo e qualquer tipo de reunião, o método d’Os Seis Chapéus do Pensamento (Sextante, 2008) criado pelo médico e psicólogo Edward De Bono.
    • Produto: não é tão mais simpático chamar de produto o que nossos senhores aparecidos citam como entregável? Deixa pra lá. O importante aqui é entender que toda e qualquer reunião deve gerar um resultado, um produto. Como se concretiza a realização de determinado objetivo? É recomendável que se pense nisso com certa antecedência. Mesmo que o produto seja uma simples lista com distribuição de responsabilidades.
    • Preparação: e por falar em certa antecedência. O que deve ou pode ser feito antes da reunião de forma a evitar atropelos, improvisos e saias justas? Não cabe aqui apenas uma eventual apresentação tipo powerpoint, mas tudo o que pode ser preparado para garantir um encontro produtivo.
    • Logística: destaca-se aqui outro tipo de preparação, aquela que envolve reserva de salas e equipamentos de apoio; revisão da lista de convidados; elaboração e publicação do convite (pauta); aquisição ou solicitação de comes & bebes etc.
    • Riscos: não há ato de planejamento bem feito que não considere e destaque possíveis armadilhas. Ao simplesmente pensar sobre isso os organizadores e condutores do encontro já se protegem contra malas, debates estéreis, aparecidos da silva e outras incontáveis situações que podem comprometer uma reunião.
    • Se eu fosse o autor do framework 7P’s destacaria outro componente, o Tempo. É nada menos que vital para uma reunião produtiva que sejam delimitados (e incondicionalmente respeitados) os horários de início e término do encontro. E faz bem para a qualidade dos requisitos que os eventos não ultrapassem o limite de duas horas de duração.

    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.

    Observações

    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:

    • Ativa: o observador ocupa o lugar do observado por um certo tempo, executando seu trabalho. Literalmente, “calçamos os sapatos” e “sentimos as dores” do usuário ou cliente. Não vale que seja por apenas alguns minutos, apenas para “ver como é”. Não, na observação ativa dedicamos o tempo necessário para literalmente sentir dores. Rica que é, difícil explicar sua pequena adoção em terras tupiniquins. Será preguiça?
    • Passiva: aqui há de fato apenas a observação atenta. Em alguns casos, ela deve ser silenciosa e, se possível, escondida. Explico: não é raro que o observado, quando ciente da observação, passe a atuar – falseando ou exagerando seus gestos, falas, caras e bocas. Se ele deixar de ser quem é, de fazer o que realmente faz e como o faz, a observação estará perdida. As conversas, quando necessárias, devem ser separadas da observação. Interrupções constantes também comprometem o trabalho de observação.

    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.

     

    Notas

    1. Surrupiado de Comportamento Organizacional, Stephen Robbins (Prentice Hall, 2002).
    2. Um projeto de sistema que se propõe a substituir outro sistema, por exemplo, não exigirá tanto encontro tête-à-tête. Aliás, se for uma simples substituição, a maioria das reuniões e entrevistas devem ser feitas com o próprio substituído. A isso chamamos Engenharia Reversa, técnica que ainda pode aparecer no decorrer desta série.
    3. Gamestorming, Dave Gray, Sunni Brown e James Macanufo (O’Reilly, 2010);
      Visual Meetings, David Sibbet (Wiley, 2010);
      The Back of the Napkin, Dan Roam (Portfolio, 2008). Eu fugiria da edição nacional deste, uma lástima. De qualquer maneira, caso te interesse, foi traduzido como Desenhando Negócios e publicado pela Campus (2010).
    4. Surrupiado de Gamestorming, listado acima. Os 7 P’s do nome, do original em inglês, são Purpose, People, Process, Product, Prep, Practical Concerns e Pitfalls. Eu sei, é barra forçada para parecer original. Este modelo, com pequenas variações, deve existir desde a época em que morávamos em cavernas. De qualquer maneira, não dá para negar sua utilidade.
    5. O Líder Técnico, Gerald M. Weinberg (Makron Books, 1994).

     

  • +Aprendizado sobre Requisitos

    +Aprendizado sobre Requisitos

    Foi sincera a questão que encerrou o capítulo anterior: o que viria a seguir? Por natural que pareça o tema que será desenvolvido nesta parte – aprendizado – não é comum vê-lo em trabalhos sobre requisitos. A exagerada compartimentalização de disciplinas que inventamos no século passado e, infelizmente, seguimos alimentando, deixa entender que conhecimento e aprendizagem organizacional ficam em um lado, requisitos ou engenharia de requisitos noutro. Divisão falsa e danosa. O aprendizado e desenvolvimento de requisitos é um tipo de aprendizagem organizacional. Em minha opinião, o mais importante deles. Porque é em projetos que geramos e disseminamos o maior número de novos conhecimentos.

    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²:

    • Tácito: pessoal, específico de um contexto, difícil de comunicar. Existe em duas dimensões:
      • Técnica: comumente identificado como know-how (saber como fazer);
      • Cognitiva: crenças, valores, ideais, percepções, emoções e modelos mentais.
    • Explícito: codificado, transmitido de maneira formal e sistemática.

    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á!

     

    Notas

    1. Conhecimento é uma das cinco dimensões de um sistema sociocultural (de uma empresa, por exemplo). Quando apresentei o tema na série anterior, Pensando Negócios, escrevi que são dois verbos – duas preocupações – que caracterizam a forma como uma organização trata cada dimensão. Os verbos são Gerar e Disseminar. Neste novo contexto eles podem ser trocados por apenas um: Aprender. Se o tema lhe interessa, recomendo a leitura das partes V e VI daquela série.
    2. Os pais do modelo aqui apresentado são Hirotaka Takeuchi e Ikujiro Nonaka. Recomendo dois trabalhos: Gestão do Conhecimento (Bookman, 2008) e Knowledge Management – Classic and Contemporary Works, coletânea de artigos compilada por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (MIT Press, 2000). Os artigos clássicos de Takeuchi e Nonaka são de 1995/96. Um deles está neste último livro. Outro deu origem ao método conhecido como Scrum.
    3. Tenho quase certeza de que o autor original desta brincadeira foi Thomas Stewart, autor de outro livro fundamental sobre aprendizagem organizacional: Capital Intelectual (Campus, 1998).

     

     

  • +Conhecimento sobre Requisitos

    +Conhecimento sobre Requisitos

    No capítulo anterior vimos conceitos básicos sobre dois elementos fundamentais para o trabalho com requisitos: Informação e Comunicação. O tema de hoje é Conhecimento – o que devemos aprender e desenvolver sobre cada requisito de um projeto. O papo será mais prático, podes crer.

    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.

    Tipo

    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.

    Fonte

    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.

    Perspectiva

    É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:

    • Estratégica: a pessoa está no topo da pirâmide organizacional, é proprietária ou da alta direção.
    • Tática: gerentes, coordenadores ou supervisores. A pessoa está no escalão intermediário.
    • Operacional: na base da pirâmide, onde ficam todos que de fato colocam a mão na massa (ou  no martelo).

    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.

    Valor

    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:

    • Fundamental: a não realização deste requisito resultará em fracasso do projeto. Sua satisfação é incondicional.
    • Importante: este requisito não dá uma contribuição direta para a realização dos objetivos do negócio. É uma função ou característica que pode ser entregue em outro momento. Ainda assim, por algum motivo, ela é importante para o cliente ou usuário.
    • Opcional: requisito que não representa nenhuma contribuição direta ou indireta para a realização dos objetivos do negócio. Deve ser percebido apenas como algo que agradaria o cliente ou usuário caso haja tempo e dinheiro para sua realização.

    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á!

    Relações com os Outros Requisitos

    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:

    • Dependência: a realização do requisito B depende da realização do requisito A. É através deste mecanismo que agrupamos requisitos, formando um módulo ou uma funcionalidade completa, por exemplo.
    • Complementaridade: a realização do requisito A facilita a realização do requisito B ou simplesmente o completa. Aqui também sinalizamos um agrupamento, desta vez com elementos levemente acoplados.
    • Redundância: requisitos A e B, apesar de uma possível redação diferente, representam a mesma condição – necessidade ou restrição. Portanto, um deles deve ser excluído* do escopo do projeto.
    • Conflito: o requisito A impede a realização do requisito B. Este conflito normalmente se dá entre funções e atributos ou, principalmente, entre funções e restrições. E, infelizmente, boa parte deles só pode ser identificada na bancada de testes. Ainda assim, é recomendável que o analista fique atento aos conflitos em potencial. E registre-os.
    • Substituição: o requisito B substitui o requisito A. Está aqui o mais importante mecanismo de proteção da história do projeto de todo o modelo proposto. Uma vez registrado, nunca mais o requisito deveria ser editado ou apagado. Se determinado requisito precisa ser alterado por algum motivo qualquer, deveríamos registrar um novo requisito e indicar que ele substitui um ou mais existentes. Anotando cuidadosamente o motivo da alteração. No meio de tanto bafafá sobre gerenciamento de mudanças, normalmente perdemos o essencial: uma mudança é, antes de tudo, um requisito. Por isso, deveria ser tratada da mesmíssima maneira (no mínimo).
      * Portanto, o excluído daquela frase deve ser interpretado como uma desativação do requisito mas não sua exclusão física. Porque pode ser bom lembrar e medir, por exemplo, quanta redundância se originou do trabalho de diversos analistas entrevistando diversas pessoas.

    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…

    Testes

    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.

    Estado

    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 Central

    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:

    • Número: sequencial, por ordem de entrada. Serve apenas para identificação e não tem relação nenhuma com a Ordem (posição do requisito no escopo do projeto ou backlog do produto).
    • Descrição: breve texto que exprime aquela necessidade ou restrição. Existem regrinhas de padronização para cada tipo de requisito. Veremos isso no momento oportuno.
    • Justificativa: explicação (opcional) para o requisito. É um campo texto, livre.
    • Material Complementar: Lista (opcional) de links e referências para fontes que completem o entendimento do requisito.
    • Versão: Número da versão do requisito. Cada substituição inserida (veja Relações entre Requisitos acima) se reflete aqui.
    • Analista: Nome (ou código) do analista que efetuou o registro do requisito.
    • Timestamp: (Agora exagerei. Perdão).

    Revendo Tudo

    • Informação é diferença que faz a diferença. (Gregory Bateson)
    • Informação é dado investido de relevância e propósito. (Peter Drucker)
    • A conversão de dados em informação requer conhecimento. (idem)
    • Informação é a principal matéria prima de projetos.
    • Comunicação = Informação * Relacionamentos * Confirmação (Jurgen Appelo)
    • Comunicação (em Projetos) = Requisitos * Relacionamentos
    • Requisito é informação devidamente confirmada e livre de ruídos.
      Requisito = (Informação * Confirmação) – Ruído
    • Requisito, enquanto informação estruturada e enriquecida, é conhecimento produzido por conhecimento.
    • Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)

    Depois deste tour de force, quem sabe o que virá a seguir?

     

    Notas

    1. Em Requirements-Led Project Management (Addison-Wesley, 2005). É do casal Suzanne e James Robertson o modelo Volere, um “modelo de conhecimentos de requisitos” mais completo (e mais complicado) do que o que é sugerido nesta série. Não gosto da forma como o modelo do negócio é (mal) tratado no Volere.
    2. A sugestão aqui apresentada foi concebida, há mais de dez anos, como um modelo E-R (entidade-relacionamento). Quando ela deixou o laboratório e ganhou as ruas, através do treinamento {FAN}, manteve o desenho original. Para surpresa deste que aqui rabisca, o formato se provou bastante didático. No entanto, peço desculpas se a terminologia técnica ou as bobas explicações sobre ela causaram chateação, desconforto ou dúvidas. Neste caso, sou todo ouvidos.
    3. O termo elicitação não existe em língua portuguesa. E sua criação, convenhamos, é totalmente desnecessária. Não porque utilizamos coleta em seu lugar. Mil vezes não! Coletamos lixo ou material para exames clínicos. Não coletamos requisitos.
      Essa terminologia, particularmente a separação entre elicitação e análise de requisitos, é herança maldita das cascatas e cascateiros. No longínquo 1989, Donald Gause e Gerald Weinberg já nos mostravam a correção do termo Explorar requisitos (Exploring Requirements – Quality Before Design. Dorset House). São equivalentes os termos aprender e desenvolver, os meus preferidos.
      Não tem muito tempo que deixamos de chamar requisitos de requerimentos. Passa da hora de abandonarmos palavras que, além de feias, não refletem o real significado do trabalho com requisitos.

     

  • +Requisitos +Informação

    +Requisitos +Informação

    Segue o papo sobre Requisitos e Conversas. Depois dos exemplos da semana passada, hora de um pouco mais de teoria básica. Os temas de hoje são Informação, Comunicação, ruído e a relevância disso tudo para o trabalho com requisitos.

    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.

    + Comunicação

    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³:

    • Transmitida: a informação foi enviada;
    • Recebida: a pessoa na outra ponta recebeu a informação;
    • Entendida: o receptor entendeu a mensagem. Se não, é provável que o processo se reinicie com a transmissão da informação de forma diferente. Este ciclo pode se repetir diversas vezes, até que haja o entendimento;
    • Aceita: o receptor concorda com o que foi informado. Se o ciclo anterior era para compreensão, agora pode existir um ciclo de negociação. Que também pode requerer um reinício – um retorno ao primeiro estado;
    • Convertida em Ação: o receptor faz algo a respeito da informação que recebeu, entendeu e aceitou.

    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á.

     

    Notas

    1. Surrupiada do fundamental Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Ainda devo a entrada deste em nossa biblioteca.
    2. Um dos modelos de comunicação mais referenciados foi criado por Virginia Satir e publicado em The Satir Model: Family Therapy and Beyond (Science and Behaviour Books, 1991). Você entendeu bem: terapia de família! Gerald Weinberg utiliza o Modelo Satir em diversos livros.
    3. Scott Berkun também cita o Modelo Satir em A Arte do Gerenciamento de Projetos (Bookman, 2008). É dele o modelo básico utilizado neste artigo.
    4. Esta fórmula veio de Management 3.0, livro de Jurgen Appelo bastante citado por aqui e em outros lugares.
    5. A última fórmula foi retirada de Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990) – um livro que todo analista de negócios deveria conhecer. Para não ter o mesmo destino dos analistas de sistemas…

     

  • +Requisitos do Negócio | Exemplos

    +Requisitos do Negócio | Exemplos

    No artigo anterior vimos conceitos básicos sobre requisitos do negócio. Hoje veremos alguns exemplos.

    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:

    • Perspectiva Financeira:
      • Aumentar faturamento em 30%. Prazo: 2 anos
    • Perspectiva Clientes:
      • Aumentar base de clientes
    • Perspectiva Processos:
      • Tornar as visitas mais eficientes
        • Reduzir tempo de duração de uma visita
        • Aumentar número de visitas (de 15 para 24/dia)
      • Tornar as visitas mais eficazes
        • Aumentar número de negócios fechados
        • Aumentar valor médio das vendas
    • Perspectiva Aprendizado e Desenvolvimento
      • Como tornar as visitas de vendas mais eficazes?
      • Como tornar as visitas mais eficientes?

    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:

    • Perspectiva Financeira: Quanto a empresa espera ganhar (ou economizar) com isso?
    • Perspectiva dos Clientes: O que os clientes receberão de diferente? Ou estamos falando de novos clientes?
    • Perspectiva dos Processos: O que deve ser mudado no trabalho atual de forma a atender novos clientes ou levar coisas novas para os clientes atuais?
    • Perspectiva do Aprendizado e Desenvolvimento: o que devemos aprender e desenvolver de forma a mudar nossa forma de trabalho (nossos processos)?

    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.

    Nada de Duplos, Triplos ou Infinitos Sentidos

    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).

    Agregando Perspectivas

    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.

    Testes e Dúvidas

    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:

    • O aumento de 30% dos lucros é factível?
    • Esta meta esconderia outro problema?
    • Se a ACME pretende aumentar o número de clientes atendidos através do aumento da produtividade dos vendedores, então por que ela buscaria também um aumento do valor médio das vendas? Seria este último requisito uma “forçada” de barra? Se sim, qual o objetivo?
    • Gracindo nos leva a crer que Dilermando desconfia dos vendedores. Eles seriam “preguiçosos”? Dilermando pretende fiscalizá-los de alguma maneira? O controle e o papo sobre “meritocracia” (não confirmado) seriam formas de motivação extrínseca e forçada?
    • Ou Dilermando quer apenas o bem de todos e a felicidade geral da nação? Que tipo de pressão ele sofre? É ele o real demandante do projeto ou a coisa veio “de cima”?

    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é!

     

    Notas

    1. Acho que nunca um caso foi tão sugado. Como o inteligente gerador de artigos relacionados mostra abaixo, a história que ilustra esta série não é inédita. Já apareceu aqui e em diversos treinamentos que apresentei como “O Caso do Seu Moreira”. Se finalmente resolvi encerrar a história (com exemplos!) é porque estou em vias de aposentá-la. Os treinamentos que lanço no próximo mês, inclusive o {FAN} 2013, contarão um novo caso.
    2. Não tem muito tempo que comecei a acompanhar o trabalho do Fabrício. Não perco um post, mesmo quando é de caráter mais técnico. Várias leituras, particularmente das rápidas entrevistas que ele faz com outros profissionais da área, sempre me jogam no mesmo lugar: por que a comunidade de AN é tão diferente? Por que nossos papos parecem um tanto mais pobres e repetitivos? Não é desprezível a sobreposição entre as macrodisciplinas AN e UX. Por isso a diferença entre comunidades e profissionais me parece ainda mais gritante e incômoda.
    3. Seus Olhos Estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).

     

  • +Requisitos do Negócio

    +Requisitos do Negócio

    Segunda parte da série +Requisitos +Conversas. O papo de hoje é sobre requisitos do negócio, aqueles que devem explicar e justificar qualquer projeto.

    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 Início, O Fim e o Meio

    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:

    • Você não precisa saber disso, diz o cara de negócios, sonegando informações que lhe permitiriam i) Priorizar requisitos; ii) Criticar requisitos; iii) Saber se está no caminho certo; iv) Ter um propósito na vida que não seja apenas deixar-se levar; dentre outras coisas.
    • Você não é orientado a falar sobre isso pela fantástica metodologia adotada, afinal o importante é entregar dentro do prazo e do orçamento o escopo acordado, seja lá o que isso signifique.
    • Você e seus colegas estão perdidinhos da silva, sem saber o que perguntar e para quem. Mas todo início de projeto é assim mesmo, diz a voz da “experiência”.

    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³:

    • Qual ou quais problemas de negócio você precisa resolver?
    • Qual é a motivação para que se resolva este problema?
    • O que pode acontecer se ele não for resolvido?
    • Que tipo de solução está fora de cogitação? Por quê?
    • Você entenderá que este projeto foi um sucesso se…
    • Quanto vale esta solução?
    • Quais pessoas ou áreas serão afetadas pela implantação desta solução?
    • Quem poderá influenciar a construção desta solução?

    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é!

     

    Notas

    1. Seus Olhos estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).
    2. Não passarei a série toda falando sobre “problemas e/ou oportunidades”. Porque o aproveitamento de uma oportunidade é, até a sua realização, um problema. Portanto, toda vez que você se deparar com a palavra “problema” acate esta interpretação, por favor.
    3. Lista surrupiada e adaptada de More About Software Requirements – Karl E. Wiegers (Microsoft Press, 2006). Que por sua vez surrupiou e adaptou de Exploring Requirements – Quality Before Design, de Donald C. Gause e Gerald M. Weinberg (Dorset House, 1989). Autores como Wiegers e Scott Berkun consideram este o melhor livro sobre requisitos já escrito. Ele mereceu uma edição em pt-br, publicado em 1991 pela Makron Books com o infeliz título Explorando Requerimentos de Sistemas. Está esgotado, mas você pode ter a sorte de encontrá-lo nos sebos da vida.

     

  • +Requisitos +Conversas

    +Requisitos +Conversas

    Depois de uma releitura dos conceitos de arquitetura e modelagem de negócios,  por que não uma série sobre outro tema que é muito caro para este {finito}, requisitos? Até hoje, publiquei apenas onze artigos sobre o tema. Eles estão soltos por aqui. E um tanto datados. Além disso, tenho visto um maior interesse pelo tema. Em buscas que caem neste site e papos que rolam por aí.

    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.

    Uma Base de Conhecimentos

    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:

    • Funções – ações que um produto, serviço ou sistema deve realizar ou ajudar um usuário a realizar. Aqui sempre temos um verbo, uma ação. O diagrama sugere que as funções, quando realizadas por um sistema de negócio, invariavelmente suportam (apoiam) a execução de um ou mais processos de negócio. É interessante notar que esta vinculação direta pode não fazer sentido em produtos de uso geral como um editor de textos, por exemplo.
    • Atributos – são características que um produto, serviço ou sistema deve apresentar. Alguns atributos serão gerais – devem caracterizar o produto, serviço ou sistema como um todo. Mas a grande maioria estará vinculada a funções específicas. O diagrama sugere que alguns atributos serão detalhados em termos de Preferências, possibilitando ou facilitando, por exemplo, negociações ou tarefas de personalização.
    • Restrições – são as fronteiras apresentadas e que devem merecer, logo de cara, uma classificação. Existem restrições ao projeto (orçamento, prazos, equipe etc – sim, são exemplos de requisitos!) e restrições ao produto, serviço ou sistema (tecnologia, formas de acesso e distribuição, política de atualização etc). É curiosa e muito comum a confusão que existe entre requisitos do tipo restrição e regras de negócio. É fácil desfazê-la: tire o produto, serviço ou sistema; A restrição segue valendo? Então se trata de uma regra de negócio, não de um requisito.

    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é!

     

    Notas

    1. O Guia BABoK® (ainda) não mudou mas eu passo a impressão de estar cada dia mais azedo em relação a ele, né? Não é só impressão não. Mas meu alvo não é mais o BABoK e sim a comunidade que insiste em espalhá-lo sem o mínimo senso crítico. Se senso crítico é uma das principais qualidades esperadas de um analista de negócios, o que dizer? O que fazer? O quanto chorar? Melhor é deixar pra lá.
    2. Não passarei toda a série escrevendo “produto, serviço ou sistema”. Vamos combinar o seguinte: nos próximos capítulos vou escrever apenas “sistema”. Por favor, entenda que pode se qualquer tipo de sistema. Um liquidificador é um exemplo de sistema, ok?

     

  • Pistas & Palpites – O Resultado da Pesquisa

    A pesquisa que disparei 15 dias atrás só permite concluir uma coisa: nosso povo não gosta muito desse tipo de coisa. Coloquei uma meta muito modesta: 150 participantes. Consegui apenas 131. Entendo que é uma amostra muito pequena, que não permite conclusões. Mas dá boas pistas. E possibilita a elaboração de alguns palpites.

    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.

    Sobre Projetos

    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.

  • Sobre Conversas e Comunidades

    De todos os modelos de negócio que vi nos últimos anos, apenas um merece minha mão no fogo e meus suados centavos. Conheci sua versão consolidada através do blog Confused of Calcutta, de JP Rangaswami. Dada sua amplitude, talvez seja mais correto chamá-lo de metamodelo. É o seguinte:

    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.