Aplicação de Design Thinking no desenvolvimento de APP - Case BATEU

O objetivo deste questionário é mostrar aos desenvolvedores de projetos na Celepar como está sendo aplicado DCU durante o processo de desenvolvimento de sistemas - PDS, através do relato do designer Joserley Barbosa de Oliveira que conduziu essa iniciativa de sucesso.

1. MÉTODO EMPREGADO

1.1. Contextualização sobre o que é o projeto e que tipo de sistema foi desenvolvido

Para atender as situações de acidentes de trânsito, em especial com vítimas, a Polícia Militar necessita - além de prestar socorro aos acidentados - realizar todo registro da ocorrência. Porém, assim que o policial chega ao local, antes de iniciar o Boletim do Acidente, muitas vezes, se depara com situações complexas em que precisa redobrar a atenção: administrar conflitos entre pessoas, dialogar com indivíduos alcoolizados e até lidar com situações extremas, como eventos criminosos. Somam-se a isso, ainda, fatores climáticos como chuva e vento. Só após conseguir administrar o cenário é que se inicia o registro do acidente que até setembro de 2018 era realizado por meio de formulários de papel.

Como forma de aumentar a confiabilidade do processo e agilizar os procedimentos operacionais, foi projetado e desenvolvido um aplicativo que tem proporcionado ganhos qualitativos e quantitativos ao processo. Entre os ganhos qualitativos: tornar a abordagem do Policial Militar em campo mais segura e assertiva, dificultar atos ilícitos e promover maior controle aos gestores, em relação as equipes de policiais em campo (é possível, por exemplo, monitorar as ações ou omissões de um agente). Em termos de ganhos quantitativos o uso do aplicativo, já implantado em Curitiba e Região Metropolitana, potencializou a produtividade do contingente policial em campo, com a diminuição no tempo de atendimento às ocorrências, bem como o da equipe dedicada as atividades em escritório.

Toda a solução foi projetada utilizado técnicas de Design Thinking: do mapeamento dos processos, identificação de gargalos, projeção de soluções até em como definir a forma mais assertiva da implantação da ferramenta nos batalhões da PM de todo o Estado do PR. O aplicativo é de uso exclusivo do Policial Militar. A solução ficou bem robusta, ao isolar-se o conjunto de funcionalidades, pode-se para considerar que há uns 10 aplicativos dentro de um só.

1.2. Método utilizado, etapa por etapa e duração

A metodologia utilizada foi o Design Thinking, cujas etapas foram:

• imersão
• análise e compilação
• ideação
• prototipação
• testes de usabilidade
• implantação e homologação

A etapa de imersão tem como objetivo aproximar-se do contexto do problema. Inicia-se com reuniões de alinhamento estratégico com os profissionais da equipe do órgão ou secretaria. Alguns dos objetivos dessa etapa são: definir o escopo do projeto e seus “limites”, identificar os usuários, mapear a jornada do usuário, bem como dos processos. Em seguida há um processo de análise e compilação dos dados coletados.

A terceira etapa é a ideação, momento em que busca-se gerar ideias inovadoras em cocriação com o cliente e usuários. Das soluções geradas protótipos de baixa fidelidade foram criados para avaliação e testes rápidos; sendo os protótipos inadequados/inapropriados logo descartados.

Por fim, as principais soluções projetadas geraram uma listagem, que passam por uma análise de viabilidade e uma classificação quanto a priorização de cada uma delas, para então serem encaminhadas às equipes de desenvolvimento.

Vale lembrar que essas etapas podem ou não serem realizadas em meio a um workshop/design sprint – depende de cada caso. Um workshop, inclusive, é uma ferramenta do Design Thinking/Design de Serviços.

Com relação a prazos, delimitados em horas, para cada atividade é importante ressaltar que esse conceito se aplica mais a um contexto de workshop/sprint, que por questões do processo da dinâmica delimita-se prazos para realização de determinadas atividades. No caso desse projeto foram realizadas 3 sprints. Entretanto, nem sempre o resultado de uma sprint atinge a profundidade/abrangência necessária para evoluir o projeto (há uma série de fatores que podem influenciar, como a própria delimitação de tempo).

