Мы — разработчики на аутсорсе, но ходим к инвесторам клиента и помогаем с кастдевом

А еще — отказываемся от разработки, если приложение нужно «потому что у всех есть». Рассказываем о нашем подходе — с метриками, маркетинговым анализом и оценкой, нужен ли вообще ИТ-продукт

«Целый год убили на разработку приложения, а результата не видно».

«Отдали разработчикам 3 млн ₽, а продукт не решил задачу — повысить лояльность клиентов».

Знакомо? С такими болями к нам часто приходят компании, которые уже обожглись на разработке ИТ-решений. Так происходит по нескольким причинам, одна из них — разрыв в коммуникации между заказчиком и разработчиком. Первый не рассказал об истинных задачах продукта, второй — не стал копать, а просто выполнил заказ.

Так рынок получает продукты ради продуктов, «потому что у всех конкурентов есть мобильные приложения», «потому что гендир так решил» и тому подобное.

Мы в DNA Team против такого подхода: можно, конечно, бездумно выполнять заказы и получать деньги, но мы за пользу для бизнеса. Подробнее о нашем бизнесовом и сервисном подходе в разработке — в этой статье. Может быть полезно тем, кто планирует заказать сайт, мобильное приложение или любой другой ИТ-сервис для бизнеса.

Есть стереотип, что в ИТ-компаниях работают технари-«душнилы», с которыми тяжело сотрудничать: они кодят только то, о чём их попросят, не выходя за рамки техзадания. Мы — точно не такие. Чтобы составить коммерческое предложение, нам важно изучить ситуацию конкретного клиента. Может оказаться, что клиенту, который пришел за новым сайтом, он вообще не нужен: бизнес-задачи можно решить маркетингом, а не разработкой.

Вот пример. Однажды к нам обратился клиент. Он планировал запустить премиальный сервис доставки товаров для животных. Сервис должен был включать сайт, мобильное приложение и систему по работе с курьерами и складами. Причем старт продаж планировался через 3 месяца: клиенту было важно проверить гипотезу о том, что сервис будут использовать из-за мгновенной доставки.

Мы изучили задачу и поняли, что для быстрого тестирования гипотезы достаточно лендинга: на разработку всей системы уйдет больше времени и это будет стоить дорого. Поскольку мы не делаем лендинги, проект не случился. Но заказчик остался благодарен нам за то, что мы помогли ему решить бизнес-задачу и не стали разрабатывать рискованный сервис вместо MVP — за несколько миллионов рублей.

Мы не открыли Америку: наши рекомендации клиенту банальны, но не у всех предпринимателей есть понимание, как проще решить задачу именно в техническом плане.

У каждого бизнеса что-то «болит»: например, нужно уменьшить операционные расходы или создать новый канал продаж. Мы стараемся заранее выяснить, какой цифровой продукт закроет запрос клиента.

Мы не рассчитаем стоимость проекта на первой встрече. Можем дать только ориентиры, вилку. Наше сотрудничество с клиентом начинается с подготовительного этапа, в течение которого мы:

Подготовительный этап — или, как мы его называем, пресейл — для клиента бесплатный. Он может занять 2–4 недели. Да, это не слишком быстро.

Итогом подготовительного этапа становится коммерческое предложение и дорожная карта — стратегический план проекта, который показывает, куда проект должен прийти, в какие сроки и какой заложить фундамент, чтобы проект мог развиваться.

Для начала просим клиента заполнить бриф: 30+ вопросов о бизнесе, о целях, метриках, конкурентах, референсах. Пример брифа можно посмотреть здесь. Не все готовы вручную вписывать ответы на все вопросы. В этом случае мы заполняем их вместе с клиентом в формате интервью.

Затем запрашиваем у заказчика данные о клиентах. Не просто пол, возраст и интересы, а подробное описание болей и сценариев взаимодействия с компанией. Если у клиента нет исследования ЦА, мы можем за отдельную плату предложить такую услугу — у наших специалистов есть опыт в маркетинге. Это редкость для студии разработки и мы этим очень гордимся.

Например, недавно наш дизайнер делала новый сайт для частного детского сада. У заказчиков было мало данных об аудитории — и дизайнер предложила провести кастдев. Клиент обзвонил почти всех клиентов садика — родителей, и спросил, что им важно видеть на сайте.

Оказалось, многие заходили на сайт, чтобы узнать, работает ли с детьми логопед и проводят ли занятия по эмоциональному интеллекту. Мы использовали этот инсайт и при разработке добавили на видное место блоки с нужной информацией.

Проводим глубинные интервью с заказчиком. Менеджер созванивается с клиентом и выясняет его пожелания и ограничения. Мы не стесняемся задавать «глупые» вопросы, если уверены, что они помогут лучше понять компанию и её запрос.

Показываем мудборд. Это следующий этап, чтобы понять, каким клиент хочет видеть готовый продукт. Словами объяснить иногда сложно: «максимально простой» стиль для дизайнера — это минимализм, а клиент мог иметь в виду, что его раздражает объёмный шрифт.

Готовим дорожную карту продукта. Дорожная карта — план, который показывает, как будет развиваться продукт и какую базу для этого нужно подготовить уже сейчас. Это как при строительстве дома: лучше сразу определить, сколько этажей вы хотите возвести, и закладывать фундамент, который выдержит эти масштабы. Неважно, что денег на отделку всех этажей у вас пока нет: когда появятся, просто продолжите стройку.

В дорожной карте прописываем функциональность и этапы развития продукта: например, если сейчас задача — создать сайт с информацией о компании, а в дальнейшем — продавать товары на этом же ресурсе, мы сразу разрабатываем возможность «пристрелить» на сайт личные кабинеты пользователей, чтобы не пришлось впоследствии создавать отдельный сайт для продаж.

Вот пример. Мы много лет работаем с Лабораторией Касперского — делаем облачную систему, где компания хранит маркетинговые материалы. Иногда у бренда меняется фирменный дизайн, и заказчику важно, чтобы на бренд-гайдлайнах и шрифтах внутри системы можно было указать «срок годности» — используется ли материал до сих пор или уже в архиве.

В начале мы торопились сделать хранилище к определенному сроку, поэтому создали простую систему с базовым поиском. Но через полгода заказчик вернулся к нам за более специфическими настройками: нужно было сократить время, которое менеджеры тратили на поиск нужного файла. Мы смогли усилить систему, потому что заранее подумали о её возможном развитии.

Составляем коммерческое предложение. Только на этом этапе мы готовы озвучить клиенту стоимость разработки — в этот момент и нам, и клиенту понятно, что получится в итоге. Поэтому цифра не взята с потолка и не будет меняться просто так.

А на рынке такое часто встречается: клиент обращается за разработкой, команда готовит проект, в котором еще много неточностей, темных пятен. Клиенту озвучивают одну стоимость, а когда в процессе выплывают эти темные пятна, цена растет. И понятно почему: на берегу многое не предусмотрели, не обсудили. А у заказчика уже выбора нет, он на середине пути, приходится соглашаться.

Когда есть понимание, каким должен быть результат, мы переходим к проектированию. Этот этап занимает обычно не меньше 30% от всего процесса, но мы заключаем отдельный договор на проектирование и берём за него фиксированную оплату. Так мы защищаем себя и клиента от бесконечного переделывания ТЗ и каких-то внезапностей.

С клиентом работает команда бизнес-аналитиков и продуктологов, а еще — технические специалисты высокого ранга, например архитекторы.

Мы составляем техническое задание для продукта, утверждаем структуру — за этим стоит несколько этапов погружения в проект, а занимается подготовкой ТЗ целая команда.

Для наглядности разрабатываем интерактивный веб-прототип — черновое наполнение продукта, без дизайна и деталей, набросок с концепцией расположения блоков, кнопок и других элементов. Обсуждаем с клиентом, что нравится и не нравится, согласовываем и используем эти наработки.

Благодаря тому, что выделяем этап проектирования в отдельный, мы можем не закладывать лишних рисков в сроки и бюджет на этапе разработки.

Вы спросите: а что в итоге? Ну, потратили вы месяц на подготовку, сделали дорожную карту, прототип, а что потом? А потом — предсказуемый для всех сторон этап разработки. Минимум правок, недопониманий и несовпадений ожиданий и реальности.

Не все готовы ждать столько времени, чтобы узнать стоимость разработки. И не все готовы глубоко погружаться в свой продукт и тратить время на длинные интервью с командой разработки. Зато так мы отсеиваем тех, кто ждет от нас магии и телепатии, надеется, что мы все придумаем сами, без их участия. Как вы могли догадаться, это невозможно.

Еще немного о том, что называем сервисным подходом.

У нас нет такого, что проект передают из отдела в отдел, а клиенту приходится каждый раз ставить задачу новым специалистам: менеджер, который обрабатывал заявку в самом начале, присутствует в проекте до конца и знает весь персональный трек, к нему всегда можно прийти с вопросами. И не только к менеджеру — наши технические специалисты тоже готовы проконсультировать клиента и объяснить архитектуру разработки.

Кроме того, заказчик в любое время может связаться с основателями и руководителями студии — со мной или моим партнером Димой Забавиным, и высказать свое волнение или беспокойство.

Пока идет разработка, мы готовы выступать как часть команды клиента и защищать проект перед инвесторами или биг-боссами другого уровня, если это поможет отделу.

Несколько раз клиенты просили нас с Димой рассказать о продукте инвесторам. Мы выступали как часть команды клиента, а не просто подрядчик, и презентовали инвестору приложение, рассказали, как будем им управлять, на что потратили деньги, почему выбрали именно такие решения. Этого не было в договоре, но мы, тем не менее, помогали клиентам.

После разработки мы не бросаем проект: держим связь с заказчиком, можем выступить в роли техподдержки, усовершенствовать что-то со временем или в чем-то помочь.

Сниму белое пальто: мы тоже не идеальные разработчики, мы тоже иногда сдвигаем сроки, порой и у нас возникают проблемы, потому что в любом ИТ-проекте случаются непредсказуемые вещи. Но суть сервисного подхода в том, что мы всегда на связи с клиентом, всегда делимся тем, как выходим из кризисной ситуации и готовы решать проблемы вместе.

Подрядчик не отчитывается вовремя о ходе работ, дедлайны сдвигаются, клиент не понимает, с кем обсудить проблемы — менеджеры ничего не понимают, никто не беспокоится, что нужно успеть к открытию магазина 1 декабря. Понятно, что аутсорс-разработчики — просто подрядчики, они не привязаны к бизнесу клиента. Но мы за то, чтобы становиться партнёрами, а не исполнителями.

У такого подхода, который мы называем сервисным, много плюсов.

Но минусы тоже есть.

Мы уделяем клиенту больше времени, чем могли бы, — и некоторые этим пользуются. Иногда мы тратим командные ресурсы, но клиент отказывается от разработки. В моменте это идет нам в минус, но в будущем может принести профит. Например, когда клиент, с которым не стали работать, рекомендуют нас знакомым.

Как вам такой подход? Готовы пару недель ждать КП?

#разработкаприложений #аутсорс #сервис