Как согласовываются изменения в техническом задании
Что проверяют
Знаете ли вы процесс управления изменениями требований и умеете ли не пропустить изменение «на словах» мимо документа. Следом спрашивают, что вы делаете, если заказчик требует доработку без сдвига сроков.
Как отвечать
Опишите процесс по шагам, а потом подкрепите своим случаем:
- фиксация запроса: любое изменение оформляется как запрос на изменение (change request): кто инициатор, что меняется, зачем. Устные просьбы с созвона тоже записываете и отправляете письмом или задачей в Jira;
- анализ влияния: какие требования, экраны, интеграции, API и тест-кейсы задевает изменение. Здесь выручает матрица трассируемости. Оценку трудозатрат и рисков даёт команда, а не аналитик в одиночку;
- решение: кто утверждает, договариваются заранее. Это владелец продукта, заказчик или комиссия по изменениям (CCB) на крупных проектах. Исходы: принять, отклонить, отложить в следующий релиз, принять в обмен на исключение другой задачи;
- обновление документа: новая версия ТЗ или страницы в Confluence, лист изменений с датой, автором и ссылкой на запрос. В заказной разработке по ГОСТ 34 изменения ТЗ оформляют дополнением или протоколом, подписанным заказчиком и разработчиком;
- оповещение: разработка, тестирование и смежные команды узнают об изменении из одного источника, а не из пересказа.
В гибких командах процесс легче: изменение попадает в бэклог, приоритет ставит владелец продукта, а текущий спринт без веской причины не трогают. Но фиксация и анализ влияния остаются.
Пример приводите свой: что поменялось, какой риск вы нашли при анализе и чем закончилось.
Где спотыкаются
Говорят «созваниваемся и договариваемся». Без записанного решения через месяц никто не помнит, кто что согласовал, и спор выигрывает тот, кто громче.
Правят документ молча, без версии и истории. Тестировщики проверяют по старому тексту, разработчики пишут по новому.
Соглашаются на изменение, не показав его цену. Заказчик должен видеть, что сдвинется: срок, объём или бюджет.