Skip to content

Instantly share code, notes, and snippets.

@GregoryKogan

GregoryKogan/ESE.md

Created December 22, 2025 22:49
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save GregoryKogan/5760694fea8e141d1b6a5656c2b38099 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save GregoryKogan/5760694fea8e141d1b6a5656c2b38099 to your computer and use it in GitHub Desktop.
Download ZIP
Билеты к зачету ЭПИ
Raw
ESE.md

ЭПИ. Билеты

Вопросы

Ответы

1. Понятие программной инженерии (ПИ). История ее появления и становления как самостоятельной дисциплины

Понятие: Программная инженерия (Software Engineering) — это приложение систематического, дисциплинированного и измеримого подхода к разработке, эксплуатации и сопровождению программного обеспечения. Это инженерная дисциплина, которая занимается всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию.

История и становление:

  • Предпосылки (1950–60-е): Программирование воспринималось как искусство или ремесло. Отсутствовали стандарты, проекты часто срывали сроки и превышали бюджеты.
  • Кризис ПО (Software Crisis): К концу 60-х сложность задач выросла, а методы остались кустарными. Это привело к низкому качеству продуктов, невозможности поддержки кода и огромным финансовым потерям.
  • Рождение термина (1968): Термин был официально введен на конференции НАТО в Гармиш-Партенкирхене (Германия). Целью было объявить о необходимости перехода от «кустарного» программирования к промышленному производству ПО, основанному на инженерных принципах.
  • Становление:
    • 1970-е: Появление модели Waterfall (каскадная), структурного программирования.
    • 1980-е: Развитие CASE-средств, объектно-ориентированного подхода, появление моделей оценки стоимости (COCOMO).
    • 1990-е – н.в.: Акцент на гибких методологиях (Agile), DevOps, стандартизации процессов (ISO/IEC 12207, CMMI).

Наверх

2. Типы компаний, связанных с IT. Условия их функционирования в РФ (включая налоговый аспект и возможные преференции)

Типы компаний (согласно лекциям):

  1. R&D центры вендоров (ранее Oracle, Intel и др.): Крупные штаты, западная бюрократия, высокие зарплаты, работа над мейнстрим-технологиями.
  2. Стартапы: Малые команды (3-5 чел.), базируются на идее, высокие риски, семейная атмосфера, возможность резкого роста или провала.
  3. Системные интеграторы (Software-подразделения): Обслуживание клиентов, условно-стабильные ЗП, работа от «раздолбайства» до формализма.
  4. Оборонные предприятия и НИИ: Госзаказ, бюрократия, стабильность, вертикальный карьерный рост, часто устаревшие подходы, но интересные задачи.
  5. Web-студии / Агентства: Выросшие стартапы, средний размер, разные предметные области.
  6. Разработчики бизнес-ПО (1С, Финтех): Сложная предметная область, стабильность, большие штаты.
  7. Промышленная автоматизация: Работа с «железом» и софтом, требует инвестиций в оборудование.

Условия функционирования в РФ (налоговый маневр для IT): Для получения льгот компания должна быть включена в реестр аккредитованных IT-компаний Минцифры и получать не менее 70% доходов от профильной деятельности.

  • Налог на прибыль: 0% (до конца 2024 года, далее возможны изменения, стандартная ставка — 20%).
  • Страховые взносы: Сниженный тариф 7,6% (вместо стандартных 30%).
  • НДС: Освобождение от НДС при продаже ПО, включенного в Единый реестр российского ПО.
  • Прочие льготы: Льготная ипотека для сотрудников, отсрочка от армии для специалистов, мораторий на плановые проверки.

Наверх

3. Элементы организационного дизайна компаний (ОДК), связанных с IT

Организационный дизайн — это не просто структура (схема подчинения), а системный подход к согласованию всех аспектов работы компании для достижения стратегических целей.

Ключевые элементы ОД:

  1. Стратегия: Цели компании, миссия, видение, конкурентные преимущества. Отвечает на вопрос «Куда мы идем?».
  2. Структура: Формальная иерархия, распределение ролей, ответственности и подчинения.
  3. Процессы: Способы выполнения работы, потоки информации, принятие решений (бизнес-процессы, регламенты).
  4. Люди (Персонал): Подбор, обучение, развитие талантов, компетенции сотрудников.
  5. Системы вознаграждения: Мотивация, KPI, бонусы, карьерные лестницы.
  6. Культура: Неформальные правила, ценности, стиль лидерства, способы коммуникации внутри команды.

В лекциях также выделяются конкретные действующие лица: Гендиректор, Бухгалтерия, Отделы разработки/тестирования, Продажи/Маркетинг, HR, Юристы, Безопасность.

Наверх

4. Модели и параметры ОДК

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

