От разработчика требуется рабочий код, без багов, тормозов, который можно поддерживать. От менеджеров, аналитиков и тестировщиков нужны офигенные идеальные задачи.

Извините за ненормативную лексику, но термины "хорошие" и "плохие" задачи не отражают суть.

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

  1. Задачи должны быть в таск-трекере.
  2. За один взгляд на задачу я могу определить, охуенная она или хуевая.
  3. Я люблю охуенные задачи, их можно делать и "сделать".
  4. Лайфхак: хуевые задачи можно не делать. Их можно обсуждать в групповом чате. Типа "смотрите, какую мне @manager создал хуевую задачу. А если немного подумать, то можно вот это немного переписать, а вот это вообще убрать и будет конфетка".
  5. Написать охуенную задачу не сложно и не долго. Иногда проще и быстрее, чем хуевую. Часто достаточно одного предложения и скриншота. Иногда этого мало и надо написать побольше.

Как делать охуенные задачи

Я знаю два способа: "по инструкции" и "на опыте". Свою инструкцию я писать не буду, приведу лишь ссылки на статьи, которые необходимо прочитать, чтобы писать задачи и багрепорты. Желательно прочитать несколько раз. Желательно вдумчиво. Желательно применять это на практике. У Ольги Киселевой (большинство ссылок на неё) есть еще полезные статьи, можете еще походить по ссылкам внутри.

"На опыте" можно сделать задачу быстрее и лучше. Просто пишите, как надо, а как не надо - не пишите. Нужная информация должна быть, не нужной быть не должно, задача "ежу понятна" с первого прочтения, акценты расставлены, результат проверяемый, потенциально проблемные места учтены и так далее.

После написания задачи, не важно по какому способу, можно проверить задачу с помощью чеклиста:

Дополню этот чеклист:

  1. Понятность
  2. Идеальное название
  3. Полнота
  4. Однозначность
  5. Непротиворечивость
  6. Необходимость
  7. Осуществимость
  8. Тестируемость

Нулевая характеристика задачи - понятность. Если задача понятная, но не точная - это плохо. Но если задача точная, но непонятная - это критичнее, в ней нет никакого смысла, она не экономит время, а тратит.

Формулировки задач важны, особенно заголовок. По заголовку задачи должно быть понятно, что надо сделать и даже можно сделать оценку. Короткое название лучше длинного. Не все задачи можно сформулировать коротко и понятно, но надо хотя бы попытаться. Если задачу нельзя коротко и понятно сформулировать - бывает, это нормально, такова жизнь. Легко сказать, но есть хороший способ: подумать пару минут. Это не пустая трата времени, потому что иначе каждый человек, который будет расшифровывать название или описание задачи, будет тратить эту пару минут. Каждый человек. Каждый раз.

Мне понравилось, как об этом написал программист Федор Борщев, Инфостиль в заголовках задач:

Я не сильно докапываюсь к чистоте текста в задачах и служебной переписке: конечно клёво, когда люди пишут понятно, но не всем нужно это учить: нафига какому-нибудь руководителю логистической службы писать тексты на 8 баллов главреда? Главное, чтобы он мог хоть как-то сформулировать сигнал, что болит — а дальше придут опытные продакты/проджекты и всё выяснят.

Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. На сколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.

Вот пара правил для заголовков задач, которые помогут не превращать трекер в бухгалтерский отчёт:

  • Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
  • Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
  • В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера-логиста».
  • Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».

Как не делать хуевые задачи

Задачи должны быть написаны письменно и в таск-трекере. Если задача поставлена и обсуждена устно, но не записана в таск-трекер - её нет, она не поставлена. У нее нет приоритета, описания, про неё все забыли. Если задача написана в чате - её нет, так как чат - не таск-трекер. Отличить таск-трекер от не-таск-трекера легко: в таск-трекере есть статус выполнения. Он может быть простым (чекбокс) или сложным (настраиваемые статусы или колонки на канбан-доске).

Задачи должны быть правильно разделены. Если задача составная (подумайте 2 раза, прежде чем такую создавать), в ней должен быть чеклист с подзадачами.

Пример чеклиста

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

Главный и обязательный лог для SPA - вкладка "Network" или "Сеть" консоли разработчика, в ней надо разбираться.

Описание ошибок, трейс с подробной информацией необходим при 500 ошибках, его можно найти в Sentry сразу после обнаружения ошибки.

Приоритет. Обычно это задача менеджера. На то он и менеджер, чтобы "расставлять приоритеты". Слово "приоритет" происходит из латинского "prioir" - первый, старший. Так что в изначальной трактовке приоритет может быть только в единственном числе и означает одну, первую задачу или действие.

В более широкой трактовке, приоритет или приоритеты - порядок действий или задач. Это важно. Именно порядок действий, который прекрасно задается перетаскиванием внутри колонки на доске канбана. Не поле приоритета и не лейбл "надо срочно пипец ASAP!!!11".

Насколько всё плохо (а может норм?)

Хочу поделиться цитатой из статьи Некомпетентные компетенции с хабра:

О другом испытании мне рассказал заведующий одной из кафедр Российского экономического университета им. Г.В. Плеханова после командировки в Оксфордский университет по обмену опытом. Во время обучения в Оксфорде каждый студент должен самостоятельно написать около 60 эссе на различные темы. Специальное подразделение, не зависимое от кафедр, проверяет написанные эссе на предмет плагиата. В случае обнаружения плагиата, согласно установленным правилам, на первый раз студенту делается предупреждение, которое ложится грязным пятном на все его дальнейшее обучение. В случае повторного плагиата - студент отчисляется независимо от статуса и успеваемости. Насколько я информирован, после прохождения такого испытания, у выпускников Оксфорда отсутствуют проблемы в изложении своих мыслей на бумаге. Однако я постоянно сталкиваюсь с этими проблемами у молодых аналитиков, выпускников российских вузов.

Уверен, что есть люди, которые хорошо умеют излагать свои мысли и создают хорошие задачи. Однако как часто они встречаются?