Антон Носков | Разработка для е-ком

Time & Material, квартальное планирование, долгие проекты, фокус на одном направлении - всё, что обеспечивает стабильность в работе.

Рассказали в статье как отказались от проектной работы в пользу долгих проектов и научились встраиваться в процессы клиента

Статья на VC>>

Жду день когда забикс напишет: "Ребята, все хорошо, ничего не упало, вы все большие молодцы".

В продолжение темы долгосрочного сотрудничества

Кажется, что отношения между заказчиком и подрядчиком иногда напоминают романтические ❤️

Начиная от знакомства и конфетно-букетного периода, когда все стараются быть добрыми и красивыми. Заканчивая разрывом, по обоюдному согласию или по инициативе одной из сторон, тогда вторая страдает 💧 (а иногда пытается снова быть "вместе", реанимировать отношения — возобновить сотрудничество).

А между этими стадиями, при правильном подходе обеих сторон, должны быть годы плодотворной работы.

Написали целую статью про то, как мы годами работаем с клиентами и не выгораем >>

Читать на VC >>
Читать на VC >>
Читать на VC >>

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

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

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

Какая моя выгода за бесплатную работу?
Благодаря вам я собираю ещё больше опыта в решении проблем в екоме и развиваю свою насмотренность.

Возможно вы станете клиентом Metalcode и мы вместе приступим к выполнению плана.

Для записи пишите мне в личку "Нужна стратсессия" @andreyfrolov

Сегодня Спорт Ферме исполнилось 8 лет. Это супер проект, где мы с партнерами развиваем международный е-ком.

Благодаря им я познал внутрянку настоящего, стремительно растущего е-кома. Со всеми факапами и победами.

Ура, товарищи! Всем изотонического пива за мой счёт

Вот эти цифры "Период работы" о чем-то говорят все таки..

Они говорят про невероятный LTV наших клиентов!

2015-2022 с ума можно сойти, у меня сын в школьника вырос за это время.

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

Выражается в довольно простых подходах:

— глубоко интегрироваться в системы заказчика (трекеры, чаты и прочее);
— интегрироваться в процессы — режимы планирования, оценки, бюджетирование, коммитмент;
— делать регулярные статусы, чтобы не только разбирать текучку, но и чувствовать "температуру";
— идти на встречу в сложных моментах (в рамках разумного, но почти всегда можно поднажать, чтобы спасти выполнение квартального плана);

Ну и ключевое: выполнять обещанное в оговоренные сроки — тогда все будет прекрасно.

Оттого и сарафанка всегда была, и остается, нашим супер-эффектиным каналом привлечения новых клиентов.

Скрин с нашего сайта metalcode.tech

Одних отпускаем, других онбордим.

Далеко не редкость, что в компании нет четкого процесса онбординга. Приходит новый разработчик (а на удаленке он никуда не приходит, просто добавляется в таск-трекер и слак), и сидит, ждет пока менеджер обратит на него внимание, подкинет первые задачи. Звучит немного грустно.

Поэтому, как тимлид, пытаюсь создать атмосферу полного погружения 😁

Благо процессы у нас понятные, команда не большая, все прозрачно.

С чем помогаю:

— встроиться в наши процессы: делаем вводные созвоны, рассказываю что где лежит. Про трекер, жизненный цикл задачи, доступы и прочее;

— про основную техню, которая будет окружать: контуры, гитфлоу, миграции и тд;

— онбордиться в проект / проекты с которыми придется взаимодействовать: сначала верхнеуровнево, из чего состоит конкретный е-ком, как оно работает. Затем по кусочкам предметно, по мере втягивания человека в проект и решение задач;

— помощь с оценками — кого они не пугают на старте? "Сейчас назову не ту цифру и меня сразу уволят" — нет, возьми время на аналитику, у нас есть такой процесс (но чтобы о нем узнать, кто-то должен рассказать про него при онбординге =)

— даю параллельно почитать регламенты — сажать человека изучать документы про ваш трекер, регламенты разработки и забывать про него на неделю — вот так не надо;

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

Процесс не идеальный, но помогает адаптироваться (сужу по отзывам ребят).

Навеяно постом Макса про палатки.

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

Использовали его, чтобы собрать распределенную команду металкода вместе.

Подружились там с множеством крутейшими спецов из Ульяновска и не только.

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

Даже изнуряющая дорога из Владимира до Ульяновска на машине не кажется страшной ради такой тусы (но видимо я стал староват для авто путешествий 😅, потому что жалкие 10-12ч за рулем не вселяют мне оптимизма).

К сожалению, в этом году не срослось, но в следующем непременно.

Удивительно, что когда рассказываю ребятам на собесах, как мы тимбилдимся в палатках, мало кто знает про сам юлкемп. Но воспринимают всегда позитивно.

Кто был на юлкемпе?)

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

Под полноценными бизнес-требования пониманию что они:
— внятно описаны;
— не противоречат сами себе, другим задачам и процессам;
— учитывают зависимости проекта (хотя бы верхнеуровнево).

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

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

Зато умеющий формировать требования менеджер сэкономит огромное количество времени и нервов команде.

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

