Комментарии 19
«Как давно в вашем офисе засиживались допоздна или суетились перед демонстрацией? Если давненько — меня бы это насторожило.»
Если регулярно, то это настораживает еще больше и намекает на неправильно построенный рабочий процесс или неверный анализ сроков выполнения. К тому же регулярные овертаймы неизбежно вызовут недовольство как самой команды, так и их семей (или потенциальных семей), которым тоже нужно внимание и время. Опять же уменьшается время отдыха, что также сказывается на продуктивности.
Нельзя оценивать команду исключительно с позиции тягловой единицы, все мы живые люди. А спортивный интерес создается и без подобных условий, так что если в Вашем представлении это синонимы, то стоит серьезно подумать о пересмотре своей позиции.
Если регулярно, то это настораживает еще больше и намекает на неправильно построенный рабочий процесс или неверный анализ сроков выполнения. К тому же регулярные овертаймы неизбежно вызовут недовольство как самой команды, так и их семей (или потенциальных семей), которым тоже нужно внимание и время. Опять же уменьшается время отдыха, что также сказывается на продуктивности.
Нельзя оценивать команду исключительно с позиции тягловой единицы, все мы живые люди. А спортивный интерес создается и без подобных условий, так что если в Вашем представлении это синонимы, то стоит серьезно подумать о пересмотре своей позиции.
Ни о регулярности, ни о тяговой силе речи не идёт. Речь идёт о помощи (фасилитаторстве) команде в ситуациях, когда снижается фокус. Проще говоря, всё это о том, как помогать людям бороться с ленью и быть всегда в тонусе. Каждый этого хочет, но не всем это даётся легко. Вот для тех, кому сложно мотивировать себя самостоятельно, и нужен фасилитатор с набором подобных техник.
Фокус создается не стрессовыми условиями, соревновательность — не овертаймами и авралами.
Стрессовые условия существуют вне нашего желания, это данность большинства проектов. Фокус аналогично снижается вне нашей воли, это данность человеческих существ. Пост о том, что требуется от PO, чтобы фокус всегда был на приемлемом уровне: максимально понятно представлять команде продукт, внимательно относиться к каждому её участнику, вести живой диалог с конечными пользователями, ставить релевантные цели спринта, обращать внимание на внешние факторы, влияющие на сроки разработки.
И всё это — абсолютно правильно, как с точки зрения теории подхода, так и той практики, которую мне посчастливилось иметь. Единственно соглашусь, что некоторые формулировки вышли не очень удачными. Уверен, что на следующей итерации выйдет куда складней +)
И всё это — абсолютно правильно, как с точки зрения теории подхода, так и той практики, которую мне посчастливилось иметь. Единственно соглашусь, что некоторые формулировки вышли не очень удачными. Уверен, что на следующей итерации выйдет куда складней +)
Создайте давление срочности или важности.
Стрессовые условия существуют вне нашего желания, это данность большинства проектов
Однако это не повод создавать стресс искусственно и сверх необходимости.
Если же в тексте проблема формулировки автора, то, наверное, стоит переписать так, чтобы не выглядело столь нелепо.
Если же в тексте проблема формулировки автора, то, наверное, стоит переписать так, чтобы не выглядело столь нелепо.
Моя попытка научиться писать короткие статьи начинает попахивать фейлом — не хватает примеров и некоторого количества знаков, для объяснения деталей. Но продолжу учиться, а отстреливаться буду в коментах J.
Разумеется, ve1m прав. Регулярные овертаймы — это не здорово и не здорово. Я за поддерживаемый ритм разработки. Здесь я скорее говорю о балансе интересов продуктовой и технологической стороны. Если перегиб на стороне бизнеса, то мы успешно работаем над краткосрочными коммерческими целями, однако команда выжимается и страдает качество. Перегиб на стороне технологий характеризуется чистейшим кодом, экспериментами с новыми технологиями, 100% покрытием тестами и т.п., и при этом, несвоевременностью поставки продукта, потерей рынка либо несоответствию затрат и ценности.
Пример 1. Владелец продукта работает над игровым приложением. Проект длится почти год. За этот период «случилось» подобие внутреннего релиза, но процесс был слабо-итеративным. Команда технически очень сильная, зарплаты выше средних на рынке. Однако, потеря ощущения «срочности» сказывается на мотивации завершать начатое. Люди попросту привыкли не напрягаться, иметь достаточно времени и на фейсбучек и на неторопливую разработку.
Как разбудить вовлеченность в проект, в его результаты? «Придумайте» выставку, конференцию, встречу с инвесторами. Дисциплинируйте, прежде всего, себя. Покажите команде, как важна вам эта дата. Людям нравится решать сложные задачи. Нравится помогать и чувствовать полезность своей работы. В этом случае бессмысленно мотивировать деньгами, люди просто потеряли ощущение конечной цели. Дайте им почувствовать ее вкус, и они проснутся. И толковые спецы сами придумают какой процесс им построить, что бы «выручить» довольно (а может и слишком) лояльного к ним Владельца продукта.
Как видите, я сейчас не говорю о процессах. Статья — о Владельцах продуктов и для них же.
Пример 2. Владелец продукта разрабатывает конкурентное решение на рынке облачных хранилищ. Продукт строится на основе нескольких вау-фич, которые пока еще не реализованы ни в одном существующем сервисе. Проекту полгода. Владелец продукта уверен, что поставлять нужно «либо все, либо ничего». Точнее, «все и в лучшем виде». Команда таким же образом относится к внутренним техническим решениям. К предпринимательским веяниям в компании, разработчики относятся настороженно. Бытует мнение, что весь этот Lean StartUp — от лукавого, лишь сеет соблазны пасть до написания недостаточно великолепного кода.
Как мотивировать программистов на конечную цель? Цель в красивом коде, или в красивом продукте? Наведите порядок в своей голове, особенно если вы Владелец продукта с инженерным бекграундом. Цель — в проверке идеи и построении стабильного бизнеса. Почему важно поскорее проверить решение рынком? Что будет, если мы ошибались и вау-фичи окажутся невостребованными? Скольких пользователей охватили конкуренты за то время, пока мы пишем свое решение? Как часто они умеют поставлять версии? Как быстро они смогут скопировать наши фичи и сделать своим конкурентным преимуществом? Дайте большую картинку технологического бизнеса и люди поймут свою роль в нем. И сами поймут какое решение достаточно великолепно для этого времени и фазы жизни продукта.
Еще раз повторюсь — статья для Владельцев Продукта, о том, как сделать ваше видение — движущей мотивационной силой команды.
Разумеется, ve1m прав. Регулярные овертаймы — это не здорово и не здорово. Я за поддерживаемый ритм разработки. Здесь я скорее говорю о балансе интересов продуктовой и технологической стороны. Если перегиб на стороне бизнеса, то мы успешно работаем над краткосрочными коммерческими целями, однако команда выжимается и страдает качество. Перегиб на стороне технологий характеризуется чистейшим кодом, экспериментами с новыми технологиями, 100% покрытием тестами и т.п., и при этом, несвоевременностью поставки продукта, потерей рынка либо несоответствию затрат и ценности.
Пример 1. Владелец продукта работает над игровым приложением. Проект длится почти год. За этот период «случилось» подобие внутреннего релиза, но процесс был слабо-итеративным. Команда технически очень сильная, зарплаты выше средних на рынке. Однако, потеря ощущения «срочности» сказывается на мотивации завершать начатое. Люди попросту привыкли не напрягаться, иметь достаточно времени и на фейсбучек и на неторопливую разработку.
Как разбудить вовлеченность в проект, в его результаты? «Придумайте» выставку, конференцию, встречу с инвесторами. Дисциплинируйте, прежде всего, себя. Покажите команде, как важна вам эта дата. Людям нравится решать сложные задачи. Нравится помогать и чувствовать полезность своей работы. В этом случае бессмысленно мотивировать деньгами, люди просто потеряли ощущение конечной цели. Дайте им почувствовать ее вкус, и они проснутся. И толковые спецы сами придумают какой процесс им построить, что бы «выручить» довольно (а может и слишком) лояльного к ним Владельца продукта.
Как видите, я сейчас не говорю о процессах. Статья — о Владельцах продуктов и для них же.
Пример 2. Владелец продукта разрабатывает конкурентное решение на рынке облачных хранилищ. Продукт строится на основе нескольких вау-фич, которые пока еще не реализованы ни в одном существующем сервисе. Проекту полгода. Владелец продукта уверен, что поставлять нужно «либо все, либо ничего». Точнее, «все и в лучшем виде». Команда таким же образом относится к внутренним техническим решениям. К предпринимательским веяниям в компании, разработчики относятся настороженно. Бытует мнение, что весь этот Lean StartUp — от лукавого, лишь сеет соблазны пасть до написания недостаточно великолепного кода.
Как мотивировать программистов на конечную цель? Цель в красивом коде, или в красивом продукте? Наведите порядок в своей голове, особенно если вы Владелец продукта с инженерным бекграундом. Цель — в проверке идеи и построении стабильного бизнеса. Почему важно поскорее проверить решение рынком? Что будет, если мы ошибались и вау-фичи окажутся невостребованными? Скольких пользователей охватили конкуренты за то время, пока мы пишем свое решение? Как часто они умеют поставлять версии? Как быстро они смогут скопировать наши фичи и сделать своим конкурентным преимуществом? Дайте большую картинку технологического бизнеса и люди поймут свою роль в нем. И сами поймут какое решение достаточно великолепно для этого времени и фазы жизни продукта.
Еще раз повторюсь — статья для Владельцев Продукта, о том, как сделать ваше видение — движущей мотивационной силой команды.
Кальки с английского режут кое-где глаз. Типа элеватор питч.
Простите, сомневалась как написать — «лифт питч» или «элеватор питч». Выбрала оригинальное название. На самом деле, это строго определенный тип презентации, который отличается весьма — и структурой и длительностью, и поэтому имеет отдельное непереводимое название.
Можно было бы написать «подача в лифте», но резало бы глаза тем, кто не знает формата, и смешило бы тех, кто его знает. Такие профессиональные техники зачастую не переводятся. По крайней мере, я не встречала достойного перевода.
Можно было бы написать «подача в лифте», но резало бы глаза тем, кто не знает формата, и смешило бы тех, кто его знает. Такие профессиональные техники зачастую не переводятся. По крайней мере, я не встречала достойного перевода.
Дочитали пост до конца? Если нет — меня бы это насторожило.
>вы описываете: проблему, над которой работаете, ваше решение проблемы,
Имхо проблемы (баги уровня show-stopper, фатальные недостатки архитектуры и т.п.), не прерогатива PO.
Имхо проблемы (баги уровня show-stopper, фатальные недостатки архитектуры и т.п.), не прерогатива PO.
В этом пункте идет речь о высокоуровневом видении.
Пример питча.
Вы можете время от времени менять набор деталей и стиль подачи — в зависимости от того — кто перед вами: инвестор, юзер или кандидат в команду. Но цель одна: дать общее представление о проекте, заинтересовать, зажечь идеей, остаться в уме собеседника.
Пример питча.
Для разработчиков, освоивших базовые конструкции языка программирования, CheckiO — это обучающая социальная игра. Целью игры является создание и совершенствование программных решений, при помощи обратной связи и советов других игроков. У квеста есть легенда, персонажи и уровни с заданиями. Примером такого задания может служить написание программы, которая «играет» в тетрис. Программы «соревнуются» между собой и зарабатывают своим создателям очки в игре. Игроки видят код друг друга и могут совершенствовать свои программы.
Для рекрутеров и HR компаний, которые разрабатывают программные продукты, Чекио — это инструмент поиска кадров, оценки экспертизы разработчиков, проведения технических собеседований, организации «баталий» между девелоперами (с целью повышения культуры разработки, передачи опыта и знаний внутри компании).
Образно говоря, Checkio — это как Codeacademy + World of Warcraft. Это игровой образовательный портал с социальными механизмами, в котором наставничество — является частью игры. Таким образом, Чекио — это площадка для создания образовательной экосистемы нового типа.
Вы можете время от времени менять набор деталей и стиль подачи — в зависимости от того — кто перед вами: инвестор, юзер или кандидат в команду. Но цель одна: дать общее представление о проекте, заинтересовать, зажечь идеей, остаться в уме собеседника.
Ладно, можно простить
элеватор питч, в конце-концов я понимаю натянутые отношения менеджера с русским языком. Но
Создайте давление срочности или важностиэто уже, прошу прощения, за гранью добра и зла. Разработчик, как любой пролетарий, во-первых, не дурак, а во-вторых не имеет никакой мотивации работать кроме удовольствия от работы и денег. Вы же сейчас предлагаете искусственно вводить человека в состояние стресса, апеллируя к его чувству долга и срочности достижения целей. Текучки кадров под давлением срочности не возникает? Если нет — меня бы это насторожило.
Я предлагаю повысить удовольствие от работы, которое непосредственно зависит от наличия у нее цели и смысла. Все никак не пойму — где я написала про состояние стресса? Давление срочности и важности — это нечто другое. Попробую на примере.
Пример 3. Я девочка-гик, люблю программировать. А еще — жую иногда печеньки перед монитором, увлекаюсь. Мне в общем-то нравится быть здоровой и стройной. Но печеньки такие преченьки, мммм. И времени на пробежку вечно жалко — другие приоритеты. Как же быть? Я узнаю, что бывают такие мультиспортивные гонки — X-Крым. Там нужно делать много всего — бегать, плавать, дюльферить (простите, не знаю перевода) и лазить по скалам. Это классное, увлекательное приключение. Командное, притом. Но к нему нужно готовиться. И приходится себя вытряхивать на пробежку по утрам, и жевать изюм вместо печенек, и завязывать восьмерки. Цель важнее: хочу попасть на гонку и не сдохнуть там (простите), хочу этого опыта. Без давления срочности (это уже 5-го октября!) и важности (хочешь приключение? нужна подготовка!) мотивации заниматься здоровьем было бы сильно меньше.
В Примеры 1 и 2 были более релевантными софтверной разработке. Этот — более метафорический.
Пример 3. Я девочка-гик, люблю программировать. А еще — жую иногда печеньки перед монитором, увлекаюсь. Мне в общем-то нравится быть здоровой и стройной. Но печеньки такие преченьки, мммм. И времени на пробежку вечно жалко — другие приоритеты. Как же быть? Я узнаю, что бывают такие мультиспортивные гонки — X-Крым. Там нужно делать много всего — бегать, плавать, дюльферить (простите, не знаю перевода) и лазить по скалам. Это классное, увлекательное приключение. Командное, притом. Но к нему нужно готовиться. И приходится себя вытряхивать на пробежку по утрам, и жевать изюм вместо печенек, и завязывать восьмерки. Цель важнее: хочу попасть на гонку и не сдохнуть там (простите), хочу этого опыта. Без давления срочности (это уже 5-го октября!) и важности (хочешь приключение? нужна подготовка!) мотивации заниматься здоровьем было бы сильно меньше.
В Примеры 1 и 2 были более релевантными софтверной разработке. Этот — более метафорический.
В вашем примере похудеть — это цель самой девочки, которую она сама себе поставила и хочет добиться. А выпустить программу к сроку и удовлетворяющую каким-то требованиям — это цель PO, и с помощью различных техник (т.н. мотивация) она навязывается разработчикам. Для меня эти техники делятся на честные и не честные. Поскольку любая программа делается с целью получения денег, то к честным техникам относятся те, в которых деньгами делятся. В виде зарплаты — нормально, в виде премий — хорошо, в виде процента от продаж — отлично. К нечестным же относятся те, в которых реальная цель (получение денег) подменяется искусственной — созданной срочностью и важностью в том числе. Срочность объективна — любой исполнитель скажет вам, сколько потребуется на выполнение работы. Сокращение сроков вплоть до приемлемых осуществляется сокращением объёма работ. Важность тоже объективна — никто же не строит иллюзий что очередной todo-лист для мобилки или сервис обмена сообщениями сделает мир лучше.
Жалею о том, что не хватает кармы для голосование за пост (понятия не имею сколько нужно, лишь Хабр бьет по рукам).
Суть статьи поддерживаю двумя руками, являясь менеджером продукта.
Если бы менеджер продукта прошел мимо этой статьи — меня бы это насторожило.
Суть статьи поддерживаю двумя руками, являясь менеджером продукта.
Если бы менеджер продукта прошел мимо этой статьи — меня бы это насторожило.
Кастомеры труднодоступны, каша из фич, питчите ли вы свои идеи, потенциальных юзеров, кастомер девелопмент и т. д.— честное слово, хочется подарить вам «Лингво», чтобы импликативно не имплементировали дефолтные паттерны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 Идей для Владельцев продукта: как усилить мотивацию команды через работу над Видением