Comments 35
Увлекательно, жду продолжения.

В целом, согласен, но иногда ПО загибается в зародыше от большого количества предварительных шагов. Хотя могло бы что-то и получиться
Для небольших веб- и мобильных проектов прохождение этих шагов может занять до недели. Этот ролик про то, как Nordstrom Innovation Lab создает небольшой рабочий прототип за неделю, включая тестирование на «живых» пользователях (к слову, разрабатывая продукт у них же на глазах).

На стартап-конкурсах у нас похожий, но сильно «обезжиренный» процесс занимал пару часов. На обучающих воркшопах с командами мы доходили до фазы планирования первой итерации за один день. Разумеется, набор практик зависит от контекста, идеи, рынка и даже технологий. Мы стараемся следовать Закону Чувака (Девида Хассмана):

Value = Why / How
Ценность практики равна отношению Пользы (Почему используем?) к Сложности (Как выполнять?)

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

Затягивать не стоит, но небольшая подготовка поможет сэкономить время в дальнейшем.
UFO landed and left these words here
Это у фильма Inception — основная тема внедрение. А у фильма Inseption, как тут написано, может быть любая тема :-)
По себе знаю, чтобы продолжать, лучше сделать работающий зародыш продукта, который не будет совершенным, но затянет тебя с потрохами, тогда вопросов с мотивацией не возникает и начинаешь творить с большей радостью. А, иначе, первый шаг — он самый трудный. И если много планируешь, теряешь запал. А запал, это в нашем деле очень важно.
100% согласен. я сейчас как раз на этом пути. Считаю что многие вещи всё равно в планирование не влезут, и это как с релизами — фиксим одни баги, добавляем новые, а движение — есть жизнь.
Хм, странно, а вас-то почему заминусовали? Иногда не понимаю хабралюдей :) Пофиксила, спасибо!
Наталья, спасибо за статью.

У предложенной вами методики есть какие-то границы применимости? Стоит ли по ним делать игры?
Вадим, интересная статья, спасибо.

Смысл слова «анархия» очень хорошо понимается на индийских дорогах в перенаселенных штатах. При практически полном отстутствии формальных знаков и правил, самом плотном трафике, который я видела где-либо — практически нет ДТП. В тех нескольких, которые мне доводилось видеть — были вовлечены западные люди.

Границы применимости может подсказать только здравый смысл, внутри определенного контекста. Например, если вы делаете сайты на вордпрессе по готовым шаблонам — не вижу смысла. В создании игр — вижу)
Я знаком с Максимом Ткачуком, но кто такие «грабители банков» в статье — не понял.
На «кухонном жаргоне» мы с Максом так называем небольшие полнофункциональные команды, которые вместе могут — «взять банк», или создать продукт, обладая всеми необходимыми для достижения цели навыками и знаниями. Чуть больше о формировании такой команды я писала здесь.
Сколько успешных массовых продуктов вам удалось создать по предлагаемой методике?
Денис, если говорить о нашей компании, то из публичных проектов мы в похожем ключе открывали мобильную версию сайта ведущего молдавского сотового оператора, сейчас так работаем над B2B порталом молдавских ИТК компаний и порталом Почты Молдовы. С апреля начинаем работу над крупным собственным продуктом.

В наших масштабах подход работает прекрасно.
Вадим, я не сомневаюсь в пользе Agile-методик в разработке заказных систем.

В этой статье акцент на agile PRODUCT development, а не просто agile development, поэтому мне интересен статус рекомендаций, их проверенность автором.
Ни одного. Я зарабатываю на жизнь другой деятельностью, а именно — обучением. Последнее время фокусируюсь не только на процессе разработки продукта но и на процессе проработки идеи. Учусь практикам у западных мастеров (Хассман, Паттон) и нахожу способы отработать их, что бы понять пользу и уметь модифицировать. Для этого участвую в стартап-конкурсах, работаю с друзьями над их продуктами и с партнером над собственным. Этот продукт нишевой, он в находится в фазе, в которой уже экономит деньги нашей компании и проходит проверку внешними пользователями и клиентами. Работаем над тем, что бы сделать его открытым и коммерческим.

В своей основной команде, работая над не-технологическими продуктами (программы обучения, конференции) мы используем такие инструменты как Видение, Персоны, Истории (даже для того, что бы «прогнать» воркфлоу участника мероприятия), иногда прорабатываем новые направления деятельности при помощи BMC. У меня есть iPad приложение, которое я использую скорее как инструмент размышления, чем как способ создания бизнес-плана. Поскольку речь идет о нашей собственной компании, многие решения мы обсуждаем и принимаем с партнером на кухне офиса, или на даче — процесс не очень формален.
Ок, тогда сколько ваших клиентов создали успешные массовые продукты по этим рекомендациям?

Или это сборник методик, которые вам КАЖУТСЯ полезными, но статистики их применения их у вас нет — тогда почему бы так и не написать в статье?

Product Discovery Team — это ваше изобретение, Кагана, кого-то ещё?
Как Spotify создает продукты — пример ряда успешных массовых продуктов, созданных при участии нашего коллеги Хенрика Книберга по схожему процессу.

О Product Discovery Team узнала от Джефа Паттона, Каган тоже об этом говорит, уж не знаю кто из них первый начал :) Статистики у меня нет, поскольку не ею я руководствуюсь, при выборе инструментов, которые мне кажутся полезными.

