Школа
системного анализа
и проектирования

Профессия «Системный аналитик информационных систем для бизнеса»

Автор: Денис Бесков + OpenAI o1
Вёрстка и графика: Алина Богачёва
Это универсальное пособие для всех, кто связан с системным анализом: оно охватывает весь путь информационной системы — от идеи и требований до внедрения и развития. Новичкам книга подскажет, как войти в профессию; джуны поймут свою роль в проекте; мидлы смогут восполнить пробелы и увереннее вести переговоры; сеньоры сравнят свои подходы с альтернативными мнениями, а руководители отделов анализа получат обзор ключевых навыков, инструментов и актуальных трендов. По сути, это настольная книга, к которой стоит обращаться по мере возникновения новых задач и вопросов.
Автор: денис бесков

Профессия «Системный аналитик информационных систем для бизнеса»

Раздел I. Роль системного аналитика в разработке информационных систем для бизнеса

Раздел I отвечает на главный вопрос: кто такой системный аналитик и почему без него IT-проекты часто буксуют. При этом не нужно погружаться во все главы подряд, достаточно открыть ту, которая решает вашу насущную задачу.

Скажем, в главе 1 вы узнаёте, почему аналитик — это не специалист по классическому «системному анализу и теории систем» из вузовского учебника, а специалист на стыке бизнеса и IT.

Глава 2 помогает разобраться с «предметами разработки», будь то внутренняя информационная система, программный продукт или интернет-сервис: это особенно полезно, когда приходится переключаться между корпоративным внедрением и созданием тиражного ПО.

Глава 3 про «контексты разработки» объяснит, что нужно учитывать при автоматизации бизнеса, работе в стартапе или системной интеграции.

Если не понимаете, как аналитик взаимодействует с архитектором, тестировщиком, менеджером проекта или специалистом по внедрению, загляните в главу 4 — там всё разложено по ролям.

В главе 5 показано место профессии на рынке: как в мире, так и в России, а вы сможете оценить свои перспективы. Захотелось разобраться, с чем вы вообще работаете ежедневно (коллективы, люди, процессы, документы)? Откройте главу 6.

Глава 7 рассказывает о методах работы с людьми: проведение интервью, встреч, презентаций — вы вдруг поймёте, почему так важно задавать «правильные» вопросы.

И наконец, если хотите наладить проектную работу и понять, как грамотно ставить задачи, вести их сдачу и сбор обратной связи, то в главе 8 «раскрыт» весь механизм, чтобы не застревать на согласованиях и бюрократии.

Возможные инсайты с Вашей стороны: «Похоже, всё же придётся отвечать на вопросы тестировщика» и «Подождите, если мои задачи по операционным процессам — это не проект, значит, я не получу проектную премию?».

Раздел II. Анализ информационных систем для бизнеса

Раздел II рассказывает, как именно системный аналитик «залезает под капот» будущей системы и превращает бизнес-идеи в чёткие требования и концептуальные схемы. При этом не нужно читать подряд все главы — достаточно открыть ту, которая к вам ближе по текущим задачам.

Скажем, в главе 9 вы узнаете, как «прочувствовать» бизнес: провести бизнес-анализ, смоделировать процессы и правильно оформить бизнес-требования.

В главе 10 речь пойдёт о надсистемном анализе: где заканчиваются границы системы и чем она взаимодействует «снаружи» (особенно полезно, когда вы запутались в окружении).

Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.

В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.

Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX.

Надо разобраться с концептуальным дизайном? Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.

И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных и нефункциональных требований, выявлением технических ограничений и критериев качества.

Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».

Раздел III. Проектирование информационных систем для бизнеса

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


Допустим, глава 16 описывает «техническое проектирование»: как внутри системы распределить логику, какие базы данных выбрать, зачем нужна контейнеризация. Если вы туманно представляете, чем занимаются архитекторы и почему обсуждают микросервисы или ER-диаграммы, то здесь вас ждёт прозрение: «Ах, вот оно что, так строится внутреннее моделирование!»


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


Глава 18 открывает тему интеграции: очереди сообщений, API, брокеры — если вы застряли в вопросах «какими форматами мы обмениваемся с внешними системами?» или «как мы синхронизируем редактуру данных?», вам обязательно туда.


И, наконец, глава 19 покажет, как оформлять задачи на разработку так, чтобы не остаться в недоумении: «Почему у нас всё время разные люди по-разному поняли одни и те же требования?»


Возможные инсайты: «Подождите, значит REST-подход и очереди — это не взаимоисключающие методы?» и «Вместо того, чтобы в четвёртый раз переписывать техническое задание для разработчиков, я могу наконец-то составить критерии приёмки».

Раздел IV. Сопровождение аналитиком дальнейших этапов создания информационных систем

Раздел IV показывает, что после написания «основных» требований и проектирования работа аналитика не заканчивается: ему ещё предстоит участвовать в тестировании, документировании и сопровождать проект в боевом режиме.

И вновь не обязательно читать подряд: если вам больно смотреть на нескончаемые баги и надо понять, чем QA-жизнь отличается от обычной, загляните в главу 20 — «тестирование и качество».

Если вы вдруг запутались в том, как оформить и актуализировать документацию, добро пожаловать в главу 21.

Глава 22 расскажет, как системный аналитик может «подружиться» с AI, чтобы собирать требования и анализировать большие массивы данных.

И, наконец, в 23-й главе вы поймёте, почему внедрение и поддержка системы — это не просто «запустить и забыть», а постоянное взаимодействие с DevOps, службой поддержки, бизнесом.

Возможные инсайты: «Ого, оказывается, тестирование — это не в конце, а часть цикла!» и «Так вот, как правильно поддерживать документацию, чтобы её читал не только я».

Раздел V. Профессиональное развитие системного аналитика

Раздел V рассказывает о том, как расти в профессии системного аналитика, оставаясь при этом в адекватном психологическом состоянии и не теряя интерес к делу.

Если вы только начинаете карьеру и хотите понять, с чего стартовать, обратитесь к главе 24: там — «Как стать системным аналитиком», об опыте в IT, стажировках и работе с ментором.

А в 25-й главе речь про психогигиену: как не «сгореть», балансируя общение с заказчиками, командой и постоянными изменениями.

В 26-й главе вы найдёте инструменты самооценки и планирования развития — чтобы трезво понять, каких навыков не хватает и куда можно двигаться (в бизнес-анализ, архитектуру, продакт-менеджмент).

И наконец, глава 27 отвечает на вопрос «Куда идёт сама профессия?» — тенденции, AI, гибридные роли.

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

Глоссарий

1. Основные роли

Аналитик данных
  • Определение: Специалист, который занимается сбором, очисткой и интерпретацией данных (часто больших объёмов), выявляет закономерности и готовит отчёты или модели. Может тесно сотрудничать с системным аналитиком при формировании структуры данных и интеграции с аналитическими модулями.
  • Официальные термины: «Аналитик данных», «Data Analyst»
  • Разговорные: «дата-аналитик»
Архитектор ПО
  • Определение: Отвечает за проектирование программной части системы (структуру модулей, классов, взаимодействие компонентов), выбирает технологии и паттерны, определяет, как код будет организован на уровне приложения.
  • Официальные термины: «Архитектор программного обеспечения», «Software Architect»
  • Разговорные: «архитектор», «арх по коду»
Архитектор решений
  • Определение: Специалист, который смотрит шире, чем просто код, и проектирует решение на уровне всей системы и окружения (интеграции, сети, серверы, безопасность). Зачастую учитывает бизнес-контекст и организационную структуру при формировании IT-ландшафта.
  • Официальные термины: «Архитектор решений», «Solution Architect»
  • Разговорные: «солюшн-архитектор»
Бизнес-аналитик
  • Определение: Специалист, отвечающий за изучение бизнес-процессов, выявление проблем и возможностей на уровне организации, формирование бизнес-целей. Тесно взаимодействует с системным аналитиком, который переводит высокоуровневые идеи в детальное проектирование.
  • Официальные термины: «Business Analyst», «Аналитик бизнес-процессов»
  • Разговорные: «бэ-а», «биэй»
Бизнес-архитектор
  • Определение: Занимается глобальным устройством бизнеса на уровне организационной структуры, стратегических процессов, общих целей компании. Определяет, какие информационные решения нужны организации и как они вписываются в бизнес-стратегию.
  • Официальные термины: «Business Architect», «Организационный архитектор»
  • Разговорные: «бизнес-арх», «архитектор по компании»
Владелец продукта
  • Определение: В гибких методологиях (Scrum) и продуктовых командах отвечает за видение продукта, приоритеты функционала и ценность продукта для пользователей и бизнеса.
  • Официальные термины: «Product Owner», «Ответственный за продукт»
  • Разговорные: «владелец прод», «пиоу»
DevOps-инженер
  • Определение: Специалист, отвечающий за непрерывную интеграцию и доставку (CI/CD), автоматизацию окружений, оркестрацию контейнеров, мониторинг и поддержание инфраструктуры. Тесно сотрудничает с аналитиком, когда возникают вопросы о средах развёртывания и особенностях эксплуатации.
  • Официальные термины: «DevOps Engineer», «Инженер по DevOps-практикам»
  • Разговорные: «девопс», «девопсник»
