Про догфудинг
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
---
Пост из марта 2024
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
---
Пост из марта 2024