Чого я навчилася за рік роботи проджект-менеджеркою у продуктовій компанії

Привіт! Я Настя Немиря, і вже понад рік працюю проджект-менеджеркою у стартапі Storyby від venture builder SKELAR. Storyby відкриває світу авторів, в яких бачить потенціал створювати бестселери. Команда розробляє продукти, аби історії авторів можна було читати, слухати та взаємодіяти через різноманітний контент. Один із продуктів Storyby — AlphaNovel, маркетплейс новел із транзакційною моделлю монетизації. У нас є застосунки Android & iOS для читачів, вебверсія для читачів, вебплатформа для авторів та внутрішня онлайн CRM-система. Хочу розказати про свій досвід, поділитися кількома інсайтами і порадами, які я була б рада почути на початку шляху.

Як усе починалося

У 2022 році мені пощастило потрапити до Genesis IT School, де я отримала знання про продуктове IT та різні домени бізнесу. Після випуску відкриваються двері у велику кількість партнерських / дружніх до Genesis компаній, серед них — стартапи та бізнеси SKELAR. Зокрема, стартап Storyby. У мене була технічна освіта, пів року досвіду роботи на позиції RPA (Robotic Process Automation) developer і декілька командних проєктів в університеті, де я була в ролі проджекта / продакта.

У Storyby на той час було дві команди з розроблення (одна займалась iOS & Android апками, інша — вебом). У той період технічна команда швидко масштабувалась (5 → 9 людей). Product manager на всіх був один, а обсяги та складність завдань зростали. Тому виникла потреба в людині, яка організує і буде підтримувати якісні процеси, ефективну комунікацію, фасилітувати зустрічі. Так стався метч, і я прийшла у Storyby на позицію Project Manager.

Starter pack: теоретична база + актуальний досвід колег

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

Список матеріалів, з яких, на мою думку, варто починати ознайомлення з Agile-фреймворками на будь-якій ролі, повʼязаній з delivery:

Ці матеріали дають розуміння не просто про те, що таке Agile, Scrum і Kanban, а й чому вони саме такі й навіщо їх застосовувати. Розуміння філософії, яка стала фундаментом для спринтів, дейліків та ретро, виводить роботу на якісно інший рівень. Наприклад:

Далі можна доповнювати свої знання актуальним досвідом українських колег, щоб бути в курсі сучасних best practices, вивчати приклади застосування в українському контексті та просто для натхнення. :) Ділюся ресурсами і спільнотами, які регулярно переглядаю:

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

Вчитись у технічної команди

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

Комунікація

Прийшовши у команду, я б радила провести 1-1 з кожним, наприклад, з таких питань:

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

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

Також проводжу регулярні 1-1 з кожним раз на 2-3 місяці — запитую фідбек про свою роботу, про процеси у команді загалом; над чим людина зараз працює, які є проблеми, чим можу допомогти. Так я краще розумію, що відбувається у команді, дізнаюсь про проблеми та інші нюанси, які збоку можуть бути непомітні і не виноситись на командні обговорення з тих чи інших причин.

Технічні процеси на практиці

Далі я заглиблювалась у технічні деталі: флоу розробки, які є середовища (локальне / стейдж / прод); як код потрапляє з одного середовища в інше; хто і як проводить code review; які є етапи тестування і як вони проводяться; як відбувається реліз. Вважаю, що це важливо для проджекта — щоб покращити процеси, треба розуміти, що на них впливає.

Мені було дуже корисно спробувати себе в ролі QA. Коли я поставила на телефон додатки для тестування на стейджі і на проді, протестила кілька фічей — зрозуміла весь флоу набагато краще. Також допомогло  — принаймні поверхово — розібратись у структурі проєкту. Особливо те, як клієнти взаємодіють із бекендом, а бекенд — з базою даних,  напряму впливає на процес розробки і командну роботу.

Підписуйтеся на наші соцмережі

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

Приносити цінність бізнесу

