Віталій Цимбалюк: як зробити скрам у non-IT компанії?

Я займаюся маркетингом практично все життя. До того, як почав просувати YouTube-канали в One2, я керував відділом клієнтського сервісу в агентстві PROMO. Мене завжди приваблювали інновації, тож зустріч із методологією Scrum була питанням часу.

Як я прийшов до проєктного менеджменту

У рекламному агентстві я став керівником відділу аккаунт-менеджерів. Системи управління проєктами не було. Ми не встигали виконати зобов’язання за договором або робили роботу неякісно. Тому я став трабл-шутером з негативом від клієнтів. Це був шлях у нікуди: я не міг попередити проблему, а працював із наслідками.

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

Я став трабл-шутером з негативу від клієнтів.

Як ми обрали методологію проєктного менеджменту 

Спочатку ми дивилися на Канбан. Він дуже гарно підходить для потокових завдань на зразок багфіксу та обробки заявок у колл-центрі. Але для впровадження Канбана потрібна команда з високими рівнями мотивації та організації. Це був не наш випадок.

Дивилися також на Waterfall. Він хороший для IT-команд, бо через чітку послідовність етапів потрібно писати менше коду, прямуєте по зростаючій. Такий же проєкт у Scrum виглядатиме по-іншому:

робоче «щось» —> налаштування —> оптимізація.

В надежности Waterfall скрывается его недостаток — большой риск сорвать сроки. Бизнес хочет получить результат в ближайшее время, а не прождать целый год, чтобы убедиться: выбранная стратегия не работает. Scrum лишен этой «болячки».

Які інструменти Scrum підійдуть маркетинговому агентству

У Scrum є багато інструментів для роботи з мотивацією:
  • скрам-дошки. У скрам-дошках видно статус завдання і можна визначити, де виник застій (наприклад, занадто багато завдань перебувають на стадії обговорення з клієнтом). Ми дали клієнтам доступ до скрам-дощок, щоб вони могли відстежувати статус завдань. Це колосально знизило навантаження на акаунт-менеджерів
  • щоденні стендапи. Кожен член команди по черзі розповідає про результати за минулий день, дає обіцянку на поточний день і ділиться проблемами. Завдяки щоденному стендапу можна зрозуміти, що відбувається в компанії та як зробити роботу ефективнішою
  • планування. Робить процес роботи прозорим для керівника і клієнта. Ми запрошували окремих клієнтів і разом вирішували, які завдання ставити на наступні спринти.
  • ретроспектива. Можна зрозуміти, яких помилок припустилися, як їх можна виправити (наприклад, як збільшити одночасну кількість завдань у роботі без втрати якості).
  • демонстрація продукту. Це презентація того, що команда встигла зробити за спринт. Кожен учасник команди показує свою частину продукту. Демонстрація продукту дає можливість швидко внести зміни, поліпшити продукт і не витрачати час на ранні презентації повноцінного продукту.
Раніше моєю основною роботою був аналіз негативу клієнта. Після впровадження Scrum ми стали опитувати клієнта для того, щоб зрозуміти, чи в правильному ми напрямку рухаємося. Ми також підняли індекс підтримки споживача (NPS).

Виталий Цимбалюк для Worksection

Які недоліки Scrum для non-IT команд?

У скраму є три головні недоліки:
  1. Бізнес-процеси стають дорожчими. Ми ввели посаду product owner, тому що ніхто з команди не потягнув би таку важливу роль. Це дорогий фахівець. Product owner, як і Scrum master, безпосередньо не створюють цінність, вони перебувають за рамками команди і, по суті, потрапляють у категорію накладних витрат.
  2. Немає зручного сервісу управління проєктами за Scrum для non-IT команд. Раніше ми використовували Jira, але для її налаштування часто потрібно залучати фахівця.
  3. 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. Зменшиться плинність кадрів.
Виталий Цимбалюк и Кристина Лисовская для Worksection

Навіщо потрібен product owner?

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

