Больше доить и меньше кормить
Есть такой известный анекдот:
«Чтобы коровы больше давали молока и меньше ели, их надо больше доить и меньше кормить.»
Сегодня хотелось бы рассмотреть один из инструментов для реализации такой стратегии менеджмента в ИТ (и не только).
Надо такие вещи уметь распознавать, чтобы понимать с кем связался, и что тебя ждет в будущем.
Суть стратегии
Суть – моральное давление на сотрудников. Не важно, как человек работает, как растет, каких успехов он достигает, какие задачи выполняет. Главное находить поводы для недовольства и упреков, развивая в работнике постоянное чувство вины и стыда.
В состоянии этого чувства вины сотрудник будет стремиться её компенсировать еще более продолжительным и усердным трудом, а денег просить не будет, потому что ему и так очень стыдно, что даже за текущую зарплату работодатель им недоволен.
Плюсы
Хоть это и звучит бесчеловечно и аморально, но у этого подхода есть очевидный финансовый плюс. На какое-то время работники правда доятся больше, а едят меньше. Недовольные, конечно, уходят, но их легко заменить новыми, которых тоже можно выжимать досуха, отправляя потом на заслуженный отдых в рехаб.
Этой стратегий раньше частенько пользовались какие-нибудь региональные работодатели галерного типа. Живешь в небольшом городе, рабочих мест не так много. Работодатель купается в кандидатах не особенно высокой квалификации, которые не могут найти себе другое место работы, и доит их пока может, подготовив какой-нибудь складный процесс ротации кадров (ведь его это непременно ждет).
В итоге получается вполне рабочая бизнес модель, где угнетенные и зашеймленные работники, опустив голову, безропотно гребут своими мозолистыми руками. А денежки-то капают.
Минусы
Почему я сказал «раньше»? Потому что последние лет 5 в России начала приподниматься удаленка, а с началом пандемии она подняла голову и в России, и в мире в целом, настолько резким рывком, что аж челка назад запрокинулась. И работодатели, научившиеся работать в распределенных командах, запылесосили угнетенных региональных страдальцев за зарплаты кратно более высокие, организовав им более комфортные условия труда не только финансовые, но и психологические.
В итоге бесчеловечные работодатели не просто лишились дойных коров, а еще и получили ведро говна от ушедших сотрудников, которые поняли, что можно, оказывается, работать и так, чтобы с тобой обращались по-человечески и с уважением к твоему труду.
В итоге и эйчар бренд в глубокой яме, и рабочая сила разбежалась. Остается только надежда вузы пылесосить и студентов за дошик учить работать, да клиенту продавать как-то их творчество. Да и то сейчас уже и студенты в курсе, как вообще в жизни бывает.
Итог
Работодателям тут нет смысла что-то советовать. Уверен, что работодатель, который так поступает, в большинстве случаев делает это сознательно. И не будет такой человек никаких советов слушать, он сам кузнец своих денежек.
А работникам хочу посоветовать ретроспективно оценить, нет ли у них в работе с их руководством подобных тревожных звоночков. По опыту консалтинга нескольких десятков людей я вижу, что такие ситуации зачастую сложно заметить, если ты в них уже привык находиться. Всё это сливается в единую какую-то ненормальную «норму».
Тут помогает остановиться и постараться сознательно взглянуть на себя и руководство со стороны. Поговорить со своими коллегами. Поговорить с людьми из разных компаний, узнать, как в целом люди в индустрии живут и работают.
Успехов вам, крепкого ментального здоровья!
Есть такой известный анекдот:
«Чтобы коровы больше давали молока и меньше ели, их надо больше доить и меньше кормить.»
Сегодня хотелось бы рассмотреть один из инструментов для реализации такой стратегии менеджмента в ИТ (и не только).
Надо такие вещи уметь распознавать, чтобы понимать с кем связался, и что тебя ждет в будущем.
Суть стратегии
Суть – моральное давление на сотрудников. Не важно, как человек работает, как растет, каких успехов он достигает, какие задачи выполняет. Главное находить поводы для недовольства и упреков, развивая в работнике постоянное чувство вины и стыда.
В состоянии этого чувства вины сотрудник будет стремиться её компенсировать еще более продолжительным и усердным трудом, а денег просить не будет, потому что ему и так очень стыдно, что даже за текущую зарплату работодатель им недоволен.
Плюсы
Хоть это и звучит бесчеловечно и аморально, но у этого подхода есть очевидный финансовый плюс. На какое-то время работники правда доятся больше, а едят меньше. Недовольные, конечно, уходят, но их легко заменить новыми, которых тоже можно выжимать досуха, отправляя потом на заслуженный отдых в рехаб.
Этой стратегий раньше частенько пользовались какие-нибудь региональные работодатели галерного типа. Живешь в небольшом городе, рабочих мест не так много. Работодатель купается в кандидатах не особенно высокой квалификации, которые не могут найти себе другое место работы, и доит их пока может, подготовив какой-нибудь складный процесс ротации кадров (ведь его это непременно ждет).
В итоге получается вполне рабочая бизнес модель, где угнетенные и зашеймленные работники, опустив голову, безропотно гребут своими мозолистыми руками. А денежки-то капают.
Минусы
Почему я сказал «раньше»? Потому что последние лет 5 в России начала приподниматься удаленка, а с началом пандемии она подняла голову и в России, и в мире в целом, настолько резким рывком, что аж челка назад запрокинулась. И работодатели, научившиеся работать в распределенных командах, запылесосили угнетенных региональных страдальцев за зарплаты кратно более высокие, организовав им более комфортные условия труда не только финансовые, но и психологические.
В итоге бесчеловечные работодатели не просто лишились дойных коров, а еще и получили ведро говна от ушедших сотрудников, которые поняли, что можно, оказывается, работать и так, чтобы с тобой обращались по-человечески и с уважением к твоему труду.
В итоге и эйчар бренд в глубокой яме, и рабочая сила разбежалась. Остается только надежда вузы пылесосить и студентов за дошик учить работать, да клиенту продавать как-то их творчество. Да и то сейчас уже и студенты в курсе, как вообще в жизни бывает.
Итог
Работодателям тут нет смысла что-то советовать. Уверен, что работодатель, который так поступает, в большинстве случаев делает это сознательно. И не будет такой человек никаких советов слушать, он сам кузнец своих денежек.
А работникам хочу посоветовать ретроспективно оценить, нет ли у них в работе с их руководством подобных тревожных звоночков. По опыту консалтинга нескольких десятков людей я вижу, что такие ситуации зачастую сложно заметить, если ты в них уже привык находиться. Всё это сливается в единую какую-то ненормальную «норму».
Тут помогает остановиться и постараться сознательно взглянуть на себя и руководство со стороны. Поговорить со своими коллегами. Поговорить с людьми из разных компаний, узнать, как в целом люди в индустрии живут и работают.
Успехов вам, крепкого ментального здоровья!
Учеба: менеджеры vs технари
Этот пост навеян несколькими вещами:
⁃ Постом на хабре, как мужчина в 65 лет потерял работу и его теперь никуда не берут. Отходя от темы возраста, я просто подумал о его карьере в ИТ длиной в 40 (вроде) лет. Страшно понимать, сколько в такой длинной карьере техническому специалисту приходится переучиваться, доучиваться, следить за обновлениями всех его текущих и появляющихся новых инструментов.
⁃ Рефлексией и консалтингом технических специалистов и менеджеров. Могу сравнивать объемы требуемых знаний и навыков как на себе, так и на других.
⁃ Ремонтом (внезапно). Жена состоит вместе со мной в чате с прорабом и угарает от того, что я ему пишу формулировками из классического менеджмента 🙂
Учеба технарей
В технической части ИТ профессии есть очень большой пласт знаний, который постоянен, языконезависим (особо) и мало меняется. Освоив его однажды, не обязательно как-то пристально дальше следить за этим. Это классический computer science: базы данных, алгоритмы и структуры данных, паттерны проектирования, парадигмы программирования, бест практисы типа вменяемого нейминга и т.д.
Если бы всё этим и заканчивалось, была бы красота. Однако с этого всё скорее только начинается. Для реальной работы, за которую платят реальные деньги нужно хорошо уметь жонглировать теми инструментами, которые индустрия регулярно генерит, обновляет, изменяет и убивает. Языки программирования, фреймворки, работа с инфраструктурой – всё это постоянно меняющаяся, бурлящая река.
И даже если вы скажете «Зачем мне новый язык и фреймворк, ведь я могу сидеть на текущем проекте с застывшим стэком 5 лет и не париться?». Нет, не можете. Даже один инструмент постоянно меняется. Обновления несут новую функциональность, отпиливают старую, порой ломают обратную совместимость. И в итоге это превращается в постоянную гонку, где каждые 3-6 месяцев вы даже в своих текущих инструментах разбираете все обновления, что-то переписываете, дописываете, меняете, патчите. А там где-то в фоне уже выходят новые фреймворки, языки, инструменты, и эта гонка, скорее всего, не в вашу пользу.
А тут еще индустрия мягко намекает вам, что софт скиллы неплохо было бы подтянуть:)
Учеба менеджеров
С менеджментом, на мой взгляд, проще. Да, у менеджеров тоже огромный пласт знаний и навыков, которыми необходимо владеть, чтобы хорошо делать свою работу. Это и в целом работа и коммуникация с людьми, проджект и продакт менеджмент, бизнес скиллы и т.д. Одна только информация из PMBOK чего стоит. Много где можно надолго залипнуть, НО…
Но нет таких постоянных апдейтов, где каждые полгода что-то ощутимо меняется и новое рождается, а вчера родившееся новое отмирает. Ну придумают за пару-тройку лет какую-нибудь фигульку новую. Типа, у нас три года назад был KPI, а сейчас давайте OKR пусть будет. PMBOK за 35 лет всего лишь 7 изданий заимел. Аджайл манифест так уже 20 лет висит как висел.
Перспективы
Менеджером вы засните на 5 лет, проснитесь и продолжите менеджерить примерно точно так же. Потому что всё это работа про людей, здравый смысл и денежки. А еще не только в работе это сработает, но и в целом в жизни. Какая разница, что вы хотите нормально скоординировать, рабочий проект, или проект по ремонту своей квартиры?
А технарем усните на 5 лет и проснетесь на обочине индустрии. Всё уже изменилось, а вы безнадежно отстали, добро пожаловать на поддержку сайта региональной парикмахерской.
Но есть насчет перспектив у технарей еще один плюс. В среднем нормальный менеджер только на внутреннем (я из России) рынке может работать. Не нужны особо за границей менеджеры, там своих хватает. А вот технари нужны, и нужны сильно. Так что будучи хорошим технарем в разы проще найти себе работу за твердую общемировую валюту.
Итог
С одной стороны, мне, как полутехнарю, интересно разбирать эти новые тулзы и быть где-то в потоке индустрии.
С другой стороны, как полуменеджер, я знаю, что эта моя часть более долгосрочно перспективная в плане трудоустройства (на Российском рынке).
Так что порефлексируйте над тем, что вам нравится, какие у вас планы на жизнь и карьеру.
Этот пост навеян несколькими вещами:
⁃ Постом на хабре, как мужчина в 65 лет потерял работу и его теперь никуда не берут. Отходя от темы возраста, я просто подумал о его карьере в ИТ длиной в 40 (вроде) лет. Страшно понимать, сколько в такой длинной карьере техническому специалисту приходится переучиваться, доучиваться, следить за обновлениями всех его текущих и появляющихся новых инструментов.
⁃ Рефлексией и консалтингом технических специалистов и менеджеров. Могу сравнивать объемы требуемых знаний и навыков как на себе, так и на других.
⁃ Ремонтом (внезапно). Жена состоит вместе со мной в чате с прорабом и угарает от того, что я ему пишу формулировками из классического менеджмента 🙂
Учеба технарей
В технической части ИТ профессии есть очень большой пласт знаний, который постоянен, языконезависим (особо) и мало меняется. Освоив его однажды, не обязательно как-то пристально дальше следить за этим. Это классический computer science: базы данных, алгоритмы и структуры данных, паттерны проектирования, парадигмы программирования, бест практисы типа вменяемого нейминга и т.д.
Если бы всё этим и заканчивалось, была бы красота. Однако с этого всё скорее только начинается. Для реальной работы, за которую платят реальные деньги нужно хорошо уметь жонглировать теми инструментами, которые индустрия регулярно генерит, обновляет, изменяет и убивает. Языки программирования, фреймворки, работа с инфраструктурой – всё это постоянно меняющаяся, бурлящая река.
И даже если вы скажете «Зачем мне новый язык и фреймворк, ведь я могу сидеть на текущем проекте с застывшим стэком 5 лет и не париться?». Нет, не можете. Даже один инструмент постоянно меняется. Обновления несут новую функциональность, отпиливают старую, порой ломают обратную совместимость. И в итоге это превращается в постоянную гонку, где каждые 3-6 месяцев вы даже в своих текущих инструментах разбираете все обновления, что-то переписываете, дописываете, меняете, патчите. А там где-то в фоне уже выходят новые фреймворки, языки, инструменты, и эта гонка, скорее всего, не в вашу пользу.
А тут еще индустрия мягко намекает вам, что софт скиллы неплохо было бы подтянуть:)
Учеба менеджеров
С менеджментом, на мой взгляд, проще. Да, у менеджеров тоже огромный пласт знаний и навыков, которыми необходимо владеть, чтобы хорошо делать свою работу. Это и в целом работа и коммуникация с людьми, проджект и продакт менеджмент, бизнес скиллы и т.д. Одна только информация из PMBOK чего стоит. Много где можно надолго залипнуть, НО…
Но нет таких постоянных апдейтов, где каждые полгода что-то ощутимо меняется и новое рождается, а вчера родившееся новое отмирает. Ну придумают за пару-тройку лет какую-нибудь фигульку новую. Типа, у нас три года назад был KPI, а сейчас давайте OKR пусть будет. PMBOK за 35 лет всего лишь 7 изданий заимел. Аджайл манифест так уже 20 лет висит как висел.
Перспективы
Менеджером вы засните на 5 лет, проснитесь и продолжите менеджерить примерно точно так же. Потому что всё это работа про людей, здравый смысл и денежки. А еще не только в работе это сработает, но и в целом в жизни. Какая разница, что вы хотите нормально скоординировать, рабочий проект, или проект по ремонту своей квартиры?
А технарем усните на 5 лет и проснетесь на обочине индустрии. Всё уже изменилось, а вы безнадежно отстали, добро пожаловать на поддержку сайта региональной парикмахерской.
Но есть насчет перспектив у технарей еще один плюс. В среднем нормальный менеджер только на внутреннем (я из России) рынке может работать. Не нужны особо за границей менеджеры, там своих хватает. А вот технари нужны, и нужны сильно. Так что будучи хорошим технарем в разы проще найти себе работу за твердую общемировую валюту.
Итог
С одной стороны, мне, как полутехнарю, интересно разбирать эти новые тулзы и быть где-то в потоке индустрии.
С другой стороны, как полуменеджер, я знаю, что эта моя часть более долгосрочно перспективная в плане трудоустройства (на Российском рынке).
Так что порефлексируйте над тем, что вам нравится, какие у вас планы на жизнь и карьеру.
Вышло мое небольшое интервью со скиллбокс медиа.
Сначала хотели поговорить про одно, но потом как-то за консалтинг зацепились, и понеслось🙂
https://skillbox.ru/media/code/kak-razrabotchiku-stat-konsultantom/
Сначала хотели поговорить про одно, но потом как-то за консалтинг зацепились, и понеслось🙂
https://skillbox.ru/media/code/kak-razrabotchiku-stat-konsultantom/
Skillbox
Как разработчику стать консультантом
Программисты продают не только код, но и опыт. Если у вас за плечами много лет разработки, можно попробовать силы в IT-консалтинге.
Секция шутёх
Сегодня хочу рассказать про один небольшой ритуал, который делает работу нашей команды немного приятнее.
Никого не агитирую делать точно так же. Я это сделал осознанно, попробовав, посмотрев на реакцию, инициативу, опросив людей по результатам.
В чем суть?
У определенной части нашего коллектива раз в 2 недели существует ретроспектива. И вот в конце этой ретроспективы, когда уже всё обговорено, новый спринт заведен, рабочие моменты все закрыты, я предложил делать «секцию шутёх».
Это просто еще полчасика времени, где мы все болтаем о жизни, рассказываем шутки, истории какие-то, стараемся обходиться без душноты и работы.
Участие в секции шутёх исключительно добровольное. Если кто-то торопится или не хочет, то его/её никто не держит.
Со временем я стал замечать, что на секцию шутёх с определенной долей удовольствия остаются все участники ретроспективы. Все весело и душевно общаются. Даже те люди, кто на общих собраниях обычно отмалчивается, на секции шутёх становятся более разговорчивые, расслабленные, с новой стороны раскрываются для коллектива.
На выходные я стал уходить с замечательным настроением. Поспрашивал у некоторых ребят, от них услышал примерно такие же отзывы.
Потом попробовал не раз в 2 недели делать эту секцию, а каждую пятницу, и звать именно на неё уже всю команду. Сейчас приходит процентов 70-80 от всей команды. И я очень рад, что мы все можем после трудовой недели собраться и «на дорожку» потравить каких-нибудь баек, что-то пообсуждать, посмеяться и разойтись в хорошем настроении.
Что же это дало?
Обложил ли я это какими-то метриками? Нет, конечно.
Посчитал ли выгоду в деньгах или других измеримых единицах? Тоже нет.
Лично мне достаточно понимать, что это не какая-то хитрая менеджерская уловка, не ритуал, который спланирован для повышения бодрости «человеческих ресурсов», а просто искренне желанная расслабленная беседа с коллегами. Желанная для меня и для коллег.
Мы все люди на работе, нам всем хочется, чтобы было не только ЭФФЕКТИВНО, но и приятно. И вот с приятностью у нас в коллективе всё в порядке. А уже побочный эффект от приятности – низкая ротация кадров. Тут желающие посчитать профиты от низкой ротации кадров могут легко прикинуть выгоды и по найму, и по ФОТу, и по времени на адаптацию, и по простою работ в периоды недоукомплектации команды.
Итог
Если можете сделать работу себя и своей команды немножечко душевнее, то почему бы и нет?)
Но делайте это, не бездумно повторяя за кем-то, а наблюдая, анализируя, подстраиваясь индивидуально под свои условия.
Сегодня хочу рассказать про один небольшой ритуал, который делает работу нашей команды немного приятнее.
Никого не агитирую делать точно так же. Я это сделал осознанно, попробовав, посмотрев на реакцию, инициативу, опросив людей по результатам.
В чем суть?
У определенной части нашего коллектива раз в 2 недели существует ретроспектива. И вот в конце этой ретроспективы, когда уже всё обговорено, новый спринт заведен, рабочие моменты все закрыты, я предложил делать «секцию шутёх».
Это просто еще полчасика времени, где мы все болтаем о жизни, рассказываем шутки, истории какие-то, стараемся обходиться без душноты и работы.
Участие в секции шутёх исключительно добровольное. Если кто-то торопится или не хочет, то его/её никто не держит.
Со временем я стал замечать, что на секцию шутёх с определенной долей удовольствия остаются все участники ретроспективы. Все весело и душевно общаются. Даже те люди, кто на общих собраниях обычно отмалчивается, на секции шутёх становятся более разговорчивые, расслабленные, с новой стороны раскрываются для коллектива.
На выходные я стал уходить с замечательным настроением. Поспрашивал у некоторых ребят, от них услышал примерно такие же отзывы.
Потом попробовал не раз в 2 недели делать эту секцию, а каждую пятницу, и звать именно на неё уже всю команду. Сейчас приходит процентов 70-80 от всей команды. И я очень рад, что мы все можем после трудовой недели собраться и «на дорожку» потравить каких-нибудь баек, что-то пообсуждать, посмеяться и разойтись в хорошем настроении.
Что же это дало?
Обложил ли я это какими-то метриками? Нет, конечно.
Посчитал ли выгоду в деньгах или других измеримых единицах? Тоже нет.
Лично мне достаточно понимать, что это не какая-то хитрая менеджерская уловка, не ритуал, который спланирован для повышения бодрости «человеческих ресурсов», а просто искренне желанная расслабленная беседа с коллегами. Желанная для меня и для коллег.
Мы все люди на работе, нам всем хочется, чтобы было не только ЭФФЕКТИВНО, но и приятно. И вот с приятностью у нас в коллективе всё в порядке. А уже побочный эффект от приятности – низкая ротация кадров. Тут желающие посчитать профиты от низкой ротации кадров могут легко прикинуть выгоды и по найму, и по ФОТу, и по времени на адаптацию, и по простою работ в периоды недоукомплектации команды.
Итог
Если можете сделать работу себя и своей команды немножечко душевнее, то почему бы и нет?)
Но делайте это, не бездумно повторяя за кем-то, а наблюдая, анализируя, подстраиваясь индивидуально под свои условия.
Горящие глаза
Многим знакомо желание работодателя видеть «горящие глаза» у своих сотрудников. Но хотелось бы обсудить, насколько реалистично и этично превращать это в требование.
Где горящие глаза нужны
Наверное, самый главный случай, когда нужен большой энтузиазм в работе, – когда работать приходит джуниор. Впереди его ждет очень долгая и сложная дорога, а ухабы начинаются прямо со старта. Чтобы это всё не бросить (что часто бывает) и расти дальше профессионально, потребуется действительно огромный энтузиазм.
Где горящие глаза не нужны
Почти во всех остальных случаях, если вы работаете с уже компетентным специалистом.
Я не говорю сейчас о наплевательском отношении к работе. Я говорю о купировании лозунгов «МЫ СЕМЬЯ», «НОЧЬ РАБОТЕ НЕ ПОМЕХА», и прочих манипулятивных историях, в которых из людей тянут жизнь капельку за капелькой.
В целом наша работа во многом довольно рутинная, что бы там ни говорили про труд программистов и менеджеров. Да, есть творческие аспекты, но есть и обыкновенные скучные рядовые задачи, которые нам необходимо решать. Есть известное сравнение людей в профессии с малярами и художниками. Да, кое-где иногда нужны одаренные художники. Им, конечно, энтузиазм в работе необходим для реализации своего творческого потенциала. Но в подавляющем большинстве случаев мы с вами – маляры. А маляры просто делают свою обычную работу, и я не понимаю, зачем от них требовать какого-то дополнительного запала.
Однажды меня и моего коллегу работодатель на полном серьезе вызвал на разговор. Единственной его претензией было то, что у нас «не горят глаза». Прямо буквально в этом была суть претензии. При этом работа была абсолютно рутинная, а зарплаты хватало ровно на то, чтобы заплатить за квартиру, купить по скидкам простейшую еду в пятерочке и оплатить интернет. На новую одежду, или лекарства, или поездку куда-то, или технику оставалось от 0 до 1к рублей в месяц. От чего конкретно у меня должны были зажечься глаза, я не понимал ни тогда, ни сейчас.
Этично ли было это требование? Я считаю, что нет. Долго ли мы потом проработали вместе? Тоже нет.
Чем хорошо заменяются горящие глаза
Они заменяются профессиональным и добросовестным трудом.
Это значит, что работу, которую вы беретесь делать, вы делаете хорошо и качественно. Если что-то непонятно или есть сомнения – уточняете, а не лепите откровенно некорректное решение, прикрываясь «в задаче так сказано». Если где-то можете что-то предложить, улучшить, привнести – делаете, потому что так система станет лучше, так труд вас и ваших товарищей станет эффективнее и комфортнее. Если где-то чувствуете, что что-то идет не так – предупреждаете кого следует, или принимаете меры самостоятельно.
Если при этом вам еще и в целом не безразличен продукт, который вы делаете, то это вообще красота. Для работодателя это большая удача найти не просто профессионала, а профессионала, активно заинтересованного в самом продукте. Это не базовое требование к сотруднику, это большая удача (либо сознательное формирование целого комплекса материальных и нематериальных факторов, формирующих именно такой найм).
Итог
Трудитесь хорошо и добросовестно, но не позволяйте на себе бессовестно кататься.
А если вы работодатель, то цените тех, кому ваше дело не безразлично. Не тираньте тех, кто продает вам свой труд. Вам продают свои труд, время, навыки, опыт, а не душу.
Многим знакомо желание работодателя видеть «горящие глаза» у своих сотрудников. Но хотелось бы обсудить, насколько реалистично и этично превращать это в требование.
Где горящие глаза нужны
Наверное, самый главный случай, когда нужен большой энтузиазм в работе, – когда работать приходит джуниор. Впереди его ждет очень долгая и сложная дорога, а ухабы начинаются прямо со старта. Чтобы это всё не бросить (что часто бывает) и расти дальше профессионально, потребуется действительно огромный энтузиазм.
Где горящие глаза не нужны
Почти во всех остальных случаях, если вы работаете с уже компетентным специалистом.
Я не говорю сейчас о наплевательском отношении к работе. Я говорю о купировании лозунгов «МЫ СЕМЬЯ», «НОЧЬ РАБОТЕ НЕ ПОМЕХА», и прочих манипулятивных историях, в которых из людей тянут жизнь капельку за капелькой.
В целом наша работа во многом довольно рутинная, что бы там ни говорили про труд программистов и менеджеров. Да, есть творческие аспекты, но есть и обыкновенные скучные рядовые задачи, которые нам необходимо решать. Есть известное сравнение людей в профессии с малярами и художниками. Да, кое-где иногда нужны одаренные художники. Им, конечно, энтузиазм в работе необходим для реализации своего творческого потенциала. Но в подавляющем большинстве случаев мы с вами – маляры. А маляры просто делают свою обычную работу, и я не понимаю, зачем от них требовать какого-то дополнительного запала.
Однажды меня и моего коллегу работодатель на полном серьезе вызвал на разговор. Единственной его претензией было то, что у нас «не горят глаза». Прямо буквально в этом была суть претензии. При этом работа была абсолютно рутинная, а зарплаты хватало ровно на то, чтобы заплатить за квартиру, купить по скидкам простейшую еду в пятерочке и оплатить интернет. На новую одежду, или лекарства, или поездку куда-то, или технику оставалось от 0 до 1к рублей в месяц. От чего конкретно у меня должны были зажечься глаза, я не понимал ни тогда, ни сейчас.
Этично ли было это требование? Я считаю, что нет. Долго ли мы потом проработали вместе? Тоже нет.
Чем хорошо заменяются горящие глаза
Они заменяются профессиональным и добросовестным трудом.
Это значит, что работу, которую вы беретесь делать, вы делаете хорошо и качественно. Если что-то непонятно или есть сомнения – уточняете, а не лепите откровенно некорректное решение, прикрываясь «в задаче так сказано». Если где-то можете что-то предложить, улучшить, привнести – делаете, потому что так система станет лучше, так труд вас и ваших товарищей станет эффективнее и комфортнее. Если где-то чувствуете, что что-то идет не так – предупреждаете кого следует, или принимаете меры самостоятельно.
Если при этом вам еще и в целом не безразличен продукт, который вы делаете, то это вообще красота. Для работодателя это большая удача найти не просто профессионала, а профессионала, активно заинтересованного в самом продукте. Это не базовое требование к сотруднику, это большая удача (либо сознательное формирование целого комплекса материальных и нематериальных факторов, формирующих именно такой найм).
Итог
Трудитесь хорошо и добросовестно, но не позволяйте на себе бессовестно кататься.
А если вы работодатель, то цените тех, кому ваше дело не безразлично. Не тираньте тех, кто продает вам свой труд. Вам продают свои труд, время, навыки, опыт, а не душу.
Раз на раз выскочим?
Сегодня речь пойдет о встречах один на один (сократим до 1-1).
Это общеизвестный и широко применяемый нынче в менеджменте инструмент, в рамках которого организуются регулярные встречи один на один с руководителем. На них можно проговорить все волнующие проблемы, понять общее моральное состояние сотрудников, принять какие-то решения, как дальше жить.
Правда с недавних пор слышу и определенную критику. Постараюсь коротко про всё это рассказать.
Плюсы
Руководители часто оторваны от своей команды по тем или иным причинам. У кого-то перегруз своими задачами, а кто-то просто плохой руководитель, который не понимает и не хочет понимать, как с людьми работать.
1-1 помогает глубже погрузиться в то, что конкретно у каждого работника происходит. Раз уж у нас такая сфера, где люди очень ценны, то этим заниматься необходимо. Важно понимать проблемы людей и по мере сил их разрешать.
Знаю лично примеры, когда руководители начинали вводить регулярные (раз в 2-4 недели) 1-1 встречи, и у них прям глаза открывались на то, что происходит на самом деле в команде. Да и сотрудникам тоже хорошо, что есть такой приватный разговор, где можно выговориться о наболевшем и получить обратную связь от руководителя без лишних свидетелей.
Важно отметить, что сразу должно быть оговорено, что этот разговор должен быть откровенным, следовательно, каждый должен чувствовать, что за его открытость у него не будет проблем. Задача руководителя – на таких встречах добиться от работника откровенности и привить чувство безопасности одновременно.
Резюме: работник принес свои проблемы, руководитель их решает, да и в целом лучше осведомлен о происходящем.
Критика
Есть одна претензия простая и одна посложнее.
Простая: регулярность 1-1 встреч, когда нечего сказать. Иногда бывает, что и работнику, и руководителю говорить не о чем, но встреча в календаре есть. Они все равно собираются и высасывают из пальца разговор, в душе мечтая побыстрее его закончить и пойти своими делами заниматься. Тут я предлагаю просто заранее синкануться, и если у каждого нет тем для обсуждения, просто пропустить встречу.
Посложнее: отложенность обсуждения проблем. Если у вас появилась проблема, а вы ждете 2-4 недели, чтобы её обсудить, это не очень эффективно. Тут я полностью согласен. Лучше строить такую систему, в которой не раз в N времени вытягиваются из людей проблемы, а в которой по мере появления проблем люди сами будут тут же проталкивать их в неё. Это существенно ускорит решение.
НО. Я не считаю, что 1-1 прям вообще не нужны, если люди научатся откровенно и своевременно поднимать тревожные вопросы.
Люди в целом сложные, и может так оказаться, что не все вопросы удастся пропушить по тем или иным причинам (психологическим, политическим, финансовым и т.д.) Какие-то вещи, да нужно обговаривать один на один иногда. К идеалу можно стремиться, но нельзя достичь. Следовательно, покуда идеал не достигнут, можно и 1-1 повстречаться там, где это необходимо.
Итог
1-1 встречи, на мой взгляд, – инструмент полезный. Но пользоваться им нужно с умом и не надеяться, что он все ваши проблемы решит.
Желательно строить систему, где 1-1 нужен будет все меньше, потому что открытость и своевременность обсуждений проблем в команде будет расти.
Сегодня речь пойдет о встречах один на один (сократим до 1-1).
Это общеизвестный и широко применяемый нынче в менеджменте инструмент, в рамках которого организуются регулярные встречи один на один с руководителем. На них можно проговорить все волнующие проблемы, понять общее моральное состояние сотрудников, принять какие-то решения, как дальше жить.
Правда с недавних пор слышу и определенную критику. Постараюсь коротко про всё это рассказать.
Плюсы
Руководители часто оторваны от своей команды по тем или иным причинам. У кого-то перегруз своими задачами, а кто-то просто плохой руководитель, который не понимает и не хочет понимать, как с людьми работать.
1-1 помогает глубже погрузиться в то, что конкретно у каждого работника происходит. Раз уж у нас такая сфера, где люди очень ценны, то этим заниматься необходимо. Важно понимать проблемы людей и по мере сил их разрешать.
Знаю лично примеры, когда руководители начинали вводить регулярные (раз в 2-4 недели) 1-1 встречи, и у них прям глаза открывались на то, что происходит на самом деле в команде. Да и сотрудникам тоже хорошо, что есть такой приватный разговор, где можно выговориться о наболевшем и получить обратную связь от руководителя без лишних свидетелей.
Важно отметить, что сразу должно быть оговорено, что этот разговор должен быть откровенным, следовательно, каждый должен чувствовать, что за его открытость у него не будет проблем. Задача руководителя – на таких встречах добиться от работника откровенности и привить чувство безопасности одновременно.
Резюме: работник принес свои проблемы, руководитель их решает, да и в целом лучше осведомлен о происходящем.
Критика
Есть одна претензия простая и одна посложнее.
Простая: регулярность 1-1 встреч, когда нечего сказать. Иногда бывает, что и работнику, и руководителю говорить не о чем, но встреча в календаре есть. Они все равно собираются и высасывают из пальца разговор, в душе мечтая побыстрее его закончить и пойти своими делами заниматься. Тут я предлагаю просто заранее синкануться, и если у каждого нет тем для обсуждения, просто пропустить встречу.
Посложнее: отложенность обсуждения проблем. Если у вас появилась проблема, а вы ждете 2-4 недели, чтобы её обсудить, это не очень эффективно. Тут я полностью согласен. Лучше строить такую систему, в которой не раз в N времени вытягиваются из людей проблемы, а в которой по мере появления проблем люди сами будут тут же проталкивать их в неё. Это существенно ускорит решение.
НО. Я не считаю, что 1-1 прям вообще не нужны, если люди научатся откровенно и своевременно поднимать тревожные вопросы.
Люди в целом сложные, и может так оказаться, что не все вопросы удастся пропушить по тем или иным причинам (психологическим, политическим, финансовым и т.д.) Какие-то вещи, да нужно обговаривать один на один иногда. К идеалу можно стремиться, но нельзя достичь. Следовательно, покуда идеал не достигнут, можно и 1-1 повстречаться там, где это необходимо.
Итог
1-1 встречи, на мой взгляд, – инструмент полезный. Но пользоваться им нужно с умом и не надеяться, что он все ваши проблемы решит.
Желательно строить систему, где 1-1 нужен будет все меньше, потому что открытость и своевременность обсуждений проблем в команде будет расти.
Теперь я соведущий во втором сезоне подкаста Кода кода
Если вы помните, то несколько месяцев назад я приходил гостем в подкаст Кода Кода поговорить о работе на удаленке.
А не так давно, мне внезапно написал автор этого подкаста Виктор Корейша и предложил побыть соведущим во втором сезоне.
Выбор тем для подкаста и то, как Виктор трудится над его качеством, мне очень импонирует. Так что согласился я с удовольствием. Формат решили делать такой: сначала между собой немного говорим на выбранную тему, потом интервью с гостями, а потом опять между собой финализируем.
Надеюсь слушателям придется такое по душе (хоть я и буроблю часто), а в идеале еще и пользу какую-то кому-нибудь принесет🙂
Сегодня вышел первый выпуск из уже четырех записанных. В четвертом один из гостей для меня прям вообще отдельное место в сердечке занимает. Думаю, когда вы узнаете кто там, то вы тоже примерно так скажете)
Ссылка на телеграм канал, куда публикуются выпуски подкаста https://www.tg-me.com/kodakodacast/70
Приходите, слушайте, обсуждайте (если есть чего обсудить).
Приятного прослушивания👍
Если вы помните, то несколько месяцев назад я приходил гостем в подкаст Кода Кода поговорить о работе на удаленке.
А не так давно, мне внезапно написал автор этого подкаста Виктор Корейша и предложил побыть соведущим во втором сезоне.
Выбор тем для подкаста и то, как Виктор трудится над его качеством, мне очень импонирует. Так что согласился я с удовольствием. Формат решили делать такой: сначала между собой немного говорим на выбранную тему, потом интервью с гостями, а потом опять между собой финализируем.
Надеюсь слушателям придется такое по душе (хоть я и буроблю часто), а в идеале еще и пользу какую-то кому-нибудь принесет🙂
Сегодня вышел первый выпуск из уже четырех записанных. В четвертом один из гостей для меня прям вообще отдельное место в сердечке занимает. Думаю, когда вы узнаете кто там, то вы тоже примерно так скажете)
Ссылка на телеграм канал, куда публикуются выпуски подкаста https://www.tg-me.com/kodakodacast/70
Приходите, слушайте, обсуждайте (если есть чего обсудить).
Приятного прослушивания👍
Telegram
Кода кода
В первом выпуске второго сезона подкаста «Кода Кода» гости расскажут об IT курсах, их маркетинговой политике, двойственности, проблемах и реальной пользе. В выпуске гости поделятся реальными историями из жизни о курсах разной степени полезности, выявят их…
Три амиго
Не так давно столкнулся с формулировкой «три амиго» на одном из вебинаров про тестирование. Потом понял, что мы сами в своей команде давно наступали на подобные грабли и естественным путем пришли к этой идее. Возможно, если я про неё расскажу, то кто-нибудь не станет повторять эти ошибки, а уже воспользуется более эффективной стратегией.
В чем суть?
Идея в том, чтобы при обсуждении и согласовании фичи собирать команду из трех контекстов: бизнес, разработка и тестирование.
Если сразу вместе подумать о фиче с трех сторон, то существенно сократится время на переделку или пересогласование фичи уже в процессе реализации.
Вы сталкивались с ситуацией, когда менеджер что-то наобещал заказчику, принес разработчикам уже утвержденную идею, а разработчики говорят «так не работает, давай по-другому пересогласовывать»? Или дизайнер нарисовал, заказчик утвердил, отдает во фронтенд, а так нельзя? Или фронтендер наделал дел, отдает в бэкенд, а там тоже что-то не стыкуется?
Вот концепция идеи в том, чтобы единовременно всеми людьми из разных контекстов собираться и утверждать подходящее решение, а потом спокойно делать, без перемены коней на переправе.
Помогло ли это нам?
Определенно очень помогло. У нас нет отдельных тестировщиков (масштаб проектов такой, что разработчики пока сами справляются с написанием тестов), но тем не менее стыки заказчик - бизнес - дизайн - фронтенд - бэкенд болели. И порой приходилось делать двойную или тройную работу, если всё вместе заранее не согласовать.
После того, как стали обсуждать крупные фичи совместно менеджмент-дизайн-разработка, количество проблем, переделок, затраченных нервов существенно сократилось.
Зачем всем сразу время тратить?
Да, кажется, что это трата времени. Почему менеджер не может сразу нормально согласовать, чтобы небожителей разрабских не отвлекать? Почему дизайнер не может так сразу нарисовать, чтобы элита ИТ не выныривала из потока? Да потому что внутри себя даже элитарии от разработки не могут нормально сделать, чтобы в другой отдел передать, и потом не пересогласовывать что-то:)
И это нормально. Не все мы очень дальновидные, не все мы предсказываем будущее, не у всех хорошо работают хрустальные шары.
И вот чтобы нормально получилось, лучше сразу потратить чуть больше времени на согласование, чтобы потом ничего не переделывать. Как говорилось в одном мультике «лучше день потерять, зато потом за час долететь».
Итог
3 амиго – хороший пример согласованной работы команды и своевременного проектирования. Чем раньше на согласование подключатся все нужные контексты, тем меньше будет переделок, затрат нервов и душевных сил.
Не ждите от других чуда, становитесь участником чуда сами:)
Не так давно столкнулся с формулировкой «три амиго» на одном из вебинаров про тестирование. Потом понял, что мы сами в своей команде давно наступали на подобные грабли и естественным путем пришли к этой идее. Возможно, если я про неё расскажу, то кто-нибудь не станет повторять эти ошибки, а уже воспользуется более эффективной стратегией.
В чем суть?
Идея в том, чтобы при обсуждении и согласовании фичи собирать команду из трех контекстов: бизнес, разработка и тестирование.
Если сразу вместе подумать о фиче с трех сторон, то существенно сократится время на переделку или пересогласование фичи уже в процессе реализации.
Вы сталкивались с ситуацией, когда менеджер что-то наобещал заказчику, принес разработчикам уже утвержденную идею, а разработчики говорят «так не работает, давай по-другому пересогласовывать»? Или дизайнер нарисовал, заказчик утвердил, отдает во фронтенд, а так нельзя? Или фронтендер наделал дел, отдает в бэкенд, а там тоже что-то не стыкуется?
Вот концепция идеи в том, чтобы единовременно всеми людьми из разных контекстов собираться и утверждать подходящее решение, а потом спокойно делать, без перемены коней на переправе.
Помогло ли это нам?
Определенно очень помогло. У нас нет отдельных тестировщиков (масштаб проектов такой, что разработчики пока сами справляются с написанием тестов), но тем не менее стыки заказчик - бизнес - дизайн - фронтенд - бэкенд болели. И порой приходилось делать двойную или тройную работу, если всё вместе заранее не согласовать.
После того, как стали обсуждать крупные фичи совместно менеджмент-дизайн-разработка, количество проблем, переделок, затраченных нервов существенно сократилось.
Зачем всем сразу время тратить?
Да, кажется, что это трата времени. Почему менеджер не может сразу нормально согласовать, чтобы небожителей разрабских не отвлекать? Почему дизайнер не может так сразу нарисовать, чтобы элита ИТ не выныривала из потока? Да потому что внутри себя даже элитарии от разработки не могут нормально сделать, чтобы в другой отдел передать, и потом не пересогласовывать что-то:)
И это нормально. Не все мы очень дальновидные, не все мы предсказываем будущее, не у всех хорошо работают хрустальные шары.
И вот чтобы нормально получилось, лучше сразу потратить чуть больше времени на согласование, чтобы потом ничего не переделывать. Как говорилось в одном мультике «лучше день потерять, зато потом за час долететь».
Итог
3 амиго – хороший пример согласованной работы команды и своевременного проектирования. Чем раньше на согласование подключатся все нужные контексты, тем меньше будет переделок, затрат нервов и душевных сил.
Не ждите от других чуда, становитесь участником чуда сами:)
Личный пример
Часто наталкиваюсь на дискуссии про то, как занести в команду какую-то новую практику, регламент, культурную составляющую.
Так же часто люблю говорить, что есть для этого три основных метода: убеждение, принуждение и личный пример.
Убеждение
Штука важная. Конечно, нужно объяснять, просвещать, аргументировать, презентовать. Без этого не обойтись. Это первое, с чего надо начинать.
Люди сами по себе в среднем довольно инертны, никому не хочется напрягаться. А если серьезной аргументации к тому, чтобы их напрячь, нет, то всё это будет восприниматься в штыки.
Принуждение
Тут нужна куда большая осторожность. Особенно в ИТ, где трепетные души работников и кандидатский рынок говорят о том, что мотивация работника нынче важна не только самому работнику, но и его работодателю.
Тут надо тонко чувствовать, когда это перегиб, а когда принуждение – необходимое решение. Иногда такое нужно.
Самый эффективный способ
На мой взгляд, личный пример обязательно нужен для внедрения чего-то нового, хорошего и полезного в коллективе. Отлично работает после или вместе с фазой убеждения.
Можно сколько угодно убеждать кого угодно, что так делать нужно, а по-другому не нужно, но если самостоятельно вы делаете по-другому, то все ваши слова убеждения моментально преобразуются в ложь, профанацию и лукавство.
Это как родители, которые постоянно при детях курят, пьют, ругаются, но ожидают, что ребенок вырастет без вредных привычек и сквернословия только потому, что ему сказали «не надо так делать!».
Негативные примеры личных примеров
Эта идея находит применение сплошь и рядом вокруг нас:
⁃ Пишете непонятные тексты коммитов? Ваши коллеги напишут примерно так же. Успехов в поддержке!
⁃ Назначаете встречу на 10 человек с названием «обкашлять вопросики» без комментариев? Сами будете целыми днями ходить по куче встреч, где непонятно зачем вы здесь, и чего от вас ждут.
⁃ Обещаете что-то сделать и молча сливаетесь, делая вид, что ничего не было? Удачи на следующих зарплатных переговорах, где вам много чего наобещают, а вот исполнят ли – неизвестно.
⁃ Пишете на кодревью коллеге грубые комментарии? Ждите, что с вами будут разговаривать таким же образом (вроде в твиттере недавно читал про то, что один мужик позвал другого драться за гаражами из-за того, что тот отругал его код).
Все это приводит нас еще и к теории разбитых окон, о которой я писал ранее тут https://www.tg-me.com/general_it_talks/48
А если вы руководитель, ваш личный пример особенно важен. Ваши действия особенно пристально рассматриваются работниками и больше воспринимаются, как эталонная модель поведения. Так что здесь не прокатит «да я просто занят», «это для вас, а не для меня правила».
Итог
Подавайте позитивный личный пример, будьте драйвером изменений к лучшему.
Не забывайте сочетать метод убеждения с личным примером, а в особых случаях – и методом принуждения давать по жопе кому следует (всякое бывает:)).
Часто наталкиваюсь на дискуссии про то, как занести в команду какую-то новую практику, регламент, культурную составляющую.
Так же часто люблю говорить, что есть для этого три основных метода: убеждение, принуждение и личный пример.
Убеждение
Штука важная. Конечно, нужно объяснять, просвещать, аргументировать, презентовать. Без этого не обойтись. Это первое, с чего надо начинать.
Люди сами по себе в среднем довольно инертны, никому не хочется напрягаться. А если серьезной аргументации к тому, чтобы их напрячь, нет, то всё это будет восприниматься в штыки.
Принуждение
Тут нужна куда большая осторожность. Особенно в ИТ, где трепетные души работников и кандидатский рынок говорят о том, что мотивация работника нынче важна не только самому работнику, но и его работодателю.
Тут надо тонко чувствовать, когда это перегиб, а когда принуждение – необходимое решение. Иногда такое нужно.
Самый эффективный способ
На мой взгляд, личный пример обязательно нужен для внедрения чего-то нового, хорошего и полезного в коллективе. Отлично работает после или вместе с фазой убеждения.
Можно сколько угодно убеждать кого угодно, что так делать нужно, а по-другому не нужно, но если самостоятельно вы делаете по-другому, то все ваши слова убеждения моментально преобразуются в ложь, профанацию и лукавство.
Это как родители, которые постоянно при детях курят, пьют, ругаются, но ожидают, что ребенок вырастет без вредных привычек и сквернословия только потому, что ему сказали «не надо так делать!».
Негативные примеры личных примеров
Эта идея находит применение сплошь и рядом вокруг нас:
⁃ Пишете непонятные тексты коммитов? Ваши коллеги напишут примерно так же. Успехов в поддержке!
⁃ Назначаете встречу на 10 человек с названием «обкашлять вопросики» без комментариев? Сами будете целыми днями ходить по куче встреч, где непонятно зачем вы здесь, и чего от вас ждут.
⁃ Обещаете что-то сделать и молча сливаетесь, делая вид, что ничего не было? Удачи на следующих зарплатных переговорах, где вам много чего наобещают, а вот исполнят ли – неизвестно.
⁃ Пишете на кодревью коллеге грубые комментарии? Ждите, что с вами будут разговаривать таким же образом (вроде в твиттере недавно читал про то, что один мужик позвал другого драться за гаражами из-за того, что тот отругал его код).
Все это приводит нас еще и к теории разбитых окон, о которой я писал ранее тут https://www.tg-me.com/general_it_talks/48
А если вы руководитель, ваш личный пример особенно важен. Ваши действия особенно пристально рассматриваются работниками и больше воспринимаются, как эталонная модель поведения. Так что здесь не прокатит «да я просто занят», «это для вас, а не для меня правила».
Итог
Подавайте позитивный личный пример, будьте драйвером изменений к лучшему.
Не забывайте сочетать метод убеждения с личным примером, а в особых случаях – и методом принуждения давать по жопе кому следует (всякое бывает:)).
Telegram
Тимлид Очевидность
Теория разбитых окон
Существует криминологическая теория, которая утверждает, что попустительство общества к мелким правонарушениям, таким как выбрасывание мусора в неустановленных для этого местах, вандализм, публичное пьянство, прыжки через турникеты в…
Существует криминологическая теория, которая утверждает, что попустительство общества к мелким правонарушениям, таким как выбрасывание мусора в неустановленных для этого местах, вандализм, публичное пьянство, прыжки через турникеты в…
👍1
Порно, знакомства и казино: спорные профессии в IT
Вышел очередной выпуск подкаста Кода кода, где мы с Виктором пообсуждали некоторые вопросы этики в ИТ индустрии, и послушали несколько историй от наших гостей про проекты, которые кому-то могут показаться не очень корректными с моральной точки зрения.
Тема сложная, спорная, но любопытная.
Приятного прослушивания👍
Ссылка на канала подкаста с этим выпуском тут https://www.tg-me.com/kodakodacast/84
Вышел очередной выпуск подкаста Кода кода, где мы с Виктором пообсуждали некоторые вопросы этики в ИТ индустрии, и послушали несколько историй от наших гостей про проекты, которые кому-то могут показаться не очень корректными с моральной точки зрения.
Тема сложная, спорная, но любопытная.
Приятного прослушивания👍
Ссылка на канала подкаста с этим выпуском тут https://www.tg-me.com/kodakodacast/84
Telegram
Кода кода
Секс, знакомства и казино: спорные профессии в IT
Во втором выпуске второго сезона подкаста «Кода Кода» затронута сложная тема этики в IT индустрии. Где проходит граница между тем, чем заниматься этично, а чем нет. Насколько она далеко от границы законности?…
Во втором выпуске второго сезона подкаста «Кода Кода» затронута сложная тема этики в IT индустрии. Где проходит граница между тем, чем заниматься этично, а чем нет. Насколько она далеко от границы законности?…
Просто о сложном? Сложно о сложном!
Сейчас такое время, когда в ИТ очень много информации: книги, статьи, конференции, документация, постоянные новости про свежие инструменты и т.д. И за всем этим надо как-то успевать.
Тут и рождается популярность пятиминутных видео или коротеньких статей с идеей «просто о сложном». Не надо читать больше сложные большие книги, углубляться в то, как что работает чуть глубже поверхностного слоя. Просто читаете статью с изложением книги на 10 страничек, или видос на ютубе на 7.5 минут, где вам говорят по пунктам, что и когда надо делать. А если у вас море времени, то слушаете часовую серию подкаста на тему, и вы уже эксперт!
Плюсы
В этом действительно есть свои плюсы. Если вы в какой-то теме вообще не соображаете и даже не уверены, хотите ли соображать, то можно и правда начинать с простого. Есть шанс, что поняв самые азы, вы решите, что вам это не нужно или не интересно.
Есть также шанс расширить свой кругозор, потихонечку получая знания о разных областях, в которые вы в силу времени и сил физически не смогли бы хорошо углубиться.
А еще это способ объяснить что-то другому человеку, который не в теме, а вам лень заморачиваться с объяснениями. Просто даете хорошие, короткие, простые материалы, и человек сам разберется с основами.
Минусы
Меня очень печалит масштаб современной профанации в индустрии. Это касается как инженеров, так и менеджеров.
Инженеры становятся «фреймворк программистами», а менеджеры просто «чайка менеджерами».
Это происходит потому, что зачастую люди даже по своей основной профессии не хотят заморачиваться.
Зачем углубляться в трудные и широкие фундаментальные основы, зачем читать десятки книг, зачем думать вглубь о том, что как и почему происходит? Ведь проще посмотреть видосик на ютубе или прочитать статью «5 принципов величайших успехов» и, не умея отличить вредный совет от полезного, просто повторять.
А почему не умея отличить, спросите вы? Да потому, что для того, чтобы это сделать, надо самому иметь довольно глубокое понимание темы. А где его взять, если не совершать сложные когнитивные усилия и не разбираться глубоко в предмете?
Ты самый умный?
Я не говорю, что все инженеры и менеджеры плохие, а я молодец. Я знаю в индустрии многих высокопрофессиональных разработчиков и менеджеров. Правда низкопрофессиональных знаю не меньше. А менеджеров почему-то особенно много.
У меня хватает своих пробелов, как в инженерном плане, так и в руководящем. Мне предстоит еще много чему научиться и в теории, и на практике.
Стараюсь разбираться сам, обсуждать с коллегами по индустрии, советовать/помогать тому, кто еще не разобрался. Только развиваясь самостоятельно и помогая коллегам по индустрии, можно надеяться на то, что вокруг нас станет когда-нибудь чуточку больше профессионалов.
Именно поэтому я радуюсь отзывам «Жаль я раньше те книги по твоим советам не читал и буксовал на месте. Но теперь начал читать, разбираться, и работать стал лучше», и печалюсь, когда слышу «Ооооо, там полгода надо курс проходить? Вот мне бы что-то на 3-4 недели, за это я бы взялся (наверное)».
Итог
Там, где это не очень важно и просто надо ознакомиться, короткий путь поможет вам сэкономить силы и время.
Там, где это это ваша профессиональная деятельность, не ленитесь, думайте, изучайте, делайте, анализируйте, критически мыслите. Легким путем нельзя научиться хорошо делать сложные вещи.
Сейчас такое время, когда в ИТ очень много информации: книги, статьи, конференции, документация, постоянные новости про свежие инструменты и т.д. И за всем этим надо как-то успевать.
Тут и рождается популярность пятиминутных видео или коротеньких статей с идеей «просто о сложном». Не надо читать больше сложные большие книги, углубляться в то, как что работает чуть глубже поверхностного слоя. Просто читаете статью с изложением книги на 10 страничек, или видос на ютубе на 7.5 минут, где вам говорят по пунктам, что и когда надо делать. А если у вас море времени, то слушаете часовую серию подкаста на тему, и вы уже эксперт!
Плюсы
В этом действительно есть свои плюсы. Если вы в какой-то теме вообще не соображаете и даже не уверены, хотите ли соображать, то можно и правда начинать с простого. Есть шанс, что поняв самые азы, вы решите, что вам это не нужно или не интересно.
Есть также шанс расширить свой кругозор, потихонечку получая знания о разных областях, в которые вы в силу времени и сил физически не смогли бы хорошо углубиться.
А еще это способ объяснить что-то другому человеку, который не в теме, а вам лень заморачиваться с объяснениями. Просто даете хорошие, короткие, простые материалы, и человек сам разберется с основами.
Минусы
Меня очень печалит масштаб современной профанации в индустрии. Это касается как инженеров, так и менеджеров.
Инженеры становятся «фреймворк программистами», а менеджеры просто «чайка менеджерами».
Это происходит потому, что зачастую люди даже по своей основной профессии не хотят заморачиваться.
Зачем углубляться в трудные и широкие фундаментальные основы, зачем читать десятки книг, зачем думать вглубь о том, что как и почему происходит? Ведь проще посмотреть видосик на ютубе или прочитать статью «5 принципов величайших успехов» и, не умея отличить вредный совет от полезного, просто повторять.
А почему не умея отличить, спросите вы? Да потому, что для того, чтобы это сделать, надо самому иметь довольно глубокое понимание темы. А где его взять, если не совершать сложные когнитивные усилия и не разбираться глубоко в предмете?
Ты самый умный?
Я не говорю, что все инженеры и менеджеры плохие, а я молодец. Я знаю в индустрии многих высокопрофессиональных разработчиков и менеджеров. Правда низкопрофессиональных знаю не меньше. А менеджеров почему-то особенно много.
У меня хватает своих пробелов, как в инженерном плане, так и в руководящем. Мне предстоит еще много чему научиться и в теории, и на практике.
Стараюсь разбираться сам, обсуждать с коллегами по индустрии, советовать/помогать тому, кто еще не разобрался. Только развиваясь самостоятельно и помогая коллегам по индустрии, можно надеяться на то, что вокруг нас станет когда-нибудь чуточку больше профессионалов.
Именно поэтому я радуюсь отзывам «Жаль я раньше те книги по твоим советам не читал и буксовал на месте. Но теперь начал читать, разбираться, и работать стал лучше», и печалюсь, когда слышу «Ооооо, там полгода надо курс проходить? Вот мне бы что-то на 3-4 недели, за это я бы взялся (наверное)».
Итог
Там, где это не очень важно и просто надо ознакомиться, короткий путь поможет вам сэкономить силы и время.
Там, где это это ваша профессиональная деятельность, не ленитесь, думайте, изучайте, делайте, анализируйте, критически мыслите. Легким путем нельзя научиться хорошо делать сложные вещи.
👍1
Сначала система, потом личный контроль
Когда есть процесс, который касается нескольких людей, выполнения некоторых действий вручную, каких-то специфичных знаний, то я стараюсь организовывать вокруг этого хотя бы более-менее понятную, регламентированную систему.
Система
Казалось бы, очевидная вещь, необходимая для того, чтобы избежать ошибок человеческого фактора и лишних трат времени. Однако на практике далеко не всегда люди задумываются о том, что какой-то ряд действий можно объединить в систему. А если не задуматься о группе событий, то каждый новый случай приходится решать как уникальный: погружаться в контекст, вспоминать, что как надо делать, спрашивать у других участников, в очередной раз согласовывать и т.д.
Это как бороться постоянно с одними и теми же симптомами, но не пытаться разобраться с самой болезнью.
Всегда думал, что это настолько понятно и очевидно, что даже не хотел пост на эту тему делать. Однако ретроспективно вспомнив то, что мне доводилось видеть в жизни в целом, и работе в частности, решил всё же написать:)
На днях дочитал хорошую книгу, классику менеджмента Питера Друкера «Эффективный руководитель», первое издание которой вышло еще в 1966 году. Там автор посвятил довольно много времени важности того, чтобы руководитель понимал, где типовые случаи и надо построить систему, а где уникальные ситуации, к которым нужен индивидуальный подход.
Личный контроль
Как бы ни хотелось верить в то, что системный процесс является идеальным средством от комплекса проблем, это не совсем так.
Система дает общие, понятные, почти прямые, рельсы, по которым катятся однотипные дела. Однако она не может долго идеально существовать и быть всегда одинаково эффективной.
Обязательно какие-то части станут со временем не актуальными. Периодически нужно проверять, насколько все корректно работает и тюнить это.
А еще обязательно найдется способ хакнуть и извратить систему. Например, KPI для работников, которые они придумали как обойти.
Почему я говорю именно про личный контроль? Потому что, к сожалению, я не знаю, как прям идеально осуществлять контроль без этого. Любая система опосредованного контроля – тоже потенциально уязвимая система, где промежуточные звенья могут схалтурить, умолчать, не разобраться и т.д.
Тем не менее я не говорю, что абсолютно всё всегда надо контролировать лично. Но периодически закатывать рукава, производить проверку и тюнинг системы необходимо. Не стоит закрывать глаза и надеяться «авось всё нормально».
Пример
В качестве примера можно использовать мой пост про онбординг, который я писал некоторое время назад https://www.tg-me.com/general_it_talks/118
Итог
Постарайтесь выделить группу событий, которую можно объединить в четкую, понятную, управляемую систему.
Не почивайте на лаврах, не ленитесь, а периодически проверяйте и корректируйте эту систему.
Когда есть процесс, который касается нескольких людей, выполнения некоторых действий вручную, каких-то специфичных знаний, то я стараюсь организовывать вокруг этого хотя бы более-менее понятную, регламентированную систему.
Система
Казалось бы, очевидная вещь, необходимая для того, чтобы избежать ошибок человеческого фактора и лишних трат времени. Однако на практике далеко не всегда люди задумываются о том, что какой-то ряд действий можно объединить в систему. А если не задуматься о группе событий, то каждый новый случай приходится решать как уникальный: погружаться в контекст, вспоминать, что как надо делать, спрашивать у других участников, в очередной раз согласовывать и т.д.
Это как бороться постоянно с одними и теми же симптомами, но не пытаться разобраться с самой болезнью.
Всегда думал, что это настолько понятно и очевидно, что даже не хотел пост на эту тему делать. Однако ретроспективно вспомнив то, что мне доводилось видеть в жизни в целом, и работе в частности, решил всё же написать:)
На днях дочитал хорошую книгу, классику менеджмента Питера Друкера «Эффективный руководитель», первое издание которой вышло еще в 1966 году. Там автор посвятил довольно много времени важности того, чтобы руководитель понимал, где типовые случаи и надо построить систему, а где уникальные ситуации, к которым нужен индивидуальный подход.
Личный контроль
Как бы ни хотелось верить в то, что системный процесс является идеальным средством от комплекса проблем, это не совсем так.
Система дает общие, понятные, почти прямые, рельсы, по которым катятся однотипные дела. Однако она не может долго идеально существовать и быть всегда одинаково эффективной.
Обязательно какие-то части станут со временем не актуальными. Периодически нужно проверять, насколько все корректно работает и тюнить это.
А еще обязательно найдется способ хакнуть и извратить систему. Например, KPI для работников, которые они придумали как обойти.
Почему я говорю именно про личный контроль? Потому что, к сожалению, я не знаю, как прям идеально осуществлять контроль без этого. Любая система опосредованного контроля – тоже потенциально уязвимая система, где промежуточные звенья могут схалтурить, умолчать, не разобраться и т.д.
Тем не менее я не говорю, что абсолютно всё всегда надо контролировать лично. Но периодически закатывать рукава, производить проверку и тюнинг системы необходимо. Не стоит закрывать глаза и надеяться «авось всё нормально».
Пример
В качестве примера можно использовать мой пост про онбординг, который я писал некоторое время назад https://www.tg-me.com/general_it_talks/118
Итог
Постарайтесь выделить группу событий, которую можно объединить в четкую, понятную, управляемую систему.
Не почивайте на лаврах, не ленитесь, а периодически проверяйте и корректируйте эту систему.
Telegram
Тимлид Очевидность
Онбординг
С проблемой несистемного онбординга сотрудников сталкиваются многие. Причем неважно, насколько часто к вам устраиваются новые люди.
Если поток новых людей большой, нужно проводить много рутинных однотипных действий и легко в них запутаться, забыть…
С проблемой несистемного онбординга сотрудников сталкиваются многие. Причем неважно, насколько часто к вам устраиваются новые люди.
Если поток новых людей большой, нужно проводить много рутинных однотипных действий и легко в них запутаться, забыть…
Сегодня вышел очередной выпуск подкаста Кода кода, где я с удовольствием выполняю роль соведущего☺️
Этот выпуск для меня особенный. Возможно, вы помните по этому моему посту https://www.tg-me.com/general_it_talks/142 как я искренне люблю и ценю доклад Вадима Макишвили 36. Судя по комментариям к этому посту, таких почитателей его творчества среди нас не мало.
В этом выпуске Вадим был одним из гостей и раскрылся для меня с очень неожиданной стороны по части своего стороннего проекта. За что уровень моего уважения к нему еще вырос.
Ну а если вы не знали (мне кажется явно это в докладах не проговаривалось, или я прослушал), почему доклады 42 и 55 имеют именно такие названия, то в нашем подкасте вы сможете найти ответ на этот вопрос😎
Не хочется, чтобы вы подумали, что только Вадимом единым будет интересен выпуск. Еще одна гостья, Лидия Меншенина, тоже рассказала много не менее интересного и полезного по теме.
А тема выпуска - профессиональное выгорание и кризис среднего возраста. Берегите свое психическое здоровье, радуйтесь жизни и слушайте Кода кода.
Ссылка на телеграм канал подкаста и конкретный выпуск https://www.tg-me.com/kodakodacast/86
Этот выпуск для меня особенный. Возможно, вы помните по этому моему посту https://www.tg-me.com/general_it_talks/142 как я искренне люблю и ценю доклад Вадима Макишвили 36. Судя по комментариям к этому посту, таких почитателей его творчества среди нас не мало.
В этом выпуске Вадим был одним из гостей и раскрылся для меня с очень неожиданной стороны по части своего стороннего проекта. За что уровень моего уважения к нему еще вырос.
Ну а если вы не знали (мне кажется явно это в докладах не проговаривалось, или я прослушал), почему доклады 42 и 55 имеют именно такие названия, то в нашем подкасте вы сможете найти ответ на этот вопрос😎
Не хочется, чтобы вы подумали, что только Вадимом единым будет интересен выпуск. Еще одна гостья, Лидия Меншенина, тоже рассказала много не менее интересного и полезного по теме.
А тема выпуска - профессиональное выгорание и кризис среднего возраста. Берегите свое психическое здоровье, радуйтесь жизни и слушайте Кода кода.
Ссылка на телеграм канал подкаста и конкретный выпуск https://www.tg-me.com/kodakodacast/86
👍2
Да там легко!
Случалось ли с вами такое, что вам что-то прям совсем не понятно, вы обращались за помощью, а вам очень быстро показывали и объясняли, при этом еще и говоря «да там всё просто»? А вы потом чувствовали себя каким-то ущербным и тупым, потому что там же вроде просто было, а вы прям совсем не врубились.
Что люди чувствуют
Недавно имел несколько разговоров с разными людьми по этому поводу, все они рассказывали примерно одну и ту же историю.
Историю про то, как они в минуты дискомфорта (а незнание чего-то и обращение за помощью – это дискомфорт) слышали от товарищей, как там всё элементарно, а потом приунывали из-за этого.
Когда тебе тяжело, а кто-то это сходу обесценивает (пусть и не специально) – это не очень приятная история.
А если ты джуниор, начинающий и не очень уверенный в себе специалист, которому более опытный коллега с ходу говорит, что всё легче легкого, то тут запросто можно почувствовать себя дурачком.
Может показаться, что это чисто проблемы джунов. Я, будучи начинающим в профессии специалистом, тоже от этого страдал. Сейчас я как-то уже на опыте принял, что кое-что я знаю, а еще море всего я не знаю, и это нормально. И другие тоже кучу всего не знают, и это нормально. Не очень нормально, скорее, кичиться тем, что ты знаешь якобы всё, и при этом особо ничем не интересоваться и не развиваться.
Пообщавшись с людьми разных компетенций побольше, я сделал для себя вывод, что это проблема не только новичков. Много людей среднего и даже высокого уровня профессионализма могут обладать неуверенностью в себе, чувством некой незащищенности и тоже могут унывать или даже злиться от такой, казалось бы, безобидной, обесценивающей фразы.
Что делать
На мой взгляд, тут можно как минимум немного поменять подход, не говоря ультимативно «да тут всё легко», а сказать за себя: «Я это понимаю, я в этом разбираюсь, сейчас тебе помогу». И человек не будет страдать, что он якобы не разбирается в простых вещах, а скорее порадуется, что нашел того, кто в теме и может оказать помощь.
Я уверен, что найдутся те, кто скажет: «Да чего с ними цацкаться? Пусть скажут спасибо, что хоть так объяснили», или «Ну конечно и неженки, вот при Сталине такого не было». Это их право иметь свою точку зрения. Я тут никому ничего не навязываю, просто подсветил проблему, которую многократно наблюдал в жизни. А дальше уже каждый сам решает, как он с ней работает, и как он с кем общается, и как потом с ним общаются в ответ.
Итог
Помогая кому-то, откажитесь от фразы «там всё легко» и посмотрите на результат.
Возможно, ваш собеседник станет вас ценить чуточку больше, а уровень стресса у него станет чуточку меньше. А если ему приятно, а вам не сложно (если вам не сложно), то почему бы и не попытаться?🙂
Случалось ли с вами такое, что вам что-то прям совсем не понятно, вы обращались за помощью, а вам очень быстро показывали и объясняли, при этом еще и говоря «да там всё просто»? А вы потом чувствовали себя каким-то ущербным и тупым, потому что там же вроде просто было, а вы прям совсем не врубились.
Что люди чувствуют
Недавно имел несколько разговоров с разными людьми по этому поводу, все они рассказывали примерно одну и ту же историю.
Историю про то, как они в минуты дискомфорта (а незнание чего-то и обращение за помощью – это дискомфорт) слышали от товарищей, как там всё элементарно, а потом приунывали из-за этого.
Когда тебе тяжело, а кто-то это сходу обесценивает (пусть и не специально) – это не очень приятная история.
А если ты джуниор, начинающий и не очень уверенный в себе специалист, которому более опытный коллега с ходу говорит, что всё легче легкого, то тут запросто можно почувствовать себя дурачком.
Может показаться, что это чисто проблемы джунов. Я, будучи начинающим в профессии специалистом, тоже от этого страдал. Сейчас я как-то уже на опыте принял, что кое-что я знаю, а еще море всего я не знаю, и это нормально. И другие тоже кучу всего не знают, и это нормально. Не очень нормально, скорее, кичиться тем, что ты знаешь якобы всё, и при этом особо ничем не интересоваться и не развиваться.
Пообщавшись с людьми разных компетенций побольше, я сделал для себя вывод, что это проблема не только новичков. Много людей среднего и даже высокого уровня профессионализма могут обладать неуверенностью в себе, чувством некой незащищенности и тоже могут унывать или даже злиться от такой, казалось бы, безобидной, обесценивающей фразы.
Что делать
На мой взгляд, тут можно как минимум немного поменять подход, не говоря ультимативно «да тут всё легко», а сказать за себя: «Я это понимаю, я в этом разбираюсь, сейчас тебе помогу». И человек не будет страдать, что он якобы не разбирается в простых вещах, а скорее порадуется, что нашел того, кто в теме и может оказать помощь.
Я уверен, что найдутся те, кто скажет: «Да чего с ними цацкаться? Пусть скажут спасибо, что хоть так объяснили», или «Ну конечно и неженки, вот при Сталине такого не было». Это их право иметь свою точку зрения. Я тут никому ничего не навязываю, просто подсветил проблему, которую многократно наблюдал в жизни. А дальше уже каждый сам решает, как он с ней работает, и как он с кем общается, и как потом с ним общаются в ответ.
Итог
Помогая кому-то, откажитесь от фразы «там всё легко» и посмотрите на результат.
Возможно, ваш собеседник станет вас ценить чуточку больше, а уровень стресса у него станет чуточку меньше. А если ему приятно, а вам не сложно (если вам не сложно), то почему бы и не попытаться?🙂
Никто не вечен на проекте
Сегодня хочется поговорить про то, как важно жить с мыслью, что на проекте никто не остается навсегда.
Какая бы у вас ни была статистика долгосрочного сотрудничества с работниками и заказчиками, рано или поздно это изменится. И надо быть к этому готовым.
Басфактор
Есть такое понятие как bus factor, фактор автобуса. Детали тут https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0
а если коротко, то это число, показывающее, сколько людей из вашей команды должен сбить автобус, чтобы работа над проектом встала.
Этим термином пользуются, когда пытаются подсветить проблему существования «незаменимых» сотрудников в компании. Т.е. если есть один сотрудник, который умеет делать что-то уникальное и это является неотъемлемой частью производства, то у вас басфактор равен единице. Как только этот сотрудник заболеет, уйдет в отпуск, уволится, или еще чего похуже, то всё ваше производство встанет, дела не будут делаться, вы в панике будете пытаться его работу на кого-то переложить, но никто не умеет. Вы попытаетесь нанять того, кто умеет, а их тоже поди еще поищи. Трудно, короче. Не надо так.
Альтернативный вариант кадровой непредсказуемости
Представим ситуацию, что вы на проекте как сыр в масле катаетесь, команда классная, начальник крутой, и вы планируете здесь работать долго и счастливо. Однако – бац, вашу компанию покупает какой-нибудь банк, выставляет вам нового начальника, начинает в короткие сроки накачивать команду людьми, которых в спешке запылесосил десятками. В один момент вы теряете и хорошего начальника, и уютную команду, а ваше счастье мигом трансформируется в уныние.
Ну или теряются не работники и их начальники, а какие-нибудь наработанные контакты на стороне крупного заказчика, а с новыми не факт, что удастся договориться. Клиенты уходят, деньги – тоже, компания и её работники страдают.
Memento mori
Это я все к чему? К тому что поговорки типа «надейся на лучшее, а готовься к худшему», или даже «помни о смерти» учат нас тому, что нужно быть готовым к неотвратимо наступающим изменениям. И зачастую эти изменения могут быть не в лучшую сторону. Можно пытаться их оттянуть, сгладить, распределить, но тем не менее они случатся. Не стоит питать иллюзий.
Итог
Так что, руководитель, помни: ни один сотрудник у тебя на проекте не вечен, и организуй работу таким образом, чтобы это не стреляло тебе в ногу.
А работникам стоит помнить, что если у вас сейчас легкая ситуация и вы кайфово поживаете, то всё может измениться в худшую для вас сторону в любой момент. Какой-то запасной план иметь необходимо.
Сегодня хочется поговорить про то, как важно жить с мыслью, что на проекте никто не остается навсегда.
Какая бы у вас ни была статистика долгосрочного сотрудничества с работниками и заказчиками, рано или поздно это изменится. И надо быть к этому готовым.
Басфактор
Есть такое понятие как bus factor, фактор автобуса. Детали тут https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0
а если коротко, то это число, показывающее, сколько людей из вашей команды должен сбить автобус, чтобы работа над проектом встала.
Этим термином пользуются, когда пытаются подсветить проблему существования «незаменимых» сотрудников в компании. Т.е. если есть один сотрудник, который умеет делать что-то уникальное и это является неотъемлемой частью производства, то у вас басфактор равен единице. Как только этот сотрудник заболеет, уйдет в отпуск, уволится, или еще чего похуже, то всё ваше производство встанет, дела не будут делаться, вы в панике будете пытаться его работу на кого-то переложить, но никто не умеет. Вы попытаетесь нанять того, кто умеет, а их тоже поди еще поищи. Трудно, короче. Не надо так.
Альтернативный вариант кадровой непредсказуемости
Представим ситуацию, что вы на проекте как сыр в масле катаетесь, команда классная, начальник крутой, и вы планируете здесь работать долго и счастливо. Однако – бац, вашу компанию покупает какой-нибудь банк, выставляет вам нового начальника, начинает в короткие сроки накачивать команду людьми, которых в спешке запылесосил десятками. В один момент вы теряете и хорошего начальника, и уютную команду, а ваше счастье мигом трансформируется в уныние.
Ну или теряются не работники и их начальники, а какие-нибудь наработанные контакты на стороне крупного заказчика, а с новыми не факт, что удастся договориться. Клиенты уходят, деньги – тоже, компания и её работники страдают.
Memento mori
Это я все к чему? К тому что поговорки типа «надейся на лучшее, а готовься к худшему», или даже «помни о смерти» учат нас тому, что нужно быть готовым к неотвратимо наступающим изменениям. И зачастую эти изменения могут быть не в лучшую сторону. Можно пытаться их оттянуть, сгладить, распределить, но тем не менее они случатся. Не стоит питать иллюзий.
Итог
Так что, руководитель, помни: ни один сотрудник у тебя на проекте не вечен, и организуй работу таким образом, чтобы это не стреляло тебе в ногу.
А работникам стоит помнить, что если у вас сейчас легкая ситуация и вы кайфово поживаете, то всё может измениться в худшую для вас сторону в любой момент. Какой-то запасной план иметь необходимо.
👍2
Где нанимать подходящих ИТ-специалистов в свою команду
Зарплата специалиста в регионах это 0.8 от московской зарплаты в IT-индустрии. Из-за этого многие думают, что региональные IT-специалисты хуже по некоторым техническим скиллам.
На самом деле, если посмотреть на опыт агентства Benchmark, которое регулярно нанимает специалистов и выводит целые IT-команды, то самый большой провал бывает в soft навыках, и им действительно нужно уделять внимание на собеседовании с региональным специалистом. При этом по hard навыкам они ничуть не уступают. Если вы готовы работать с сотрудниками удаленно, то региональные кандидаты значительно расширят вашу воронку и ускорят найм.
Как искать и отбирать кандидатов из регионов — в статье: https://media.benchmark.ru.com/dev_search_region
P.S. От лица автора канала Тимлид Очевидность я хотел бы тоже выразить своё личное отношение к этой ситуации.
На мой взгляд с пандемией действительно очень выросли зарплаты ИТ-специалистов.
Кто-то научился работать на удаленке и больше не хочет находиться в региональном офисе, а хочет работать из дома за столичную зарплату. Многие скилловые ребята не хотят работать за Российскую столичную зарплату, а хотят х1.5-2 зарабатывать так же из дома на международном рынке. Кто-то из крупных компаний смог хорошо заработать, и поставил перед собой большие планы по разработке, поэтому собирает людей с рынка компетентных людей с удвоенной силой, попутно пытаясь составить конкуренцию валютным зарплатам.
Как ИТ специалист я безусловно рад такому рынку сейчас. Как тот, кто на на консалтинге видит всякое в найме, в том числе и региональном, я искренне сочувствую малому и среднему бизнесу, которому нужны ИТшники. Особенно в регионах. Для многих это превращается в едва посильную ношу.
Также хочу отметить, что, на мой личный субъективный взгляд ,вот этот коэффициент 0.8 на регион все больше пропадает.
Помню как лет 5 назад было нормальной практикой говорить сотруднику прямо «ты на удаленке, значит тебе на 20-30%» меньше платим. Хотя почему меньше? Я же ведь вам на аренде офиса и оборудовании экономлю. А ведь аренда хорошего офиса с разными плюшками может запросто быть тысяч 50 на человека.
Так вот сейчас, если кто-то так скажет, то человек может легко найти того работодателя, который не хочет заниматься крохоборством этих 20 процентов. Многие уже и крупные и не очень работодатели, которые научились действительно нормально работать на удаленке, не занимаются уже такими вещами. Опять же, это мое личное субъективное наблюдение.
Насчет переживаний про софт скиллы в регионах - я бы советовал обратить внимание на организацию онбординга, менеджмент людей и проектов. Организационная работа на этом уровне поможет меньше завязываться на скиллах конкретного человека, и выстраивать систему, которая нивелирует подобные минусы (если они вообще существуют).
Зарплата специалиста в регионах это 0.8 от московской зарплаты в IT-индустрии. Из-за этого многие думают, что региональные IT-специалисты хуже по некоторым техническим скиллам.
На самом деле, если посмотреть на опыт агентства Benchmark, которое регулярно нанимает специалистов и выводит целые IT-команды, то самый большой провал бывает в soft навыках, и им действительно нужно уделять внимание на собеседовании с региональным специалистом. При этом по hard навыкам они ничуть не уступают. Если вы готовы работать с сотрудниками удаленно, то региональные кандидаты значительно расширят вашу воронку и ускорят найм.
Как искать и отбирать кандидатов из регионов — в статье: https://media.benchmark.ru.com/dev_search_region
P.S. От лица автора канала Тимлид Очевидность я хотел бы тоже выразить своё личное отношение к этой ситуации.
На мой взгляд с пандемией действительно очень выросли зарплаты ИТ-специалистов.
Кто-то научился работать на удаленке и больше не хочет находиться в региональном офисе, а хочет работать из дома за столичную зарплату. Многие скилловые ребята не хотят работать за Российскую столичную зарплату, а хотят х1.5-2 зарабатывать так же из дома на международном рынке. Кто-то из крупных компаний смог хорошо заработать, и поставил перед собой большие планы по разработке, поэтому собирает людей с рынка компетентных людей с удвоенной силой, попутно пытаясь составить конкуренцию валютным зарплатам.
Как ИТ специалист я безусловно рад такому рынку сейчас. Как тот, кто на на консалтинге видит всякое в найме, в том числе и региональном, я искренне сочувствую малому и среднему бизнесу, которому нужны ИТшники. Особенно в регионах. Для многих это превращается в едва посильную ношу.
Также хочу отметить, что, на мой личный субъективный взгляд ,вот этот коэффициент 0.8 на регион все больше пропадает.
Помню как лет 5 назад было нормальной практикой говорить сотруднику прямо «ты на удаленке, значит тебе на 20-30%» меньше платим. Хотя почему меньше? Я же ведь вам на аренде офиса и оборудовании экономлю. А ведь аренда хорошего офиса с разными плюшками может запросто быть тысяч 50 на человека.
Так вот сейчас, если кто-то так скажет, то человек может легко найти того работодателя, который не хочет заниматься крохоборством этих 20 процентов. Многие уже и крупные и не очень работодатели, которые научились действительно нормально работать на удаленке, не занимаются уже такими вещами. Опять же, это мое личное субъективное наблюдение.
Насчет переживаний про софт скиллы в регионах - я бы советовал обратить внимание на организацию онбординга, менеджмент людей и проектов. Организационная работа на этом уровне поможет меньше завязываться на скиллах конкретного человека, и выстраивать систему, которая нивелирует подобные минусы (если они вообще существуют).
У нас в подкасте Кода кода вышел новый выпуск.
В этот раз обсуждали специфику работы с западными заказчиками. Поговорили об особенностях культурного взаимодействия, работе в разных часовых поясах, требованиях к уровню владения английским языком.
Немного посравнивали стартапы в России и США.
Ссылка на пост с выпуском https://www.tg-me.com/kodakodacast/91
В этот раз обсуждали специфику работы с западными заказчиками. Поговорили об особенностях культурного взаимодействия, работе в разных часовых поясах, требованиях к уровню владения английским языком.
Немного посравнивали стартапы в России и США.
Ссылка на пост с выпуском https://www.tg-me.com/kodakodacast/91
Telegram
Кода кода
Встречаются как-то американец и русский ИЛИ Как работать на стартапы из Долины
В четвёртом выпуске подкаста «Кода Кода» поговорим о различиях и сходствах разработки в России и в США. И о тех людях и компаниях, которым удается взаимодействовать через океан.…
В четвёртом выпуске подкаста «Кода Кода» поговорим о различиях и сходствах разработки в России и в США. И о тех людях и компаниях, которым удается взаимодействовать через океан.…
Однажды тимлид – навсегда тимлид
Неоднократно слышал, что бывших тимлидов не бывает. И я почти согласен с этим утверждением. Согласен с этим на своем примере и на примере других своих товарищей по профессии.
Откаты
Я встречал истории, когда человек быстро откатывается из тимлидов, потому что это не для него. Может, поставили его насильно на эту должность, может, не сошлись ожидания и реальность, может, просто решил попробовать, чтобы посмотреть пойдет или нет.
Тут нет ничего стыдного и позорного, работник не становится плохим. По сути это делает человека даже более хорошим и ценным сотрудником: он получил полезный опыт, который далеко не у каждого есть, получше узнал себя, побольше определился, чем именно нравится и не нравится заниматься. Главное, не чмырить и не унижать себя при этом, а наоборот, порадоваться, что ты попробовал.
Но так, чтобы человек годами был тимлидом и теперь говорит: «Нет, всё, хочу назад рядовым разработчиком», прям уходит и надолго остается линейным работником, – таких примеров не слышал. Если вы слышали, поделитесь в комментариях.
Зато краткосрочных таких историй много. Был тимлидом, очень устал, перегорел, откатился в спокойное однозадачное двигание задачек в жире. Поработал, морально отдохнул и опять как-то само собой получается, что тут на что-то хочется повлиять, здесь кому-то помочь, вон там явно же кто-то не может договориться, надо разобраться. И так человек снова в колею эту входит. Потому что характер такой, потому что мотивация такая: повлиять на что-то более глобальное, на что нельзя повлиять из рядовой позиции.
Сам чего?
У меня всегда как-то само собой складывалось, что я приходил рядовым сотрудником, а потом двигался в тимлиды. Затем шел в другую компанию, и там происходило то же самое.
Да, мне иногда приходится трудновато: море переключений контекста, созвонов, переписок, согласований, контроля, документации, квадратиков и стрелочек. И я думаю: «вот бы просто сидеть, код писать постоянно, а не вот это вот всё». И я могу себе позволить иногда устроить такие разгрузочные дни. И в качестве смены деятельности это клево, люблю, когда такое случается.
Но для себя я на данный момент жизни решил, что прям 20 дней в месяц просто тягать задачи из жиры и потихоньку их прогать, мне уже не очень интересно. Мне хочется, чтобы результат моей работы был более масштабен. Не из честолюбия, а просто хочется, чтобы вокруг было больше приятного и хорошего. Больше понятных задач в проектах, больше нужных задач, больше понимания с заказчиками, больше культуры и порядка в разработке, больше нормальных, человеческих, работающих процессов у меня и моих коллег.
И если я чувствую, что я могу принести там везде пользу, то почему бы этого не сделать?
Итог
Мое личное мнение, что если ты такой человек, что тимлидить тебе по душе, то ты можешь устать, ты можешь даже откатиться назад, но, скорее всего, так или иначе ты встанешь на этот путь снова. Иными словами, тимлид – это состояние души, а от себя не убежишь:)
Бонусный контент
Эту тему мы выбрали вместе с Настей Абрашитовой, менеджером проектов из Яндекса. Знаю Настю уже полтора года и очень уважаю её профессионализм. Её пост вы можете прочитать тут https://www.tg-me.com/tealmead/41
Неоднократно слышал, что бывших тимлидов не бывает. И я почти согласен с этим утверждением. Согласен с этим на своем примере и на примере других своих товарищей по профессии.
Откаты
Я встречал истории, когда человек быстро откатывается из тимлидов, потому что это не для него. Может, поставили его насильно на эту должность, может, не сошлись ожидания и реальность, может, просто решил попробовать, чтобы посмотреть пойдет или нет.
Тут нет ничего стыдного и позорного, работник не становится плохим. По сути это делает человека даже более хорошим и ценным сотрудником: он получил полезный опыт, который далеко не у каждого есть, получше узнал себя, побольше определился, чем именно нравится и не нравится заниматься. Главное, не чмырить и не унижать себя при этом, а наоборот, порадоваться, что ты попробовал.
Но так, чтобы человек годами был тимлидом и теперь говорит: «Нет, всё, хочу назад рядовым разработчиком», прям уходит и надолго остается линейным работником, – таких примеров не слышал. Если вы слышали, поделитесь в комментариях.
Зато краткосрочных таких историй много. Был тимлидом, очень устал, перегорел, откатился в спокойное однозадачное двигание задачек в жире. Поработал, морально отдохнул и опять как-то само собой получается, что тут на что-то хочется повлиять, здесь кому-то помочь, вон там явно же кто-то не может договориться, надо разобраться. И так человек снова в колею эту входит. Потому что характер такой, потому что мотивация такая: повлиять на что-то более глобальное, на что нельзя повлиять из рядовой позиции.
Сам чего?
У меня всегда как-то само собой складывалось, что я приходил рядовым сотрудником, а потом двигался в тимлиды. Затем шел в другую компанию, и там происходило то же самое.
Да, мне иногда приходится трудновато: море переключений контекста, созвонов, переписок, согласований, контроля, документации, квадратиков и стрелочек. И я думаю: «вот бы просто сидеть, код писать постоянно, а не вот это вот всё». И я могу себе позволить иногда устроить такие разгрузочные дни. И в качестве смены деятельности это клево, люблю, когда такое случается.
Но для себя я на данный момент жизни решил, что прям 20 дней в месяц просто тягать задачи из жиры и потихоньку их прогать, мне уже не очень интересно. Мне хочется, чтобы результат моей работы был более масштабен. Не из честолюбия, а просто хочется, чтобы вокруг было больше приятного и хорошего. Больше понятных задач в проектах, больше нужных задач, больше понимания с заказчиками, больше культуры и порядка в разработке, больше нормальных, человеческих, работающих процессов у меня и моих коллег.
И если я чувствую, что я могу принести там везде пользу, то почему бы этого не сделать?
Итог
Мое личное мнение, что если ты такой человек, что тимлидить тебе по душе, то ты можешь устать, ты можешь даже откатиться назад, но, скорее всего, так или иначе ты встанешь на этот путь снова. Иными словами, тимлид – это состояние души, а от себя не убежишь:)
Бонусный контент
Эту тему мы выбрали вместе с Настей Абрашитовой, менеджером проектов из Яндекса. Знаю Настю уже полтора года и очень уважаю её профессионализм. Её пост вы можете прочитать тут https://www.tg-me.com/tealmead/41
В последнее время меня со всех сторон окружает тема разрешения конфликтов и обратной связи.
Причем рабочие конфликты порой меркнут в сравнении с бытовыми. Ну и действительно, одно дело какой-то наемный менеджер не дождался вовремя задачу и разволновался, а другое дело, когда ты человеку затопил его личную квартиру, и он в бешенстве.
Где-то по этой теме мне приходится действовать на практике, а где-то можно и потеоретизировать.
Сегодня вышла статья https://skillsetter.io/blog/feedback-problems где я получил ряд проблемных кейсов, проанализировал их и предложил несколько вариантов их решения.
Ссылка на телеграм канал https://www.tg-me.com/skillsetter/497
Причем рабочие конфликты порой меркнут в сравнении с бытовыми. Ну и действительно, одно дело какой-то наемный менеджер не дождался вовремя задачу и разволновался, а другое дело, когда ты человеку затопил его личную квартиру, и он в бешенстве.
Где-то по этой теме мне приходится действовать на практике, а где-то можно и потеоретизировать.
Сегодня вышла статья https://skillsetter.io/blog/feedback-problems где я получил ряд проблемных кейсов, проанализировал их и предложил несколько вариантов их решения.
Ссылка на телеграм канал https://www.tg-me.com/skillsetter/497
skillsetter.io
5 ошибок обратной связи: примеры от опытного менеджера
Как правильно давать обратную связь подчиненным и просить фидбек у руководства
Что вам от меня надо?
Сегодня хочется поговорить про обсуждения ожиданий от кандидата при найме.
На мой взгляд, актуальнее всего это будет для позиций менеджеров и тимлидов, чем для разработчиков (у которых всё более четко и понятно).
Суть проблемы
Человек устраивается на работу тимлидом. Проходит собеседование, отвечает на все нужные вопросы, выходит на работу и начинает свою бурную деятельность. Тюнит процессы разработки в команде: CI/CD настроил, гитфлоу внедрил, научил команду как кодревью делать, и т.д.
А через месяц его вызывают к руководству на ковер и говорят, что он не справляется. Команда стала за этот месяц релизить фичи медленнее. Кто чем занят на работе – непонятно.
Почему до сих пор за месяц не начали работать по спринтам? Где эти все стендапы, груминги, демо, ретроспективы? Сколько 1-1 провел? Ах, нисколько?! А ты уже продумал, чем на корпоративе команду развлекать?
Чем ты там вообще занимался? Зачем ты эти гитфлоу свои внедрял? Кто тебя просил? Мы думали, ты командой руководить пришел, а не свои эти задротства программистские ковырять!
Тимлид думал, что делает хорошее и полезное дело, а в итоге оказалось, что руководство хотело совсем не этого.
Что делать?
Надо было сразу оговаривать как ожидания от этой позиции, так и критерии успешности их выполнения. А по итогу разговора лучше бы зафиксировать письменно, чтобы не было недомолвок из серии «Ну мы думали, ты понимаешь! Это же очевидно! Это подразумевалось!»
В идеале это делать не в начале своей работы в компании, а еще на этапе собеседования, чтобы точно сматчить свои планы на работу с планами компании. И понять сразу, насколько вы друг другу подходите, чтобы не было потом неприятных сюрпризов.
Да, вы можете сказать, что это долго, что никто не будет так долго с кандидатом обсуждать и разглагольствовать. На мой взгляд, это не так. Хорошего тимлида сейчас попробуй найди, а цена неудачи и перенайма высока. Лучше я потрачу лишние час-два на эти разговоры, чем потом все будут страдать, терять время, деньги и душевные силы.
А если вам на собесе говорят, что некогда про это разговаривать, то задумайтесь, как вам там дальше с ними будет работаться, если у них на этапе найма (когда вы им ничем не обязаны) уже нет времени на то, что важно для вас и для бизнеса.
Итог
Обязательно проговаривайте как можно раньше и ваши ожидания от работы, и ожидания компании от вас. По возможности фиксируйте письменно.
Сегодня хочется поговорить про обсуждения ожиданий от кандидата при найме.
На мой взгляд, актуальнее всего это будет для позиций менеджеров и тимлидов, чем для разработчиков (у которых всё более четко и понятно).
Суть проблемы
Человек устраивается на работу тимлидом. Проходит собеседование, отвечает на все нужные вопросы, выходит на работу и начинает свою бурную деятельность. Тюнит процессы разработки в команде: CI/CD настроил, гитфлоу внедрил, научил команду как кодревью делать, и т.д.
А через месяц его вызывают к руководству на ковер и говорят, что он не справляется. Команда стала за этот месяц релизить фичи медленнее. Кто чем занят на работе – непонятно.
Почему до сих пор за месяц не начали работать по спринтам? Где эти все стендапы, груминги, демо, ретроспективы? Сколько 1-1 провел? Ах, нисколько?! А ты уже продумал, чем на корпоративе команду развлекать?
Чем ты там вообще занимался? Зачем ты эти гитфлоу свои внедрял? Кто тебя просил? Мы думали, ты командой руководить пришел, а не свои эти задротства программистские ковырять!
Тимлид думал, что делает хорошее и полезное дело, а в итоге оказалось, что руководство хотело совсем не этого.
Что делать?
Надо было сразу оговаривать как ожидания от этой позиции, так и критерии успешности их выполнения. А по итогу разговора лучше бы зафиксировать письменно, чтобы не было недомолвок из серии «Ну мы думали, ты понимаешь! Это же очевидно! Это подразумевалось!»
В идеале это делать не в начале своей работы в компании, а еще на этапе собеседования, чтобы точно сматчить свои планы на работу с планами компании. И понять сразу, насколько вы друг другу подходите, чтобы не было потом неприятных сюрпризов.
Да, вы можете сказать, что это долго, что никто не будет так долго с кандидатом обсуждать и разглагольствовать. На мой взгляд, это не так. Хорошего тимлида сейчас попробуй найди, а цена неудачи и перенайма высока. Лучше я потрачу лишние час-два на эти разговоры, чем потом все будут страдать, терять время, деньги и душевные силы.
А если вам на собесе говорят, что некогда про это разговаривать, то задумайтесь, как вам там дальше с ними будет работаться, если у них на этапе найма (когда вы им ничем не обязаны) уже нет времени на то, что важно для вас и для бизнеса.
Итог
Обязательно проговаривайте как можно раньше и ваши ожидания от работы, и ожидания компании от вас. По возможности фиксируйте письменно.