Fase Automatizar

Objetivos

Essa é a segunda fase da Fórmula Zeev de criar aplicativos.

Nessa fase o desenvolvedor cidadão irá realizar todas as atividades de mapeamento, modelagem e configuração da ferramenta Zeev que não envolvam nenhum tipo de programação ou criação de códigos.

O grande segredo dessa fase é explorar ao máximo o uso de recursos nativos da ferramenta, separando e isolando requisitos técnicos que eventualmente envolvam codificação para a próxima fase (customizar).

Profissionais envolvidos

O desenvolvedor cidadão é o principal responsável pela execução dessa etapa. É ele o responsável por realizar todas as configurações necessárias no Zeev.

Essa fase pode levar uma ou mais iterações, dependendo do tamanho do aplicativo.

O desenvolvedor cidadão irá contar com apoio do dono do aplicativo, dos especialistas, do cliente e dos atores para:

1. Elucidar dúvidas;

2. Simular o aplicativo;

3. Aprovar a fase;

Eventualmente, o desenvolvedor cidadão poderá interagir com o desenvolvedor profissional, responsável pela próxima fase, para ajudá-lo em dúvidas de como especificar da melhor maneira os requisitos técnicos que serão implementados no futuro.

Como

Nessa fase, o desenvolvedor cidadão irá:

• Desenhar o processo do aplicativo completo, totalmente no formato BPMN, seguindo todas as regras de modelagem e boas práticas de desenho;

• Implementar o formulário eletrônico do aplicativo;

• Simular, conjuntamente com os stakeholders, a execução do aplicativo.

Para que essa fase seja implementada iterativamente, a recomendação é que o desenvolvedor cidadão determine um número máximo de elementos do aplicativo que serão contemplados em cada ciclo. Geralmente, em casos normais, trabalhamos entre 8 e 12 elementos em cada iteração.

Isso significa que você irá desenhar, configurar e automatizar de maneira completa entre 8 e 12 elementos do desenho. Irá simular essa parte do aplicativo, e apresentá-la aos stakeholders. E buscar a aprovação dos stakeholders sobre esse pedaço.

Após essa aprovação, você parte para a próxima parte do aplicativo, com mais 8 a 12 elementos.

E assim sucessivamente.

Desenhar o processo do aplicativo

Recomendamos que o primeiro passo seja o desenho do processo do aplicativo, puro e simples.

Nessa etapa, você não deve se preocupar ainda com:

• Formulários;

• Anexos;

• Atores;

• SLAs;

• Prazos;

• Controles;

• Configurações de etapas;

• Configurações de condicionais;

• Integrações,

• Etc.

Você irá se preocupar somente em representar visualmente o fluxo de informações de sua empresa.

Encare o desenho do aplicativo como uma ferramenta iterativa. Você irá gerar diversas versões incrementais desse desenho, melhorando-o pouco a pouco, validando com seus colegas e com os stakeholders do aplicativo.

Para desenhar o processo do aplicativo, é necessário que você conheça:

• O funcionamento de atividades, gateways, eventos e swinlanes;

• Como usar nossa ferramenta de desenhador de processos;

• Regras fundamentais de desenho;

• Boas práticas de desenho;

Exemplo de um desenho de processo:

Veja o manual completo desse assunto no link abaixo:

Criar formulário

Recomendamos que o formulário seja a segunda etapa, e que o formulário comece a ser construído depois de você ter uma versão inicial básica do desenho do aplicativo.

Os formulários são alguns dos principais elementos dentro de um aplicativo de processo. Apesar de nem todos os aplicativos possuírem formulários (ex.: um aplicativo de documentos), a maioria utiliza este recurso como método de estruturação das informações digitadas pelos solicitantes e participantes do aplicativo. Assim, na maior parte das vezes, você irá criar um formulário associado a um aplicativo.

Cada aplicativo pode possuir somente um formulário. Mas, não se preocupe! Na próxima etapa, de configurar elementos, entre outras coisas, você irá definir quais campos do formulário serão visíveis e quais serão editáveis em cada etapa do aplicativo. Ou seja, no Zeev, você irá construir um grande formulário que inclui todas as informações necessárias para seu processo rodar. E esse formulário poderá ser quebrado em múltiplas visões, ao longo das tarefas.

Exemplo de um formulário de aplicativo:

Veja o manual completo desse assunto no link abaixo:

Configurar elementos

Com seu processo já desenhado e o formulário base construído, vamos a etapa de configuração. Essa etapa consiste em acessar a tela de configurações de cada elemento do aplicativo e definir como esse elemento será executado.

Para configurar um elemento, selecione o elemento e, nos ícones de opções avançadas, clique no ícone de configuração. A barra de configurações aparecerá do lado esquerdo da tela.

A maior parte das configurações são opcionais. Aos poucos, você vai acrescentando níveis de recursos no aplicativo.

As regras de negócio envolvidas na configuração de cada elemento, nesse manual, estão justamente dentro da documentação geral de cada elemento: atividades, gateways e eventos.

Depurar e simular

A depuração de um processo de aplicativo é um procedimento automatizado que irá percorrer todo o seu desenho, seu formulário e suas configurações, buscando inconsistências. Você pode e deve rodar a depuração diversas vezes ao longo de seu desenvolvimento. Com base no relatório de problemas identificados, você pode implementar melhorias e correções no processo do aplicativo.

