Ми лажаємо: складна розмова про те, як правильно виправляти факапи в ІТ
Помилки та проблеми у роботі компанії – це складна тема, про яку зазвичай не дуже хочеться говорити. Набагато приємніше говорити про свої досягнення та успішні кейси. Але як не крути, публічне обговорення факапів – це дуже сильна терапія, яка допомагає стати краще. У сфері IT помилки - це звичайна справа, тому поговорімо не про те, як їх уникати, а про те, як проживати їх правильно.
Звідки беруться факапи
Розробка діджитал-продуктів – це процес з мільйоном змінних. Ніби ви збираєте просунутий конструктор LEGO з обмеженням в часі, іноді вигадуючи потрібні деталі вже під час збирання. Рідко можна досягти того, щоб абсолютно все йшло за планом. Перераховувати окремі причини помилок можна довго – людський фактор, технічні проблеми, складнощі комунікації, форс-мажор, etc. Я взагалі вважаю, що у всесвіті немає нічого ідеального: людей, предметів, процесів.
На ситуацію можна дивитися й з точки зору статистики – якщо ви зробите дев'ять проектів без проблем, на десятому щось точно піде не так. Факт у тому, що ніхто не застрахований від неприємностей, іноді вони стаються, попри весь досвід розробників та будь-які можливі запобіжні заходи.
Як це буває на практиці
Неприємності на проекті умовно можна розділити на дві категорії: невдалі обставини та невдалі рішення.
Невдалі обставини хоча й провокують стрес, але все ж не такі страшні. Скажімо, незабаром після запуску сайту клієнт без попередження запускає seo-ботів, які кладуть ресурс на лопатки. Або хтось невірно розрахував навантаження на сервер. Проблеми на проектах можуть виникнути під час завантаження великих оновлень, переведення продукту на інші технології, або під час реалізації великої кількості фіч, особливо якщо команда не мала часу на рух за ітераціями.
Важливо своєчасно усувати подібні проблеми й тримати під контролем комунікацію, інакше вони починають провокувати паніку на стороні клієнта. Щоб цього уникнути, ми готуємося до завантаження оновлень заздалегідь й наперед обговорюємо всі наші дії. І якщо ресурс все ж "лягає", то команда розробки вже готова негайно все полагодити.
Невдалі рішення набагато гірші. Погано продумана бізнес-логіка, проблеми з архітектурою, помилковий вибір технологій, etc. Приклади з життя: клієнт замовляє розробку найпростішої програми або MVP, але під час розробки вигадує до неї два десятки нових фіч. А розробники не помічають чи ігнорують очевидні проблеми - з урахуванням усіх нових вимог масштаб проекту змінився, настав час змінювати його архітектуру. Як результат, підсумковий продукт формально вписується в ТЗ, але практично зовсім непридатний до використання.
Подібне трапляється в тому випадку, якщо ролі в проекті розробки ПЗ від початку були розподілені неправильно, або команді не вдалося вибудувати з клієнтом ефективну комунікацію. Відстежити джерела проблеми у таких ситуаціях складно, та й пошук винних мало чим допоможе. Проект потрібно переробляти, втрачаючи час та гроші. Клієнтоорієнтована організація, як правило, закриває такі дірки коштом власного прибутку.
Більше про факапи, які з нами траплялися в роботі і як ми з ними справлялися, дивіться в нашому подкасті.
Хто винен?
Коли у WEZOM хтось зазнає невдачі, то я не розглядаю це як відповідальність окремої людини, чи навіть окремої команди розробників. Лажаємо ми всі разом, це наша спільна відповідальність. Зрештою, клієнтам не важливо, чому стався факап. Якщо це трапилося, значить у нас щось не так із процесами, їх треба покращувати.
Це зовсім не означає, що на помилки не потрібно точково реагувати. Жоден факап не можна залишати поза увагою, ми розбираємо їх до найдрібніших подробиць. Кожен причетний співробітник має твердо розуміти, чому виникла проблема, та яку роль у ній відіграли його дії чи його бездіяльність. Важливо, щоб кожен зробив для себе висновки й не припускався подібних помилок.
Обговорення помилок на наших зідзвонах може бути різким та емоційним, але за фактом ми ніколи не шукаємо “винного”. Бувають ситуації, коли за провалом стоїть конкретний співробітник, і його треба “посварити”. Толерантності до факапів не може бути жодної. Як би це не звучало, але тут працює аналогія з вихованням дітей - це нескінченний процес: планомірне повторення одних і тих самих правил, доки вони не стають базовою нормою.
Як поводити себе з клієнтом у разі факапу
Це ключове питання, адже зрештою клієнтів не цікавлять причини проблем та пошук винних. Вони хочуть одержати те, за що платять гроші.
По-перше, важлива оперативність. В ідеалі потрібно одразу мати на столі кілька варіантів розв'язання проблеми й рухатися за ними. Досвідчений менеджер вже на старті проекту позначить для себе його вразливі точки та накидає кілька сценаріїв "що якщо". І звичайно ж, вживе превентивних заходів.
По-друге, важлива чесність. Потрібно мати мужність сказати клієнту всю правду: "ми припустилися помилки з наступних причин, ми маємо ось такі варіанти її розв'язання". Чесність майже завжди знаходить розуміння, адже наш клієнт - теж людина бізнесу. Він розуміє, що жоден з процесів не застрахований від проблем. За нормально вибудованої комунікації перший стресовий поштовх на проекті буде зустрінутий клієнтом з розумінням.
Найгірше, що може зробити компанія у разі факапу, так це почати "клеїти дурня" - уникати прямих відповідей, замилювати клієнту очі, чи навіть перекладати відповідальність за ситуацію на нього самого. Така практика на ринку є, і я вважаю це слабкою позицією. Помилку можна виправити, а ось репутаційні втрати через неадекватну комунікацію відіграти вже не вийде.
Чи можуть помилки виникати з вини клієнта?
Перекладання відповідальності за проблему на клієнта – поширена тема для розмов у курилках IT-компаній. Адже для створення дійсно крутого продукту, потрібно постійно утримувати фокус уваги клієнта на розробці, а це буває непросто. З іншого боку, є клієнти, які приходять до аутсорсера з власними уявленнями про продукт й наполягають на них до останнього. Навіть якщо розробники розуміють, що їхні уявлення є помилковими.
Я переконаний, що клієнт не може бути відповідальним за результати нашої роботи. Якщо ми називаємо себе експертами та беремо на себе зобов'язання зробити все якісно, з дотриманням дедлайнів та бюджету, то вся відповідальність за результат лежить на нас.
Так, в IT-виробництві є такий момент – бажання та погляди клієнта часом можуть вести проект не туди, куди він, на наш погляд, має рухатися. Але клієнт не може і не має бути експертом у розробці, бо тоді він би до нас не звертався. Наша місія тут – надати дійсно якісний клієнтський сервіс: провести комунікацію належним чином, вказати на всі можливі ризики та проблеми запропонованих рішень.
У таких випадках ми чітко дотримуємося нашої інструкції та відпрацьованого бізнес-процесу: попереджаємо про наслідки того чи іншого рішення, окремо фіксуємо це попередження. І якщо розробники мають рацію, і проект рухається до глухого кута, то ми повертаємося до тієї самої поворотної точки й відпрацьовуємо все заново. Що ж, пошук робочих рішень "методом тику" - це також частина процесу розробки, якісний проект постійно розвивається й переживає безліч ітерацій.
В цьому випадку, наша відповідальність, як професіоналів та знавців ніші - надати клієнту повну та чесну картину проекту. Вжити всіх необхідних заходів для того, щоб уберегти його від помилок, які дорого йому коштуватимуть.
Факапи та “справжня” клієнтоорієнтованість
З огляду на весь свій досвід можу лише дати пораду клієнтам, які шукають аутсорсерів в IT: не вірте красивим обіцянкам. Навіть більше, остерігайтеся розробників, які в усьому з вами погоджуються. Якщо команда аутсорсерів не оцінює ваші ідеї через призму своєї експертизи й не пропонує власних рішень, то вона або не має досвіду у вашій ніші, або (що набагато гірше), їй байдужий успіх вашого проекту. Якщо у розробників немає залучення до проекту, то проблеми та факапи насамперед будуть “замилюватися” та замовчуватися. Аби тільки формально виконати ТЗ, здати проект в реліз якнайшвидше та забути про нього.
Ми давно визнали подібну стратегію провальною, навіть якщо вона в моменті дозволяє заробляти більше. Нам цікавий успіх кінцевого продукту, його фактичний вплив на бізнес клієнта. Адже задоволений клієнт – це лояльний клієнт, він стає нашим партнером на багато років уперед, радить нас друзям. У тому числі й з огляду на те, як ми реагуємо на форс-мажори, виправляємо помилки та “гасимо пожежі”.
Я давно помітив, що у бізнес-менталітеті нашої країни вкоренилися не зовсім правильні уявлення про те, що таке клієнтоорієнтована компанія. Під цими словами часто приховують прагнення догодити клієнту тут і зараз, навіть на шкоду ефективності проекту. Я ж переконаний, що справжні ознаки клієнтоорієнтованості – це чесність, точність та відкритість, а не уникання “гострих кутів”. І в цьому сенсі WEZOM – завжди на 100% за клієнта – за відвертий діалог з ним, за реальне подолання труднощів, за роботу на результат.
