Ошибки роста: построение команды

Как я потратил год на поиск нестандартной модели управления разработкой

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

Я не очень хотел его писать т.к. 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 и фронтенд.