Полезный справочник для новичков, стажёров, разработчиков и всех, кто работает в IT-сфере. Глоссарий охватывает популярные роли, технологии, термины, сленг и бизнес-лексикон.
| Термин | Значение |
|---|---|
| CEO | Chief Executive Officer — генеральный директор |
| CTO | Chief Technology Officer — технический директор |
| CPO | Chief Product Officer — отвечает за продукт |
| COO | Chief Operating Officer — операционный директор |
| Dev | Developer — разработчик |
| QA | Quality Assurance — тестировщик (ручной или автоматизатор) |
| PM | Project Manager — руководитель проекта |
| PO | Product Owner — владелец продукта, формирует задачи |
| TL / Lead | Team Lead — тимлид, руководитель команды |
| BA | Business Analyst — бизнес-аналитик |
| HR | Human Resources — рекрутер, кадровик |
| UX/UI | User Experience / User Interface — дизайнер интерфейсов |
| SRE | Site Reliability Engineer — инженер надежности |
| DevOps | Специалист по CI/CD, автоматизации инфраструктуры |
| Intern | Стажёр |
| Junior | Младший специалист |
| Middle | Специалист среднего уровня |
| Senior | Старший специалист |
| Architect | Архитектор ПО — проектирует архитектуру приложения |
| Термин | Значение |
|---|---|
| Backend | Серверная часть — логика, базы данных, API |
| Frontend | Клиентская часть — интерфейс, то что видит пользователь |
| Fullstack | Специалист и в backend, и в frontend |
| Stack | Набор технологий (например: React + Node.js + MongoDB) |
| CI/CD | Непрерывная интеграция и доставка |
| API | Интерфейс для связи между системами (REST, GraphQL) |
| DB | Database — база данных |
| ORM | Object-Relational Mapping — работа с БД через код |
| IDE | Integrated Development Environment — среда разработки |
| Repo | Репозиторий — хранилище кода (обычно Git) |
| Branch | Ветка в Git |
| Merge | Слияние веток |
| Pull Request (PR) | Запрос на слияние кода |
| Code Review | Проверка кода другим разработчиком |
| Refactor | Переписывание кода без изменения поведения |
| Commit | Сохранение изменений в Git |
| Deploy | Выкладывание проекта на сервер |
| Release | Выпуск новой версии продукта |
| Термин | Значение |
|---|---|
| MVP | Minimum Viable Product — минимально рабочая версия |
| Pivot | Смена стратегии или направления проекта |
| KPI | Key Performance Indicators — ключевые метрики |
| OKR | Objectives and Key Results — цели и результаты |
| A/B тест | Сравнение двух версий фичи |
| Roadmap | Дорожная карта разработки |
| User Story | История пользователя, задача с точки зрения юзера |
| Sprint | Короткий цикл разработки |
| Backlog | Список задач |
| Estimate | Оценка задачи |
| Scope | Объём работ или функционала |
| Deadline | Крайний срок |
| Feature | Функция, возможность |
| Tech Debt | Технический долг — компромиссы в коде |
| Stakeholder | Заинтересованное лицо (инвесторы, заказчики) |
| Термин | Значение |
|---|---|
| Stand-up | Ежедневный митинг команды |
| Call | Звонок по видеосвязи |
| 1-on-1 | Индивидуальная встреча |
| Ping / Пингануть | Напомнить, написать |
| Sync | Сверка по прогрессу |
| ASAP | As Soon As Possible — как можно скорее |
| ETA | Estimated Time of Arrival — время выполнения |
| FYI | For Your Information — для информации |
| IMO / IMHO | По моему (скромному) мнению |
| TL;DR | Слишком длинно — не читал. Краткое резюме |
| LGTM | Looks Good To Me — одобрение PR |
| BRB | Сейчас вернусь |
| AFK | Отошёл от клавиатуры |
| Термин | Значение |
|---|---|
| CI/CD pipeline | Автоматическая сборка, тесты, деплой |
| Microservices | Архитектура из отдельных независимых сервисов |
| Monolith | Монолитное приложение — всё в одном коде |
| Container | Изолированная среда (Docker и т.п.) |
| Orchestration | Управление контейнерами (например, Kubernetes) |
| Load Balancer | Балансировщик нагрузки |
| Scalability | Масштабируемость |
| Latency | Задержка ответа |
| Throughput | Пропускная способность |
| Failover | Переключение при сбое |
| Cache | Кеш — временное хранилище данных |
| Queue | Очередь задач (RabbitMQ, Celery) |
| Pub/Sub | Публикация/подписка, событийная система |
Если ты хочешь добавить термин — создай Pull Request или Issue!
MIT License
Dev
Вот полный разбор термина CPO:
CPO (Chief Product Officer) — это директор по продукту, один из ключевых C-level руководителей в IT и технологических компаниях.
CPO — это главный человек, отвечающий за продукт в компании. Он решает:
-
🔭 Продуктовая стратегия Определяет, каким будет продукт, зачем он нужен, кому и как его развивать.
-
🎯 Управление фичами Какие функции приоритетны, какие — в будущем, какие — вырезать.
-
🧩 Связующее звено между командами Работает с разработкой, дизайном, маркетингом, аналитикой и продажами.
-
📈 Рост и метрики Отвечает за KPI: активность пользователей, удержание, конверсии, выручку, NPS.
-
🧪 Прототипы, A/B тесты и исследования Организует процесс гипотез, тестирования, проверок идей.
В типичной IT-компании:
CEO
|
+--------+---------+---------+
| | |
CTO CPO CMO/COO
| | |
devs product marketing
- CEO — генеральный директор
- CPO — глава всего, что связано с продуктом
- CTO — отвечает за технологии (как продукт работает)
- CMO — за маркетинг
- COO — за операционку
| CTO | CPO | |
|---|---|---|
| Отвечает за | Технологии, архитектуру | Продукт, пользователей |
| Цель | Рабочий, надежный код | Полезный, востребованный продукт |
| Взаимодействует с | Разработчиками, DevOps | UX-дизайнерами, аналитиками, клиентами |
- «Какая фича важнее: чат или платёжная система?»
- «Как улучшить онбординг в приложении?»
- «Как повысить Retention на 14-й день?»
- «Какую бизнес-модель выбрать — подписка или freemium?»
- «Пора ли делать новую версию продукта или нет?»
Часто CPO — это:
- бывший продакт-менеджер с большим опытом
- или основатель продукта, выросший до руководителя
- или аналитик/маркетолог, глубоко понимающий рынок и пользователей
Вот подробное объяснение:
COO (Chief Operating Officer) — это операционный директор, правая рука CEO и один из главных управляющих в компании. Он отвечает за ежедневную операционную деятельность бизнеса.
COO следит за тем, чтобы вся машина бизнеса работала слаженно: от найма до логистики, от поставок до внутренней эффективности. Это человек-процессы.
-
🏗 Организация внутренних процессов Управление командами, найм, внутренние регламенты, процедуры, контроль сроков.
-
🔄 Оптимизация работы бизнеса Внедрение CRM, систем учёта, KPI, автоматизация процессов.
-
📦 Управление производством или сервисом Особенно актуально для e-commerce, производств и сервисных компаний.
-
🧑🤝🧑 Работа с командами HR, финансы, юридический отдел, support, менеджеры — часто под COO.
-
📈 Выполнение стратегий CEO CEO придумывает стратегию — COO реализует её на практике.
- «Как уменьшить сроки выхода фичей на прод в 2 раза?»
- «Как масштабировать команду без потери контроля?»
- «Как внедрить отчётность и KPI во все отделы?»
- «Как сократить расходы на логистику на 15%?»
- «Как создать SLA для техподдержки и заставить его работать?»
| CEO (Генеральный директор) | COO (Операционный директор) | |
|---|---|---|
| Что делает | Определяет курс, видение, стратегию | Реализует всё на практике |
| За что отвечает | Внешнее — рынок, инвестиции, миссия | Внутреннее — люди, процессы, эффективность |
| С кем работает | Борд, инвесторы, клиенты | Все команды внутри компании |
- 📈 Когда компания активно растёт и CEO уже не может лично управлять всем
- 🏢 Когда появляется много отделов: support, продажи, HR, продакты, техкоманды
- ⚙️ Когда бизнес требует сильной внутренней организации (например, логистика, ритейл, производство)
Часто это:
- бывший project/product manager с уклоном в управление
- человек с опытом управления операциями, логистикой, отделами
- основатель (если CEO — визионер, а COO — оператор)
В ИТ-компаниях COO может заниматься:
- наймом и оргструктурой
- сопровождением релизов (если нет CTO/CTO загружен)
- юридическими вопросами, финансами
- автоматизацией процессов (CRM, Notion, Git, CI/CD процессов)
- формированием культуры и процессов
Вот подробное объяснение термина CI/CD:
CI/CD — это набор практик и автоматизаций в разработке ПО, который ускоряет и упрощает процесс доставки кода от разработчика до пользователя.
Расшифровка:
- CI (Continuous Integration) — Непрерывная интеграция
- CD (Continuous Delivery / Continuous Deployment) — Непрерывная доставка или непрерывный деплоймент
Разработчики регулярно (несколько раз в день) заливают код в общую ветку (например, main или develop), после чего автоматически запускаются:
- Сборка проекта
- Юнит-тесты
- Анализ кода (линтеры, статический анализ)
- Снижается риск конфликтов при слиянии
- Ошибки находятся на ранних этапах
- Повышается стабильность кода
- GitHub Actions
- GitLab CI
- Jenkins
- Travis CI
- CircleCI
После прохождения CI проект автоматически подготавливается к релизу:
- Происходит сборка production-версии
- Генерируются артефакты (например, Docker-образы)
- Код может быть развёрнут на staging-сервере
- Но деплой на прод — вручную (по кнопке)
- Быстро выпускать новые версии
- Уменьшить ручную работу
- Тестировать продукт на «боевых» условиях без риска
Процесс деплоя автоматизирован полностью: после успешного CI пайплайна код автоматически выкатывается на продакшн без ручного участия.
- Максимальная скорость поставки продукта
- Полная автоматизация (Zero Touch Deployment)
- Идеально для микросервисов и стартапов
1. Разработчик пушит код -> GitHub
2. CI запускает:
- Линтер
- Юнит-тесты
- Сборку проекта
3. Если всё ок — создаётся Docker-образ
4. Delivery: выкатываем на staging
5. Manual approval (или автоматический запуск)
6. Deployment: выкатываем на production
✅ Быстрое обнаружение багов ✅ Ускорение релизов ✅ Автоматизация тестирования ✅ Повышение стабильности ✅ Логирование и контроль версий
Отличный вопрос, Dev. Вот точный и развернутый ответ:
В компаниях роль за CI/CD может быть:
Чаще всего за это отвечает DevOps-инженер, но также может:
- выполнять Backend-разработчик (если команда маленькая)
- настраивать тимлид (на старте проекта)
- взять на себя SRE (Site Reliability Engineer)
В стартапах нередко один человек совмещает роли: и dev, и devops, и ci/cd.
В крупных продуктах бывает отдельный CI/CD-инженер или Release Engineer, отвечающий за:
- настройку пайплайнов (Jenkins, GitHub Actions и т.п.)
- поддержку автоматической сборки, тестирования и выката
- инфраструктуру артефактов (Docker Registry, Nexus, GitLab Registry)
- безопасность CI/CD (секреты, токены, доступы)
- оптимизацию скорости сборки
| Тип компании | Кто отвечает за CI/CD |
|---|---|
| Стартап (1–5 dev) | Сам разработчик |
| Средняя (6–20 dev) | DevOps или тимлид |
| Крупная (>20 dev) | Выделенный CI/CD инженер или DevOps команда |
Если ты разработчик и хочешь уметь настраивать CI/CD самостоятельно:
- Базовые знания YAML (для конфигов)
- Опыт с Git и GitHub/GitLab
- Понимание Docker и контейнеризации
- Знание CI/CD-систем: GitHub Actions, GitLab CI, Jenkins и др.
- Знание тестов, линтеров, инструментов деплоя (Kubernetes, Ansible и др.)