Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Oleg Voronov от 05 Октября 2010, 17:42:47
-
Что делать если реализованный функционал не описан в требованиях, но не противоречит им ?
-
ничего. считайте, что вы бесплатно его сделали, вместо того, чтобы сделать что-то из требований за деньги...
-
я смотрю наш тест по хорошим рукам пошёл.
ну что же, хорошо. придётся переделывать. да и пора уже.
-
я смотрю наш тест по хорошим рукам пошёл.
ну что же, хорошо. придётся переделывать. да и пора уже.
О каком тесте речь?
-
Практическая часть довольно странная. Я слабо представлю ситуацию когда появляется "левый" функционал. Вот поэтому и решил проконсультироваться у гуру :)
-
О каком тесте речь?
Конфликтующие требования от 2-х ЗЛ, незапрошенные функции в продукте - это вопросы теста, который мы используем в отделе при отборе кандидатов на собеседования.
-
Так какой правильный ответ ?
-
+ бывает творческий полёт мысли разработчика, но редко.. И быстро искореняется.
-
Во-первых - гордиться. Если, конечно, это достойный функционал, и он помогает пользоваться системой, а не мешает этому. И если сроки/бюджеты не пострадали от этого. А во-вторых - попробовать получить с этого бонусы от заказчика в том или ином виде. Не обязательно в виде денег, возможно и менее материальное - благосклонность и снисходительность при приемке, благодарность пользователей, учет при следующих заказах.
-
А трудозатраты на поддержание\изменение такого ненужного функционала никто не считает?? Тем более такого, которого нет в требованиях.
Еще будете делать Заказчику работу бесплатно?
-
Ну с другой стороны если он не мешает, то зачем тратить силы на его исключение. Если его нужно будет изменить, то можно вложить на это бюджет и рассматривать этот функционал как нечто нужное, предлагаемое клиенту.
-
Вариант у нас иногда использовался такой - скрыть данный функционал и попробовать его продать на ближайших доработках. Или выторговать за что-нибудь :)
-
LastLegion86, я говорю про заказную разработку, а вас интересует продуктовая.
-
Не обязательно. Даже если эта заказная разработка, то рано или поздно наступает момент когда тот или иной продукт требует доработки. Внедрение новой версии так сказать. И тогда идет описание того, что нужно изменить и как. Например нужно изменение модуля номер 1 и номер 5. И вполне вероятна ситуация когда незапланированный функционал пришелся "по вкусу" заказчику в процессе использования всего продукта и у заказчика есть пожелания по его изменению доработки. И тогда подобные изменения доработки можно делать уже за денежку.
-
Да, но вы уже подарили его, то есть вам уже требуется реализовать доработку за бюджет и отбить уже потраченные деньги. Бюджет, возможно, потребуется обосновать (и не факт что заказчик будет тюфяком и подпишет любую сумму). Либо придётся эти деньги распылять по всем этапам проекта и всем задачам. + получается, что вы уже вылетели из бюджета, например, то есть проект нельзя назвать успешным. А если финансовый год на носу?
При том: функционал должен был быть изначально не полным, он должен быть востребованным и за него готовы заплатить. А если вам заказчик багу пришлёт - есть такая фишка, но работает на один модуль, а при том, по логике, это из "Раздела общих фунций". Доделывайте, ничего не знаю!
Получается, что слишком много рисков.
-
Если мы по итогам реализации проекта вложились в сроки и бюджет, то реализация лишнего не есть плохо (хотя разработчики конечно могли бы лишний час поспать :) ).
А доработка этого функционала - это уже возможность заработать денег. Ее можно рассматривать как предложение чего то нового. То есть попробуйте, понравилось - пользуйтесь, хотите чуть подправить - платите за доработку, не хотите не платите.
Я понимаю что деньги потраченные на разработку лишнего не отобьешь, но если я не вылетел из бюджета, то это не страшно (потеря сверхприбыли конечно). Но подобный неучтенный функционал может дать возможность заработать в дальнейшем.
То что функционал не полный - не факт. Например в модуль бухгалтерии прикрутили месенджер. В принципе бухгалтеру он не нужен, но ему понравилось что удобно скидывать номера накладных или реквизиты своим коллегам. Они не задумывались о подобном, а тут попробовали и понравилось (Правда непонятно из чего исходил программист прикручивая мессенджер :) ).
Вот насчет багов проблема, есть баг - негатив ложится на всю систему целиком и не скажешь что "Неиспользуйте вы это не заказывали". Либо убирать, либо исключать.
-
ТЗ будете актуализировать, если оставляете??
-
Я вот это и пытаюсь узнать.
Я никогда не сталкивался с подобным.
Мое мнение что ТЗ актуализировать не получится. Как объяснить заказчику, что мы ему что-то "левое" впихнули?
+ По идеи, ТЗ уже давно согласованно и подписано, и как его менять непонятно. Опять же тот или иной функционал должен покрывать задокументированную нужду заказчика\пользователя, а в данном случае заказчик\пользователь никак ее не озвучивает и не факт, что ему оно понравится и уж точно он не готов сразу за это платить.
Так же при вносе этого функционала в ТЗ мы наживаем "геморой" себе. Получая обязанность "на халяву" поддерживать и разрабатывать что - то.
-
В том то и дело :)
Либо Вы показываете этот ф-ал заказчику и договариваетесь включить это в ТЗ, чтобы можно было поддерживать. Либо по тихому удаляете и все.
-
Кстати, а у кого - нибудь были в практике подобные случаи ?
-
Много раз (вызвано особенностью проекта, не спрашивайте почему :) ). Я написал, что мы делали - скрывали и потом выторговывали или продавали.
-
Сравнительно небольшие и безобидные дополнительные фичи (как упомянутый выше мессенджер) можно оставлять в качестве бонусов - будет просто полезная дополнительная мелочевка.
Но серьезные излишества однозначно надо удалять. Потом пользователь паче чаяния начнет этими модулями пользоваться, при этом выяснит, что их функционал неполный и несоответствует ожидаемым им требованиям, найдет ошибки, будет скандалить и требовать исправления в рамках сопровождения. Зачем нужен бесплатный геморой?
-
Ну вот тут момент что он начнет требоваться и захочет дополнения - это не так уж и плохо. Можно попробовать срубить денег на доработке. А вот баги и поддержка это конечно зло.
-
Что делать если реализованный функционал не описан в требованиях, но не противоречит им ?
Я бы вначале попробовал разобраться в причинах, по которым этот функционал был реализован, но не описан. И уже от этого плясал бы.
-
На самом деле, я себе вообще слабо представляю подобную ситуацию.
Если не рассматривать вариант когда заказчик напрямую договорился с разработчиками ( в обход всех и вся ), то что должно сподвигнуть программиста выполнить лишнюю работу ???
-
На самом деле таких ситуаций может быть огромное количество. Первое, что приходит на ум:
Заказчик передает предварительный запрос на доработку. Доблестный ПМ стартует работы по выполнению этого запроса до подписания официальных документов. Когда все уже реализовано, Заказчик меняет свое решение, отказывается от доработки и не подписывает документы/не оплачивает работы.
-
Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.
-
На самом деле таких ситуаций может быть огромное количество. Первое, что приходит на ум:
Заказчик передает предварительный запрос на доработку. Доблестный ПМ стартует работы по выполнению этого запроса до подписания официальных документов. Когда все уже реализовано, Заказчик меняет свое решение, отказывается от доработки и не подписывает документы/не оплачивает работы.
Ну этот вариант не совсем корректный. Тут речь о другом, о том что все подписано и сделано что - то неизвестное клиенту. Он этого не просил и знает что это. Может понадобится, может нет. Инициатива не от заказчика.
-
Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.
1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.
-
дополнительные затраты - это, конечно, так. НО! ведь на поддержку системы будет новый (другой!) договор, и там можно (нужно!) прописать всё, что вам будет нужно, например адекватную цену.
Сопровождение (= доработка) - отдельная песня, еще один договор со своими условиями и ценой.
-
Об этом я писал уже выше. Действительно, если в дальнейшем клиент скажет что "Да классно, мне нравится, но вот тут бы допилить", ему можно ответить "Ок, 200к" :). И тогда это только плюс.
Поддержка оговаривается в рамках контракта на внедрение. И если поддержка не лимитирована (то есть должен чинить все и всегда), то вполне реальна ситуация, когда клиент говорит что "ваша левая" фича падает и ее нужно починить и допилить. А это ресурсы. А деньги те же что и без нее, так как согласовывались до ее появления. В итоге - убытки.
-
что тут скажешь? улучшайте процесс продаж, обучайте продажников - не должно быть такой ситуации: ни когда "поддержка не лимитирована", ни когда "деньги согласовывались до ее появления". неправильно закладывать бюджет имея только слабое представление о будущих рисках, либо не имея его вовсе. в этом случае убытки - вполне закономерный исход недостаточно квалифицированного управления...
-
Я немного другое имел ввиду.
Допустим мы провели предпроектное исследование и т.д. Формируем требования и т.д. В итоге получаем систему в набором функ-ий (например 10).
Согласовываем и получаем что наши 10 фун-ий стоят 100 т р. Там же оговариваем поддержку, есть круглосуточный сапорт 24/7, которая обойдется в 200 т р. клиенту. И примерно знаем что будет 50 обращений в месяц для которых хватит ресурсов 2 х сотрудников.
А по факту выходит что у нас не 10, а 12 фун-ий. И если мы их оставляем - мы должны их поддерживать. В итоге будет на 50, а 60 обращений и 2х сотрудников саппорта не хватит. В итоге мы несем затраты.
-
еще раз.
контракт на поддержку непринятой в эксплуатацию системы, т.е. системы с неопределенным набором функций, ЗАКЛЮЧАТЬСЯ НЕ ДОЛЖЕН. Иначе Вы не сможете его выполнить.
При этом действительно ресурсы поддержки оцениваются из опыта, статистики и т.п. Количество обращений тоже.
Однако дальше все зависит от организации процессов поддержки. В принципе я могу и в эту тему погрузиться, но она не для этого форума - читайте ITIL/ITSM и itsmforum.ru
а затраты мы несем всегда, это точно... вот только нормативные они будут или сверхнормативные зависит не от количества обращений, а от организации процесса. пока расслабьтесь и оставайтесь в области разработки...
-
Почему система не принятая в эксплуатацию - с неопределенным набором функций ? Мне казалось что они как раз описываются до разработки и уже указаны в контракте, иначе как проводить приемку ?
Я еще раз напоминаю, что не нужно углубляться в те или иные процессы.
Речь идет не о том как правильно организовать поддержку, а о том стоит ли такой функционал включать в ТЗ и описывать (тем самым беря на себя ответственность за него) или его стоит искоренить (даже если это затратно). И если стоит оставить, то почему и какие профиты с этого можно поиметь.
-
Вообще говоря, все зависит от организации Вашего процесса разработки: если он подразумевает согласуемое с заказчиком ТЗ и последующую его неизменность (некий вариант водопадной модели). Вы можете рискнуть и сразу подписать контракт на поддержку. Но я бы этого делать не стал, так как риски изменений очень велики.
Однако, когда заказчик подписывает контракт на разработку, он понимает, что систему нужно будет поддерживать и стремится снизить свои издержки в отношении поддержки. НО! на самом деле издержки, связанные с поддержкой будут минимальны, когда снята неопределенность в отношении состава поддерживаемой системы. как минимум это означает, что контракт на поддержку должен подписываться в районе подписания акта приемки. да и для разработчика это выгоднее.
а представьте бывают ситуации, когда поддержка гарантировано будет осуществляться не разработчиком, а компанией, выбираемой на конкурсной основе. как тогда работала бы Ваша схема?
P.S. ну что ж раз Вы не хотите обсуждать организацию поддержки, то и я не буду на этом настаивать...
-
1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.
Дальше я тоже читал, прежде чем ответить...
Во-первых, вопрос в величине расходов. Сопровождать 100 фич или 102 - безразлично. Если заказывали 3, а сделали 10 - да, это беда. Но если эти 10 уложились в бюджет 3, то и сопровождение 10 уложится в бюджет 3 - это же чистая статистика, сопровождение везде тоже считают как проценты от разработки. Кроме того, дополнительные фичи можно не сопровождать и, особенно. не дорабатывать. Так что не понимаю опасений.
Речь идет не о том как правильно организовать поддержку, а о том стоит ли такой функционал включать в ТЗ и описывать (тем самым беря на себя ответственность за него) или его стоит искоренить (даже если это затратно). И если стоит оставить, то почему и какие профиты с этого можно поиметь.
Есть компромиссный вариант: в продукте оставить, в ТЗ не включать и не описывать. В конце концов, ТЗ уже согласовано. Стоит ли оставить зависит от ситуации, от того. какие профиты можно поиметь. Например, довольство заказчика и большую вероятность последующих заказов.
-
По поводу не сопровождения фич это спорно. Если клиент говорит что при нажатии на такую то кнопку что-то падает, то ее надо починить что-бы не падало. Сказать ему "Не нажимайте" вы не заказывали будет некорректно.
Так же если функционал оставить но не включить в ТЗ, то как потом отслеживать "откуда оно появилось" ?
-
Ну, если при нажатии на кнопку система падает, то это не фича (в смысле - она не работает, то есть не сделана). Если падать стало в результате доработок системы, про фичу забыли - можно кнопку убрать.
А что касается как отслеживать - по-моему всегда есть внутренние, а не внешние доки на систему. Там и написать кратко "случайно сделали такую-то фичу, в ТЗ ее нет.
-
Ну предположим "фича" может падать когда параллельно с ней открыты одноклассники. А такую ситуацию не оттестируешь сразу (это утрированный пример). А всплывет это после внедрения и нужно будет потратить время, что бы эту ошибку локализовать.
Так может кнопку сразу убрать и не показывать заказчику вообще ?
Как правило эти внутренние инструкции очень плохо систематизированы. И найти в них что то непросто.
-
Вот! Не показывать! Этот вариант я привёл ещё на первой странице обсуждений :)
-
Вот! Не показывать! Этот вариант я привёл ещё на первой странице обсуждений :)
Но ведь как вариант это не всплывет и заказчик получит лишний профит, а в идеале за денежку потом этот функционал доработает. Тем самым прибавив нам прибыли.
-
Но ведь как вариант это не всплывет и заказчик получит лишний профит, а в идеале за денежку потом этот функционал доработает. Тем самым прибавив нам прибыли.
Может закажет. А может не закажет - съест бесплатный сыр и этим удовлетворится - он что лох что ли, попадаться на такую простую разводку.
В любом случае это должна быть продуманная и спланированнная маркетинговая акция, а не спонтанное творчество. Нажно прикинуть его будущие потребности исходя из имеющейся информаци, и реализовать их частично, чтобы было что дорабатывать. Наживочная функциональность должна быть продумана и протестирована не менее тщательно, чем заказанный функционал, и отражена во внутренних ТЗ, которые заказчику не передаются.
А случайно родившийся функционал прибивать
-
А прибивание спонтанного творчества - оно плохо сказывается на мотивации и моральном состоянии авторов этого творчества. Они же старались. Так что тут в обе стороны проблемы быть могут...
-
А прибивание спонтанного творчества - оно плохо сказывается на мотивации и моральном состоянии авторов этого творчества. Они же старались. Так что тут в обе стороны проблемы быть могут...
Ну да, творческая личность развлеклась от нечего делать, а остальные участники процесса (тестеры, документаторы, сопровождение) негры что-ли? А если так развлекся аналитик/архитектор/проектировщик, то вообще по башке надо давать - неграми становятся уже программеры. Если у кого-то избыток времени, то это не значит, что его избыток и у всех остальных. Так что с точки зрения внутрикомандной мотивации мотивации и морали это палка обоюдоострая.
Но воообще-то для полностью заказных продуктов мне кажется это все-таки надуманная ситуация. Для тиражных, полутиражных-полузаказных, внутренней автоматизации - да, такое бывает, но там не так страшно.
-
Коллеги, кроме того, есть риск удешевления стоимости дальнейших контрактов. Представьте себе, вы согласовали scope работ, ткой-то стоимостью, долго бодались по продолжительности. Договорились.
Сдаете работу. Выясняется - что помимо выполненных задач вы сделали еще и то, о чем не просили. Вывод - вы я вно завысили цену, и на следующих переговорах вам это припомнят.
-
Сдаете работу. Выясняется - что помимо выполненных задач вы сделали еще и то, о чем не просили. Вывод - вы я вно завысили цену, и на следующих переговорах вам это припомнят.
Я бы не стал так трактовать это однозначно. Хотя могу предположить у автора наличие горького опыта.
Я вовсе не отрицаю подобного развития событий, однако то, что мы сделали что-то, о чем собственно не просили, может быть уже ранее созданным функционалом, некоторым наработанным ранее решением, или неким сопутствующим моментом. Вопрос как это преподнести
-
Сдаете работу. Выясняется - что помимо выполненных задач вы сделали еще и то, о чем не просили.
Ну и бардак же там у вас... :)
-
Коллеги, кроме того, есть риск удешевления стоимости дальнейших контрактов. Представьте себе, вы согласовали scope работ, ткой-то стоимостью, долго бодались по продолжительности. Договорились.
Сдаете работу. Выясняется - что помимо выполненных задач вы сделали еще и то, о чем не просили. Вывод - вы я вно завысили цену, и на следующих переговорах вам это припомнят.
Расскажите как у вас так получается? на своей практике всегда наоборот. Не успеваем выполнить все требования, т.к. при первоначальном обследовании хотели одно, а в ходе реализации выявляется еще и новое, "без чего они жить не могут". Перерасход бюджета, не выполнение сроков и т.д "приятности" :)
-
при первоначальном обследовании хотели одно, а в ходе реализации выявляется еще и новое, "без чего они жить не могут".
Зачем тогда проводить обследование? Только время терять и бюджет тратить... :о))) Все равно что-то новое выявится...
Перерасход бюджета, не выполнение сроков и т.д "приятности" :)
Уж по бюджету-то можно создать резерв. По ресурсам и срокам сложнее... Только не забывайте о законе Брукса
-
Расскажите и мне как проводить обследование и выявить все требования с первого раза? Но эта тема другого топика.
"Лишнее" можно делать только в том случае, когда это улучшает качество продукта и вы знаете, что работаете на перспективу (продать многим клиентам, например).Включить в требования наверно не получится.
-
Ну и бардак же там у вас... :)
Непонятно, причем тут я?
Автор темы задал вопрос касательно того, что сделали работу, не описанную в ТЗ.
Я предлагаю посмотреть на это с точки зрения Заказчика, с которым торговались по объемам и по ценам, а потом говорят : а теперь "приз"!
-
Непонятно, причем тут я?
Автор темы задал вопрос касательно того, что сделали работу, не описанную в ТЗ.
Я предлагаю посмотреть на это с точки зрения Заказчика, с которым торговались по объемам и по ценам, а потом говорят : а теперь "приз"!
Ага пардон что то не обратил внимание что процитировал цитату из др сообщения.
А выглядит это действительно как бесплатный подарок. Если дать ребенку игрушку а потом отобрать - примерно тоже самое и тут получится.
-
Расскажите и мне как проводить обследование и выявить все требования с первого раза? Но эта тема другого топика.
заводите тему, рассказывайте свой подход - обсудим. но по-моему подобные темы уже были.
и потом выявление требований не должно останавливаться по окончании обследования, это точно уже обсуждали.
"Лишнее" можно делать только в том случае, когда это улучшает качество продукта и вы знаете, что работаете на перспективу (продать многим клиентам, например).Включить в требования наверно не получится.
думаю, что в каждом конкретном случае "лишнее" будет выражено чем-то своим. поэтому лучше говорить предметно.
приведу абстрактный пример: при обследовании какую-то сущность определили кратко - достаточно вручную вводить некое наименование, а по факту выяснилось, что для этого нужен справочник, который пришлось делать + какие-то процедуры его ведения. IMHO лишним в данном случае не является, всего лишь недообследованный/недодуманный участок. для таких случаев и нужно создавать резервы.
Причем тут "включить в требования не получится"? Требования - это один поток информации, реализация - другой. Они, безусловно, связаны друг с другом, но не обязательно реализуются все требования, но то, что реализовано, должно быть в требованиях.
Вы, кстати, ТЗ с требованиями не путаете?
P.S. ничего личного
-
не путаю и не обижаюсь..
если ваш справочник не подтягивается при вводе - это недообследование и естно недореализация. Это резерв и т.д. Согласна.
А если вы понимаете что ваш фильтр не предназначен для работы с информацией клиента? Что делаете в этом случае? Можно плюнуть и сказать "нет требований". Но можно пойти на реализацию вне бюджета только если такой фильтр всем понадобится и конкурентоспособность системы повысится. Я предпочитаю второй способ, только надо очень много доказать руководству, что это "лишнее" совсем не лишнее. :) Вот как то так...
-
не уверен, что адекватно понял сентенцию про фильтр, поэтому мне сложно по существу сказать "чья тут вина, ты мне ответь", но IMHO скажу, что в подобном случае нужно утереться и сделать "чтобы было как надо" - соответственно получается, риск сработал.
Ибо клиент платит не за то, что вы делали (занимались решением задачи), а за то, что вы сделали (как задачу решили).
Если это оказалось вне бюджета исполнителя - хреновый исполнитель или хреновое решение, только и всего. Плохо, конечно, что руководству в этих условиях еще что-то надо доказывать, но у него ведь другие мерки - затраты. Но ведь могут быть и другие, скажем - стратегические, интересы.