«Кожен в компанії мислить як підприємець»: як Jooble розвиває глобальний сайт з пошуку роботи

Jooble — українська IT-компанія, головний продукт якої — сайт з пошуку роботи. Майданчик агрегує вакансії з понад 140 тис. онлайн-ресурсів з усього світу, серед яких — job-сайти, сайти компаній, соцмережі, класифайди. Jooble працює 29 мовами, щодня ним користуються мільйони людей у 67 країнах. Завдяки цьому він входить в десятку найбільш відвідуваних світових сайтів у сегменті Jobs And Employment.

Ми поспілкувалися з ключовими фахівцями Jooble, які безпосередньо відповідають за створення та розвиток продукту. Вони розповіли про свої суперсили та невдачі, показали «внутрішню кухню» продуктової розробки, а також пояснили, які навички необхідні кандидатам, щоб стати частиною команди.

Максим Бєляк,
CPO of Aggregation 

«Проривні рішення виникають на перетині експертиз»

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

Як лідер я визначаю продуктову стратегію: яке в нас бачення, куди ми рухаємося, чому саме туди, як швидко туди прийдемо. Ще одна важлива складова моєї роботи — впровадження найкращих продуктових практик. Мене захоплює можливість впливати на глобальний продукт, у якого майже 1 млрд відвідувань на рік. 

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

Як ідеї стають частиною продукту

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

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

У нас з’явилася мета — зробити так, щоб отримані бізнес-вигоди, зокрема зростання показників, суттєво перевищували витрати на розробку. Тому у 2022 році ми провели зміни в структурі й сформували вісім кросфункціональних продуктових команд розробки. У кожній з них є фахівці різних спеціалізацій.

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

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

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

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

Ми серйозно ставимося до показників і A/B-тестів. У межах експериментів ми аналізуємо не тільки ключові метрики продукту, але й велику кількість поведінкових показників, які дозволяють встановити причинно-наслідкові зв’язки. Нам важливо відстежувати навіть незначні зміни у користувачів, адже Jooble — у топі найвідвідуваніших job-сайтів світу, і це накладає відповідальність.

Найбільший виклик, або як взаємодіяти на перетині експертиз

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

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

Головне — довіряти командам, надати їм простір для творчості та інновацій, допомагати розвиватися.

Саме в такому середовищі минулого року одна з команд всього за місяць запустила мобільний застосунок на всі країни присутності Jooble. За 9 місяців ми досягли 1 млн встановлень!

Найбільший фейл, або чому не варто вкладатися у непотрібні фічі

Нещодавно ми вирішили запустити новий канал комунікації у месенджерах. Але не перевірили гіпотезу, «проскочили» цей етап і одразу перейшли до реалізації. У нас була початкова впевненість, що комунікація в месенджерах — цінна фіча, адже вона є у конкурентів. Зрештою коли запустили A/B-тест, виявилося, що це не надто цікаво нашим користувачам. 

І навіть коли ми не отримали результатів, то все одно не припинили роботу над цим, а спробували все вдосконалити — але теж марно. Зрештою виснажилися і тільки тоді вже зупинилися.

Отримали урок, як не треба робити. Тепер ми не нехтуємо тестуванням гіпотез, а якщо щось не «злітає», то не витрачаємо ресурсів і перемикаємося на щось актуальніше.

Які продуктові менеджери потрібні компанії

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

Наш продуктовий менеджер повинен вміти працювати з командою і стейкхолдерами, розвивати продуктове мислення у колег, разом знаходити найкращі рішення та досягати поставлених цілей. Інші необхідні навички — розуміння продуктових метрик, вміння створювати дорожню карту продукту, проводити інтерв’ю з користувачами, аналізувати ринок і конкурентів, генерувати продуктові гіпотези з коректними очікуваннями. Ще потрібен практичний досвід проведення A/B-тестів та прийняття рішень за їхніми результатами. 

Також для кандидатів буде перевагою, якщо вони працювали зі «зрілими» продуктами на ринках США, Канади, ЄС. Або мали підприємницький досвід: створювали власний продукт, навіть якщо зрештою зазнали невдачі.

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

Ксенія Сорока,
Area Product Manager

«Ми всі однаково сильно вболіваємо за результат і не мовчимо, коли бачимо проблему»

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

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

Мене драйвить свобода дій: у компанії немає зайвої бюрократії, а топменеджери заохочують експериментувати. 

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

Як фічі стають цінністю для користувачів

