Релизы: дилемма выбора
"Внедрили искусственный интеллект строителя в алгоритмы сервиса.
Ой, это же из будущих релизов! А в данный момент на Radme.ru появился новый функционал заказа ремонта и строительных работ. Это позволит легко, быстро и достаточно точно формулировать задания в понятном для исполнителей виде.
Для жителей Новой Москвы упростили ввод адреса. Все локальные алгоритмы для населенных пунктов Новой Москвы будут работать по-старому – максимально точно и адекватно местной специфике.
На Radme.ru освежили внешний вид иконок и попапов, проделали серьезную внутреннюю работу с ресурсом для повышения стабильности работы алгоритмов расчета ремонта."
Такое или примерно такое сообщение мы пишем по понедельникам в соцсетях. Понедельник – день релиза стабильной версии. Для нашей команды этот день недели оптимальный: на релиз в конце недели серьезно накладывают отпечаток выходные. Не смотря на то, что в выходные мы работаем, скорость реагирования на задачи плавает по времени суток и падает в дневное время – команда небольшая, но все социализованы и уделяют время для своих близких и родственников.
Перед релизом стабильной версии у нас недельное тестирование на закрытой версии. Сюда мы складываем готовые решения или завершенные элементы для user stories из разработки.
На старте разница релиза между тестовой и стабильной версией была день, но за два месяца с ростом функциональности сервиса приходится добавлять время на тестирование. Очень важно проверить, чтобы в стабильную версию не ушло лишнее, или не оказался скрытым новый функционал, который раньше был готов, но "выпиливался".
Каждую неделю, мы не только планируем задачи в итерацию, но и прогнозируем, что отправляем в стабильный релиз. Для выбора не пользуемся соотношениями, типа "20/80" или "1:1:3", а задаем вопрос: "эта фича улучшит пользовательский опыт?".
Положительный ответ предполагает желаемый профит для проекта в виде обратной связи и интересной статистики после внедрения, что крайне важно для реального money making.
Отрицательный ответ отправляет функционал в режим ожидания, пока он не окажется необходим для фич реально улучшающих пользовательский опыт.
Такая организация релизов снимает с разработки лишнюю "головную боль", а время расходуется эффективнее.
Ваш Кэп.