Основные модели:

  1. Модель McKinsey 7S: Делит элементы на «жесткие» (Hard S) и «мягкие» (Soft S).
    • Hard: Strategy (Стратегия), Structure (Структура), Systems (Системы).
    • Soft: Shared Values (Ценности), Skills (Навыки), Staff (Сотрудники), Style (Стиль управления).
  2. Модель «Звезда» (Star Model) Джея Гэлбрейта: Пять вершин звезды, которые должны быть согласованы: Стратегия, Структура, Процессы, Вознаграждение, Люди.
  3. Модель «ДНК организации» (Strategy&): Рассматривает 8 элементов в парах (формальные и неформальные):
    • Решения (Права / Нормы).
    • Информация (Метрики / Мышление).
    • Мотивация (Стимулы / Обязательства).
    • Структура (Иерархия / Связи).
  4. BCG Smart Design: Фокусируется на поведении сотрудников как главной силе бизнеса.

Параметры ОДК (характеристики):

  • Степень централизации/децентрализации.
  • Уровень формализации (жесткие регламенты или гибкость).
  • Специализация (разделение труда).
  • Диапазон контроля (сколько подчиненных у менеджера).

Наверх

5. Организационные структуры компаний, связанных с IT: сравнительный обзор

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

1. Простая структура (Startup):

  • Суть: Гендиректор (собственник) управляет всеми напрямую.
  • Плюсы: Быстрые решения, гибкость, минимум бюрократии.
  • Минусы: Зависимость от лидера, плохая масштабируемость, хаос при росте.

2. Функциональная структура:

  • Суть: Группировка по специализации (Отдел Backend, Отдел Design, Отдел QA, Отдел Продаж).
  • Плюсы: Высокая экспертиза внутри отделов, четкая карьера, эффективность ресурсов.
  • Минусы: «Колодцы» (плохая коммуникация между отделами), медленная реакция на изменения рынка, конфликт приоритетов.

3. Дивизиональная структура:

  • Суть: Деление по продуктам, рынкам или регионам (Дивизион «Облачные решения», Дивизион «Мобильные приложения»). У каждого дивизиона свои ресурсы (разрабы, маркетинг).
  • Плюсы: Фокус на продукте/рынке, быстрая реакция, ответственность за прибыль лежит на дивизионе.
  • Минусы: Дублирование ресурсов (свои юристы/бухгалтеры в каждом дивизионе), конкуренция между дивизионами, высокие затраты.

4. Матричная структура:

  • Суть: Двойное подчинение. Сотрудник подчиняется функциональному руководителю (Главе разработки) и менеджеру проекта/продукта.
  • Плюсы: Гибкое использование ресурсов, фокус и на качестве кода, и на сроках проекта.
  • Минусы: Конфликты приоритетов (двух начальников), сложная коммуникация, стресс для сотрудников.

5. Современные гибкие структуры (Сетевая, Командная, Холакратия):

  • Суть: Децентрализация, кросс-функциональные команды, минимум иерархии (плоская структура).
  • Плюсы: Высокая адаптивность, вовлеченность персонала, инновационность.
  • Минусы: Сложность координации, риск потери управляемости, требует высокой зрелости сотрудников.

Наверх

6. Сравнение сервисной и продуктовой модели. Основные черты, присущие обеим моделям

Сервисная модель (Аутсорсинг/Заказная разработка):

  • Суть: Продажа времени и компетенций специалистов («аренда» команды).
  • Фокус: Ответ на вопрос «Как сделать?». Ориентация на ТЗ заказчика, сроки, бюджет и качество кода.
  • Доход: Маржа между ставкой продажи специалиста клиенту и его зарплатой (Hourly Rate / Fixed Price).
  • Риски: Низкие. Оплата обычно гарантирована контрактом.
  • Масштабирование: Линейное (хочешь больше денег — нанимай больше людей).

Продуктовая модель:

  • Суть: Создание тиражируемого решения (продукта) для массового рынка.
  • Фокус: Ответ на вопрос «Что делать?». Проверка гипотез, поиск ценности для пользователя (Customer Development), метрики продукта.
  • Доход: Продажа лицензий, подписки, реклама. Потенциально неограничен.
  • Риски: Высокие. Продукт может «не взлететь», и затраты не окупятся.
  • Масштабирование: Экспоненциальное (один раз написал код — продал миллион раз).

Общие черты:

  • Использование IT-технологий и инструментов разработки.
  • Потребность в квалифицированных кадрах (разработчики, тестировщики).
  • Необходимость управления качеством.
  • Работа в условиях конкуренции.

Наверх

7. Продуктово-сервисные и сервисно-продуктовые модели

Это гибридные формы, сочетающие элементы обеих моделей для диверсификации рисков и увеличения прибыли.

Продуктово-сервисная модель: Компания продает продукт как основу, но зарабатывает также на сопутствующем сервисе.

  • Пример: Продажа сложной ERP-системы (продукт) + платные услуги по ее внедрению, кастомизации под клиента, обучению сотрудников и техподдержке (сервис). Часто сервис приносит больше денег, чем лицензия.

