Выученные уроки молодого продакта
Всем привет! Меня зовут Юстина Цига, и я владелец продукта IIoT в Цифровом СИБУРе. IIoT — это в целом промышленный интернет вещей, но сейчас я хочу поговорить именно о разработке софта — платформы для визуализации показаний и настройки беспроводных датчиков на заводах.
В этом проекте я была с самого начала своей работы в СИБУРе, помогала предыдущему продакту, замещала его, руководила дополнительными блоками имеющегося решения, и все казалось понятным и знакомым. Но полтора года назад я стала единственным владельцем продукта и прошла от стадии воодушевления и горящих глаз до осознания, что я не справляюсь.
В этой статье я хочу поделиться своими ошибками, их разбором и просто историей, которая, как я надеюсь, поможет молодым продактам не опустить руки и сразу обратить внимание на тревожные звоночки.
Урок первый: теперь во всём виноват ты
Итак, я осталась одна. Первая мысль, как, наверное, у многих на моём месте, была: «уж теперь я всё сделаю, как надо!» У тебя раскрываются крылья, исчезает чужой продакт вижн, висящий над тобой всё это время, и ты входишь в фазу воодушевления. Ты лезешь во все процессы, потому что теперь — это твой продукт, ты не можешь пройти мимо ни одной из проблем и везде выдвигаешь гипотезы о их решении.
На самом деле, я до сих пор уверена, что так и должен работать любой продакт. Но если раньше некоторые твои решения могли «отбриваться» по каким-то причинам человеком выше, то теперь ты — этот самый человек.
Умение осознанно, обдуманно и на основе данных, а не чувств, принимать решения — твой новый разблокированный скилл. Ведь если ты сказал заказчику, что фича будет готова через 2 недели, а у бэкендера случился грипп, и он не успел — отвечать тебе. Или если дизайнер предложил изменить цвет кнопки, и это уронило пользовательскую лояльность — отвечать тебе.
Но и в этом есть своё удовольствие. Да, теперь ты вынужден отложить реализацию супер фичи, которую сам же и кастдевил, потому что другая, менее прекрасная для пользователей принесет проекту больше эффектов. Зато теперь ты жонглёр и умеешь не только приоритизировать классные фичи, но и выполнять своими действиями функциональный контракт, приносить компании деньги и обосновывать затраты.
В моём случае этого жонглёра приходится мирить с внутренним UX-дизайнером, поэтому мне больно слышать от пользователей и от команды, что та или иная фича бы так помогла и такая классная. Но приходится напоминать себе, что прямо сейчас опциональная доработка не улучшит наши метрики, да и обязательные цели у нас ещё не выполнены.
Урок второй: метрики
Вам всегда нужно понимать, что ваши действия к чему-то привели, и, в зависимости от результата, определять стратегию. Даже, если до Вас так никто не делал — особенно если до Вас никто это не делал., И просто интервью с пользователями недостаточно — их должны дополнять метрики, и важно основательно подойти к их определению, чтобы они действительно отражали наши целевые показатели.
Если вы только пришли на проект — первое, что нужно понять, это какие у продукта метрики, отражают ли они тот показатель, на который нацелен продукт и достигаются ли они. Да, обратная связь и глубинные интервью прекрасны, но свои решения надо как-то измерять.
Я столкнулась с тем, что мои старые метрики не измеряли в должной степени то, на чем завязан эффект продукта. А когда мы сформировали новые метрики, вскрылась более серьёзная задача — оказалось, нужно в целом перестраивать бизнес-процесс.
Урок третий: названный разработчиками срок надо умножать на два
Тут, я, конечно, утрирую, но поинт вот в чем: нужно закладывать время на риски.
Предположим, что вы планируете задачи на квартал. Вы определили фичи и пошли к техлиду узнать, сколько займёт их реализация. Тот озвучивает сроки, вы приоритизируете фичи и выносите их на бизнес.
Это было верхнеуровневое планирование, а когда начинается планирование спринтов, выясняется, что фича потребует переделки всей страницы раздела, переписания базы данных, да еще и ваш тестировщик на месяц уходит в отпуск. И ответственность за эту ошибку несёте, разумеется, вы.
В менеджменте не зря существует рискоориентированный подход — даже если вы еще не умеете работать с рисками, заложите 20% времени на нештатные ситуации. Ведь лучше взять что-то дополнительное из бэклога, чем недоделать цели.
Урок четвертый: команда должна быть счастлива
На этом этапе самопознания отсеиваются чувствительные продакты. Или находят хорошего психолога, тут как повезёт ☺ Продакт — это фильтр между злым и страшным миром и уютом, в котором привыкли жить разработчики.
С тех пор, как я стала руководить продуктом, мне приходилось порой слышать, что продукт недостаточно хорош или не приносит пользы. Для человека, который искренне считает продукт своим детищем, это большой стресс, и как бы не хотелось с кем-нибудь это обсудить, ни в коем случае не стоит выносить это на разработчиков. Но точно стоит обсудить с ментором…
Казалось бы, очевидно, но всё же стоит это отметить. Потому что команда разработки творчески и с удовольствием делает классный продукт, а бизнесовые проблемы, предподнесённые на эмоциях, могут начисто сбить эту магическую атмосферу. Но разумеется, утаивать подсвеченные проблемы не надо: если вам говорят, что продукт не решает поставленной задачи, — это замечательный повод для исследования и дальнейших улучшений.
Просто нужно решать бизнесовые проблемы на бизнесовом уровне в зоне вашей ответственности, а команде разработки достаточно понимать цели, задачи и риски.
Урок пятый: баланс между тимлидом и руководителем проекта
В жизни бывают разные ситуации, и с выгоранием может столкнуться каждый член команды. Ваша задача, как руководителя — следить за эффективностью и эмоциональным состоянием команды, узнавать, что происходит, по возможности помогать и давать в такие моменты корректирующую обратную связь, касающуюся работы.
Иногда разработчику нужно сменить направление задач, иногда даже проект. Проговорите с ним, как он видит своё развитие, какими задачами ему интересно заниматься, предложите что-то новое. Иногда жизненная ситуация вовсе требует уйти в продолжительный отпуск — предложите сотруднику такую возможность. В современных компаниях это, к счастью, всё более распространённая практика.
При этом стоит иметь в виду, что не всегда эти усилия могут дать эффект, и нужно быть морально готовыми искать сотрудника на замену. К сожалению, в IT пока нет должности «хороший парень».
Урок шестой: чем раньше ты признаешься, что не справляешься, тем лучше
У меня наступил сложный момент спустя 3 квартала моей самостоятельной работы. Всё как-то полетело под откос: мы делали еще больше багов, цели не успевались, посреди спринта выяснялось, что мы забыли о блокирующей задаче для фичи.
Не важно, какая ваша роль в команде — если вы видите проблему — её нужно подсветить. А уж если вы продакт, то это ваша первостепенная задача. Как мне сказал мой ментор: «Знаешь в чем хлеб продакта? В проблемах и их решении.»
Но если вы понимаете, что проблема не решается на уровне команды, не бойтесь прийти к своему руководителю или ментору и честно всё рассказать. Старшие коллеги могут и помочь советом, и правильно помочь взять ответственность перед бизнесом, если задачи не выполняются, и привлечь других специалистов, если надо.
В моей ситуации мне действительно больше всего помог ментор. Он сказал, что если ты идешь к руководителю с фразой «Кажется, я плохой продакт, и мне нужна помощь» — это говорит скорее о том, что ты хороший продакт. Плохой будет сидеть ровно и игнорировать проблемы.
Также нам помогло привлечение скрам-мастера. У нас его не было уже больше двух лет (ну, а что, процессы же выстроены), но любое изменение в процессах может поменять весь привычный рабочий уклад, а скрам может помочь подсветить риски и предложить изменения, которые пойдут на пользу команде и работе.
Эпилог
Возможно, эти советы для кого-то очевидны, но я буду рада, если они помогут таким же начинающим продактам избегать ошибок и сохранять спокойствие в стрессовых ситуациях! Рано или поздно мы все сталкиваемся с суровой реальностью, и лучше использовать для этого чужой опыт.
В частности, мой. Поэтому дайте знать, если хотите больше материалов по теме! Инсайтов из работы может быть ещё много :)
