Крайние за фичи

В 2ГИС налажен процесс ведения фич, когда фича закрепляется за ответственным — фичекрайним. 

Два года назад я загорелся стать фичекрайним. Мы тогда только взяли курс на реалистичность карт, и так я стал крайним за фичу «реалистичные дороги».

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

Теперь это уже не та задача, в которой мелкие менеджерские недочёты можно перекрыть собственной работоспособностью. Мне предстояло решить задачу такого объёма, с которым я никогда не сталкивался. Чтобы не облажаться (спойлер — почти облажался) я захотел сделать шаг назад и получше разобраться в матчасти «фичекрайности».

Что вообще хотят от фичекрайнего

Для начала провёл расследование. Опросил 15-20 человек: продактов, проджектов, разработчиков, тестировщиков и лидов. Хотелось узнать, что на их взгляд должен делать фичекрайний (я).

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

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

Я решил уточнить у незаинтересованного лица, кто всем этим занимается. ChatGPT выдал список должностей: Product manager, Project Manager, Scrum Master, Delivery Manager, Team Lead. И главное, на что обращала внимание нейросеть:

Всё это чисто менеджерское, а ведь я разработчик…

Дальше я обратился к Саше Картавцеву — теперь уже продакт-лиду 2GIS KIT. Пять лет назад на конференции он выступал про фичекрайних, и на его доклад часто ссылаются в компании.

Вот, что говорил Саша. Представим пирамиду «движения идеи». Наверху — продакт, который занимается стратегией. «Под ним» команда: аналитики, разработчики, тестировщики, девопсы. Из-за большого количества «ступеней» реализация идеи может идти долго и без обратной связи.

А в концепции с фичекрайним продакт может напрямую коммуницировать с разработчиком.

Преимущества этого подхода:

1. Продакт всегда может узнать, что происходит на уровне исполнителей, не общаясь с другими менеджерами.

2. Разработчик может с другими исполнителями накидывать продакту обратную связь и пожелания. 

3. А ещё разработчик может попробовать себя в роли менеджера, прокачать новые скиллы.

Поэтому для себя я вывел такую суть: фичекрайний — это просто тот, кто помогает доставить фичу. Всё. А что конкретно делать, знает только этот самый человек в конкретный момент времени для этой конкретной фичи.

Но как начинающий фичекрайний я этого не знал. И тем более не мог сформулировать ожидания от своей работы: как для коллег, так и для себя самого. Получилась размытая ответственность, от которой мне было очень сложно в самом начале.

Доставляем фичу

Многие знакомы с эффектом Даннинга-Крюгера — кривая на графике показывает, насколько меняется уверенность человека в себе при накоплении опыта. У этой кривой четыре основные стадии, которые проходят практически все. Эти стадии я прошёл за 16 месяцев.

Первая стадия: «Ого, прикольно!»

На этой стадии я, молодой фичекрайний, объединился с другими опытными разработчиками и менеджерами, чтобы вместе продумать, как реализовать новую фичу. Это была интенсивная и драйвовая работа, полная экспериментов, аналитики и планирования. На этом этапе мы изучали нормативные документы о строительстве дорог в России. Спойлер: их редко используют. На этой же стадии я проходил наш внутренний курс фичекрайних: узнавал, как управлять проектами и учился навыкам ведения переговоров.

Всё круто, но есть нюанс: опыта ноль. 

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

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

В голове начало формироваться ощущение, что я должен быть повсюду. Внутренний уровень высокой ответственности приводил к страху что-то упустить. И мозг подбросил «самое очевидное» решение — микроменеджмент.

Вторая стадия: «Блин, чота сложна»

На это стадии уже не так весело, эйфория от нового опыта спадает, а давление в это же время растёт. На горизонте проявлялись дедлайны. Это был нервёж и постоянное «страшно, страшно». И потихоньку начало всплывать всё, что по неопытности не учли в первой стадии.

Я как гиперответственный человек считал, что если ничего не получается, то это я косячу. И что же я делал? Ещё больше работал. Изо всех сил. 

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

Вот так выглядело моё расписание:

Я даже бронировал время на написание кода, но большая часть — созвоны, а остальное «решение очень важных вопросов в маттермосте, которые нельзя решить без меня». В таком режиме я жил где-то полгода. 

И вот наш первый прототип дорог и разметки, которые мы генерировали из данных:

Когда я впервые принёс этот прототип на синк команд, которые занимаются реалистичными картами, все были в восторге. Но вот как фича выглядела в конце апреля, при том что релиз ставили на май:

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

Третья стадия: «Чистилище»

Произошёл надлом: я понял, что ничего не понял. И не понимал, накосячил ли именно я и где накосячил. Из этого состояния было три выхода: 

1. Сдаться. Выгореть и отстраниться от фичи. 

2. Тащить, превозмогая. Взять волю в кулак, включить режим робота и дотащить. 

3. Успокоиться и подумать. Просветиться, пытаться понять, что сделал не так, рефлексировать. Вспомнить про делегирование, прозрачные коммуникации, шаринг контекста. 

А что, сразу нельзя было пойти по третьему пути? Нет, потому что не умел. Я наломал дров, фултайм занимался тушением пожаров и не замечал системные проблемы. 

Мой цикл работы выглядел примерно так несколько месяцев:

Я был уверен, что нужно просто написать код. Но нет. Нужно было написать код, протестировать, отдать дизайнерам, опять протестировать, понять, что что-то забыли, переписать половину кода, протестировать. При этом команд много, и некоторые напрямую друг с другом даже не работали. И нужно было научиться работать такой большой компанией. Вместо этого я сидел и страдал.

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

Мне дали на помощь двух пиэмов, с которыми цикл сразу преобразился:

Вместе мы начали исправлять процессы, и это воодушевило меня.

Четвёртая стадия: «Всё будет хорошо»

В этот момент я как фичекрайний постиг истину: ах, вот как оно надо! Я учился оценивать свой труд, что делаю правильно, а что происходит не так. Удовольствие и драйв росли!

Пятая стадия: «Атлант расправил плечи»

Здесь я понял важность и крутость позиции фичекрайнего. Фичекрайний находится внизу пирамиды, но участвует в процессах, что позволяет видеть глубоко. Такой человек находится на стыке продуктовых хотелок и технических ограничений, что позволяет фичекрайнему:

1. Подсвечивать глубинные процессы на стыке интеграции. 

2. Озвучивать, когда фичи технически идут совсем не туда. 

3. Исправлять всё это в налаженных процессах.

Сейчас я считаю, что миссия фичекрайнего не просто доставить фичу, а доставлять лучше. Чтобы следующие фичи релизились лучше, красивее и дешевле. Я нашёл этот смысл для себя, и он мне приносит удовлетворение.

Как-то сложно, оно вообще надо?

Для меня единственный критерий, чтобы решиться стать фичекрайним — огромное желание. Если этого хочет руководитель или хочется пройти «очередной курс», то скорее всего, ничего не выйдет. 

Быть фичекрайним — это не на пикник съездить. Но если гореть идеей — будет крутой опыт! Это возможность вложить существенный вклад в продукт, которые используют ваши близкие: ваши дети и семьи, может быть, в будущем и собаки.

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

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

Всем ребятам, которые работали над дорогами — я вас очень-очень люблю, спасибо! ?