Як я прийшов до проєктного менеджменту
У рекламному агентстві я став керівником відділу аккаунт-менеджерів. Системи управління проєктами не було. Ми не встигали виконати зобов’язання за договором або робили роботу неякісно. Тому я став трабл-шутером з негативом від клієнтів. Це був шлях у нікуди: я не міг попередити проблему, а працював із наслідками.
Я почав шукати якийсь набір інструментів, який міг би виправити ситуацію. Тоді ще не знав про Agile і Scrum, тим паче про те, як застосовувати методологію Scrum у non-IT командах.
Я став трабл-шутером з негативу від клієнтів.
Як ми обрали методологію проєктного менеджменту
Спочатку ми дивилися на Канбан. Він дуже гарно підходить для потокових завдань на зразок багфіксу та обробки заявок у колл-центрі. Але для впровадження Канбана потрібна команда з високими рівнями мотивації та організації. Це був не наш випадок.
Дивилися також на Waterfall. Він хороший для IT-команд, бо через чітку послідовність етапів потрібно писати менше коду, прямуєте по зростаючій. Такий же проєкт у Scrum виглядатиме по-іншому:
робоче «щось» —> налаштування —> оптимізація.
В надежности Waterfall скрывается его недостаток — большой риск сорвать сроки. Бизнес хочет получить результат в ближайшее время, а не прождать целый год, чтобы убедиться: выбранная стратегия не работает. Scrum лишен этой «болячки».
Які інструменти Scrum підійдуть маркетинговому агентству
У Scrum є багато інструментів для роботи з мотивацією:
- скрам-дошки. У скрам-дошках видно статус завдання і можна визначити, де виник застій (наприклад, занадто багато завдань перебувають на стадії обговорення з клієнтом). Ми дали клієнтам доступ до скрам-дощок, щоб вони могли відстежувати статус завдань. Це колосально знизило навантаження на акаунт-менеджерів
- щоденні стендапи. Кожен член команди по черзі розповідає про результати за минулий день, дає обіцянку на поточний день і ділиться проблемами. Завдяки щоденному стендапу можна зрозуміти, що відбувається в компанії та як зробити роботу ефективнішою
- планування. Робить процес роботи прозорим для керівника і клієнта. Ми запрошували окремих клієнтів і разом вирішували, які завдання ставити на наступні спринти.
- ретроспектива. Можна зрозуміти, яких помилок припустилися, як їх можна виправити (наприклад, як збільшити одночасну кількість завдань у роботі без втрати якості).
- демонстрація продукту. Це презентація того, що команда встигла зробити за спринт. Кожен учасник команди показує свою частину продукту. Демонстрація продукту дає можливість швидко внести зміни, поліпшити продукт і не витрачати час на ранні презентації повноцінного продукту.
Раніше моєю основною роботою був аналіз негативу клієнта. Після впровадження Scrum ми стали опитувати клієнта для того, щоб зрозуміти, чи в правильному ми напрямку рухаємося. Ми також підняли індекс підтримки споживача (NPS).
Які недоліки Scrum для non-IT команд?
У скраму є три головні недоліки:- Бізнес-процеси стають дорожчими. Ми ввели посаду product owner, тому що ніхто з команди не потягнув би таку важливу роль. Це дорогий фахівець. Product owner, як і Scrum master, безпосередньо не створюють цінність, вони перебувають за рамками команди і, по суті, потрапляють у категорію накладних витрат.
- Немає зручного сервісу управління проєктами за Scrum для non-IT команд. Раніше ми використовували Jira, але для її налаштування часто потрібно залучати фахівця.
- IT-термінологія в скрамі не адаптована під non-IT компанії. Для IT-компаній є докладні методички, де розписано, як змусити Scrum працювати. Пояснюється термінологія: інкремент — це працюючий продукт, демо — показ того, як продукт працює. У нашому випадку було незрозуміло, як написання контенту відбивається на роботі продукту. А що таке інкремент у SEO? Якщо ми написали текст і розмістили його на сайті — це працюючий продукт? У нас пішло понад три місяці на те, щоб адаптувати IT-термінологію під наші потреби.
Як ми провалили впровадження Scrum
Впровадження Scrum ми почали з об’єднання в команди. І одразу припустилися двох помилок.Помилка №1. В одній команді об’єднали фахівців контекстної реклами та SEO. Логіка така: всі вони залучають трафік на сайти клієнтів і підвищують продажі, а отже, нехай працюють разом. Команда об’єднувалася навколо одного клієнта.
Як розв’язали проблему: з часом ми розділили фахівців за цінностями і продуктами. У деяких клієнтів стало відразу кілька акаунт-менеджерів і команд.
Що зрозуміли: об’єднувати команду потрібно навколо бізнес-цілі. Така команда самодостатня і зможе самостійно зробити цінність для клієнта.
Помилка №2. Не визначили одразу, хто має виконувати функції скрам-майстра і власника продукту.
Як вирішили проблему: функції скрам-майстра додали в навантаження до наявної позиції group accountant. До цього він відповідав за продуктивність команди та безперебійну доставку цінностей для клієнта. На посаду product owner ми найняли окрему людину.
Є дві помилки, які часто зустрічаю в компаніях, які теж впроваджують скрам:
- Команди об’єднують навколо однієї функції. Відділ просто перейменовують на команду. Проблема в тому, що якщо клієнту потрібен сайт, то в команді має бути програміст, дизайнер і менеджер. Відділ маркетингу з бренд-менеджерами сайт не зроблять.
- Компанія боїться зруйнувати поточну структуру. Реальний приклад. Один акаунт-менеджер вів кілька проєктів, з кожним з яких працюють різні SEO-фахівці. Проєкти розподіляються на основі завантаження SEO-фахівців. Припустимо, фахівець отримав у роботу 10 проєктів із різною пріоритетністю. Пріоритети виставляє проєктний менеджер, і в цій компанії їх було кілька. У кращому випадку SEO-фахівець виконував найзрозуміліше завдання, у гіршому — завдання акаунт-менеджера, який більше за всіх кричав.
Об’єднання в «правильні» команди — це болісний процес.
Навіщо потрібен Scrum-майстер?
У Toyota є цікавий кейс на тему скрам-майстра. На заводі до механіка приставили людей для оптимізації роботи. Механіку платили за годину роботи, і платили багато, тож потрібно було збільшити ефективність роботи і зменшити витрати. Побачили, що механік довго шукає потрібний ключ — прикріпили до нього підмайстра, який подавав ключі. Подумали ще й зробили простіше: намалювали на підлозі трафарети для інструментів і підмайстер вранці до початку роботи розкладав їх.
Тож 80% успішного впровадження скраму — це хороший скрам-майстер. Якщо у вас немає людини, яка могла б узяти на себе цю роль, знайдіть того, кому цікаво було б навчатися і працювати далі в цій сфері. У крайньому разі шукайте скрам-майстра в IT-компаніях.
Неочевидні функції скрам-майстра:
- Відчуває, де команда не допрацьовує, де можна прискоритися, а де — краще пригальмувати. Це як щит від палаючих дедлайнів і хаосу.
- Відповідає за відчуття безпеки команди. Зокрема від клієнта, який хоче “зробити все і на вчора”. Наприклад, ми зіткнулися з такою проблемою: акаунт-менеджери довго робили звіти для клієнтів. З подачі скрам-майстра налаштували автоматизовані звіти, які формуються в реальному часі. Тепер клієнт не чекає кінця місяця, щоб зрозуміти, як ідуть справи. Усі задоволені.
- Виводить команду на той рівень, коли вона користуватиметься Scrum за власним бажанням.
- Спілкується з кожним членом команди one-to-one. Про проблеми та болі співробітника. Так junior-фахівці швидше стануть middle, а middle-фахівці — senior. Зменшиться плинність кадрів.
Навіщо потрібен product owner?
Ми не одразу зрозуміли, хто має бути власником продукту і за що він відповідатиме. Ми дійшли до того, що product owner — це технічний фахівець, який добре знається на продукті, може готувати контекстні та SEO-стратегії, доносити їх до клієнта. Тобто це стратег, який каже, що потрібно робити.
Що робить наш product owner?
- формує беклог;
- видаляє і розставляє пріоритети завдань;
- коригує стратегії на основі даних, отриманих від команди;
- відповідає перед клієнтами за результат.
Як ми впровадили Scrum в non-IT компанію
Раніше фахівці працювали окремо: копірайтери та редактори, лінкбілдери та SEO-аналітики. Впроваджуючи Scrum, ми перемішали їх один з одним. Також у кожній команді є акаунт-менеджер, який доставляє цінність клієнтам.
Команди сформували під кожен із трьох напрямів SEO:
- управління посилальною масою
- створення контенту
- доопрацювання сайту.
Із тривалістю спринту ми експериментуємо. Коли тільки почали впроваджувати Scrum, спринт тривав тиждень. Тижневий спринт дає можливість швидко прогнати процес і зрозуміти, де ви помиляєтеся, навчити співробітників і зрозуміти, як все працює.
Ключова рекомендація щодо тривалості
спринту scrum у маркетингу: обирайте термін, якого достатньо, щоб зробити корисну річ.
Спринт має такий вигляд:
планування —> стендапи —> демо —> ретроспектива.
Частину команд ми перевели на двотижневий спринт. Врахуйте, що чим довший спринт — тим вищий ризик зірвати терміни.
У роботі використовуємо такі інструменти:
- покер-планування. Техніка дає можливість оцінити складність і обсяг завдань, які потрібно буде вирішувати під час створення продукту. У покер-плануванні беруть участь усі члени команди. За допомогою карт оцінюють завдання і приймають колегіальні рішення;
- аналог парного програмування з екстремального програмування. Над завданням працює кілька людей за одним робочим місцем. Наочне втілення правила “Одна голова добре, а дві — краще”. Ми використовуємо її в критичні моменти;
- HADI-цикли. Алгоритм перевірки спірних гіпотез, який допомагає заслужити довіру клієнта. Детальніше про HADI-цикли — трохи нижче.
Що таке HADI-цикли і як їх використовувати?
Що це? HADI-цикл — алгоритм перевірки гіпотези, який має такий вигляд:гіпотеза —> перевірка —> результат —> висновки.
HADI-цикли схожі на петлю Lean Startup:
build —> measure —> learn
Як це працює? Ти генеруєш гіпотези, у працездатності яких не впевнений. Якщо завдання зрозуміле і потрібне, його немає сенсу обробляти на HADI-циклі. Після перевірки гіпотези визначаєш, спрацювала вона чи ні, і наскільки добре. Якщо спрацювала — запускаєш на спринт, якщо ні — відкидаєш.
Як це виглядає? Наприклад, є гіпотеза: «Якщо я зроблю перелінковку на товарах, це дасть потрійний приріст трафіку». Перевіряєш гіпотезу на одному товарі, проставляючи вручну посилання всередині сайту. Якщо гіпотеза спрацювала, даєш завдання програмістам: «Зробіть перелінковку на всьому сайті».
У чому перевага HADI-циклу? Клієнту може здатися, що твоє рішення не спрацює. У відповідь показуєш реальний приклад на основі одного елемента.
Документуй гіпотези, навіть якщо вони не спрацювали. У наступному спринті зможеш протестувати іншу. Також стеж за тим, щоб в експериментів не було конфлікту інтересів (наприклад, щоб не тестувалися одночасно гіпотези, пов’язані з однією і тією ж веб-сторінкою). Інакше не буде зрозуміло, яка з гіпотез спрацювала.
7 порад про те, як впровадити Scrum, якщо ви — не IT
- Почніть із навчання. Почитайте спеціалізовану літературу, сходіть на тренінг.
- Визначте, хто ваш стейкхолдер (зацікавлена сторона). І далі працюйте на те, щоб донести цінність і клієнту, і стейкхолдеру.
- Спринт має залишатися незмінним. Не бійтеся змінювати все інше.
- Не переводьте всю компанію на Scrum, просто тому що “це круто”. Наприклад, наші копірайтери працюють за Канбаном, оскільки у текстів немає пріоритетів — просто їх треба робити якомога швидше.
- Визначте оптимальний розмір команди. З мого досвіду це п’ять-сім осіб у non-IT компаніях.
- Організуйте окремий робочий простір для кожної команди. Якщо у вас open space офіс, додайте офлайнові скрам-дошки.
- Проявляйте ініціативу в реалізації Scrum. Якщо керівництво не розуміє, навіщо потрібна нова методологія, нічого не вийде.