Закриття проєкту

Буває, що проєкт формально ніхто не закриває, і він перетворюється на зомбі-проєкт: користі вже не дає, а ресурси досі забирає. Гру випустили, але команда досі отримує «дрібні задачі по проєкту». Рахунки за тестові сервери досі приходять. Ніхто не може сказати, чи проєкт уже закінчився. Щоб так не сталося, закриття роблять окремою роботою з чітким списком справ.

Що входить у закриття

• Прийняти результат. Засновники офіційно підтверджують, що гра відповідає критеріям приймання (модуль 7).
• Передати в операційну роботу. Після релізу гру підтримує команда підтримки. Їй потрібні доступи, інструкції, моніторинг і людина, до якої звертатися. Про це ми говорили ще в модулі 1: проєкт закінчується, а підтримка триває.
• Закрити контракти. Перевірити, що студія звуку виконала все за договором, розрахуватися і закрити договір (модуль 10).
• Звільнити ресурси. Повернути людей на інші проєкти, вимкнути тестові сервери, скасувати непотрібні ліцензії.
• Підбити підсумки. Фінальний звіт: план проти факту. У студії реліз вийшов на 14-му тижні замість 13-го, а витрати склали близько 299 тис. грн проти 270 тис. за базовим планом і 300 тис. разом із резервом (прогноз з модуля 9 справдився).
• Зберегти документи. Статут, плани, рішення, звіти — в одне місце, де їх знайде наступний проєкт.
• Подякувати команді. Відзначити завершення так само важливо, як і почати. Вечеря після релізу з модуля 10 — теж частина закриття.

Коли проєкт закривають достроково

Іноді проєкт зупиняють до кінця: ринок змінився, вигоди вже недосяжні, гроші закінчилися. Це теж закриття, і пункти ті самі. Вчасно зупинити такий проєкт — спосіб не дати йому стати зомбі-проєктом. Тому навіть після скасування проєкту збирають уроки.

Уроки проєкту

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

• Що вийшло добре. Двотижневі спринти з демо для засновників. Тестування кожного рівня одразу після збирання. Резерв у 30 тис. грн, який покрив перевитрату.
• Що покращити. Механіка і сервер дісталися одному програмісту, і це помітили запізно (модуль 10). Рекламну бібліотеку оновили без перевірки на старих телефонах (модуль 12). Маркетинг почали за два тижні до релізу.
• Де нам пощастило. Програміст не захворів у тиждень перед релізом, хоча код сервера знав лише він. Удача — теж урок: те, що спрацювало випадково, наступного разу може не спрацювати.
• Що робимо інакше. Перевіряти навантаження людей на плануванні. Додати перевірку на старих телефонах у чек-лист релізу. Починати маркетинг з першого тижня. Другий розробник вивчає код сервера.

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