6 шагов, которые помогут внедрить изменения в проекте. Опыт PM'a

Меня зовут Максим Островский, я руководитель группы в PMO компании AMC Bridge. В IT тружусь последние 7 лет, до этого работал в консалтинге и с развитием систем, связанных с обучением в производственных компаниях и медицине.

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

Данная статья про изменения. Она построена в основном на примере работы с системой управления проектами. Но некоторые примеры будут из внедрения ТРИЗ и систем управления персоналом для больших предприятий.

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

Эта статья для тех, кто уже работает над процессами. Это может быть PMO или любая другая структура. Для директоров, которые проводят изменения и стратегию топ-менеджмента. Для топ-менеджмента — ради понимания принципов, из-за которых нововведения могут провалиться. И для PМ’ов и прочих специалистов, которые в работе сталкиваются с анализом и улучшением процессов.

О провалах

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

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

Удачные/неудачные изменения

Что же такое изменение системы, процесса или стандарта? Это когда есть состояние А (работающая схема, которая повторяется и понятна участникам), и мы хотим прийти в состояние Б (новая система, но обладающая такими же характеристиками).

Чтобы подтвердить, что мы достигли состояние Б, нужно следующее:

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

А что же тогда неудачные изменения?

Для меня это:

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

Нестабильность может быть причиной неполной проработанности внедрений. Например, мы разработали основную линию — и заказчик должен постоянно быть в курсе статуса проекта. Вроде все просто. Но на практике возникнет множество нюансов и вопросов. Какая периодичность отчетности и почему? А если заказчику не нужны эти данные, он нам доверяет? Если заказчик не хочет получать отчет — значит, не нужно собирать эти данные? Если мы не знаем, что конкретно хотим и предлагаем как система, вернемся к прежнему отсутствию отчета, с одной только разницей — вначале проекта ПМ будет официально писать, что отчет не нужен. Так и происходит «откат».

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

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

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

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

Шаг 1. Ищем стейкхолдеров и заключаем соглашения

Для начала нужно найти тех, кто изменения купит. И это не только менеджмент компании, но и те, кто с этой обновленной системой будет работать. Все по классической схеме: определяем всех, кто может влиять на проект. В идеале — построить реестр стейкхолдеров.

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

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

Спонсор — это тот, кто дает жизнь проекту, обычно выделяя ресурсы или давая добро на то, чтобы вы их взяли. Он должен быть:

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

Если с первым пунктом сложно что-либо изменить, только идти к правильному человеку, то пункты 2 и 3 зависят от нас. Вот три инструмента, как обеспечить вовлеченность и заинтересованность спонсора в проект:

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

Принцип маятника

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

У меня был один заказчик, руководитель департамента, в котором мы строили Scrum. Его звали Сергей (но все имена, конечно же, изменены). Это был решительный и ответственный руководитель. Мы встретились для планирования и презентации программы, и я ему нарисовал картинки прекрасного и счастливого будущего, которое еще и выражалось в количественных показателях. Он был не со всеми действиями согласен, но я продал ему идею. Мы договорились, что через 4 спринта показатели достигнут отметки 90%. Проходит два спринта — показатели на уровне 45%. Сергей потребовал список людей, которых мы будем штрафовать, экстренных мер и прочего. А показатели упали по двум причинам: во-первых, мы просто начали правильно считать, во-вторых, нужно было время разгрести то, что раньше считалось неправильно. Я напомнил ему о договоренности про 4 спринта — руководитель принял. И вот заканчивается 3-й спринт — показатели 60%. Сергей рвет и мечет и настойчиво предлагает включать админрычаг. Напоминаю ему про договоренность.

В результате 4‑го спринта мы вышли на 89%. Заказчик доволен :) Но это постоянный маятник — сначала продаем идею, а потом сдерживаем, когда хотят достичь светлого будущего, например, быстрее.

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

Если растет незаинтересованность, сделайте фокус на «продажу» результатов проекта и коммуникацию. Если спешка, делайте ставку на планирование и реальные сроки, прошлые договоренности.

Это постоянный процесс. И чем лучше управляетесь с маятником заинтересованности, тем стабильнее и качественнее получатся нововведения.

Шаг 2. Ставим цели и определяем образец

Все мы знаем, что начинать нужно с целей. Но иногда это сложная задача. Мы часто инициируем изменения, потому что есть что-то лучшее, но не всегда возникают вопросы, зачем и чего добьемся, внедрив это. «Очевидно, что жить по Agile лучше!», «Разве есть кто-то, кому нравится разгребать баги в продакшене?» — это то, что говорим себе в таких случаях. И это отличная мотивация для нас, но не для бизнеса.

Поддержка изменений будет, если цели имплементации сформулированы на языке целей бизнеса и если они желанны для спонсоров.

Напоминание, что нужно бизнесу:

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

Последствия. Мы к ним готовы?

Да, еще на этом этапе стоит задать себе вопрос: «А нам это точно нужно? Не хотим ли мы изменений ради изменений?».

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

Если все еще отвечаете утвердительно — окей, едем дальше.

Где брать цели

Про постановку целей сказано много, я остановлюсь только на том, где брать цели для проекта имплементации:

1. Из стратегии. Посмотрите на стратегические цели компании. Лучше всего спросить об этом у потенциального/реального спонсора.
2. Из проблем. Почему страдаем сейчас так сильно, что уже нет сил и готовы потратить кучу денег и ресурсов, лишь би решить проблему.
3. Из образца. Если есть инструмент, часто с ним в нагрузку идут цели, которых он может достигать.
4. Священные коровы. У каждой компании они свои. Это диктуется отношением топ-руководства к бизнесу, и часто это не прибыль. Для кого-то это близкие отношения с клиентами, для кого-то стандарт качества, для кого-то скорость. Подумайте, что это для вашей компании, и все, что улучшает священную область, потенциально будет желанно для менеджмента.

«План — ничто, планирование — все»

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

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

Образец системы

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

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

Мы выбрали CMMI — Capability Maturity Model Integration — как систему, на которую можно опираться в оценке и развитии процессов в компании. Выбор, по сути, был среди двух моделей зрелости проектных организаций — CMMI и OPM3. Но CMMI — это тема отдельных публикаций. Здесь нас интересует подход к тому, как делаются изменения.

Шаг 3. Анализируем систему

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

В моем опыте есть пару компаний, где аккуратной кучкой лежат сломанные мной копья о систему, которую начинал менять, прежде чем ее понять.

В одной из компаний я должен был работать с тремя директорами предприятий и с их отделами по персоналу. Будучи молодым, я совместил встречу-знакомство с директорами и начальниками отделов с проведением «аудита». После этого подготовил перечень проблем и способов, как их устранить. В течение двух недель мне разными отчетами, доказательствами и прочим показали, что только один мой комментарий из 23 реально применим. В итоге я вообще неправильно понял систему и ее проблему, также испортил отношения со старта со всеми руководителями департаментов, с которыми мне нужно было работать. На отлаживание отношений и «нормальный» анализ системы потратил после этого около года.

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

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

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

Этапы оценки:

1. Определение параметров.
2. Разработка шкал оценки и опросников/чек-листов.
3. Проведение оценки.
4. Постановка целей в тех же категориях, в которых проводилась оценка.

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

Шкала оценки часто вызывает вопросы. Для себя я разработал набор критериев хорошей шкалы:

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

Чем могут отличаться оценки:

• наличием или отсутствием чего-либо (процесс выполняется = 3, процесс выполняется и документируется = 4);
• постоянством (выполняется, но не всегда = 2, исполняется в 99% процентов случаях и является стандартом и привычным для всех = 3);
• измерениями (<10 = 4, >10 = 5);
• соответствием чему-то (полностью соответствует стандарту = 3, частично = 4).

Как проводить оценку? Советую придерживаться таких правил:

1. Делайте оценку анонимной (насколько это возможно).
2. Если нужна дифференциация, делайте даже маленькие группы по каким-то критериям (численность людей в проекте, страна клиента прочее), но оценка — анонимная.
3. Много коммуницируйте до, во время и после оценки. Минимум три раза с каждым участником.
4. Все респонденты должны получить отчет по итогам оценки.
5. Планируйте еще одну встречу для разъяснения результатов.

Вот здесь точно действует правило: You can not overcommunicate. Коммуникаций не может быть слишком много. Проще недокоммуницировать.

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

Шаг 4. Документация как база

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

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

Расставьте приоритеты. Приоритизируйте те области, которые в первую очередь нуждаются в документации. Даже иногда не области, а части процесса. В первую очередь покройте их, а в фоновом режиме разрабатывайте остальное. Это нормально, когда на начальных этапах в документах много пунктов стоит как TBD (to be discussed).

Например, в одном из кейсов, внедряя issue log проекта, нашей целью было заставить PМ’ов осознанно смотреть на происшествия в проекте. Даже не работать с сыгравшими рисками, а для начала определять их и сохранять как историю. Но я понимал, что работа с issue — обширная область и не ограничивается историей. Наш стандарт выглядел так: 1) определения и важность; 2) общие подходы; 3) документирование сыгравших рисков; 4) репортинг клиенту — TBD; 5) план действий — TDB и так далее.

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

Команды и роли

Мне нравится схема распределения ролей, принятая во внедрении CMMI:

• Champion — чемпион.
• Process engineers — те, кто работает над улучшением и анализом процессов.
• Performers — исполнители.
• Sponsor (это я добавил от себя).

Чемпион — это лицо изменений, тот, кто объясняет, доносит, продает, успокаивает и убеждает. Этот человек ассоциируется с нововведениями, и все знают, что вопросы стоит адресовать ему. Если вам приходилось работать в одной компании с очень мотивированным Scrum-мастером, вы точно встречали чемпиона (в некоторых областях их называют евангелистами). Этот человек необязательно руководит процессом, но должен понимать свою роль.

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

