📄Подборка статей

😀Безопасность API (аутентификация и авторизация): проблемы, решения, практические рекомендации — статья на Хабре, в которой рассказывается о системном подходе к безопасности API

😀Умный вайб-кодинг или семь раз отмерь, один раз сгенерь — статья на Хабре про практику AI-Driven разработки (AIDD)

😀Интеграция и внешние идентификаторы — в статье на vc рассказывается, что может пойти не так при интеграции систем, и как можно хранить внешние идентификаторы

Шпаргалка на тему «Выявление требований»

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

🚀 Для начала начните с подготовки:

Перед встречей с заказчиком:

- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)

- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты

- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.

📋 Техники сбора требований
Используйте комбинацию методов:

- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»

- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.

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

- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.

✅ Как готовиться к интервью

- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»

- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.

- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.

📑 Документирование требований

📎 Статья: Стандарты и шаблоны для ТЗ на разработку ПО

- Структурируйте информацию. Разделяйте требования на:

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

- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.

- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.

❗️Чего делать НЕ стоит

- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.

- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.

- Не используйте технический жаргон. Говорите на языке заказчика.

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

✅ Проверка и согласование

- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).

- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.

____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.

- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).

- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.

Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.

Вижу — значит, понимаю: зачем нужны прототипы

Прототип — это способ увидеть проблему до того, как она съест ваш бюджет, сроки и репутацию.

➡️Когда делать прототип?
🔚У вас есть непонятные требования
🔚Клиент говорит «Узнаю, когда увижу»
🔚Риски — высокие, цена ошибки — ещё выше
🔚Интерфейс критичен для продукта
🔚Нужно быстро получить фидбек

➡️Какие бывают прототипы?
🔚Одноразовый — быстрое прояснение требований, наброски экранов
🔚Эволюционный — постепенная сборка функционала, приближающаяся к финальному продукту
🔚Экспериментальный — проверка архитектуры, производительности, технической реализуемости

➡️Прототип это не Продукт
Важно: прототип — это НЕ MVP, не финал, не половина разработки. Это инструмент. И да, его можно сделать в PowerPoint, Figma или даже на бумаге. Главное — не застревать в отрисовке, а быстро получать обратную связь.

➡️Этапы:
🔚Сценарии использования
🔚Карты экранов / диалогов
🔚Вайрфрейм
🔚Фидбек от пользователей
🔚Дизайн интерфейса
Чем больше итераций — тем меньше сюрпризов.

➡️Риски при работе с прототипами
🔚Заигрались и ушли в перфекционизм
🔚Клиенты начинают думать, что это уже рабочая система
🔚Архитектура не выдержит масштабирования
🔚Команда тратит больше времени на отрисовку, чем на анализ

Документирование — это мощнейший инструмент системного мышления.

Мы часто думаем: «Документацию никто не читает, значит, ее можно не писать»

Это самое частое оправдание. Но в нем кроется ошибка: ценность не только в готовом документе, но и в процессе его создания.

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

3 причины писать «для себя»

😻Выявление «дыр» и противоречий
Пока требование крутится у вас в голове, оно кажется идеальным. Но стоит начать излагать его на бумаге, как сразу всплывают вопросы:

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

🧡 Вывод: Документирование — это стресс-тест для ваших требований.

😻Структурирование информации
Наша память нелинейна. В ходе интервью мы получаем информацию кусками: из диалога с экспертом, из письма, из старой документации.
Процесс написания — это сбор паззла. Вы группируете разрозненные данные в логические блоки: функциональные требования, бизнес-правила, сценарии.

🧡Вывод: Голова освобождается от хранения информации, и вы можете сконцентрироваться на анализе.

😻Создание «якоря» для памяти и коммуникации
Через месяц или даже неделю вы не вспомните, почему было принято то или иное решение. Записав ход мыслей и аргументы, вы создаете надежный источник правды, к которому всегда можно вернуться.

🧡 Вывод: Документация — это внешняя память аналитика, которая не подводит.

Как применять на практике?

Не обязательно сразу писать полноценный BRD. Начинайте с малого:

🦊Конспектируйте встречи. Не просто записывайте решения, а тезисно формулируйте проблему и аргументы.
🦊Рисуйте схемы. Набросайте от руки блок-схему процесса, который пытаетесь понять. Это сразу выявит логические разрывы.
🦊Ведите личные заметки. Используйте любой удобный формат: Markdown-файл, Miro-доска, OneNote. Пишите так, как понятно вам