Техническое задание: законодательные требования и сложившаяся практика
Сложность составления технического задания состоит в том, что его положения должны обеспечить приобретение именно того товара, в котором нуждается заказчик, но при этом не должно быть нарушено антимонопольное законодательство. Требования должны быть четкими и подробными, но количество и набор характеристик не могут быть «подогнаны» под конкретную марку или определенного производителя. В противном случае такие действия по нормам Федерального закона «О защите конкуренции» могут быть расценены как нарушение антимонопольного законодательства в виде создания участнику торгов преимущественных условий.
Теоретически заказчик может и не предъявлять никаких требований к товарам, но тогда ему ожидаемо поставят самое худшее из возможных.
Типичные нарушения заказчика при составлении технического задания
Нарушение 1: неясные формулировки, значения
Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ч. 1 и ч. 2 ст. 33 документация должна содержать требования, которые позволяют установить подходят ли предлагаемые товары, (работы или услуги) заказчику. Не следует использовать термины наподобие «не хуже», «не слабее» и тому подобные, это не объективное описание. Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.
Характеристики объекта закупки, например, могут выглядеть так:
«Требования к товару. Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений. Функциональные размеры столов». Наименование товара — стол эргономичный. Размер, Ш x Г x В (ширина, глубина, высота): — минимальные значения — 100 x 100 x 71,5 см; — максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению. Цвет: коричневый. Требования к столешнице: Материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края. В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.»
Бывает, что заказчики ошибаются при указании требований диапазонными значениями. Например, «ширина более 360 мм и менее 214 мм». Иногда при описании объекта закупки не учитываются собственные инструкции по подготовке заявок: «В случае, если присутствует слово «диапазон», «в пределах», то поставщику необходимо предоставить диапазон значений ниже установленного заказчиком». Каким образом это понимать в случае температурного диапазона непонятно.
Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона ГОСТ 7473-2010. Бетон может быть либо жестким (Ж), либо подвижным (П). Это взаимоисключающие характеристики. Однако, заказчики умудряются вписать в техзадание и то и другое: жесткость Ж1-Ж4; подвижность П1-П4. Материала с такими характеристиками не может быть. И это является нарушением ч. 2 ст. 33 44-ФЗ.
Должны быть обязательно указаны правильно единицы измерения показателей характеристик. В практике были случаи, когда заказчики указывали «м» вместо «мм».
Термины характеристик, их единицы измерения должны соответствовать техническим регламентам. В противном случае, заказчику придётся обосновать применение иных терминов и единиц измерения.
Установление излишне детализированных требований к материалам, из которых изготавливается товар также будет нарушением закона.
Нарушение 2: ссылка на ГОСТ без какого-либо описания
Ещё одно распространённое нарушение — это перечисление в техническом задании ГОСТ, без привязки к конкретным товарам. Позиция ФАС в этой ситуации такова, что подобное описание объекта закупки не позволяет идентифицировать каждый товар, и не позволяет потенциальному поставщику подготовить заявку должным образом.
Нарушение 3: отсутствие фразы «или эквивалент»
Распространённой ошибкой также является указание в описании объекта закупки требования к товарному знаку без ссылки на возможность применения эквивалента, что может привести к ограничению конкуренции. Узнайте подробнее об этом требовании закона в видео на сайте Школы электронных торгов «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию»
В общем случае при составлении закупочного ТЗ заказчик должен следить за полной безликостью описываемого объекта, то есть в нем не должно быть никаких требований и даже намеков на конкретные товарные знаки, производителей или даже страну происхождения товара.
Ещё несколько рекомендаций при составлении техзадания по 44-ФЗ
На самом деле, грамотно подготовить описание объекта закупки, техническое задание по 44-ФЗ, без наличия специальных знаний в конкретной области довольно непросто. Некоторые заказчики даже создают закупку на оказание услуг по подготовке техзаданий. Но и самостоятельно это сделать вполне реально, если внимательно изучить требования к объектам закупки, сопоставить со своими потребностями и точно следовать правилам описания объекта закупки по 44-ФЗ.
Нужно иметь в виду, что в маркировке изделий зашифрованы некоторые характеристики. К примеру, техническим заданием предусмотрен материал «плитка тротуарная» с маркировкой «Классико 1КО.4», техзаданием никаких требований к толщине плитки не предъявлено. Согласно расшифровке маркировки, её толщина составляет 4 см. (последняя цифра маркировки указывает на толщину в смантиметрах). Однако, при исполнении контакта выяснилось, что требовалась плитка толщиной 6 см. От толщины плитки зависит нагрузка, которую она может выдержать. Неграмотно составленное техзадание привело к закупке материала, который не удовлетворяет необходимым требованиям. Поэтому нужно тщательно проверить маркировку всех материалов в техническом задании и указать все основные, важные требования к материалам.
Желательно не копировать описание товаров с различных сайтов. Информация в описании может не быть достоверной и окажется, что заявленным требованиям не соответствует ни один товар. Существует большая вероятность, что под данное описание подходит единственный товар. Это может расцениваться как ограничение конкуренции.
Все требования к характеристикам не должны иметь двусмысленное толкование. Иначе будет очень много запросов на разъяснение. Зачастую бывает так, что при множестве запросов, заказчик не может успеть в установленные сроки ответить на них по существу и времени на корректировку технического задания может не оказаться. На основании этого, иногда заказчик в разъяснении указывает, что достаточно подачи одного лишь согласия, без указания на материалы. В свою очередь, это снижает шансы закупить именно то, что необходимо, так из заявки не видно какие материалы будут использованы при исполнении работ.
Инструкцию по подготовке заявки лучше составлять уже после описания требований к техническим характеристикам. Инструкция должна не запутывать участника, а конкретизировать требования технического задания, во избежание множества запросов от участников. Несоответствие технического задания инструкции, создающее препятствие для подготовки заявки, может спровоцировать направление жалоб в УФАС потенциальными участниками закупки.
Какие ещё требования важно указать в техзадании:
Главные правила
Распространенные вопросы
Вопрос: Можно ли прописывать на поставку запасных частей указание «оригинальных»?
Ответ: Можно, если речь идет о продукте, стоящем на гарантии, либо присутствует необходимость обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком, а также в случае закупок запасных частей и расходных материалов к машинам и оборудованию.
Вопрос: Обязательно ли прописывать идентификационный код закупки в техническое задание?
Ответ: Идентификационный код закупки указывается в плане закупок, плане-графике, извещении об осуществлении закупки, приглашении принять участие в определении поставщика (подрядчика, исполнителя), осуществляемом закрытым способом, документации о закупке, в контракте, а также в иных документах, предусмотренных настоящим Федеральным законом. В ТЗ его указывать не обязательно.
Вопрос: Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен. Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.
Ответ: Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) – можно, в других случаях — нельзя.
Вопрос: Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?
Ответ: При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент».
Как составить техническое задание и получить то, что нужно
Если вы заказываете у сторонних подрядчиков проект, в котором нет жестких стандартов качества, попробуйте работать по техническому заданию. Оно поможет в разработке сайта, дизайна, написании статей в блог или оказании других маркетинговых и IT-услуг. ТЗ конкретизирует пожелания.
Рассказываем, как составить ТЗ так, чтобы вас поняли, что в него стоит добавить, кто должен оформлять этот документ и какие есть нюансы и особенности.
Что такое техническое задание
Техническое задание, или ТЗ — это документ, в котором фиксируются требования к проекту. Условно ТЗ можно назвать любое поручение исполнителю, главное, чтобы в нем были ясно прописаны характеристики итогового продукта.
В первом примере мы даем поручение, которое исполнитель должен выполнить по своему усмотрению. Во втором явно указываем, что именно нам нужно. Идеальным решением во втором случае еще будет составление договора, чтобы техническое задание стало приложением к нему.
Когда стоит составлять техническое задание
Всё зависит от проекта и вашей бизнес-модели. Если проект маленький, вы доверяете исполнителю, и риск получить не то, что вы хотели, мал, можно обойтись устным поручением.
Если проект требует значительных для вас вложений, он связан со сложной IT-сферой, где много нюансов из-за особенностей технологий, или с творческой сферой, стоит зафиксировать требования в ТЗ.
Кто должен составлять техническое задание
Устоявшейся практики нет — как договоритесь с подрядчиком.
Заказчик делает сам
Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.
В таких случаях мы точно знаем, что, как и когда нужно снимать. Соответственно, можем сразу рассчитать стоимость и сроки работ. Но в большинстве случаев заказчики не имеют точного ТЗ, потому что у них нет конкретного понимания, что именно нужно требовать от исполнителя. В таких случаях мы предлагаем им заполнить форму с наводящими вопросами.
Анатолий Шостак
Гендиректор «АрхФото»
Совместная работа
Процесс может выглядеть так: заказчик формулирует все требования к будущему продукту, заполняет бриф подрядчика по образцу, а затем на интервью согласовываются нюансы.
Техзадание полностью делает исполнитель
В таких ситуациях подрядчику ставится общая задача, а требования и обязательные функции к продукту он собирает с помощью разных источников — проводит интервью сотрудников заказчика, изучает потенциальных потребителей и конкурентов.
Совместная работа по составлению ТЗ и заказ задания исполнителю отличается в первую очередь подходом. Например, вы хотите заказать интернет-магазин:
Универсального решения нет, но лучше доверять составление ТЗ представителю подрядчика — специалист лучше знает, как должен работать его проект. Но при этом не стоит отстраняться от работы — объясните подрядчику, зачем вам продукт, как вы планируете его использовать, кто и зачем им будет пользоваться, покажите примеры решений конкурентов, которые вы считаете хорошими.
Сколько стоит заказать ТЗ
Если проект сложный, с большим списком функций и требований, техническое задание можно заказать за деньги. Это практикуется при создании сайтов и мобильных приложений. С готовым ТЗ можно не искать исполнителя самостоятельно, а открыть тендер.
Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.
Не рассчитывайте получить качественное ТЗ бесплатно. Для его составления привлекают аналитиков, которые должны сформировать функциональные требования исходя из задач бизнеса и описать их так, чтобы не было пространства для двусмысленных толкований.
При этом ТЗ — это отчуждаемый документ, с которым может работать любой исполнитель. То есть вы можете заказать ТЗ у одних разработчиков, а затем обратится к другим. Главное, чтобы в ТЗ были описаны бизнес-логика и правила работы.
Максим Мул
Основатель Work Solutions
Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.
Чтобы составить минимально ценное для клиента и понятное разработчикам ТЗ, аналитику нужно потратить минимум одну неделю на опрос всех сотрудников клиента, уточнить возможность реализации требований с разработчиками и в итоге свести всё в один документ.
Такие затраты микро- и малый бизнес в основном не могут себе позволить — заказ ТЗ актуален для верхнего малого и среднего бизнеса, когда IT-продукт в итоге существенно сократит расходы бизнеса и это будет выгодно.
Владимир Севрук
Гендиректор компании «Информатика и Сервис»
Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии.
У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.
Анатолий Шостак
Гендиректор «АрхФото»
За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.
Как написать техническое задание
Что конкретно стоит добавить в техзадание, зависит от продукта. Например, если вы заказываете партию одежды, нужно прописать особенности покроя, виды материалов и их качество, вплоть до примерной матовости поверхности пуговиц.
Если заключаете договор на разработку сайта, нужны сценарии его использования.
Пишите однозначно
Составляя ТЗ или описывая продукт подрядчику, старайтесь избегать качественных прилагательных. «Красивый» пиджак для одного человека будет приталенным, а для другого, наоборот, широкого покроя. Так и с любыми проектами: чем больше конкретики, тем лучше.
Хороший подрядчик будет конкретизировать и уточнять неоднозначные строчки в ТЗ, но это потребует дополнительного времени на переделку. Поэтому лучше стараться минимизировать недопонимание. И постараться определить для себя конкретные требования к продукту еще до разговора с исполнителем.
Бывает, что заказчик не знает, что конкретно хочет получить, причем часто сам того не осознавая. Из-за этого в ТЗ появляются расплывчатые и многословные формулировки. В итоге заказчик с исполнителем потратят значительное время на их уточнение. Эффективнее сделать ТЗ с конкретными и точными требованиями, без многословности.
Алексей Орлов
Руководитель проектов компании «Рексофт»
Стоит попробовать любые пожелания сводить к количественным требованиям.
| Не подходит | Подходит |
| Выводить на главной странице сайта популярные товары | Взять самые покупаемые товары за неделю и показывать их на первом экране сайта в блоке популярных товаров. С возможностью добавить товар в корзину за один клик. |
Дайте подрядчику общую информацию
Расскажите подрядчику, чем занимается компания, кто ее целевая аудитория, поделитесь нюансами работы — это поможет исполнителю лучше вникнуть в проект и избежать ошибок.
Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.
Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.
Максим Болотов
Гендиректор INOSTUDIO
Помогите разобраться в терминах и нюансах
Подрядчик, как правило, специалист в своей отрасли, в вашей сфере он по умолчанию разбирается хуже. Поэтому помогите ему понять специфические термины или нюансы в техзадании.
Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.
Покажите конкурентов
В ТЗ стоит добавить ссылки на аналогичные проекты и дополнить их описаниями: что конкретно нравится в аналогах, что стоит повторить, а чего точно стоит избегать.
Если заказчик планирует создать продукт, идея которого уже есть на рынке, то имеет смысл изучить конкурентов. Выявить отличительные особенности их IT-решений, чтобы разработать собственное с уникальными преимуществами.
К документу с видением продукта рекомендуем прикладывать ссылки на аналогичные решения. С описанием функциональных блоков, которые вам понравились. Это упростит дальнейшее общение с подрядчиком.
Максим Болотов
Гендиректор INOSTUDIO
Уточните важные технические требования
Если вы делаете IT-продукт, стоит сразу согласовать все технические требования с вашим IT-специалистом и подрядчиками. Это необходимо, чтобы новое решение могло быть интегрировано в ваши имеющиеся платформы и бизнес-процессы.
Например, если вы заказываете интернет-магазин, важно, чтобы его движок мог принимать данные из всех ваших систем — не только обмениваться актуальными ценами с 1С, но и получать информацию из CRM и самописных сервисов.
О нюансах нужно предупреждать подрядчика еще во время обсуждения общего видения проекта и до составления ТЗ. Важно, чтобы исполнитель умел работать со всеми вашими технологиями.
Распишите сценарии использования продукта
Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».
Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:
Опишите требования к проверке проекта
При составлении ТЗ отталкивайтесь не от абстрактных требований к продукту, в таком случае получится многословный и неструктурированный список желаний. Попробуйте вместо этого придумать условный чек-лист, по которому вы будете проверять успешность проекта.
Например, для интернет-магазина это может быть:
Чем подробнее и длиннее чек-лист, тем лучше.
Двигайтесь от общего к частному
Старайтесь собирать требования к продукту от общего к частному. Если вы заказываете дизайн сайта, то сначала стоит рассказать про общую концепцию и пожелания по цветовой гамме. Затем рассказать, какие страницы должны быть на ресурсе. После перейти к описанию требований к каждому блоку на каждой странице. И в конце определиться с элементами в блоках: какой вид и размер шрифта должен быть у текста, как оформляются иллюстрации.
Шаблоны и примеры ТЗ
Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.
Если вы решили составлять ТЗ самостоятельно, эффективнее попросить шаблон или пример у подрядчика. Или поискать брифы, которые предлагают заполнить исполнители у себя на сайтах — вопросы из таких форм можно использовать как разделы ТЗ.
Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:
Эффективнее будет составлять ТЗ вместе с выбранным подрядчиком. Он будет задавать вопросы, уточнять нюансы и структурировать информацию. А вы объяснять, что же вам в итоге нужно от продукта.
Когда ТЗ не нужно
Не стоит самостоятельно составлять техническое задание для любого продукта — зачастую это излишняя работа, которая только запутает и станет бесполезной бумагой для подрядчика.
Эффективнее будет начать с общего понимания задачи — подумайте, что вам нужно от продукта, как его будут использовать, что в нем должно быть, а что, наоборот, точно стоит исключить. Опишите это с использованием не качественных, а количественных характеристик.
С этим пониманием обратитесь к подрядчику. Возможно, он предложит использовать не ТЗ, а гибкие методологии создания продукта — когда сначала делают небольшой прототип, выпускают его, а затем собирают обратную связь от первых клиентов и постоянно дополняют требования на основе этой аналитики. С таким подходом проект реализуется с учетом потребности клиента.
Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще.
Может быть, выгоднее и эффективнее выполнять бизнес-задачу, например, с помощью SCRUM. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.
Владимир Севрук
Гендиректор компании «Информатика и Сервис»
Кратко — универсальные советы по составлению ТЗ
Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:
Не пропустите новые публикации
Подпишитесь на рассылку, и мы поможем вам разобраться в требованиях законодательства, подскажем, что делать в спорных ситуациях, и научим больше зарабатывать.
Начинать разработку IT-продукта с ТЗ — устаревший подход. Как действовать правильно?
Директор IT-компании «Пиком»
Разработку не каждого IT-продукта стоит начинать с ТЗ: есть риск потратить больше времени и денег или создать сервис, который не будет востребован на рынке. Григорий Коган, директор IT-компании «Пиком», рассказал, какие шаги надо пройти на старте, чтобы минимизировать затраты.
Его опыт будет полезен предпринимателям, стартаперам, руководителям проектов, грантополучателям — всем, кто планирует запускать MVP (минимально жизнеспособный продукт с достаточным набором функций, чтобы удовлетворить потребности первых пользователей).
Тест: узнай, сможешь ли ты грамотно выйти на рынок в другой стране
Мы с 2000 года интегрируем умные решения в разные бизнесы: занимаемся сложной веб-разработкой и развитием продуктов, внедряем CRM и ERP-системы, разрабатываем личные кабинеты. Создали более 530 сайтов и веб-сервисов. Имеем опыт заказной разработки для стартапов, а также запуска собственного продукта — MVP экспертной платформы «Консалт-Коллегия».
Здесь эксперты продвигают свои услуги, а предприниматели и топ-менеджеры получают помощь по вопросам, которые сложно или затратно решать своими силами. Администрация платформы организует работу и контролирует эффективность консультаций.
При разработке мы применили новый подход, который помог быстро проверить спрос на продукт, запустить тестовый сервис и собрать данные для создания следующей версии. Ранее мы всегда использовали классический цикл разработки, который начинается со сбора требований и составления техзадания.
Но сейчас становится все больше проектов, в которых такой подход уже не гарантирует успешный результат. И речь даже не о качестве продукта, а о достижении владельцем продукта своих бизнес-целей.
Какие тренды проявились в онлайне
По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.
Веб-сервисы, в отличие от традиционного ПО, позволяют вносить доработки так, чтобы все пользователи автоматически получали последнюю версию, не скачивая обновления. Это дает возможность быстро менять функционал IT-продуктов, добавлять и тестировать новые функции.
Веб-технологии стали доступнее, выросло число пользователей интернета — появилась возможность быстро запускать бизнес на основе несложных веб-решений сразу на широкую аудиторию.
Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.
Причем как количественно — за счет появления новых игроков, так и качественно — за счет расширения клиентской базы.
Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.
И что это меняет?
Сокращается длительность этапа разработки, меняется подход — реализуется только самый необходимый функционал, процессы становятся более гибкими. Вынужденно меняется и сам цикл, который теперь включает не только разработку. Мы давно и долго воспитывали клиентов работать по ТЗ, но сейчас с этим есть две проблемы:
1) Подход с первоначальным проектированием всего продукта не обеспечивает необходимых скорости и гибкости.
Поэтому при разработке по классическому циклу стартап может не взлететь. Пока команда продумывает все детали, учитывает все возможности, реализует весь функционал, пройдет год-два.
Наконец, создан очень качественный сервис. Но потребности пользователей уже изменились, конкуренты запустили другие решения. Проект опоздал: рынок поделен, продукт не востребован, клиенты потеряны. Вложили столько сил и денег, а в результате убытки.
2) Далеко не всегда клиенты четко представляют себе бизнес-модель своего продукта либо готовы тестировать и быстро адаптировать ее в соответствии с реакцией рынка.
Эта проблема находится вне обычной зоны ответственности компании-разработчика. Но мы хотим создавать успешные продукты, которые решают задачи пользователей и приносят прибыль владельцам.
Поэтому мы включили в цикл нашей работы этапы проработки продукта. Парадокс, но выйти на рынок можно быстрее, если на старте, еще до составления ТЗ, дополнительно пройти шесть шагов. Именно так работают Agile-команды: движение короткими итерациями и конкретные результаты каждого этапа. Ниже мы проиллюстрируем эти шаги (и допущенные ошибки) на примере нашего собственного продукта.
Шаг 1. Видение продукта
Нужно найти ответ на ключевой вопрос: зачем пользователям ваш продукт? Для этого необходимо проработать идею и определить, для кого вы делаете сервис и зачем люди будут им пользоваться.
В результате получится концепция, которая состоит из трех разделов:
Пример
Идея собственного продукта — экспертной платформы — появилась у нас после попыток решить свои сложные задачи. У большинства бизнесов рано или поздно возникает нетиповой запрос, который требует узких знаний.
Внутри команды их нет. Можно нанять консультанта. Но как определить его компетенции? На виду обычно те, кто активнее себя продвигает. Однако, навыки самопрезентации не равны профессионализму: часто бизнесу учат те, кто им никогда не занимался.
Более надежным кажется сарафанное радио, но и оно не гарантирует качества работы. У нас был подобный негативный опыт: для заключения договора аренды нам рекомендовали юриста, который специализируется на сделках с недвижимостью. Потом выяснилось, что договор составлен не в нашу пользу, а за досрочное расторжение предусмотрены серьезные санкции.
Возникла идея собрать носителей узких знаний в одном месте. На такой площадке эксперт может предложить свои услуги, а клиент — найти консультанта. В роли экспертов могут выступать как специалисты, так и предприниматели с релевантным опытом. Многие из них не позиционируют себя как консультантов и не представлены в публичном поле.
Шаг 2. Аналитика
На этом этапе надо более глубоко погрузиться в рынок, изучить целевую аудиторию и провести анализ конкурентов — не только прямых аналогов, но и любых продуктов, с помощью которых потенциальные клиенты решают свою задачу.
Пример
Я провел более 20 проблемных интервью со знакомыми предпринимателями. Часто это был не запланированный опрос, а спонтанный разговор о том, что их беспокоит. Я обобщал информацию, находил причинно-следственные связи. Формировалась проблематика проекта: дефицит квалифицированных кадров, кризис доверия к консультантам, сложности цифровизации бизнеса и эффективной коллаборации для решения деловых вопросов.
Мы привлекли к реализации проекта нашего партнера бизнес-сообщество «Конгресс-коллегия». В основу концепции легли две составляющие:
Анализ конкурентов выявил, что у большинства массовых B2B-сервисов взаимодействие между заказчиками и консультантами не контролируется. Потенциальный клиент регистрируется и выбирает исполнителя под свою ответственность. Если вопрос не решился, спрашивать не с кого.
Мы поняли, что процессами нужно управлять в ручном режиме. У платформы должна быть администрация, которая подбирает лучшего исполнителя под конкретную задачу, следит, чтобы клиент получил результат, а также формирует пул готовых решений для базы знаний.
Шаг 3. Генерация идей
Задача этапа — собрать все идеи, которые можно реализовать в продукте. Для этого проводят мозговые штурмы, опросы потенциальных пользователей.
Пример
Мы определили мотивацию у консультантов и клиентов. У экспертов есть потребность в масштабировании своей деятельности. Многие из них тратят время на переговоры и отбор проектов, а также вынуждены вкладываться в личный бренд. Платформа предлагает готовую методологию для входа в консалтинг, позволяет минимизировать издержки на продвижение и выстроить процесс взаимодействия с клиентами.
У клиентов возникают два типа запросов: либо получить консультацию по интересующей его теме (например, как оптимизировать налогообложение), либо оперативно решить конкретный вопрос (что делать при выездной налоговой проверке). В зависимости от этого администрация платформы будет работать по разным схемам.
Шаг 4. Проверка гипотез
Концепция проекта оформлена. Теперь на ее основе надо сформулировать гипотезы, приоритизировать их и проверить, насколько они рабочие.
Недостаточно просто опросить потенциальных потребителей, стали бы они пользоваться таким продуктом. Результаты будут зависеть от личного отношения к вам. Для глубокого исследования нужно использовать специальные инструменты:
Если отработать процесс один-два раза, потом на этот этап будет уходить минимум времени.
Пример
Для проверки гипотезы по экспертной платформе мы разработали маркетинговые материалы и провели презентацию для участников бизнес-сообщества. Получили положительные отклики и заявки от желающих стать экспертами. Затем приступили к разработке тестовой версии.
Шаг 5. Формализация требований
На этом этапе составляют список функциональных требований к продукту — Product Requirements Document. Получится подробное описание функционала с кучей разных фич.
Если у стартапа нет технического фаундера, описание IT-составляющей продукта может быть не проработано. Потом окажется, что реализовать функционал дольше и/или сложнее. В таких случаях лучше привлекать технологического партнера для оценки IT-решений.
Пример
У нас получилось развернутое описание проекта на 40 страниц. Полный список функционала включает в себя создание цифрового образа каждого эксперта, открытого рейтинга экспертов, базы знаний, личного кабинета, модуля сбора и анализа статистики.
Шаг 6. Выделение MVP
Из всего набора требований выделяют критически важные функции, без которых нельзя запустить продукт. Если функционал сложный и нетиповой, при разработке ТЗ стартаперу может быть сложно учесть все детали и визуализировать результат, что потом грозит объемными доработками и внеплановыми расходами. Именно поэтому сначала рекомендуется разработать MVP.
На этом этапе выделяют:
Запуск минимальной версии позволяет протестировать продукт на реальных пользователях и собрать обратную связь. Ценен любой результат. С одной стороны, можно понять, как дальше развивать продукт, и продолжить разработку по классическому циклу. С другой — если тестирование показало, что продукт не выстрелил, может быть принято решение закрыть проект. Именно это помогает сэкономить деньги и ресурсы.
Пример
Мы разработали MVP экспертной платформы с минимальным функционалом:
Лендинг и каталог экспертов собраны на «Тильде». Бэкенд реализован на «Битрикс24». Механика следующая:
Наши факапы: что мы не учли и к чему это привело
Мы прошли шесть шагов до ТЗ, но все-таки допустили просчеты. Что можно было сделать иначе для лучших результатов:
Я сам как владелец продукта разрабатывал концепцию платформы в свободное от других задач время. Мы привлекали сотрудников, занятых на других проектах. Разработка MVP затянулась более чем на полгода. Если бы работала выделенная команда, проект реализовали бы быстрее и проще.
Мы выявили и подробно описали боли ЦА — предпринимателей и экспертов. Но не убедились в том, что формат экспертной платформы наиболее востребован целевой аудиторией. Тестовая версия могла бы быть проще — не отдельный сайт, а группа на Facebook со списком услуг и конверсионной кнопкой или канал в Telegram с чат-ботом для записи на консультации.
Можно было создать сайт не на «Тильде», а на «Битриксе». Тогда на верстку ушло бы меньше времени — через админ-панель было бы удобнее выкладывать контент.
Мы недооценили себестоимость создания цифрового образа эксперта. Эта работа состояла из нескольких этапов: отправка вопросов и получение заполненной анкеты, интервью с экспертом, написание, согласование и верстка текста для его персональной страницы. Всего на каждого эксперта уходило пять-шесть часов.
Когда мы начали продвигать платформу с помощью разных инструментов: презентаций на бизнес-мероприятиях, рассылок, посевов в соцсетях и Telegram-каналах — на нас хлынул поток заявок от экспертов. Ресурсов на обработку стало не хватать. На первом этапе можно было сконцентрировать усилия только на привлечении клиентов, но не расширять пул консультантов.
