Самый популярный пост моей рассылки был про ошибки найма, сегодня в каком-то смысле продолжение, про то, как выстрелить себе в ногу после найма.
Я не очень хотел его писать т.к. 1) оглядываясь назад ошибки выглядят очевидными и 2) happy end еще не наступил. Но зато личный опыт!
Начнем издалека.
2016, я нанял первого программиста на Джинн (привет, Оксана!)
Все хорошо, мы начали наконец делать давно накопившиеся задачи типа full-text search, но есть проблемы: 1) вдвоем много не сделаешь 2) все решения по продукту идут через меня, я же главный bottleneck.
2020, появляется второй разработчик. Я ожидаю, что теперь мы сделаем вдвое больше, но вместо этого скорость релиза новых фич падает драматически. Фрустрация all around.
Я понимаю, что наверное мне надо больше разработчиков и большой вопрос как организовать работу над продуктом. Начитавшись кучу умных книжек и статей, я начинаю эксперименты.
Итерация №1: ПМ не нужен
Гипотеза в том, что мы движемся медленно, потому что приходится уговаривать разработчиков сделать то, что мне нужно.
Если разработчики будут сами придумывать себе задачи, то мотивация будет ого-го и сделаем все быстро, даже если не в том порядке, как я бы делал сам. Плюс, Макс, ты же нанял профессионалов. Не надо second guessing, “надо больше доверять”.
Нет.
Мы делали какой-то случайный набор фич и изменений, с которыми я был внутренне не согласен, продукт (по моему мнению) лучше не становился, мы теряли время и лояльность пользователей.
Если кого-то нужно “уговаривать” и “мотивировать”, дело не в процессах. Плохой контакт, проект не тот, mismatch ожиданий ваших и сотрудника – не имеет значения причина, решение только одно – расставаться.
Итерация 2: quick fixes for the win
Сделал reshuffle команды, взяли двух новых фронтендов, делаем только простые задачи. Все хорошо, но на quick fixes далеко не уедешь, а на более сложных задачах падает скорость и видна нехватка продуктовой экспертизы.
Итерация 3: разработчик выполняет роль ПМ
Окей, функция ПМ нужна.
Нельзя просто пилить случайный набор фич, кто-то должен валидировать идеи, общаться с пользователями, замерять метрики и проводить эксперименты. Пусть это делает разработчик! Там нет ничего сложного, я если что научу/помогу.
Идея простая: разработчик работает над задачей от начала и до конца.
Делает custdev и проводит интервью с пользователями, смотрит аналитику, дизайнит и кодит фичу, запускает эксперимент и отчитывается о результатах.
Эта модель работала лучше, чем предыдущие варианты, но проблемы обнаружились с “неожиданной” стороны: скорость еще упала и растить команду ниндзя-программистов еще сложнее.
Пишу в кавычках, т.к. это было ожидаемо для всех, кроме меня. Да и я бы к этому пришел, если бы подумал над этим дольше, чем пять секунд.
1) Неэффективно: даже если разработчик может провести 3-5 интервью, у него уйдет на это весь день и прогресса по коду не будет.
То же самое со сбором метрик, настройкой экспериментов и любой другой задачей: если ты делаешь ее, ты не делаешь что-то другое. В данном случае не пишешь код для новой фичи или рефакторинг для старой.
2) Не масштабируется: сложно найти ребят, которые могут и хотят так работать.
Думаю это абсолютно правильный подход на этапе founding team, когда вы вместе пытаетесь понять, кто наши пользователи и какой продукт им нужен, но абсолютно не годится для фазы масштабирования, когда уже все ясно с продуктом и пользователями и нужно быстро деливерить нужные фичи и улучшения на прод.
Итерация 4: Кросс-функциональные команды и специализация
If it’s good enough for Netflix or Preply it should be good enough for us. Не надо изобретать велосипед.
Идея простая: есть разные роли в команде, над каждой задачей работают несколько человек, каждый добавляет свою экспертизу.
ПМ ищет гипотезы для проверки и валидирует их у пользователей, дизайнер с разработчиком ищут решение, разработчик пишет код, ПМ считает метрики и делает пост-мортем и цикл повторяется.
В теории все просто, на практике будем проверять. Надеюсь через полгода смогу написать новый пост, о том как все круто работает. Ну или другой пост: “Ошибки роста: фигня все эти ваши кросс-функциональные команды”.
На сегодня все, пора бежать варить овсянку ребенку. Обсуждение, как обычно, в Telegram. Цьом-цьом.
P.S.: we’re hiring! ;-)
Прямо сейчас ищу на Джинн PM и PMM, на очереди UX и фронтенд.