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