Форум Сообщества Аналитиков

×


Реализовать нельзя упростить(Прочитано 32676 раз)
Реализовать нельзя упростить : 22 Октября 2013, 12:33:40
Вот уже на протяжении  6 лет я веду у 5 курса учебный проект. Все по-взрослому. У нас есть внешний заказчик, у нас есть команда, роли, задачи.
Нет реальных денег, но и с этим, я надеюсь, как-то решить.

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

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

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

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

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

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



Re: Реализовать нельзя упростить Ответ #1 : 22 Октября 2013, 13:40:50
1. хранить сведения о доставке будет в профиле пользователя
Мне, как заказчику, пофиг где и как будет это храниться.

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

3. а эффекта будет пшик
Что значит пшик? Кто будет платить за товар и доставку, который не доставили по причине неправильного адреса? Сколько мы на этом потеряем денег и клиентов и сколько будет стоить разработка?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

Я бы настояла реализацию адреса как текста в профиле клиента, но если вдруг адрес меняется, то - при заказе в комментариях.
Максимум , что можно уступить заказчику - это станцию метро  или район:)). Ну опять же если реализовать функционал по всей стране, то и это бы не предложила.
Вот такая я злюка :))
 
« Последнее редактирование: 22 Октября 2013, 14:56:50 от Elf »



Re: Реализовать нельзя упростить Ответ #3 : 22 Октября 2013, 14:13:35
Эд, а в чём конфликт интересов?

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

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



Re: Реализовать нельзя упростить Ответ #4 : 22 Октября 2013, 14:16:55
Модель предметной области есть? В ней согласовано, что адрес доставки — это атрибут конкретного заказа, а не только клиента?



Re: Реализовать нельзя упростить Ответ #5 : 22 Октября 2013, 15:10:56
Эд, а в чём конфликт интересов?

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

Ты знаешь, зачем ты заказываешь то, что заказываешь? Можешь объяснить подрядчику в терминах качества продукта и бизнес-эффектов (конверсия, результативность, потери)? С какой стати подрядчик оценивает степень «пшика» — он что, эксперт по электронной торговле? Его нанимали в таком качестве?
Заказчику надо предложить описать эффект, какой хочется достичь  от реализацией данного требования. Попробовать количественно оценить его.
Подрядчик, со своей стороны описывает трудозатраты, срок реализации требований, сопровождение данного функционала.
В этом случае Подрядчик косвенно влияет на решение Заказчика.
И потом часто бывает так, что у Подрядчика есть опыт реализации таких требований и он может сказать и без оценки - на сколько это "выгодно".
Но вопрос то не в этом как правильно, а в том оправдано ли реализация предопределенного адреса для сайта доставки пиццы? если я правильно поняла.
« Последнее редактирование: 22 Октября 2013, 15:38:23 от Elf »



Re: Реализовать нельзя упростить Ответ #6 : 22 Октября 2013, 15:56:13
Как и в реальном проекте возникают конфликты интересов. В частности возник такой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.
« Последнее редактирование: 22 Октября 2013, 15:59:27 от Леонид »



Re: Реализовать нельзя упростить Ответ #7 : 22 Октября 2013, 16:00:59
Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.
Как вообще заказчик может «лезть в не своё дело», если он просит «сделайте мне вот такую загогулину за мои деньги»? Он же не просит Подрядчика написать на сайте Подрядчика какой он, Подрядчик, дурак.



Re: Реализовать нельзя упростить Ответ #8 : 22 Октября 2013, 16:16:59
Как вообще заказчик может «лезть в не своё дело», если он просит «сделайте мне вот такую загогулину за мои деньги»? Он же не просит Подрядчика написать на сайте Подрядчика какой он, Подрядчик, дурак.

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



Re: Реализовать нельзя упростить Ответ #9 : 22 Октября 2013, 17:08:26
Саша, Элла.

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

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

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



Re: Реализовать нельзя упростить Ответ #10 : 22 Октября 2013, 17:18:47
Эд, а в чём конфликт интересов?
Конфликт громко сказано, конечно. Просто есть ожидание заказчика, и неожиданная реализация разработчика.

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

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

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

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



Re: Реализовать нельзя упростить Ответ #11 : 22 Октября 2013, 17:20:25
Модель предметной области есть? В ней согласовано, что адрес доставки — это атрибут конкретного заказа, а не только клиента?
Да есть - все согласовано.



Re: Реализовать нельзя упростить Ответ #12 : 22 Октября 2013, 17:21:13
Но вопрос то не в этом как правильно, а в том оправдано ли реализация предопределенного адреса для сайта доставки пиццы? если я правильно поняла.
Нет не доставка пиццы, ниже (выше) я пояснил предметную область



Re: Реализовать нельзя упростить Ответ #13 : 22 Октября 2013, 17:33:59
Я имею ввиду, что в сферической ситуации от Заказчика требуется более-менее внятно объяснить, чего он хочет. Разработчик должен предложить решение, при помощи которого Заказчик получит желаемое. В жизни возникает взаимопроникновение в "сферы ответственности". Заказчик пытается навязывать свои варианты решений, Разработчик предлагает изменения в бизнес-процессах. В зависимости от обстоятельств, такое вмешательство в дела друг друга может быть как самодурством, так и плодотворным сотрудничеством.

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

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

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

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



Re: Реализовать нельзя упростить Ответ #14 : 22 Октября 2013, 17:44:59
Неясно, в чем конфликт.
Да нет конечно не конфликт, так просто к слову пришлось
Цитировать
Разработчик предложил альтернативу и подкрепил ее (как смог) аргументами.
Тут уже были не аргументы - а реализация. Если бы это произошло до реализации, возможно разошлись бы полюбовно :)
Цитировать
У Разработчика были виды на внедрение какой-то своей технологии, которую он хотел обкатать на Заказчике?
Мне об этом не известно.
Цитировать
Разработчик хотел схалтурить при фикс прайсе?
Ну скорее всего, все-таки помимо моего проекта, нужно писать курсовую и сдавать другие предметы.
Цитировать
У Разработчика были виды на дальнейшие объемы работ (в частности, на разработку конвертера из текста в структуры для последующей аналитики или серию разовых преобразований)?
Мне кажется у нас с ним были разное понимание требования.

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

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

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

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

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

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

Цитировать
Без представления об остальном функционале Системы невозможно сделать вывод, лезет ли Заказчик не в свое дело, настаивая на приятных ему решениях, или Разработчик хитрит.
Почитайте Вигерса https://drive.google.com/folderview?id=0B-lK9AAeV_5cenFMMnd6Y2l5b0k&usp=sharing




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19