How to Negotiate Technical Scope Professionally

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

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

---

«Відмова» — це відмова, а не відмова

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

“Я не можу взяти на себе зобов’язання до п’ятниці” — це відмова. “Якщо ми визначимо пріоритет потоку автентифікації, я зможу доставити його до п’ятниці. Функція звітів буде готова наступної середи. Чи це працює?» — це переговори.

---

«Від чого залежить рівень»

Коли і як його використовувати

«Це за межами сфери застосування» є законною і необхідною фразою, але її потрібно донести в контексті, а не як стук дверей.

“Ця функція виходить за рамки того, що ми погодилися на старті. Я був би радий створити окремий квиток для нього і ми можемо приоритизувати його в наступному спринті. ”

• “Початковий запит не включав підтримку багатьох валют. Додати його на цьому етапі вимагає перебудови модуля ціноутворення - це значна зміна обсягу. Чи можемо ми обговорити, як з цим впоратися?»* “Це технічно не входить до сфери цього проекту, але це розумна річ, яку можна бажати. Я можу дати вам приблизну оцінку, якщо ви хочете розглянути це для Фази 2. “

М’які альтернативи

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

---

Мінімальний можливий підхід

Предложение МВП

** MVP ** (Minimum Viable Product або Minimum Viable Approach) — це найменша версія можливості, яка забезпечує цінність. Представлення MVP є потужним інструментом переговорів — він переносить розмову з «так або ні» на «скільки, до якого часу»

• “Яке мінімальне значення нам потрібно надіслати, щоб перевірити це з користувачами? Ми можемо побудувати спрощену версію зараз і ітерувати на основі зворотнього зв’язку.”* “Я пропоную почати з ручного процесу — ми можемо автоматизувати його на Фазі 2, як тільки ми підтвердимо, що робочий процес є правильним.” “Повний фільм займе шість тижнів. Версія, яка покриває 80% випадків використання, буде мати два. Чи буде MVP прийнятним для запуску?»

Використовує фрази МВП

• “Яка найменша версія, яка була б корисною?”
• • « Чи можемо ми зараз закодувати це і зробити налаштовуваним пізніше? » *
• “Давайте доставим основную функциональность и отложим крайние случаи.”
• “Тонкий скибочка через весь потік буде достатньо для демо.”

---

Переклад з англійської мови

Пропозиція фаз

** Фазовий підхід ** розбиває велику область на послідовні поставки. Це дає зацікавленим сторонам видимість раннього прогресу при управлінні складністю.

“Я б запропонував розбити це на три фази: Фаза 1 охоплює основні операції CRUD; Фаза 2 додає інтеграцію з стороннім API; Фаза 3 вводить панель аналітики.” “Ми можемо доставити Фазу 1 за три тижні. Це дає маркетинговій команді щось, щоб продемонструвати, поки ми будуємо решту фаз» “Ризик від виконання всього одночасно полягає в тому, що якщо вимоги зміняться — що часто буває — ми будемо мати створені речі, які нам потрібно скасувати. Поетапний підхід дозволяє нам перевірити на ранньому етапі.»

Позитивні фази

• “Фаза 1 приводить вас на рынок быстрее.” * “Кожна фаза дає реальну цінність - ми не просим вас чекати шість місяців, щоб побачити що-небудь.” “Цей підхід зменшує ризик, дозволяючи нам вчитися на реальних випадках використання, перш ніж приймати рішення про повне впровадження.”

---

Мова торгівлі

Визначення окремих категорій

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

• “Ми можемо додати цю функцію, але це пересунуть дату доставки з 1 жовтня на 22 жовтня. Чи прийнятний цей компроміс?»*
• “Ми зможемо виконати завдання вчасно, якщо вилучити модуль звіту з цього випуску. Чи це працює, чи є звітування важкою вимогою?»*
• “В цьому випадку існує три змінні: обсяг, час і якість. Ми можемо налаштувати будь-які дві, але не всі три одночасно.”*

Класичний трикутник

*“Швидко, дешево, добре - вибери два. Зараз ми зосереджені на якості і швидкості, тому обсяг повинен бути гнучким»

Специфічні фрази для торгівлі

• • “Якщо ми додамо X, нам доведеться відкинути Y або розширити хронологію.” *
• “Компроміс тут - між швидкістю доставки і довгостроковою підтримкою.”
• • “Ми можемо зробити це швидко, але ми накопичимо технічний борг, який нам доведеться розглянути пізніше.” *
• “Ціна того, щоб зробити це зараз, порівняно з тим, щоб зробити це пізніше…”

---

Підвищений тиск

Коли інші учасники відступають

“Я розумію, що термін важливий. Допоможіть мені зрозуміти, яка з цих вимог є найкритичнішою, і ми зможемо з’ясувати, що можна відкласти. ”

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

Пропозиції варіантів, а не ультиматуми

“Ось три варіанти. Вариант А - все доставить до 1-го ноября. Вариант Б передбачає виконання основної функції до 15 жовтня, а решта буде виконана пізніше. Вариант C - полностью открывает модуль отчетности и доставляет до 1-го октября. Що б ти хотів робити?»

---

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

Розвиток мовлення в вільних мовленнях

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

Наприклад, уявіть, що ви отримуєте повідомлення Slack: « Привіт, команда, давайте якомога швидше об’єднаємо потоки автентифікації користувачів! Це буде швидко - просто оновлення класу AuthService. ” Пряма відповідь на кшталт “Це забагато роботи!”, Швидше за все, припинить подальшу дискусію. Натомість, розгляньте щось більш нюансове. Ви можете відповісти: «Звучить амбітно! Щоб переконатися, що ми забезпечуємо надійний і безпечний поток автентифікації, поговоримо про обсяг. Оновлення тільки AuthService може не враховувати потенційні краї випадки або інтеграцію з існуючими системами. Может, мы могли бы разбить это на более мелкие этапы? Фаза 1 могла б зосередитися на основній функціональності, а Фаза 2 могла б розглянути інтеграції. “Зауважте використання “амбітного”, що робить його позитивним, але вимагає подальшого розгляду. Фраза «надійний і безпечний» підкреслює проблеми якості без конфронтації.

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

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

# Example: Using `git diff` to highlight changes in a PR description related to scope
git diff --stat my_feature_branch > pr_summary.txt

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