Versão 3.0: faça melhor

A empresa está constantemente desenvolvendo seus produtos de TI. Não há como "parar o momento", caso contrário, mesmo o melhor programa inevitavelmente ficará desatualizado. Contamos como criamos uma nova versão do aplicativo médico para a Europa e quais problemas foram resolvidos ao mesmo tempo.

Hospital App

Estamos trabalhando com um aplicativo médico para hospitais na Europa. Ajuda os médicos a passar mais tempo com os pacientes, reduzindo a papelada. Os médicos determinam informações sobre pacientes e exames, o aplicativo converte as gravações de áudio em formato de texto, preenche um modelo e gera documentos para médicos e pacientes. Em cada etapa do trabalho, é estabelecida sua própria lógica de negócios e integração com vários sistemas externos.

O cliente nos encarregou de desenvolver uma nova versão do aplicativo para demonstração aos investidores.

Detalhes do projeto

Áudio

Como gravar áudio na versão 2.0:

1. Abriu o aplicativo.
2. Clicou no botão Adicionar registro.
3. Na janela que apareceu, selecionamos a versão desejada do dispositivo de gravação.
4. Gravação de áudio ditada.
5. O número do paciente, data da visita, número da visita (visita = consulta médica) foram inseridos.
6. Eles clicaram no botão Concluir para fazer upload de áudio e visitar os dados no servidor.

Agora, na versão 3.0, menos esforço é necessário para escrever:

1. O médico abre o aplicativo.
2. Seleciona um compromisso (por data, hora, número ou nome do paciente) da lista e clica em 1 hora para abrir um cartão de visita.
3. Grava áudio.
4. Pressione o botão Concluir para enviar áudio para o servidor.

Na versão 3.0, o trabalho do médico é o mais automatizado possível. O número de operações diminuiu, enquanto o próprio programa adiciona dados sobre os pacientes.

Trabalhar com letras

Trabalhar com letras também se tornou mais fácil. Na versão 2.0, havia uma fila difícil para o processamento. O médico não pôde receber imediatamente uma lista completa de cartas - apenas em partes e em uma determinada ordem. Para começar, você precisava:

• clique para obter uma lista de suas cartas;
• vá para outra janela;
• clique duas vezes na letra para abri-la;
• depois de processar as letras da lista, clique novamente para receber as seguintes letras na lista.

Na versão 3.0, o médico vê todas as letras disponíveis para processamento. Ele pode selecionar um documento de duas maneiras - manualmente na lista ou usando filtros e tipos (você pode salvá-los para abrir ainda mais a carta com um clique). Para abrir a carta, basta clicar uma vez.

Interface

Em geral, a interface da versão 2.0 era complicada e inconveniente. A tarefa inicial do aplicativo era economizar o tempo dos especialistas médicos, reduzindo o fluxo de trabalho em papel e trabalhando com gravações de áudio. Na prática, o aplicativo não lidou com essa tarefa tão bem quanto gostaríamos. Para fazer um registro, o médico teve que escolher várias configurações em longas listas suspensas.

Nossos especialistas trabalharam com a interface e destacaram o botão de áudio para que os usuários possam concluir sua tarefa com o menor número de cliques.

Em seguida, forneceremos detalhes sobre como desenvolvemos a nova versão.

Novas necessidades

Quando um cliente nos contatou para atualizar a versão 2.0, o aplicativo está funcionando há cerca de três anos. Era familiar para os usuários e tinha certas vantagens:

• Havia um conjunto de funções para executar lógica de negócios complexa, integração com sistemas de terceiros;
• os clientes estão acostumados ao programa e não desejam abandoná-lo;
• A equipe de suporte técnico conhecia o aplicativo e ajudou rapidamente os usuários;
• Havia configurações flexíveis para configurar o sistema para qualquer desejo de negócios;
• Foi estabelecido o rastreamento de possíveis problemas nas partes do servidor do sistema, conhecidas soluções alternativas para resolvê-los.

No entanto, ao analisar a operação do aplicativo, encontramos esses problemas:

• o desenvolvimento e teste de novos recursos levavam cada vez mais tempo;
• ao adicionar novas funções, erros apareciam no sistema;
• como resultado, até 30% das melhorias complexas foram colocadas em prateleira, o que ameaçou desatualizar o aplicativo. Por exemplo, nos hospitais, modelos cada vez mais complexos apareceram, era necessário adicionar novas funções no fluxo de trabalho;
• a arquitetura do aplicativo não suporta novas soluções;
• 40% do tempo de desenvolvimento foi gasto em suporte;
• houve dificuldades ao instalar novas versões e atualizações do produto de desktop;
• a interface complicada da década de 2000 assustou novos clientes;
• um sistema de configurações inconvenientes impedia que o sistema iniciasse rapidamente e também aumentava os riscos de erros.

