Давайте представим, что некая фирма создала полезное приложение, которое обрело популярность у аудитории в краткие сроки. И спустя некоторое время, помимо доработок, продукт обзавелся багажом ошибок, выявленных пользователями. И как планировалось, фирма выпускает обновление, которое добавит новое и исправит старое. Но по мере функционального улучшения приложения, возникают и неожиданные "сюрпризы”. И вновь, команда разработчиков, дабы не потерять интерес аудитории, вынуждена оставить работу над функционалом. Чтобы, как можно скорее, подготовить к выпуску очередной релиз, который исправит ряд выявленных недочетов.
Каждая компания использует собственный регламент в отношениях с клиентами. Но наступает момент, когда приходится задуматься о том, с какой частотой стоит обновлять продукт: как только забьётся почтовый ящик тех. поддержки или хладнокровно, не обращая внимания на гневные требования и “вопли о помощи”, выпустить релиз в назначенный день и назначенный час. Выделим два популярных решения данного вопроса. Первый - подготовка релизов с большим количеством свежих функций и исправленных багов. Второй - потоковое внесение изменений, будь то нововведение или исправленный баг, после того как прошли ревью и проверку тестами. У каждого решения будут как плюсы, так и минусы. Вкратце, рассмотрим и попытаемся сделать вывод - какой же из подходов лучше подходит для применения на практике.
Обновление по графику
Начать сравнение можно с ответа на вопрос: как мы относимся к очередным изменениям интерфейса в социальной сети, которой пользуемся каждый день? Быстро ли происходит адаптация к нововведениям в приложении? Частые метаморфозы интерфейса вызывают раздражение и суетной поиск нужной вкладки или функционала, к которому привык. Если не хотите, чтобы пользователи испытывали лишний стресс, тогда обратите внимание на запланированные обновления, привязанные к конкретной дате. К примеру - постоянный выпуск релиза в последний понедельник месяца. И к тому же, такой подход подчеркивает ответственность и стабильность компании, т.к. аудитории не приходится угадывать дату очередного релиза.
Наличие одного ежемесячного релиза не требует многолетнего опыта проектного управления. Это облегчает нагрузку на команду разработчиков - позволяя перенаправить ресурсы на тестирование и выпуск. Не нужно уметь "властвовать над хаосом", чтобы планомерно решить поставленные задачи. И поэтому, такой способ покажется комфортным для компаний с небольшим штатом разработчиков. Тем не менее многие крупные и передовые компании используют этот подход.
Конкретные сроки выпуска рисуют ясную картину действий. Определяются приоритетные нововведения, серьезные недоработки, затем, выстраивается четкий план действий, исходя из слабых и сильных стороны как продукта, так и команды. Выбрав "крупный" релиз, можно отсеять по необходимости не столь критичные ошибки и отложить нововведения, которые не успеваешь доделать. Но при этом, фиксированный отрезок времени дисциплинирует команду. Увеличивается количество выполненных задач.
При наличии возможности легко управлять проектом, выстраивать план задач и гарантировать стабильность, большие апдейты "грешат" частыми переносами. Релиз приходится сдвигать по срокам. Причина тому: ряд сложных инноваций, которые столь упорно внедряет команда разработки. Такие задержки оттягивают столь долгожданный набор подготовленных функций и исправлений.
Хоть часть потребителей и не рада "каждодневным" обновлениям, наличие определенного срока до следующей версии играет и отрицательную роль. Обратная связь становится "заторможенной" - разработчики не сразу получают замечания пользователей и идеи по доработке. Исправление выявленных багов и добавление фич необходимо переносить на следующий спринт. К тому же, люди успевают привыкнуть к некоторому ряду ошибок, а грядущее обновление вынудит вырабатывать привычки заново.
Обилие добавленного функционала, пропорционально сопровождается выявлением "слепых зон". Пользователи, как "лучшие тестировщики", предоставляют результат работы в отдел техподдержка. Приходится подключать дедуктивный метод сыщика, чтобы не с первого раза понять источник и причину происхождения багов. Подобную закономерность предсказать можно, но сложно контролировать.
Частые обновления
При сравнении главным достоинством потоковых релизов считается - работа по принципу конвейера. Пользователь недолго ожидает очередной порции полезных нововведений. В том числе, люди быстро привыкают к тому, что выявленные ошибки исправляются в скором времени.
Тем самым, добавленные опции пересматриваются и улучшаются в короткие сроки. Ошибки не успевают "пустить корни". Разработчики оперативно "пропалывают грядку" от сорняков. И к тому же, если регулярно публиковать свежие функции и немедленно исправлять баги, это позитивно скажется на отношении аудитории к компании.
Связка большого состава команды разработки и концепции частых обновлений дает возможность гораздо легче предсказывать и контролировать поведение продукта. Каждый становится ответственен за релиз: новая функция вносится сразу, поэтому разработчик пытается выполнить поставленную перед ним задачу с минимальным количеством исправлений в будущем. Тем самым увеличивается скорость выравнивания "отклонения" проекта.
Но ряд минусов присущих такому методу, делает выбор не столь очевидным, несмотря на явное преимущество в виде скорости. Для того чтобы учащенно выпускать обновления, требуется соблюсти некоторые условия. Без умения постоянно «жонглировать» большим количеством задач, при этом удерживая баланс между выпуском нового функционала и исправлением ошибок – такой подход будет сложно интегрировать и реализовать. При отсутствии должного опыта работы в столь «хаотичном» режиме, можно сильно просесть в динамике развития продукта, погрязнув в объеме задач, которые поступают «ежедневно». Поэтому такой подход к выпуску обновлений сложно назвать универсальным, по сравнению с плановым релизом. Так как такая практика подходит не для каждого проекта и не для каждой команды. Реализация напрямую зависит от этих двух факторов.
Столь нередкая реконструкция требует большего внимания и ресурсов. Для этого необходимо уметь грамотно комбинировать ручную и автоматизированную проверку. Так как ежедневная полная проверка «руками» нереальна, а авто тесты не могут в полной мере заменить человека и покрыть требования к пользовательскому интерфейсу.
При повторении одних и тех же сценариев ручное тестирование требует больше времени и к тому же, становится скучным, и как следствие, вовлеченность в разработку уменьшается и увеличивается процент появление ошибок. Да, в этом случае на помощь приходят автоматические тесты. Но инструменты авто тестирования, а также обучение их использованию – дорого обходятся. И при этом, автоматизация не исключает необходимости пристального контроля за состоянием пользователей – вероятность ошибок в продукте еще остается. Наличие этих факторов делает частые выпуски ресурсоёмким процессом.
Что выбрать?
Сравнивая две концепции, ясно, что плановое обновление по графику - универсальное и простое в освоении, при этом не лишено очевидных минусов: непредсказуемость и медленная реакция на новую сборку. На таком фоне, постоянный поток инноваций привлекает скоростью отклика и динамикой развития приложения. Но без должного умения "управлять потоком" здесь и сейчас - является весьма сложным в освоении. Решение будет зависеть от конкретного проекта и команды, которая над ним трудится.
Если у вас есть большое количество ресурсов и штат сотрудников для тестирования, а "за плечами" достаточный опыт ведения сложных проектов - тогда стоит попробовать концепцию частых релизов. Благодаря этому:
- Увеличивается динамика развития
- Легче предсказывать риски и контролировать отклонения
- Появляется быстрая обратная связь
- Негативная реакция на частые изменения минимизируется скоростью исправления ошибок и постоянным притоком свежих опций.
Сложный или легкий проект, большая или маленькая команда - для плановых релизов это не так принципиально.
- Легкое конструирование сборки: новые функции + критичные ошибки
- Комфорт: меньше стресса и нагрузки на штат разработки
- Планомерность: работа происходит не ситуативно, а придерживается заранее выстроенного плана
Конечно, можно создать свою комбинацию из частых и плановых релизов и выпускать так часто, как захочется. Важно иметь в виду, что некоторые пользователи чувствуют себя в большей безопасности, регулярно получая обновления, в то время как некоторые раздражаются, когда каждый день появляется всплывающее окно: « Установите 129 новых обновлений! Нажмите здесь, чтобы подождать 20 минут и загрузить, затем еще 10, чтобы установить!». Часто разочаровывают пользователей – вовсе не сроки, а то, что не известно: нужен ли новый апдейт или нет. Поэтому желательно четко понимать, какие полезные функции реализованы, какие критичные ошибки исправлены. К тому же, люди хотят быть уверены, что, если все-таки установить новую версию, ничего не сломается.
