Design Sprint sempre vai resultar em um sistema ou aplicativo?

Olá Gustavo, tudo bem =D

Isso não é uma limitação da metodologia não, usamos como referência este exemplo em aula pois se aproxima muito do dia a dia dentro de uma empresa de tecnologia.

Mas a etapa de storyboarding do design sprint visa trazer uma solução visual para o protótipo apresentado.

Pensando em uma campanha de marketing por exemplo o storyboarding visária mostrar as etapas em um protótipo. Quais as informação virão da camapanha, dimensões na qual se deve construir cada elemento e assim por diante.

A palavra chave nesta etapa é protótipo, precisa ser algo funcional e testável para a solução desejada. Mas não necessariamente precisa ser uma tela de um aplicativo, depende do que você esta soluciando usando esta metodologia.

Não sei se me fiz claro, faz sentido pra ti?

O que você disse faz sentido.

É a primeira vez que estudo detidamente sobre Design Sprint, mas tudo o que eu já vi a respeito de forma espalhada por aí, sempre o foco é a construção de um sistema ou aplicativo (ou uma parte de um sistema ou aplicativo). Aqui no curso, mais uma vez esse foi o exemplo dado - e nenhum outro exemplo foi usado. Claro que o curso tem que ter um foco, mas seria interessante ter essa abertura para outras coisas.

Vejo que há uma tendência, de forma geral, que as pessoas vejam um novo sistema ou aplicativo, ou um novo módulo, ou uma nova funcionalidade, como a solução para um problema, ou como um meio para alcançar o objetivo de longo prazo. Isso é o que me incomoda, que a metodologia "force" para isso, seja tendenciosa do sentido de que já parta do princípio que o resultado, ao final, é a recomendação da implementação de um sistema ou aplicativo. Me preocupa, portanto, que outros caminhos para chegar à visão de longo prazo sejam ignorados.

Por exemplo, possíveis caminhos poderiam ser:

• A modificação de algo já existente no sistema/aplicativo.
• A supressão de alguma funcionalidade (ou seja, remover coisas em vez de criar coisas).
• A modificação no modelo de negócio, por exemplo, mudar a forma de remunerar os entregadores.

Na prática, quem já tem mais experiência na realização de Design Sprints, vê esse "viés de implementação"? Ou há abertura suficiente para se chegar a outros tipos de solução?

Como existe a etapa de protótipo essa exemplificação palpável como aplicativo, novas funcionalidades é realmente sempre o mais usado como exemplo e é até bem didático, acho que por isso essa escolha em vários momentos e em vários lugares.

Mas por ser uma metodologia de trabalho, é um fluxo que pode ser seguido por um time de diversas formas e em diversos projetos.

Mas você tem toda razão é muito dificil desvincular e é um receio válido. Por que existem outras metodologias, e essas outras metodologias podem conversar melhor com um processo de gestão e construções mais abstratas.

É uma discussão interessante.

Ao meu ver, por mais que os exemplos sejam sempre assim. Se eu trocar a palavra protótipo por MVP eu consigo abstrair mais o vinculo com criação de um novo aplicativo.

Por que a ideia da metodologia e que sempre ganha muito espaço é o fato de você poder testar rápido, errar rápido para ajustar rápido.

Então ter algo paupável é importante, por exemplo na modificação de um modelo de negócio é importante conseguir colocar isso a prova de alguma maneira para aplicar a metodologia. nem que seja por simulação.

O viés de implementação é o coração da metodologia, por isso é tão dificil abstrair.

Mas se a gente pega como referencia a logistica de entrega de ração de uma petshop para clientes a X KM de distancia.

é possível criar soluções através da metodologia, e é diferente de criar um app. Mas no storyboard vai ser necessário colocar a prova um MVP quais mudanças logisticas existirão e como podemos fazer esse teste rápido para validar a ideia saca.

É uma discussão muito legal essa man, e eu agora estou com muito mais ideias na cabeça na verdade, não sei se ajudei em mais alguma coisa mas estou tentnado formular mehor ainda isso tudo.