Термин «догфудинг» (буквально: «поедание своего собственного собачьего корма») обозначает практику, когда компания использует в работе свои собственные продукты. Есть и более аппетитные выражения, например, «пьем собственное шаманское», «едим то, что сами приготовили». В некоторых компаниях такую практику описывают как принятие роли «нулевого клиента». Вне зависимости от названия, цель регулярного использования самодельных продуктов состоит в том, чтобы стать их первым и самым ценным пользователем, активнее собирать обратную связь от аудитории и быстрее вводить инновации.
Идея применения созданных продуктов внутри компании не нова. Всем хорошо известна история о том, как в начале 2000-х Джефф Безос разослал по всей компании распоряжение, согласно которому все команды Amazon обязаны были «представлять свои данные и функциональность через интерфейсы сервиса» и взаимодействовать друг с другом также при помощи этих интерфейсов. Он добавил, что прямой доступ к базам данных и любые другие способы получения данных напрямую из источника теперь под запретом. Это знаменитое распоряжение заканчивалось словами: «Все нарушители будут уволены. Спасибо и хорошего дня».
Не все руководители запускают программы догфудинга с таким напором, однако подобные практики сейчас вводят во многих компаниях в надежде, что из «влезания в шкуру» пользователя можно будет извлечь пользу для продукта.
Как сообщает centercode, команды, которые пользуются собственными продуктами и сервисами, получают больше ценности для бизнеса и привносят в процесс разработки продукта больше интересных наблюдений.
При выпуске новых продуктов или функциональности внутреннее тестирование может помочь повысить стандарты качества (или удержать их на должной высоте). Тестировщики, которые лучше знакомы с технической стороной, могут отлавливать баги и следить, чтобы всё работало так, как предполагалось. Те, кто с технической стороной незнаком, способны перед релизом протестировать продукт в «естественной среде» — их замечания могут потенциально оказаться ценными, так как транслируют потребности обычного пользователя.
Если говорить о процессах, которые осуществляются не так регулярно – например, онбординг или регистрация в системе – очень полезно бывает дать продукт новичкам, чтобы они оценили функциональность свежим взглядом и высказали свое мнение. Это помогает вносить нужные поправки в документацию и тур по продукту. Компании часто слишком увлекаются выпуском новых заманчивых возможностей и забывают о том, что к старой функциональности тоже неплохо бы время от времени возвращаться.
Нередко случается так, что сотрудников, которые занимаются продажами, маркетингом или взаимодействием с пользователями, в процессе разработки оттесняют в сторону. Но если к тестированию продуктов и сервисов привлекаются люди из разных команд, начинает складываться обще понимание как самого продукта, так и пользователя, для которого он предназначен.
Наличие разных точек зрения сослужит вам хорошую службу и в тех случаях, когда проектируются и создаются специфические виды ПО и пользовательского опыта. Кроме того, отдача пойдет также и в обратную сторону: люди, которые слабо разбираются в технической начинке программы, узнают о ней больше и смогут глубже характеризовать продукт в разговорах с потенциальными партнерами и клиентами.
Компания, которая регулярно использует собственные продукты и сервисы, будет регулярно испытывать всё то же, что испытывают ее пользователи. Повторяя пользовательский опыт, команда получает возможность определять болевые точки, а это, в свою очередь, может вносить коррективы в дорожные карты и подход к проектированию.
Хотя в целом все сходятся на том, что использование собственных продуктов на постоянной основе приносит компаниям пользу, нельзя забывать и о потенциальных рисках, связанных с этой практикой.
Ключевой момент: продуктовые команды должны четко понимать, когда имеет смысл применять внутреннее тестирование, а когда это просто бесполезно. Например, сервисы, обращенные к пользователю, вроде Fitbit или Facebook прекрасно подходят для догфудинга. С другой стороны, получить качественную обратную связь по очень сложным или нишевым программам в пределах компании удается не всегда.
При анализе обратной связи команде следует отдавать приоритет тем наблюдениям, которые соотносятся с пунктами в дорожной карте и долгосрочными целями компании. Последнее, что стоит делать – сосредотачиваться на пустяковых замечаниях, которые только смешают вам планы.
Наконец, продуктовым командам нужно помнить, что внутреннее тестирование не способно заменить собой контроль качества и бета-тесты. Как бы активно ваша команда ни пользовалась продуктом, вы всё равно должны проводить все необходимые тесты для обеспечения корректной работы и выявления багов и ошибок.
Ближе к концу 2021 года компания DoorDash объявила, что все сотрудники, кроме тех, кто занимается доставкой постоянно, обязаны доставлять по одному заказу каждый месяц, что породило жаркие споры на анонимной платформе Blind.
Некоторые считали, что это разумная инициатива, которая позволяет больше узнать о том, как работает команда доставки и какими инструментами ее снабдил DoorDash. Другие же, немногочисленные, но разгневанные сотрудники возмущались тем, что новая практика «выходит за рамки договора». Кто-то даже подумывал уволиться.
Это может показаться абсурдным – люди, которые получают по 400 000 $ в год недовольны тем, что придется раз в месяц возить заказы – однако эта история пролила свет на несколько серьезных соображений, которые компании должны иметь в виду, когда продумывают программу догфудинга.
Если вы всерьез намерены вводить практику такого рода, вам нужно согласие всех задействованных, в первую очередь – лидов. Руководство должно показать пример другим сотрудникам: выкроить время в своем напряженном графике и занять первые места в очереди за «домашней стряпней».
В большинстве компаний подобные инициативы организуют продуктовые команды – продакт-менеджеры, которые отвечают непосредственно за работу над продуктом, берут под крыло и программы догфудинга. Но бывает и такое, что программу ведут UX-дизайнеры, наблюдающие за тем, как пользователи взаимодействуют с их продуктом, или тестировщики, которые намерены собрать всю возможную информацию о багах в программе.
Ваши тестирующие будут использовать продукт по-разному, а значит, обращать внимание на разные его части, что будет отражаться на обратной связи, которую они предоставят. Например, люди из отдела продаж и маркетинга могут взглянуть на продукт с точки зрения целевой аудитории, а продуктовые команды и программисты – дать техническую экспертизу, указывая на ошибки и случаи некорректного поведения программы. Поэтому важно разделять тестирующих и, соответственно, поступающие от них замечания на группы.
Кто-то будет пробовать работать с продуктами компании и без всякой дополнительной мотивации, но кому-то она потребуется. Простой способ подогреть интерес команды – выделить сотрудникам свободное время на внутреннее тестирование.
В истории с DoorDash особенно часто звучала следующая претензия: принудительная доставка попросту добавляла еще один пункт в и так бесконечный список дел сотрудников. Если подходить к программе серьезно, необходимо продумать, как встроить тестирование в набор еженедельных обязанностей так, чтобы у людей не появлялось ощущения «этого еще не хватало».
Последнее, чего хотят ваши сотрудники – заполнять длинную форму Google, расписывая все подробности работы программы и своего опыта взаимодействия с ней. Можно сделать так: выделить для продукта или каждого типа функциональности основные цели, а затем составить опросник, который запрашивает только ту информацию, которая поможет команде работать на достижение этих целей здесь и сейчас.
Составляя опросники, старайтесь, чтобы они были понятными и простыми для заполнения. В качестве примера приведу формы для бета-тестирования от Typeform и Hotjar – их можно адаптировать под вашу программу внутреннего тестирования.
*
Конкуренция на рынке растет, и компаниям постоянно приходится привносить что-то новое и ценное в пользовательский опыт, чтобы люди не ушли к очередному конкуренту, который может появиться в любой момент. Когда компания становится сама себе первым и лучшим пользователем, это ускоряет процессы тестирования и инновации, что создает ценность для бизнеса. Команда быстрее собирает данные по аудитории и предоставляет возможности, которые действительно нужны людям.
Первые шаги в этом направлении ваши сотрудники могут встретить негодованием (если, конечно, вы не пойдете по стопам Джеффа Безоса), но в долгосрочной перспективе те, кто ставит себя на место пользователя, с большей вероятностью оставят конкурентов позади.
Dogfooding 101: A Quick Guide to Internal Beta Testing | Centercode
Dogfooding: Conducting an Internal Beta Test for Your App | Instabug Blog
Идея применения созданных продуктов внутри компании не нова. Всем хорошо известна история о том, как в начале 2000-х Джефф Безос разослал по всей компании распоряжение, согласно которому все команды Amazon обязаны были «представлять свои данные и функциональность через интерфейсы сервиса» и взаимодействовать друг с другом также при помощи этих интерфейсов. Он добавил, что прямой доступ к базам данных и любые другие способы получения данных напрямую из источника теперь под запретом. Это знаменитое распоряжение заканчивалось словами: «Все нарушители будут уволены. Спасибо и хорошего дня».
Не все руководители запускают программы догфудинга с таким напором, однако подобные практики сейчас вводят во многих компаниях в надежде, что из «влезания в шкуру» пользователя можно будет извлечь пользу для продукта.
Зачем это нужно?
Как сообщает centercode, команды, которые пользуются собственными продуктами и сервисами, получают больше ценности для бизнеса и привносят в процесс разработки продукта больше интересных наблюдений.
Улучшение пользовательского опыта
При выпуске новых продуктов или функциональности внутреннее тестирование может помочь повысить стандарты качества (или удержать их на должной высоте). Тестировщики, которые лучше знакомы с технической стороной, могут отлавливать баги и следить, чтобы всё работало так, как предполагалось. Те, кто с технической стороной незнаком, способны перед релизом протестировать продукт в «естественной среде» — их замечания могут потенциально оказаться ценными, так как транслируют потребности обычного пользователя.
Если говорить о процессах, которые осуществляются не так регулярно – например, онбординг или регистрация в системе – очень полезно бывает дать продукт новичкам, чтобы они оценили функциональность свежим взглядом и высказали свое мнение. Это помогает вносить нужные поправки в документацию и тур по продукту. Компании часто слишком увлекаются выпуском новых заманчивых возможностей и забывают о том, что к старой функциональности тоже неплохо бы время от времени возвращаться.
Более тесное знакомство с продуктом
Нередко случается так, что сотрудников, которые занимаются продажами, маркетингом или взаимодействием с пользователями, в процессе разработки оттесняют в сторону. Но если к тестированию продуктов и сервисов привлекаются люди из разных команд, начинает складываться обще понимание как самого продукта, так и пользователя, для которого он предназначен.
Наличие разных точек зрения сослужит вам хорошую службу и в тех случаях, когда проектируются и создаются специфические виды ПО и пользовательского опыта. Кроме того, отдача пойдет также и в обратную сторону: люди, которые слабо разбираются в технической начинке программы, узнают о ней больше и смогут глубже характеризовать продукт в разговорах с потенциальными партнерами и клиентами.
Ориентация на пользователя
Компания, которая регулярно использует собственные продукты и сервисы, будет регулярно испытывать всё то же, что испытывают ее пользователи. Повторяя пользовательский опыт, команда получает возможность определять болевые точки, а это, в свою очередь, может вносить коррективы в дорожные карты и подход к проектированию.
Не переедайте
Хотя в целом все сходятся на том, что использование собственных продуктов на постоянной основе приносит компаниям пользу, нельзя забывать и о потенциальных рисках, связанных с этой практикой.
Не все продукты годятся для внутреннего тестирования
Ключевой момент: продуктовые команды должны четко понимать, когда имеет смысл применять внутреннее тестирование, а когда это просто бесполезно. Например, сервисы, обращенные к пользователю, вроде Fitbit или Facebook прекрасно подходят для догфудинга. С другой стороны, получить качественную обратную связь по очень сложным или нишевым программам в пределах компании удается не всегда.
Не все замечания одинаково полезны
При анализе обратной связи команде следует отдавать приоритет тем наблюдениям, которые соотносятся с пунктами в дорожной карте и долгосрочными целями компании. Последнее, что стоит делать – сосредотачиваться на пустяковых замечаниях, которые только смешают вам планы.
Техническое и бета-тестирование не замещается внутренним
Наконец, продуктовым командам нужно помнить, что внутреннее тестирование не способно заменить собой контроль качества и бета-тесты. Как бы активно ваша команда ни пользовалась продуктом, вы всё равно должны проводить все необходимые тесты для обеспечения корректной работы и выявления багов и ошибок.
Как организовать программу догфудинга
Ближе к концу 2021 года компания DoorDash объявила, что все сотрудники, кроме тех, кто занимается доставкой постоянно, обязаны доставлять по одному заказу каждый месяц, что породило жаркие споры на анонимной платформе Blind.
Некоторые считали, что это разумная инициатива, которая позволяет больше узнать о том, как работает команда доставки и какими инструментами ее снабдил DoorDash. Другие же, немногочисленные, но разгневанные сотрудники возмущались тем, что новая практика «выходит за рамки договора». Кто-то даже подумывал уволиться.
Это может показаться абсурдным – люди, которые получают по 400 000 $ в год недовольны тем, что придется раз в месяц возить заказы – однако эта история пролила свет на несколько серьезных соображений, которые компании должны иметь в виду, когда продумывают программу догфудинга.
Заручитесь поддержкой главных «псов»
Если вы всерьез намерены вводить практику такого рода, вам нужно согласие всех задействованных, в первую очередь – лидов. Руководство должно показать пример другим сотрудникам: выкроить время в своем напряженном графике и занять первые места в очереди за «домашней стряпней».
Четко определите ответственных
В большинстве компаний подобные инициативы организуют продуктовые команды – продакт-менеджеры, которые отвечают непосредственно за работу над продуктом, берут под крыло и программы догфудинга. Но бывает и такое, что программу ведут UX-дизайнеры, наблюдающие за тем, как пользователи взаимодействуют с их продуктом, или тестировщики, которые намерены собрать всю возможную информацию о багах в программе.
Проведите сегментирование
Ваши тестирующие будут использовать продукт по-разному, а значит, обращать внимание на разные его части, что будет отражаться на обратной связи, которую они предоставят. Например, люди из отдела продаж и маркетинга могут взглянуть на продукт с точки зрения целевой аудитории, а продуктовые команды и программисты – дать техническую экспертизу, указывая на ошибки и случаи некорректного поведения программы. Поэтому важно разделять тестирующих и, соответственно, поступающие от них замечания на группы.
Отведите время на кулинарные приключения
Кто-то будет пробовать работать с продуктами компании и без всякой дополнительной мотивации, но кому-то она потребуется. Простой способ подогреть интерес команды – выделить сотрудникам свободное время на внутреннее тестирование.
В истории с DoorDash особенно часто звучала следующая претензия: принудительная доставка попросту добавляла еще один пункт в и так бесконечный список дел сотрудников. Если подходить к программе серьезно, необходимо продумать, как встроить тестирование в набор еженедельных обязанностей так, чтобы у людей не появлялось ощущения «этого еще не хватало».
Упростите обратную связь
Последнее, чего хотят ваши сотрудники – заполнять длинную форму Google, расписывая все подробности работы программы и своего опыта взаимодействия с ней. Можно сделать так: выделить для продукта или каждого типа функциональности основные цели, а затем составить опросник, который запрашивает только ту информацию, которая поможет команде работать на достижение этих целей здесь и сейчас.
Составляя опросники, старайтесь, чтобы они были понятными и простыми для заполнения. В качестве примера приведу формы для бета-тестирования от Typeform и Hotjar – их можно адаптировать под вашу программу внутреннего тестирования.
*
Конкуренция на рынке растет, и компаниям постоянно приходится привносить что-то новое и ценное в пользовательский опыт, чтобы люди не ушли к очередному конкуренту, который может появиться в любой момент. Когда компания становится сама себе первым и лучшим пользователем, это ускоряет процессы тестирования и инновации, что создает ценность для бизнеса. Команда быстрее собирает данные по аудитории и предоставляет возможности, которые действительно нужны людям.
Первые шаги в этом направлении ваши сотрудники могут встретить негодованием (если, конечно, вы не пойдете по стопам Джеффа Безоса), но в долгосрочной перспективе те, кто ставит себя на место пользователя, с большей вероятностью оставят конкурентов позади.
Ссылки
Dogfooding 101: A Quick Guide to Internal Beta Testing | Centercode
Dogfooding: Conducting an Internal Beta Test for Your App | Instabug Blog