Сервисно-продуктовая модель: Компания занимается услугами (аутсорсинг), но упаковывает их как коробочные продукты или создает внутренние инструменты для продажи.

  • Пример 1 (Продуктизация услуги): Вместо «разработки сайта с нуля» агентство продает «Готовое решение для интернет-магазина за 3 дня по фиксированной цене».
  • Пример 2 (Внутренний продукт): Аутсорсинговая компания написала для себя систему трекинга задач, поняла, что она удобная, и начала продавать ее как SaaS-продукт на рынок.

Наверх

8. Можно ли трансформировать продуктовую модель в сервисную и наоборот? Приведите примеры

Ответ: Да, трансформация возможна и часто происходит в процессе эволюции компании.

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

  • Пример: Веб-студия 37signals занималась заказной разработкой, создала для себя инструмент управления проектами, который позже стал продуктом Basecamp, и компания полностью ушла в продукт.

Трансформация Продукт -> Сервис: Продуктовая компания сталкивается с потолком рынка или необходимостью выживания и начинает продавать экспертизу своей команды. Либо продукт становится настолько сложным (Enterprise), что требует глубокого консалтинга.

  • Пример: Компания-разработчик игр, чей собственный проект провалился, начинает делать графику или код на заказ для других студий, чтобы сохранить команду и финансирование.

Наверх

9. Инструментарий сервисных команд: обзор методов и подходов (проектное управление, Helpdesk, BPM)

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

  1. Проектное управление (Project Management):

    • Нацелено на соблюдение «железного треугольника»: Сроки, Бюджет, Скоуп (объем работ).
    • Используются стандарты (PMBOK) для формализации процессов.
    • Основная задача — сдать проект заказчику в соответствии с ТЗ.

  2. Helpdesk (Service Desk):

    • Системы обработки заявок (тикетов) от пользователей/клиентов.
    • Критически важны для этапа поддержки и сопровождения.
    • Позволяют отслеживать SLA (время реакции, время решения проблемы), контролировать загрузку поддержки и качество сервиса.

  3. BPM (Business Process Management):

    • Управление бизнес-процессами. Позволяет моделировать, автоматизировать и оптимизировать повторяющиеся процессы (например, процесс согласования договора или обработки входящей заявки).
    • Использует нотации (например, BPMN) для визуализации схем работы.
    • Цель — сделать оказание услуги стандартным, измеримым и качественным.

Наверх

10. PMI (PMBOK), Prince2, P3express – общая характеристика

Это стандарты и методологии управления проектами, часто применяемые в сервисном подходе и крупных организациях.

  1. PMI (PMBOK - Project Management Body of Knowledge):

    • Это стандарт (свод знаний), разработанный американским институтом PMI.
    • Не является жесткой методологией («делай раз, делай два»), а представляет собой энциклопедию лучших практик.
    • Описывает процессы (инициация, планирование, исполнение и т.д.) и области знаний (управление интеграцией, содержанием, сроками, стоимостью, рисками и др.).
    • Универсален, применим в любой отрасли.

  2. PRINCE2 (PRojects IN Controlled Environments):

    • Это структурированная методология (родом из Великобритании).
    • Фокусируется на обосновании бизнеса (Business Case) — проект должен быть целесообразен на любом этапе.
    • Четко определяет роли и обязанности в команде.
    • Делит проект на управляемые стадии. Очень процеcсно-ориентирован.

  3. P3express:

    • Современная, минималистичная и практичная система управления проектами.
    • Создана как упрощенная альтернатива «тяжеловесным» PMBOK и PRINCE2.
    • Легко изучается и внедряется.
    • Фокусируется на цикличности и регулярных простых шагах, делая управление проектом понятным для не-профессиональных менеджеров.

Наверх

11. Основные методологии проектного управления: Waterfall, Agile

1. Waterfall (Каскадная модель):

  • Суть: Последовательный метод, где каждый следующий этап начинается только после полного завершения предыдущего.
  • Этапы: Требования -> Проектирование -> Разработка -> Тестирование -> Внедрение -> Поддержка.
  • Особенности: Требует четкого ТЗ на старте. Изменения в процессе вносить сложно и дорого.
  • Применение: Строительство, промышленность, проекты с фиксированным бюджетом и понятным результатом (Fixed Price), где цена ошибки критична.

2. Agile (Гибкая методология):

  • Суть: Итеративный подход. Проект разбивается на короткие циклы (итерации), в конце каждого создается рабочая версия продукта.
  • Принципы (Agile Manifesto): Люди и взаимодействие важнее процессов; работающий продукт важнее документации; сотрудничество с заказчиком важнее контракта; готовность к изменениям важнее следования плану.
  • Применение: Стартапы, разработка новых продуктов, условия высокой неопределенности, когда требования меняются по ходу дела.

Наверх

12. Гибкие методы управления проектами: Scrum, Scrumban, Canban

Это фреймворки (каркасы), реализующие философию Agile.

1. Scrum:

  • Основа: Работа короткими фиксированными отрезками времени — спринтами (обычно 1-4 недели).
  • Роли: Product Owner (владелец продукта), Scrum Master (фасилитатор), Команда разработки.
  • Артефакты: Бэклог продукта (список всех задач), Бэклог спринта (план на итерацию), Инкремент (готовый кусок продукта).
  • Ритуалы: Ежедневные стендапы, Планирование спринта, Демо (обзор), Ретроспектива.
  • Цель: Поставка ценности в конце каждого спринта.

