Поговорим про технический продакт менеджмент.

У нас с командой только что был очень важный разговор.

Для создания новой фичи в Metacast, мы меняем структуру данных, на которой держится одна из уже существующих фич.

В мобильной разработке есть очень геморный фактор, которого нет в веб-сервисах. Помимо данных на сервере, существуют данные хранящиеся локально на устройстве пользователя. Соответственно, чтобы при обновлении приложения ничего не сломалось (или не дай Бог не потерялись пользовательские данные!), нужно сделать миграцию данных из одного формата в другой.

Мы это делаем во время инициализации приложения. Когда пользователь обновляется до новой версии и запускает Metacast, приложение автоматически сконвертирует данные в новый формат.

Казалось бы — супер, всё хорошо, изи...

Не так быстро. Есть нюансы.

Так как могут быть пользователи, которые не обновляются месяцами, у нас стоит выбор — оставить миграцию данных в функционале на долгий срок (потенциально, навечно) или заставить всех пользователей обновиться разом.

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

Второй вариант — более понятный и лёгкий.

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

Проблема этого подхода в том, что кто-то будет ехать за рулём на хайвее, слушая подкасты, когда приложение вдруг перестанет воспроизводить аудио. Кто-то будет в роуминге с дорогой связью. Кто-то будет в гараже, где не хватает качества соединения на скачивание новой версии приложения. Кто-то будет в спешке выходить из дома, вставит наушники в уши, откроет приложение, увидит, что оно не работает, матюгнётся и откроет Apple Podcasts.

Второй вариант проще для разработчиков, но хуже для пользователей.

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

Они стали смотреть данные — кто на какой версии и как они обновляются. Я сказал, что это неважно. Мы знаем и так, что некоторые отключают автоматические обновления (я это видел в гугле работая над мобильными SDK — некоторые пользователи Андроида не обновляются месяцами, это боль!)

Важен принцип — мы не пушим пользователей апгрейдиться ради нашего удобства. Мы тут говорим именно о "красоте" кода и паре часов лишней работы, не более.

Как продакт менеджеру в этой ситуации, мне было важно понять, что происходит на техническом уровне и проговорить с разработчиками сценарии миграции, увидеть возможность сделать по-другому и, убедившись, что вариант есть — поставить вопрос ребром.

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