Давайте мы вам напрограммируем: как помочь клиенту с выбором технологического стека, если вы просто «продаёте людей»
Модель «продажи людей» и аутстаффинга уже давно на слуху — много компаний работают в этой плоскости, много материалов написано, много клиентов прошли через это. Но есть и обратная сторона такого формата работы, о котором говорят не так много — технический консалтинг. Как грамотно его оказать, не навязывая клиенту своё мнение? И почему вообще нужно помогать заказчику?
Всем привет! Меня зовут Сергей Полуэктов, я СЕО IT-компании MediaSoft. Мы занимаемся заказной разработкой с 2014 года по направлениям backend, frontend, mobile, analytic и QA. Недавно я выступал на ежегодной конференции Mind Bros Conf с докладом о технологическом консалтинге в аутстафф модели.
Мы не пытаемся залезть в бизнес-составляющие клиента. Мы лезем в проектные решения, архитектуру и те тонкости разработки, которые клиент не всегда может самостоятельно разрулить. Я постарался провести границу между проектами, где «всё понятно», и проектами, где «не очень понятно».
С проектами, где «всё понятно» вопросов не возникает. Но что делать, когда приходит заказчик категории «не очень понятно»? Я разберу 5 кейсов, которые иллюстрируют наши решения внутри компании.
Кейс 1. Пришли за PHP, получили Elixir.
К MediaSoft обратилась большая международная компания за решением на PHP, которое выдержало бы миллион контактов онлайн. Разработчики посмотрели и поняли, что слишком большой риск того, что сайт рухнет. Клиенту так и сказали — написать можем, но можем и подобрать решение удачнее. Провели тесты на PHP, Go и Elixir и продемонстрировали клиенту результаты. Нам дали полную свободу. Как итог — клиент, с которым мы сотрудничаем уже 5 лет.
Кейс 2. Пришли за нативом, получили Flutter.
Когда к нам приходят за небольшими и несложными мобильными приложениями, в из платформенных решений там только оплата, мы предлагаем Flutter. Это ускоряет процесс разработки до 20-30% часов и уменьшает бюджеты. Понятно, что это можно делать только в том случае, когда глобальных доработок и добавления сложных платформенных решения не предвидится. Клиенты переживают, что кроссплатформенные решения недостаточно эффективны, но нам несложно объяснить преимущества такого решения.
Кейс 3. Проектный менеджмент есть, но нет.
Бывает, что клиент приходит за людьми и технической экспертизой, но оказывается, что квалификации менеджера не хватает или самого менеджера просто нет. В одном кейсе получилось так, что со стороны клиента оказался не проджект-менеджером, а backend-разработчиком. Поэтому видимых результатов за месяц не было.
Мы предложили проектного менеджера на part-time, чтобы оптимизировать работу и повысить прозрачность процессов. С этим клиентом сотрудничаем второй год, а наш менеджер всё ещё на проекте.
Кейс 4. Экономим на инфраструктуре.
Одному из клиентов нужно было решение, связанное с написанием микросервиса к продукту, который делали не мы. Сервис строил статистику и анализировал данные. Звучит не очень сложно, но суть в том, что количество данных огромное, а количество человек, желающих смотреть их в real time — ещё больше.
Решение «в лоб» не подходило, хотя именно за ним пришёл клиент и попросил людей. Мы решили провести исследование и выяснили, что можно сэкономить на серверах, если использовать облачное решение от Amazon. Адаптировали решение с учетом сервисов AWS и в итоге сэкономили на обслуживании инфраструктуры.
Кейс 5. Новаторство.
Киллер-фичи, которые нужны для решения, завязаны на том, с чем ни мы, ни клиент раньше дела не имели. Управление датчиками расхода воды и умной розеткой, сделать бегающее животное в WebGL, отслеживание прогресса в процессе чтения и другие идеи формата «стартап».
В таких случаях мы сначала продаём короткий спринт в формате исследования, определяем критерии результата, получаем или не получаем функциональный прототип, переходим в режим классической разработки, формируем и расширяем команду, получаем лояльность клиента и желание работать только с нами.
Зачем нам всё это нужно?
Мы пытаемся понять, какой экспертизы клиенту не хватает, чтобы получить полноценную проектную команду. Так, решая боль клиента или давая ему чуть больше, чем он просил, формируем лояльность клиента. Технологический консалтинг зачастую оказывается за пределами аутстафф модели. Это помогает выстраивать долгосрочные и более прогнозируемые отношения, более гибко управлять нагрузкой на производство, повысить интерес и вовлеченность разработчиков и развивать технологическую экспертизу в компании.