Интервью о переходе от проектного мышления к продуктовому

Этой весной я выступал на Codefest в Новосибирске. Рассказывал, как перейти от проектного мышления к продуктовому. После доклада меня позвали дать интервью, где я рассказал о переходе от проектного мышления к продуктовому, кросс-функциональных командах и о том, где взять крутого Product Owner'а.

Чтобы послушать интервью, кликайте по ссылке https://drive.google.com/file/d/1mqiPAlj2cFqglUR1qCuT8ILEUNa-AQZE/view

— Добро пожаловать в студию ЦФТ. С нами Александр Бындю, который рассказывал про то, как перейти от проектного мышления к продуктовой разработке.

— Всем привет.

— Как заслужить доверие заказчика, чтобы от работы по проектам, он согласился перейти к продуктам?

— Есть два способа. Первый самый простой — приходишь по рекомендации и уровень доверия сразу высокий. Второй способ чуть длиннее. Нарисуем график: по одной оси доверие, по другой прозрачность, разделим пополам и получим четыре зоны. Если начинаем работать с низкого уровня доверия, то продукты нам никто не даст разрабатывать. Продукты делают на высоком доверии. Как заслужить высокое доверие? Только через повышение прозрачности. Делаете процессы прозрачными, налаживайте взаимодействие, показывайте результаты и т.д. Начинайте двигаться по квадратикам, пока не приходите в высокий уровень доверия и тогда вам дают делать продукты.

— Есть модели продажи контрактов Fixed price и Time&Material. Я слышал, что есть возможность продавать Story Point, особенно когда вы заслужили доверие и работаете как продуктовая команда. Как к этому прийти?

— Можно продавать Story Point, но мы продаем часы работы. Как к этому прийти? На самом деле многие заказчики к этому готовы, они знают что такое T&M, они знают, что такое плавающий Scope работы. Они понимают, что если написать ТЗ на полгода вперед, то через три месяца окажется, что половина ТЗ уже неактуальна, и нужно делать другое. Тогда зачем писать ТЗ, давайте просто стремиться к бизнес-результату и делать все возможное, чтобы его достигнуть.

— Помогают метрики, которые вы собираете о продукте?

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

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

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

Команда в какой-то момент говорит, что забирают сисадмина к себе. А админу говорят, что он теперь DevOps. Теперь должен заморачиваться о том, что создается продукт, т.е думать о бизнесе. Могут просить делать релизы каждый день. Может еще хуже — все автоматизировать, чтобы ничего не делать вручную.

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

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

— В докладе вы приводили пример начальника склада, который остается не удел в случае сопротивления.

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

— Вынужден был меняться?

— Да, и сразу пришел с новыми проектами к руководству. Естественно, взял все наши идеи, но нам не жалко, главное, что изменения начались.

— Быстро подстроился. С чем это связано?

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

— Вы перечисляли разного рода маппинги: Impact Mapping, User Story Mapping, Customer Journey Mapping. Как клиенты воспринимают эти техники? С первого взгляда они кажутся непривычными. К тому же вы настаиваете, чтобы заказчики участвовали в процессе их создания.

— Заказчики привыкли к описанию бизнес-процессов стандартными схемами и документами. Люди хотят просто прочитать документ на 50 страниц и осознать целостный продукт. Но мы настаиваем на простых визуализациях, которые способен сделать любой. Заказчики схватываются эти техники налету, а потом внедряют их в своих компаниях.

— Проблема в том, что Impact Map нельзя зафиксировать, он меняется на протяжении работы, поэтому заказчик должен соучаствовать. Заказчики участвуют?

— Да, заказчики участвуют. Они знают ценность результата. Был случай, когда заказчик через 4 часа работы над картой, передумал делать продукт, потому что увидел, что нет ни целей, ни гипотез.

— Сорвался контракт?

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

— История обернулась в вашу пользу.

— Мы заботимся, помогаем, это положительно влияет на наш бизнес.

— Product owner’ов нет на рынке, их сложно выращивать, при этом каждый продукт требует Product Owner’а.

— Именно.

— Где их брать?

— Хороший вариант — выращивать в компании.

— Нельзя в одночасье стать предпринимателем.

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

Второй признак хорошего будущего Product Owner'а — тема продукта у него "болит". Только учтите, что лучше брать человека из бизнеса и учить его разработке продуктов, чем брать айтишника и учить его бизнесу.

— Как понять какие данные собирать для метрик продукта в первую очередь? Раз это довольно трудоемкий процесс не хочется потратить время зря.

— Это исследовательский процесс. Никто не скажет заранее, какие данные собирать. Общая рекомендация — собирайте данные, которые влияют на расчет бизнес-ценности.

— При этом данные могут быть плохого качества.

— Они и будут плохого качества. Их будут скрывать.

— Что с этим делать?

— Добывать, пытаться их найти, систематизировать, забирать из эксельничков.

— Как вы считаете, меняется ли культура заказчика, его образованность, подготовленность к изменениям?

— Да, меняется, потому что рынок уплотняется, особенно российский рынок. Если раньше вы одни умели покупать электронику подешевле и продавать ее подороже, то сейчас есть еще 10 компаний, который умеют делать тоже самое. Когда бизнесы начинают тереться друг о друга, то возникает вопрос как дальше конкурировать. Топ-менеджеры читают Гартнер и Форестер, а там написано о продуктах и новых подходах.

— Но выигрывает всегда потребитель.

— Да. Все борются за потребителя.

Слайды и видео доклада, о котором идет речь в интервью https://2018.codefest.ru/lecture/1270