Заказчик
  • Определение: Лицо (или организация), которое инициирует и финансирует проект, определяет бизнес-цели и конечные результаты. Может быть внутренним (в рамках одной компании) или внешним (сторонний клиент).
  • Официальные термины: «Customer», «Client», «Инициатор проекта»
  • Разговорные: «клиент», «оплачивающая сторона», «бизнес-заказчик»
Заинтересованное лицо
  • Определение: Любой человек или подразделение, чьи интересы затрагиваются при создании или изменении системы (сотрудники, партнёры, инвесторы, госорганы). Активно участвует или влияет на проект.
  • Официальные термины: «Stakeholder», «Заинтересованная сторона»
  • Разговорные: «стейкхолдер», «участник проекта»
Инженер по эксплуатации
  • Определение: Занимается поддержанием системы в рабочем состоянии после ввода в эксплуатацию (администрирование, мониторинг, обновление). Может называться инженером сопровождения (Operations Engineer).
  • Официальные термины: «Operations Engineer», «Инженер по эксплуатации»
  • Разговорные: «опс-инженер», «эксплуататор»
Менеджер продукта
  • Определение: Отвечает за стратегическое развитие продукта: анализ рынка, формирование дорожной карты, исследование потребностей клиентов. Может совмещать функции маркетинга, финансов и планирования релизов.
  • Официальные термины: «Product Manager», «Менеджер по продукту»
  • Разговорные: «продакт-менеджер», «продакт»
Менеджер проекта
  • Определение: Организует работу команды, планирует сроки, ресурсы, бюджет, управляет рисками и коммуникациями, обеспечивает достижение целей проекта.
  • Официальные термины: «Project Manager», «Руководитель проекта»
  • Разговорные: «пиэм», «менеджер проекта»
Проектировщик и дизайнер интерфейсов
  • Определение: Специалист, отвечающий за UX (пользовательский опыт) и визуальное оформление (UI). Создаёт макеты, прототипы, обеспечивает удобство и консистентность решений в интерфейсе.
  • Официальные термины: «UX/UI Designer», «Информационный архитектор»
  • Разговорные: «дизайнер UI», «UXер», «макетчик»
Разработчик
  • Определение: Пишет код, создаёт программную логику и пользовательские интерфейсы. Взаимодействует с аналитиком для уточнения функционала, сценариев использования, интеграций.
  • Официальные термины: «Developer», «Программист»
  • Разговорные: «дев», «кодер»
Системный аналитик
  • Определение: Специалист, переводящий бизнес-потребности в форму технических решений, анализирующий процессы, формализующий данные и контролирующий соответствие системы целям.
  • Стажёр (Intern): Получает первый опыт, помогает старшим аналитикам.
  • Джун (Junior): Имеет базовые навыки, ведёт небольшие части проектов при поддержке.
  • Мидл (Middle): Работает самостоятельно над задачами средней сложности, советуется с сеньорами.
  • Сеньор (Senior): Ведёт целый проект, решает конфликты, понимает бизнес-процессы в глубину.
  • Ведущий (Lead): Координирует аналитиков, определяет подходы и методики.
  • Руководитель отдела: Управляет аналитической функцией, участвует в стратегических решениях.
  • Официальные термины: «Systems Analyst», «Инженер по системному анализу»
  • Разговорные: «эс-а», «аналитик по системам»
Специалист по внедрению
  • Определение: Устанавливает готовое решение на стороне заказчика, настраивает, интегрирует с другими системами, обучает пользователей. Часто взаимодействует с аналитиком при корректировке логики и настроек.
  • Официальные термины: «Implementation Specialist», «Инженер внедрения»
  • Разговорные: «внедренец»
Специалист технической поддержки
  • Определение: Принимает и обрабатывает обращения пользователей, решает проблемы с работой системы (неудачные обновления, ошибки). При сложных ситуациях эскалирует к аналитикам, разработчикам или инженерам по эксплуатации.
  • Официальные термины: «Support Specialist», «Сотрудник службы поддержки»
  • Разговорные: «саппорт», «техпод»
Тестировщик
  • Определение: Проверяет, правильно ли реализован функционал, нет ли дефектов, насколько система удовлетворяет ожиданиям. Сотрудничает с аналитиком для уточнения критериев приёмки и сценариев тестирования.
  • Официальные термины: «QA Engineer», «Тестировщик программного обеспечения»
  • Разговорные: «тестер», «куа»
Технический писатель
  • Определение: Готовит документацию (руководства, справку), понятную конечным пользователям и поддерживающей аудитории. Часто консультируется с аналитиком, чтобы корректно отразить бизнес-логику и специфику системы.
  • Официальные термины: «Technical Writer», «Технический писатель»
  • Разговорные: «техрайтер», «техпис»

2. Методологии и процессы

Аджайл (Agile)
  • Определение: Гибкий подход к управлению проектами, при котором ценятся взаимодействие людей, быстрая реакция на изменения и самоорганизация команд вместо жёсткого следования плану.
  • Официальные термины: «Agile methodology», «Гибкая методология разработки»
  • Разговорные: «аджайл», «гибкая разработка»
Артефакт
  • Определение: Любой ощутимый результат процесса разработки: документы, диаграммы, прототипы, готовые модули кода, тестовые сценарии и др.
  • Официальные термины: «Artifact», «Проектный артефакт»
  • Разговорные: «артефакт», «результат работы»
Бёрндаун-чарт
  • Определение: График, показывающий, как уменьшается объём оставшейся работы (задач) во времени. Применяется в Scrum и других Agile-подходах.
  • Официальные термины: «Burndown Chart», «График снижения задач»
  • Разговорные: «бёрндаун», «сгорание задач»
Бэклог
  • Определение: Упорядоченный список всех задач и улучшений, необходимых в проекте или продукте. Может постоянно пересматриваться и приоритизироваться.
  • Официальные термины: «Backlog», «Список приоритетных работ»
  • Разговорные: «бэклог», «стопка задач»
Ватерфолл
  • Определение: Каскадная модель разработки, при которой фазы (анализ, дизайн, кодирование, тестирование) идут последовательно с чёткой фиксацией результатов каждого этапа.
  • Официальные термины: «Waterfall model», «Каскадная модель»
  • Разговорные: «Waterfall», «водопад»
Ветвление (Branching)
  • Определение: Создание параллельных веток разработки в системе контроля версий (например, Git), позволяющее разработчикам вести независимые изменения, не мешая друг другу.
  • Официальные термины: «Branching», «Разделение веток в системе версий»
  • Разговорные: «ветвление», «брэнчинг»
Демо (Demo)
  • Определение: Короткая демонстрация достигнутых результатов разработки для команды и заинтересованных лиц; обычно проводится в конце итерации (Sprint Review в Scrum).
  • Официальные термины: «Demonstration», «Обзор готовой функциональности»
  • Разговорные: «демка», «показ»
Деплой (Deployment)
  • Определение: Развёртывание приложения (копирование файлов, настройка окружения, запуск) на сервере или в облаке, чтобы система стала доступна конечным пользователям или тестировщикам.
  • Официальные термины: «Deployment», «Развёртывание системы»
  • Разговорные: «деплой», «задеплоить», «выкатить»
Дорожная карта (Roadmap)
  • Определение: Высокоуровневый план развития проекта или продукта, отражающий крупные этапы, функции, сроки и приоритеты на несколько итераций или релизов вперёд.
  • Официальные термины: «Roadmap», «План развития»
  • Разговорные: «роадмап», «длинный план»
Инкрементная разработка
  • Определение: Подход, при котором функциональность наращивается постепенно — небольшими «инкрементами», каждый из которых самостоятельно работоспособен и может быть продемонстрирован.
  • Официальные термины: «Incremental development», «Постепенное приращение функционала»
  • Разговорные: «инкременты», «приростное создание»
Итеративная разработка
  • Определение: Подход, где циклы «планирование — реализация — проверка» повторяются многократно. Каждая итерация даёт улучшенный результат с учётом обратной связи.
  • Официальные термины: «Iterative development», «Итерационный подход»
  • Разговорные: «итеративка», «разработка циклом»
Канбан
  • Определение: Метод управления задачами через визуальную доску с колонками «Сделать», «В работе», «Готово». Позволяет ограничивать незавершённые задачи и улучшать поток работы.
  • Официальные термины: «Kanban method», «Доска Канбан»
  • Разговорные: «канбан-доска», «визуальная доска»
Клонирование (Cloning)
  • Определение: Создание локальной копии репозитория (например, Git), включая все ветки и историю. Позволяет разработчикам независимо работать с кодом на своих машинах.
  • Официальные термины: «Cloning repository», «Клонирование репозитория»
  • Разговорные: «склонировать репу», «клонировать код»
Коммит (Commit)
  • Определение: Фиксация изменений кода (или документации) в репозитории с добавлением описания того, что было сделано. Каждому коммиту присваивается уникальный идентификатор.
  • Официальные термины: «Commit», «Сохранение изменений в системе контроля версий»
  • Разговорные: «коммитнуть», «залить коммит»
Критерии готовности (Definition of Ready)
  • Определение: Список условий, при котором задача считается достаточно описанной и понятной, чтобы команду можно было «брать в работу». Включает ясные цели, оценку объёма и приоритет.
  • Официальные термины: «Definition of Ready», «DoR»
  • Разговорные: «достаточно описано», «задача готова»
