Тендеры и лиды
Информация
К нам в Aiston попадают проекты трёх типов: с готовым списком функций, с частичным видением задачи или вообще без предварительной проработки. В каждом случае список желаемых функций может занимать несколько страниц. Например, аналитика в реальном времени, интеграция со всеми системами или отдельный модуль для отчётности. И кажется, что каждая функция для чего-то нужна.
Когда подрядчик предлагает убрать часть из них или перенести на следующий этап, то это может восприниматься как отказ. Казалось бы, заказчик готов вкладываться в продукт, а команда не хочет выполнять работу!
Дело в том, что задача команды — не реализовать как можно больше пунктов из списка, а помочь решить бизнес-задачу с помощью продукта. И сделать это в доступные сроки и бюджет, не усложнив систему ещё до запуска. Для этого и нужна приоритизация требований.
Разберём, почему некоторые функции не входят в первую версию проекта и как принимаются такие решения.
Отказ от функции не всегда означает, что её полностью исключают из проекта. В зависимости от задачи команда может предложить несколько вариантов:
Упростить решение, если задача не требует сложной разработки;
Перенести функцию, если функция не обязательна для первого запуска;
Сначала проверить гипотезу, если пока полезность функции непонятна;
Изменить сценарий, если сама функция нужна, но текущая логика её использования создаёт проблемы.
Подрядчику тоже невыгодно просто соглашаться со всем списком требований. Можно формально выполнить ТЗ и сделать все функции, а на выходе получить неудобный, дорогой и не масштабируемый продукт.
Заказчик вряд ли назовёт такой проект успешным, а отвечать за результат и свою репутацию всё равно подрядчику. Поэтому вместо простого «нет» подрядчик должен объяснить, почему функция кажется избыточной или преждевременной.
Причин, по которым команда предлагает пересмотреть часть функций, может быть несколько.
Пропускная способность любого проекта ограничена. Есть:
а) определённое количество разработчиков;
б) фиксированный срок на проект;
в) заранее согласованный бюджет.
Теоретически эти ресурсы можно распределить между всеми запрошенными функциями. Но тогда второстепенные задачи начинают конкурировать за время команды с теми, без которых продукт вообще не заработает.
Допустим, в проекте заявлено 10 функций на срок в 3 месяца. Три из них нужны для запуска продукта, остальные делают работу удобнее или закрывают менее частые сценарии. Если пытаться реализовать всё одновременно, второстепенные задачи начинают конкурировать за время команды с теми, без которых продукт вообще не заработает.
Поэтому приоритизация — это не просто сокращение списка. Команда распределяет ограниченный ресурс в пользу того, что важнее для запуска. Если речь идёт о первой версии или MVP, так определяется и набор функций MVP: в него входит то, без чего продукт не сможет решить основную задачу.
Проблема становится заметнее, когда список функций продолжает расти уже во время разработки. Каждая задача сама по себе может казаться небольшой, но вместе они расширяют первоначальный объём проекта. В итоге сроки начинают сдвигаться, а бюджет — расти. Поэтому обычно часть пожеланий фиксируют, но сознательно оставляют на следующие этапы.
Если команда успевает сделать всё в срок, то можно реализовать все функции сразу? На самом деле нет.
Каждая функция, которая внедряется «на всякий случай» или «чтобы было надёжнее», основана на гипотезе о её полезности. А гипотеза может не подтвердиться.
Например, заказчик хочет многоступенчатое согласование: сначала документ проверяет один сотрудник, затем второй, после чего решение принимает руководитель. Гипотеза строится на том, что это снизит риски пропуска ошибок. Команда реализует всё в точном соответствии с запросом. Но после запуска выясняется, что руководители в 90% случаев принимают решение сразу, не читая комментарии предыдущих этапов. Многоступенчатая логика оказывается избыточной.
Настойчивость на полном объёме не гарантирует пользы. Поэтому иногда вместо полноценной разработки сначала предлагают проверить гипотезу: на прототипе, тестовой группе или более простой версии функции.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Если заказчик приходит с уже готовым представлением о функции, на предпроектном этапе команда разбирает не запрос сам по себе, а задачу, которая за ним стоит. Тогда может выясниться, что предложенный способ её решения слишком сложный.
Например, компания хочет отдельный модуль для формирования 20 видов отчётов. После анализа выясняется, что сотрудники постоянно используют 5. Остальные используют либо редко, либо никогда. Тогда на первом этапе делают основные отчёты и добавляют выгрузку данных для редких случаев. Если позже станет понятно, что полноценный модуль действительно нужен, его можно развивать дальше.
Подрядчик отказывается не от самой задачи, а предлагает закрыть её способом, который требует меньше ресурсов и не добавляет продукту лишнюю сложность на старте.
Каждая новая функция — это дополнительный риск. Особенно это заметно у функций, которые касаются интеграций, ролей пользователей и доступа к данным.
Код нужно:
а) тестировать;
б) поддерживать при каждом обновлении;
в) связывать с остальной системой.
Эти шаги не зависят от того, насколько часто функцией пользуются. Например, дополнительный формат экспорта используют всего несколько сотрудников. Но если через него можно получить доступ к корпоративным данным, все три шага выше применяются к нему точно так же, как к функции, которой пользуются все.
Поэтому команда смотрит обширнее и учитывает, сколько сложностей и рисков функция добавит после запуска.
Дополнительная функция редко означает всего несколько часов разработки. Сначала её нужно разобрать с аналитиками, продумать интерфейс и связи с уже существующими сценариями. Затем — разработать и протестировать.
Чем сложнее продукт, тем больше таких связей. Например, новая роль пользователя почти всегда затрагивает права доступа в других частях системы. Небольшая на первый взгляд доработка иногда требует пересмотреть уже принятые решения.
Если таких функций становится много, это сказывается на всём проекте:
растёт время на согласования и проверку зависимостей;
сдвигаются сроки;
увеличивается стоимость проекта.
После запуска цепочка не заканчивается: новые функции нужно поддерживать и учитывать при каждом обновлении. Поэтому команда оценивает не только саму разработку, но и то, сколько новых зависимостей, сложностей и рисков функция добавит после запуска.
Одна и та же функция может быть обязательной в одном продукте и второстепенной в другом, поэтому универсального правила нет.
Обычно приоритизация требований начинается ещё до разработки. Мы проводим её на этапе Discovery: разбираемся, кто будет пользоваться продуктом, какие задачи он должен решать, как сейчас устроен процесс и какие ограничения нужно учитывать.
При оценке каждой функции можно опираться на несколько вопросов:
Какую задачу она решает?
Что произойдёт, если её не будет?
Кто и как часто будет ей пользоваться?
Есть ли данные, подтверждающие её ценность?
Можно ли решить задачу проще?
Как функция повлияет на сроки и бюджет?
Какие риски она добавляет?
При этом сбор требований к проекту — только часть работы. Недостаточно зафиксировать всё, что хотят видеть в продукте. Нужно проверить требования, сопоставить их с реальными пользовательскими сценариями и понять, что действительно стоит реализовывать в первую очередь.
Например, в проекте для сети клиник «Медикум» мы не стали собирать личный кабинет из предполагаемого списка функций. Сначала поговорили с сотрудниками клиники и корпоративными клиентами, провели анонимный опрос и разобрали системы, которыми они уже пользовались. Так удалось понять, какие сценарии действительно важны в ежедневной работе, а какие функции только усложнили бы продукт.
Как из этого исследования вырос личный кабинет и какие решения вошли в итоговый продукт, подробно рассказали в кейсе.
Отказ в части функций на старте — не значит, что заказчик получит менее ценный продукт. Часто это означает обратное: то, что действительно нужно, получит больше внимания команды, а то, что было добавлено по инерции, не будет тянуть время и бюджет на себя.
Если вы планируете похожий проект и не уверены, какие из задуманных функций стоит реализовывать в первую очередь — можем обсудить это на этапе предпроектного анализа до старта разработки.
