# ISRM Insight Hub: опис проєкту та пропозиції для погодження

**Статус документа:** проєкт для перегляду партнерами та замовником; не є договором, погодженим технічним завданням або підтвердженою пропозицією постачальника.  
**Мова:** українська. Інтерактивний артефакт також має перемикач української/англійської.  
**Наявні матеріали:** цей повний опис · [інтерактивне демо — пошук, каталог сервісів і граф залежностей](/) · [коротка клієнтська пропозиція](/proposal). Окремої розрахункової книги в проєктній теці немає. У пропозиції показані індикативні діапазони MVP та окремого експертного пілота: це розрахунки з явно позначених планувальних припущень і ринкових орієнтирів, а не погоджені котирування партнерів чи фіксована ціна.

## 1. Що пропонується

ISRM Insight Hub — цифровий інструмент для пошуку експертизи й формування груп під різні проєктні цілі: підготовку матеріалів і статей, накопичення знань та виконання проєктів для клієнтів. MVP має дати самостійну користь до будь-якого експертного пілота: знаходити фахівців за доказами й напрямами, створювати проєкти з цілями, формувати команди та фіксувати призначені задачі й результати. Це обмежений робочий процес, а не повна система керування проєктами з чатом, календарем, білінгом і складною автоматизацією. Поточний застосунок є демонстрацією шляху користувача та пропонованої функціональності; демо-пошук і граф не є готовим захищеним production-сервісом.

Пропозиція не передбачає, що одна функція автоматично потрібна кожному замовнику. Замовник переглядає пропозицію й погоджує функції, межі даних, пілот, результати та бюджет. Партнерський маршрут окремо призначений для внутрішнього перегляду ролей, scope, оцінок і відкритих рішень; він не є тим самим клієнтським маршрутом і наразі не має автентифікації.

## 2. Навігація та артефакт

Поточна версія розділяє три поверхні: головна сторінка `/` містить пошук і граф мережі; кнопка конфігурації відкриває каталог сервісів, а кнопка залежностей — граф сервісних функцій із передумовами; `/proposal` — коротка клієнтська пропозиція з MVP і окремим, необов’язковим експертним пілотом після рішення за результатами MVP; `/partner` — внутрішній партнерський перегляд із чотирма внутрішніми scope та моделлю оцінювання. Перший публічний реліз не пропонується як продукт на цій стадії: це віддалена можливість лише за умови успішних попередніх етапів. Сторінки не є захищеними кабінетами: вибір у формі не створює погодження, а локальна чернетка не надсилається автоматично.

У проєкті наявний один повний супровідний документ — цей опис; таблиці розрахунків окремим файлом не створено. Сторінка `/proposal` показує два етапи: корисний сам по собі MVP і опційний цикл роботи з експертною спільнотою, рішення про який ухвалюється після перегляду MVP. Додаткова консультаційна підтримка винесена окремо. Для кожного етапу показано індикативний діапазон із формулою, одиницями, джерелом ставок і припущеннями; це не замінює узгодження оцінок партнерів, прав повторного використання графа/пошуку, зовнішніх витрат і остаточного обсягу. Не надсилайте демо з даними мережі як приватне посилання: автентифікація, авторизація й контрольований обмін файлами ще не налаштовані.

## 3. Пошук експертів

Пошук фільтрує наявну CRM-когорту за секторами, записаною в CRM географічною ознакою та наявністю публічного джерела; користувач може перейти від графа до картки чи сформованої групи. Ці ознаки описують дані, а не доводять фактичне місце роботи, професійну придатність, зацікавленість, згоду на участь або дозвіл на контакт.

Збереження чи експорт із локального демо не створює керованого реєстру. Для операційного використання потрібні погоджені правила джерел, виправлень, згоди, зберігання, доступу та контакту. Поточний партнерський preview показує псевдонімізовані профілі й широкі категорії; він не є анонімізацією та не є повноцінним захищеним доступом до іменних міні-досьє. Не поширювати цей локальний preview як зовнішнє партнерське посилання.

