Этой весной я выступал на 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
Комментариев нет:
Отправить комментарий