За 12 лет на рынке IT мы сотрудничали с разными клиентами, в том числе, – всемирно известными компаниями: делали приложение с программой лояльности для McDonald’s и изучали новые способы доставки контента для спортивного телеканала ESPN с 86 млн зрителей.
А американский сервис по доставке продуктов за полчаса, для которого мы создавали продукт с нуля, взорвал рынок: стал «единорогом», и его стоимость сейчас оценивают в $15 млрд.
На нашем опыте мы сформировали свои принципы по работе с крупными клиентами и хотим поделиться как они помогают развивать бизнес.
От мелких стартапов до «крупной рыбы»
MLSDev – украинская IT-компания по разработке мобильных и веб-приложений для клиентов из США, стран Ближнего Востока и ЕС. В основном, мы работаем с проектами в сферах электронной коммерции и здравоохранения.
Первые пять лет мы сотрудничали только со стартапами. Мы сами были еще маленькой компанией и понимали, что вряд ли будем интересны большим клиентам.
Все основатели стартапов верят, что создадут «единорога» и покорят мир – на практике 99% проектов проваливается.
Так было и с нашими заказчиками: из сотни продуктов, которые мы разрабатывали, «выстрелил» один. Постепенно этот стартап превратился в полноценную компанию, а мы получили первый опыт работы с крупным клиентом.
После этого мы решили, что и нам пора расти. Стали ориентироваться на средний бизнес – компании со стоимостью проектов от сотен тысяч долларов до нескольких миллионов.
Что мы делали
Чтобы привлечь таких клиентов, мы полностью изменили стратегию маркетинга. Как правило, клиенты обращаются к нам по рекомендациям или переходят на наш сайт с площадок по поиску IT-подрядчиков.
Раньше они видели на нашей главной странице текст в духе: «Работаем со стартапами, сделаем проект не за все деньги мира». Это актуально для маленьких компаний, которые впервые выводят на рынок продукт и у них нет больших бюджетов на разработку.
Тогда как у состоявшихся компаний обычно есть продукт, пользователи, своя доля рынка. От IT-партнера они ожидают не столько «десяток умных голов по привлекательной цене», сколько понимание их ниши, долгосрочных задач и «болей», которые нужно закрыть с помощью технологического решения.
Сейчас у нас на сайте написано, что наша компания «в первую очередь фокусируется на привнесении добавочной стоимости вашему бизнесу, что приводит к более высокой прибыльности». А наша цель – «создавать решения, которые точно соответствуют вашим потребностям и рыночным условиям».
Такое позиционирование помогает привлечь внимание крупных клиентов.
Предлагаем не разработчиков, а стабильность
В ходе переговоров мы всегда показываем, что у нас есть все ресурсы, чтобы реализовать проект крупного клиента. В первую очередь, это касается команды: клиенты часто интересуются уровнем текучки в компании.
Крупные компании планируют проекты на годы вперед, а потому им важно, чтобы IT-подрядчик мог гарантировать стабильность.
IT- специалистам нравится, что мы предлагаем им разрабатывать реальные продукты, у которых уже есть реальная аудитория. Ребята создают новые функции – и сразу видят результат своей работы, получают отзывы от пользователей.
Это помогает поддерживать их мотивацию.
Фундаментальные подходы
Двое из сооснователей компании – технари, и это во многом сразу определило наш подход к разработке продуктов.
Даже когда мы только начинали и сотрудничали со стартапами, все равно использовали фундаментальные подходы: разработка через тестирование, рефакторинг, непрерывная интеграция, резервное копирование данных.
Все это помогло нам не только сформировать базу для привлечения крупных клиентов и вырасти, но и выработать свой подход к найму сотрудников.
Сооснователи MLSDev
Как формируем команду
Вот три основных критерия, на которые мы смотрим при подборе технических специалистов:
- Фундаментальные знания компьютерных наук. Это самое важное: технологии постоянно меняются, а теория остается неизменной. Если у человека есть сильная база, но не хватает практического опыта – он разберется уже в процессе работы.
- Знания по специализации. Мы ищем человека на конкретный проект и не можем не оценивать владение ключевыми технологиями, которые понадобятся именно в этой работе.
- Личные качества и навыки.Если первые два пункта необходимы, чтобы человек в принципе подошел на вакансию, то совпадение по личным качествам – это то, что позволяет ему остаться с нами надолго.
При оценке личных качеств мы ориентируемся на список, который предложил Джоэль Спольски, создатель программ StackOverflow и Trello. За годы работы он показал свою эффективность.
Важный момент: если бы мы просто набирали в команду хороших и умных ребят, то у нас ничего не получилось бы – этого мало.
Крайне важно, чтобы каждый сотрудник стремился понимать и понимал бизнес, на который он работает.
Никогда не понижаем планку при подборе
Например, если программист создает приложение для водителей службы доставки, то он должен знать, как устроена вся цепочка – от формирования заказа до его непосредственной доставки клиенту. Так он сможет более качественно решить задачу бизнеса, а это и есть главная цель его работы.
Если говорить в целом о первых двух пунктах, то мы не снижаем планку во время подбора, что бы ни происходило на рынке труда, как бы сложно ни было находить людей. Ведь те, кого мы берем в команду, напрямую влияют на качество нашей работы.
Чтобы нанимать бизнес-ориентированных сотрудников, во время интервью мы обязательно оцениваем их кругозор, в частности, профессиональный.
К примеру, мы рассчитываем, что Backend-разработчик (программист, который отвечает за внутреннюю логику сайта/приложения – Прим.ред.) знает или хотя бы хочет знать, что происходит у его DevOps-коллег (программисты, которые отвечают за любую автоматизацию задач – Прим.ред.).
Фразы вроде «моя работа – код писать» или «меня это не интересует» – означают автоматический отказ в трудоустройстве.
На своем опыте убедились: лучше подождать полтора-два месяца и все-таки найти нужного специалиста, чем взять того, кто не полностью соответствует нашим требованиям.
Да, так можно выиграть в краткосрочной перспективе (например, закрыть нехватку рук на проекте), но в долгосрочной – есть риск потерять большого клиента.
Несколько раз мы делали исключения, но в итоге это всегда приводило к убыткам и расставанию с сотрудником.
Я лично уделяю вопросу подбора немало времени и внимания: в свое время сам проводил технические интервью с кандидатами, регулярно объяснял команде по найму, как важно не отклоняться от утвержденного «курса».
Также обучал и обучаю технических специалистов правильно проводить собеседования: сначала рассказываю, на что нужно обращать внимание, затем помогаю все отработать на практике – вместе с ними несколько раз интервьюирую кандидатов и направляю их общение.
Убираем бюрократию, но следим за дисциплиной
Один из главных вызовов в работе с крупными клиентами – это коммуникация по проекту. Часто в нем могут быть задействованы десятки людей.
С одной стороны, нужно убирать лишнюю бюрократию и барьеры, чтобы вопросы решались быстрее.
С другой стороны, важно понимать и принимать риски такого подхода.
Прежде всего, это скрытые конфликты между сотрудниками, которые могут приводить к негативным последствиям – вплоть до увольнений. Потому стоит все же сохранять определенную долю формальности и дисциплины.
Ограничиваем количество звонков
Мы еще в 2016 году стали нанимать людей на удаленную работу. Это было нужно, чтобы не ограничиваться только локальными специалистами и быстро расширять команду, если этого требует проект.
Поэтому еще до локдауна 2020 года мы усвоили главное: залог успешной дистанционной работы – регулярная, прозрачная и эффективная коммуникация по текущим задачам.Общения должно быть максимально много, но все же не чрезмерно.
Чтобы работа не превратилась в бесконечные созвоны, мы ограничиваем количество звонков.
Как правило, ориентируемся на четыре основные встречи из методологии SCRUM: планирование спринта (промежуток времени, необходимый для выполнения запланированной совокупности операций – Прим.ред.), ежедневные 15-минутные «летучки», обзор итогов спринта и ретроспективное совещание (предложения по совершенствованию – Прим.ред.).
За каждой встречей закрепляется модератор, обычно это менеджер проекта. Он следит, чтобы обсуждение шло по плану и не превращалось в демагогию.
На ежедневной 15-минутной встрече по планированию задач на день модератор задает всем участникам команды три вопроса: что человек делал вчера, что будет делать сегодня и есть ли какие-то препятствия, которые могут помешать достичь цели проекта?
Как мы обжигались
Раньше мы уже несколько раз «обжигались» из-за недостаточной дисциплины. Например, модератор задавал разработчикам два первых вопроса и пропускал третий – полагал, что если есть трудности, то человек и так о них расскажет.
Однажды это привело к тому, что менеджер проекта все же узнал о проблеме слишком поздно – компания потеряла десятки тысяч долларов прибыли.
Дело было в том, что топ-разработчик долго никому не рассказывал о низком качестве кода, который написал новичок. В итоге проект дошел до состояния, когда проще переписать с нуля, чем исправить.
Переписывали, конечно, за счет компании. А если бы узнали о проблеме раньше, то могли бы вовремя заменить разработчика на более опытного.
Не замалчиваем проблему
Крупные клиенты любят прозрачное и предсказуемое сотрудничество. При этом, никогда не выйдет свести все риски к нулю: всегда есть вероятность, что ключевой член команды заболеет или решит покинуть компанию.
Самое плохое, что можно сделать в таком случае – замалчать проблему. Клиент начнет переживать и может задуматься о разрыве контракта. Мы действуем по-другому: сами идем к клиенту и обо всем рассказываем.
При этом важно не только честно сказать о проблеме, но и объяснить, что мы делаем для ее решения.
Возможно, это повлечет задержку по срокам – такое бывает, это рабочий момент. Скорее всего, клиент воспримет это нормально, если вы предупреждаете заранее.
Однажды благодаря честности мы сохранили клиента
Как я уже упоминал, нашим первым крупным заказчиком стала компания, которая начинала свой путь как стартап и вместе с нами превратилась в состоявшийся бизнес. После того как их продукт «выстрелил», они сверхбыстро росли. И мы не успевали делать свою работу на той скорости, которую от нас ожидал клиент.
Нам не говорили прямо, что планируют отказаться от наших услуг, но мы чувствовали – к этому идет.
Тогда мы решили, что нужно развиваться вслед за клиентом. Для этого мы привлекли внешних консультантов: они помогли нам составить список проблем и план по их устранению.
Чтобы быстрее разрабатывать новые функции, мы решили разбить нашу команду на три: каждая сможет работать с разной частью продукта независимо от других. Также внедрили сервис круглосуточного мониторинга и поддержки облачной инфраструктуры, чтобы разработчики смогли сосредоточиться на создании нового функционала. Улучшили процессы коммуникации.
Этот план мы показали клиенту и попросили дать нам время. Заказчик нам поверил – и мы работаем вместе уже более восьми лет.
Благодаря этому случаю мы поняли, как адаптировать свою команду к проектам для крупных компаний, а также убедились, как важна честность и прозрачность.
Поддерживаем отношения с клиентами
Начинающим предпринимателям может показаться, что если они подписали контракт с большим клиентом, то поймали Бога за бороду – теперь все будет хорошо, можно почивать на лаврах.
Но это не так: отношения с клиентом нельзя пускать на самотек. Их нужно поддерживать – это задача уже не программистов и даже не менеджеров проектов, а топ-менеджеров компании.
Лучший способ поддерживать отношения – живое неформальное общение.
После личной встречи клиент и команда осознают, что работают с реальными людьми, а не с «портретами» в мессенджерах. Между ними возникает совершенно новый уровень вовлеченности и доверия. В итоге, клиенты готовы отдать нам больше работы.
Однажды мы посчитали, сколько зарабатываем в проектах с онлайн-заказчиками, и сколько с теми, с кем виделись лично. Разница нас поразила: цифры отличались на сотни тысяч долларов в год.
Личные встречи с клиентами
Мы стараемся минимум дважды в год устраивать личные встречи с клиентом. Причем коммуникация должна происходить на всех уровнях: руководителя с руководителем, менеджеров с менеджерами, разработчиков с разработчиками.
Однажды мы год работали с клиентом и пригласили его команду приехать к нам в гости. При личной встрече нам на пальцах объяснили некоторые термины и специфические проблемы.
С помощью обычной доски и маркера это оказалось проще и быстрее, чем онлайн.
Так мы смогли глубже понять бизнес компании. Как я уже говорил, очень важно, чтобы все сотрудники постоянно держали в голове потребности клиента, а не «закапывались» в рутине, забывали о глобальной цели своих действий.
Еще мы на собственном опыте поняли, как важно постоянно задавать клиентам вопросы (как при первом знакомстве, так и на следующих этапах работы).
У нас есть клиент – владелец кафе в арабской стране. На одном из первых созвонов он пожаловался, что платит комиссию 30% сервису по доставке еды. Мы подумали, что это его «боль», и стали готовить предложение по разработке собственного сервиса доставки.
А потом еще в одном разговоре выяснилось, что он рассказал о высокой комиссии на эмоциях. Тогда как реальная проблема в том, что пользователи уходят из-за «кривого» мобильного приложения с меню, которое тормозит и не выполняет своих функций.
До потерь из-за высокой комиссии дело не доходило, потому что клиент в принципе ничего не зарабатывал.
Тогда мы расставили приоритеты по-другому: предложили сначала доработать основной продукт, а потом заняться доставкой.
Этот случай помог нам осознать, что всегда лучше задать даже глупый вопрос, чем молча кивать. Чревато сделать продукт, который не принесет ценности.