- Все статьи цикла:
- Почему вашему проекту нужна концепция (вы здесь)
- Состав и структура концепции цифрового продукта
Времена простых продуктов и гениальных одиночек безвозвратно прошли. Сейчас с проектированием чего-то сложнее лендинга уже не справится один-единственный специалист. Более того, даже сама подготовка к полноценному проектированию может отнимать значительное количество времени и ресурсов.
Я ещё помню дни, когда после первого контакта было нормой отправлять клиенту опросник. Затем его место занял более подробный бриф, некоторые даже составляли что-то вроде проектного задания. Названия менялись, и каждая компания вкладывала в них разные значения, но суть оставалась одна: собрать в едином месте первоначальные требования к будущему продукту. Однако и по сей день эти требования частенько собираются кое-как. В лучшем случае это делает аналитик, чаще – вообще какой-нибудь аккаунт-менеджер. Даже в крупных компаниях, которые решают разработать собственный внутренний продукт, требования не всегда формируют действительно компетентные люди. Про грамотную обработку и систематизацию такой информации я даже не говорю. Всё это впоследствии провоцирует целый ряд проблем, иногда – довольно не очевидных на старте.
Почему концепция
Иногда я помогаю внешним проектам: уже запущенным или только разрабатываемым. И регулярно встречаюсь на них с одними и теми типовыми проблемами, которые спокойно можно было предупредить ещё до начала непосредственного проектирования – всего одним небольшим предварительным этапом.
Если говорить о терминологии, то мы в Eleven предпочитаем называть этот этап концепцией. Остальные определения, чаще всего, подразумевают банальный сбор информации без какой-либо её серьёзной обработки. Приступать к проектированию с такими вводными мне лично страшновато. Концепция же предполагает базовые исследования и аналитику уже на самом старте проектного процесса. Она включает в себя сразу несколько других документов и является, по сути, нулевым этапом проектирования.
В этой короткой серии постов мы поговорим о том, какие цели преследует концепция и что входит в её состав. И начнём с того, зачем вообще нужен этот самый «нулевой» этап.
1. Единое информационное поле
Говоря об информационном поле, я подразумеваю комплексное, однозначное и единое представление о будущем продукте у всех участников проектной команды: от разработчиков до клиента, CEO или владельца продукта. Почему важно, чтобы каждая деталь концепции, основа и базовые границы проекта виделись всем участникам проекта одинаково? Если этого не сделать до начала непосредственного проектирования (а уж тем более, до начала разработки), то процесс пойдет намного медленнее и болезненнее. Клиент будет вносить спонтанные, как вам кажется, правки; разработка – использовать не те инструменты, которые следовало бы; а маркетинг готовить совсем другие метрики.
Представьте себе идеальный стартап. Например, сервис по передержке домашних животных. В команде с самого начала сидят CEO, продуктовый дизайнер, аналитики, разработчики и маркетологи. И вроде идея уже сформирована и даже кое-как описана на одном листе А4. Всем кажется, что они точно знают, что нужно делать.
Вот только маркетинг думает, что основная задача сервиса с точки зрения монетизации – свести клиентов и ситтеров, тогда как CEO планирует основной доход получать не с процентов за сделку, а с партнерских программ (например, продавать клиентам корм со скидкой).Разработчики, жадные до новых технологий, хотят сделать новомодное веб-приложение на последнем React’е и уже даже начали набрасывать технический прототип – но они понятия не имеют о том, что одной из фишек сервиса будет являться опция видеонаблюдения за своими питомцами. А у асинхронных библиотек есть определённые проблемы с потоковым видео, и это нужно учитывать.
О CEO и говорить нечего. На старте он почти всегда глубоко убежден, что знает проект досконально. Хотя по факту, чаще всего, не учитывает огромное количество нюансов и деталей: вроде платы за обращение к гугл-картам, необходимости подключать онлайн-кассу или особенностей управления персональными данными клиентов.
Грамотная концепция формирует у всей команды единую картинку продукта. А это довольно сильно влияет на стабильность дальнейшей работы на ним.
2. Определение и фиксация границ проекта
Кроме того, проектное задание призвано свершить еще одно великое дело: очертить первоначальные границы проекта. Определить, что будет в проекте, а чего в нём быть не должно. Из каких частей будет состоять продукт, какие типы ресурсов потребуются для его создания, каким образом будет осуществляться коммуникация с клиентами, партнёрами и так далее.
У вас случалось когда-нибудь, что простенький с виду лендинг к релизу обрастал админкой, мобильным приложением, искусственным интеллектом, чат-ботом и собственным спутником на геостационарной орбите? Тогда вы понимаете, о чём я.
Чтобы проиллюстрировать этот момент, давайте вернёмся к нашему примеру про животных.
Итак, CEO говорит, что между пользователями возможны конфликты и споры. И что если сделка проходит через сервис, мы должны эти конфликты решать. А значит, нужен внутренний сервис тикетов – своеобразный арбитраж, через который любая сторона может подать жалобу на неисполнение условий договорённости.
Вы можете себе представить, сколько усилий уйдёт на создание внутренней арбитражной системы? При том, что она вовсе не является функциональным ядром сервиса – и стартап спокойно запустится без неё. Если дизайнер/проектировщик/аналитик умные, они кратко опишут арбитраж под грифом “следующие этапы развития” – и предложат ввести рейтинг, а спорные вопросы первое время решать через поддержку.
Зафиксируют это в концепции, и тогда в конце проектирования не придётся второпях запускать на орбиту спутник, изыскивая на это и так дефицитные ресурсы.
3. Выявление рисков, недостатков и перспектив продукта
За годы в IT мне удалось поучаствовать в создании многих проектов, включая внутренние продукты крупных компаний. И ни разу – ни на простом стартапе, ни на какой-нибудь системе налоговой отчётности – не было случая, чтобы клиент продумал всё идеально. Всегда возникали проблемы, каждая идея претерпевала множество изменений.
Концепция – не «серебряная пуля», и она не защитит ваш проект от всех коллизий и мутаций. Но она способна свести их к минимуму. Попутно выявляя потенциальные недостатки и векторы развития будущего продукта. Давайте снова обратимся к нашему выдуманному примеру.
Допустим, у нас в стартапе есть гугл-карта с доступными ситтерами. Если пользователей станет много и они будут достаточно активны, то бесплатный лимит запросов к картам очень скоро закончатся. Тогда карта просто перестанет работать. И сделает это, возможно, весьма внезапно. А значит, нам нужно завести в Google Cloud Platform платёжный аккаунт и подцепить к нему банковскую карту, на которой всегда будут какие-то деньги. Да, это можно решить и не на этапе концепции, но предусмотреть подобные вещи в начале не сложно – а они могут сказаться на финансовой модели.
Или представим, что на старте бизнес не уверен, в какую сторону развивать продукт: делать упор на безопасность и вводить платные аккаунты с видеонаблюдением или везде подсовывать продукцию партнёров, получая проценты с продаж. Аналитики рекомендуют сперва изучить потребительский спрос на конкретном продукте, и только потом принимать решение. В этом случае в концепции стоит отразить оба варианта. Чтобы дизайнер построил универсальный UX, а разработчики не блокировали один из них ошибочными технологическими решениями.
Предусмотреть базовые риски несложно. Описать предполагаемые векторы развития – тоже. Можно даже примерно представить, что может воспрепятствовать развитию продукта – и подумать, как обойти или убрать такие препятствия.
4. Первичная оценка проекта и проектирования
Разумеется, на старте очень и очень редко можно дать даже примерную оценку стоимости создания проекта (если это, конечно, не какой-нибудь типовой e-commerce). Однако очертить хотя бы базовый горизонт, понять порядок объема ресурсов, которые потребуются, – можно вполне.
Кроме того, концепция за счёт предыдущих пунктов сильно стабилизирует затраты. Нам не придётся в середине проектирования столкнуться с тем, что продукт нежизнеспособен без какой-нибудь его части – а стоимость её создания сопоставима со всеми остальными работами.
Помните наш стартап? Пользователи в нём делятся на 2 типа:
- те, кто отдаёт животных на передержку;
- те, кто принимает питомцев в своих квартирах на обозначенный срок.
Подразумевается, что вторые должны проходить какую-то предварительную проверку, чтобы первые не отдавали своих мохнатых любимцев кому попало. Однако клиент попросту упустил этот момент, когда говорил с аналитиком, а дизайнеру банально не пришло это в голову. Если нет чётко описанной концепции, этот нюанс всплывет значительно позже – скорее всего, уже на этапе создания прототипа или даже дизайн-макетов. То есть придётся перерабатывать значительную часть пользовательских сценариев. А это может довольно серьёзно повлиять на стоимость проектирования и последующей разработки.
Что дальше?
Дальше вы можете отправить этот пост своему клиенту, когда понадобится подтвердить необходимость концептуального этапа проектирования.
А можете проследовать ещё дальше и перейти к следующему посту цикла – там я расскажу о составе этого самого «нулевого» этапа. О том, какая информация должна входить в концепцию и как она может быть структурирована.
- Все статьи цикла:
- Почему вашему проекту нужна концепция (вы здесь)
- Состав и структура концепции цифрового продукта