Коли у нас в команді з’являється ідея нової фічі, ми спочатку з’ясовуємо, чи варто братися за її втілення. Для цього ставимо одне одному запитання: «Яку бізнес-цінність це дасть компанії?», «Якою буде цінність для користувачів?», «Чи є у користувачів потреба у цьому?». Краще відкинути невдалі ідеї одразу, ніж витрачати час на побудову Ейфелевої вежі.

Щоб сформулювати гіпотезу, організовуємо дослідження. Наприклад, проводимо опитування на сайті або інтерв’ю з користувачами, розпитуємо менеджерів підтримки, на які проблеми їм найчастіше скаржаться. Зрештою виносимо нашу гіпотезу на спільне обговорення між командами — колективний досвід і погляд зі сторони допомагає нічого не пропустити.

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

Зазвичай проводимо A/B-тести, а продуктові аналітики стежать, як новий функціонал впливає на поведінку користувачів та на бізнес-показники. 

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

А десь рік тому ми шукали відповідь, як можна дати користувачам додаткову цінність, окрім агрегації вакансій. Відтак з’явилася ідея створити CV Review — сервіс, який дозволяє покращити резюме. Ми знайшли технічного партнера, за допомогою якого змогли швидко втілити MVP (Minimum Viable Product, мінімально життєздатний продукт — Ред.) та перевірити гіпотезу. Наші очікування справдилися. Як результат, тепер ми закриваємо більше потреб користувачів і підвищуємо їхню лояльність.

Найбільший виклик, або як виховати продуктове мислення

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

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

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

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

Найбільший фейл, або чому погана комунікація — часта причина невдач

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

Інший кейс: ми вирішили запитувати у користувачів про їхній досвід, щоб на основі цього надавати їм більш підхожі вакансії. Запустили тестування цієї фічі, але через технічну помилку його побачили тільки 20% запланованої аудиторії. Ми закрили на це очі. А за два тижні зрозуміли, що через малу кількість користувачів не можемо зробити висновки щодо цієї гіпотези. Але в цієї історії щасливий кінець: ми з командою обговорили наші помилки, тож уже під час наступного тесту всі з перших днів активно стежили, щоби все проходило як треба.

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

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

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

Які продуктові менеджери потрібні компанії

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

Крім цього, важливо, щоб кандидат був командним гравцем, націленим на розвиток і відкритим до співпраці з експертами з різних команд. 

Гарний знак, коли кандидат уже на інтерв’ю пропонує нові ідеї або фічі. Отже, людина зацікавлена у тому, що ми робимо, й готова проактивно розвивати продукт.

Назім Сулейманов,
СТО of Jooble

«Кожен рядок коду має працювати на збільшення цінності продукту»

Я прийшов у Jooble 8 років тому на посаду Junior-розробника, а наразі відповідаю за технічну складову компанії: як за стабільність інфраструктури, так і за розвиток фахівців та інженерні практики.

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

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

Як рішення стають кодом

У Jooble — близько 60 інженерів: це розробники, QA-спеціалісти, ліди. Всі вони працюють у складі продуктових команд. Їхня ключова мета — разом з усіма знаходити оптимальні шляхи, щоб створювати цінність для наших користувачів.

Наприклад, продуктова команда ставить собі за мету: «Збільшити повернення користувачів на сайт через email-канал на 5%». Усі спільно вирішують, як це зробити, які експерименти краще провести, а потім оцінюють результат. Інженерам у таких командах важливо мати продуктове мислення, адже кожен рядок коду має працювати на збільшення цінності продукту. 

Загалом об’єднання у кросфункціональні команди, щоб ми всі разом могли домовлятися про кращі рішення, — швидко принесло позитивні результати. Вже за 3-4 місяці кількість продуктових експериментів збільшилася на 30%.

Наприклад, у нас була ціль — підсвічувати для пошукача ключові особливості вакансії одразу в результатах пошуку. Одна з продуктових команд почала працювати над цим, залучивши фахівців з департаменту Data Science. Разом вони сформували підхід до тестування гіпотези, виділили, як хочуть підсвічувати ключові теги, як-от «віддалена робота», «часткова зайнятість», «потребує переїзду» тощо. Команда самостійно провела декілька A/B-тестів, які показали, що завдяки тегам конверсія у відгук після переходу на вакансію — підвищується. Відтак вони запропонували, як можна далі розвивати цей функціонал. У такий спосіб ми змогли швидко пройти шлях від «сирої» гіпотези до реалізованої корисної фічі.

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

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

Найбільший виклик, або як інженеру стати менеджером

