A hierarquia das necessidades de Maslow e a modelagem do software ou “O teste do trabuco”

Em 1943, o professor Abraham Maslow publicou seu trabalho chamado “A theory of human motivation”.

200px-abraham_maslow

O trabalho, o qual eu considero genial dentro das limitações dos meus conhecimentos em psicologia, divide as necessidades humanas em cinco categorias: fisiologia, segurança, amor/relacionamento, estima e realização pessoal e propõe a existência de uma hierarquia entre essas categorias, ou seja, um ser humano não consegue satisfazer uma categoria de necessidades sem ter satisfeita a categoria logo abaixo no desenho.

Claro que a hierarquia serve como um modelo, uma idéia geral do funcionamento do comportamento humano, ideal para os oceanos de um palmo de profundidade* como eu.

Ficheiro:Hierarquia das necessidades de Maslow.svg

 

Hum… psicologia… @oclaudiobr vai escrever sobre gerenciamento de equipes, ou melhor, desenvolvimento de equipes, motivação, yada yada yada, como diz o Google. Não, meu post não tem nada a ver com isso, quero falar de modelagem.

Vamos a uma pequena fábula que chamo de “teste do trabuco”:

Imagine um sistema feito com uma interface horrível, mal pensada, que é muito lento e vive saindo do ar (difícil pensar em apenas um não é?). Você provavelmente não usaria esse sistema, se negaria, reclamaria com o chefe e até mesmo pensaria em sair da empresa.

Agora pense no mesmo sistema, só que agora tem alguém apontando um trabuco na sua direção e dizendo “cadastra um usuário senão eu atiro”. Vai ser ruim, mas se os requisitos funcionais estiverem corretos, você vai dar um jeito.

Agora pense em algo pior, além de tudo isso, o sistema teve seus requisitos funcionais mal pensados. Para executar uma tarefa que lhe traria valor, você precisa acessar diversas funcionalidades, fazer cadastros redundantes e por aí vai. Algumas funcionalidades necessárias nem existem. Você pensa em demissão novamente não? Aí o sujeito do trabuco aparece novamente dizendo “gera um relatório de vendas semestral quebrado por filial senão eu atiro”. Você respira fundo, lembra que as regras de negócio estão ok, que “vendas”, “filiais” (entidades) e “datas” e “valores” (atributos) estão dentro do sistema, psicografa uma query e produz o tal relatório.

Ok, agora pense em algo pior (está parecendo “Josef Climber”), além de tudo, as regras de negócio não estão legais. Parece que o sistema pertencia a outra empresa e foi comprado sem adaptações. O sujeito do trabuco aparece, e solicita seja o que for. A sua única ação é implorar “na cara não doutor, na cara não”. Não há o que fazer, você fecha os olhos aceitando seu destino cruel. Felizmente o sujeito mira e atira no sistema matando o desgraçado imediatamente.

Essa fábula serve para mostrar como a hierarquia do Maslow funciona no nosso dia a dia. Quando alguém aponta um trabuco na nossa direção, temos nossa necessidade de segurança ameaçada e quando isso acontece, dane-se o “amor/relacionamento”, a “estima” e a “realização pessoal”. Você faz tudo para retomar a segurança.

A história envolve TI porque acredito que a hierarquia das necessidades também se aplica à modelagem de sistemas.

Apenas para relembrar, para quê modelamos? Modelamos primeiro para aprender, depois para comunicar e depois para, quem sabe, documentar.

Existe mesmo uma hierarquia na modelagem? A princípio não, pois quando modelamos para aprender estamos explorando e artefatos e abordagens alternativas são bem-vindos, é hora de sair rabiscando, contudo, para considerar um modelo como “pronto”, prego que a seguinte hierarquia seja respeitada:

 

Hierarquia_software

 

