Здравствуйте, okon, Вы писали:
B>>1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).
B>>Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
B>>На выходе получаете список потребностей заказчика в свободной форме.
O>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать
Вот тут как раз не надо долго! Надо кратко и с точки зрения бизнеса. Заказчик не должен продумывать, как все должно работать, — это задача команды разработчиков.
Пример правильно записанной хотелки: "Я банкир, я хочу, чтобы мои клиенты могли переводить друг другу деньги с помощью мобильного приложения, потому что это повысит привлекательность моих банковских продуктов."
Всё. Как именно это будет происходить — ваша задача предложить.
Или: "Я специалист по продажам, мне нужно знать, какие постоянные клиенты давно ничего не заказывали, чтобы предложить им сделать новый заказ".
Обратите внимание на вторую часть хотелки — конечная бизнес-цель. Ее знать не обязательно, но полезно, поскольку может помочь связать разные требования воедино (во втором примере можно сразу автоматизировать подготовку коммерческого предложения клиенту). Никаких форм, кнопок, серверов здесь не должно упоминаться. Исключение: у заказчика есть пользователи, уже привыкшие работать с определенным интерфейсом/в рамках определенного процесса — это знание пригодится, хотя и не должно являться требованием скопировать существующее решение.
O>Как правило после интервью остается больше вопросов и ответы уже ищутся по ходу реализации, т.к. не понятно что спрашивать
Спрашивать всегда нужно три вещи:
1. Каковы бизнес-цели заказчика? ("Я владелец фирмы-дистрибьютора элитной сантехники, хочу продавать свои товары через интернет. Хочу чтобы сайтом пользовались и дизайнеры интерьеров, получая информацию о новых сериях.")
2. Кто пользователи? (количество, демография, их связь с интервьюируемым)
3. Каковы их цели? ("Пользователь должен иметь возможность подобрать товар, подходящий к дизайну его ванной комнаты по стилю и цвету.")
O>Получается что пока не понятно что делать нет возможности приступить к разработке, это не практично.
Как вы себе представляете разработку в условиях, когда не понятно, что делать?
Если серьезно, хороший анализ экономит массу времени и, в конечном счете, уйму денег. Лишняя неделя на подумать спасет вас от пары месяцев переделок и вероятных срывов сроков.
O>Приходилось сталкиваться с проектами как сопровождения так и разработки полностью с нуля , никогда не бывает что сразу все понятно, но разработка как правило начинается с некого прототипа, который как правило не похож на финальное решение, которое получилось бы если сразу все знать и понимать.
Согласен, никогда не бывает так, что вся картинка складывается сразу. Даже если вы получили всю необходимую информацию и быстро спроектировали систему по состоянию дел в момент времени Т, через полгода бизнес заказчика изменится и требования вместе с ним. Но DDD не противоречит итеративной разработке — это аналитический подход, который защищает вас от ненужных ошибок, а не от вынужденных переделок.
O>Собственно меня ДДД и привлекает тем что язык описания как бы коррелирует с бизнесом и бизнес может в принципе сам конструировать реализацию или по крайней мере понимать ее.
В идеальном мире да, но наша профессия существует благодаря тому, что мы дополняем описание бизнеса спецификой реализации на основе разных профессиональных знаний: юзабилити, выбор алгоритмов исходя из их производительности и т.п. Это то, чего бизнес не сможет делать самостоятельно без посторонней помощи никогда.
O>Поэтому мне кажется ДДД все таки должна дружить с гибкими методами разработки когда в начале совсем практически не понятно что будет в конце тоннеля.
Ещё как дружит. Все что я описал, применимо к отдельным фичам — не обязательно прописывать все приложение сразу. Например, если вы делаете интернет-магазин, вы вероятно потратите немало времени, чтобы понять всю специфику каталога товаров вашего заказчика. Но уже в первом спринте вы сможете набросать прототип с корзиной и регистрацией пользователей, который отображает товары простым списком без структуры, и описывает их одним названием, без фото, характеристик и прочего.
