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

«Мерседес» посеред шосе і що з ним робити: правила успішної спільної роботи з вендором

Михайло Захаров
Михайло Захаров Custom Division director в P2H
10 квітня 2024 10 хвилин читання

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

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

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

Завдання клієнта — отримати дієвий прозорий продукт 

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

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

Одна з основних проблем в цьому розрізі — часткова чи не взаємопов'язана цифровізація й відсутність комплексних end-to-end процесів. Як наслідок, запит на певну послугу, наприклад, підготовка витягу з реєстру — приходить електронний, але опрацювати інформацію треба руками, проаналізувавши для цього декілька баз даних. Через відсутність необхідних рішень гальмуються наступні процеси, в установах утворюються черги на місяці, ще й на кожному кроці може статися помилка. 

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

Що може завадити: проблеми на шляху

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

Замовники мають обмежений бюджет, негнучкий таймінг і можуть відмовитися від певного рішення, бо не мають відповідних спеціалістів зі свого боку. Для багатьох державних інституцій важливо також контролювати рішення після запуску, тож вони зважають на наявність в команді чи в географічній доступності фахівців, які зможуть далі підтримувати процеси. Це може стати вирішальним фактором. 

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

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

Чим раніше вступити в діалог, тим краще

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

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

У нас була ситуація, коли клієнт чітко не повідомив про свої плани на кінцеві обсяги навантаження на платформу та різке зростання числа користувачів після запуску певних сервісів. Щоб наочно зрозуміти масштаб, як за книжкою, — на фінальних 20% користувачів, які долучилися до сервісу, припало 80% навантаження. Одномоментно трафік зріс кратно, закладених потужностей було недостатньо, а розвʼязувати проблему треба було за лічені години. Довелося вручну імпортувати та переносити дані й підтримувати роботу системи. І всьому цього можна було б запобігти, якби технічну команду попередили заздалегідь. Складнощі з плануванням роботи команди за такого підходу очевидні. 

Золоті правила спільної роботи: чотири ключі до успіху

Кооперація буде успішною, якщо у відносинах «вендор-замовник» вдається чути іншу сторону, навіть якщо вона не хоче необхідним чином підтримувати комунікацію або не розуміє її важливість. Задля досягнення цієї мети, Project-, Delivery- та Account-Manager мусять витратити всю необхідну кількість зусиль та часу. Заощаджувати на цьому не можна. Ми прямуємо до спільної мети й на цьому шляху важливо:

  • 1
    Розуміти головні й локальні цілі: на старті проєкту чи ітерації від клієнта важливо отримати орієнтир, що в цілому потрібно від рішення. Коли команда вендора переглядатиме вимоги чи створюватиме якісь елементи, вона зможе орієнтуватися, чи відповідає воно ідеям і задачам. На прикладі з кейсом, коли навантаження на платформу різко й без попередження зросло в десятки разів: якби плани було проговорено спочатку, то обсяг роботи із навантаженням одразу було б закладено  в архітектуру системи.
  • 2
    Будувати перспективу якомога далі: чим детальніше замовник із вендором обговорює плани, тим краще він уявляє собі генеральну задачу, road map, підбирає спеціалістів, підлаштовує команди. 
  • 3
    Відкрито комунікувати про зміни і не боятись розділити з вендором відповідальність: чим раніше команда дізнається про будь-які зміни, навіть кардинальні, тим краще рішення можна буде знайти, витрачаючи при цьому менше ресурсів і нервів з обох сторін. Якщо клієнт бере на себе всі ризики й ухвалює рішення одноосібно, можуть виникнути неприємні наслідки, як-то прогалини в технічній частині, зайві витрати часу й грошей.

    Гарний приклад тут — клієнт вирішив перевести back-end з кастомного рішення на enterprise-платформу, спираючись лише на власну експертизу. Нашій команді треба було реалізувати задум, хоча ми не розуміли, як ця зміна задовольнить основні потреби замовника. При цьому вона ще й суттєво обмежувала можливості. Але сказано — зроблено. Правда, за декілька років ми знову переводили платформу на інші технологічні рейки, адже рішення було дороге в підтримці та, передбачувано, не спрацювало повністю. Певні проблеми рішення, задля усунення яких все робилось, залишились невирішеними. 
  • 4
    Знаходити золоту середину і виділяти вагоме: певні бізнес-вимоги можуть суперечити один одному. Наприклад, між задачами «зробити швидко» та «додати більше дизайн-елементів і фіч» потрібно знаходити компроміс. І це завжди про діалог. Менше тестів зробити, прибрати щось чи випустити все, проте підсилити бік підтримки, — вихід є, але до нього треба дійти разом. При розробці рішення ми балансуємо між обмеженнями, намагаючись знайти «золоту середину» між часом, коштами, можливостями та інтересами бенефіціарів. Все “подружити” неможливо, тож треба обирати найвагомішу складову.

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


Підбиваючи підсумок

Проєкт може бути успішним навіть за доволі несприятливих обставин. Ми його зробимо і випустимо. Проте ні для клієнта, ні для команди це не буде win-win, адже обидві сторони будуть істотно виснажені нескінченним подоланням проблем, яких цілком можливо було б запобігти. 

Справжня кооперація — це не виконання поставлених завдань, а відкрита комунікація й спільна design thinking культура, тобто те, що підтримує мотивацію з обох сторін, економить гроші та скорочує time to market. Розбудова таких відносин з клієнтом є невіддільною частиною роботи менеджера і команди, навіть якщо клієнт початково не бачить у цьому цінності. Обов’язково побачить — перевірено на власному багаторічному досвіді співпраці.

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

Як залучати крутих фахівців на перенасиченому джунами ринку

Владислав Миронович 5 годин тому

Василь Задворний про стартап медичного неострахування lilo та формування нового ринку в Україні

Олександр Тартачний 5 годин тому

Блокчейн у спорті: як новітні технології змінюють спортивну індустрію?

Владислав Гринів 6 годин тому

Бренд, побудований на провокації: історія Playboy

Артем Беседа 9 годин тому

Data Scientist та Data Analyst: що вони роблять та у чому різниця між ними

Владислав Миронович 12 годин тому