: :
os agilistas

ENZIMAS #202 Jobs To be Done para definir os próximos passos do projeto

ENZIMAS #202 Jobs To be Done para definir os próximos passos do projeto

os agilistas
: :

Clarissa: Oi, gente. Meu nome é Clarissa, eu sou Design de Produto. Eu vou comentar um pouco com vocês sobre um processo de Discovery, que realizei recentemente, em um produto que a gente está trabalhando para uma mineradora. A gente começou a fazer uma nova plataforma para eles e, conforme o time de desenvolvimento foi começando o processo de implementação do produto, os próximos passos para onde nós iríamos começaram a ficar um pouco menos claros — para mim, enquanto designer, até o ponto aonde a gente chegou e começou a desenvolver. Estava tudo certo e depois foi ficando um pouco mais difícil de entender para onde nós iríamos.

Eu estava um pouco confusa e me vendo em um beco sem saída, sem saber para onde eu iria seguir em um processo de discovery; sabendo que eu precisava estar um passo à frente deles, pelo menos, para a gente continuar fazendo um bom dual track. Isso eu percebi, principalmente, durante um processo, que a gente tem aqui na DTI, chamado Check de Produto e Design, que foi quando a gente identificou esse possível risco. A partir disso, eu tive uma conversa com os meus POs e eu comentei sobre essa dificuldade. Uma das minhas POs me passou um material para estudar sobre Jobs To Be Done, porque nós identificamos que havia um gap no nosso produto, nessa área. A partir dos estudos desse material que ela me passou, eu me deparei com uma ferramenta chamada Job Map. Ela trazia um color bem legal para mim — melhor do que a ferramenta de jornada estava me trazendo naquele momento —, mas eu ainda sentia que alguma coisa estava faltando. Eu sentia que precisava de alguma coisa que estivesse entre a jornada e o Job Map.

Então, a partir disso, eu desenvolvi uma ferramenta que mistura o Job Map com um pouquinho de outras coisas. Ela começa, assim como um Job Map convencional, definindo a área do processo que você vai mapear — você define o Jobs To Be Done dela; em seguida, você define os oito passos do Job Map, sendo que você pode incluir menos ou mais passos, vai depender das especificidades do seu produto; em seguida, você descreve, o que eu gosto de chamar de micro jobs, mas o Tony Ulwick — que é o idealizador dessa ferramenta, o Job Map —, ele chama de Jobs Relacionados. Mas como existem vários mapeamentos de jobs nesse processo, eu sinto que Jobs Relacionados é um nome que pode gerar um pouco de confusão. Então, eu acabo chamando esses jobs específicos, de cada etapa, de micro jobs.

A diferença entre o processo convencional do mapeamento do Job Map e o que implementei foi que, depois desse passo que você define os micros jobs, você passa para o momento seguinte, em que você descreve como aquilo é realizado no seu produto naquele momento. A ideia é que, após o mapeamento desses micros jobs, você responda como o seu usuário realiza essas tarefas hoje em dia. Não só isso, mas junto você já faça uma matriz CSD. Então, conforme você vai descrevendo como aquilo é realizado hoje em dia, você vai mapeando, ao mesmo tempo, as suas certezas, suposições e dúvidas. Ao final desse mapeamento, a gente volta para um processo um pouco mais convencional do Job Map, que é a definição de desired outcomes. Ao finalizar tudo isso, a ideia é sair com uma visão mais holística do seu produto, de uma forma que você consiga ter mais clareza, não só para onde você pode ir, mas de onde você está. E aí é um excelente material para fornecer insumo para os próximos passos de Discovery, porque você sai com uma matriz CSD, que você pode explorar em entrevistas com o seu usuário, mas você também sai com desired outcomes, que você pode explorar em futuros processos de priorização. Como é a ideia de um desired outcome, ele é algo focado na metrificação, então, você já sai com uma informação potencialmente metrificável.

É isso, gente. Apesar desse material ser excelente para direcionamentos futuros de Discovery, é importante ressaltar que ele não é um substituto da Jornada de Usuário, ela continua sendo extremamente relevante.

Ele é uma alternativa para quando você sente que você ainda não tem insumo suficiente para fazer essa jornada ou você já fez essa jornada, e precisa de alguma coisa que incremente mais.

Caso vocês implementem essa solução, eu espero que ela os ajude no direcionamento, assim como ela me ajudou bastante. É isso. Muito obrigada por ouvirem. Tchau, tchau.