Dessa forma, em especial no caso de projetos complexos, por vezes, se faz necessário que o designer de serviços realize outras atividades complementares. O que vem antes ou depois não tem regra: cada caso é um caso e adaptações, via de regra, são necessárias. Vale ressaltar que atuar com facilitações é uma das “skills” de um service designer.

Um exemplo de atividade complementar, no caso do BATEU Mobile, foram as imersões em campo. Contudo o processo percorrido para mapear e se projetar o protótipos de baixa fidelidade levou em torno de 45 dias. Naturalmente, depois vieram outras fases.

1.3. Quais foram os analistas envolvidos em cada etapa e qual era o papel deles naquele momento?

• Service Designer: mapeamento dos processos; articulação com cliente; repasse e apoio ao desenvolvedor das funcionalidades projetadas; alinhamento das necessidades identificadas com gestor para que providenciasse os devidos encaminhamentos, facilitação dos workshops, UX, design do protótipo, elaboração e execução dos testes de usabilidade com usuários, também na implantação.
• Desenvolvedor do aplicativo: avaliação da tecnologia apropriada, montagem do protótipo navegável, desenvolvimento das funcionalidades projetadas para o aplicativo, mapeamento da arquitetura de webservices necessário para ser provido pelo backend sistêmico.
• Desenvolvedor do backend: Arquitetura e desenvolvimento dos webservices necessários para a integração do aplicativo com o sistema operacional de backoffice.
• Equipe de Qualidade: atuou em conjunto nos testes de usabilidade e de performance

2. TÉCNICAS UTILIZADAS

2.1. Segue abaixo algumas das técnicas e/ou ferramentas utilizadas no processo, algumas delas foram realizadas em workshops/design sprint, outras não.

1) IMERSÃO: iniciou-se com algumas pesquisas relacionadas a temática do projeto, bem como benchmark. Em seguida buscou-se identificar os usuários e/ou stakeholders do projeto, para tanto foram realizadas entrevistas com policiais para compreender suas rotinas de trabalho, dificuldades. Outra técnica utilizada foi o shadowing, que visa acompanhar o usuário em sua atividade e observar sua interação com o produto/serviço. Trata-se de uma atividade em que o pesquisador não deve interagir com o usuário, mas sim observa-lo.

2) ANÁLISE E COMPILAÇÃO: mapa de empatia ferramenta que visa reunir algumas informações a respeito do usuário como o que ele diz, faz, pensa e sente. Também foram criadas algumas personas(personagens fictícios) criados a partir da análise sintetizada das informações coletadas a respeito dos usuários. Outra ferramenta foi a criação da Jornada do Usuário, a qual trata-se de uma representação das etapas com as quais o usuário interage com o produto/serviço.

3) IDEAÇÃO: nessa etapa buscou-se gerar ideias “inovadoras" em cocriação com o cliente e usuários. Através de atividades em grupo rodamos um workshop/design sprint que visou estimular a criatividade e a colaboração do grupo. As soluções propostas passaram por uma análise de viabilidade e classificação quanto a priorização junto ao grupo.

4) PROTOTIPAÇÃO: essa é a etapa de materialização de uma ideia, a passagem do abstrato para o físico. Em um dos workshops trabalhou-se uma atividade em que se colocou o grupo a dar forma as ideias. Nesse caso o resultado foram protótipos de baixa fidelidade (wireframes), que num segundo momento serviram de referência para que o designer projetasse as funcionalidades num protótipo de alta fidelidade, que posteriormente foi encaminhado a equipe de desenvolvimento.

5) TESTES DE USABILIDADE: foram adotados dois formatos de testes. Primeiramente foram utilizados os chamados “testes de guerrilha”, os quais foram aplicados durante um dos workshops com os protótipos de baixa fidelidade. Num segundo momento, além da análise heurística, foram realizados testes mais estruturados com usuários.

2.2. Existe um protocolo, um modelo, um roteiro ou um passo a passo que foi utilizado? Há um registro deles que possa ser acessado, para que outros desenvolvedores entendam o que foi perguntado, analisado, observado, investigado?

