Цикл строгости – как он помогает улучшать качество ваших проектов Сегодня я хотел бы поговорить о рефлексии. Причём не о простой, а о профессиональной, направленной на проработку и улучшение качества рабочих процессов. Примерно год назад, на лекциях по методам HCI в Вышке, я разбирал со студентами статью A Three Cycle View of Design Science Research. В этой статье Алан Хефнер, профессор Университета Южной Каролины, предлагает схему того, как может работать процесс продуктовых исследований. Особенный интерес у меня вызвал завершающий элемент схемы — цикл строгости, так как, на мой взгляд, этот этап (1) применим не только к исследованиям, но и вообще ко всем видам деятельности; (2) этот цикл часто упускают из виду, хотя он приносит значительную пользу. Попробую объяснить, почему, а вы дальше судите сами. Если коротко, Хефнер выделяет три основных цикла продуктовых исследований: 🔸 Цикл релевантности — когда мы ищем проблему среди пользователей, которую хотим решить. На данном этапе, как правило, мы используем разные методы "discovery" типа глубинных интервью, включённых наблюдений, дневников и т. д. 🔸 Цикл дизайна — на этом этапе дизайнеры проектируют решение, а мы его тестируем. Здесь выходят на сцену юзабилити-тесты, разные first-click тесты, опросы и т. д. 🔸 Цикл строгости — шаг, на котором мы фиксируем всё в базу знаний. Причём это не только про результаты исследований и отчёты, но и про рефлексию о процессах, методах и теориях, на которые вы опираетесь. По своему опыту знаю, что базы знаний в компаниях содержат, как правило, результаты исследований и описание методов/процессов. И это здорово: если в вашей компании есть такая база знаний, то всё уже очень круто. По крайней мере, хорошо описанные процессы и чётко зафиксированные результаты помогают всем участникам процесса использовать исследования наиболее эффективно. Однако есть один момент, который упускается почти всегда, либо не имеет систематического характера. На мой взгляд, неотъемлемой частью цикла строгости должна быть регулярная рефлексия о том, как проходил каждый проект. В своей практике я использую очень простую схему: в ходе каждого проекта я фиксирую для себя все недочёты и, наоборот, удачные моменты. Причём это могут быть как супер мелкие моменты типа: "перепутал имя респондента в письме" или "неуклюже попрощался в конце интервью"; так и более объёмные вещи: “вовлечение продакта в интервью улучшили процесс” или "прототип был слишком 'стоковым' — это сбивало с толку пользователей". К завершению проекта у меня получается небольшой список, который я потом разбиваю по очень простой схеме: переношу его в Figjam/Miro на стикеры и распределяю их по двум категориям — "what was good" и "what went wrong". После этого я генерирую идеи, как можно улучшить процесс, основываясь на этих пунктах. В завершение я трансформирую идеи в действия и планирую их применение в следующих проектах. Цикл строгости как подход к анализу проектов универсален и подходит не только для исследователей. Судите сами: если вы анализируете свои действия и фиксируете результаты рефлексии, даже на подсознательном уровне вам будет легче не допустить прежних ошибок. А теперь вы расскажите, делаете что-то такое? И если да, то в какой форме? 🗿