Почати роботу з великим ентерпрайзом – це складно. Перевести роботу над одним проектом у тривале взаємовигідне партнерство – набагато складніше. Але це те, що виводить ІТ-консалтингову компанію на новий рівень, дозволяє отримувати масштабніші проекти, розвивати команду та виходити у світові лідери.
Розповідаємо, як один тримісячний проект трансформувався в комплексну співпрацю та чого це вартувало технічній команді, на прикладі роботи SoftServe з одним з найбільших постачальників рішень у галузі охорони здоров’я у світі.
З чим ми працювали?
Клієнт
Британська корпорація, продукція якої продається у понад 100 країнах. За структурою це холдинг, до якого входить низка підприємств, кожне – зі своєю специфікою.
Його запит
За 16 тижнів мігрувати Proof of Concept (PoC) нового продукту з локального дата-центру в хмару AWS з використанням AWS managed services та інтегрувати його з існуючими CI/CD і Infrastructure as a code.
Глобальна задача, яку ми перед собою ставимо в таких випадках
Максимально розширити дорожню карту проектів, які ми робимо для цього клієнта.
Дисклеймер – було складно, але це вдалося.
Сильна технічна експертиза – не єдине, що допомогло в цьому. Відверто ділимося неочевидними на перший погляд моментами.
На проекті працювала команда Cloud&DevOps Center of Excellence – група експертів з найвищою експертизою, які не є закріпленими за певним довгостроковим проектом для одного клієнта, а залучаються на найскладніші задачі. Більшість експертів, задіяних у цьому кейсі, працюють в київському розробницькому центрі SoftServe.
Нетехнічні виклики технічного проекту
Довіра клієнта до партнера by default не виникає і це нормально
В корпораціях є багато стейкхолдерів, кожен з яких відповідає за свою частину роботи і є в ній експертом. Залучені ззовні фахівці можуть сприйматися як конкуренти чи як ті, хто прийшов, щоб забрати частину їхньої роботи.
У випадку з цим кейсом ситуація ускладнювалася тим, що перед співпрацею з нами клієнт мав негативний досвід роботи з іншим технологічним партнером – йому не вистачило розуміння суті ентерпрайзу і роботи з ним (наприклад, що в кожен процес залучена велика кількість внутрішніх учасників і що затверджене рішення може змінюватися в процесі роботи, оскільки з’являються нові потреби і вимоги). Відповідно, і до нас клієнт поставився упереджено.
Тому першочерговою задачею було довести, що ми є експертами і можемо допомогти.
Розуміючи, наскільки важливо і на перших етапах, і далі в процесі роботи налагоджувати кооперацію з клієнтом, розуміти його контекст і знати, чим саме ми можемо бути корисними йому, ми в SoftServe запозичили практику американських колег і ввели на масштабних проектах нову роль Trusted Advisor. Це експерт, який:
- керує технічними експертами – знає, над чим команда працює, який технологічний стек використовує і т.д.;
- співпрацює з бізнесом – розуміє його вимоги, як вони змінюються та що є актуальним на конкретний момент;
- знає сучасні тренди на ринку технологій та розуміє задачі, необхідні для розвитку клієнта.
Це дозволяє вибудувати двосторонній діалог, коли не просто одна сторона ставить задачі, а друга – їх виконує, а є розуміння ширшого контексту у всіх: клієнт розуміє, що і чому робить технічна команда, а команда – чим зумовлені правки/зміни з боку клієнта. Trusted Advisor – поєднує в собі компетенції архітектора, бізнес-аналітика і технічного експерта. Trusted Advisor залишається з клієнтом довгостроково, в той час як проекти змінюються, а технічна команда ротується, залежно від етапу роботи.
На ринку таких фахівців немає, тому наша задача – вирощувати їх всередині. На цьому проекті саме маємо успішний кейс, коли Trusted Advisor повністю впорався із цією роллю.
Корпорації мають занадто складну структуру, в якій навіть внутрішні стейкхолдери не завжди можуть розібратися
Завелика кількість внутрішніх стейкхолдерів, які не завжди знають про існування один одного і не мають чітко визначених зон відповідальності кожного – велика проблема корпорацій, через яку робота з ними перетворюється у той ще квест.
У цьому випадку ми працювали з такими командами:
- Ключова команда, яка відповідає за хмарну інфраструктуру;
- Команда з безпеки;
- Мережева команда (Networking team);
- Продуктові команди, які живуть незалежно від перерахованих вище.
З кожною з цих потрібно було провести ряд зустрічей, зрозуміти потреби і особливості і завоювати довіру до себе як до експертів. Потім – продумати схему взаємодії.
Саме розуміння культурних особливостей окремого регіону та налагодження внутрішнього нетворкінгу – це ключ до того, що вам вдасться отримати більш довготривалу співпрацю з компанією.
Наприклад, через декілька місяців після старту роботи до нас прийшла одна з продуктових команд із запитом на розробку інфраструктури під аналіз даних і звітність по них. Коли ми запропонували інтеграцію з технологіями, які компанія вже активно використовувала, вони здивувалися, бо нічого про них не чули. Відповідно, ми організували мітинг цієї команди з ключовим стейкхолдером, відповідальним за хмарну інфраструктуру, на якому вони познайомилися і домовилися працювати спільно. А для нас це означало плюс один масштабний проект в дорожню мапу по цьому клієнту.
Охорона здоров’я – специфічна галузь. Не кожне рішення, яке здається оптимальним з погляду технологій, тут підійде
Технологічні рішення в сфері охорони здоров’я дуже жорстко регулюються, оскільки тут мова про зберігання особистої інформації пацієнтів (personal health information, PHI). Основним нормативним стандартом є HIPAA, який накладає обмеження на сервіси для обробки і зберігання цих персональних даних, які можна використовувати. Критично важливо слідкувати за цим. Наприклад, частина сервісів та технологій, які ми хотіли початково використовувати на цьому проекті, взагалі не відповідають HIPAA, деякі AWS managed services – не відповідають HIPAA в певних регіонах.
Окрім HIPAA, є додаткові сертифікати стандартів та вимог безпеки, які треба використовувати. Водночас, потрібно розуміти, що частина з них стосується лише приватних даних (тобто, треба знати класифікацію даних, щоб не робити на проекті зайвих обмежень).
Відповідно, тут задача – знайти оптимальне рішення не лише з погляду технологій, але і законодавства, інакше клієнт нестиме відповідальність.
Потрібно зануритися у проблеми компанії, щоб зрозуміти у потреби і те, як ми можемо принести найбільшу користь
Серед технічних фахівців є тренд вирішувати будь-яку поставлену задачу за рахунок використання хайпових технологій, наприклад Kubernetes. Але це працює не завжди. Інколи вони просто не вирішать задачі. Або їх імплементування коштує занадто дорого, враховуючи потребу змінювати код, архітектуру рішення і тд. Бізнесу головне – отримувати прибуток, відповідно, якщо рішення працює, то інвестувати в його реорганізацію не будуть. Тому при виборі стеку технологій на проект потрібно керуватися реальними потребами.
Окремо варто виділити підхід до реалізації пілотного проекту. Він потрібен перед стартом основної роботи, щоб відтестувати обраний підхід/технологію. В нашому випадку завданням було перенести рішення з дата-центру в хмару. Якби ми тут просто підняли кластери і запустили «Hello, World», яку користь це принесло б? В Інтернеті є купа матеріалів та документації, як це зробити. Нічого екстра в цьому немає.
Однією зі складних задач у роботі з цим клієнтом була вимога розгорнути продукт на AWS інфраструктурі в Китаї. Задача була не з простих, адже це досить специфічний регіон:
- Для AWS це неповноцінний регіон, де вони працюють через локальних провайдерів;
- Суворе локальне законодавство, через яке частина сервісів не працюють взагалі, частина – мають обмежений функціонал.
Зробивши цей проект, ми оцінили, наскільки реально адаптувати продукт до китайського ринку і скільки це коштуватиме. Такі моменти також дають клієнту зрозуміти рівень експертизи партнера і вибудовують довіру до нього.
Готуйтеся бути технологічно сміливими і працювати з такими технологіями, про які ви до цього лише чули
З попереднього пункту не випливає те, що з погляду технологій такі проекти прості. Викликів тут більш ніж достатньо. І щоб їх вирішити, потрібно бути готовими вийти за межі звичного стеку і застосовувати інші підходи. На цьому проекті ми мали можливість попрацювати, наприклад, з Argo CD та GitOps.
Що отримали в результаті?
За 16 тижнів ми реалізували проект, з яким до нас початково і прийшов клієнт:
- проаналізували наявні сервіси та можливості їх перенесення в клауд;
- налагодили комунікацію з внутрішніми командами клієнта і співпрацю між всіма сторонами, залученими в проект;
- зробили HIPAA сумісний хмарний сервіс, куди потенційно було б можливо мігрувати всі проекти клієнта;
- адаптували PoC клієнта до хмарних сервісів.
Зараз в роботі у нас ще паралельно 4 проекти для різних команд.
Такі проекти дають величезний досвід як з погляду hard skills, так і soft skills. Так, є багато викликів, рідко коли все йде за початковим планом, доводиться проявляти винахідливість в багатьох моментах, але зрештою результат того вартий.
Источник: ain.ua
Самые актуальные новости - в 
