6 ошибок при постановке задач в IT-проектах

Разработка софта не сводится к одному лишь программированию. Любой проект начинается с описания требований и составления технического задания. Если пропустить этот этап, то есть риск затянуть разработку или получить не тот результат, на который рассчитывает заказчик.

Чтобы разобраться в самых частых ошибках при постановке задач и их последствиях, мы обратились к Екатерине Подаруевой — руководителю QA-отдела в SimbirSoft. Поговорили о том, почему важно фиксировать все договорённости, привлекать к работе системного аналитика и что ещё делать, чтобы избежать возможных проблем в проекте.

Екатерина Подаруева

Руководитель отдела QA в SimbirSoft. Опыт работы в IT — более четырёх лет, занимается обеспечением качества мобильных и веб-приложений.

Ошибка 1

Неполное описание задачи в таск‑трекере

В компаниях для постановки задач обычно используют таск-трекеры, например Jira или Kaiten. Они предлагают большое количество полей для описания того, что требуется сделать разработчику, аналитику или другому специалисту.

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

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

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

Возможные риски

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

Задача возвращается на доработку. Если у задачи отсутствует подробное описание с требованиями, то разработчик может не понять, чего именно от него ждут. Поэтому задача, скорее всего, вернётся на доработку, а того, кто её ставил, попросят уточнить техническое задание.

Бизнес или пользователи не будут удовлетворены результатом, а значит, и продуктом в целом. Разработчик, не найдя полного описания требований, реализует функциональность так, как он её понял. А QA-специалист, проверяя результат, будет опираться на понимание задачи программистом. Так возникает риск получить не то, что ожидает увидеть заказчик или конечные пользователи. В итоге с большой вероятностью придётся дорабатывать продукт или лишиться части пользователей из-за плохой функциональности и, как следствие, низкой популярности продукта.

Что делать?

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

При создании и формулировке задач на разработку помнить про основные пункты описания:

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

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

Читайте также:

Боль тестировщика: с какими проблемами сталкиваются QA-инженеры

Ошибка 2

Недостаточное описание предыдущих этапов разработки или его полное отсутствие

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

Возможные риски

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

Что делать?

• Все уточняющие вопросы по разработке и информацию по существующим зависимостям необходимо фиксировать в базе знаний. Это сократит время на локализацию проблем при их возникновении.
• Если в проекте не составлены требования к отдельным модулям и функциональности, создайте отдельные задачи для их описания. Обязательно укажите конкретные сроки и ответственных лиц.

Ошибка 3

Постановка одной задачи для нескольких команд

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

Возможные риски

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

Нарушение принципа раннего тестирования. Например, QA-специалист может не увидеть, что бэкенд-разработчик уже завершил свою часть работы и что можно приступать к API-тестированию, не дожидаясь фронтенда. Это мешает раннему выявлению багов.

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

Что делать?

• Создавать эпики (в терминологии Agile — большие задачи, которые можно разбить на несколько меньших) и подзадачи. Общая задача — это эпик. В нём создаются подзадачи для каждой команды с конкретным описанием и учётом особенностей работы над ними.
• Следить за статусом всех подзадач в таск-трекере и следовать принципу раннего тестирования: каждую подзадачу можно и нужно тестировать по готовности, не дожидаясь остальных. Когда все подзадачи готовы и протестированы, эпик переводится в статус «Готово к тестированию» и тестируется полностью.

Ошибка 4

Разработка без аналитики

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

Возможные риски

Команда будет тратить больше времени на решение задачи. Допустим, после разработки таск перейдёт к QA-специалисту. Чтобы понять, какие изменения были внесены в систему, ему придётся поспрашивать разработчика, отвлекая его от других задач.

Неверная реализация. Если требования не описаны, то разработчик не может понять, правильно ли он понял ожидания тимлида и клиента. В результате возможна ошибочная реализация функциональности с последующими исправлениями.

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

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

Что делать?

• Фиксировать в комментариях к задаче все обсуждаемые требования. Если требования не описаны, то считать задачу незавершённой и помечать её как технический долг до подробного описания в базе знаний и проверки на соответствие.
• Передавать задачу аналитику. Он подготовит описание и проведёт ревью, которое затем попадёт в базу знаний.

Читайте также:

Технический долг: что это такое и как с ним жить

Ошибка 5

Недостаточное описание задач для аналитиков

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

Возможные риски

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

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

Что делать?

• Договориться с командой, чтобы системный аналитик обязательно обсуждал задачу с автором, перед тем как взять её в работу. Все дополнительные сведения, полученные во время этой встречи, фиксируются в описании задачи.
• Перед отправкой задачи в работу обсудить её с разработчиком и QA-специалистом. Это поможет учесть их мнения на этапе описания требований, а не в момент реализации фичи.

Ошибка 6

Нехватка источников требований

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

Что делать?

• Подключить консультанта или эксперта. Узнать у клиента, к кому можно обратиться с вопросами по бизнесу или отрасли в целом. Провести с этим человеком или отделом предварительную встречу и объяснить важность работы с системным аналитиком.
• Проводить онбординг специалистов, который включает в себя погружение в специфику проекта — объяснение его целей, целевой аудитории, конкурентных преимуществ и других нюансов. Команда разработки должна быть погружена и в техническую, и в бизнесовую часть продукта. Для того чтобы не проводить подробный онбординг с каждым, основную информацию о проекте и отрасли необходимо добавить в базу знаний, предварительно согласовав с клиентом или экспертом.

Что запомнить

Подведём краткие итоги:

• Проработанное описание требований экономит время команды и снижает затраты на создание IT-продукта.
• Если не описывать этапы разработки, есть риск поймать регрессионные баги — когда новый код ломает существующий.
• Системный аналитик может снизить риски, работая над требованиями и вовремя описывая систему в базе знаний.
• Команда разработки должна знать не только техническую часть проекта, но и бизнесовую: для кого создаётся продукт, как он отличается от разработок конкурентов, какая у него конечная цель и так далее.