Релизы: дилемма выбора

“Внедрили искусственный интеллект строителя в алгоритмы сервиса”. Такое или примерно такое сообщение мы пишем по понедельникам в соцсетях. За внешней стороной релиза каждый раз стоит дилемма: что именно мы готовы показать и в каком объеме. И мы нашли выход из такой ситуации.

“Внедрили искусственный интеллект строителя в алгоритмы сервиса.

Ой, это же из будущих релизов! А в данный момент на Radme.ru появился новый функционал заказа ремонта и строительных работ. Это позволит легко, быстро и достаточно точно формулировать задания в понятном для исполнителей виде.

Для жителей Новой Москвы упростили ввод адреса. Все локальные алгоритмы для населенных пунктов Новой Москвы будут работать по-старому — максимально точно и адекватно местной специфике.

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

Такое или примерно такое сообщение мы пишем по понедельникам в соцсетях. Понедельник — день релиза стабильной версии. Для нашей команды этот день недели оптимальный: на релиз в конце недели серьезно накладывают отпечаток выходные. Не смотря на то, что в выходные мы работаем, скорость реагирования на задачи плавает по времени суток и падает в дневное время — команда небольшая, но все социализованы и уделяют время для своих близких и родственников.

Перед релизом стабильной версии у нас недельное тестирование на закрытой версии. Сюда мы складываем готовые решения или завершенные элементы для user stories из разработки.

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

Каждую неделю, мы не только планируем задачи в итерацию, но и прогнозируем, что отправляем в стабильный релиз. Для выбора не пользуемся соотношениями, типа “20/80” или “1:1:3”, а задаем вопрос: “эта фича улучшит пользовательский опыт?”.

Положительный ответ предполагает желаемый профит для проекта в виде обратной связи и интересной статистики после внедрения, что крайне важно для реального money making.

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

Такая организация релизов снимает с разработки лишнюю “головную боль”, а время расходуется эффективнее.

Ваш Кэп.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.