# Fase Mapear
## Objetivos
Essa é a **primeira fase** da [Fórmula Zeev](/zeev/formula-zeev/introducao-a-formula-zeev.md) de criar aplicativos.
O objetivo principal dessa fase é identificar, mapear e realizar o **desenho básico e inicial do processo do aplicativo**.
## Profissionais envolvidos
O [desenvolvedor cidadão](/zeev/formula-zeev/definir-papeis.md#desenvolvedor-cidadao-citizen-developer) é o principal responsável pela execução dessa etapa. É ele o responsável por conduzir as atividades colaborativas de desenho do processo do aplicativo.
É fundamental a participação ativa do [dono do aplicativo](/zeev/formula-zeev/definir-papeis.md#dono-do-aplicativo-app-owner), dos [especialistas](/zeev/formula-zeev/definir-papeis.md#especialista-de-dominio-subject-matter-expert), do [cliente ](/zeev/formula-zeev/definir-papeis.md#clientes-customers)e dos [atores](/zeev/formula-zeev/definir-papeis.md#atores-performers) em encontros organizados pelo desenvolvedor cidadão.
Geralmente, encontros em conjunto são mais ricos pois permitem a todos terem uma visão geral do processo, porém encontros individuais de levantamento também podem ocorrer.
### O dono do aplicativo
O dono do aplicativo é peça fundamental na fórmula. Ele será o principal responsável por tomar as decisões que nortearão a implementação e a automatização. No caso de não haver consenso, o dono do aplicativo é quem decide.
Em processos multifuncionais, que permeiam muitos times da organização, às vezes pode ser difícil definir um dono. Mas não defini-lo é pior ainda. Muito tempo poderá ser perdido resolvendo conflitos e múltiplos interesses, e o aplicativo corre o risco de ser um segregado de interesses de times diferentes. O dono do aplicativo é quem define a visão unificada do processo.
{% hint style="info" %}
**Dica**: não ter um dono do aplicativo claro desde o início é um dos [principais erros](/zeev/formula-zeev/resumo-de-principais-erros.md#nao-definir-um-dono-do-processo) de projetos de automação.
{% endhint %}
## Como
A fase de Mapear é o momento em que, em geral, você irá discutir, rascunhar, especificar, documentar e mapear o desenho básico do aplicativo.
Diversos métodos e metodologias de mercado pregam diferentes níveis e ferramentas de documentação. Nenhum é necessariamente compatível ou incompatível com nossa fórmula, e você pode usar livremente as ferramentas que julgar necessárias. Exemplo:
* Ferramentas de gerenciamento de projetos tradicionais pregam uma elevada e detalhada documentação nas fases iniciais do projeto, de modo a ter clareza do escopo, prazos e riscos do projeto;
* Métodos tradicionais de descobrimento de processos pregam o mapeamento do processo AS IS (como o processo ocorre hoje) seguido do processo TO BE (como o projeto deveria ser ou como será).
### Documentação ágil
Anteriormente falamos que nossa fórmula é baseada na [filosofia ágil](/zeev/formula-zeev/introducao-a-formula-zeev.md#seja-agil). De acordo com o [manifesto ágil](https://agilemanifesto.org/iso/ptbr/manifesto.html), o software em funcionamento deve ter mais prioridade do que uma documentação abrangente. Mas isso, de forma alguma, tira a importância de documentar. Construir a documentação de um projeto é fundamental para a comunicação do cliente com o time e vice-versa.
**O principal erro que ocorre nessa fase é prolongar demais o uso de ferramentas de documentação.** A documentação ágil deve ser tão magra quanto possível, ou seja, deve ser simples, clara e muito objetiva, considerando, claro, o nível de detalhes necessários para o projeto. Informações demais podem tornar o documento muito complexo e cansativo para quem irá utilizá-lo e, também, atualizar suas informações será bem trabalhoso.
Sendo mais claro: nas demais fases da fórmula, seu processo **vai** mudar. Documentação demais ou muito detalhada no início do projeto **será** perda de tempo.
{% hint style="info" %}
**Dica**: prolongar demais essa fase, criando uma documentação grande, detalhada e desnecessária, é um dos[ principais erros](/zeev/formula-zeev/resumo-de-principais-erros.md#especificar-e-documentar-demais) de projetos de automação.
{% endhint %}
A maneira mais simples e otimizada que nós usamos para começar a desenhar um processo é o Excel. Mas, antes de mostrar um processo no Excel, é preciso entender o conceito de "caminho feliz".
### O que é "caminho feliz"
Caminho feliz é o conjunto de atividades sequenciais de um processo que levam a **geração de valor mais rapidamente**. É o caminho do processo onde tudo dá certo, onde não há retrabalhos nem erros.
Apesar de o caminho feliz nem sempre acontecer, pensar no caminho feliz é uma boa tática para começar a refletir e desenhar seu processo.
Veja, por exemplo, no desenho completo abaixo, o caminho em verde representando o caminho feliz do processo, onde tudo dá certo.
### Representando o caminho feliz no Excel
Representar o caminho feliz do processo no Excel é bastante simples.
Veja o exemplo do processo desenhado acima em um formato de tabela:
| Responsável | Atividade | Prazo \* |
| -------------------- | --------------------------------------------- | ---------------- |
| Assistente comercial | Registrar pedido de proposta | |
| Equipe comercial | Montar proposta | 8 horas úteis |
| Equipe comercial | Atualizar CRM | Automático |
| Assistente comercial | Enviar proposta ao cliente e aguardar retorno | 10 dias corridos |
| Equipe de entrega | Despachar produtos | 2 dias corridos |
| Equipe de entrega | Atualizar o CRM | Automático |
Você pode, no Excel, ir criando novas colunas para já iniciar a documentação de cada etapa.
Aos poucos, pode ir acrescentando novas planilhas, indicando os caminhos alternativos, o caminho **que não é feliz**; quando a solicitação é rejeitada, quando algo dá errado, quando é preciso voltar para um ponto passado do processo. Imagine o caminho feliz como a espinha dorsal do processo, e os caminhos alternativos como as costelas.
### Desenhando o processo do aplicativo
Nessa fase não é necessário que você utilize o Zeev; o desenho inicial pode ser feito em qualquer ferramenta que permita desenhos de processos. Exemplos de ferramentas complementares:
* Quadro na parede;
* Posts-its;
* Microsoft Visio;
* Miro;
* Powerpoint;
* Bizagi;
Algumas notações de mercado mais conhecidas para desenho de processos são:
* [Fluxograma](https://blog.zeev.it/5-passos-para-criacao-de-um-fluxograma/)
* [SIPOC](https://blog.zeev.it/o-que-e-sipoc/)
* [VSM ou Value Stream Mapping](https://blog.zeev.it/vsm-value-stream-mapping/)
* EPC
* [BPMN](#o-que-e-bpmn)
Você pode prosseguir (opcionalmente) até o[ desenho do BPMN](/zeev/como-construir-processos/como-desenhar-processos.md#o-que-e-bpmn), mas procure manter o desenho mais simples possível, pois a maior parte das pessoas envolvidas na co-criação dessa etapa não vão conhecer o BPMN. Nesse momento, NÃO é preciso que o processo desenhado siga [todas as regras](/zeev/como-construir-processos/como-desenhar-processos/regras-fundamentais-de-desenho.md) e [boas práticas de desenho](/zeev/como-construir-processos/como-desenhar-processos/boas-praticas-de-desenho.md).
## Cursos Online
Esses são os cursos online que apoiam essa fase.
* [Fórmula Zeev](https://universidade.zeev.it/p/ead-02-formula-zeev)
* [Dia-a-dia usando o Zeev](https://universidade.zeev.it/p/ead-03)
* [Como criar aplicativos](https://universidade.zeev.it/p/ead-05-criar-aplicativos)
## Duração
Considerando que o desenho do processo irá mudar ainda diversas vezes ao longo do projeto, conforme as demais fases forem executadas, é indicado que essa fase seja a mais curta possível, envolvendo o mínimo de iterações.
## Entregas
Ao final de todas as iterações dessa fase, é esperado que as seguintes entregas sejam finalizadas:
* [ ] Visão coesa entre [stakeholders](/zeev/formula-zeev/definir-papeis.md#stakeholders) sobre expectativas e objetivos do projeto
* [ ] Mapeamento básico inicial do processo
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://kb.stoque.com.br/zeev/formula-zeev/criar-um-aplicativo/executar-fases/fase-mapear.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.