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

Представления заказчика и исполнителя о процессе разные

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

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

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

Відключити

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

Вовлекайте клиента уже на стадии подготовки

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

- пожелания по поводу изменений;

- цели, которые он планирует достичь при помощи обновлений;

Відключити

- особые требования;

- этапы выполнения;

риски, связанные с обновлениями, и т. д.

Такой бриф придаст конкретики и покажет технической команде заказчика, что именно будет происходить и в какой момент.

Відключити

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

И еще один важный подготовительный пункт — тестирование. До того, как ваша команда начнет работать над обновлениями, нужно оценить тестовое покрытие. Если его достаточно, можно переходить к техническому этапу. А вот когда покрытие тестами отсутствует, вам предстоит его создать до начала работы над кодом.

IT-специалисты определяют, какие тесты использовать:

- модульные предназначены для одной функции;

- интеграционные проверяют совместную работу разных элементов.

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

Таким образом, подготовительный этап позволяет заказчику четко определить цели, а разработчикам оценить, с чем предстоит работать и насколько реально выполнить пожелания. В то же время, IT-специалисты проверяют возраст кода, его архитектуру, тестовое покрытие и разъясняют клиенту дальнейшие действия. Все это не просто формальности, а реальные инструменты, которые способствуют выстраиванию правильной и эффективной коммуникации между заказчиком и разработчиками. Без такой вот подготовки, велика вероятность возникновения недопонимания с обеих сторон и, как следствие, потеря доверия либо прекращение сотрудничества. А ведь этого вполне можно избежать.

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