План команды и штатной структуры (team and staffing plan) — каноничная модель ролей и роста команды

Версия: 1.0 Дата: 27.04.2026 Статус: Готов к обсуждению

Назначение документа

Этот документ задаёт каноничную модель команды и штатной структуры платформы Vitiana — какие роли нужны, в какой момент появляются, какие responsibilities несут. Документ не календарный hiring plan и не job descriptions — это архитектура команды, согласованная с development roadmap и operational maturity.

Документ построен по тем же принципам, что и roadmap.md: роли появляются по триггерам стадий, не по календарю; ответственности caпсулируются по execution contours и доменам, согласованно с documentation-governance.md; рост команды — управляемый, не реактивный.

Документ не фиксирует:

• конкретные имена сотрудников;
• конкретные salary ranges;
• юридические формы найма (full-time / contractor / agency);
• календарные даты найма каждой роли;
• конкретные tools для подбора (это операционная задача HR).

Документ фиксирует:

• архитектуру ролей (что роль делает и за что отвечает);
• триггеры появления каждой роли (когда роль становится критичной);
• связь ролей с execution contours, доменами, operational pillars;
• модель роста команды по стадиям;
• принципы организационного дизайна.

Тезисное обоснование

Тезис 1. Команда растёт по триггерам, не по календарю.

Альтернативы: (а) фиксированный календарный hiring plan на 12 месяцев; (б) hiring под текущую загрузку (реактивный); (в) hiring по триггерам стадий зрелости.

Trade-off: вариант (а) приводит к найму ролей, которые не нужны на текущей стадии (premature hiring), или к отсутствию ролей, которые стали критичны раньше плана; вариант (б) приводит к burnout существующей команды до того, как hiring завершится; вариант (в) — hiring запускается при достижении триггера (например, появление tenant Enterprise → hiring SRE; SLA Professional 99% → hiring второго on-call engineer; 50+ partner integrations → hiring partner success manager). Это согласовано со stages model в roadmap.md и принципом «развитие без деградации».

Тезис 2. Роли capсулируются по execution contours и доменам, не по «функциональным колодцам».

Альтернативы: (а) функциональная организация (frontend team, backend team, ops team, QA team); (б) feature-team организация (cross-functional teams per feature); (в) domain-team организация (cross-functional teams per execution contour / domain).

Trade-off: вариант (а) приводит к Conway's law противоречию — архитектура декомпозирована по доменам, а команды по функциям, что создаёт постоянные cross-team coordination tax; вариант (б) хорош для продуктовой работы, но плохо масштабируется на платформенный уровень (общие компоненты не имеют owner); вариант (в) — каноничный pattern платформ верхнего уровня (Stripe, Twilio, Algolia): команда по execution contour несёт E2E ответственность от domain model до production operations. Это масштабируется и согласовано с documentation-governance.md (каждый domain owner — представитель domain team).

Тезис 3. Operational maturity требует separate roles от core engineering на стадии 4+.

Альтернативы: (а) core engineers делают operations on rotation; (б) полный outsourcing operations (managed services провайдер); (в) dedicated SRE / Platform / Security teams с фазы 4.

Trade-off: вариант (а) работает на стадиях 0–3 (small team, owners-on-call), но не масштабируется на 99.9% Enterprise SLA; вариант (б) дёшев, но создаёт зависимость от внешнего вендора и увеличивает MTTR; вариант (в) — dedicated SRE/Platform/Security как separate ownership с фазы 4 — каноничный pattern для production-capable платформ. Это согласовано с sla-and-on-call-model.md (5-уровневая on-call structure требует resourcing) и disaster-recovery-and-capacity.md (DR drills требуют dedicated owner с фазы 3+).

Тезис 4. Compliance и legal — first-class роли с фазы 3, не «через юр. фирму ad-hoc».

Альтернативы: (а) compliance через внешнюю юридическую фирму ad-hoc; (б) compliance совмещается с CTO/CEO до стадии 5; (в) dedicated compliance officer с фазы 3 (controlled external beta).

Trade-off: вариант (а) дешёв, но не реактивен на регуляторные изменения и приводит к compliance gaps; вариант (б) работает на bootstrap, но не выдерживает регуляторного давления при выходе в EU broader (GDPR / PSD2 / EU TOMS / Package Travel Directive); вариант (в) — каноничный pattern для travel/financial платформ с регулируемыми юрисдикциями. Compliance officer координирует с внешними юристами, но владеет процессами и документами как ownership.

