Жду новый пост

Серия «Timeweb Cloud»

Еще 20 лет назад, когда только запустили первое облако LaaS, многим казалось, что облачный и локальный сервер – это как небо и земля. Спустя время опросы показывают, что пользователи перестали замечать разницу между двумя средами. А выбор сервера по большей части зависит от потребностей конкретного бизнеса. Кто-то сразу останавливается на одном из вариантов, а кому-то приходиться пройти немалый путь, чтобы найти свое. Хочу, чтобы у Вас сразу сформировалось четкое представление о двух средах, поэтому прошу под кат.

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

Отсутствие первоначальных вложений

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

Увеличение или уменьшение мощности

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

Наличие сертификации у поставщика облачных услуг

Данные на сервере хранятся во многих видах деятельности и в таких сферах услуг, как образование, медицина, финансы, энергетика и т. д.. Чтобы обезопасить клиентские данные, для каждой сферы были разработаны свои стандарты и требования. И поставщик, который предлагает услугу, должен им соответствовать. Соответственно, клиенту не приходится обращаться к сторонним агентствам по сертификации и услугам внутренних IT-аудиторов.

Безопасность

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

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

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

Затраты на локальный и облачный сервер (без цифр)

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

Локальный сервер

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

Как происходит с облачным сервером?

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

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

Защита данных

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

Безопасность на физическом сервере — ответственность только на вас

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

Защита данных на облачном сервере — репутация поставщика

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

Доступность данных

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

Локальное размещение сервера

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

В облачной среде

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

Доступ к данным

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

Локальный сервер

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

Облачный сервер

Здесь весь процесс контролируют облачные провайдеры, и вы не сможете погрузиться в него на 100%. Но и сейчас происходят изменения на рынке. Компании, предлагающие услуги облачного сервера, стали принимать принцип «прозрачности». Таким образом, клиенту предоставляется документация с данными по внешнему аудиту, оценке безопасности и тд. Это формирует доверительные отношения между продавцом и покупателем.

Резервное копирование

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

Локальный сервер

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

Облачный сервер

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

Масштабируемость

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

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

Локальный сервер

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

Облачный сервер

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

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

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

Оригинал

Подписывайтесь на наш блог, чтобы не пропустить новые интересные посты!

Приветствуем, дорогие читатели. Мы живем в непростые для IT-отрасли времена и можем сегодня наблюдать некоторый кризис на рынке хостингов. Если говорить вкратце — всё грустно. Но печаль и паника — не наш выход, а потому не спешите закрывать статью и погружаться в тяжелые размышления. Цель этого материала не напугать, а в том, чтобы максимально понятно донести и разъяснить обстановку, в которой мы оказались, а также дать парочку-другую советов и предоставить инструменты, дабы выйти из этой непростой ситуации с минимумом потерь.

Итак, пройдемся по некоторым неприятным фактам и причинам, соответственно:

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

2. Идёт сокращение количества предприятий малого и среднего бизнеса. Для любой экономики это плохо, для российской — особенно.

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

4. Закрытие части рынка различного рода конструкторами и no\low-code решениями. То есть идёт, скажем так, стандартизация рынка, за счёт более простых инструментов по созданию своих проектов. Порог входа существенно упал, а с ним и качество. Если раньше для создания сайта нужно было нанять программиста и дизайнера, то сейчас достаточно зайти на сайт по созданию сайтов и получить готовый продукт.

5. Идёт стагнация доменной зоны ru/рф. Как следствие, мы не можем видеть качественного роста рынков сбыта нашей продукции не столько в России, сколько за её пределами.

Количество веб-сайтов и одностраничников на доменах ru/рф сократилось по сравнению с мартом 20 на 4,3% (-120 тыс. доменов). Здесь всё просто — хостинговые компании теряют своих клиентов, рынок идёт на спад.

6. Так как рынок стагнирует, ценовая конкуренция между его лидерами растёт. Но в тоже время из-за кризиса (о котором ниже), маржа маленьких хостингов просела до нуля или вообще ушла в минус. К тому же, они просто не в состоянии конкурировать с гигантами отрасли.

