Як займатися менеджентом в інді студії?

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Синхронізація команди, зрозумілий напрям компанії та налагоджена комунікація між відділами — це основа ефективної роботи. Кожен департамент повинен чітко розуміти, коли і хто очікує від нього певні дані, моделі і т.д. Щоб цього досягти, побудуйте roadmap, або в Gamirare ми їх називаємо overview — дуже деталізований опис/план проєкту, звідси ми можемо встановити набір фіч та проблем які можуть виникнути, поставити запитання й оцінити їх в часі та ресурсах. Запускаючи подальшу роботу варто постійно повертатись до overview та оцінювати що перетинається з новою фічею й чи коректно вона поєднується з іншими, що потрібно передати сусіднім департаментам.

Overview можна розбити на певний відрізок гри/продукту — milestones. Для загального розуміння напряму залишається overview, а milestone слугують для поточної роботи. Обсяг роботи має бути чітким, зрозумілим і посильним, щоб виконати його в певний проміжок часу. Наприклад, місяць, зрозуміти швидкість роботи вашої команди та який обсяг роботи ви можете охопити — це шлях спроб та помилок. Комунікуйте з вашими спеціалістами та не бійтесь змінювати щось. Частиною цієї комунікації є ретроспектива, загальне обговорення яке має вести медіатор — якщо ви помилялись, обговоріть це і знайдіть спосіб як цього уникнути. Не бійтесь того що ви щось не знаєте, не вмієте чи провалились. Тільки у книжках є «успішний успіх», а в реальній розробці ви встигнете ще набити синців) Вміння визнати помилку і вирішити її, одне з ключових які потрібно буде випрацювати.

Не останнє, але ключове це зони відповідальності. За певні процеси мають відповідати люди які мають найбільшу в цьому експертизу. Є рішення які може ухвалити лише девелопер, він/вона може аргументувати своє рішення і пояснити його команді. Прислухайтесь до своїх лідів напрямів, не створюйте набридливий мікроменеджмент та попіклуйтесь про те, щоб команда бачила чіткий вектор розвитку що компанії, що ваших продуктів. Саме таким чином, з команди 5 людей ми зараз виросли до 60. Можна ще багато чого розповісти, але це вже не коментар, а ціла серія статей :)

Навряд, є граматичні помилки, але написано дуже локанічно і реально по ділу.

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

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

Підписатись на коментарі