Анализ документов 📜

Вы посмотрели другие системы и немного вдохновились на разработку! Теперь пора изучить документы, которые уже есть по проекту.
Вы же не подумали, что до вашего прихода на проект вообще ничего нет? 😉

Конечно, кто-то до вас уже проработал концепцию, и у заказчика наверняка есть видение по решению его проблем. Соберите всё, что есть по проекту: схемы бизнес-процессов, руководство пользователя, скриншоты, старые презентации. Также в компаниях ведут базу знаний, например, в Confluence. Вы можете самостоятельно поискать информацию там.

А бывает и так, что документации вообще нет 😱
Выбивайте хоть что-то: скриншоты аналогичных систем, идей, в конце концов вместе сядьте и нарисуйте видение будущей системы.

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

Минусы:
❌ Документы устаревают.
❌ Не все компании ведут документацию детально, а иногда её просто нет.

#requirements

Наблюдение 👀

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

🔍 Как это выглядит?
Вы правда приходите на рабочие места пользователей и смотрите, как они работают.
* Например, изучаете производственные процессы на заводе.
* Приглашаете пользователей в ваш офис, чтобы посмотреть лично за их действиями, как они используют продукт.
* Организуете встречи в Zoom, чтобы посмотреть удалённо за процессом.

Плюсы метода:
✅ Видите реальную работу пользователей и скрытые проблемы.
✅ Выявляете нюансы, которые сложно описать словами (их можно только увидеть).

Минусы:
❌ Требует времени.
❌ Не заменяет общения — нужно уточнять детали с пользователями.

Наблюдение — мощное дополнение к другим методам сбора требований. Комбинируйте и получите максимально точные данные!

#requirements

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

Привет! 👋
С вами Вера.
Сегодня расскажу, как я собирала требования на своем первом месте работы. Это был стартап в сфере страхования. Вначале коллектив был небольшим, а со временем вырос до 40 человек. С любовью вспоминаю те времена!

🗣 На старте я работала с бизнес-экспертом по страхованию, менеджерами техподдержки и гендиректором. В основном, я проводила интервью — готовилась к совещаниям, оформляла свои идеи в виде схем и макетов, задавала вопросы и выясняла детали. После встреч обязательно оформляла результаты.

📊 Перед интервью я готовила прототипы пользовательского интерфейса, а прототипирование — это тоже метод сбора требований (но и метод анализа требований).

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

📜 Без анализа документов тоже не обошлось. Изучала все, что попадалось: старые спецификации, схемы, презентации.

🔍 А еще проводила анализ аналогов — ходила по сайтам страховых компаний, регистрировалась и смотрела, как у них устроен процесс покупки страховки.
Кстати, отголоски этого опыта есть до сих пор. Мне до сих пор приходят предложения оформить ОСАГО на машину, которой у меня нет! 😂

#requirements #sa_dev

Составьте план обучения и двигайтесь к цели! 🚀

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

✨ Составьте план обучения на следующую неделю!

Вот что можно запланировать:
1️⃣ Перечитайте посты про сбор требований по хэштегу #requirements.
2️⃣ Попрактикуйтесь! Какие требования вы бы сформулировали для интернет-магазина? Используйте метод анализа аналогов, который мы обсуждали.
3️⃣ Составьте вопросы к заказчику. Помните кейс с системой бронирования столиков в ресторане? Возьмите область интернет-магазина и попробуйте сформулировать список вопросов к заказчику.
4️⃣ Начните читать Вигерса. Его «Разработка требований к программному обеспечению» — это настоящая библия для аналитиков (как бы заезженно это не звучало).

Каждый сделанный шаг приближает вас к цели — стать уверенным системным аналитиком без страха и сомнений! 💪

#path_to_sa #requirements

Начнем эту неделю с хорошего и простого! 💡
Время поговорить о преимуществах профессии. Часть 4.

Что было ранее:
Часть 1
Часть 2
Часть 3

Работа в IT — это про классных людей вокруг.
Со временем у вас появляются общие темы для разговоров, схожие интересы, а ваш язык... немного меняется. 😉
🚀 Вы больше не напоминаете кому-то что-то, а «пингуете».
🚀 Не правите документ, а «фиксите».
🚀 Не публикуете, а «пушите».
🚀 Не ищете, а «ресерчите».
Это часть профессиональной среды, в которой интересно быть.

Вместе не только работают, но и отдыхают:
🍻 Кто-то после работы ходит в бар.
🎲 Кто-то собирается за настолками.
🏐 А кто-то играет в волейбол или другие командные игры.

IT — это ещё и про поддержку.
В нашей сфере новички — это нормально. Опытные коллеги понимают, что нужно помочь, подсказать и поддержать. Так формируется культура, где каждый может вырасти, задавая вопросы и обучаясь.

#path_to_sa

Системный аналитик — это тот, кто ищет детали

