Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Бесплатная гарантийная техподдержка. Как поступить?

На днях ко мне обратился приятель, занимающийся аутсорсингом разработки ПО. Суть вопроса в следующем. Он заключает контракт на достаточно большой проект, запуск всей системы будет происходить по этапам. В процессе разработки будут появляться новые доп. соглашения на новые модули. И в начале проекта оценить объем этих новых доп. соглашений не представляется возможным. Заказчик настаивает на бесплатную годовую гарантийную поддержку. Как в данном случае поступить?

Ничего сверхъестественного в требовании “бесплатной” годовой гарантийной ТП нет. Адекватное требование клиента. Если хочет чтобы была ТП бесплатной — тоже не проблема. Дополнительные риски и расходы Исполнителя в данном случае закладываются сверху в стоимость проекта. Каждый, кто занимается аутсорсингом разработки, должен приблизительно понимать, чему равны подобные расходы в его случае. Мы же для простоты предположим, что это 10%.

Конфуз в другом. Как я написал выше, предполагается, что запуск системы будет проводиться по этапам. А гарантия начинает действовать с завершением первого. И заканчивается спустя год после завершения последнего (который, кстати, ещё непонятно когда заканчивается — ведь будет неясное число доп. соглашений). И все понимают, что гарантийная ТП на конкретный функционал — абсурд. ТП должна быть на всю систему. Хорошо, когда мы заранее знаем объем работ по всем этапам и плановые сроки их начала/завершения. Тогда мы сможем посчитать реальную продолжительность гарантийных обязательств и рассчитать правильную надбавку. В данном случае не так.

Поясню возможную проблему на примере. Допустим, у нас 3 этапа. Первый имеет трудоемкость 50 (условных единиц), второй 30, третий 20. Для простоты стоимости сделаем соответствующие: 50+30+20 = 100 рублей. Ну с накинутыми 10% за “бесплатную” гарантийку — 110. Первый этап завершается в январе 2011 года, второй завершается в марте 2011 а третий в декабре 2011 (при заключении договора мы понятия не имели, когда будет третий этап и на сколько он будет трудоемким). Тогда наши обязательства по поддержке вступают в силу в январе 2011 года, а становятся исполненными в декабре 2012.

По сути, мы поддерживаем первый модуль 2 года, второй модуль 1 год и 10 месяцев ну а третий ровно 1 год. Тогда наша надбавка за ТП, по-хорошему, должна равняться 50*2*0,1 + 30*1,83*0,1 + 20*0,1 = 17,5 рублей. Т.е. по факту мы только в плане недосчитались 7,5 рублей (а могло быть и хуже, а могло и лучше).

Как быть в таком случае? Мне в голову пришло два варианта:

  1. Изменять процент гарантийной надбавки при согласовании работ по новому этапу.
  2. Взять чуть больший процент гарантийной надбавки (по отношению к принятому в конкретной компании).

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

Ну и да — есть третий вариант. Не париться и понадеяться на авось. Может за 2 года не придётся тратить времени на починку багов?:).

Как вы посоветовали бы поступить в подобной ситуации?

