Всем привет! Меня зовут Юстина Цига, и я владелец продукта IIoT в Цифровом СИБУРе. IIoT – это в целом промышленный интернет вещей, но сейчас я хочу поговорить именно о разработке софта – платформы для визуализации показаний и настройки беспроводных датчиков на заводах. 

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

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

Урок первый: теперь во всём виноват ты

Итак, я осталась одна. Первая мысль, как, наверное, у многих на моём месте, была: «уж теперь я всё сделаю, как надо!» У тебя раскрываются крылья, исчезает чужой продакт вижн, висящий над тобой всё это время, и ты входишь в фазу воодушевления. Ты лезешь во все процессы, потому что теперь - это твой продукт, ты не можешь пройти мимо ни одной из проблем и везде выдвигаешь гипотезы о их решении.

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

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

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

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

Урок второй: метрики

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

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

Я столкнулась с тем, что мои старые метрики не измеряли в должной степени то, на чем завязан эффект продукта. А когда мы сформировали новые метрики, вскрылась более серьёзная задача – оказалось, нужно в целом перестраивать бизнес-процесс. 

Урок третий: названный разработчиками срок надо умножать на два

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

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

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

В менеджменте не зря существует рискоориентированный подход – даже если вы еще не умеете работать с рисками, заложите 20% времени на нештатные ситуации. Ведь лучше взять что-то дополнительное из бэклога, чем недоделать цели.

Урок четвертый: команда должна быть счастлива

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

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

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

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

Урок пятый: баланс между тимлидом и руководителем проекта

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

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

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

Урок шестой: чем раньше ты признаешься, что не справляешься, тем лучше

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

Не важно, какая ваша роль в команде – если вы видите проблему – её нужно подсветить. А уж если вы продакт, то это ваша первостепенная задача. Как мне сказал мой ментор: «Знаешь в чем хлеб продакта? В проблемах и их решении.» 

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

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

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

Эпилог

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

В частности, мой. Поэтому дайте знать, если хотите больше материалов по теме! Инсайтов из работы может быть ещё много :)