## 4. Конфігуратор сервісів

Граф функцій показує залежності та етапи, а не фактичну готовність кожного модуля. Центральна зона відведена спільним консультаційним сесіям; далі розміщуються функції MVP, функції, потрібні для погодженого пілота, та можливі наступні функції. Вибір функції показує її призначення, залежності, відповідального партнера, очікуваний результат, критерій приймання, KPI та статус доказовості. Відповідність експертних записів певній функції є лише планувальним зіставленням, не свідченням інтересу або згоди.

Trust & Influence Index (TII) — запропонована концепція індексу для експертів: структурований спосіб збирати й оцінювати атрибутовані докази професійної надійності та впливу фахівця у визначеній сфері, а не рейтинг популярності чи автоматичний вердикт про компетентність. TII ще не валідований і не є чинним галузевим стандартом. Його можна розробити й надалі запропонувати як такий лише після спільного визначення призначення, показників, джерел доказів, меж застосування, людського перегляду, виправлення й оскарження та незалежної перевірки надійності методики.

Якщо наявних функцій недостатньо, форму додаткової вимоги слід заповнювати як коротке завдання: користувач/роль, потреба, очікувана поведінка системи, результат, дані/інтеграції та критерій приймання. Це збирає коментар до scope, а не запускає автоматично розробку.

## 5. Чотири внутрішні напрями робіт

Партнерська модель розділяє чотири внутрішні scope; клієнтська сторінка показує два етапи з індикативними діапазонами, а консультації поза включеними результатами — окремою опцією. Віддалений публічний продукт не є пакетом цієї пропозиції. Внутрішні scope — не кроки навігації та не пакети «мінімум / стандарт / максимум».

| Scope                                   | Призначення та результат                                                                                                                                                                                        | Межа                                                                                                                                                                                            |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Консалтинг і стратегія**                 | Додаткова робота з пріоритетами розвитку, прогалинами експертизи, рішеннями борду й організаційною моделлю поза погодженими результатами MVP та експертного пілота. | Спільне проєктування TII, включене в експертний цикл, не виставляється вдруге як окрема консультація. Додаткові сесії мають окремий scope і ціну. |
| **2. MVP застосунку**                         | Корисний самостійний набір функцій: знаходити експертизу, формувати проєктні групи для написання матеріалів, накопичення знань і клієнтських проєктів, фіксувати цілі, задачі, відповідальних і результати. | Планувальна межа: легкий проєктний робочий процес, не повноцінна PM-система. Існуючі пошук і граф не рахуються як нова розробка; залишкові роботи та повторне використання мають окрему перевірку. |
| **3. Опційний експертний пілот**              | Після MVP — за окремим рішенням — залучити охочих членів спільноти й запросити інших експертів через дозволені канали; спільно розробити процедуру TII, провести робочі групи за погодженим порядком денним, підготувати звіт і статті, відстежити згадки та оцінити готовність до конференції. | До планового діапазону входять дві статті й один висновок про доцільність конференції як припущення. Повідомлена чисельність LinkedIn-групи — неперевірений планувальний контекст, а не підтверджене охоплення чи дозвіл на контакт. Участь, членство, оплата й конференція не гарантуються. |
| **4. Віддалене продовження**                  | Якщо MVP і, за вибором сторін, експертний цикл дадуть достатні докази користі, надалі можна окремо розглянути публічний продукт, членські сервіси, кілька спільнот, оплату та підтримку. | Не є продуктом або пакетом цієї пропозиції; не входить до наведених цінових діапазонів і не має оцінки на цій стадії. |

## 6. Запропонований пілот і результат для замовника