Комментарии (22)

  • Аватар

    Бычков Валерий [vbychkov], 07 сентября 2010, 12:23

    0
    Вариант 3. Разделить доп. соглашения на бесплатную тех. поддержку на две части: - на время ввода системы в эксплуатацию. С оценкой рисков по каждому этапу. - первый год работы системы. Если это не первое внедрение системы, у исполнителя должно быть вполне обоснованное предположение о сбистоимости этого этапа.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 07 сентября 2010, 12:49

      0
      нет никакого доп. соглашения на бесплатную тех. поддержку. Это строчка в основном договоре (или доп. соглашении на дополнительный модуль). Если б договор на техническую поддержку был отдельным и оплачиваемым -- то тут проблем никаких нет.
      • Аватар

        Бычков Валерий [vbychkov], 07 сентября 2010, 13:17

        0
        Что мешает дополнительному соглашению быть отдельным, но не оплачиваемым? Или что мешает в основном договоре прописать объем бесплатных гарантий по тех.поддержке?
        • Аватар

          Рубинштейн Кирилл [krubinshteyn], 07 сентября 2010, 14:09

          0
          Приведи пример для данного конкретного случая, что нужно написать и в каких доп. соглашениях.
          • Аватар

            Бычков Валерий [vbychkov], 07 сентября 2010, 17:06

            0
            Дополнительное соглашение №1 Бесплатная тех. поддержка на период внедрения системы. Оговариваем поэтапно функции охватываемые тех. поддержкой. Оговариваем объем тех. поддержки. Оговариваем не гарантийные случаи и случаи, когда проблема будет решена на следующих этапах внедрения. Дополнительное соглашение №2 Бесплатная гарантийная тех. поддержка в первый год. Оговариваем, что является гарантийными случаями. Оговариваем объем гарантийных работ. Оговариваем стоимость не гарантийных работ/стоимость превышения оговоренного объема гарантийных работ. Дополнительное соглашение №3 Платная гарантийная тех. поддержка. В ДС№2 дополнительная задача – подписать продление тех. поддержки на 2-й и последующие годы с добавлением пунктов относительно стоимости работ. Да, стоимость работ по бесплатной тех. поддержке фактически будет скрыта внутри стоимости остальных работ по договору, однако в таком варианте можно детализировать объем гарантийных работ на каждом этапе проекта.
            • Аватар

              Рубинштейн Кирилл [krubinshteyn], 07 сентября 2010, 17:12

              0
              Доп. соглашение 1. Оговаривать функции охватываемые на этапе гарантийки бессмыслено -- нужно поддерживать все функции, находящиеся в этот момент в продакшене. Негарантийные случаи (админ взял удалил пол кода и ничего не работает) в любом случае описываются в договоре. Или же ты имеешь ввиду что-то другое? В итоге не вижу, как предложеные 3 доп. соглашения решают проблему бесконечно продолжающейся технической поддержки на весь функционал.
              • Аватар

                Бычков Валерий [vbychkov], 07 сентября 2010, 17:24

                0
                А для разработки в которой сроки завершения работы не определены - вообще бессмысленно подписываться на бесплатную гарантию на всю систему. Можно попробовать бесплатную гарантию на отдельные модули и спустя год переводить в платный вариант гарантии каждый модуль в отдельности.
                • Аватар

                  Рубинштейн Кирилл [krubinshteyn], 07 сентября 2010, 17:28

                  0
                  Так а вот в этом и был вопрос -- как поступить. Если не подписываться на бесплатную гарантийку, то не подписывается и контракт ;).
                  • Аватар

                    Бычков Валерий [vbychkov], 08 сентября 2010, 16:08

                    0
                    Получил подтверждение правильности своего подхода. Александр Левинсон, международный консультант по ITSM, предлагает еще более сложную структуру контракта: 1. Глобальный контракт 2. Тарифы по глобальному контракту 3. Детализированный контракт по услуге 4. финансовая часть по услуге 5. соглашение об уровне сервиса 6. Детализация процессов и процедурной части ИМХО - та же идея - все вопросы, особенно в дальнейшем связанные с чем то "бесплатным" максимально детализировать и явно указывать ограничения - только так можно более-менее точно предсказать затраты на бесплатный сервис
  • Аватар

    Солопов Павел [PaSol], 09 сентября 2010, 15:26

    0
    Коллеги, а не смешались ли понятия. Поддержка и гарантия. Гарантия это когда производитель обязуется устранить баги, которые он наделал по своей вине. Т.е. баги, которые не соответствуют ТЗ. Я бы требовал от производителя даже не год, а пожизненную гарантию, чтобы внимательней к разработке относились. А Поддержка - это может быть очень по разному. От консультирования пользователей какую кнопку жать, до разработки новых модулей. Что предполагается выполнять в рамках поддержки в данном случае?
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 09 сентября 2010, 15:47

      0
      Павел, имеется ввиду именно гарантия -- несоответствие ТЗ. Про пожизненню гарантию это вы загнули конечно. Ну спорить не будете, что бесплатных гарантий вообще не бывает (все риски закладываются в стоимость продукта). Соответственно, если кто-то пообещал сделать что-то бесплатно и пожизненно, то значит либо продукт идеальный (а это очереденой сферический конь), либо в стоимость он заложил много миллионов. А что до гарантийный багов -- то по большому счету, в рамках гарантии находятся минорные баги, четкого описания поведения системы для которых в ТЗ как правило не бывает и аналитику (или кто там продукт проектировал) в рамках исправления бага приходиться принимать решение о том, какое поведение системы в данном случае верное.
  • Аватар

    Солопов Павел [PaSol], 09 сентября 2010, 15:58

    0
    Судя по всему стоимсоть поддержки не зависит от объёма функционала напрямую, а лишь от цены модуля. В таком случае мы вполне можем сделать так: Первый этап (50 р.) завершается в январе 2011 года, второй завершается в марте (30 р) 2011 а третий (20 р.) в декабре 2011. В январе 2012 подписываем договор на поддержку первого модуля (50х0,1), в марте 2012 допсоглашение на поддержку второго модуля (30х0,1), в декабре 2012 поддержка на третий модуль (20х0,1)... Это конечно если заказчик допускает возможность с ним обсуждать варианты, а не бесприкасловно выполнять поручения.
  • Аватар

    Солопов Павел [PaSol], 09 сентября 2010, 16:27

    0
    Кирилл, вы видимо не сильно внимактельно ознакомились с предложенной мной моделью. :-) Поддержка на первый модель бесплатаня в течение года с 01.2011 по 01.2012, договор на поддержку появляется только через год после ввода в действие модуля. Аналогично и по другим модулям. Я подозревал, что вы скажете о зависимотси цены модуля от функционала, но ключевым является модель формирования стоимости поддержки. Если стоимость поддержки всегда пропорциональна стоимости поддерживаемого продукта, то моя модель применима. Если нет, то появляется ещё одна неизвестная... Дело осложняется.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 09 сентября 2010, 16:31

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

    Солопов Павел [PaSol], 09 сентября 2010, 16:45

    0
    Ах да, забыл сделать примечание, что предполагается преобретение заказчиком поддержки. А почему нельзя делать поддержку помодульно? Или предполагается, что второй и третий этапы это будет доработка и видоизменение, созданного на первом. Иначе, если будет создан разный функционал, то его можно как-то разграничить для целей гарантии.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 09 сентября 2010, 17:01

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

    Солопов Павел [PaSol], 13 сентября 2010, 00:58

    0
    Кирилл, что-то вы всё совсем запутали, кто заказчик, кто исполнитель, кто аутсорсер? Это вообще случай из жизни или придуманный сюжет-провокация. Давайте ближе к конкретике. Пусть разрабатывается на первом этапе модуль ввода данных и модуль анализа. На втором модуль отчётности, а на третьем веб-портал. Что же вы не можете определить, какой функционал к какому модулю относится? Не спорю бывают такие случаи, когда изменение в одном модуле может потребовать изменения в другом, если поддержки на "задеты" модуль уже нет, при согласовании изменения в поддерживаемом заказчику озвучивается, что надо доплатить, ибо поддержки нет (раз покупать не хочет). Но если заказчик не диалого-пригоден, то умножайте цену на 5 и не тратьте время, ни своё, ни наше. :-)
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 13 сентября 2010, 11:41

      0
      Ситуация вполне жизненная, не выдуманная. Под Исполнителем в предыдущем посте я подразумеваю Аутсорсера (он же исполнитель:). Эта же компания у нас на подряде переписывает на новую платформу сайт сообщества и пишет новый модуль (но не подумайте, что тот заказчик, о котором идет речь -- это мы:). Итак, для простоты, давайте приведу пример с нашим же сайтом, хоть функционал тут гораздо меньше. Вот сейчас есть сайт в том виде, в котором вы его видите. Не открою большой тайны, если напишу, что через месяц добавиться новый функционал -- расширенный каталог аутсорсинговых компаний и услуг. Т.е. по сути -- функционал вроде бы как отделяем друг от друга. Но код то один, сайт один. Так же есть связный функционал (измениться процедура регистрация, карточка участника и её редактирование). Ну а на уровне кода -- ещё больше. Соответственно, коммитим в одно место -- ломается другое. Или, например, сломалась регистрация участника -- она сломалась в части сообщества, или каталога? Ну вообще вывод, как вы написали -- оценивать расходы на поддержку перед согласованием каждого нового доп. соглашения. Думаю, это сухой остаток:).
  • Аватар

    Солопов Павел [PaSol], 20 сентября 2010, 12:22

    0
    Давайте по порядку. 1. Ситуация "Соответственно, коммитим в одно место -- ломается другое". Не относится к гарантии, поскольку сбои возникли по причине вновь вносимых изменений. Подобные сбои должны устраняться независимо от наличия поддержки, поскольку они результат некорректных действий разработчика. Иначе получается бесконечная цепочка: дорабатываем, ломаем рядом стоящее, требуем денег за починить рядом стоящее, чиним рядом стоящее, ломаем стоящее рядом с рядом стоящим, требуем денег... 2. Ситуация: "Так же есть связный функционал (измениться процедура регистрация, карточка участника и её редактирование)". Если мы заведомо знаем, что придёться что-то поменять в модуле, созданом ранее, то это необходимо внести в стоимость разработки, это никоим образом не относится к гарантийным обязательствам. 3. Гарантии надо предоставлять не на код или элементы интерфейса, а на функционал. Функция авторизация - должна делать то-то и то-то, функция личная карточка то-то и то-то... Гарантия включается в том случае, когда какая-то функция перестала работать, как это было описано в ТЗ. При разборе сбоя возможен отказ в гаратнии, если выяснится, что сбой возник по причине некорректных действий пользователя, вмешательства в код программы, некорректной настройки и т.д. Нужно по возможности чётко разгарничить случаи гарантийные и не гаратнийные.