Достаточно часто в продуктовой разработке я сталкиваюсь с тем, что в Prod просачиваются ошибки, которые не были выявлены ни автоматическими тестами, ни на уровне QA.
При ретроспективе, как правило, в артефактах системного или бизнес анализа кейсы прямо или косвенно прослеживаются, равно как и порядок их обработки.
Причина не столько в том, что кто-то не доработал, в конечном итоге, продукт - это результат командной работы, и искать здесь крайнего непродуктивно. Вылили ошибку в продакшен - все молодцы.
Дело в том, что в процессе разработки продукта или фичи, описание ее претерпевает несколько трансформаций, преобразовываясь в ту форму, которая понятна конкретному специалисту. Заказчик предъявляет функциональные требования или "хотелки", бизнес аналитик преобразовывает их в сценарии и наращивает логику, дизайнер интерфейсов рисует пользовательскую историю в картинках, системный аналитик описывает изнанку, схемы, взаимодействия, улаживает нестыковки бизнеса, дизайна и архитектуры, разработчик вычленяет требования для реализации, специалист качества пишет тесты с учетом требований и реальной реализации.
Вот как написано, так и разрабатывай
Как бы мы ни старались находиться в одном информационном поле, системный анализ и реализация отличаются. Они будут отличаться даже в том случае, когда и аналитику и реализацию фактически поставит один и тот же специалист. Дело не в коммуникации, а в степени погруженности в детали. Зачастую только на уровне кода, в контексте среды, стека, задачи возникают вопросы, которые ранее не было возможно даже предположить. Как правило, разработчик на месте принимает решение эскалировать ли вопрос на уровень аналитики или архитектуры или нет.
Ровно по этой причине имеет место тренд на вытеснение компетенции системного анализа и преобразование её в феномен групповой работы команды разработки.
Мой опыт говорит, что чаще всего разработчик принмает решение самостоятельно. В угоду времени, скорости, чаще какого-то дедлайна. Это парадокс, но разработчику всегда не хватает времени, сколько бы его ни было для поиска решения. Спустя время возникает другое решение, которое кажется программисту более правильным.
В результате на уровне системной аналитики одно, на уровне кода - другое, на уровне QA что-то среднее. И это независимо от того, представлена компетенция SA отдельно или это собирательный образ из разработки.
Специалисту качества приходится сложнее всего. Ведь когда все работает как часы, то вся команда - молодцы. Когда что-то пошло не так - первым достается QA.
Ограничения
Ограничения - это хорошо. Сложнее всего эта истина постигается бизнесом, потому что тому нужно всё и сразу, с конкурентными преимуществами, чтобы была возможность продавать не только на морально-волевых.
Четко определяем критерии готовности к разработки и готовности как таковой.
Мы получаем конечные чек-листы, которые не дают нам ошибиться, ну или, по крайней мере, совершить меньше ошибок, или забыть что-то важное.
DoD & DoR - это простые с виду списки, в которых воз полезностей: от последовательной структуры до согласования с заказчиком и тестов. Они показывают и стоперы разработки, и условия релиза, и основу для Release Notes и презентаций бизнесу.
Comments are closed