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