Как в IT-команде устроено построение задач с разработчиками?
Спросите любого тимлида и он подтвердит: постановка задач в IT — это не просто записать что-то в Jira и ждать чуда. Это процесс, который напрямую влияет на то, как быстро и качественно команда выкатит фичу, починит баг или сделает редизайн. И да, здесь действительно много нюансов.
Мы поболтали с руководителем команды тестирования, менеджером проекта CORPTIME и готовы рассказать, как мы это делаем — с примерами, шутками и честными признаниями.
Как выглядит процесс постановки задач?
«Процесс постановки задач — это не просто «пришел, сказал, ушел». Мы используем Jira, YouTrack для управления задачами. В самые «солнечные» дни мы проводим планирование, где снабжаем разработчиков необходимыми материалами (и да, эмодзи в комментариях — это тоже часть материалов). В дни «непогоды» я скидываю просто ссылку на задачу где указана вся информация и на этом ограничиваюсь.»
Самое главное, чтобы у задачи было всё — понятное описание, мокап, ссылки, комментарии аналитика, чек-лист ожиданий и крайний срок. Задача должна быть не «сделай красиво», а например, «добавь отображение онлайн-статуса рядом с именем пользователя в списке контактов в личном кабинете, как в прототипе. Обновление статуса — по вебсокету».
Как определяются приоритеты задач?
Что важнее: бизнес-цели или технические нюансы?
«Приоритеты определяются на пересечении трех ключевых факторов: бизнес-ценность, сложность реализации и срок реализации. В нашей практике — планируется звонок на котором присутствуют коллеги из отдела бизнеса (продукта) и аналитики — открывается дорожная карта и происходит магия (приоритизация)»
Это не значит, что мы беремся за всё подряд. Каждая задача проходит фильтр: насколько она важна для бизнеса, сколько времени займёт, насколько она срочная. Иногда задача с маленькой бизнес-ценностью оказывается в приоритете, потому что она «быстрая и нужна была ещё вчера».
Бывали ли ситуации, когда разработчики предлагали изменить постановку задачи?
Если да, то как это решается?
«Бывали, и это абсолютно нормально. Иногда разработчики предлагают более элегантные и надежные решения, чем изначально запланировано. Мы обсуждаем их предложения в команде, взвешиваем риски и возможности, после чего корректируем постановку задачи. Главное правило — аргументация: «мне так удобнее» не работает, а вот «это повысит производительность в три раза» или «это будет быстрее без потери качества» — уже совсем другой разговор.»
И это работает. Мы не делаем «как написано», если есть способ сделать лучше. В такие моменты крайне важно помнить, что мы занимаемся делом, которое искренне любим, а не работаем по принципу «и так сойдет».
Как оценивается сложность задач и сроки их выполнения?
«Мы используем story points. (Здесь встаёт из-за стола аналитик и начинает активно жестикулировать, но мы не узнаем продолжения…) Главная цель — не гадать, а опираться на аналоги и опыт команды. Иногда оценки корректируются по ходу работы, но это не значит, что мы «переоцениваем сложность», скорее наоборот — просто реальность всегда вносит свои коррективы.»
Поясним: story points — это относительная оценка сложности задачи. Мы не спрашиваем «Сколько это займёт часов?», а скорее «Насколько это сложнее или проще, чем задачи, которые мы уже делали?». Например, если задача по внедрению логики обработки событий по сложности равна условной пятерке, то мелкий фикс в верстке — это скорее единица. Система помогает сбалансировать нагрузку в спринте, не перегружая команду.
Какие метрики мы используем?
Количество багов после релиза — это, пожалуй, главный индикатор того, насколько задача была правильно поставлена и реализована.
«Хороший код – это не тот, который написали, а тот, который работает.»
Мы также отслеживаем, укладываемся ли в спринты, сколько задач возвращается на доработку, как часто разработчики задают уточняющие вопросы, и сколько времени уходит на работу по задаче после того, как она взята в работу. Все эти вещи помогают понять, где мы могли «не дожать» на этапе постановки.
Самые частые ошибки в постановке задач:
I. Нечеткие требования — разработчики не должны читать мысли, им нужны конкретные ожидания.
II. Нет критериев приемки — задача «сделана» ≠ задача «работает».
III. Слишком большая задача — проще разбить ее на несколько мелких, чем потом переделывать всё.
IV. Нереальные дедлайны — магии не существует, даже если очень хочется.
V. Неучтенные взаимосвязи — если задача тянет за собой еще три, лучше это выяснить до старта.
VI. Необоснованные приоритеты — «сказали срочно» ≠ «действительно срочно».
Лайфхаки для постановки задач в IT-команде, которые действительно работают
1. Прислушиваемся к команде – иногда разработчик видит проблему раньше, чем менеджер, и это стоит учитывать.
2. Добавьте в описание задачи фразу: «Если есть вопросы — спрашивайте» и приготовьтесь к шквалу вопросов :)))
3. Пишите задачи как для человека, который не в курсе контекста. Это повысит читаемость и снизит количество вопросов.
Тут вспоминается корпоративная шутеечка: «В команде у нас отличные отношения. Особенно повезло с лидом — он по образованию учитель для детей с особенностями развития.»
4. Если задача не укладывается в один экран — почти всегда её стоит разбить.
5. Пример уже выполненной задачи, похожей по сложности — идеальный ориентир для команды.
Чек-лист для хорошей постановки задачи:
✅ Понятное и конкретное описание
✅ Ссылки на дизайн/прототип/аналитику
✅ Чек-лист критериев приемки
✅ Указаны взаимосвязи (если есть)
✅ Аргументированный приоритет
✅ Оценка сложности или хотя бы предварительный ориентир
✅ Контактный человек для уточнений
✅ Внятный результат задачи (что должно быть на выходе)
Постановка задач — это мост между «что надо сделать» и «как это реализовать». Чем лучше построен мост — тем быстрее и безопаснее по нему пройдет команда. И не забывайте: хорошие задачи начинаются с умения слушать и договариваться.
А как вы ставите задачи в своей команде? Делитесь в комментариях, обсудим самые рабочие приемы и фейлы 👇
Больше историй из закулисья IT и наших инсайтов — в Telegram-канале CORPTIME. Переходите по ссылке и подписывайтесь!