Привет! Меня зовут Корсунов Глеб, я отец российского ИТ-аутстаффинга или директор по развитию в Holyweb. Мы помогаем продуктовым командам, которые используют на проектах JavaScript (от React до Node), PHP, Golang, Java и Python, укладываться в спринты и выпускать релизы в срок.
В прошлой статье мы рассказывали, за что любим аутстаффинг еще до того, как это стало мейнстримом. Этот год показал, насколько спрос на такой формат опережает предложение. При текущем дефиците кадров продуктовые компании, которые хотят расти, используют все доступные инструменты, чтобы быстро масштабироваться, опередить конкурента с релизом и выиграть очередную битву за потребителя.
Чтобы IT-аутстаффинг приносил максимальный эффект обеим сторонам, мы подготовили исчерпывающий мануал, в котором разобрали существующие страхи клиентов и способы их избежать. Материал — must read для ресурс-менеджеров, рекрутеров, тимлидов, продактов и для всех, кто участвует в работе с внешними исполнителями на своих проектах.
Всем пользы!
На старт, собираем команду, марш!
Страх: а что если я соберу на проект команду неподходящих специалистов? Нужно больше кандидатов, чтобы было из кого выбрать!
Когда начинаете поиск аутстафф-команды на свой проект, не поленитесь потратить время на разъяснение деталей. Ситуация, когда подрядчик получает лаконичный запрос в виде «Нужна разработка фронтенда на React» — возможно, неплохое начало знакомства, но бывает, что все вводные от клиента на этом заканчиваются.
Подход «утром деньги» (CV, тестовое задание, техническое интервью), «вечером стулья» (подробное описание проекта, дедлайны, детали технологического стека) не дает команде подрядчика понять ваши требования и подобрать подходящих кандидатов. Разработчик, который заранее понимает, с чем ему предстоит иметь дело, сможет до начала проекта освежить в памяти нужные темы, изучить документацию, и онбординг пройдет быстрее и эффективнее.
Если ваш подрядчик не заинтересован качественно снять требования на старте, может случиться так, что вы окажетесь завалены десятками нерелевантных СV. Или, еще хуже, выберете разработчика, который вам понравился, и получите отказ — так как спрос на хороших специалистов большой, и выбираете не только вы, но и вас.
Как не допустить?
До того, как запрашивать CV и проводить интервью, подготовьте чек-лист передачи информации о проекте. Можете использовать наш шаблон.
Рекомендуем включить туда следующие пункты:
Список требований к специалисту (обязательные и «будет плюсом»). Самый простой способ — взять его из описания своих вакансий.
Состав команды — кто уже работает на проекте. Будет полезно, например, если аутстафферу предстоит влиться в команду из 5-10 и более человек, в этом случае подрядчик будет понимать, что соло-игроков предлагать не стоит.
Сроки проекта, чтобы подрядчик заранее имел возможность свериться с производственным календарем и графиком отпусков, а на вашем проекте не возникали неловкие паузы.
Описание: отрасль, суть проекта, как устроены процессы. Чем подробнее, тем выше ваши шансы получить разработчиков с релевантным опытом.
Список задач, которые предстоит решать. Разработка с нуля или работа с legacy-кодом? Проектирование архитектуры, code review, багфикс, рефакторинг, реализация новых функций? На чем нужно будет сконцентрироваться, какой тип задач преобладает на проекте?
Мы всегда стараемся внимательно изучить потенциальный проект, особенно если он требует единовременного выделения не менее 5 человек. После того, как интервью пройдены и клиент утвердил специалистов, мы предлагаем провести discovery call между командами. Тимлиды, проект-менеджеры и другие активные участники проекта со стороны клиента отвечают на вопросы наших специалистов, обсуждают роли на проекте и организационные моменты. После звонка мы обсуждаем проект в команде, собираем обратную связь от специалистов. Если все участники удовлетворены своими перспективами участия в проекте, то мы готовы стартовать. Клиенту этот звонок тоже помогает убедиться в правильности выбора и синхронизироваться по ключевым вопросам. Это особенно важно, если впереди у нас длительный проект.
Страх: а что если я недостаточно тщательно подхожу к отбору? Давайте проведем еще два этапа собеседования. И лайвкодинг!
Чаще всего заказчики подходят к интервью с кандидатами очень ответственно — возможно, даже основательнее, чем к подбору сотрудников в штат. Обычная история: два этапа интервью по часу каждый, тестирование теоретических знаний, а на десерт — сеанс лайвкодинга, когда разработчик в реальном времени решает задачи под наблюдением 3-5 человек во главе с вице-президентом компании (ладно, здесь мы погорячились, но это не точно).
Вот пример из нашей практики. Далее со слов разработчика: «Первоначальное собеседование проводил телеграм-бот. Стартовал таймер, бот дал задачку академического уровня (а ты знаешь, как я не люблю академические задачи), в ответ нужно отправить ему код решения. Потом он в пяти разных формулировках уточнил, как работает код и что можно в нем улучшить. В результате определил мой уровень soft skills как низкий (как?!) и предложил пройти собеседование еще раз, но с живым человеком».
Все это напоминает анекдот:
В казарму новобранцев заходит лейтенант:
— Кто тут разбирается в электричестве?
— Я! — вскакивает один новобранец.
— Что закончил?
— МЭИ с красным дипломом.
— Сойдет. Будешь следить, чтобы свет выключали в 22:00.
Наш опыт показывает, что жесткость и неприступность отбора очень редко коррелирует со сложностью и престижностью проекта. Слишком завышенные требования приводят к тому, что заказчик из 20 подходящих CV едва ли пропускает одного кандидата.
Как не допустить?
Интервью должно быть адекватно задачам проекта. Если на следующий этап вашей воронки отбора проходит критически мало разработчиков, возможно, дело не в разработчиках? Попробуйте уточнить входные требования, чтобы получать более релевантные CV, или слегка ослабить гайки при отборе — так вы повысите конверсию и сэкономите свои ресурсы на подбор кандидатов достаточной для проекта квалификации (если задача все-таки нанять, а не создавать видимость работы).
Если вы делаете с подрядчиком уже не первый совместный проект и прошли вместе огонь и воду, не бойтесь прислушиваться к его мнению. Может, волнение разработчика не позволило ему раскрыться на собеседовании. Качества и способности своих сотрудников подрядчик знает лучше, чем вы после пары часовых интервью. Поэтому если кандидат формально не прошел ваш отбор, но подрядчик настойчиво просит дать ему шанс, не отказывайте в этом.
Взгляд со стороны клиента
Лайфхак в этой области: аккаунт, который работает от подрядчика, физически находится в офисе клиента, ходит на планирования спринтов, на груминги, ретроспективы и т.д. Этот человек понимает, чем живет продукт, какая у него культура, какие люди там работают. За счет такого глубокого погружения аккаунту достаточно легко подбирать новых участников в команду или производить замены — потому что он хорошо понимает, что нужно проекту.
На нашей практике было несколько случаев, когда мы настаивали взять разработчика, отклоненного после интервью, на тестовый период 1-2 недели. Если бы он не прошел испытательный срок, заказчик оплатил бы 50% стоимости — половину рисков мы забирали на себя. Но этого ни разу не случалось — разработчики всегда оправдывали доверие и оставались на проекте.
Еще одна рекомендация — обязательно давайте фидбэк после интервью. Это позволит дополнить ваши требования, а с последующими кандидатами с большей вероятностью все сложится, так как подрядчик будет знать, что для вас особенно важно.
Александр Морозов, руководитель центра компетенций Росбанка
Вряд ли нормальный вендор будет пытаться подсунуть джуна вместо мидла или синьора и рисковать испортить отношения, а еще и тратить силы на такой микроменджмент. Плюс, это ничем не отличается от ситуации, когда с рынка приходит человек и рассказывает, что он синьор. Риск того, что такой неквалифицированный сотрудник проскочит, несущественно отличается от варианта с рынка, и на интервью все также будет ясно видно, в том числе и попытки вендора заранее подтянуть знания специалиста под профиль запроса.
В команде прибавление. Начинаем работу!
Страх: а как я подключу к проекту сразу 10 человек? У меня же все сломается. Помогите!
Онбординг аутстафф-специалистов и штатных сотрудников ничем не отличается. Им точно так же необходимо ознакомиться с регламентами, подходами, требованиям к работе, таск-трекером и т.д.
Если на проект заходит не один сотрудник, а сразу целая команда, это действительно может создать нагрузку на тимлидов, архитекторов, менеджеров со стороны клиента. И тут важно не допустить хаоса, когда в ручном режиме, открываются доступы, пересылаются документы, разработчики стучатся к разным людям и добывают нужную для них информацию.
Как не допустить?
Заранее подготовьте чек-лист для онбординга (или возьмите наш готовый шаблон) — там должна быть информация, кто за что отвечает, где брать доступы, ссылки на нужные документы и прочее. Например, вот такой список:
Доступы (VPN, API, репозитории, Postman, Swagger и т.д.)
Описание структуры команды. По каким вопросам к кому стоит обращаться?
Инструкция по настройке dev окружения проекта.
Бэклог задач для новых разработчиков, с обозначенными приоритетами, если известны.
ТЗ на разработку (включая UI-кит, макеты и ссылки на Figma, требования к поддержке браузеров).
Документация на существующий функционал.
Правила коммуникации (чат в Телеграме, почта, Google-календарь, таск-трекер, форма отчетов, принятые точки контроля — например, еженедельные созвоны). Разработчик должен понимать, где и каким способом запросить уточнения по задаче, как решаются спорные вопросы, в каком виде он должен отчитываться о проделанной работе.
Дедлайн и этапы проекта с примерным описанием результатов по каждому этапу для корректировки сроков.
Если у вас есть свои метрики, методы оценки эффективности, системы управления проектами — обязательно донесите их до подрядчика на старте. Обе стороны должны знать правила игры, чтобы синхронизироваться в ожиданиях. Тогда отчетность будет точно заполнена так, как нужно, а эффективность специалиста оправдает ваши ожидания.
Факт: Наши внутренние исследования показывают, как грамотный онбординг повышает уровень удовлетворенности разработчика проектом до 20%, что благоприятно сказывается на его вовлеченности.
Екатерина Снегирёва, E-commerce Content Product Owner в AliExpress
Оптимальный вариант — это две встречи. Первая — установочная, когда мы рассказываем о продукте, его ценности, обсуждаем будущие задачи, делимся документацией, отвечаем на вопросы. Чтобы человеку был понятен, а главное интересен проект, которым ему предстоит заниматься.
Вторая встреча — организационная, когда техническая команда помогает получить нужные доступы, понять, где что лежит, куда и по каким правилам коммититься, как выглядит архитектура продукта, рассказывают какие-то особенности и так далее. Если ребята живут в общей парадигме процессов команды, то онбординг получается легким и быстрым. Вначале они работают чуть медленнее, но в процессе ускоряются и вливаются в единый поток. Конечно, внутренняя команда может на старте негативно оценивать внешних «новичков» — это нормальный процесс, который обычно органично решается на уровне техлида и в каких-то ситуативных коммуникациях.
Страх: а что если аутстафферы будут работать слишком медленно? Что тогда делать?
На старте проекта производительность труда сотрудников только набирает обороты — это относится и к штатным бойцам, и к аутстафф-командам. Не спешите формировать свое мнение, пока идет настройка процессов. Опытные подрядчики знают, что все потенциальные проблемы обычно проявляются в первые недели, поэтому особенно внимательны к проекту в начале.
Взгляд со стороны клиента
Срок, по итогам которого можно делать выводы о сотруднике, сильно зависит от роли. Например, дизайнер или тестировщик показывает результат быстрее — обычно уже после двух спринтов. По факту, мы готовы смотреть на сотрудника до трех месяцев и не рубить с плеча. Если не подходит, просим заменить и все. Но такое происходит не часто.
Но что делать, если период адаптации остался позади, а разработчик не показывает нужных результатов?
Как не допустить?
Основное правило здесь одно — не тяните с обратной связью. Обсудите с подрядчиком, что пошло не так и почему нужный результат не достигается? Верные действия с его стороны: провести аудит, побеседовать со своим сотрудником и выявить слабые места. После этого вы вместе решите, что делать: заменить сотрудника или устранить те самые слабые места.
У нас был случай, когда клиент пришел и сказал, что снимает одного разработчика с проекта. Разбираться ни в чем не хотели — «нет и все». Когда выяснили причину, оказалось, что между нашим разработчиком и другим участником команды возник конфликт, который мешал общему делу. Мы предложили переход разработчика в другую команду в рамках этого же проекта и две недели испытательного срока. В итоге разработчик провел на проекте еще четыре месяца, до самого его завершения.
Если не стоит вопрос с мотивацией и вовлеченностью, а технические скиллы на достаточном уровне, ищите другие причины неэффективности — они могут быть неочевидными с первого взгляда. Разработчиков на рынке мало, но хороших менеджеров и коммуникаторов еще меньше, особенно в условиях когда все работают удаленно. Как показывает практика, тупиковых ситуаций почти не бывает, и если реагировать вовремя, положительный эффект обязательно будет.
Вот еще несколько рекомендаций, которых помогут сохранять хороший темп и качество работы:
Прогноз временных затрат по задачам должен проверяться вашим менеджером, так как он обладает полной картиной проекта и может вовремя заложить риски.
Квалификация разработчика должна соответствовать задачам. Не давайте мидлу задачи уровня техлида. Но постепенно повышать сложность задач, чтобы сотрудник показывал рост — отличная практика.
Еще не добавили менеджера со стороны подрядчика в рабочие чаты? Сделайте это прямо сейчас!
Чтобы избежать риска накрутки часов, уточните, работает ли специалист только на вашем проекте или совмещает его с другими? Мы в Холивеб придерживаемся правила: один разработчик — один проект, чтобы не снижать эффективность из-за постоянного переключения контекстов.
Екатерина Снегирёва, E-commerce Content Product Owner в AliExpress
Первое, на что я обращаю внимание, — человек не закрывается от общения, выходит на связь и доступен, чтобы команда могла как минимум выйти с ним на связь и в целом найти общий язык в последствии. Эффективность работы оценивается внутренней командой по объему работы и качеству кода. Техлид дает оценку, насколько результат работы внешних специалистов соответствуют нашему запросу, гайдлайнам, выполняется ли запланированный объем работы. Первые четыре двухнедельных спринта обычно дают понимание, как ребята вошли в процесс — и по их итогам мы принимаем решение, как работаем дальше.
Страх: а что если аутстафф-сотрудники не такие мотивированные, как наш родненький инхаус?
Наш опыт показывает, что аутстафф-сотрудники обычно даже более мотивированы, чем инхаус-команда, так как настроены достигнуть конкретный результат на относительно короткой дистанции — например, успешно завершить проект за 3-4 месяца.
А вот если оставлять своим сотрудникам самые интересные задачки, а аутстафферов подключать только тогда, когда все горит или сломалось, может случиться и снижение мотивации, и даже выгорание. Но вы же не не злоупотребляете этим?
Как не допустить?
Выполняйте обещания, которые вы дали разработчикам — относитесь к ним в этом вопросе так же, как к своим сотрудникам. Все, что вы рассказываете на интервью, не должно расходиться с реальностью. Например, если вам требуется работа с большими объемами legacy-кода трехлетней давности, не стесняйтесь сказать об этом прямо — с такими задачами тоже работают, но человек должен понимать, что его ждет.
Не бойтесь давать аутстафферам больше свободы и задач серьезного уровня. Поддерживайте баланс между рефакторингом и разработкой фич, которые позволят разработчику становиться лучше. Работа «в стол» тоже никого не мотивирует — если ты трудился над фичей, которая не пошла в продакшн, это обижает и демотивирует — даже если работа была оплачена.
Не поощряйте переработки, даже если сотрудник сам проявляет инициативу и очень увлечен проектом. Лучше долгая и стабильная работа с ровной производительностью, чем вспышки продуктивности, чередующиеся с провалами в результативности и мотивации.
Александр Морозов, руководитель центра компетенций Росбанка
Важно разговаривать с человеком, а не скатываться в бюрократию. Иначе у сотрудника может сложится впечатление, что он попал во враждебную среду. На моем прошлом месте работы мы даже внедряли программу наставничества: чтобы полчаса в день утром и полчаса вечером уделять своему подопечному в виде обязательной беседы. Все это применимо и к аутстафферам, потому что они такие же члены команды.
Реальность такова, что сегодняшний аутстаффер через год-два может стать твоим штатным сотрудником (даже если ты этого совершенно не предполагаешь), и надо сразу относиться к нему как к своему человеку. Также важно понимать, что покинувший компанию аутстаффер с негативным осадком рассказывает об этом везде, формируя репутацию компании заказчика. Как ты потом будешь доказывать, что это именно потому, что это был аутстаффер? Да и, скорее всего, только хуже будет.
На моем опыте работы с 70-80 аутстафферами не могу припомнить, чтобы кто-то из них не был мотивирован — все относились к работе как к своей. На мой взгляд, аутстаффер плохо работает, если он плохой работник, а не из-за того, что он аутстаффер.
Страх: а что если специалисты не делают мой проект, а целыми днями играют в Доту? Я же не вижу, чем они там занимаются
Инхаус-команда дарит сладкое ощущение полного контроля над ситуацией — вот люди, которые сидят в офисе на глазах у начальника и каждый день трудятся на благо предприятия.
Аутстаффинг же предполагает, что клиент берет на себя ответственность за то, чтобы загрузить разработчика, который сидит в чужом офисе, а то и в другом городе. При этом оплачивается каждый его рабочий час. Абсолютно естественно желание иметь полный контроль над процессом и расходовать средства рационально.
А еще контракт часто предусматривает оплату простоев, то есть выкуп всех рабочих часов команды в заданный промежуток времени.
Однажды мы работали в команде со специалистом от другого поставщика и стали свидетелями интересной ситуации. Так получилось, что менеджмент на стороне клиента забыл про этого разработчика и не давал ему задач в течение двух недель. Поставщик почему-то решил промолчать и попросить оплату в полном размере. Эта ситуация вынудила клиента пересмотреть правила оплаты простоев.
Сложно здесь что-то комментировать, потому что на уровне внутренних регламентов поставщика возможность этой ситуации должна быть исключена. Тем не менее, как выяснилось, существуют и такие варианты развития событий.
Как не допустить?
2020 год показал всем нам, что удаленка — это не больно и не страшно. У опытных компаний, которые давно практикуют такую модель, есть все регламенты и процедуры, чтобы контролировать продуктивность сотрудников хоть в Москве, хоть в Сызрани, хоть на Бали. Вот стандартная процедура работы для аутстаффа: команда выполняет задачи по бэклогу, который формирует заказчик. Разработчик трекает потраченное на каждую задачу время. Отчетность сдается в конце месяца, после согласования происходит оплата. Ее размер зависит от трудозатрат, то есть заказчик может посмотреть, на какую задачу сколько затрачено часов, и сопоставить это с историей коммитов (порций) кода. Все прозрачно: понятно, куда потрачено время, а разработчик не страдает от того, что Большой Брат все время следит за ним.
Никита Лебедев, Product Owner в Сбер
Прежде чем разработчик принимает какое-то важное решение, мы синхронизируемся, обсуждаем и решаем. Нужны процессы, скрам или его модификация, дэйли, груминг, ретро — неважно, удаленные у тебя исполнители, привлек ты аутстафферов на месяц или они твои инхаус.
Измеряем эффективность — если оценили фичу в две недели, а делали месяц, то собираемся на ретро и обсуждаем, почему так произошло, какие проблемы и как это исправить.
Важно понимать, что формирование бэклога происходит на стороне заказчика. Поэтому если у вас возникают сложности с постановкой задач или вы не успеваете загрузить аутстафф-команду, не стесняйтесь обратиться к аккаунт-менеджеру подрядчика — обсудите и решите, что делать.
Если ваши прогнозы по загрузке не сбылись и полный объем часов не востребован, здесь есть несколько вариантов действий:
Профилактика. Разработчик (команда) прогнозирует свою загрузку и заблаговременно информирует об этом вашего менеджера. Проактивность — наше все.
Оплачивать часы простоя с дисконтом, чтобы разделить нагрузку пополам. Таким образом за вами сохраняется бронь команды, а поставщик закрывает свои косты, чтобы не работать в минус.
Сокращать команду и выкупать объем, равный текущей потребности. Обычно заявки подписываются ежемесячно, что позволяет регулярно пересматривать планы и корректировать свой объем обязательств.
Денис Самбудагва, Product Manager в Delivery Club
Если вы инхаус разрабатываете бэкенд, а фронтендом занимается внешняя команда, то надо понимать, сможете ли вы работать синхронно. Мы сталкивались с ситуацией, когда подрядчик почти закончил приложение, а наш бэкенд сделал API только на 50%. Чтобы не расходиться в сроках и ожиданиях, важно заранее договариваться и предупреждать, если разработка задерживается.
Страх: а что если у меня украдут конфиденциальные данные и продадут конкурентам?
Есть ощущение, что внутри команды всегда проще сохранять конфиденциальность. Но при правильном подходе к организации процесса на аутстаффе без проблем можно добиться тех же результатов.
Как не допустить?
Распространяйте на аутстафферов все механизмы контроля, принятые в команде. Бюрократизируйте процесс передачи конфиденциальных данных, их хранение и утилизацию. Используйте специализированное ПО для защищенного подключения сотрудников (например, Citrix).
Для доступа к сервисам заказчика обычно используется VPN, что обеспечивает безопасное соединение с корпоративной сетью и позволяет пользоваться сервисами заказчика (Jira, Gitlab, Bitbucket и другие внутренние сервисы). В некоторых случаях для подключения к VPN используется только логин и пароль, в других — двухфакторная идентификация с помощью специального устройства (токена).
В крупных организациях, где конфиденциальность данных особенно важна (например, в банках) обычно есть служба безопасности и собственный софт, который обеспечивает возможность удаленного подключения. Как правило, это не вызывает никаких критических сложностей, и у подрядчика нет причин не пойти навстречу и игнорировать ваши регламенты по безопасности. Также аустафф-разработчика могут оформить на 0,1 ставку, чтобы допустить к внутренним информационным системам.
Александр Морозов, руководитель центра компетенций Росбанка
В частных компаниях к этому относятся проще, чем в банках. У нас же этими вопросам занимается служба безопасности. Как и везде, они устанавливают Citrix, который обеспечивает безопасный доступ к внутренним приложениям..
Чтобы обеспечить сохранение конфиденциальности, подписывайте с компанией и с каждым из сотрудников NDA. Указывайте в договоре штрафы за разглашение информации.
А мы с вами до конца? Как сделать так, чтобы мы оставались счастливы вместе
Релиз отправился на продакшн, цикл завершен — и вот у вас появилась новая ачивка «сделать проект руками аутстафферов». Теперь у вас есть проверенный поставщик ресурсов, который понимает ваши требования и особенности. Расширяйте взаимодействие и достигайте новых результатов. Но что, если…
Страх: а что если подрядчик меня бросит? Выйдет из проекта или заберет половину команды!
Причины могут быть разными:
Не ясно, насколько долгосрочным будет ваше сотрудничество. Подрядчику важно прогнозировать загрузку, и длинные контракты, где обе стороны договорились, на какой период рассчитана их совместная работа, всегда будут выигрывать у тех, где перспективы туманны. Поэтому никогда не стесняйтесь рассказать о совместных планах и будущих проектах.
Разработчик увольняется из агентства. Такое бывает. Здесь важно, чтобы подрядчик обеспечил процесс передачи знаний — например, договориться о периоде, когда предыдущий разработчик будет консультировать нового члена команды.
Вы хантите людей подрядчика. Не надо так. Веб-продакшны в любом случае теряют много людей, который органически уходят на рынок на сторону клиента и в другие компании. Да и будет ли вам выгодно забрать одного разработчика в штат и лишиться еще пятерых, которые останутся у подрядчика?
Не индексируются ставки. На очень длинных проектах ставки специалистов могут расти, так как повышаются заработные платы (осень 2020 показала, как стремительно это может происходить). Поэтому к аутстаффингу стоит относиться как к HR-процессу, а не как к закупке товаров. Цепочка здесь очень простая: вы не проиндексируете ставку — поставщик не сможет увеличить зарплату своему сотруднику — сотрудник уволится и вы его потеряете. Поэтому если вы планируете работу на очень долгой дистанции, обратите внимание, прописан ли этот пункт в договоре.
Культура аутстаффа пока только складывается, заказчики и подрядчики вместе строят правила эффективной работы. Но спрос на такой тип услуг растет с невероятной скоростью — а значит, мы должны как можно быстрее формировать культуру взаимодействия. В этом материале мы постарались обобщить собственный опыт, чтобы развеять страхи, избавиться от стереотипов и дать клиентам инструменты по отработке самых распространенных рисков.
Желаем удачи в выстраивании win-win-взаимодействия!
Есть что дополнить? Напишите в комментариях или мне в telegram, с какими страхами и рисками вы сталкивались? Какие дали бы рекомендации? Конструктивные комментарии по теме попадут в обновленную статью.
