Как мы уже прояснили в предыдущей статье, аналитиков в ИТ великое множество. И каким именно вы будете аналитиком (по специфике) зависит только от вас и вашего желания.
В этой статье я хочу поделиться знаниями о том, кто же такой аналитик в заказной разной разработке? И зачем он собственно нужен?
В заказной разработке нужны практически все виды аналитиков, но обычно это один человек, заключающих в себе все-все знания. Это должен быть уникальный человек, который сможет собрать требования, обработать их и выдать команде разработки.
Давайте разберем, как следует действовать такому аналитику и за что он ответственен.
Исходные данные: в компанию пришёл заказчик и дал свои требования к нужной функции/системе, у него уже был написал небольшой текстовый документ с его мыслями, идеями и желанием что-то создать. Аналитик ознакомился с этими материалами и...начался процесс.
Первоначально в аналитике должна проснуться внутренняя почемучка. Аналитик должен понять ЗАЧЕМ же все таки заказчику нужно то, с чем он к вам пришёл, в чем заключается его "боль". Лучше всего подготовить свои первоначальные вопросы, чтобы глубже разобрать исходные данные. И часто бывает так, что заказчик имея свой бизнес, увидел какую-то уже существующую информационную систему, которая может помочь ему с чем-то, но есть какие-то особенности, почему ваш заказчик не хочет/не может ее использовать. И в таких случаях хорошо бы задать такие вопросы, чтобы выяснить, чем заказчик вдохновлялся, какие функции и возможности системы его привлекли.
После определения этой боли, нужно задокументировать все, что узнали. Здесь можете использовать любой способ - диаграммы, схемы, скриншоты из различных приложений/систем или просто текстовое описание. После этого первоначальной стадии сбора требований, необходимо согласовать ваше понимание требований с заказчиком и, в случае успеха, начать детализировать каждую часть.
Детализация подразумевает под собой - проектирование ИС (если есть в команде архитектор, то совместно с ним, иначе с тимлидом или самостоятельно), детализация бизнес процессов, прототипирование, описание функциональных требований (с упоминанием о преследуемой цели), описание прототипа.
В большинстве случаев заказчикам не требуется дополнительно согласовывать ваши детально проработанные требования (это не касается гос.заказов, здесь все более бюрократичнее). Но если есть хотя бы малейшее сомнение в корректности требований, лучше уточните их с заказчиком.
Ну и казалось бы, на этом всё, аналитик свободен. Но нет, не торопитесь уходить и говорить "у меня лапки". Здесь то как раз самый разгар работы и начинается. Аналитику необходимо консультировать разработчиков, помогать им искать различную информацию, задавать уточняющие вопросы у заказчика, если этого не было сделано на этапе проработки требований. И после того, как функциональность разработана, необходимо ее первично протестировать, то есть посмотреть, а учтены ли все требования, которые были описаны. И только в случае корректно разработанной системы и полного тестирования можно отдавать заказчику. Чаще всего заказчику устраивают демонстрационные сессии, это делает либо аналитик, либо менеджер. Тут уж у каждого по-своему.
И только после приемки системы заказчиком работа аналитика заканчивается. И начинается что-то новое :-)
Напомню про свой Телеграм канал - Становление аналитика. Заходите, иногда я пишу там свои мысли, делюсь своим опытом.
#программирование #аналитика #ктотакойаналитик #agile
