Есть разработка, заказчик ее проверяет и вроде как принимает. Но есть ошибки, которые нельзя выявить сразу (так называемые скрытые), или например, он не пользуется часто разработкой, а например, раз в квартал или раз в месяц.
Какой гарантийный срок принято давать на разработки? Как вы контролируете, чтобы исправление ошибок не перешло в новые доработки?
Демидова Татьяна
Этот вопрос не в этом форуме, см. http://forum.klerk.ru/forumdisplay.php?f=3
в смысле? зачем мне писать про разработки на 1С в бухучете?
Демидова Татьяна
Извини, сначала не понял вопроса....
Вы ведь спрашиваете: "Какой гарантийный срок принято давать на разработки?
(На разработки чего?) Как вы контролируете, чтобы исправление ошибок не перешло в новые доработки?"
Вообще этот вопрос надо задавать Франчайзи, в момент
обсуждения договора...
Но, как Вы наверное уже убедились, (по обсуждению темы
"Кому нужна 1С") ошибки в программе
БЫЛИ, ЕСТЬ и БУДУТ.. (К большому сожалению).
разработки - дополнения и изменения, создание обработок и новых конфигураций с нуля, любые вещи, написанные на 1С (и ей подобных платформах).
Хочу узнать, как это делают программисты 1С (разработчики, внедренцы, и прочие люди, причастные к разработкам на 1С). Меня интересует практика.
Демидова Татьяна
Практика разная.Сообщение от Демидова Татьяна
В зависимости от критичности приложения.
Вообще-то гарантийный срок должен быть адекватным времени жизни продукта.
Не очень то вижу проблемы. Обычный договорный процесс.
А зачем принимать разработку не проверив ее работоспособность.
Практика: Пишется задание, что надо сделать (как можно подробнее). А далее сморится его выполнении.
Вариант подродного задание есть страховка от того что исправление ошибок не перерастет в новыю разработку.
Надо присать ТЗ.
У меня пример Конфигурация для банка "Налоговый Учет ОС"
Начало они хотели считать только амморизацию, и упор делали на НУ.
Передалал стандартную бухгалтерию по банковский план счетов, т.к. начисление аммортизации у всех одинаковый.
Увидев это они захотели чтобы все формы по ОС запомнялись, т.е. захотели вести полный учет и отчетность по ОС, как НУ так и БУ.
Через некоторое время вспомнили что им надо делать переоцену и модернизацию, сделал.
Пришло распоряжение, кажется с ЦБ, вести учет ОС по МФСО,с сделал.
Не давно звонил просили подойти у них есть еще пожелания.
Да и в этой конфигураци они ведут учет материалов, НДС, авансовые отчеты.
Все это тянется уже 1,5 года и какой срок гарантии в этом случае. Это одна разработка или ......
В данном случае у нас заключен абон. договор.
Не всегда есть возможность все проверить, так что постановка вопроса в принципе правильная.
ТЗ на самом деле к гарантии не имеет отношения.
Гарантия может быть на конкретный модуль, или целую разработку. И неважно, какой срок это тянется.
Абонентский договор и гарантии - вещи, вообще-то существенно разные.
BorisG, проблем нет
Мне интересна сложившаяся практика и подход к этому вопросу ИТ-специалистов.
допустим срок жизни продукта - 3 года (то есть априори принимается, что 3 года продукт может без изменений суцществовать в созданном виде).Вообще-то гарантийный срок должен быть адекватным времени жизни продукта.
А как вы определаете срок жизни продукта?
Демидова Татьяна
Я думаю у ПП не может быть определенного срока жизни продукта, т.к. пока на нем работают он жив. Перестали работать ПП умер.
А гарантия, если вы найдете ошибку через 10 лет, как быть....
Если Вы закзывате разработке, то будьте добры ее проверить на работоспособность. Деньги заплатили, за что.... А раз заплатили значит Вас это устраивает.
Fosihas, ну представьте себе, вы пишете с нуля специфичную конфигурацию. Допустим конфигурация не большая и оплата производитсчя в один этап. Как можно сразу проверить абсолютно ВСЕ? Даже 1С сама до сих пор устраняет собственные ошибкиВариант - не платить вам денег, пока группа ползователей не оттестирует программу? Если это бухгалтерия, то срок затянется как минимум до сдачи годового баланса
Демидова Татьяна
Неверно, многие производители устанавливают срок жизни продукта. И на самом деле неважно, программный продукт это, или нет. По сути, срок жизни продукта, это срок окончания его поддержки, установленный производителем.
Такой термин, в оригинале они звучат как Life Time, End Of Life, End Of Standard Maintenance, End Of Extended Maintenance, Вы сможете найти и у SAP R/3, и у, например, Cisco. Эти две фирмы очень четко следуют этим терминам. Причем, первая - известный производитель программного обеспечения, вторая - известный производитель и "железа", и софта.
Последний раз редактировалось BorisG; 28.02.2005 в 09:22. Причина: Дополнение
Так а... проблема то в чем? Это же чисто договорной процесс, записывайте в договор порядок, сроки и объем тестирования. И все.
И еще один момент, Вас же не смущает тот факт, что, например, покупая зимнюю обувь весной, гарантийный срок начинает исчисляться с начала соответствующего сезона
Ну это дело конкретного производителя. Кто-то продает "Как есть...", кто-то органичивает сроки предъявления претензий, например, 90 днями (срок из реального договора).
Деньги и тестирование - вещи вообще-то не связанные.
BorisG, меня интересуетХочу, чтобы мне раскрыли тайну - кто на сколько договаривается и каков критерий? Ну вот если я попрошу гарантию 10 лет на разработку. Со мной согласятся?Какой гарантийный срок принято давать на разработки?
Демидова Татьяна
А мы в момент продажи ПП даем Лицензионное соглашение, где указываем, сто в течении календарного года мы обязаны исправлять найденные ошибки, гарнантируем телефонную поддержку и соответстветствие законодательству. Далее через год продлеваем обязательства за деньги. И всего делов.
Yuwa, очень интересно! А продлеваете обязательства за какие деньги? Сколько процентов от стоимости разработки, например? А ПП какое продаете? Собственного производства или как?
Демидова Татьяна
1) Продаем свою конфигурацию на 7.7
2) 20% от стоимости
В доходах фирмы доля этих платежей значительна.
Yuwa, спасибо за информацию, очень помогли
Демидова Татьяна
Что-то нигде не увидел, поэтому хочу сказать:
Очень часто пользователь принимает за ошибку что-то, что по его мнению работает не так. Т.е. он не выполнил ряд регламентных действий, в результате у него что-то не срослось.. Или неудобно ему, или ещё что-то... Он хочет изменить алгоритм (например избавиться от регламентных действий, добавить удобные фишечки, фенечки).
В этом случае, мне кажется, речь о гарантии идти не должна. Оплата должна быть отдельной. Ведь на этапе оценки работы программер предполагал именно такой функционал, а не расширенный...
С уважением
Зернятко А.В.
А вот еще вопрос возник. Многие сетуют на то, что заказчики в процессе работы изменяют требования к результату, поэтому исполнители советуют составлять ТЗ. Все, что не предусмотрено ТЗ, - за отдельную плату.
Я очень часто сталкиваюсь с недочетами программистов, которые они впоследствии исправляют. По справедливости, за это надо деньги брать?
Мне кажется, что как не бывает идеального ТЗ, так и не бывает идеального исполнения и везде есть допустимый процент ошибок. Вопрос в том - какой процент?
Демидова Татьяна
>Вопрос в том - какой процент?
Я бы сказал (глядя на релизы готовых конфигураций
и список того что исправлено) - 90% (шутка конечно),
а если серьезно - 20%
Любое ТЗ, как бы хорошо оно не было написано, не может отражать очень много существенных моментов, которые неочевидны. Вообще, я считаю, что ТЗ - это такая бумага, при помощи которой разработчику можно достать свои деньги. Это ее основное назначение. В теории ее должен писать заказчик, но в моей практике не было ни одного случая, когда пользователь мог бы ее написать сам. Наверное, бывают такие случаи, когда задачка простейшая, тогда ее пользователь может изложить, но кому она нужна. Слишком просто.
Вот азернот - программист, правда? Чувствуется. А может быть хватит "открывать Америку" и внедрять каждое очередное предприятие, как в первый раз. Хкатит плодить уникальные конфы. Есть такое понятие - отраслевое решение. Здесь правда. Верно, брат?
а подойдет ли отраслевое решение 20% крупных заказчиков? вряд ли. Довольны будут лишь 80% малых. Собственно, как и сейчас это происходит 80% довольны типовыми решениями от ЗАО 1С.Хкатит плодить уникальные конфы. Есть такое понятие - отраслевое решение.
Демидова Татьяна
Я вовсе не имел ввиду, что все отраслевые решения от 1С. Есть ИТРП, Инталев, Рарус, Астор и прочие. Мы. Есть замечательная и совершенно разумная идея от вендора "1С-Совместно", ЦКП (не путать с Совместимо).
Другой вопрос - это качество и настраиваемость ОР. Если в ОР будет параметрическая настройка, то это изживет болезнь "безудержного кодирования".
На продукты 1C? Ну ну...
Вы не так поняли.
Поесняю.
пишется ТЗ (конкретное задание и что мы сделали).
Обычно при объеме работы от 10 часов.
И мы отвечаем только за работу "нашего куска".
За конфигурацию "отвечает 1с" и линия консультаций.
Последний раз редактировалось Aquad; 13.03.2005 в 18:31.
alta, спасибо за отклик.
Скажите, а на разработки менее 10 часов есть ли гарантия? например какая-нибудь простенькая обработка или отчет?
Сколько бы вы дали гарантию на конфигурацию, написанную с нуля? к примеру простая конфа по бюджетированию для мелкой фирмы (пример абстрактный).
Демидова Татьяна
Правильный подход к качеству разработок на 1С примерно следующий.
Всегда покупайте разработки только по договору.
В договоре или приложении к нему (Тех.задании) опишите функциональные возможности разработки.
Укажите срок действия договора и предусмотрите обязанность разработчика в течение этого срока бесплатно исправлять ошибки, препятствующие использованию разработки по целевому назначению, либо не обеспечивающие заявленную фукциональность.
Совет: покупайте типовые и тиражные решения, которые постоянно обновляются и развиваются разработчиками. В этом случае вы получите большую уверенность в качестве и сроке жизни приобретаемого решения, поскольку сам разрабочик заинтересован в сохранении их актуальности и отсутствии ошибок.
Я обычно работаю так. Запуск комплексных систем в опытную эксплуатацию начинаем с 01 января. Будет ли Заказчик при этом вести параллельный учет в старой системе - фиолетово. Но 3 месяца опытной эксплуатации - это тот срок, в течение которого мы бесплатно устраняем все ошибки и недоработки.
Подписание Акта о переводе системы в промышленную эксплуатацию означает, что Заказчик к Исполнителю претензий не имеет. Все.
Иногда устанавливаем гарантийный срок - год. Но это только на очень крупных проектах. Если Заказчик за 3 месяца не в состоянии проверить работу несложной конфигурации - пусть платит деньги.
Насчет ТЗ я написал выше, а в остальном категорически солидарен. Я за тиражируемые отраслевые решения, а не уникальные "нетленки" программеров. При этом неважно, является ли указанный программер сотрудником франча или фикси или фри.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
