Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

В июне наша компания завершила проект на общую сумму в $20 тысяч. Контракт мы получили через Upwork. Это такая популярная международная биржа для фрилансеров. Контракт закрыли успешно — заказчик поставил пять звёзд и написал хороший отзыв.

Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

К такому результату мы шли полтора года. До этого наш средний чек был $500. Если посмотреть карточку компании, то может сложиться впечатление, что дела идут хорошо. Но на самом деле это не так — мы приостановили работу с платформой и сократили целый отдел. Всего этого можно было избежать.

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

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

— “Это всё потому что UpWork диктует нам свои правила”.

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

Логично предположить, что биржа фриланса является двигателем гиг-экономики, суть которой в выполнении мелких заданий для множества клиентов. Но на самом деле это не так. При расчете комиссии Upwork смотрит, как долго вы работаете с отдельным заказчиком. Поэтому выгодно делать наоборот — выстраивать долгосрочные отношения с клиентами и искать заказы покрупнее.

Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

При этом, чтобы получить привилегии и больший контроль над своей учетной записью, необходимо каждые три месяца успешно закрывать 10 контрактов. Это даст возможность общаться с техподдержкой в чате и удалять негативные отзывы от клиентов. Чтобы угодить всем алгоритмам и не отдавать кучу денег, нужно найти заказчика, у которого для вас всегда найдется работа, и уговаривать его постоянно открывать новые контракты и оставлять отзывы за закрытые. Задача не из простых.

Но рынок всегда накладывает на участников ограничения. Несмотря на жесткие условия, Upwork является практически бесплатным источником лидов, и, судя по всему, все действия биржи направлены на улучшение их качества. А если вам что-то не нравится, то вас никто не держит.

Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

— “Но они же за океаном, у них сейчас ночь!”.

Мы ограничили географию поиска офферов США и Канадой. С восточным побережьем у нас разница в 8 часов. Есть целых два часа, чтобы рассказать заказчику, что вы успели сделать сегодня и что планируете сделать завтра. Можно даже устроить созвон в рабочее время. Но так сложилось, что большинство стартапов, которые нуждаются в аутсорсе, расположены на западном побережье. Рабочие часы с ними уже не пересекаются — когда мы едем домой с работы, они только заваривают себе утренний кофе.

Разница во времени мешает действовать оперативно. Вся работа может встать из-за пустяка. Клиент предоставил неправильные доступы? Ждите, пока он проснётся. Нужно уточнить параметры задачи? Ждите, когда закончатся рождественские каникулы. Но эти моменты решаемы. Мы наладили рабочий процесс, который устраивал и нас, и заказчиков.

Не удалось решить эту проблему в пресейлах. На этапе первого контакта с потенциальным заказчиком скорость реакции очень важна. Чтобы он продолжил переговоры, нужно с порога убедить его в своей экспертизе. Менеджеру для этого не всегда хватало технических знаний. А привлечь к созвону разработчиков было невозможно, так как они хотели работать строго с 9 до 6.Не важно, откуда ваш заказчик. Все клиенты хотят одного и того же. Им нужно лучшее качество за меньшие деньги. Любой клиент ожидает гарантии и хочет быстрого решения своих проблем. В конечном итоге, клиент платит зарплату сотрудникам. Об этом нельзя забывать.

— “Мобильная разработка совсем не такая, как веб-разработка”.

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

Все, что нужно знать о разнице мобильной и веб-разработки — это то, что первая очень сильно зависима от третьей стороны. Вы можете создать что угодно, но решающее слово за вендором — только Apple и Google решают, что попадет в их магазин приложений, а что нет.

Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

Практически ни разу выкладка приложения не проходила у нас гладко, что отрицательно влияло на срок поставки. Речь сейчас даже не о нарушениях гайдлайнов — не получалось отдать билд на тестирование из-за сбоев в работе Itunes connect, а однажды пришлось месяц ждать ответа от Apple, чтобы узнать, что проблема была на их стороне.

В случае с Google вы еще зависите от решений конкретных производителей смартфонов. На сегодняшний день в производстве более 16 тысяч сертифицированных устройств. Может случится так, что ваше приложение не будет запускаться лишь на одном из них. Так один раз случилось с нами — мы сделали простой сканер, который не запускался только на Lenovo, которую закупили для всех работников склада. В итоге, еще больше времени ушло на дебаггинг через тимвьюер и установление причин.

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

— “А чего вы хотели? Геймдев — не наш профиль!”

Любой тендер на Upwork буквально за час набирает полсотни откликов. С такой конкуренцией кажется, что заполучить проект — это как айфон за репост выиграть. Но есть верный способ выделиться среди кандидатов — показать релевантный кейс. Чтобы ваше письмо заметили, скажите, что вы уже делали что-то подобное.

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

Так мы заполучили свой самый большой контракт на бирже и взялись за разработку настоящей игры. В этот момент у разработчиков появилось новое оправдание — они не нанимались в компанию на роль разработчиков игр. Они объясняли, что не видят смысла расти в этом направлении и не хотели углубляться в связанные с этим технологии. Ребятам казалось, что навыки, полученные в процессе, не пригодятся им в «настоящей» разработке софта.

Примерно вот так чувствовали себя разработчики, окончательно застряв в текстурах
Примерно вот так чувствовали себя разработчики, окончательно застряв в текстурах

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

Программистам ежедневно приходится не только писать код, но и изучать разные технологии. Так и происходит карьерный рост. Все навыки, полученные в геймдеве, легко перенести на другие сферы деятельности.

— “И как нам быть без тимлида?!”

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

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

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

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

Шесть фраз, к которым мы не прислушались, и поэтому закрыли отдел разработки

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

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

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

— “Нам нужно затащить этот кейс в портфолио, вот тогда заживем!”

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

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

Менеджер смотрит статистику легаси-приложения в консоле эппстора
Менеджер смотрит статистику легаси-приложения в консоле эппстора

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

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

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

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

Важно признать, что вы не исключительные. Скажите себе, что вы обычные люди, которые выполняют обыкновенную работу. И нет ничего особенного в том, что сейчас вы взяли неудачный проект или пошли не в том направлении. Такое со всеми случается. Люди постоянно ошибаются. В этом нет никакой специфики. Максим Батырев в своем бестселлере “45 татуировок менеджера” посвятил этому целую главу, которую мы, судя по всему, читали невнимательно. Глава называется “Признание специфичности смерти подобно”.

44
2 комментария

Спасибо за статью. 
Почему не удалось договориться с Тимлидом о работе до конца проекта? Так и полкоманды могло уйти за ним и что тогда делать?

Ответить

Тут два момента. Во-первых, мы расстались с тимлидом в хороших отношениях. Уходя, он дал слово, что поможет завершить проект  и действительно пытался проявлять участие. К сожалению, с новым графиком это оказалось практически нереально. Во-вторых, команда лучше знала кодовую базу и утверждала, что  со всем справится самостоятельно. Так и произошло. Основная проблема заключается в том, что никто не попытался приложить чуточку больше усилий. Всех устраивало сослаться на какую-то объективную проблему, а не вложиться в её решение. Время шло, а деньги заканчивались. Как только проект сдали, поняли, что лошадь сдохла.      

Ответить