1. Введение Настоящий документ описывает процессы, обеспечивающие поддержание жизненного цикла ПО «Microboard, Белая доска», включая регламент технической поддержки.
2. Жизненный цикл программного обеспечения, включая информацию о совершенствовании ПОПО «Microboard, Белая доска» может быть поставлено заказчику двумя способами:
- Облачное решение — ПО «Microboard, Белая доска» и его данные размещаются на серверах компании ООО «ТАЙМВЭБ». При поставке решения заказчику производится первоначальная настройка ПО, после которой заказчику предоставляются учетные записи для доступа к облачному сервису.
- Серверное решение — заказчику предоставляются инструкция и ПО для установки ПО
- «Microboard, Белая доска» на локальных серверах заказчика.
Для контроля версий ПО
«Microboard, Белая доска» каждый релиз имеет свой номер:
- Для стабильных версий принято обозначение вида «X.Y», где X и Y — номер версии и ее сборка.
- Для версий с незначительными обновлениями или срочными исправлениям принято обозначение вида «X.Y.Z», где X и Y — номер и сборка стабильной версии, а Z — номер обновления для указанной стабильной версии.
Выпуск стабильных версий производится с периодичностью раз в две недели.
Информация о совершенствовании ПОПО «Microboard, Белая доска» постоянно обновляется с целью внедрения новых функций, улучшения производительности и повышения удобства использования. Данные обновления охватывают широкий спектр аспектов — от исправления ошибок до расширения функционала, улучшения интерфейса и оптимизации работы с интеграциями. Каждый цикл обновлений тщательно прорабатывается, чтобы платформа соответствовала современным требованиям пользователей и оставалась конкурентоспособной на рынке.
Обновления и новые функцииРазработка новых функций основывается на активном взаимодействии с пользователями и глубоком анализе тенденций на рынке. Исследования и опросы позволяют выяснить, какие инструменты и функции наиболее востребованы среди пользователей. Опираясь на полученные данные, команда разработчиков формирует план обновлений, включающий наиболее актуальные для пользователей улучшения и новшества.
Каждая новая функция проходит этап тестирования и валидации, что гарантирует ее стабильную работу и отсутствие критических ошибок. Этот важный процесс включает как внутренние тесты, так и бета-тестирование с привлечением групп пользователей, что позволяет выявить возможные недочеты и учесть мнения конечных пользователей до официального релиза.
После завершения всех тестов новые функции и исправления включаются в регулярные обновления системы. Это позволяет не только расширять возможности работы с доской, но и предоставлять пользователям более эффективные инструменты для управления проектами. Например, улучшения в функционале могут включать добавление новых шаблонов для визуализации идей, расширение инструментов совместной работы в реальном времени и оптимизацию интеграций с другими сервисами.
Этот систематический подход к разработке и внедрению обновлений обеспечивает постоянное улучшение продукта. Microboard адаптируется к меняющимся потребностям пользователей, оставаясь при этом надежным и стабильным инструментом для работы. Каждый этап процесса совершенствования фокусируется на создании более удобного и эффективного решения, что положительно сказывается на общей удовлетворенности пользователей и позволяет Microboard занимать уверенные позиции на рынке.
Информация об устранении неисправностей в ходе эксплуатации ПОВ процессе эксплуатации программного обеспечения «Microboard, Белая доска» могут возникать технические сбои или неисправности, которые могут затруднять работу пользователей. Чтобы обеспечить бесперебойную работу платформы и быстро реагировать на возникающие проблемы, применяется система управления инцидентами. Этот процесс включает в себя несколько ключевых этапов, обеспечивающих эффективное выявление и устранение неполадок.
Сбор отчетов об ошибкахПервая стадия процесса устранения неисправностей включает в себя сбор и регистрацию отчетов об ошибках. Пользователи могут сообщать о проблемах через встроенные механизмы обратной связи, такие как формы отчета или поддержку пользователей. Эти сообщения фиксируются в системе и классифицируются по типу и степени серьезности.
Анализ инцидентовПосле регистрации инцидентов команда технической поддержки и разработчиков проводит анализ собранных отчетов. Этот этап включает в себя детальную проверку условий, при которых возникла проблема, а также воспроизведение сбоев в тестовой среде. Такой подход помогает определить корневую причину неисправности, что является ключевым для нахождения оптимального решения.
Приоретизация ошибокВ рамках системы управления инцидентами ошибки классифицируются по уровням приоритета. Критическим считаются те неисправности, которые существенно влияют на стабильность системы и могут нарушить работу пользователей (например, системные сбои или утечка данных). Эти ошибки обрабатываются в первую очередь, что позволяет минимизировать время простоя и последствия для пользователей.
Оперативное исправлениеПосле выявления критических проблем команда разработчиков немедленно приступает к их исправлению. Это может быть реализовано через создание и выпуск регулярных патчей и обновлений, которые внедряются в систему в кратчайшие сроки. В процессе работы над исправлениями учитываются не только сами ошибки, но и возможное влияние изменений на остальные функциональные элементы ПО.
Информирование пользователейПо мере работы над исправлением ошибок пользователи информируются о ходе выполнения и статусе инцидентов. После завершения работ они получают обновления о том, какие проблемы были устранены и какие изменения были внедрены. Это важно для поддержания доверия пользователей к платформе.
Обратная связь и улучшение процессаПосле устранения неисправностей собранные отчеты и проведенные мероприятия анализируются для дальнейшего улучшения процесса управления инцидентами. Важным аспектом здесь является получение и учет обратной связи от пользователей, что позволяет совершенствовать систему и предотвращать возникновение аналогичных проблем в будущем.
В итоге, процесс устранения неисправностей ПО «Microboard, Белая доска» направлен на обеспечение высокой надежности и стабильности платформы, что является приоритетом в работе команды поддержки и разработки. Постоянный мониторинг, анализ инцидентов и оперативные меры по их устранению способствуют созданию положительного пользовательского опыта и повышению общего уровня удовлетворенности клиентов.
3. Типовой регламент технической поддержки 3.1 Условия предоставления услуг технической поддержки Услуги поддержки предоставляются каждому клиенту в соответствии с условиями выбранного пакета программного обеспечения. Запросы, связанные с проблемами, препятствующими нормальной работе клиента в ПО, обрабатываются в приоритетном порядке. 3.2 Каналы доставки запросов в техническую поддержкуЗаказчики могут регистрировать запросы на техническую поддержку через электронную почту
info@microboard.ru, по телефону +7(495)021-08-33 или используя форму обратной связи на сайте microboard.ru.
3.3 Выполнение запросов на техническую поддержкуЗапросы на техническую поддержку обрабатываются в установленном порядке. После регистрации заявки сотрудники службы поддержки проверяют ее и начинают работу над решением проблемы. Пользователь получает уведомление о статусе заявки и окончательном решении. Для ускорения процесса рекомендуется указать:
- ссылку на доску, где произошла проблема
- приложить скриншот экрана
- предоставить технические детали.
Чем полнее будут данные, тем быстрее сотрудники службы поддержки смогут помочь.
3.4 Порядок выполнения работ по оказанию технической поддержкиКаждый запрос в службу технической поддержки обрабатывается следующим образом:
- Запросу присваивается уникальный идентификатор, назначаются ответственные исполнители и устанавливается его приоритет.
- Обработка и выполнение зарегистрированного запроса выполняются в соответствии с установленными приоритетами.
- Исполнитель предлагает заказчику варианты решений возникшей проблемы, основываясь на содержании запроса.
- Заказчик должен следовать всем рекомендациям и предоставлять необходимую дополнительную информацию для своевременного решения вопроса.
3.5 Закрытие запросов в техническую поддержкуПосле предоставления ответа запрос считается завершенным и остается в этом состоянии до тех пор, пока заказчик не подтвердит разрешение инцидента. Если заказчик не согласен с закрытием запроса, его исполнение продолжается. Запрос переходит в статус закрытого только после получения согласия заказчика. Если в течение 5 рабочих дней ответа не поступает, запрос автоматически считается закрытым. Заказчик также может инициировать закрытие запроса, если необходимость в ответе исчезает.
3.6 Персонал для поддержания жизненного цикла3.6.1 Сотрудники и компетенции у правообладателя