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

Виступ на технічній конференції - це один з найефективніших способів побудувати свою професійну репутацію, поділитися своїми знаннями і збільшити свою мережу. Але перед тим, як вийти на сцену, вам потрібно пройти через комітет CFP (Call for Papers) — а це означає написання переконливої пропозиції англійською мовою. Багато технічно блискучих інженерів втрачають можливість виступити, тому що їх пропозиція неясна або не вдається пояснити цінність для учасників. У цій статті ви дізнаєтесь про структуру і мову написання пропозиції, яку буде прийнято.

Ключові фрази

** Резюме (150-300 слів): **

• «Ця розмова досліджує, як…»
• «З мого досвіду будівництва X в Y, я поділюся…»
• “Більшість команд стикаються з [проблемою], коли вони намагаються [реч]. У цій сесії, я покажу вам практичний підхід до…”
• «До кінця цієї розмови, ви зрозумієте, чому [традиційна мудрість] не вистачає і що робити замість цього»

** Результати навчання: **

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

** Опис розмови: **

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

Біографія оратора:

• «Драунинг з мого досвіду в [компанії], де я керував…»
• «Я провів останні п’ять років, будуючи дані трубопроводи в масштабі.»
• «Я раніше виступав на [конференції] і [зустрічі]»
• «Я є супроводжувачем [проекту з відкритим кодом] і співробітником [спільноти]»

Як це використовувати на практиці

Сильна заявка на CFP має чотири компоненти:

** 1. Резюме - це ваш маркетинговий ролик для комітету з відбору. Вона повинна починатися з проблеми, пояснити ваш підхід і обіцяти конкретний результат. Не перевищуйте 150-300 слів. Більшість пропозицій відкидаються, тому що резюме є занадто нечітким: «Я поговорю про Kubernetes» не є пропозицією. «Я поділлюся трьома критичними помилками, які спричинили безмовний крах нашого кластера Kubernetes — і шаблонами спостережливості, які впіймали їх першими» є пропозицією.

2. Результати навчання повідомляють комітету, що ви подумали про потреби аудиторії. Використовуйте формат « Учасники зможуть… » і будьте конкретними. Неясні результати, такі як «учасники зрозуміють мікросервіси» слабші, ніж «учасники зможуть реалізувати автоматичні вимкнення за допомогою Resilience4j і зрозуміти, коли їх використовувати проти повторних спроб»

** 3. Опис дискусії** дає більш докладний опис. Використовувати пронумеровані розділи або пункти для показу структури. Включіть рівень (початківець / середній/ досвідчений), очікувану аудиторію, а також, чи буде проведено демонстрації або приклади коду.

** 4. Біографія оратора ** повинна встановити вашу репутацію для цієї конкретної теми. Якщо ви говорите про оптимізацію швидкодії, згадайте, що ви оптимізували систему, яка обробляє X запитів за секунду. Загальна біографія про «інженера-програміста з 10-річним досвідом» є менш переконливою, ніж цільова.

Приклад розмови

** Інженер (Галіна): ** « Я надіслав CFP на KubeCon, але не впевнений, що моя абзацна частина достатньо сильна. »

Ментор: “Що в першому реченні?”

Halyna: “В ньому сказано: ‘В цій розмові я обговорю стратегії моніторингу кластерів Kubernetes.’”

Ментор: “Це занадто загальне. Спробуйте почати з проблеми: « Більшість операторів Kubernetes виявляють помилку вузла з квитка користувача, а не з їх панелей управління. У цій промові я покажу вам три прогалини спостережливості, які дозволяють приховувати мовні помилки протягом годин — і як ми їх виправили в нашому масштабі 400 вузлів.’ Тепер це конкретно, це має гачок, і це каже комітету точно, яку цінність ви доставляєте. “

Практичні поради

1. ** Прочитайте прийняті приклади CFP:** Багато конференцій публікують списки прийнятих доповідей з їх резюме. PyCon US, KubeCon і QCon мають архіви минулих програм. Прочитайте 10 прийнятих резюме і визначте шаблон: з якої проблеми вони починаються, як вони обіцяють цінність, і наскільки конкретні результати навчання?

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

3. ** Вправляйтеся у написанні біографії англійською мовою: ** Напишіть біографію 100- слів, яка зосереджена на вашій репутації на певну тему. Уникайте загальних тверджень. Використовуйте конкретні номери, назви проектів і ролі. Прочитайте його вголос, щоб переконатися, що воно звучить природно і впевнено.

Навигація зворотного зв’язку та виправлення запитів — практичний підхід

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

Наприклад, уявіть, що ви отримали цей коментар на запит pull: “Опис основної функціональності алгоритму може бути більш чітким. Розгляньте можливість додавання речення, в якому буде описано компроміси, які виникають при його реалізації. » Проста відповідь на зразок « Дякую за відгук! Я поясню алгоритмічні компроміси і додам цю деталь до пропозиції - зосереджуючись на [конкретній метриці], як ви запропонували ”, є ввічливим, але не повністю відповідає запиту. Замість цього спробуйте щось більш детальніше: «Дякую за те, що ви на це звернули увагу; це важливий аспект розуміння рішення. Для забезпечення ясності, я переглядаю розділ, щоб чітко описати компроміси між продуктивністю і використанням пам’ яті. Зокрема, я додам абзац, де обговорюватиму вплив на [цільове обладнання], як ми це описали у початковому документі проекту. Я дякую вам за те, що ви підкреслили це — це підсилює загальний аргумент для обраного підходу»

Іншою поширеною ситуацією є запит на зворотний зв’язок через Slack. Припустимо, що колега відсилає: «Просто хотів перевірити - чи чітко визначені «результати навчання»? Це здається трохи неясним. “Оборонна відповідь на кшталт “Вони досить чіткі, я подумав!” не допомагає. Замість цього, визнайте їхню занепокоєність і активно шукайте пояснення: «Хороша точка зору - ви маєте право ставити це під сумнів. Щоб переконатися, що вони відповідають аудиторії, я переглядаю розділ результатів навчання, щоб включити вимірювані результати, такі як « Учасники зможуть реалізувати [спеціальну техніку] у практичному контексті. » Чи є у вас якісь конкретні приклади того, що зробило б їх більш конкретними? Це демонструє відкритість до зворотнього зв’ язку і бажання вдосконалити вашу пропозицію.

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