Компания
29,13
рейтинг
26 ноября 2012 в 02:55

Разное → 5 Идей для Владельцев продукта: как усилить мотивацию команды через работу над Видением tutorial

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

Отсутствие ясности на уровне видения продукта, четкого позиционирования на рынке, стратегии развития на 3-6 месяцев, давления срочности или ощущения конкурентной схватки — гасит скорость работы команды и личную вовлеченность ее участников.

Способность Владельца Продукта (роль Product Owner в терминологии SCRUM) воплощать видение продукта в своих словах и действиях, нельзя переоценить, когда мы говорим о командной разработке. Такая способность помогает команде работать сфокусированно (focus — одна из ценностей процесса SCRUM).

Фокус внимания меняет наше восприятие. Что бы лучше понять о чем это, попробуйте небольшой эксперимент. На протяжении дня держите в фокусе какую-то простую вещь, например, красный цвет. Обращайте внимание на все красное на улице и в офисе, думайте о красном в душе и лифте, найдите пару интересных фактов о самом цвете, или красных вещах. Уже к концу дня вы начнете воспринимать красный по-другому. Мужчины могут с удивлением обнаружить, что у красного есть оттенкиJ А на следующий день, вам могут приходить в голову “красные” мысли.

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

Ниже — 5 идей для Владельцев продукта о том, как усилить внутреннюю мотивацию и командную работу через видение.


1. Подготовьте элеватор питч. Владельцы продукта часто используют этот тип презентации инвесторам. Питчите ли вы свои идеи команде? Если нет — меня бы это насторожило. Попробуйте один из сжатых структурированных форматов представления продукта, в котором за 2 минуты (пока вы едете в воображаемом лифте с важным для проекта человеком), вы описываете: проблему, над которой работаете, ваше решение проблемы, ключевую аудиторию, способ монетизации, возможности рынка, известных вам конкурентов и текущую фазу проекта. Сделайте его максимально коротким, содержательным и эмоциональным. Запишите на видео и понаблюдайте — насколько вдохновляющим лидером продукта вы являетесь.

2. Поработайте с волонтерами. Есть ли у вашего проекта поклонники, последователи, помощники готовые поработать за идею? Если нет — меня бы это насторожило. Попробуйте найти таких людей, вовлечь их в активность по проекту и понаблюдать. Чем отличается ваше поведение в общении с участниками проекта “за деньги” и теми, кто помогают “за идею”? Очевидно, что перед волонтерами “плясать” приходится больше, ведь у них нет никакой дополнительной, материальной мотивации. Относитесь к своим сотрудникам, как к волонтерам, и результаты не заставят себя ждать.

3. Обуйте тапочки клиентов. Есть ли у вашего продукта “живые” кастомеры? Если нет — меня бы это насторожило. Даже если пока еще вы на стадии бумажного прототипа, или идут первые спринты (итерации в терминах Scrum) работы над проектом. Как вы знаете, что проблема правда существует, а ваше решение — подходит? Вы выходите из офиса, находите потенциальных юзеров и спрашиваете. Используйте кастомер девеломпент, как командообразующую активность. Приглашайте ключевых пользователей на демонстрации — пусть ахают от восторга в присутствии команды. Если ваши кастомеры труднодоступны (например, живут через океан), вам особенно важно использовать технику User Personas, для их описания. В любом случае, как можно чаще думайте о пользователях и от имени пользователей вашего продукта.

4. Используйте цели итерации. Используете ли вы цели релиза и спринта, как часть выражения видения продукта? Если нет — меня бы это насторожило. Если вам сложно находить подходящую формулировку, причина может крыться в недостаточно ясном видении продукта. Если на более высоком уровне видения нет ясности — то на уровень ниже будет каша из фич. И наоборот, если вы смогли ясно сформулировать цель релиза — то и на уровне спринтов вам будет легче выражать цели. Используйте SMART-цели, например “Увеличить продажи номеров отеля за счет использования социальных рекомендаций постояльцев”. Другая возможная причина отказа от целей — это недооценка их важности. Помните, что цели релизов и спринтов сужают фокус внимания команды, помогают понимать приоритеты разработки, самим направлять свою деятельность и чувствовать себя вовлеченными в поток создания ценности.

5. Создайте давление срочности или важности. Как давно в вашем офисе засиживались допоздна или суетились перед демонстрацией? Если давненько — меня бы это насторожило. Да, трудовые выходные были отменены каноническим аджайлом в пользу “поддерживаемого темпа” разработки. Однако, я нередко встречаю команды, которым недостает “спортивного интереса” в их размеренной жизни. Возможно, пока вы топчетесь на месте, ваши конкуренты уже захватывают рынок. Хотите узнать какой прилив энергии и мотивации может дать ощущение срочности? Посетите любое мероприятие для стартапщиков, что-то вроде “Garazh48” или “StartUp Weekend”. Если вам не хватает “внешних” ограничений — придумайте собственные (конкурентная схватка, участие в выставках, конкурсах и т.п.). Комбинируйте срочность и важность для создания внутренней мотивации работы над продуктом.

