Retro, пример супер 

redona, т.е. проблема в том, что имеющаяся целевая аудитория содержит сегменты с разными потребностями, правильно?
Тогда ИМХО нужно просто сделать несколько версий, где базовый набор функций будут составлять используемые всей аудиторией, а специализированные входить в соответствующие версии.
Чем такой вариант не годится?

А то, что посылают к пользователям, это правильно.
Опускание этого этапа и есть те главные грабли, которые храбро собирают все разработчики. Им часто трудно себе представить, что на их софт не любоваться будут, а зарабатывать деньги с его помощью (как правило). Поэтому главное - необходимость и достаточность, удобство, переносимость, эффективность. Как бы вас не восхищала чудесная объектная модель или совершенный код, написанный вами, ни один пользователь его все равно не увидит  Об этом стоит помнить.
Поэтому бесполезно ЗДЕСЬ задавать вопрос - что должно быть в таком продукте? Только заказчик ответит на него.


А вы уже доросли до размеров и прибылей Майкрософт? ;)


дык критерием интересности-то и является пользователь - т.е. тот вот самый риэлтор.
Что-то может и совпадет.

Это сообщение отредактировал(а) ida - 12.1.2009, 17:55

ой, ну не нужно придираться к примерам

Добавлено @ 19:24

Ну я же сказал, что конкретного заказчика как такового нет. Заказчика нужно привлечь. А будет ли заинтересован будущий покупатель, если он откроет программу и увидит там две кнопки: добавить квартиру и найти квартиру. Круто, всё просто до ужаса, ну а толку.

Это сообщение отредактировал(а) Akella - 12.1.2009, 19:25

Akella, возможно, я не совсем ясно выразилась.

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

Да, мы создали опрос (гугл прекрасный инструмент предоставляет), разослали, народ ответил, по результатам немного допилили напильником программу, чуток добавили функционала. Но ничего существенного от них не дождались. Большая часть агентств развалилась просто-таки, ответили всего около 20-ти % от всех существующих клиентов, а хотелось бы, что бы процентов 80% ответили. 

Видишь ли в чём ИХ проблема, а может быть даже наша. Они, заказчики, категорически не хотят предоставлять техзадание. Меня недавно один клиент за душу тааак тряс, чтобы я добавил какую-то там функциональность, объясняя это вдумя словами. А это чревато доделками/переделками. Во он категорически отказался написать то, что он конкретно хочет от программы. Я отказался доделать желаемый функционал, т.к. даже смутно понимал, что вообще нужно было ему. 
Так что распрашивать их зачастую бесполезно.

Добавлено через 51 секунду

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

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

Могу помочь, если скинете предварительное описание (то, что вы насобирали) в Системный анализ, проектирование и UML

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

Добавлено через 1 минуту и 2 секунды

Не понял.

Добавлено через 1 минуту и 51 секунду
Пока конкретных описаний нет ещё. Есть пока что уже почти готовая база данных.

toida: извиняюсь, но слишком специализированный подход, Akella ведь не делает конкретный продукт для конкретного пользователя, пусть даже этот пользователь несколько размыт до уровня условный риэлтор, поэтому на большинство вопросов следует отвечать тому, кто считает экономические риски для этого продукта. думается, в данном случае, это отдельный человек. тем более, что продукт для всего этого уже есть, ms office практически идеально подходит, разве что макросов дописать и все будет в лучшем виде. готов поспорить.
прошу прощения, но пользователь, зачастую идиот, и ему надо рассказывать, как ему будет удобней. помните фразу -- если бы первые производители слушали пользователей, то они бы вывели новую породу скоростных лошадей.

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

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

я лично про жаргон имел ввиду упрощение поиска, как  я пояснил на примере Поиск по среднему этажу. А чешка, полька - это всё один справочник, т.е. в принципе никакого упрощения поиска.

Добавлено @ 23:32

Я понял, я видел такой справочник типов. Можно сформулировали набор правил, назвать его Набор1, второй набор назвать Набор2. Потом, выбираем Набор2 и часть полей заполняемой формы уже заполнена. Это для ускорения добавления квартир неплохо. Т.е. можно показывать на форме добавления список выпадающий, где будет показано название набора и его описание.
Только в той программе, которую я видел сделано было не много не так. Было там реализовано не по собственным названиям наборов, а по названиям жэков. Т.е. № дома и № жэка определяли тип планировки квартиры, уже можно было знать, что это за дом, в каком состоянии крыша или трубы и т.д.

Добавлено через 7 минут и 56 секунд
Единственный минус - это сбор информации об жэках, домах затруднён.

Это сообщение отредактировал(а) Akella - 12.1.2009, 23:34

      

а что, бывает и такое   

Да, потому что тогда еще не было аналитиков.

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

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

2. Пользователи осведомлены в своей предметной области гораздо больше любого среднего разработчика.
А разработчики, которым не объяснили хотя бы основ в хорошем ТЗ, нередко допускают такие ошибки, с которым становится бесполезным весь продукт.

3. Именно пользователи являются вашим источником дохода.
Без них все это вообще никому не нужно.

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

Это сообщение отредактировал(а) ida - 13.1.2009, 00:30

ida, спасибо, учтём 

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

Конкретный пример? Вести, например, в базе программы учёт заключённых договоров.
Потом такой пример. Вести в программе базу клиентов с паспортными данными. Для чего? Чтобы в будущем потратить немного денег на рассылку поздравительных открыток ко дням рождения. Мелочь? А человеку будет приятно. Он когда-то был в том агентстве... и забыл про него... а агентство не забыло про него, такой себе маркетинговый ход. Тот же календарь посуточной аренды с возможностью заранее бронировать квартиры или гостиничные номера.