Методологія керованого хаосу для розроблення проєктів

Несвіт Богдан, COO компанії Bear games, поділився з App2Top.ru своїм матеріалом про суть управління хаосом у рамках керівництва ігровою компанією.

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

Саме тому поступово виділився окремий термін - керований хаос. Ця методика є гібридною і основна її мета - ефективна побудова роботи компанії в умовах СНД ринку.

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

У стандартній ситуації у компанії є пул проєктів, над яким вона веде роботу. При цьому в кожного проєкту є власна виділена команда розробників, що дає змогу говорити про матричний підхід до розробки. Якими будуть процедури управління проєктом, чи то методологія PMI, PMI2 або PRINCE2, це вже питання другорядне. Тут усе залежить від специфіки роботи компанії і від специфіки її потреб.

СИТУАЦІЇ, В ЯКИХ ТРАДИЦІЙНИЙ РОЗПОДІЛ РЕСУРСІВ ЕФЕКТИВНИЙ

1. Проєкт великий або на проєкт робиться велика ставка

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

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

2. У компанії є стабільне фінансування і немає стимулу до змін

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

3. Пул проєктів суворо обмежений їхнім малим числом

Припустимо, що компанія робить 1-2 проєкти і нових у неї немає, або вони будуть робитися строго після перших двох проєктів. Сама ситуація не підштовхує до того, щоб щось змінювати. Завдання ставляться тільки за цими проєктами, всі сили концентруються саме на них, немає необхідності щось оптимізувати, тому що ресурси, що звільнилися, нікуди подіти.

4. Компанія спеціалізується на великих хардкорних проєктах

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

5. Компанія займається аутсорс- або аутстаф-розробкою

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

Загалом, після прочитаного здається, що в усьому цьому суворому розподілі обов'язків і суворому розподілі людей за проєктами немає мінусів. У компанії кілька проєктів, на кожному проєкті своя команда під управлінням свого проєкт-менеджера, є чіткі обов'язки і чітка відповідальність, усі щасливі. Але, насправді, мінуси є.

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

СИТУАЦІЇ, В ЯКИХ ЕФЕКТИВНИЙ КЕРОВАНИЙ ХАОС

1. Багатопроєктність - основоположна стратегія розвитку компанії

В одній зі своїх численних доповідей CEO & Founder нашої компанії Михайло Харківський розповідав про те, що таке багатопроєктність, у чому її переваги та недоліки. Подивитися його можна на головній сторінці компанії Bear games, або на youtube каналі компанії Bear games. Він розглядав багатопроєктність з погляду глобальної стратегії розвитку компанії, а в даній статті ми щільно стикаємося з багатопроєктністю і розглядаємо методику побудови робочих процесів і управління компанією за багатопроєктності.

2. Компанія займається розробкою власних проєктів

Коли компанія розробляє власні проєкти, її руки не пов'язані зовнішніми зобов'язаннями. Вона сама розставляє пріоритети за проєктами і завданнями, вибудовує процес роботи з урахуванням власних особливостей і внутрішніх обставин. Усе це дає змогу чітко планувати свою роботу, робити її передбачуваною і такою, що легко піддається аналізу.

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

3. Компанія спеціалізується на казуальних або мідкорних проєктах

Цей пункт не аксіома, але істотно полегшить імплементацію розглянутої методики.

Хардкорні проєкти самі по собі складні, тому їх складніше прогнозувати і ними складніше оперувати. Набагато складніше. А ось казуальні проєкти простіше прогнозувати, простіше планувати, простіше розробляти. Відповідно, зменшуються ризики, пов'язані з неправильним плануванням процесу розробки. У вас з'являється чіткіша картина розподілу ресурсів на тому чи іншому етапі, що дає змогу з великою точністю підраховувати часові відрізки, на які ресурси можна задіяти на інших завданнях.

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

У ЧОМУ СУТЬ КЕРОВАНОГО ХАОСУ?

1. Дає змогу запускати безліч проєктів одночасно за мінімальних ресурсних витрат на етапі старту робіт

Звісно, ви все одно підключите необхідні ресурси, або наберете в сумі необхідну кількість годин. Від цього нікуди не дітися. Але ви зробите це тоді, коли вам це зручно, а не на старті робіт! Тобто ключова думка в тому, що, щоб запустити проєкт, зовсім не обов'язково відразу залучати повноцінну команду. Можна спочатку почати робити концепт-арт, наприклад, або одразу намалювати всі вікна UI, а потім уже робити код. А можна взагалі використовувати готові рушії ігор для редизайну або випуску нового проєкту на основі старого. Варіантів маса.

