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