Atualmente, o Instituto Sicoob possui um sistema para acompanhamento e execução dos projetos que são desenvolvidos juntamente ao Instituto. Porém, o sistema não possibilitava a visão ampla da execução dos projetos e tarefas e dificultava o gerenciamento desses projetos durante todo o ano. Guiados por essa dor foi iniciado o processo para a criação de um novo produto que atendesse os requisitos necessários para auxiliar a execução das tarefas e gerenciamento das mesmas.

 
Objetivos

  • 1. Criar um fluxo de tarefas que auxilie os usuários a executarem os projetos, sabendo o que deve ser feito em seguida;

  • 2. Auxiliar no gerenciamento da execução dos projetos em um time distribuído pelo Brasil;

  • 3. Melhoria dos fluxos de tarefas, para otimização dos projetos executados.

 
Processo de Design

Para nos auxiliar na criação de soluções para esses problemas, buscamos seguir um processo para o desenvolvimento do produto ou sua experiência. Para isso, seguimos um processo composto por 4 etapas:


Na prática o nosso processo de design funcionou da seguinte forma:

 
A pesquisa

No início, haviam diversas incertezas sobre qual o melhor caminho a seguir. Então, optamos por começar com entrevistas com os Stakeholders e usuários finais, que são pessoas que gerenciam a execução dos projetos e utilizam o produto com o mesmo objetivo.

Assim, foi possível entender como essas pessoas executam e gerenciam seus projetos no dia a dia, conhecendo suas frustrações e expectativas ao utilizar a versão atual do produto.

Iniciamos com uma lista simples de questões. E, a cada entrevista realizada, obtínhamos diferentes visões com base nas experiências de cada usuário. Viajamos para outro estado para entender melhor a realidade dos mesmos, e as respostas contribuíram para o levantamento das hipóteses que direcionariam o produto.


Entrevista com usuários finais

Uma das principais frustrações que foi colhida das perguntas realizadas foi a de que não era possível ter um fluxo de tarefas a serem realizadas, os usuários não sabiam o que deveria ser feito a seguir e iam realizando as atividades de forma aleatória.

 
Entrevista com Stakeholders

Com o objetivo de também conhecer as frustrações de quem gerencia a execução dos projetos, buscamos estar ao lado de quem realiza esta função, o que nós ajudou a ter mais empatia em um contexto em que o time não estava inserido.

As entrevistas de imersão duraram em média 40 - 80 minutos cada. Sentamos informalmente com cada entrevistado e deixamos que as pessoas falassem sobre seu dia a dia, execução dos projetos, gerenciamento e acompanhamento. Também realizamos experimentações e co-criações junto aos usuários. Assim também foi possível aprendermos com outros produtos que as pessoas utilizavam para administrar seus projetos.


Rafaela, 27 anos:

No início da conversa, Rafaela demonstrou insatisfação com o sistema atual. Alguns problemas relacionados à falta de comunicação e gerenciamento em tempo real dos projetos foram relatados. Para driblar a limitação, ela precisa utilizar outros softwares, somente assim consegue acompanhar o que está acontecendo na execução de seus projetos.

Problema detectado: Não consegui gerenciar os projetos em tempo real gera frustação para o usuário no gerenciamento do projeto.

Para gerenciar os projetos ela precisa acessar outros softwares e fazer o controle através de mensagens recebidas via celular ou E-mail.

Michael, 32 anos:

Como Rafaela, Michael também relatou problemas relacionados a falta de comunicação e gerenciamento em tempo real dos projetos. Além disso, expôs frustrações com a execução de tarefas de forma aleatória e em obter os resultados das mesmas apenas no final do ano, quando os usuários acessam o sistema e submetem todas as ações realizadas durante a execução dos projetos.

Problema detectado:Não ter acesso aos documentos e comprovantes das atividades enquanto ocorrem.Só possui os dados dos projetos no final do ano.

Para gerenciar os projetos ela precisa acessar outros softwares e fazer o controle através de mensagens recebidas via celular ou E-mail.

Quanto mais perguntávamos, mais descobríamos coisas, até identificarmos um padrão com as questões levantadas e com os principais problemas relatados. Isso nos possibilitou o mapeamento do perfil dos nossos usuários e o que cada um desses perfis gostaria que fosse resolvido com a nova solução. A variedade de pessoas nos possibilitou um aprendizado e a geração de hipóteses.

