Вітаю!
ฅ⁠^⁠•⁠ﻌ⁠•⁠^⁠ฅ

Що було раніше: Курка чи Яйце?

Що першим з'явилося: Колос чи Насіння?

Як авторам потрібно писати: Спершу навчаючись чи Викладати у процесі?

Останнє, до речі, дуже часто бачив тут. І інколи доходило до таких розмов, що хотілося кинути одну палицю між авторами і сховатися - а потім дивитися, хто залишеться "останнім переможцем". ☠️

Це про усі оці питання про "талант", "навчання на коротких формах", "вмію \ не вмію", "організацію" та усе подібне. 

І я завжди дивився на це, як людина, що колись була у ІТ. Не знаю, можливо цей блог допоможе тим, хто зараз вагається, що йому робити. Тим, хто переймається, що недостатньо вкладає зусиль чи не так щось робить. Хто не може зрозуміти, чи якісно він пише, чи ні - коротше для усіх тривожників)))

Кажу як тестувальник з досвідом. У ІТ є 2 основні моделі розробки Програмного Забезпечення (далі ПЗ). Звісно, що їх там значно більше ніж 2, здається їх там десь около 8. Але основні - лише дві. І ці дві моделі показують підхід до створення. І, в цілому, ці моделі можна перенести й на створення книг. Що ж, я задовбав мяукати навколо, давайте вже до суті)

1️⃣
"WATERFALL"
Вона ж "КАСКАДНА"

Називається ця модель так, бо, як Ви бачите, вона йде зверху вниз і ніяк не підіймається. У ІТ ці процеси виглядають так: "збір інформації" потім "дизайн того, як буде виглядати" потім "розробка" потім "тестування" потім "викладання" потім "підтримка". 

Це сувора модель, що не дозволяє помилок. Наприклад, якщо під час "тестування" ми знаходимо помилку в "дизайні", то ми беремо і повертаємося не тільки на попередню стадію, а саме на стадію "розробки", а ще йдемо далі - на стадію "дизайн" і перероблюємо усе там. 

⏳Така модель використовується при розробці банківських систем, систем безпеки, або у медицині. Чому? Бо ціна помилки - занадто велика! Втрата грошей, втрата безпеки, втрата людського здоров'я та життя - тут потрібно працювати уважно й жорстко - і саме "каскадна" модель - жорстка та сувора модель - підходить сюди найліпше! 

2️⃣
"AGILE"
Вона ж "ГНУЧКА"

Ого, а тут бублик! 

Саме так, тут бублик! Тому що Agile модель - це модель постійного апдейту. ✅✊✅

Виглядає це, як постійне оновлення. Тобто перше коло: ми зробили продукт і випустили його до користувача "збирати інформацію". Якщо десь на цьому шляху знайшлася помилка... "Вітаю, ми виправимо її у наступному бублику". Як би Вам це пояснити... Ось уявіть собі книгу, яку хтось пише по частинам. Він її випускає одразу і вона виглядає як "передмова" та "частина 1". Поки людина пише "частина 2" - вона ще може виправляти "частину 1", а також збирати думки читачів для "частини 3". Розумієте? Саме тому ця модель і називається гнучкою. 

І де це використовують? Да скрізь! Я впевнений, що навіть Букнет зробили за Agile-ом. Можна, до речі, спитати у тех.підтримки це))

❄️Дуже цікаво, але навіщо це нам?❄️

Ну, ці моделі, на мій погляд, вирішують вічне питання: "що та як писати?"

На мій погляд усе це зникає, бо є книги, яким взагалі не потрібно йти по каскадній моделі. Якийсь роман можна написати на одному подиху за кілька тижнів, без додаткових налаштувань та "проб пера". І від цього роман не буде поганим! 

А можна писати, звісно, щось величезне, щось, що розмірами навіть буде більше за Гру Престолів (хоча в паперовій версії там "Пісні льоду та полум'я"). І можна довго збирати матеріал, аналізувати, розробляти, прописувати героїв від "3 секунди після народження" до "3 секунди до смерті". І це також буде гарно! А найголовніше - неможливо сказати, що ліпше! 

Ну як Ви скажете, що ліпше: спорткар чи пікап? 

Ну так, якщо ми будемо на гоночній дорозі, то пікап буде виглядати як динозавр у крамниці з посудом. 
Але якщо ми будемо дрова перевозити, то Ви швидко відмовитесь від боліду формули)))

☘️Давайте приклади?☘️

Давайте!

Ось пишите Ви роман і одразу ж його викладаєте. Потім пишите новий, потім новий, а потім ще новий - це дуже довгий Agile. Ви вчитеся на власних спробах. Кожний новий роман - новий бублик, що покращує ВАС. 

Ось Ви довго створюєте світ, аналізуєте інші книжки, щось там вигадуєте події, а потім різко викладаєте 5 томів історії. Вітаю, це Waterfall. 

Але можна і томи однієї історії запхати у Agile! Вже вибачайте, що вставляю сюди рекламу власних творів, але це буде показово, як на мене. 

Ось є в мене історія "Леді замку Саммерфелл" - 5 книг, 2.5 мільйони символів. Ті, хто читав, мабуть Вам підкажуть, що перша книга відрізняється за якістю та насиченням від п'ятої як небо відрізняється від землі. І що з того? Книга не стала гіршою від цього! Просто якість йде на зростання. Тобто тут утворюється той самий Agile, де кожна книга успадковує висновки, що зроблені на минулій. Тож можна навіть великий складний проект реалізувати у Agile. 

☀️Кому що обрати?☀️

Виходимо на фінальну межу! 

Кому що обирати?

Якщо Ви збираєтеся писати багато, у вас є багато ідей - беріть Agile і не катуйте себе думками "а що, якщо вийде неякісно?". З кожною новою історією Ви будете вчитися на попередніх і ставати краще! 

Якщо Ви плануєте написати довгу історію, цикл, серію - та також беріть Agile. Ця модель підійде також. Просто, як я казав вище, книги будуть відрізнятися між собою у якості, що, в цілому, добре, бо видно розвиток!

Якщо Ви плануєте написати одну історію (не важливо цикл чи одна книга) і Ви бажаєте, щоб ця історія увійшла у історію і була найякіснішою - тоді так, тут Вам вже треба розбиратись, багато чого читати, випробовувати себе у різних жанрах. А вже потім йти до історії - тут це Waterfall.

Сподіваюсь, що допоміг комусь...

А з Вами був я
Ваш (хоча я вам не належу)
LibertyFox