Як обговорювати Vendor Lock-in з зацікавленими сторонами

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

Ключовий словник

** Захоплення постачальника ** — ступінь, до якого переключення з певного постачальника буде складним або дорогим, через те, наскільки глибоко їхні власні інструменти або API інтегровані у вашу систему. “Ми маємо значний блокування постачальника з цим постачальником - міграція означатиме переписування наших шарів автентифікації, розрахунків і зберігання одночасно.”

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

** Переносимість ** — це легкість, з якою систему або її дані можна перенести до іншого постачальника або середовища. “Ми зробили переносимість нашого шару зберігання пріоритетною, використовуючи стандартний API, сумісний з S3, тому зміна постачальника пізніше не потребує переписування.”

** Пропрієтарний API ** — інтерфейс, унікальний для певного виробника, не заснований на відкритому стандарті, який підвищує блокування при глибокій інтеграції. “Їхній власне API для фонових завдань не сумісний з будь-яким іншим провайдером, що є головним джерелом нашого ризику блокування там.”

** Шар абстракції ** — шар коду, вставлений між вашою програмою і API виробника, розроблений для того, щоб полегшити зміну постачальника пізніше. “Ми додали шар абстракції навколо постачальника платежів, тому майбутній перехід означатиме переписування одного модуля замість того, щоб торкатися кожної частини кодової бази.”

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

• “Хоча ми задоволені цим постачальником сьогодні, ми задокументували стратегію виходу на випадок, якщо ціни або умови значно зміняться.” *

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

• “Оскільки ми так заблоковані, наші переговори при продовженні контракту слабкі - вони знають, що зміна коштуватиме нам більше, ніж будь-яке зростання цін.” *

** Стратегия мультихмарності / мультипродавця ** - навмисне розповсюдження завантажень або залежностей на більше ніж одного постачальника для зменшення ризику блокування. “Ми не повністю мульти-хмарні, але ми зберігаємо наш склад даних портативним, особливо, щоб уникнути повної залежності від екосистеми одного постачальника.”

Пояснення ризику для зацікавлених сторін

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

Використовуються альтернативні та інші способи

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

Прийняття рішень

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

Професійні поради

1. ** Фрейм-локація з точки зору вливання, а не тільки технічної залежності. ** “Ми маємо слабкішу переговорну позицію при оновленні” резонує з бізнес-зацікавленими сторонами більше, ніж абстрактні архітектурні проблеми.
2. ** Коли це можливо, вкажіть вартість переходу на інший пристрій на реальних прикладах. ** Конкретна цифра або минулий досвід переконливіші, ніж гіпотетичне попередження.
3. ** Надати варіант середнього шляху, а не просто так або ні. ** Шлях абстракції або часткова переносимість часто є простішою для продажу, ніж повне уникнення корисної можливості виробника.

Практичні вправи

1. Поясніть менеджеру продукту, в 3-4 реченнях, що таке блокування постачальника і чому це важливо, навіть якщо ви задоволені постачальником сьогодні.
2. Напишіть коротку пропозицію (4- 5 речень) щодо додавання шару абстракції, щоб зменшити ризик блокування при новій інтеграції.
3. Написати повідомлення, у якому буде документовано рішення щодо стратегії виходу з угоди з постачальником, з яким ваша команда вирішила прийняти ризик замикання.

Національні мови: мова мовлення — мова, що використовується для спілкування національних меншин

Хорошо, давайте скажем, что вам поручили пояснить потенциальные риски замыкания на поставщике группе менеджеров по продуктам и руководителей маркетинга. Ви розумієте технічні аргументи – власні API, складності міграції даних, відсутність співпраці – але перекладати це на ясну, переконливу мову для людей, які в першу чергу думають з точки зору частки ринку і придбання клієнтів, може бути складно. Ключовим є визнання того, що різні аудиторії потребують трохи різних підходів, і, що найважливіше, оснащення себе конкретним словником, щоб уникнути жаргону і ефективно повідомляти про свої проблеми.

Однією з поширених пасток є просто заява «ми заблоковані в цьому постачальнику». Це відчувається обвинувачуючим і негайно робить вас суперником. Замість цього, зосередьтеся на формулюванні ризика - більш нейтрального і менш емоційно зарядженого терміну. Ви можете сказати щось на зразок: « Наша поточна залежність від платформи [Назва виробника] становить потенційний довгостроковий ризик для нашої гнучкості і гнучкості. Хоча вони пропонують значні переваги в [спеціфічній області], важливо, щоб ми проактивно оцінювали наслідки повної залежності від їх технологічної дорожньої карти, яка може не ідеально відповідати змінюючимся потребам ринку. “Це негайно переносить увагу від звинувачення до стратегічного розгляду. Інша корисна фраза – «майбутні обмеження», що говорить про обмеження, які можуть виникнути в майбутньому.

Розгляньте повідомлення Slack, яке ви можете надіслати після коментаря про перегляд коду, пов’ язаного з інтеграцією постачальника. Нетехнічний користувач може бути заплутаний технічними термінами, такими як « API choking ». Ви можете відповісти: « Дякую за звернення уваги на цю проблему, [Ім’ я користувача]. Я погоджуюсь – нам потрібно забезпечити безперервний обмін даними. Поточна архітектура вводить потенційні * майбутні обмеження *, якщо виробник значно змінить свій API, що може вимагати значних переробок з нашої сторони. Давайте розглянемо варіанти з поетапним розгортанням і надійним тестуванням інтеграції, щоб зменшити цей ризик. “Зауважте, як ви переформулювали технічну проблему в бізнес-орієнтовану - майбутні витрати на переробку, оперативну ефективність.

Нарешті, при описі потенційних альтернатив під час опису PR для нової функції, що вимагає доступу до постачальника, уникайте слів «Ми * повинні * використовувати цього постачальника. » Замість цього спробуйте «Щоб максимізувати наші можливості і довгострокову стратегічну гнучкість, ми оцінюємо рішення, які пропонують [спеціфічні переваги], зберігаючи сумісність з відкритими стандартами. Цей підхід дозволяє нам швидко пристосовуватися до змін ринку і уникнути потенційних проблем з блокуванням постачальника. » Використання таких фраз, як «стратегічна гнучкість», «сумісність з відкритими стандартами» і «адаптивна стратегія» демонструє складне розуміння бізнес-контексту і розташовує вас як проактивного, а не реактивного.