Projeto contínuo em desenvolvimento: metodologia e princípio

Na prática, acontece que você desenvolveu um produto e, após o lançamento, os clientes não o usam como pretendido. Acontece que as tarefas do usuário são diferentes e são contrárias ao desenvolvimento planejado do produto e à sua visão do projeto. Porque


De fato, você está trabalhando com uma tarefa do usuário que não é totalmente compreendida e que muda sob a influência do produto. Isso sugere que o produto precisa ser finalizado, além disso, emparelhado com o cliente. Portanto, você se protege imediatamente de criar soluções desnecessárias baseadas apenas em hipóteses.


Eu acho que é melhor criar comunicação com o usuário de acordo com o princípio do design contínuo, que será discutido no artigo.



Caro e duvidoso caos de TI


A maioria dos produtos e funções fornecidas pela TI não encontra aplicação prática. Recursos, aplicativos, software permanecem não reclamados. Nem todas as empresas pensam se seus produtos são realmente necessários.


Uma prova vívida é o mercado de desenvolvimento móvel, que possui indicadores mensuráveis. Embora as melhores práticas estejam concentradas aqui, as estatísticas deixam muito a desejar: em 2017, a empresa analítica Localytics publicou um estudo Sql , do qual se conclui que 24% dos aplicativos são abertos apenas uma vez pelos usuários.



Isso leva em consideração o fato de que a porcentagem de usuários que abriram o aplicativo menos de 10 vezes não excede 63% . Se levarmos em conta a "estabilidade" das estatísticas, fica claro que não são tiradas conclusões. As pessoas sabem como se desenvolver, mas sentem falta do aspecto de como o produto entra na vida de uma pessoa, ou seja, elas não usam o modelo centrado no homem. O último envolve interação de longo prazo com o cliente; geralmente por vários anos.


Isso nos leva à conclusão: em uma abordagem centrada no cliente, você precisa recorrer às práticas de desenvolvimento existentes, como DevOps, ágil ou scrum, que geralmente são aplicadas separadamente. Mas se os combinarmos, obtemos algo mais chamado de design contínuo. Consiste nos princípios clássicos do DevOps e no design thinking. Propomos considerá-lo e adotá-lo, mas para implementar o princípio no desenvolvimento, é necessário reconsiderar o relacionamento entre os dois componentes: design e operações.


Introdutório de operações e design


Operações são o que está acontecendo agora. Isso pode ser administração do sistema, suporte ao usuário, processos de negócios. As operações são criadas em modelos diferentes, por exemplo, usando os DevOps mencionados. Ele fornece um processo contínuo de feedback, melhorias e entrega de soluções. Um "loop" é criado a partir do feedback, planejamento, busca de soluções e sua apresentação. E para cada uma das etapas, existem ferramentas que ajudam no trabalho, automatizam os processos e fornecem uma troca constante de informações e soluções.



Design é tudo o que está envolvido na definição de ações, métodos de construção e maneiras de embalar um produto para o consumidor. Normalmente, abordamos o design como uma solução para um problema. Se entendermos a essência do problema, podemos oferecer a solução certa.


Essa é uma abordagem tradicional.


4 circunstâncias que a abordagem tradicional não leva em consideração


Mas, ao combinar design e operações, surgem quatro fatores que anteriormente funcionavam separadamente para as equipes. E para esses aspectos, o design contínuo se torna a solução:


# 1 O problema não pode ser totalmente compreendido.

Com a ajuda de análises e pesquisas, hipotetizamos como as pessoas usarão o produto, mas elas dão uma idéia incompleta do problema, pois não podemos cobrir todos os seus aspectos. Somente quando o produto cai nas mãos do consumidor, vemos como ele foi útil para ele, quais tarefas ele ajudou a resolver ou o que mudou.


Um exemplo simples: no jeans, há um pequeno bolso para um relógio. Foi inventado por Levi Strauss em 1873. Desde então, ninguém usou o bolso para a finalidade a que se destina. A empresa até lançou um vídeo inteiro dedicado a isso.


