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

Задача — это описание требований, представление того, что должно быть сделано. Мария Бердышева, ex-Head of System Analytics в Paysend, расскажет, как ставить задачи так, чтобы они были понятны и выполнимы для всех участников продуктовой команды разработки.

Карл Вигерс в своей книге «Разработка требований к программному обеспечению» объясняет, что такое требования: это свойства, которыми должен обладать продукт, чтобы быть полезным для пользователей.

Обратите внимание, что Вигерс определяет требования как свойства продукта, а не системы. Это связано с тем, что продукт — это нечто большее, чем просто система. Он включает в себя не только программное обеспечение, но и все, что связано с его работой (инфрастуктура и т. д).

Уровни требований

Требования делятся на функциональные и нефункциональные.

Функциональные требования — это требования, которые описывают, что система, приложение или сервис должны делать для удовлетворения бизнес-потребностей заинтересованных сторон.

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

Функциональные требования

Один из наиболее удобных и понятных методов описания функциональных требований — это варианты использования (use cases).

Этот метод стал популярен по всему миру благодаря книге Алистера Коберна «Современные методы описания функциональных требований к системам».

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

Нефункциональные требования

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

Пользовательские истории ≠ требования

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

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

Less is more

Краткость — сестра таланта; людям сложно удерживать внимание на длинном тексте. Не пытайтесь описать все детали в одной пользовательской истории или в одном варианте использования. Это приводит к тому, что команда не читает ваши требования и совершает ошибки.

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

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

Убираем расплывчатые термины

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

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

Уходим от неопределенных условий

Требования не должны включать неопределенные условия, такие как «насколько это возможно», «по возможности», «если необходимо», «в случае необходимости», «при необходимости».

Не используем открытые и неполные перечисления

Требования не должны включать открытые, неполные перечисления, такие как «включая, но не ограничиваясь», «и т. п.», «и так далее».

Атомарность требований

Требования должны быть атомарными. Избегайте использования слов, таких как «также», «но также» и пр.

Универсальные требования

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

Измеримая производительность

Требования должны включать конкретные измеримые целевые показатели производительности.

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

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

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

Материал подготовлен при поддержке редакции ProductStar. Мы — онлайн-школа IT-профессий, часть холдинга РБК с 2023 года. Спасибо, что остаетесь с нами! Предлагаем вам подписаться на нас в Telegram, посмотреть на все наши публикации на VC и познакомиться с предлагаемыми нами курсами по менеджменту: Product Manager, CPO, Менеджер проектов и многое другое.

А еще мы запустили интерактивную игру «Lead Game», которая позволит прокачать лидерские навыки на реальных кейсах. Хотите занять руководящую должность или уже занимаете? Пришло время оценить ваши soft skills.