Як писати специфікації на фічі

by · Published · Updated

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

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

Що містить специфікація

Специфікація в продукті — це ясно сформульований план про те, ЩО ви хочете створювати і, головне, НАВІЩО і ЧОМУ.

Дайте відповідь для себе і команди на такі 8 запитань:

  • Яку проблему ми вирішуємо. Сформулюйте проблему, яку ви намагаєтеся вирішити. Що ще важливіше, поясніть, чому до цього варто звернутися. Будьте конкретні та надайте показники.
  • Критерій успіху (мета). Усе просто — оцінювання і порівняння метрик до і після впровадження рішення мають будуватися на меті, яку можна «помацати». Це може бути ключова продуктова метрика або ті, за якими користувач іде до неї.
  • Гіпотеза. Загальний варіант вирішення поставленої раніше проблеми. Опишіть рішення загальними словами: «менше дій користувача/швидка дія/допомога з вибором або рішенням/інформування/і т.д.». Пам'ятайте, що в специфікації 1 проблема, вирішується в рамках 1 гіпотези в рамках 1 фічі (але є винятки).
  • MVP. Конкретний приклад розв'язання проблеми із зазначенням користувацького контексту і UX. Так, «MVP-підхід» можна використовувати не тільки під час запуску продукту, а й для кожної фічі та ідеї відповідно, тестуючи потроху ваші ідеї без їх глобального впровадження (а потім і випилювання).
  • Запитання команді. Найважливіший розділ, на основі якого ваша команда і повинна обговорювати будь-які можливі рішення. Провокуйте команду запитаннями, залучайте її до обговорення можливого рішення з його перевагами і недоліками.
    Дедлайн. Те, до чого ми всі рано чи пізно приходимо. Усе індивідуально, тому варто з самого початку спільно з командою прикидати можливі терміни реалізації задуманого.
  • Успіх MVP. Дублер пункту №2 з поправкою на те, що це MVP. Тобто можна тестувати велику гіпотезу. У випадку з кнопками авторизації з прикладу нижче, це інтеграція всього лише 1 сервісу, на результатах обкатки якого можна думати далі про підключення доп. сервісів.

Приклад специфікації під фічу для підвищення реєстрації користувачів, яку ви можете адаптувати під свій таск-менеджер.

Інші рекомендації:

  • Зазначайте напрямок для командних роздумів, а не видавайте готові рішення.
  • Не поспішайте. Будь-яка фіча/ідея має відстоятися мінімум тиждень.
  • Будьте стислими. Стислість зумовлює ясність думки та спілкування. Використовуйте маркери і жирний шрифт, щоб спростити сканування документа/сторіс. Пишіть у повсякденному стилі, в якому спілкуєтеся в команді. І немає нічого поганого в гуморі.
  • Попереджай питання команди. Завершена специфікація — це специфікація, яка була розглянута і загалом узгоджена. Якщо ви сподіваєтеся включити роботу в майбутній спринт, переконайтеся, що ви почали цей процес за 2-3 тижні до цього.
  • Думай як розробник. Дуже допомагає бачити взаємозв'язки між об'єктами всередині продукту і заздалегідь бачити слизькі місця і майбутнє.
  • Візуалізуйте. Якщо блок-схеми передають величезну кількість інформації в легко засвоюваній формі і набагато наочніші для розуміння зв'язків і поетапних процесів.
  • Дотримуйтеся пунктів і переходьте до наступного тільки після повного розуміння попереднього.
  • Призначити зустріч і обговорити специфікацію. Вважається гарним тоном, коли учасники ЗАДАЛЕГІДЬ і перед зустріччю ще раз читають специфікацію. Що і як обговорювати на зустрічі описував у цьому пості.
  • Не забувайте оновлювати специфікації після обговорень або верифікацій значущих моментів на зустрічах.
  • Головний плюс специфікацій у тому, що в них немає нічого, окрім записаних раніше цифр, тексту і командного обговорення, які змушують мислити в заданому напрямку вельми тверезо і критично. 

Источник — https://telegra.ph/Kak-pisat-specifikacii-na-fichi-02-15