No início, haviam diversas incertezas sobre qual o melhor caminho a seguir. Então, optamos por começar com entrevistas com os Stakeholders e usuários finais, que são pessoas que gerenciam a execução dos projetos e utilizam o produto com o mesmo objetivo.

Assim, foi possível entender como essas pessoas executam e gerenciam seus projetos no dia a dia, conhecendo suas frustrações e expectativas ao utilizar a versão atual do produto.

Iniciamos com uma lista simples de questões. E, a cada entrevista realizada, obtínhamos diferentes visões com base nas experiências de cada usuário. Viajamos para outro estado para entender melhor a realidade dos mesmos, e as respostas contribuíram para o levantamento das hipóteses que direcionariam o produto.

Personas
 

Com a combinação dos dados recolhidos durante a pesquisa e dos padrões identificados, começamos a mapear as personas para nosso produto. Utilizamos, também, a representação dos comportamentos e padrões demográficos.

Aqui estão alguns dos valores gerados a partir da pesquisa e seu desenvolvimento:

- O time aprendeu o valor de falarmos com os usuários para entender o misto de comportamentos e experiências;
- As ideias que eram geradas dentro do time eram enviesadas a partir do nosso background de experiências;
- Aprendemos que existiam um misto de pessoas e experiências dentro do Instituto, mas que conseguiríamos atender as variantes com o produto;
- Houve uma evolução nas ideias geradas, que eram enviesadas e não baseadas nas dores e necessidades dos nossos usuários; - Dando nome aos tipos de usuários, conseguimos ter mais empatia e identificação das pessoas que utilizariam o produto..



 
Definindo o Produto

Com as pesquisas realizadas e as pessoas definidas, tínhamos uma perspectiva de que forma poderíamos começar a olhar a questão. Decidimos então expressar em algumas palavras o que seria o produto baseado na identificação dos problemas.

O que é/ faz o SINS?

O sistema de gerenciamento do Instituto Sicoob é uma evolução do atual sistema, feito para as pessoas que atuam juntamente ao Instituto Sicoob e que necessitam de um sistema mais acessível, fácil de usar e que traga toda a visão gerencial e executora dos projetos que ocorrem durante o decorrer de um ano.

Livre de complexidade, ajudando na escalabilidade da execução de projetos que impactam diretamente no crescimento do negócio. Diferente de outros gerenciadores de tarefa, o sistema do Instituto Sicoob traz a junção de poderosas ferramentas que auxiliam a seguir um fluxo de tarefas com: Fluxo de processos, ajuda na priorização de tarefas, demonstração de uma tarefa por vez ( “evitando a sobrecarga”) além de possuir uma menor esforço para adoção.

Com esse processo nós percebemos que, por muitas vezes, é mais fácil definirmos qual o problema que queremos resolver do que trazermos soluções sem embasamentos iniciais. Depois de alguns dias trabalhados, críticas, dados e materiais coletados durante a pesquisa, o time se unificou na visão do produto e estávamos prontos para começarmos a explorar hipóteses e soluções para o produto.


Hipóteses

Com algumas hipóteses levantadas a partir da pesquisa e problemas reais relatados, nosso processo de construção dos protótipos começou por priorização do que seria a parte principal do produto, pois precisávamos atender a necessidade principal primeiramente.

A partir disso, conseguimos identificar 3 features que teriam muita importância e atenderia as necessidades do usuário que gerencia e do usuário que executa.

Sendo essas 3 features:
- Criação do fluxo de tarefas;
- Criação projeto;
- Execução do projeto.

A partir daí já sabíamos por onde começar, hora de pôr as mãos na massa!

 
Hora de rabiscar

A primeira coisa que fizemos quando foram definidas as features iniciais a serem atendidas foi realizar uma sessão de reunião para gerarmos insumos e chegarmos a uma solução baseados nas necessidades, trabalho feito de forma conjunta por todos os integrantes do time, independente de serem desenvolvedores, Designers, PO ou Scrum Master.

A ideia desse momento é que todos os integrantes participem da solução e deixem todas as ideias saírem para gerarmos mais ideias e questionamentos, maximizando as nossas possibilidades quanto a solução do problema estabelecido anteriormente, sempre acompanhados de um Stakeholder para tomar as decisões chaves.

A partir das ideias geradas pelo time, imergimos nas soluções trazidas para o produto, explorando as soluções tanto de modo técnico como negocialmente. Neste momento era só nós e um quadro branco, sem nenhuma ferramenta digital ainda.

 
Wiframes e fluxos da possível solução

Após muitas discussões, estávamos prontos para iniciarmos a criação das interfaces e protótipos de baixa fidelidade. Exploramos várias versões para as soluções discutidas, até que chegamos a 2 possíveis soluções para o problema. Assim, decidimos seguir em frente e começarmos realmente com Wireframes e protótipos, para levarmos para validação com os usuários e realizarmos um teste A/B. Nisso poderíamos descobrir se estávamos no caminho certo e entender se a solução criada atenderia as necessidades de nossos usuários.

Wiframes e fluxos da possível solução

Após a jornada de criação de Wireframes e protótipos de baixa fidelidade, nós sentimos que chegamos a uma arquitetura de informação, jornadas de usuários e fluxos que faziam sentido e que podiam comunicar o que estávamos propondo sem muita complexidade e uma nova experiência.

Mas agora só nos restava uma coisa... TESTAR!

 
O Teste A/B

Ao final das discussões e criação dos protótipos, chegamos a 2 protótipos com diferentes soluções e levamos as duas para os usuários, para entender qual melhor resolveria o problema em questão.

O Teste A


Ao final das discussões e criação dos protótipos, chegamos a 2 protótipos com diferentes soluções e levamos as duas para os usuários, para entender qual melhor resolveria o problema em questão.

Resultado Final:

Para os dois tipos de perfis de usuários que tínhamos para o teste do produto, definimos algumas missões a serem realizadas, tarefas que habitualmente eles deveriam realizar no dia a dia futuramente.

Resultados


Com a aplicação do teste, conseguimos entender que o fluxograma apresentado daquela forma não faria tanto sentido para os usuários. Isso porque eles não possuíam familiaridade com o mesmo e enfrentaram dificuldades na criação e visualização ao usá-lo. Assim, a experiência dos usuários seria prejudicada, trazendo mais dificuldades na visão deles.

Tínhamos ainda o Teste B para aprender mais com os usuários e chegarmos a uma solução que fizesse mais sentido para os usuários.

 
O Teste B

Na segunda solução, tentamos trazer um equilíbrio para quem gerenciava e para quem executava os projetos., baseados no background dos usuários. Tentamos simplificar o produto sem perder a essência do mesmo.

Missões

Assim como no teste A determinamos missões tarefas a serem realizadas trouxemos para a segunda solução o foco era entender se tínhamos uma solução que faria mais sentido que o fluxograma do Teste A e confirmar outros pontos observados no teste do mesmo.

Resultados


Com a segunda possibilidade, percebemos que os usuários necessitavam de um gerenciador de tarefas sem muita complexidade, onde quem gerenciava, criaria as tarefas-base para quem iria executar o projeto. Assim, não seria necessário seguir fielmente um fluxo, podendo ter a possibilidade de adicionar tarefas, o que possibilitaria a execução e gerenciamento com facilidade e sem burocratizarmos ou gerar retrabalhos com o sistema. Tínhamos, então, o seguinte fluxo para os usuários:

Com isso, conseguiríamos resolver os problemas relatados inicialmente e estabelecermos o propósito do produto:
  • Mescla os melhores produtos atuais, de gerenciamento e execução de tarefas;

  • Você consegue acesso aos dados que precisa do projeto, sem burocracia e a qualquer momento;

  • 100% transparente ao que está acontecendo com o projeto;

  • O produto demonstra para o usuário progressivamente as informações que ele necessita, porém apenas e quando precisar;

  • Traz a liberdade, porém a possibilidade de criação de insumos para o seu projeto, ajudando na melhoria do mesmo;

  • Acessível para usuários menos experientes;

  • Ajuda na melhoria contínua de processos de trabalhos;

    RESULTADO FINAL


    Usuários de gerenciamento:

     
    Conclusão:

    Foi uma jornada de aprendizados. Mas, pela combinação de nossas ferramentas, processos e pessoas, estamos confiantes que conseguimos gerar um produto coesivo e amigável.

    O produto ainda está em fase de implantação, mas já conseguimos ver melhorias em relação ao gerenciamento e a execução de tarefas, além da noção e controle das tarefas em tempo real e acesso aos dados a qualquer momento.

    Estamos levando o produto também para o mobile, o que vai trazer ainda mais liberdade para os usuários poderem acessar informações necessárias quando precisarem.

    Esperamos também que, com os dados gerados, o produto ajude na escalabilidade dos projetos do Instituto Sicoob. Tornando melhor e mais acessível cada projeto e alcançando um número maior de pessoas que serão ajudadas pelos Instituto Sicoob.


     

    Tem um projeto em mente?

    Fale comigo!