Начали сотрудничать с агентством по контент-маркетингу.

Ребята в рамках брифинга заставили нас вспоминать кейсы за последние несколько лет по е-кому (внезапно, в этом канале будет что-то про е-ком — пока нет 😃)

Вообще я человек, который плохо придумывает ответы на ходу, наверняка это что-то про тип мышления. Сильно лучше получается выдать мысли "на бумаге", чем быстро на ходу.

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

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

Теперь сижу поднимаю архивы за 10 лет, чтобы найти свой успешный успех 🏆 или провальный провал.

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

Теперь надо исправляться, фиксировать кейсы в любых проявлениях.

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

Адресован мне, как лиду. Я остаюсь на распутье, по факту все еще тимлид, но наличие нескольких команд и функционала позволяющего строить техническое управление, процессы, и в целом инженерную культуру тянет в сторону техдирства.

В любом случае приятно получать подобную обратную связь. Работаю во многом ради этого, пипл-менеджмент ван лав 🫀

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

Закончилось полугодовое обучение на техдира в отусе.

Это был мой первый опыт обучения на онлайн-курсах. Опасения были, но забегая вперед — хепиэнд.

Сам формат такой: больше 130 академических часов лекций (живые, не в записи) + практика с кураторами. И проектная работа в конце по построению стратегии ИТ-подразделения на 1,3,5 лет.

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

Не стану утаивать, сдал не все домашки. И потребовался конкретный рывочек в конце, чтобы добить проектную работу.

Но дело сделано, впечатления позитивные. Пошел бы еще раз? Да, но.. 😅 через полгодика, примерно. Надо выдохнуть. Может на что-то более техническое.

Естественно, настоящего СТО из меня один курс не сделает. Зато я перевел часть зон из неосознанной некомпетентности (не понимаю, что дурак), в осознанную некомпетентность (знаю, что туповат и знаю куда копать, чтобы исправить ситуацию). Плюс систематизировал знания — чего сильно не хватает для борьбы с внутренним самозванцем.

Кое чего по ходу обучения надергал в свои процессы, обобщу в одном из будущих постов.

Команда курса красавчики, все состоявшиеся техидиры с разным опытом и насмотренностью. Был преподаватель с большим количеством лет техдирства в заказной разработке (аутсорс/аутстаф), то собственно, чем мы занимаемся в металкоде, поэтому вдвойне ценно.

Ученье — свет 💡🤓
CTO Otus — рекомендасьен.

Ps надеюсь смогу теперь вернуться к ведению канала, последние пару месяцев было сложно писать.

Микроменеджмент

Считаю, что микроменеджмент можно рассматривать как инструмент. Если взять его ключевой аспект повышенного контроля и применить в сложной ситуации (близкой к провалу).

Когда надо дотащить проект / задачу в ограниченных ресурсах (обычно в сильно сгоревших сроках) или с новой командой, которая не сработалась — не стыдно прибегнуть к повышенному контролю, все перепроверять и спрашивать как дела пять раз в день).

Брать на вооружение в регулярной работе — нет. Но применить к месту, краткосрочно — очень даже да.

Лучше сделать под чутким контролем, чем не сделать вообще. А потом ретроспективно посмотрим, что было причиной и как этого не допустить снова.

Вижу схожее мнение от нескольких CTO, с которыми сейчас учусь. Но есть и ярые противники.

Как считаете, пресекать в себе микроменеджемент или тренировать?)

Ps в комментах уже подсказали, что в сложных условиях это не микроменеджмент, а антикризисное управление.

Времяписец (тайм-трекер) и микроменеджмент

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

Я в любой момент мог видеть по разработчикам, у кого на какой задаче тикает таймер и сколько набежало.

Ох, как же меня тогда колбасило 🙃 Почему у Васи не тикает таймер? Почему Коля уже три часа его не останавливает? Почему я уже 10 раз посмотрел кто чем занят..

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

Естественно дело не в том, у кого в данный момент тикает таймер. Дело в результате разделенном на трудозатраты и умноженном на коэффициент качества (не уверен, что именно такая формула у эффективности, набросал из головы 💡).

Поэтому в какой-то момент вообще запретил себе смотреть, что у кого «тикает».

Затем мы поменяли систему и сейчас у нас вообще нет тайм-трекера. Вносим трудозатраты вручную: время, тип работы и комментируем их. Тип работы — разработка, тестирование, исследование (аналитика) или обсуждение. В первом комментарии скрин, как это выглядит.

Хочешь вноси раз в день, хочешь логируй каждые 30 минут. Если удобно используй внешний тайм-трекер, если неудобно — просто вноси трудозатраты.

Что могу отметить:

— Трудозатраты можно внести вплоть до минуты (1ч 12м и тд)

— Уже на этапе собеса доношу до разработчиков, что у нас аутсорс и надо будет фиксировать трудозатраты. Благодаря этому никакого саботажа.

— Были казусы, когда ребята новички пытались размазать свой 8 часовой день по задачам, чтобы было 8ч из 8ч. На первой же ретроспективе это чинится обычным разговором и дальше данные становятся «чище».

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