Тезис 5. Партнёрский success — first-class функция с фазы 3, не «sales делает».

Альтернативы: (а) partner success — часть sales/business team; (б) partner success через support tickets без proactive engagement; (в) dedicated partner success team с фазы 3.

Trade-off: вариант (а) приводит к подмене retention growth-метриками (sales фокусируется на новых, не на existing); вариант (б) реактивен и приводит к partner churn; вариант (в) — partner success как proactive function (onboarding, certification, technical advisory, retention) — каноничный pattern для B2B platforms (Stripe Connect Partner Success, Twilio Customer Success). Согласовано с api-as-product.md — partner lifecycle требует ownership.

Главные принципы организационного дизайна

Принцип 1. Domain ownership = code ownership = documentation ownership

Каждый каноничный domain имеет owner, который:

• ведёт canonical document (см. documentation-governance.md);
• владеет кодом domain (review approver);
• участвует в on-call rotation для domain incidents.

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

Принцип 2. Cross-functional ownership внутри domain team

Domain team — cross-functional unit:

• Engineering (backend, infrastructure-as-code, тестирование);
• Domain expertise (бизнес-логика, regulatory awareness);
• Operations (on-call ownership для domain incidents).

С фазы 4 domain teams могут быть усилены dedicated SRE и frontend engineers.

Принцип 3. Platform team — shared infrastructure для всех domain teams

Platform team предоставляет общие сервисы (deployment infrastructure, observability stack, identity, eventing, search, ML, A/B), которые domain teams потребляют как infrastructure. Этот pattern предотвращает дублирование и обеспечивает consistency.

С фазы 5 Platform team декомпозируется на:

• Infrastructure & DevOps;
• Observability & Reliability (SRE);
• Identity & Tenancy;
• Eventing & Data Platform.

Принцип 4. Dual reporting — для cross-cutting roles

Cross-cutting roles (compliance officer, security lead, data protection officer) имеют dual reporting:

• functional reporting в CTO / COO;
• domain coordination со всеми domain teams.

Это исключает изоляцию и обеспечивает влияние на cross-cutting concerns во всех доменах.

Принцип 5. Hire ahead of triggers, not after

Hiring запускается до достижения триггера, не после. Lead time на hiring senior engineer — 8–16 недель; lead time на specialist (SRE, compliance) — 12–24 недели. Поэтому при появлении leading indicator triggers hiring немедленно, не ждёт hardening trigger.

Правило: при достижении 70% triggers стадии — открыть позиции для ролей следующей стадии.

Принцип 6. Партнёрское доверие требует non-junior ownership

Роли, отвечающие за partner-facing surfaces (partner success, integration architects, customer success), не могут быть junior-only. Партнёры (особенно Enterprise) требуют seniority в communication и technical depth. Junior engineers могут поддерживать, не вести.

Принцип 7. Burnout protection — обязательный constraint hiring

Команда не может работать стабильно при on-call burden более 1 недели в месяц per engineer (см. sla-and-on-call-model.md). Это hard constraint hiring — при увеличении on-call workload до этого предела hiring следующего engineer становится обязательным, не «когда найдём».

Структура команды по стадиям зрелости

Команда растёт по 7 стадиям, согласованным с roadmap.md (стадии 0–6).

Стадия 0 — Архитектурный baseline (1–3 человека)

Главная задача: собрать каноничную архитектуру и документы.

Каноничные роли:

• Главный архитектор / CTO (1) — owner архитектурной оси, утверждает каноничные документы, эскалация развилок;
• (опционально) Senior platform engineer (1) — sparring partner для архитектора, подготовка implementation breakdown;
• (опционально) Documentation contributor (1, contractor) — помощь в обширной документной работе.

Что не нанимается на стадии 0:

• engineering team полного состава (преждевременно);
• operations roles (нет production);
• partner-facing roles (нет партнёров);
• compliance / legal (нет регулируемых операций).

Триггер выхода: все каноничные документы Фаз 0–6 опубликованы, документная governance зафиксирована.

Стадия 1 — Implementation baseline (4–8 человек)

Главная задача: перевести архитектуру в executable design, собрать первый production-capable execution contour.

Каноничные роли:

