effectcup | blog

[effectcup]

Тренинг по управление продуктами - 7 декабря 2013, Киев

Друзья, зову вас всех на свой продуктовый тренинг 7-го декабря: http://goo.gl/Hiz2Eq

В последнее время я увлекаюсь генерацией и быстрым тестированием идей для ИТ-продуктов. Этим и займемся ))

Отзывы о прошлом таком мероприятии можно почитать вот тут: http://goo.gl/jsgGPf

Буду рад видеть всех!

[effectcup]

Лови momentum, или Как дольше не потерять импульс

Раньше, когда у меня были хобби, я часто переносил выводы, сделанные, скажем, во время плавания или рукопашных тренировок, на работу. Появлялись статьи "Управление проектами как заплыв на 2000 метров: как не утонуть" или "Спарринг СкрамМастера".

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

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

В мое сердце бьется фраза Мэри Поппендик: с сотрудниками надо работать, как будто это волонтеры, и в любой момент могут свалить. Они и правда могут. Но не валят, пока у проекта есть momentum. Когда у проектов есть Momentum, работается легко, на подъеме, все колбасят сверхурочно.

Откуда берется momentum

Импульс берется от сильного пинка (кэп?). Один из моих продуктов начался с того, что меня выгнали с проекта. Эмоции зашкаливали, и не только у меня - импульса хватило месяцев на 8 работы, и на несколько рабочих версий продукта.

Чем ярче мы начнем, тем надольше хватит импульса. Хорошо поэтому начинать свои проекты с яркого события: хакатона там, или распада фирмы.

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

Как лучше всего использовать импульс?

Во-первых, есть сложные и неприятные вещи, без которых продукт не выживает. Например, оплата. Обычно их откладывают на потом, "когда выйдет первая (энная) версия", потому что "без этого можно жить" (а на самом деле просто не хочется делать).

Так вот, если их не сделать, пока ещё есть импульс, то вы их не сделаете никогда. Говорю по опыту своих 3-х проектов, у которых все ещё нет никаких платных аккаунтов.

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

Что делать, когда momentum прошел?

К этому моменту должны быть налаженный процесс и хорошая скорость. Нет ни того, ни другого? Имеет смысл остановиться и поискать другую команду или проект.

То же правило работает с любыми тренировками и спортом: если первый драйв прошел, на его место должна прийти привычка и мелкие трюки.

Как дольше не терять импульс?

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

Почему? Да потому, что ничто так не поддерживает momentum, как небольшие регулярные успехи. А они будут только, если (хоть что-то) делать, и выпускать в люди как можно чаще.

Ещё две вещи, которые поддерживают momentum: четкие цели и простой способ понять, что мы к ним приближаемся. Также помогает важное событие в очень скором времени (например, встреча с инвестором и отчет о потраченных деньгах).

По аналогии: если вы будете месяц выбирать курсы самообороны, ходить, сравнивать, к моменту, когда вы выберете, у вас пропадет всякое желание. А вот если вы на каждой тренировке отжимаетесь на 10 раз больше, когда у вас появился на животе первый кубик, а через месяц - первые соревнования с профессионалами, тогда драйв в работе только растет!

Как определить, остался ли ещё momentum у проекта?

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

[effectcup]

JIRA integration

For our corporate users who use JIRA we implemented syncronization between effectcup and JIRA. We import effectcup stories into JIRA and sync statuses of issues from JIRA back to effectcup.

Let me show how this works:

1) you put in URL and credentials to your JIRA server

2) you choose a project where you'd like to import stories from effectcup. From issue types you choose one you'd like to create in this project

3) all the stories from effectcup which are not present yet in this project will be created. Sketches will be attached to the issues in JIRA.

Also all the stories imported before will be updated in effectcup (statuses will be updated). It works only from JIRA to effectcup, and not vice versa. 4) after synchronization you will see links on the user stories which were copied to JIRA

In JIRA imported issue looks like this:

[effectcup]

Видео по Impact Mapping'у

Друзья, привет!

2 февраля 2013 года на конференции AgileBaseCamp Дима Миндра и я провели мастер-класс "Разгоняем туман и наводим резкость с помощью Impact Map'ов". Презентация с него лежит вот тут, а теперь, благодаря Саше Баглаю доступно видео!

Преамбула. В первой части мастер-класса участники готовились учить "детей"  счетать в алфавите Брайля. Потом мы протестировали то, что у них получилось ("дети" практически не пострадали ;).

После этого я предложил подойти к этой задачи, используя карты бизнес-эффекты. Об этом я и говорю на видео (11 минут).

