Хотим поделиться принципами работы с задачами в Компания веб-разработок Джанго которые сформировались за годы нашей практики. Их цель — создать образ мышления, направленный на повышение эффективности достижения результатов.
Статья полезна новичкам и молодым командам. Принципы легко применимы к любому процессу разработки и инструментам. Они основаны на понимании того, что такое задача по своей сути и как с ней работать в целом.
Задача здесь относится как к конкретной «задаче», так и к «функции» или «эпопее». В тексте не будет примеров толкования принципов, чтобы не раздувать их. Оставлю несколько рекомендованных материалов, которые чуть шире раскроют суть отдельных тезисов, а на оставшиеся вопросы с удовольствием отвечу в комментариях.
Целенаправленность
Почему у каждой задачи есть цель? Чтобы процесс ее достижения был эффективным, из задачи должно быть понятно, зачем нужен желаемый результат. Полезные вопросы для формулировки проблемы:
- Какой результат нужно получить?
- Почему был нужен такой результат? Для чего это? Кому и какую ценность это принесет?
- Как понять, что проблема решена (результат получен)?
Задавайте эти вопросы с учетом потребностей и особенностей пользователей разрабатываемой системы и бизнес-целей. Поставьте себя на место пользователя или клиента. Это сложно, но научиться можно: попробуйте и проверьте предположения опытных товарищей.
Что значит поставить задачу?
Подумайте и опишите:
- Цель, потребность или проблема.
- Желаемый результат. Совместите его с целью. Убедитесь, что результат способствует его достижению.
- Ограничения, такие как время или технология.
Задача должна быть одинаково понятна исполнителю, автору, тестировщику и другим лицам, заинтересованным в ее решении. Опирайтесь на общепринятые понятия, исключайте двойные толкования и будьте достаточными, но не избыточными. С одной стороны, не стоит создавать исполнителю лишних ограничений. С другой стороны, необходимо не упустить существенных требований к результату.
Что значит принять задачу?
- Понимание требуемого результата и цели. Согласитесь с их оптимальным соответствием друг другу.
- Согласитесь с ограничениями задачи по времени или максимальной сложности решения.
- Возьмите на себя ответственность за достижение результатов в установленных пределах.
Тот, кто ставит задачу, отвечает за постановку задачи. Но прежде чем принять задание в работу, вы можете повлиять на его формулировку, обсудить и исправить вместе с автором.
Наличие неопределенности в проблеме – это всегда риск. Прежде чем принять задачу, разберитесь со стратегией работы с ней.
Что значит сделать?
Задача считается выполненной, когда результат ее выполнения готов для использования по назначению и не требует дополнительных действий. Задача не может быть «почти выполнена». Это либо сделано, либо в любом другом состоянии. Задача, представленная на тестирование, также является еще не выполненной задачей.
Если вы утверждаете, что выполнили задачу, это должно означать: дополнительное тестирование, развертывание и проверка не требуются, а результат работы можно использовать. Верно и обратное: если никаких дальнейших действий не требуется, а результат приносит ожидаемую пользу, то задача выполнена и ее следует перевести в статус выполненной.
Когда говорят, что задача должна быть выполнена к определенному моменту, то к этому времени она должна пройти все необходимые этапы жизненного цикла, включая тестирование и приемку. Чтобы задание было выполнено вовремя, нужно начать «сдавать» его раньше дедлайна.
Этот принцип следует применять и к планированию. Назовите время и трудоемкость решения проблемы, учитывая тестирование, отладку и т.д.
Эффективность
Чем раньше вы получите результат с добавленной стоимостью, тем лучше. Обратная связь появляется быстрее, управление качеством, ожиданиями и проектом в целом эффективнее.
Двигайте задачи к завершению. Они не должны застревать в одном статусе или скапливаться у одного исполнителя. Это симптомы проблем, которые снижают эффективность достижения результатов.
Для поддержания принципа производительности требуется «здоровая» декомпозиция.
Декомпозиция по потребности
Декомпозиция задач должна повысить эффективность получения общего результата и упростить процесс управления проектом.
Хороший уровень декомпозиции — это когда результат каждой задачи можно использовать для контроля достижения общего результата проекта и его качества. При этом появление промежуточного результата не замедляет процесс достижения цели. Чем меньше задач, тем больше отвлекающих факторов для переключения между ними.
Учет времени на общение
Если вам нужно фиксировать время, потраченное на работу, учитывайте время, потраченное на общение. Ознакомление с проблемой и ее обсуждение является частью процесса решения. Не стоит заводить отдельные задачи для «разговора».
Например, обсуждение дизайна приложения с программистом SaaS (https://www.softformance.com/services/saas-development/), пример между дизайнером и разработчиком, является частью задачи разработки этого дизайна. Коммуникация — это инструмент сотрудничества. Но также необходимо учитывать общение в сложности решения задачи. Иногда требуется больше времени, чтобы поговорить, чтобы узнать и договориться, чем написать код. И это нормально.