Исполнители — разгружают чемпиона и инженеров.

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

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

Делаем документацию применимой

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

Обе эти крайности не решают всех вопросов. Если выбирать между ними — я за понятность. Но если есть возможность, нужно создать цикл документации и материалов, которые бы покрыли максимум из шкалы от «просто и мало информации» до «сложно, но все подробно».

Мы остановились на следующих типах документов по каждой из областей:

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

Шаг 5. Пилотные запуски

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

Где брать пилотов?

От лучшего — к менее хорошему:

1. Энтузиасты — люди, которые заинтересованы в изменениях и поддерживают ваше видение.
2. Внутренние проекты и внутренние департаменты (которые не работают с реальными клиентами). Они уже привыкли, что на них что-то пилотируется.
3. PM, который мечтает стать генералом. Если такие закончились, то может есть кто-то, кого нужно чуть-чуть подтолкнуть. Возможно, сейчас сотрудник хочет расти по карьерной лестнице? Покажите ему связь между мотивацией и необходимостью пробовать новый процесс.
4. Если же никто не хочет, ищем того, до кого позволяет дотянуться наш уровень управления.

Поддерживаем огонь

Несколько советов с практики, которые помогут не потерять пилотов и поддерживать в них огонь:

1. Когда «продаете» им идею и продумываете пилотное внедрение, ищите выгоды для их проекта и процесса. Говорите с ними на языке не трудностей, а того, чем их жизнь можно улучшить.
2. Никогда не присваивайте себе их результат. Вы будете пожинать лавры изменений в компании в целом — поверьте, они поинтереснее. Рядом с любыми положительными результатами пилотного проекта должно звучать имя пилота. Дайте специалистам самим рассказать об успехе, везде ссылайтесь на то, что они это сделали (в том числе в разговоре 1:1). Мотивация коллег будет расти, а вы получите «агентов перемен».
3. Не переставайте «продавать» идею даже после их согласия на пилотный запуск. Вам нужны люди, которые верят в идею, а пилоты — это еще и те, у кого есть практическое обоснование этой веры.
4. Можно поддерживать соревновательный дух между пилотами. Рассказывайте об успехах и выводах других пилотов. Только следите за мотивацией. Если в этом проекте дела идут не очень хорошо, история об успехах другого может стать последним гвоздем.
5. В рамках процесса вы общаетесь с руководством выше своего уровня. Например, со спонсором. Хорошая практика — знакомить спонсора с пилотами.

На этапе пилотного запуска план в 99% случаев ломается. И к этому лучше быть готовым. Мы ведь помним: «План — ничто, планирование — все». Поэтому анализируем обратную связь, но не держимся за план. Для этого и начинаем с пилотных стартов.

Советы

Не делайте выводов, пока пилотные проекты не завершились и вы не увидели всех результатов (как положительных, так и отрицательных).

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

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

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

Шаг 6. Анализ и масштабирование

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

• Помните, мы говорили, что внедрения — это проект. Так и продолжаем: планируйте мейлстоуны, пакеты доставки, работу со стейкхолдерами и прочее.
• Поэтапность обычно имеет лучшие результаты, чем внедрение огромных изменений одним куском. Поэтому сделайте промежуточные отсечки, на которых сможете остановиться и пересмотреть, куда идти дальше.
• Введите Lessons Learned. И, внимание, используйте полученные уроки на последующих этапах.
• One step at a time. Начинаем с одного проекта, потом все проекты одного PM’а, потом один департамент, затем все проекты в одном офисе, потом все проекты. И так постепенно, шаг за шагом, прорабатываем каждую область. Это так же работает в вопросе масштаба. Например, ваши проекты совсем не учитывали риски. Если добавить полноценную комплексную модель работы с рисками, с оценками, прогнозами, планами митигации и репортинга для внутренних и внешних клиентов — они утонут. Попробуйте начать с добавления списка рисков в шаблон оценки проекта или стандартный контракт. Потом внесите простую оценку рисков и учет их стоимости в проект. На следующем шаге, например, зачатки митигейшн-плана, включите активности по минимизации рисков, но только, например, для fix price проектов. И так далее.
• Позаботьтесь, чтобы результаты и выводы из внедрений были доступными для всех в компании. Презентуйте планы и последние новости, видение и роудмап, выложите их на Wiki компании с общим доступом. Это позволит работать в едином информационном поле и уберет часть вопросов и страхов, вызванных непониманием нового. Не бойтесь показать провалы команды.
• Последний — практический момент, применимый для работы с проектами. Начинать хорошо с конца, например с Project Review. Анализировать и контролировать проект стоит после его завершения. Тогда результаты уже известны и PM сам может подытожить, что нужно сделать по-другому. Это добавляет практической мотивации и делает процесс более мягким.

Спасибо всем за внимание. Предлагаю делиться своими инсайтами под статьей.