Во второй части мастер-класса команды учили "детей" считать по-китайски и по-египетски, предварительно построив карты бизнес-эффектов и выбрав самые выгодные "фичи".

Огромное спасибо Диме Миндре за мастер-класс и Саше Баглаю за съемку!

[effectcup]

Дофаминовые продукты, или Что делать, если ваш продукт вызывает привыкание

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

Каждое непростое решение - это бой насмерть внутри нашей головы между дофаминовой и когнитивной системами. Дофаминовая система требует немедленного кайфа. "Сожри картошки из макдональдса", - вопит она, - "и скачай новый сериал!". Когнитивная ей на это отвечает: "От картошки у тебя попа толстая! Ану бегом на стадион! И займись лучше самообучением, вон три курса на курсере тебя ждут!"

Если выбрать нужно прямо сейчас, побеждает чаще всего дофаминовая система, а если потом - тогда скорее всего когнитивная. Это доказывает куча экспериментов: знаменитый "эксперимент с мармеладками" и другой эксперимент с шоколадками и фруктами. Ученые предлагали детям на выбор шоколадку или фрукт. Одну группу просили выбрать сейчас и сразу же отдавали им то, что они выбрали: 70% детей выбрали шоколадку. Вторую просили выбрать сейчас, но результат им отдадут через неделю: две трети выбирали фрукт. Именно поэтому, кстати, тяжело не бросить TDD: хорошо от тестов будет когда-нибудь потом, а паршиво будет уже сейчас. А ещё, именно “Хочу! Сейчас!!!” эксплуатируют всякие Free Trial модели оплаты сервисов. Так вот, к чему я это? Я тут думаю, как использовать дофаминовую систему доверчивых пользователей в корыстных целях моего продукта. Мысли следующие.

Во-первых, есть люди, которые уже хотят наш продукт, как только он появился, потому что они хотят все новое. Это - наши ранние последователи. Уже скоро они пропадут (как только наш продукт проживет хотя бы пару месяцев), и поэтому их нужно использовать немедленно и жестоко! Эш Маурья, скажем, советует брать с этих людей по 200 долларов в месяц, и при этом дает им задания наблюдать за своей работой в системе, писать отчеты и т.п. А если вы хотите, чтобы они с вами побыли чуть подольше, выпускайте новые фичи  как можно чаще (на ранних этапах продукта это обычно несложно). Другая мысль. Предположим, ваш продукт вызывает зависимость, и большинство ваших пользователей - "дофаминовые наркоманы", которые ждут красной цифирки "Новый лайк". Эти люди сидят в нем по пять часов в день, и поэтому оочень внимательно следят за изменением цены. Похоже на курильщиков, которые выкуривают по 2 пачки в день: если сигареты вдруг подорожают вдвое (или только собираются подорожать), такие люди часто вообще перестают курить. Что ещё веселее, исследования показали, что курить бросают даже не с повышением цены, а только с ожиданием повышения. Поэтому не удивляйтесь, если вы посадили пользователей на “Free trial”, а потом написали, что ваш социальный сервис когда-нибудь станет платным - и вдруг от вас ушло три четверти пользователей.

Последняя мысль. Когда курильщик отказывается от сигарет (или едок - от картошки из Мака), хватает одной сигареты, чтобы он снова начать курить. Создайте курильщику благоприятные условия, скажем, попросите его передать пачку сигарет своему другу (или пригласите его на обед в Мак) - и он ваш! На этом построена система возврата ушедших клиентов: если они волевым решением перестали пользоваться вашим сервисом, сделайте им подарок - и они ваши! На этом все, и хорошей вам весны!

[effectcup]

Больше или быстрее - вот в чем вопрос, или Грозовые тучи в продуктовой разработке

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

Сегодня хочется поделиться инструментом для решения подобных проблем, который я одолжил из теории ограничений (ТОС). Инструмент называется “грозовая туча” или диаграмма решения конфликтов. Прошу прощения за очень много букв - тема сложная, да и инструмент нелегкий ;) Возьмем для примера обычную дилемму продакт-менеджера или PO: на чем сосредоточиться: на добавлении новой функциональности в продукт или на совершенствовании старой? И у того, и у другого есть свои преимущества и своя цена. А одновременно заниматься двумя вещами не хочется - это уменьшает скорость и размывает фокус. Чтобы решить эту проблему, я нарисую так называемую “тучу лейтенанта” . Шаг 1. Записываем методы обеспечения Итак, у нас есть две альтернативы: “Добавлять новые фичи” и “Дорабатывать старые фичи”. Одновременно это невозможно, потому что у нас не хватит ресурсов. В тучах те опции, которые противоречат друг другу, называются “методами обеспечения”. Записываем их и рисуем между ними молнию - противоречие.

