Чи можливо написати книгу, коли працюєш повний робочий день на основній роботі, яка до того ж є єдиним джерелом доходу для забезпечення життя? Відповідь на це питання я шукала років десять.
Я дуже давно хотіла написати книгу, але не знала, як втілення цього бажання поєднати з досить стресовою роботою й хобі, відмова від яких призвела б до швидкого вигорання. Ця думка конкурувала з іншою: чомусь я вирішила, що аби почати писати, треба цілком зануритись лише в цей процес. Буквально закритися в кабінеті та інвестувати хоча б декілька місяців на творчі спроби. А це значить - треба звільнитися. І тут постає цікавий вибір: покинути роботу, де ти вже професіонал і добре платять, та ризикнути заради ефемерної перспективи стати письменницею чи відкласти свою мрію до кращих часів?
Роками я обирала друге. Тим часом, внутрішній голос, що вимагав бодай спробувати щось написати робився все голоснішим, поки не перетворився на невпинний вереск.
Всесвіт був схильним дати мені шанс. Десятирічну прокрастинацію від писання перервала стаття на Medium, яка випадково впала мені в око. Справжній джекпот! Авторка статті ділилася своїм досвідом, як їй вдалося написати і видати свою книжку при тому, що вона була зайнята повний робочий день на основній роботі. Її підхід був у тому, аби щодня зранку перед роботою писати по кілька сотень слів. Так очевидно! Але ця стаття стала справжньою революцією для мене, бо зруйнувала мої страхи і показала, що поєднати два заняття абсолютно можливо і не обов’язково обирати щось одне. Треба лише вигадати свою систему координат: як саме рухатись, щоби мати прогрес і щоби кожна зайнятість не заважала одна одній.
Експеримент
Натхнення прийшло з моєї професії в ІТ. Тоді я вже була менеджером продуктів. В ІТ проєктах, в розробці яких я брала участь, використовувались гнучкі методології. Вони якраз і дозволяли невеликими шматками будувати щось з нуля. Я подумала, а чому б мені не застосувати методологію Agile разом із церемоніями і відповідним програмним забезпеченням до написання книги?
Так народився мій експеримент. Окрім допомогти мені систематизувати роботу над книгою і забезпечити постійне просування, мене розбирала цікавість перевірити, чи можуть гнучкі методології розробки ІТ проєктів бути дієвим засобом для роботи письменників. Результати вийшли дивовижні.
Сетап
Отже, в умовах обмеженої кількості доступного часу, критичним є дотримання дисципліни і наявність чітких цілей. Схема авторки тієї статті на Medium для мене не спрацювала б, тому що частина ранків і вечорів були зарезервовані на інші регулярні заняття. А в те, що писання по пару абзаців, коли випаде нагода, буде ефективним способом роботи над книгою – я не вірила.
Тож, проаналізувавши свою ситуацію, я визначила, що для мене більш дієвим буде визначити певний об’єм робіт на відтинок часу. Тому я обрала працювати в тижневих спринтах [тобто циклах довжиною в тиждень], в які запланую конкретний список задач. Складність кожної задачі має бути заздалегідь приблизно оцінена. А для кожного спринта обов’язково має бути встановлена мета, наприклад, «дописати розділ про Карлу». І не важливо, коли і як я буду виконувати ці задачі, бодай, вночі чи на вихідних, але в кінці тижня має бути виконаний запланований об’єм робіт.
Аби планувати тижневий об’єм задач і відслідковувати поступ, я купила підписку на JIRA (професійний софт для планування розробки). На час мого експерименту, наприкінці 2018 року, вже існували інші безкоштовні програми для управління задачами, але ця для мене була найбільш зручною, зокрема через можливість вписувати оцінку розміру кожної задачі, встановлювати мету спринту та візуальну звітність – різні графіки щодо продуктивності тощо. Тут важливим було й дещо зі сфери психології - я розраховувала, що витрати на підписку будуть мотивувати мене тримати дисципліну.
Вам ніколи не було цікаво, скільки саме витрачається часу на конкретну задачу, без перерв на каву, гортання Інстаграму тощо? Можливо, я і задрот, але раз вже експериментую, то мені дуже кортіло дізнатися, скільки реально піде «чистого» часу на написання книги. Тому я встановила на телефон спеціальний додаток з таймером Timesheet, за допомогою якого можна реєструвати точний час, витрачений на роботу над книгою.
Також, для роботи над «книжковим проєктом» я купила електростатичну білу дошку, запаслася різнокольоровими картками для нотаток і маркерами. І останній компонент – приготувала спеціальний нотатник для фіксування своїх спостережень і висновків щодо експерименту. Завдяки цьому, до речі, зараз я можу відтворити багато інформації.
Тепер все було готове до початку роботи: методологія була обрана – працюю по Scrum [один з підходів в Agile методології] в тижневих спринтах; веду проєкт в JIRA; в Timesheet реєструю час; використовую дошку для креативного процесу.
Підготовка. Workshop
Наступний етап – це сформувати список задач [backlog] аби додати їх в JIRA. Цей список, насправді - план написання книги, де кожна задача – це епізод, або цілий розділ книжки (наприклад, передмова або епілог).
Але для того, щоб створити цей план, треба ідею книги повністю деконструювати на дрібні частини. На той момент у мене був лише задум книги, певне бачення концепції і ймовірна кінцівка, які вкладалися в кілька речень. Ще не було жодних деталей, скільки яких героїв буде і якою буде їх стежка через увесь твір.
"Створення плану книги – це неодноразова декомпозиція і об’єднання ідей."
Щоб добитися такого рівня деталізації, спочатку я зробила щось на кшталт Google Design Sprint [креативний процес трансформації ідеї в прототип рішення]. Впродовж тижня я займалася індивідуальним мозковим штурмом і працювала з білою дошкою.
Під кінець вправи у мене було детальне бачення книги [в ІТ термінології це можна прирівняти до product vision]. Були визначені усі головні герої, їх основні риси та місія [personas], а також я визначила приблизний шлях по сюжету кожного з них [user journey]. В процесі роботи над цими завданнями, концепція книги обросла деталями, викристалізувався відбиток розвитку подій від початку до кінця [service blue print], який конвертувався в розширений синопсис. А якщо є синопсис, то вже є що декомпозувати далі.
Чому я пішла таким, на перший погляд, складним шляхом? Колись моя перша спроба писати стихійно, визначаючи подальший розвиток подій на ходу, зазнала фіаско. Так я з’ясувала, що я з тих авторів, хто пише з кінця. Тобто, аби починати взагалі щось пробувати писати, на старті має бути чітке розуміння, в яку кінцеву точку я хочу дійти і як саме. Можливо, це професійна деформація, бо ось це і є завданням менеджера продукту. Але для мене це єдиний рецепт успіху.
"Я з тих авторів, хто пише з кінця."
З синопсису чітко вималювалися частини твору, умовно: пролог, зав’язка, розв’язка, епілог (у мене були інші назви). Їх я потім побила на розділи. Частини стали епіками [epic – тип завдань в JIRA], а кожен розділ розбився на кілька сторі [story – тип завдань в JIRA], звісно, згідно з принципом INVEST :).
Маючи список завдань до сюжету, також стало зрозуміло, які теми треба подосліджувати перед тим, як починати писати розділ. Так, сформувався список завдань на дослідження – таски [task – тип завдань в JIRA]. В такий «нехитрий» спосіб, сторі і таски перетворилися на беклог.
Оскільки хронологія сюжету була відома, то і завдання вибудувалися у відповідному порядку. Чорнову роботу по розбивці зробила в Excel, а потім створила проєкт в JIRA і перенесла всі завдання туди. На цьому підготовка завершилась. Тепер почалася справжня гра в Scrum.
Планування
Моя робота над книжкою складалася з планування та продумування епізодів, дослідження деяких тем або фактів, власне писання і фіксування спостережень, висновків, ідей. Різні типи задач потребують різного часу на виконання. До прикладу, дослідження можуть займати дуже багато часу. Тому я старалася їх дробити так, щоб за тиждень встигнути і подосліджувати, і щось написати.
Отже, першим і важливим практичним етапом в Scrum є планування спринта. Для цього треба продивитися свої задачі з гори беклогу, якось їх оцінити та прикинути, скільки з них я реально можу встигнути за тиждень.
Оскільки у мене одноосібна команда в цьому проєкті (а може бути і більш чисельна: може бути залучений другий автор, ілюстратор, бета-читач а-ля тестер тощо), то і оцінювати усе мені, за моїм внутрішнім відчуттям. Як я це робила?
За допомогою методу відносного порівняння. Наприклад, дослідження на тему "з яких молекул складається пластик і чи можлива зворотна хімічна реакція аби розкласти його на первинні елементи" – для мене, як для не фахівця, складна задача, тому ставлю 13 пунктів*, а швидко перевірити історію колумбійського наркоугрупування ФАРК – відносно, проста, тому 3 пункти.
* В Scrum для позначення складності задач, найчастіше використовується ряд Фібоначчі – 1, 2, 3, 5, 8, 13 і т.д., де 1 – це найлегша задача.
На підставі оцінок кожної окремої задачі, обирала кілька з них, встановлювала мету тижня, стартувала спринт в JIRA (це магічний момент, коли починається зворотній відлік днів спринту), і починала безпосередньо працювати.
Виконання проєкту
Писати книгу, граючись в Scrum, виходоло досить натурально. Більшість церемоній, передбачених методологією для виконання проєкту, були придатними.
Refinement (Доопрацювання завдань)
Під час роботи над текстом, іноді з’ясовувалось, що необхідні додаткові дослідження, або я вирішила ввести додаткового героя, або переграти якийсь фрагмент. В таких випадках я просто редагувала існуючі або додавала нові завдання в JIRA та змінювала пріоритети задач. Це документування дозволяло нічого не загубити, нічого не забути.
Планування спринту
Наприкінці кожного тижня, перед запуском нового спринту, я готувала і оцінювала список задач на наступний. Більш детально про це йдеться в попередньому розділі.
Ретроспектива
Після закінчення спринту робила аналіз результатів – чи досягла мети тижня, що з запланованого встигла, що не встигла і чому, чи Agile працює для книги тощо і коригувала процес.
Daily Scrum (Щоденна нарада)
Кожного нового дня я перечитувала попередній написаний фрагмент, щоб зберегти тяглість думки. А також переглядала статус завдань в JIRA, і перевіряла, що робити далі згідно з планом.
Демо
Єдиний ритуал, якого я не робила – це демо (в ІТ така спеціальна процедура демонстрації команді того, що зроблено за спринт), тобто вичитка написаного за спринт уривка бета-рідером. Я вирішила, що критика на рівні малих фрагментів може вплинути на мій текст, мотивацію і вже визначений план. Ще була думка давати текст на вичитку, коли вже готовий цілий розділ, але від цього я також тоді відмовилась з тієї ж причини. Не хотілося перебивати потік. Тому демо я робила самій собі. Перечитувала написане, намагалася критично оцінити та виправляла текст.
Це все може видаватися надто складним, але, насправді, адміністрування процесу (виконання усіх тих церемоній Scrum) займало від 5 до 30 хв на тиждень. Я це точно можу сказати, пам’ятаєте, все в Timesheet!
Результати експерименту
Головний результат – книга написана!
Scrum спрацював! Робота за методологією дозволила мені щотижня просуватися вперед, що в свою чергу добре відобразилося на мотивації, а також допомогла тримати фокус - не «відлетіти в космос» і не вибитись з графіка.
На роботу над книгою загалом пішло 492 години. З яких: 263 години на написання, 66,5 годин на дослідження, 152,5 години на редагування. Це цікавий інсайт, який для мене слугуватиме своєрідним орієнтиром в плануванні роботи над наступними творами. Цифри також демонструють, що саморедагування тексту займає половину часу написання книги.
Кілька прикладів, як саме Scrum був корисний
Після кількох перших спринтів підвів голову мій внутрішній критик, вимагаючи писати-переписувати кожен фрагмент до стану невідомо якого перфекціонізму, і я почала товктись на місці. Ось це зациклювання на якомусь слові чи фразі перебивало потік думок і потім писалось важче. Тут мене дійсно врятував Agile mindset. Я вирішила, що треба гнучкіше підійти до цього завдання – писати як несеться, а потім, на рівні розділу чи навіть коли готова уся книга, дописувати, переписувати, виправляти, вдосконалювати.
Спринти підштовхували, щоби максимально виконати запланований об’єм робіт. Ти ніби змагаєшся сам із собою, береш себе на слабо. І під кінець тижня все-таки витискаєш з себе все можливе, аби тільки зробити поступ. Все як в ІТ проєктах.
Тижневі спринти, які вміщували 2-4 завдання, були вдалим вибором. Швидко бачиш якийсь прогрес. Менша кількість завдань в спринті робить їх виконання досяжним. Отже, плюс до мотивації.
Гра в Scrum була такою цікавою, що перемогла прокрастинатора. Дійсно втягуєшся в процес, орієнтований на досягнення конкретної мети, яка зрозуміла і зафіксована.
Коли я подорожувала по роботі чи у відпустку, а це бувало досить часто, то ставила проєкт на паузу, але по поверненню було дуже легко повернутися в контекст – в JIRA був чіткий план, що робити далі.
Використання Scrum сприяло кращому балансуванню роботи: комбінування творчої частини - написання тексту, з рутиною – дослідження.
Дотримання методології допомогло уникнути хаосу і краще організувати роботу навколо написання книжки. Як і в справжньому Scrum – на етапі формування беклогу я багато чого не врахувала і потім додавала десятки завдань, які легко було впорядкувати відповідно до пріоритетів. Або, коли недооцінювала деякі задачі, і через це вони переходили на наступний спринт, було дуже легко все впорядкувати. Словом, ніколи не стояло питання, що саме робити далі.
Висновок
Іноді, щоб надурити прокрастинатора всередині себе, доводиться вигадувати різні методи. Я перетворила письменницьку роботу в гру, де бавилася в написання книги по Agile. Саме ця гра часто мотивувала мене робити більше і швидше, а також досягти конкретного результату.
По натурі я експериментатор. Мені подобається схрещувати власний досвід з різних сфер. Тому цей гачок, який я собі закинула, «а давай перевіримо, чи Agile буде ефективним для письменника», для мене спрацював на 100%. Зараз можу сказати, що методологія релевантна для такого не ІТ проєкту, як написання книги.
Чи буду я застосовувати цей підхід для роботи над наступними творами? В дещо спрощеному вигляді, напевно так!
***
Підписуйтесь на сторінку в Instagram, щоб слідкувати за анонсами нових блогів.