2. Kanban:

  • Основа: Визуализация потока задач и ограничение незавершенной работы (WIP — Work In Progress).
  • Инструмент: Канбан-доска (To Do -> In Progress -> Done).
  • Особенности: Нет фиксированных спринтов, задачи берутся в работу по мере освобождения ресурсов («вытягивающая» система). Главное — скорость прохождения задачи по доске (Flow).
  • Применение: Техподдержка, эксплуатация, непрерывное производство.

3. Scrumban:

  • Суть: Гибрид Scrum и Kanban.
  • Особенности: От Scrum берутся роли и ритуалы (стендапы, ретроспективы), от Kanban — визуализация, лимиты WIP и отсутствие жестких спринтов (планирование по требованию). Используется, когда Scrum слишком жесткий, а Kanban недостаточно структурирован.

Наверх

13. BPMS-системы

Понятие: BPMS (Business Process Management System) — это класс программного обеспечения для управления бизнес-процессами организации. Оно позволяет моделировать, исполнять, контролировать и оптимизировать процессы.

Задачи BPMS:

  1. Моделирование: Рисование схем процессов (обычно в нотации BPMN) в понятном графическом виде.
  2. Исполнение: Автоматическое распределение задач между сотрудниками согласно нарисованной схеме. Система сама «пинает» исполнителя.
  3. Контроль: Мониторинг сроков выполнения, поиск «узких мест» (где процесс застревает).
  4. Оптимизация: Анализ статистики и улучшение процесса на основе реальных данных.

Примеры: ELMA, Camunda, Pega. В отличие от простой автоматизации, BPMS позволяет менять логику процесса «на лету» без переписывания кода ядра системы.

Наверх

14. Инструментарий продуктовых команд: обзор методов и подходов

Инструментарий направлен на понимание пользователя и проверку гипотез (ответ на вопрос «Что делать?»).

  1. CJM (Customer Journey Map): Карта пути клиента. Визуализация взаимодействия пользователя с продуктом от возникновения потребности до покупки и использования. Помогает найти барьеры и боли клиента.
  2. User Story: Описание требований к функционалу на языке пользователя. Формат: «Как <роль>, я хочу <действие>, чтобы <ценность>».
  3. UX/UI дизайн:
    • UX (User Experience): Проектирование удобства, логики и сценариев работы.
    • UI (User Interface): Визуальное оформление (цвета, кнопки, шрифты).
  4. Сервисный дизайн: Проектирование целостного опыта обслуживания, включающее не только интерфейс, но и оффлайн-процессы, работу персонала, физическое окружение.
  5. CustDev (Customer Development): Методология создания продукта через тестирование идеи на будущих пользователях (проблемные и решенческие интервью) до начала разработки.
  6. HADI-циклы: Алгоритм проверки гипотез: Hypothesis (Гипотеза) -> Action (Действие) -> Data (Сбор данных) -> Insights (Выводы).
  7. Lean Startup (Бережливый стартап): Концепция запуска бизнеса через создание MVP, быстрое получение обратной связи и отказ от лишних трат. Цикл: «Создать — Оценить — Научиться».

Наверх

15. Понятие и предназначение Discovery-фазы (DPh). Почему она нужна/можно обойтись без нее? Элементы DPh

Понятие: Discovery-фаза — это предварительный этап проекта, направленный на сбор информации, анализ требований и снижение неопределенности перед стартом разработки.

Предназначение:

  • Зафиксировать Scope (границы проекта): что делаем, а что нет.
  • Получить реалистичную оценку сроков и бюджета.
  • Минимизировать риски (технические и бизнесовые).
  • Синхронизировать видение заказчика и команды.

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

Элементы Discovery-фазы:

  1. Постановка бизнес-целей: Сбор требований, определение KPI успеха.
  2. Исследование рынка и ЦА: Кто клиент? Конкуренты? User Stories.
  3. Проработка решения:
    • Верхнеуровневая архитектура.
    • Прототипы UX/UI.
    • Выбор технологического стека.
    • План работ (Roadmap) и смета.

Наверх

16. Proof of Concept: понятие и цель. Может ли PoC заменить MVP?

Понятие: Proof of Concept (PoC, «Доказательство концепции») — это проверка практической осуществимости определенного метода, идеи или технологии. Это черновой вариант или макет, который создается не для продажи, а для внутреннего исследования.

Цель: Дать однозначный ответ на вопросы:

  • Технически реализуема ли эта идея?
  • Будет ли это работать так, как задумано?
  • Насколько сложной и дорогой будет реализация?
  • Пример: Перед созданием сложного ИИ-сервиса разработчики пишут скрипт, чтобы проверить, сможет ли алгоритм вообще распознать нужные данные.