Масштабирование
  • Определение: Увеличение ресурсов (серверов, процессоров, оперативной памяти) или оптимизация архитектуры, чтобы система обрабатывала больше запросов. Может быть вертикальным (добавить мощность) или горизонтальным (добавить узлы).
  • Официальные термины: «Scaling (vertical/horizontal)», «Масштабирование системы»
  • Разговорные: «скейл», «нарастить ресурсы»
Метод MoSCoW
  • Определение: Способ приоритизации, где все функции распределяются по категориям Must, Should, Could и Won’t, что позволяет расставить фокус на жизненно важных задачах и отложить менее критичные.
  • Официальные термины: «MoSCoW prioritization»
  • Разговорные: «москоу», «M/ S/ C/ W»
Непрерывная интеграция
  • Определение: Регулярное слияние кода в общий репозиторий с автоматическими сборками и тестами, позволяющее быстро выявлять конфликты и дефекты.
  • Официальные термины: «Continuous Integration (CI)», «Непрерывная интеграция»
  • Разговорные: «сишка», «непрерывка»
Непрерывная поставка
  • Определение: Подход, при котором каждая актуальная сборка проекта проходит автоматические проверки и может быть развернута в любой момент. Позволяет выпускать продукт часто и надёжно.
  • Официальные термины: «Continuous Delivery (CD)», «Непрерывная доставка»
  • Разговорные: «сиди», «постоянный деплой»
Обзор спринта (Sprint Review)
  • Определение: Заключительная встреча итерации (в Scrum), когда команда показывает выполненный функционал заинтересованным лицам, собирает обратную связь и планирует дальнейшие шаги.
  • Официальные термины: «Sprint Review», «Демонстрация результатов спринта»
  • Разговорные: «спринт-ревью», «концовка спринта»
План управления рисками
  • Определение: Совокупность подходов и документов, описывающих возможные риски (вероятность, ущерб) и способы снижения или принятия. Предотвращает неожиданные проблемы в проекте.
  • Официальные термины: «Risk Management Plan», «План рисков проекта»
  • Разговорные: «риск-план», «таблица рисков»
Приоритизация
  • Определение: Распределение задач по степени важности и срочности. Может использовать разные техники (MoSCoW, относительное сравнение), чтобы выбрать, что делать в первую очередь.
  • Официальные термины: «Prioritization», «Ранжирование задач»
  • Разговорные: «распределение приоритета», «сортировка важности»
Пулл (Pull)
  • Определение: Операция в системе контроля версий (Git), при которой локальный репозиторий обновляется изменениями с удалённого. Позволяет синхронизировать работу нескольких разработчиков.
  • Официальные термины: «Pull», «Загрузка изменений в локальную копию»
  • Разговорные: «запуллить», «притянуть код»
Пуш (Push)
  • Определение: Операция в системе контроля версий (Git), при которой локальные изменения отправляются в удалённый репозиторий, становясь доступными для других участников.
  • Официальные термины: «Push», «Выгрузка изменений на сервер»
  • Разговорные: «запушить», «выложить код»
Рефайнмент (Refinement)
  • Определение: Регулярная встреча или процесс, где задачи и требования из бэклога детализируются, уточняются и оцениваются, чтобы команда могла без проблем брать их в спринт.
  • Официальные термины: «Backlog Refinement», «Уточнение бэклога»
  • Разговорные: «рефайн», «допиливание задач»
Скрам
  • Определение: Agile-фреймворк с короткими спринтами (до 4 недель), определёнными ролями (Scrum Master, Владелец продукта) и регулярными встречами (стендапы, демо, ретроспективы).
  • Официальные термины: «Scrum Framework», «Методология Scrum»
  • Разговорные: «скрам», «scrum-процесс»
Спринт
  • Определение: Короткий временной отрезок (1–4 недели) в Scrum, за который команда выпускает работающий инкремент продукта. Завершается обзором спринта и ретроспективой.
  • Официальные термины: «Sprint», «Итерация»
  • Разговорные: «спринт», «короткий цикл»
Стэндап
  • Определение: Короткая ежедневная встреча команды, где участники говорят, что сделали вчера, что планируют сегодня и какие есть блокеры. Помогает синхронизировать работу.
  • Официальные термины: «Daily Stand-up», «Daily Scrum»
  • Разговорные: «дэйли», «стендап-митинг»
Управление изменениями
  • Определение: Процесс учёта и согласования корректировок в проекте (новые требования, сдвиг приоритетов), а также анализа их влияния на сроки, ресурсы и бюджет.
  • Официальные термины: «Change Management», «Процесс согласования изменений»
  • Разговорные: «хендлить ченджи», «перестраивать проект»
Управление конфигурацией
  • Определение: Поддержание согласованности и целостности версий кода, документации, окружений. Позволяет вести учёт изменений и воспроизводить разные сборки.
  • Официальные термины: «Configuration Management», «CM»
  • Разговорные: «конфиг-менеджмент», «управлять версиями»

3. Моделирование и документирование

Алгоритм (Algorithm)
  • Определение: Строгая последовательность действий, приводящих к решению задачи или вычислению результата. Может описываться через псевдокод, блок-схемы, UML-диаграммы или нотацию Drakon.
  • Официальные термины: «Алгоритм», «Algorithm»
  • Разговорные: (нет)
Альтернативные потоки (Alternate Flows)
  • Определение: Дополнительные ветви сценария (например, варианта использования), которые обрабатывают нетипичные ситуации, ошибки или выбор пользователя, отличные от «основного пути» (happy path).
  • Официальные термины: «Alternate Flows», «Альтернативные ветви сценариев»
  • Разговорные: «ветки», «ответвления», «не happy path»
Анализ требований (Requirements Analysis)
  • Определение: Процесс исследования и уточнения собранных требований, определения приоритетов, выявления противоречий и предпосылок для формализации. Может включать интервью, воркшопы и проверки согласованности.
  • Официальные термины: «Requirements Analysis»
  • Разговорные: (нет)
Бизнес-правила (Business Rules)
  • Определение: Логика и ограничения, определяющие поведение компании и её процессов. Могут быть формализованы в документах и требованиях, чтобы система соответствовала реальной практике бизнеса.
  • Официальные термины: «Business Rules», «Правила бизнеса», «Регламенты»
  • Разговорные: (нет)
Бизнес-требования (Business Requirements)
  • Определение: Высокоуровневые требования, отражающие цели и задачи организации (увеличение продаж, оптимизация процессов, соблюдение нормативов). Формируют общую мотивацию для создания системы.
  • Официальные термины: «Business Requirements», «BRD (Business Requirements Document)»
  • Разговорные: «бизнес-хотелки»
Блок-схема (Block Diagram)
  • Определение: Упрощённый графический способ описания алгоритма или процесса, где каждый блок соответствует действию, решению или началу/концу, а стрелки показывают поток управления.
  • Официальные термины: «Block Diagram»
  • Разговорные: (нет)
Варианты использования (Use Cases)
  • Определение: Текстовые описания или схемы, показывающие, как пользователь и система взаимодействуют для достижения определённой цели. Могут включать основной (happy path) и альтернативные потоки.
  • Официальные термины: «Use Cases», «Сценарии использования»
  • Разговорные: «юскейсы», «варианты юзов»
Видение и границы (Vision and Scope)
  • Определение: Раздел или документ, описывающий, зачем нужна система, какие задачи решает и каковы рамки проекта (что включено, что исключено). Помогает согласовать ожидания стейкхолдеров.
  • Официальные термины: «Vision and Scope», «Раздел “Видение и границы”»
  • Разговорные:
Глоссарий (Glossary)
  • Определение: Систематизированный список терминов и определений, используемых в проекте. Помогает избежать неоднозначности и прояснить специфику отраслевых сокращений.
  • Официальные термины: «Glossary», «Словарь терминов»
  • Разговорные: «локальный словарик»
DDD (Доменно-ориентированное проектирование) (Domain-Driven Design)
  • Определение: Подход, при котором модель предметной области находится в центре архитектуры. Термины и логика берутся непосредственно из домена, чтобы сохранить согласованность и понятность кода.
  • Официальные термины: «Domain-Driven Design (DDD)»
  • Разговорные: (нет)
Диаграмма бизнес-процессов (BPMN) (Business Process Model and Notation)
  • Определение: Графическая нотация для описания бизнес-процессов (шаги, роли, логика), расшифровывается как Business Process Model and Notation. Позволяет моделировать и оптимизировать потоки работ.
  • Официальные термины: «BPMN diagram», «Нотация BPMN»
  • Разговорные: «бпмн-диаграмма», «бизнес-процессы в кружочках»
Диаграмма вариантов использования (Use Case Diagram)
  • Определение: UML-диаграмма, где показываются акторы (пользователи, внешние системы) и связываемые с ними варианты использования. Отражает границы системы и основные сценарии.
  • Официальные термины: «Use Case Diagram»
  • Разговорные: «диаграмма юскейсов», «варианты применения»
Диаграмма деятельности (Activity Diagram)
  • Определение: UML-диаграмма, показывающая логику процесса или операции в виде блоков и переходов (действия, ветвления, слияния). Демонстрирует последовательность шагов.
  • Официальные термины: «Activity Diagram», «Диаграмма активностей»
  • Разговорные: «диаграмма действий», «активити»