·         Regras de negócio: As regras de negócio nos mostram como o negócio é. Infelizmente a maior parte das pessoas vê as regras de negócio como aquelas declarações enfadonhas em texto**, contudo, 85% das regras de negócio se encontram em um diagrama de classes de alto nível, ou seja, um diagrama que mostre os relacionamentos entre as entidades do negócio. Outro diagrama excelente para apresentar regras de negócio é o diagrama de máquina de estados. Me assusta muito analistas de negócios que vêem esses artefatos como ferramentas da análise de sistemas. O que define o que vai nesses diagramas é o negócio.

·         Requisitos funcionais: Os requisitos funcionais expressam os objetivos que o usuário alcança através do sistema que trazem valor perceptível para o negócio. É normal a conversa começar pelos requisitos funcionais, contudo, o que vai balizar o seu funcionamento são as regras de negócio.

·         Requisitos não-funcionais: Os requisitos não-funcionais podem ser expressos como requisitos de qualidade, ou seja, não estão ligados ao quê o usuário pode fazer através do sistema, mas sim, em como isso se dá. Aqui temos de tudo, desde tempo de resposta, capacidade de processamento, acessos simultâneos, mas deixo em evidência nesta pirâmide a interface do usuário que se expressa em termos de usabilidade.

·         “?”: Aqui deixo aberto para você colocar o que quiser. Seria o equivalente a realização pessoal da pirâmide do Maslow.

 

O que justifica a hierarquia no meu ponto de vista é o fato de que, se algo é alterado no nível mais baixo da pirâmide, fatalmente teremos alterações nos níveis acima.

 

Pense comigo, se houver uma mudança nas regras de negócio como, por exemplo, um cliente do banco poder ter N contas e não apenas uma, haverá, com certeza mudanças nos requisitos funcionais, o cliente poderá, por exemplo, ver um saldo consolidado das contas, algo que antes não existia, e evidentemente, haverá mudanças nos requisitos não-funcionais, mesmo que sejam alterações na interface atual.

O nível de baixo é sempre alicerce para os níveis de cima.

Isso quer dizer que precisamos conhecer TODAS as regras de negócio antes de partir para os requisitos funcionais? Não, não confunda a hierarquia com o BDUF (big design up-front). Precisamos conhecer TODAS as regras de negócio envolvidas com o requisito funcional no qual estamos trabalhando. É por isso que meus casos de uso são SEMPRE acompanhados de um diagrama de classes que apresenta as entidades envolvidas no caso de uso, seus relacionamentos e atributos.

E a interface do usuário, e a usabilidade? O objetivo do usuário, representado pelo requisito funcional é entrada, insumo do trabalho de um responsável pela usabilidade. Se falarmos em usabilidade sem saber o que o usuário precisa/quer fazer, estaremos apenas divagando.

Pensando em concorrência, eu poderia dizer que:

  •  Empresas medíocres entregam sistemas que atendem as regras de negócio.
  •  Empresas razoáveis entregam sistemas que atendem os requisitos funcionais.
  •  Empresas boas entregam sistemas que atendem também os requisitos não-funcionais.
  •  Empresas medonhas que não mereciam ter nascido focam em atender a um nível sem ter atendido os níveis inferiores.

 

