О применении инструментов

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

графики ради графиков, если честно. можно что угодно нарисовать, но не факт, что это вообще будет крутым продуктом или вообще воплотимо

анализ конкурентов – инструмент, причем классический маркетинговый, я тут не спорю. график этот – не инструмент))

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

После этого я, конечно, дополнила свою заметку расшифровкой баллов, но сестра продолжила 🙂

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

короче, когда у нас был курс по маркетингу и мы придумывали новый продукт, там все это было – анализ конкурентов и их продуктов и позиционирование своего. без всяких голубых океанов)))

И тут я поняла, что действительно упустила существенную часть объяснения, при каких условиях стоит пользоваться этими инструментами. Ее возмущало не только то, что мы называем новыми словами давно забытое старое, но и то, что мы сильно урезаем классический инструментарий и оставляем только визуализацию и некоторые логические выводы. Для меня такая точка зрения была открытием, но она имеет место быть. Как мы знаем, нет правильного и неправильного.

Собираем пазл

Если взглянуть на мир вокруг, то он очень быстро меняется, по сравнению с тем, что было пол столетия назад. Технологии развиваются стремительно, сегодня становится возможно то, что вчера казалось фантастикой, например, 3D-печать. А многие ли из вас смогли объяснить своим дедушке и бабушке, зачем вы заряжаете электронную бритву, сигарету, 3D-очки и зубную щетку? 🙂

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

Короче мир запутанный, но с этим как раз и научился работать Agile. Этот подход предлагает нам все время держать связь со своим пользователем, чтобы радовать его решениями, которые ему нужны. Но как это сделать? Например, scrum, когда мы что-то делаем 1-4 недели и доставляем это пользователю. Он пробует и дает свои комментарии. Или kanban, когда мы находимся в непрерывном потоке доставки ценности.

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

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

  • это сделает конкурент
  • мы можем утопать в свои фантазиях и создавать ненужные продукты

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

А если у вас все еще есть сомнения, пишите!

Advertisements

Scrum при работе на заказ

Буквально на прошлой неделе мне звонила не безызвестная в моем городе компания Axmor и спрашивала ищу ли я работу скрам мастером. Когда начала выяснять для чего оно им, оказалось, что для внутреннего продукта. На вопрос, почему они не используют таких людей для работы во внешних проектах, мне ответили, что это невозможно. На мой взгляд, Agile-контракты вполне реальны даже не в продуктовой компании. Давайте посмотрим, что может мешать переводить внешнюю разработку на scrum?

Scrum это дорого

Если при обычном подходе во взаимодействии с заказчиком участвует только PM, а остальные “делом” заняты и работают, то в scrum общаться с заказчиком будут все! Если PM потратит на встречу 1 час, то команда потратит 1 час*количество членов команды. Очень часто именно экономическое обоснование останавливает от перехода на фреймворк.

Помимо этого, scrum предполагает работу 1 человека над 1 продуктом. Здесь очень плохо пилить сразу несколько продуктов, что тоже является своеобразным стопором для компаний-разработчиков. Ведь за это время разработчик может произвести больше работы, а значит мы больше заработаем, считают они. Что, кончено же, заблуждение.

Двойная работа

Лень объяснять про плюсы scrum

Почему большинство продуктов сейчас пока создается по водопаду? Потому что люди не знают, что можно по-другому и никто им это не объясняет. Ведь куда легче взять готовое ТЗ, оценить, умножить на два, закрыв свои риски таким образом, и начать делать. Чем возиться с заказчиком и объяснять ему все тонкости и пользы другого подхода. А польза будет в первую очередь заказчику! Это занимает некоторое время и обычно, не маленькое! Когда я была обычным PM и пришла на тренинг по Scrum, где мы играли Video Scrum, я была шокирована: “Кааак, в первом спринте не нужен сценарий ролика, а уже нужно видео?! Кааак это сделать за такое короткое время?!” И потом наступило прозрение 🙂

Вот буквально вчера я проводила Митап с Lego Scrum и пыталась донести до аудитории суть в основном не в увеличенной скорости разработки, основное отличие в том, что вы начинаете раньше доносить ценность до своего пользователя, зарабатывать раньше и уменьшать общий риск ошибки продукта. С водопадом вы донесете ценность только через год, а обратную связь получите, наверное, через 1,5. И в результате вообще сделаете около 60% работы в стол, потому что рынку за год уже понадобится другое.

Лень воспитывать владельцев продуктов

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

cueeigpxyaahwlr
если у вас U-образная форма присутствия владельца продукта, то у вас проблемы

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

Agile-контракты

Это штука непростая, потому что здесь должна быть некоторая степень доверия между вами и заказчиком. При классическом подходе мы чуть ли не перемножаем основную оценку разработки в 2, а то и в 3 раза, чтобы в случае внезапно возникших рисков они были покрыты.То есть риск в основном на компании-разработчике, поэтому получается фиксированная цена и список фич.

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

Agile говорит, что на самом деле можно найти компромисс и у нас есть третье решение, оно в плоскости где-то между первым и вторым. Что нужно сделать, просто не фиксировать все три точки классических проектов: фичи, сроки и бюджет. А зафиксировать только 2, которые чаще всего важны бизнесу – это сроки и бюджет. Дальше, объяснить, что у нас нет сейчас никаких адекватных объяснений, что рынок ждет все твои фичи из ТЗ, которые ты там принес. Это могут быть галлюцинации, которые на самом деле нужно проверять. Приоритезируем их в порядке важности для пользователя и начинаем планомерно разрабатывать, обозначая себе несколько релизов по пути.

csm_agile_en_976fe518e8

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

kak-sozdavali-tehnicheskoe-zadanie