Друзья!

Напоминаю, в среду, 7 июня, в 20.00 мск проведу открытый урок "Как управлять тимлидами" в предверии старта нового курса Delivery Manager в OTUS.

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

Зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-2938

ПРО ПЕРЕГОВОРЫ #5

Продолжаем переговорный тред. В предыдущих сериях:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
ПРО ПЕРЕГОВОРЫ #4

Мы подробно обсудили этап подготовки к переговорам. Точнее сказать, этап стратегической подготовки. Это основа. Дальше на стратегию накладывается тактика. И это последний шаг в подготовке. Но не по значению.

Шаг 1 – Аргументы и обоснования. Берем все результаты нашей стратегической подготовки, наше видение портрета оппонента и его интересов. И готовим аргументы, которые могут убедить его. Каждому аргументу нужны еще и обоснования. Здесь можно использовать инструмент из продаж и презентаций ПИОН:
- П – Поручение – мнение авторитетных людей
- И – История – реальные истории из жизни, свои или чужие
- О – Официальные данные
- Н – Наглядные модели

Шаг 2 – Подача аргументов. Да-да, мало что-то говорить, важно говорить это правильно! Вот здесь как раз на сцену выходит все разнообразие переговорных техник, которыми можно усиливать ваши аргументы:
- Удержание сильных аргументов
- Заезженная пластинка
- Паузы
- Открытые/закрытые вопросы
- Внимание на общую картину
- Тайм-аут
- Эскалация
- …

Шаг 3 – Оппонент. Теперь нужно прикинуть, исходя из портрета, целей и интересов, а также переговорной позиции оппонента, какими аргументами и приемами он может воспользоваться. Фантазируем, какие у него могут быть аргументы, как он может пытаться их обосновать, как будет их вам подавать (какие переговорные техники станет использовать).

Шаг 4 – Ответы оппоненту. Разворачиваем все возможные действия оппонента обратно на него. Готовим контраргументы к его аргументам. Чем больше, тем лучше. Готовим контрприемы на его переговорные приемы. И важный момент – готовим возможные уступки. При каких “если” мы можем соглашаться на его предложения и аргументы. Обязательно готовьте этот блок заранее, чтобы во время разговора не растеряться и сохранять твердость своей позиции.

Шаг 5 – План переговоров. Теперь берем все результаты шагов 1-4 и оформляем в единый план. Что будем говорить, как будет говорить. Как будем парировать аргументы и переговорные приемы оппонента. На какие уступки можем пойти с выгодой для себя, на какие – ни в коем случае.

Вот теперь точно все. Вы готовы к переговорам. И у вас есть план. Не скрипт, а именно план. Там возможны ветвления и креатив “на местности”. Но с планом гораздо спокойнее. Даже если вы им и не воспользуетесь в итоге. План – ничто, планирование – все!

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

Видео вчерашнего вебинара "Как руководителю повысить прозрачность работы проектных команд?"

https://www.youtube.com/watch?v=E9wT5eSU6pg

Внутри, традиционно, немного рекламы OTUS 🙂

ПРО СТЕК

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

Но там подсмотрел одну метафору, которая мне показалась элегантной. Вот делюсь.

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

Ну разве это не гениально? 🙂

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

Инженер – он что? Он решает задачу наиболее простым способом. Усложнениями всякие разные ученые обычно занимаются, чо-то вот там придумывают, совершенствуют. А инженер берет готовое и известное, и из этого складывает то, что ему нужно. В строительстве, в производстве, везде так!

А программисты же не такие? У этих постоянно креатив, тяга к прекрасному, желание творить и развиваться. И они, наоборот, вперед всякого RnD стараются что-то придумать и первыми запустить. Даже не ради наград, а просто, потому что интересно.

И вот где тут, спрашивается, ошибка? Зря программистов инженерами назвали? Или классическое понимание инженера давно устарело и надо все пересматривать?

Я больше склоняюсь ко второму варианту. Это объясняет, почему в IT последние десятилетия движуха, а все остальные сферы жизни и производства развиваются заметно медленнее. Были бы везде такие “голодные” инженеры, глядишь совсем иначе выглядел бы мир. Но это не точно.