Может ли PoC заменить MVP? Нет, не может. Это разные инструменты для разных стадий:

  1. PoC проверяет техническую возможность (feasibility). Это исследование «в стол», часто код PoC выбрасывается.
  2. MVP проверяет рыночную востребованность (viability). Это продукт, которым пользуются реальные люди. PoC отвечает на вопрос «Можем ли мы это сделать?», а MVP — «Нужно ли это кому-то?»

Наверх

17. CustDev, Lean CustDev – сущность методик, их этапы

CustDev (Customer Development): Методология, разработанная Стивом Бланком. Суть заключается в том, что продукт нужно создавать, опираясь на постоянную обратную связь от потенциальных клиентов, а не на галлюцинации основателей. «Выйди из офиса и спроси клиента».

Lean CustDev: Это «бережливая» версия методики (популяризирована Синди Альварес). Акцент делается на скорости проверки гипотез с минимальными затратами ресурсов, часто без создания продукта (на этапе интервью).

Этапы классического CustDev:

  1. Customer Discovery (Выявление потребителей): Формулирование гипотез о проблеме и клиенте. Проведение проблемных интервью. Понимание, есть ли боль.
  2. Customer Validation (Верификация потребителей): Попытка продать решение (или MVP) первым клиентам (ранним последователям). Подтверждение того, что бизнес-модель работает.
  3. Customer Creation (Привлечение потребителей): Масштабирование продаж, когда ценность подтверждена.
  4. Company Building (Создание компании): Переход от стартапа к структурированной компании.

Первые два этапа — это поиск бизнес-модели, вторые два — ее реализация.

Наверх

18. UX/UI дизайн

Это два взаимосвязанных этапа проектирования интерфейсов.

1. UX (User Experience — Пользовательский опыт):

  • Суть: Проектирование того, как пользователь будет взаимодействовать с системой. Это про логику, удобство, архитектуру и сценарии.
  • Задачи: Исследование пользователей, создание прототипов (wireframes), разработка информационной архитектуры, тестирование юзабилити.
  • Результат: Понятный и удобный интерфейс, решающий задачу пользователя.

2. UI (User Interface — Пользовательский интерфейс):

  • Суть: Визуальное оформление продукта. Это про внешний вид, эстетику и эмоциональный отклик.
  • Задачи: Подбор цветов, шрифтов, иконок, отрисовка кнопок, анимация, создание гайдлайнов.
  • Результат: Красивый и целостный визуальный стиль.

Связь: Сначала прорабатывается UX (скелет), затем на него «натягивается» UI (кожа).

Наверх

19. Customer Journey Map (CJM)

Понятие: CJM (Карта пути клиента) — это визуализация истории взаимодействия клиента с продуктом/компанией от момента возникновения потребности до покупки, использования и ухода.

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

Основные элементы CJM:

  1. Персона: Чей путь мы описываем (портрет целевого клиента).
  2. Этапы: Осознание потребности -> Поиск -> Выбор -> Покупка -> Использование -> Поддержка.
  3. Точки контакта: Сайт, приложение, звонок менеджера, курьер, email.
  4. Действия клиента: Что он делает на каждом этапе.
  5. Боли и барьеры: Что мешает или раздражает клиента.
  6. Эмоции: График эмоционального состояния (радость/фрустрация).

Наверх

20. UX/UI дизайн, Сервисный дизайн

Вопрос подразумевает сравнение этих понятий, так как они часто путаются.

UX/UI дизайн:

  • Фокус: Цифровые точки контакта (экран смартфона, веб-сайт, интерфейс терминала).
  • Объект: Приложение или сайт.
  • Границы: Ограничен взаимодействием человека и устройства (Human-Computer Interaction).

Сервисный дизайн (Service Design):

  • Фокус: Целостный опыт клиента (Omnichannel) + внутренние процессы компании.
  • Объект: Услуга в целом.
  • Границы: Включает в себя UX/UI, но выходит за его пределы. Охватывает офлайн-процессы, работу персонала, физическое окружение, логистику.
  • Пример:
    • UX/UI: Сделать удобную кнопку «Заказать такси» в приложении.
    • Сервисный дизайн: Продумать, чтобы такси приехало чистым, водитель был вежлив, оплата прошла незаметно, а в случае забытых вещей сработала служба поддержки.

Сервисный дизайн проектирует не только то, что видит клиент (фронстейдж), но и то, как работают сотрудники компании (бекстейдж), чтобы этот сервис обеспечить.

Наверх

21. HADI-циклы

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

Этапы цикла:

  1. Hypothesis (Гипотеза): Формулирование предположения. Пример: «Если мы изменим цвет кнопки "Купить" на красный, конверсия вырастет на 5%».
  2. Action (Действие): Реализация изменений для проверки гипотезы. Делаем это максимально быстро и дешево (MVP).
  3. Data (Сбор данных): Измерение показателей за определенный период.
  4. Insights (Выводы): Анализ полученных данных. Гипотеза подтвердилась — масштабируем решение. Не подтвердилась — отказываемся и формулируем новую.

Наверх

22. User story и UX – определите связи между понятиями, если таковые существуют. Использование критериев INVEST в User Story

