Чого я навчилася за рік роботи проджект-менеджеркою у продуктовій компанії
Привіт! Я Настя Немиря, і вже понад рік працюю проджект-менеджеркою у стартапі 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:
- 1
-
2
«SCRUM. Навчись робити вдвічі більше за менший час» — книга Джеффа Сазерленда
- 3
- 4
Ці матеріали дають розуміння не просто про те, що таке Agile, Scrum і Kanban, а й чому вони саме такі й навіщо їх застосовувати. Розуміння філософії, яка стала фундаментом для спринтів, дейліків та ретро, виводить роботу на якісно інший рівень. Наприклад:
- Дейліки проводять не для того, щоб проджект трекав, хто скільки працює, а для того, щоб команда координувалася для досягнення цілі спринту.
- На ретро ми не шукаємо винних, а покращуємо взаємодію, щоб уникнути проблем у майбутньому.
Далі можна доповнювати свої знання актуальним досвідом українських колег, щоб бути в курсі сучасних best practices, вивчати приклади застосування в українському контексті та просто для натхнення. :) Ділюся ресурсами і спільнотами, які регулярно переглядаю:
- Scrum Ukraine: YouTube, telegram
- Артем Биковець:YouTube, telegram
- Agile with Ukraine
- Agile Space
Звісно, не варто забувати про нетворк з колегами з інших проєктів — обмін досвідом завжди йде тільки у плюс.
Вчитись у технічної команди
Я була джуном без ментора-проджекта, тому організації роботи технічної команди я вчилась насамперед у розробників і QA. (А в тому, що стосується бізнесу — збору вимог, пріоритизації завдань, довгострокового планування — вчилась у продуктової команди і стейкхолдерів, але про це пізніше.) Ретроспективно я розумію, що такий підхід заклав фундамент хороших відносин з командою і процесів, які будувались на реальних запитах (а не просто за інструкцією з книжки). Розробники цінують, коли прислухаються до їхньої експертизи та досвіду.
Комунікація
Прийшовши у команду, я б радила провести 1-1 з кожним, наприклад, з таких питань:
- У яких компаніях (продукт / аутсорс), командах (компонентних / крос-функціональних) працював (-ла) раніше? Як виглядали процеси, що позитивне / негативне можеш виділити?
- Що можеш сказати про процеси і взаємодію у команді зараз? Що подобається, які точки росту бачиш?
- Які очікування від мене, з якими запитами можу допомогти?
Я прийшла до цього не одразу, але коли почала проводити такі зустрічі, стала розуміти команду набагато краще. Тепер користуюсь цією структурою і коли в команду приходять нові розробники / QA.
Таким чином я знайомлюсь із командою, розумію, які є очікування і запити, що потрібно робити насамперед.
Також проводжу регулярні 1-1 з кожним раз на 2-3 місяці — запитую фідбек про свою роботу, про процеси у команді загалом; над чим людина зараз працює, які є проблеми, чим можу допомогти. Так я краще розумію, що відбувається у команді, дізнаюсь про проблеми та інші нюанси, які збоку можуть бути непомітні і не виноситись на командні обговорення з тих чи інших причин.
Технічні процеси на практиці
Далі я заглиблювалась у технічні деталі: флоу розробки, які є середовища (локальне / стейдж / прод); як код потрапляє з одного середовища в інше; хто і як проводить code review; які є етапи тестування і як вони проводяться; як відбувається реліз. Вважаю, що це важливо для проджекта — щоб покращити процеси, треба розуміти, що на них впливає.
Мені було дуже корисно спробувати себе в ролі QA. Коли я поставила на телефон додатки для тестування на стейджі і на проді, протестила кілька фічей — зрозуміла весь флоу набагато краще. Також допомогло — принаймні поверхово — розібратись у структурі проєкту. Особливо те, як клієнти взаємодіють із бекендом, а бекенд — з базою даних, напряму впливає на процес розробки і командну роботу.
Підписуйтеся на наші соцмережі
Якщо вирішите розібратись із технічною складовою проєкту — не бійтесь незнайомих термінів, просіть пояснити слова, які чуєте найчастіше. З часом це дає можливість спілкуватись з командою однією мовою і навіть “перекладати” запити розробки для бізнесу.
Приносити цінність бізнесу
Відповідальністю проджекта є ефективні процеси в розробці і “полегшення життя” технічної команди — проте не варто забувати, що кінцевою метою є максимізація business-value роботи команди.
Хто такий «бізнес»?
Насамперед потрібно зрозуміти, хто є ключовими стейкхолдерами для вашої команди:хто ставить задачі, замовляє фічі, має вплив на їх пріоритизацію, очікує на релізи. Зазвичай це менеджмент (якої ланки — залежить від розміру компанії). Далі варто розібратись, як зʼявляються запити у стейкхолдерів. Вони вигадують задачі самі чи збирають запити від своєї команди? Як часто? Який вплив виконані задачі мають на їхні роботу, цілі? В ідеалі, проджект має розуміти цикл життя кожної задачі від виникнення ідеї до кінцевого впливу на метрики бізнесу. Мені тут допомогло спілкування з продактом, дизайнером, аналітиками.
І друге питання: чи є один decision-maker, який несе відповідальність за те, щоб пріоритизувати задачі й правильно передати їх команді (у scrum-фреймворку — Product Owner)? Якщо є, важливо проговорити з ним ролі і відповідальність кожного. Якщо немає, то найімовірніше, цю роль треба буде зайняти вам, а також налагодити процес збору і пріоритизації вимог.
Бізнес vs розробка
Отримавши відповіді на ці запитання, буде зрозуміло, на чиї запити і фідбек насамперед орієнтуватись і як правильно будувати взаємодію між бізнесом і розробкою. Кілька основних порад:
- У перші місяці роботи поспілкуватись 1-1 з ключовими стейкхолдерами, дізнатись про запити і очікування — не тільки від вас, а й від розробки загалом. Підтримувати регулярну комунікацію і запитувати фідбек, де це релевантно.
- Залучати стейкхолдерів до прямої взаємодії з розробкою — запрошувати на зустрічі, особливо на рефайнменти, щоб розказати вимоги і надати бізнес-контекст. Це сильно пришвидшує вирішення питань і зменшує вірогідність помилок.
- Памʼятати, що ви є представником розробки в очах бізнесу і представником бізнесу в очах розробки: вчитись передавати контексти простими словами, підсвічувати непроговорені моменти. Уточнювати вимоги так, щоб вони були прозорими для розробників, а дедлайни — так, щоб вони були прозорими для бізнесу.
Чіткі очікування і відповідальність
Як мінімум, потрібно проговорити зі своїм менеджером, за що саме ви відповідаєте, та які показники ефективності вашої роботи. Після узгодження з менеджером комунікувати про це з командою і стейкхолдерами.
Тут хочу поділитись підходом, який надто покращив мій робочий процес і забустив зростання: не варто чекати, поки менеджер (чи хтось інший) поставить чітке ТЗ і розпише «посадову інструкцію».
Подумайте, як ви можете принести найбільше цінності, що з цього ви б хотіли робити — і почніть робити. Звісно, варто регулярно проговорювати це з менеджером, але можна вже у форматі “Я знайшов(-ла) таку проблему і ось так її вирішую”, або “Мене зацікавила ось ця тема і я вивчаю її, щоб імплементувати в роботу”. Ваша ініціатива буде цінуватись, а ви зможете розвиватись у напрямку, який вам цікавий.
Запитувати, чим варто зайнятись, теж потрібно, але можна не обмежуватись поставленими завданнями.
Оптимізаційна ціль
Є універсальна відповідь на те, чого хоче бізнес від розробки: щоб завдання робились швидко, якісно, дешево й одразу після того, як були придумані. На жаль, все це одночасно існувати не може — потрібно визначити пріоритети.
Коли йдеться про “покращення процесів”, що саме мається на увазі: зменшити time to market, покращити якість і надійність продукту, пришвидшити зміну пріоритетів? Відповіддю і є ваша оптимізаційна ціль.
Найбільше вона залежить від етапу розвитку продукту і поточних бізнес-цілей. Коли я прийшла в команду, фокус однозначно був на швидкості реалізації і адаптивності команди — заради швидкого тестування продуктових гіпотез ми були готові допускати баги та неідеальні технічні рішення. Тепер у нас більше юзерів, помилки коштують дорожче, і бігти можна трохи повільніше — робити релізи рідше, але бути певними, що критичних помилок немає, а реалізація надійна.
Оптимізаційна ціль має бути відомою як стейкхолдерам, так і технічній команді, і — головне — всі мають розуміти, як вона повʼязана з бізнес-цілями. Зміни у процесах і командній роботі мають наближати до оптимізаційної цілі.
Вирішувати проблеми до їхньої появи
Коли я запитувала фідбек про свою роботу у стейкхолдерів, з позитивного найчастіше чула, що стало менше проблем.
Парадокс роботи проджект-менеджера в тому, що її не видно, якщо вона робиться добре. Хороший проджект не гасить пожежі, а запобігає їх виникненню.
Як досягти цієї магії?
- Прислухайтесь до технічної команди. Якщо не виділяти час на техборг регулярно, потім доведеться виділити його багато і одразу. Якщо у спринт взяти більше, ніж точно встигнемо, реліз затягнеться або буде не до кінця протестований. Прості істини, які варто періодично нагадувати бізнесу.
- Надавайте максимальний контекст. Коли команда в курсі бізнес-пріоритетів, усі зосереджуються на дійсно важливому, і серйозні проблеми не допускаються.
- Помічайте точки росту і підсвічуйте їх команді. Колись я запитала, чи можна пришвидшити code review — виявилось, що так, просто до старого флоу всі звикли, як до чогось очевидного. Довгостроково кумулятивний ефект від таких покращень може значно оптимізувати команду.
- Якщо проблеми вже не вийде уникнути, повідомте про неї якомога раніше й одразу поясніть причини. Наприклад, реліз затримується, бо під час спринту зʼявилась нова термінова задача. Часто вчасна і прозора комунікація вирішує половину проблеми.
Що далі?
За 3-4 місяці я розібралась із запитами розробки і бізнесу, закрила основні болі, базово налаштувала процеси у команді і комунікацію з бізнесом. Чим же займатись далі, щоб не вигорати через одноманітність роботи, і продовжувати рости?
Continuous improvement
Цей принцип прийшов в Agile з Kaizen-філософії. Він про те, що потрібно покращувати процес постійно, нехай і маленькими кроками. На практиці це означає не зупинятись на “задовільному” рівні, а постійно шукати точки росту. Якщо очевидних проблем немає, можна задуматись про командну взаємодію, продуктовий майндсет команди, автономність в ухваленні рішень, технічні практики.
Чудовим інструментом для пошуку точок росту є проведення ретроспектив. Поки команду “штормить”, на ретро будуть обговорюватись очевидні проблеми. Якщо ж команда вже не приносить на обговорення так багато тем, раджу поекспериментувати з форматами — приклади легко знайти. Основна задача тут — подивитись на звичні речі під незвичним кутом, задати такі запитання, щоб команда обговорила щось нове, прийшла до нових інсайтів.
Буває й так, що для покращень потрібні серйозні зміни. Коли я прийшла, команда додатків працювала за 1-тижневими спринтами. QA не встигали все протестувати, задачі не завжди вкладались у спринт, і реліз відбувався вже в наступному спринті. “Хвіст” ставав все довшим. Ми довго намагались вирішити проблему дрібними змінами: краще планувати, інакше тестити тощо, але суттєвих результатів це не приносило. У певний момент ми внесли кілька принципових змін одразу:
- перейшли з 1-тижневих спринтів на 2-тижневі;
- визначили ціллю спринту реліз, який має відбуватись у його межах;
- перейшли на спільну оцінку задач і планування по капасіті всієї команди, включно з QA.
Закілька спринтів новий флоу вже працював набагато краще, ніж старий. Тоді я отримала фідбек, що на ці зміни можна було наважитись раніше, як тільки проблеми стали помітними. Тож раджу і вам не відкладати радикальні зміни, якщо вони можуть принести очевидну користь.
Data-driven підхід
“In data we trust” — одна з цінностей SKELAR. Це про те, що в ухваленні рішень ми спираємось на дані, а не на інтуїцію чи субʼєктивну думку. Процесів це також стосується. Корисно слідкувати за agile-метриками, які повʼязані з вашою оптимізаційною ціллю: velocity, lead time, cycle time і т.д. Можна розказати про них команді, домовитись, які з них для вас важливі.
Метрики дозволяють оцінити довгостроковий вплив змін у процесах. Наприклад, коли ми перейшли з 1-тижневих спринтів на 2-тижневі, cycle time за деякий час парадоксально зменшився — спринт став довший, але ефективніший, задачі перестали “зависати” у статусах і потрапляли у реліз вчасно.
Раз на пів року-рік я роблю аналіз усіх метрик, як вони змінились і що на них вплинуло — для команди це класна можливість відрефлексувати роботу і побачити, що змінилось на краще, а над чим ще треба попрацювати.
Залученість у продукт
Вище я говорила здебільшого про delivery, але discovery є такою ж обʼємною і важливою складовою процесу. Що більше ви у нього залучені, то краще ви зможете його оптимізувати. З чого можна почати:
- Проаналізуйте продукт, який вже є. Чому він саме такий? Для чого була зроблена кожна фіча і логіка?
- Збираючи вимоги до розробки, цікавтесь, звідки вони виникли — тут чудово працює правило п’ятьох чому.
- Поцікавтесь, як оцінюється ефект нових фічей. Як проводяться А/B-тести. Які продуктові метрики зараз у фокусі.
Буде чудово, якщо продуктовий майндсет матиме вся команда — намагайтесь створити умови для шерингу цих знань, заохочуйте команду ставити питання і тримайте в контексті.
Далі все залежить від вашої зацікавленості і бачення свого розвитку. З позиції проджекта можна органічно долучатись до бізнес-ініціатив, поступово брати на себе більше відповідальності — не просто передавати задачі, а й долучатись до їхнього створення.
Дотичні теми: фасилітація, психологія, менеджмент
Проджект-менеджмент — це робота з людьми і командами. Лишу тут кілька книг, інсайти з яких допомогли мені в роботі:
- “Секрети фасилітації. SMART-посібник із результативної роботи в групі” — Майкл Вілкінсон
- “Розверніть корабель. Уроки менеджменту від капітана підводного човна” — Девід Марке
- “Why Motivating People Doesn't Work . . . and What Does” — Susan Fowler
- “За межами піраміди потреб. Новий погляд на самореалізацію” — Скотт Баррі Кауфман
- PMBOK — міжнародний стандарт у проджект-менеджменті.
Універсального списку не існує, усе залежить від вашого контексту та інтересів, однак знання у цих сферах точно не будуть зайвими.
Висновки
Отже, «інструкція виживання» для проджект-менеджера початківця у продуктовій компанії:
- вивчати теоретичну базу та сучасну експертизу в Agile-фреймворках;
- вчитись у всіх, з ким працюєте: розробників, QA, дизайнерів, аналітиків, продактів, стейкхолдерів;
- тримати фокус на цінності для бізнесу, балансувати між запитами бізнесу і розробки;
- не зупинятись після вирішення очевидних проблем: шукати шляхи розвитку для команди і поглиблення своєї експертизи.
Я люблю проджект-менеджмент за різноманітність завдань, можливість заглибитись у різні частини бізнесу, знаходити баланс між ними і вести команду до кращих результатів. Якщо це звучить цікаво — пробуйте, і все вийде!