Як написати технічне резюме Spike англійською мовою

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

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

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

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

Основність - чи є підхід технічно можливим і практичним за даних реальних обмежень, на відміну від просто можливого в теорії.

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

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

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

• “Ми рекомендуємо продовжити з варіантом B і подати наступний квиток для обробки краю випадку, який ми знайшли навколо одночасних оновлень.” *

Структурування резюме

• Питання: Чи можемо ми замінити поточний механізм опитування підходом, заснованим на webhook, без порушення зворотної сумісності?
• «Що ми спробували: Ми створили прототип webhook-приймача проти середовища пісочниці і перевірили його проти трьох наших найбільших типів подій»
• «Що ми виявили: Webhooks працюють надійно для двох з трьох типів подій; третій прибуває не в порядку приблизно 5% часу, що наша поточна логіка обробки не побудована для роботи з ними»
• «Що ми не досягли: Ми не тестували поведінку під тривалою високою нагрузкою, оскільки це було за межами дводенного піку.»

Рекомендації слід робити чітко

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

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

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

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

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

Зв’язані ресурси

• Як написати технічний запис рішення англійською мовою
• Як пояснити затримку поширення DNS англійською мовою

Не слід плутати з ненаціональними мовами

Будьмо чесними - написання короткого технічного резюме не просто про перелік * того, що * ви зробили. Це про те, як ви підійшли до проблеми, з якими викликами ви зіткнулися, і висновки, які ви зробили, так, щоб вони відповідали вашій команді, незалежно від їх рідної мови або рівня технічної експертизи. Для розробників, які все ще будують свій професійний англійський словник, це може здатися особливо пригнічуючим. Незначні зміни у фразуваннях – від «я досліджував» до «я досліджував», або «я зіткнувся з труднощами» проти «це було важко» – мають значну вагу в передачі впевненості і професіоналізму.

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

Крім того, будьте обережні з використанням надто складного словника. Хоча демонстрація технічних знань важлива, постійне використання жаргону, який не є загально зрозумілим, може створити бар’ єри для розуміння. Розгляньте можливість заміни фраз типу «Я розробив прототип рішення, що використовує асинхронне повідомлення» фразою «Я створив швидке доведення концепції, що використовує асинхронне спілкування». Останнє є більш доступним і зосередженим на результаті – робочому прототипі – а не на тому, щоб застрягти в технічній термінології. Пам’ ятайте, що мета не в тому, щоб вразити вашою лексикою; це для того, щоб полегшити ефективну співпрацю.

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