Как часто выпускать обновления?

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

Каждая компания использует собственный регламент в отношениях с клиентами. Но наступает момент, когда приходится задуматься о том, с какой частотой стоит обновлять продукт: как только забьётся почтовый ящик тех. поддержки или хладнокровно, не обращая внимания на гневные требования и “вопли о помощи”, выпустить релиз в назначенный день и назначенный час. Выделим два популярных решения данного вопроса. Первый - подготовка релизов с большим количеством свежих функций и исправленных багов. Второй - потоковое внесение изменений, будь то нововведение или исправленный баг, после того как прошли ревью и проверку тестами. У каждого решения будут как плюсы, так и минусы. Вкратце, рассмотрим и попытаемся сделать вывод - какой же из подходов лучше подходит для применения на практике.

Обновление по графику

Начать сравнение можно с ответа на вопрос: как мы относимся к очередным изменениям интерфейса в социальной сети, которой пользуемся каждый день? Быстро ли происходит адаптация к нововведениям в приложении? Частые метаморфозы интерфейса вызывают раздражение и суетной поиск нужной вкладки или функционала, к которому привык. Если не хотите, чтобы пользователи испытывали лишний стресс, тогда обратите внимание на запланированные обновления, привязанные к конкретной дате. К примеру - постоянный выпуск релиза в последний понедельник месяца. И к тому же, такой подход подчеркивает ответственность и стабильность компании, т.к. аудитории не приходится угадывать дату очередного релиза.

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

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


Планирование

При наличии возможности легко управлять проектом, выстраивать план задач и гарантировать стабильность, большие апдейты "грешат" частыми переносами. Релиз приходится сдвигать по срокам. Причина тому: ряд сложных инноваций, которые столь упорно внедряет команда разработки. Такие задержки оттягивают столь долгожданный набор подготовленных функций и исправлений.

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

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

Частые обновления

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

Тем самым, добавленные опции пересматриваются и улучшаются в короткие сроки. Ошибки не успевают "пустить корни". Разработчики оперативно "пропалывают грядку" от сорняков. И к тому же, если регулярно публиковать свежие функции и немедленно исправлять баги, это позитивно скажется на отношении аудитории к компании.

Связка большого состава команды разработки и концепции частых обновлений дает возможность гораздо легче предсказывать и контролировать поведение продукта. Каждый становится ответственен за релиз: новая функция вносится сразу, поэтому разработчик пытается выполнить поставленную перед ним задачу с минимальным количеством исправлений в будущем. Тем самым увеличивается скорость выравнивания "отклонения" проекта.


Командная работа

Но ряд минусов присущих такому методу, делает выбор не столь очевидным, несмотря на явное преимущество в виде скорости. Для того чтобы учащенно выпускать обновления, требуется соблюсти некоторые условия. Без умения постоянно «жонглировать» большим количеством задач, при этом удерживая баланс между выпуском нового функционала и исправлением ошибок – такой подход будет сложно интегрировать и реализовать. При отсутствии должного опыта работы в столь «хаотичном» режиме, можно сильно просесть в динамике развития продукта, погрязнув в объеме задач, которые поступают «ежедневно». Поэтому такой подход к выпуску обновлений сложно назвать универсальным, по сравнению с плановым релизом. Так как такая практика подходит не для каждого проекта и не для каждой команды. Реализация напрямую зависит от этих двух факторов.

Столь нередкая реконструкция требует большего внимания и ресурсов. Для этого необходимо уметь грамотно комбинировать ручную и автоматизированную проверку. Так как ежедневная полная проверка «руками» нереальна, а авто тесты не могут в полной мере заменить человека и покрыть требования к пользовательскому интерфейсу.

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

Что выбрать?

Сравнивая две концепции, ясно, что плановое обновление по графику - универсальное и простое в освоении, при этом не лишено очевидных минусов: непредсказуемость и медленная реакция на новую сборку. На таком фоне, постоянный поток инноваций привлекает скоростью отклика и динамикой развития приложения. Но без должного умения "управлять потоком" здесь и сейчас - является весьма сложным в освоении. Решение будет зависеть от конкретного проекта и команды, которая над ним трудится.


Неправильный инструмент

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

  • Увеличивается динамика развития
  • Легче предсказывать риски и контролировать отклонения
  • Появляется быстрая обратная связь
  • Негативная реакция на частые изменения минимизируется скоростью исправления ошибок и постоянным притоком свежих опций.

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

  • Легкое конструирование сборки: новые функции + критичные ошибки
  • Комфорт: меньше стресса и нагрузки на штат разработки
  • Планомерность: работа происходит не ситуативно, а придерживается заранее выстроенного плана

Конечно, можно создать свою комбинацию из частых и плановых релизов  и выпускать так часто, как захочется. Важно иметь в виду, что некоторые пользователи чувствуют себя в большей безопасности, регулярно получая обновления, в то время как некоторые раздражаются, когда каждый день появляется всплывающее окно: « Установите 129 новых обновлений! Нажмите здесь, чтобы подождать 20 минут и загрузить, затем еще 10, чтобы установить!». Часто разочаровывают пользователей – вовсе не сроки, а то, что не известно: нужен ли новый апдейт или нет. Поэтому желательно четко понимать, какие полезные функции реализованы, какие критичные ошибки исправлены. К тому же, люди хотят быть уверены, что, если все-таки установить новую версию, ничего не сломается.

Попробуйте «Управление IT-отделом 8» бесплатно
Автоматизация работы технической поддержки, управление IT-командой, учёт оборудования и многое другое
Попробовать бесплатно
Фото автора записи

Руководитель отдела технической поддержки компании Софтонит

Системные решения для 1С
Как часто выпускать обновления?
SoftOnIT.RU
Для каждого разработчика рано или поздно становится актуальным вопрос: как часто стоит выпускать обновления... 2022-11-18T18:48:09+03:00
Как часто выпускать обновления?
Как часто выпускать обновления?
https://softonit.ru
Поделитесь статьей
Рекомендуем почитать
Статьи Оптимизация работы с помощью диаграммы сгорания

Burndown Chart- сложное название инструмента, призванного улучшить качество работы. В этой статье поговорим о "Диаграмме сгорания задач", а именно что это и как им пользоваться.

Статьи Контролируем обещание данное клиенту техподдержки

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

0 / 0