Связь User Story и UX:

  • User Story (Пользовательская история) описывает потребность и ценность («ЧТО нужно пользователю и ЗАЧЕМ»). Это входные данные для дизайна.
  • UX (User Experience) проектирует решение («КАК пользователь это получит»).
  • Связь: User Story является фундаментом для UX-дизайна. Дизайнер берет историю (например, «Я хочу быстро оплатить заказ») и превращает ее в интерфейсное решение (сценарий оплаты в один клик). Без User Story UX-дизайн не имеет контекста и цели.

Критерии INVEST: Это мнемоническое правило для проверки качества User Story. Хорошая история должна быть:

  • Independent (Независимая) — ее можно реализовать отдельно от других.
  • Negotiable (Обсуждаемая) — это не жесткое ТЗ, а тема для обсуждения с командой.
  • Valuable (Ценная) — приносит пользу клиенту или бизнесу.
  • Estimable (Оцениваемая) — команда может оценить трудоемкость.
  • Small (Компактная) — можно сделать за одну итерацию (спринт).
  • Testable (Тестируемая) — имеет критерии приемки (Definition of Done).

Наверх

23. 5 Почему – цель использования и примеры

Цель: Техника поиска корневой причины проблемы (Root Cause Analysis). Позволяет не бороться с симптомами, а устранить источник дефекта. Часто используется в методологиях Бережливого производства (Lean) и Шесть Сигм.

Алгоритм: Задавать вопрос «Почему?» к каждому ответу, пока не будет найдена первопричина (обычно хватает 5 итераций).

Пример (IT-сфера):

  1. Проблема: Сервер упал. Почему?
  2. Закончилась оперативная память. Почему?
  3. Скрипт не очищал кэш. Почему?
  4. Разработчик допустил ошибку в цикле. Почему?
  5. Корневая причина: В компании нет процедуры Code Review (проверки кода), и ошибку никто не заметил. Решение: Внедрить Code Review, а не просто перезагрузить сервер.

Наверх

24. TCO: понятие и предназначение

Понятие: TCO (Total Cost of Ownership / Совокупная Стоимость Владения) — это методика расчета всех затрат на информационную систему (ИС) на протяжении всего ее жизненного цикла: от момента покупки/разработки до вывода из эксплуатации.

Формула (упрощенно): TCO = Прямые затраты (CAPEX) + Косвенные/Эксплуатационные затраты (OPEX)

Предназначение:

  1. Выявление скрытых затрат: Прямые расходы (покупка ПО и железа) составляют лишь 20-30%, остальные 70-80% — это скрытые расходы на поддержку, простои и обучение.
  2. Сравнение решений: Позволяет выбрать между «дешевым при покупке, но дорогим в обслуживании» и «дорогим, но экономичным» решением.
  3. Обоснование бюджета: Помогает IT-директору доказать необходимость финансирования не только закупки, но и поддержки.

Наверх

25. Разнообразие подходов к расчету TCO

Единого стандарта нет, разные компании предлагают свои методики акцентирования внимания на разных типах затрат.

  1. Модель Gartner Group:

    • Самая популярная.
    • Главный акцент на косвенных затратах, особенно на «Активности пользователя» (скрытые расходы, когда сотрудники сами чинят свои ПК, помогают коллегам, учатся методом тыка — так называемый Futz-фактор).
    • Делит затраты на фиксированные (капитальные) и текущие.

  2. Модель Microsoft / Interpose:

    • Четкое разделение на Прямые (бюджетируемые: железо, софт, зарплата админов) и Косвенные (небюджетируемые: простои системы, пользовательские затраты).
    • Акцент на том, что снижение прямых затрат (например, урезание бюджета поддержки) часто ведет к взрывному росту косвенных (простои).

  3. Методика для российских предприятий (Хубаев, Родина):

    • Адаптация западных моделей под реалии РФ (специфика бухучета, налогов).
    • Предлагает методику ПУЗ-ОХР (Пошаговое Упорядочение Затрат), использующую экспертные оценки и имитационное моделирование для расчета затрат в условиях нехватки статистики.

Наверх

26. Различие CAPEX / OPEX

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

1. CAPEX (Capital Expenditure — Капитальные затраты):

  • Суть: Единовременные расходы на приобретение или модернизацию внеоборотных активов (имущества, которое служит более 1 года).
  • В IT это: Покупка серверов, строительство ЦОД, покупка бессрочных лицензий на ПО, разработка собственного софта (постановка на баланс).
  • Финансы: Деньги тратятся сразу, но в расходах (в отчете о прибылях и убытках) сумма списывается частями через амортизацию на протяжении нескольких лет.
  • Цель: Инвестиции в будущее, расширение активов.

2. OPEX (Operational Expenditure — Операционные затраты):

  • Суть: Регулярные расходы, необходимые для повседневного ведения бизнеса.
  • В IT это: Аренда облачных серверов (AWS, Azure), подписка на SaaS-сервисы (ежемесячная оплата), зарплата IT-штата, оплата интернета и электричества, ремонт техники.
  • Финансы: Списываются в расходы полностью в том периоде, когда они возникли. Уменьшают налогооблагаемую базу (прибыль) «здесь и сейчас».
  • Цель: Поддержание текущей деятельности.