Диаграмма Дракон (Drakon Chart)
  • Определение: Графическая нотация для описания алгоритмов и процессов, упрощающая понимание за счёт строгих правил расположения блоков. Разработана для космической отрасли, но применяется и в общих задачах.
  • Официальные термины: «Drakon Chart»
  • Разговорные: (нет)
Диаграмма контекста (Context Diagram)
  • Определение: Графическое представление системы в формате «чёрного ящика», где показаны входы, выходы и внешние взаимодействия с акторами и другими системами.
  • Официальные термины: «Context Diagram», «Контекстная диаграмма»
  • Разговорные: «чёрный ящик»
Диаграмма последовательностей (Sequence Diagram)
  • Определение: UML-схема, описывающая хронологический порядок обмена сообщениями и вызовами между участниками (объектами, сервисами) в конкретном сценарии.
  • Официальные термины: «Sequence Diagram»
  • Разговорные: «последовательная диаграмма», «seq-диаграмма»
Диаграмма состояний (State Diagram)
  • Определение: UML-диаграмма, отражающая возможные состояния объекта и переходы между ними при определённых событиях. Удобна при сложном поведении с чёткими этапами.
  • Официальные термины: «State Diagram», «State Machine Diagram»
  • Разговорные: «стейт-чарт», «стейт-диаграмма»
Жизненный цикл требований (Requirements Life Cycle)
  • Определение: Последовательность стадий, которые проходят требования: от появления и анализа до согласования, реализации, поддержки и возможной утилизации.
  • Официальные термины: «Requirements Life Cycle»
  • Разговорные: (нет)
Запрос на изменение (Change Request)
  • Определение: Формальное уведомление о необходимости откорректировать проект (добавить, уточнить, убрать функциональность), влияющее на сроки и приоритеты.
  • Официальные термины: «Change Request (CR)»
  • Разговорные: «чейндж-реквест»
Интервьюирование (Interviewing)
  • Определение: Метод сбора сведений, при котором аналитик беседует с потенциальным пользователем, заказчиком или экспертом, задавая целенаправленные вопросы о процессах и проблемах.
  • Официальные термины: «Interviewing», «Метод интервью»
  • Разговорные: «взять интервью», «побеседовать»
Job Story (Джоб стори)
  • Определение: Формат описания потребности, фокусирующийся на задаче, которую пользователь пытается решить: «Когда я [контекст], я хочу [действие], чтобы [результат]».
  • Официальные термины: «Job Story»
  • Разговорные: (нет)
Карта пользовательского пути (CJM) (Customer Journey Map)
  • Определение: Графическое или табличное описание всех шагов и этапов, которые проходит пользователь, взаимодействуя с системой, включая эмоции, боли и ожидания.
  • Официальные термины: «Customer Journey Map (CJM)», «Пользовательский путь»
  • Разговорные: «си-джей-эм», «карта пути юзера»
Макет (Mockup)
  • Определение: Наглядный черновой эскиз интерфейса, показывающий расположение основных элементов. Используется для раннего обсуждения дизайна и функционала, без глубокой проработки стилей.
  • Официальные термины: «Mockup», «Макет пользовательского интерфейса»
  • Разговорные: «мокап», «черновой макет»
Метод Specification by Example (SbE)
  • Определение: Подход к формулированию требований и тестов на основе конкретных примеров, устраняя двусмысленность за счёт детальных кейсов.
  • Официальные термины: «Specification by Example (SbE)»
  • Разговорные: «спек от примеров»
Нефункциональные требования (Non-functional Requirements – NFR)
  • Определение: Характеристики системы, не описывающие конкретный функционал (производительность, безопасность, масштабируемость), но влияющие на её качество и архитектуру.
  • Официальные термины: «Non-functional Requirements (NFR)», «Атрибуты качества»
  • Разговорные: «НФТ»
Ограничения (Constraints)
  • Определение: Заданные условия, рамки или внешние факторы (бюджет, сроки, совместимость), которые нельзя нарушить при проектировании и разработке.
  • Официальные термины: «Constraints», «Ограничения проекта»
  • Разговорные: «констрейны», «жёсткие рамки»
Пользовательская история (User Story)
  • Определение: Короткое описание потребности пользователя в формате «Как [роль], я хочу [действие], чтобы [результат]». Часто используется в гибких методологиях (Scrum, Kanban).
  • Официальные термины: «User Story», «Пользовательский сценарий»
  • Разговорные: «юзер-стори», «история»
Приёмочные критерии (Acceptance Criteria)
  • Определение: Чёткие условия, подтверждающие, что требование или пользовательская история реализованы правильно (какие сценарии должны пройти, какие ограничения соблюдены).
  • Официальные термины: «Acceptance Criteria», «Критерии приёмки»
  • Разговорные: (нет)
Прототип (Prototype)
  • Определение: Неполная, демонстрационная версия интерфейса или процесса, позволяющая оценить идеи и собрать обратную связь до полной реализации. Может быть интерактивным или статичным.
  • Официальные термины: «Prototype»
  • Разговорные: «проба UI», «щупаемая версия»
Реестр требований (Requirements Register)
  • Определение: Систематизированный список требований (название, описание, приоритет, статус), позволяющий управлять объёмом проекта и отслеживать изменения.
  • Официальные термины: «Requirements Register», «Requirements List»
  • Разговорные: (нет)
Ревизия требований (Requirements Review)
  • Определение: Процесс проверки и анализа набора требований, чтобы выявить несогласованность, пропуски или двусмысленность. Часто проводится командой или сторонними экспертами.
  • Официальные термины: «Requirements Review», «Audit of Requirements»
  • Разговорные: «проверка требований», «ревью»
Счастливый путь (Happy Path)
  • Определение: Основной успешный сценарий прохождения процесса, при котором не возникает ошибок, исключительных ситуаций и все шаги выполняются «как задумано».
  • Официальные термины: «Happy Path», «Основной путь»
  • Разговорные: (нет)
Сценарий (Scenario)
  • Определение: Описание последовательности действий или шагов, которые пользователь и/или система выполняют в определённом контексте. Может включать основной и альтернативные потоки.
  • Официальные термины: «Scenario»
  • Разговорные: (нет)
Спецификация требований (SRS – Software Requirements Specification)
  • Определение: Формализованный документ, описывающий функциональные и нефункциональные аспекты, используемый для согласования между стейкхолдерами и командой разработки.
  • Официальные термины: «Software Requirements Specification (SRS)»
  • Разговорные: «спека», «требования в доке»
Техническое задание (ТЗ) (Technical Specification)
  • Определение: Документ, формализующий цели, функционал, ограничения и сроки разработки. Может служить основой контракта или внутренним стандартом при выполнении задачи.
  • Официальные термины: «Technical Specification», «Technical Task»
  • Разговорные: «ТЗ», «техзад»
Технический долг (Technical Debt)
  • Определение: Накопленные упрощения или временные обходные решения, которые со временем усложняют поддержку и развитие системы, требуя рефакторинга или переработки.
  • Официальные термины: «Technical Debt»
  • Разговорные: (нет)
Трассировка требований (Requirements Traceability)
  • Определение: Установление связей между требованиями и другими элементами (тест-кейсами, задачами разработки), чтобы при изменении одного компонента было понятно, что ещё затронуто.
  • Официальные термины: «Requirements Traceability», «Traceability Matrix»
  • Разговорные: (нет)
Уточнение требований (Requirements Clarification)
  • Определение: Деятельность, направленная на снятие двусмысленностей, дополнение деталей и согласование формулировок для повышения точности и полноты. Может включать интервью, воркшопы, изучение регламентов.
  • Официальные термины: «Requirements Clarification», «Refinement»
  • Разговорные: (нет)
Функциональные требования (Functional Requirements)
  • Определение: Описывают, что именно должна делать система (функции, процессы, реакции на действия пользователя), формирующие основу предметной логики.
  • Официальные термины: «Functional Requirements», «FR»
  • Разговорные: «ФТ»

4. Технические аспекты и интеграции

API (Интерфейс прикладного программирования)
  • Определение: Набор методов и правил (эндпоинтов), по которым одно приложение может взаимодействовать с другим (запрашивать или изменять данные, вызывать функции).
  • Официальные термины: «Application Programming Interface», «Интерфейс прикладного программирования»
  • Разговорные: «апи», «программный интерфейс»
API-шлюз
  • Определение: Промежуточный слой, который управляет входящими запросами к различным сервисам: маршрутизирует, проверяет аутентификацию, применяет лимиты, ведёт логи.
  • Официальные термины: «API Gateway», «Шлюз для программных интерфейсов»
  • Разговорные: «шлюз апи», «входная точка»
База данных
  • Определение: Организованное хранилище данных, где информация может быть эффективно извлечена и изменена. Бывает реляционной (SQL) или нереляционной (NoSQL).
  • Официальные термины: «Database (DB)», «Система управления базами данных (СУБД)»
  • Разговорные: «база», «ДБ»
Брокер сообщений
  • Определение: Программный компонент (RabbitMQ, Kafka, ActiveMQ), принимающий сообщения от одних приложений и передающий их другим по заданным правилам. Поддерживает асинхронную связь и очереди.
  • Официальные термины: «Message Broker», «Система обмена сообщениями»
  • Разговорные: «месседж-брокер»
