was successfully added to your cart.

Корзина

☠️ 4 всадника «Требования» ☠️

Любая «задача», «запрос», «пожелание», «заказ» и другие подобные виды информации, которое вам кто-то передает, чтобы вы что-то с этим сделали называется «требование» (это профессиональный термин).

Абсолютно любое «требование» состоит из:

  1. «У меня или кого-то возникает вот такая вот потребность вот в такой ситуации»
  2. (ситуационно) «Текущее решение потребности вызывает проблема, которая болит на Х из 10«
  3. «Я ожидаю получить решение своей потребности вот в таком виде» (Definition of Success)
  4. «Решение можно считать сделанным если будет работать вот так» (Definition of Done)

Формула Требования:

Требование = Потребность + Проблема (с оценкой боли) + Ожидание (Definition of Success) (DoS) + Факт завершенности (Definition of Done) (DoD)

Так вы получаете ВЕСЬ возможный контекст задачи понимая мотивы, (если есть) боли, ожидания и способы подтвердить успешность выполнения.

Без этих пунктов вы обязательно что-то упустите и попадете в залупу или на этапе придумывания решения по несуществующей проблеме, или даже на этапе ощущения «что все сделано», когда на деле у заказчика было совсем другое ожидание.

Запомним эти 4 элемента, как «4-х всадников требования»:

  1. Потребность – чего, в каком контексте и как хотят
  2. Проблема – что мешает добиться потребности + оценка боли по 10-бальной шкале
  3. Ожидание (Definition of Success) (DoS) – что хотят получить от решения
  4. Факт завершенности (Definition of Done) (DoD) – после какого события можно считать, что потребность + проблема решены успешно

Правило 1. «Нет» реализациям

В Требовании никогда не должна быть описана реализация.

ПРИМЕР НА ПОДХОДЕ

Правило 2. «Который час?»

Обязательно во всех пунктах, всегда уточняйте «К которому времени надо чтобы было вот это, вот это, вот это».

Очень полезный лайфхак

Уже сейчас попробуйте все свои задачи (которые не касаются чего-то слишком процессуального, типа «поправить вот эту кнопку») в таск-трекере оформлять по шаблону:

  1. Название
  2. Потребность
  3. Проблема
  4. DoS
  5. DoD

Например кейс moikrug.ru:

  1. Название: Нужно добавить возможность сохранить несколько фильтров поиска в «избранные фильтры»
  2. Потребность: конкретный пользователь, который ищет работу чаще всего каждый день производит фильтрацию по одному и тому же набору фильтров
  3. Проблема: сейчас для этого ему приходиться вводить их каждый раз заново, что вызывает дискомфорт
  4. DoS: мы должны реализовать функционал, который даст возможность пользователю сохранять набор фильтров, скажем, в «избранные фильтры»
  5. DoD: у нас на сайте в том или ином виде пользователь может сохранить набор фильтров, а потом одним нажатием воспользоваться ими

Или более специфичный кейс внутренней задачи:

  1. Название: Составить варианты оптимизации работы сервиса
  2. Потребность: мы хотим иметь стабильную работу сервиса для пользователей (примером показателя может быть ответ от сервера на любой запрос не более 1 секунды)
  3. Проблема: сейчас многие функции нашего интерфейса прогружаются слишком долго, потому что сервис написан слишком давно и плохо.
  4. DoS: в идеале, нужно найти способ прооптимизировать систему без рефакторинга, но при этом не привлекая кодеров или же надо доказать, что такое невозможно и придется все переписывать
  5. DoD: документ с гипотезами того, как реализовать оптимизацию без рефакторинга и аргументы подтверждающими / опровергающими возможность и эффективность их внедрения.

Гораздо больше контента и развлечений в Telegram-канале