Топ-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
Иногда очень сложно определить тему для очередного поста. Нет, не потому что темы закончились. Запас-то ещё ого-го. Сложно потому, что слишком много всего происходит кругом.
Общаешься с HR и тут же что-нибудь придумаешь написать на тему обратной связи, ответственности, каких-нибудь полезных инструментов подбора. Общаешься с разработчиками - и бац! - тут тебе и про архитектуру что-то, и про нюансы процессов. А ещё про менеджмент что-нибудь философское. Или про осознанность решений. Про картографию и интерпретацию. Много всего.
Большой выбор ничем не лучше отсутствия выбора. Много идей ничем не лучше их отсутствия. Много фич в продукте ничем не лучше сырого продукта.
Вот почему важна обратная связь. Даже тем, кто вещает с табуретки. Фокусироваться помогает. На том, что действительно нужно слушателям-читателям.
Так что не проходите мимо, пишите в вопросы, которые вас сейчас беспокоят. Вдруг что-то да знаю и отвечу.
ФБ: https://facebook.com/WebByte/posts/1659263824138357
Общаешься с HR и тут же что-нибудь придумаешь написать на тему обратной связи, ответственности, каких-нибудь полезных инструментов подбора. Общаешься с разработчиками - и бац! - тут тебе и про архитектуру что-то, и про нюансы процессов. А ещё про менеджмент что-нибудь философское. Или про осознанность решений. Про картографию и интерпретацию. Много всего.
Большой выбор ничем не лучше отсутствия выбора. Много идей ничем не лучше их отсутствия. Много фич в продукте ничем не лучше сырого продукта.
Вот почему важна обратная связь. Даже тем, кто вещает с табуретки. Фокусироваться помогает. На том, что действительно нужно слушателям-читателям.
Так что не проходите мимо, пишите в вопросы, которые вас сейчас беспокоят. Вдруг что-то да знаю и отвечу.
ФБ: https://facebook.com/WebByte/posts/1659263824138357
#РазговорилисьCегодня с одним IT-предпринимателем про технических директоров. Опасается человек, что в случае конфликта с руководством технический директор со всеми его полномочиями может бизнес грохнуть.
Мне почему-то сразу вспомнилась фраза, что «при увольнении рядовые сотрудники уносят с собой информацию, руководители среднего звена — бизнес-процессы, а топ-менеджеры — бизнес». Не совсем в тему, но всё же.
Что тут сказать.
Конечно, если технический директор выстроил процессы так, что вся техника завязана только на него, то шансы получить проблемы при конфликте весьма велики. Люди разные бывают, нервы опять же, стресс. Конечно, если вы зависите от одного человека, то его нужно холить и лелеять. Покупать ему санкционный сыр и в масле катать.
Кстати, лайфхак еще есть — жениться на техдиректоре. Или замуж за него выйти. Главное, правильно транслировать это текущему супругу или супруге: «Извини, солнышко, ничего личного, just business».
Но, конечно, подобная проблема может быть не только с техдиректором. В моей практике бывали случаи, когда бутылочным горлышком, от которого зависел многомиллионный бизнес, был далеко не директор. Ну сложилось так исторически, чо.
Что делать в таком случае? Дублировать. Размывать компетенции, знания, навыки как можно быстрее. Давать денег, если попросит. Шантаж? Да, шантаж. Сами виноваты. Ну или те, кто был до вас. Говорят, долю еще давать можно ключевым сотрудникам, иногда спасает.
Страдать и дублировать. Людьми, инструментами, изменением процессов. Планомерно. Неделя за неделей. Может быть даже в ущерб развитию бизнеса. Это временно, ненадолго. А вот если человека автобус переедет — будет больно. Очень.
Знайте, кто у вас самое узкое место.
Думайте, как это исправить.
Торопитесь.
ФБ: https://www.facebook.com/WebByte/posts/1663398640391542
Мне почему-то сразу вспомнилась фраза, что «при увольнении рядовые сотрудники уносят с собой информацию, руководители среднего звена — бизнес-процессы, а топ-менеджеры — бизнес». Не совсем в тему, но всё же.
Что тут сказать.
Конечно, если технический директор выстроил процессы так, что вся техника завязана только на него, то шансы получить проблемы при конфликте весьма велики. Люди разные бывают, нервы опять же, стресс. Конечно, если вы зависите от одного человека, то его нужно холить и лелеять. Покупать ему санкционный сыр и в масле катать.
Кстати, лайфхак еще есть — жениться на техдиректоре. Или замуж за него выйти. Главное, правильно транслировать это текущему супругу или супруге: «Извини, солнышко, ничего личного, just business».
Но, конечно, подобная проблема может быть не только с техдиректором. В моей практике бывали случаи, когда бутылочным горлышком, от которого зависел многомиллионный бизнес, был далеко не директор. Ну сложилось так исторически, чо.
Что делать в таком случае? Дублировать. Размывать компетенции, знания, навыки как можно быстрее. Давать денег, если попросит. Шантаж? Да, шантаж. Сами виноваты. Ну или те, кто был до вас. Говорят, долю еще давать можно ключевым сотрудникам, иногда спасает.
Страдать и дублировать. Людьми, инструментами, изменением процессов. Планомерно. Неделя за неделей. Может быть даже в ущерб развитию бизнеса. Это временно, ненадолго. А вот если человека автобус переедет — будет больно. Очень.
Знайте, кто у вас самое узкое место.
Думайте, как это исправить.
Торопитесь.
ФБ: https://www.facebook.com/WebByte/posts/1663398640391542
Менеджмент похож на беговые виды спорта в легкой атлетике.
Бывают задачи, где нужно думать о стратегии. Как в марафоне. С наскоку его пробежать не получится. Держишь в голове эти 42 километра и планомерно к ним идешь. Неделя за неделей, месяц за месяцем. Километр за километром.
Бывают задачи, где нужно думать о тактике. Как на средних дистанциях — 800 и 1500. Можно быстро начать, но не добежать. Можно начать спокойно, но не успеть вовремя ускориться. Думать надо.
Бывают задачи, где нужно нестись, что есть сил. Как на стометровке. Или на 400 метрах. Не раздумывая. Просто срываясь с колодок и хренача.
Редкие спортсмены бегают дистанции разных типов.
В основном, специализируются на одних — спринт, средние, длинные.
А что ж тогда от менеджера ожидают способности бегать сразу тремя способами?
ФБ: https://www.facebook.com/WebByte/posts/1666650030066403
Бывают задачи, где нужно думать о стратегии. Как в марафоне. С наскоку его пробежать не получится. Держишь в голове эти 42 километра и планомерно к ним идешь. Неделя за неделей, месяц за месяцем. Километр за километром.
Бывают задачи, где нужно думать о тактике. Как на средних дистанциях — 800 и 1500. Можно быстро начать, но не добежать. Можно начать спокойно, но не успеть вовремя ускориться. Думать надо.
Бывают задачи, где нужно нестись, что есть сил. Как на стометровке. Или на 400 метрах. Не раздумывая. Просто срываясь с колодок и хренача.
Редкие спортсмены бегают дистанции разных типов.
В основном, специализируются на одних — спринт, средние, длинные.
А что ж тогда от менеджера ожидают способности бегать сразу тремя способами?
ФБ: https://www.facebook.com/WebByte/posts/1666650030066403
#РазговорилисьСегодня про развитие сотрудников. И была высказана мысль: «Либо помещаем сотрудников в условия, где они сами развиваются, либо развиваем, либо понимаем,что наша компания — тупая мясорубка и только на перекантоваться». И ответ на эту фразу: «Не бирюза ни разу, но горькая правда жизни».
Я не спец в организационном развитии. Так... Кое-что читал, кое за чем наблюдал, кое с кем дискутировал. Но всё равно этот ответ показался странным. И вот почему.
"Бирюзовость" — не превосходящая форма всех остальных организационных формаций. Она их включает. Как организм не превосходнее отдельного органа или клетки. Более сложный — да. Лучше — нет. Как можно сравнивать печень и сердце? Или кости и мышцы? Они дополняют друг друга, делая работу организма целостной. Как можно сравнивать разные организмы? Они все ценны для матушки-природы.
Если поразмышлять о сходстве устройства «организма» и «организации», то можно прийти к очевидному выводу.
Мясорубка — такая же часть бирюзовой организации, как и зубы в организме млекопитающего. Если для целей развития организма нужно пережевывание пищи, то почему для целей развития организации не может использоваться «мясорубка» в отдельных ее частях? Почему не может использоваться иерархия? Ведь нас окружают тысячи организмов, в которых иерархия — основа. Даже в нашем организме есть жесткая иерархия. Разве менее прекрасен дуб от того, что он весь из себя иерархичен? Разве «парятся» кости стопы, выполняя сигналы из мозга? Нет, у всех свои функции — обеспечить развитие организма. Вместе. Во имя общей цели.
Пожалуйста, не идеализируйте «бирюзу». Это всего лишь более целостная организационная форма. Чуть другая. А не «лучшая».
И да. Если кто-то в России говорит про свою бирюзовость, посмотрите на забор. Там тоже много, что написано. А подходишь поближе — доски.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1669915749739831
Я не спец в организационном развитии. Так... Кое-что читал, кое за чем наблюдал, кое с кем дискутировал. Но всё равно этот ответ показался странным. И вот почему.
"Бирюзовость" — не превосходящая форма всех остальных организационных формаций. Она их включает. Как организм не превосходнее отдельного органа или клетки. Более сложный — да. Лучше — нет. Как можно сравнивать печень и сердце? Или кости и мышцы? Они дополняют друг друга, делая работу организма целостной. Как можно сравнивать разные организмы? Они все ценны для матушки-природы.
Если поразмышлять о сходстве устройства «организма» и «организации», то можно прийти к очевидному выводу.
Мясорубка — такая же часть бирюзовой организации, как и зубы в организме млекопитающего. Если для целей развития организма нужно пережевывание пищи, то почему для целей развития организации не может использоваться «мясорубка» в отдельных ее частях? Почему не может использоваться иерархия? Ведь нас окружают тысячи организмов, в которых иерархия — основа. Даже в нашем организме есть жесткая иерархия. Разве менее прекрасен дуб от того, что он весь из себя иерархичен? Разве «парятся» кости стопы, выполняя сигналы из мозга? Нет, у всех свои функции — обеспечить развитие организма. Вместе. Во имя общей цели.
Пожалуйста, не идеализируйте «бирюзу». Это всего лишь более целостная организационная форма. Чуть другая. А не «лучшая».
И да. Если кто-то в России говорит про свою бирюзовость, посмотрите на забор. Там тоже много, что написано. А подходишь поближе — доски.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1669915749739831
Обратная связь - лучшее, что придумало человечество после изобретения граблей. Потому что грабли по лбу - это физическая боль. А от обратной связи чаще даже приятно.
Обратная связь - отличный инструмент для развития. Ты даёшь обратную связь коллегам, друзьям, родственникам - они растут над собой. По крайней мере шанс на это проявляется. Тебе дают - радуйся и развивайся дальше.
Как чаще всего бывает? По наблюдениям и опыту обратную связь на работе используешь, в основном, для развития. Иногда даже готовишься к очередному сеансу. Проанализируешь действия человека, результаты, на его коммуникации с другими сотрудниками посмотришь. И давай ему по учебникам - сначала плюсы, потом минусы, потом на позитиве заканчиваешь. Методом "гамбургера" это, кажется, называется.
Меж тем иногда этот метод применять не стоит.
Иногда стоит минусами обойтись. Корону сбить. Как граблями.
А иногда просто поддержать нужно, посаппортить. Без всякого развития. Просто потому что хороший. Бывает, что нужно и так. Помогает.
В общем, обратная связь - очень полезный инструмент. Пользуйтесь почаще. Запрашивайте почаще.
Обсудить в ФБ: https://facebook.com/WebByte/posts/1672786796119393
Обратная связь - отличный инструмент для развития. Ты даёшь обратную связь коллегам, друзьям, родственникам - они растут над собой. По крайней мере шанс на это проявляется. Тебе дают - радуйся и развивайся дальше.
Как чаще всего бывает? По наблюдениям и опыту обратную связь на работе используешь, в основном, для развития. Иногда даже готовишься к очередному сеансу. Проанализируешь действия человека, результаты, на его коммуникации с другими сотрудниками посмотришь. И давай ему по учебникам - сначала плюсы, потом минусы, потом на позитиве заканчиваешь. Методом "гамбургера" это, кажется, называется.
Меж тем иногда этот метод применять не стоит.
Иногда стоит минусами обойтись. Корону сбить. Как граблями.
А иногда просто поддержать нужно, посаппортить. Без всякого развития. Просто потому что хороший. Бывает, что нужно и так. Помогает.
В общем, обратная связь - очень полезный инструмент. Пользуйтесь почаще. Запрашивайте почаще.
Обсудить в ФБ: https://facebook.com/WebByte/posts/1672786796119393
Примерно раз в месяц я рассказываю, как проводить декомпозицию.
Беру какой-нибудь пример с небольшим числом требований. На выходе должна появиться последовательность задач, обеспечивающих выполнение этих требований.
Один из этапов декомпозиции — проверка целостности полученного решения. На этапе проверяются два простых правила.
1. Каждому требованию из примера соответствует хотя б одна задача.
2. Нет задач без соответствующих им требований
Первое правило показывает, что мы не забыли учесть ни одно из требований. Второе — что не делаем лишнего.
Вот со вторым правилом постоянно проблемы.
Каждая группа пытается обязательно придумать что-нибудь избыточное. Вот, к примеру, есть задание "Организовать перелет из Москвы в Лондон". Так обязательно предложат купить обратный билет. Или обязательно задумаются о негабаритном багаже.
Любим мы переусложнять, ага.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1676173999114006
Беру какой-нибудь пример с небольшим числом требований. На выходе должна появиться последовательность задач, обеспечивающих выполнение этих требований.
Один из этапов декомпозиции — проверка целостности полученного решения. На этапе проверяются два простых правила.
1. Каждому требованию из примера соответствует хотя б одна задача.
2. Нет задач без соответствующих им требований
Первое правило показывает, что мы не забыли учесть ни одно из требований. Второе — что не делаем лишнего.
Вот со вторым правилом постоянно проблемы.
Каждая группа пытается обязательно придумать что-нибудь избыточное. Вот, к примеру, есть задание "Организовать перелет из Москвы в Лондон". Так обязательно предложат купить обратный билет. Или обязательно задумаются о негабаритном багаже.
Любим мы переусложнять, ага.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1676173999114006
Идеальные требования наглядны.
Так я начинаю один из блоков занятия про техническое задание в рамках преподавания в «Нетология» и ВШБИ.
Уже почти нет возражений, что хорошая диаграмма заменяет много текста. Понемногу понимают, что современное поколение программистов не любит читать большие тексты, но вполне нормально относится к картинкам, схемам и диаграммам. Одна диаграмма вполне заменяет 3-4 абзаца текста.
Уже никто не спорит с тем, что в хорошем ТЗ должны быть прототипы. Спрашивают разве что, какими инструментами их делать. Я рассказываю про всякие Sketch или Figma, про сервисы рисования схем и диаграмм. Вроде Draw.io или Gliffty. Даже про Tilda рассказываю как средство прототипирования. А чо, можно и на ней собрать.
Но вот слайд про то, что для пользовательских сценариев и прототипирования можно использовать простейшие подручные вещи — типа маркерной доски, стикеров или бумаги — иногда вызывает легкую усмешку. А зря. Теплая ламповая бумага вполне рулит, когда что-то нужно быстро нарисовать. Салфетки часто под рукой. А вот онлайн-инструменты не всегда.
Кстати, на маркерной доске отлично можно изобразить план запуска проекта, даже если проект очень длительный. Главное, чтобы 3-4 разноцветных маркера были под рукой. И уборщица не стерла ваш замечательный план.
А как вы делаете прототипы и пользовательские сценарии?
Ответить в ФБ: https://www.facebook.com/WebByte/posts/1679021618829244
Так я начинаю один из блоков занятия про техническое задание в рамках преподавания в «Нетология» и ВШБИ.
Уже почти нет возражений, что хорошая диаграмма заменяет много текста. Понемногу понимают, что современное поколение программистов не любит читать большие тексты, но вполне нормально относится к картинкам, схемам и диаграммам. Одна диаграмма вполне заменяет 3-4 абзаца текста.
Уже никто не спорит с тем, что в хорошем ТЗ должны быть прототипы. Спрашивают разве что, какими инструментами их делать. Я рассказываю про всякие Sketch или Figma, про сервисы рисования схем и диаграмм. Вроде Draw.io или Gliffty. Даже про Tilda рассказываю как средство прототипирования. А чо, можно и на ней собрать.
Но вот слайд про то, что для пользовательских сценариев и прототипирования можно использовать простейшие подручные вещи — типа маркерной доски, стикеров или бумаги — иногда вызывает легкую усмешку. А зря. Теплая ламповая бумага вполне рулит, когда что-то нужно быстро нарисовать. Салфетки часто под рукой. А вот онлайн-инструменты не всегда.
Кстати, на маркерной доске отлично можно изобразить план запуска проекта, даже если проект очень длительный. Главное, чтобы 3-4 разноцветных маркера были под рукой. И уборщица не стерла ваш замечательный план.
А как вы делаете прототипы и пользовательские сценарии?
Ответить в ФБ: https://www.facebook.com/WebByte/posts/1679021618829244
Должна ли быть открытой информация о зарплатах в компании?
Есть ли однозначный ответ на этот вопрос? Если не должна, то как это сочетается с заявлениями компании о "прозрачности"? Если должна, то как объяснить, почему у Марьванны зарплата выше, чем у Сансаныча? Вот, говорят, даже в Morning Star информация о зарплатах закрыта. Хотя вродь осознанность высокая у сотрудников. В книжках про них пишут, ага-ага.
А должна ли быть прозрачна вилка зарплаты на грейде? А то, на каком грейде находится сотрудник?
А должна ли быть прозрачность в том, насколько компания в зарплатах соответствует рынку? А должность в компании насколько?
А должна ли бы прозрачна информация о зарплатах в отрасли и профессиях?
Вот Яндекс считает, что не должна.
И закрыл свой сервис про зарплаты: "К сожалению, данный раздел был закрыт и больше не поддерживается. Его возвращение не планируется.".
Пойду, слайд из презентации удалю. Устарела.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1681836321881107
Есть ли однозначный ответ на этот вопрос? Если не должна, то как это сочетается с заявлениями компании о "прозрачности"? Если должна, то как объяснить, почему у Марьванны зарплата выше, чем у Сансаныча? Вот, говорят, даже в Morning Star информация о зарплатах закрыта. Хотя вродь осознанность высокая у сотрудников. В книжках про них пишут, ага-ага.
А должна ли быть прозрачна вилка зарплаты на грейде? А то, на каком грейде находится сотрудник?
А должна ли быть прозрачность в том, насколько компания в зарплатах соответствует рынку? А должность в компании насколько?
А должна ли бы прозрачна информация о зарплатах в отрасли и профессиях?
Вот Яндекс считает, что не должна.
И закрыл свой сервис про зарплаты: "К сожалению, данный раздел был закрыт и больше не поддерживается. Его возвращение не планируется.".
Пойду, слайд из презентации удалю. Устарела.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1681836321881107