Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁

И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно!

Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление.

И, кажется, это одна из моих любимых тем!

Я вообще считаю, что одна из главных проблем платформенных команд — мы слишком часто думаем о том, что и как построить, и слишком редко о том, зачем это кому-то нужно.

В итоге получаем технически прекрасные решения, которые либо никто не использует, либо используют исключительно потому, что выбора нет.

О чём поболтали:

1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом?
2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁
3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать.
4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта?
5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек?
6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами?

Ну и поговорили про SLO, исследования пользователей, продуктовые метрики и прочие штуки, от которых у настоящего инженера иногда начинает дёргаться глаз.

В общем, если вы строите внутренние платформы, инженерные инструменты или просто хотите понять, зачем в инженерных командах нужны продуктовые менеджеры — рекомендую посмотреть!

Смотреть и слушать:

📺 YouTube

📱 VK Видео

📺 Rutube

🎧 Mave

Ну и приходите в комментарии спорить!