O objetivo do plano de ação é trazer clareza para a demanda que será desenvolvida, desta forma fazendo com que o responsável pelo desenvolvimento, possa ter uma visão geral se a demanda tem o que é necessário para ser realizada.
Ao realizar o plano de ação, será possível identificar o objetivo da demanda e questionar todos os pontos necessários antes do início da demanda. Além de trazer uma visão mais objetiva do que será realizado para todos envolvidos na tarefa.
Como funciona o processo do plano de ação?
1) Objetivo
O primeiro passo seria entender o que tem que ser realizado na demanda, é questionar qual o objetivo e resultado que o cliente ou responsável espera com essa demanda.
Esse primeiro passo é muito importante, pois com o questionamento e entendimento, a demanda pode mudar ou evoluir o escopo inicial, além de evitar execuções de tarefas sem um entendimento claro de todos envolvidos.
Também é recomendado atualizar a documentação de “Motivação/Objetivo” da demanda, para que fique de acordo com o objetivo real, de uma forma que fique claro para qualquer responsável que tenha que executar.
A recomendação para essa etapa é:
Caso o objetivo da demanda não tenha ficado claro para todos envolvidos, a demanda não deveria ser iniciada e nem seguir para os próximos passos do plano de ação. A demanda deveria voltar para o cliente/responsável, com os questionamentos necessários para o entendimento.
Seguindo esse processo, conseguimos evitar muitas execuções e solicitações de demandas sem clareza ou com documentações ruins.
2) Como irei fazer?
Após entender qual o objetivo da demanda, o segundo passo é entender o como deve ser feito a demanda, não de uma forma técnica, mas de uma forma mais simples e abstrata, usando apenas lógica.
Por exemplo, ao pegar uma demanda onde o objetivo seja criar um formulário para página de contato onde o cliente quer receber o nome, email, assunto e dúvida do cliente / usuário.
Podemos entender que o como irei fazer seria:
“Irei criar um formulário na página X, com os campos de nome (onde o usuário irá poder adicionar qualquer tipo de texto), o assunto (que pode ser um campo de seleção de assuntos definidos pelo cliente), um campo de email (que terá que ter validação de se é um email válido), um campo de texto (onde o cliente irá poder adicionar uma mensagem mais longa descrevendo melhor a dúvida ou problema) e um botão para enviar as informações.
Após o usuário preencher todas informações, e clicar no botão de enviar, irei ter que validar se os campos estão preenchidos corretamente.
Caso não esteja, terei que apresentar uma mensagem de feedback de qual o problema e campo que faltou informação.
Caso esteja válido, irei enviar essas informações para o email XX do cliente em um formato que fique claro para entendimento. Após ser enviada com sucesso, irei apresentar uma mensagem para o usuário, com o feedback de sucesso.”
Seguindo esse exemplo, que pode ser aplicado para qualquer tipo de demanda ou tarefa, conseguimos entender o fluxo que preciso executar, sem aplicar nenhum conhecimento técnico neste momento.
A recomendação para essa etapa é:
Caso o responsável pela demanda não consiga descrever o fluxo com clareza sem envolver questões técnicas, a demanda não deveria ser iniciada e nem seguir para os próximos passos do plano de ação.
Neste caso, existe um problema de entendimento do objetivo ou uma deficiência de lógica do processo da demanda. Com isso, é recomendado que o responsável tenha o auxílio de uma outra pessoa para o entendimento da demanda.
3) Cronograma
Após ter clareza de como irá fazer a demanda, o terceiro ponto é criar um cronograma com os passos que devem ser seguidos para a execução da demanda.
Nesta etapa iremos aplicar o fluxo desenhado no segundo passo em formato de checklist. Também iremos considerar nessa etapa o como irá ser feito tecnicamente.
Por exemplo, se iremos usar um plugin, se vamos usar javascript para fazer a validação dos campos, se iremos usar alguma ferramenta ou biblioteca para o envio de emails, entre outros..
Podemos entender que o cronograma seria:
Primeiro exemplo:
- Criar campos
- Nome
- Assunto
- Texto
- Criar validação dos campos
- Assunto
- Criar processo de envio
- Validação de campos preenchidos corretamente
- Envio de informações por email
- Validação da demanda
Após ter uma base dos pontos que iremos executar, podemos especificar um pouco mais, com processos que normalmente não levamos em consideração na estimativa da demanda, como por exemplo:
Segundo exemplo:
- Configurar ambiente inicial do projeto
- Estudar/Entender documentação do projeto
- Criar campos
- Nome
- Assunto
- Texto
- Criar validação dos campos
- Assunto
- Criar processo de envio
- Validação de campos preenchidos corretamente
- Envio de informações por email
- Validação da demanda
- Montar plano de teste da demanda
- Abrir PR para responsáveis
- Documentar demanda no Jira
- Suporte para QA/Validação
Neste segundo exemplo, colocamos alguns processos internos que são necessários para que a demanda tenha uma qualidade de entrega e que em muitas vezes não são considerados no decorrer do processo, podendo fazer com que além da falta de qualidade na entrega, também tenha um aumento do tempo de execução e entrega.
No cronograma, conseguimos identificar qual o planejamento inicial do responsável pela demanda e com isso conseguimos questionar e auxiliar em pontos não previstos na documentação inicial.
A recomendação para essa etapa é:
Caso o responsável pela demanda não consiga desenvolver um cronograma claro do que irá executar, a demanda não deveria ser iniciada e nem seguir para os próximos passos do plano de ação.
4) Estimativa
Uma das maiores dificuldades do responsável pelo desenvolvimento da demanda é fazer uma estimativa de tempo (horas) que precisa para desenvolver a tarefa. Um dos pontos positivos do plano de ação, é dar a base necessária para o desenvolvimento de uma estimativa baseada em itens e um plano.
Após o desenvolvimento do cronograma da demanda, o quarto passo é estimar cada item listado no cronograma.
No caso do exemplo listado acima, estimar o desenvolvimento de um formulário funcional pode ser um pouco complexo pela falta de experiência ou clareza. Ao utilizar o cronograma já desenvolvido como base, não iremos estimar a demanda, mas sim uma ação, como por exemplo: Criar um campo de email ou Criar a validação em js para o campo de email.
Seguindo esse exemplo, conseguimos entender melhor quanto tempo precisamos para cada etapa e também conseguimos ter mais clareza de onde temos dificuldade.
Podemos entender que o cronograma seria:
Primeiro exemplo:
- Configurar ambiente inicial do projeto (2 horas)
- Estudar/Entender documentação do projeto (1 hora)
- Criar campos
- Nome (15 min)
- Email (15 min)
- Assunto (30 min)
- Texto (15 min)
- Criar validação dos campos
- Email (??)
- Assunto (30 min)
- Criar processo de envio
- Validação de campos preenchidos corretamente (1 hora)
- Envio de informações por email (??)
- Validação da demanda (30 min)
- Montar plano de teste da demanda (15 min)
- Abrir PR para responsáveis (15 min)
No exemplo acima, conseguimos notar que para 2 itens do cronograma, não foi possível estimar, por uma falta de entendimento ou experiência.
Neste caso, o que é recomendado é desmembrar esses pontos e subitens, onde iremos adicionar um tempo para estudo, teste e aplicação.
A recomendação para essa etapa é:
Caso o responsável pela demanda não consiga estimar os itens do cronograma, a demanda não deveria ser iniciada e nem seguir para os próximos passos do plano de ação.
É recomendado que o usuário revise o cronograma, pois ele não está claro o suficente.
Segundo exemplo:
- Configurar ambiente inicial do projeto (2 horas)
- Estudar/Entender documentação do projeto (1 hora)
- Criar campos
- Nome (15 min)
- Email (15 min)
- Assunto (30 min)
- Texto (15 min)
- Criar validação dos campos
- Criar validação do campo de email
- Estudar/Pesquisar (30 min)
- Testar (30 min)
- Aplicar (30 min)
- Assunto (30 min)
- Criar validação do campo de email
- Criar processo de envio
- Validação de campos preenchidos corretamente (1 hora)
- Envio de informações por email
- Estudar/Pesquisar (45 min)
- Testar (30 min)
- Aplicar (1 hora)
- Validação da demanda (30 min)
- Montar plano de teste da demanda (15 min)
- Abrir PR para responsáveis (15 min)
Mesmo com a falta conhecimento ou experiência, conseguimos montar um plano de entendimento e estudo para executar o item. Conseguimos ter um entendimento melhor do que exatamente na demanda teria dificuldade em executar.
Com esse nível de clareza, além de criar um processo de que seja possível o desenvolvimento, também conseguimos criar um processo de solicitação de ajuda para outras pessoas que talvez tenham mais conhecimento/experiência no ponto de dificuldade do plano montado.
5) Desenvolvimento / Execução
Com a estimativa pronta, o quinto passo é listar todos os pontos necessários para começar o desenvolvimento da demanda.
Nesta etapa, iremos listar todas informações, acessos ou impedimento que temos para o início da demanda, como por exemplo, backup do projeto, acesso ao repositório, ambiente de homologação, entre outros.
Podemos entender que a lista seria:
- Acesso ao repositório
- Acesso ao admin WordPress
- Acesso ao ambiente de homologação
- Dados da ferramenta de SMTP
Resultado
Finalizando a lista dos pontos necessários para o início da demanda, a ideia seria adicionar na demanda do Jira, um report com o resultado do plano de ação,
por exemplo:
Cronograma/Estimativa
- Configurar ambiente inicial do projeto (2 horas)
- Estudar/Entender documentação do projeto (1 hora)
- Criar campos
- Nome (15 min)
- Email (15 min)
- Assunto (30 min)
- Texto (15 min)
- Criar validação dos campos
- Criar validação do campo de email
- Estudar/Pesquisar (30 min)
- Testar (30 min)
- Aplicar (30 min)
- Assunto (30 min)
- Criar validação do campo de email
- Criar processo de envio
- Validação de campos preenchidos corretamente (1 hora)
- Envio de informações por email
- Estudar/Pesquisar (45 min)
- Testar (30 min)
- Aplicar (1 hora)
- Validação da demanda (30 min)
- Montar plano de teste da demanda (15 min)
- Abrir PR para responsáveis (15 min)
Total: 10,5 horas
Informações necessárias para o desenvolvimento:
- Acesso ao repositório
- Acesso ao admin WordPress
- Acesso ao ambiente de homologação
- Dados da ferramenta de SMTP
Deixe um comentário