Найбільшим викликом для мене був перехід з інженерної посади на лідерську.

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

Але нова роль тимлідера — це зовсім про інше. Вона потребує геть інших навичок і має геть інші показники успіху. 

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

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

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

Найбільший фейл, або як один запит усе «стер»

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

Усе зробив, збирався додому, аж раптом зрозумів, що припустився помилки — позначив геть усі вакансії в нашій системі як неактивні. А отже користувачі не побачать їх на нашому сайті! 

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

Цей досвід став для мене яскравим прикладом, що навіть з надскладної ситуації можна знайти вихід. Але важливо при цьому зберігати холодний розум.

Які інженери потрібні компанії

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

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

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

Антон Золотухін,
Scrum Masters Lead

«Робота лідера — розвивати нових лідерів»

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

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

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

Моя суперсила — я вмію ставити запитання, щоби зрозуміти, що насправді має на увазі людина на рівні сенсів.

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

Як спроможність слухати стає ефективністю в бізнесі

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

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

Інколи доводиться ставити незручні запитання на кшталт: «Яка твоя потреба?», «Що стоїть за цією потребою?», «Імені якого клієнта ми робимо це?». Подекуди вони сприймаються як провокативні. Але нам важливо розуміти, яка потреба насправді стоїть за тим чи іншим запитом щодо розв’язання певної проблеми. Тож відповіді дозволяють розширити контекст і наблизитися до справжніх сенсів — та вже від цього планувати наступні кроки. У такий спосіб можна зменшити ризик, що компанія рухатиметься в хибному напрямку або недоотримає цінність.

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

Зараз ми використовуємо цінності, принципи та основні елементи фреймворку Less Huge. Водночас ми не прив’язуємося до конкретних фреймворків (набір інструментів і процесів для управління продуктами, сервісами, послугами — Ред.), а обираємо їх залежно від цілей, завдань та умов. Наприклад, у перші місяці повномасштабної війни неможливо було дотримуватися звичних процесів, домовленостей й темпу роботи, бо доводилося працювати між вибухами, переїздами, в бомбосховищах, у коридорах. Тож ми відмовилися від Планування двотижневими Спринтами та перейшли на гнучкіший формат. Наш CPO пріоритезував спільний перелік завдань (Беклог), а продуктові команди самостійно обирали, що з цього реалізувати, прогнозували можливі строки і тримали в курсі щодо готовності. У такий спосіб ми змогли адаптуватися до складних умов.

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

Найбільший виклик, або як і навіщо казати «ні» 

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

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

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

Важливо вміти прозоро доносити свої можливості до команд і за потреби говорити «ні». Наприклад, сказати: «Я не можу зараз організувати цикл зустрічей щодо декомпозиції, але можу провести навчання, а потім лише надавати фідбек та менторити». Щоб так комунікувати, потрібно самому знати свої можливості, а також розуміти як власні потреби, так і потреби колег.

Навчальний фейл, або чому важливо звіряти очікування

Рік тому після змін у процесах через війну в нас зросла кількість реалізованих фіч, але якість А/B-тестів при цьому не покращилася. Ми розуміли, що причина не в людях, а в структурі та процесах, тож вирішили їх змінити. Підготували матеріали, презентацію, окреслили коло проблем, які хочемо розв’язати завдяки змінам, сформували очікування від нововведень і команд, відповіли на запитання — і «поїхали». 

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

Найцінніше для мене в цій історії — усвідомлення і прийняття помилки, а також зроблені висновки.

Зрештою ми з командами ще раз проговорили очікування, відпрацювали їх на кейсах та пройшли спільне навчання для побудови розуміння та стосунків. В результаті нам вдалося збільшити кількість та якість А/B-тестів та досягти річної цілі.

Які Agile-коучі потрібні компанії 

Під час спілкування з кандидатами я звертаю увагу на те, як людина ставиться до відповідальності, відкритості, ініціативності, людяності. Наприклад, «я не зробив цього, тому що мені ніхто не допоміг» — не те саме, що «я не зробив, бо сам не звернувся по допомогу». Звісно, інколи виникають справді непереборні обставини, але здебільшого людина має хоча б 5% впливу на ситуацію. І питання у тому, що вона з ними зробить, чи здатна подолати внутрішнє протистояння.

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

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

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

Читайте також

Позитивне лідерство: як зберегти бізнес та команду під час війни

5 ознак, що у вас вийде відкрити власну справу і стати підприємцем

Робота й кар’єрне зростання у сфері outreach: історія спеціалістки з Jooble