MVP має дати практичну користь незалежно від запуску пілота. Після його демонстрації замовник і партнери вирішують, чи є підстава проводити окремий експертний цикл. Якщо так, до старту погоджуються порядок денний, склад робочих груп, правила TII, дозволені канали й повідомлення, метрики, період спостереження, обробка згоди та межа якісного аналізу.

Експертний цикл має перевірити, чи здатна зацікавлена група спільно сформулювати процедуру Trust & Influence Index (TII) для оцінювання експертів. За погодженим порядком денним охочі учасники працюють у групах, залучають інших фахівців і фіксують рішення та розбіжності. Результати циклу: версійований проєкт процедури TII; нотатки робочих груп і підсумковий звіт; до двох статей із джерелами; журнал фактичних публікацій і зовнішніх згадок; висновок, чи є достатньо підтвердженого інтересу, матеріалу й готових учасників для конференції. Публікації, зовнішні згадки й сама конференція не гарантуються.

⚠️ [ASSUMPTION] Користувач повідомив про приблизно 11 000 учасників LinkedIn-групи; це число не перевірене. Його можна використовувати лише як наративний контекст, якщо буде підтверджено датованим джерелом і правомірність такого використання. Членство в групі не доводить, що публікацію побачили, що людину можна адресно запросити або що вона погодиться. У циклі слід окремо вимірювати фактичне унікальне охоплення публікації, переходи за окремим посиланням, добровільні заявки, прийнятих нових членів і — лише після визначення ціни та умов членства — фактичні оплати. Після підтвердження відповідних знаменників можна обчислити: `виміряне унікальне охоплення × (добровільні заявки ÷ виміряне унікальне охоплення) × (прийняті нові члени ÷ добровільні заявки) × (оплати ÷ прийняті члени, яким показано конкретну пропозицію)`. Для цих переходів наразі немає перевірених коефіцієнтів із зіставним органічним каналом, визначеним знаменником і періодом; реклама LinkedIn або загальні показники вебконверсії не є коректною заміною. Числову конверсію не заявлено: її слід виміряти в дозволеному циклі. До фактичних результатів можна окремо додати кількість охочих експертів, сформовані групи, виконані результати, добровільні заявки на членство, інтерес до платного рівня та підтверджені оплати — кожен показник із джерелом, знаменником і періодом.

Експертний цикл не включає автоматичні приватні повідомлення, обробку контактів без згоди, навчання базової AI-моделі, платіжну інтеграцію, виробництво конференції, публічний реліз або необмежене масштабування. Інтерес до платного членства можна вимірювати лише після того, як замовник визначить саму пропозицію; фактична оплата й білінг залишаються поза MVP та циклом за замовчуванням.

### 6.1 Когорта 2 пілота · gate клієнта й борду

Когорта 1 пілота — це наявні залучені члени з CRM. Когорта 2 не може бути визначена implementation і не може бути вигадана. Канал комунікації для формування когорти 2 — група в LinkedIn. До gate-рішення клієнта й борду жодного числа не виводиться, жодного контакту не здійснюється, жодних даних не збирається.

Conversion formula, яка буде застосована тільки після вимірювань у пілоті: `виміряне унікальне охоплення × (добровільні заявки ÷ виміряне унікальне охоплення) × (прийняті нові члени ÷ добровільні заявки) × (оплати ÷ прийняті члени, яким показано конкретну пропозицію)`. Усі чотири input-слоти порожні до запису фактичних значень у пілоті. Conservative estimates формуються лише після аналізу складу LinkedIn-групи та після вимірювань; до цього моменту число не є прогнозом.

Gate-клієнта/борду вимагає явного затвердження: scope, controller, purpose, channel, cohort, notice, retention, processing. Без цього preview опитування залишається невідправлюваним, а LinkedIn-група не використовується для контакту.

## 7. Партнери, відповідальності та майбутня передача

Пропозиція адресована трьом партнерам. Винагорода кожного має бути пов’язана з конкретними пакетами результатів, а не з абстрактною присутністю в команді.