У системного аналитика много задач, и одна из самых важных — работа с требованиями. И вот что мы хотим сказать всем начинающим: не верьте исходному требованию в лоб. Любое требование можно (и нужно!) раскручивать.

Например, заказчик говорит:
Сделайте возможность регистрации пользователей на сайте.

Вы передали это разработчикам, а они возвращаются к вам с уточняющими вопросами:
😱 Какой минимум данных нужен для регистрации?
😱 Нужно ли подтверждение email или телефона?
😱 Какие поля должны быть обязательными?
😱 Нужно ли поддерживать регистрацию через соцсети?
😱 Как будет реализована безопасность?
и еще 20 вопросов

Заказчик сказал немного, но за этим стоит огромный пласт работы.
Ваша задача как системного аналитика — найти детали, которые упустил заказчик, и превратить общую идею в конкретное, понятное требование.

💡 Это и есть системное мышление. Развивайте его, и работа с требованиями станет вашим сильным преимуществом!

#requirements

Тренируем системное мышление! 🧠✨

К вам пришел заказчик с требованием:
Хочу добавить фильтры для поиска товаров в интернет-магазине.

На первый взгляд всё просто. Но давайте посмотрим, какие вопросы стоит задать, чтобы уточнить это требование:

✅ Какие параметры фильтрации важны для товаров? (цена, категория, бренд, цвет, размер и т.д.)
✅ Сколько фильтров пользователь может применить одновременно?
✅ Как будет отображаться результат после применения фильтров?
✅ Должен ли фильтр запоминать предыдущий выбор пользователя?
✅ Какие виды товаров вообще подлежат фильтрации?
✅ Как обработать ситуацию, если под выбранные фильтры нет товаров?
✅ Фильтры должны обновляться автоматически или по кнопке?

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

👉 Вопрос на подумать: Что ещё нужно уточнить у заказчика про фильтры? Можете написать свои варианты в комментариях.

#requirements

💡 Как одно требование превращается в множество?

Изначальное требование от заказчика:
Сделайте возможность оставить отзыв о продукте.

Мы задали уточняющие вопросы:
* Где будет размещаться форма для отзыва?
* Какие поля должны быть в форме?
* Нужно ли подтверждение личности пользователя?
* Можно ли добавлять фото или видео?
* Как будут модераться отзывы?
* Должны ли отображаться только положительные отзывы?

После уточнений требование превратилось в:
1️⃣ Форма отзыва с полями: текст, оценка, фото/видео.
2️⃣ Проверка пользователя через подтверждение email.
3️⃣ Автоматическая и ручная модерация.
4️⃣ Сортировка отзывов по дате или оценке.
5️⃣ Возможность лайкать и жаловаться на отзывы.

Причем каждое из этих требований можно раскладывать дальше на множество других.
Как видите, одно требование почти всегда скрывает за собой больше деталей, чем кажется на первый взгляд. Ваши вопросы — это ключ к качественным требованиям.

#requirements

Продолжаем тренировать системное мышление 🧠

Изначальное требование от заказчика:
Сделайте поиск товаров на сайте.

Здесь кажется, что всё просто, но системный аналитик то знает... Это только верхушка айсберга. Что скрывается за этой формулировкой?
1️⃣ Добавить строку поиска на главную страницу.
2️⃣ Настроить поиск по названию товара.
3️⃣ Настроить поиск по категориям и фильтрам.
4️⃣ Реализовать автодополнение и подсказки при вводе.
5️⃣ Обрабатывать некорректные запросы (например, опечатки).

Дальше детализируем один из пунктов:
4️⃣ Реализовать автодополнение и подсказки при вводе.

4.1. Источник данных для автодополнения (на основе популярных запросов или полного каталога товаров).
4.2. Ограничение на количество подсказок (например, до 10 вариантов).
4.3. Визуальное оформление подсказок (добавлять иконки категорий, фото товара и т.д.).
4.4. Реализация подсказок для часто задаваемых вопросов (например, «доставка», «возврат»).
4.5. Логика обработки, если пользователь не завершил ввод и быстро удалил текст.

Как видите, заказчик сказал одно требование про поиск, а вы на выходе получили уже больше десятка конкретных задач, каждая из которых требует внимания, обсуждения и уточнения.

Системный аналитик — это тот, кто видит детали за каждым общим требованием.

#requirements

Вы молодцы! 🎉 Спасибо, что участвовали в задании!

Все ответы были правильными, кроме:
❌ Автодобавление товаров в корзину при выборе категории — поиск и фильтрация товаров должны оставаться на уровне отображения товаров, а не вмешиваться в процессы добавления в корзину.
❌ Запретить пользователю менять категории после выбора — это ограничение, да и вредное. Мы не можем «привязать» пользователя к одной категории, так как это ограничивает возможности поиска.

Продолжим тренировку! 🧠

К нам пришли с требованием:
Реализовать корзину покупателя на сайте.

