Любая команда разработчиков при уходе от модели «waterfall» или любого другого традиционного стиля управления проектами сталкивается с одним и тем же вопросом «как мне структурировать свою работу?». К счастью метод разработки по методологии Agile использует четыре четких механизма для того, чтобы структурировать любой проект:
- Epic – массивный объем работ, который разделяется на задачи
- Story -наименьшая единица работы, еще называемая задачей
- Version – выпуск готового продукта
- Sprint – цикл, в котором работает команда
Работая с такими механизмами команды разработчиков могут организовать свою работу разбив ее на небольшие части, достаточные для того, чтобы отдавать предпочтение обратной связи с клиентом и отойти от привычного стиля управления проектами.
Способность изменять и адаптировать план разработки, на основании текущей информации является признаком гибкости. Мы определили 4 механизма, которые помогут сделать проект гибким, и покажем, как они применяются в аджайл на практике. Но сначала поговорим о разнице самих механизмов.
Лучший ролик о Сжигании Жира| Весь механизм за 5 Минут
Epic vs Story
Эпики – наиболее крупные объекты, представляющие собой множества задач. Эпики могут охватывать несколько спринтов и версий. В отличие от эпиков версии исчисляются релизами программного обеспечения, и при необходимости могут включать в себя несколько эпиков. Эпики помогают команде создавать иерархию и структуру, в то время как истории – отслеживать конкретные детали задачи, и могут быть разбиты на подзадачи.
Эпики обычно сводятся к более стратегическим целям или инициативам. Эти инициативы обычно разрабатываются в процессе долгосрочного планирования и формирования стратегии развития.
Что такое эпик?
Эпик — это большой объем работы, который можно разбить на несколько небольших задач. Например, исследование производительности релиза. Эпик может охватывать более одного проекта, если несколько проектов включены в доску, к которой принадлежит эпик.
В зависимости от того какую структуру agile Вы используете (scrum, kanban или Ваш собственный выбор) эпики могут использоваться по разному. Для канбана эпики могут использоваться в качестве направляющих для сегментации различных потоков работ. Если вы используете скрум, эпики могут помочь обозначить работу в Ваших спринтах, как в примере ниже.
Миссия на Марс — это эпик в этом спринте. TIS 1, TIS 2 и т.д.. — все задачи в спринте (TIS Sprint 1). Вы должны заметить, что в спринте есть как задачи (истории) так и эпики.
Оценка эпиков.
Диаграммы Burndown также используются для визуализации эпиков, которые поддерживают мотивацию команды и информируют о продвижении работ все заинтересованные стороны.
Такая диаграмма наглядно показывает характер развития agile. На ней можно наблюдать как идет процесс работы команды, а также когда заказчик добавил или удалил задачи. Такое прозрачное отображение данных позволяет любому участнику проекта оценить прогнозы развития, упрощает диалог с заказчиком и доверительные отношения на всех уровнях.
Что такое задача?
Задача (история или рассказ пользователя)– наименьшая единица работы в agile структуре. Это требование к программному обеспечению, которое выражается в нескольких коротких предложениях, в идеале использующих нетехнический язык.
Цель пользовательской истории — вернуть конкретное состояние заказчику. Обратите внимание, что «заказчик» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними заказчиками или коллегами в Вашей компании, которые зависят от Вашей команды.
Истории пользователей (задачи) — это несколько предложений на простом языке, которые описывают желаемый результат. Они не вникают в подробные требования.
Пример задачи – рассказа пользователя.
Истории пользователей нарисованы владельцем продукта, а затем команда разработчиков коллективно решает более подробные требования. Задачи — это гранулированные работы, которые помогают определить элементы реализации и предстоящего спринта.
Используя тот же пример, что и выше, задачи в этом спринте имеют оценку, приоритет, правопреемник, эпичность и описание, поэтому каждый может получить быстрый обзор выполняемой работы.
Что такое версия?
Версии — это фактические выпуски программного обеспечения для потребителя. Помните, что в конце каждого спринта команда должна иметь возможность отправлять программное обеспечение заказчику. Версии — это контролируемые изменения, которые владелец продукта действительно получает.
Версии часто развиваются по множеству спринтов, как эпики. Эпик также не должен полностью «дублировать» версию. Продуманные владельцы продуктов могут растягивать эпик на несколько версий. Представляя эпик в нескольких версиях, владелец продукта может узнать, как рынок реагирует на этот эпик и принимает решения о дальнейшем развитии продукта, а не делает один гигантский релиз.
Пример использования версий
Владелец продукта может структурировать стратегию выпуска версий ПО следующим образом:
- Версия 1: логин, выход из системы, управление паролями
- Версия 2: история покупок
- Версия 3: сохранение настроек
- и т.д.
Область изменения версии также является естественной частью развития проекта по методу agile. Графики Burndown наглядно показывают, как версия эволюционирует с течением времени. Изменения в версии должны обсуждаться со всей командой, чтобы держать всех в курсе дела.
Что такое спринт?
Спринт — это короткий период, в течение которого команда разработчиков реализует и обеспечивает дискретное и потенциально увеличиваемое приращение приложения, например. рабочая версия. Если Вы еще не имели практики работы со спринтами, мы рекомендуем использовать фиксированную двухнедельную продолжительность для каждого спринта. Этого промежутка времени достаточно для того, чтобы добиться чего-то, но не так много, чтобы испытывать нехватку отзывов потребителей.
Спринты являются частью структуры scrum. Команды kanban, напротив, работают над следующей задачей по мере возможности ее решения. В этом случае прогнозирование не требуется.
Scrum команды фиксируют набор задач в течение фиксированного периода времени. Теоретически, спринты могут длиться одну, две или четыре недели. Длина спринта определяется командой, которая работает над проектом. После определения частоты спринтов команда постоянно работает в этом ритме.
Спринты с фиксированной длиной увеличивают точность оценки сроков работы и позволяют прогнозировать будущую скорость для команды в аджайл проекте. Делать выводы можно, как только будут получены данные из нескольких завершенных спринтов.
Пример спринта Вы уже видели на скриншотах выше. TIS Sprint 1 – это множество задач.
Несколько вещей, которые вы должны знать о спринте:
- Как только команда фиксирует набор задач для спринта, а спринт запускается, мастер скрум запрещает изменение задач. Это заставляет команду сфокусироваться и не поддаться искушению добавить работу в спринт после его запуска. Добавление работы в середине спринта компрометирует способность команды точно прогнозировать и оценивать.
- В конце каждого спринта команда должна предоставить рабочую часть программного обеспечения. В scrum это называется потенциально прибыльным приращением (PSI). Владелец продукта в итоге решает, когда PSI перейдет в релиз. Но работа должна быть достаточно полной, чтобы быть подходящей для выпуска в конце спринта.
Отличным инструментом для любой команды scrum являются графики burndown. Они четко отслеживают прогресс на протяжении всего спринта с «оставшейся работой» по оси Y и «временем» на оси X. Диаграммы и графики Burndown являются мощным мотиватором для команды, и фокусируют каждого ее члена на работе над спринтом.
Масштабирование.
У более крупных организаций часто есть несколько команд agile, работающих над общим проектом, а планирование портфолио — ключевая часть работы agile в масштабе. Эпики и версии закладывают основу для надежного управления портфолио на уровне команды. Управление портфолио охватывает программы отслеживания в нескольких командах, сохраняя при этом тот же уровень гибкости на более высоких уровнях организации. Узнайте больше о гибкости в масштабе большой организации в разделе agile portfolio.
Наша компания предоставляет различные услуги по внедрению, оптимизации, переносу, обучению работы с продуктами jira, обращайтесь [email protected]
Источник: system-admins.ru
Как настроить Jira и начать жить?
Если Jira используют как некий блокнот , накидывая задачи как попало после чего проект превращается в свалку в беклоге с ужасным описанием (если оно вообще есть) — то настало время разобраться с этим…
Сразу оговорюсь, что для матерых атласЯнов тут ничего нового не будет. Углубляться в тонкости настройки каждого пункта я тоже не буду, а попробую коротко описать первый блок важных вещей, поняв и настроив который, можно сделать работу людей сильно удобнее.
1. Почему Jira?
Немного предыстории. Я успел поработать и не 2–3 месяца со всеми популярными системами управления проектов redmine , trello, basecamp, merlin (он же MS Project) и Jira.
Конечно у всех из них есть свои плюсы минусы, но за что мне понравилась именно jira:
- простой и удобный трекинг времени и отслеживание его в рамках проекта
- фильтрация и графики для мониторинга чего угодно
- огромная возможность кастомизации
- возможность детально разграничивать права доступа
- огромное количество интеграций , что позволяет автоматизировать различные шаги
- тонкая настройках воркфлоу с подсказками для тех, кто идет по нему , чтобы ничего не забывали делать.
Сразу оговорюсь, что я не считаю что другие системы плохи, я лишь постараюсь рассказать за что я люблю Jira , на примере одного Scrum проекта.
2. WorkFlow Scheme
Воркфлоу схемы позволяют для одного проекта в зависимости от типов задач задавать разные воркфлоу. Так например для Story задач нужен сложный ворклоу, проходящих через несколько отделов и разные проверки , а для RD — таск с простейшим воркфлоу , создан для упорядочивания работ (чтоб можно было планировать это время в спринт и соответственно трекать и отслеживать время)
3. Workflow
На основе правильно описанного воркфлоу в Jira и можно накрутить много чего полезного по автоматизации, а так же разграничить доски разных отделов и видимость задач.
Вот так например выглядит workflow для стори:
Левая часть диаграммы — это шаги дизайн отдела. В этом воркфлоу так же есть шаг, который избавляет разработчиков от проблем “не совсем готового к разработке” дизайна — шаг “in dev/test review” , на котором лиды отсматривают дизайн и обсуждают его с дизайн отделом, чтобы на момент взятия задачи в спринт все были уверены, что все реализуемо и готово к тому, чтобы брать задачу в спринт.
Правая часть — это шаги отдела разработки и тестирования. В нем так же есть 1 шаг для дизайнеров — “design review” на котором дизайнеры проверяют насколько разработчики постарались и сделали работу точно по макетам. Такой ворфлоу позволяет разделить доски отделов в рамках одного проекта так, чтобы дизайнеры не видели ни спринты , ни таски разработки и наоборот, что позволяет проще ориентироваться во всем многообразии задач (см. пункт 5).
4. Transitions
Транзишены обеспечивают переходы между статусами задач — это те кнопочки , которые видят ваши коллеги в Detail View любой задачи. В рамках транзишена я обычно отслеживаю:
- избыточность переходов. Важно re-use’ать одинаковые транзишены, т.к. тогда проще автоматизировать и настраивать процессы
- Screen. Это модальное окно, которое отображается при осуществлении транзишена. Это те самые подсказки, чтобы люди не забывали логать время / писать комментарий/ прикреплять что-то / линковать и т.д.
- Options. В этой части кроется много полезного для автоматизации процессов:
- Post functions — позволяют автоматизировать перевод задачи на нужного человека автоматически, очищать нужные поля, фиксировать какие-то данные и т.д. Советую внимательно изучить эти возможности.
- Triggers — позволяют обеспечить автоперевод задач в нужные статусы, интегрировав в Jira, GitHub/etc. Чаще всего ребята забывают перевести какой-то таск в работу, а так jira сама будет переводить “в работу” когда создастся ветка с указанным таском в тайтле.
В целом, в каждой из опций транзишена вы можете найти для себя полезные вещи, а так же много нового можно добавить туда , путем установки дополнений из маркетплэйса. Чуть подробней о дополнениях в п. 6.
5. Разграничение досок отделов
Отдельные статусы для задач в для разных отделов но с одним и тем же смыслом “in design progress” и “in progress” нужны для того, чтобы можно было разграничить доски для отделов.
Для этого создаете несколько досок. Далее в General настройках досок конфигурируете фильтр по котором работает доска. Ограничиваете статусы , находясь в которых задачи будут отображаться на доске. Например вот так:
Таким образом в одном и том же проекте у разных отделов видны только те задачи, которые нужны им для работы. Никаких лишних кнопок, тасков и сомнений а точно ли это задача к нам?
При этом если уже в спринте разработки задача попадает в статус “дизайн ревью” , то она появится на доске дизайнеров. Трудно не заметить что у тебя повилось что-то новое — обозначение спринта в котором находится эта задача и сам таск.
6. Atlassian marketplace и интеграции
Очень забавно, но есть много полезных дополнений, которые работают только на Jira , которая находится на вашем сервере, а не в облаке, но и для облачной Jira есть много крутых плагинов, которые делают работу приятнее и быстрее, например:
- Tempo Timesheets — трекеры времени, удобный timesheet репорт, аддон на рабочий стол Jira , все это можно получить благодаря темпо.
- Jira Misc Workflow Extensions — расширение, которое добавляет много полезных и нужных вещей в post functions транзишена. Облегчает автоматизацию workflow
- ScriptRunner for Jira — тут все очевидно JQL скрипты в транзишены, для более “глубокой” и не тривиальной автоматизации, если вдруг в предыдущем расширении не нашли того, что нужно.
- Portfolio — не хотите строить роадмап руками? Заведите правильно задачи в жира и портфолио сделает это за вас
И так далее, список на самом деле огромный, зайдите на https://marketplace.atlassian.com/ и посмотрите сами 🙂
Помимо прочего, есть итеграции со слаком, гитом , тэстрэйлом и кучей чего еще.
Эпилог
Безусловно, все эти инструменты не защищают от некачественной постановки задач, от того, что не пишут поясняющие комментарии, забывают трекать время или в целом не следяют за формализацией процесса. Это нужно воспитывать в команде самому, но на моей практике ни разу не было, чтоб всем было удобнее работать в хаосе, чем с точно и понятно описанными и распланированными задачами. И не важно какой у вас шаг планирования — неделя или пол года, и какой инструмент вы используете для работы.
Источник: medium.com
JIRA Service Desk
У вашей команды есть задачи. Ваши клиенты ожидают решения этих задач и ваш бизнес зависит от эффективности их решения.
JIRA Service Desk сочетает в себе интуитивно понятный пользовательский интерфейс с поддержкой SLA, настраиваемые очереди заявок и отчеты в режиме реального времени.
Вся производительность и мощность JIRA теперь в JIRA Service Desk.
Функции JIRA Service Desk
Внедрение JIRA Service Desk
Если вам нужна помощь, консультация по покупке или внедрению системы — обращайтесь к нам!
Перед внедрением системы мы рекомендуем посетить наши тренинги и вебинары по установке, настройке и администрированию приложения.
Подробнее о тренингах.
Понятный интерфейс
Просить о помощи легче, чем когда-либо с интуитивным и понятным интерфейсом JIRA Service Desk . Клиенты видят именно то, что нужно и не более того.
ИТ-специалисты получают возможность говорить на своем языке в JIRA, также как и клиенты получают возможность говорить на своем языке в JIRA Service Desk .
Интерактивные отчеты
С JIRA Service Desk вы можете оценить прогресс и производительность в режиме реального времени.
Если вы установите JIRA Service Desk сегодня, вы сможете применять метрики SLA задним числом на предыдущие закрытые задачи. На основе тенденций прошлого вы сможете повысить качество обслуживания клиентов вашей командой.
База знаний
Отвечайте на вопросы еще до того как они будут созданы в вашей системе. Мощные возможности поиска в Confluence интегрированы непосредственно в панель JIRA Service Desk так, что ваши клиенты смогут легко найти решения самостоятельно.
Превратите ваш Service Desk в самостоятельную службу поддержки с базой знаний Confluence.
Соглашение об уровне услуг (SLA)
Ваша команда будет обслуживать клиентов с уверенностью, зная, что SLA приоритеты видны для всех, кто работает над задачей.
Это очень важно — знать, что и когда должно быть сделано. Информация об SLA отображается как в очередях так и в задаче.
Управляемые очереди
Убедитесь, что все работают над правильными задачами и в нужное время с помощью очередей и языком выборки — JIRA Query Language (JQL). Очереди помогут вашей команде разделять и властвовать над задачами в режиме реального времени по мере их поступления.
Ручная сортировка и определение приоритета ваших запросов уходит в прошлое!
| Пользователей | Ваш сервер (1-й год) | Наш хостинг (на год) |
| 3 agents | $50 | $130 |
| 5 agents | $1,500 | $1,700 |
| 10 agents | $3,000 | $3,250 |
| 15 agents | $4,500 | $5,700 |
| 25 agents | $6,500 | $6,950 |
| 50 agents | $12,000 | $13,500 |
| 100 agents | $20,000 | $23,100 |
| 250 agents | $32,000 | $35,800 |
| 250+ agents | $45,000 | call |
| Пользователей | Обновление (1 год) |
| 3 agents | $10 |
| 5 agents | $825 |
| 10 agents | $1,650 |
| 15 agents | $2,475 |
| 25 agents | $3,575 |
| 50 agents | $6,600 |
| 100 agents | $11,000 |
| 250 agents | $17,600 |
| 250+ agents | $24,750 |
| на 5 agents | на 10 agents | на 15 agents | на 25 agents | на 50 agents | на 100 agents | на 250 agents | на 250+ agents | |
| с 3 agents | $1,500 | $3,000 | $4,500 | $6,500 | $12,000 | $20,000 | $32,000 | $45,000 |
| с 5 agents | $2,250 | $3,750 | $5,750 | $11,250 | $19,250 | $31,250 | $44,250 | |
| с 10 agents | $3,000 | $5,000 | $10,500 | $18,500 | $30,500 | $43,500 | ||
| с 15 agents | $4,250 | $9,750 | $17,750 | $29,750 | $42,750 | |||
| с 25 agents | $8,750 | $16,750 | $28,750 | $41,750 | ||||
| с 50 agents | $14,000 | $26,000 | $39,000 | |||||
| c 100 agents | $22,000 | $35,000 | ||||||
| c 250 agents | $29,000 |
Agent — это пользователь JIRA Service Desk, имеющий право использования интерфейсов ServiceDesk: управление очередями, отчетность и настройка плагина.
- указана стоимость за 1-й год использования продукта, без косвенных налогов
- в стоимость всех лицензий входит плагин локализации на русский язык.
- оплата лицензий осуществляется в рублях, по курсу «ЦБ РФ+1,5%» на день оплаты счёта
Anton Romm (Teamlead) размещен на ноя 26, 2013
Warning! You are viewing the old version of site.
После того как Atlassian представил свой новый продукт — JIRA Service Desk русскоязычные пользователи захотели работать с этим плагином на русском языке.
Рады вам представить русификацию JIRA Service Desk. Так же будем рады общению с вами в формате тренинга.
Oxana Alexeenko (Teamlead) размещен на окт 22, 2013
Warning! You are viewing the old version of site.
Недавно Atlassian представил свой новый продукт — JIRA Service Desk.
Плагин для создания Service Desk — решение востребованное на рынке, ведь практически каждая вторая компания использует Atlassian JIRA именно в таком ключе.
Суть плагина — в возможности реализовать Соглашение об уровне услуг (Service Level Agreement (SLA)). То есть вы заранее настраиваете приоритет и время реакции в зависимости от запроса и знаете, что сотрудники поддержки работают над правильными задачами. Иными словами «никто не забыт и ничто не забыто».
Ключевых плюсов в JIRA Service Desk два. Первое несомненно то, что он интегрирован с JIRA, и все запросы не просто обрабатываются на первой линии поддержке, но и назначаются/решаются/закрываются в самой JIRA.
Второй большой плюс — возможность интеграции с Atlassian Confluence, а точнее с базой знаний созданной на ней. Именно благодаря этой функции, вы можете значительно облегчить жизнь сотрудникам техподдержки за счет отсечения множества простых вопросов на этапе регистрации запроса клиентом.
Подробнее о функциональности нового плагина можно почитать на нашем сайте.
Небольшое дополнение о том, откуда появился JIRA Service Desk.
В недавнем прошлом это был достаточно популярный плагин от компании Valiantys — VertygoSLA. В связи с этим у всех владельцев лицензии на плагин VertygoSLA есть возможность получить бесплатную лицензию на JIRA Service Desk на аналогичное количество пользователей. Запрос на бесплатную лицензию нужно сделать до 31 декабря 2013 года, сделать это можно через нас.
Зачем нужна JIRA для покупки JIRA Service Desk?
JIRA Service Desk является надстройкой (плагином) для JIRA, а значит вы не можете использовать JIRA Service Desk без JIRA. JIRA Service Desk 2.0 работает на версии JIRA 6.3.5 или более поздней версии.
Какую версию программного обеспечения нужно иметь, чтобы вступило в силу новое лицензирование JIRA Service Desk?
- версия JIRA 6.3.5 и более поздние
- версия JIRA Service Desk 2.0.2 и более поздние
Как лицензируется JIRA Service Desk?
- установка JIRA Service Desk на одном инстансе JIRA в одной производственной среде на одном сервере
- бессрочное использование JIRA Service Desk
- поддержка программного обеспечения в течении 12 месяцев (в том числе и обновления)
В чем разница между агентом (agent) и пользователем (user) JIRA?
Агенты обрабатывают и отвечают на запросы клиентов. Каждый агент расходует лицензию как в JIRA, так и в JIRA Service Desk. Пользователи JIRA сотрудничают с агентами и могут оставлять внутренние комментарии на запросы клиентов
Кто такой клиент (customer)?
Клиент — это пользователь, который может делать запросы в вашу службу поддержки. Для клиентов не нужно приобретать лицензию. Также их может быть бесконечное множество.
Кто такие сотрудники (collaborators)?
Коллабораторы — это сотрудники компании, которые помогают агентам обрабатывать запросы. Они могут просматривать и добавлять запросы, добавлять и удалять свои комментарии и вложения. Каждый соучастник расходует одну лицензию JIRA.
Типы пользователей JIRA Service Desk.
- могут создавать и отслеживать свои запросы
- могут создавать публичные комментарии в своих запросах
- могут добавлять вложения в свои запросы
- имеют доступ к пользовательскому порталу и к интерфейсу службы поддержки
- могут просматривать отчеты, SLA-метрик, очередь запросов
- могут редактировать запросы, назначенные на них
- могут добавлять, редактировать и удалять наблюдателей, а также приватные комментарии к запросам
- могут просматривать запросы, комментарии и вложения
- могут добавлять и удалять свои вложения
- могут добавлять внутренние комментарии к запросам и удалять свои комментарии
- могут добавлять и удалять клиентов, сотрудников и агентов
- могут настраивать типы запросов и клиентский портал
- могут создавать и редактировать отчеты
- могут подключить базу знаний Confluence в службу поддержки
- могут настраивать почтовый канал
Буду ли я платить больше с новой политикой ценообразования на JIRA Service Desk?
Atlassian пересмотрели множество вариантов ценообразования на JIRA Service Desk, и, к сожалению, для немногих компаний новая ценовая политика может быть более дорогой. Тем не менее, можно с уверенностью сказать, что для подавляющего большинства клиентов, это изменение будет очень полезным.
Наша компания уже пользуется JIRA Service Desk, как это обновление повлияет на работу в JIRA Service Desk?
Новая политика ценообразования относится только к новым покупкам JIRA Service Desk, сделанным после 10 сентября 2014 года. Она позволяет приобретать JIRA Service Desk по количеству сервисных агентов вашей команды, а не по общей базе пользователей JIRA. Вы можете продолжать использовать JIRA Service Desk также как и использовали в момент первоначальной покупки и также продолжать продлевать его. Когда придёт время возобновления или обновления работы JIRA Service Desk вам предоставляется выбор: продолжать работу в обычном режиме или перейти на новую модель ценообразования. Всё зависит только от вас.
Я собирался купить JIRA Service Desk до новой политики ценообразования. Могу ли я приобрести JIRA Service Desk по старой цене?
К сожалению, если у вас нет открытой или действительной лицензии на JIRA Service Desk мы не можем предложить вам старую модель ценообразования.
Существует ли русская версия плагина JIRA Service Desk?
Да, компания Teamlead поставляет локализованную версию JIRA Service Desk. Оставьте запрос в форме на странице контактов.
JIRA Service Desk интегрируется с Confluence и автоматически выдает решения из базы знаний. Если количество пользователей Confluence меньше, смогут ли они получать эту информацию?
Ваша лицензия Confluence не должна иметь одинаковое количество пользователей для того, чтобы подключить Confluence к JIRA Service Desk. Если в пространстве разрешен анонимный просмотр страниц, все пользователи JIRA смогут получать статьи из Confluence. Однако, если просмотр в пространстве ограничен определенными пользователями, пользователи JIRA должны иметь то же имя пользователя в Confluence для поиска в пространстве из JIRA Service Desk, то есть все кто будет искать статьи из JIRA Service Desk, должны быть зарегистрированы в Confluence.
Что такое SLA?
Соглашения об уровне обслуживания (Service Level Agreement, SLA) — не что иное, как контракт, заключаемый двумя сторонами. В основном такие соглашения описывают уровень сервиса, предоставляемого клиенту.
Источник: www.teamlead.ru