# 2 Produto muda consumidor

A experiência ativa na interação com o produto muda o usuário. E isso transforma o problema que o produto resolve, o que cria novas dificuldades para você e o cliente.


Lembre-se de como pedimos um táxi há 5 a 6 anos: o operador do outro lado do fio aceitou o pedido e disse que o carro seria servido em 20 a 30 minutos. E estávamos prontos para esperar. Com o lançamento de serviços como Uber, Gett e Yandex.Taxi, nossa percepção mudou: em 2018, o momento ideal para entregar um carro é de 2 a 3 minutos para nós. Se esperarmos mais, começa a ficar chato. E o ponto não está na digitalização ou na uberização, mas na mudança de nosso modelo de consumo.


# 3 Valor é algo criado em conjunto

O valor de um produto não pode ser imaginado no momento de sua criação. Após o lançamento, o serviço começa a viver sua própria vida e a ganhar um novo valor, que é formado durante o uso. Algumas funções estarão em demanda, enquanto outras não. E o valor criado por você e pelo consumidor amadurece. Portanto, muitas vezes a utilidade permanece não óbvia até que um bem ou serviço seja usado.


Lembre-se da AppStore, que parecia contrária à percepção de valor da Apple. Em 2007, Steve Jobs apresentou ao iPhone as palavras: “Você não precisa escrever programas. É inútil: você tem html5. " Isso não impediu os usuários: eles invadiram dispositivos e escreveram seus softwares, distribuídos pelo aplicativo Cydia. Foi lançado em março de 2008 e, em 10 de junho daquele ano, os caras de Cupertino adotaram a experiência bem-sucedida e lançaram a AppStore, mudando a situação a seu favor e se tornando o número 1 no mercado móvel.


Esta tese nos leva à conclusão de que o desenvolvedor e o consumidor fazem parte do problema e da solução.


# 4 Dificuldade elimina o controle

Estamos constantemente criando sistemas complexos que não podem ser totalmente controlados. E isso leva a falhas e erros inevitáveis ​​neles. Um dos principais problemas com o trabalho com esses sistemas é a tentativa de controlar em muitos níveis, quando você pensa cuidadosamente sobre o que vai acontecer ou pode acontecer.


Estou certo de que todos já ligamos para o suporte ao cliente, onde fomos redirecionados muitas vezes para diferentes operadoras. E, repetidamente, descrevemos o problema e esperamos uma resposta para a música de fundo da empresa. São casos em que o serviço - os operadores - é pensado com muito cuidado. Os funcionários têm algoritmos de comunicação com o cliente que são constantemente correspondidos e detalhados. Em vez de servir o benefício dos interesses do usuário, eles apenas complicam e confundem o sistema. Devido à política da empresa, um único operador não pode resolver seu problema, mesmo que seja simples. Ele simplesmente precisa redirecioná-lo para outra pessoa.


Software de digitalização



Veja a evolução do iPod

Esses fatores não contabilizados afetam não apenas o mundo digital, mas também o mundo físico. Está se tornando mais difícil adquirir experiência que não inclui um componente intermediário de software. O ambiente em que vivemos é verificado por software, e isso altera a percepção das coisas e a maneira como as usamos.


Por exemplo, a Tesla lançou uma atualização de software que aumenta a vida útil da bateria do carro. Ao mesmo tempo, suas características físicas são aprimoradas: agora você pode ir não apenas ao supermercado ou ao trabalho, mas também à cidade vizinha. Não o número de viagens e nem a duração da viagem mudaram, mas a qualidade do carro e, com eles, a compreensão das tarefas e propósitos de seu uso. Agora você não precisa gastar dinheiro em um táxi ou colocar outras restrições, porque a bateria dura 2 vezes mais. Uma máquina fecha todas as tarefas de seu proprietário.


Marca se afasta da promessa de diálogo


