Задачи и хотелки

Пользуюсь такими терминами, спрашивают: почему так, и в чем отличие.

• Задача — это то, что надо сделать. В этом виде удобно передавать вводные исполнителю, «иди и делай». Отлично, если задача отвечает критериям задачи (specified, measurable…) и вписывается в план.
• Хотелка — это то, что кому-то вдруг хочется получить (или иметь). То есть всё остальное, окромя формализованной и поставленной задачи, что пока такой задачей не является. А возможно, ею не станет никогда.

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

Первая отвечает на вопрос «надо», вторая на вопрос «хочу».
В этом неформальном разделении лежит очень глубокая, и очень полезная для понимания пропасть. Которую необходимо осознать.

Превращение хотелок в задачи называется формализацией требований, а постановка их в работу — планированием.

1. Не всякая хотелка = задача

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

Первый фильтр:

• могут ли от нас вообще этого хотеть?

Здесь может оказаться, что запрошенное надо делать не здесь, а в совершенно другом месте, другими людьми и другими системами.

Второй фильтр:

• могут ли вот эти люди от нас этого хотеть?

Очень полезно, когда есть специально выделенные люди (продукт-овнер, например), которые определяют и занимаются возможностями продукта, что он должен делать, а чего не должен. Тогда именно там будет приниматься аргументированное решение, и именно туда должны прилетать хотелки (а прилетевшие в обход и наугад — следует туда мягко перенаправить).

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

Есть специальные люди, задача которых вдумчиво аргументированно понимать, что рынку и пользователю особенно нужно: пожалуйста, обращайтесь к ним.

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

Третий фильтр:

• могут ли от нас этого хотеть сейчас?

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

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

Последний фильтр:

• есть ли существующий механизм для тех задач, которые хотят?

Если механизм есть, работающий, но даже неидеальный — следует на него указать. Хотеть кнопку «пыщь и магия» опять же, никто не запрещает, но если есть прямо сейчас доступные альтернативы, используйте их. Геликоптер — нихт. Пока не запилят.

С входными фильтрами разобрались, смотрим дальше.

2. Не каждая хотелка реализуема

Формальные признаки задачи у хотелок обычно отсутствуют. Их нужно доводить до ума (сортировка здесь по smart, важные = все).

• Определенность: её нет, описание обычно прилетает в виде «хочу такое», или «хочу как там». В ходе уточнения, чего же хотел сказать автор, и где же это «там» — неминуемо вылезут нюансики. Способные раздуть оценочный срок вдвое-втрое. Думать и разбираться лучше все-таки на берегу, на этапе анализа требований, и не выяснять детали постфактум. Если сложно, заложите итерацию на исследование вопроса (конкурента посмотреть, прототип собрать итп).
• Измеримость: сколько вешать в граммах. А также важное разграничение, «чего от нас хотят, а чего не хотят» — чтобы сферу хотелки как-то практически ограничить, до реально выполнимых величин.
  Чего не хотят — не менее важно, часто есть простые быстрорастворимые способы решений (и их надо поискать).
• Достижимость: а мы такое вообще сделать-то можем физически?
• Применимость: зачем от нас этого хотят. Какую свою проблему автор хотелки пытается решить? Уже не для того, чтобы хотелку зарезать (см про фильтры), но затем, чтобы предложить решение(-ия), наиболее релевантные проблеме. Скорее всего кто-то решал проблемы до вас, вы не первые, не вы последние. А еще есть best practices отраслевые.
• Время: оно когда хочется, и когда вообще можется? Хорошие специалисты могут всё, особенно если ожидаемый срок = бесконечность. Только не всем это подходит.

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

3. Декомпозиция

Одна развесистая хотелка может превратиться в множество взаимосвязанных задач. А может и не превратиться — в зависимости от аппетитов. Необходимо помимо собственно декомпоза (как кушать этого слона), еще и определить, в каком порядке кушать. И как вписать в существующие планы.

С подзадачами полезно пробежаться снова по фильтрам: что-то конкретное делать мы, возможно, вовсе не хотим или не можем; что-то надо делать иначе, а что-то не сейчас.

Rev. Каждая задача - хотелка?

Увы, в реальном мире это не так. На немолодом проекте в развесистом плане работ у вас неминуемо будут находиться задачи, хотелки к которым — т.е целеполагание и проблематика — уже утеряны или неактуальны. Так бывает.

Но на мой взгляд, следует стремиться к тому, чтобы задачи были привязаны к хотелкам/фичам/целеполаганию всегда. Иначе отвечать на вопрос «нахрена мы вообще это делаем?» становится очень сложно. То, что можно не делать, лучше не делать.

Если по итогу анализа хотелки она превращается в «надо» — она становится задачей. Или задачами. Но не ранее того.