ЧАСТЬ 1.

Почему аналитик сначала ищет проблему, а не решение

Когда люди узнают о профессии системного аналитика, они часто спрашивают: чем он занимается? Кто-то скажет: пишет требования. Кто-то: общается с заказчиками. Кто-то вспомнит BPMN, UML и другие инструменты. Все это часть работы. Но главное другое. Аналитик должен понять проблему до того, как команда начнет создавать решение. Именно это часто определяет успех проекта.

Почему это важно

Представим ситуацию. Заказчик говорит: «Нам нужна кнопка “Повторить заказ”». Можно сразу начать обсуждать дизайн, разработку и тестирование. Но аналитик задает другой вопрос: «Какую проблему должна решить эта кнопка?» Потому что кнопка — это не проблема. Это только один из возможных вариантов решения.

Проблема и решение — не одно и то же

Например: Проблема: пользователям долго оформлять повторный заказ. Решение: добавить кнопку «Повторить заказ». Но причина может быть другой: пользователи не находят историю покупок; нужный раздел плохо расположен; процесс оформления слишком сложный. Можно сделать идеальную кнопку, которая не изменит ситуацию.

Как мыслит аналитик

Другие участники проекта думают о реализации: Заказчик: «Нам нужна кнопка». Разработчик: «Где ее разместить?» Дизайнер: «Как она должна выглядеть?» Тестировщик: «Что должно происходить после нажатия?» Аналитик спрашивает: «Почему вообще появилась эта необходимость?» Он пытается понять причину, а не просто выполнить первое предложение.

Один вопрос может изменить весь проект

После обсуждения может выясниться: Проблема не в отсутствии кнопки. Пользователи просто не могут быстро найти свои прошлые заказы. Тогда решения могут быть другими: улучшить навигацию; сделать историю заказов заметнее; добавить поиск; предложить рекомендации. Кнопка тоже остается вариантом, но уже не единственным. Хороший аналитик не ищет ответ заранее. Он сначала понимает задачу.

Почему вопрос «Зачем?» экономит деньги

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

Что нужно запомнить

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

Мини-практика

Заказчик говорит: «Нужно добавить фильтр по городам». Не думайте сразу о реализации. Сначала спросите: «Какую проблему он пытается решить?» Попробуйте придумать три возможные причины. Именно с такого мышления начинается работа системного аналитика.