Англійська для технічних оцінок постачальників: порівняння інструментів і створення справи
Master the English of evaluating tools and vendors: framing criteria, running a proof of concept, weighing trade-offs, and presenting a recommendation. For engineers and tech leads.
У певний момент вашої кар’ єри вас попросять « оцінити варіанти і рекомендувати інструмент ». Незалежно від того, чи це база даних, платформа спостереження, чи постачальник інтегрованих систем, * технічний * аналіз — це лише половина роботи — інша половина — це повідомлення про це: визначення критеріїв, проведення справедливого порівняння і винесення рекомендацій, яким довіряє керівництво. Цей посібник дає вам англійську, щоб зробити це переконливо.
Складання оцінки
Почніть з визначення * того, як ви вирішите * перед тим, як поглянути на будь- який інструмент. Англійською мовою це evaluation criteria і requirements.
- «Дозвольте мені викладити критерії перед тим, як ми порівняємо продавців»
- «Я б розділив це на обов’язкові і приємні»
- «Наші ключові вимоги є X, Y і Z; все інше є вторинним.»
- “Я оціню кожен варіант за однією і тією ж рубрикою.”
Словник:
- необходимо-мати / гарно-мати / розрив-договору
- ** зважені критерії ** — деякі критерії мають більше значення
- ** матриця оцінювання / рубрика ** — рамка порівняння
- ** поза сферою дії ** — явно виключено
“Перед порівнянням, дозвольте мені викладити критерії. Необхідні - це відповідність SOC 2 і управляна пропозиція. Приятні - це сильний інтерфейс користувача і щедрий безкоштовний рівень. Multi-cloud is out of scope for now. (англійською)
Запуск дослідження концепції
Коротка випробувальна версія для перевірки інструменту є доказом концепції (PoC) або пілотним. Дієслова:
- ми **запустимо **показовий **програмний **інструмент **випробуємо його
- ми покрутимо шини (неформально: перевіримо на практиці)
- ми контролюємо це за нашим робочим навантаженням
- ми ** підтверджує ** ключові припущення
“Замість того, щоб вирішувати на папері, я ** запустив би двотижневий PoC ** з нашим реальним навантаженням, ** еталонною ** затримкою і ** перевірив **, що шлях міграції реалістичний. ”
Фрази для того, що ви перевіряєте:
- Чи не тримає він під навантаженням?
- Який у вас досвід роботи з ними?»
- «Що таке повна вартість власності, а не тільки ціна наклейки?»
- «Як це заблоковано?» (як важко покинути)
Словник порівняння
Коли ви зважуєте варіанти, вам потрібна порівняльно- точніше мова:
- «На папері, A виглядає краще, але на практиці B було гладше»
- «A ** edges out ** B on performance» (англійською)
- «B є головою і плечима вище решти в документації.»
- «Вони ** приблизно на рівні ** для основних функцій.»
- «A є ** ясним лідером **.»
- «C є не-стартером, тому що в ньому відсутній SSO»
Мова ступеня:
- незначно/немного/значительно/значительно лучше
- промив (без значної різниці)
- а шаг изменился (большой скачок)
«На сирій продуктивності вони **приблизно на рівні **, але на **досвіді розробника **, інструмент A **голова і плечі вище ** інших. Це ** вирішальний фактор ** для мене.”
Говоря о стоимости честно
Цена - це більше, ніж ціна. Ключовим терміном є ** загальна вартість власності (TCO) **:
- Ціна на стикері/ціна в каталозі проти ціна за домовленістю
- TCO — ліцензія + операції + міграція + навчання
- ** Приховані витрати ** — платежі за вихід, рівень підтримки, надлишкові платежі
- Ціна за місце / за використання / за фіксованою ставкою
- ** Локальна вартість ** — вартість виходу пізніше
“Ціна ** в списку ** є конкурентоспроможною, але як тільки ви враховуєте ** платежі за вихід ** і ** вартість міграції **, реальна ** TCO ** приблизно на 30% вище, ніж це виглядає. Я б відкинув ціни в переговорах»
Название рисков без убийства сделки
У кожного інструменту є недоліки. Зазначте їх як контрольовані, якщо вони не є дійсно фатальними:
- «Головний ризик це блокування продавцем, але це контрольоване з шаром абстракції»
- «Моя зауваження — це мала спільнота — менше відповідей, коли ми застрягли»
- «Є ризик залежності: вони молодий стартап»
- Це розрахована ставка — сильний продукт, невизначеність довголіття компанії
Розрізняти тяжкість:
- делай-брейкер - это исключает
- ** червоний прапор ** - серйозно, потребує розслідування
- ** незначна проблема / незначний недолік ** — невеликий
Представляю рекомендацию
Прими решение, а потом обосновай его. Не заставляйте руководство ждать ответа на анализ:
“Моя **рекомендація - це інструмент A. ** Це єдиний варіант, який відповідає всім нашим обов’язковим, він вирізняється на полі досвідчених розробників, і TCO в межах бюджету. Головний компроміс - це менша спільнота, яку я зменшую за допомогою внутрішньої документації»
Структурування фраз:
- «В нижній частині лінії перед: Я б пішов з A.»
- «Ось причина для **А..”
- «Один з них — це я»
- Якщо б ми мали вибрати друге місце, це було б B. ”
Коли ти справді не впевнений:
- “Честно говоря, это близко. Я ** схиляюся до ** A, але я можу бути переконаний в B, якщо вартість є пріоритетом. “
Фрази для оціночної зустрічі
Запрошую до огляду:
- «Підтримайте це — я хочу тестувати рекомендацію.»
- «Чи я важу критерії так, як би ти?»
Відповідь на тиск продавця:
- «Я ціную демо, але я б хотів ** перевірити ** це з нашими власними даними.»
- Це сильне твердження — чи можете ви ** підтвердити це ** з еталоном? ”
** Завершується: **
- “Якщо немає заперечень, я продовжу з А і почну план розгортання.”
Нерідко виникли проблеми з ненадійними інженерами
- ** « Порівняти A з B » проти « порівняти A з B ». ** Існують обидва варіанти, але для оцінки подібних параметрів, * порівняти A з B * є більш ідіоматичним.
- **Скажите “цена”, когда вы имеете в виду TCO. **Используйте общую стоимость владения, чтобы звучать старше.
- ** Перебільшення недоліку. ** “Це жахливо в X” вбиває довіру; “це слабше в X” точне.
- Поховали рекомендацию. Начало с нее - “нижняя строка впереди.”
- **“Продавець” вимовляється ** - /ˈvendə(r)/, наголос на першому складі.
Ключевые вещи
- Визначте обов’ язкові до використання проти приємних до використання і групу оцінювання до того, як* ви поглянете на будь- який інструмент.
- Перевіряйте за допомогою PoC і benchmark на вашому реальному навантаженні — не на слайдах постачальника.
- Використовуйте точну порівняльну мову: * краї, на парі, голова і плечі вище, не-стартер.*
- Аргументувати вартість як ** загальна вартість власності **, включаючи приховані та замкнені витрати.
- Починайте свою рекомендаційну статтю з нижньої лінії вперед, потім поясніть — і назвайте одне застереження чесно.
Науковий напрямок: «Системи управління дорожнім рухом»
Успішно керувати оцінки постачальників залежить від більш ніж просто заявивши вимоги; це про їх вираження з точністю і ясністю. Поширеною пасткою для не-рідних носіїв англійської мови є надмірно формальна мова або нездатність виразити тонкі відмінності в значенні, особливо при детальному описі технічних потреб. Розглянемо декілька реалістичних сценаріїв, де уточнення вашої фрази може значно вплинути на результат обговорення з постачальником.
Уявіть, що ви брали участь у перегляді коду, що стосується інтеграції з новим API. Замість простого повідомлення « Цей API повільний », у якому не вистачає деталей, які можна використати, спробуйте щось на зразок: « Під час тестування на доказовість концепції з допомогою служби [Назва API] я спостерігав проблеми з затримкою. Початкові виміри показують середній час відповіді, що перевищує 200 мс - значно впливаючи на продуктивність програми. Чи можемо ми дослідити оптимізацію структури запиту або, можливо, дослідити альтернативні варіанти маршрутизації, щоб зменшити цю проблему?» Зауважте, що ця фраза надає вам конкретні точки даних (200 мс) і пропонує конкретні рішення, сприяючи продуктивнішому діалогу. Аналогічно, якщо ви створюєте опис запитів на звантаження для компонента, який надає виробник, уникайте нечітких вказівок на зразок « Цей компонент потребує тестування ». Замість цього, будьте прямими: « Ми вимагаємо всеохопних тестів модулів, які охоплюють всі основні функціональні можливості цього модуля, включаючи краї і сценарії обробки помилок. Будь ласка, надайте звіти про тестування, що демонструють дотримання стандартів кодування нашої команди»
Крім того, критичне значення має оволодіння розмовами Slack. Просте, дещо незграбне повідомлення - “Це добре?” - може не отримати необхідну інформацію від представника продавця. Замість цього, вкажіть контекст вашого запиту: « Ми оцінюємо [Назва інструменту] на предмет його можливостей масштабування. Чи можете ви розібратися, як він працює з одночасними користувачами і піками обсягу даних? Ми особливо зацікавлені у розумінні обмежень поточної архітектури. » Це показує, що ви зробили домашнє завдання і справді шукаєте конкретні деталі, що спонукає до більш докладної відповіді. Пам’ятайте, щоб завжди бути ввічливим і показувати повагу до часу продавця - чітке спілкування будує довіру і зміцнює стосунки.
Нарешті, при представленні рекомендації після дослідження концепції, уникайте простого зауваження «Інструмент X краще». Структуруйте ваш аргумент навколо чітко визначених критеріїв: «Заснований на нашій оцінці проти ключових вимог, описаних в RFP - включаючи еталони продуктивності, можливості інтеграції і підтримку постачальника - ми рекомендуємо інструмент X. Його продемонстрована здатність досягти [Специфічна метрика] відповідає безпосередньо нашим потребам, особливо враховуючи потенціал довгострокової масштабованості. Ми задокументували ці результати і підтримуючі дані в заключному звіті. ” Сфокусування на вимірюваних результатах і вирівнювання ваших рекомендацій з попередньо встановленими критеріями робить ваш аргумент набагато більш переконливим і менш схильним до суб’єктивних інтерпретацій.