Антон Сахаров – автор контента на сайте

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

No items found.