Já a simulação consiste em rodar, manualmente, todo o aplicativo. Com essa ferramenta, todas as tarefas humanas serão direcionadas a você, que poderá simular o papel de outras pessoas recebendo e executando tarefas. A simulação é importante para você ter a mesma visão dos atores finais e garantir que tudo está funcionando corretamente.

Customizações e integrações

Um dos grandes objetivos dessa fase é dar condições para que o aplicativo possa ser simulado, validado e aprovado pelos stakeholders, SEM se preocupar com integrações e customizações.

Para isso, o desenvolvedor cidadão deverá usar algumas técnicas para simular as integrações e customizações.

Necessidades de customizações no formulário

Como desenvolvedor cidadão, é possível que você identifique, ao criar o formulário associado ao aplicativo, a necessidade de algumas customizações que vão além do que a ferramenta oferece nativamente.

Exemplos de necessidades relativamente comuns de customizações:

• Realizar cálculos matemáticos com base em campos do formulário;

• Esconder e mostrar campos do formulário de acordo com regras de negócio;

• Realizar validações especiais;

• Carregar valores de campos com base em integrações e sistemas externos;

Nessa fase, você não irá desenvolver nenhuma dessas customizações. Você fará adaptações no aplicativo temporárias para permitir que ele seja simulado e poderá usar o recurso "Ajuda do campo" no construtor de formulários para especificar e tornar visível os requisitos técnicos necessários.

Digamos que você tenha um formulário com os campos valor unitário, quantidade e valor total, e possua como requisito realizar o cálculo do valor total com base no valor unitário e na quantidade. Nossa sugestão seria:

• Tornar o campo "Valor total" editável no aplicativo (temporariamente), permitindo que ele seja preenchido manualmente, possibilitando assim que o aplicativo seja simulado;

• Adicionar comentário no campo "Valor total" explicitando a necessidade da automação.

Veja como poderia ficar:

Em outro cenário, digamos que você tenha um formulário com duas caixas de seleção, UF e cidade. Deseja que, após selecionada a UF, a lista de cidades seja atualizada automaticamente. Nossa sugestão seria:

• Transformar o campo "Cidade" temporariamente em um campo do tipo texto, permitindo que o nome da cidade seja preenchido manualmente e possibilitando assim que o aplicativo seja simulado;

• Adicionar comentário no campo "Cidade" explicitando a necessidade da automação.

Veja como poderia ficar:

Observe que ao utilizar esses artifícios:

• Você permite que o aplicativo seja executado e simulado de ponta a ponta;

• Você permite que os stakeholders aprendam com o aplicativo real, executado;

• Você permite que os stakeholders confirmem que a customização é extremamente necessária;

• Você deixa explícito aos stakeholders que está ciente do requisito que foi solicitado, mas informa que ele não foi implementado ainda.

Necessidades de integrações com outros sistemas

Digamos que você identifique, no meio do desenho do aplicativo, a potencial necessidade de integrações com outros sistemas, com o uso de tarefa de serviço.

Como desenvolvedor cidadão, você irá especificar essa necessidade e desenhar a tarefa no aplicativo , mas não irá configurá-la. Se você não configurá-la e não se preocupar com a criação da integração em si, o aplicativo ainda assim poderá ser simulado e executado; a tarefa de serviço simplesmente será ignorada.

Veja o exemplo abaixo. Caso a tarefa "Criar negócio no CRM" não seja configurada, após "Montar proposta comercial" (tarefa humana), o aplicativo seguirá direto para "Enviar proposta ao cliente e aguardar retorno".

Caso essa integração seja responsável por retornar algum dado (por exemplo, o número do negócio no CRM), você usará as mesmas técnicas utilizadas na simulação das customizações do formulário para apresentar essa informação aos stakeholders:

Backlog de pendências técnicas revisto e priorizado

O Backlog é um documento de especificação onde o desenvolvedor cidadão realiza a identificação, mapeamento e descrição das necessidades técnicas de customização e integração que serão, na próxima fase, implementadas pelo desenvolvedor profissional.

Esse Backlog é construído ao longo das diversas iterações da fase de automação. Ao final, é muito importante que o dono do aplicativo aprove o documento, formalmente confirmando a importância de cada item ser desenvolvido.

Na tabela abaixo, temos um exemplo simplificado de como um documento de Backlog poderia ser:

Cursos Online

Esses são os cursos online que apoiam essa fase.

• Dia-a-dia usando o Zeev

• Como criar aplicativos

Duração

Essa fase pode levar de alguns dias até alguns meses, dependendo do tamanho do projeto. Se o projeto é grande, divida-o em ciclos menores de entregas.

Entregas

Ao final de todas as iterações dessa fase, é esperado que as seguintes entregas sejam finalizadas:

• Processo do aplicativo desenhado e configurado no Zeev, usando padrão BPMN e melhores práticas

• Formulário eletrônico construído no Zeev, usando somente funções nativas

• Times e funções cadastrados na plataforma

• Aplicativo simulável na plataforma, sem customizações nem integrações

• Aplicativo básico testado e aprovado pelos stakeholders

• Backlog de pendências técnicas revisto e priorizado