Проектирование digital-продуктов

Сергей Иванов: Добрый день, друзья! В эфире программа «Бизнес Online», в студии я, Сергей Иванов. Сегодня мы поговорим о проектировании digital-продуктов. К digital-продуктам мы можем отнести и сайты, и сервисы, и мобильные приложения. Не важно, с чем из них вы столкнетесь, принципы и правила их проектирования являются общими. О том, каковы эти принципы и правила, мы сегодня спросим у нашего гостя — директора по проектированию и аналитике компании Artektiv Алексея Бородкина.
Алексей Бородкин: Здравствуйте, дамы и господа!
С. И.: Привет, Алексей!

Алексей Бородкин, директор по проектированию и аналитике компании Artektiv.
Родился в 1985 году в Москве.
В 2008 году окончил Российский государственный медицинский университет (медицинская кибернетика).
В 2010-2013 годах — маркетолог компании «Наносемантика».
В 2013-2014 годах — директор по аналитике компании qb interactive.
В 2014 году стал директором по проектированию и аналитике компании Artektiv.

С. И.: Расскажи нам, пожалуйста, на какие этапы делится проектирование digital-продуктов, что это такое?
А. Б.: Проектирование digital-продуктов само по себе можно разделить на два глобальных этапа. Первый — это работа с требованиями. Мы приходим к клиенту, мы общаемся с ним, мы собираем его «хотелки». Это его пожелания, его требования, какие-то его мысли, которые, возможно, облечены в форму документов. В общем, мы собираем с клиента всю имеющуюся информацию, проводим самостоятельные исследования, смотрим рынок, смотрим в собственные воспоминания, как мы это делали раньше, пользуемся собственной экспертизой. И сводим это в более или менее формальный документ, под которым клиент подписывается. Это если мы говорим про идеальную схему проектирования, к которой мы стремимся. Это именно первый этап, назовем его «Аналитика». На втором этапе мы начинаем уже не просто очерчивать условия задачи, но и предлагать клиенту решение. И на этом этапе, который занимает, наверное, 75% времени проектирования, мы составляем проектную документацию и разные приложения к ней. Например, прототипы страниц, какие-то эскизы, схемы — все то, что может понадобиться по проекту.
С. И.: Я правильно понимаю, что именно проектная документация является результатом проектирования?
А. Б.: Да.
С. И.: Это не ТЗ, не прототип, не дизайн?
А. Б.: Ну, ТЗ и прототип являются как раз частями проектной документации. Если говорить конкретно про ТЗ, то оно является сердцем проектной документации. Тут еще есть небольшая терминологическая путаница. Мы от словосочетания «техническое задание» сейчас активно избавляемся, потому что оно несет очень много совершенно неправильных коннотаций и вселяет в клиента совершенно неправильные ожидания. Само понятие «техническое задание» родилось в Советском Союзе. И собственно, сейчас есть ужасная конструкция под названием «ТЗ по ГОСТу» родилась именно в Советском Союзе. И используемый сейчас шаблон, если мне не изменяет память, датируется 1989 годом. Для тех времен понятие ТЗ было совершенно правильным, объяснимым и логично используемым. Это было сильно забюрократизированный, четко очерченный набор требований, который предоставлялся исполнителям…
С. И.: Нашим реалиям уже не очень соответствует, да?
А. Б.: Это было именно задание. Как я уже говорил, при проектировании только на первом этапе собираются требования. На втором этапе оно уже предлагает часть решения, то есть описывает продукт. Техническое задание по своему замыслу должно было именно выставлять требования, а уж как разработчик, не знаю, начинки для баллистической ракеты будет делать эту начинку, это его дело. Главное — попадать в требования. Но когда ТЗ стало применяться для веб-разработки, то в задание уже стала входить половина решения. Мы бюрократически описывали условие задачи и еще пытались туда зачем-то всунуть описание решения точно таким же забюрократизированным языком, который был непонятен как для разработчика, так и для клиента. Но оно было таким, потому что так требовал шаблон. Такой карго-культ получался: давайте сделаем все по ГОСТу, и у нас и продукт будет по ГОСТу. Да ничего подобного! Не получается так. И поэтому мы от ТЗ сейчас избавляемся, мы используем слово «продуктовая спецификация». Это описание продукта, но не описание того, как его надо делать. Это не описание того, каким должен быть сервер, чтобы выдерживать землетрясения. Реально, такие требования в ТЗ по ГОСТу встречаются, но это не описывает продукт. Это действительно важное требование, но это не продуктовое требование.
С. И.: Рискну предположить, что проектированием должен заниматься проектировщик, так ли это?
А. Б.: Да, конечно.
С. И.: Можешь описать функциональные обязанности этого специалиста? И всегда ли он присутствует в компаниях как штатная единица?
А. Б.: Сейчас я буду описывать то, что, с нашей точки зрения, должен делать проектировщик. Тема проектирования очень сильно недоработана и на российском рынке, и, как мне говорили, на западном рынке тоже много своих вопросов. Но у нас эта проблема особенно остро ощущается. На наш взгляд, проектировщик должен снимать с клиента требования, он должен общаться с ним. В некоторых компаниях почему-то общаться с клиентом засылают менеджеров, но о будущем продукте должен спрашивать проектировщик, потому что он будет задавать правильные вопросы. И никогда не получается составить список из 15 вопросов.
С. И.: Да еще и шаблон.
А. Б.: Да, у нас шаблон для брифа, мы к клиенту приехали… Это невозможно, потому что у всех клиентов проблемы разные, и надо прощупать все слабые места, надо выяснить всю подноготную будущего проекта, которую у клиента можно получить. Таким образом, проектировщик должен общаться с клиентом. Он должен уметь еще на этапе, когда он пообщался с клиентом, как-то свести эти требования в некий структурированный документ. Проектировщик должен уметь анализировать, уметь рыться в различных источниках информации, уметь собирать инфу для будущей работы. Далее, проектировщик должен обладать хорошими навыками системного анализа и навыками, я бы сказал, умозрительных построений. Он должен в своей голове создать продукт, перенести его в ряд проектных документов, утвердить их с клиентом, поработать над ними. Где-то убедить клиента, что его решение правильное, где-то принять от клиента мнение. Он должен обладать…
С. И.: …способностью превратить концепцию, записанную на салфетке, в нечто более осязаемое и детальное.
А. Б.: Да-да-да, и при этом обладать самокритикой, не быть предубежденным.
С. И.: Ну да, знаменитая юмористическая история о создании пяти красных перпендикулярных линий описывает самую главную опасность, которая нас всех подстерегает.
А. Б.: Именно! И проектировщик, помимо работы над проектной документацией и анализом, должен еще выступать в дальнейшей разработке в роли такого, я бы сказал, военного консультанта, к которому разработчик может обратиться по теме продукта и получить исчерпывающий ответ. Причем ответ не просто из головы: «А вот я думаю, что в этом продукте лучше сделать так», — а со ссылкой на конкретный кусок проектной документации. Проектная документация выступает в роли такого священного писания, на которое все постоянно ссылаются, и не дай бог его где-то нарушить немотивированно, несанкционированно.
С. И.: Какие еще условия должен выполнять проектировщик, для того чтобы не напортачить на самой начальной стадии работы? Каких специалистов он еще должен привлечь? Существует ли такой, действительно идеальный человек, который сразу, даже при наличии самокритики, выполнит все условия заказчика и в собственном видении совместит их в единый, цельный, гармоничный и непротиворечивый продукт?
А. Б.: Совершенно верно. Если говорить про рамки, которые он не должен нарушать, то там базовых принципов не так много. Проектировщик должен работать над проектной документацией не единым куском, а двигаться к готовому продукту плавно. И двигаться от общего к частному, если мы говорим и о требованиях, и о составлении проектной документации. Проектировщик должен постоянно общаться с клиентом и сверять часы на каждом своем шаге. Бывает так, что проектировщик у некоторых компаний собирает требования с клиента, уходит на три месяца, потом появляется со своим видением продукта. Клиент за эти три месяца успевает нафантазировать себе невесть что. Клиент смотрит на то, что приносит проектировщик, и говорит: «Ребята, вы этим три месяца занимались?» Тот такой: «Ну да, мы же думали!» Как в том анекдоте: «Знал, куда ударить, — 98 рублей, удар — 2 рубля». Клиент говорит: «Ребята, ну, это не то, что мы хотели получить». И в лучшем случае приходится тратить дополнительные ресурсы, чтобы приблизить получившийся у проектировщика продукт к видению клиента. Или, что хуже, у клиента напрочь заклинивает мозг от этого несоответствия, у него происходит разрыв шаблона, который приводит к деструктивным последствиям. Приходится клиента «откачивать» несколько месяцев, после этого двигаться к новому продукту. А он уже подозрительный, он уже смотрит с прищуром на всю документацию, говорит: «Ребята, сейчас вы опять что-нибудь пришлете плохое». Начинается жутко дурацкая история. Надо двигаться итерациями, постоянно показывать клиенту, что у нас получается, чтобы и у клиента тоже рамки ожиданий смещались в нашу сторону. Плюс это, естественно, дает нам полезную возможность конкретизировать какие-то наши шаги, если мы ошибаемся. Такое, естественно, бывает, потому что клиент знает свои потребности лучше нас, а мы лучше клиента знаем, как эти потребности реализовать, поэтому мы объединяем экспертизы.
С. И.: Эти тонкости процесса вызывают у меня дополнительный интерес: какая часть процесса проектирования строится на гипотезах, а какая часть на анализе? Как все это проверяется?
А. Б.: Для всех проектов я эту цифру назвать не могу. Все очень сильно зависит от специфики. Если у нас продукт создается с нуля, например, компания выводит на рынок какой-нибудь новый сервис, естественно, мы начинаем работать исключительно на гипотезах, на своем представлении о прекрасном.
С. И.: И вы начинаете проверять это на какой стадии процесса?
А. Б.: Да, часто мы запускаем не финальную, естественно, версию, а некую бету — или публичную, или для своих. На ней мы обкатываем свои гипотезы, смотрим, как пользователи себя ведут, смотрим метрики и начинаем уже на следующих этапах разворачивать продукт в сторону пользователя. Изначально, естественно, первая стадия запуска происходит чисто на наших гипотезах, чисто на нашем каком-то видении. Если речь идет о переделке готового продукта, мы в основу всегда закладываем какие-то метрики, какие-то данные по реальным пользователям, по реальным данным. И наверное, еще один момент, который стоит в этой связи упомянуть: при разработке сложных прототипов мы можем проводить тестирование на целевой аудитории, проводить фокус-группы. Конечно, мы на этом не специализируемся, как некоторые другие компании на рынке, потому что мы не юзабилисты в первую очередь, мы проектировщики. Но все равно мы это делаем для сложных продуктов, и это позволяет нам на ранних этапах понять, туда ли мы копаем, действительно ли мы получаем на выходе то, что должны.
С. И.: Тем не менее мы описываем достаточно сложные, нелинейные процессы.
А. Б.: Так и есть.
С. И.: Но мы же знаем, что в digital время играет ключевую роль. Как выстроить процессы, чтобы не ходить кругами, не срывать сроки, не затягивать?
А. Б.: Да, фактор времени действительно является критичным. Мы уже занимаемся проектированием два года с гаком. За это время мы очень много шишек набили. Когда я говорю «мы», я говорю о себе и о своей команде. Мы кочуем из компании в компанию, потому что команду проектировщиков очень сложно разорвать.
С. И.: Единый организм, да?
А. Б.: Это единый организм, который обычно не разрывается. И мы пришли к следующей методологии. Еще на этапе предпродажи у нас проектировщик активно вовлекается в процесс именно коммуникации с клиентом, и уже тогда он начинает составлять документацию. Как ни парадоксально, проектировщик еще до проектирования начинает свою работу. И эта работа заключается в следующем: приходит к нам клиент, у клиента есть список каких-то требований. В 99% случаев этот список требований неструктурированный, фрагментарный: «Мне нужно разработать такой-то большой блок функционала, а еще чтобы сбоку зелененькая кнопочка была».
С. И.: Проектировщик должен додумать за клиента эту неструктурированную фрагментированную задачу, превратив ее в некое целостное видение, да?
А. Б.: И он должен ее обязательно проговорить с клиентом. На этапе предпродажи клиент общается с проектировщиком, проектировщик «широкими мазками» выясняет, что хочет клиент, и составляет документ, который у нас называется «Концепт». Он касается глобальных деталей будущего проекта. Это целевая аудитория, как она делится, кто это будет. Это какое-то общее видение продукта, общий смысл. И это список функциональных требований, которым проект должен соответствовать.
С. И.: На практике это сильно сокращает время за счет исключения длительного хождения кругами вокруг клиента?
А. Б.: Это колоссально сокращает время. И, что самое главное, это очерчивает круг будущих работ. И на этапе создания документов, о котором мы еще будем говорить, если клиент что-то хочет получить вне этого списка требований, которые оговаривались ранее, мы клиенту сообщаем, что выходим за рамки изначального бюджета, что это приведет к увеличению сроков, к увеличению стоимости. Или мы отказываемся от этого и переносим на следующий релиз, или мы действительно отматываем назад и начинаем буксовать на месте. Мы постоянно клиенту об этом сигнализируем, и клиент чаще всего, конечно, на потом это оставить. Потому что на этапе концепта продукт и в голове проектировщика, и на бумаге должен рождаться цельный, который служит какой-то цели. Даже если эта цель — протестировать на своих же пользователях какую-нибудь маленькую фичу.
С. И.: Всегда ли можно и, самое главное, нужно уже на этапе проектирования оценивать общую стоимость проекта? Как часто бывает перерасход, насколько велик «перелет»?
А. Б.: С этим всегда дело очень интересно обстоит. До начала проектирования единственное, что мы оцениваем точно, по одной из схем образования цены, — это этап проектирования. Пользуясь своей экспертизой, пользуясь своим знанием истории взаимоотношений с этим клиентам или в целом разработки продуктов в той или иной отрасли, мы можем назвать сумму, в которую обойдется проектирование.
С. И.: Плюс-минус, соответственно, да?
А. Б.: Нет, не плюс-минус. Она фиксируется четко. Например, проектная документация займет 125 часов и будет стоить 250 тыс. руб. Но этот подход, конечно, не идеален. Потому что мы все равно закладываем туда некие риски. Клиент может в какой-то момент погрязнуть в собственных согласованиях, например, а у нас будут «проедаться» внутренние ресурсы, деньги. Поэтому если сам проект, например, стоит 200 тыс. руб., мы все равно что-то накидываем сверху чисто ради этих рисков. И получается, конечно, не очень красивая история, что мы обманываем клиента, мы называем ему не стоимость продукта под названием «Проектная документация»…
С. И.: …а страховочную стоимость.
А. Б.: …а страховочную стоимость. И мы обманываем еще и сами себя в ряде случаев, когда мы из этой страховочной стоимости можем выпасть. У нас в свое время были проблемы, когда еще методология не была отстроена, что мы порядка месяца работали себе в убыток. Просто из-за того, что мы не попали в стоимость по ряду причин.
С. И.: Но при этом вы уже изначально заложили некую подушку.
А. Б.: Да, эту подушку мы радостно проели и после этого работали себе в убыток. Это была дикая головная боль, и это стало для нас хорошим уроком.
С. И.: Как же быть?

А. Б.: Идеальной схемой расчета стоимости является почасовая оплата. Она прозрачна для клиента, потому что клиент понимает, на что идут его деньги. Но здесь есть проблемы. К примеру, клиенту мы говорим: «Вы потратите, по нашему опыту, 200-250 тыс. руб., но что конкретно будет, сказать сложно. Может быть меньше, может быть больше, но вы будете видеть, на что расходуется эта сумма». А клиент не всегда готов сделать такой шаг в вечность и не понимает, какие траты ему предстоят.

А вторая проблема заключается в том, что на нашем рынке, к сожалению, принято друг другу не доверять.
С. И.: Да, потому что он не очень развит.
А. Б.: И это небезосновательно появилось. Поэтому клиенты могут не пойти на почасовую схему, потому что решат: «Ребята, вы сейчас будете раздувать часы».
С. И.: Да, непонятно, почему на эту задачу уходит столько-то часов, а на другую в два раза больше.
А. Б.: Именно. И поэтому мы всегда, когда работаем по почасовой схеме, движемся маленькими этапами. На каждом этапе мы показываем клиенту:
— Мы сделали это за столько-то часов. Смотри, тебе нравится?
— Да, нравится. Двигаемся дальше.
И мы постоянно держим клиента в курсе работы, чтобы он понимал, что мы эти десять часов, за которые с него берем деньги, не сидели на месте, просто читая интернет и ничем не занимаясь.
С. И.: Мы говорили о том, что проектировщик является ключевой центральной фигурой при переговорах с заказчиком. Тем не менее менеджер проекта и проектировщик — это не одно и то же лицо?
А. Б.: Нет.
С. И.: Не одно и то же лицо. Насколько часты и возможны конфликты между менеджером проекта и проектировщиком? Может ли менеджер проекта наобещать чего-то такого, от чего проектировщик просто схватится за голову и скажет, что это невыполнимо или идет в разрез с тем, что он уже на предварительных переговорах себе наметил?
А. Б.: Конфликты действительно могут быть. И они рождаются, если недостаточно правильно разведены в компании понятия «продукт» и «проект». Это, как говорят в Одессе, две большие разницы. Продукт — это то, что мы разрабатываем, это то, что должно получиться в итоге. Проект — это все то, что окружает продукт, то есть вся инфраструктура, которая служит для его создания. И если менеджер продукта, то есть проектировщик… Ну, слово «менеджер» мне тут не нравится. Проектировщик является скорее идеологическим лидером продукта.
С. И.: Дизайнер продукта.
А. Б.: Вот! Именно дизайнер в западном смысле этого слова. Не человек, который рисует, а человек, который создает некий целостный вид продукта. Проектировщик отвечает за сам продукт. Он отвечает за документацию, он отвечает за то, чтобы продукт отвечал своим задачам, чтобы на выходе заказчик получил то, что он должен был получить. Менеджер выполняет совершенно иную функцию. Он менеджер проекта. И в его компетенцию входит коммуникация с клиентом — именно коммуникация не по поводу продукта, а по поводу юридической документации, по поводу бюджетов, сроков. Чисто прикладная коммуникация. Коммуникация с командой исполнителей. Это дизайнеры, это разработчики, это те же самые проектировщики. Туда же входит компетенция по разрешению каких-то кризисных ситуаций в общении с клиентом. У менеджера основной головной болью должны быть бюджеты и сроки. Он должен обеспечить, чтобы продукт получился в нужные сроки и «съел» при этом минимум бюджета. У проектировщика задача — чтобы продукт был качественным и отвечал задачам.
С. И.: В том-то и дело, что, действительно, сроки и стоимость могут быть соблюдены, но прокрался какой-то нюанс, из-за которого проект может дорожать или затягиваться по срокам. Как в реальности такие вещи решаются?
А. Б.: Я сейчас для упрощения расскажу, как у нас строится схема работы над проектом. У нас есть этап предпродажи. На нем в паре выступают и менеджер, и проектировщик. Менеджер договаривается по деньгам, по схемам оплаты, ездит туда-сюда с договором. Выполняет организационную функцию. Проектировщик снимает требования, составляет этот документ, о котором я говорил, «Концепт». Дальше, когда мы договорились обо всем с клиентом и подписали договор, мы переходим к этапу собственно проектирования. Проектировщик общается с клиентом, при этом менеджер присутствует. Проектировщик пишет документацию и укладывается в ту сумму, которая отводится на проектирование. После этого проектировщик выходит из активной фазы, подключается менеджер. Менеджер берет проектную документацию, идет к клиенту и говорит: «Наши разработчики насчитали, что по этой проектной документации реализация продукта будет стоить столько-то». Клиент говорит: «О’кей». И дальше первую скрипку начинает играть как раз таки менеджер. Он ходит с этой проектной документацией, он раздает всем указания, он ставит всем задачи на реализацию продукта и к проектировщику обращается только в том случае, если или разработчик чего-то не понимает, или, например, возникают какие-то проблемы по продукту. Проектировщик выступает в двух качествах во время реализации проекта. С одной стороны, он консультирует всех участников процесса, а с другой стороны, он выполняет очень важную контролирующую функцию. До показа клиенту любое готовое то, что в Scrum называется замечательным словом deliverable, некий готовый комплект, будь то комплект шаблонов или кусок функционала, обязательно проходит через проектировщика. Проектировщик ставит свою визу — пускать, не пускать. Если проектировщик говорит «не пускать» и аргументирует, мы это клиенту не показываем. Таким образом мы обеспечиваем качество продукта. И если у нас возникают задержки, — например, действительно проектировщик говорит: «Нет, мы это не пускаем», — надо разбираться, чем это вызвано. Это может быть вызвано несовершенством разработчика, это может быть вызвано несовершенством менеджера, что он за чем-то не уследил. Может быть вызвано несовершенством проектировщика, что в его проектную документацию вкралась какая-то логическая дыра. Это все разбирается, находится виновный, находится решение проблемы, все двигаются дальше. И самое важное, чтобы и менеджер, и проектировщик помнили о своей задаче и постоянно находились в коммуникации друг с другом. Грубо говоря, когда менеджер и проектировщик сидят у клиента, а клиент начинает какие-то идеи давать в обход документации, то должны оживиться и проектировщик, потому что нарушается святая святых — документация, и менеджер, потому что он понимает, что бюджет раздувается, сроки раздуваются. И они каждый со своей стороны должны клиенту объяснить, что происходит.
С. И.: Раз мы заговорили о Scrum, хочу задать тебе вопрос. Digital-продукт можно создавать как по классической каскадной технологии, так и по итерационной модели типа Scrum. Можешь рассказать нашим зрителям об этих двух моделях, как они влияют на процесс проектирования? Ну и какая, на твой взгляд, модель эффективнее?
А. Б.: Начну с конца отвечать. По личному опыту, конечно, предпочтительны гибкие методики разработки, особенно если дело касается сложных сервисов, интранетов, мобильных приложений и всего того, что состоит из кучи взаимосвязанных частей. Отступим на шаг назад и посмотрим со стороны. У нас, допустим, есть некий сложный проект. Сервис, социальная сеть, например. Мы пишем по нему документацию, документация у нас получается большой, несколько сотен страниц. Мы в течение нескольких месяцев над ней работаем, делаем прототипы, все утрясаем, клиент доволен, все хорошо. Мы это отдаем в разработку, разработка занимает еще от полугода до года вместе с дизайном. В итоге мы через год получаем продукт, который был описан по документации, составлявшейся невесть когда. У клиента по ходу пьесы возникают еще какие-то свои мысли. Часть мыслей мы переводим на следующую итерацию, часть приходится вносить в уже имеющуюся продуктовую документацию. И появляется риск возникновения хаоса внутри разработки, когда возникают новые требования, нам надо их рассовывать, сдвигаются сроки, растет стоимость. И клиент готовый продукт не видит, потому что он получается у него уже не через год, а через полтора года, потому что нам пришлось вернуться в проектирование, внести правки в прототип. Оттуда мы вносим правки в дизайн, из дизайна это переходит в программинг, а там у клиента возникают новые идеи, и так мы ходим кругами, не получая ничего на руки. Если мы говорим про гибкие методологии, в чем их плюс? Мы гарантированно на руки что-то получаем через определенные промежутки времени. И конечно же, такой метод работы был бы предпочтителен. Как меняется роль проектировщика в зависимости от выбора «каскада» или гибких методологий? Если мы говорим про «каскад», там проектировщик выступает в роли военного советника: он один раз активно работает и дальше присматривает за процессом разработки. Если мы говорим про гибкие методологии, там проектировщик постоянно вовлечен в процесс разработки. Например, если мы говорим про Scrum, проектировщик фактически оказывается product owner, который собирает требования с клиента, формализует их, надзирает за их разработкой. А так как у нас еженедельно приходят новые требования, еженедельно происходит разработка, проектировщик постоянно варится в этой разработке и не поднимает оттуда головы. Положа руку на сердце, мы стараемся приблизить «водопад» к гибким методологиям. Чтобы у нас были разведены сущности «владелец продукта» и «владелец проекта», чтобы у них были свои области ответственности, свои точки приложения сил.
С. И.: Невероятно интересно! Тем не менее в качестве такого мажорного завершающего аккорда я не могу не спросить тебя, сколько же стоит проектирование digital-продукта. Если возьмем для примера интернет-сайт, то какую долю в его расходах, в его смете составляет проектирование?
А. Б.: На данный момент у нас с ценами достаточно все просто. Час работы проектировщика стоит 2 тыс. руб., если мы работаем по схеме, когда оцениваем всю проектную документацию одним куском. И 1,5 тыс. руб., если мы работаем по почасовой схеме. Туда уже можно не закладывать свои риски, и эта схема прозрачна для всех сторон. Что касается стоимости проектной документации, то это, конечно же, зависит от сайта.
С. И.: Хорошо, а если мы будем говорить о доле в общей смете?
А. Б.: Доли тоже бывают очень разные. Но в целом стоимость проектной документации у нас получается где-то от 150 тыс. руб. до 400 тыс. руб. Это если мы говорим о продуктах средней стоимости. Если говорить про долю, то где-то, наверное, 20-25% от разработки.
С. И.: Это цифры, типичные для digital-агентств?
А. Б.: Мне сложно говорить про типичные цифры, потому что всерьез на российском рынке проектированием занимается две с половиной компании.
С. И.: Хорошо, типичны ли цифры для двух с половиной компаний?
А. Б.: В целом да.
С. И.: Ну что ж, спасибо тебе большое, Алексей, за интереснейший рассказ! Я время от времени забывал, что мне нужно задавать следующий вопрос. Слушал бы и слушал. Я думаю, что это будет также не менее интересно как заказчикам digital-продуктов, digital-проектов, так и исполнителям. Если вас сейчас две с половиной компании, я надеюсь, что будет намного больше. Спасибо!
А. Б.: В свою очередь, спасибо за возможность выступить и донести нашу позицию о правильном проектировании широкой аудитории. Помните, в проектировании сила!
С. И.: У нас в гостях был Алексей Бородкин — директор по проектированию и аналитике компании Artektiv. Это была программа «Бизнес Online», мы говорили о проектировании digital-продуктов. Всего вам доброго, пока!