А вы как думаете? Кто же “не те” – программисты или инженеры? Или не надо их сравнивать, и инженер-программист – это как русский рок: рок, конечно, но очень особенный, “русский”?

Видео вчерашнего открытого урока в OTUS "Как управлять тимлидами"

https://www.youtube.com/watch?v=ZI6hvR5EVSg

Внутри информация о стартующем курсе Delievry Manager и немного рекламы OTUS.

Новая статья! На этот раз про метрики и управление сразу несколькими проектами.

https://habr.com/ru/companies/otus/articles/740834/

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

Приятного чтения!

ПРО НАЙМ

В минувшую субботу провел своей день в Школе CTO Стратоплана. Говорили про найм, развитие сотрудников, увольнение. Весь ЖЦ охватили, так сказать 🙂

Хотел поделиться мыслями по одному инструменту, который разбирали. Это портрет кандидата. По сути, описание сотрудника, которого мы хотим нанимать.

Концепция унаследована из маркетинга, где принято описывать подробно портрет ЦА. Хотя, там есть мнение, что портреты уже не работают, и нужно отталкиваться от JTBD клиента. Но в найме пока не так, здесь все работает.

В портрете кандидата описываются основные стандартные блоки:
- Компетенции
- Опыт
- Личные качества
- Возможные позиции
- Специальные требования
Может быть что-то еще, но эти – основные.

Есть 3 основных способа формирования портрета кандидата:
1. Фотография – одна из крайностей, описать детально все требования, вплоть до пола и возраста, чем сильно заузить воронку для рекрутинга
2. “Ежик в тумане” – другая крайность, не описывать вообще почти ничего, потом фильтровать всех на этапах интервью
3. Конструктор – баланс, выделить главное и второстепенное, из кубиков собрать несколько потенциальных портретов

Так вот, что интересно. Обратите внимание на картинку 1 – так выглядит обычный стандартный процесс найма в IT. В среднем по больнице.

А теперь посмотрите на картинку 2 – это процесс найма тимлидов. Интервью с HR и интервью с руководителем занимают гораздо больше места, чем этап технического интервью. Логично, техника начинает уходить на второй план.

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

Почему так происходит? Потому что чем выше позиция, тем важнее проверять личностные качества, те самые Soft Skills. Важно, чтобы они матчились с корпоративной культурой. Ошибиться в этом с инженером – не страшно. Иногда даже поправимо. Если же нанять руководителя, с которым не наблюдается culture fit – это “бомба замедленного действия”, когда и как она стрельнет – никто не знает. Риски, при том неоправданные.

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

А как у вас с наймом менеджеров? Похожая история?

ПРО УВОЛЬНЕНИЯ #4

Продолжение треда про увольнения. Предыдущие посты:
ПРО УВОЛЬНЕНИЕ #1
ПРО УВОЛЬНЕНИЕ #2
ПРО УВОЛЬНЕНИЕ #3

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

Начинается все, традиционно, с подготовки. 3 шага подготовки к разговору:

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

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

3. Проработка рисков – рисков полно, и нужно учесть большую их часть. Юридические риски – законодательство специфично, и во многих странах (в том числе в РФ) оно вообще не на стороне работодателя. Репутационные – уволенные часто токсичат, как внутри коллектива, так и за пределами компании, нужно это проработать и заранее подстраховаться. Безопасность – банальные доступы, контакты с заказчиком и т п, нужно заранее подумать, как это быстро ограничить, если вдруг чего

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

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

Саму структуру разговора я стараюсь выдерживать примерно следующей:
- Без лишних вступлений и вводных
- Четко озвучить решение и причину
- Подтверждающие факты и фидбеки
- Предложение и условия
- Показать, в чем профит для сотрудника
- Дать слово сотруднику – ок / не ок
- Обработать возражения / вопросы
- Зафиксировать договоренности

Думал, умещу все в этот пост, но не получилось) Сделаю еще один по теме “А если не получилось договориться?”. Покидайте в комменты, какие еще вопросы по увольнениям стоит рассмотреть и подробнее раскрыть?

И снова статья про Delivery Manager-а! Легкое чтиво, про карьерное развитие тимлида, плюсы и минусы роли DM, сложность перехода.