Тенденция: Современный IT-рынок смещается от модели CAPEX (купить сервер) к модели OPEX (арендовать мощность в облаке), так как это дает гибкость.

Наверх

27. Понятие и типы CF

Понятие: CF (Cash Flow — Денежный поток) — это реальное движение денежных средств компании за определенный период. Это разница между всеми поступлениями и выплатами.

  • Важно: CF ≠ Прибыль. Прибыль — это бухгалтерский показатель (на бумаге), а CF — это фактическое наличие денег на счетах («кэш»).

Типы денежных потоков (в контексте инвестиционного анализа):

  1. CIF (Cash Inflow): Поток поступлений (доходы от проекта).
  2. COF (Cash Outflow): Поток платежей (расходы, инвестиции).
  3. NCF (Net Cash Flow): Чистый денежный поток = CIF - COF.
  4. Discounted CF (Дисконтированный денежный поток): Денежный поток, скорректированный с учетом фактора времени (стоимости денег). Будущие деньги стоят дешевле сегодняшних. Используется для расчета NPV.

Наверх

28. Основные показатели эффективности IT-проекта и их интерпретация

Эти показатели рассчитываются на основе дисконтированных денежных потоков для принятия решения: запускать проект или нет.

  1. NPV (Net Present Value — Чистый дисконтированный доход):

    • Суть: Сумма всех будущих доходов, приведенная к текущей стоимости, минус инвестиции. Показывает, сколько реальных денег принесет проект сверх вложений.
    • Интерпретация:
      • NPV > 0 — Проект прибыльный, можно брать.
      • NPV < 0 — Проект убыточный, отвергаем.
      • NPV = 0 — Проект окупится, но прибыли не принесет.

  2. IRR (Internal Rate of Return — Внутренняя норма доходности):

    • Суть: Процентная ставка, при которой NPV проекта равен 0. Это «запас прочности» проекта.
    • Интерпретация: Сравнивается с банковской ставкой или стоимостью капитала компании. Если IRR > Ставки депозита — деньги выгоднее вложить в проект, чем положить в банк.

  3. ROI (Return on Investment — Коэффициент возврата инвестиций):

    • Суть: Соотношение полученной прибыли к вложенным средствам (в процентах).
    • Интерпретация: Чем выше, тем эффективнее работают вложенные деньги.

  4. PBP (Payback Period — Срок окупаемости):

    • Суть: Время, которое требуется, чтобы доходы покрыли расходы.
    • Интерпретация: Чем короче срок, тем ниже риски и выше ликвидность проекта.

Наверх

29. Основные этапы планирования TCO

Планирование Совокупной Стоимости Владения необходимо для понимания реальной цены IT-решения, а не только цены «на ценнике».

Этапы:

  1. Идентификация затрат: Определение «видимых» (прямых) и «невидимых» (косвенных) расходов.
  2. Определение косвенных потерь: Прогнозирование затрат на простои системы, самообучение пользователей, снижение производительности.
  3. Классификация (Статьи затрат): Распределение расходов по категориям (оборудование, ПО, персонал, аутсорсинг, коммуникации).
  4. Расчет показателей: Использование методик (Gartner, Interpose) или калькуляторов для получения итоговой цифры.
  5. Анализ и оптимизация: Выделение самых «тяжелых» статей расходов (обычно это поддержка и простои) и поиск инструментов для их снижения (например, стандартизация ПО, обучение персонала).

Наверх

30. Матрица RACI

Понятие: Матрица RACI (Матрица ответственности) — это инструмент распределения ролей и полномочий в проекте или процессе. Она помогает избежать путаницы («кто за что отвечает») и ситуаций, когда задачу делают двое или не делает никто.

Расшифровка ролей (аббревиатура):

  • R — Responsible (Исполнитель): Тот, кто непосредственно выполняет работу (пишет код, рисует дизайн). Может быть несколько человек.
  • A — Accountable (Ответственный): Тот, кто принимает работу и несет конечную ответственность за результат (головой). Важно: У каждой задачи может быть только один Accountable.
  • C — Consulted (Консультант): Эксперт, чье мнение спрашивают до или во время работы. С ним ведут двустороннюю коммуникацию.
  • I — Informed (Информируемый): Тот, кого ставят в известность о результатах (например, стейкхолдер). Односторонняя коммуникация.

Пример: В задаче «Разработка макета сайта»: Дизайнер — R, Арт-директор — A, Разработчик — C (спросить, реально ли это сверстать), Клиент — I (получает готовый макет).

Наверх

31. Модель COCOMO. Ее виды. Метрики модели

Понятие: COCOMO (COnstructive COst MOdel) — это алгоритмическая модель оценки стоимости и трудоемкости разработки программного обеспечения, разработанная Барри Боэмом в 1981 году.

Метрика модели: Основная единица измерения размера — KLOC (Kilo Lines of Code / Тысячи строк исходного кода). Также используются DSI (Deliverable Source Instructions — исходные поставляемые команды).