• Главный архитектор / CTO (1) — продолжает (без него core невозможен);
• Engineering Manager / Tech Lead (1) — operational lead для команды;
• Senior backend engineers (2–3) — owners первых execution contours (transactional + commercial + ingestion);
• Senior frontend engineer (1) — owner agency Surface 2 + internal Surface 1 prototypes;
• DevOps / Infrastructure engineer (1) — Phase 1 infrastructure (OVHcloud), CI/CD;
• (опционально) QA engineer (1) — для критических paths (booking, payment).

Что не нанимается на стадии 1:

• product manager (главный архитектор + tech lead покрывают);
• dedicated SRE (DevOps engineer покрывает);
• partner success (нет партнёров);
• ML / data engineers (нет ML / DWH в production).

Триггер выхода: первый production-capable execution contour работает, agency surface MVP в dev/staging, payment + booking + tour builder prototype запущены.

Стадия 2 — Controlled internal platform (8–14 человек)

Главная задача: controlled internal reality с первыми пилотными агентствами.

Каноничные роли (новые):

• Domain owner: Tour Builder (1) — engineering lead для Tour Builder operational model;
• Domain owner: Payment (1) — engineering lead для платёжного домена + PSP интеграция;
• Domain owner: Search & Discovery (1) — engineering lead для search domain;
• Data engineer (1) — построение DWH minimal viable schema, ETL pipelines;
• On-call engineer (1, secondary on-call) — для усиления on-call rotation (CTO + tech lead не могут оба on-call навечно);
• Customer support / operations specialist (1) — для пилотных агентств.

Триггер выхода: SLA Free tier (best-effort) держится за 90 дней, 2–3 пилотных агентств в closed beta, IsolationBoundaryCheck без cross-tenant leaks.

Стадия 3 — Controlled external beta (15–25 человек)

Главная задача: ограниченный, но честный внешний operating loop.

Каноничные роли (новые):

• Domain owner: API as Product (1) — engineering lead для partner machine surface, sandbox, certification;
• Domain owner: Notifications (1) — engineering lead для notification platform;
• Domain owner: i18n / Media / Content (1, может объединять 2–3 домена) — для multilingual UI и content management;
• Partner success manager (1) — proactive partner engagement, certification support;
• Compliance officer (1, может быть part-time) — GDPR / PSD2 / TOMS / Package Travel Directive coordination;
• Frontend engineers (1–2) — agency surface + B2C surface initial;
• Backend engineers (2–3) — расширение domain teams;
• Site Reliability Engineer (SRE) (1) — owner observability stack, capacity planning, DR drills;
• Security engineer (1, может быть part-time с фокусом на product security);
• (опционально) QA / SDET engineer (1) — automated testing coverage для critical paths;
• (опционально) Technical writer (1) — поддержка documentation governance, partner-facing docs.

Триггер выхода: SLA Free + Starter (95%) держатся за 90 дней, 5+ partner integrations в production через sandbox→certification, partner self-service onboarding работает.

Стадия 4 — Production-capable baseline (25–45 человек)

Главная задача: SLA Professional (99%), SOC 2 Type 1, production-capable operations.

Каноничные роли (новые):

• Director / VP of Engineering (1) — operational leadership, on-call escalation tier;
• Domain owner: Analytics / BI (1) — построение partner-facing analytics dashboards;
• Domain owner: A/B Testing (1) — experimentation platform owner;
• ML Engineer (1) — initial ML use cases (ranking, anomaly detection);
• Site Reliability Engineers (SREs) (2–3) — формирование SRE team;
• DevOps / Platform engineers (2–3) — Phase 2 → Phase 3 infrastructure transition;
• Security engineer (1, full-time) — SOC 2 Type 1 готовность, security audits;
• Compliance officer (1, full-time) — GDPR / PSD2 / SOC 2 / Package Travel Directive ownership;
• Customer Success Manager (Enterprise tier) (1) — для первых Enterprise клиентов;
• Engineering Managers (2–3) — formation of engineering management layer;
• Frontend engineers (2–3) — расширение surface coverage;
• Backend engineers (4–6) — расширение domain teams;
• QA engineers (2–3) — automated testing для всех critical paths;
• Technical writer (1, full-time) — partner-facing документация, SOC 2 audit evidence;
• Data engineer (1–2) — DWH maturation, ETL pipelines.

Триггер выхода: SLA Professional 99% удержан за 180 дней, 50+ partner integrations, SOC 2 Type 1 audit пройден, multi-component sagas работают без manual intervention в > 95%.

