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