Веб-сервис
  • Определение: Программа или компонент, доступный по сети через стандартные протоколы (HTTP, SOAP, REST), предоставляющий функционал и данные другим приложениям.
  • Официальные термины: «Web Service», «Веб-служба», «внешний сервис»
  • Разговорные:
Версионирование
  • Определение: Подход к контролю изменения программного кода, документации или конфигураций, где сохраняется история версий и возможен возврат к нужному состоянию.
  • Официальные термины: «Version Control», «Версионирование»
  • Разговорные: «гит-подход», «управление версиями»
Виртуализация
  • Определение: Техника создания абстракции над физическими ресурсами (сервер, сеть, хранилище), позволяющая запускать несколько виртуальных машин или окружений на одной аппаратной платформе.
  • Официальные термины: «Virtualization», «Виртуальное окружение»
  • Разговорные: «вирта», «виртуалки»
Горизонтальное масштабирование
  • Определение: Увеличение пропускной способности системы за счёт добавления дополнительных экземпляров серверов или узлов, а не путём наращивания мощностей одного узла.
  • Официальные термины: «Horizontal Scaling», «Масштабирование вширь»
  • Разговорные: «горизонталка», «добавлять узлы»
Доменное имя (DNS)
  • Определение: Текстовое имя (например, example.com), с помощью которого пользователи и системы обращаются к ресурсам в интернете. DNS (Domain Name System) переводит доменное имя в IP-адрес.
  • Официальные термины: «Domain Name», «DNS»
  • Разговорные: «домен», «днс»
Загрузка баланса (Load Balancing)
  • Определение: Распределение входящих запросов или трафика между несколькими серверами, чтобы избежать перегрузки и повысить доступность и производительность.
  • Официальные термины: «Load Balancing», «Балансировка нагрузки»
  • Разговорные: «лоад-баланс», «распределение нагрузки»
Инфраструктура как код
  • Определение: Подход, при котором конфигурации серверов, сетей и сервисов описываются текстовыми файлами (кодом), а затем автоматически разворачиваются и управляются (Ansible, Terraform).
  • Официальные термины: «Infrastructure as Code (IaC)», «Инфраструктура в виде кода», «автоматизация инфраструктуры»
  • Разговорные:
Клиент-сервер
  • Определение: Модель взаимодействия, где «клиент» (приложение, браузер) отправляет запросы «серверу» (хранящему данные и логику) и получает ответы. Фундаментальная концепция в сетевых приложениях.
  • Официальные термины: «Client-Server Architecture», «клиент-сервер», «клиентско-серверная модель»
  • Разговорные:
Контейнеризация
  • Определение: Упаковка приложения со всеми зависимостями в единый контейнер (Docker и др.), который может запускаться где угодно, упрощая развёртывание и масштабирование.
  • Официальные термины: «Containerization», «Dockerization»
  • Разговорные: «докер», «контейнерная сборка»
Кэширование
  • Определение: Хранение часто запрашиваемых данных в быстром доступе (оперативной памяти или специальном хранилище), чтобы уменьшить время отклика и нагрузку на основные ресурсы.
  • Официальные термины: «Caching», «Кэширование»
  • Разговорные: «кэш»
Миграция данных
  • Определение: Перенос данных из одного места (старой базы, форматов) в новое (новая БД, другой формат) при внедрении или обновлении систем. Включает преобразование структуры, очистку и проверку.
  • Официальные термины: «Data Migration», «Перенос данных»
  • Разговорные: «перекинуть базу», «мигрировать данные»
Микросервисы
  • Определение: Архитектурный стиль, при котором приложения состоят из набора небольших автономных сервисов, каждый отвечает за свою часть логики, и взаимодействуют через API или события.
  • Официальные термины: «Microservices Architecture», «Микросервисная архитектура»
  • Разговорные:
Мониторинг
  • Определение: Наблюдение за состоянием системы (нагрузка, время отклика, логи, метрики), чтобы своевременно обнаруживать проблемы и реагировать на сбои или деградацию производительности.
  • Официальные термины: «Monitoring», «Система мониторинга»
  • Разговорные:
Монолит
  • Определение: Архитектура, где всё приложение разрабатывается и разворачивается в виде одного блока (модуля, исполняемого файла). Может быть проще в начале, но сложнее в масштабировании и обновлениях.
  • Официальные термины: «Monolithic Architecture»
  • Разговорные:
Облачная платформа
  • Определение: Инфраструктура и сервисы (AWS, Azure, Google Cloud), предоставляющие вычислительные ресурсы, базы данных, хранилища и другие модули через интернет на гибкой основе «по требованию».
  • Официальные термины: «Cloud Platform», «Облачные сервисы»
  • Разговорные: «облако», «клауд»
Оркестрация
  • Определение: Управление жизненным циклом контейнеров и сервисов (развёртывание, масштабирование, обновления) с помощью инструментов вроде Kubernetes, обеспечивая автоматизацию и консистентность.
  • Официальные термины: «Orchestration», «Оркестрация контейнеров»
  • Разговорные: «оркестра», «кубер»
Пайплайн CI/CD
  • Определение: Автоматизированная цепочка процессов (сборка, тесты, проверка качества кода, деплой) при каждом изменении. Позволяет «непрерывно» собирать и поставлять обновлённую версию приложения.
  • Официальные термины: «CI/CD Pipeline», «Конвейер непрерывной интеграции и доставки»
  • Разговорные: «цепочка билд-деплой», «пайплайн»
Прокси-сервер
  • Определение: Посредник в сетевых запросах, перенаправляющий трафик от клиентов к ресурсам. Может использоваться для кэширования, контроля доступа, анонимизации, балансировки.
  • Официальные термины: «Proxy Server», «Прокси-сервер»
  • Разговорные: «прокся», «прокси»
REST
  • Определение: Стиль архитектуры взаимодействия по HTTP, где ресурсы идентифицируются URL, а операции опираются на методы (GET, POST, PUT и т. д.). Рассчитан на простоту и масштабируемость.
  • Официальные термины: «Representational State Transfer», «RESTful API»
  • Разговорные: «рест», «рестовый сервис»
RPC
  • Определение: Механизм удалённого вызова процедур (Remote Procedure Call), при котором клиент вызывает функцию так, как будто она локальная, хотя на самом деле выполняется на другом сервере.
  • Официальные термины: «Remote Procedure Call», «Удалённый вызов процедур»
  • Разговорные: «эрписи», «rpc-вызов»
SOAP
  • Определение: Протокол обмена сообщениями на основе XML, используемый для веб-служб до распространения REST. Обладает формальной схемой, часто применяется в корпоративных интеграциях.
  • Официальные термины: «Simple Object Access Protocol», «SOAP-протокол»
  • Разговорные: «соуп», «мыльный протокол»
SSL/TLS
  • Определение: Криптографические протоколы для защищённой передачи данных по сети (веб-сайты https, защищённые API). Обеспечивают шифрование, целостность и аутентификацию.
  • Официальные термины: «Secure Sockets Layer / Transport Layer Security»
  • Разговорные: «эсэсэл-тилэс», «https-шифрование»
Управление конфигурацией
  • Определение: Поддержание согласованности всех версий кода, инфраструктуры, библиотек и настроек. Позволяет контролировать изменения и воспроизводить рабочие окружения.
  • Официальные термины: «Configuration Management», «CM»
  • Разговорные: «конфиг-менеджмент», «конфиг-управление»
Уровень интеграции
  • Определение: Слой, который обеспечивает соединение систем и сервисов, обработку обмена данными (конвертацию форматов, маршрутизацию), часто реализуется через ESB или набор API.
  • Официальные термины: «Integration Layer», «Слой интеграции»
  • Разговорные: «интеграционный уровень», «слой связки»
Хранилище объектов
  • Определение: Система для хранения неструктурированных объектов (файлов, изображений, видео), обычно доступных по протоколу HTTP (S3 или аналоги). Предоставляет версионность и масштабируемость.
  • Официальные термины: «Object Storage», «Объектное хранилище», «S3-хранилище»
  • Разговорные:
Шина корпоративная (ESB)
  • Определение: Архитектурный подход, при котором все сервисы подключаются к «шине», обеспечивающей маршрутизацию, трансформацию сообщений и управление интеграцией на уровне предприятия.
  • Официальные термины: «Enterprise Service Bus (ESB)», «Корпоративная шина сервисов»
  • Разговорные: «шина», «есб»

5. Управление качеством и релизами

Автоматическое тестирование
  • Определение: Использование специализированных инструментов и скриптов для автоматической проверки работы приложения (сборка, прогон тестов, анализ результатов). Ускоряет процесс выявления дефектов и облегчает регрессию.
  • Официальные термины: «Automated Testing», «Автоматизация тестирования»
  • Разговорные: «автотесты», «запустить авто»
Баг
  • Определение: Ошибка или несоответствие ожидаемому поведению программы, обычно приводящее к сбою или некорректной работе. Может проявляться на разных этапах (от интерфейса до логики).
  • Официальные термины: «Defect», «Ошибка ПО»
  • Разговорные:
