Зберегти бюджет і бізнес: дев'ять порад із пошуку IT-аутсорсу в 2023 році
Як не потрапити в халепу, віддаючи багато завдань сторонній команді
Сьогодні реальний сектор економіки неможливо уявити собі без IT-аутсорсу. За даними Statista, 2023 року глобальний дохід аутсорсингу IT-послуг наблизиться до позначки у $430 млрд. Компанії звертаються до зовнішніх команд розробників, аби не брати на себе непрофільних завдань, отримати унікальну експертизу й послуги найкращих фахівців, а також і заради елементарної економії коштів.
Втім аутсорс може бути не лише вигідною угодою, а й пасткою, яка з’їдає час і кошти клієнта. Як не потрапити в цю пастку й уникнути елементарних помилок, спеціально для Mind пояснює Сергій Гузенко, CEO компанії WEZOM.
Насправді практично кожен інсайдер IT може розповісти вам декілька байок про провальний аутсорс – з власного досвіду або з досвіду своїх колег. Неадекватні обіцянки, втрати дедлайнів на роки, перевитрати початкового бюджету у три-чотири рази, конфлікти виконавців та клієнтів, аж до судової тяганини – у цьому світі буває все.
Може здатися, що замовник убезпечить себе, якщо звернеться до шанованої компанії з гучним ім’ям і беззаперечною репутацією, але це не так. Хрестоматійним є приклад IBM – ця легендарна компанія стояла у витоків сфери IT як такої і залишається одним з її гігантів донині. Та це не вберегло IBM від декількох скандальних провалів.
Найгучніший такий епізод стосується впровадження електронної системи оплати праці для працівників охорони здоров’я на замовлення австралійського штату Квінсленд. Усе почалося з відносно невеликого контакту на 6 млн австралійських доларів. Однак строки робіт затягувались, а вартість постійно переоцінювалася та зростала. Відтак на момент тестування 2010 року проєкт продовжувався на 18 місяців довше, ніж очікувалось, і вже перевищував запланований бюджет на 300%.
Однак це було не головною проблемою, адже система просто не працювала. Спроба застосувати її на практиці призвела до катастрофи: тисячі лікарів і медсестер отримували виплати неправильно або не отримували їх взагалі. Відомо принаймні про 35 000 епізодів помилкового розрахунку, що призвело до масових галузевих страйків та відставки міністра охорони здоров’я Квінсленду. З урахуванням вартості робіт і всіх наслідків, провал проєкту обійшовся платникам податків щонайменше в 1,2 млрд австралійських доларів – це десь $850 млн за курсом того часу.
Цей кейс можна вважати унікальним за своїми політичними наслідками, але не за технічним змістом. Якщо таке може статися з топовою компанією, та ще й під наглядом урядовців в одній з найуспішніших країн світу, то від провалу не застрахований ніхто.
Чому трапляються факапи?
З одного боку, кожен провал унікальний. З іншого – в основі кожного в різних пропорціях лежать ті самі фундаментальні проблеми, що ведуть до неправильної оцінки ресурсів і недооцінки ризиків.
Слабка підготовка до розробки. Деякі клієнти приходять із настроєм зануритися до розробки якомога швидше, адже в них є гроші, і нова платформа потрібна їм «на вчора». Це не найкращий настрій для амбітного проєкту. Відсутність належної уваги до ґрунтовної бізнес-аналітики й бажання якомога швидше покінчити з Discovery Stage можуть боляче вдарити по строках проєкту та кишенях клієнта. У гіршому раз вони призведуть до фундаментальних помилок у ключовій логіці продукту, що роблять весь проєкт марним.
Відсутність бачення результату. Ця проблема може прямо випливати з попередньої, а може проявлятися вже під час розробки. Скажімо, клієнт постійно пропонує для продукту нові фічі, а команда розробки впроваджує їх «на ходу», без адекватної рефлексії для долі проєкту. Відтак продукт стає архітектурно безглуздим: він може працювати й номінально відповідати техзавданню, але буде занадто складним у підтримці, та й просто працюватиме нестабільно.
Проблеми з комунікацією. Існує мільйон способів зіпсувати комунікацію між замовником і виконавцем: від різниці у часових поясах до людського фактору та недостатньої кваліфікації менеджерів. Адже команда розробника та клієнта хоч і говорять однією мовою, але бачать проєкт геть по-різному. Наслідки цієї дистанції можуть бути різними – від суперечки про колір кнопок до важкого рішення повністю перебудувати майже готовий продукт.
Прогалина в цінностях. Дуже добре, якщо клієнт і підрядник сповідують спільні погляди на бізнес та життя як таке, культивують взаємну повагу, проявляють розуміння й емпатію. Тоді вони мають усі шанси стратегічними партнерами. Але, коли клієнт ставиться до аутсорсера зверхньо або розробники вважають, що можуть продати «неприємному» клієнту продукт будь-якої якості – гідного результату досягти не вийде.
Виконавець «не тягне». Трапляється й таке. Деякі команди розробників можуть не мати необхідного вам досвіду, експертизи та виробничих потужностей, але будуть це приховувати або казати напівправду. Іноді молоді команди елементарно переоцінюють свої можливості. І добре, якщо посеред проєкту аутсорсер може чесно пояснити клієнту межі своїх можливостей, а не до останнього вдає, що все добре.
У роботі з аутсорсерами неможливо повністю уникнути ризиків, як і в будь-якому бізнесі. Втім мінімальна обачливість допоможе їх мінімізувати.
Як уникнути проблем з аутсорсом?
За 23 роки на ринку наша компанія виробила декілька власних рекомендацій щодо того, як віддати аутсорс гідній команді та не «злити» бюджет в нікуди.
Шукайте аутсорсера з кейсами у вашій ніші. Команда без досвіду у вашому бізнесі цілком може впоратись з проєктом, якщо в неї все добре з аналітикою, виробництвом і відповідальністю. Але це не точно. Щонайменше, наявність досвіду дозволить скоротити Discovery Stage та пришвидшити розробку.
Цінуйте чесність. Якщо команда розробників відверто говорить, що для реалізації вашого проєкту їй бракує певних ресурсів, адекватно оцінює усі ризики та пропонує рішення, то ви, імовірно, маєте справу з професіоналами. Якщо аутсорсер не у всьому погоджується з вами й обґрунтовано захищає своє бачення, наприклад дизайну, то це теж норма. І навпаки, гучні обіцянки чи відсутність інтересу до результату – це погані знаки.
Починайте з MVP. Не варто розпочинати великий проєкт, якщо у вас є лише бажання та ідея, але ще немає його бачення й детального плану. Розробка мінімально життєздатного продукту дозволить як протестувати на практиці гіпотезу, так і перевірити вашу «робочу сумісність» з аутсорсером.
Не забувайте про культурні відмінності та ментальність. Може здатися, що це дрібниця. Але культура спілкування та ділова етика в різних країнах суттєво відрізняються, і це прямо впливає на комунікацію щодо проєкту та загальний підхід до роботи. У роботі з європейцями це майже непомітно, але, якщо ви працюєте, наприклад, з командою із Бразилії, або з Японії, будьте обачні.
Будьте уважними з документами та зобов'язаннями. Комерційна пропозиція має бути прозорою і написана зрозумілою мовою – без недомовок та двозначних формулювань. Якщо тут є проблеми, то це вже привід замислитись. Переконайтеся, що пропозиція не містить прихованих платежів і будь-яких інших неприємних несподіванок.
Знайдіть відгуки про аутсорсера. З’ясуйте, які компанії вже працювали із цікавою вам командою розробників і попросити в них фідбек. У нас чомусь так не заведено, але на Заході це поширена практика. Це вельми просто, зазвичай успішні команди самі поспішають розповісти про свій досвід та крутих клієнтів, якщо це не заборонено NDA.
Тримайте руку на пульсі. Обов`язково призначте власного продакт-менежера, який буде моніторити перебіг розробки та давати команді розробників увесь необхідний фідбек. Професійна команда лише вітатиме залученість сторони клієнта й забезпечить для цього максимальну прозорість. Врешті, без клієнтського фідбеку розробники завжди ризикують «копати в неправильному напрямку».
Фокусуйтеся на цінності, а не на вартості. Обрати найдешевшу пропозицію по ринку – це не економія, а покладання на себе прихованих ризиків. Розумний підхід криється в тому, щоб отримати найкращий продукт у межах вашого бюджету, аби жоден долар не був витрачений дарма. Переконайтеся, що аутсорсер пропонує вам розробку на актуальних технологіях і має для неї всі необхідні ресурси.
Перевіряйте якість роботи. Рев'ю коду вашого аутсорсера в третьої сторони не буде зайвим, навіть якщо створений ним продукт працює добре. Щонайменше рев’ю підсвітить технічні вразливості проєкту, над якими ще можна попрацювати. А іноді незалежна консультація може вберегти вас від серйозних неприємностей.
Чи можна обійтися без аутсорсу?
Насправді сьогодні межі IT-аутсорсу розмиваються як ніколи, і 2023 року цей тренд лише підсилиться. Цифрові гіганти на кшталт Google та Apple віддають стороннім командам навіть свої профільні та вельми відповідальні напрями роботи. А начебто сервісні компанії будують для своїх клієнтів такі екосистеми та платформи, яким можуть позаздрити і продуктові стартапи, і постачальники хмарних сервісів.
Але аутсорс – це не «рулетка», де можна виграти або програти. Наразі це усталена практика, свого роду галузевий стандарт в IT. Чи можна обійтися без нього? Так, можна вкласти ресурси у власну IT-команду. Питання лише в тому, наскільки це вигідно, наскільки відповідає довгостроковій меті вашого бізнесу. У низці випадків аустсорс не має альтернатив. Але необхідно підійти до нього розумно – правильно обрати команду, виділити відповідні ресурси, оцінити ризики й уникнути типових помилок. Тоді результат вас не розчарує.
Автори матеріалів OpenMind, як правило, зовнішні експерти та дописувачі, що готують матеріал на замовлення редакції. Але їхня точка зору може не збігатися з точкою зору редакції Mind.
Водночас редакція несе відповідальність за достовірність та відповідність викладеної думки реальності, зокрема, здійснює факт-чекінг наведених тверджень та первинну перевірку автора.
Mind також ретельно вибирає теми та колонки, що можуть бути опубліковані в розділі OpenMind, та опрацьовує їх згідно зі стандартами редакції.
