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

Проблема 1. Заказчик не предоставляет БТ (или пишет слабые БТ). Что можно сделать: 1. Собрать бизнес-требования самостоятельно: провести интервью, порисовать прототипы интерфейсов на основании первичных требований и обсудить их с заказчиком, обсудить, какой пользовательский путь планируется с новой доработкой, посмотреть, как пользователи работают с текущей проблемой сейчас и исходя из этого предложить свое решение. 3. Задавать вопросы по всему, что не покрыто требованиями, и объяснять, почему без этой информации не получится сделать доработку. Со временем заказчик запомнит хотя бы часть важных моментов. 4. Составить чек-лист по написанию БТ для заказчика со списком всего, что нужно не забывать включать в БТ.

Проблема 2. Заказчик говорит, что это не то, что он хотел увидеть. Часто является следствием предыдущей проблемы (но не всегда). Что можно сделать: 1. Попробовать иные способы сбора требований, помимо БТ: собрать у заказчика прототипы интерфейсов, юз кейсы, провести брейншторм, посмотреть, как пользователи работают с текущей проблемой сейчас. 2. Фиксировать все договоренности по итогам встреч в письменном виде. 3. Фиксировать критерии приемки (UAT). 4. Внедрить процесс проведения демонстрации функционала заказчику и проведения UAT до принятия решения о включении задачи в релиз. 5. Внедрить согласование ТЗ аналитика заказчиком. 6. Составить чек-лист по написанию БТ для заказчика со списком всего, что нужно не забывать включать в БТ, чтобы снизить кол-во таких ситуаций в будущем.

Проблема 3. У заказчика нет времени отвечать на вопросы аналитика, возникающие в ходе работы аналитика над ТЗ. Что можно сделать: 1. Собрать первую встречу с заказчиком на полчаса и посвятить вопросам по БТ этот заранее выделенный промежуток времени. 2. По всем открытым вопросам предложить свое решение, прийти с этим к заказчику и получить его согласование или замечания. Для заказчика прокомментировать уже готовое гораздо быстрее и проще, чем думать и отвечать на открытые вопросы. 3. Написать все требования, которые могут быть написаны без ответов на вопросы, составить список оставшихся вопросов и собрать еще одну короткую встречу для обсуждения всего, что осталось.

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