Для сопровождения руководства

Четвертое — быть готовым к любым изменениям в графике шефа, продлении переговоров на несколько часов или быстрого завершения мероприятия. То есть не собираться в последнюю минуту, теряя канцелярские принадлежности на пол и роняя листы бумаги, когда шеф уже в дверях идет на выход после встречи.

Также следует подготовится к тому, что встреча затянется. Поэтому позаботится о наличии воды, чая или кофе. Хотя бы для своего начальника, если встреча проходит на стороне.

Шестое — готовность №1. Это правило касается поездок в первую очередь. При работе в крупной компании, когда шеф часто посещает другие города и страны, иногда он берет с собой и своего секретаря.
Некоторые поездки могут случиться неожиданно и даже срочно. На сборы может и не быть времени.

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

Сопровождение программных продуктов и баз данных – процесс, который не определен законом, но он все равно встречается в официальной документации. За счет этого в мире сложилось общее понимание предстоящей операции. Сюда можно отнести обучение клиентов основам работы с программным обеспечением, а также консультирование, настройку и адаптацию контента в пользовательской среде, поддержку работоспособности, исправление неполадок и возникающих ошибок. При необходимости – обновление и модификацию.

Сопровождение контента не имеет четко обозначенных границ, поэтому соответствующее понятие является весьма широким. Определяется непосредственными сторонами-участниками. Далее техническая поддержка программных продуктов будет рассмотрена более подробно.

Определение понятия

Рассматриваемое понятие – процедура улучшения, устранения дефектов и оптимизации программных продуктов. Осуществляется после того, как софт передан на реализацию. Является одной из фаз жизненного цикла ПО. Она идет после передачи контента в эксплуатацию.

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

О границах использования

Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:

1. Сопровождение автоматизированных информационных систем ничем не отличается от аналогичной операции относительно другого софта.
2. Сопровождение ПО не предусматривает техническую поддержку АИС. Связано это с небольшой разницей при реализации.

ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.

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

Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.

Структура

Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:

• для устранения обнаруженных ошибок;
• при модификации в соответствии с потребительскими нуждами.

В структуре технической поддержки программного обеспечения выделяют несколько линий. Они помогают понять, чем будет заниматься соответствующий специалист.

Чтобы лучше разобраться в теме, необходимо рассмотреть наглядную структуру процесса. За основу взят внешний контент:

1. Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
2. Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
3. Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
4. Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.

Работа инженера иногда сравнивается с информационными центрами. Функционал у соответствующих «специалистов» сильно отличается. Колл-центр собирает обращения, а сопроводитель – это ключевое звено технического обслуживания и доработки. Он будет решать проблемы, связанные с эксплуатацией программных продуктов и сервисов.

Виды

Техподдержка бывает разной. Она включает в себя базовый и расширенный типы. В первую категорию включены следующие операции:

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

Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.

Расширенный тип предусматривает:

• модификации эталонных сервисов и баз данных для развития и встраивания обновлений;
• совершенствование для отладки работоспособности итогового контента.

Остальные задачи обсуждаются индивидуально.

Этапы

Рассматриваемая операция обычно включает в себя несколько этапов:

1. Подготовка к необходимым исследованиям и действиям.
2. Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
3. Внесение изменений.
4. Проверка и приемка контента.

В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.

Как быстро освоить направление

Поддержка программного обеспечения – процесс, который сможет освоить любой IT-специалист. Особенно, если он занимается системным администрированием и разработкой.

Чтобы быстрее освоить направление, в Москве и других регионах России рекомендуется закончить специализированные компьютерные курсы. В срок до 12 месяцев пользователя научит инновационным профессиям с нуля. В конце будет выдан сертификат, подтверждающий знания и умения в соответствующей области.

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.

Документация по сопровождению программных средств.

Документация
по сопровождению ПС описывает
ПС с точки зрения ее разработки. Эта
документация необходима, если ПС
предполагает изучение того, как оно
устроена, и модернизацию его программ.
Сопровождение — это продолжающаяся
разработка. Поэтому в случае необходимости
модернизации ПС к этой работе привлекается
специальная команда разработчиков-сопроводителей.
Этой команде придется иметь дело с такой
же документацией, которая определяла
деятельность команды первоначальных
(основных) разработчиков ПС, — с той лишь
разницей, что эта документация для
команды разработчиков-сопроводителей
будет, как правило, чужой (она создавалась
другой командой). Команда
разработчиков-сопроводителей должна
будет изучать эту документацию, чтобы
понять строение и процесс разработки
модернизируемого ПС, и внести в эту
документацию необходимые изменения,
повторяя в значительной степени
технологические процессы, с помощью
которых создавалось первоначальное
ПС.

Документация
по сопровождению ПС можно разбить на
две группы:

(1)
документация, определяющая строение
программ и структур данных ПС и технологию
их разработки;

(2)
документацию, помогающую вносить
изменения в ПС.

Документация
первой группы содержит итоговые документы
каждого технологического этапа разработки
ПС. Она включает следующие документы:

• Внешнее
  описание ПС.

• Описание
  архитектуры ПС, включая внешнюю
  спецификацию каждой ее программы.

• Для
  каждой программы ПС — описание ее
  модульной структуры, включая внешнюю
  спецификацию каждого включенного в
  нее модуля.

• Для
  каждого модуля — его спецификация и
  описание его строения.

• Тексты
  модулей на выбранном языке программирования.

• Документы
  установления достоверности ПС,
  описывающие, как устанавливалась
  достоверность каждой программы ПС и
  как информация об установлении
  достоверности связывалась с требованиями
  к ПС.

Документация
второй группы содержит

• Руководство
  по сопровождению ПС, которое описывает
  известные проблемы вместе с ПС, описывает,
  какие части системы являются аппаратно-
  и программно-зависимыми, и как развитие
  ПС принято в расчет в его строении
  (конструкции).

Общая
проблема сопровождения ПС — обеспечить,
чтобы все его представления шли в ногу,
когда ПС изменяется. Чтобы этому помочь,
связи и зависимости между документами
и их частями должны быть зафиксированы
в базе данных управления конфигурацией.

Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.

Обсудим
обеспечение примитивов качества ПС,
выражающих критерии функциональности
и надежности ПС.

Обеспечение завершенности программного средства.

Завершенность
ПС является общим примитивом качества
ПС для выражения и функциональности и
надежности ПС.

Функциональность
ПС определяется его функциональной
спецификацией. Завершенность ПС как
примитив его качества является мерой
того, насколько эта спецификация
реализована в данном ПС. Обеспечение
этого примитива в полном объеме означает
реализацию каждой из функций, определенной
в функциональной спецификации, со всеми
указанными там деталями и особенностями.

Однако
в спецификации качества ПС могут быть
определены несколько уровней реализации
функциональности ПС: может быть определена
некоторая упрощенная (начальная или
стартовая) версия, которая должна быть
реализована в первую очередь, могут
быть также определены и несколько
промежуточных версий. В этом случае
возникает дополнительная технологическая
задача: организация наращивания
функциональности ПС. Упрощенная версия
требуемого ПС должна быть рассчитана
на практически полезное применение
любыми пользователями, для которых оно
предназначено. Поэтому главный принцип
обеспечении функциональности такого
ПС заключается в том, чтобы с самого
начала разрабатывать ПС таким образом,
как будто требуется ПС в полном объеме,
до тех пор, пока разработчики не будут
иметь дело с теми частями или деталями
ПС, реализацию которых можно отложить
в соответствии со спецификацией его
качества. Тем самым, и внешнее описание
и описание архитектуры ПС должно быть
разработано в полном объеме. Можно
отложить лишь реализацию тех программных
подсистем, определенных в архитектуре
разрабатываемого ПС, функционирования
которых не требуется в начальной версии
этого ПС.

Понятие сопровождения программ для ЭВМ и баз данных (далее — ПО и БД) не определено законом, но на практике и в различных официальных документах сложилось достаточно однородное понимание этого процесса — к нему относится, прежде всего, разного рода обучение пользователей работе с продуктом и соответствующие консультации, настройка и адаптация продукта в среде пользователя, поддержание его работоспособности и исправление возможных ошибок, обновление, а иногда и модификация. Состав операций по сопровождению не имеет жестких универсальных границ, а гибко определяется договорами сторон. Важно отметить, что при наличии в составе действий по сопровождению модификации ПО и БД перед участниками сделки встает вопрос о принадлежности прав на модифицированный продукт.

Необходимо отметить, что распространенность сопровождения ПО на ИТ-рынке как формы сервиса влечет проникновение этого термина и в сферу юридических отношений, вследствие чего нередки становятся случаи, когда приходится соотносить с ним те или иные действия сторон договора либо правовые институты, что иногда может оказаться непростой задачей.

Особенно часто потребность в правовой квалификации сопровождения ПО и БД возникает в сфере интеллектуальной собственности, когда необходим учет интересов авторов и правообладателей при конструировании сделки. Для прояснения ситуации в настоящей статье будет произведен обзор категории сопровождения ПО в соответствии с установившимися практиками.

Что является сопровождением ПО

В федеральном законодательстве отсутствует понятие сопровождения ПО и БД (а равно и понятие «поддержка», которое обычно рассматривается как синоним). Вместе с тем на рынке сложилось определенное понимание перечня операций и обязательств сервисной организации, относящихся к сопровождению, притом что данный перечень является широким и продолжает расширяться по мере технологического прогресса. Это понимание основывается в том числе на ряде примеров операций по сопровождению, которые содержатся в различных официальных документах (в том числе подзаконных актах и нормативных актах регионального уровня), и отражается в договорной (контрактной) практике рынка.

