Некоторое время назад мы на работе проводили догфуддинг.

Догфуддинг — это когда компания применяет свои собственные продукты или технологии, прежде чем они становятся доступными для клиентов. В IT это означает, что разработчики и сотрудники компании используют программы и приложения, которые они создали, в своей повседневной работе. Таким образом, они могут проверить удобство и работоспособность продукта, найти и исправить ошибки, прежде чем продукт попадет к пользователям.

У нас это был догфуддинг перед запуском новых фичей для сайта. Так как наш продукт специфичный (как, я думаю, многие продукты в IT), у нас нет возможности использовать его каждый день на работе. Поэтому догфуддинг нужно организовывать специально.

Как это проходило

Под догфуддинг был выделен день, когда разработчики (и не только) могли попользоваться тем, что сделали сами.
Для этого были подготовлены данные на сайте и сценарии. Нужно было пройти их как пользователь, чтобы решить определенную задачу.
В процессе мы заводили баги и фича-реквесты. Дополнительно была настроена статистика, кто сколько багов и фичей завел, это добавило игровой механики и дух соревнования.

Что в результате

По итогу догфуддинга мы завели 67 багов и 22 фича-реквеста. Если вы думаете, что это слишком много, то лично мне так не показалось)
Во-первых, это был первый раз с начала разработки, когда мы “отошли подальше”, чтобы посмотреть на всё то, что было сделано.
Во-вторых, не все из этих багов и фичей были приоритетными. Мы руководствовались принципом “записывай все, что приходит в голову, а потом разберемся”. Лучше записать и потом с командой решить, что это неактуально, чем упустить какой-то важный момент. Мне это напоминает принцип Inbox-а из GTD.
К тому же, часть багов и задач дублировали друг друга. Дубли закрывались уже после окончания догфуддинга, чтобы не тратить на это время сразу.


Я уже не первый раз сталкиваюсь с догфуддингом на работе. Каждый раз для него могут быть разные цели: познакомиться с продуктом, который вы делаете (например, для новеньких в команде или при передаче проекта от одной команды к другой), или понять, какие боли испытывают ваши пользователи, возможно, некоторые из них можно решить двумя строчками кода.
В нашем случае догфуддинг показал, где решения в нашем продукте были еще сырыми и недоработанными.

От меня точно лайк такой практике!)