245. Чеклист технического здоровья продукта

В идеальном бирюзовом мире работает так.

Product owner отвечает за продукт, его успешность, фичи, направление развития. Если продукт не нравится пользователям и не приносит денег, овнера бьют по голове канделябром и закапывают в саду.

Dev team отвечает за технику. За стек технологий, поддержку, выплату тех. долга, аптайм. Если сайт упал и лежал два часа, то команду разработки расстреливают в полном составе. А продакту за это ничего не предъявляют, он вообще может сказать, мол, ничего в этом не смыслю, не моя зона ответственности, дайте тоже выстрелить, пожалуйста.

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

В помощь продуктовым менеджерам небольшой чеклист по технике. Дополняйте в комментариях.

1. Есть мониторинг основных технических характеристика: загрузка серверов, очереди уведомлений, платежей. В идеале – это несколько дашбордов с графиками в реальном времени, например в Grafana.

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

3. Есть тот, кто реагирует на алерты и регулярно смотрит мониторинги. Если у вас тысяча сообщений, которые никто не читает – смысла в них нет.

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

5. Продукт можно развернуть в полном окружении и работоспособности за сутки. Лучше, за час.

6. У вас есть больше одного человека, кто может поддерживать продукт и восстановить его с нуля. Если у вас всего один разработчик, найдите разработчика на парт-тайм, обучите и пусть он будет за минимальную плату в горячем резерве.

7. Технический долг / проблемы описаны в бэклоге, и существует реалистичный план что и когда с ними делать.

8. У вас не используются языки программирования, фреймворки и библиотеки, на которые сложно найти работников в будущем, когда незаменимый Вася уйдет.

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

10. Есть минимальная документация, с помощью которой посторонний инженер может за день-два разобраться, как работает продукт и начать его поддерживать (или развернуть с нуля).

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