Для начала предложим обобщающий взгляд на содержание сопровождения ПО и БД, а ниже поговорим подробнее о его отдельных элементах в контексте конкретных иллюстрирующих примеров. Итак, на рынке устоялись следующие типы сопровождения ПО с нижеследующим характерным наполнением:

1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком, может включать:
   • обучение работе с продуктом и его обслуживание в режиме диспетчерской связи. Иначе — информационно-справочная поддержка функционирования продукта;
   • адаптацию, настройку, изменение и дальнейшую техподдержку экземпляров с учетом особенностей среды пользователя. Речь может идти об обеспечении работоспособности и функционирования экземпляра ПО и БД при первичной интеграции и в случаях изменений в программно-аппаратной среде пользователя (адаптация, переустановки);
   • поддержку работоспособности, профилактику и устранение сбоев в работе пользовательских экземпляров. Данное направление предполагает мониторинг и устранение ошибок и сбоев в работе конкретных пользовательских экземпляров ПО и БД в том числе путем тестирования, а также иными способами и средствами;
   • прочие, обычно индивидуально обусловленные операции, в той или иной мере изначально заложенные разработчиком.
2. Расширенный тип сопровождения — дополнительно включает некоторую доработку (модификацию) ПО и БД, в частности:
   • модификацию эталонного ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры. Модификация продукта производится в интересах его совершенствования, а загрузка обновленных версий (пакетов обновления) в индивидуальные пользовательские экземпляры ПО и БД вместе с их адаптацией в конкретной программно-аппаратной среде необходимы для доведения обновлений до пользователей;
   • модификацию эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры. Модификация продукта иногда требуется для устранения и предотвращения различных серьезных ошибок и сбоев, до пользователей они доводятся аналогично.

Сразу отметим, что приведенный комплекс операций очерчивает границы сопровождения ПО и БД как теоретической категории. На практике же, в рамках конкретных договоров и техзаданий, сопровождение ПО и БД обычно представлено лишь какой-то частью этих операций, интересных и необходимых конкретному пользователю данного продукта с учетом особенностей его технологии, сервисной политики разработчика, объема потребностей и т. д. Таким образом, любой компонент представляет собой сопровождение ПО и БД как сам по себе, так и в связке с другими компонентами.

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

Раскрытие понятия сопровождения ПО в официальных документах

Теперь посмотрим, как отдельные операции по сопровождению ПО и БД из обозначенного перечня отобразились в тех или иных официальных документах.

1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком

1.1. Обучение работе с продуктом и его обслуживание в режиме диспетчерской связи.

• дополнительные требования к программам для ЭВМ и базам данных, сведения о которых включены в реестр российского программного обеспечения (утв. Постановлением Правительства РФ от 23.03.2017 N 325) [1]. Под сопровождением пользователей понимается информационная поддержка (п. 2). Сопровождение пользователей обеспечивается посредством использования телефонной связи и средств электронной почты на русском языке в круглосуточном режиме (п. 16);
• Приказ Федерального казначейства от 10.10.2018 N 37н [2].

К услугам, связанным с сопровождением, технической поддержкой, обновлением ПО и БД, отнесены, в частности:

• прием, выполнение и мониторинг выполнения обращений пользователей программного обеспечения;
  • информационно-справочное обслуживание, включая:
  • поддержку и консультацию пользователей программного обеспечения по телефону и электронной почте;
  • ведение и обновление базы данных, содержащей информацию для службы технической поддержки в целях поддержки и консультации пользователей программного обеспечения.
  • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [3].

Поддержка функционирования ПО и БД может включать в себя обучение или работу в режиме диспетчерской связи (п. 6.4.10.1).

1.2. Адаптация, настройка и дальнейшая техподдержка экземпляров с учетом особенностей среды пользователя.

• ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [4].

Сопровождение может включать изменение программного продукта после поставки, обеспечивающее его работоспособность в измененных или изменяющихся условиях (среде), то есть модернизацию, позволяющую вносить изменения в эксплуатационную среду программного средства. Данные изменения должны быть внесены для сохранения работоспособности продукта в изменяемой среде. Например, операционная система может быть модернизирована и некоторые изменения должны быть внесены в продукт для его адаптации к новой операционной системе (п. 4.1).

1.3. Профилактика и устранение сбоев в работе пользовательских экземпляров.

• ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [5].

