Логіко-структурна матриця, або логфрейм, це компактна таблиця, яку багато міжнародних донорів просять додати до заявки. На перший погляд вона виглядає складно, але в основі лежить проста ідея: якщо ми зробимо X, то отримаємо Y, а це, своєю чергою, наблизить нас до Z. У цій статті йдеться про те, з яких частин складається логфрейм, як перевірити його логіку і яких помилок варто уникати під час заповнення.
Що таке логфрейм і навіщо він потрібен
Логфрейм змушує заявника викласти логіку проєкту явно, ще до написання розгорнутого опису, і побачити, чи витримує вона перевірку. Для рецензента це зручний спосіб швидко зрозуміти, чи узгоджені між собою рівні проєкту. Пізніше та сама таблиця часто стає основою для плану моніторингу: саме за прописаними в ній індикаторами команда відстежуватиме прогрес під час реалізації. Для команди, яка ще не звикла до такого формату, корисно сприймати логфрейм не як бюрократичну вимогу, а як стислий переказ усієї заявки на одній сторінці.
Структура матриці: рядки і стовпці
Класичний логфрейм це таблиця з чотирма рядками і чотирма стовпцями. Рядки відповідають рівням проєкту: мета, ціль, результати, діяльність. Стовпці описують кожен рівень із чотирьох боків: опис, індикатори, джерела перевірки та припущення.
| Рівень | Приклад питання, на яке він відповідає |
|---|---|
| Мета | Якій довгостроковій зміні служить проєкт? |
| Ціль | Що конкретно зміниться до кінця проєкту? |
| Результати | Які конкретні продукти чи результати з'являться? |
| Діяльність | Які конкретні дії ми виконаємо? |
Вертикальна логіка: від діяльності до мети
Вертикальну логіку читають знизу вгору за принципом «якщо, то»: якщо виконати заплановану діяльність і при цьому виконуються припущення цього рівня, з'являються результати; якщо отримано результати і виконуються припущення наступного рівня, досягається ціль; якщо досягнуто цілі і виконуються ширші припущення, робиться внесок у мету. Якщо на якомусь кроці цей ланцюжок «якщо, то» не витримує критики, слабке місце варто переформулювати ще до подання заявки.
Наприклад: якщо провести навчання для активістів громади (діяльність) і при цьому учасники дійсно матимуть час і мотивацію відвідати всі заняття (припущення), з'являться підготовлені активісти, здатні самостійно вести ініціативи (результат); якщо ці активісти й далі отримають підтримку від місцевої влади (припущення наступного рівня), вони зможуть реалізувати власні проєкти (ціль); а якщо в громаді загалом збережеться простір для громадської активності (ширше припущення), розвиток самоорганізації громади зробить внесок у стійкий місцевий розвиток (мета).
Горизонтальна логіка: індикатори, джерела, припущення
Кожен рядок має бути внутрішньо узгодженим по всіх чотирьох стовпцях. Індикатор повинен справді вимірювати те, що заявлено в описі цього рядка, а не щось суміжне. Джерело перевірки має бути реалістичним способом дійсно отримати дані за цим індикатором, а не документом, якого насправді не існує. Стовпець припущень фіксує зовнішні умови, які мають зберігатися, щоб вертикальна логіка спрацювала: наприклад, стабільність співпраці з партнерами чи незмінність умов роботи в громаді. Саме припущення найчастіше залишають порожніми, хоча вони показують, наскільки крихкою чи стійкою є логіка проєкту.
Як заповнювати логфрейм на практиці
Зручно починати заповнення з середини таблиці, з рядків «результати» і «діяльність»: вони найконкретніші, і їх найлегше сформулювати. Далі можна піднятися вгору до цілі й мети. Для кожного індикатора одразу перевіряйте питання «а звідки ми це реально дізнаємось»: якщо чіткої відповіді немає, індикатор не годиться. Для кожного припущення чесно запитайте, що може зруйнувати цю логіку ззовні, і запишіть відповідь, навіть якщо вона незручна. Заповнення логфрейму рідко вдається з першого разу: це нормальний, ітеративний процес, і повертатися до вже заповнених рядків після роботи над іншими часто необхідно.
Навіщо логфрейм потрібен і після подання заявки
Логфрейм не втрачає значення одразу після подання заявки. Під час реалізації проєкту команда регулярно звіряється саме з цією таблицею, щоб перевірити, чи рухається робота відповідно до заявленої логіки, а не лише відповідно до плану витрат. Індикатори, прописані на етапі заявки, стають основою для проміжних і підсумкових звітів: замість того щоб вигадувати, як показати результат, команда просто збирає дані за вже узгодженими показниками. Якщо під час виконання з'ясовується, що якесь із припущень виявилося хибним, наприклад партнер перестав співпрацювати чи ситуація в громаді істотно змінилася, це привід чесно переглянути логіку, а не мовчки продовжувати виконувати план, який більше не веде до заявленої цілі.
Типові помилки в логфреймі
- індикатори сформульовані настільки розмито, що їх неможливо об'єктивно виміряти;
- джерело перевірки насправді не існує або зібрати за ним дані нереалістично;
- стовпець припущень лишили порожнім або заповнили загальними фразами без змісту;
- опис діяльності записаний у рядок результатів чи навпаки;
- мету і ціль злили в одне формулювання замість двох окремих рівнів.
Логфрейм не прикрашає заявку, він перевіряє, чи витримує її логіка уважне читання.