Трекаете время на задачи? Бьете по рукам разрабов за «не тикающий» таймер? 😅

Ps плюсов в карму ➕ тому, кто отгадает что за система была с возможностью видеть таймер каждого сотрудника. Начинается на W.. ныне недоступна в РФ.

Удаленка

Классический холивар удаленка vs офис.

Кто чаще всех говорит, что удаленка не эффективна? — адепты офиса.

Те кто построил огромный офис, с кухней, баристой, пивом после 17:00, игровой, теннисным кортом, спальней, печеньками и тд тп. Утрирую, но смысл понятен.

Будучи адептом офиса, во-первых тебе очень сложно принять удаленку, а если ты ее не принял, ничего не получится.

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

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

Мы же имеем обратную ситуацию в 90% случаев. Все сделано под офисников, а удаленщики по остаточному принципу.

Потом смотрим и удивляемся: пять человек в переговорке, сидим, офисные печеньки трескаем, Колян вообще соло на гитаре зафигачил во время созвона, а Вася (который один подключался к встрече онлайн) как-то был менее вовлечен и демотивировался. Просчитались, но где?)

(Я кстати, часто на встречах с заказчиками один говорю из телека на переговорку, и мне норм, это им приходится телевизор выключать, чтобы градус духоты снизить "вечно этот Антон со своими нюансами и ограничениями систем лезет в нашу прекрасную идею" =)

Каждый имеет право не принимать удаленку. И строить только офис. Даже гибрид запретить. От этого удаленка не становится хуже.

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

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

Отчеты о трудозатратах

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

Делюсь двумя основными отчетами, которыми мы обмениваемся с заказчиком.

— все отчеты о трудозатратах в часах;

— генеряться нажатием пары кнопок (за счет мощного трекера youtrack, который пушка, но про него в другой раз).

1. Общий отчет по составу выполненных работ

Крутой отчет с разделением по типу работы (аналитика / разработка / дизайн / тестирование / обсуждение и тд). Писали про него в подрядчиках (там же в посте скриншотик).

— видно из каких типов работ состояла каждая задача;

— в сторону чего происходит перекос, кто больше загружен на проекте;

— ловим, если Обсуждения начинают сильно разрастаться, значит пора сокращать количество встреч =)

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

2. Отчет по единицам работы

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

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

Отправляем раз в месяц.

Бывает, что заказчик просит еще и отчет в нужном ему формате, например акт-отчет. Обычно он автоматически не заполняется и приходится в полуручном режиме его составлять менеджеру (что не круто, но бывает). Такой отчет готовим дополнительно к основным.

Конверсия в найме

У нас бутиковая команда и мы работаем (и терпим 😅) друг с другом годами. Вопреки статистике, что разработчики на одном месте держатся в среднем 1,2-1,5 года.

Так вот, как обычно происходит найм сотрудника по воронке:

~ 60-80 откликов (треть из которых не читает требования, фрилансеры, рекрутеры предлагающие свои услуги через отклик на вакансию); полагаю, что количество не релевантных откликов растет вместе с известностью компании;

~ 8-10 интервью (на этап знакомства с командой проходят 2-3);

~ 1 найм на испытательный.

При условии нормальной рыночной ЗП и не специфичных требований (не супер узкая специализация — «ищу фортран-разработчика»).

Знаю, что некоторые проводят сильно больше интервью для закрытия вакансии, но мне кажется это перебор + дело не в количестве интервью, а в качестве кандидатов и первичном отборе.

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

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

Сколько стоит найм разработчика

Подслушал мнение бывалых СТО, что найм по статистике обходится в 2 оклада.

Нанимаешь сотрудника с зп 150тр, будь готов выложить 300 за найм.

Я не удивляюсь, просто последний найм обошелся нам в 7тр потраченные на hh 🍷

Но надо признать, что я не вписываю в расходы свое время, в которое я и за рекрутера, и за техническое интервью, и за знакомство с командой.

Кстати, у нас три этапа:

— скоринг резюме + первичный контакт текстом с минимальными вводными вопросами;

— техническое интервью (хотя там все подряд, но цель конечно же определить подходит ли сотрудник по скиллам, ожиданиям, настрою);

— знакомство с командой - тут уже подключаю своих, вместе общаемся по упрощенному плану.

Иногда добавляется этап собеса с заказчиком, если аутстафф и ему подобное.

Накидайте в комменты самых всратых вопросов с собесов чтобы я добавил их в свой план

Все хотят сеньоров

У нас в разработке бытует мнение, что все хотят нанимать только сеньоров — наиболее прокаченных разработчиков, если смотреть по упрощенному грейду (джун/мидл/сеньер).

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

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

Проблемы сроков или масштабирования ему поможет решить тимлид из команды, направит, посоветует.

А еще нанимая мидл-разработчиков сэкономите денег (по рынку они стоят дешевле сеньоров) и при этом получите стабильного работника, которые не зазвездился, и не требует бесконечных прорывных задач.

Берегите мидлов 🦄

Когда кто-то предлагает запустить очередной стартап за выходные и ты вспоминаешь про свое кладбище идей 💧

Хороших выходных!)