Як пояснити рефакторинг нетехнічним зацікавленим сторонам англійською мовою
Вивчіть англійську фразу для обґрунтування перефакторизації коду для менеджерів продуктів і керівників, які турбуються про вплив на бізнес, а не про деталі реалізації.
Пояснення рефакторингу нетехнічним зацікавленим сторонам є вправою перекладу, так само як і вправою англійської мови — ви повинні перетворити «код є безлад» на мову про ризик, швидкість і вартість, оскільки це терміни, в яких зацікавлені сторони фактично приймають рішення. Цей посібник надає вам вказівки щодо оформлення і вимови, щоб зробити переклад переконливим.
Ключовий словник
** Переклад технічного боргу в бізнес-ризик ** - переосмислення проблеми якості коду з точки зору того, що може піти не так для бізнесу, а не описування самого коду.
- “Я перетворив технічний борг на бізнес- ризик: « у цьому модулі немає тестів, тому кожна зміна може призвести до переривання роботи в процесі замовлення », а не « якість коду тут погана. ”*
Кількісне оцінювання вартості бездіяльності — оцінювання того, що продовження без рефакторизації буде коштувати, у часі, грошах або ризику, щоб зробити «нічого не робити» видимим, порівнянним варіантом, а не вільним типовим. “Я кількісно оцінив вартість бездіяльності: «кожна нова функція в цій області на даний момент займає вдвічі більше часу для створення і тестування через поточну структуру» — конкретна цифра, а не просто відчуття.”
Розгляд рефакторингу як інвестиції, а не як обходу — представлення роботи як чогось, що платить за себе, а не часу, відібраного від «справжньої» роботи над функцією. “Я розглядав це як інвестицію: ‘цей двотижневий рефакторинг повинен скоротити майбутній час функціонування в цій області приблизно на 30%,’ а не представляти це як паузу в прогресі.”
Пропонування обмежених, часових зусиль — пропонування конкретного, обмеженого шматка рефакторингу, а не відкритого «ми повинні прибрати це», що набагато легше для зацікавленої сторони схвалити. “Я запропонував обмежений часом проект: два тижні, обмежений модулем платежів, з чіткою метрикою до і після.”
Звичайні фрази
- «Це не просто перевага якості коду — це сповільнює кожну функцію, яку ми створюємо в цій області»
- «Ціна того, що цього не робити, це [спеціфічний, вимірюваний вплив]»
- «Я пропоную обмежене, двотижневе зусилля, а не відкрите переписування»
- «Ось що стає швидшим або безпечнішим, як тільки це зроблено: [конкретний результат]»
- «Ми можемо зберегти функції доставки без цього, але кожен з них буде тривати довше і нести більше ризику»
Приклади висловлювань
Відкривати з бізнес- рамкою, а не з технічними деталями:
- “Я хочу позначити дещо, що впливає на нашу швидкість доставки: модуль розрахунків стало важко змінювати безпечно, і тепер він додає реальну дату до кожної функції, яку ми там створюємо.” *
Кількісне оцінювання вартості бездіяльності з конкретним порівнянням: “Наші останні три функції в цьому модулі займали приблизно на 40% більше часу, ніж функції аналогічного розміру в інших місцях, в основному через те, як щільно все пов’ язано разом - ця відстань буде зростати, якщо ми не звернемося до неї.”
Пропонування обмежених запитів: *“Я пропоную двотижневий, обмежений часом рефакторинг, обмежений спеціально для модуля розрахунків — не повне переписування. Ми б призупинили роботу над новими функціями на ці два тижні, а потім очікували помітно швидшого доставки після цього»
Завершуючи з ясним компромісом для тих, хто приймає рішення: *“Компроміс простий: два тижні повільнішої доставки зараз, в обмін на постійну швидшу і безпечнішу доставку в цій області в майбутньому. Я хочу, щоб ви могли знати, що я роблю, якщо ви хочете»
Професійні поради
- Завжди ** перекладайте технічну проблему в бізнес-ризик ** - “ризик відключення”, “повільніша доставка”, “важче забрати нових інженерів” приземляться з зацікавленими сторонами таким чином, як “безладний код” ніколи не буде.
- ** Оцініть вартість бездіяльності **, де б ви не були, навіть грубо — число робить « не робити нічого » видимою, порівнянною вартістю замість безкоштовного типового вибору.
- Представте рефакторинг як ** інвестицію з віддачею **, а не обхід від реальної роботи - зацікавлені сторони схвалюють інвестиції набагато легше, ніж паузи.
- ** Обсяг і час запитання ** — відкрите «ми повинні прибрати це» набагато важче схвалити, ніж «два тижні, цей один модуль, ось очікуваний результат»
- Закрити з явним заявою про компроміс - це поважає роль прийняття рішень зацікавлених сторін, а не означає, що рефактор не підлягає обговоренню.
Практичні вправи
- Переписати “код неправильний” як заяву про бізнес-ризик.
- Напишіть речення, в якому виміряти вартість бездіяльності за допомогою приблизного числа.
- Створення проекту гіпотетичного рефактору з обмеженим часом виконання.
Наприклад, мова опису: описує мовлення з використанням опису мови
Добре, давайте поговоримо про те, що часто втрачається при перекладі - логіка, що стоїть за рефактором. Легко застрягти в технічних термінах, коли пояснюєш це зацікавленим сторонам, які в першу чергу турбуються про результати, а не про те, як ти їх досяг. Ключовим елементом є передбачення їх питань і активне вирішення потенційних проблем з мовою, яку вони розуміють і цінують. Часто люди сприймають рефакторинг як просто «прибирання коду», що не передає цінності або невідкладності.
Розглянемо сценарій: Ви визначили деяку надто складну логіку в PR функції, яка впливає на продуктивність. Під час розмови з менеджером продукту, Сарою, ви можете спочатку сказати: « Я роблю деякі зміни в цьому коді ». Це занадто нечітко. Замість цього спробуйте щось на зразок: «Я оптимізую робочий процес тут — по суті спрощуючи те, як дані протікають через систему. Цей перероблений код зменшить затримку і покращить загальну швидкість реакції для користувачів. Бачите зміну? Ми відійшли від чисто технічного опису («внесення змін») до бізнес-орієнтованого пояснення, зосередженого на * перевагах * («зменшити затримку», «покращити загальну здатність реагувати»).
Іншою поширеною пасткою є надмірне використання жаргону, наприклад, « технічного боргу ». Хоча це має правове місце у внутрішніх дискусіях, це може бути відчужено для зацікавлених сторін. Замість того, щоб сказати: « Ми сплачуємо технічний борг », розгляньте можливість формулювання: « Цей рефакторинг вирішує деякі основні складності проектування, які сприяли повільній продуктивності і збільшували ризик майбутніх проблем ». Це використовує більш доступну мову — « складності проектування » і « збільшили ризик » — що робить рефакторинг проактивним заходом для довгострокової стабільності.
Нарешті, коли ви описуєте рефакторинг у описі завдання на звантаження, не просто скажіть « Рефакторинг ». Замість цього, створіть короткий опис: « Рефакторинг для покращення масштабованості і зменшення витрат на обслуговування. Ця зміна покращує читабельність коду, спрощує майбутні оновлення, і зменшує потенційні проблеми з продуктивністю. Це чітко сформулює позитивний вплив роботи. Пам’ятайте, ви продаєте їх за ціною - більш надійну, ефективну систему.