Виды (уровни) модели COCOMO-81: Модель предлагает три уровня детализации для разных этапов оценки:

  1. Базовая (Basic): Быстрая, грубая оценка на ранних стадиях. Расчитывает трудоемкость только как функцию от размера программы (KLOC).
  2. Промежуточная (Intermediate): Более точная. Учитывает размер программы + 15 факторов стоимости (Cost Drivers), таких как надежность ПО, сложность продукта, опыт персонала и т.д.
  3. Детальная/Углубленная (Advanced): Оценивает влияние факторов стоимости на каждом этапе жизненного цикла (анализ, проектирование, кодирование и т.д.) отдельно.

Наверх

32. Модель COCOMO II. Ее виды. Метрики модели

Понятие: COCOMO II — это обновленная версия модели (представлена в 2000 г.), адаптированная к современным методологиям разработки (не только каскадной, но и спиральной, итеративной) и новым технологиям (визуальное программирование, повторное использование кода).

Виды (стадии) модели COCOMO II: Модель предлагает три стадии оценки, соответствующие ходу развития проекта:

  1. Модель композиции приложения (Application Composition Model — ACM):
    • Когда: На самых ранних стадиях (прототипирование).
    • Метрика: Object Points (Объектные точки) — количество экранов, отчетов, модулей 3GL.
  2. Модель раннего этапа проектирования (Early Design Model — EDM):
    • Когда: Архитектура уже прорабатывается, но деталей нет.
    • Метрика: Function Points (Функциональные точки), пересчитанные в KLOC.
    • Параметры: Использует 5 факторов масштаба и упрощенный набор из 7 факторов затрат.
  3. Постархитектурная модель (Post-Architecture Model — PAM):
    • Когда: На этапе детальной разработки и поддержки.
    • Метрика: KLOC (Строки кода) или FP.
    • Параметры: Использует 5 факторов масштаба и полный набор из 17 факторов затрат.

Ключевые множители модели:

  • Факторы масштаба (Scale Factors, $W_i$): Определяют нелинейность роста затрат (экономия или перерасход при росте масштаба). Их 5: Прецедентность (опыт), Гибкость разработки, Архитектура/Риски, Сплоченность команды, Зрелость процессов (CMM).
  • Факторы затрат (Cost Drivers, $EM$): Множители трудоемкости (квалификация персонала, сложность платформы, требуемая надежность и др.).

Наверх

33. COSYSMO: понятие и применение. Факторы масштаба и затрат в модели COSYSMO

Понятие: COSYSMO (COnstructive SYStems Engineering Cost MOdel) — это модель для оценки трудоемкости системной инженерии. В отличие от COCOMO, которая считает затраты на написание кода, COSYSMO считает затраты на спецификацию требований, разработку архитектуры, тестирование и проектирование системы в целом.

Применение: Используется для крупных программно-аппаратных проектов (военная промышленность, авиация) и базируется на стандарте ISO/IEC 15288.

Факторы масштаба (Драйверы размера) в COSYSMO: В этой модели размер проекта определяется не строками кода, а четырьмя параметрами:

  1. Количество системных требований (Requirements): Сколько требований нужно реализовать/протестировать.
  2. Количество системных интерфейсов (Interfaces): Внутренние и внешние связи системы.
  3. Количество алгоритмов (Algorithms): Уникальные математические или логические задачи.
  4. Количество операционных сценариев (Scenarios): Сценарии использования (Use Cases).

Факторы затрат (Cost Drivers): Модель включает 14 множителей, влияющих на трудоемкость (например, Понимание требований, Сплоченность команды, Уровень инструментальной поддержки, Технологический риск и др.).

Наверх

34. 6 сигм для ПО

Понятие: Шесть Сигм (Six Sigma) — это методология управления качеством, нацеленная на минимизацию отклонений и дефектов в процессах.

  • Цель: Достичь уровня качества, при котором на миллион возможностей возникает не более 3,4 дефекта (уровень 6 сигм).

Принципы для IT:

  1. Ориентация на пользователя (качество — это то, что нужно клиенту).
  2. Решения на основе данных (Data-driven), а не интуиции.
  3. Процессный подход.

Жизненный цикл проекта (Метод DMAIC): Это алгоритм улучшения существующего процесса:

  1. D — Define (Определяй): Описание проблемы и целей. Что мы хотим улучшить?
  2. M — Measure (Измеряй): Сбор данных о текущей ситуации. Сколько багов сейчас? (Расчет уровня сигм).
  3. A — Analyze (Анализируй): Поиск корневых причин дефектов. Почему они возникают?
  4. I — Improve (Совершенствуй): Внедрение решений для устранения причин дефектов.
  5. C — Control (Проверяй/Контролируй): Мониторинг, чтобы улучшения закрепились и проблема не вернулась.

Команда: Используется ролевая модель из восточных единоборств (Зеленые пояса, Черные пояса) для обозначения уровня экспертизы в методике.

Наверх

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment