Содержание |
Рынок заказной разработки сегодня
Раньше всем было удобнее работать гибко — планомерно заниматься созданием ИТ-продукта, параллельно с разработкой тестировать гипотезы, принимать решения, изменять его конечное видение и ТЗ. И подрядчик легко мог подключать необходимые ресурсы, расширять/сушить команду, вместе с клиентом экспериментировать. Под такой процесс идеально подходил формат T&M взаимодействия с подрядчиками.
За последние два года горизонт планирования сильно сократился, к бюджетам стали относиться строже, изменениями стали управлять жестко, и бизнес теперь приходит с запросом на проекты с понятным сроком/бюджетом и пользой: гипотезы ставятся на старте, их нужно проверить быстро, качественно и не выпасть из бюджета, что автоматически приводит нас к необходимости работать в моделе FIXED Cost.
На подрядчиках оказываются все риски, поэтому им надо уметь хорошо планировать и считать: понимать истинную потребность клиента, формулировать техническое решение, которое реально можно разработать в нужные сроки, и подписаться под стоимостью проекта, а значит — быть уверенным в решении, которое ты предложил.
В такой ситуации многие коллеги по рынку предлагают свои услуги заказной разработки по модели Retainer (что по сути выкуп команды клиентом), тем самым возвращая на сторону заказчика все риски непопадания в бюджет/сроки.
|
Retainer — формат взаимодействия, при котором поставщик устанавливает бюджет и резервирует определенное количество часов для работы, выполняемой на регулярной основе. Формат подразумевает наличие собранного бэклога задач, но без жесткой фиксации по бюджету всего проекта. |
Мы, 65apps, в прошлом году решили, что верным шагом будет научиться работать с потребностью рынка в Fixed Cost и построили качественный процесс лидотрансформации — обработки входящих запросов и доведение их до проекта (трансформация «лида» в «проект»). Для этого собрали выделенную команду технических продаж, которая помогает клиентам дойти до результата на условиях, отвечающих современному запросу рынка.
Уникальная команда senior IT-специалистов
Задача команды технических продаж — сделать так, чтобы клиенты успешно встречали заявленные цели. В своей работе они по сути являются билингвами — разговаривают на языке бизнеса и на языке технологий. Экспертно понимают бизнес-запрос и чутко ощущают мотивацию команды клиента. Умеют копать в глубину и понятно презентовать решения. Соединяют продукт, который действительно нужен клиенту, и реальную техническую возможность его разработать в доступный срок и бюджет.
Наша сборка такой команды состоит из трех человек: руководитель — хэд технических решений, бизнес-аналитик и РМ (менеджер проектов). Это все специалисты уровня senior — они очень хорошо разбираются в ИТ, многообразии технологий и бизнес-процессах. У каждого 10+ лет опыта работы в продуктовой и заказной разработке на разных уровнях: от разработчиков, аналитиков до управленцев. Эти ребята на практике, а не в теории прошли все этапы разработки ИТ-продуктов и вывода их на рынок.
Они участвовали в десятках проектов разного объема и направленности для крупнейших российский компаний и государства: разрабатывали банковские порталы, модули и системы автоматизации, создавали b2b-порталы, редакционные системы для СМИ, панели администрирования для интернет-магазинов и сами интернет-магазины, работали с геоинформационными системами, медицинскими учреждениями, голосовыми помощниками, криптографией и многим-многим другим.
Эти знания, опыт, насмотренность позволяют им быстро схватывать боли клиентов, предлагать релевантное решение, здраво оценивать его сроки и стоимость.
Дополнительную экспертизу под каждый проект пресейла мы подтягиваем из производства по необходимости и составу задач: это может быть лид mobile- / backend-разработки, арт-директор, solution- или бизнес-архитектор, либо лид направления екомма, финтеха или IoT. Мы на рынке больше 12 лет, и за это время сформировали несколько центров компетенций.
Три современные задачи клиентов, которые решает команда технических продаж:
1. Трансформация аморфной задачи в понятный запрос
Не все клиенты приходят в описанным ТЗ и заранее проработанным описанием задачи. Как правило, нужно вместе сформулировать и гипотезу, и верхнеуровневые требования к ней.
Для этого команда проводит custdev и включает творческий подход — примеряет на себя роли бизнес-архитектора, СТО, CPO, CDTO, РМа и других. Так клиент может обстучать свою идею с разных сторон: для чего нужен проект, какие задачи он закроет, какие фичи нужны, как проект будет встраиваться в общую архитектуру, как разделить процесс на этапы, когда и какой может быть MVP.
Порой на этом этапе становится понятно, что клиент пришел с запросом, который не соответствует его истинной потребности. Например, хочет нативное мобильное приложение, когда для решения его реальной задачи подойдет лендинг на Тильде + PWA (прогрессивное web-приложение — технология в web-разработке, которая визуально и функционально трансформирует сайт в приложение) или чат-бот в телеграмме.
И наоборот — на этапе погружения становится понятно, что клиенту на самом деле недостает кусков цифровой стратегии развития. И тут мы тоже помогаем: включаем «helicopter view», комплексно смотрим на бизнес-модель и подсказываем, где, как и что необходимо доработать.
|
Такие случаи тоже не единичны. Например, один клиент пришел с запросом на починку мобильного приложения — ему казалось, что оно медленно работает, и поэтому компания на нем недозарабытывает. Когда мы пошли копать вглубь, оказалось, что команда клиента до конца не понимает, как именно продукт должен генерировать прибыль, настроены ли процессы маркетинга для потока трафика, и кто в принципе ответственный за направление канала продаж через мобильное приложение. В этом случае говорить, что приложение неэффективно — необоснованно, так как нет точки отсчета этой эффективности. Мы посоветовали клиенту в первую очередь прописать стратегию, роли, определить технические гэпы, собрать бэклог и только тогда браться за разработку и починку продукта. Иначе, приложение мы бы починили, но совсем не факт, что это помогло бы клиенту больше зарабатывать. |
2. Проработка точно реализуемого технического решения
Когда становится понятно, какую задачу нужно закрыть — подбирается оптимальное техническое решение. Мы смотрим на то, что есть у клиента в ИТ-ландшафте, какие планируются интеграции, подбираем необходимый уровень сложности архитектуры, безопасности и тд. В том числе на этом этапе мы можем провести RnD и дать рекомендации, какие сторонние готовые продукты использовать.
|
Иногда на этом этапе мы можем выяснить, что под запрос бизнеса уже существуют готовые решения, которые полностью закрывают его потребности. В этом случае мы только рады, что смогли помочь клиенту и сэкономили ему бюджет. |
Учитывая, что сейчас фокус сместился на скорость, подрядчикам важно не просто все делать быстро, но и продуманно — создавать такие решения, которые будут органично вписываться в общий архитектурный ландшафт клиента.
В современных крупных компаниях уже есть большое количество различных систем, и наша задача — продумать, как разработать продукт, который будет полезен и не превратит ИТ-инфраструктуру в «зоопарк». Так мы гарантируем, что на выходе клиент получит не кота в мешке, а реальный инструмент, который будет работать и приносить деньги.
Тогда и разговор о стоимости разработки сразу становится предметным.
|
Если компания с миллиардным оборотом планирует запустить новый канал продаж и вырастить в нем за год до 30% выручки, то становится оправданным запрос на обеспечение требований к высоким нагрузкам, максимальному быстродействию, безопасности, продуманный UI и многое другое. Эти статьи затрат легко конвертируются в будущие выгоды и прибыль. |
3. Гарантия адекватной стоимости, под которую компания может подписаться
Понятную задачу, у которой снижены риски и проработана техническая часть, проще оценить и не разлететься по вилке в +/- 10 раз.
Когда мы уверены, что предлагаемое клиенту решение именно то, что ему нужно, что именно оно закрывает его задачи и разработка пойдет по предложенному нами плану — мы можем обосновать и защитить стоимость.
Оценки таких проработанных решений могут быть выше, чем у конкурентов. Но мы можем гарантировать, что наше предложение реально будет сделано в заявленный бюджет и срок, будет закрывать задачи клиента, и мы не придем на середине проекта с запросом на расширение бюджета/сроков/скоупа.
|
Один из первых проектов, пройденных через команду технических продаж, в прошлом месяце пришел к релизу. Мы создали b2b-портал для логистического оператора «РУЛОГ» в рамках большого проекта импортозамещения, где уложились во все договоренности. Сейчас к порталу подключено 1200 клиентов «РУЛОГ» и он обеспечивает более 1000 заказов ежедневно. |
Конечно, доля неопределенности на этапе пресейла будет всегда. Всех рисков на старте мы снять не можем, и это нормально. Главное понятно донести это клиенту и команде разработки. Все оставшиеся риски регулируются уже на этапе разработки проекта, и это компетенция проектного менеджера — управлять проектным треугольником и его рисками.
Процесс выделенной лидотрансформации существует в 65apps уже год. За это время через него прошло более 80 проектов.
Команда постоянна в составе, пресейлы ведутся до момента, пока производство полностью не примет проект к себе и не наладит прямую коммуникацию. А при необходимости они, как владельцы знаний о клиенте, подключаются к сложным вопросам уже в процессе производства и помогают работать с рисками и договоренностями.
Плюс ко всему эта команда систематизирует всю работу с лидами и консолидирует внутри знания, что сильно ускоряет процесс продаж и улучшает качество предложений. В случаях, когда клиент возвращается после нескольких месяцев «обдумывания», все знания о его идее проекта хранятся в команде технических продаж — нет нужды заново погружаться, выяснять особенности и ограничения. И мы стартуем проект кратно быстрее.
5 блоков вопросов, над которыми стоить подумать перед тем как обратиться в компанию заказной разработки:
- Какую проблему вы хотите решить с помощью разрабатываемой системы? Какие результаты ожидаете? Какие потери или негативные результаты возникнут, если проблему не решить сейчас?
- Есть ли сформированные требования к будущей системе или нужна помощь в выявлении, формировании и фиксировании данных требований?
- В какие сроки вам необходимо получить решение? С чем связаны эти сроки?
- Определен ли бюджет на разработку проекта?
- Готовы ли вы делить функциональность будущей системы на несколько итераций: выделять этап MVP и далее его дорабатывать, или вам необходимо получить сразу всю функциональность будущей системы?
