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

Как и в реальном проекте возникают конфликты интересов. В частности возник такой.

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

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

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

Когда я как заказчик обратился к команде с некоторым удивлением, мне сказали примерно следующее:
1. хранить сведения о доставке будет в профиле пользователя
2. если реализовать то, что вы сказали - трудоемкость возрастет в разы
3. а эффекта будет пшик

Интересно мнение форумчан.  Прав ли заказчик, настаивая на своих требованиях. Или ему следует прислушаться к мнению разработчиков, что так проще?

1. хранить сведения о доставке будет в профиле пользователя

Мне, как заказчику, пофиг где и как будет это храниться.

2. если реализовать то, что вы сказали - трудоемкость возрастет в разы

Что значит в разы? Сколько было в часов, сколько стало?

3. а эффекта будет пшик

Что значит пшик? Кто будет платить за товар и доставку, который не доставили по причине неправильного адреса? Сколько мы на этом потеряем денег и клиентов и сколько будет стоить разработка?

Правильно ли я поняла, что Заказчик настаивает на реализации предопределенного адреса в профиле или в комментариях к заказу?
Если так, то
1. Реализация будет очень трудоемкой.
2. Эффект от лояльности клиента, какой хочется достигнуть в рамках этой задачи, нулевой.
3. Сопровождение данного функционала будет дорогим.

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

Эд, а в чём конфликт интересов?

«Трудоёмкость возрастёт» — что, подрядчик не получит за это больше денег? Или у вас фикс прайс?

Ты знаешь, зачем ты заказываешь то, что заказываешь? Можешь объяснить подрядчику в терминах качества продукта и бизнес-эффектов (конверсия, результативность, потери)? С какой стати подрядчик оценивает степень «пшика» — он что, эксперт по электронной торговле? Его нанимали в таком качестве?

Модель предметной области есть? В ней согласовано, что адрес доставки — это атрибут конкретного заказа, а не только клиента?

Эд, а в чём конфликт интересов?

«Трудоёмкость возрастёт» — что, подрядчик не получит за это больше денег? Или у вас фикс прайс?

Ты знаешь, зачем ты заказываешь то, что заказываешь? Можешь объяснить подрядчику в терминах качества продукта и бизнес-эффектов (конверсия, результативность, потери)? С какой стати подрядчик оценивает степень «пшика» — он что, эксперт по электронной торговле? Его нанимали в таком качестве?

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

Как и в реальном проекте возникают конфликты интересов. В частности возник такой.

Неясно, в чем конфликт. Разработчик предложил альтернативу и подкрепил ее (как смог) аргументами.
У Разработчика были виды на внедрение какой-то своей технологии, которую он хотел обкатать на Заказчике?
Разработчик хотел схалтурить при фикс прайсе? У Разработчика были виды на дальнейшие объемы работ (в частности, на разработку конвертера из текста в структуры для последующей аналитики или серию разовых преобразований)?

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

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

В состав реализуемых на данном этапе функций Системы входит статистика/аналитика заказов в разрезе адресов доставки? А в перспективы развития Системы?

Однако когда была предложена реализация, то оказалось, что Место доставки - текстовое поле, куда клиент вбивает адрес доставки.

Это сильно дешевле с точки зрения разработки и эксплуатации, чем запрошенный Заказчиком вариант ввода адреса из иерархического справочника. Реализация требований Заказчика в пределе повлечет за собой:
1. Раз[до]работку подсистемы ведения НСИ.
2. Усложнение структуры БД и принятие ряда непростых решений о способе хранения адресной информации.
3. Доработку руководства пользователя.
4. Доработку технологической инструкции.
5. Доработку должностных обязанностей.
6. Повышение требований к квалификации пользователя.
7. Усложнение освоения Системы.
8. Увеличение объема работ по обслуживанию Системы.
 
Но зато даст возможность относительно легко собирать о обрабатывать статистику.

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

Ввод вручную из справочника не гарантирует корректности адреса.
Улучшить достоверность адресной информации можно путем интеграции с HRM-системой Компании (которая знает, кто где сидит и куда переехал).

Когда я как заказчик обратился к команде с некоторым удивлением, мне сказали примерно следующее:
1. хранить сведения о доставке будет в профиле пользователя

Прощай, учет доставок.

2. если реализовать то, что вы сказали - трудоемкость возрастет в разы

По сравнению с предложением Разработчика - да.

3. а эффекта будет пшик

Я бы попросил Разработчика обосновать столь замечательный вывод.

Интересно мнение форумчан.  Прав ли заказчик, настаивая на своих требованиях. Или ему следует прислушаться к мнению разработчиков, что так проще?

Почему или-или?
Заказчик должен изучить и согласовать варианты технических решений, предложенных Разработчиком. Или не согласовать и отправить на доработку. Или впечатлиться предложениями настолько, что внести изменения в ТЗ в установленном порядке.

Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.

Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.

