В июне наша компания завершила проект на общую сумму в 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 татуировок менеджера» даже посвятил этому целую главу — «Признание специфичности смерти подобно», которую мы, судя по всему, прочитали невнимательно.
Мы хотим вернуться на UpWork, но на этот раз нам нужны люди, которые просто будут добросовестно выполнять свою работу и не считать, что занимаются чем-то особенным. И если вы такой человек, то свяжитесь с нами.
Комментарии (34)
Dekmabot
11.11.2019 13:10+1Для меня показательным является уже то, что менеджер поручил отделу веб-разработки делать мобильное приложение. Ладно, сеньор может и разберётся во всех этих лэйаутах и интендах, но тоже не быстро и не в рамках сроков коммерческого договора, так как отличия существенные. Про джунов вообще молчу, а судя по тегам, вы вышли на поле с ними.
Как в том анекдоте: "… Ну, не шмогла я, не шмогла".
Но пример показательный, давайте его не будем минусовать, кому-то будет наукой.
worksolutions Автор
11.11.2019 13:20Возможно, я не совсем ясно описал в самом посте, но отдел мобильной разработки не входил в основной состав компании. То есть, в нём работали специально выделенные разработчики, которые к вебу не имели никакого отношения. Тимлид — да, пришел из веба, но мобилку знал хорошо.
balexa
11.11.2019 19:05+2Да там все показательно.
Привлекать на такую роль отдельного человека было дорого, поэтому в качестве наставника выступил один из ключевых сотрудников.
Т.е. такой человек со стороны стоил бы дорого, а ключевой сотрудник — стоит дешево. Вот и славно. Странно даже, почему этот ключевой сотрудник так неожиданно покинул компанию.
Neikist
11.11.2019 13:25+1В этот момент у разработчиков появилось новое оправдание — они не нанимались в компанию на роль разработчиков игр. Они объясняли, что не видят смысла расти в этом направлении и не хотели углубляться в связанные с этим технологии. Ребятам казалось, что навыки, полученные в процессе, не пригодятся им в «настоящей» разработке софта.
Я вот тут полностью согласен с разработчиками. Навыки абсолютно перпендикулярны разработке прикладных приложений. Сужу по себе, к сожалению есть опыт разработки простенькой игрушки, мне даже на сорцы смотреть не хочется, очень скучное для меня занятие, и вообще никак не помогло вырасти как мобильному разработчику. К тому же еще и не факт что были гейм дизайнер и дизайнер отдельные, есть подозрение что эти роли тоже на разработчиков возложили.
Есть люди которым интересно разрабатывать прикладные приложения (бизнес логику продумывать, хранение данных, UX и т.п.), а есть те кому интересно разрабатывать игры. И, подозреваю, эти множества не очень то пересекаются. А если заставить разработчика заниматься неинтересным ему делом — можем получить прокрастинацию, выгорание и фигню вместо решения.
kaljan
11.11.2019 14:20+3Работать за три гроша в команде без тимлида, с неадекватным работодателем, у которого не построен диалог и коммуникации внутри фирмы, нет сбора обратной связи (или ее игнор), разработчикам навязывают свой стек, и который хочет, чтобы я работал по графику заказчика — спасибо, откажусь, и никому не посоветую
Читать надо не только 45 татуировок менеджера. Книга полезная, но это как описывать слона, дергая его за хвост
Stasgar
11.11.2019 15:02+2но на этот раз нам нужны люди, которые просто будут добросовестно выполнять свою работу и не считать, что занимаются чем-то особенным
Очень странная завершающая мысль. Будто вы не научились на своих же ошибках, описанных в статье. Программист, который просто «выполняет свою работу и не считает это занятие чем-то особенным» — скорее всего не очень хороший специалист.
Ваш подход «берем любой заказ, лишь бы набрать отзывов» — достаточно опасен сам по себе. А когда этот же подход перекидывается на разработчиков — это еще грустнее.
BugM
11.11.2019 16:46Простите, а где вы взяли разработчиков хотящих работать с 9 до 6? В 1-2 жаворонков в команде я поверю, но всю команду на такой график сильно прогибать придется.
Кажется что вы свои хотелки с хотелками разработчиков путаете.
worksolutions Автор
11.11.2019 17:55Это, скорее, фигура речи — у нас график относительно гибкий, и вы, наверное, не поверите, но больше половины разработчиков работают с 8 до 5, тогда как могут прийти к 10 и уйти в 7. Это нормально. Мысль немного о другом.
Neikist
11.11.2019 19:06Я вот не поверю. На моей практике при гибком графике раньше 11 приходит меньше половины сотрудников.
balexa
11.11.2019 19:34А я охотно поверю. Составьте статистику отдельно по тем коллегам, у кого есть семья, и кто холостой. Если ребенка к 8 нужно отвести в садик, а до 19 забрать его оттуда — то лучше всего работать с 9 до 6. Если нет детей, но вторая половинка работает по четкому графику — то лучше приходить домой тоже одновременно.
А вот молодые-холостые — да, приходят на работу к 11-12,BugM
11.11.2019 20:19Социальная группа "Отцы отводящие детей в сад" составляет явно меньше половины среднего коллектива разработчиков.
Вот и получается что половина хочет ездить к 11-12. Пробок меньше, людей в транспорте меньше. Красота.
У автора "все" хотят работать с 9 до 6. С
Все совершенно добровольно хотят встать пораньше и ехать в час пик.Matisumi
12.11.2019 13:36Да имхо лучше пораньше начать и пораньше закончить, чтобы вечером еще свои дела поделать можно было. А к 11-12 едешь — вроде и с утра ничего не сделаешь, и вечером уже тоже поздно что-то делать.
Neikist
12.11.2019 13:48Вот только в 8-9 утра до работы 40 минут добираться по пробкам, а часов в 11 уже минут 10-20. То же в обратную сторону. Вроде мелочь, но экономится время здорово.
Alesh
11.11.2019 23:02Неожиданно уходит тимлид, который днём наставляет джунов, а ночью исправляет их косяки. Да уж, действительно неожиданно :)
Frimko
12.11.2019 07:02мда, неплохо описана фирма с которой нужно бежать без оглядки, а лучше и вовсе отсеить на этапе трудоустройства.
werevolff
13.11.2019 06:42+1А теперь возьмите и напишите вторую статью, в которой развенчаются оправдания менеджмента:
- Мы ждали, что биржа нас поймёт и простит.
- Мы скинули контакт с заказчиком на разработчиков и не хотели решать проблемы коммуникации.
- Мы посчитали, что разработчики могут выполнить любую работу. Онижпрограммисты.
- Мы не хотели строить иерархию в разработке и ждали, что разработчики будут сами рвать пятые точки за наш интерес.
- Мы наняли не профессиональную команду и отказались её обучать, при этом требуя от неё архитектурных решений.
- Мы кормили джунов сказками о том, как мы классно заживём, когда проект капнет нам в портфолио.
- Нам не был нужен рейтинг. Нам был нужен киллер-проект в портфолио.
- Мы не сделали выводов, когда свалил тимлид.
- Мы решили запилить статью на хабре с рассказом о нормированном рабочем дне, не забыв упомянуть о том, что наш тимлид исправлял косяки джунов по ночам.
- Мы уволили нафиг всех джунов. В нашем портфолио есть киллер-проект и положительный отзыв заказчика. Приглашаем опытных джунов в наш хоррор квест. Добро пожаловать в ад, мясо!
ExellionNet
13.11.2019 10:19Я наверное что-то упустил… В начале статьи говорится, что проект успешно завершили и даже получили положительный отзыв… А зачем тогда отдел разработки распустили? Сейчас у меня впечатление такое, что джуны вытянули проект, который не должны были тянуть, а вы их в благодарность уволили, потому что они возмущались много...
worksolutions Автор
13.11.2019 10:46Не понятно, что вы имеете в виду, когда говорите, что они не должны были тянуть проект.
Возвращаясь к вопросу — увольнять людей всегда непросто. И эта история не про то, как мы сократили конкретных сотрудников, которые с чем-то не справились, — напротив, ребята выросли в профессиональном плане и моментально нашли себе работу уже в качестве pre-middle. Решение было закрыть отдел мобильной разработки, а статья о причинах, по которым такое решение было принято.mad_nazgul
13.11.2019 11:09Т.е. вы признаетесь, что были «кузницей кадров» и за счет клиента обучили для других компаний специалистов?!
Это мне напоминает «бизнес по русски» :-)worksolutions Автор
13.11.2019 12:13Если брать нашу ключевую компетенцию, веб-разработку, то мы ежегодно тратим больше миллиона рублей на обучение сотрудников. Курсы, сертификации и прочее. У нас также есть план развития для джунов и система наставничества. Так что нет — мы не бросаем новичков в бой, без подготовки выполнять коммерческие задачи. Мобильный же отдел начинал с нуля. Там не было сложных проектов. Джуны выполняли задачи по своему уровню под присмотром наставника. Что касается, ухода в другую компанию — нам было нечего предложить им внутри (хотя мы обсудили с Android-разработчиком вариант остаться у нас изучать spring).
Alex_Builder
13.11.2019 12:15Это статья, кстати, очень хорошо отражает ужас, в который порой превращается современный IT.
С одной стороны «эффективные менеджеры»(tm), коим часто по образованию по-хорошему нужно торговать помидорами на рынке, бойко крича, демпингуя и отбивая себе место под солнцем среди кавказских торговцев в кепке.
С другой стороны, приблизительно такие же по уровню «программисты»-самоучки сразу после школы/колледжа или месячных курсов примитивного жаба-скрипта с отточенным навыком и умением гуглить, какую именно жаба-скрипт библиотеку нужно молниеносно закачать для решения той или иной проблемы (конечно, если такая библиотека уже есть).
Все это сливается в банду aka команду и бежит на фрилансовые площадки отбивать себе место под солнцем, бойко конкурируя с индусами в чалмах, работающими за еду, и стремиться выполнять аж по 10 контрактов в месяц!
И как при этом люди в компаниях годами и десятилетиями выпускают, развивают и совершенствуют один и тот же продукт?!
Наверное, у них просто нет таких чудесных «эффективных менеджеров» и замечательных и реактивных «жаба-скрипт исполнителей».
И, наверное, это к счастью :)
DrunkBear
Люди добросовестно выполняли свою работу — следовали указаниям тимлида.
Нет тимлида — нет работы.
И вы конечно извините, но «просто выполнять работу» и «найти и устранить утечки памяти» — это совсем разные компетенции, у обычного человека они отсутствуют.
История про «мы ждали, когда разработчики самоорганизуются и родят техлида, а они ждали техлида от нас» — просто эпик! Работающих коммуникаций и бизнес-процессов нет, вообще нет, иначе бы не ждали.
Frimko
не удержался, думаю все можно описать одной картинкой