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

Буває так, що компанія має в штаті потужних фахівців, але отримує посередні, нічим не видатні результати — це так звана “проблема ОХО” і багато хто не знає, як її розв'язати. Ми в компанії Р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 годин.

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

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

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

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

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

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

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