| Роль                                                     | Зона відповідальності та очікувані результати                                                                                 | Приклад вимірювання                                                                        |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Комунікація із замовником і розвиток бізнесу**         | Discovery та комунікація з клієнтом/бордом; узгодження рішень, комерційних умов, змін і наступних кроків.                     | Пункти рішень із власником і наступною дією ÷ усі відкриті пункти.                         |
| **Операції, OSINT, події та зовнішні комунікації**       | Підготовка дозволеного дослідження, людського перегляду, опитувань, подій і кампаній; журнал фактичних доставок і відповідей. | Записи з дозволеним джерелом/каналом і простежуваним результатом ÷ усі опрацьовані записи. |
| **Власник продукту, стратегія та робота з розробниками** | Пріоритети й модель продукту; backlog і критерії приймання; координація постачальника без дублювання його включеного PM.      | Прийняті результати ÷ подані результати; години та зміни scope проти погодженого плану.    |

Після пілота ці функції можна зіставити зі стандартними управлінськими ролями, щоб оцінити, що має залишитися в постійній команді, що можна передати штатному менеджменту, а що замовляти зовнішньо. Це опція організаційного дизайну, не обіцянка автоматичного працевлаштування чи прибутку.

## 8. Технологічне обґрунтування та межі готовності

Демонстрація побудована як React/TypeScript-застосунок із графом мережі та графом функцій; інтерактивний партнерський маршрут розділяє пошук/конфігурацію та погодження/ціну. Запропонована цільова архітектура може інтегрувати CRM, керований реєстр експертів, робочі процеси перевірки, аналітику та базу знань. Ці інтеграції є цільовою архітектурою, а не підтвердженим фактом готового production-підключення.

Для production потрібні щонайменше: автентифікація та авторизація з розмежуванням ролей; керований і контрольований життєвий цикл даних та згоди; аудит змін; безпечне зберігання секретів; перевірка доступу до джерел; правила виправлення/видалення; резервне копіювання й відновлення; тестування дозволів та інцидентний процес. Локальне збереження чернетки в браузері цього не забезпечує. До появи цих контролів показувати артефакт тільки як локальне демо, не як безпечний портал партнерів чи клієнта.

Функція пошуку не повинна видавати збіг за рекомендацію або верифікацію. AI, семантичне зіставлення та автоматичні висновки не є необхідною передумовою описаного пілота; якщо їх розглядатимуть надалі, потрібні окремі рішення про призначення, оцінювання похибок, людське підтвердження, витрати API та допустимі дані.

## 9. Індикативна модель ціноутворення

Окремої розрахункової книги у проєктній теці немає. Клієнтські суми нижче є бюджетними діапазонами, обчисленими з видимого work-package WBS і ринкових орієнтирів. Години є планувальними припущеннями, а не табелем фактичного часу чи підтвердженим обсягом конкретного партнера; суми не є офертою, котируванням названого постачальника або гарантованою верхньою межею.

**MVP застосунку: $3 600–$14 112; базовий сценарій — $7 104.** Нижня межа: `(120 годин розробника × $25/год) + (24 години продуктового супроводу × $25/год) = $3 600`. Базовий сценарій: `(160 × $37) + (32 × $37) = $7 104`. Верхній сценарій: `(240 × $49) + (48 × $49) = $14 112`. WBS включає збережені проєктні брифи/цілі, експертні групи, призначення задач і результатів, ролі й доступ, перевірку доказів, погоджений перший контакт за згодою, QA та передачу. Оцінка не включає повну систему керування проєктами.