Руководствуюсь тем, что: 1) пробую и наблюдаю разницу, 2) интересуюсь опытом применения у своих западных коллег, поскольку его «там» сильно больше
Автор явно никогда не создавал новых продуктов. Статья написана с точки зрения человека, которого наняли сделать продукт в уже готовом бизнес окружении. Специально поискал по тексту — слово «деньги» встречается 1 (один) раз, «клиенты» 3 раза.

Первое с чего надо начать при создании нового продукта понять кто и когда, желательно с указанием этапов будет оплачивать все эти 7 (или сколько там шагов). Это нужно понимать, хотя бы для того чтобы точно знать сколько времени и ресурсов можно потратить на эти N шагов, в каком объеме, в какие сроки, пока деньги не кончились.

На старте, пока рынок еще неясный это может быть:
— свободное время создателей (bootstrap)
— семья, друзья и дураки (FFF)
— инвестор или бизнес ангел ( в России пока редкость)
— заказная разработка для первых клиентов

Второе. Используя эти ресурсы максимально экономно и действуя максимально быстро, создать прототип, первую версию и пр, что готово для поставки клиентам. Именно это и называется MVP (Minimum Viable Product) — минимально жизнеспособный продукт. Поставить эту бету на рынок.
prooflinks:
www.svproduct.com/mvp-vs-product-vision/
venturehacks.com/articles/minimum-viable-product

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

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

Автор работает в сфере консалтинга, ей и не нужно ничего создавать. :)
а теперь понял. Автора нанимали, для того чтобы помочь тем, кого наняли для создания продукта…
SRichard, статья написана человеком, которого уже лет пять как для этого не нанимают. Последние полгода нанимали для того, что бы помочь командам, разрабатывающим свои продукты, получить более ясный, предсказуемый, итеративный процесс разработки.

Насчет объема первой поставки — эта статья описывает разницу в MVP (Minimum Viable Product) vs. MDP (Minimum Delightful Product) vs. VCP (Very Crappy Product), в импонирующем мне стиле.
Основной посыл в статье неверный, инструменты поставлены во главу процесса.
Ваши «Владельцы Продукта» всегда, в первую, вторую и третью очередь должны думать о деньгах, которые будет генерировать продукт и о своей клиентской базе.
В реальном бизнесе все просто — если продукт не генерирует деньги, всю команду тут же разгоняют, независимо от того, насколько правильные инструменты на правильных шагах применяла команда…
А вы уверены что лучшей тактикой всегда является MVP? Если мы разрабатываем сложный проект в духе MVP то после запуска мы, вероятно, столкнемся с проблемой: как развивать и улучшать этот MVP? Ведь делалось все не основательно, не вдумчиво, а быстро, так что почвы под развитие, наверняка, не было заложено. Появится костыли и т.д. Куча лишней работы, которую можно было сделать в самом начале грамотно. Что скажете? Все равно запускать MVP?
Опять же, если мы делаем клон, или схожий по функционалу продукт с %product_name%, который уже доказал состоятельность идеи и имеет хорошие показатели, имеем ли мы право вообще выкатывать MVP? По-моему, в этом случае, нужен наоборот максимально вылизанный продукт, который смог бы тягаться со своим конкурентом, а не сыроватая бета, которая в сравнении с конкурентом никого не заинтересует.
Чуть выше ссылка на MVP / MDP / VCP. Для публичных релизов MVP, как правило, не достаточно. Но для тестирования в закрытой бете — вполне. Вот еще одна интересная статья о том, как Spotify — один из наиболее успешных европейских стартапов, создает свои продукты. Процесс описан довольно подробно, включая решение о выходе на рынок.

Для того, что бы итеративно-инкрементально наращивать функциональность уже работающего продукта, необходим процесс разработки, в котором вносить изменения быстро и дешево. Над этой темой поработаю в следующей статье.
Здесь мы имеем дело с типичным затыком агилистов, которые пытаются натянуть обслуживающую РОЛЬ product owner, который в agile-процессе отвечает за сбор хотелок бизнеса, их небольшую формализацию до user story, организацию приоритезации, внутреннюю приёмку и консультирование команды по историям) на ПРОФЕССИЮ product manager, который отвечает за успех продукта на рынке, и обладает для этого компетенциями (знанием конкретного рынка и методик работы с ним) и полномочиями (бюджетом, ресурсами).
Спасибо за прекрасную статью! Отличное продолжение статьи Алексея. Лично для меня очень важно было связать воедино всё то, к чему мы так или иначе приходили за время работы по гибким подходам.
Везет вам, у вас видать фирма хорошая такая где больше одного человека принимает решение что делать. А вот бывает еще так, делаешь продукт, все вроде знают что делают, примерно понимают для кого (Этакий пользователь Х). А потом, приходит весточка с верху, мол нужно сделать вместо мониторинга мобильных устройств, систему оповещения о тревоге для охраняемых объектов. Далее следует небольшая пауза, разработчики задумчиво чешут репу, и раздается вопрос «А это же была шутка?». Увы нет. У кого деньги под того и пишем.
Всё правильно — кто рискует деньгами, тот и принимает продуктовые решения.
Спасибо за статью и полезные ссылки. Очень рад, что на Хабре иногда появляются такие материалы. Комплексный взгляд на процессы в создании продукта.
Only those users with full accounts are able to leave comments. Log in, please.