https://habr.com/ru/companies/otus/articles/741756/

ПРО ПЕРЕГОВОРЫ #6

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

Все предыдущие посты вот:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
ПРО ПЕРЕГОВОРЫ #4
ПРО ПЕРЕГОВОРЫ #5

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

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

1. “Переговорное джиу-джитсу” – уворачиваться от атак оппонента, переносить фокус на проблему, не критиковать позицию оппонента и не защищать свои идеи, а быть гибким, искать точки пересечения

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

3. Противодействие уловкам – есть уловки, чтобы бороться с уловками. Наиболее частые из них:
- Преднамеренный обман
- Психологическая война
- Позиционное давление

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

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

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

Вот и все. Так выглядит алгоритм подготовки и проведения переговоров, которым пользуюсь сам, и рекомендую пользоваться остальным. А основную мысль можно сформулировать очень просто: “к любым переговорам нужно готовиться, от этого зависит их эффективность”.

Удачи в переговорах, коллеги!

Коллеги!

В следующий понедельник, 19 июня, в 20.00 мск проведу открытый урок курса TeamLead в OTUS по теме "Тимлидское искусство пофигизма".

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

Мероприятие бесплатное, зарегистрироваться можно здесь https://otus.ru/lessons/teamlead2-0/#event-2927

ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 3 НЕДЕЛИ

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

Анонс статьи про управление тимлидами

Пост про метрики проекта - пара полезных фреймворков

Видео окрытого урока про риски для тимлидов

Пост про увольнения #3 - разбор подхода Учить/Лечить/Мочить

Пост про проблемы роста менеджеров

Пост про переговоры #5 - про тактический уровень подготовки

Видео вебинара "Как руководителю повысить прозрачность работы проектных команд?"

Пост про стек

Видео открытого урока "Как управлять тимлидами"

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

Пост про найм и портрет кандидата

Пост про увольнения #4 - подготовка и проведение разговора

Анонс статьи "Я тимлид. Что дальше?"

Пост про переговоры #6 - завершающий весь тред, про непосредственно проведение переговоров

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

Коллеги, еще хочу напомнить!

29 июня буду выступать с МК на Skolkovo Tech Week с темой “Тимлид – ключевое звено в изменении корпоративной культуры”. Ищите меня в потоке MANAGEMENT.

У меня есть несколько промиков с бесплатными билетами! Напишите в личку @ilya_prakht, кому надо. Срок у них до 23 июня.

Про мероприятие:
Что важно для современного предпринимателя?
Быть в курсе последних трендов на рынке, а также уметь собрать сильную команду.
Об этом и многом другом вы можете узнать на крупнейшей технологической конференции России - TECH WEEK 2023 @russiantechweek
Что там интересного:
• Тематические выступления по 12 потокам, выступления экспертов на актуальные темы и мастер классы;
• Нетворкинг - соберёте самые ценные контакты, найдёте партнеров и близких людей по духу, а еще можно тусануть на AfterParty;
• Практика - разберёте кейсы, сделаете задания, изучите предметно рабочие инструменты;
• Выставка актуальных решений для бизнеса в сфере технологий, инноваций и технологического сервиса.

Коллеги!

Сегодня в 20.00 мск проведем финальный открытый урок перед стартом курса Delivery Manager в OTUS. А старт уже в понедельник!

Тема ОУ "От проекта к портфелю: как управлять несколькими проектами?" - поговорим про управление проектами через метрики и роль DM во всем этом.

Зарегистрироваться на мероприятие можно тут https://otus.ru/lessons/delivery_manager/#event-2939

Проведу не я, но мой коллега, один из преподавателей курса DM, Дима. Дима крутой! Очень рекомендую)

Видео вчерашнего ОУ "Тимлидское искусство пофигизма". Философский сказ о том, почему гиперответственность - это плохо, что тимлид должен делать, а чего - нет.

https://www.youtube.com/watch?v=HRUMY1Zw0ks

Видео вчерашнего открытого урока про метрики и управление несколькими проектами.

https://youtu.be/TdQj7kSEN0s

