Разговорный английский для онлайн-встреч: 40 полезных фраз

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

Я преподаю английский для делового онлайн-общения более 15 лет и готова поделиться важными фразами на английском языке, которые помогают студентам провести встречу без лишнего напряжения и сосредоточиться на теме встречи, а не на волнении о своих коммуникативных способностях. Я просмотрела более 200 видео из IT-каналов на Youtube, чтобы выбрать 40 актуальных фраз, которые будут уместны при проведении встречи и внезапных технических проблемах. Англоговорящие коллеги с легкостью поймут вас и вы будете чувствовать себя увереннее. 

Как провести  встречу. «Один. Два. Три. Поехали»

Когда у вас запланирована встреча один на один, а участников больше 5, 10 или 15 человек, организатору становится сложнее контролировать их статус: кто опаздывает, кто только присоединяется, проверить присутствие важного сотрудника.

Фразы, которые плавно, но решительно переводят тему small talk ближе к делу:

Do we have Andrew on the call? 

Let’s get down to business, shall we?

Ok, let’s kick off. 

«Кто говорит? — Слон»

Бывает так, что один из участников включает микрофон и начинает отвечать на вопрос, а нам неловко спросить, кто это. Поэтому перед своим выступлением следует представиться:

This is Andrew.

It`s Andrew here. 

Перебивать или не перебивать собеседника?

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

Sorry to interrupt,..

Just (want) to interject here…

Can I cut in here for a second?

Если перебивают вас, вы остановились и сигнализируете свою готовность выслушать фразой: 

Go ahead.

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

1) Вы потеряли мысль;

В этом случае “Where was I?” вернет туда, где остановились.

2) Выполняете какие-то действия на экране и автоматически замолкаете.

Начните комментировать свои действия:

I’m going to switch over to the [Internet Explorer] now.

Please bear with me while I’m doing it/ switching to it.

Как закончить встречу

 Завершить собрание можно фразами:

We’re just about out of time.

So we’re going to wrap up.

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

Sorry, I have to jump to another call.

I’ve got a hard stop at 2 o’clock.

Как сообщить о технических неполадках

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

Sorry, I‘m having some technical difficulties here.

Затем, в зависимости от типа проблемы, прокомментируйте ситуацию со своей стороны.

Проблема с интернетом

Если соединение нестабильное, сообщить об этом можно так:

My internet connection seems to be slow. 

Please bear with me while the page is loading — it might take a few minutes.

I think there’s a problem with the Internet at my end. 

Не могу войти или подключиться к встрече

Эти фразы пригодятся, если вы или собеседники неожиданно отключились от собрания:

Sorry, guys, I got cut off.

Did we lose Andrew (again)? Hello?

Проблема с изображением

В этом случае воспользуетесь следующими фразами в зависимости от проблемы:

Your video is lagging.

The screen is blank.

You are  frozen.

Проблема со звуком или микрофоном

Выберите подходящие фразы:

The image and sound are out of sync.

You’re breaking up a little bit.

There’s a bit of an echo on the line.

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

Sorry guys. I was on mute.

Andrew might be on mute. 

Если плохо слышно собеседника, предложите предпринять следующие действия:

Could you speak up a bit, please?

You’re a little bit quiet. Could you speak closer to the microphone?

Пока вы решаете технические проблемы, попросите собеседников подождать:

Hold on a minute.

Потом прокомментируйте свои действия:

I`m  trying to fix it now.

Just a second, I’m going to turn the volume up.

Let me start over again.

И проверьте результат:

Is that better now?

