Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁 И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно! Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление. И, кажется, это одна из моих любимых тем! Я вообще считаю, что одна из главных проблем платформенных команд — мы слишком часто думаем о том, что и как построить, и слишком редко о том, зачем это кому-то нужно. В итоге получаем технически прекрасные решения, которые либо никто не использует, либо используют исключительно потому, что выбора нет. О чём поболтали: 1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом? 2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁 3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать. 4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта? 5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек? 6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами? Ну и поговорили про SLO, исследования пользователей, продуктовые метрики и прочие штуки, от которых у настоящего инженера иногда начинает дёргаться глаз. В общем, если вы строите внутренние платформы, инженерные инструменты или просто хотите понять, зачем в инженерных командах нужны продуктовые менеджеры — рекомендую посмотреть! Смотреть и слушать: 📺 YouTube 📱 VK Видео 📺 Rutube 🎧 Mave Ну и приходите в комментарии спорить!