Ao avaliar os pontos fortes e os desafios, chegamos à conclusão de que o aplicativo precisa ser mais móvel (versão Web em vez de desktop) e conveniente, competitivo e facilmente adaptável às tarefas de negócios.

Requisitos de versão

Analisamos as funções do aplicativo e identificamos as mais importantes que tornaram o produto valioso para os negócios. Com base nesses dados, determinamos qual deveria ser o programa na nova versão:

• São necessárias as principais funções do aplicativo, intuitivas para médicos e outros usuários;
• Deve ser fácil para os usuários - provedores de assistência médica e equipe de suporte - aprender como usar o programa;
• elimine a perda de dados mesmo sob condições extremas (falta de energia, acesso instável à Internet, etc.);
• documentos gerados pelo sistema devem cumprir as normas e requisitos da lei;
• durante as atualizações do sistema, o possível inconveniente para o usuário e o serviço de suporte deve ser minimizado;
• é necessário criar uma arquitetura modular orientada a serviços com base em componentes distribuídos e pouco acoplados, que permitirão que sejam usados ​​para construir sistemas de software complexos;
• Use o Active Directory para configurar uniformemente seu ambiente de trabalho.

Além disso, era impossível permitir que a nova versão fosse um "clone complicado" da antiga. Portanto, as funções principais precisavam ser salvas, mas sem sobrecarregar o aplicativo. Abandonamos implacavelmente configurações complexas redundantes.

Analistas de negócios que trabalham com a versão 2.0 não aceitaram imediatamente as alterações. Nos termos de referência, foram frequentemente encontradas frases: “Deveria estar aqui como na versão 2.0”, “Adote o esquema de trabalho na versão 2.0”. O mais difícil nesta fase foi a resistência à tentação de levar tudo, como na versão anterior.

Equipe do projeto

Como regra, no início de cada projeto, na SimbirSoft, nos conectamos a uma equipe de especialistas de diferentes perfis - analistas, especialistas em garantia de qualidade (QA) e outros. Ao trabalhar em um aplicativo médico, reunimos a seguinte equipe:

• desenvolvedores que escreveram código e adaptaram recursos da versão 2.0;
• Especialistas em garantia de qualidade (QA). Eles, juntamente com os desenvolvedores, estavam familiarizados com o código legado, soluções de arquitetura e erros da versão 2.0 e também testaram novas funções;
• Engenheiro de automação de teste (SDET), que configurou a verificação automática de caso de teste nas versões desktop e web;
• Inteligência de negócios. Eles conversaram com o cliente e os médicos, descobriram como os processos de negócios foram criados, quais são os requisitos e desejos para a aplicação. Depois disso, eles elaboraram diagramas de processos de negócios que eram compreensíveis para toda a equipe;
• Designer e especialista em usabilidade. Eles foram responsáveis ​​pelo desenvolvimento de uma interface amigável.
• Gerente de projetos envolvido no gerenciamento e agendamento de horário.

No processo, mantivemos constantemente tabelas dos riscos alegados na nova versão. Para evitá-los, pensamos em um sistema flexível de configurações de aplicativos e automatizamos seus testes para proteger os usuários contra erros. Em particular, nosso especialista em SDET escreveu uma estrutura que ajudou a verificar rapidamente todas as alterações no código e gastar menos tempo em testes de regressão.

Desafios e soluções

Ao atualizar o aplicativo, enfrentamos vários estágios difíceis, que discutiremos abaixo.

Design do aplicativo

Como a versão anterior tinha uma interface complicada, redesenhamos o design do aplicativo. Propusemos cinco opções preliminares e as mostramos ao grupo focal dentre os usuários do aplicativo, realizando testes de usabilidade. Como resultado, os especialistas médicos escolheram uma opção que, na sua opinião, acabou sendo a mais conveniente, atraente e fácil de usar.

Desenvolvimento de plugins para diferentes navegadores

Nós fornecemos vários riscos técnicos associados ao aplicativo. Por exemplo, o plug-in escolhido para implementação pode não ser adequado para alguns navegadores da Internet. Para reduzir esse risco, primeiro desenvolvemos um plug-in para o software usado na maioria das instituições médicas parceiras. No futuro, desenvolvemos com calma o plugin para outros navegadores.

Hipóteses de negócios inválidas

Nossa tarefa era desenvolver uma versão limitada do produto para apresentação aos investidores. Por esse motivo, procuramos implementar no aplicativo apenas as funções mais necessárias. Analisamos algumas hipóteses do cliente e nos recusamos a implementá-las.

Por exemplo, o cliente sugeriu a criação de um calendário para o planejamento do trabalho de médicos especialistas. Segundo a hipótese, o calendário poderia tornar o trabalho dos médicos mais conveniente. No entanto, em condições reais, essa função não foi bem-sucedida e, por fim, foi desativada. Mais tarde, o calendário foi adaptado às necessidades de outro grupo de usuários - pacientes, não trabalhadores médicos. Hipóteses inválidas - isso é parte integrante do negócio e você precisa estar preparado para elas.

