Квалификация команды для заказной разработки
Почему «квалификация» — часть экономики
Заказной проект чаще срывают люди и процессы, чем «не та версия библиотеки»: архитектор не согласовал границы с заказчиком, аналитик не умеет оформить ТЗ под ГОСТ, QA не строит трассировку к ПМИ. В COCOMO II это напрямую отражается в множителях PCAP (программисты), ACAP (аналитики), LTEX (опыт языка) — см. статью COCOMO.
Глава 1.2 учебника про подготовку коллектива — про минимальный набор компетенций для производства сложного заказного комплекса программ.
Рынок труда и вилки — в карьерном разделе. Здесь — профессиональные требования к ролям в контрактной разработке.
Мини-глоссарий ролей
| Роль | Аббревиатура | Главная ответственность |
|---|---|---|
| Руководитель проекта | PM | Срок, бюджет, контракт, коммуникация |
| Бизнес-аналитик | BA | Процесс, ценность, приоритеты |
| Системный аналитик | SA | ТЗ, API, NFR, трассировка |
| Архитектор | — | Целостность, NFR, технологии |
| Tech lead | — | Модуль/сервис внутри архитектуры |
| QA / инженер по качеству | — | Тесты, ПМИ, доказательства качества |
| Технический писатель | — | ТЗ, ПМИ, руководства |
Заинтересованные лица и «перевод» требований
Перед набором команды фиксируют stakeholders (заинтересованные лица) и кто переводит их язык в требования (116):
| Stakeholder | Что важно | Кто «переводит» |
|---|---|---|
| Заказчик-бизнес | ROI, сроки, отчётность | PM, BA |
| ИТ-заказчик | Интеграции, эксплуатация | SA, architect |
| Регулятор / ИБ | Соответствие нормам | SA, security, tech writer |
| Конечные пользователи | Удобство, ошибки | BA, UX, QA |
| Поддержка после сдачи | Runbook, логи | DevOps, SA |
Подготовка коллектива начинается с общего понимания: кто принимает решения, что считается успехом, какой baseline сдаём на приёмке.
Руководитель проекта (PM)
Без чего заказной проект буксует:
- ведение контракта: этапы, change request, акты, претензии;
- риск-менеджмент (срок, бюджет, scope);
- коммуникация с не-IT заказчиком (без жаргона или с глоссарием);
- понимание SDLC и границ Agile vs этапов по контракту.
Ориентир квалификации: опыт Fixed Price / госконтрактов; термины PMBOK или PRINCE2; умение читать ТЗ и ПМИ и проверять, что команда им следует.
| Уровень | Ожидание |
|---|---|
| Junior PM | Ведёт задачи под сеньором, знает артефакты |
| Middle | Ведёт этап, CR, риски |
| Senior | Контракт целиком, эскалации, переговоры по scope |
Подробнее — Основы управления IT-проектами.
Архитектор / ведущий проектировщик
Отвечает за целостность комплекса программ:
- границы подсистем, NFR, технологический стек;
- декомпозиция и reuse (103);
- ADR (Architecture Decision Record) — почему выбрали Kafka, а не RabbitMQ;
- оценка сложности для COCOMO / планирования.
Ошибка архитектора — одна из самых дорогих: переделка интеграций и данных после подписания ТЗ.
| Компетенция | Зачем на заказном проекте |
|---|---|
| Чтение ТЗ и контракта | Не обещать невозможное в архитектуре |
| Интеграции и legacy | 80% рисков — на стыках |
| Безопасность и 25010 | Security-by-design, а не «допилим перед приёмкой» |
Аналитики (BA / SA)
| Роль | Фокус | Для заказного ПО обязательно |
|---|---|---|
| BA | Бизнес-процесс, ценность | Интервью, BPMN, приоритеты, согласование сценариев |
| SA | Техническая спецификация | ТЗ/спецификация, API, трассировка, NFR с цифрами |
Типичная ошибка новичка-SA: описать экраны, но не критерии приёмки и не связать с ПМИ.
Подготовка: аналитика, ТЗ по ГОСТ.
Разработчики (конструирование)
Нужно больше, чем синтаксис языка:
- модульность, связность/сцепление;
- unit-тесты, code review, SCM;
- чтение чужого кода и легаси;
- контракты между компонентами комплекса (API, события).
Для компонентов сложного комплекса выделяют tech lead модуля — мини-архитектор внутри сервиса.
| Сигнал «команда не готова» | Последствие |
|---|---|
| Нет code review | Дефекты на приёмке |
| Нет автотестов на критичном | Дорогое сопровождение |
| «Пишем только по ТЗ, NFR не наше» | Провал нагрузки/ИБ на приёмке |
QA / инженеры по качеству
- тест-дизайн, уровни 111;
- трассировка ТЗ → тест → протокол;
- white-box на критичных модулях;
- участие в приёмочных и сертификации;
- умение читать NFR и строить нагрузочные/негативные сценарии.
На заказном проекте QA — партнёр по доказательствам, а не «отдел в конце».
Технические писатели
На заказном проекте с ГОСТ — обязательная роль:
- ТЗ, ПМИ, руководства (7-08);
- синхронизация версий с SCM;
- единый стиль терминов с глоссарием.
Разработчик «накидает README» не заменяет комплект для приёмки.
Организатор производства (глава 1.2)
Роль близка к Release manager / PMO:
- план PERT/CPM;
- координация подрядчиков;
- CMMI-подобные процессы (SDLC);
- календарь базовых линий и релизов.
Как готовить коллектив к проекту — чек-лист
- Kick-off с заказчиком — цели, stakeholders, критерии приёмки, перечень артефактов.
- Обучение домену — финансы, медицина, телеком (2–4 недели погружения: глоссарий, регламенты).
- Единый глоссарий — термины RU/EN, чтобы ТЗ и код говорили одним языком.
- Пилот процессов — SCM, CI, шаблоны ТЗ/ПМИ до массового кода.
- Парное усиление — senior + middle на критичных модулях и на первых CR.
- Ретроспектива компетенций — чего не хватило на первом релизе (не только «что бесило в спринте»).
Красные флаги перед стартом контракта
| Флаг | Риск |
|---|---|
| Нет SA с опытом ГОСТ-ТЗ | Переделка документов, срыв приёмки |
| Нет архитектора на интеграциях | Взрыв сроков на стыках |
| QA подключают за неделю до акта | Формальная приёмка с сюрпризами |
| Один «звезда» знает систему | Bus factor = 1 |
Матрица «роль — артефакт — глава курса»
| Роль | Ключевой артефакт | Глава учебника |
|---|---|---|
| Architect | Архитектура, NFR, ADR | 1.1, 1.3 |
| BA/SA | ТЗ, трассировка | 1.2, 1.3 |
| PM | План, бюджет, акты | 1.5–1.6, 2.4 |
| Developer | Код, unit-тесты | 2.1, 2.3 |
| QA | ПМИ, протоколы | 2.2–2.5, 2.8 |
| Tech writer | Эксплуатационная док. | 2.7 |
| DevOps / RM | CI, baseline, релиз | 2.7, 2.4 |
Связь квалификации с оценкой трудозатрат
| Слабое звено | В COCOMO II | На практике |
|---|---|---|
| Новички на платформе | ↑ LTEX, PLEX | +30–50% к сроку модуля |
| Слабые аналитики | ↑ ACAP, PCON | Переделка ТЗ |
| Разрозненная команда | ↑ TEAM, SITE | Потери на согласованиях |
| Зрелые процессы | ↓ PMAT, TOOL | Меньше брака на приёмке |
Инвестиция в подготовку коллектива окупается меньшим PM и одной приёмкой вместо двух.
Куда читать дальше
| Тема | Материал |
|---|---|
| Команда и роли | 7-02/11 |
| Оценка с учётом людей | COCOMO II |
| Приёмка | Сертификация и приёмка |
| Маршрут курса | intro |
См. также
Другие статьи этого же раздела в боковом меню (как на странице «О разделе»). На совещании вы слышите: «эта фича — 8 story points». Это работает внутри команды, когда все знают прошлые спринты. Восемь характеристик качества ПО простым языком: что писать в ТЗ, как проверять на приёмке и почему «без багов» — мало. SCM простым языком: конфигурационные единицы, baseline, контроль изменений и связь с Git, CI/CD и ГОСТ-документацией. Что происходит с заказным ПО после акта приёмки: виды сопровождения, SLA, экономика и типичные ошибки — простым языком. Что такое системы реального времени, чем hard RT отличается от веба, как формулировать требования и тестировать на стенде — для новичка. Испытания, удостоверение качества и сертификация — простым языком: ПМИ, акт приёмки, ФСТЭК и что закладывать в смету.Модель COCOMO II — прогноз трудоёмкости и стоимости
Модель качества ISO/IEC 25010
Управление конфигурацией программных комплексов
Сопровождение программных комплексов
Заказные системы реального времени
Сертификация и приёмка заказных программных продуктов