В верхней части “тучи лейтенанта” отображают текущее положение дел. Сейчас мы больше добавляем новые функции, запишем это сверху. В нижней части находится будущее желаемое положение дел. Туда пишем “Усовершенствовать старую функциональность”. Возле молнии объясняем, почему одновременно это невозможно. Шаг 2. Находим условия. Теория ограничений говорит, что сложившаюся ситуацию просто просто так не изменить. потому что часто - это состояние, эффективное по Парето. Любое изменение сделает хуже как минимум одной из сторон. И все стороны, которым от изменений станет хуже, будут им сопротивляться. Найдем то условие, для которого нам нужен метод обеспечения D.. С какой целью нам нужно добавлять новые фичи в приложение? К примеру, чтобы переманивать новых клиентов от конкурентом, у которых таких фич нет. Или чтобы сделать счастливее разработчиков, ведь им намного больше нравится писать новое, чем исправлять ошибки в старом. Метод обеспечения, которого мы так хотим, тоже служит достижению какой-то цели, как правило, более глобальной. Для чего нам стоит усовершенствовать существующий функционал? Конечно для того, чтобы удержать существующих клиентов, увеличить их лояльность, и возможно, превратить их в наших приверженцев, которые приводят к нам все новых и новых клиентов.

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

А если мы тратим много сил на улучшение существующих фич, новых клиентов нам привлечь не удастся, потому что улучшения не создают информационного повода и не служат достаточным основанием для людей, незнакомых с нашим приложением, попробовать им попользоваться. Шаг 4. Находим глобальную общую цель Наконец, ТОС говорит, что и первое, и второе условие служат достижению одной и той же цели. У нас цель - рост базы пользователей. Не будем сейчас обсуждать, почему нам это важно. Просто запишем формулу: Рост базы = Новые пользователи - Ушедшие пользователи Для увеличения роста нужно привлекать все больше и больше новых клиентов и делать так, чтобы существующие пользователи от нас не сбегали (в слишком больших количествах).

Шаг 5. Находим сомнительные связи Ура, наша “туча” готова. И что дальше? Как же нам получить из неё решение? Для этого нужно внимательно посмотреть на все стрелочки-связи, и найти среди них наиболее подозрительные или ошибочные. У меня лично вызывает сомнение, что для привлечения новых пользователей нам так уж нужно добавлять новые фичи. Очень может быть, что это можно сделать и другими путями. Ещё одна подозрительная стрелка - это предположение, что, если добавлять новые фичи, пользователя удержать нельзя. Если пользователи сами требовали фичи много раз, то с выходом каждой следующей они будут становиться все лояльнее и лояльнее.

Шаг 6. Делаем инъекцию Подозрительные связи дают нам хорошие вопросы, которые и помогают придумать “инъекцию” - изменение положения дел, решающее конфликт. 1) Как привлечь новых пользователей без добавления новых фич? - Общаясь со смежными сегментами рынка. - Выступая на конференциях. - Используя наших приверженцев для вирусной рекламы 2) Как добавлять новые фичи, удерживая при этом пользователей? - Добавлять те фичи, которые пользователи сами давно просили Мне больше всего нравится инъекция “Добавлять те фичи, которые пользователи сами давно просили”. При этом мы можем не улучшать существующие фичи, и лояльность пользователей при этом сохранится. Добавим её в тучу и уберем метод обеспечения “Усовершенствовать старые фичи”. Как видим, оба условия достигаются, а конфликт разрешен. Более подробно о “туче лейтенанта” читайте здесь и здесь: Тема навеяна статьей “Ways to Improve a Product”.

[effectcup]

Что и как делать с русалкой, или Задаем правильные вопросы

Друзья, привет! Сегодня хочется поговорить о том, как задавая очень похожие вопросы клиенту, можно получить очень разные ответы. И какие вопросы все-таки стоит задавать.

Вспоминается анекдот. Сидят в лодке посреди северного моря два рыбака. Вдруг у одного из них клюет, и он вытаскивает из воды прекрасную обнаженную русалку (но к сожалению, с рыбьим хвостом). Рыбак берет её на руки, качает пару минут, вздыхает и выбрасывает обратно в море. Рыбаки час сидят молча, потом второй спрашивает "Почему?". Проходит ещё час, и первый отвечает "А как?"

Когда я рассказываю этот анекдот студентам, они сразу предлагают с десяток способов "Как". На удивление, "Что" (хотел сделать рыбак с бедной русалкой) не вызывает никаких вопросов! ))

Разница между "Что" и "Как"

При построении Impact Map'ов я обратил внимание, что если задать клиенту вопрос "Что?" (например, "Что должна сделать персона, чтобы мы достигли своей цели), то после некоторых усилий он рождает миллиард новых идей во все стороны.

То есть если бы рыбак спросил себя "Что (ещё) я могу сделать с этой русалкой?", возможно, он не отпустил бы её в море так просто. Повезло русалке, что он не читал наш блог! ;))

С одной стороны - это супер! А с другой - клиент пузырит идеями, никак не связанные с нашей бизнес-целью (запрячь русалку в лодку; заставить её откладывать икру и продавать; показывать её на ярмарках).

Когда же я задаю клиенту вопрос "Как?", я получаю его идеи в четко очерченных границах. (Как подсказывают мне студенты, у русалки кроме хвоста есть рот, руки и глаза).

И это с одной стороны хорошо, когда мы уже решили, что будем делать с нашей русалкой- мы ограничиваем фантазию наших рыбаков... простите, клиентов. А с другой, вопрос "Как?" заставляет сосредоточиться на проблемах и как их обойти (иногда не удается - см. выше).

Вывод: когда вы хотите, чтобы клиент родил много идей или вышел из тупика - спрашивайте его "Что?". Если вы хотите его сфокусировать - задавайте вопрос "Как?".

П.С. А вот что по этому поводу думает Гойко Аджич: https://groups.google.com/forum/?fromgroups=#!topic/impact-mapping/1qwEOdNsa64

П.П.С. Тема русалки, раскрытая в виде импэкт мэпа - http://i.imgur.com/i9LGj.png?1

[effectcup]

Customer Journey, пиратские метрики и лестница узнавания

Друзья! В преддверии мастер-класса 15 декабря хочется поделиться 25-минутным слайдкастом, в котором мы рассказываем на примере, как использовать Customer Journey Map, пиратские метрики и лестницу узнавания.

Customer journey, пиратские метрики и лестница узнавания from Artyom Serdyuk

[effectcup]

Курс "Эмоциональный скрам" - разработан с применением effectcup!

Друзья!

Обратите внимание на курс "Эмоциональный скрам" от Сергея "Another PM" Бережного и коллег!

Я знаю, что Сергей и его коллеги строили Impact map'ы в effectcup.com в процессе работы над курсом, поэтому он должен быть очень даже ориентированным на слушателей )) А ещё приятно знать, что Impact map'ы помогают не только в разработке софта, но могут быть полезными и для других видов продуктов.

Поэтому рекомендую - Эмоциональный скрам!

[effectcup]

Мысли и впечатления от ReqLabs 2012 (Киев, 9 ноября)

В позапрошлую субботу, 9-го ноября, команда effectcup заглянула на крупнейшую конференцию Украины, посвященную бизнес- и системному анализу: ReqLabs 2012.

Если вы не были на ReqLabs 2012 в Киеве, вам обязательно стоит почитать отчет Михаила Цепкова и посмотреть фотоотчет организаторов ReqLabs. 

Если же вы были на конференции, вам стоит посмотреть (ещё раз) на презентации докладчиков.

А мы хотим поделиться тем, что заметили на конференции, и мыслями, которые нам пришли во время докладов. 

Наблюдение 1: Похоже, аналитики больше любят писать, чем рисовать. Трагедия же в том, что аналитики не любят много читать (а кто любит?).

Это я к тому, что слайды в большинстве докладов были плохие. 

На конференции я открыл для себя два новых типа слайдов: “засасывающие” слайды и “разрывающие мозг” слайды. Засасывающий слайд содержит очень много мелких, причудливо переплетенных деталей. Попытки разобрать ,что же там нарисовано, занимают минут 10. Это похоже на складывание паззла. Что говорит при этом докладчик... а он ещё что-то при этом говорит?

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

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

Наблюдение 2: аналитики озабочены скорее процессом, чем результатом. Им важнее “как правильно” и “что мы должны делать”, чем “как эффективнее” и “что мы ещё могли бы сделать”. То есть они сосредоточены на процессе больше, чем на результате. И это здорово (для организации), У.Э. Демминг был бы в доволен. 

Поэтому на конференции много говорили о том, “как у них все устроено”. И “что должен делать аналитик, и чего он делать не должен”. 

Что запомнилось 

Анастасия Паукова и Роман Сахаров из ЕРАМ рассказывали, как у них все устроено. Очень много англоязычных терминов: иногда звучали фразы“мы проревьювали юзер стори и расшарили ноледж”. У них я подслушал два классных трюка, которыми хочу поделиться:

1) “истории в конверте”: если команда часто не доделывает истории, нужно показывать им первых 3-4 истории на спринт, а остальные прятать в конверт. И открывать его только когда первых 2 истории будут стоять в “готово”.

2) Игра “Допиши specification by example”, в которую можно сыграть, если разработчики не дочитывают требования до конца. Для этого пишут начало сценария (например “если пропало соединение с интернетом, а у пользователя есть несохраненный документ, то...”) и у команды спрашивают “Что должно произойти?” По ходу игры и аналитик, и команда могут узнать о требованиях и друг о друге много нового. 

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

" ..и это рождает еще один слой прозрачности..."

Я спросил у аджайл экспертов как совместить iso стандарты и гибкие методологии. Они ответили: "Творчески""

"..софт, как ребенка родить - непросто. Родили - подписали акт о работах и сдали "ребенка" в дом для слабоумных"

- Метафора Дмитрия Безуглого о “границе хаоса” на круглом столе, посвященном зонам ответственности продакт менеджера и аналитика:

“Аналитик всегда находится на “границе хаоса” - месте, где стройные и предсказуемые процессы разработки встречаются с реальными пользователями и их безалаберной непредсказуемостью. Мы можем заставить делать это команду, но эта граница есть, и аналитик всегда на ней.”

- Метафора о продакт менеджере и аналитике как о муже и жене, подсказанная неизвестным (мне) слушателем. В моей команде мечты продакт менеджер - это голова, а аналитик - шея. Совсем как в семье: продакт менеджер - это муж, а аналитик - жена. И отношения между ними должны быть соответствующие (кто-то принимает решения, а кто-то направляет эти решения в нужную сторону ;)

Огромное спасибо организаторам, докладчикам и участникам за мероприятие!

[effectcup]

Отчет о посещении Agile Breakfast с Сергеем Бережным (17 ноября 2012 года)

В эту субботу команда effectcup зашла на Agile Breakfast в Житомире, чтобы послушать Сергея Бережного (@anotherpm). Сергей - известный в СНГ и за его пределами тренер, - эксперт по отношениям с заказчиками, особенно в условиях наступившего Agile'а.

Житомирская публика, не разбалованная такими гостями, добиралась до места с  опозданием, что дало Сергею возможность выпить кофе и съесть бутерборд. 

Однако публика не заставила себя ждать долго, и уже в 10-15 в учебном центре компании QAP было около 30 человек. 

Следующих 4 часа Сергей, не переставая, жег напалмом. Мы успели поговорить и порисовать о том: 

- почему в компании завелся аджайл;

- чего ожидает заказчик, менеджеры и команда от Agile, и как потом эти ожидания не оправдываются;

- за что заказчики и команды ненавидят тех, кто приносит к ним гибкие методологии; 

- и как с этим бороться.

По ходу родились такие мемы как большой босс Виктор Федорович на вершине иерархии;

“Гибкая стабильность (или стабильная гибкость” (которую получает заказчик вне зависимости от того, чего он там хотел)

Scrum-ВД - внедрение гибких методологий в организации на этапе -А-I (например, в милиции). 

Огромное спасибо Сергею Бережному и организаторам за классный завтрак и яркое событие для IT-сообщества Житомира.

[effectcup]

Мастер-класс по быстрому планированию продуктов

Друз

ья! Рады пригласить вас на мастер-класс Артёма Сердюка, посвященный быстрому планированию продуктов с помощью Impact map'ов и Story Map'ов.

Мастер-класс пройдет 15 декабря в Киеве. Посмотреть подробности и зарегистрироваться можно тут: http://ow.ly/fjnq4

[effectcup]

Customer Journey или Как заставить пользователя сделать следующий шаг

Друзья, сегодня хочется сказать несколько слов о технике под названием "Карта путешествия пользователя" (Customer Journey Map). Техника очень простая: мы выбираем одну из персон системы и описываем шаг за шагом её "путешествие" по нашей системе. Как правило, шаги совпадают с основными действиями в "воронке продаж": визит, регистрация, активация, возврат, платеж и т.п. На каждом шаге мы задаем пользователям (или себе) вопросы: - что привело пользователя на этот шаг? по каким причинам он тут оказался? - какие у него возникают вопросы на этом шаге? что ему интересно было бы знать? какая информация ему нужна? - какие есть на этом шаге преграды, которые мешают пользователю совершить действие и перейти на следующий шаг? - какие действия должен выполнить пользователь на этом шаге? Результат может выглядеть так (мы построили путешествие для пользователя effectcup.com):

Мы не расписывали подробно действия (это можно сделать, построив user story map), а нарисовали вместо этого storyboard.

Юзабилисты говорят, что используют Customer Journey для улучшения опыта взаимодействия пользователя с приложением. Не верьте! Ну то есть, конечно, верьте, но Customer Journey Map явно заточен под то, чтобы помогать пользователю сделать следующий шаг. Другими словами, это очень хороший инструмент для увеличения конверсии пользователей. Итого: если ваша задача - увеличить конверсию пользователей, Customer Journey Map для этого прекрасно подойдет. Подробнее о Customer Journey Map можно почитать тут: http://blogs.hbr.org/cs/2010/11/using_customer_journey_maps_to.html . П.С.: заходите на наш доклад на ReqLabs в пятницу 9-го ноября! Будем рады увидеться и пообщаться.

[effectcup]

Рыба моей мечты, или Место аналитика и продакт-менеджера в продуктовой команде

Пришла осень, интернет заполонили статьи про менеджеров: проджект менеджеров, продакт менеджеров, разных других менеджеров. Внесем и мы свою струю в этот поток. Продакт девелопмент - это как рыбалка

Я не рыбак, но метафора пришла почему-то именно рыбная. Осень повлияла, не иначе )) Представьте себе пруд, в котором толкаются разной величины и разного характера рыбки. Есть огороженные участки-инкубаторы, есть инвесторы, которые прикармливают себе места, чтобы потом... сами знаете что )) У каждой рыбы есть голова - команда проблемы, смотрящая на рынок и говорящая с клиентами. И есть филейная часть, занимающаяся собственно производством и разработкой. Давайте посмотрим, кто у нас тут водится. Доуэль

Это визионер, придумавший гениальную идею, которая вот-вот захватит рынок. У него огромная голова и большие глаза, которыми он внимательно следит за трендами.  Только вот незадача: команды-то у него нету. Не набралось за годы работы по аутсорсинговым компаниям пары программистов, которые доверяют этому товарищу и готовы вместе с ним ввязаться в авантюру. Тушка хека

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

У этой рыбы оооочень длинная шея, по которой почему-то плохо проходят сигналы и пища. Команда проблемы занята своими делами - поиском рынков и клиентов, продажами, налаживанием связи. А разработка занята своими - тестированием технологий, настройкой Continuous Integration-сервера. Голова у этой рыбы очень нервная, все волосы на ней давно вырваны. Ведь она обещает-обещает-обещает, но нет никаких возможностей заставить остальную часть рыбы плыть в правильном направлении. Зато туловище очень спокойно, ведь оно знает: на мясо всегда есть спрос, не с этой головой повезет, так с другой. Есть подозрение, что такие рыбы были специально выведены в тропических условиях, и в наш пруд попали случайно. В наших широтах они, как правило, не живут (или требуют определенных модификаций).  Электрический стив

Настоящий хищник. Рыщет по рынку с огромной скоростью, подманивая наивных клиентов своим ярким видением. От конкурентов отхватывает огромные куски своими кривыми зубами-фичами, смазанными ядовитым чувством юмора. Что характерно, это всегда очень маленькая рыбка, в которой плотно сомкнуты голова (всегда одна) и все остальное (которого тоже немного).. Если повезет, электростив вырастает в настоящего кита: сначала нанимают больше девелоперов-тестеров, потом проджекта, чтобы все это смог выровнять, а потом продажников и продактов-аналитиков. Возвращаемся обратно в реальность. В реальности все та же осень с дождем и снегом. А где же в этом рыбном мире менеджеры, спросите вы. И будете правы. В рыбном мире их нет, зато они есть в моей Идеальной рыбе.

Идеальная рыба идеальная потому, что каждой из функций менеджмента (по Адизесу) занята её отдельная часть. Голова в виде команды проблемы занимается Е - эффективностью в будущем. Тело в составе команды решения занято Р - эффективностью в настоящем. Кроме того, есть менеджер проекта, занятый А - продуктивностью в настоящем. И появились продакт-менеджер и бизнес-аналитик, занятые I - продуктивностью в будущем. Они - та самая шея, которой так не хватало рыбе-жирафу. Продакт-менеджер в этой рыбе - член команды проблемы. И отвечает он не за рынок, а как раз за филейную часть, занятую разработкой. Вернее, за продукт этой самой разработки.

Аналитик в нашей рыбе - член команды решения. Он переводит все, что говорит голова, на язык, понятный задней части рыбы (и этим очень экономит время голове, которая не умеет и не хочет рисовать скетчи и писать истории в JIRA). Наконец проджект менеджер - это орган, следящий за тем, чтобы все работало как надо, все места в задней части были хорошо смазаны.. Если совместить продакта и аналитика, получится Product Owner, знакомый и любимый нами из Скрама. Он и за продукт отвечает (перед маркетингом и продажами), и истории в джиру пишет, и скетчи рисует. А вот совмещать продакт-менеджера и проджект менеджера я не советую, потому что фунции и фокусы у них очень разные. Такое совмещение может привести к тому, что страдает какая-то часть рыбы (или шея утоньчается, или филе перестает шевелиться). Подробно об этом рассказывал Михаил Карпов на ProductCamp в Киеве. Помните, что продукты повторяют структуру команд или компаний, которые их породили. Бойтесь перекосов в своей команде, потому что таким же перекошенным получится и продукт. И наоборот: если получилось сделать команду мечты - у вас хороший шанс выпустить продукт мечты! Приятной вам осенней рыбалки, и до встречи на ReqLabs!

[effectcup]

Слайдкаст о применении Impact Mapping для генерации бэклога продуктов

Друзья! Хотим поделиться с вами записью вебинара для UXpresso, посвященного построению бэклога продукта с помощью Impact mapping.

Создание бэклога продукта с помощью карты бизнес-эффектов (Impact Map) from Artyom Serdyuk

[effectcup]

Отчет об участии команды effectcup.com в ProductCamp Kiev (27 октября 2012)

27 октября в центре GreenWell прошел Product Camp Kiev, собравший продакт менеджеров из Украины, России и Беларуси. Мы тоже побывали на этом мероприятии, впечатлениями о чем хочется поделиться. В нескольких словах: самое яркое и полезное мероприятие для продакт менеджеров, на котором я был. Очень плотная сетка докладов, интересные докладчики и мысли, прекрасное общение в кулуарах. В общем, уважаемые организаторы, огромное спасибо за то, что привезли Product Camp в Киев! А теперь подробности. Нам удалось побывать на пяти докладах и двух круглых столах. День начался с доклада Алексея Журбы, product manager'а wargaming.net "Как я стал Product Manager'ом Wargaming.net". Алексей рассказывал о том, что входит в его работу. Слова Алексея, которые нам запомнились лучше других: - не старайтесь выпустить продукт в срок: лучше чуть позже, но зато хороший; - важно пользоваться тем продуктом, который вы делаете; - я играю в танки час в месяц, но проверяю, как устанавливается игра, несколько раз в день. - через какое-то время продакт менеджер перестает отчитываться своему руководителю, и начинает больше отчитываться пользователям; - если я слышу какой-то вопрос больше двух раз, я записываю ответ на него в вики.

(фото Сергея Бережного @anotherpm) Роман Россов из prom.ua рассказывал, кто такой "Редкий зверь, Product manager в компании". Роман, по его словам, - самый крупный продакт менеджер в СНГ, ведь он пришел с разработку из профессионального баскетбола ))

Доклад Романа запомнился яркими цитатами: - Вот это схема работы наших Продакт менеджеров. На выходных или когда все спят. А на самом деле это выглядит вот так. - главное умение продакт менеджера - умение сказать "Нет"; - продакт - это человек, который виноват во всем. - "Ты продакт, ты виноват!" - "Нет!" Нормально, работаем дальше. Дмитрий Безуглый говорил о "Выявлении и понимании наличия компетенции управления продуктами в компании" Дмитрий предложил очень интересную модель продуктовой компетентности. Ещё на выступлении Дмитрия мы не смогли дать правильного ответа ни на один заданный им вопрос, что вызвало некоторое недоумение. Мысли Дмитрия, которые запомнились: - очень легко скатиться из неосознанной компетентности обратно в некомпетентность. Это происходит, когда мы какое-то время не практикуемся; - знания очень быстро устаревают. Каждый генерал старается выиграть прошедшую битву; - существует 4 уровня продуктовой компетентности организации: 0 - неделание, 1 - рефлекторные реакции, 2 - осознанные реакции, 3- проактивные действия, 4 - про-проактивные действия. Михаил Карпов из Яндекса рассказывал "Продуктовые истории". Михаил построил свой доклад на ответах на наиболее частые вопросы о продуктовой разработки компании Яндекс. Было очень интересно послушать. Оказалось, что в Яндексе существует определенная "ярмарка идей", и если автор идеи смог заинтересовать ей руководство, то он получает команду. И если повезет, проджект менеджера. И если очень повезет, маркетолога. Иначе продакт должен все это совмещать в себе одном. Михаил рассказывал, как он совмещал в себе проджект и продакт менеджера в течение двух лет, и как это приводило к перекосам. Ещё он рассказывал о том, что по ходу реализации продукта можно потерять идею, поэтому иногда нужна роль "сторителлер", который всем постоянно напоминает, а в чем собственно была изначальная идея. Денис Бесков говорил о том, где искать и как растить продактов.