Há um volume grande de informações mapeadas ao longo do processo os quais proporcionaram  alicerce a solução projetada. Entretanto, a maioria delas não estão catalogadas/compiladas de forma didática de modo que possa ser reaproveitada. Contudo, ficamos a disposição para ajudarmos no que for necessário, inclusive respondendo a dúvidas ou dando direcionamentos a colaboradores que tenham interesse em aprender e se aprofundar na metodologia.

3. FOCO DCU

3.1. Em que momento e como aconteceu o envolvimento dos usuários (ou seja, de quem vai utilizar o sistema de fato)?

É importante ressaltar que uma sprint/workshop é apenas uma das ferramentas do Design de Serviços. Ou seja, mesmo não estando em um workshop o usuário também é envolvido no processo desde o inicio. Por exemplo: em pesquisas (quantitativas e qualitativas), em entrevistas, também na realização de testes de usabilidade entre outros. Durante as sprints os usuários foram envolvidos de outras maneiras, mais focados em atividades nas quais eles colocavam a “mão na massa".

3.2. Como foram identificados e como se chegou a esses usuários?

Através de entrevistas.

3.3. O que foi utilizado para coletar dados com esses usuários?

Foi elaborado um roteiro de entrevista.

3.4. Como foram sintetizadas as informações coletadas com esses usuários?

Mapa de empatia, criação de personas, jornada do usuário.

3.5. Houve algum controle pós-uso e/ou alguma avaliação da aceitação do produto pelos usuários? Como isso ocorreu e quais instrumentos foram utilizados?

Como os usuários foram envolvidos em várias etapas do processo, o impacto no pós refletiu-se positivamente. Ainda assim monitoramos os feedbacks, sendo alguns recorrentes como a limitação do sinal de internet em algumas regiões, o que impacta em algumas funcionalidades do APP. Já Temos a solução para essa questão, inclusive já priorizada pelo cliente; entretanto algumas atividades levantadas no processo fogem a atuação da equipe mobile, como a criação de uma base off-line de mandatos por exemplo. Outra questão é a limitação de hardware dos smartphones disponibilizados pela policia. Há um processo licitatório em andamento, mas atualmente os dispositivos oferecidos são obsoletos com algumas limitações. Ou seja, nosso backlog que foca na melhora continua da solução já bem extenso, mas algumas questões fogem um pouco ao nosso alcance.

4. CONSIDERAÇÕES FINAIS

4.1. Breve relato dos desafios, obstáculos e pontos interessantes que podem ser relevantes para seus colegas, diante do que aconteceu no case de construção do APP BATEU

• Implantação de um processo novo de concepção de projetos precisa ser acompanhado de uma revisão de papéis atuantes no processo vigente, para que os projetos possam andar com maior fluidez;
• Revisão da estrutura de dedicação exclusiva de equipes a órgãos para se ter flexibilidade na atuação de equipe de projetos distintas em nicho de negócios existentes, para facilitar a revisões de processos e/ou adoção de novas tecnologias;
• Estabelecimento de um processo de recepção de demandas na Celepar, para caracterizar de forma mais clara a responsabilidade de cada setor dentro da esteira fim-a-fim dos projetos, entre a concepção-implantação-sustentação.

4.2. Em todo percurso de seu case, você sentiu a falta de alguém que exercesse um papel específico? Qual?

Via de regra toda nova utilização de metodologia para se projetar produtos/serviços despende uma boa dose de energia, isso era previsto. Contudo um alinhamento mais vertical, direcionado pela estratégia da empresa – certamente – facilitaria a “abertura” de algumas portas, potencializando os resultados, bem como a evangelização do processo e envolvimento de outras equipes.

4.3. Como o processo que você vivenciou em seu case pode ser replicado em outros projetos da empresa? Complemente sugerindo em quais tipos de projetos, em quais etapas e em qual estrutura eles seriam adequados.

O design de serviços possui uma infinidade de técnicas/ferramentas, a variação da utilização dessas vai depender de fatores como nível de complexidade e tempo disponível basicamente. Sua utilização é recomendada na etapa de Discovery, ou seja, no inicio do projeto, quando a proposta ainda está no campo de uma simples “ideia”, a qual necessita ser avaliada para então tornar-se – ou não – um produto/serviço. Entretanto, o método também pode ser utilizado pontualmente para evolução ou criação de uma nova funcionalidade a um produto, por exemplo.