Очень часто на практике случается, что заказчик понимает процесс обновления приложения не так, как его в итоге выполняет IT-компания. Чтобы избежать недоразумений и конфликтных ситуаций, рекомендую внимательно и скрупулезно отнестись именно к подготовительному этапу.
Сегодня сами пользователи говорят о своих более высоких ожиданиях от приложений. На практике это подтверждает, например, развитие финансовых технологий: улучшение пользовательских навыков клиентов банков приводит к тому, что они хотят видеть в приложениях больше функций. Соответственно, другим сферам приходится «подтягиваться».
Обращаясь к IT-специалистам, нередко клиент уверен — добавление небольшого функционала не потребует глобальных изменений для работающего кода. Когда же IT-компания говорит, именно о его о корректировке, возникает недопонимание. Еще сложнее, если заказчик считает — так разработчики хотят вытащить из него большую оплату.
Дабы избежать подобных ситуаций, клиенту сразу нужно показать, что ваше решение основано на глубоком анализе кода, а еще вы руководствуетесь бизнес-логикой. Как это сделать, разберем далее.
Вовлекайте клиента уже на стадии подготовки
Прежде всего, не приступайте к работе, пока клиент не предоставит исчерпывающий список своих ожиданий от приложения. Здесь должно быть указано все и поэтапно:
- пожелания по поводу изменений;
- цели, которые он планирует достичь при помощи обновлений;
- особые требования;
- этапы выполнения;
риски, связанные с обновлениями, и т. д.
Такой бриф придаст конкретики и покажет технической команде заказчика, что именно будет происходить и в какой момент.
Отдельно уделите внимание рискам. Не достаточно, чтобы клиент просто их озвучил. Он должен понимать, как будет работать приложение во время обновления и каким образом произойдет переход от старого кода к новому. Особенно аккуратного обращения требует большая информационная база пользователей. Сложность заключается в том, что для каждого продукта нужно искать индивидуальное решение, поскольку, к примеру, структура базы данных у приложений разная, а она влияет на скорость работы.
И еще один важный подготовительный пункт — тестирование. До того, как ваша команда начнет работать над обновлениями, нужно оценить тестовое покрытие. Если его достаточно, можно переходить к техническому этапу. А вот когда покрытие тестами отсутствует, вам предстоит его создать до начала работы над кодом.
- интеграционные проверяют совместную работу разных элементов.
Правильным подходом будет выявление подходящих тестов в старой кодовой базе. Их использование поможет понять, насколько хорошо интегрирована новая функция.
Таким образом, подготовительный этап позволяет заказчику четко определить цели, а разработчикам оценить, с чем предстоит работать и насколько реально выполнить пожелания. В то же время, IT-специалисты проверяют возраст кода, его архитектуру, тестовое покрытие и разъясняют клиенту дальнейшие действия. Все это не просто формальности, а реальные инструменты, которые способствуют выстраиванию правильной и эффективной коммуникации между заказчиком и разработчиками. Без такой вот подготовки, велика вероятность возникновения недопонимания с обеих сторон и, как следствие, потеря доверия либо прекращение сотрудничества. А ведь этого вполне можно избежать.
В следующем материале уделю внимание второму этапу — технической стороне обновления кода. Поговорим о критериях оценки и о том, от чего зависит степень изменений.