7. Мы наблюдаем рост только в IaaS (инфраструктура как услуга от англ. Infrastructure-as-a-Service). То есть в виртуальных серверах с чётко заданной вычислительной мощностью. Но проблема в том, что мелким игрокам виртуального хостинга очень сложно потянуть создание и подъем необходимой инфраструктуры, так как для старта требуются весьма большие инвестиции. Более подробно об этом рассказано здесь.

В чём заключается текущей кризис?

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

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

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

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

Как вообще работают хостинги на рынке?

Несмотря на попытки импортозамещения, РФ всё ещё во многом зависит от западных стран. Это особенно остро чувствуется в ситуации с программным обеспечением. Большая часть российских хостингов использует западное ПО (CPAnel, DirectAdmin, ISPsystem). Это влечёт за собой соответствующие риски, а конкретнее:

— ПО, находящееся в облаке, а не на физическом носителе, могут просто заблокировать;

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

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

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

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

В новом выпуске подкаста «Релиз в пятницу» Миша Шпаков, Кира Айрапетова, Олег Филимошин обсудили грейды: когда, кому, зачем они нужны и как эффективно их использовать.

Если коротко, вот что я выделила для себя:

- Грейд — структура, позволяющая привязать зарплаты в компании к навыкам и задачам сотрудников.

- Грейды нужны не всем компаниям.

- Грейды не только про hard-skills.

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

- Грейды могут быть вертикальные и горизонтальные.

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

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

Миша Шпаков — dev тимлид VDS.
Кира Айрапетова — руководитель HR в Timeweb.
Олег Филимошин — архитектор Timeweb Cloud.

Миша Шпаков (МШ): Всем привет, это подкаст «Релиз в пятницу» от компании Timeweb. Сегодня мы поговорим о грейдах в IT и не в IT-компаниях. Нужны ли они? Что это такое? И как с этим жить? Меня зовут Миша Шпаков, сегодня мне помогут Олег и Кира. Представьтесь, пожалуйста, и расскажите о себе.

Олег Филимошин (ОФ): Меня зовут Олег Филимошин, я работаю архитектором облака в Timeweb. Я застал много всяких вариаций того, как оценивать скилы разработчика, сам принимал участие в составлении программ и проектировании процесса оценки специалистов, поэтому я постараюсь чем-то поделиться.

Кира Айрапетова (КА): Меня зовут Кира Айрапетова, я работаю руководителем HR-отдела компании Timeweb. Я занималась в течение своей карьеры и доработкой грейдов, и разработкой грейдов, поэтому тоже хотела бы поделиться мыслями на этот счет.

МШ: Класс! А вообще, какое-то непонятное слово «грейд», что это такое?

КА: По сути, это структура для оценки снизу доверху. Началось это где-то в конце ХХ века, когда люди, которые управляли компаниями, поняли, что выдавать зарплаты из воздуха — это не очень удобно. Поэтому они придумали систему грейдирования. И мы все, особенно в IT, на ней едем по сей день.

МШ: Слушай, а вот джуниор, мидл, синьор — это оттуда?

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

МШ: Слушай, а вот ты начала говорить, что это используется для мотивации — только для мотивации или есть еще какие-то причины внедрения грейдов?

КА: Для введения грейдов существует несколько причин. Грейды полезны как бизнесу, так и разработчикам или другим сотрудникам, но мы IT-компания, так что будем говорить о разработке и о разработчиках.

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

У нас есть грейд, скажем тот самый, не очень удачный «джуниор / мидл / синьор».

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

Какое-то общее понимание, что такое «джуниор / мидл / синьор», может быть похожим от места к месту.

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

Тот, кто в одном месте синьор, в другом может быть джуном, и наоборот. Бывают люди, которые говорят: «Я джун, я вообще ничего не знаю, меня не повышали 20 тысяч лет, я, наверное, совсем дурак» А потом он приходит и пилит архитектуру. Такое тоже бывает.

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

Еще существует бюрократическая история — карта компетенций, карта развития сотрудника. Это хорошо, но сложно. У разработчиков все немного проще: есть, допустим три грейда — что ты должен сделать, чтобы подняться на следующий, есть perfomance review, ты должен его пройти.

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

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

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

ОФ: Я тоже хотел добавить. На самом деле, хорошо, если эти грейды прописаны.

А то приходишь в компанию, а там все на каком-то «подсознательном уровне» чувствуют, кто они есть и куда им двигаться. Потом осознанные люди начинают задавать вопрос «А куда я развиваюсь?» и всё рассыпается. Так что очень хотелось бы, чтобы грейды были прописаны. Хотя бы в Confluence.

КА: Мне кажется, документация нужна всегда и везде, хотя бы в минимальном количестве.

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

ОФ: Сам по себе, в отрыве от других процессов, грейд — это не система мотиваций. Я хотел вкинуть мысль, которую нам следует обсудить — а только ли хард скиллы входят в грейды?

ИП: Нет. Я уже говорила, что джуна, мидла и синьора друг от друга отличает инициативность и самостоятельность. Это как раз про социальные навыки. Они везде почти одинаковые, но их тоже надо прописывать.

ОФ: Очень хорошо, если эйчар знает и умеет это использовать.

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

Позже IT-отрасль в России стала развиваться и появлялись осознанность и осмысленность. Появились процессы по пересмотру уровня и зарплаты. Часто шел запрос на повышение уровня и з/п от разработчиков, так как они не развивались. Люди хотели не просто денег, но еще и расти в своей специальности.

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

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

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

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

КА: Да, есть люди, которые после нормально фидбэка возвращаются на собеседование, подтянув свои навыки.

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

Грейды — это инструмент, который не всегда подходит в контексте. Бывает контекст, когда у тебя кросс-функциональная команда, здесь неплохо подходит механизм с ролями.

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

Не все сеньоры могут менторить. Люди могут не уметь, не хотеть или не знать, что так можно. Поэтому мы ввели роль ментора. Это было формализовано, ты мог найти карточку сотрудника-ментора и узнать, с развитием каких компетенций он может помочь. У нас появилась внутренняя платформа для обучения (менторства). И появилась она благодаря тому, что мы это прописали, проговорили и рассказали остальным.

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

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

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

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

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

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

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

Грейды — отличный инструмент, если его применять правильно. Если вводит грейды, которыми ты собираешься кошмарить людей, то получишь отток сотрудников. Грейды — это мотиватор, помощь компании и очень удобный инструмент оценки, чтобы двигать человека дальше, что выгодно обеим сторонам.

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

ОФ: Также можно сравнить несколько кандидатов.

ОФ: Кто придумывает грейд в компании?

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

И грейды должны периодически пересматриваться, так как рынок очень подвижный. Следовать грейдам, которые написаны 2 года назад бесполезно. Это закладывают при разработке грейдов.

МШ: Давайте попробуем разобраться. У нас есть общепринятая практика на рынке. Есть три уровня специализации и кажется это очень мало.

КА: Что такое джун/мидл/синьор. Это три позиции, которые человек будто бы должен в своей жизни занимать. Есть еще тимлид. Хорошо, 4.

ОФ: Это странно, словно обязательно ты должен в тимлида вырастать.

КА: Ну да, будто менеджерская — это обязательно. На самом деле, нет. Если ты не хочешь заниматься менеджерством, это тоже допустимо. Джун/мидл/синьор — очень узко профилированная оценка, она не дает широты понимания всех навыков сотрудника.

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

В идеале грейды должны быть многоуровневые, должны быть грейды в глубину и в ширину.

Допустим, сотрудник знает PHP на 10/10, JS на 5/10, еще знает базы данных, может работать с продуктами. Для грейда конечная цель — не только развитие, но и зарплата. Она должна складываться не только из того, что ты сеньор на PHP, но и из других навыков. Так, по моему мнению, должны выглядеть хорошие грейды.

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

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

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

