Про принципы совместной работы с задачами

Пара слов о том, как правильно понять и сформулировать задачу, принять в работу и сделать её эффективно и прозрачно с точки зрения командной работы.

Привет! Меня зовут Максим, я отвечаю за управление проектами в SmartHead.

Мы хотим поделиться принципами работы с задачами, которые сформировались за годы нашей практики. Их цель — создать образ мышления, направленный на повышение эффективности достижения результата.

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

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

Это запрос на получение результата для достижения конкретной цели. Задача должна отвечать на вопрос: «Что нужно сделать?». Акцент на результате должного качества, который закрывает потребности или решает проблему, а не на процессе его получения.

Здесь можно перефразировать Некрасова: Как задачу сформулируешь — так она и будет сделана.

Подробнее о понимании качества:

У любой задачи есть цель. Чтобы процесс её достижения был эффективным, из задачи должно быть понятно, зачем нужен требуемый результат. Полезные вопросы для формулирования задачи:

• Какой результат необходимо произвести?
• Почему возникла потребность в этом результате? Для чего он нужен? Кому и какую ценность принесёт?
• Как понять, что задача решена (результат получен)?

Задавайте эти вопросы с учетом потребностей и особенностей пользователей разрабатываемой системы и целей бизнеса. Поставьте себя на место пользователя или заказчика. Это сложно, но научиться можно: пробуйте и проверяйте предположения у опытных товарищей.

Подуймайте и опишите:

• Цель, потребность или проблему.
• Требуемый результат. Согласуйте его с целью. Убедитесь, что результат способствует её достижению.
• Ограничения, например срок или технология.

Задача должна быть одинаково понятна исполнителю, автору, тестировщику и другим заинтересованным в её решении лицам. Опирайтесь на общепринятые понятия, исключайте двойные трактовки, будьте достаточными, но не избыточными. С одной стороны, не стоит создавать лишние ограничения для исполнителя. С другой — нужно не упустить действительно важные требования к результату.

• Понять требуемый результат и цель. Согласиться с их оптимальным соответствием друг другу.
• Согласиться с ограничениями задачи по сроку или предельной трудоёмкости решения.
• Взять на себя ответственность за достижение результата в заявленных ограничениях.

За постановку задачи отвечает тот, кто её ставит (привет, кэп!). Но до приёма задачи в работу вы можете повлиять на её формулировку, обсудить и скорректировать вместе с автором.

Наличие неопределённости в задаче — это всегда риск. До принятия задачи в работу поймите стратегию работы с ним.

Интересные заметки на эту тему:

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

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

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

Этот принцип нужно применять и для планирования. Называйте сроки и трудоёмкость решения задачи с учётом тестирования, отладки и т.д.

Вдохновлялись мы здесь:

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

Статус задачи — это инструмент контроля её состояния при совместной работе. Он должен отражать фактическое состояние задачи в конкретный момент времени. Например, если работа над задачей приостановлена, она не должна оставаться в In progress. Если решение готово к тестированию — нужно перевести задачу в To test.

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

Чем раньше получен результат, приносящий ценность, тем лучше. Быстрее появляется обратная связь, эффективнее управление качеством, ожиданиями и проектом в целом.

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

Для поддержания принципа результативности требуется «здоровая» декомпозиция.

Декомпозиция задачи должна повышать эффективность получения общего результата и упростить процесс управления проектом.

Хороший уровень декомпозиции — когда результат каждой задачи может быть использован для контроля достижения общего результата проекта и его качества. При этом появление промежуточного результата не тормозит процесс достижения цели. Чем мельче задачи, тем больше отвлечений на переключения между ними.

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

Пример подходов и способов декомпозиции:

Если нужно фиксировать затрачиваемое на работу время, учитывайте время и на коммуникацию. Ознакомление с задачей и её обсуждение — это часть процесса решения. Не стоит заводить отдельные задачи на «поговорить».

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

Соблюдайте принцип минимальных привилегий при наличии в задаче конфиденциальных данных. В остальных случаях любая информация по задаче должна быть доступна всем в команде проекта.

Постановка и приём задачи в работу синхронизирует ожидания команды проекта относительно её результата до начала выполнения. Но планы иногда меняются, требования и оценки трудоёмкости корректируются. Делитесь с командой своими сомнениями, которые возникают в процессе решения задачи. Говорить об этом нормально. Делайте это сразу после появления отклонений от плана и их анализа.

Чуть подробнее про ожидания:

Озвученные принципы должны повысить эффективность достижения результата. Какими-то из них можно пренебречь, когда это принесёт больше пользы, чем вреда. Важно это делать сознательно, обоснованно и прозрачно.

Помните: качественное оформление задачи, декомпозиция, управление ожиданиями — это инструменты проектного менеджмента, помощи в достижения цели проекта. Это все «гигиена». Она не делает нас здоровыми автоматически — не приводит к получению конечного результата. Но её отсутствие может нам навредить: если не понимаем, что нужно сделать, или понимаем по-разному, высока вероятность получить бесполезный результат — не то и не вовремя.