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

Журналіст і медіаменеджер Робін Квонг у своєму підручнику про проєктний менеджмент у медіа докладно пояснює, чому треба робити підсумкові зустрічі, що саме треба занотувати, коли проєкт нарешті закінчився, та чому архів підсумків проєктів допоможе медіа зростати. Це четвертий та останній розділ із підручника.

Основне із першого розділу ми публікували в тексті «Що таке проєктний менеджмент у медіа й чим він відрізняється від управління продуктом».

Вибрані поради із другого розділу читайте в тексті «Команда, дедлайни та показники успіху: докладні інструкції для медіаменеджерів про старт проєкту».

Підсумки третього розділу читайте в тексті: «Стартувати правильно: що треба знати проєктним менеджерам у медіа про першу зустріч із командою».

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

«Дорожня карта» після запуску

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

1. Невідкладні завдання. Це основні завдання проєкту, які треба виконати протягом тижня чи максимум через місяць після дати запуску, бо їх просто не можна було виконати раніше (наприклад, просування контенту та маркетинг). З технічного боку проєкт не завершиться, доки вони не будуть виконані, водночас журналісти мають глибоко вкорінену тенденцію розглядати дату публікації як остаточний дедлайн. 
2. Розширення. Це завдання та ідеї, які віднесли до категорії бажаних, або ж навпаки непотрібних. Їх необов’язково виконувати, але повторний перегляд необхідний, аби зрозуміти, чи ваша думка щодо них не змінилася, якби не було негайного тиску через запуск проєкту. Навіть якщо вона не зміниться, мати впорядкований список цих питань буде корисно для подальшого навчання. Для WSJ Money Challenge (курс WSJ, де учасники проходили шеститижневий челендж із практичними завданнями та порадами щодо ведення власного бюджету) це включало ідеї як повернути читача на сайт wsj.com після виконання кожної вправи курсу, створення різних «рівнів складності» для вправ і пошук способів розширити стосунки з читачами, які пройшли курс.
3. Обслуговування/оновлення. Ці завдання схожі на категорію «невідкладні завдання», але їх треба планувати пізніше, а не одразу після запуску проєкту. В ідеалі їх можна передати команді, яка контролює відповідну сферу (або ж менеджер проєктів може передати ці завдання операційному менеджеру). Утім, реальність у більшості редакцій така, що делегування неможливе, тому треба бути ментально готовим до того, що саме керівнику проєкту доведеться відстежувати ці завдання. У проєкті WSJ Money Challenge ця категорія включала перевірку контенту для оновлення кожні шість місяців, а також повторне надсилання заявок на участь у конкурсі на здобуття нагород, коли закінчувалися терміни їхнього подання. 

Розрізняти запуск проєкту та продукту

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

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

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

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

Докладніше про те, хто такий продакт-менеджер і що входить до його обов’язків читайте у нашому тексті.

Аналітика: які результати?

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

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

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

1) дає широку відповідь на питання: «Чи все йде добре?»;

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

Цей попередній звіт дасть вам час, щоб зібрати більше даних і проаналізувати інші питання, аби у наступному повному звіті ви могли зосередитися на інсайтах.

Ретроспективна зустріч

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

Можна використовувати онлайн-дошку, наприклад Google Jamboard або Miro. Якщо ж усі беруть участь особисто — фізичну дошку та наліпки. Розділіть дошку на чотири секції: «Що пройшло добре», «Що пройшло погано», «Що ми маємо зробити по-іншому наступного разу» і загальна секція.

Після короткого вступу про порядок денний та мету зустрічі попросіть кожного записати свої думки про те, що пройшло добре, на (віртуальній чи фізичній) наліпці. Учасники мають написати по одній думці на папірці та використати стільки наліпок, скільки захочуть. Встановіть таймер на три-п’ять хвилин, і протягом цього часу ви або інший фасилітатор групуйте наліпки зі схожими тезами. Після цього варто одразу ж повторити той самий процес для «Що пішло погано» без обговорення написаного. Роздуми про те, що не пішло за планом, часто штовхають на думки про покращення роботи, тож краще їх зафіксувати.

Останній крок перед обговоренням — попросіть кожного написати на наліпках «Що ми маємо зробити по-іншому наступного разу», а також будь-які інші думки, які не вписуються в цю рубрику (в загальний розділ). Далі використовуйте отримані кластери на дошці, щоб полегшити обговорення. Якщо учасників порівняно небагато (менше ніж 10), можна прочитати кожен папірець і попросити прокоментувати написане. 

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

Wrap deck

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

Це корисно з кількох причин. 

• Управління знаннями редакції. За умови старанної практики, з часом ваша редакція накопичить бібліотеку таких wrap deck. Це формує інституційні знання та полегшує іншим доступ до минулих проєктів. 
• Wrap deck підштовхує до роздумів про представлення знань медіа реальній аудиторії. Це може бути внутрішня (стейкхолдери, ваш відділ тощо) або зовнішня аудиторія (наприклад, журналістська конференція). Публічна розмова про проєкт — хороший спосіб віддати належне всім, хто працював над ним.

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