**Опційний експертний цикл після MVP: $3 900–$18 228; базовий сценарій — $8 880.** Сумарний WBS становить 156–372 партнерські години; базовий обсяг — 240 годин. Формула: `156 × $25 = $3 900`; `240 × $37 = $8 880`; `372 × $49 = $18 228`. До нього входять підготовка й спільне проєктування процедури TII, відбір/орієнтація рецензентів, стратегічна робота, кампанія та робочі групи, підсумковий звіт, `[ASSUMPTION]` дві статті та `[ASSUMPTION]` висновок щодо доцільності конференції. Дві статті оцінено як `2 × 8–16 годин`; конференційний висновок — `8–16 годин`. Аналіз до 50 відповідей є окремим планувальним припущенням; більший обсяг ручного аналізу потребує перегляду оцінки.

**Разом за обидва етапи, якщо замовник обирає їх обидва: $7 500–$32 340; базовий сценарій — $15 984.** Це арифметична сума двох діапазонів, а не окремий пакет чи знижка. MVP можна використовувати самостійно; опційний цикл запускається лише після перегляду результатів MVP і окремого рішення.

У розрахунку використано записаний у проєкті діапазон Clutch Ukraine `$25–$49 за годину постачальника`; базове `$37/год` — арифметична середина `(25 + 49) ÷ 2`, а не опубліковане середнє. Під час цієї редакції обидві сторінки Clutch не вдалося отримати через помилку мережевого з'єднання, тому сам діапазон тут незалежно не перевірено: до такої перевірки він має статус `[ASSUMPTION — UNVERIFIED RATE INPUT]`, а обчислені ціни є лише умовними сценаріями. Застосування того самого consulting-provider діапазону до продуктових, комунікаційних та операційних партнерських годин є окремим `[ASSUMPTION]`-проксі, а не ставкою конкретного партнера. Поточна сторінка Lemon.io містить загальні чинники ставок, але не публікує використаних раніше числових значень для України; її не використовуємо як числовий cross-check.

Для внутрішнього звіряння витрати лишаються розділеними, щоб не рахувати одну роботу двічі: погоджені години партнерської ролі × її ставка; залишкові години розробки × ставка постачальника; окремо виміряна робота з досьє; погоджена компенсація за повторне використання графа/пошуку; підтверджені зовнішні витрати. Вже виконану роботу не можна вдруге виставляти як нову розробку. Право повторного використання, ліцензія та компенсація потребують окремого рішення; порожнє поле не означає безкоштовне використання.

Діапазони є сценарними, не статистичними інтервалами. Вони показують клієнту числовий бюджетний коридор зараз, але перед договором партнери мають підтвердити години, фактичні ставки, обсяг учасників/відповідей і права на повторне використання. Додаткова консультаційна робота залишається окремою опцією й не дублює роботу над TII, вже включену до експертного циклу.

Не включені до сум податки, валютні коливання, хостинг, AI/API, юридичні/приватнісні послуги, ліцензування чи очищення даних, платне просування, додатковий ручний перегляд, переклад статей, конференційне виробництво та постійна підтримка. Ці невідомі суми не дорівнюють нулю. Публічне масштабування — віддалена можливість після доказів успішності попередніх етапів, не продукт цієї пропозиції й не частина наведеного діапазону.

## 10. Варіанти відносин із замовником

Замовник і його борд мають вирішити, чи виступають вони клієнтом, партнером розвитку, майбутнім власником коду/платформи або замовником закритого сервісу. Ці варіанти впливають на права, розподіл майбутньої економічної вигоди, контроль розвитку, обсяг підтримки та ризики; вони не повинні приховано змінювати погоджену ціну виконання. Окремо можна розглянути фінансування через спільноту, опитування чи фандрайзинг, але лише після дозволу борду й погодження повідомлень/каналів.

Рекомендована послідовність: погодити потребу та функції; погодити технічне завдання, пілот і критерії приймання; погодити оцінку, бюджет, валюту та порядок оплати; потім формалізувати права й обов’язки договором. Будь-яка майбутня таблиця є сценарієм, а не зобов’язанням сторін, доки її входи й умови не погоджені.

## 11. Що саме мають вирішити партнери

