Что делать если реализованный функционал не описан в требованиях, но не противоречит им ?

ничего. считайте, что вы бесплатно его сделали, вместо того, чтобы сделать что-то из требований за деньги...

я смотрю наш тест по хорошим рукам пошёл.
ну что же, хорошо. придётся переделывать. да и пора уже.

я смотрю наш тест по хорошим рукам пошёл.
ну что же, хорошо. придётся переделывать. да и пора уже.

О каком тесте речь?

Практическая часть довольно странная. Я слабо представлю ситуацию когда появляется "левый" функционал. Вот поэтому и решил проконсультироваться у гуру

О каком тесте речь?

Конфликтующие требования от 2-х ЗЛ, незапрошенные функции в продукте - это вопросы теста, который мы используем в отделе при отборе кандидатов на собеседования.

Так какой правильный ответ ?

+ бывает творческий полёт мысли разработчика, но редко.. И быстро искореняется.

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

А трудозатраты на поддержание\изменение такого ненужного функционала никто не считает?? Тем более такого, которого нет в требованиях.
Еще будете делать Заказчику работу бесплатно?

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

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

LastLegion86, я говорю про заказную разработку, а вас интересует продуктовая.

Не обязательно. Даже если эта заказная разработка, то рано или поздно наступает момент когда тот или иной продукт требует доработки. Внедрение новой версии так сказать. И тогда идет описание того, что нужно изменить и как.  Например нужно изменение модуля номер 1 и номер 5. И вполне вероятна ситуация когда незапланированный функционал пришелся "по вкусу" заказчику в процессе использования всего продукта и у заказчика есть пожелания по его изменению доработки. И тогда подобные изменения доработки можно делать уже за денежку.

Да, но вы уже подарили его, то есть вам уже требуется реализовать доработку за бюджет и отбить уже потраченные деньги. Бюджет, возможно, потребуется обосновать (и не факт что заказчик будет тюфяком и подпишет любую сумму). Либо придётся эти деньги распылять по всем этапам проекта и всем задачам. + получается, что вы уже вылетели из бюджета, например, то есть проект нельзя назвать успешным. А если финансовый год на носу?
При том: функционал должен был быть изначально не полным, он должен быть востребованным и за него готовы заплатить. А если вам заказчик багу пришлёт - есть такая фишка, но работает на один модуль, а при том, по логике, это из "Раздела общих фунций". Доделывайте, ничего не знаю!

Получается, что слишком много рисков.