Денис рассмотрел варианты привлечения продакта от конкурентов, из свободных предпринимателей, из UX-ов и проджект менеджеров, и показал плюсы и минусы каждого из вариантов.

Круглый стол "Как перейти из заказной разработки в продуктовую". На круглом столе получилось поговорить на 5 тем: - Где взять деньги на разработку своего продукта; - Как устроена команда продукта по сравнению с командой заказной разработки; - как управлять требованиями в разработке продукта и с кем её обсуждать; - как работать с командой аутсорсеров при продуктовой разработке. Отдельное спасибо Антону Витязю за мысль, что под свою идею нужно находить программистов, которые реально ей загорятся. А остальных уволить. И вторую мысль от него же, что при разговоре с инвесторами главное - имя. Без имени и репутации стоящего за ней человека, идея - ничто. Короткие выводы круглого стола смотрите на фото ниже.

Круглый стол "Методы исследования рынка для продуктов".

Я пришел ко второй половине круголого стола, и оказалось, что о кейсе effectcup.com уже говорили )) Поэтому следующие полчаса мы разговаривали о том, как effectcup.com исследовал рынок перед началом разработки, какие проблемы он решает и в чем его преимущество перед конкурентами. Ценные мысли, которые я взял для себя:

- нужно помогать своим passionate пользователям аргументировать покупку перед теми, кто распоряжается деньгами (спасибо Виктору Комисcаруку из job.ukr.net); - стоит придумать некопируемое преимущество, которые не сможет легко скопировать игрок побольше (спасибо Ивану Портному из prom.ua); - задумываться о продажах стоит только после достижения Retention > 50% (спасибо Александру Слипченко из job.ukr.net) - вопрос, на который мы сейчас хотим найти ответ: "Кто согласен покупать effectcup.com и по какой цене?" (спасибо Дмитрию Безуглому). - лучше использовать модель Free trial, чем Fremium потому, что пользователь может оценить прелести премиума (и будет потом больше страдать от их отсутствия).

Самый яркий диалог круглого стола: - У тебя первый джава-телефон был? - Ну был... - Вот, ты - инноватор!

Очень порадовала команда продакт менеджеров из Prom.ua. Для таких продактов хочется писать продукты, которые бы сделали их жизнь легче и приятнее )) Мы вернулись с Product Camp'а полные вдохновения и новых идей. Некоторые из них вы скоро увидите в нашем продукте effectcup.com. Ещё раз спасибо организаторам и всем участника

[effectcup]

Новый релиз effectcup.com - экспорт в JIRA и новый вид бэклога

Друзья, привет!

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

Экспорт историй в JIRA

Чтобы экспортировать все истории с карты или и из бэклога в JIRA, нужно нажать на значек JIRA на панели инструментов.

После этого вы увидите такую страницу: 

На ней вас попросят заполнить логин и пароль к проекту в JIRA, куда вы хотите экспортировать задачи, а также указать ключ проекта. Ключ проекта - это короткое название проекта (вроде MYPROJ), которые в JIRA пишется перед номером задачи (если задача имеет ID MYPROJ-15, то ключ проекта - MYPROJ).

При повторном нажатии на кнопку экспорта, все новые задачи с карты или из бэклога экспортируются в JIRA без лишних вопросов :-).

Новый вид бэклога

Вид бэклога изменился. Теперь он выглядит так:

Что значат эти буквы и цифры? Первая цифра - это ценность истории. То есть - насколько эта история помогает наступить желаемому эффекту. Возможные значения - S(1) - слабо помогает, М(2) - средне, L(3) - сильно, и XL(4) - очень сильно.

Вторая цифра - это оценка количества работы, нужного, чтобы реализовать историю. Работы может быть  S(1) - мало, М(2) - средне, L(3) - много, и XL(4) - очень много.

Третья цифра - бизнес-вес. Он показывает, насколько мы продвинемся к бизнес-цели на единицу усилий, вложенных именно в эту историю. Бизнес-вес расчитывается, как отношение ценности к объему (точнее, вес = (ценность/объем)*25).

Истории с большим бизнес-весом - это "низко висящие фрукты", позволяющие нам с наименьшими усилиями получить желаемый результат.

В следующем релизе, который выйдет через неделю, ожидайте расширение работы с JIRA, а также появление возможностей совместной работы!

Всегда рады услышать ваши впечатления и предложения. Пишите нам на [email protected].

--

С наилучшими пожеланиями,

Команда effectcup