Стадия 5 — Controlled scale (45–80 человек)

Главная задача: масштабирование без размывания ядра, SOC 2 Type 2.

Каноничные роли (новые):

• VP of Engineering (1) — если ещё не Director (становится дополнительным VP при росте);
• Director of Operations (1) — координация SRE / DevOps / Security;
• Director of Product (1) — owner product roadmap, отдельно от engineering;
• Engineering Managers (3–5) — для каждого major team;
• Senior SREs (3–5) — формирование SRE team с follow-the-sun coverage;
• ML Engineers (2–3) — формирование ML team (recommendations, ranking, dynamic pricing, anomaly detection);
• Data Scientists (1–2) — для ML use cases и A/B analysis;
• Data Engineers (2–3) — DWH scale, advanced ETL;
• Frontend engineers (5–7) — расширение surface coverage;
• Backend engineers (8–12) — расширение domain teams;
• Mobile engineers (2–3) — initial mobile strategy если выбрано на стадии 3;
• DevOps / Platform engineers (3–5) — Phase 3 packaging full deployment;
• Security engineers (2) — formation of security team;
• Compliance specialists (1–2) — для регулярных аудитов;
• Customer Success Managers (2–3) — для растущей Enterprise base;
• Partner Success team (3–5) — proactive partner engagement;
• Technical writers (2) — растущая документная работа;
• Customer support specialists (3–5) — tier-зависимый support.

Триггер выхода: более 100 partner integrations, более 10 поставщиков, SOC 2 Type 2, infrastructure на Phase 3 packaging.

Стадия 6 — Multi-region and enterprise (80+ человек)

Главная задача: глобальное присутствие, enterprise-readiness, ISO 27001.

Каноничные роли (новые):

• VP of Engineering / VP of Operations — established management layer;
• Chief Information Security Officer (CISO) — owner security strategy, ISO 27001;
• Chief Compliance Officer (CCO) — owner regulatory strategy, SOC 2 Type 2 + ISO 27001 + GDPR + PSD2;
• Regional engineering teams — для multi-region deployment (3 регионов minimum для follow-the-sun);
• Customer Success teams per region — local language, local timezone support;
• Partner Success teams per region — local partner relations;
• DPO (Data Protection Officer) — обязательно для GDPR в EU;
• Specialized roles: AML/KYC officer, regulatory reporting specialist, treasury manager.

Текущий горизонт. После стадии 6 структура пересматривается с учётом новых стратегических развилок (potential IPO readiness, M&A capability, expansion в новые vertical markets).

Каноничная матрица ролей

Роли по execution contours

Execution contour	Domain owner role	Supporting roles
Core Transactional	Booking Domain Lead, Payment Architect	Backend engineers, SRE
Offer & Commercial	Commercial Architect, Pricing Lead	Backend engineers
Supplier Intake & Ingestion	Integration Lead	Backend engineers, Data Engineer
Surface Delivery	API as Product Lead, Frontend Lead	Frontend / Backend engineers
Operational Control	Operations Lead, Security Engineer	SRE, DevOps, Compliance

Роли по platform domains

Platform domain	Owner role	Stage появления
Tenancy & Identity	Platform Lead	Стадия 1
Tour Builder	Tour Builder Engineering Lead	Стадия 2
Payment	Payment Architect / Finance Lead	Стадия 2
Search & Discovery	Search Engineering Lead	Стадия 2
Notifications	Communications Lead	Стадия 3
Media & Content	Content Lead	Стадия 3
i18n	i18n Lead (может совмещать)	Стадия 3
Data Platform & Events	Data Engineering Lead	Стадия 2 (minimal) → Стадия 4 (full)
ML Platform	ML Engineering Lead	Стадия 4
A/B Testing	Experimentation Lead	Стадия 4
Analytics & BI	Analytics Lead	Стадия 4
API as Product	Platform Product Lead	Стадия 3
Multi-Tenant Isolation	Platform Lead (часть Tenancy)	Стадия 4 (dedicated_compute), Стадия 6 (dedicated_infrastructure)

Роли по operational pillars

Operational pillar	Owner role	Stage появления
Runbooks	Operations Lead	Стадия 2 (minimal) → Стадия 3 (full)
SLA & On-call	Operations Lead → SRE Lead (стадия 4)	Стадия 2 (informal) → Стадия 4 (formal)
DR & Capacity	Operations Lead → SRE Lead	Стадия 1 (Tier 1 only) → Стадия 4 (full)
Observability	DevOps engineer → SRE	Стадия 1 → Стадия 4
Release Engineering	DevOps engineer → SRE / Platform	Стадия 1 → Стадия 4

Роли по compliance / legal

Регулирование	Owner role	Stage появления
GDPR	Compliance officer	Стадия 1 (informal через CTO) → Стадия 3 (formal)
PSD2 SCA	Payment Architect + Compliance officer	Стадия 2
EU TOMS VAT	Compliance officer + Treasury	Стадия 3
Package Travel Directive	Compliance officer + Tour Builder Lead	Стадия 3
AML / KYC	AML/KYC officer (новая роль на стадии 4)	Стадия 4
SOC 2 Type 1	Security Engineer + Compliance officer	Стадия 4
SOC 2 Type 2	Security team + CCO	Стадия 5
ISO 27001	CISO + CCO	Стадия 6
DPA (GDPR)	Data Protection Officer	Стадия 6 (mandatory для EU)

On-call structure по стадиям

Согласовано с sla-and-on-call-model.md — 5 уровней эскалации.

Стадия 1–2 (small team)

• Primary on-call: rotation среди backend engineers + tech lead;
• Secondary on-call: CTO / главный архитектор;
• Manager escalation: CTO;
• Director escalation: не применимо (CTO = director).

Burden: 1 неделя per engineer per month; 4–6 engineers в rotation.

Стадия 3 (с появлением SRE)

• Primary on-call: SRE + senior engineers (rotation);
• Secondary on-call: Engineering Manager + tech lead;
• Manager escalation: Engineering Manager;
• Director escalation: Director of Engineering;
• Executive: CTO.

Burden: 1 неделя per engineer per 4–6 weeks.

Стадия 4 (production-capable)

• Primary on-call: dedicated SRE team rotation;
• Secondary on-call: Domain on-call (по execution contour);
• Manager escalation: Engineering Manager соответствующего team;
• Director escalation: Director of Engineering / VP of Operations;
• Executive: CTO / CISO для security incidents.

Burden: не более 1 недели per SRE per 6 weeks (требование burnout protection).

Стадия 5–6 (follow-the-sun)

• Regional primary on-call: SRE per region (3 регионов);
• Regional secondary: domain teams per region;
• Cross-region escalation: Director of Operations;
• Executive: CTO / CISO / CCO.

Burden: not more than 1 week per SRE per 8 weeks (improved через распределение по часовым поясам).

Связь с development roadmap

Каждая роль появляется при достижении конкретного триггера development roadmap:

Роль	Триггер появления	Ссылка
Главный архитектор	Day 0	Стадия 0
Tech Lead / Engineering Manager	Решение начать implementation	Стадия 1
Senior backend engineers (2–3)	Implementation baseline scope	Стадия 1
DevOps engineer	Первый deployable artifact	Стадия 1
Tour Builder Lead	Tour Builder engineering начат	Стадия 2
Payment Architect	PaymentIntent prototype	Стадия 2
On-call secondary engineer	Первый internal beta tenant	Стадия 2
API as Product Lead	Sandbox launched	Стадия 3
Partner Success Manager	Первый partner certification	Стадия 3
Compliance officer	Первый регулируемый flow в production (GDPR + PSD2)	Стадия 3
SRE	SLA Starter (95%) committed	Стадия 3
Security Engineer	First external partner production access	Стадия 3
Director of Engineering	25+ engineers в команде	Стадия 4
ML Engineer	Первый ML use case в production (ranking)	Стадия 4
Customer Success (Enterprise)	Первый Enterprise tenant	Стадия 4
VP of Engineering	50+ engineers	Стадия 5
Director of Operations	5+ SREs	Стадия 5
CISO	SOC 2 Type 2 готовность	Стадия 5–6
CCO	ISO 27001 готовность	Стадия 6
DPO	EU broader expansion	Стадия 6

Принципы найма

1. Hire for current stage + 1

Hiring закрывает потребности текущей стадии и первого месяца следующей. Не больше — преждевременный hiring создаёт «висящих» сотрудников без задач; не меньше — реактивный hiring приводит к burnout.

2. Senior-heavy на ранних стадиях

