Se você não é da área de informática, provavelmente não sabe o que significa UML.
UML é uma sigla para "Unified Modeling Language", ou em português “Linguagem de Modelagem Unificada”. É uma linguagem padrão de diagramas e documentação que lhe permite especificar sistemas de uma forma coesa e compreensível a todos os envolvidos no projeto, sejam ele computacionais ou não. Mas eu duvido muito que alguém use isso para qualquer coisa não computacional, e você vai entender o porque mais diante.
Antes de começar, quero falar que sou usuário da linguagem UML há cerca de 6 anos, então não sou nenhum recém-formado na faculdade que está revoltado com uma coisa sem tê-la experimentado bastante. Eu uso UML quase todo dia.
O fato é que a UML é vendida como a salvação da lavoura, o método definitivo para fazer a especificação de sistemas e soluções, e que é perfeito para esta missão. Há ai um enorme engano. A UML funciona muito bem para quem a conhece bem, ou seja, para o pessoal técnico, para os programadores, para nós, analistas de sistemas, arquitetos de solução, engenheiros de software, etc.
Para o usuário final, ou seja, para a pessoa mais importante de todas na cadeia de construção de sistemas, aquela que demanda o serviço, que origina a demanda e para quem o sistema é feito, a UML não significa absolutamente nada! Não importa se você usa Rational Rose, Jude, Argo, papel de pão ou qualquer outra ferramenta representativa. O problema é conceitual e não de execução.
Se você trabalha em uma fábrica de software com conceitos de produto (como a Microsoft, Oracle, Sun, etc) você não precisa se preocupar com esse artigo, porque você trabalha em um universo totalmente diferente. Você não faz software sob encomenda, você faz prospecção de mercado e implementa ferramentas com soluções amplas que atendam a aquela demanda de maneira bem abrangente. Você domina um nicho de mercado, você atua em uma área de negócio bem específica a qual destrincha dia após dia, e evolui com ela, aprendendo e reutilizando conhecimento adquirido para tal.
Mas para pessoas como eu, que trabalham apenas com software sob encomenda, atacando nichos diferentes todos os dias, sem tempo de se especializar em um único ramo de negócio, fica aqui minha opinião: estou convencido de que a UML mais atrapalha do que ajuda quanto ao relacionamento que você tem com seu cliente.
Cito alguns casos pelos quais infelizmente passei. Meus clientes simplesmente não entendem a especificação do sistema, por mais claros que estejam os diagramas de casos de uso e suas descrições, por mais lógicos que sejam os diagramas de seqüência e de atividades, por mais elaborados e detalhados que estejam os diagramas de classe (que nem deve ser mostrado ao usuário sob pena de ouvir coisas como "não faço a menor idéia do que isso representa").
Você não pode se apoiar na UML para validar sua especificação com o cliente porque ele até vai lhe dizer que entendeu, mas no fundo, não entendeu nada, e na hora de validar o sistema de fato os problemas vão começar a aparecer e você terá muitas dores de cabeça para solucionar cada ponto, porque a especificação terá sido aprovada sem de fato o cliente se dar conta de que ali haviam regras de negócio e fluxos de trabalho completamente fora da realidade que ele havia imaginado.
Você pode falar que seu usuário é burro por causa disso? De forma alguma! Existe uma tendência dos especialistas em achar que os usuários são ignorantes, burros ou mal intencionados, quando na verdade tudo o que eles querem é uma solução para alguma situação crítica em seu cotidiano, e são então bombardeados com especificaçõs que não entendem. O que acontece é que eles simplesmente não pensam como nós. Se pensassem, não precisariam de analistas e programadores, porque eles mesmos resolveriam seus problemas.
Diante disso fica um impasse, cuja solução é bastante simples, porém de complexa execução: é preciso que o usuário, o seu cliente, entenda o que está sendo proposto em termos de solução de uma maneira muito mais clara do que a UML jamais poderá expor. Como fazê-lo entender então?
Muitos usuários (99,9%) só conseguem entender o que você havia especificado quando a solução está de fato pronta. Ou seja, quando eles vêem a tela, quando clicam nos botões, quando vêem a navegabilidade, quando acessam o dito cujo é que conseguem entender. Ou seja: os usuários em sua grande maioria não consegue visualizar algo tão abstrato quanto um software enquanto ele não existe!
Os profissionais de informática são formados para pensar em coisas extremamente abstratas e concebê-las no reino da abstração, então para nós esta tarefa é tão natural que achamos que isso faz parte da própria capacidade humana de pensar. Mas não é. E está mais do que na hora de se assumir isso.
Isso não faz de nós melhores do que qualquer outro ser humano, apenas somos mais especializados em uma atividade a mais neste mundo, assim como existem muitos profissionais especializados em coisas das quais nem sabemos, mas que precisamos. O que temos que saber é como traduzir estes conceitos abstratos para uma linguagem que as pessoas comuns possam entender claramente. E esta linguagem com toda certeza não é a UML, pelo menos não sozinha.
A UML nasceu do conceito de orientação a objetos, que por sua vez bate no peito e proclama ser a mais natural das formas de representação da realidade porque vê as coisas como objetos reais, com formas, atributos e capacidades. Isso é válido. Mas eles se esquecem que a mente humana pensa não orientada a objetos, com classes e métodos que podem ser acionadas em qualquer instante do tempo, mas sim de forma estruturada temporal. A orientação a objetos tem seu conjunto de diagramas seqüenciais, mas estes são abstratos demais para que os usuários os entendam claramente.
Vivemos em um universo temporal. Isso significa que a natureza dotou nossos cérebros de uma percepção temporal, ou seja, com o tempo andando em uma só direção, e com todos os eventos que vivenciamos tendo começo, meio e fim, com eventos podendo ocorrer em paralelo (eu posso estar indo para o trabalho ao mesmo tempo em que escuto música por exemplo). Volto a falar que a UML e a orientação a objetos podem representar isso claramente para pessoas nelas muito bem treinadas, mas não a pessoas comuns, não aos usuários. Eles precisam de algo mais natural e palpável para entender uma proposta de solução, uma especificação de requisitos, uma modelagem de um sistema.
O que os usuários precisam é de protótipos funcionais. Telas navegáveis e com um grau mínimo de exemplificação de regras de negócio e sequenciamento, simulando como o sistema se comportará quando constituído.
Mas protótipos funcionais tem um grave problema: demoram para serem feitos, portanto são caros, e são vistos por muitas empresas de software como um artefato arriscado em termos comerciais, pois ele ocorreria em um momento de fragilidade aonde o usuário ainda não tem nenhum compromisso em contratar seus serviços: no levantamento inicial.
Muitas empresas fazem protótipos apenas após o contrato assinado, na fase de detalhamento e especificação, mas fazer um protótipo neste momento pode muito bem demonstrar que o levantamento inicial ocorreu de maneira muito rasa, de forma que ocorre a partir desta prototipação uma alteração de escopo de projeto, exigindo adendos de contrato e revisão de valores e cronogramas, em uma fase de renegociação que muitas vezes é estressante para todos, e que não raras vezes acaba com a dissolução do negócio e a frustração de ambas as partes. E isso é péssimo.
O ideal em termos técnicos é que a prototipação seja feita antes da especificação, ou seja, que faça parte do levantamento de requisitos e sirva como delimitador do que será feito dentro da proposta apresentada em todo o decorrer do projeto se ele vier a ser aprovado.
Isso só seria possível se o levantamento inicial deixasse de ser “sem compromisso”, e passasse a ter um valor-hora cobrado, bem abaixo do valor-hora das fases de especificação e codificação. Um valor-hora "de custo", que zere prejuízos mas que não vise lucro, afinal o lucro só deve ser planejado sob projetos contratados, e o levantamento inicial não é um projeto por si só, mas sim um gerador deste.
Minha conclusão é a de que a UML é insuficiente para validações com clientes. Ela se apresenta como uma ótima ferramenta de especificação equipe-equipe, mas não é uma boa solução equipe-cliente. Na verdade a prototipação funcional é uma ferramenta tão clara para o cliente que deve ser fortemente considerada a ser utilizada como ferramenta de levantamento inicial.
Os custos do uso da prototipação funcional podem ser altos e aumentar o valor do projeto no seu começo. Mas o ganho que ela dará ao seu projeto evitando replanejamentos, correções e ajustes futuros por causa de lacunas no levantamento inicial e na especificação darão um ganho considerável a ele em sua finalização, acabando por proporcionar um ganho e não uma perda em seus custos de desenvolvimento.
UML é uma sigla para "Unified Modeling Language", ou em português “Linguagem de Modelagem Unificada”. É uma linguagem padrão de diagramas e documentação que lhe permite especificar sistemas de uma forma coesa e compreensível a todos os envolvidos no projeto, sejam ele computacionais ou não. Mas eu duvido muito que alguém use isso para qualquer coisa não computacional, e você vai entender o porque mais diante.
Antes de começar, quero falar que sou usuário da linguagem UML há cerca de 6 anos, então não sou nenhum recém-formado na faculdade que está revoltado com uma coisa sem tê-la experimentado bastante. Eu uso UML quase todo dia.
O fato é que a UML é vendida como a salvação da lavoura, o método definitivo para fazer a especificação de sistemas e soluções, e que é perfeito para esta missão. Há ai um enorme engano. A UML funciona muito bem para quem a conhece bem, ou seja, para o pessoal técnico, para os programadores, para nós, analistas de sistemas, arquitetos de solução, engenheiros de software, etc.
Para o usuário final, ou seja, para a pessoa mais importante de todas na cadeia de construção de sistemas, aquela que demanda o serviço, que origina a demanda e para quem o sistema é feito, a UML não significa absolutamente nada! Não importa se você usa Rational Rose, Jude, Argo, papel de pão ou qualquer outra ferramenta representativa. O problema é conceitual e não de execução.
Se você trabalha em uma fábrica de software com conceitos de produto (como a Microsoft, Oracle, Sun, etc) você não precisa se preocupar com esse artigo, porque você trabalha em um universo totalmente diferente. Você não faz software sob encomenda, você faz prospecção de mercado e implementa ferramentas com soluções amplas que atendam a aquela demanda de maneira bem abrangente. Você domina um nicho de mercado, você atua em uma área de negócio bem específica a qual destrincha dia após dia, e evolui com ela, aprendendo e reutilizando conhecimento adquirido para tal.
Mas para pessoas como eu, que trabalham apenas com software sob encomenda, atacando nichos diferentes todos os dias, sem tempo de se especializar em um único ramo de negócio, fica aqui minha opinião: estou convencido de que a UML mais atrapalha do que ajuda quanto ao relacionamento que você tem com seu cliente.
Cito alguns casos pelos quais infelizmente passei. Meus clientes simplesmente não entendem a especificação do sistema, por mais claros que estejam os diagramas de casos de uso e suas descrições, por mais lógicos que sejam os diagramas de seqüência e de atividades, por mais elaborados e detalhados que estejam os diagramas de classe (que nem deve ser mostrado ao usuário sob pena de ouvir coisas como "não faço a menor idéia do que isso representa").
Você não pode se apoiar na UML para validar sua especificação com o cliente porque ele até vai lhe dizer que entendeu, mas no fundo, não entendeu nada, e na hora de validar o sistema de fato os problemas vão começar a aparecer e você terá muitas dores de cabeça para solucionar cada ponto, porque a especificação terá sido aprovada sem de fato o cliente se dar conta de que ali haviam regras de negócio e fluxos de trabalho completamente fora da realidade que ele havia imaginado.
Você pode falar que seu usuário é burro por causa disso? De forma alguma! Existe uma tendência dos especialistas em achar que os usuários são ignorantes, burros ou mal intencionados, quando na verdade tudo o que eles querem é uma solução para alguma situação crítica em seu cotidiano, e são então bombardeados com especificaçõs que não entendem. O que acontece é que eles simplesmente não pensam como nós. Se pensassem, não precisariam de analistas e programadores, porque eles mesmos resolveriam seus problemas.
Diante disso fica um impasse, cuja solução é bastante simples, porém de complexa execução: é preciso que o usuário, o seu cliente, entenda o que está sendo proposto em termos de solução de uma maneira muito mais clara do que a UML jamais poderá expor. Como fazê-lo entender então?
Muitos usuários (99,9%) só conseguem entender o que você havia especificado quando a solução está de fato pronta. Ou seja, quando eles vêem a tela, quando clicam nos botões, quando vêem a navegabilidade, quando acessam o dito cujo é que conseguem entender. Ou seja: os usuários em sua grande maioria não consegue visualizar algo tão abstrato quanto um software enquanto ele não existe!
Os profissionais de informática são formados para pensar em coisas extremamente abstratas e concebê-las no reino da abstração, então para nós esta tarefa é tão natural que achamos que isso faz parte da própria capacidade humana de pensar. Mas não é. E está mais do que na hora de se assumir isso.
Isso não faz de nós melhores do que qualquer outro ser humano, apenas somos mais especializados em uma atividade a mais neste mundo, assim como existem muitos profissionais especializados em coisas das quais nem sabemos, mas que precisamos. O que temos que saber é como traduzir estes conceitos abstratos para uma linguagem que as pessoas comuns possam entender claramente. E esta linguagem com toda certeza não é a UML, pelo menos não sozinha.
A UML nasceu do conceito de orientação a objetos, que por sua vez bate no peito e proclama ser a mais natural das formas de representação da realidade porque vê as coisas como objetos reais, com formas, atributos e capacidades. Isso é válido. Mas eles se esquecem que a mente humana pensa não orientada a objetos, com classes e métodos que podem ser acionadas em qualquer instante do tempo, mas sim de forma estruturada temporal. A orientação a objetos tem seu conjunto de diagramas seqüenciais, mas estes são abstratos demais para que os usuários os entendam claramente.
Vivemos em um universo temporal. Isso significa que a natureza dotou nossos cérebros de uma percepção temporal, ou seja, com o tempo andando em uma só direção, e com todos os eventos que vivenciamos tendo começo, meio e fim, com eventos podendo ocorrer em paralelo (eu posso estar indo para o trabalho ao mesmo tempo em que escuto música por exemplo). Volto a falar que a UML e a orientação a objetos podem representar isso claramente para pessoas nelas muito bem treinadas, mas não a pessoas comuns, não aos usuários. Eles precisam de algo mais natural e palpável para entender uma proposta de solução, uma especificação de requisitos, uma modelagem de um sistema.
O que os usuários precisam é de protótipos funcionais. Telas navegáveis e com um grau mínimo de exemplificação de regras de negócio e sequenciamento, simulando como o sistema se comportará quando constituído.
Mas protótipos funcionais tem um grave problema: demoram para serem feitos, portanto são caros, e são vistos por muitas empresas de software como um artefato arriscado em termos comerciais, pois ele ocorreria em um momento de fragilidade aonde o usuário ainda não tem nenhum compromisso em contratar seus serviços: no levantamento inicial.
Muitas empresas fazem protótipos apenas após o contrato assinado, na fase de detalhamento e especificação, mas fazer um protótipo neste momento pode muito bem demonstrar que o levantamento inicial ocorreu de maneira muito rasa, de forma que ocorre a partir desta prototipação uma alteração de escopo de projeto, exigindo adendos de contrato e revisão de valores e cronogramas, em uma fase de renegociação que muitas vezes é estressante para todos, e que não raras vezes acaba com a dissolução do negócio e a frustração de ambas as partes. E isso é péssimo.
O ideal em termos técnicos é que a prototipação seja feita antes da especificação, ou seja, que faça parte do levantamento de requisitos e sirva como delimitador do que será feito dentro da proposta apresentada em todo o decorrer do projeto se ele vier a ser aprovado.
Isso só seria possível se o levantamento inicial deixasse de ser “sem compromisso”, e passasse a ter um valor-hora cobrado, bem abaixo do valor-hora das fases de especificação e codificação. Um valor-hora "de custo", que zere prejuízos mas que não vise lucro, afinal o lucro só deve ser planejado sob projetos contratados, e o levantamento inicial não é um projeto por si só, mas sim um gerador deste.
Minha conclusão é a de que a UML é insuficiente para validações com clientes. Ela se apresenta como uma ótima ferramenta de especificação equipe-equipe, mas não é uma boa solução equipe-cliente. Na verdade a prototipação funcional é uma ferramenta tão clara para o cliente que deve ser fortemente considerada a ser utilizada como ferramenta de levantamento inicial.
Os custos do uso da prototipação funcional podem ser altos e aumentar o valor do projeto no seu começo. Mas o ganho que ela dará ao seu projeto evitando replanejamentos, correções e ajustes futuros por causa de lacunas no levantamento inicial e na especificação darão um ganho considerável a ele em sua finalização, acabando por proporcionar um ganho e não uma perda em seus custos de desenvolvimento.
0 comentários:
Postar um comentário