Se tudo ficou mais claro com as operações e o design, um conceito maior e mais abstrato da marca permanece. Ele também trabalha em um monte de design contínuo.


Costumávamos tomar a marca como uma promessa. Por exemplo, estabilidade ou imutabilidade. Mas agora sua base está mudando para o diálogo, porque vivemos em um paradigma de mudança de valores. E o diálogo com o usuário não deve ser unilateral, está ligado à comunicação constante.É exatamente o ambiente em que isso é feito mais rapidamente. Afinal, temos ferramentas para fornecer feedback constante em diferentes níveis: dos serviços analíticos externos aos métodos do DevOps.


A TI se torna um ambiente de diálogo contínuo


Começamos a mudar o produto sem parar, graças ao feedback do cliente, que observamos e cujas ações analisamos. Portanto, o loop do DevOps se aproxima do infinito quando operações, desenvolvimento, design e marketing estão envolvidos nesse processo: selecionamos uma solução dentre várias, a implementamos e vemos como ela se comporta na prática. É dessa forma que o design contínuo funciona.


Paradigma de Design Contínuo


E para que o design se torne um diálogo fascinante, existem 4 recomendações:


# 1 Projetar interações cliente-funcionário nos pontos de contato

Crie uma experiência do usuário antes de liberar um produto. E é necessário estudá-lo não apenas em condições ideais quando o produto ou serviço é usado corretamente, mas também onde o cliente entra em contato com os processos de negócios: um back office ou arquitetura de TI. Projetar a experiência com base no ambiente externo e no estilo de vida do usuário ajuda a identificar como o produto e os funcionários com os quais ele interage se encaixam na vida da pessoa. Também esclarecerá qual será o terreno comum com as divisões da empresa e sob quais condições. Você pode usar CJM e clientes e colegas de trabalho a realizar para isso.


# 2 Minimize o atraso, maximize o feedback

Metodologias de desenvolvimento flexíveis, como a prática ágil e DevOps, oferecem mais do que velocidade e entrega de atualizações ou versões beta. Utilizando-os, podemos obter rapidamente feedback, testar hipóteses e ajustar ações para melhorar ainda mais o produto. Aprendemos com cada sprint de trabalho ou atualização de produto e extraímos o conhecimento ao longo do ciclo de vida de serviço.


# 3 Design para erros. Faça para estudar

Transforme mergulhos em informações que atendem aos seus interesses e aos do usuário. Erros são inevitáveis ​​em todas as etapas, seja projetando funções ou desenvolvendo uma campanha de marketing. Mas você precisa estar preparado para eles e criar um design contínuo para perceber o erro a tempo e tirar conclusões. É importante usar práticas Lean UX, como testes UX, testes AV, hipóteses e assim por diante.


No final, é formada uma cultura de trabalho com bugs e as ferramentas que ele cria: como o Chaos Monkey ou o Blameless post mortem.


# 4 O conceito de "concluído" não existe

Estamos em uma situação em que o problema não pode ser totalmente compreendido e a solução ao mesmo tempo o altera. Portanto, a equipe não pode simplesmente seguir as hipóteses sobre o valor do produto e projetar ainda mais a arquitetura e o serviço de TI. Em vez disso, você precisa observar como os produtos e serviços funcionam quando ficam fora de controle. O feedback no loop do DevOps é inútil até que as operações e o mundo externo influenciem o processo de melhoria do produto. E, neste caso, o conceito de "pronto" é excluído. Você está constantemente mudando o produto. Isso significa que o processo continua ainda mais no sistema DevOps e no design thinking.


Trabalhar no paradigma de design contínuo ensina a responder rapidamente a erros, é mais fácil se relacionar com eles e não fazer um trabalho inútil. Sua vantagem é que, passo a passo, mais e mais tarefas do cliente são encerradas, o que gera lucro adicional e tem um efeito benéfico nos negócios.



ps A redação deste material foi inspirada na performance de Jeff Sassna.

Source: https://habr.com/ru/post/pt417911/


All Articles