Надеюсь, это было чем-то полезно и буду благодарна за другие идеи внутренних мотиваторов.
Спасибо за внимание к теме (учусь писать еще короче и содержательнее).
Автор: @Natatara
SCRUMguides
рейтинг 29,13
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (19)

  • +7
    «Как давно в вашем офисе засиживались допоздна или суетились перед демонстрацией? Если давненько — меня бы это насторожило.»

    Если регулярно, то это настораживает еще больше и намекает на неправильно построенный рабочий процесс или неверный анализ сроков выполнения. К тому же регулярные овертаймы неизбежно вызовут недовольство как самой команды, так и их семей (или потенциальных семей), которым тоже нужно внимание и время. Опять же уменьшается время отдыха, что также сказывается на продуктивности.

    Нельзя оценивать команду исключительно с позиции тягловой единицы, все мы живые люди. А спортивный интерес создается и без подобных условий, так что если в Вашем представлении это синонимы, то стоит серьезно подумать о пересмотре своей позиции.
    • 0
      Ни о регулярности, ни о тяговой силе речи не идёт. Речь идёт о помощи (фасилитаторстве) команде в ситуациях, когда снижается фокус. Проще говоря, всё это о том, как помогать людям бороться с ленью и быть всегда в тонусе. Каждый этого хочет, но не всем это даётся легко. Вот для тех, кому сложно мотивировать себя самостоятельно, и нужен фасилитатор с набором подобных техник.
      • 0
        Фокус создается не стрессовыми условиями, соревновательность — не овертаймами и авралами.
        • 0
          Стрессовые условия существуют вне нашего желания, это данность большинства проектов. Фокус аналогично снижается вне нашей воли, это данность человеческих существ. Пост о том, что требуется от PO, чтобы фокус всегда был на приемлемом уровне: максимально понятно представлять команде продукт, внимательно относиться к каждому её участнику, вести живой диалог с конечными пользователями, ставить релевантные цели спринта, обращать внимание на внешние факторы, влияющие на сроки разработки.

          И всё это — абсолютно правильно, как с точки зрения теории подхода, так и той практики, которую мне посчастливилось иметь. Единственно соглашусь, что некоторые формулировки вышли не очень удачными. Уверен, что на следующей итерации выйдет куда складней +)
          • 0
            Создайте давление срочности или важности.


            Стрессовые условия существуют вне нашего желания, это данность большинства проектов
          • +1
            Однако это не повод создавать стресс искусственно и сверх необходимости.
            Если же в тексте проблема формулировки автора, то, наверное, стоит переписать так, чтобы не выглядело столь нелепо.
    • 0
      Моя попытка научиться писать короткие статьи начинает попахивать фейлом — не хватает примеров и некоторого количества знаков, для объяснения деталей. Но продолжу учиться, а отстреливаться буду в коментах J.

      Разумеется, ve1m прав. Регулярные овертаймы — это не здорово и не здорово. Я за поддерживаемый ритм разработки. Здесь я скорее говорю о балансе интересов продуктовой и технологической стороны. Если перегиб на стороне бизнеса, то мы успешно работаем над краткосрочными коммерческими целями, однако команда выжимается и страдает качество. Перегиб на стороне технологий характеризуется чистейшим кодом, экспериментами с новыми технологиями, 100% покрытием тестами и т.п., и при этом, несвоевременностью поставки продукта, потерей рынка либо несоответствию затрат и ценности.

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

      Как разбудить вовлеченность в проект, в его результаты? «Придумайте» выставку, конференцию, встречу с инвесторами. Дисциплинируйте, прежде всего, себя. Покажите команде, как важна вам эта дата. Людям нравится решать сложные задачи. Нравится помогать и чувствовать полезность своей работы. В этом случае бессмысленно мотивировать деньгами, люди просто потеряли ощущение конечной цели. Дайте им почувствовать ее вкус, и они проснутся. И толковые спецы сами придумают какой процесс им построить, что бы «выручить» довольно (а может и слишком) лояльного к ним Владельца продукта.

      Как видите, я сейчас не говорю о процессах. Статья — о Владельцах продуктов и для них же.

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

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

      Еще раз повторюсь — статья для Владельцев Продукта, о том, как сделать ваше видение — движущей мотивационной силой команды.
  • +2
    Кальки с английского режут кое-где глаз. Типа элеватор питч.
    • 0
      Простите, сомневалась как написать — «лифт питч» или «элеватор питч». Выбрала оригинальное название. На самом деле, это строго определенный тип презентации, который отличается весьма — и структурой и длительностью, и поэтому имеет отдельное непереводимое название.

      Можно было бы написать «подача в лифте», но резало бы глаза тем, кто не знает формата, и смешило бы тех, кто его знает. Такие профессиональные техники зачастую не переводятся. По крайней мере, я не встречала достойного перевода.
  • +4
    Дочитали пост до конца? Если нет — меня бы это насторожило.
  • 0
    >вы описываете: проблему, над которой работаете, ваше решение проблемы,
    Имхо проблемы (баги уровня show-stopper, фатальные недостатки архитектуры и т.п.), не прерогатива PO.
    • 0
      В этом пункте идет речь о высокоуровневом видении.

      Пример питча.
      Для разработчиков, освоивших базовые конструкции языка программирования, CheckiO — это обучающая социальная игра. Целью игры является создание и совершенствование программных решений, при помощи обратной связи и советов других игроков. У квеста есть легенда, персонажи и уровни с заданиями. Примером такого задания может служить написание программы, которая «играет» в тетрис. Программы «соревнуются» между собой и зарабатывают своим создателям очки в игре. Игроки видят код друг друга и могут совершенствовать свои программы.

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

      Образно говоря, Checkio — это как Codeacademy + World of Warcraft. Это игровой образовательный портал с социальными механизмами, в котором наставничество — является частью игры. Таким образом, Чекио — это площадка для создания образовательной экосистемы нового типа.


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

      • 0
        Я к тому что проблема (problem) это именно проблема- когда что то адски не так, как должно быть. А то о чем вы говорите — issue, point, etc
  • +3
    Ладно, можно простить
    элеватор питч
    , в конце-концов я понимаю натянутые отношения менеджера с русским языком. Но
    Создайте давление срочности или важности
    это уже, прошу прощения, за гранью добра и зла. Разработчик, как любой пролетарий, во-первых, не дурак, а во-вторых не имеет никакой мотивации работать кроме удовольствия от работы и денег. Вы же сейчас предлагаете искусственно вводить человека в состояние стресса, апеллируя к его чувству долга и срочности достижения целей. Текучки кадров под давлением срочности не возникает? Если нет — меня бы это насторожило.
    • 0
      Я предлагаю повысить удовольствие от работы, которое непосредственно зависит от наличия у нее цели и смысла. Все никак не пойму — где я написала про состояние стресса? Давление срочности и важности — это нечто другое. Попробую на примере.

      Пример 3. Я девочка-гик, люблю программировать. А еще — жую иногда печеньки перед монитором, увлекаюсь. Мне в общем-то нравится быть здоровой и стройной. Но печеньки такие преченьки, мммм. И времени на пробежку вечно жалко — другие приоритеты. Как же быть? Я узнаю, что бывают такие мультиспортивные гонки — X-Крым. Там нужно делать много всего — бегать, плавать, дюльферить (простите, не знаю перевода) и лазить по скалам. Это классное, увлекательное приключение. Командное, притом. Но к нему нужно готовиться. И приходится себя вытряхивать на пробежку по утрам, и жевать изюм вместо печенек, и завязывать восьмерки. Цель важнее: хочу попасть на гонку и не сдохнуть там (простите), хочу этого опыта. Без давления срочности (это уже 5-го октября!) и важности (хочешь приключение? нужна подготовка!) мотивации заниматься здоровьем было бы сильно меньше.

      В Примеры 1 и 2 были более релевантными софтверной разработке. Этот — более метафорический.
      • –1
        В вашем примере похудеть — это цель самой девочки, которую она сама себе поставила и хочет добиться. А выпустить программу к сроку и удовлетворяющую каким-то требованиям — это цель PO, и с помощью различных техник (т.н. мотивация) она навязывается разработчикам. Для меня эти техники делятся на честные и не честные. Поскольку любая программа делается с целью получения денег, то к честным техникам относятся те, в которых деньгами делятся. В виде зарплаты — нормально, в виде премий — хорошо, в виде процента от продаж — отлично. К нечестным же относятся те, в которых реальная цель (получение денег) подменяется искусственной — созданной срочностью и важностью в том числе. Срочность объективна — любой исполнитель скажет вам, сколько потребуется на выполнение работы. Сокращение сроков вплоть до приемлемых осуществляется сокращением объёма работ. Важность тоже объективна — никто же не строит иллюзий что очередной todo-лист для мобилки или сервис обмена сообщениями сделает мир лучше.
  • 0
    Жалею о том, что не хватает кармы для голосование за пост (понятия не имею сколько нужно, лишь Хабр бьет по рукам).
    Суть статьи поддерживаю двумя руками, являясь менеджером продукта.
    Если бы менеджер продукта прошел мимо этой статьи — меня бы это насторожило.
    • 0
      Спасибо за отзыв. Похоже, статья не попала в аудиторию, так бывает.
  • 0
    Кастомеры труднодоступны, каша из фич, питчите ли вы свои идеи, потенциальных юзеров, кастомер девелопмент и т. д.— честное слово, хочется подарить вам «Лингво», чтобы импликативно не имплементировали дефолтные паттерны.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное