Agile, scrum, waterfall, kanban

Lean

оптимизации бизнес-процессов

ТРИ «M»

Muda (потери) – Lean определяет семь различных видов потерь, которые могут быть искоренены. Некоторые из них включают транспортировку продукта, перемещение работников или машин, чрезмерную переработку и перепроизводство.
Mura (нерегулярность) — этот принцип направлен на оптимизацию рабочего процесса за счет уменьшения отклонений и устранения накладных расходов.
Muri (напряжение) – относится к устранению переутомления, стресса и перегрузки сотрудников. Это может быть результатом неадекватной организации, обучения или неправильных инструментов.

Agile — что это такое

Понятие agile, или эджайл, происходит от англ. agile — «проворный». Это довольно удачная формулировка, ведь agile-команды более проворные: они стараются как можно раньше начать работу с минимальным требованиями и сроками, пока другие долго планируют, прикидывая сроки и бюджеты.

Сам по себе Agile — не метод управления. Это скорее набор идей и принципов для эффективного создания проектов. Уже на основе этих принципов и лучших практик разработаны отдельные гибкие методологии, или фреймворки: Scrum, Kanban, Crystal и другие. Они разные, но следуют одним и тем же принципам Agile.

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

планирование,
проектирование,
разработку,
внедрение,
оценку.

Такой подход избавляет от лишней траты времени и даёт сконцентрироваться на выполнении конкретной задачи в ограниченный срок.

Этапы работы с проектом по Agile

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

Kanban. Отличия Kanban от SCRUM

Kanban также реализует принципы Agile-манифеста, но в данном случае главная задача руководителя — поставить товар потребителю «точно в срок» в необходимом объеме. Для этого работа выстраивается так, чтобы равномерно распределить нагрузку между сотрудниками. Например, не допускать ситуаций, когда программисты простаивают, а дизайнеры не успевают решать поступающие задачи.

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

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

В отличие от менеджмента по SCRUM, в модели Kanban главная метрика эффективности — среднее время решения задачи

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

Task	Step 1	Step 2	Step 3	Step 4	Status
	Max 2	Max 3	Max 3	Max 2
K
L	I	F	C	A
M	J	G	D	B
N		H	E
O
P

Обучение по теме

Курс

Методология Agile. Эффективное управление бизнесом

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

3 650 ₽

Подробнее

Традиционная методология водопада

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

Как только все требования будут четко определены, приходит Дизайн фаза. Там все требования переводятся на техническое значение, то есть о том, как они будут реализованы или выполнены.

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

Как только все реализовано, есть Фаза проверки и тестирования Соответствуют, где все функциональные возможности дважды проверяются и проверены.

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

В чём плюсы Waterfall-модели

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

Поэтому водопадная модель максимально простая и понятная. Всё логично и протекает в рамках привычных фаз.

Второй важный плюс – внятная структура. Костяк проекта жёсткий, и не подразумевает отклонений по мере работы над задачами. Никаких неожиданностей, переключения на более важные фичи, доработок на ходу, смены парадигм и т.п.

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

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

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

Agile или Waterfall. Что выбрать?

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

Важно учитывать плюсы и минусы Agile в сравнении с Waterfall, а уже затем делать взвешенный выбор

Agile

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

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

Waterfall в переводе с английского означает «водопад». Эта модель управления проектами позволяет детально спланировать работу над проектом, продумать все стадии работы, оценить их стоимость и необходимые временные затраты.

Waterfall

+	—
Легко оценить итоговую стоимость проекта	Итоговая стоимость работ по проекту может увеличиться, но маловероятно, что она уменьшится
Привычная и понятная модель работы	Работу нельзя подстроить под непредвиденные обстоятельства. В крайнем случае — можно сэкономить время на стадии тестирования продукта, отказавшись от нее
Привычные формы отчетности по проекту	Невозможно тестировать продукт в ходе работы. Тестирование можно организовать, только когда проект фактически завершен
Задачи определены с момента запуска проекта	В продукт невозможно внести изменения в процессе разработки, даже если разработчик понимает, как продукт можно улучшить

Модель Waterfall стоит использовать в том случае, если основное ограничение для проекта — сроки реализации или если ваша команда недостаточно сработалась, чтобы участвовать в управлении сообща. Для гибкого цикла разработки продукта же участие команды в управлении проектом — это обязательное условие.

Scrum

Сегодня Scrum — наиболее популярная методология гибкой разработки. В мире на 2021 год Scrum применяют 66% Agile-разработчиков. Изначально Scrum был разработан для IT-сферы, но сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ, и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам термин пришел из регби и в переводе с английского означает «схватка».

В основе Scrum лежит гибридная итерационно-инкрементальная модель разработки. Итерации здесь называются «спринтами» (от англ. sprint, бег на короткую дистанцию).

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

Роли.

В Scrum можно выделить четыре главных роли:

Клиент — он же заказчик, инициирует проект и дает на него деньги.
Владелец продукта (Product owner) — в классическом понимании это постановщик задачи. Он взаимодействует с заказчиком и формулирует задачи для команды разработчиков.
Scrum-мастер — управляет процессом разработки. Назначает и проводит разные организационные мероприятия, координирует работу команды. Самый близкий аналог Scrum-мастера — это руководитель либо менеджер проекта. Scrum-мастер контролирует, чтобы команда следовала предусмотренному протоколу разработки.
Scrum-команда — сплоченная команда высококлассных и разносторонних разработчиков, обычно 5–10 человек, работающая в плотном взаимодействии друг с другом.

Цикл разработки.

Цикл разработки по Scrum выглядит следующим образом: в начале каждой итерации производится планирование спринта (Sprint Planning) и оценка задач по дальнейшему развитию продукта бэклогов (Product Backlog).

Бэклог изначально состоит из эпиков (Epic). «Эпик» — большая автономная часть функционала, которая может быть завершена в рамках разработки продукта. Затем проводится декомпозиция, каждый «эпик» разбивается на меньшие компоненты, которые называются сториз (User Story).

Для сториз часто используется шаблон: «Я, как <роль/тип пользователя>, хочу <выполнить действие/получить результат>, чтобы <достигать цели>». Так простым человеческим языком формулируются задачи проекта. Любой сториз подвергается дальнейшей декомпозиции, до тех пор, пока не будет разбит на наименьшие сущности («таски» или задачи).

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

У спринтов есть жесткие ограничения по времени (минимум неделя и максимум месяц). Если не удалось уложиться в дедлайн, спринт считается проваленным. Необходимо понять, в чем была ошибка в оценке времени, и скорректировать ее на следующий спринт. Для всего этого Scrum предусматривает соответствующие процедуры. По завершении текущего спринта формируется список задач на новый спринт (Sprint Backlog), то есть происходит переход к следующей итерации.

Важно не забывать и про недостатки Scrum, которые часто забывают учесть заранее

6. «Iterative Model» (итеративная или итерационная модель)

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

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

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

Когда оптимально использовать итеративную модель?

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

Agile Methodologies.

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

Активные методологии в основном применяются в проектах, где степень неопределенности и сложности высоки.

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

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

Минусы Waterfall методологии

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

С Водопадной моделью вы не сможете «откатиться» назад и что-то переделать. Тут доступно только движение вперёд – до самого конца. Переделка и доработка возможны будут только при следующей итерации – со своими этапами формирования требований, анализа и проектирования, реализацией и т.д.

В Waterfall максимально высокие риски. Если что-то не было учтено на этапе проектирования, то переделать «на ходу» уже ничего не получится. Нужно будет останавливать весь процесс разработки и начинать всё сначала. А это потери времени, ресурсов и денег.

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

Стандарты управления проектами

Существуют несколько групп стандартов в области управления проектами. Это:

Частные стандарты. Разрабатываются в компании для проектов определенного типа, например, один стандарт для проектов по созданию сайтов, другой — по их продвижению, третий — по запуску рекламных кампаний в «Яндекс.Директе».
Корпоративные стандарты. Это общие стандарты для конкретной организации/корпорации, или единая система проджект-менеджмента. Определяет, как правило, общую политику, классификацию проектов, систему оценки результатов. Может включать также детальные описания процессов в виде методической документации.
Общественные стандарты. Разрабатываются и применяются в обществах специалистов в какой-либо отрасли, например, в генной инженерии или в медицине (даже клятву Гиппократа можно считать примером такого общественного стандарта).
Международные стандарты. Это стандарты управления проектами, созданные в какой-то одной стране, но благодаря высокой эффективности применяемые во многих странах. Пример такого стандарта — пожалуй, самый известный — PMBOK (Project Management Body of Knowledge). А его современная и нестандартная альтернатива — SCRUM.

Стандарт управления проектами РМВОК

Стандарт РМВОК был принят Американским национальным институтом стандартов для обеспечения управления проектами в космической отрасли и оборонной промышленности еще в 70-х годах прошлого века. Сегодня стандарт получил мировое признание — он используется в 160 странах, в том числе и в России. РМВОК описывает полный жизненный цикл проекта, разбирает его на процессы, а процессы делит на группы. Вот такие:

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

7 советов для тех, кто ищет проджект-менеджера, отвечающего за сайт компании

Стандарт управления проектами SCRUM

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

В команде в этом случае обязательно участвует SCRUM-мастер. Он следит за реализацией проекта, проводит короткие собрания (Scrum meetings) на которых выявляет проблемы, ктуальные здесь и сейчас, и помогает найти пути их решения. На экспресс-собрании каждый член команды отвечает на три вопроса:

Что ты делал вчера, чтобы помочь команде успешно завершить спринт?
Что ты будешь делать сегодня, чтобы помочь команде успешно завершить спринт?
Какие препятствия ты видишь на пути команды прямо сейчас?

Why is PMBOK® changing?

Until now, PMBOK was mainly focusing on waterfall project management techniques. However, with the fast pace of technology, competition is harsher than it was never before. Product life cycles are shorter and requirements of the product or project can change over time depending on the progress of the project.

With conventional project management approaches, it is not possible to welcome rapidly changing requirements to the projects. That is why agile project management methods and approaches emerged in the 2000s. These agile frameworks started to be adapted by many organizations in project management, especially in the IT and software industry.

PMP is the most reputable project management certification around the world with nearly one million PMP certified professionals. PMBOK is the backbone of the PMP certification exam content. Since the project management dynamics, popular frameworks, and trends are changing, PMBOK must be relevant to the changing dynamics of the project management profession as well. That is the main reason why PMBOK is changing every three to five years.

Project Manager: профессиональное управление проектами

Project Manager, менеджер проекта или продакт менеджер – это руководитель, основной задачей которого является контроль всех этапов реализации проекта.

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

Задачи делятся на стратегические и тактические.

Тактические – решение ежедневных вопросов и устранение сложностей.

Стратегические – координация работы команды для достижения цели проекта.

Плюсы работы проектного менеджмента

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

Увеличение качества предоставления услуг и сервисов.
Рост удовлетворенности клиентов.
Повышение квалификации команды.
Приобретение конкурентных преимуществ.
Появление возможности расширения сервиса.
Рост гибкости.
Увеличение производства товаров и услуг за единицу времени.

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

Недостатки работы проектного менеджмента

Несмотря на очевидные преимущества, такой подход имеет ряд недостатков.

1. Высокая стоимость, отсутствие ROI.2. Усложнение простых проектов (в случае, когда выбрана неверная методология).3. Отсутствие реальных результатов из-за смещения акцента к статусу этапов.

Выбор верной стратегии

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

Применение Agile в управлении бизнесом и маркетинге

Методологии Agile — не свод правил и предписаний, а радикально иной способ взглянуть на организацию рабочего процесса. Agile Project Management может быть очень выгоден компании в первую очередь тем, что помогает быстро адаптироваться к изменениям на рынке, а также найти узкие места и устранить их. Что такое узкие места? Простыми словами — это рабочие задачи, которые решаются очень медленно и тормозят работу компании.

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

Возможное решение по Agile Project Management: организовать более жесткий контроль качества изделий до обжига и перевести на него часть рабочих, которые производят новые вазы. Это позволит улучшить качество изделий, которые в итоге попадают в печь, и снизить нагрузку на узкое место.

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

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

Новый манифест Agile-маркетинга. Философия подхода:

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

Акцент на адаптации

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

На этот раз коллеги из PMI написали однозначно – «…настоящее Руководство не является методологией». И для пущего понимания описали подробно, как использовать Руководство (термины Руководство, PMBOK используются в тексте настоящей статьи как синонимы — прим. автора).

Разработчики рекомендуют использовать PMBOK для создания методологии управления проектами в организации. Методология может быть создана собственными внутренними экспертами организации или с помощью внешних профессиональных консультантов. Это первый уровень адаптации — процессы и инструменты из PMBOK приспосабливаются под конкретную организацию.

Чтобы было легче адаптировать, в PMBOK в каждой области знаний выделен раздел «Соображения по адаптации», который через наводящие вопросы заставляет задуматься, а какие из перечисленных в Руководстве инструментов действительно нужны на проекте. Для большего удобства соображения по адаптации собраны также в отдельное приложение в конце издания.

Таким образом, хотя PMBOK у многих профессионалов ассоциируется с жестким классическим проектным управлением, Институт управления проектами делает каждое последующее издание Руководства все более гибким и адаптивным.

Делаем выводы

Проджект-менеджмент — прогрессивный и эффективный метод управления проектами, а проджект-менеджеру никогда не придется скучать, и всегда будет, куда расти. Чтобы рост шел активнее, убедитесь, что на проекте, над которым вы работаете прямо сейчас, вы сделали все, чтобы повысить его эффективность:

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

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