Clarissa: Oi, gente. Meu nome é Clarissa, eu sou Design de Produto. Eu vou comentar um pouco com vocês sobre um processo de Discovery, que realizei recentemente, em um produto que a gente está trabalhando para uma mineradora. A gente começou a fazer uma nova plataforma para eles e, conforme o time de desenvolvimento foi começando o processo de implementação do produto, os próximos passos para onde nós iríamos começaram a ficar um pouco menos claros — para mim, enquanto designer, até o ponto aonde a gente chegou e começou a desenvolver. Estava tudo certo e depois foi ficando um pouco mais difícil de entender para onde nós iríamos. Eu estava um pouco confusa e me vendo em um beco sem saída, sem saber para onde eu iria seguir em um processo de discovery; sabendo que eu precisava estar um passo à frente deles, pelo menos, para a gente continuar fazendo um bom dual track. Isso eu percebi, principalmente, durante um processo, que a gente tem aqui na DTI, chamado Check de Produto e Design, que foi quando a gente identificou esse possível risco. A partir disso, eu tive uma conversa com os meus POs e eu comentei sobre essa dificuldade. Uma das minhas POs me passou um material para estudar sobre Jobs To Be Done, porque nós identificamos que havia um gap no nosso produto, nessa área. A partir dos estudos desse material que ela me passou, eu me deparei com uma ferramenta chamada Job Map. Ela trazia um color bem legal para mim — melhor do que a ferramenta de jornada estava me trazendo naquele momento —, mas eu ainda sentia que alguma coisa estava faltando. Eu sentia que precisava de alguma coisa que estivesse entre a jornada e o Job Map. Então, a partir disso, eu desenvolvi uma ferramenta que mistura o Job Map com um pouquinho de outras coisas. Ela começa, assim como um Job Map convencional, definindo a área do processo que você vai mapear — você define o Jobs To Be Done dela; em seguida, você define os oito passos do Job Map, sendo que você pode incluir menos ou mais passos, vai depender das especificidades do seu produto; em seguida, você descreve, o que eu gosto de chamar de micro jobs, mas o Tony Ulwick — que é o idealizador dessa ferramenta, o Job Map —, ele chama de Jobs Relacionados. Mas como existem vários mapeamentos de jobs nesse processo, eu sinto que Jobs Relacionados é um nome que pode gerar um pouco de confusão. Então, eu acabo chamando esses jobs específicos, de cada etapa, de micro jobs. A diferença entre o processo convencional do mapeamento do Job Map e o que implementei foi que, depois desse passo que você define os micros jobs, você passa para o momento seguinte, em que você descreve como aquilo é realizado no seu produto naquele momento. A ideia é que, após o mapeamento desses micros jobs, você responda como o seu usuário realiza essas tarefas hoje em dia. Não só isso, mas junto você já faça uma matriz CSD. Então, conforme você vai descrevendo como aquilo é realizado hoje em dia, você vai mapeando, ao mesmo tempo, as suas certezas, suposições e dúvidas. Ao final desse mapeamento, a gente volta para um processo um pouco mais convencional do Job Map, que é a definição de desired outcomes. Ao finalizar tudo isso, a ideia é sair com uma visão mais holística do seu produto, de uma forma que você consiga ter mais clareza, não só para onde você pode ir, mas de onde você está. E aí é um excelente material para fornecer insumo para os próximos passos de Discovery, porque você sai com uma matriz CSD, que você pode explorar em entrevistas com o seu usuário, mas você também sai com desired outcomes, que você pode explorar em futuros processos de priorização. Como é a ideia de um desired outcome, ele é algo focado na metrificação, então, você já sai com uma informação potencialmente metrificável. É isso, gente. Apesar desse material ser excelente para direcionamentos futuros de Discovery, é importante ressaltar que ele não é um substituto da Jornada de Usuário, ela continua sendo extremamente relevante. Ele é uma alternativa para quando você sente que você ainda não tem insumo suficiente para fazer essa jornada ou você já fez essa jornada, e precisa de alguma coisa que incremente mais. Caso vocês implementem essa solução, eu espero que ela os ajude no direcionamento, assim como ela me ajudou bastante. É isso. Muito obrigada por ouvirem. Tchau, tchau.

Descrição

Como usar o método Jobs to be done no processo de discovery? No Enzimas de hoje, Clarissa Reis, Designer de Produto na dti, explica mais sobre essa metodologia para entender as questões dos usuários e clientes. Dá o play!


Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no 
Telegram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!

See omnystudio.com/listener for privacy information.