exemplo da vida real: você está em uma reunião de análise com um médico, e ele diz: "Eu gostaria de registrar minha opinião inicial sobre o paciente". Você pega a sua nota, copia no seu caderno, ou talvez você gravá-lo sob a forma de um método formal como um simples diagrama de casos de uso. Você assume que uma caixa de texto na tela é o suficiente para isso. Tudo o que o médico tem que fazer é digitar seus pensamentos, e está feito. Então, você vai para o escritório pra transformar esse requisito em código. Baseado no seu mpetodo de programar, você pode criar classes e desenvolver uma tabela de banco de dados, onde uma simples coluna vai conter toda a informação que ele registrar em texto. Então você tem que codificar as informações de interface de uso, colocar em sua instância de classe, e salvá-lo ao banco de dados quando necessário. Ou se você está seguindo DB, você pode criar uma tabela de banco de dados e em seguida, escrever as classes que irão ler e gravar informações em banco de dados, e no fim desenvolver a tela que irá apresentar e coletar dados. Você pode pensar que algumas das abordagens do tipo DB são muito velhas, e "ninguém faz mais isso". Bem, não é. Há ainda milhares de desenvolvedores que usam esses métodos, e todos esses desenvolvedores se sentem mais ou menos da mesma forma, quando ocorre o seguinte:
Depois de passar horas para escrever o código, projetar a interface de banco de dados e de usuário, testando-o etc, você organiza uma outra reunião com seus clientes, e o médico que lhe deu o requisito original para gravar suas opiniões olha para o software que você desenvolveu e sacode a cabeça: não foi isso que pedi". Você, com a obrigação de ser educado, pergunta, "desculpe?". O médico explica que preferiria ter uma lista de itens na tela, cada um representando um parecer, para que ele possa lê-los melhor, e ainda mais, ele quer usar um sistema de código de seleção de determinadas opiniões, ou para ser mais exato seus diagnósticos, tais como a CID, CIAPE ou SNOMED CT. Desde que ele não mencionou nenhum desses na primeira reunião, você diz que ele apenas disse que gostaria de registrar suas opiniões, e você fez o que queria. Tudo o que ele faz é dar de ombros. "Isto é o que eu quis dizer, eu pensei que você entenderia"
Então horas de trabalho foram por água abaixo. Você sabe que nada do que você fez vai poder ser aproveitado. Uma vez que existem vários itens que você precisa mostrar em uma lista, seu projeto db é bastante irrelevante agora. Você tem de introduzir uma nova tabela para fins de normalização do banco de dados quevão carregar as IDS da condição selecionada. A classe que costumava ter um apenas um campo String agora tem que ter uma coleção de strings. Espere, nós não falamos sobre os requisitos de codificação! O usuário quer usar algum padrão de codificação!!!
Então você volta ao trabalho, e seguindo a mesma abordagem, antes, fazer a coisa toda. Para a codificação, você coloca um botão no formulário, e quando o usuário clica no botão, uma nova caixa de diálogo é exibida onde existe um controle de árvore, que inclui códigos hierárquicos de condições. Você usa uma tabela do banco de dados previamente definida, criado por outro programador. Você escreve um widget inteligente que acessa o db como nós da árvore são expandidos e os nós filhos são adicionados dinamicamente. Você pode testar o aplicativo, adicionar um par de condições e ele funciona. Você está pronto para a próxima reunião neste momento. Você chama o medico para mostrar seu trabalho, está feito agora, certo?
Você pode executar a demonstração para o cliente, e pedir-lhe para testá-lo. Ele abre o diálogo para selecionar as condições, e começa a navegar na árvore. Ele começa a procurar por uma condição, e sua viagem através da árvore parece nunca ter fim! Após a expansão sobre uma dúzia de nós, ele descobre que ele quer, e clica nele. Em seguida, vem o próximo, que não é fácil de alcançar. Após três diagnósticos que ele vira para você e diz: "Desculpe, não podemos usar isso". Você encontrará sua mão tremendo um pouco, mas ainda consegue perguntar "porquê?".
Ele diz que seria impossível usar isso durante o horário de trabalho, onde pacientes aguardam na fila, e ele tem quase nenhum tempo. Além disso, ele quer saber se ele pode adicionar os seus próprios códigos para a lista. Você pede a ele que tipo de interface do usuário que ele gosta, então? E ele diz: "Eu não sei, algo mais fácil de usar".
Qualquer desenvolvedor que tenha feito mais de um ano de desenvolvimento em um campo semelhante sabe do que estou falando. Isso é desenvolvimento de software. No primeiro caso, você entendeu mal o requisito, e seu trabalho se foi, o dinheiro da sua empresa se foi também, desde aquelas horas que você trabalhou naõ vão ser pagas, pois nada de utilizável foi produzido. No segundo caso, você tentendeu corretamente o requisito, mas, desta vez, devido à natureza e estrutura de dados de domínio (os códigos), você enfrentou uma barreira de usabilidade, um requisito não-funcional não foi atendido (o sistema deve ser fácil de usar) .
--
Jussara Rötzsch
Você tocou em um ponto super interessante, Jussara.
A bastante tempo venho defendendo que qualquer sistema de informação, seja de qualquer origem de negócio, tem ter a capacidade de adaptar a cultura das pessoas de quem a utilizam, isto significa saida (ou 'telas') customisaveis ao gosto de cada organização.
Sei que todos defendem a Organização de Processos bem definidos como o Dr.Marivan bem os colocou, mas prefiro pensar de maneira diferente:
Para realizar análises adequadas eu preciso dos 'dados' gerados por qualquer processo. Este dado tem que estar bom.
Exemplificando de maneira bem vulgar se preciso analisar a variável x, preciso dos dados b, d e f.
A maneira que estes dados são inputados, ou o processo que ele foi inputado no sistema pouco me importa para o objetivo final. Se o cliente quer digitar d, b e f para mim é suficiente. Se quer o botão rosa ao invés de cinza também o faço.
Estou descartando processos? De maneira nenhuma! O que faço: Isolo toda a minha inteligência em um aplicativo base e vou criando varias visualizações que são responsáveis por capturar e armazenar estes dados. Eu não pretendo mudar a cultura do meu cliente, eu quero adaptar meu software a cultura dele, aos processos dele, ao 'caos' dele, mas no final das contas tenho os mesmos dados e posso realizar o objetivo do software e da análise.
Com o tempo vamos apresentando novos prismas para este consumidor e assim pouco a pouco ele vai aceitando que precisa mudar, o ponto é não forçar ninguém a nada, realizar somente o mínimo necessário para se atingir o objetivo. O ponto é mostrar para o cliente que ele tem disponível o filé, mas se tem preferência por ossos a coisa não vai desandar por causa disto.
Custos? Customização é algo que se vende mais fácil do que o próprio produto, o ponto é seu sistema estar preparado para que esta customização não seja cara demais.
Bom dia!
Marcus Alexandre
Tecnologia da Informação
EPRIMECARE - Gestão de Cuidados em Saúde S.A
+55 (31) 2519-4800 / 3275-4140
AVISO LEGAL:Essa mensagem é destinada exclusivamente para as pessoas a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada.Se você não for destinatário dessa mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma utilizar a informação contida nessa mensagem, por ser ilegal.Caso você tenha recebido essa mensagem por engano, pedimos que nos retorne este E-mail, promovendo desde logo a eliminação do seu conteúdo em sua base de dados, registro ou sistema de controle.
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!
Em 27 de janeiro de 2011 09:55, Jussara Rotzsch <jussara.macedo@gmail.com> escreveu:Vocês esqueceram de dois aspectos importantes: a usabilidade e utilidade. As interfaces pouco amigáveis e a falta de beneficios para quem coleta a informação são obstáculos a uma boa informatização. Tem que se investir mais nisso, em interfaces amigáveis e em serviços para os profissionais. No primeiro caso investir mais em plataformas de interoperabilidade, pois muitos medicos ja têm seu prontuário no consultório, de modo que eles possam sincronizar seus registros.
jussara2011/1/27 Rosane Gotardo <rosane.gotardo@gmail.com>Caro Dr. Marivan, você acertou o alvo!Rosane GotardoQualquer informação, seja de Instituição filantrópica, pública ou privada, se não estiver préviamente organizada por processos de fluxos controlados, não terá como se "auto-organizar" com sua informatização.
Este é o ponto. A maioria das instituições quando informatizam, pensam que um sistema irá solucionar seus problemas de fluxos e processos. E sabemos que não é assim. Muitas vezes solicitam alterações nos sistemas para adequá-los às suas falhas de processos, o que gera um problema tanto para as empresas de desenvolvimento como para a própria instituição, que estará "calcificando" o seu problema (o caos).
Abraços,
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br
--
Jussara Rötzsch
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br
--
Jussara Rötzsch
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br
0 comentários:
Postar um comentário