Відповідальністю проджекта є ефективні процеси в розробці і “полегшення життя” технічної команди — проте не варто забувати, що кінцевою метою є максимізація business-value роботи команди.

Хто такий «бізнес»?

Насамперед потрібно зрозуміти, хто є ключовими стейкхолдерами для вашої команди:хто ставить задачі, замовляє фічі, має вплив на їх пріоритизацію, очікує на релізи. Зазвичай це менеджмент (якої ланки — залежить від розміру компанії). Далі варто розібратись, як зʼявляються запити у стейкхолдерів. Вони вигадують задачі самі чи збирають запити від своєї команди? Як часто? Який вплив виконані задачі мають на їхні роботу, цілі? В ідеалі, проджект має розуміти цикл життя кожної задачі від виникнення ідеї до кінцевого впливу на метрики бізнесу. Мені тут допомогло спілкування з продактом, дизайнером, аналітиками.

І друге питання: чи є один decision-maker, який несе відповідальність за те, щоб пріоритизувати задачі й правильно передати їх команді (у scrum-фреймворку — Product Owner)? Якщо є, важливо проговорити з ним ролі і відповідальність кожного. Якщо немає, то найімовірніше, цю роль треба буде зайняти вам, а також налагодити процес збору і пріоритизації вимог.

Бізнес vs розробка

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

Чіткі очікування і відповідальність

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

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

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

Запитувати, чим варто зайнятись, теж потрібно, але можна не обмежуватись поставленими завданнями.

Оптимізаційна ціль

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

Коли йдеться про “покращення процесів”, що саме мається на увазі: зменшити time to market, покращити якість і надійність продукту, пришвидшити зміну пріоритетів? Відповіддю і є ваша оптимізаційна ціль.

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

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

Вирішувати проблеми до їхньої появи

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

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

Як досягти цієї магії?

Що далі?

За 3-4 місяці я розібралась із запитами розробки і бізнесу, закрила основні болі, базово налаштувала процеси у команді і комунікацію з бізнесом. Чим же займатись далі, щоб не вигорати через одноманітність роботи, і продовжувати рости?

Continuous improvement

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

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

Буває й так, що для покращень потрібні серйозні зміни. Коли я прийшла, команда додатків працювала за 1-тижневими спринтами. QA не встигали все протестувати, задачі не завжди вкладались у спринт, і реліз відбувався вже в наступному спринті. “Хвіст” ставав все довшим. Ми довго намагались вирішити проблему дрібними змінами: краще планувати, інакше тестити тощо, але суттєвих результатів це не приносило. У певний момент ми внесли кілька принципових змін одразу:

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

Data-driven підхід

“In data we trust” — одна з цінностей SKELAR. Це про те, що в ухваленні рішень ми спираємось на дані, а не на інтуїцію чи субʼєктивну думку. Процесів це також стосується. Корисно слідкувати за agile-метриками, які повʼязані з вашою оптимізаційною ціллю: velocity, lead time, cycle time і т.д. Можна розказати про них команді, домовитись, які з них для вас важливі.

Метрики дозволяють оцінити довгостроковий вплив змін у процесах. Наприклад, коли ми перейшли з 1-тижневих спринтів на 2-тижневі, cycle time за деякий час парадоксально зменшився — спринт став довший, але ефективніший, задачі перестали “зависати” у статусах і потрапляли у реліз вчасно.

Раз на пів року-рік я роблю аналіз усіх метрик, як вони змінились і що на них вплинуло — для команди це класна можливість відрефлексувати роботу і побачити, що змінилось на краще, а над чим ще треба попрацювати.

Залученість у продукт

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

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

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

Дотичні теми: фасилітація, психологія, менеджмент

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

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

Висновки

Отже, «інструкція виживання» для проджект-менеджера початківця у продуктовій компанії:

Я люблю проджект-менеджмент за різноманітність завдань, можливість заглибитись у різні частини бізнесу, знаходити баланс між ними і вести команду до кращих результатів. Якщо це звучить цікаво — пробуйте, і все вийде!