Сопровождение может предполагать реактивное изменение программного продукта, выполняемое после его поставки для корректировки обнаруженных проблем (несоответствий, ошибок). Подобные изменения исправляют программный продукт для того, чтобы он соответствовал установленным требованиям (п. 4.3).

Также в рамках сопровождения возможна профилактическая модификация программного продукта после поставки в целях обнаружения и корректировки имеющихся в нем скрытых ошибок для предотвращения явного проявления этих ошибок при эксплуатации данного продукта (п. 4.11).

1.4. Прочие, обычно индивидуально обусловленные операции.

Стороны могут договориться о ряде иных необходимых клиенту операций по поддержанию ПО и БД в требуемом состоянии и облегчению работы с ним. Например, по улучшению дизайна, по корректному выводу из эксплуатации, созданию резервных копий и т.д. Приведем пример.

• Приложение № 6 к Приказу Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П [6].

Сопровождение ПО и БД включает мероприятия по анализу качества, устранению выявленных ошибок, внесению изменений в ПО и документацию, извещение пользователей об изменениях, хранение образов установочных дисков используемого ПО (п. 6.2).

2. Расширенный тип сопровождения — дополнительная доработка (модификация) ПО и БД.

2.1. Модификация эталонных ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры.

• ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [7].

Сопровождение может предусматривать модификацию программного продукта после поставки для повышения его рабочих характеристик, и тогда оно обеспечивает модернизацию (усовершенствование) продукта в интересах пользователя, уточнение соответствующих программных документов и его перепрограммирование для улучшения рабочих характеристик, сопровождаемости и других атрибутов программного средства (п. 4.10).

• ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [8].

Результат успешного сопровождения ПО и БД, в частности, предусматривает (п. 6.4.10.2):

• разработку и тестирование модифицированных продуктов;
• помещение обновленных продуктов в среду заказчика.

2.2. Модификация эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры.

• Решение УФАС по Владимирской области от 27.06.2018 N К-1009-02/2017 [9].

В рамках антимонопольного дела процитирована конкурсная документация заказчика по аукциону на право сопровождения программного продукта, а именно: сопровождение — процесс поддержания работоспособности, а также улучшения, оптимизации и устранения дефектов существующей системы; в ходе сопровождения в систему вносятся изменения, с тем чтобы исправить обнаруженные в процессе использования дефекты и недоработки.

Состав работ по сопровождению ПО и БД в различных схемах обслуживания и контрактах

Как видим, ни закон, ни указанные выше официальные документы не определяют жесткого перечня операций по сопровождению ПО и БД. Причем, как уже было указано, в большинстве случаев в договоры включаются только некоторые элементы сопровождения, интересующие заказчика в контексте специфики имеющегося продукта, собственных сервисных ресурсов, опыта и т. п.

Законодательство также не лишает стороны договора возможности разбить весь комплекс операций (услуг и работ) по сопровождению ПО и БД на несколько «учетных единиц», т.е. товарных позиций, в отношении каждой из которых будут действовать различные договорно-правовые режимы и цены. Например, такая разбивка распространена при расширенном сопровождении, включающем модификацию ПО и БД, когда действия по его доработке (улучшению и/или индивидуализации функционала, созданию новых или расширению имеющихся БД и т.п.) выделяются в отдельную товарную позицию или даже в отдельный договор. Это бывает оправдано, ведь модификацией произведения признается его переработкой и имеет особый правовой режим, требующий согласования с разработчиком (пп. 9 п. 2 ст. 1270 ГК РФ) [10]. Но с другой стороны, в ряде случаев сопровождение ПО и БД сводится к минимальной техподдержке их работоспособности в той или иной форме при различных сбоях, и тогда товарная позиция по договору является узкой и монолитной.

Особенности сопровождения ПО и БД очень сильно зависят от свойств, которые приданы им разработчиком, и от тех правовых и маркетинговых политик, которые практикуются последним. Так, некоторые продукты существуют в свободном для использования онлайн-доступе без каких-либо требований к сопровождающим лицам, тогда как другие распространяются только через сертифицированные организации (дилеров, дистрибьюторов), наделенных специальными инструментами для сопровождения ПО и БД и/или предоставления легального доступа. В последнем случае состав операций по сопровождению ПО и БД также может быть распределен между разработчиком и дистрибьюторами самым различным образом. Частый случай: к деятельности разработчика по сопровождению ПО и БД относятся в основном модификация и обновление эталонного продукта в целях его развития (придание новых свойств, совершенствование функциональности), а к деятельности дистрибьюторов — более широкий спектр операций, исключая саму модификацию.

Можно привести следующие примеры из практики. Пример «широкого» содержания сопровождения ПО и БД — Приложение 4 к Письму Комитета финансов Санкт-Петербурга от 30.11.2010 N 01-02/3067 о финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 г. Согласно данному документу работы и услуги по сопровождению программных продуктов включают:

1. Модификацию макетов программных продуктов, используемых для автоматизированного ведения бюджетного учета.
2. Оказание консультационных услуг на рабочем месте пользователя.
3. Восстановление работоспособности модулей программных продуктов автоматизированного ведения бюджетного учета «1С» и «Парус».
4. Обучение пользователей ведению бюджетного учета с использованием программных продуктов.
5. Установка программных продуктов… на дополнительные рабочие места, установка дополнительных модулей программных продуктов.
6. Выгрузка и загрузка данных для децентрализованных бюджетных учреждений.
7. Выгрузка и загрузка данных для централизующихся бюджетных учреждений.
8. Установка новых релизов, редакций, конфигураций.
9. Обновление первичных документов и отчетных форм.

Надо сказать, что процитированный документ содержит подробную расшифровку почти каждого пункта описания работ и услуг, составляющих сопровождение. Так что границы его оказываются очень обширными, включая в себя десятки различных операций (установки, выгрузки, диагностика, коррекция, настройки, различные виды обучения и т.д.) [11].

Пример «узкого» содержания сопровождения ПО и БД — Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В рамках судебного спора процитировано положение заключенного между участниками спора договора: «…Исполнитель обязуется оказать услуги по сопровождению прикладного программного обеспечения в объеме одного отчета для одного пользователя. Сопровождение — процесс улучшения (не ведущий к трудозатратам, более описанных в Приложении N 1), оптимизации и устранения дефектов прикладного ПО после передачи в эксплуатацию, обеспечение полноценной функциональности прикладного ПО, консультации пользователей» [12].

Заключение

В настоящей статье рассмотрены правовые и практические аспекты понятия «сопровождение программного обеспечения (программ для ЭВМ и баз данных)».

Данное понятие не регулируется в федеральном законодательстве.

На практике и в подзаконных актах к сопровождению ПО и БД относится обширный комплекс различных операций, которые можно сгруппировать в несколько направлений. Очень важно, что данный комплекс не является универсальным, неизменным и обязательным, а регулируется договорами между заказчиками и исполнителями. В ряде случаев в составе сопровождения проводится модификация ПО и БД, которая требует урегулирования вопроса прав на модифицированный продукт.

Наконец, учитывая стремительный темп развития информационных технологий, само понятие сопровождения ПО следует охарактеризовать как достаточно динамичное и отражающее самые различные тренды и перспективы.

1. Постановление Правительства РФ от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» // Собрание законодательства Российской Федерации, 2017, № 14, ст. 2062.
2. Приказ Казначейства России от 10.10.2018 N 37н «Об утверждении формы и порядка представления информации о потребности в осуществлении централизованных закупок программного обеспечения для ведения бюджетного учета и формирования потребности для осуществления централизованных закупок программного обеспечения для ведения бюджетного учета» // Официальный интернет-портал правовой информации http://www.pravo.gov.ru, 25.12.2018.
3. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
4. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
5. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
6. Приказ Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П «Об утверждении нормативных документов филиала федерального государственного бюджетного учреждения «Федеральная кадастровая палата Федеральной службы государственной регистрации, кадастра и картографии» по Москве в сфере информационных технологий».
7. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
8. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
9. Решение Управления Федеральной антимонопольной службы по Владимирской области от 27.06.2018 N К-1009-02/2017.
10. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ // Российская газета, № 289, 22.12.2006.
11. Письмо Комитета финансов Правительства Санкт-Петербурга от 30.11.2010 N 01-02/3067 «О финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 году».
12. Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В этой статье рассмотрим отдел сопровождения франчайзи (далее – партнеров) в том виде, в котором он должен быть. Будет рассмотрен только тот бизнес, который продает франшизы всем подряд, а не выбирает партнеров тщательно.

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

Возможно, я соглашусь с этим утверждением, за исключением «основной прибыли».

По теме: Готов ли ваш бизнес к созданию франшизы?

За время работы я не раз сталкивался с проблемой сопровождения партнеров. Каждый третий руководитель скажет, что отдел сопровождения – это документальный отдел, который постоянно отвечает на вопросы партнеров, и от них больше ничего не требуется.

Факты:

1. Отдел сопровождения может приносить прибыль. За счет роялти-платежей ежемесячная прибыль компании растет.
2. Отдел сопровождения прямо пропорционально влияет на количество продаж.
   Если партнеры зарабатывают, то их количество увеличивается. И наоборот, если не зарабатывают, то вероятность хороших продаж франшиз близка к нулю.
3. Дальнейшие развитие компании зависит от отдела сопровождения.
   Грамотное управление всей сетью для эффективного функционирования  партнеров.

По теме: Причина, по которой ваш бизнес не будет постоянно расти

Команда

Команда строится под определенный вид бизнеса, но, как минимум, в отделе сопровождения должны быть два специалиста:

• Руководитель отдела;
• Менеджер по сопровождению.

Дополнительно:

• Менеджер по закупке;
• Менеджер по согласованию;
• Менеджер по маркетингу;
• HR-менеджер;
• И другие.

Главное – чтобы в отделе работали талантливые умы, которые могут решить задачу в короткие сроки, без потери качества. И помните: у каждого сотрудника есть своя зона ответственности.

Еще команда должна обладать свойством многозадачности. Это свойство в совокупности с компетенциями дает взрывной рост!

Взаимодействие партнера с управляющей компанией (УК)

Приобретая нового партнера, важно ознакомить его с имеющейся информацией по открытию своего бизнеса. Обычно в состав франчайзингового пакета входит:

• план работы;
• инструкции по открытию ИП или ООО;
• консультация по налогообложению;
• бренд-бук;
• сертификаты (на товары);
• маркетинг;
• договоры (трудовые, аренды, поставки и прочее);
• инструкции (подбор персонала, открытия и прочее);
• рекомендации по помещению;
• список оборудования;
• скрипты по переговорам;
• анкеты и прочие документы.

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

Рекомендую хранить франчайзинговый пакет в Google Docs. Настройки доступа легко редактируются, также можно заменить или дополнить файл. Информация у всех партнеров обновится мгновенно.

Также будет здорово, если вы запишете видеоинструкции, разбив их на короткие ролики, по 4-5 минут каждый. Видео должно быть снято на профессиональное оборудование. Для наглядности можно сделать видео с инфографикой.

Тематика видеоинструкции. Пример:

• Приветствие;
• Подбор персонала;
• Как закупать товар;
• Отличие товара А от Б;
• Пошаговое открытие точки продажи.

Исходя из моего любимого правила Парето, могу с уверенностью сказать, что вы как УК предоставляете партнерам 80% информации. За партнером остается 20% действий – применение теории в практике. Естественно, под чутким контролем менеджера по сопровождению.

Пример из моей практики. Партнер просил сделать рекламу в его городе за счет средств УК. Опираясь на то, что он и так заплатил паушальный взнос и мы должны рекламировать его бизнес. Мы постарались максимально вежливо донести информацию о том, что есть понятие «маркетинговые отчисления», которые у нас отсутствуют, и инвестиции в рекламный бюджет остаются за самим партнером.

Приведу аналогичный пример с банковской системой. Клиенты выбрали банк, заплатили за открытие расчетного счета, подключение клиент-банка, заверение карточки с образцами подписей и оттиском печати. Также клиент ежемесячно вносит абонентскую плату за ведение расчетного счета.

Все эти платежи клиенты воспринимают как должное и никто не говорит, что у него нет денег, или – что у него в этом месяце не было движения по счету и т.д.

Так в чем же трудность – ежемесячно платить роялти? Ведь роялти платится за право пользование брендом, за консультации, поддержку, маркетинговые акции.

Еще одним важным документом является регламент.

Примеры из практики.

Внутренний регламент. Работая в туристической компании, у которой было более 90 партнеров, я разработал внутренний регламент, один из пунктов которого гласил: все ответы на вопросы партнеров будут обработаны в течение трех часов с момента отправки вопроса. Менеджер по сопровождению очень разгрузился, и учитывая то, что все вопросы поступали на электронную почту, менеджер начал выполнять свою работу с показателем ответов на полученные письма в 100% случаев. Это удобно для нас и для партнеров. Ситуация win-win.

Также решились дела со «сломанным телефоном». Все вопросы и ответы можно легко отследить через почту менеджера.

Регламент для партнеров. Работая в компании, где была товарная франшиза, мы как УК меняли в одностороннем порядке поставщика товара, т.к. цены у нового поставщика были «вкуснее». Следовательно, это было также выгодно для всех: для партнеров, для поставщика, для нас – чисто морально

Общение с партнерами

С партнерами нужно быть настороже. Любые слова могут быть интерпретированы ими в удобной форме. Зачастую – в обратную сторону от сказанного. Поэтому я стараюсь выстроить работу с партнерами письменно, во избежание недопонимания.

При общении с партнерами я как руководитель отдела часто использую метод «кнута». Метод «пряника» больше подходит менеджеру по сопровождению, который общается с партнерами каждый день.

Почему «кнут»? Потому что в обязанности руководителя отдела входят такие задачи как решение конфликтных ситуаций, ведение претензионной работы, соблюдение стандартов УК, сбор роялти-платежей. Иногда партнеры бывают неправы, и нужно уметь грамотно донести до них информацию. Конечно, в случаях, когда виновата УК, нужно общаться мягко и доброжелательно. Но исход должен быть один: решение вопроса в короткие сроки.

Партнеры – это лицо вашей компании в разных городах. Они должны оказывать соответствующий сервис, дизайн должен быть выполнен в том же стиле, что и у УК. Для этого должна быть четко и понятно расписана последовательность действий, предоставлены промо-материалы и различные инструкции. Оказывайте хороший сервис, чтобы у партнера не было мысли о смене названия компании и работы под своим брендом. Сделайте так, чтобы партнер был лоялен к вам. Тогда не будет проблем с оплатой роялти.

Процессы внутри УК

Пример. Сотрудники отдела сопровождения чем-то занимаются, что-то делают, что-то пишут, но работы не видно. Нет результата их действий, но работа идет постоянно. В одной компании, где я проработал чуть более месяца, директор сказал мне, мол, Руслан, работа у тебя автоматизирована (я вкалывал по 10-12 часов в день), и мы можем посадить на твое место специалиста подешевле. Я подумал, что это странное решение, т.к. чтобы полностью оптимизировать этот отдел, работы предстоит еще очень много. Но руководство не видело «кипящей» жизни отдела и всех подводных камней. После моего ухода мне еще около недели писали-звонили с вопросами, как сделать что-либо. Как итог, при общении с партнерами руководитель компании весь негатив по недоработкам «скинул» на меня и тем самым занял выгодную позицию перед партнерами.

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

Различие клиентов и партнеров

Руководители компании хотят, чтобы с партнерами через позитив и слаженную работу выстраивались теплые отношения. Это 80% успеха бизнеса! 20% – это закручивание гаек в работе с партнерами через, к сожалению, жесткость.

Давайте рассмотрим это подробнее на примере банковской системы, где дополнительные офисы будут выступать в лице партнеров.

Допустим, у банка есть 20 дополнительных офисов. У всех офисов должен быть единый стандарт обслуживания, оформление, фирменная одежда, реклама, бейджи, режим работы, вывеска, тарифы и прочее – все должно быть выполнено в едином стиле. И ни один из офисов не вносит свои правила в работу банка.

По теме: Как мы выстраивали продажи, маркетинг и работу с партнерами

Так почему же УК не могут добиться такого же уровня обслуживания от своих партнеров? Почему партнеры просят изменить розничные цены для клиентов, проводить мероприятия, выбиваясь из общего маркетингового графика, не надевать фирменные футболки, не носить бейджи, не принимать единые дисконтные карты сети и сертификаты, выданные другими партнерами? И многое, многое другое.

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

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

Что такое вообще сопровождение сотрудника в процессе выполнения поставленной задачи?

Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.

Вообще изначально, я хотел написать другую статью, на тему «Как правильно сопровождать сотрудника во время выполнения задачи», но я понял, что перед этим важно написать о принципах, которые будут лежать в основе моих методов сопровождения.

Сопровождение, если говорить формально

Если говорить формально, то сопровождение сотрудника представляет собой процесс поддержки и руководства сотрудника по выполнению поставленной задачи. Оно может включать в себя инструкции, обучение, обратную связь, мониторинг, советы и другие методы, которые помогут сотруднику достичь нужного результата. Цель сопровождения сотрудника заключается в том, чтобы помочь сотруднику как овладеть навыками, умениями и знаниями, необходимыми для выполнения поставленных задач, так и для выполнения сотрудником его личных планов. С другой стороны, целями бизнеса в сопровождении являются укрепление коллектива, выстраивание мотивации сотрудника вместе с мотивацией фирмы, достижение ожидаемых результатов, обеспечение качества результатов. Получается, если работа приобретает образ тандема, то обе стороны от этого только выигрывают.

Моё понимание

Если уже говорить про моё понимание, то для меня, сопровождение сотрудника в процессе выполнения поставленной задачи означает проверку и предоставление поддержки в ходе выполнения поставленных задач. Я вижу это как неотъемлемую часть процесса управления проектами. Моя задача как руководителя ИТ проекта включает в себя отслеживание прогресса выполнения задач сотрудниками и предоставление необходимой им поддержки. Я уверен, что правильное сопровождение помогает сотрудникам работать более эффективно и успешно выполнять поставленные задачи.

Выстраивание основ взаимодействия

Несколько подходов, которые я сам использую, чтобы помочь сотруднику выполнить задачу.

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

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

Возвращаясь к теме. Дальше, я считаю, когда мы выстроили хорошую коммуникацию, я могу начать работать над качеством. Вот несколько примеров:

1. Если человек занимается разработкой, то идти ко мне не всегда будет хорошим вариантом, да я понимаю какие‑то вещи из разработки, но лучше всего в этой ситуации сможет помочь другое экспертное мнение из той же области, например мидл и мидл или мидл и сеньор и тд.

2. Может ли человек без обращения к кому‑либо, сначала решить самостоятельно свой вопрос? Да, и для этого существует такое понятие, как документация проекта или база знаний по проекту. Если это касается требований клиента или вопросов по технической части, то я стараюсь создать на проекте перечень документов, которые описывают хотя бы самые важные аспекты проекта, как с точки зрения бизнеса, так с точки зрения разработчиков. Это требует несколько десятков человекочасов, однако, как я решил для себя, оно явно того стоит. Единая база знаний вообще очень нужная вещь, которая улучшает понимание и осознанность людей в том, что они делают.

3. Ещё одним подходом для повышения качества сопровождения сотрудника будут 1on1 митинги. Я стараюсь проводить их не реже(и чаще тоже не стоит) чем раз в 2–3 недели. На них мы обсуждаем, как я мог бы улучшить условия для сотрудника, чтобы он мог меньше отвлекаться на факторы, которые будут его только отвлекать от задач. К примеру, если постоянно падает инфраструктура, нет чётких требования от заказчика, смена приоритизации задач и тд.

4. Ещё одним подходом, но он достаточно косвенный, я бы назвал совпадение рабочих принципов. Мне намного проще дать человеку то, что я сам понимаю зачем ему что‑то требуется.

Я не говорю о ситуациях, когда человек со временем начинает постоянно надеяться на то, что за него всё сделают, или, когда исполнитель, в случае провала задачи, начинает оправдываться, что ему неправильно подсказали(решения по выполнению задания всё равно принимает он, а не тот, кто ему помогал). Темы про перекладывание ответственности или про превращение кого-то из членов команды в помогайку требуют дополнительных статей.

Трудности в достижении

Теперь к практике. То что я описываю, на бумаге может звучать здорово, но ведь на практике все может быть совсем иначе.

Приведу в пример ситуацию из своего опыта. Заранее скажу, что с разработчиком Александр, о котором пойдёт дальше речь, были проработаны вышеописанные пункты — мы совпадали в большинстве рабочих принципов, он умел говорить о своих проблемах, умел просить о помощи. У нас также была документация по проекту.

Ситуация “Как быть если никто не может помочь?”

На одном из последних мест работы, мы строили пайплайн по работе с моделями машинного обучения, используя достаточно свежий фреймворк Ray, у которого ко всему прочему была несовместимость между его версиями(что в последствие и сыграло роль в решении задачи).

На тот момент, по какой‑то причине, команде не удавалось создавать подпроцессы(в библиотеке они называются workers или actors) для конкретных пайплайнов обработки данных. Разработчик Александр чётко следовал гайдам из документации, но у него не получалось.

Сначала это выражалось в том, что на череде daily standup единственным блокером в задаче была именно эта проблема. Мы начали с самых простых вариантов — задачи на более глубокое изучение библиотеки, задачи на изучение сторонних гайдов на конкретных кейсах(не те, которые «Create your own pipelines in 10 minutes», а которые глубже изучают вопрос). Затем, я начал подключать других разработчиков, но это также не давало результат.

Так, уже над всей командой висел большой блокер, который тормозил в целом проект, из‑за того, что задача настройки пайплайнов была одной из ключевых. На тот момент, мы уже потратили на задачу около 4 спринтов. Позднее, решение было всё‑таки найдено, и оно было донельзя банальным — несовместимость версий: на кластере оператор был одной версии, а actors создавались на основе библиотеки другой версии. После решения, мы двинулись дальше по проекту.

Было ли за это что‑нибудь разработку? Нет, мы просто учли этот опыт в будущем.

Предвидя вопросы «Почему мы не стали использовать другой фреймворк?» или «Почему мы сами не написали конкретно требуемый функционал?». Тогда мне казалось, что это может потребовать больших ресурсов, ведь решение вот‑вот будет найдено.

Хоть статья и не об этом, но что я мог бы сделать тогда иначе?

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

2. Заранее предвидеть риск использования нового для нас фреймворка, как итог, указать больше времени на выполнение проекта.

Вместе с этим, решая такой «сложный» блокер, мы получили и ряд положительных моментов:

• команда сплотилась, решая одну проблему;

• мы смогли проверить навыки нашей коммуникации;

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

В общем, помимо одного большого минуса в виде задержки сроков, мы получили много плюсов. Если бы, к примеру, наш разработчик стал бы в закрытую пытаться решить проблему, решение могло бы затянуться на ещё более длительный срок.

Вывод по статье

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

Если интересно больше узнать про мои подходы, у меня есть небольшой телеграм канал, где я выкладываюсь чаще, чем на хабре.

На этом у меня все. Буду рад обратной связи!