2. Дає змогу максимально оптимізувати ресурси

У компанії кожен співробітник чимось зайнятий, немає ніякого тимчасового простою і ніякої розслабленості. Навіть якщо у вас невеликий стартап, ви все одно можете розвиватися наперед, роблячи заготовки під нові проєкти.

3. Дозволяє швидко перекидати ресурси з проєкту на проєкт

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

4. З'являється готовність до будь-якого розроблення

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

5. Дозволяє швидко розширювати свій бізнес

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

6. Дозволяє варіювати напрямки розвитку компанії

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

ПЕРЕВАГИ КЕРОВАНОГО ХАОСУ

1. Економія ресурсів розробки

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

2. Грамотний розподіл ресурсів

Розподіляючи ресурси, ви завжди маєте можливість оптимізувати їх. Припустімо, для відтворення UI в казуальних і мідкорних проєктах не завжди потрібен сильний художник. Найчастіше достатньо посадити на два-три тижні кваліфікованого артиста UI, який відмалює концепт головних інтерфейсів і 2-3 другорядних вікна, а потім замінити його на джуніора або іншого дизайнера ("технаря"), який не малює концепти, зате добре робить методичну нудну роботу на зразок складання інтерфейсів на основі вже готових концептів і макетів.

3. Нижчий бюджет на розробку всіх проєктів

Досить очевидний пункт: коли ресурси не простоюють, автоматично скорочується бюджет на розробку проєкту.

4 Економічно вигідні пропозиції для партнерів

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

5. Можливість запускати більше проєктів

Якщо у вас є вільний ресурс, чому б не почати робити нову роботу? Наприклад, у вас звільнилися дизайнери - починайте малювати концепти для нових проєктів. І, як уже було сказано, не обов'язково повноцінно запускати проєкт! Можна, наприклад, спочатку намалювати графіку, а через два місяці почати робити код. Або навпаки, спочатку робити код на заглушках, а потім уже залучити дизайнерів до процесу розробки.

6. Спрощене планування роботи компанії

Коли у вас заздалегідь визначені потенційно нові проєкти, з'являється можливість більш грамотно планувати роботу компанії наперед і мати план її розвитку. Коли ви чітко розумієте, які у вас є напрацювання (наприклад, три місяці тому ви намалювали концепт для потенційно нового проєкту або у вас є готовий рушій для HOG проєкту), набагато простіше ухвалити рішення щодо подальших планів, відповідно, набагато простіше будувати стратегію розвитку компанії та дивитися в майбутнє. До того ж наявність чітких планів позитивно впливає на співробітників, адже вони впевнені в завтрашньому дні й почуваються комфортніше.

7. Підвищення кваліфікації співробітників і компанії загалом, завдяки отриманню досвіду роботи у всіх жанрах і напрямках

Дуже важливий пункт. Проблема багатьох розробників у тому, що вони роками сидять на 1-2 проєктах, тому досвід їхньої роботи досить обмежений. Якщо ж розробник постійно перемикається між проєктами, він отримує більше досвіду роботи в різних проєктах, жанрах і напрямках. І важливо дотримуватися адекватності ступеня переходу між проєктами: девелопер не повинен "стрибати" туди-сюди по десятку проєктів; він повинен "ходити" між двома-трьома проєктами, і щойно закінчується один, натомість йому дається інший. Тобто загальний пул його завдань має бути обмежений таким числом, яке дає певне навантаження на різних завданнях. Але стек його завдань не повинен бути непосильним, а перемикання між проектами не повинно забирати багато часу і моральних сил. Спочатку буде важко, але поступово девелопери звикають до такого режиму роботи. Це лише питання звички.

8. Можливість "заткнути" слабкі місця в команді компанії

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

ЧИННИКИ, ЯКІ ДАЮТЬ ЗМОГУ КЕРУВАТИ ХАОСОМ

1. Чітке планування проєктів і ресурсів на них

Для скорочення ризиків, пов'язаних з термінами роботи і датами додавання\зменшення ресурсів на проєктах, життєво необхідні роадмапи за термінами, за людьми і за завданнями. Розуміючи, на яку дату вам потрібні ті чи інші ресурси, і на який термін вони будуть задіяні, набагато простіше планувати всю роботу загалом.