Integração com sistemas externos

Demorou muito tempo para concordar com nosso parceiro sobre o procedimento para integrar o aplicativo a sistemas externos para envio e armazenamento de cartas.

Os usuários do aplicativo - instalações médicas - queriam usar sistemas de integração antigos e familiares para a versão 3.0; eles não podiam ser alterados. Nosso parceiro assumiu que, neste caso, a integração seria rápida. No entanto, de fato, muitas tarefas foram associadas à integração:

• Reunir informações gerais sobre como os sistemas de envio de email funcionam;
• faça uma lista de bugs críticos que estavam na versão 2.0;
• considere esses casos no estágio de análise e desenvolvimento, a fim de levá-los em consideração e não pisar no mesmo rake;
• analise se as funções da versão 2.0 são adequadas para os processos da versão 3.0 ou se algo precisa ser alterado. Em caso de alterações, especifique sempre por que funções específicas são necessárias e comunique-se com os especialistas técnicos do cliente, e não apenas com analistas.

No processo de negociações com o cliente, pudemos provar que trabalhar com integração leva tempo. Nosso parceiro concordou conosco: você não pode simplesmente transferir e transferir o código de uma versão para outra.

Testes e análises

A versão anterior do projeto foi criada sem a participação de analistas. Os desenvolvedores e especialistas em controle de qualidade especificaram os requisitos no processo de criação do aplicativo. A terceira versão já era baseada nos requisitos dos analistas, no entanto, ainda havia dificuldades nos testes:

• diferentes equipes trabalharam no projeto;
• havia um grande volume de tarefas paralelas;
• durante o sprint, os requisitos e tarefas geralmente mudam;
• Era necessário levar em consideração a interação de novos recursos com os já aprovados.

Para trabalhar na nova versão do produto, precisávamos transformar fluxos de trabalho individuais, por exemplo:

• Fortalecemos as análises do lado do desenvolvimento e do controle de qualidade e reservamos horas adicionais para isso.
• Era uma regra indicar o objetivo da função sendo testada nos requisitos para a revisão. Isso melhorou o entendimento das tarefas dos analistas e proporcionou a oportunidade de propor a solução ideal.
• Para esclarecer os termos de trabalho, alteramos a terminologia: em vez de uma estimativa aproximada em horas, começamos a classificar as tarefas como “grandes” ou “pequenas”. Começamos a calcular o lead time somente após uma revisão completa da tarefa do lado do desenvolvimento, controle de qualidade e aprovação da versão final dos requisitos pelo cliente. Se a tarefa expandir, recalculamos a estimativa dos custos de tempo.
• Começamos a planejar quais funções devem ser implementadas nos próximos trimestres - para os próximos 2-3 lançamentos. Para prever com mais precisão o desenvolvimento, não incluímos mais no plano de liberação as tarefas que não passaram na avaliação.
• Para conveniência dos analistas e uma melhor compreensão do sistema, indicamos nas listas de verificação quais interações devem ser levadas em consideração ao fazer requisitos. Também desenvolvemos regras comuns para escrever artigos no Confluence e documentação no JIRA e começamos a aderir a eles.

Reuniões on-line regulares com o cliente nos ajudaram a melhorar nossa compreensão de seus processos de negócios. Durante a conversa, nosso parceiro contou os detalhes de como os médicos trabalham e explicou as metas de negócios. Por sua vez, explicamos as nuances técnicas e mostramos vários casos não óbvios. Isso nos permitiu formular requisitos de produtos que cobrem as necessidades das instituições médicas e são ótimos em termos de custos de implementação.

Sumário

A flexibilidade nos processos de trabalho e a atenção às necessidades dos negócios nos permitiram superar todas as dificuldades que surgiram durante o processo de desenvolvimento. Criamos e lançamos com sucesso uma nova versão do aplicativo para instituições médicas na Europa.

Agora continuamos a desenvolver o produto e a introduzir novos recursos. Examinamos como usuários reais trabalham com o sistema, coletamos casos não contabilizados e histórias de usuários e identificamos novos valores de negócios.

Ao criar uma nova versão de um produto, os desenvolvedores, em regra, enfrentam os mesmos problemas que nós, por exemplo:

• hipóteses incorretas do lado dos negócios são possíveis;
• existem contradições nos desejos dos usuários (deixe tudo como era ou refazê-lo de uma nova maneira);
• às vezes é necessário reestruturar o trabalho da equipe para alcançar um melhor resultado.

O principal é que o lançamento da nova versão do produto de TI não é uma cópia do código “Ctrl + C”, “Ctrl + V” da versão anterior, mas um desenvolvimento completo do zero. Isso ocorre porque os processos de negócios, os requisitos do usuário e a situação no mercado de soluções de TI estão mudando.

Obrigado pela atenção! Esperamos que você ache este artigo útil.