Версионность релизов
  • Определение: Подход к выпуску программного обеспечения, где каждый релиз получает уникальный номер (например, 1.0, 1.1.2), отражающий изменения и совместимость.
  • Официальные термины: «Release Versioning», «Нумерация версий»
  • Разговорные:
Готовность к релизу
  • Определение: Совокупность критериев (стабильность, покрытие тестами, отсутствие критических дефектов) и процедур, указывающих, что продукт можно выпустить в эксплуатацию или предоставить заказчику.
  • Официальные термины: «Release Readiness», «Состояние готовности к релизу»
  • Разговорные: «релизная готовность», «go/no-go»
Дым-тест (Smoke test)
  • Определение: Короткая серия тестов, проверяющих базовую работоспособность основных функций приложения, чтобы убедиться, что «приложение не разваливается при запуске».
  • Официальные термины: «Smoke Testing», «Проверка верхнеуровневой работоспособности»
  • Разговорные: «дымовой тест», «быстрая проверка»
Заморозка кода
  • Определение: Этап, на котором вносить изменения в код без крайней необходимости запрещено. Обычно вводится перед релизом, чтобы зафиксировать версию для тестирования и стабилизации.
  • Официальные термины: «Code Freeze», «Заморозка исходного кода»
  • Разговорные: «фриз», «код на стопе»
Инцидент
  • Определение: Любое событие, не входящее в нормальную работу сервиса или системы, приводящее к сбою или снижению качества обслуживания пользователей. Требует быстрой реакции.
  • Официальные термины: «Incident», «Сбой в работе системы»
  • Разговорные: «инцидент»
Критичность дефекта
  • Определение: Оценка того, насколько сильно дефект влияет на работу и бизнес: от «некритичного» (косметическая ошибка) до «блокирующего» (остановка основных функций).
  • Официальные термины: «Severity of Defect», «Уровень критичности»
  • Разговорные: «севери-левел», «критикал»
Метрики качества
  • Определение: Набор показателей, позволяющих оценивать состояние проекта или продукта: процент покрытых тестами, количество открытых дефектов, среднее время на исправление.
  • Официальные термины: «Quality Metrics», «Показатели качества»
  • Разговорные: «метрики QA», «числа качества»
Метрика релиза
  • Определение: Показатель, отражающий статус и готовность конкретного релиза (количество незакрытых задач, критических багов, процент выполненных тестов и т. п.).
  • Официальные термины: «Release Metric», «Показатель релизного цикла»
  • Разговорные: «релизная метрика», «число готовности»
Нагрузочное тестирование
  • Определение: Метод проверки, при котором система испытывается под заранее определённой (или возрастающей) нагрузкой, чтобы оценить производительность и реакцию на пиковые значения.
  • Официальные термины: «Load Testing», «Тестирование под нагрузкой»
  • Разговорные: «лоад-тест», «прогон на нагрузку»
Отчёт о тестировании
  • Определение: Документ (или сводка), фиксирующий результаты тестовых прогонов (какие сценарии проверены, какие дефекты выявлены, процент выполнения, статус принятия). Помогает команде видеть общую картину качества.
  • Официальные термины: «Test Report», «Отчёт о результатах тестирования»
  • Разговорные: «тест-репорт», «сводка QA»
План релиза
  • Определение: Набор задач и изменений, которые войдут в следующий выпуск системы, с указанием сроков, ответственных, рисков. Может отражать приоритеты, зависимость функций.
  • Официальные термины: «Release Plan», «План выпуска»
  • Разговорные:
План тестирования
  • Определение: Структурированный документ или список, описывающий стратегию, объём, подходы и график тестирования. Помогает команде QA определить, что и как проверять.
  • Официальные термины: «Test Plan», «Стратегия тестирования»
  • Разговорные: «план теста», «тест-план»
Приёмочное тестирование
  • Определение: Проверка, проводимая с точки зрения заказчика или реальных пользователей, чтобы убедиться, что разработанный функционал соответствует их ожиданиям и бизнес-целям.
  • Официальные термины: «Acceptance Testing», «UAT (User Acceptance Testing)»
  • Разговорные: «акцепт-тест», «пользовательская приёмка»
Регрессионное тестирование
  • Определение: Повторная проверка уже работающих функций после внесения изменений или исправления багов, чтобы убедиться, что новое не повредило старому функционалу.
  • Официальные термины: «Regression Testing», «Регресс-тест»
  • Разговорные: «регресс», «перепроверка после фиксов»
Релиз
  • Определение: Итоговая или промежуточная версия продукта, которую решено официально поставить в эксплуатацию или передать заказчику. Может сопровождаться релиз-нотами и планом развёртывания.
  • Официальные термины: «Release», «Выпуск версии»
  • Разговорные: «релиз», «версия»
Релиз-ноты
  • Определение: Краткое описание того, что изменилось в новой версии (добавленные функции, исправленные баги, известные проблемы). Рассылается команде или пользователям при выпуске.
  • Официальные термины: «Release Notes», «Примечания к релизу»
  • Разговорные: «описание новшеств»
Ретроспектива
  • Определение: Встреча команды (обычно после релиза или спринта), где анализируется, что прошло хорошо, что не очень, и формируются идеи для улучшения процессов.
  • Официальные термины: «Retrospective», «Ретроспектива команды»
  • Разговорные: «ретро», «разбор полётов»
Сертификация качества
  • Определение: Формальный процесс подтверждения соответствия определённым стандартам (например, ISO, ГОСТ) или отраслевым нормам. Может охватывать процессы разработки и тестирования.
  • Официальные термины: «Quality Certification», «ISO-сертификация»
  • Разговорные: «сертиф», «оформление стандартов»
Скоринг дефектов
  • Определение: Оценка дефектов по нескольким осям (важность для пользователя, трудоёмкость исправления, риск для бизнеса) для определения очередности исправлений.
  • Официальные термины: «Defect Scoring», «Оценка дефектов»
  • Разговорные: «приоритет багов», «скоринг багов»
Тест-дизайн
  • Определение: Процесс определения и составления эффективного набора тестовых сценариев для проверки функционала, включая техники проектирования тестов, анализ граничных значений.
  • Официальные термины: «Test Design», «Проектирование тестов»
  • Разговорные: «дизайн тест-кейсов», «придумывание тестов»
Тест-кейс
  • Определение: Описанный набор шагов для проверки конкретного аспекта системы с ожидаемым результатом. Может включать исходные данные, окружение и критерии успеха.
  • Официальные термины: «Test Case», «Сценарий тестирования»
  • Разговорные: «тесткейс», «кейсы»
Трекинг дефектов
  • Определение: Процесс отслеживания жизненного цикла найденных багов (когда обнаружен, приоритет, кто исправляет, в каком статусе) в специальной системе (Jira, Bugzilla).
  • Официальные термины: «Defect Tracking», «Bug Tracking»
  • Разговорные: «баг-трекинг», «журнал дефектов»

6. Личная эффективность и инновации

Автоматизация рутины
  • Определение: Использование инструментов или скриптов для избавления от повторяющихся механических задач (форматирование документов, сортировка писем, заполнение шаблонов). Помогает экономить время и фокусироваться на более важных аспектах работы.
  • Официальные термины: «Routine Automation», «Автоматизация повседневных операций»
  • Разговорные: «автоматизация рутины», «убрать рутину»
Асинхронная коммуникация
  • Определение: Общение, при котором участники не обязаны отвечать мгновенно (электронная почта, мессенджеры), позволяя работать в удобном режиме и снижая отвлекающие факторы.
  • Официальные термины: «Asynchronous Communication», «Непрерывный несинхронный обмен»
  • Разговорные: «ассинх-коммуникация», «без постоянных созвонов»
Ассистент на базе ИИ
  • Определение: Программа или сервис, использующий искусственный интеллект (чат-боты, голосовые помощники), способный подсказывать решения, генерировать тексты, анализировать данные. Может быть встроен в инструменты аналитика.
  • Официальные термины: «AI Assistant», «Виртуальный помощник на основе искусственного интеллекта»
  • Разговорные: «ИИ-ассистент», «умный бот»
Брейнсторм
  • Определение: Метод коллективного генерации идей, при котором важно собрать как можно больше концепций без первоначальной критики, а затем отобрать наиболее подходящие.
  • Официальные термины: «Brainstorm», «Мозговой штурм»
  • Разговорные: «брейншторм», «генерация идей»
Воркшоп
  • Определение: Формат групповой работы (мастер-класса, семинара), где участники совместно разбирают задачу, создают прототипы или формируют новые подходы.
  • Официальные термины: «Workshop», «Коллективная рабочая сессия»
  • Разговорные: «воркшоп», «рабочая сессия»
Гибкий график
  • Определение: Режим, в котором сотрудникам разрешается начинать и заканчивать рабочий день в удобное время или работать частично удалённо, при условии выполнения задач и сохранения коммуникации.
  • Официальные термины: «Flexible Schedule», «Гибкий режим работы»
  • Разговорные: «флекс-график», «свободный режим»
Групповая динамика
  • Определение: Психологические и социальные процессы, происходящие в рабочей группе или команде (роли, конфликты, стадии развития). Влияют на общую эффективность и качество совместной работы.
  • Официальные термины: «Group Dynamics», «Динамика команды»
  • Разговорные: «групповое взаимодействие», «командная химия»
