Перед началом работы: что нужно обсудить с агентством по разработке программного обеспечения
Все, что нужно знать о BANT
BANT имеет дело с вашим бюджетом, однако сам бюджет - не единственный фактор, который ИТ-компании учитывают в процессе оценки.
BANT - это метод, который обычно используют агентства по разработке программного обеспечения для проверки того, укладываются ли предположения и ожидания проекта в рамки конкретного бюджета и, короче говоря, имеют ли они смысл. Проверка проекта на начальном этапе может позволить обеим сторонам лучше понять проект, придумать альтернативные варианты или просто избежать разочарований и недоразумений в процессе сотрудничества.
BANT означает четыре термина: Бюджет, Полномочия, Потребность и Сроки.
- Бюджет: одним из сложных аспектов продаж является выяснение у клиента его финансовых возможностей. Однако большинство считает, что первым шагом всегда является открытый диалог с клиентом - квалифицированное изучение его проблем и выработка решения для его нужд.
Этот этап позволяет ответить на такие вопросы, как:
Адекватны ли бюджет и ресурсы масштабам проекта?
Готов ли клиент платить и корректировать бюджет?
- Полномочия: этот этап важен для обеих сторон, чтобы убедиться в возможности сотрудничества. Агентство, занимающееся разработкой программного обеспечения, хочет определить, готов ли потенциальный клиент к сотрудничеству, и если да, то на каких условиях. Он призван проверить серьезность и реальную заинтересованность обеих сторон, чтобы с уважением отнестись к их времени.
Этот этап позволяет ответить на такие вопросы, как:
Кто будет проверять и утверждать задания?
Всем ли понятна сфера ответственности?
Как сообщать об изменениях?
Находимся ли мы на стадии принятия решений?
- Потребность: на этом этапе выявляется реальная потребность, лежащая в основе запроса, особенности и функциональные возможности разрабатываемого программного обеспечения. Здесь же определяются УТП, проводится конкурентный анализ, определяются сценарии использования.
Этот этап позволяет ответить на такие вопросы, как:
Какую проблему будет решать продукт или услуга?
Что отличает его от всего остального?
Какова цель?
- Сроки: сроки согласовываются с ожиданиями. Количество версий и исправлений определяется и согласуется с бюджетом и ресурсами. Прохождение этого этапа важно для того, чтобы определить, уложится ли проект в сроки или столкнется с задержками, а также может ли он повлечь за собой дополнительные расходы.
Этот этап позволяет ответить на такие вопросы, как:
Когда планируется запуск конечного продукта?
Можно ли оправдать дополнительные затраты для ускорения процесса?
Каков процесс утверждения?
Прохождение BANT очень полезно для клиентов, которые могут убедиться в том, что они находятся на одной волне с агентством по разработке ПО, осознать риски и проблемы, а также выявить потенциальные "узкие места". В конечном итоге это может сократить время как для них, так и для ИТ-компаний, которые могут отказаться от проекта, если не смогут выполнить его в предложенных рамках.
Хотя BANT - это метод, который применяют многие специалисты по разработке ПО, он не единственный, с которым вы можете столкнуться. Другой альтернативой является MVP, который, вкратце, представляет собой уменьшенную тестовую версию проекта с целью проверки его бизнес-целесообразности.
Кратко остановимся на нем.
Важность MVP в разработке программного обеспечения
Во всех ли проектах необходим MVP? Нет, скорее всего, нет. Однако если бы каждый проект в мире проходил через это, то, возможно, некоторые из них не были бы разработаны так, как мы знаем, или не потерпели бы неудачу.
MVP - это один из самых простых методов проверки или уточнения идеи продукта или программного обеспечения.
MVP - это ограниченная версия продукта, которая предлагает основные и наиболее важные функции для проверки того, будет ли конечный продукт успешным. Он описывает фундаментальные и базовые функции, составляющие ценность продукта. Таким образом, агентство по разработке программного обеспечения получает обратную связь о функциональности приложения, а заказчик может проверить, имеет ли смысл выбранный путь.
Создавая MVP, мы стремимся получить быструю и надежную оценку идеи или продукта на этапе тестирования. Мы в CrustLab часто рекомендуем это решение клиентам, которые работают над "строящимися" проектами или чьи идеи нуждаются в дополнительной проверке. Мы также можем предложить провести семинары, на которых вместе с нами будет разработано видение проекта.
Однако это не всегда так. Возможно, вы уже точно знаете, чего хотите добиться? И эти требования и ожидания обычно включаются в RFP.
RFP: что нужно знать о запросе предложений
Термин RFP - это аббревиатура, обозначающая запрос предложения. Зачастую он также включает в себя RFQ (request for quotation), в том числе подписание договора и определение условий. Этот этап является более детальным - клиент, получивший RFP, зачастую уже знает, что он ищет, что может себе позволить и какого рода сотрудничество он хочет. Агентства по разработке программного обеспечения могут запросить дополнительную информацию, а семинары также являются отличным способом прояснить все сомнения.
Даже если RFP не является обязательным на начальном этапе сотрудничества, оно полезно для обеих сторон, даже если создано в сокращенном варианте. Это может позволить партнеру по разработке программного обеспечения лучше понять основу проекта и указать на те области, которые необходимо пересмотреть. RFP также позволяют предложить альтернативные решения и дать точную оценку времени и стоимости проекта.
Это дает заказчику предсказуемость и позволяет гибко планировать время и бюджет, а также дает возможность представить демонстрационную версию инвесторам или потенциальным пользователям. RFP также может создать возможность для более быстрого выхода на рынок и более прибыльного заработка.
Нет ничего плохого в отсутствии запроса предложений (RFP) - не каждый проект или продукт имел его с самого начала. Надежный партнер по разработке программного обеспечения должен быть настоящим партнером и на этом этапе и вести вас по всему процессу независимо от наличия или отсутствия запроса предложений. Он должен понимать и ориентироваться в том, каковы потребности бизнеса заказчика, какие функции будет выполнять программное обеспечение/продукт, каковы отличительные особенности отдельных предприятий, каковы области применения, что продукт предлагает рынку и какова его основная продажная ценность.
Ниже приведен образец RFP для ознакомления.
Шаблон RFP
- Информация о версии документа.
- Введение:
- общий обзор отрасли,
- конкурентный анализ и/или примеры для подражания,
- эталоны и предпочтения в области дизайна,
- цель проекта,
- роли и доступы, необходимые в рамках проекта,
- Определения отраслевых терминов, которые могут встречаться в RFP.
- Список основных функций для каждой роли.
- Список всех видов, которые должны быть включены в приложение, с достаточным количеством примеров дизайна, желательно макетов, хотя зачастую они еще не готовы на данном этапе.
- Подробное описание каждой подстраницы и ее отдельных элементов:
- нижний и верхний колонтитулы,
- описание предложения в полном объеме,
- фотогалерея - оформление и содержание,
- контент на подстраницах,
- элементы, такие как вкладки, категории, корзина, избранное, календарь бронирования и т.д.,
- панель администратора,
- возможные способы оплаты,
- другие возможности, такие как алгоритмы ценообразования и продвижения, поисковые системы предложений, фильтрация.
- Отдельное описание для мобильной версии.
- Технические требования: технология, KPI трафика, поддерживаемые браузеры или устройства, тестовая среда, необходимые интеграции; SEO-требования.
- Формальные требования - как подать предложение, в какие сроки, по каким каналам, к кому обращаться в случае возникновения дополнительных вопросов и т.д.
Подобное RFP может быть разослано нескольким компаниям, занимающимся разработкой программного обеспечения, с целью получения наилучшего предложения и выбора одной из них для непосредственной разработки. При этом возникает множество вопросов, причем не только со стороны заказчика.
Вопросы, которые может задать компания-разработчик программного обеспечения
На самом деле, чем больше информации задает компания-разработчик, тем лучше для будущего всего проекта. Задавание вопросов не свидетельствует о плохом знании или отсутствии навыков, а скорее указывает на желание компании-разработчика разобраться в сути проблемы и предоставить точные оценки.
Хотя могут существовать некоторые предопределенные шаблоны и схемы вопросов (как будет показано ниже), обычно это индивидуальные случаи, зависящие от того, насколько сложным является RFP. Некоторые вопросы могут быть уже рассмотрены в RFP или просто нуждаться в уточнении, поскольку они лишь царапают поверхность, но могут быть и многочисленные области, которые вообще не освещены.
Чем больше информации запрашивают компании-разработчики, тем лучше для будущего всего проекта.
Если же RFP вообще не проводится, то вопросы будут накапливаться быстро.
Важность упреждения на этом этапе и быстрого предоставления ответов может улучшить общий процесс, ускорить его и улучшить взаимодействие, что в конечном итоге будет способствовать успешному завершению проекта.
Ниже приведены некоторые часто задаваемые вопросы (и их варианты), которые задают компании-разработчики программного обеспечения при получении RFP или простого запроса. Воспринимайте их скорее как руководство к действию в отношении того, что может быть задано и какие детали могут потребоваться для предоставления. На этом этапе могут возникнуть сотни и сотни вопросов
1. Стадия разработки проекта: