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

Но как быть в ситуации с созданием массовых продуктов, когда нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать? Причём делать обширные маркетинговые исследования не позволяют ресурсы (деньги и время).

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

Наиболее актуальна эта задача для стартапов, ну и для любых персональных проектов.

Т.е. вопрос вот в чём - есть ли какие-то нотации помимо MindMap, Excel для модели потребностей, методы её формирования и трансформации в пользовательские требования?

Так же интересны методики по выявлению аудитории/потребностей/требований в такой ситуации.

Но как быть в ситуации с созданием массовых продуктов, когда нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать? Причём делать обширные маркетинговые исследования не позволяют ресурсы (деньги и время).

Под "массовым продуктом" понимается ПО, рассчитанное на большой тираж, но с каждой инсталляцией работает небольшое количество пользователей с узкоспециализированными  потребностями или "публичные" системы (небольшое количество инсталляций, но большое количество - "масса" пользователей)?

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

Наиболее актуальна эта задача для стартапов, ну и для любых персональных проектов.

Т.е. вопрос вот в чём - есть ли какие-то нотации помимо MindMap, Excel для модели потребностей, методы её формирования и трансформации в пользовательские требования?

Нотация - это только знаки, которыми описывается модель. Задача соотнесения  потребностей и идеи проекта часто упирается в модель автоматизируемой деятельности (пользователя системы). Т.е. проблема обычно в содержательном развертывнии идеи в модель, особенно для систем, которые не подпадают под традиционные модели типа "промышленное производство" или даже "предприятие". У Вас не так?

Под "массовым продуктом" понимается ПО, рассчитанное на большой тираж, но с каждой инсталляцией работает небольшое количество пользователей с узкоспециализированными  потребностями или "публичные" системы (небольшое количество инсталляций, но большое количество - "масса" пользователей)?

Массовый продукт - продукт, рассчитанный на использование массами. Я же пишу в заголовке - "публичные веб-системы" - частный случай массового продукта.

Нотация - это только знаки, которыми описывается модель. Задача соотнесения  потребностей и идеи проекта часто упирается в модель автоматизируемой деятельности (пользователя системы). Т.е. проблема обычно в содержательном развертывнии идеи в модель, особенно для систем, которые не подпадают под традиционные модели типа "промышленное производство" или даже "предприятие". У Вас не так?

Кто бы спорил, что только знаки. Модель использования вполне ложится в use-case'ы. Но нужна не модель использования, а модель потребностей, принципы её формирования. Модель использования из неё сделать уже не так сложно, когда знаешь цели потребителя, его портрет и ожидания.

Вот тут есть цикл тематически близких публикаций, точка зрения маркетолога.

Но как быть в ситуации с созданием массовых продуктов, когда нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать? Причём делать обширные маркетинговые исследования не позволяют ресурсы (деньги и время).

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

Мне кажется это один из "чисто теоретических" случаев.

Если нет возможности провести маркетинговое исследование, то что означают "релевантные потребности"? Откуда они возьмутся?

Мне кажется это один из "чисто теоретических" случаев.

Ничего теоретического - у самого несколько проектов такого характера на руках.

Если нет возможности провести маркетинговое исследование, то что означают "релевантные потребности"? Откуда они возьмутся?

Нет возможности провести ОБШИРНОЕ маркетинговое исследование.

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

Опять же, несмотря на все эти мантры "вы не можете знать, чего хочет пользователь, пользователь сам не знает, чего он хочет", тем не менее, мы всё равно при системном проектировании по крайней мере в технической части оперируем моделями и мысленными экспериментами - что есть UML-модель будущей системы, как не экспериментальная умозрительная конструкция, которую можно протестировать другими людьми?

Ничего теоретического - у самого несколько проектов такого характера на руках.

Нет возможности провести ОБШИРНОЕ маркетинговое исследование.

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

О чём вообще этот наш с вами системный анализ?

(голосом Вицина) Не "наш", а "ваш". Я вообще-то аналитик не настоящий.

В условиях малого бюджета я бы подумал в двух направлениях.

1. Провести разговор об ответственности и рисках с заказчиком/спонсором/автором идеи проекта. Польза такого общения зависит от того, как задача поставлена перед аналитиком. Если "ты сходи, обследуй кого-нибудь и выясни, что им нужно, неважно, что денег на это нет, на сколько есть, на столько и обследуй", то, возможно, это как раз тот случай, когда за проект лучше не браться. Если же заказчик/спонсор/автор идеи отдает себе отчет, что это проект с принципиально невосполнимой неполнотой исходной информации, и согласен взять эти риски на себя - тогда на месте аналитика я бы делал все требования с его слов. Возможно, это инновационный проект, который призван только сформировать у пользователей какие-то потребности, - тогда их и выяснять на начальном этапе, может быть, и бесполезно.

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

Собственно, 1-ый и 2-ый подходы не исключают их комбинированного применения.

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

Опять же, несмотря на все эти мантры "вы не можете знать, чего хочет пользователь, пользователь сам не знает, чего он хочет", тем не менее, мы всё равно при системном проектировании по крайней мере в технической части оперируем моделями и мысленными экспериментами - что есть UML-модель будущей системы, как не экспериментальная умозрительная конструкция, которую можно протестировать другими людьми?

Возможно, интересно было бы попытаться:
1. сформулировать (проклассифицировать, протипизировать) хотя бы возможные рамки пользовательских практик ("в жизни", не в виртуале), в которых полезно использование веб-систем. Какие классификационные признаки могут быть значимы для Вашей системы (чтобы не пытаться разрабатывать совсем глобальную классификацию)? Как позиционируется предлагаемая Вами идея в рамках такой классификации?
2. Каждой рамке (типу практик) соотнести типичного пользователя (профиль).
3. Для Вашей системы попытаться определить (профиль) пользователя "конструированием" пользователя Вашей системы из групп типичных пользователей других систем (по степени сходства и различия с Вашей системой).
3. Определить рамки "эксперимента на людях...".

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

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

Нет возможности провести ОБШИРНОЕ маркетинговое исследование.

тогда, имхо надо отталкиваться от артифактов и анализа потребностей для ролевых акторов, определить минимальные (без которых никуда) потребности и самые_общие (вероятно используются всеми) ... в любом проекте есть контингент на окучивание, и он как-то да изучен

тогда, имхо надо отталкиваться от артифактов и анализа потребностей для ролевых акторов, определить минимальные (без которых никуда) потребности и самые_общие (вероятно используются всеми) ... в любом проекте есть контингент на окучивание, и он как-то да изучен

Каких артефактов, откуда они возьмутся? Как определить минимальные потребности?

Каких артефактов, откуда они возьмутся? Как определить минимальные потребности?

вы разрабатываете 'сферического коня в вакууме'? разве первичным толчком к разработке 'массовых продуктов' не является потребность большой аудитории?

вы разрабатываете 'сферического коня в вакууме'? разве первичным толчком к разработке 'массовых продуктов' не является потребность большой аудитории?

"Первичным толчком" обычно является видение РЕШЕНИЯ, которое удовлетворяет КАКИЕ-то потребности КАКОЙ-то аудитории. Т.е. есть образ решения, которое МНЕ кажется ИНТЕРЕСНЫМ. Будет ли оно реально востребовано или нет - это вопрос.

Вот есть конкретный пример: http://www.uml2.ru/forum/index.php?topic=261.0

Мне кажется, я в своём первом сообщении высказался достаточно конкретно:

В в ситуации с созданием массовых продуктов, нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать.

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

Есть ли какие-то нотации для модели потребностей, методы её формирования и трансформации в пользовательские требования?

Что именно здесь непонятно?