Эфир не мой, повторюсь. Но курс-то мой :) И Дима молодец!

ПРО УВОЛЬНЕНИЯ #5

Завершаем тредик. Все предыдущие посты вот:
ПРО УВОЛЬНЕНИЕ #1
ПРО УВОЛЬНЕНИЕ #2
ПРО УВОЛЬНЕНИЕ #3
ПРО УВОЛЬНЕНИЕ #4

Теперь рассмотрим, а что, собственно, делать, если сходу не договорились. Пообщались, поторговались, но к единому консенсусу не пришли.

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

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

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

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

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

Вариант 3 – пытаться все-таки договориться. Что называется, “не мытьем, так катаньем”. Встречаться с сотрудником снова и снова, объяснять конструктивно и спокойно, что будущего у вашего сотрудничества нет и не будет, возвращаться к предложению, показывать, в чем здесь профит для сотрудника и почему ему следует принять это предложение. Рано или поздно ему надоест это, и он станет сговорчивее.

Вариант 4 – пойти на условия сотрудника. Чаще всего, основной и единственный камень преткновения – деньги. Если все делать сокращением по-закону, получается дороже. Компания хочет сэкономить, и заплатить поменьше. Вот здесь все расхождения и начинаются. Можно спросить сотрудника “в лоб”, какой размер выходного пособия его устроит, немного поторговаться и принять его условия. Получится дешевле, чем вариант 1.

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

Но лучше договаривайтесь. Помните то правило, с которого я все начинал: “принимать решение нужно, как менеджер, а реализовывать – как человек”.

Удачи, коллеги! Очень надеюсь, что этот материал вам никогда не пригодится. И велком в комментарии с вопросами!

ПРО НАЙМ #2

По мотивам активной дискуссии в посте ПРО НАЙМ. По просьбе @raiserspb и @JustManowar попробуем порассуждать, для технических руководителей насколько, все-таки, важны hard-skills.

Первое, на что хочется обратить внимание – роль руководителя. Да, тимлид тоже руководитель, и его это тоже касается. Вспомним 4 основные функции руководителя: планирование, организация, мотивация, контроль. Заметьте, ни слова про “писать код” 🙂

Значит ли это, что харды не нужны? Отнюдь! Но здесь важно понять смену парадигмы: для тимлида харды – уже не базовые компетенции, благодаря которым он может выполнять свою работу (как это у разработчика), а инструмент. Хорошие харды, хороший технический бэкграунд дает возможность эффективнее делать планирование, организацию, мотивацию и контроль. И чем технически сложнее проект, тем лучше нужно понимать контекст, тем важнее здесь харды.

Второй момент: тимлид – играющий тренер. Очень часто его функции распределяются в пропорциях, например 50/50: 50% времени управляешь командой, 50% времени сам пишешь код и решаешь инженерные задачи. Ну как уж тут без хардов? Это добавляет путаницы в вопросе. Естественно, если будут искать именно такого человека в найме, то и портрет будет состоять из 2 частей: тут вам и требования по технике (причем вагон, как у скиллового разработчика), и софты, поскольку лидерскую функцию тоже нужно закрывать.

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

В качестве примера в дискуссии был выбран геймдев. Является ли геймдев технически сложным? Несомненно! Сложнее ли он, чем, например, банкинг? Большой вопрос. Но в банкинге, как правило, гораздо больше требований к софтам у руководителей, а в геймдеве - к хардам. Почему так?

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

Теперь геймдев. Здесь также я бы выделил 2 основных момента. Первое – очень много различных стримов в рамках каждого продукта. Здесь работают и художники, и дизайнеры геймплея, и много разных разработчиков под разные платформы и т д и т п. Отсюда, как раз, наличие большого количества продюсеров и других специальных менеджеров, кто чисто за софты – потому что все это надо синхронизировать и этим как-то управлять. Второе – очень высокая скорость time-to-market. А это означает огромный дефицит времени в принятии решений. Как это сочетать вместе, учитывая сложность синхронизации и целый штат продюсеров? Закрываться очень технически прокаченными тимлидами, чтобы они могли быстро и в одной голове решать как организационные, так и технические вопросы. Отсюда и высокие требования к хардам.

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

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