Это требование можно разложить:
1️⃣ Добавление товаров в корзину.
2️⃣ Удаление товаров из корзины.
3️⃣ Просмотр содержимого корзины.
4️⃣ Изменение количества товаров.
5️⃣ Подсчет общей стоимости товаров.
6️⃣ Проверка наличия товаров на складе.
7️⃣ Возможность сохранения корзины между сессиями.
8️⃣ Очистка всей корзины одним кликом.

#requirements

Разбираем ошибки

Судя по предыдущему заданию есть вопросы к некоторым вариантам ответа. Все варианты верные, кроме:
❌ Запретить пользователю изменять товары в корзине после добавления — это «вредное» ограничение. В нашем примере мы собирали требования к обычному интернет-магазину, где можно менять количество.
❌ Добавление товаров в Избранное — это отдельная функция, которая имеет свой сценарий использования.
❌ Оформление заказа с возможностью выбора способов доставки — это следующая стадия после наполнения корзины.

#requirements

Пишем через «Если, то, иначе» 🚦

Эту конструкцию часто используют разработчики в коде:
💡 Если пользователь нажал кнопку,
💡 то открыть окно регистрации,
💡 иначе показать подсказку.

Как это помогает нам, системным аналитикам?
Вопросы «А что будет, если...?», «Что делать, если иначе?» помогают сделать требования более качественными и детализированными.

Например:
✏️ Если товар есть в наличии, то добавляем его в корзину, иначе показываем сообщение, что товар закончился.

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

Каждое «если» — это возможность предусмотреть нюансы, улучшить требования и избежать будущих доработок. Чем больше вы задаёте такие вопросы, тем качественнее становятся ваши требования.

#requirements

Если, то, иначе: учимся предусматривать всё 🧠

Давайте проработаем требование: Возврат товара в интернет-магазине.

💡 Сценарий 1:
Если товар куплен онлайн, то возврат делается через форму на сайте, иначе через чек в магазине.

💡 Сценарий 2:
Если прошло менее 14 дней с момента покупки, то возврат возможен, иначе требуется подтверждение от службы поддержки.

💡 Сценарий 3:
Если товар повреждён, то при возврате требуется фото с описанием дефекта, иначе достаточно указать причину возврата.

Каждое из этих «если» помогает нам учесть важные аспекты работы системы.

#requirements

Алгебра логики для системного аналитика
Это про умение работать с условиями: И, ИЛИ, НЕ. Вспоминаем уроки информатики в школе!

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

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

Представим, что мы разрабатываем hh.ru.
Задача — добавить баннер с рекламой Премиума. Компания заинтересована продвигать платный тариф.
❌ Формулировка «Реализовать баннер с рекламой премиума» недостаточно.
Разработчику нужны четкие условия. В ТЗ это может выглядеть так:

- Если статус соискателя «Активно ищу работу» И у него тариф НЕ «Премиум», то отображать баннер с рекламой премиума.
- Иначе отображать баннер с предложением «проверить резюме hr-специалистами».

Давайте протестируем это условие. Какие вообще могут быть варианты?

💡 КЕЙС_1
статус соискателя = «Активно ищу работу», тариф «Премиум»
Что отобразится по описанной выше логике?
Ответ: баннер с предложением «проверить резюме hr-специалистами»

💡 КЕЙС_2
статус соискателя = «Не ищу работу», тариф «Премиум»
Что отобразится по описанной выше логике?
Ответ: снова баннер с предложением «проверить резюме hr-специалистами»

💡 КЕЙС_N .... принцип вы поняли)

Итого баннер с предложением «проверить резюме hr-специалистами» отобразится в случаях:
- статус соискателя = «Активно ищу работу», тариф «Премиум»
- статус соискателя = «Не ищу работу», тариф «Премиум»
- статус соискателя = «Не ищу работу», тариф НЕ «Премиум»
- статус соискателя = «Рассматриваю предложения», тариф «Премиум»
- статус соискателя = «Рассматриваю предложения», тариф НЕ «Премиум»

❗Почему так?
В нашем условии указан оператор «И».

Оператор И требует выполнения всех условий. Поэтому в нашем примере для показа баннера с рекламой премиума должны одновременно выполняться два условия:
1️⃣ Статус соискателя = «Активно ищу работу»,
2️⃣ Тариф НЕ = «Премиум».
Если хотя бы одно из них не выполняется, логика переходит к «Иначе».

#requirements

Оператор И: основы алгебры логики

Оператор И — означает, что для выполнения условия должны быть верны все его части.

Пример из жизни:
💡 Если сегодня выходной И погода хорошая, то мы идем на пикник.
Если хотя бы одно из условий не выполняется (не выходной или плохая погода), на пикник мы не идем.

Пример в разработке:
💡 Если пользователь активен И его подписка истекает через 7 дней, то отправить напоминание о продлении.
И = все условия должны быть выполнены.
👆 Если пользователь не активен или подписка истекает позже, напоминание не отправится.

#requirements