Стадии 0–2 требуют senior engineers (10+ years experience), способных принимать архитектурные решения и работать самостоятельно. Junior engineers становятся продуктивны на стадии 3+, когда есть mentorship capacity и established processes.

3. Cultural fit > skill match для cross-cutting roles

Cross-cutting roles (compliance officer, partner success, customer success) требуют cultural fit и communication skills больше, чем technical depth. Technical skills можно поднять через onboarding, soft skills — нет.

4. Diverse hiring как стратегическая дисциплина

Команда с фазы 4 (25+ engineers) обязана иметь diversity dimensions:

• gender;
• nationality / cultural background;
• educational background;
• prior industry experience.

Это улучшает product decisions, снижает groupthink, расширяет recruitment pool.

5. Remote-first с phased office presence

Платформа развивается remote-first с географическим распределением (Восточная Европа + EU broader + KZ). Office presence появляется с фазы 5 в ключевых regional hubs (Прага / Варшава / Алматы / Берлин или аналогичные).

6. Contractor-to-FTE conversion для специалистов

Specialist roles (compliance officer, security engineer, technical writer, ML scientist) на ранних стадиях нанимаются как contractors (cost-effective) с возможностью conversion в full-time при росте load. Это снижает risk преждевременного hiring.

7. Internal mobility приоритет над external hiring

При появлении новых ролей приоритет — внутренние candidates с upskilling, не external hires. Это улучшает retention и culture continuity. External hires — для ролей, требующих принципиально нового expertise.

Организационная структура (high-level)

Стадии 0–1 (flat structure)

CTO / Главный архитектор
├── Tech Lead
└── Engineers (3–6)

Стадии 2–3 (functional groups появляются)

CTO
├── Engineering Manager
│   ├── Backend team (4–6)
│   ├── Frontend team (2–3)
│   └── DevOps / SRE (1–2)
├── Operations Manager
│   ├── Customer Support (1–2)
│   └── Partner Success (1)
└── Compliance officer (part-time, направление к CTO)

Стадия 4 (multi-team structure)

CTO
├── Director of Engineering
│   ├── Engineering Manager: Transactional Core Team (Booking + Payment)
│   ├── Engineering Manager: Ingestion + Search Team
│   ├── Engineering Manager: Surfaces Team (Frontend + API as Product)
│   └── Engineering Manager: Platform Services Team (Tour Builder, Notifications, Media, i18n)
├── SRE Lead
│   ├── SRE engineers (2–3)
│   └── DevOps / Platform engineers (2–3)
├── Security Engineer
├── Compliance officer
├── Director of Operations
│   ├── Customer Success Manager (Enterprise)
│   ├── Partner Success Manager
│   └── Customer Support Lead
└── Director of Product
    └── Product Managers (2–3)

Стадия 5–6 (mature multi-team / multi-region)

CEO / CTO / COO / CFO
├── VP of Engineering
│   ├── Director: Domain Engineering (4–5 EMs)
│   ├── Director: Platform Engineering (3–4 EMs)
│   └── Director: Data & ML (2–3 EMs)
├── VP of Operations / Director of Operations
│   ├── SRE Director
│   ├── DevOps / Infrastructure Director
│   └── Customer / Partner Success Director
├── CISO
│   └── Security team (3–5)
├── CCO
│   ├── Compliance team (2–3)
│   └── DPO
└── Director of Product
    └── Product Managers per domain (5–8)

Каноничные ролевые ответственности

Главный архитектор / CTO (стадия 0+)

Ответственность:

• зафиксировать каноничную архитектурную ось;
• утверждать canonical документы (см. documentation-governance.md);
• эскалация развилок, требующих стратегических решений;
• блокировать изменения, нарушающие правило 00000;
• в стадиях 0–3 — также tech leadership и on-call participation;
• с стадии 4 — стратегическая роль, ежедневная operations делегируется Director of Engineering.

Engineering Manager (стадия 2+)

Ответственность:

• people management (1:1, performance reviews, career development);
• engineering process ownership (sprints, code review, deployment cadence);
• cross-team coordination;
• on-call participation (как secondary в early stages, как escalation в later);
• domain ownership of one или нескольких execution contours.

Site Reliability Engineer (SRE, стадия 3+)

Ответственность:

• owner observability stack (см. observability-and-incident-response.md);
• owner SLI / SLO / SLA infrastructure (см. sla-and-on-call-model.md);
• on-call participation (primary on-call в стадии 4+);
• DR drills coordination (см. disaster-recovery-and-capacity.md);
• capacity planning;
• incident response leadership;
• post-mortem ownership.

