Как сделать описание экрана полезным? 🤔
Всем привет! 👋
С вами Вера, основатель AnalystCore.
Прямо сейчас я помогаю нашему ученику Сергею с рабочим кейсом. С его разрешения публикую наше обсуждение :)
Сергей описывает документацию по шаблону, который принят у них в команде, и использует «фразы», предусмотренные этим шаблоном. Но разработчикам такая документация не нравится, и её никто не читает.
Сергей описывает новый экран, и мы вместе сели подумать, что можно улучшить в шаблоне.
Сходу скажу:
Комментарии к одному элементу я оставила на картинках — сохраняйте 👆.
Предложенное описание элемента я как раз писала по шаблону, который даю на курсе «БАЗА». У меня свой подход, наработанный за 8 лет.
Приходите за шаблонами, теорией, практикой и поддержкой.
#тз_разбор #requirements
Всем привет! 👋
С вами Вера, основатель AnalystCore.
Прямо сейчас я помогаю нашему ученику Сергею с рабочим кейсом. С его разрешения публикую наше обсуждение :)
Сергей описывает документацию по шаблону, который принят у них в команде, и использует «фразы», предусмотренные этим шаблоном. Но разработчикам такая документация не нравится, и её никто не читает.
Сергей описывает новый экран, и мы вместе сели подумать, что можно улучшить в шаблоне.
Сходу скажу:
Что документация есть, что ее нет, она не несёт пользы. Здесь достаточно только макетов. Если просто перечислять элементы, то какой в этом смысл?
Комментарии к одному элементу я оставила на картинках — сохраняйте 👆.
Предложенное описание элемента я как раз писала по шаблону, который даю на курсе «БАЗА». У меня свой подход, наработанный за 8 лет.
Приходите за шаблонами, теорией, практикой и поддержкой.
#тз_разбор #requirements
🔥11👍7❤4
Media is too big
VIEW IN TELEGRAM
🎥 Посмотрите на курс изнутри!
Мы заглянули в первые модули, показали структуру и кусочек ДЗ.
👉 https://analystcore.com/system-analyst-base
Мы заглянули в первые модули, показали структуру и кусочек ДЗ.
👉 https://analystcore.com/system-analyst-base
👍9❤🔥3👏3
Хотите сменить работу в этом году? 🎯
Если планируете переход — сейчас самое время начинать поиски и подготовку к собеседованиям.
В крупных компаниях часто есть годовые бонусы. Чтобы их получить, нужно отработать хотя бы полгода. А значит: устроиться до конца июня! 💸
📆 До лета — всего полтора месяца. Пора освежить знания и подготовиться к интервью.
Вот полезная подборка постов, которые помогут:
📌 Мой чеклист перед собеседованиями — это список тем, которые я всегда повторяю 😉
📌 Что происходит после нажатия на кнопку «Войти»?
📌 Задача на сбор требований и проектирование
📌 Задачи на определение «это синхронное или асинхронное взаимодействие?»
📌 Спроектируйте взаимодействие: выберите синхронный или асинхронный способ
📌 Задача на Use Cases
📌 Виды интеграций
📌 Безопасный и идемпотентный
📌 Как сделать POST-запрос идемпотентным?
📌 Почитайте все по хэштегу #api
И будьте готовы к личным вопросам:
– Расскажите о себе
– Как относитесь к переработкам?
– Что будете делать, если задача на 3 дня, а работы на 5?
– А если коллега вам не отвечает три дня, а он вам нужен — как поступите?
Если планируете переход — сейчас самое время начинать поиски и подготовку к собеседованиям.
В крупных компаниях часто есть годовые бонусы. Чтобы их получить, нужно отработать хотя бы полгода. А значит: устроиться до конца июня! 💸
📆 До лета — всего полтора месяца. Пора освежить знания и подготовиться к интервью.
Вот полезная подборка постов, которые помогут:
📌 Мой чеклист перед собеседованиями — это список тем, которые я всегда повторяю 😉
📌 Что происходит после нажатия на кнопку «Войти»?
📌 Задача на сбор требований и проектирование
📌 Задачи на определение «это синхронное или асинхронное взаимодействие?»
📌 Спроектируйте взаимодействие: выберите синхронный или асинхронный способ
📌 Задача на Use Cases
📌 Виды интеграций
📌 Безопасный и идемпотентный
📌 Как сделать POST-запрос идемпотентным?
📌 Почитайте все по хэштегу #api
И будьте готовы к личным вопросам:
– Расскажите о себе
– Как относитесь к переработкам?
– Что будете делать, если задача на 3 дня, а работы на 5?
– А если коллега вам не отвечает три дня, а он вам нужен — как поступите?
Если хотите не просто повторить, а наконец разобраться во всём системно, приходите на курс «Системный аналитик. БАЗА». Он поможет вам разложить знания по полочкам, чтобы пройти собеседование без страха и потом уверенно работать на новом месте.
❤🔥6👍4🔥4
🎯 Зачем выделять MVP даже в маленькой задаче?
Иногда кажется, что MVP — это для стартапов, больших релизов, глобальных фичей.
Но на деле его стоит выделять даже в небольших задачах. Вот пример 👇
💬 Задача
«Добавить возможность пользователю загружать документы по заявке»
Звучит просто. Но как только начинаем прорабатывать требование всплывают детали:
— А можно загружать сразу несколько файлов? Сколько максимум? Как они будут отображаться вместе на странице?
— А какие форматы и ограничения по размеру?
— Нужно ли разделять ошибки? Какие?
— Где пользователь потом увидит загруженные документы?
— Нужно ли, чтобы в списке заявок была иконка вложения, чтобы пользователь знал, в каких есть файлы, а в каких нет?
— А если пользователь случайно загрузил не тот файл? Как удалить?
— Делаем предпросмотр?
— Показываем прогресс‑бар загрузки?
и пр.
📌 И вот уже «простая» задача превращается в мини‑проект с UX-сценариями, вопросами по API, фронту, бэку и дизайну.
И всё «надо, желательно, хотелось бы». И всё это увеличивает срок разработки и тестирования.
✅ Именно в этот момент аналитик должен остановиться и совместно с командой выделить MVP — минимальный объём, чтобы пользователь мог загрузить файл и отправить заявку.
В итоге MVP:
— Грузим только один файл (представим, что для нашего кейса — это ок)
— Только PDF, до 5 МБ (если нужно загрузить несколько скриншотов — пусть объединят в один PDF)
— Без предпросмотра, разделения ошибок, прогресс‑бара, иконки вложения, без удаления (пусть если что новую заявку создают) и пр.
Остальное добавляем в бэклог, отдельными задачами. Выкатим в следующих релизах.
💡 Плюсы:
— задача ушла в разработку на следующий день;
— сделали быстро;
— релиз не сорвался;
— пользователь смог загрузить документ — миссия выполнена ✅
Выделять MVP можно и нужно не только для больших задач.
Даже в маленькой задаче это спасает от переработок, задержек и метаний «а давайте добавим ещё…». Когда ограничены сроки, ваше спасение — выделить MVP.
#requirements
Иногда кажется, что MVP — это для стартапов, больших релизов, глобальных фичей.
Но на деле его стоит выделять даже в небольших задачах. Вот пример 👇
💬 Задача
«Добавить возможность пользователю загружать документы по заявке»
Звучит просто. Но как только начинаем прорабатывать требование всплывают детали:
— А можно загружать сразу несколько файлов? Сколько максимум? Как они будут отображаться вместе на странице?
— А какие форматы и ограничения по размеру?
— Нужно ли разделять ошибки? Какие?
— Где пользователь потом увидит загруженные документы?
— Нужно ли, чтобы в списке заявок была иконка вложения, чтобы пользователь знал, в каких есть файлы, а в каких нет?
— А если пользователь случайно загрузил не тот файл? Как удалить?
— Делаем предпросмотр?
— Показываем прогресс‑бар загрузки?
и пр.
📌 И вот уже «простая» задача превращается в мини‑проект с UX-сценариями, вопросами по API, фронту, бэку и дизайну.
И всё «надо, желательно, хотелось бы». И всё это увеличивает срок разработки и тестирования.
✅ Именно в этот момент аналитик должен остановиться и совместно с командой выделить MVP — минимальный объём, чтобы пользователь мог загрузить файл и отправить заявку.
В итоге MVP:
— Грузим только один файл (представим, что для нашего кейса — это ок)
— Только PDF, до 5 МБ (если нужно загрузить несколько скриншотов — пусть объединят в один PDF)
— Без предпросмотра, разделения ошибок, прогресс‑бара, иконки вложения, без удаления (пусть если что новую заявку создают) и пр.
Остальное добавляем в бэклог, отдельными задачами. Выкатим в следующих релизах.
💡 Плюсы:
— задача ушла в разработку на следующий день;
— сделали быстро;
— релиз не сорвался;
— пользователь смог загрузить документ — миссия выполнена ✅
Выделять MVP можно и нужно не только для больших задач.
Даже в маленькой задаче это спасает от переработок, задержек и метаний «а давайте добавим ещё…». Когда ограничены сроки, ваше спасение — выделить MVP.
#requirements
👍13🔥6❤4
🧩 8 способов декомпозировать задачу
Если задача выглядит громоздкой и оценена, скажем, в 3 недели работы — не спешите сразу отдавать её в разработку.
Попробуйте декомпозировать и предложите команде и менеджеру варианты, с чего начать.
Вот 8 шаблонов, которые в этом помогут 👇
1️⃣ Последовательность действий
Можно ли сначала сделать начало и конец процесса, а остальное позже?
📌 Например, процесс записи на вебинар. Сначала можно сделать форму записи и экран подтверждения. Позже интеграцию с календарём.
2️⃣ Отдельные операции
Можно ли разбить задачу на несколько операций и делать по одной?
📌 Пример: базовая декомпозиция по CRUD. Сначала делаем «создать», потом «просмотреть», «редактировать», «удалить».
3️⃣ Разные группы данных
Можно ли сначала работать с частью данных, а потом добавить остальные?
📌 Примеры:
— Разделить поведение по ролям.
— Разбить большую форму для заполнения на части.
— Разбить экран на блоки: сначала учимся выводить основную информацию, потом дополнительные блоки.
4️⃣ Упрощённый интерфейс
Можно ли сначала реализовать упрощённый UI?
📌 Пример: сначала делаем простую кнопку загрузки файла, позже добавим drag-and-drop и предпросмотр.
5️⃣ Бизнес-правила
Можно ли начать без сложной логики, а добавить её потом?
📌 Пример: на фронте сначала валидируем только заполненность полей, позже добавим более сложные проверки. Например, если в поле_1 выбрано значение А, то поле_2 становится обязательным, и в этом случае нужно выводить читаемую ошибку.
6️⃣ Производительность — позже
Можно ли сначала реализовать функциональность, а заняться оптимизацией позже?
📌 Пример: делаем простую выгрузку отчёта, даже если она будет долго грузиться. В рамках отдельной задачи будем оптимизировать процесс формирования выгрузки и биться за скорость.
7️⃣ Простота/Сложность
Можно ли сначала сделать только базу, а дополнения позже?
📌 Пример: сначала реализуем выгрузку отчёта в CSV, а позже добавим визуальный дашборд и фильтрацию.
8️⃣ Основной объём — потом
Можно ли сначала сделать happy path, а остальное позже?
📌 Например, публикация поста в админке. Сначала реализуем ввод текста и кнопку «Опубликовать». Позже добавим отложенную публикацию и черновики.
💡 Эти шаблоны помогают ускорить выход фичи в прод, сократить баги и упростить разработку. Используйте их даже в небольших задачах — это избавит вас от переделок и «пожаров» в конце спринта.
Если пост понравился, ставьте реакции ❤️🔥, так мы узнаем, интересно ли вам читать про декомпозицию.
#requirements
Если задача выглядит громоздкой и оценена, скажем, в 3 недели работы — не спешите сразу отдавать её в разработку.
Попробуйте декомпозировать и предложите команде и менеджеру варианты, с чего начать.
Вот 8 шаблонов, которые в этом помогут 👇
1️⃣ Последовательность действий
Можно ли сначала сделать начало и конец процесса, а остальное позже?
📌 Например, процесс записи на вебинар. Сначала можно сделать форму записи и экран подтверждения. Позже интеграцию с календарём.
2️⃣ Отдельные операции
Можно ли разбить задачу на несколько операций и делать по одной?
📌 Пример: базовая декомпозиция по CRUD. Сначала делаем «создать», потом «просмотреть», «редактировать», «удалить».
3️⃣ Разные группы данных
Можно ли сначала работать с частью данных, а потом добавить остальные?
📌 Примеры:
— Разделить поведение по ролям.
— Разбить большую форму для заполнения на части.
— Разбить экран на блоки: сначала учимся выводить основную информацию, потом дополнительные блоки.
4️⃣ Упрощённый интерфейс
Можно ли сначала реализовать упрощённый UI?
📌 Пример: сначала делаем простую кнопку загрузки файла, позже добавим drag-and-drop и предпросмотр.
5️⃣ Бизнес-правила
Можно ли начать без сложной логики, а добавить её потом?
📌 Пример: на фронте сначала валидируем только заполненность полей, позже добавим более сложные проверки. Например, если в поле_1 выбрано значение А, то поле_2 становится обязательным, и в этом случае нужно выводить читаемую ошибку.
6️⃣ Производительность — позже
Можно ли сначала реализовать функциональность, а заняться оптимизацией позже?
📌 Пример: делаем простую выгрузку отчёта, даже если она будет долго грузиться. В рамках отдельной задачи будем оптимизировать процесс формирования выгрузки и биться за скорость.
7️⃣ Простота/Сложность
Можно ли сначала сделать только базу, а дополнения позже?
📌 Пример: сначала реализуем выгрузку отчёта в CSV, а позже добавим визуальный дашборд и фильтрацию.
8️⃣ Основной объём — потом
Можно ли сначала сделать happy path, а остальное позже?
📌 Например, публикация поста в админке. Сначала реализуем ввод текста и кнопку «Опубликовать». Позже добавим отложенную публикацию и черновики.
💡 Эти шаблоны помогают ускорить выход фичи в прод, сократить баги и упростить разработку. Используйте их даже в небольших задачах — это избавит вас от переделок и «пожаров» в конце спринта.
Если пост понравился, ставьте реакции ❤️🔥, так мы узнаем, интересно ли вам читать про декомпозицию.
#requirements
❤🔥14👍8👏5
Всем привет! 👋
В последнее время у нас получаются слишком большие посты 😅. Для баланса запустим новую рубрику «мини-лайфхаки / советы».
Это короткие и местами очевидные советы, но именно они часто спасают нас в повседневной работе. Будем периодически делиться ими в течение недели.
🎯 Мини-лайфхак №1
Системный аналитик — это источник правды для своей команды. Мы должны формулировать требования максимально чётко.
Если есть неопределённость — выносим как открытый вопрос, обсуждаем и уточняем.
❓ А какой мини-лайфхак дали бы вы другим аналитикам?
Пишите в комментариях 💬. Лучшие советы попадут в следующий пост рубрики 😉
#лайфхаки #requirements
В последнее время у нас получаются слишком большие посты 😅. Для баланса запустим новую рубрику «мини-лайфхаки / советы».
Это короткие и местами очевидные советы, но именно они часто спасают нас в повседневной работе. Будем периодически делиться ими в течение недели.
🎯 Мини-лайфхак №1
Не используйте в ТЗ формулировки вроде «возможно», «наверное», «может быть».
Такие слова так и побуждают спросить: «А ты сам то уверен в своём ТЗ?»
Системный аналитик — это источник правды для своей команды. Мы должны формулировать требования максимально чётко.
Если есть неопределённость — выносим как открытый вопрос, обсуждаем и уточняем.
❓ А какой мини-лайфхак дали бы вы другим аналитикам?
Пишите в комментариях 💬. Лучшие советы попадут в следующий пост рубрики 😉
#лайфхаки #requirements
👍14👏5🔥4
🔍 Как понять, что требование плохо сформулировано? Проверьте эти 3 признака
Сохраняйте себе, чтобы под рукой был мини-чеклист с примерами 👇
1️⃣ Недвусмысленность
Все должны понимать требование одинаково и без уточнений. Избегайте абстрактных формулировок.
История заказов:
❌ Пользователь может видеть все свои заказы за последний год
✅ Пользователь может видеть все свои заказы за последние 365 дней, отсчитывая от текущей даты
Поиск по сайту:
❌ Пользователь может искать по названию и категории товара
✅ Пользователь может искать товары отдельно по названию, отдельно по категории, либо по комбинации обоих полей
2️⃣ Непротиворечивость
Требования не должны конфликтовать друг с другом.
Форма заказа:
❌ Кнопка «Отправить заказ» должна всегда быть активной, но нажать можно только если все обязательные поля заполнены
✅ Кнопка «Отправить заказ» активна только после заполнения всех обязательных полей
Редактирование заявки:
❌ Заявку можно редактировать в любое время, но после отправки на согласование редактировать нельзя
✅ Редактировать заявку можно до тех пор, пока она не отправлена на согласование
3️⃣ Проверяемость
Тестировщик должен легко и однозначно проверить, выполнено требование или нет.
Уведомления по email:
❌ Пользователь должен получать уведомления достаточно быстро после регистрации
✅ Пользователь должен получать email-уведомление о регистрации в течение 5 минут после её завершения
Валидация пароля:
❌ Пароль должен быть сложным и надёжным
✅ Пароль должен состоять минимум из 8 символов, включать минимум 1 цифру, 1 заглавную букву и 1 спецсимвол из списка @#$
👉 Подробнее о курсе «Системный аналитик.БАЗА»
#requirements
Сохраняйте себе, чтобы под рукой был мини-чеклист с примерами 👇
1️⃣ Недвусмысленность
Все должны понимать требование одинаково и без уточнений. Избегайте абстрактных формулировок.
История заказов:
❌ Пользователь может видеть все свои заказы за последний год
✅ Пользователь может видеть все свои заказы за последние 365 дней, отсчитывая от текущей даты
Поиск по сайту:
❌ Пользователь может искать по названию и категории товара
✅ Пользователь может искать товары отдельно по названию, отдельно по категории, либо по комбинации обоих полей
2️⃣ Непротиворечивость
Требования не должны конфликтовать друг с другом.
Форма заказа:
❌ Кнопка «Отправить заказ» должна всегда быть активной, но нажать можно только если все обязательные поля заполнены
✅ Кнопка «Отправить заказ» активна только после заполнения всех обязательных полей
Редактирование заявки:
❌ Заявку можно редактировать в любое время, но после отправки на согласование редактировать нельзя
✅ Редактировать заявку можно до тех пор, пока она не отправлена на согласование
3️⃣ Проверяемость
Тестировщик должен легко и однозначно проверить, выполнено требование или нет.
Уведомления по email:
❌ Пользователь должен получать уведомления достаточно быстро после регистрации
✅ Пользователь должен получать email-уведомление о регистрации в течение 5 минут после её завершения
Валидация пароля:
❌ Пароль должен быть сложным и надёжным
✅ Пароль должен состоять минимум из 8 символов, включать минимум 1 цифру, 1 заглавную букву и 1 спецсимвол из списка @#$
Если вы ловили себя на мысли, что ваши требования «понятны только вам» 😱 или команда задаёт слишком много уточняющих вопросов, значит, пора подтянуть базу 👉 Приглашаем на курс «Системный аналитик.БАЗА».
👉 Подробнее о курсе «Системный аналитик.БАЗА»
#requirements
👍11🔥6👏3
🎯 Мини-лайфхак №2
❌ Доработать форму заявки (какую именно доработку делаем?)
✅ Добавить поле Цель кредита в форму заявки
Так на дейли вы смотрите на доску и сразу понимаете, о чём идёт речь. Экономите время всей команде.
❓А вы бы что посоветовали? Пишите в комментариях 💬
#лайфхаки #requirements
Пишите заголовок задачи в Jira так, чтобы суть задачи была понятна без описания.
❌ Доработать форму заявки (какую именно доработку делаем?)
✅ Добавить поле Цель кредита в форму заявки
Так на дейли вы смотрите на доску и сразу понимаете, о чём идёт речь. Экономите время всей команде.
❓А вы бы что посоветовали? Пишите в комментариях 💬
#лайфхаки #requirements
👍12🔥5❤2
🎯 На собеседовании не обойтись без вопросов по теме требований, ведь это основа работы аналитика
Мы собираем требования, чтобы выявить ожидания пользователей, определить функциональность, спроектировать API, БД и пр. Неважно, за какую задачу берёмся — без требований ничего не получится.
Сохраняйте самые частые вопросы по требованиям 👇
1️⃣ Какие методы сбора требований знаете? Какие применяли на практике?
2️⃣ В каком виде вам приходят задачи на текущем проекте и на прошлых? С какими подходами сталкивались?
3️⃣ Как, по вашему мнению, выглядит идеальная задача, которая поступает к вам на анализ?
4️⃣ Какие виды требований знаете?
5️⃣ Прорабатывали ли нефункциональные требования? Что к ним относится?
6️⃣ Как понять, что требование хорошее? (ожидают услышать «критерии хороших требований»)
7️⃣ Использовали ли в работе User Story? Как работали по ним?
8️⃣ Для чего применяют User Story, а для чего Use Case?
9️⃣ Работали с Use Case? Что это такое? По какому шаблону описывали?
1️⃣0️⃣ Участвовали ли в декомпозиции задач? Знаете, как можно декомпозировать? Давайте попробуем: <дают задачу на декомпозицию>
1️⃣1️⃣ Как бы вы вели документацию на проекте? Какие разделы в ней были бы? Что для вас «идеальный шаблон»?
Ваши Вера и Юрий, основатели AnalystCore
Удачи на собеседованиях 💪
#requirements #interview
Мы собираем требования, чтобы выявить ожидания пользователей, определить функциональность, спроектировать API, БД и пр. Неважно, за какую задачу берёмся — без требований ничего не получится.
Сохраняйте самые частые вопросы по требованиям 👇
1️⃣ Какие методы сбора требований знаете? Какие применяли на практике?
2️⃣ В каком виде вам приходят задачи на текущем проекте и на прошлых? С какими подходами сталкивались?
3️⃣ Как, по вашему мнению, выглядит идеальная задача, которая поступает к вам на анализ?
4️⃣ Какие виды требований знаете?
5️⃣ Прорабатывали ли нефункциональные требования? Что к ним относится?
6️⃣ Как понять, что требование хорошее? (ожидают услышать «критерии хороших требований»)
7️⃣ Использовали ли в работе User Story? Как работали по ним?
8️⃣ Для чего применяют User Story, а для чего Use Case?
9️⃣ Работали с Use Case? Что это такое? По какому шаблону описывали?
1️⃣0️⃣ Участвовали ли в декомпозиции задач? Знаете, как можно декомпозировать? Давайте попробуем: <дают задачу на декомпозицию>
1️⃣1️⃣ Как бы вы вели документацию на проекте? Какие разделы в ней были бы? Что для вас «идеальный шаблон»?
Если чувствуете, что пока не хватает кругозора, работали только в одной-двух компаниях, интересно, как бывает по-другому, или просто хотите подтянуть базу, приглашаем на наш курс «Системный аналитик.БАЗА»
Ваши Вера и Юрий, основатели AnalystCore
Удачи на собеседованиях 💪
#requirements #interview
👍12❤6🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
☀️ Лето — идеальное время, чтобы...
Знаем, летом хочется отдыхать, а не учиться. Но именно летом у многих появляется время на себя, ведь нет авралов на работе и всё чуточку спокойнее.
А значит — можно учиться без стресса.
Сейчас отличное время, чтобы сделать первый шаг к большим изменениям:
💬 Обрести уверенность в себе и перестать бояться встреч с заказчиками и разработчиками
💪 Перестать полагаться на наставника и начать самостоятельно решать задачи
📚 Узнать best practices и начать применять их в работе, а не действовать по наитию
🌟 Стать классным специалистом, который реально помогает команде
💸 Получить повышение
Часто, чтобы прийти к этому, нужна именно БАЗА. И мы готовы вам её дать.
💡 У нас есть бесплатный ТЕСТ-ДРАЙВ курса.
Перейдите по ссылке, зарегистрируйтесь и посмотрите первый урок.
Проверьте, подойдёт ли вам наш подход: https://analystcore.com/system-analyst-base
Знаем, летом хочется отдыхать, а не учиться. Но именно летом у многих появляется время на себя, ведь нет авралов на работе и всё чуточку спокойнее.
А значит — можно учиться без стресса.
Сейчас отличное время, чтобы сделать первый шаг к большим изменениям:
💬 Обрести уверенность в себе и перестать бояться встреч с заказчиками и разработчиками
💪 Перестать полагаться на наставника и начать самостоятельно решать задачи
📚 Узнать best practices и начать применять их в работе, а не действовать по наитию
🌟 Стать классным специалистом, который реально помогает команде
💸 Получить повышение
Часто, чтобы прийти к этому, нужна именно БАЗА. И мы готовы вам её дать.
💡 У нас есть бесплатный ТЕСТ-ДРАЙВ курса.
Перейдите по ссылке, зарегистрируйтесь и посмотрите первый урок.
Проверьте, подойдёт ли вам наш подход: https://analystcore.com/system-analyst-base
👍8❤5💯3
🛠 Мини-лайфхак №3
Описывайте все по этой структуре, даже если кажется, что «всё и так понятно».
Зачем?
✅ Чтобы через неделю вы сами вспомнили, в чём была проблема.
✅ Чтобы разработчик не додумывал за вас.
✅ Чтобы тестировщик понял, как проверять фиксы.
#лайфхаки #requirements
Нашли баг, и нужно самому его завести без тестировщика? Опишите его по шаблону:
— Шаги воспроизведения (1, 2, 3, 4, 5)
— Фактический результат
— Ожидаемый результат
Описывайте все по этой структуре, даже если кажется, что «всё и так понятно».
Зачем?
✅ Чтобы через неделю вы сами вспомнили, в чём была проблема.
✅ Чтобы разработчик не додумывал за вас.
✅ Чтобы тестировщик понял, как проверять фиксы.
#лайфхаки #requirements
👍11❤4🔥4
👵 Даже опытные аналитики часто не справляются с задачами по требованиям на собеседовании
Что это за задачи?
На собеседовании дают конкретное требование и просят продумать для него решение.
Пример реального задания:
В этом задании проверяют:
— какие вопросы вы задаёте,
— как глубоко копаете,
— выйдете ли вы на мысль, что можно создать отдельный сервис для уведомлений,
— выйдете ли на админку для маркетологов, где они смогут задавать условия,
— предложите ли внедрить акционные механики, которые можно запускать без релизов.
💡 Вот так одно требование может многое показать о вашем уровне и мышлении.
Чтобы действительно уверенно выполнять такие задания, нужно тренировать навык работы с требованиями и развивать системное мышление.
Практикуйтесь ежедневно!
Возьмите любое требование и раскрутите его дальше: что ещё нужно учесть, какие модули, сценарии, интеграции, бизнес-правила?
С нас подборка требований, на которых можете потренироваться:
❓Хотим напомнить клиентам о брошенной корзине через 2 часа
❓Хотим показывать на главной странице «персональные рекомендации»
❓Добавить возможность пользователю «заморозить» подписку на месяц
С вами Вера и Юрий ❤️,
основатели AnalystCore
#requirements #interview
Что это за задачи?
На собеседовании дают конкретное требование и просят продумать для него решение.
Пример реального задания:
«Хотим слать уведомления клиентам, которые сделали только один заказ».
Проработайте решение, соберите требования.
В этом задании проверяют:
— какие вопросы вы задаёте,
— как глубоко копаете,
— выйдете ли вы на мысль, что можно создать отдельный сервис для уведомлений,
— выйдете ли на админку для маркетологов, где они смогут задавать условия,
— предложите ли внедрить акционные механики, которые можно запускать без релизов.
💡 Вот так одно требование может многое показать о вашем уровне и мышлении.
Чтобы действительно уверенно выполнять такие задания, нужно тренировать навык работы с требованиями и развивать системное мышление.
Практикуйтесь ежедневно!
Возьмите любое требование и раскрутите его дальше: что ещё нужно учесть, какие модули, сценарии, интеграции, бизнес-правила?
С нас подборка требований, на которых можете потренироваться:
❓Хотим напомнить клиентам о брошенной корзине через 2 часа
❓Хотим показывать на главной странице «персональные рекомендации»
❓Добавить возможность пользователю «заморозить» подписку на месяц
На нашем курсе «Системный аналитик.БАЗА» вы прокачаете навык работы с требованиями, научитесь задавать правильные вопросы, видеть подводные камни и докапываться до сути. Это та самая база, без которой не получится уверенно двигаться дальше.
С вами Вера и Юрий ❤️,
основатели AnalystCore
#requirements #interview
👍8🔥7❤4
Когда говорим о требованиях, никуда без User Story и Use Case
Они помогают не только фиксировать требования, но и глубже прорабатывать логику работы системы.
Сохраняйте подборку наших постов 👇
📌 Ищем требования с помощью Use Case — идеальная техника для поиска альтернативных кейсов и анализа, что может пойти не так
📌 Альтернативные сценарии — не только ошибки
📌 В Use Case можно «свёртывать» ошибки — см. подробности
📌 Почему не рекомендуют писать детали пользовательского интерфейса в Use Case — смотрите минусы
📌 Use Case и User Story — это разные инструменты и их часто сравнивают. Одно из отличий — По User Story не написать документацию
📌 Считаю, что Use Case — это не про «писать», это про «мыслить»
📌 Альтернативные сценарии в процессе авторизации
📌 Шаблон Use Case на примере записи на приём к врачу
📌 Как называть Use Case?
📌 Use Cases для лифта — разбор задачи с собеседования
📌 Примеры плохих User Story и объяснение, почему они такие плохие
📌 Исправили плохие User Story
📌 User Story ≠ «просто пришёл на PBR»
📌 Почему истории от «Системы» — это плохо
#requirements
Они помогают не только фиксировать требования, но и глубже прорабатывать логику работы системы.
Сохраняйте подборку наших постов 👇
📌 Ищем требования с помощью Use Case — идеальная техника для поиска альтернативных кейсов и анализа, что может пойти не так
📌 Альтернативные сценарии — не только ошибки
📌 В Use Case можно «свёртывать» ошибки — см. подробности
📌 Почему не рекомендуют писать детали пользовательского интерфейса в Use Case — смотрите минусы
📌 Use Case и User Story — это разные инструменты и их часто сравнивают. Одно из отличий — По User Story не написать документацию
📌 Считаю, что Use Case — это не про «писать», это про «мыслить»
📌 Альтернативные сценарии в процессе авторизации
📌 Шаблон Use Case на примере записи на приём к врачу
📌 Как называть Use Case?
📌 Use Cases для лифта — разбор задачи с собеседования
📌 Примеры плохих User Story и объяснение, почему они такие плохие
📌 Исправили плохие User Story
📌 User Story ≠ «просто пришёл на PBR»
📌 Почему истории от «Системы» — это плохо
Чтобы действительно научиться писать Use Case и User Story, недостаточно теории. Нужно тренировать насмотренность. Видеть кучу плохих примеров, получать разборы ошибок и предложения, как исправить.
За всем этим приходите к нам 😉 У нас есть отдельный курс User Story & Use Case.
#requirements
👍9💯6👏5🔥1
🛠️ Мини-лайфхак №4
#лайфхаки #requirements
В Use Case не пишите «если» в шагах сценария — для этого в данной технике есть «альтернативные потоки».
#лайфхаки #requirements
👍10🔥5👏4
🛠️ Мини-лайфхак №5
Чёткие границы задачи экономят время на обсуждениях и снимают лишние вопросы.
#лайфхаки #requirements
Пишите «не делаем» явно. Если в задаче не делаем drag-and-drop — напишите это прямо. Иначе команда всё-равно спросит.
Чёткие границы задачи экономят время на обсуждениях и снимают лишние вопросы.
#лайфхаки #requirements
👍11🔥4👏3❤1
✨ Cамый любимый вопрос аналитика
Есть один вопрос, который помогает увидеть то, что обычно остаётся за кадром.
Он проверяет систему на прочность и открывает глаза на некоторые вещи.
Это вопрос — «А что будет, если…?» 🧠
📌 А что будет, если пользователь не заполнит обязательное поле?
📌 А что будет, если файл слишком большой?
📌 А что будет, если соединение с сервером прервётся?
Каждый такой вопрос — как краш-тест для вашей идеи. Он помогает предусмотреть сбои, ошибки, исключения. То, о чём часто забывают, но из-за чего потом всё ломается. 😅
🎯 Этот вопрос особенно важен в момент, когда задача вроде бы уже понятна, когда уже хочется бежать писать ТЗ. Вот тогда и надо притормозить и задать себе (и команде) вопрос:
А что будет, если…?
#requirements
Есть один вопрос, который помогает увидеть то, что обычно остаётся за кадром.
Он проверяет систему на прочность и открывает глаза на некоторые вещи.
Это вопрос — «А что будет, если…?» 🧠
📌 А что будет, если пользователь не заполнит обязательное поле?
📌 А что будет, если файл слишком большой?
📌 А что будет, если соединение с сервером прервётся?
Каждый такой вопрос — как краш-тест для вашей идеи. Он помогает предусмотреть сбои, ошибки, исключения. То, о чём часто забывают, но из-за чего потом всё ломается. 😅
🎯 Этот вопрос особенно важен в момент, когда задача вроде бы уже понятна, когда уже хочется бежать писать ТЗ. Вот тогда и надо притормозить и задать себе (и команде) вопрос:
А что будет, если…?
#requirements
👍16👏4💯4
💬 Какие бывают вопросы?
Не все вопросы одинаково полезны 😅
Иногда мы что-то спрашиваем, но получаем размытый или вообще не тот ответ.
Системному аналитику важно уметь задавать вопросы разного типа — в зависимости от того, какую информацию вы хотите получить.
📌 Открытые — чтобы собрать как можно больше информации:
→ «Расскажите, как сейчас работает этот процесс?»
→ «Что происходит после того, как пользователь нажимает кнопку?»
📌 Закрытые — чтобы уточнить детали:
→ «То есть сейчас файл загружается вручную, верно?»
→ «Пользователь должен быть авторизован, чтобы увидеть эту страницу?»
📌 Наводящие — чтобы направить собеседника к точному ответу:
→ «Получается, система должна отправлять уведомление только один раз?»
→ «Если данных нет, нужно показать пустой список, так?»
#requirements
Не все вопросы одинаково полезны 😅
Иногда мы что-то спрашиваем, но получаем размытый или вообще не тот ответ.
Системному аналитику важно уметь задавать вопросы разного типа — в зависимости от того, какую информацию вы хотите получить.
📌 Открытые — чтобы собрать как можно больше информации:
→ «Расскажите, как сейчас работает этот процесс?»
→ «Что происходит после того, как пользователь нажимает кнопку?»
📌 Закрытые — чтобы уточнить детали:
→ «То есть сейчас файл загружается вручную, верно?»
→ «Пользователь должен быть авторизован, чтобы увидеть эту страницу?»
📌 Наводящие — чтобы направить собеседника к точному ответу:
→ «Получается, система должна отправлять уведомление только один раз?»
→ «Если данных нет, нужно показать пустой список, так?»
#requirements
👍12🔥5👏2
🔍 Первый вопрос, который должен задать аналитик — «ЗАЧЕМ?»
К вам прилетела задача:
* Нужно добавить кнопку
* Сделайте возможность загрузки файла
* Добавьте новое поле в форму
Очень хочется сразу бежать и начать делать: нарисовать прототипы, описать ТЗ, поставить задачу разработчикам...
Но стоп. Сначала задайте вопрос: «А зачем вы хотите добавить кнопку?»
Какая причина?
Какую проблему мы решаем?
Это не просто теоретический совет. Это боль, которую прочувствовал наш подписчик и мы сами в начале карьеры в IT. 🙈
🙋 Сергей поделился своим кейсом:
Вот почему «ЗАЧЕМ?» — это первый вопрос аналитика при проработке задачи.
Он помогает понять суть и найти самое эффективное решение, а не просто «сделать, как сказали».
#requirements
К вам прилетела задача:
* Нужно добавить кнопку
* Сделайте возможность загрузки файла
* Добавьте новое поле в форму
Очень хочется сразу бежать и начать делать: нарисовать прототипы, описать ТЗ, поставить задачу разработчикам...
Но стоп. Сначала задайте вопрос: «А зачем вы хотите добавить кнопку?»
Какая причина?
Какую проблему мы решаем?
Это не просто теоретический совет. Это боль, которую прочувствовал наш подписчик и мы сами в начале карьеры в IT. 🙈
🙋 Сергей поделился своим кейсом:
Заказчик пришёл с требованием, я сразу поставил задачу на разработку. Задачу оценили в 5 рабочих дней, реализовали, пошли показывать, а заказчик остался недоволен. Хотя всё сделали «в лоб», как он и хотел!
На встрече опытный разработчик задал вопрос: «А зачем вообще это нужно?» — и выяснилось, что настоящую проблему можно было решить даже без разработки.
Это урок, который я запомню на всю жизнь. Надеюсь 😞
Вот почему «ЗАЧЕМ?» — это первый вопрос аналитика при проработке задачи.
Он помогает понять суть и найти самое эффективное решение, а не просто «сделать, как сказали».
#requirements
❤15👍7🔥2
🔍 Хотите добраться до сути задачи? Используйте технику «5 почему»!
Бизнес часто приходит с готовым решением:
«Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться»
Очень хочется сказать «окей» и сразу бежать писать ТЗ… Но стоп!
Используем технику 5 «почему» — и докопаемся до сути.
Запрос: Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться
1️⃣ Почему нужна эта кнопка?
→ Потому что клиенты часто звонят, чтобы уточнить, на каком этапе их заявка, но им трудно найти наш номер.
2️⃣ А почему клиенты не видят этап своей заявки в личном кабинете?
→ Потому что сейчас там просто написано «Заявка в обработке».
3️⃣Почему выводится общий статус?
→ Потому что статусов заявки в системе много, и они пока не отображаются клиенту.
4️⃣Почему не отображаются?
→ Потому что никто не описал, какие статусы понятны пользователю и как их показать.
5️⃣ Почему важно это показать?
→ Потому что тогда клиент поймёт, что заявка движется, и не будет нервничать.
📌 Вывод:
Проблема не в отсутствии кнопки, а в недостаточной прозрачности процесса.
Если просто добавить кнопку, звонков станет ещё больше.
✅ Лучшее решение:
- Показать клиенту понятные статусы заявки в интерфейсе: «что происходит с его заказом?»
- Также мы выяснили, что клиентам трудно найти номер телефона в ЛК — отдельной задачей подумаем, куда лучше разместить номер
Так работает техника «5 почему». Она помогает найти корень проблемы, а не просто реализовать первое предложенное решение.
📝❓ Маленькое задание:
Выберите что-то из своей жизни — бытовое или рабочее.
Например:
— «Хочу поменять работу / команду / проект»
— «Не могу начать учиться»
И попробуйте раскрутить это с помощью «5 почему».
Пишите свои выводы в комментарии, если захотите поделиться!
С вами Вера и Юрий,
основатели AnalystCore 🙌
#requirements
Бизнес часто приходит с готовым решением:
«Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться»
Очень хочется сказать «окей» и сразу бежать писать ТЗ… Но стоп!
Используем технику 5 «почему» — и докопаемся до сути.
Запрос: Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться
1️⃣ Почему нужна эта кнопка?
→ Потому что клиенты часто звонят, чтобы уточнить, на каком этапе их заявка, но им трудно найти наш номер.
2️⃣ А почему клиенты не видят этап своей заявки в личном кабинете?
→ Потому что сейчас там просто написано «Заявка в обработке».
3️⃣Почему выводится общий статус?
→ Потому что статусов заявки в системе много, и они пока не отображаются клиенту.
4️⃣Почему не отображаются?
→ Потому что никто не описал, какие статусы понятны пользователю и как их показать.
5️⃣ Почему важно это показать?
→ Потому что тогда клиент поймёт, что заявка движется, и не будет нервничать.
📌 Вывод:
Проблема не в отсутствии кнопки, а в недостаточной прозрачности процесса.
Если просто добавить кнопку, звонков станет ещё больше.
✅ Лучшее решение:
- Показать клиенту понятные статусы заявки в интерфейсе: «что происходит с его заказом?»
- Также мы выяснили, что клиентам трудно найти номер телефона в ЛК — отдельной задачей подумаем, куда лучше разместить номер
Так работает техника «5 почему». Она помогает найти корень проблемы, а не просто реализовать первое предложенное решение.
📝❓ Маленькое задание:
Выберите что-то из своей жизни — бытовое или рабочее.
Например:
— «Хочу поменять работу / команду / проект»
— «Не могу начать учиться»
И попробуйте раскрутить это с помощью «5 почему».
Пишите свои выводы в комментарии, если захотите поделиться!
С вами Вера и Юрий,
основатели AnalystCore 🙌
#requirements
❤11👍6👏2
Как я начинала собирать требования?
Привет! 👋
С вами Вера, основатель AnalystCore.
Моим первым местом работы был стартап в сфере страхования.
🗣️ На старте я работала с экспертами по страхованию, тех.поддержкой и ген.директором. В основном, проводила интервью — готовилась к совещаниям, оформляла свои идеи в виде схем и задавала вопросы.
📊 Перед интервью готовила прототипы UI, а прототипирование — это тоже метод сбора требований (но и метод анализа требований).
👀 Мы приглашали пользователей в офис! Наблюдали, как они используют продукт, что им нравится, а что раздражает.
📜 Без анализа документов тоже не обошлось. Изучала все, что попадалось: старые спецификации, схемы, презентации.
🔍 А еще проводила анализ аналогов — ходила по сайтам страховых компаний, регистрировалась и смотрела, как у них устроен процесс покупки страховки.
Кстати, отголоски этого опыта есть до сих пор. Мне до сих пор приходят предложения оформить ОСАГО на машину, которой у меня нет! 😂
#requirements #sa_dev
Привет! 👋
С вами Вера, основатель AnalystCore.
Моим первым местом работы был стартап в сфере страхования.
🗣️ На старте я работала с экспертами по страхованию, тех.поддержкой и ген.директором. В основном, проводила интервью — готовилась к совещаниям, оформляла свои идеи в виде схем и задавала вопросы.
📊 Перед интервью готовила прототипы UI, а прототипирование — это тоже метод сбора требований (но и метод анализа требований).
👀 Мы приглашали пользователей в офис! Наблюдали, как они используют продукт, что им нравится, а что раздражает.
📜 Без анализа документов тоже не обошлось. Изучала все, что попадалось: старые спецификации, схемы, презентации.
🔍 А еще проводила анализ аналогов — ходила по сайтам страховых компаний, регистрировалась и смотрела, как у них устроен процесс покупки страховки.
Кстати, отголоски этого опыта есть до сих пор. Мне до сих пор приходят предложения оформить ОСАГО на машину, которой у меня нет! 😂
#requirements #sa_dev
👍10❤🔥4🥰4😁3💯1
Не всегда очевидно, какие аналоги анализировать 🤔
Привет! 👋
С вами Вера, основатель AnalystCore.
В продолжение темы методов сбора требований хочу отметить «анализ аналогов».
В далёком 2020 у меня был опыт работы в довольно специфической сфере — мы делали судебную систему. Через неё сотрудники банков могли подавать обращения в суд о взыскании кредитной задолженности и пр.
Где найти аналог будущей системы? На что опираться? Есть ли уже подобные системы? Как получить к ним доступ, где взять логин и пароль?
💡 Так заказчик нам поможет и сам подскажет, какие системы нужно «пощупать» и взять за ориентир! Но помним, изучить аналоги недостаточно. Мы не знаем, как их система работает «под капотом», какие есть нюансы. Из такого метода нельзя понять все требования.
#requirements #sa_dev
Привет! 👋
С вами Вера, основатель AnalystCore.
В продолжение темы методов сбора требований хочу отметить «анализ аналогов».
В далёком 2020 у меня был опыт работы в довольно специфической сфере — мы делали судебную систему. Через неё сотрудники банков могли подавать обращения в суд о взыскании кредитной задолженности и пр.
Где найти аналог будущей системы? На что опираться? Есть ли уже подобные системы? Как получить к ним доступ, где взять логин и пароль?
Вне зависимости от предметной области стоит узнать у заказчика, а на какой продукт мы ориентируемся, есть ли конкуренты, какие системы нравятся?
💡 Так заказчик нам поможет и сам подскажет, какие системы нужно «пощупать» и взять за ориентир! Но помним, изучить аналоги недостаточно. Мы не знаем, как их система работает «под капотом», какие есть нюансы. Из такого метода нельзя понять все требования.
#requirements #sa_dev
👍10🔥2