2. Своєчасне виконання завдань на всіх стадіях розробки і, як наслідок, своєчасне звільнення ресурсів

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

3. Кваліфікація керівної ланки, від СЕО до тім лідів

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

4. Розуміння суті поставлених завдань

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

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

5. Єдина стандартизація процесів розробки всередині компанії

Щоб спростити процес "ходіння" з проєкту на проєкт і максимально скоротити час "входу" в проєкт для будь-якого розробника, необхідно стандартизувати процеси розробки всередині компанії. Потрібно розуміти, що якщо у вас ігри на Flash, то всі повинні писати, припустимо, на чистому флеші або на однакових фреймворках. Не повинно бути такого, що хтось із девелоперів віддає перевагу PureMVC, хтось Robotlegs, а хтось узагалі "пиляє" власний движок. І в підсумку, щоб увійти в проєкт на власному рушії, будь-кому зі сторонніх програмістів знадобиться зайвий час. У таких умовах говорити про безболісне "перекидання" ресурсів дуже складно.

6. "Подушка безпеки"

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

7. Необхідні гарантії, що співробітники не звільняться за короткий період

Життєво важливо мати гарантії того, що ви не втратите співробітника на середині розробки, адже через це зламається весь ланцюжок із поточних і майбутніх завдань. Яким чином їх отримати? Легко: починаючи від підписаних контрактів, за якими співробітник зобов'язується відпрацювати N часу саме у вашій компанії, та закінчуючи особистими домовленостями, якщо ви працюєте в компанії друзів. Є й інші численні варіанти, напевно у вас буде своє рішення цього питання. Основна думка в тому, що, маючи такі гарантії, можна не боятися будувати плани наперед. І якщо раптом співробітник вирішить звільнитися, у вас буде достатньо часу для його повноцінної заміни.

НЕДОЛІКИ ТА "ВУЗЬКІ МІСЦЯ" КЕРОВАНОГО ХАОСУ

1. Терміни розроблення можуть розтягуватися

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

2. Недостатня кваліфікація розробників

Якщо рівень розробників недостатній, стек їхніх завдань поступово заповнюється і з'являються накладки за завданнями. Звідси починаються запізнення за термінами і всі проблеми, що випливають.

Цей ризик усувається:

Шляхом тієї самої "подушки безпеки"

Ви ідентифікували проблему, тут же накинули додаткові ресурси або замінили ресурс, вирішили проблему.

Шляхом постійного посилення команди новими сильними кадрами

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

Шляхом зростання кваліфікації всередині компанії

Поступово ваша команда набирається досвіду і з часом починає брати на себе дедалі більше й більше завдань, видаючи дедалі якісніший результат.

3. неправильне планування розробки

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

4. Імовірність з керованого хаосу перейти до некерованого

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

5. Залежність від безлічі факторів і специфічність самої методології

Звичайно, є цілком очевидне розуміння, що ця методологія підходить далеко не всім і не у всіх ситуаціях. І що для її впровадження необхідно провести багато попередньої роботи і звести воєдино багато чинників. Однак, як показує практика, багато хто, особливо розробники-початківці, вже давно скотилися до хаосу. Тому чому б не почати керувати ним?

6. Інші ризики та підводні камені

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

Загалом, на цьому етапі можна завершити стислий тезовий розгляд особливості цієї методології управління робочими процесами всередині геймдев компанії. Чому вона отримала назву саме "Керований хаос"? На практиці методика доволі специфічна і потребує великої кваліфікації, великого досвіду в геймдеві. І інколи збоку здається, що управління десятьма і більше проєктами доволі хаотичне і логічно не зрозуміле, породжує безлад і анархію. Але якщо ви зрозумієте її суть, модернізуєте під власне середовище і зможете успішно застосовувати на практиці, то результат буде приголомшливим.

Звісно, як і в будь-якої медалі, тут є два боки. І цілком можливо, що в один прекрасний момент ви зрозумієте, що "щось пішло не так". Але дайте собі чесну відповідь: "Як часто у своєму житті ви завершили проєкт, який пройшов без сучка і задирки від початку до кінця, причому не тільки за документами, а й у реальності?". Ідеальна розробка можлива тільки на папері, вам у будь-якому разі доведеться вирішувати цілу купу проблем. Так чим же проблеми і ризики, пов'язані з шаблонною розробкою, перевищують проблеми і ризики, пов'язані з керованим хаосом?