Как читать мысли заказчика без регистрации и смс

В рамках серии экспертных публикаций SkillStaff делится знаниями и опытом своих аутстафферов. На этот раз мы представляем материал от Дарьи Горамзиной, опытного специалиста в области бизнес-анализа.

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

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

Кто хоть раз реализовывал в команде то, что оказалось ненужным?!

Лично у меня такое случалось несколько раз, с тех пор как я пришла в этот огромный мир бизнес анализа, полный вопросов, недопониманий и субъективных интерпретаций. Проработав аналитиком столько времени, я выработала несколько правил работы пошагового взаимодействия с заказчиком при сборе требований:

1.1. Ищем заказчика! Если требования дает Ваш руководитель: например, он говорит, что необходимо вместо текущего треугольника реализовать маленький квадрат 5 на 5? мы внимательно читаем/слушаем, но требуем коммуникации с непосредственным заказчиком. Скорее всего, это будет руководитель отдела или компании, назовем его Василий. Делаем мы это не потому, что наш руководитель плохой или не знающий, а просто потому что невозможно быть экспертом во всем. Во время коммуникации с Василием необходимо:

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

1.2 Знакомимся с конечными пользователями. Вот, казалось бы, и все? Но это было бы слишком просто. Руководители занимаются организаторской деятельностью, масштабированием и, как правило, не знают всех бед своих подчиненных за неимением времени или обратной связи от сотрудников. Попросите Василия выделить пару человек, которые непосредственно будут работать с будущим продуктом. Во время коммуникации с ними необходимо посмотреть, как работает процесс со стороны пользователей, выяснить проблемы, которые, по их мнению, тормозят процесс, узнать поможет ли реализация, озвученная заказчиком, в решении этих проблем. Если есть еще какие-то варианты реализации — обсудить их.

Эта коммуникация позволит более глубоко погрузиться в проект, узнать боли конечных пользователей и минимизировать возможные будущие изменения требований. В моей работе был яркий пример: руководитель разработал методику процесса, но пользователям он был неудобен, и они с течением времени его немного изменили, но результат работы был таким же, как его видел руководитель. Разница была выявлена только при детальном анализе и работе с конечными пользователями, вот поэтому так важен этот этап.

1.3 Best practice — всему голова! Посмотрите в интернете или узнайте в смежных отделах — возможно, другие уже решали подобные проблемы. Можно взять пару уже реализованных идей для минимизации трудозатрат.

1.4 Грумминг с командой. Собраны требования, есть несколько вариантов реализации? Самое время вернуться в команду. Обсудите верхнеуровнево все варианты реализации со всеми участниками команды: сроки, нюансы реализации, неуточненные детали требований. Возможно, какие-то из вариантов труднореализуемые, а может команда подкинет еще пару идей.

1.5 Оформление идей. Готовы все варианты решения проблемы. Порисуем? Представьте все варианты реализации в виде таблицы. По каждому решению опишите все особенности, положительные и отрицательные моменты.

1.6 Встречаемся вместе с РП, Василием и Лицом, принимающим решение, если оно есть.

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

— как часто я слышу подобные комментарии от людей, далеких от ИТ, когда они узнают, кем я работаю.

Казалось бы что тут такого? Заказчик ведь знает, чего не хватает бизнесу.

Как бы не так! Заказчик знает это с точки зрения бизнеса, но, скорее всего, не имеет понятия о процессах и системах.

2.1 Нарисуйте детальную схему текущего процесса (asis) и будущего процесса (tobe) в рамках того, что вы оговорили на этапе выше.

2.2 На каждом из шага будущего процесса подумайте, что может пойти не так? Что может сделать пользователь? Случайно или умышленно. Могут ли быть системные сбои на этом шаге?

2.3 Для каждого шага напишите список кейсов, которые могут произойти, даже гипотетически.

2.4 Каждый кейс обсудите с заказчиком, как должна себя вести система по каждому случаю?

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

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

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

3.1 Разделим требования на 2 группы: обязательные и желательные.

Первую группу разделим еще на две: Must have – то, что необходимо сделать в любом случае. То, без чего процесс работать не будет. MVP процесс. Для того чтобы проверить покатиться ли шар, необязательно его красить, достаточно просто создать форму по согласованным параметрам. На этом этапе функционал активно тестируется, выдвигаются гипотезы. Зачастую после реализации меняются требования для дальнейшего развития продукта — то-то уже не нужно, а где-то появляются новые хотелки.

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

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

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

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