Инновационные решения
  • Определение: Новые методы, технологии или подходы, которые позволяют достичь существенного улучшения в продукте, процессе или организации, сравнивая с привычной практикой.
  • Официальные термины: «Innovative Solutions», «Инновационные подходы»
  • Разговорные:
Инструменты ИИ
  • Определение: Программы и сервисы, использующие искусственный интеллект (глубокое обучение, машинное обучение, обработку естественного языка), помогающие в аналитике, автоматизации рутины, генерации идей.
  • Официальные термины: «AI Tools», «Инструментарий искусственного интеллекта»
  • Разговорные: «айтишки», «ИИ-помощники»
Карьерное планирование
  • Определение: Определение долгосрочных целей и шагов в профессиональном росте. Может включать выбор курсов, смену ролей, получение сертификаций, прохождение стажировок или менторства.
  • Официальные термины: «Career Planning», «Разработка карьерного плана»
  • Разговорные: «план карьеры», «куда развиваться»
Коллективный интеллект
  • Определение: Суммарная способность группы людей решать задачи лучше, чем любой из них по отдельности, при грамотной организации совместной работы и обмена знаниями.
  • Официальные термины: «Collective Intelligence», «Интеллект группы»
  • Разговорные: «командное мышление», «общий мозг»
Личный бренд
  • Определение: Репутация и образ специалиста в профессиональном сообществе, который формируется через портфолио, публичные выступления, активность в соцсетях и личные проекты.
  • Официальные термины: «Personal Brand», «Имидж специалиста»
  • Разговорные: «бренд себя», «публичное лицо»
Личный план развития
  • Определение: Структурированная программа саморазвития, включающая цели (освоить новую методологию, пройти курсы), сроки, ресурсы и критерии достижения.
  • Официальные термины: «Personal Development Plan (PDP)», «Личный план роста»
  • Разговорные: «план прокачки», «дорожка развития»
Менторинг
  • Определение: Процесс, при котором более опытный специалист (наставник) делится знаниями и помогает менее опытному коллеге (ученику) адаптироваться и расти профессионально.
  • Официальные термины: «Mentoring», «Наставничество»
  • Разговорные: «менторинг», «наставничать»
Методы фасилитации
  • Определение: Набор инструментов и техник, облегчающих групповое обсуждение, принятие решений, генерацию идей (мозговые штурмы, карту эмпатии, silent storming и др.).
  • Официальные термины: «Facilitation Methods», «Инструментарий фасилитатора»
  • Разговорные: «фасил-приёмы», «техники групповой работы»
Мотивация команды
  • Определение: Система факторов (материальных и нематериальных), способствующих вовлечённости сотрудников, их стремлению к достижению целей и инициативности в работе.
  • Официальные термины: «Team Motivation», «Мотивирующие факторы»
  • Разговорные: «подъём боевого духа», «заряд команды»
Навык публичных выступлений
  • Определение: Умение ясно и убедительно говорить перед аудиторией (презентации, доклады, семинары), используя структуру, примеры и взаимодействие со слушателями.
  • Официальные термины: «Public Speaking Skills», «Навык публичных презентаций»
  • Разговорные: «скилл спича», «умение выступать»
Навыки ведения совещаний
  • Определение: Умение планировать повестку, фасилитировать дискуссию, следить за временем, документировать итоги и решения, чтобы встречи проходили продуктивно.
  • Официальные термины: «Meeting Management Skills», «Умение управлять совещанием»
  • Разговорные: «собраться поговорить», «рулить митингом»
Нетворкинг
  • Определение: Создание и поддержание профессиональных контактов для обмена знаниями, поиска партнёров, работы или клиентов. Включает участие в конференциях, соцсетях, группах по интересам.
  • Официальные термины: «Networking», «Профессиональное общение»
  • Разговорные: «заводить связи», «общаться для дел»
Обучение на рабочем месте
  • Определение: Формат развития сотрудника, при котором знания и навыки осваиваются непосредственно в процессе реальных проектов и ежедневных задач (стажировка, ротация, shadowing).
  • Официальные термины: «On-the-job Training (OJT)», «Обучение в процессе работы»
  • Разговорные: «учиться на практике», «освоение на месте»
Органайзеры задач
  • Определение: Приложения для управления личными и командными делами, устанавливающие приоритеты, сроки, напоминания (Trello, Notion, Todoist). Помогают повысить эффективность за счёт структурирования работы.
  • Официальные термины: «Task Management Tools», «Инструменты управления задачами»
  • Разговорные: «таск-менеджеры», «списки задач»
Психогигиена
  • Определение: Комплекс приёмов и привычек, направленных на сохранение эмоционального и психологического здоровья (управление стрессом, правильный отдых, рефлексия).
  • Официальные термины: «Psychological Well-being», «Психологическая гигиена»
  • Разговорные: «беречь нервы», «не выгорать»
Рабочая среда
  • Определение: Совокупность условий, в которых человек выполняет труд (физическое пространство, инструменты, коллектив, нормы взаимодействия), влияющих на продуктивность и комфорт.
  • Официальные термины: «Work Environment», «Условия труда»
  • Разговорные: «рабочее окружение», «офис и атмосфера»
Самомотивация
  • Определение: Способность человека поддерживать внутренний интерес и энтузиазм к задачам и целям, не полагаясь на внешние стимулы.
  • Официальные термины: «Self-motivation», «Внутренняя мотивирующая установка»
  • Разговорные: «подпитывать себя», «заряжать себя»
Самооценка
  • Определение: Регулярный анализ собственных навыков, достижений и пробелов, позволяющий поставить новые цели или скорректировать подход к работе. Включает сбор обратной связи и личную рефлексию.
  • Официальные термины: «Self-assessment», «Анализ личных компетенций»
  • Разговорные: «оценка себя», «самопроверка»
Самоорганизация
  • Определение: Умение самостоятельно планировать и контролировать свою деятельность, расставлять приоритеты и придерживаться дисциплины без жёсткого внешнего контроля.
  • Официальные термины: «Self-organization», «Самостоятельное управление временем и задачами»
  • Разговорные: «собраться», «самодисциплина»
Тайм-менеджмент
  • Определение: Набор приёмов и инструментов для рационального распределения времени (приоритизация задач, календарное планирование, контроль отвлекающих факторов).
  • Официальные термины: «Time Management», «Управление временем»
  • Разговорные:
Удалённая работа
  • Определение: Формат, при котором сотрудник выполняет задачи вне офиса (из дома, коворкинга, другого города) с использованием дистанционных каналов связи и инструментов совместной работы.
  • Официальные термины: «Remote Work», «Дистанционная работа»
  • Разговорные: «удалёнка», «работать из дома»
Эмоциональный интеллект
  • Определение: Способность человека осознавать и управлять своими эмоциями, а также понимать чувства окружающих, что помогает выстраивать эффективные коммуникации и избегать конфликтов.
  • Официальные термины: «Emotional Intelligence (EI)», «Эмоциональная компетентность»
  • Разговорные: «эмо-интеллект», «чувствовать людей»

7. Инструменты и программное обеспечение

Системы управления проектами и задачами
  • Jira (Джира): Cистема для планирования, отслеживания задач, ведения спринтов по Agile, управления бэклогом и релизами.
  • Trello (Трелло): Упрощённое канбан-приложение с карточками и досками для задач, наглядная визуализация прогресса.
  • Azure DevOps (Азур ДевОпс): Комплексная платформа от Microsoft для планирования, хранения кода, CI/CD и тест-менеджмента.
  • YouTrack (ЮТрек): От JetBrains, трекер задач, позволяющий гибко настраивать поля, приоритизацию и рабочие процессы.
  • Asana (Асана): Веб-сервис для управления проектами и постановки задач, со множеством интеграций и доской Kanban.
  • Monday.com (Мандэй): Онлайн-платформа для визуального планирования, создания досок и сбора статистики по задачам.
  • Redmine (Редмайн): Open Source-решение для управления проектами и отслеживания ошибок, поддерживает плагины и Gantt.
  • Bitrix24 (Битрикс24): Российский сервис для управления задачами, CRM, коммуникациями, подходит для комплексной организации работы.
Системы совместной работы и чат
  • Slack (Слак): Корпоративный мессенджер с каналами по темам, расширенными интеграциями и поддержкой файлов.
  • Microsoft Teams (Майкрософт Тимс): Решение для чат-общения, видеоконференций и работы с документами в Office 365.
  • Telegram (Телеграм): Популярный мессенджер с облачным хранением, ботами, каналами и группами; используется и для рабочих чатов.
  • Discord (Дискорд): Удобные голосовые и текстовые каналы, изначально для геймеров, но адаптирован для командной работы.
  • Skype (Скайп): Классическая программа для видео- и аудиозвонков, чатов; по-прежнему встречается в некоторых IT-командах.
  • Rocket.Chat (РокетЧат): Open Source-аналог Slack, можно развернуть на собственных серверах.
  • Mattermost (Маттермост): Тоже Open Source-платформа для чатов и командных коммуникаций, формально напоминает Slack.
  • VK Teams (ВК Тимс): Российский корпоративный мессенджер для рабочих чатов, конференций и интеграций с экосистемой ВКонтакте.