Как вообще заказчик может «лезть в не своё дело», если он просит «сделайте мне вот такую загогулину за мои деньги»? Он же не просит Подрядчика написать на сайте Подрядчика какой он, Подрядчик, дурак.

Как вообще заказчик может «лезть в не своё дело», если он просит «сделайте мне вот такую загогулину за мои деньги»? Он же не просит Подрядчика написать на сайте Подрядчика какой он, Подрядчик, дурак.

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

Саша, Элла.

Мы проектируем Cafeteria Ordering System по Вигерсу. Система заказов обслуживает только сотрудников компании. Компания большая. Адрес доставки должен находится внутри компании и нигде более. Клиент оплачивает обеды через удержание из з/п - если заказ доставляется, и наличными, если не сотрудник приходит в кафетерий ногами.

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

Элла, как теперь изменится твое мнение? И главное почему?

Эд, а в чём конфликт интересов?

Конфликт громко сказано, конечно. Просто есть ожидание заказчика, и неожиданная реализация разработчика.

«Трудоёмкость возрастёт» — что, подрядчик не получит за это больше денег? Или у вас фикс прайс?

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

Ты знаешь, зачем ты заказываешь то, что заказываешь? Можешь объяснить подрядчику в терминах качества продукта и бизнес-эффектов (конверсия, результативность, потери)? С какой стати подрядчик оценивает степень «пшика» — он что, эксперт по электронной торговле? Его нанимали в таком качестве?

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

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

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

Более того я готов пойти на уступки, но это же должно быть как-то объяснено?

Модель предметной области есть? В ней согласовано, что адрес доставки — это атрибут конкретного заказа, а не только клиента?

Да есть - все согласовано.

Но вопрос то не в этом как правильно, а в том оправдано ли реализация предопределенного адреса для сайта доставки пиццы? если я правильно поняла.

Нет не доставка пиццы, ниже (выше) я пояснил предметную область

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

Заказчик, т.е. я сформулировал требования по адресу доставки и проработал их вместе с аналитиками примерно 2 недели назад. Никаких заявлений о способе реализации, месте хранения и т.п. заказчик не выдвигал. Ему это фиолетово было.

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

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

Возможно, я как заказчик (и преподаватель) строг?

Неясно, в чем конфликт.

Да нет конечно не конфликт, так просто к слову пришлось

Разработчик предложил альтернативу и подкрепил ее (как смог) аргументами.

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

У Разработчика были виды на внедрение какой-то своей технологии, которую он хотел обкатать на Заказчике?

Мне об этом не известно.

Разработчик хотел схалтурить при фикс прайсе?

Ну скорее всего, все-таки помимо моего проекта, нужно писать курсовую и сдавать другие предметы.

У Разработчика были виды на дальнейшие объемы работ (в частности, на разработку конвертера из текста в структуры для последующей аналитики или серию разовых преобразований)?

Мне кажется у нас с ним были разное понимание требования.

В состав реализуемых на данном этапе функций Системы входит статистика/аналитика заказов в разрезе адресов доставки? А в перспективы развития Системы?

Да, это одна из целей создания системы

Это сильно дешевле с точки зрения разработки и эксплуатации, чем запрошенный Заказчиком вариант ввода адреса из иерархического справочника. Реализация требований Заказчика в пределе повлечет за собой:
1. Раз[до]работку подсистемы ведения НСИ.
2. Усложнение структуры БД и принятие ряда непростых решений о способе хранения адресной информации.
3. Доработку руководства пользователя.
4. Доработку технологической инструкции.
5. Доработку должностных обязанностей.
6. Повышение требований к квалификации пользователя.
7. Усложнение освоения Системы.
8. Увеличение объема работ по обслуживанию Системы.

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

Но зато даст возможность относительно легко собирать о обрабатывать статистику.

Кроме того устранить аномалии модификации

Ввод вручную из справочника не гарантирует корректности адреса.
Улучшить достоверность адресной информации можно путем интеграции с HRM-системой Компании (которая знает, кто где сидит и куда переехал).

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

По сравнению с предложением Разработчика - да.

Не аргумент

Я бы попросил Разработчика обосновать столь замечательный вывод.

Я попросил.

Почему или-или?
Заказчик должен изучить и согласовать варианты технических решений, предложенных Разработчиком. Или не согласовать и отправить на доработку. Или впечатлиться предложениями настолько, что внести изменения в ТЗ в установленном порядке.

Именно к этому я и призываю сторону разработки. Согласовывать со мной свои решения.

Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.

Почитайте Вигерса https://drive.google.com/folderview?id=0B-lK9AAeV_5cenFMMnd6Y2l5b0k&usp=sharing