Упс! Не вдала спроба:(
Будь ласка, спробуйте ще раз.

Надихнулися McDonald's і подвоїли продуктивність: як в Р2Н розв'язали “проблему ОХО”

Дмитро Бреславець
Дмитро Бреславець Співзасновник Р2Н, американської IT-компанії з українським корінням
11 березня 2024 8 хвилин читання

Буває так, що компанія має в штаті потужних фахівців, але отримує посередні, нічим не видатні результати — це так звана “проблема ОХО” і багато хто не знає, як її розв'язати. Ми в компанії Р2Н застосували протилежний підхід — ХОХ — і змогли отримати надзвичайні результати. Крім того, вони оптимізували наявні процеси веброзробки, покращили якість послуг і революціонізували конвертацію дизайну в HTML. Розповім вам про цей кейс детальніше.

Що таке проблема ОХО

Річ у тому, що звичайні процеси, навіть із залученням “надзвичайних спеціалістів”, приносять звичайні результати. Так утворюється “проблема ОХО”, скорочено від “Ordinary, eXtraordinary, Ordinary”. Розвʼязати її можна протилежним підходом — створити надзвичайні процеси, які виконуватимуть “звичайні спеціалісти” і отримувати надзвичайний результат. Це називається XOX-принципом, тобто “eXtraordinary, Ordinary, eXtraordinary”. 

Яскравий приклад бізнесу, що побудований на чітких процесах, — це McDonald's. Велика мережа швидкого харчування відома своєю стабільною якістю та обслуговуванням в тисячах ресторанів по всьому світу, а їхня виручка лише за один квартал складає майже $6,7 млрд. Такий шалений успіх став можливим завдяки багатьом факторам, серед яких суворість до чистоти, ненав’язливі маркетингові “фішки”, зручне розташування ресторанів. Найцікавіше, що всюди в основі лежать процеси, які в McDonald's гарно налагоджені. 

Компаніям як Coca-Cola, Starbucks, Amazon також вдалося розв’язати “проблему OXO” й досягати масштабних і екстраординарних результатів — при цьому наймаючи не суперзірок, але талановитих і кваліфікованих працівників.

Досвід McDonalds для розв’язання задач в ІТ: кейс Р2Н

Отже, як для розв'язання проблеми ми використали досвід «МакДональдс»?

Опис задачі

Від початку діяльності Р2Н, тобто в 2005 році, ми усвідомили, що компанія займе окрему нішу та надаватиме послуги з конвертації дизайну в HTML — тобто розробили “коробкове рішення”. Ми отримували файли від клієнтів із мінімальним описом або без нього та за 8 годин представляли готовий продукт. 

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

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

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

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

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

Р2Н швидко масштабувалася, проєкти ставали складнішими й стало очевидним, що старий метод більше не задовольняв бізнес-вимоги. Так ми стикнулися з “проблемою ОХО” та почали її розв’язувати.

Рішення

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

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

Такий підхід і став розв'язанням “проблеми ОХО”. Він передбачав максимальне документування процесів, прописування інструкцій, яких чітко дотримувалися, та встановлення таймінгів і КРІ на кожному етапі.

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

Результат

Нам вдалося організувати систему, де незалежно від того, хто робив проєкт спочатку, будь-який інженер міг опрацювати фідбек, внести зміни та видати якісний продукт за стандартом. Чіткість, якість і надання результату в стислі терміни стали нашою перевагою: ми навчилися робити складні й об'ємні HTML-сайти за 8 годин.

Після переходу на роботу за ХОХ-підходом, тобто протилежністю ОХО, вдвічі зросла продуктивність — але не тільки. Ми також змогли: 

  • залучати більший пул талантів, потребуючи, при цьому, менше ресурсів на залучення та адаптацію спеціалістів; 
  • виконувати більше проєктів одночасно; 
  • зменшити виробничі витрати в довгостроковій перспективі та швидше зростати; 
  • делегувати контроль якості спеціалістам із меншим рівнем кваліфікації, як-то junior. Своєю чергою, це дало їм більше можливостей для стрімкого професійного зростання в межах однієї компанії та відчуття довіри до них з самого початку;
  • навчати спеціалістів “з нуля” та розвивати їх у команді.

Етап вдосконалення: чому з конвеєра перейшли на Agile

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

Це ні добре, ні погано, просто виробничий процес перестав відповідати задачам. Постала необхідність проводити довші зустрічі між клієнтами й проєктними менеджерами, щоб детально проговорювати вимоги до проєкту. Вже неможливо було надавати шаблонні рішення, адже йшлося про створення цілих вебсайтів на платформах, як WordPress, Magento, Drupal тощо. Адаптація вимагала переосмислення ролей проєктних менеджерів і ІТ-розробників.

Стара система себе вичерпала, тому ми ввели принцип агільності (Agile). Щоб поставити на рейки нові процеси та обслуговування складніших проєктів, ми в компанії частково впровадили принципи холакратії та кластерну систему.

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

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

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

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.
50 UAH 150 UAH 500 UAH 1000 UAH 3000 UAH 5000 UAH
0
Прокоментувати
Інші матеріали

Дизайн дитячого простору: середовище, яке виховує та надихає

Алеся Карнаухова 18 липня 2024 12:28

Інклюзивність в iOS: як забезпечити доступність для користувачів з обмеженими можливостями

Vladyslav Khambir 17 липня 2024 16:40

Як підвищити лояльність клієнтів та залучити нових за допомогою SERM? Кейс Netpeak у ніші біодобавок

Андрій Тарасенко 15 липня 2024 21:23

Як не відволікатись під час роботи за комп’ютером

Олександр Тартачний 11 липня 2024 11:04

Вік не перешкода. Junior Python Developer у 61 рік

Oleh Potichnyi 9 липня 2024 13:32