Партнери перевіряють, чи зрозумілі чотири внутрішні scope та призначення кожного; чи погоджуються вони з власними функціями й критеріями приймання; які оцінки, ставки, валюта й витрати мають джерело; чи придатні дизайн і послідовність демо для клієнтської розмови; яку модель партнерства та права на повторне використання варто винести на узгодження. Коментарі можна залишити в партнерському маршруті. Розрахункова книга в поточному проєкті відсутня, тому клітинки й підсумки з неї не можна вважати доступними чи перевіреними.

Після перегляду партнерами замовник має окремо підтвердити проблему та очікуваний результат, функції пілота, критерії приймання, дані й доступ, граничний бюджет і прийнятну модель відносин. Вибір «погоджую / пропоную зміни / потрібне обговорення» має доповнюватися поясненням зміни, а не трактуватися як підписаний контракт.

## 12. Джерела та статус доказів

Наведені нижче джерела підтримують лише порівняльні ставки, використані в індикативній формулі розділу 9. Вони не встановлюють остаточну ціну контракту ISRM і не є ставками конкретних партнерів. Розділ 9 окремо розмежовує provider-company pricing guides і freelance contract rates.

- **YunoJuno, Freelancer Rates Report** — можливе джерело для майбутнього порівняльного аналізу ставок фрилансерів; жодне значення звіту не заповнює поточні поля ціни: [джерело](https://www.yunojuno.com/freelancer-rates-report).
- **Lorien, UK software developer contract rates** — можливе джерело для окремого порівняння ставок контракторів; не є котируванням розробницької команди ISRM: [джерело](https://www.lorienglobal.com/insights/software-developer-contract-rates-in-the-uk).
- **Clutch software development pricing** — provider-company pricing guide; у вересневому зрізі 2026 року український діапазон `$25–$49 за годину`: [джерело](https://clutch.co/developers/pricing).
- **Clutch business consulting pricing** — окремий provider-company pricing guide; у вересневому зрізі 2026 року український діапазон `$25–$49 за годину`: [джерело](https://clutch.co/consulting/pricing).
- **Lemon.io rate calculator** — сторінка пояснює загальні чинники ставок, але в доступному вмісті не містить підтвердження числової ставки для України; до розрахунку не включена: [джерело](https://lemon.io/rate-calculator/ukraine/).
- **NASA SWE-015, Cost Estimation** — методичні принципи документування оцінки, припущень і невизначеності: [джерело](https://swehb.nasa.gov/display/SWEHBVB/SWE-015+-+Cost+Estimation).
- **NASA Software Work Breakdown Structures** — розклад робіт за результатами: [джерело](https://swehb.nasa.gov/spaces/7150/pages/16449881/7.05+-+Work+Breakdown+Structures+That+Include+Software).
- **W3C WCAG 2.2** — орієнтир доступності; формальна відповідність окремо не аудіювалася: [стандарт](https://www.w3.org/TR/WCAG22/).
- **Внутрішні специфікації проєкту** — `README.md`, `roadmap.md`, `src/lib/proposal-data.ts` і план `plan/feature-isrm-partner-configurator-v1.md` у репозиторії ISRM Insight Hub. Вони описують поточну реалізацію демо, функції, пакети робіт і обмеження; не замінюють погоджений договір чи технічне завдання.

## 13. Статус перед зовнішнім надсиланням

Цей документ дає основу для першої розмови про проблему, MVP і можливе продовження. У ньому наведено індикативні бюджетні діапазони, але це не договір, котирування конкретної команди чи фіксована оферта: години є планувальними припущеннями, а ставки взяті з ринкових довідників. Перед бюджетним рішенням партнери мають підтвердити межі робіт, години, фактичні ставки, обсяг учасників/відповідей, права повторного використання графа/пошуку, невраховані витрати та критерії приймання. Публічний реліз не входить у поточну пропозицію. Демо не має автентифікації й авторизації; не надсилати відкритий URL з даними мережі до налаштування захищеного доступу.