E aí, o que você acha disso? Comentários, por favor!

     

     

    * Algo que acho interessante no curso de Administração de Empresas é a criação de Extreme Generalists, representada pela expressão “oceano de conhecimento de um palmo de profundidade”. Vemos de tudo, de psicologia ao mercado de ações (e fazemos teorias envolvendo os dois).

    ** Aliás, prego que uma forma boa de avaliar a qualidade de uma regra de negócio expressada em texto. Verifique quantos verbos estão no texto. Se houver mais de dois, cuidado, talvez você esteja disfarçando um requisito funcional de regra de negócio.

    *** Imagens roubadas da Wikipedia, claro.

     

    14 ideias sobre “A hierarquia das necessidades de Maslow e a modelagem do software ou “O teste do trabuco”

    1. Claudio, ótimo texto e excelente comparação com o mundo de desenvolvimento de software.Concordo 100%, principalmente com a parte da diferença entra empresas mediocres, razoaveis, boas e medonhas. heheheAbs,

    2. Oi Kerber!Na sua metáfora, o sujeito que trabalhava com aquele software nada funcional estava preocupado primeiramentecom a sobrevivência em comprar o santo pão de cada dia. Vemos tantos empregados reclamando de ERPs ou sistemas em geral. Depois o trabuco apontado na cara é para segurança com certeza – hehehNessa vida de analista existe um ponto interessante que é decidir pelo que realmente é fundamental e agrega valor ao negocio (20 – 80 de Paretto), mas muitas vezes conciliar com o cliente "spoilt" que não esta com enfoque na base e só enxerga o topo da pirâmide. Outro ponto que detone a qualidade como você comentou é o desconhecimento das regras de negocio na manutenção ou continuidade do sistema… Remendos e mudança de tecnologia no projeto podem por um sistema a se perder.

    3. @Thiago, obrigado amigo! Interessante que só no finalzinho mesmo que veio a ideia de comparar as empresas. Vejo no mercado que só as melhores conseguem se garantir em relação às regras de negócio e requisitos funcionais ao ponto de poderem investir de fato nos requisitos não-funcionais.

    4. Olá Kerber,Pode ser perigoso a interpretação que essa pirâmide pode gerar. Por exemplo, imagine que as regras de negócio são consideradas como sempre as mais importantes. Numa eventual discussão de uma RN com um Requisito Não-funcional, poderíamos prejudicar o atendimento dessa última. E há casos em que um requisito não-funcional é tão importante quanto o atendimento de uma regra de negócio. Exemplo, imagine que um requisito não-funcional do Cuil (http://en.wikipedia.org/wiki/Cuil) fosse ser tão rápido quanto o buscador da Google. O não atendimento dessa poderia inviabilizar o negócio.De toda forma, é certo que essa sua proposta auxilia. É como se fosse uma âncora. Afinal, ele aponta para o que REALMENTE importa.[]sShigueru.

    5. Oi Shigueru!Eu continuo pregando que a pirâmite é válida, mesmo no caso do Cuil. O que ocorre é que você pegou um exemplo no qual as regras de negócio (a definição do que é um site, o que é conteúdo, que um link, um usuário, uma visita e por aí vai) estão muito claras em relação a dificuldade que existe na parte não-funcionail.Até mesmo os requisitos funcionais estão claros (questão dos thumbnaiils e tal).Como você sente segurança em relação às regras de negócio, se sente confortável para jogar toda a sua energia sobre os requisitos não-funcionais.Agora pense, do que adianta uma arquitetura bem montada, milhares ou milhões de servidores trabalhando em grid se existir um erro de concepção em relação a o que é um site, o que é uma página, um link, ou qualquer outra entidade do negócio? Um desastre.Nesse caso, mesmo tendo como meta ser um buscador tão rápido quanto o Goggle, o Cuil primeiro precisa ser um buscador. Em uma apresentação para um cliente, seria melhor (menos pior) conseguir fazer uma busca correta no dobro do tempo do que o google faz do que ser tão rápido quanto o google e não entregar o que se espera de um buscador.É claro que os requisitos não-funcionais são foco dessa turma, mas apenas pelo fato de que a base da pirâmide já está satisfeita. Se você remover algum tijolo dessa base, todo o trabalho de cima precisa ser revisto.

    6. Kerber,"Nesse caso, mesmo tendo como meta ser um buscador tão rápido quanto o Goggle, o Cuil primeiro precisa ser um buscador. "Sem dúvida. Por isso disse "tão importante quanto" e não "mais importante que". O alerta é apenas para que não ocorra algo similiar ao abaixo:"..temos nossa necessidade de segurança ameaçada e quando isso acontece, dane-se o “amor/relacionamento”, a “estima” e a “realização pessoal”. Você faz tudo para retomar a segurança."Há casos em que mesmo tendo todas as regras de negócios atendidas, um índice de disponibilidade longe da meta, invibializa o Negócio. Logo não seria possível dizer um "dane-se" qualquer apenas para atender uma regra. Ela deveria ser atendida juntamente com o requisito não-funcional. Certo?Agora, poderíamos chamar a base da pirâmide de Requisitos do Usuário ao invés de Regras de Negócio?[]Shigueru.

    7. oi Shigueru! A hierarquia não implica uma coisa ser mais importante do que a outra, apenas que você não consegue suprir a de cima sem suprir a de baixo.Veja que quando falo em regras de negócio, estou falando em coisas como como são e como se comportam as entidades do negócio. Se houver um erro aqui, os requisitos funcionais não farão sentido e os não-funcionais também.É aí que entra o teste do trabuco, se um sistema tiver requisitos não-funcionais pobres, você, com esforço, consegue fazer o que precisa. Se ele tiver problemas nos requisitos funcionais, você até pode fazer o que precisa sei lá, acessando o banco e fazendo alterações direto nele. Agora, se até o banco (que em última instância seria a maior representação das regras de negócio que temos) não estiver ok, não tem como.Ahh, e com falta de segurança você manda o resto para o espaço sim. Se eu aparecer aí na sua sala com um trabuco apontado para você, tenho certeza que você vai concordar rapidinho com meus argumentos para preservar a sua, mesmo que isso vá contra necessidades de níveis mais altos :)

    8. Kerber,Mais claro agora."Ahh, e com falta de segurança você manda o resto para o espaço sim. Se eu aparecer aí na sua sala com um trabuco apontado para você, tenho certeza que você vai concordar rapidinho com meus argumentos para preservar a sua, mesmo que isso vá contra necessidades de níveis mais altos :)"Sim, esse o é o mundo real. Apesar que as vezes o trabuco é igual arma de palhaço, e o costume, o automático, faz as pessoas agirem sem questionar o mínimo.Obrigado,Shigueru.

    9. Gostei do artigo, Kerber. Mas uma vez vc me surpreende com as suas analogias… :-)Vc tocou num ponto importante e muitas vezes ignorado por analistas de negócios. Muitas regras de negócio são relacionadas às entidades e, portanto, são implementadas no banco de dados. Nós ANs deveríamos desenhar diagramas de entidade-relacionamento com termos do negócio pra documentar essas regras como parte dos requisitos.Sua analogia com a pirâmide de Maslow que lembrou de outra coisa… Muitas vezes reclamamos que o usuário nunca está satisfeito. Entregamos uma coisa e ele(a) logo quer outra. É a pirâmide de novo. Quando satisfazemos as necessidades mais fundamentais, ele(a) pode começar a pensar em outras, acessórias. Ele nunca vai parar de pedir. Nunca vai dizer: "todas as minhas necessidades estão plenamente satisfeitas e eu não preciso de nada."

    10. Obrigado Suzandeise. É isso mesmo, as entidades não tem o nome de "entidades de negócio" por acaso. E se elas são do negócio, são da nossa conta.Em relação ao diagrama utilizado, eu prefiro me expressar usando o diagrama de classes, uma vez que ele permite que eu utilize alguns conceitos da orientação a objetos que facilitam a comunicação com as partes interessadas do negócio (como especializações) e também a implementação por parte dos desenvolvedores, já que tudo (quase tudo) hoje é desenvolvido nesse paradigma.Sobre a satisfação do cliente, tem tudo a ver mesmo. Um cliente nunca vai dizer que está plenamente satisfeito e mesmo se fosse um dia, esse dia estaria longe. Não porque ele pede demais, é que nós entregamos pouco mesmo. Raras são as empresas que já estão competindo no nível dos requisitos não-funcionais, principalmente naqueles que eu foco no post, os referentes à usabilidade.

    Deixe uma resposta

    O seu endereço de email não será publicado Campos obrigatórios são marcados *

    Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    Current day month ye@r *