Разработка
Maksim Nikitzov

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

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

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

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

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

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

О постановке задачи

Что такое «задача»

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

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

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

Целеориентированность

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

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

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

Что значит «поставить задачу»

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

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

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

Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

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

О решении задачи

Что значит «принять задачу в работу»

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

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

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

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

Что значит «сделать»

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

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

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

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

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

Актуальность задачи и её статуса

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

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

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

Результативность

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

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

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

Декомпозиция исходя из потребности

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

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

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

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

Учёт времени на коммуникацию

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

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

О прозрачности

Управление доступом к информации

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

Управление ожиданиями

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

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

Об управлении ожиданиями в проектной деятельности

Привет! Меня зовут Максим Никитцов, я руководитель проектов в компании SmartHead. Мы занимаемся заказной разработкой цифровых продуктов. Как и всем в индустрии нам важно, чтобы заказчики были довольны проделанной работой. Это возможно, если результат принесёт им необходимую пользу, решит существующую проблему. При этом процесс достижения…

Принцип здравого смысла

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

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

Здорово, если вы ещё здесь 👩‍🎓👨‍🎓 Поделитесь, полезны ли подобные принципы на практике?
А что так можно было? Спасибо, попробую применить.
Принципы — полезная штука. Но у меня другие, напишу в комментариях.
Мне без разницы. За меня тимлид решает, а я просто делаю.
Фигня это всё управление ваше. Мешаете только.
Показать результаты
Переголосовать
Проголосовать
0
Комментарии
Читать все 0 комментариев
null