Yes, it`s fine now.

Yes, you are back now.

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

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

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

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

Практическое задание 1.

1) Вставьте пропущенные слова. Количество черточек совпадает с количеством букв в пропущенном слове. 

1)   Ok, let’s _ _ _ _  off.

2)   _ _ _ _ is Andrew.

3)   Just (want) to i_ _ _ _ _ _ _ _  here…

4)   _ _ ahead.

5)   Please _ _ _ _ with me while I’m doing it/ switching to it.

6)   So we’re going to wr_ _ up.

7)   Sorry, I have to _ _ _ _  to another call.

8)    Sorry, guys, I got c_ _ off.

9)    The image and sound are _ _ _ of sync.

10)    Sorry guys. I was _ _  mute.

11)    Could you speak _ _  a bit, please?

12)    Let me start _ _ _ _ again.

2) Проверьте себя, вернитесь в начало статьи и прочитайте полезные выражения.

Практическое задание 2. Крестики-нолики

Это задание можно выполнять индивидуально, либо в паре. 

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

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


Статья подготовлена Элеонорой Шибаевой в рамках набора на онлайн-курс «English for IT. Looking for international IT job». А всех желающих приглашаем на бесплатное открытое занятие «Техническое собеседование в зарубежную компанию». На вебинаре проведем демо-собеседование на английском языке. Вы сможете понаблюдать за тем, как оно проходит и задать волнующие вопросы. Разберем решение задач и дизайн системы на техническом интервью. Регистрация открыта по ссылке.


ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/696598/

Отец авиатора: как Говард Хьюз-старший сколотил свое состояние на патентах

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

Будущий миллионер родился 9 сентября 1869 года в городке Ланкастер, штат Миссури, в семье среднего достатка. Говард рос непоседой и доставил множество проблем своим родителям. Пытаясь привить своему сыну дисциплину, его отец, Джадж Феликс Хьюз, отдал отпрыска в Военную академию Миссури (аналог нашего суворовского училища). Закончив его в 1893 году, Говард поступил Гарвард, но проучился там меньше года. По настоянию отца он поступил в Юридическую школу Университета штата Айова. Там Говард в очередной раз проявил свой характер и сдал выпускные экзамены досрочно в Верховном суде штата Айова, а затем начал свою собственную юридическую практику. 

Как нетрудно догадаться, данное занятие пришлось молодому человеку не по душе. Говард Хьюз бросил юридическую практику и решил заняться реальным бизнесом. Он сменил множество городов, открыл и закрыл несколько фирм, но успеха ни одно предприятие так и не принесло. И вот судьба занесла его в Хьюстон, штат Техас. В самом разгаре была нефтяная лихорадка. На юге обнаружили богатейшие месторождения черного золота и несколько крупных корпораций начали дележ участков. Об этом написаны десятки книг и статей. Но, навероное, самое знаменитое произведение искусства на эту тему — Эптона Синклера «Нефть!». Именно по этой книге был снят фильм Пола Томаса Андерсона. 

Говард Хьюз увидел в этой битве алчных гигантов возможности для себя и своей семьи. В 1904 году он женился, а спустя год родился его сын Говард, будущий миллиардер. В 1908 году предприниматель вместе со своим партнером Вальтером Шарпом основал компанию Sharp-Hughes Tool Company. Тогда же были поданы заявки на два революционных патента: US930758A и US930759A. Это был бур, позволявший добывать нефть в ранее недоступных местах. В тех или иных вариациях он применяется до сих пор в этой сфере.

Не менее интересной была схема монетизации изобретения. Говард Хьюз-старший придумал не продавать производимые его компанией буры, а сдавать их в аренду по 30000 долларов за бурение одной скважины. От желающих отбоя не было. К 1914 году буры компании применяли 11 американских и 13 зарубежных нефтедобывающих компаний. Помимо этого, Sharp-Hughes Tool Company запатентовала несколько новых изобретений в этой сфере. Лицензионные отчисления также приносили немалую долю прибыли. В 1912 году партнер Хьюза, Вальтер Шарп, скоропостижно скончался, и бизнесмен выкупил долю фирмы у его наследников. С 1915 года компания стала называться Hughes Tool Company. В разгаре была Первая мировая война, а вскоре последовало и вступление в конфликт США, что означало увеличение потребности в нефти и увеличение количества скважин.

 Говард Хьюз-старший умер 14 января 1924 года от сердечного приступа в возрасте 54 лет. Незадолго до этого, в марте 1922 года, скончалась его супруга. Видимо, смерть жены и неустанная работа подкосили здоровье неутомимого предпринимателя. Своему сыну он оставил фирму стоимостью около двух миллионов долларов и патенты на изобретения. И здесь начинается совсем другая всем известная история. 

А наследница Sharp-Hughes Tool Company до сих пор существует на рынке и называется Baker Hughes. Разумеется, это совсем другая корпорация. Но ее корни уходят в нефтяную лихорадку начала прошлого века и патенты Говарда Хьюза-старшего.   

Дарим скидку 4000 рублей при первом обращении на любую услугу onlinepatent.ru

Промокод: LOVEHABR


ссылка на оригинал статьи https://habr.com/ru/company/onlinepatent/blog/696572/

Падающие проды, соискатели-мошенники, нейросети: собрали страхи разработчиков

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

Кирилл Кошаев, автор курса «Java-фреймворк Spring» в Skillbox:

“По долгу службы приходится сталкиваться с разными, я бы сказал, экстремальными ситуациями. Именно они и вызывают страх. Боюсь не успеть подхватить вовремя падающий прод, а еще больше — не успеть его поднять до того, как новость дойдет до генерального директора. Страшно обнаружить рухнувший на проде сервис за 5 минут до конца рабочего дня, особенно ошибки с тегом “timeout”. Получается из разряда “пойди туда, не знаю куда, принеси то, не знаю что” и приходится проверять всю цепочку логики. Ну, а самое любимое — звонок от топ-менеджмента в 5 утра. Скорее всего, клиент из Омска получил ошибку при запросе”.

Александр Чернов, руководитель управления информационных технологий “Много лосося”:

“У любого человека есть своеобразные профессиональные страхи, и это нормально. Лично я очень боюсь, что у кого-то в совете директоров окажется новый Google Pixel, на котором наше Android-приложение крашится. Мы уже в процессе исправления проблемы, но пока страшно. А в новых реалиях волнение вызывает потенциальный уход с российского рынка иностранного вендора, ПО которого используется в нашей системе. Особенно если это произойдет в пятницу вечером”.

Александр Сербул, руководитель направления контроля качества интеграции и внедрений Битрикс24:

“Главный страх разработчиков — просьба друзей починить технику. Многие думают, если ты работаешь с компьютером, следовательно, ты и мастер в ремонте. Хоть я сейчас и иронизирую, но иногда такие ситуации действительно случаются. Больше всего мы боимся ошибок в коде и риска потери данных. Но в отличие от навязчивых знакомых, от этой фобии можно избавиться. Разрабатывайте простые и понятные программы, ведь сложно не означает надежно. А чтобы быть уверенным на 100% — всегда пишите автотесты”.  

Глеб Михеев, CTO Skillbox Holding:

«У меня есть большой страх уйти в менеджмент, перестать кодить и спустя пару лет стать ненужным. Ведь HR звонят только разработчикам».

Александр Хакимов, Android Team Lead Grow Food:

“Страхи есть, причем как реальные, так и надуманные. Конечно, боюсь нанять не того человека. С учетом того, что команда у нас совсем небольшая, цена такой ошибки очень высока. И очень боюсь нейросетей. Вдруг они научатся “красить и двигать кнопочки” вместо меня”.

Николай Андреев, CPO “Кухни на районе”:

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

Алексей Некрасов (@znbiz), лидер направления Python в МТС, программный директор направления Python в Skillbox: 

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

Артем Воскобойник, старший Java-разработчик в компании “Метр квадратный”:

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

Даниил Пилипенко, программный директор направления “Backend-разработки” в Skillbox, директор центра подбора IT-специалистов SymbioWay:

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

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


ссылка на оригинал статьи https://habr.com/ru/company/skillbox/blog/696604/

Изучаем инструменты для работы с ARP протоколом

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

ARP основные данные

Address Resolution Protocol (ARP) — протокол, который позволяет определить MAC адрес устройства по известному IP адресу, хотя можно используя протокол просто собрать все данные о подсети.

Протокол уже известен почти 40 лет! (Рассматриваем IPv4 версию) Описание протокола находится в RFC 826. У RFC было несколько апдейтов, которые касались различных частей протокола, вот некоторые их них:

  • RFC 5227 — рекомендации по устранению проблем с конфликтами адресов, если несколько устройств используют один и тот же IP адрес,

  • RFC 5494 — описание расширений, которые можно использовать для работы с различными протоколами. Среди них: HYPERChannel, DHCP options, ATM ARP, HARP, Dual Mac FDDI, MAPOS, FC, DNS DHCID,

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

  1. Устройство, которое используется для сбора данных собирает специальный запрос, который будет рассылаться для всей подсети.

  2. Все хосты подсети получив запрос должны ответить, если запрашиваемые данные совпадают с их характеристиками (MAC или IP адрес).

  3. Если данные запроса совпали с данными того, кто принял запрос, то он должен ответить парой значений MAC адрес и IP адрес.

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

arp -a

Или

ip neigh

Структура пакета, который используется для работы с протоколом:

Инструменты для взаимодействия и проведения атак

Разобьём набор инструментов для работы с протоколом на несколько классов:

  1. Исследование данных

  2. Создание и манипуляция параметрами пакетов

  3. Инструменты для проведения атак

Исследование данных

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

  • WireShark

  • tcpdump

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

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

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

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

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

Пример созданного пакета в Scapy:

Попробуем сделать кастомный пакет и отправить в сеть, в качестве теста используется сеть 192.168.0.1/24, запрос будем отправлять для несуществующего устройства по адресу 192.168.0.111. Листинг мини приложения будет таким:

packet = ARP(pdst='192.168.0.111') send(packet)

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

sudo nping --arp --arp-target-ip='192.168.0.111' 192.168.0.1

Результат работы команды:

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

Как ни странно, хоть ARP один из самых простых протоколов, он является очень важным в проведении MiTM атак. Причем с помощью этого протокола происходит 90% задачи по перехвату трафика в сети, а уже оставшиеся 10% доделывают остальные инструменты и обработчики более высокоуровневых протоколов.

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

  • ARPSpoofing

  • DNSSpoofing (в локальной сети)

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

В ARP протоколе существует всего 2 вида запросов, это запрос, который ищет соответствие MAC и IP адреса и ответ на этот запрос.

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

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

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

(ПЕРЕД ТЕМ КАК НАЧАТЬ ТЕСТИРОВАТЬ РЕАЛЬНЫЕ СЕТИ: сразу пытаться обрабатывать большие сети больше /24 маски может быть проблематично). Чтобы подготовить машину, рекомендуется сделать небольшую настройку:

sudo sysctl -w net.ipv4.ip_forward=1  sudo ip link set eth0 promisc on  sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  sudo modprobe nf_conntrack  echo "1" > /proc/sys/net/netfilter/nf_conntrack_helper 

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

Как запускать инструменты для тестирования:

Scapy — пример скрипта, который может проводить атаки на DNS и ARP можно найти тут

arpspoof:

arpspoof -r ip ip.vi.c.tim ip.dest.i.na.tion

bettercap:

set arp.spoof.targets ip.of.subnet.ot.victim arp.spoof on

Механизмы защиты

Защита от перенаправления трафика может быть реализована за счет нескольких инструментов:

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

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

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

Статья подготовлена в рамках старта курса Network Security. Узнать о курсе подробнее и зарегистрироваться на бесплатный урок можно по ссылке ниже.


ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/696612/

Индивидуальный план развития разработчика в Сравни

Привет, Хабр! Меня зовут Владимир Каратаев, я руковожу группой разработки в проектах страхования компании Сравни. Проще говоря, я тимлид. Моя команда разрабатывает четыре сервиса: страхование ипотеки, недвижимости, путешествий, а также страхование от несчастного случая.

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

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

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

ИПР как инструмент тимлида

В отличие от своих коллег по команде, тимлид не может уделять 100% времени программированию. Для команды тимлид — это и завхоз, и девопс, и аналитик, и даже в каком-то смысле психолог.

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

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

Зачем нужен ИПР

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

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

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

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

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

Задачи тимлида при внедрении ИПР 

Задача-минимум, которая должна быть выполнена на 100% — это выявить и задокументировать увлечения и внерабочие инициативы сотрудника. В письменном виде эта информация уже сама по себе имеет ценность: HR может более эффективно подбирать сотрудников на проекты, новый руководитель может по увлечениям сотрудника быстрее понять его возможности и потенциал.

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

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

Как мотивировать сотрудников?

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

Тогда мы вместе с ним понажимали на все кнопки, даже стукнули компьютер. Убедились, что ничего не сломалось. Затем он попробовал при мне набрать команду на клавиатуре — компьютер послушно выдал ответ. Бинго! Студент доделал работу самостоятельно, и больше мне не пришлось к нему подходить. Более того, остальные «лабы» он уже делал сам. Впоследствии я узнал, что после окончания университета он стал успешным программистом.

Основа успеха этого студента — инициатива. Без нее он бы не смог выполнять «лабы» сам. Я только вначале помог ему преодолеть боязнь техники, а дальше он всё сделал сам. Я не стоял у него над душой, он по собственной инициативе изучал программирование. Поэтому инициатива — это движущая сила развития. А инициатива сотрудника — это основа ИПР.

Пирамида реализации ИПР
Пирамида реализации ИПР

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

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

Хороший прием, чтобы заинтересовать сотрудника — привести примеры других сотрудников, которым помог ИПР. Например, мой коллега активно участвовал к митапах, прокачал софт-скиллы и получил должность тимлида.

Что может компания предложить сотруднику

Очень важно понимать, что ИПР — это дорога с двусторонним движением. Если сотрудник тратит свое время на ИПР, то и компании нужно предлагать что-то взамен. 

Есть множество способов мотивировать сотрудника на выполнение ИПР: выплата премий, повышение в должности, оплата курсов и участия в профессиональных мероприятиях, приобретение литературы, предоставление ресурсов компании для реализации проекта. 

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

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

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

Задачи ИПР и отслеживание прогресса

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

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

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

Всё обсуждение ИПР сотрудника обычно проходит в неформальных разговорах, чтобы не было ощущения давления. Тем не менее, все задачи и измеримые показатели прогресса должны документироваться: например, изучена такая-то технология, по итогам прохождения курса проведен митап, разработан демо-проект и так далее.

Пример графика выполнения ИПРа. 
Пример графика выполнения ИПРа. 

Итак, если вкратце, то рекомендации следующие: 

  • Договориться с человеком о «правилах игры»: ИПР возможен только при наличии его инициативы; если пока непонятно, что именно делать – это нормально, но важна решимость действовать.

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

  • Определить критерии прогресса и периодически ненавязчиво интересоваться у сотрудника, как продвигаются дела и не нужна ли ему какая-то помощь.

  • Документировать все измеримые результаты.

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

Подводя итоги

  • Внедрение ИПР не решит все ваши проблемы, но зато поможет наладить системную работу по практическому применению увлечений сотрудника в компании.

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

  • Задача-максимум: применение увлечений сотрудника в проектах компании.

  • Обязательное условие: без инициативы сотрудника это не сработает.

  • Работодатель должен давать сотруднику что-то взамен. Если компания воспринимает ИПР только как способ дополнительно нагрузить сотрудника, это может привести к его выгоранию. 

Бонус: шаблон индивидуального плана развития

Спасибо за внимание! Если у вас возникли какие-то вопросы или комментарии, буду рад ответить.


ссылка на оригинал статьи https://habr.com/ru/company/sravni/blog/696618/