Топ-5 интересных постов за июнь-сентябрь 2017.
Собеседование: формулирование ключевых требований к кандидату на масштабирование команды, немного советов о проверке в процессе разговора
https://www.facebook.com/WebByte/posts/1553961628001911
Компании как микросервисы: профессии будущего - архитектор экосистем
https://www.facebook.com/WebByte/posts/1501298363268238
Работа IT-менеджера - продажи. Сроков, компании, проектов, процессов
https://www.facebook.com/WebByte/posts/1563889747009099
Расставание с сотрудником через призму дублирования его компетенций в момент работы и в момент ухода из компании
https://www.facebook.com/WebByte/posts/1558816347516439
Пути развития руководителя - менять ли работу, если есть возможность роста: основные страхи руководителя.
https://www.facebook.com/WebByte/posts/1577593515638722
Собеседование: формулирование ключевых требований к кандидату на масштабирование команды, немного советов о проверке в процессе разговора
https://www.facebook.com/WebByte/posts/1553961628001911
Компании как микросервисы: профессии будущего - архитектор экосистем
https://www.facebook.com/WebByte/posts/1501298363268238
Работа IT-менеджера - продажи. Сроков, компании, проектов, процессов
https://www.facebook.com/WebByte/posts/1563889747009099
Расставание с сотрудником через призму дублирования его компетенций в момент работы и в момент ухода из компании
https://www.facebook.com/WebByte/posts/1558816347516439
Пути развития руководителя - менять ли работу, если есть возможность роста: основные страхи руководителя.
https://www.facebook.com/WebByte/posts/1577593515638722
Весь сезон СоусПарка — сериала про поиск, собеседования и адаптацию сотрудников в одной небольшой компании.
Эпизод 1. Знакомство с командой и новая вакансия
https://www.facebook.com/WebByte/posts/1613572448707495
Эпизод 2. Классический поиск сотрудника
https://www.facebook.com/WebByte/posts/1616579158406824
Эпизод 3. Маркетинг в подборе
https://www.facebook.com/WebByte/posts/1619154308149309
Эпизод 4. Собеседования: задания и стресс
https://www.facebook.com/WebByte/posts/1624817594249647
Эпизод 5. Про оферы
https://www.facebook.com/WebByte/posts/1627300377334702
Эпизод 6. Адаптация
https://www.facebook.com/WebByte/posts/1631331100264963
Эпизод 1. Знакомство с командой и новая вакансия
https://www.facebook.com/WebByte/posts/1613572448707495
Эпизод 2. Классический поиск сотрудника
https://www.facebook.com/WebByte/posts/1616579158406824
Эпизод 3. Маркетинг в подборе
https://www.facebook.com/WebByte/posts/1619154308149309
Эпизод 4. Собеседования: задания и стресс
https://www.facebook.com/WebByte/posts/1624817594249647
Эпизод 5. Про оферы
https://www.facebook.com/WebByte/posts/1627300377334702
Эпизод 6. Адаптация
https://www.facebook.com/WebByte/posts/1631331100264963
Facebook
Max Babich
Следующие пару недель в постах будет рассказ с конференции по подбору IT-специалистов: как составлять требования, где искать кандидатов, как собеседовать. И как потом адаптировать найденного...
Разговорились сегодня с одним HRD про будущее IT-рынка. Несколько размышлений.
1. Из ВУЗов выходят те, кто родился в 94-96 годах. Не самое демографически активное время.
2. В менеджмент начинают уходить те, кто родился в 85-89 годах. Последние нормальные годы с точки зрения демографии.
3. ITшники продолжают уезжать из страны. Хотя есть и обратное движение.
Что это физически означает? А означает это, что программистов уровня миддл и сеньор будет всё меньше. А значит, цена на них будет расти. При условии, что всё больше и больше программистов нужно, компании всё дороже будут перекупать их друг у друга.
Что с этим можно делать?
Логично, что если на рынке мало людей, нужно делать, чтобы их было больше. По сути, это означает, что даже небольшим компаниям нужно вкладываться в развитие сотрудников, в том числе джуниоров.
Развивать внутренних экспертов, в том числе прокачивать их способности учить. Спонсировать качественные образовательные курсы. Работать с ВУЗами - кооперируясь с теми компаниями, которые пришли раньше.
Ну и перестать смотреть на отсутствие опыта у джуниоров, а больше интересоваться их обучаемостью.
Учиться работать с распределенными командами, активно искать в регионах.
Есть ли альтернатива? Конечно. Готовить деньги.
1. Из ВУЗов выходят те, кто родился в 94-96 годах. Не самое демографически активное время.
2. В менеджмент начинают уходить те, кто родился в 85-89 годах. Последние нормальные годы с точки зрения демографии.
3. ITшники продолжают уезжать из страны. Хотя есть и обратное движение.
Что это физически означает? А означает это, что программистов уровня миддл и сеньор будет всё меньше. А значит, цена на них будет расти. При условии, что всё больше и больше программистов нужно, компании всё дороже будут перекупать их друг у друга.
Что с этим можно делать?
Логично, что если на рынке мало людей, нужно делать, чтобы их было больше. По сути, это означает, что даже небольшим компаниям нужно вкладываться в развитие сотрудников, в том числе джуниоров.
Развивать внутренних экспертов, в том числе прокачивать их способности учить. Спонсировать качественные образовательные курсы. Работать с ВУЗами - кооперируясь с теми компаниями, которые пришли раньше.
Ну и перестать смотреть на отсутствие опыта у джуниоров, а больше интересоваться их обучаемостью.
Учиться работать с распределенными командами, активно искать в регионах.
Есть ли альтернатива? Конечно. Готовить деньги.
Недавно я писал про использование маркетинговых инструментов при поиске IT-кандидатов. И в одном из комментариев задали отличный вопрос: "Почему вообще стоит доверять этим методам, а не действовать по старинке - прямым поиском?".
Вопрос, действительно, классный. Во-первых, почему вообще стоит доверять советам какого-то мужика, который ни разу ни HR и не маркетолог? Во-вторых, даже если он прав, зачем новый непонятный способ?
Слепо доверять, конечно, не стоит. Способность критично оценивать предложения - отличная черта. Особенно у руководителей. Вера - последнее, чему стоит доверять. Поэтому любые предложения, как минимум, стоит пропускать через оценку - а насколько вообще предложение подходит? А есть ли у нас необходимые компетенции? А сколько стоит их приобрести? А как изменятся наши процессы? Не повлечет ли это изменение тяжёлых негативных последствий? Приемлем ли уровень риска?
Хороший способ проверить - экспертное мнение. Можно найти эксперта и спросить, можно понаблюдать за действиями и сделать выводы. Примерно так я и делал, когда начинал изучать маркетинг в HR-процессах.
Что касается ещё одного инструмента. Моя позиция проста - чем больше у нас вариантов, тем эффективнее и результативнее мы мы можем работать. Конечно, если выбор из вариантов - незатратное дело.
Поэтому тем, кто ещё сомневается, стоит ли использовать маркетинговые инструменты в подборе, отвечу так:
- два инструмента - лучше, чем один.
- если сомневаетесь - перепроверяйте. Только вовремя останавливайтесь.
Вопрос, действительно, классный. Во-первых, почему вообще стоит доверять советам какого-то мужика, который ни разу ни HR и не маркетолог? Во-вторых, даже если он прав, зачем новый непонятный способ?
Слепо доверять, конечно, не стоит. Способность критично оценивать предложения - отличная черта. Особенно у руководителей. Вера - последнее, чему стоит доверять. Поэтому любые предложения, как минимум, стоит пропускать через оценку - а насколько вообще предложение подходит? А есть ли у нас необходимые компетенции? А сколько стоит их приобрести? А как изменятся наши процессы? Не повлечет ли это изменение тяжёлых негативных последствий? Приемлем ли уровень риска?
Хороший способ проверить - экспертное мнение. Можно найти эксперта и спросить, можно понаблюдать за действиями и сделать выводы. Примерно так я и делал, когда начинал изучать маркетинг в HR-процессах.
Что касается ещё одного инструмента. Моя позиция проста - чем больше у нас вариантов, тем эффективнее и результативнее мы мы можем работать. Конечно, если выбор из вариантов - незатратное дело.
Поэтому тем, кто ещё сомневается, стоит ли использовать маркетинговые инструменты в подборе, отвечу так:
- два инструмента - лучше, чем один.
- если сомневаетесь - перепроверяйте. Только вовремя останавливайтесь.
Давайте поговорим про деньги.
Точнее про бюджет. Скоро середина ноября, у многих вот-вот закончится бюджетное планирование или хотя бы первые стадии.
В этом году у меня впервые упражнение сформировать статьи по доходам и спрогнозировать цифры. Необычно. Предыдущие 4-5 лет упражнялся исключительно с расходами IT-подразделения.
Как я обычно считаю расходы.
Общий принцип такой: "Прогнозирование изменений в капитальных затратах и операционных расходах, а также расходах на фонд оплаты труда". ФОТ не в операционке, потому что в этой статье прогнозирую изменения по каждому сотруднику персонально. Это не строки таблицы, это живые люди :)
Что значит "прогнозирование"?
Я пытаюсь оценить следующие вещи:
1. Какие части продукта прекратят свое существование в следующем году;
2. Какие части продукта появятся в следующем году;
3. Как изменится использование существующих частей продукта, которым не грозит «смерть через выпиливание из кодовой базы».
При оценке стараюсь оценить с точностью до квартала. Если возможно — до месяца.
Конечно, без понимания продуктового развития и без понимания, как будет развиваться инфраструктура, точный прогноз составить сложно.
После того, как стал понятны планы по развитию продукта, оцениваю, каким способом мы будем их выполнять (одного и того же можно добиться разными путями).
- Капитальные затраты: серверы, рабочие станции, одноразовые лицензии на покупку ПО и так далее.
- Операционные расходы: периодические платежи за лицензии, использование интернет-сервисов (смс-рассылки, конструкторы лэндингов), аренда каналов связи, хостинга итп.
- Расходы на персонал: новые вакансии, изменения в зарплатах сотрудников, увольнения, бонусы.
Все три части согласованы между собой и с продуктовым/инфраструктурным планом.
Итак
- Продуктовый и технический roadmap
- Добавление, удаление, изменение частей сервиса
- Капитальные затраты, операционные расходы, ФОТ.
Ровно же этот принцип использую при расчете стоимости запуска нового продукта.
Точнее про бюджет. Скоро середина ноября, у многих вот-вот закончится бюджетное планирование или хотя бы первые стадии.
В этом году у меня впервые упражнение сформировать статьи по доходам и спрогнозировать цифры. Необычно. Предыдущие 4-5 лет упражнялся исключительно с расходами IT-подразделения.
Как я обычно считаю расходы.
Общий принцип такой: "Прогнозирование изменений в капитальных затратах и операционных расходах, а также расходах на фонд оплаты труда". ФОТ не в операционке, потому что в этой статье прогнозирую изменения по каждому сотруднику персонально. Это не строки таблицы, это живые люди :)
Что значит "прогнозирование"?
Я пытаюсь оценить следующие вещи:
1. Какие части продукта прекратят свое существование в следующем году;
2. Какие части продукта появятся в следующем году;
3. Как изменится использование существующих частей продукта, которым не грозит «смерть через выпиливание из кодовой базы».
При оценке стараюсь оценить с точностью до квартала. Если возможно — до месяца.
Конечно, без понимания продуктового развития и без понимания, как будет развиваться инфраструктура, точный прогноз составить сложно.
После того, как стал понятны планы по развитию продукта, оцениваю, каким способом мы будем их выполнять (одного и того же можно добиться разными путями).
- Капитальные затраты: серверы, рабочие станции, одноразовые лицензии на покупку ПО и так далее.
- Операционные расходы: периодические платежи за лицензии, использование интернет-сервисов (смс-рассылки, конструкторы лэндингов), аренда каналов связи, хостинга итп.
- Расходы на персонал: новые вакансии, изменения в зарплатах сотрудников, увольнения, бонусы.
Все три части согласованы между собой и с продуктовым/инфраструктурным планом.
Итак
- Продуктовый и технический roadmap
- Добавление, удаление, изменение частей сервиса
- Капитальные затраты, операционные расходы, ФОТ.
Ровно же этот принцип использую при расчете стоимости запуска нового продукта.
Немного про экономику найма.
Допустим вакансия миддл-программиста закрывается за 4–6 недель.
Первая пара недель уходит на поиски первых кандидатов, остальные — на собеседования, по 2-4 собеседования в неделю.
Пусть соглашается прийти на собеседование каждый пятый кандидат.
Пусть на поиск одного кандидата нужен час.
Еще полчаса — чтобы позвонить/написать и еще полчаса — как-то договориться о встрече.
Допустим, зарплата рекрутера, который это все делает, 80К.
Зарплата собеседующего программиста — 160К (миддла собеседуем сеньором, а лучше двумя).
Собеседуем час, еще полчаса — на чтение резюме, подготовку к собеседованию и обратной связи рекрутеру.
Это значит, что при таких вводных найм среднего программиста обходится компании от 60 тысяч рублей.
Это к вопросу о стоимости услуг кадровых агентств и стоимости оплаты успешной рекомендации. Посчитав стоимость своего поиска, проще понять, что и сколько должно сэкономить КА и сколько платить за рекомендацию.
Что хотел сказать? Считайте экономику.
PS. Если у вас в компании другие воронки, затраты времени и зарплаты, вы можете сами посчитать стоимость в вашем случае.
ФБ: https://www.fb.com/WebByte/posts/1644038638994209
Допустим вакансия миддл-программиста закрывается за 4–6 недель.
Первая пара недель уходит на поиски первых кандидатов, остальные — на собеседования, по 2-4 собеседования в неделю.
Пусть соглашается прийти на собеседование каждый пятый кандидат.
Пусть на поиск одного кандидата нужен час.
Еще полчаса — чтобы позвонить/написать и еще полчаса — как-то договориться о встрече.
Допустим, зарплата рекрутера, который это все делает, 80К.
Зарплата собеседующего программиста — 160К (миддла собеседуем сеньором, а лучше двумя).
Собеседуем час, еще полчаса — на чтение резюме, подготовку к собеседованию и обратной связи рекрутеру.
Это значит, что при таких вводных найм среднего программиста обходится компании от 60 тысяч рублей.
Это к вопросу о стоимости услуг кадровых агентств и стоимости оплаты успешной рекомендации. Посчитав стоимость своего поиска, проще понять, что и сколько должно сэкономить КА и сколько платить за рекомендацию.
Что хотел сказать? Считайте экономику.
PS. Если у вас в компании другие воронки, затраты времени и зарплаты, вы можете сами посчитать стоимость в вашем случае.
ФБ: https://www.fb.com/WebByte/posts/1644038638994209
Вчера было занятие группы будущих руководителей digital-продуктов. В рамках Нетологии. Тема — "техническое задание". В этот раз я решил провести эксперимент. И полностью переделать занятие.
Предыдущие занятия по этой теме выглядели так:
- Много-много систематизированной информации + кейсы из личного опыта
- Треть занятия — практика в командах.
- И дополнительные материалы по теме для самостоятельного обучения.
В этот раз всё было иначе.
Я решил пойти от уровня группы. Провел анкетирование по всем моим темам блока. Оценил общий уровень. Из оценки было видно, что бОльшая часть группы знает тему на достаточно хорошем уровне. После этого решил всё занятие сделать практикой. Чтобы ребята поучились друг у друга.
Придумал, на какой проект будем делать ТЗ. Проект взял самый насущный для HR — сервис-платформу для рекламы вакансий среди IT-специалистов. Разбил его на три компонента — личный кабинет с аналитикой, систему взаимодействия с рекламными каналами и систему генерации лэндингов.
И стартовали.
Поскольку ребят было сильно больше, чем ожидалось в субботу утром, вместо трех команд пришлось сделать четыре. Четвертая играла роль команды программистов. Оппонировала к ТЗ...
С точки зрения некоторых участников получилось, конечно, так себе:
1. Ребята много времени потеряли, чтобы друг с другом договориться. Даже внутри команды. Не говоря уж про "программистов-хейтеров".
2. Многие все же переоценили свой уровень и без систематизации им было сложно.
3. Кто-то вообще пришел без опыта, таким было сложнее всего.
Мне тоже не все понравилось. Не удивлюсь, если на следующем занятии будет сильно меньше людей. Хотя его уже проведу в традиционной форме. Там даже по анкетам это очевидно. Но вообще, я доволен экспериментом. Ведь хотя мало кто понял, как правильно делать ТЗ, почти все почувствовали на своей шкуре, что бывает, когда к нечетким требованиям добавляются проблемы с коммуникацией :)
Выводы простые:
- Everybody lies
- Сбалансированные группы в обучении — лучше.
- Нужно учитывать обратную связь и уметь вовремя остановиться.
- Четкие требования — рулят. Но меньше простора для развития
ФБ: https://www.facebook.com/WebByte/posts/1646845965380143
Предыдущие занятия по этой теме выглядели так:
- Много-много систематизированной информации + кейсы из личного опыта
- Треть занятия — практика в командах.
- И дополнительные материалы по теме для самостоятельного обучения.
В этот раз всё было иначе.
Я решил пойти от уровня группы. Провел анкетирование по всем моим темам блока. Оценил общий уровень. Из оценки было видно, что бОльшая часть группы знает тему на достаточно хорошем уровне. После этого решил всё занятие сделать практикой. Чтобы ребята поучились друг у друга.
Придумал, на какой проект будем делать ТЗ. Проект взял самый насущный для HR — сервис-платформу для рекламы вакансий среди IT-специалистов. Разбил его на три компонента — личный кабинет с аналитикой, систему взаимодействия с рекламными каналами и систему генерации лэндингов.
И стартовали.
Поскольку ребят было сильно больше, чем ожидалось в субботу утром, вместо трех команд пришлось сделать четыре. Четвертая играла роль команды программистов. Оппонировала к ТЗ...
С точки зрения некоторых участников получилось, конечно, так себе:
1. Ребята много времени потеряли, чтобы друг с другом договориться. Даже внутри команды. Не говоря уж про "программистов-хейтеров".
2. Многие все же переоценили свой уровень и без систематизации им было сложно.
3. Кто-то вообще пришел без опыта, таким было сложнее всего.
Мне тоже не все понравилось. Не удивлюсь, если на следующем занятии будет сильно меньше людей. Хотя его уже проведу в традиционной форме. Там даже по анкетам это очевидно. Но вообще, я доволен экспериментом. Ведь хотя мало кто понял, как правильно делать ТЗ, почти все почувствовали на своей шкуре, что бывает, когда к нечетким требованиям добавляются проблемы с коммуникацией :)
Выводы простые:
- Everybody lies
- Сбалансированные группы в обучении — лучше.
- Нужно учитывать обратную связь и уметь вовремя остановиться.
- Четкие требования — рулят. Но меньше простора для развития
ФБ: https://www.facebook.com/WebByte/posts/1646845965380143
Немного про то, как выглядел второй этап "Лидеров России"
https://www.facebook.com/WebByte/posts/1649401875124552
https://www.facebook.com/WebByte/posts/1649401875124552
Разговорились сегодня с представителем HR про оценку 360. Дескать, как проводить-то. Дело новое, незнакомое, что-то читали, а практики нет. По каким компетенциям техдиректора оценивать-то? Погуглить, может? Ну погуглили, узнали про этапы проведения оценки. А что дальше?
Хорошо бы, если б гугл решал за нас. А мы только пожинали плоды. Но нет. Подготовительный этап к 360 — компетентностное моделирование — гугл за вас не сделает. Впрочем, в такой области, как IT, не сильно помогут и проф.стандарты. И вот почему.
Модель компетенций сильно связана с процессами конкретной компании. А я пока не встречал двух компаний с одинаковыми процессами. Ну, я еще зеленый, да, ISO не нюхал. Раз компании разные, то модель одной может не подойти второй — либо будет что-то лишнее, либо чего-то не хватать. Поэтому на чужой опыт можно опираться, не более того.
Компания — живой организм. Кто-то приходит, кто-то уходит, как-то всё в динамике меняется. Меняется и модель компетенций. То, как вы оценивали сейчас, может не работать через год.
Ладно, а HRу-то что делать? Особенно, если на аудит ни времени, ни денег нет?
1. Построение модели начать с небольшой команды, а не сразу со всей компании.
2. Расписать вместе с участниками команды все процессы, в которых они участвуют.
3. Определить, какие из них — ключевые и попрактиковаться на них.
4. Потом определиться, какие знания нужны на каждом этапе процесса. Какие навыки (практики, инструменты). Какие компетенции работы с людьми. Какие роли и люди, в конце концов, участвуют на этих этапах.
5. Систематизировать знания, навыки, софты.
6. Снова понять ключевые.
И вот только после этого считайте, что можно приступать к формированию опросника.
Каким образом его составлять — эт отдельный вопрос, ага.
ФБ: https://www.facebook.com/WebByte/posts/1649700225094717
Хорошо бы, если б гугл решал за нас. А мы только пожинали плоды. Но нет. Подготовительный этап к 360 — компетентностное моделирование — гугл за вас не сделает. Впрочем, в такой области, как IT, не сильно помогут и проф.стандарты. И вот почему.
Модель компетенций сильно связана с процессами конкретной компании. А я пока не встречал двух компаний с одинаковыми процессами. Ну, я еще зеленый, да, ISO не нюхал. Раз компании разные, то модель одной может не подойти второй — либо будет что-то лишнее, либо чего-то не хватать. Поэтому на чужой опыт можно опираться, не более того.
Компания — живой организм. Кто-то приходит, кто-то уходит, как-то всё в динамике меняется. Меняется и модель компетенций. То, как вы оценивали сейчас, может не работать через год.
Ладно, а HRу-то что делать? Особенно, если на аудит ни времени, ни денег нет?
1. Построение модели начать с небольшой команды, а не сразу со всей компании.
2. Расписать вместе с участниками команды все процессы, в которых они участвуют.
3. Определить, какие из них — ключевые и попрактиковаться на них.
4. Потом определиться, какие знания нужны на каждом этапе процесса. Какие навыки (практики, инструменты). Какие компетенции работы с людьми. Какие роли и люди, в конце концов, участвуют на этих этапах.
5. Систематизировать знания, навыки, софты.
6. Снова понять ключевые.
И вот только после этого считайте, что можно приступать к формированию опросника.
Каким образом его составлять — эт отдельный вопрос, ага.
ФБ: https://www.facebook.com/WebByte/posts/1649700225094717
Сегодня поговорим про инциденты. Примерно такой фразой я начал очередное занятие. В течение двух часов мы говорили про управление отклонениями от нормального поведения систем.
Но шутнице-вселенной показалось мало практической работы на лекции. Выйдя из здания, я не обнаружил своей машины на месте, где ее оставил. «Та-дам! Аларм!» — глаза-мониторинг отправили сигнал в мозг. Мозг сразу эскалировал в надпочечники, запросил дозу адреналина. Началась реакция на инцидент.
Одна из основных задач инцидент-менеджмента — быстрая реакция на происходящее. Раньше заметили, раньше среагировали — меньше последствия. Чтобы ускорить реакцию, нужны инструкции — что делать в случае проблем. Нужна как минимум общая инструкция и какое-то количество частных инструкций — для проблем, с которыми уже сталкивались и научились решать.
Общая инструкция в моем случае — смотри в интернет.
Буквально через минуту после осознания, что машины нет, я уже успел открыть приложение Парковок Москвы. Из него еще через несколько секунд узнал, где находится отделение ГИБДД, куда нужно ехать за протоколом. И на какой стоянке находится моя машина.
Итак, после ознакомления с инструкцией стало понятно, что нужно делать дальше:
1. Скататься на стоянку и забрать ОСАГО.
2. Скаться в ГИБДД и получить копию протокола об административном нарушении
3. С этой копией поехать обратно на стоянку и забрать автомобиль.
Сказано — сделано.
Я классифицировал инцидент как "Критический" — потому что нужно было быть дома сильно раньше, чем теперь получалось — и сообщил заинтересованным лицам по предписанным каналам связи. С той стороны трубки сказали то, что обычно говорят заинтересованные сотрудники, когда им сообщаешь, что упала база данных. Слова угадайте сами.
Инструкция была корректной и после нескольких несложных упражнений машина была получена. Ровно через три часа я проехал мимо здания, где читал лекцию. Инцидент был завершен.
Вторая задача инцидент-менеджмента — не допустить повторение инцидента в будущем или хотя бы минимизировать его длительность и стоимость. Для этого обязательно нужно собирать детальную информацию о том, что произошло. Еще — где это случилось, что было предпринято для устранения. Я также рекомендую поминутно расписывать, что происходило во время инцидента. Это сильно помогает при анализе проблем.
Итак, давайте посмотрим по логам (протоколам и моим записям), как развивался инцидент.
- 12:45 — начало инцидента, эвакуация машины
- 14:15 — срабатывание триггера (глаза увидели). Начало работы по инциденту
- 14:45 - 15:00 — я на стоянке, забираю ОСАГО, вызываю такси
- 15:35 - 15:50 — я в ГИБДД, оформляю необходимые бумаги (штраф со скидкой 50% оплачу позднее).
- 16:00 - 16:20 — еду в такси на стоянку
- 16:36 — оплата эвакуакции,
- 16:50 — выехал за пределы стоянки
- 17:15 — проехал мимо Бауманской в сторону дома, инцидент завершен.
При анализе этого инцидента можно заметить, что часть процесса в дальнейшем можно сократить — как минимум, если уж осознанно нарушаю, нужно брать с собой ОСАГО. Это сэкономит около 700-800 р. И где-то час времени.
На следующем занятии по инцидент-менеджменту будет о чем рассказать. А то уж я переживать начал, что повторяю одни и те же случаи. Вселенная, спасибо за качественный материал! Твой юмор я тоже оценил :)
Учитесь управлять инцидентами — экономит время и нервы, учит даже к проблемам относиться спокойно.
ФБ: https://www.facebook.com/WebByte/posts/1652811764783563
Но шутнице-вселенной показалось мало практической работы на лекции. Выйдя из здания, я не обнаружил своей машины на месте, где ее оставил. «Та-дам! Аларм!» — глаза-мониторинг отправили сигнал в мозг. Мозг сразу эскалировал в надпочечники, запросил дозу адреналина. Началась реакция на инцидент.
Одна из основных задач инцидент-менеджмента — быстрая реакция на происходящее. Раньше заметили, раньше среагировали — меньше последствия. Чтобы ускорить реакцию, нужны инструкции — что делать в случае проблем. Нужна как минимум общая инструкция и какое-то количество частных инструкций — для проблем, с которыми уже сталкивались и научились решать.
Общая инструкция в моем случае — смотри в интернет.
Буквально через минуту после осознания, что машины нет, я уже успел открыть приложение Парковок Москвы. Из него еще через несколько секунд узнал, где находится отделение ГИБДД, куда нужно ехать за протоколом. И на какой стоянке находится моя машина.
Итак, после ознакомления с инструкцией стало понятно, что нужно делать дальше:
1. Скататься на стоянку и забрать ОСАГО.
2. Скаться в ГИБДД и получить копию протокола об административном нарушении
3. С этой копией поехать обратно на стоянку и забрать автомобиль.
Сказано — сделано.
Я классифицировал инцидент как "Критический" — потому что нужно было быть дома сильно раньше, чем теперь получалось — и сообщил заинтересованным лицам по предписанным каналам связи. С той стороны трубки сказали то, что обычно говорят заинтересованные сотрудники, когда им сообщаешь, что упала база данных. Слова угадайте сами.
Инструкция была корректной и после нескольких несложных упражнений машина была получена. Ровно через три часа я проехал мимо здания, где читал лекцию. Инцидент был завершен.
Вторая задача инцидент-менеджмента — не допустить повторение инцидента в будущем или хотя бы минимизировать его длительность и стоимость. Для этого обязательно нужно собирать детальную информацию о том, что произошло. Еще — где это случилось, что было предпринято для устранения. Я также рекомендую поминутно расписывать, что происходило во время инцидента. Это сильно помогает при анализе проблем.
Итак, давайте посмотрим по логам (протоколам и моим записям), как развивался инцидент.
- 12:45 — начало инцидента, эвакуация машины
- 14:15 — срабатывание триггера (глаза увидели). Начало работы по инциденту
- 14:45 - 15:00 — я на стоянке, забираю ОСАГО, вызываю такси
- 15:35 - 15:50 — я в ГИБДД, оформляю необходимые бумаги (штраф со скидкой 50% оплачу позднее).
- 16:00 - 16:20 — еду в такси на стоянку
- 16:36 — оплата эвакуакции,
- 16:50 — выехал за пределы стоянки
- 17:15 — проехал мимо Бауманской в сторону дома, инцидент завершен.
При анализе этого инцидента можно заметить, что часть процесса в дальнейшем можно сократить — как минимум, если уж осознанно нарушаю, нужно брать с собой ОСАГО. Это сэкономит около 700-800 р. И где-то час времени.
На следующем занятии по инцидент-менеджменту будет о чем рассказать. А то уж я переживать начал, что повторяю одни и те же случаи. Вселенная, спасибо за качественный материал! Твой юмор я тоже оценил :)
Учитесь управлять инцидентами — экономит время и нервы, учит даже к проблемам относиться спокойно.
ФБ: https://www.facebook.com/WebByte/posts/1652811764783563
Разговорились про то, как определять уровень знаний разработчиков, если язык разработки новый для компании.
Оставим за рамками вопрос "Зачем вообще это нужно?". Бывает. Допустим, нужно. Мне однажды нужно было тестировщика впервые в жизни нанять.
Что же делать? Простой вопрос — простой ответ.
Если каких-то компетенций не хватает, нужно, чтобы их хватало.
Как их получить?
Через обучение — долго. Сначала курсы найти, потом еще разобраться в предмете настолько, чтобы научиться собеседовать.
Самый простой вариант добрать компетенций — найти эксперта в технологии. И пособеседовать с его помощью. Если переживаете, что задергаете эксперта, вот еще варианты:
1. Найдите несколько экспертов, которых сможете привлекать по мере необходимости;
2. Возьмите своего самого сильного программиста, привлеките его на несколько первых собеседований. Пусть учится у эксперта.
3. Возьмите своего самого сильного программиста для изучения новой предметной области. Пусть пообщается с экспертом, поймет, какими инструментами решаются ваши задачи в новой технологии. И пусть проводит собеседования.
4. В конце концов, возьмите кадровое агентство, которое специализируется на IT-специалистах. Если хорошие, то точно умеют собеседовать всех.
Если всё же нашли эксперта — уговорите пособеседовать вместе. Расскажите немного про вашу область. Дайте кандидату решить практический кейс из этой области. Пусть эксперт оценит техническое качество решения, а вы — смысловое.
И не забудьте эксперта поблагодарить. Лучше деньгами.
Он вам еще пригодится.
ФБ: https://www.facebook.com/WebByte/posts/1656068254457914
Оставим за рамками вопрос "Зачем вообще это нужно?". Бывает. Допустим, нужно. Мне однажды нужно было тестировщика впервые в жизни нанять.
Что же делать? Простой вопрос — простой ответ.
Если каких-то компетенций не хватает, нужно, чтобы их хватало.
Как их получить?
Через обучение — долго. Сначала курсы найти, потом еще разобраться в предмете настолько, чтобы научиться собеседовать.
Самый простой вариант добрать компетенций — найти эксперта в технологии. И пособеседовать с его помощью. Если переживаете, что задергаете эксперта, вот еще варианты:
1. Найдите несколько экспертов, которых сможете привлекать по мере необходимости;
2. Возьмите своего самого сильного программиста, привлеките его на несколько первых собеседований. Пусть учится у эксперта.
3. Возьмите своего самого сильного программиста для изучения новой предметной области. Пусть пообщается с экспертом, поймет, какими инструментами решаются ваши задачи в новой технологии. И пусть проводит собеседования.
4. В конце концов, возьмите кадровое агентство, которое специализируется на IT-специалистах. Если хорошие, то точно умеют собеседовать всех.
Если всё же нашли эксперта — уговорите пособеседовать вместе. Расскажите немного про вашу область. Дайте кандидату решить практический кейс из этой области. Пусть эксперт оценит техническое качество решения, а вы — смысловое.
И не забудьте эксперта поблагодарить. Лучше деньгами.
Он вам еще пригодится.
ФБ: https://www.facebook.com/WebByte/posts/1656068254457914