Що робить наш product owner?
  • формує беклог; 
  • видаляє і розставляє пріоритети завдань; 
  • коригує стратегії на основі даних, отриманих від команди; 
  • відповідає перед клієнтами за результат.

Як ми впровадили Scrum в non-IT компанію

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

Команди сформували під кожен із трьох напрямів SEO:
  1. управління посилальною масою
  2. створення контенту
  3. доопрацювання сайту.
Роботу розбили на спринти, з яких формується місячне планування. Плануючи, ми спробували знизити ризик того, що наприкінці місяця не буде результату.

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

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

Спринт має такий вигляд:
планування —> стендапи > демо > ретроспектива.

Частину команд ми перевели на двотижневий спринт. Врахуйте, що чим довший спринт — тим вищий ризик зірвати терміни.

У роботі використовуємо такі інструменти:
  • покер-планування. Техніка дає можливість оцінити складність і обсяг завдань, які потрібно буде вирішувати під час створення продукту. У покер-плануванні беруть участь усі члени команди. За допомогою карт оцінюють завдання і приймають колегіальні рішення;
  • аналог парного програмування з екстремального програмування. Над завданням працює кілька людей за одним робочим місцем. Наочне втілення правила Одна голова добре, а дві — краще”. Ми використовуємо її в критичні моменти;
  • HADI-цикли. Алгоритм перевірки спірних гіпотез, який допомагає заслужити довіру клієнта. Детальніше про HADI-цикли — трохи нижче.

Що таке HADI-цикли і як їх використовувати? 

Що це? HADI-цикл — алгоритм перевірки гіпотези, який має такий вигляд:

гіпотеза —> перевірка > результат > висновки.

HADI-цикли схожі на петлю Lean Startup:

build —> measure —> learn

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

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

У чому перевага HADI-циклу? Клієнту може здатися, що твоє рішення не спрацює. У відповідь показуєш реальний приклад на основі одного елемента.

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

Виталий Цимбалюк и Кристина Лисовская для Worksection

7 порад про те, як впровадити Scrum, якщо ви — не IT

  1. Почніть із навчання. Почитайте спеціалізовану літературу, сходіть на тренінг.
  2. Визначте, хто ваш стейкхолдер (зацікавлена сторона). І далі працюйте на те, щоб донести цінність і клієнту, і стейкхолдеру. 
  3. Спринт має залишатися незмінним. Не бійтеся змінювати все інше.
  4. Не переводьте всю компанію на Scrum, просто тому що це круто”. Наприклад, наші копірайтери працюють за Канбаном, оскільки у текстів немає пріоритетів — просто їх треба робити якомога швидше.
  5. Визначте оптимальний розмір команди. З мого досвіду це п’ять-сім осіб у non-IT компаніях.
  6. Організуйте окремий робочий простір для кожної команди. Якщо у вас open space офіс, додайте офлайнові скрам-дошки.
  7. Проявляйте ініціативу в реалізації Scrum. Якщо керівництво не розуміє, навіщо потрібна нова методологія, нічого не вийде.
Інтерв’ю брала Христина Лісовська, 
статтю писав Ярослав Борута.
відповісти
Александр Соломиец 20 грудня 2017
Да, челлендж еще тот ) спасибо интересное интервью

esc
Поділитись у
или
Школа PM
Ефективне управління проєктами важливе для продуктивної роботи. Це допомагає систематизувати завдання та відстежувати, як вони виконуються командою. Вибір правильного інструменту для управління проєктами...
8 грудня 2024   •   8 min read
Школа PM
Програмне забезпечення для управління робочими процесами створене для автоматизації процесів, покращення командної співпраці та підвищення загальної продуктивності. У цьому огляді представлено 10 найкращих...
3 вересня 2024   •   12 min read
Школа PM
Правильний вибір програмного забезпечення для управління проєктами може допомогти організувати завдання, покращити командну співпрацю та забезпечити виконання проєктів у встановлені терміни та бюджет...
2 вересня 2024   •   11 min read
Почніть роботу прямо зараз
Введіть, будь ласка, свій справжній email 🙂