КА: Это вопрос очень высокой самоответственности.

ОФ: И вопрос масштабирования. Для компании в 400-500 человек, это звучит почти нереально.

МШ: Как компании понять, что она готова к внедрению грейдов? Как это определить?

ОФ: Первое — у компании нет грейдов (смеется).

КА: Есть какие-то маркеры.

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

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

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

МШ: Вы проговорили социальные навыки, роли, конкретные обязанности. Куда мне как специалисту расти, если я уже условно «сеньор», например?

КА: Можно в менеджеры. Это максимально про социальные навыки. Если ты хочешь управлять людьми, ты можешь — тогда ты это делаешь.

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

МШ: Но если я сеньор, то предполагается, что я уже на максимальном уровне и зарплаты и какого-то развития своей компании.

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

ОФ: Все зависит от компании. Если в твоей компании специалист видит, что у разработчиков зарплата n-я, а у всего менеджмента nx2, то разработчик рано или поздно догадается, куда идти.

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

МШ: А как правильно показывать, какой у тебя грейд, надо ли делать его открытым? Чтобы я знал, допустим, что у Васи такой-то грейд, такой-то уровень и такая-то зарплата или это должно быть закрыто?

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

ОФ: Но все же это основная причина. Рынок труда сейчас — это биржа. Разработчики одного и того же уровня с разницей в 2-3 месяца взятые на работу, к сожалению, получат, скорее всего, разные зарплаты.

КА: Вопрос открытости — вопрос частный. От бизнеса к бизнесу. Кого-то это привлечет, а кого-то оттолкнет.

ОФ: Тут есть проблема. Разработчик может прийти за повышением зарплаты, так как у «соседа» другая зарплата. Он задается вопросом «чем я хуже?». Зарплата используется как инструмент оценки.

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

МШ: Как правильно проводить скоринг специалиста?

ОФ: Я не уверен, что есть такое понятие «как правильно». Нельзя ответить, как правильно. Бывает как лучше, исходя из конкретных задач.

МШ: Допустим, мы в Timeweb вводим сетку грейдов, чтоб оценить своих сотрудников. Что я как тимлид должен сделать?

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

ОФ: Возможно Миша спрашивает про то, как этот процесс непосредственно организовать?

МШ: В том числе. На самом деле, есть несколько вопросов. Давай с этого начнем.

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

МШ: А если мы говорим об инструментах для оценки? Допустим, мы провели опрос 360. Это все равно нацелено на субъективную оценку тимлида, одного человека, который принимает решение. Или нет?

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

КА: Это люди принимающие решение, но у них должны быть компетенции на принятие этого решения.

ОФ: Хочу добавить, что обычно это стоит очень дорого. Раз в полгода какие-то ключевые лица от работы отстраняются, они занимаются ревью около месяца, в зависимости от размера компании. В итоге из полугода, человека занимается основными рабочими задачами только 4-5 месяцев. Это приводит к тому, что в какой-то момент начинают оценивать раз в год, качество ревью падает. Нужно искать баланс и выбирать такой процесс, чтобы это не затягивать, не превращать в дорогое бесполезное удовольствие.

МШ: Есть ли еще что-то помимо грейдов, что позволяет правильно работать с сотрудниками и мотивировать их?

ОФ: Лучший способ — это хорошая развитая обратная связь в команде.

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

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

КА: Это действительно вопрос хорошей коммуникации между руководителем и командой.

ОФ: Это вектор, куда стоит двигаться. Грейды — это способ прийти к нормальному фидбэку через формальный процесс.

МШ: Как часто надо устраивать performance review?

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

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

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

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

МШ: Я для себя узнал очень много сегодня и очень интересно было с вами пообщаться.

В итоге, что грейд — это очень крутая штука, если использовать правильно. Они нужны не всем компаниям, компания сама должна понять что ей нужно — грейды или что-то другое.

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

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

Источник: https://habr.com/ru/company/timeweb/blog/579204/