Мы перешли от разовых заказов к долгим ecom-проектам. Делюсь, как работаем, чтобы делать нормально с первого раза
В ecom-разработке важно уметь анализировать, хорошо кодить и разбираться в ритейле. Но это только верхушка айсберга, ведь еще нужно много планировать и правильно расставлять приоритеты. Делюсь, как строим рабочий процесс, чтобы не только доводить ecom-проекты клиентов до конца, но и не переделывать свои же ошибки.
Всем привет, я Андрей Фролов. В 2015 году вместе с партнером Антоном Носковым основали бутик-агентство Metalcode. Мы занимаемся ecom-разработкой: создаем развиваем интернет-магазины в формате выделенной команды, а еще автоматизируем склады и внедряем на сайты клиентов разные фичи вроде личных кабинетов с историей покупок и систем лояльности.
За 10 лет с агентством бывало разное: например, работали в минус или не сходились характерами с клиентами и в итоге возвращали им деньги. Но сейчас такого почти не бывает и мы избегаем крупных факапов. Всё благодаря четкой системе — она помогает сдавать проекты вовремя, ничего не переделывать и строить с клиентами долгосрочные партнерские отношения на годы. В статье делюсь принципами, которых придерживаемся, чтобы вы тоже могли эффективно работать с проектами 👇
Набираем в команду только сильных специалистов, которых не нужно подгонять и заставлять работать
В нашей команде 10 человек. Основа агентства — PHP- и Битрикс-разработчики. Еще есть тестировщик, дизайнеры и контент-маркетолог. При этом все работают удаленно, и только мы с Антоном находимся в одном городе и снимаем общий офис.
Команда сильно влияет на успех любого ecommerce-проекта, поэтому за годы работы у нас сложилась особая корпоративная культура. Вот какие правила появились:
✅ Тщательно отбираем сотрудников. Всё начинается с собеседования: узнаем, что умеет человек, с какими проектами работал. Есть явные признаки, что человек нам не подходит. Например, он не может четко рассказать о своей работе, о прошлом опыте или он у него слишком разный. Но главный красный флаг — человек не занимается никакими проектами на момент собеседования. Мы верим, что хороший специалист всегда в работе. Это как у хорошей команды разработки: у нее не может быть простоя.
Если опыт и хард-скилы устраивают, приглашаем кандидата на испытательный срок. Он и показывает, подходим ли мы друг другу. В нашей команде должны быть только ответственные люди, которых не нужно подгонять, заставлять работать и просить не срывать дедлайны. Этого мы ждем от каждого нового кандидата.
После испытательного срока оставляем только тех, у кого всё в порядке с самоорганизацией и кто будет справляться с работой из домашнего офиса, коворкинга или кафе. Важно: удаленка у нас — это не свободный график. Мы работаем с 9 до 18, как в обычном офисе. У нас нет практики, когда сотрудник занимается задачами три часа днем, а потом три часа ночью. Это помогает строить эффективный процесс.
✅ Строим доверительные отношения. Оговорюсь: мы сразу отказались от понятия «команда = семья». Так быть не должно: в коллективе всегда нужна иерархия, где понятно, кто руководитель, а кто — сотрудник. Но при этом вместе с Антоном строим внутри команды здоровые отношения и занимаем активную позицию. Например, открыто просим сотрудников рассказывать о проблемах и интересах. Так мы понимаем, какие проекты поручать разным людям, и предлагаем помощь, если что-то не получается.
Когда понимаем, что человеку стало тесно в проектах, что он может больше или вот-вот выгорит, не ждем просьбы о повышении или увольнения. Вместо этого первыми идем обсуждать деньги или новую должность. Мы рассматриваем работу как важную часть жизни сотрудников и стараемся поддерживать их рост и цели.
✅ Контролируем задачи. Для этого используем таск-трекер YouTrack. В нем у каждого участника команды есть своя Kanban-доска, где он видит свои задачи. У руководителей — у меня с Антоном — общая доска, где видим все проекты и поручения. Это помогает контролировать рабочий процесс и понимать, на каком этапе каждый из сотрудников.
Четко понимаем, с какими проектами хотим работать
Пять лет назад у нас не было конкретной специализации. Мы делали всё подряд: могли сделать интернет-магазин, а потом сайт института или благотворительного фонда. Все клиенты были на один раз: заказ выполнили — проект закончился.
Потом поняли, что финансовая стабильность возможна только на долгих проектах. Поэтому провели стратсессию с партнером и разобрали, что мы делаем, в чем наши сильные стороны и на что хотим опираться. Постепенно начали уходить от того, что не нравится. Например, отказались работать с SEO-правками, которыми занимались по указаниям SEO-специалистов. Такие задачи в нашем агентстве считаются низкоуровневой разработкой.
В итоге сфокусировались на интернет-магазинах и ecom-проектах и занимаемся сложной разработкой, интеграциях и автоматизациях. С этим изменились и наши клиенты. Сотрудникам стало интереснее работать, а нам это помогло вовремя сдавать задачи и не допускать ошибок. А еще нашли идеальное соотношение: у каждого разработчика максимум три проекта. Благодаря этому все вовремя сдают задачи и никто не выгорает.
Отказываемся от проекта, если заказчик не замотивирован работать
Пока работаем с клиентами, мы находимся с ними в одной лодке. Если что-то пойдет не так, это затрагивает всех, и мы либо не сдадим проект, либо сделаем его плохо. Поэтому, когда видим, что клиент не готов работать сообща, отказываемся от проекта.
Почему еще отказываемся сотрудничать:
📍 Если у клиента нет внутренней команды либо она не готова к изменениям и сотрудничеству с нами.
📍 Заказчик не может назначить ответственного человека, который достаточно разбирается в задаче, чтобы он контролировал процесс.
Кейс из практики. Как-то мы разрабатывали интернет-магазин, и клиент выделил своего управляющего для проекта. В итоге оказалось, что сотрудник не разбирается ни в маркетинге, ни в разработке. Более того, он не пытался наладить с нами контакт и не принимал ничего из тех фич и идей, которые мы предлагали. Вместо этого клиент упорно копировал решения крупных интернет-магазинов, которые не подходили проекту.
Мы долго работали вместе, но только потому, что нужно было завершить задачи. В итоге проект запустился, но криво и косо: из-за бесконечного списка функций, требований и правок мы не успевали доработать фичи до конца, и они работали с ошибками. Еще и на запуск интернет-магазина ушло в три раза больше времени, чем планировали изначально.
📍 Клиент общается с нами неуважительно, и в его команде — невоспитанные сотрудники, которые грубят и не слушают нас.
📍 Если заказчик общается с нами с позиции давления.
Если проблемы возникли в процессе работы, мы всё равно стараемся довести задачи до конца, даже в ущерб себе. Например, в самом начале практики был случай, когда мы взяли в работу проект из незнакомой нам сферы — это был заказ полиграфии, экспресс-печать. Мы неправильно оценили объем работ и выбрали неподходящие функции для сайта. Заказчика это не устроило, мы вернули предоплату и прекратили работу. Сейчас бы поступили по-другому: как минимум для начала провели глубокую аналитику бизнеса клиента.
Важно помнить, что расставаться — это нормально. Главное — сделать это спокойно и подписать все закрывающие документы, а не отключать телефон и игнорировать сообщения и звонки.
Тщательно планируем работу и расставляем приоритеты
Мы не собираем проекты с нуля, и к нам приходят клиенты уже с готовым запросом или списком задач. Но часто бывает так: заказчик думает, что проблема одна, а на деле она оказывается совсем другой. Поэтому работу с каждым новым проектом начинаем с оценки и анализа. Это нужно, чтобы сформулировать задачи и дальше составить план действий.
Бывает, что клиенты уходят после первого этапа. Например, если заказчик рассчитывал потратить максимум 100 000 рублей, а после анализа понятно, что на необходимый объем работы нужен бюджет в 3-4 раза больше. Тогда понимаем, что ничего не потеряли: человек изначально не относился к задаче серьезно. Другая ситуация, когда клиент сразу знакомится с нашими кейсами, подробно изучил сайт и отзывы. Тогда нам приятно сотрудничать: человек узнал о нашей экспертизе и захотел с нами работать еще до того, как принес нам задачу.
Если цена устраивает клиента, мы верно поняли задачу или помогли правильно ее сформулировать, брифуем клиента. Например, узнаем, какая у него инфраструктура, кто еще будет работать с нами. После этого начинаем работать:
1 Планируем задачи. Чтобы проект получился, клиент должен понимать цели и направление развития. Это нужно, чтобы наши задачи совпадали с общей стратегией бизнеса и не были разрозненными.
Если с целями всё в порядке, составляем план работ — на один, два, но в идеале на три месяца. Этот срок позволяет организовать работу со сложными задачами и провести максимально глубокую аналитику.
Работа выглядит так: например, клиент хочет добавить в личные кабинеты на своем сайте вкладку «Избранное», чтобы пользователи могли добавлять туда понравившиеся товары. Мы заносим в список задач все необходимые этапы, согласовываем с руководством и начинаем разработку.
2 Расставляем приоритеты. В работе используем методику RICE. Ее суть — оценить каждую задачу по балльной системе. Чем больше очков — тем важнее работа.
Распределять баллы нужно по четырем параметрам:
Reach — охват. Это то, на какое количество пользователей повлияет новая фича или интерфейс на сайте. Например, клиент хочет обновить интерфейс каталога и блога на сайте. Но на первую страницу каждый месяц заходит 1000 человек, а на вторую — 300. Поэтому важнее будет каталог.
Impact — влияние. Это самый необъективный параметр, но он лучше, чем делать предположения. Оценка показывает, как сильно повлияет изменение на пользователей. У параметра есть шкала, где 0,25 — слабое влияние, а 3 — максимальное, и это помогает решить, в какую сторону масштабировать изменение: в большую или меньшую.
Confidence — уверенность. Параметр помогает определить, насколько реализуема задача, и его указывают в процентах. Например, если задаче дали 40% — это скорее иллюзия, и в ближайшее время за нее не стоит браться. А если больше 50% — работу реальнее выполнить.
Effort — усилия. Измеряется месяцами и показывает, сколько времени уйдет на задачу. Этот параметр тоже бывает сложно оценить точно, но можно найти примерные значения.
Посчитать итоговые баллы и приоритеты можно по формуле: Reach × Impact × Confidence ÷ Effort.
Бывает, что план задач есть, приоритеты расставлены, но случается что-то непредвиденное. Например, когда сайты или сервисы падают. Так недавно взламывали Битрикс — все ресурсы перенаправляли туда.
Еще мы не застрахованы от изменений на стороне клиента: допустим, когда приходит новое руководство. У него часто свои планы и задачи, и бывает, что вместо работы над личным кабинетом нас просят внедрять криптокошельки.
3 Встраиваемся в процессы клиента. Когда работаем с клиентами, мы становимся частью их команды. Например, участвуем в планировании других проектов, ходим на встречи и созвоны с партнерами. Еще поддерживаем ежедневный контакт. То есть не бывает такого, что согласовали задачи, пропали на две недели и чем-то занимаемся. Это помогает нам глубже понимать клиента, улучшать коммуникацию и создавать долгосрочные проекты, а сам заказчик всегда в курсе, на каком этапе разработка.
4 Повторяем цикл. Так как не беремся за разовые заказы, со всеми клиентами мы сотрудничаем не один год подряд. Мы либо дорабатываем их ecom-платформы, либо поддерживаем их работу, либо помогаем создавать что-то новое. Поэтому сотрудничество становится бесконечным, и цикл повторяется: формулируем проблему → составляем список задач на несколько месяцев → расставляем приоритеты → разрабатываем фичи и отчитываемся клиенту.
Раньше мы работали только по строгому техническому заданию, которое согласовывали с клиентом. Цена была фиксированной, даже если приходилось перерабатывать. На небольших проектах этот подход помогал. Но вот с большими заказами были сложности, потому что ТЗ — это рамки, а вводные могли меняться много раз в процессе работы. Например, как-то мы разрабатывали интернет-магазин, и у клиента часто появлялись новые требования к проекту. Из-за этого работа растянулась на год, а изначально планировали справиться за четыре месяца.
Сейчас используем подход Time&Material: сначала формулируем задачи, согласовываем их, определяем примерную стоимость и сроки работы. И только потом подписываем договор, работаем и в каждый месяц получаем оплату — часто цена меняется, так как она зависит от затраченных ресурсов. Такой подход помогает построить более гибкий рабочий процесс, быстро менять приоритеты и учитывать новые требования.
В том, чтобы успешно доводить проекты клиентов до конца, нет никакой магии. Нужна слаженная команда, ответственные сотрудники и четкое понимание того, что вы хотите и делаете. И не только на этапе планирования проекта, но и задолго до него. Так не придется браться за работу, которая не нравится и которую в целом не хочется делать. В этом помогает позиционирование и отказ от сотрудничества со сложными и неадекватными заказчиками.
Больше о проектах и построении рабочего процесса я рассказываю в телеграм-канале Metalcode. Там же я делюсь кейсами и интересными случаями из практики нашего агентства, а также новостями и статьями из мира ecom-разработки.
А как вы считаете, что еще важно делать, чтобы работа с клиентскими проектами была успешной? Делитесь в комментариях.
Интересно, что мы в металкоде не используем в чистом виде ни канбан, ни скрам, ни другой фреймворк. В плане построения процессов придерживаемся мнения, что можно надергать разных практик и инструментов из методологий, объединять их, докручивать под себя, тестировать, экспериментировать. Взять канбан-доску, спринты, планерки, ретроспективу, залить сверху RICE, положить на ганта для планирования и тд.
За что нередко в кулуарах можно получить презрительный взгляд от коллег, типа "Как так?! Инструменты в отрыве от методологий работают хуже" и тд тп. Но факт остается фактом, все можно докрутить под себя, главное быть достаточно смелыми, чтобы затаскивать изменения в команду ))
Это как с конструктором LEGO) Можно собирать готовые наборы по схеме, а можно создать что-то новое из отдельных деталей.
Всё работает, если у руководителя есть в голове правильное представление о том как должна работать система.
На методики молятся те, кто ещё не понял и не разобрался как всё работает.
Можно сравнить с инструкцией к сложному механизму: поначалу работаешь по инструкции, потом осваиваешься, привыкаешь и можешь свободно работать. Вот инструкция это и будет готовая методика типа Скрама.
«Сотрудничество становится бесконечным…» — а какой у вас рекорд работы с одним и тем же заказчиком?
В рамках активной работы с 2018 года и по настоящее время. были спады и подъёмы, но до сих пор находим новые зоны для работы. У живых проектов нет простоев, каждый день есть задачи, планирование квартала.
А так с первым клиентом поддерживаем отношения с 2015 года.
Вы пишете, что расставаться с клиентом надо нормально. А что делать, если клиент сам закатил истерику и отключил телефон?)) как-то отсеиваете таких на старте?
На старте конечно) Если расставание происходит уже в процессе работы, то нужно соблюсти минимальный набор правил: предупредить за месяц об окончании работы, уведомить об этом по e-mail, подписать АВР, отправить оригиналы почтой с описью содержимого.