Security Engineer (стадия 3+)

Ответственность:

• security architecture review для всех major changes;
• vulnerability management;
• incident response для security incidents;
• penetration testing coordination (внешний vendor);
• secret management policies;
• credential rotation;
• SOC 2 audit evidence preparation;
• coordination with compliance officer.

Compliance Officer (стадия 3+)

Ответственность:

• regulatory compliance (GDPR / PSD2 / TOMS / Package Travel Directive);
• coordination with external legal counsel;
• audit evidence preparation;
• privacy impact assessments;
• partner contract review (regulatory clauses);
• data subject rights handling (GDPR access / deletion / portability requests);
• training команды на regulatory awareness.

Partner Success Manager (стадия 3+)

Ответственность:

• proactive partner engagement (onboarding, certification, technical advisory);
• partner certification flow (see api-as-product.md);
• partner retention metrics;
• escalation management для partner technical issues;
• partner roadmap alignment;
• voice-of-partner feedback в product decisions.

Customer Success Manager — Enterprise (стадия 4+)

Ответственность:

• proactive Enterprise tenant engagement;
• 24/7 escalation point (в follow-the-sun coverage);
• Enterprise-specific roadmap;
• contract renewal management;
• regulatory coordination для Enterprise клиентов с custom требованиями;
• coordination с SRE для tenant-specific SLA reviews.

Tour Builder Engineering Lead (стадия 2+)

Ответственность:

• canonical document ownership (tour-builder-domain.md, tour-builder-operational-model.md);
• composition rules engine;
• saga implementation для multi-component bookings;
• partner-grade Tour Builder API + UI/SDK;
• drift detection и compensation;
• coordination с Booking Domain Lead для transactional consistency.

Payment Architect / Finance Lead (стадия 2+)

Ответственность:

• canonical document ownership (payment-domain.md);
• PSP abstraction и multi-PSP support;
• 3DS / SCA flow;
• refund / chargeback workflows;
• settlement coordination;
• partner clearing implementation (см. partner-finance-and-clearing.md);
• coordination с Compliance officer для PSD2;
• coordination с Treasury manager (стадия 5+) для cash flow.

Burnout protection и retention

Каноничные правила

• On-call burden — не более 1 недели per engineer per 4 weeks (стадия 3+), per 6 weeks (стадия 4+), per 8 weeks (стадия 5+);
• Core working hours — 5–6 часов overlap для team meetings (особенно для distributed teams);
• Mandatory time off — minimum 4 weeks vacation per year, 1 неделя без email/Slack обязательно;
• No-meeting day — 1 день в неделю без recurring meetings (deep work);
• Sabbatical policy — 4 weeks sabbatical после 4 лет в компании (стадия 5+);
• Career development budget — minimum $2000 per engineer per year на courses, conferences, books (стадия 3+).

Метрики retention

• Engineering attrition — target less than 12% annual (стадия 3+);
• eNPS (engineer NPS) — target > 30 (стадия 4+);
• Time-to-productivity для new hires — target ≤ 30 дней для junior, ≤ 60 дней для senior;
• Internal mobility rate — target > 20% annually (стадия 4+) — индикатор growth opportunities.

Связь с экономической моделью

Headcount — major cost driver платформы (см. economic-model.md).

Каноничные cost ratios:

• Stage 0–1: 95%+ операционных расходов — payroll;
• Stage 2–3: 80–85% — payroll, 10–15% — infrastructure, 5% — other;
• Stage 4: 70–75% — payroll, 15–20% — infrastructure, 5–10% — other (compliance, marketing);
• Stage 5–6: 60–65% — payroll, 20–25% — infrastructure, 15% — other.

Hiring decisions имеют long-term cost impact — каждый engineer добавляет ~$120K/year fully-loaded cost (median для Senior in EU/CIS) с ramping commitment не менее 1 года. Поэтому hiring — стратегическое решение, не tactical.

Открытые вопросы и развилки

