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