Документирование и вики
  • Confluence (Конфлюенс): Платформа для хранения документации и организации вики-пространств, тесно связана с Jira.
  • Notion (Нотион): Многофункциональный инструмент для заметок, баз данных, вики, досок задач и совместной работы.
  • MediaWiki (МедиаВики): Движок Википедии, можно использовать как внутреннюю вики-систему в компании, бесплатно.
  • Google Docs (Гугл Докс): Онлайн-пакет для редактирования текстов и таблиц с комментариями и историей изменений.
  • Evernote (Эверноут): Приложение для заметок, поддержка меток, вложений, синхронизации между устройствами.
  • SharePoint (Шерпоинт): Корпоративная платформа от Microsoft для совместной работы и публикации документов.
  • Dropbox Paper (Дропбокс Пэйпер): Онлайн-редактор для совместного написания документов, комментариев и мультимедиа.
  • HackMD (ХакМД): Сервис для совместного редактирования Markdown-документов, популярный у разработчиков.
BPM и управление бизнес-процессами
  • Camunda (Камунда): Платформа для моделирования и исполнения процессов по BPMN, DMN, имеет открытый исходный код.
  • Activiti (Активити): Лёгковесный Java-движок BPM, основанный на BPMN 2.0, для автоматизации бизнес-процессов.
  • Bonita BPM (Бонита): Платформа для дизайна процессов, форм и автоматизации workflows.
  • IBM BPM (АйБиЭм БиПиЭм): Корпоративное решение для оркестрации и анализа бизнес-процессов, используется в крупных организациях.
  • Appian (Аппиан): Среда быстрого создания приложений (low-code), фокус на BPM, кейсовом управлении и автоматизации.
  • Bizagi (Бизаджи): Моделирование, автоматизация и мониторинг процессов, имеется бесплатная версия для моделирования.
  • Flowable (Фловейбл): Форк Activiti, поддерживает BPMN, CMMN и DMN, активно развивается сообществом.
  • Signavio (Сигнавио): Облачное решение для моделирования и оптимизации процессов, коллективной работы над схемами.
Моделирование и диаграммы
  • draw.io (дро.ио): Онлайн-редактор диаграмм (BPMN, UML, ER), поддерживает совместную работу и экспорт в различные форматы.
  • Lucidchart (Люсидчарт): Веб-приложение для рисования диаграмм, концептуальных схем, потоков. Имеет библиотеку шаблонов.
  • Microsoft Visio (Майкрософт Визио): Классическое настольное ПО для UML, блок-схем, интегрируется с Microsoft 365.
  • StarUML (СтарЮМЛ): Лёгкий инструмент для UML-диаграмм (классы, последовательности, состояния), удобен для проектирования.
  • Enterprise Architect (Энтерпрайз Архитект): Серьёзное решение для UML, BPMN, ArchiMate, применимо при системной архитектуре.
  • PlantUML (ПлантЮМЛ): Подход, где диаграммы UML описываются текстовыми скриптами, а затем автоматически визуализируются.
  • Gliffy (Глиффи): Плагин для Confluence/Jira или отдельный сервис, создающий диаграммы UML, блок-схемы и т. п.
  • Umlet (Юмлет): Простая бесплатная программа для UML-диаграмм, быстрая разметка элементов с помощью текстовых описаний.
Версионирование и репозитории
  • Git (Гит): Распределённая система контроля версий, ставшая стандартом индустрии. Управление ветками, коммитами, слияниями.
  • GitHub (Гитхаб): Облачный хостинг Git-репозиториев, позволяющий организовать pull request, issues, проекты.
  • GitLab (Гитлаб): Решение для хранения репозиториев, CI/CD, issue-трекера. Может использоваться в облаке или локально.
  • Bitbucket (Битбакет): Сервис Atlassian для Git/Mercurial, интегрируется с Jira и Confluence.
  • Subversion (Сабвержн): Централизованная система контроля версий, популярная до широкого распространения Git.
  • Mercurial (Меркуриал): Распределённая система контроля версий, похожая на Git, но с другими принципами ветвления.
  • Gogs (Гогс): Самостоятельно хостящаяся платформа для Git, компактная и быстрая.
  • SourceForge (СорсФордж): Историческая площадка для Open Source-проектов, с хостингом кода и трекером.
Тестирование и QA
  • Zephyr (Зефир): Плагин для Jira, позволяет управлять тест-кейсами, циклами тестирования и связями с задачами.
  • TestRail (ТестРейл): Система для хранения тест-кейсов, планирования тестовых прогонов, генерации отчётов.
  • HP ALM (HP Quality Center): Корпоративная платформа для управления тестами, дефектами, требованиями.
  • qTest (КуТест): Решение для тест-менеджмента, интегрируется с CI/CD и системами отслеживания задач.
  • Selenium (Селениум): Набор инструментов для автоматизации тестов веб-интерфейсов (Selenium WebDriver и др.).
  • Katalon Studio (Каталон Студио): Среда для автоматизированного тестирования веба и мобильных приложений, в том числе рекордер действий.
  • Postman (Постман): Клиент для тестирования REST/GraphQL API, упрощает разработку и отладку запросов, создание автотестов.
  • SoapUI (СоупЮАй): Средство функционального тестирования SOAP и REST сервисов, подходит для комплексных интеграционных сценариев.
Визуализация, BI и аналитика
  • Tableau (Табло): Среда для построения интерактивных дашбордов и отчётов из различных источников, популярен в BI-аналитике.
  • Power BI (Пауэр БиАй): Решение Microsoft для построения отчётов, дашбордов, визуализации данных. Легко интегрируется с Office 365.
  • QlikView (КликВью): Платформа для анализа и дашбордов, предшественник Qlik Sense, имеет интерактивные функции.
  • Google Data Studio (Гугл Дэйта Студио): Бесплатный инструмент для создания отчётов и дашбордов на основе данных из Google Analytics, CSV, BigQuery и др.
  • Grafana (Графана): Дашборды для метрик и логов, часто используется с Prometheus в DevOps-средах.
  • Kibana (Кибана): Визуализационный интерфейс Elasticsearch, удобно для лог-аналитики, временных рядов и поиска аномалий.
  • Redash (Редаш): Open Source BI-платформа для построения запросов к БД, визуализаций и дашбордов.
  • Metabase (Метабейс): Простое self-hosted решение BI, позволяет создавать дашборды и запросы без глубоких SQL-навыков.
AI-чат-боты и голосовые ассистенты
  • GigaChat (ГигаЧат): Российский чат-бот с ИИ, способный поддерживать диалоги, транскрибировать речь и выполнять задания по тексту.
  • Salute (Салют): Российская платформа от Сбера для голосовых ассистентов и чат-ботов, умеет преобразовывать речь, контекстно отвечать.
  • ChatGPT (ЧатДжиПиТи): Иностранный мощный чат-бот с ИИ от OpenAI, способен генерировать тексты, решать задачи, вести диалоги.
  • Bard (Бард): Иностранный ассистент от Google, нацеленный на генерацию ответов, поиск информации, контекстуальные диалоги.
  • Alice (Алиса): Голосовой помощник Яндекса с навыками распознавания речи, способный управлять умным домом и выполнять базовые диалоги.
  • Siri (Сири): Ассистент от Apple, интегрирован в iOS-устройства, выполняет голосовые команды и ищет информацию.
  • VK Marusya (ВК Маруси́я): Голосовой ассистент для экосистемы «ВКонтакте», может воспроизводить музыку, управлять сервисами ВК.
  • OfficeBot (ОфисБот): Корпоративный чат-бот, способный автоматизировать рутинные задания, поиск документов, интеграцию с CRM.
Российские решения
  • MyOffice (МайОфис): Пакет офисных приложений (текст, таблицы, презентации), разработан в РФ, используется в органах госуправления и коммерческих структурах.
  • VK Teams (ВК Тимс): Корпоративный мессенджер от «ВКонтакте» с видеоконференциями, интеграцией с экосистемой VK.
  • Bitrix24 (Битрикс24): Уже упомянутая система для управления проектами, CRM и внутренними порталами, популярна среди российского бизнеса.
  • Red OS (Ред ОС): Операционная система на базе Linux, адаптирована под российские стандарты.
  • Sfera (Сфера): Российский сервис для удалённой работы и взаимодействия, объединяющий задачи, коммуникации и видеосвязь.
  • VK Cloud (ВК Клауд): Облачная инфраструктура, предлагающая IaaS/PaaS-услуги, аналог зарубежных решений.
  • _RuStore (РуСтор):* Российский магазин приложений для Android, конкурент зарубежным сторам.
  • Lanit BPM (Ланит BPM): Отечественная система управления бизнес-процессами, позволяет моделировать и автоматизировать потоки работ.

Об авторе

■ Другие статьи по теме Архитектура

Показать еще

■ Другие статьи по теме Интеграция

■ Другие статьи на тему Базы данных

Показать еще

■ Другие статьи на тему User Stories и Use Cases

■ Другие статьи на тему Требований

Показать еще

■ Другие статьи на тему Бизнес-анализ

■ Другие статьи на тему Профессия и трудоустройство

Показать еще

■ Другие статьи на тему Проектное управление

■ Другие статьи на тему Менеджмент и архитектура предприятия

Показать еще

■ Другие статьи на тему Дизайн интерфейсов и исследования