1. Geographic distribution. Какие 2–3 hub-локации использовать для regional teams (стадия 5+)? Кандидаты: Прага (CZ — близость к Германии и Austria, EU jurisdiction), Варшава (PL — крупный pool, English proficiency), Алматы (KZ — KZ market support, Central Asia time zone), Берлин (DE — talent density, EU). Решение — на стадии 4 на основе recruitment pipeline analysis.
2. Outsourcing vs in-house для отдельных функций. Какие функции outsourcing-кандидаты (security audits, penetration testing, legal — да; core engineering, SRE, compliance officer — нет)? Граница — на стадии 4.
3. Team structure для Tour Builder. Tour Builder — отдельная domain team или часть «Composition» domain group с booking? Решение — на стадии 2 на основе actual scope.
4. DPO requirement. GDPR требует DPO при определённых thresholds (более 250 employees или regular monitoring of data subjects). При каком объёме данных или масштабе платформы DPO становится mandatory? Решение — на стадии 4 совместно с compliance officer и legal.
5. Engineering Manager vs Tech Lead. На каких стадиях разделять role'и (EM = people management, TL = technical leadership) или совмещать? Решение — на стадии 3, по мере роста team size.

Каноничный итог

План команды для платформы Vitiana — модель, в которой:

• роли появляются по триггерам development roadmap, не по календарю;
• ответственности capсулируются по execution contours и доменам;
• operational maturity требует separate roles от core engineering с фазы 4;
• compliance / partner success / customer success — first-class функции с фазы 3;
• on-call burden управляется через burnout protection;
• hiring запускается ahead of triggers с lead time 8–24 недели;
• структура растёт от flat (стадия 0–1) к multi-team (стадия 4) к multi-region (стадия 5–6);
• каждая роль имеет canonical responsibility, согласованную с documentation-governance ownership.

Этот план — рамка для долгосрочного organizational planning, не календарный hiring schedule. Конкретные решения по найму принимаются при достижении триггеров.

Связанная документация

Документы развития

• Дорожная карта развития платформы (roadmap.md) — стадии и триггеры;
• Управление документацией (documentation-governance.md) — canonical roles и ownership;
• Главные выводы (main-findings.md);
• Documentation Master Plan (documentation-master-plan.md);
• Implementation Ready Breakdown (implementation-ready-breakdown.md).

Операционные документы

• Модель SLA и дежурств (sla-and-on-call-model.md) — on-call structure и burnout protection;
• Runbook'и инцидент-плейбуки (runbooks-incident-playbooks.md) — operational responsibilities;
• Восстановление после аварий и планирование ёмкости (disaster-recovery-and-capacity.md) — DR ownership и capacity planning;
• Дорожная карта инфраструктурного масштабирования (scaling-and-packaging-roadmap.md) — infrastructure phases;
• Деплоймент и эксплуатационная модель (deployment.md) — execution contours;
• Наблюдаемость и реагирование на инциденты (observability-and-incident-response.md) — SRE ownership;
• Релизы и совместимость (release-engineering-and-migrations.md) — Platform team ownership.

Платформенные домены

• Программный интерфейс как продукт (api-as-product.md) — API as Product Lead role;
• Платёжный домен (payment-domain.md) — Payment Architect role;
• Tour Builder домен (tour-builder-domain.md) — Tour Builder Lead role;
• Операционная модель Tour Builder (tour-builder-operational-model.md);
• Статусная машина бронирования (booking-state-machine.md) — Booking Domain Lead role;
• Поиск и обнаружение (search-and-discovery.md) — Search Engineering Lead role;
• Уведомления и коммуникации (notification-and-communication.md) — Communications Lead role;
• Платформа машинного обучения (ml-platform.md) — ML Engineering Lead role;
• Платформа A/B-тестирования (ab-testing-platform.md) — Experimentation Lead role;
• Платформа данных и трекинг событий (data-platform-and-events-tracking.md) — Data Engineering Lead role;
• Аналитика и BI (analytics-and-bi.md) — Analytics Lead role;
• Сила тенантной изоляции (multi-tenant-isolation-strength.md) — Platform Lead для tenancy;
• Партнёрские взаиморасчёты (partner-finance-and-clearing.md) — Finance Lead role;
• Экономическая модель (economic-model.md) — cost structure / headcount impact.

Архитектурные правила

• Закон 00000 — платформа главенствует над поставщиками;
• Современные лучшие практики верхнеуровневых платформ — Stripe / Twilio / Algolia organizational patterns;
• Эластичное масштабирование и упаковка по фазам — связь команды с phased growth;
• Развитие без деградации;
• Тезисное обоснование архитектурных решений.