Улиточка – сотрудник месяца
Наверное, каждый из нас сталкивался с ситуацией, когда прибегает менеджер/заказчик и в суете кричит, что срочно что-то надо сделать. Мы тут же подрываемся, быстро делаем, а потом через час этот же менеджер опять приходит и говорит, что концепция поменялась и надо переделать. Мы переделываем. А закончиться всё это может тем, что придется всё вернуть в исходное состояние.
Мемы по этому поводу
Мой любимый - https://pikabu.ru/story/tikho_tikho_polzi_ulitka_po_sklonu_fudzi_6817642
И еще мудрый давний выпуск «Фитиля» - https://www.youtube.com/watch?v=eYBwY6zKSNk
Что делать?
Не буду рассматривать перевоспитание таких менеджеров, которые сначала другим подкидывают работу, а потом только думать начинают. Это тема для отдельной беседы, возможно, научно-фантастической.
Хотелось бы понять, что делать человеку, который работает в роли исполнителя?
Если вы посмотрели выпуск «Фитиля», то там всё, в общем-то, и показано🙂
- Выявляете ненадежных людей, кто грешит подобным поведением.
- Не реагируете сразу и не несетесь сломя голову выполнять поручение.
- По возможности разбираетесь в ситуации и уточняете, а точно ли так надо, именно это надо, всё ли со всеми согласовано, когда именно дедлайн, что будет, если прям вот через 7.5 секунд не успеем сделать эту «срочнейшую» задачу и т. д.
- Если были многократные рецидивы, когда человек уверял, что да, точно надо, точно срочно, а потом оказывалось, что и не срочно, и не надо, и вообще концепция изменилась, то дайте себе и заказчику немного времени на то, чтобы еще раз подумать. Не торопитесь, ведь двойную работу потом делать
вам, а не ему.
Что делать, если вы такой человек?
Вряд ли вы такой человек, потому что у вас НЕТ ВРЕМЕНИ ЧИТАТЬ ЭТОТ КАНАЛ, У ВАС ЕСТЬ СРОЧНАЯ РАБОТА!!!
Но если вдруг это всё же вы, то постарайтесь разобраться, почему так происходит.
Обычно у таких людей аргументы на уровне «это просто сфера работы такая» или «это не от меня зависит».
Аргумент «это не от меня зависит» отдает нежеланием попытаться добиться какого-то порядка от предыдущего звена, передающего работу. Это такое перекладывание ответственности, типа «я делаю плохо, но я не виноват, это другой дяденька, или тетенька плохие». Думаю, вы сами уже поняли, что звучит это оправдание довольно сомнительно.
Аргумент «просто сфера работы такая» - еще хуже выглядит. Это значит не то, что кто-то там еще другой косячит, а вы просто сами не можете свою работу организовать нормально, поэтому и ваш труд погряз в бесполезной суете, и других еще напрягаете.
Как ни крути, все варианты ведут к тому, что можно попытаться организовать свою работу и работу окружающих каким-то более-менее нормальным образом.
Многие этого не делают, потому что это сложно. Надо думать, менять что-то, разбираться, разговаривать, выяснять, договариваться, привыкать и т. д. Но мне хочется верить, что в конечном счете те, кто не в состоянии думать, трудиться, меняться, уступят свои места более вдумчивым и ответственным работникам.
Итог
Знайте ненадежных заказчиков, не ведитесь на их суету.
Думайте о своей работе, организуйте её нормально, цените труд и время других людей.
Наверное, каждый из нас сталкивался с ситуацией, когда прибегает менеджер/заказчик и в суете кричит, что срочно что-то надо сделать. Мы тут же подрываемся, быстро делаем, а потом через час этот же менеджер опять приходит и говорит, что концепция поменялась и надо переделать. Мы переделываем. А закончиться всё это может тем, что придется всё вернуть в исходное состояние.
Мемы по этому поводу
Мой любимый - https://pikabu.ru/story/tikho_tikho_polzi_ulitka_po_sklonu_fudzi_6817642
И еще мудрый давний выпуск «Фитиля» - https://www.youtube.com/watch?v=eYBwY6zKSNk
Что делать?
Не буду рассматривать перевоспитание таких менеджеров, которые сначала другим подкидывают работу, а потом только думать начинают. Это тема для отдельной беседы, возможно, научно-фантастической.
Хотелось бы понять, что делать человеку, который работает в роли исполнителя?
Если вы посмотрели выпуск «Фитиля», то там всё, в общем-то, и показано🙂
- Выявляете ненадежных людей, кто грешит подобным поведением.
- Не реагируете сразу и не несетесь сломя голову выполнять поручение.
- По возможности разбираетесь в ситуации и уточняете, а точно ли так надо, именно это надо, всё ли со всеми согласовано, когда именно дедлайн, что будет, если прям вот через 7.5 секунд не успеем сделать эту «срочнейшую» задачу и т. д.
- Если были многократные рецидивы, когда человек уверял, что да, точно надо, точно срочно, а потом оказывалось, что и не срочно, и не надо, и вообще концепция изменилась, то дайте себе и заказчику немного времени на то, чтобы еще раз подумать. Не торопитесь, ведь двойную работу потом делать
вам, а не ему.
Что делать, если вы такой человек?
Вряд ли вы такой человек, потому что у вас НЕТ ВРЕМЕНИ ЧИТАТЬ ЭТОТ КАНАЛ, У ВАС ЕСТЬ СРОЧНАЯ РАБОТА!!!
Но если вдруг это всё же вы, то постарайтесь разобраться, почему так происходит.
Обычно у таких людей аргументы на уровне «это просто сфера работы такая» или «это не от меня зависит».
Аргумент «это не от меня зависит» отдает нежеланием попытаться добиться какого-то порядка от предыдущего звена, передающего работу. Это такое перекладывание ответственности, типа «я делаю плохо, но я не виноват, это другой дяденька, или тетенька плохие». Думаю, вы сами уже поняли, что звучит это оправдание довольно сомнительно.
Аргумент «просто сфера работы такая» - еще хуже выглядит. Это значит не то, что кто-то там еще другой косячит, а вы просто сами не можете свою работу организовать нормально, поэтому и ваш труд погряз в бесполезной суете, и других еще напрягаете.
Как ни крути, все варианты ведут к тому, что можно попытаться организовать свою работу и работу окружающих каким-то более-менее нормальным образом.
Многие этого не делают, потому что это сложно. Надо думать, менять что-то, разбираться, разговаривать, выяснять, договариваться, привыкать и т. д. Но мне хочется верить, что в конечном счете те, кто не в состоянии думать, трудиться, меняться, уступят свои места более вдумчивым и ответственным работникам.
Итог
Знайте ненадежных заказчиков, не ведитесь на их суету.
Думайте о своей работе, организуйте её нормально, цените труд и время других людей.
Пикабу
Тихо, тихо ползи, улитка, по склону Фудзи
Автор: Proidemtes
Типичная вакансия тимлида
Если посмотреть на российский рынок тимлидских вакансий, то в подавляющем большинстве случаев мы можем увидеть примерно одинаковую картину. Я понимаю, почему она складывается. Иногда я даже не против. Но есть ряд замечаний, которые нанимающая сторона должна понимать.
И швец, и жнец, и на дуде игрец
Классика!
- Тимлид должен быть самым опытным разработчиком, умеющим запрограммировать самые сложные части приложения.
- Тимлид должен быть хорошим менеджером, чтобы хорошо управляться с командой разработчиков, грамотно управляться с процессом производства программного продукта и найти к каждому, от рядового сотрудника, до топ-менеджмента, свой индивидуальный подход.
- Тимлид должен быть мудрейшим рекрутером, чтобы генерить правильные вакансии, проводить лучшие собеседования, придумать класснейшие онбординг процессы.
- Тимлид даже должен быть немножко продактом, чтобы не бездумно исполнять, что скажет менеджмент, а вникать в предметную область, бизнес процессы, анализировать разные подходы к решению проблем и предлагать свои варианты.
Время не бесконечное
Пожалуй, не буду сейчас вдаваться в подробное обсуждение каждого пункта, ибо этот разговор явно не уместится в один пост.
Довольно частая ошибка, которая встречается повсеместно – ложные ожидания по трудозатратам. Если вы нанимаете человека, как полуменеджера / полуразработчика, то не надо ожидать, что он будет выполнять 100% работы разработчика, и еще 100% работы менеджера. Он даже по 50% выполнять это не сможет. В лучшем случае он будет по 40% тем и этим, а оставшиеся 20% он потратит в никуда на переключение между этими двумя ролями.
Зачем же он такой нужен?
Замечательный вопрос. Особенно у тех, кто никогда не сталкивался с ситуацией, когда менеджеры с разработчиками воюют, каждый гнет свою линию и в итоге вся команда и весь проект работают в режиме «лебедь, рак и щука».
Тут-то вам швец-жнец-тимлид и пригодится, чтобы всю эту компанию понять, подружить, направить по единому пути.
Что делать с вакансией?
Тут единого ответа у меня нет. Надо смотреть по ситуации.
Там, где маленькая команда, небольшой проект, то я бы нанимал тимлида по такой вот классической малоприятной схеме. Ибо при небольшой численности коллектива он будет в бОльшей степени разрабом и опытным товарищем, а в меньшей - менеджером (а там много и не надо).
Но есть и другие варианты, где больше команды, сложнее процессы, большее количество проектов – тут вариантов великое множество. Где-то тимлид – почти фултайм менеджер, где-то он внезапно техлид / архитектор, который отдает почти целиком менеджерскую часть другому человеку, а сам принимает функцию главного всея технаря. На таких масштабах роли начинают расслаиваться, бюджеты позволяют нанимать под определенные аспекты разных людей.
Итог
Найм тимлида – сложная и неоднозначная штука. Серебряной пули тут нет. Надо отталкиваться от текущей ситуации с командой, проектом, процессами. Главное – понимать, что существует ограниченный лимит времени + переключение между ролями тоже съедают какую-то его часть.
Если посмотреть на российский рынок тимлидских вакансий, то в подавляющем большинстве случаев мы можем увидеть примерно одинаковую картину. Я понимаю, почему она складывается. Иногда я даже не против. Но есть ряд замечаний, которые нанимающая сторона должна понимать.
И швец, и жнец, и на дуде игрец
Классика!
- Тимлид должен быть самым опытным разработчиком, умеющим запрограммировать самые сложные части приложения.
- Тимлид должен быть хорошим менеджером, чтобы хорошо управляться с командой разработчиков, грамотно управляться с процессом производства программного продукта и найти к каждому, от рядового сотрудника, до топ-менеджмента, свой индивидуальный подход.
- Тимлид должен быть мудрейшим рекрутером, чтобы генерить правильные вакансии, проводить лучшие собеседования, придумать класснейшие онбординг процессы.
- Тимлид даже должен быть немножко продактом, чтобы не бездумно исполнять, что скажет менеджмент, а вникать в предметную область, бизнес процессы, анализировать разные подходы к решению проблем и предлагать свои варианты.
Время не бесконечное
Пожалуй, не буду сейчас вдаваться в подробное обсуждение каждого пункта, ибо этот разговор явно не уместится в один пост.
Довольно частая ошибка, которая встречается повсеместно – ложные ожидания по трудозатратам. Если вы нанимаете человека, как полуменеджера / полуразработчика, то не надо ожидать, что он будет выполнять 100% работы разработчика, и еще 100% работы менеджера. Он даже по 50% выполнять это не сможет. В лучшем случае он будет по 40% тем и этим, а оставшиеся 20% он потратит в никуда на переключение между этими двумя ролями.
Зачем же он такой нужен?
Замечательный вопрос. Особенно у тех, кто никогда не сталкивался с ситуацией, когда менеджеры с разработчиками воюют, каждый гнет свою линию и в итоге вся команда и весь проект работают в режиме «лебедь, рак и щука».
Тут-то вам швец-жнец-тимлид и пригодится, чтобы всю эту компанию понять, подружить, направить по единому пути.
Что делать с вакансией?
Тут единого ответа у меня нет. Надо смотреть по ситуации.
Там, где маленькая команда, небольшой проект, то я бы нанимал тимлида по такой вот классической малоприятной схеме. Ибо при небольшой численности коллектива он будет в бОльшей степени разрабом и опытным товарищем, а в меньшей - менеджером (а там много и не надо).
Но есть и другие варианты, где больше команды, сложнее процессы, большее количество проектов – тут вариантов великое множество. Где-то тимлид – почти фултайм менеджер, где-то он внезапно техлид / архитектор, который отдает почти целиком менеджерскую часть другому человеку, а сам принимает функцию главного всея технаря. На таких масштабах роли начинают расслаиваться, бюджеты позволяют нанимать под определенные аспекты разных людей.
Итог
Найм тимлида – сложная и неоднозначная штука. Серебряной пули тут нет. Надо отталкиваться от текущей ситуации с командой, проектом, процессами. Главное – понимать, что существует ограниченный лимит времени + переключение между ролями тоже съедают какую-то его часть.
Что значит задача сделана?
Иногда сталкиваюсь с недопониманием между разработчиками, тестировщиками и менеджерами по поводу термина «задача сделана». Это может приводить к неприятным последствиям.
Суть проблемы
На переднем краю проблемы выступает разработчик. Он написал код, отправил в тестирование и доложил «задача готова». Хотя, как она готова, если она даже не протестирована?
Ну такой подход из серии «с моей стороны пули вылетели».
А если нет отдела тестирования, который эти пули хоть как-то может притормозить в случае чего, то разраб написал код, отправил в деплой и с чувством выполненного долга пошел делать другую задачу. Заодно менеджеру рассказал, что всё готово. А если менеджер бестолковый и не перепроверил, так и вообще, получается, на проде непонятно что лежит и неизвестно как работает.
В этом случае главный тестировщик и валидатор качества реализации – разгневанный пользователь, который непременно маякнет в случае чего.
Другой подход
Лично мне нравится идея, которую высказывали на одном из докладов (если я ничего не перепутал) в Badoo.
Когда разработчик занимается задачей «на полную катушку». Пишет код, участвует в тестировании, контролирует деплой и последующую жизнь этой своей фичи некоторое время. Мониторит, метрики собирает. И когда всё тоооочно нормально, тогда считается, что его задача сделана.
Критика такого подхода
Я уверен, что найдется много людей, которые искренне полагают, что их задача – ТОЛЬКО НАПИСАТЬ КОД, а для других стадий жизненного цикла фичи есть другие люди, и это их работа дальше вылетевшие пули контролировать, чтобы прилетели, куда надо.
Я это понимаю. Понимаю, что при очень хорошей, точной настройке процессов, когда у вас слаженная команда и каждый хорошо и ответственно делает свой кусочек работы - это вполне эффективная стратегия. И по ней легко и приятно работать.
Однако, стоит отметить, что если в цепочке, например, из 4х человек всё не совсем гладко и надежность каждого из них по отдельности – 0.95, то надежность всей цепочки (если я правильно считаю) будет уже 0.95*0.95*0.95*0.95 = 0.81.
Так что там про «задача сделана»?
К сожалению, я отвлекся от основной темы и начал рассуждать про то, как именно лучше сделать задачу. А что это значит – не сказал.
Так вот на мой взгляд, задача сделана – это когда выяснили, что она нужна, её разработали, протестировали, отладили, релизнули и посмотрели, что с ней в проде всё хорошо.
По крайней мере с точки зрения бизнеса – вот теперь она сделана. И менеджера, как представителя бизнес стороны, должно волновать всё это в комплексе.
А как там программисты для себя решают сделали они или не сделали задачу – это уже плавающий от компании к компании вопрос организации труда.
Итог
Позаботьтесь о том, чтобы задача была по-настоящему "сделана".
Если можете так организовать работу, чтобы каждый сделал свой маленький кусочек, то и замечательно. А если не получается - уменьшайте количество ответственных в этой цепочке.
Бонусный контент
Мы с Никитой Хромушкиным договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://t.me/product_developer/27
Иногда сталкиваюсь с недопониманием между разработчиками, тестировщиками и менеджерами по поводу термина «задача сделана». Это может приводить к неприятным последствиям.
Суть проблемы
На переднем краю проблемы выступает разработчик. Он написал код, отправил в тестирование и доложил «задача готова». Хотя, как она готова, если она даже не протестирована?
Ну такой подход из серии «с моей стороны пули вылетели».
А если нет отдела тестирования, который эти пули хоть как-то может притормозить в случае чего, то разраб написал код, отправил в деплой и с чувством выполненного долга пошел делать другую задачу. Заодно менеджеру рассказал, что всё готово. А если менеджер бестолковый и не перепроверил, так и вообще, получается, на проде непонятно что лежит и неизвестно как работает.
В этом случае главный тестировщик и валидатор качества реализации – разгневанный пользователь, который непременно маякнет в случае чего.
Другой подход
Лично мне нравится идея, которую высказывали на одном из докладов (если я ничего не перепутал) в Badoo.
Когда разработчик занимается задачей «на полную катушку». Пишет код, участвует в тестировании, контролирует деплой и последующую жизнь этой своей фичи некоторое время. Мониторит, метрики собирает. И когда всё тоооочно нормально, тогда считается, что его задача сделана.
Критика такого подхода
Я уверен, что найдется много людей, которые искренне полагают, что их задача – ТОЛЬКО НАПИСАТЬ КОД, а для других стадий жизненного цикла фичи есть другие люди, и это их работа дальше вылетевшие пули контролировать, чтобы прилетели, куда надо.
Я это понимаю. Понимаю, что при очень хорошей, точной настройке процессов, когда у вас слаженная команда и каждый хорошо и ответственно делает свой кусочек работы - это вполне эффективная стратегия. И по ней легко и приятно работать.
Однако, стоит отметить, что если в цепочке, например, из 4х человек всё не совсем гладко и надежность каждого из них по отдельности – 0.95, то надежность всей цепочки (если я правильно считаю) будет уже 0.95*0.95*0.95*0.95 = 0.81.
Так что там про «задача сделана»?
К сожалению, я отвлекся от основной темы и начал рассуждать про то, как именно лучше сделать задачу. А что это значит – не сказал.
Так вот на мой взгляд, задача сделана – это когда выяснили, что она нужна, её разработали, протестировали, отладили, релизнули и посмотрели, что с ней в проде всё хорошо.
По крайней мере с точки зрения бизнеса – вот теперь она сделана. И менеджера, как представителя бизнес стороны, должно волновать всё это в комплексе.
А как там программисты для себя решают сделали они или не сделали задачу – это уже плавающий от компании к компании вопрос организации труда.
Итог
Позаботьтесь о том, чтобы задача была по-настоящему "сделана".
Если можете так организовать работу, чтобы каждый сделал свой маленький кусочек, то и замечательно. А если не получается - уменьшайте количество ответственных в этой цепочке.
Бонусный контент
Мы с Никитой Хромушкиным договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://t.me/product_developer/27
Внимательно смотри на коллег и руководителей
Недавно ко мне приходил на консультацию человек, карьерный путь которого начался довольно стремительно и успешно. Он очень вдумчиво относится к работе и высказывает много хороших мыслей.
Одной из них я с вами с удовольствием поделюсь, ибо это всё вроде очевидно, но тем не менее далеко не все об этом задумываются.
Типичная ошибка
Часто бывает так, что человек устраивается в компанию, планируя профессиональный и карьерный рост, но не очень внимательно приглядывается к своим старшим товарищам.
Он сосредотачивается на себе, на своих скиллах, на том, что ему в идеале нужно прокачать для успешной работы в абстрактной сферической компании в вакууме. Посмотрел много конференций и исследований рынка, узнал что модно, что в тренде, чего ждет индустрия и забуривается в это.
И это всё вроде верно, план прокачки должен обязательно быть.
Проблема только в том, что вы работаете прямо сейчас в конкретной компании с конкретными процессами и с конкретными перспективами. Да, в некоторых случаях на это можно повлиять и поменять, но в среднем случае вас просто засосет в текущую систему as is.
Что делать
Если вы интересуетесь хард скиллами, смотрите на сениоров, которые работают с вами. В большинстве случаев это то, что вас ожидает в этой компании в будущем.
Если там супер умные головастые ребята – поздравляю, при должном напоре и старании вы сможете многому научиться.
А если сидят мидлы с лычками сениоров и делают типовые банальные штуки день за днем, скорее всего перспективы вас ждут такие же, БЕГИТЕ.
Если вас интересуют софт скиллы и управление, то посмотрите на своего руководителя (тимлида, менеджера) и прикиньте, насколько он загружен, насколько он адекватен, насколько с ним прилично обращаются бизнес и заказчики.
Почувствовали тревожные звоночки? Узнали, что это негласная норма? БЕГИТЕ.
Итог
Я, конечно, искренне верю, что при должном старании можно многое поменять.
У меня было такое, что я годами что-то менял и оно менялось, но это потому что в целом в компании сошлось много положительных факторов, и оно того стоило, чтобы стараться, вкладывать труд и нервы.
Но это скорее исключение, чем правило. Ибо сейчас рынок труда для ИТ специалистов такой, что если ваши изменения мало кто в компании приветствует, то вам намного быстрее и проще сменить компанию на более подходящую, чем уговаривать кого-то годами что-то изменить.
Так что всегда внимательно присматривайтесь в своей компании к тому, кто уже прошел определенный путь до вас.
Если вы смотрите на человека и думаете «а он крутой и ему тут хорошо», то это хороший знак. А если вы видите от него коммиты в 2 часа ночи, а уже утром в 8 вы видите, как его отчитывает руководство, то подумайте, может быть стоит БЕЖАТЬ.
Недавно ко мне приходил на консультацию человек, карьерный путь которого начался довольно стремительно и успешно. Он очень вдумчиво относится к работе и высказывает много хороших мыслей.
Одной из них я с вами с удовольствием поделюсь, ибо это всё вроде очевидно, но тем не менее далеко не все об этом задумываются.
Типичная ошибка
Часто бывает так, что человек устраивается в компанию, планируя профессиональный и карьерный рост, но не очень внимательно приглядывается к своим старшим товарищам.
Он сосредотачивается на себе, на своих скиллах, на том, что ему в идеале нужно прокачать для успешной работы в абстрактной сферической компании в вакууме. Посмотрел много конференций и исследований рынка, узнал что модно, что в тренде, чего ждет индустрия и забуривается в это.
И это всё вроде верно, план прокачки должен обязательно быть.
Проблема только в том, что вы работаете прямо сейчас в конкретной компании с конкретными процессами и с конкретными перспективами. Да, в некоторых случаях на это можно повлиять и поменять, но в среднем случае вас просто засосет в текущую систему as is.
Что делать
Если вы интересуетесь хард скиллами, смотрите на сениоров, которые работают с вами. В большинстве случаев это то, что вас ожидает в этой компании в будущем.
Если там супер умные головастые ребята – поздравляю, при должном напоре и старании вы сможете многому научиться.
А если сидят мидлы с лычками сениоров и делают типовые банальные штуки день за днем, скорее всего перспективы вас ждут такие же, БЕГИТЕ.
Если вас интересуют софт скиллы и управление, то посмотрите на своего руководителя (тимлида, менеджера) и прикиньте, насколько он загружен, насколько он адекватен, насколько с ним прилично обращаются бизнес и заказчики.
Почувствовали тревожные звоночки? Узнали, что это негласная норма? БЕГИТЕ.
Итог
Я, конечно, искренне верю, что при должном старании можно многое поменять.
У меня было такое, что я годами что-то менял и оно менялось, но это потому что в целом в компании сошлось много положительных факторов, и оно того стоило, чтобы стараться, вкладывать труд и нервы.
Но это скорее исключение, чем правило. Ибо сейчас рынок труда для ИТ специалистов такой, что если ваши изменения мало кто в компании приветствует, то вам намного быстрее и проще сменить компанию на более подходящую, чем уговаривать кого-то годами что-то изменить.
Так что всегда внимательно присматривайтесь в своей компании к тому, кто уже прошел определенный путь до вас.
Если вы смотрите на человека и думаете «а он крутой и ему тут хорошо», то это хороший знак. А если вы видите от него коммиты в 2 часа ночи, а уже утром в 8 вы видите, как его отчитывает руководство, то подумайте, может быть стоит БЕЖАТЬ.
Антон Околелов, ведущий подкаста Цинковый Прод, не так давно завел телеграм канал.
Там он пишет про всякое про софт и про хард. Это могут быть свои мысли, или комментарии интересных новостей, или какие-то полезные ссылки.
Мне нравится как он пишет. Тексты получаются живые и с душой. Даже когда я не согласен с его мнением - мне всё равно интересно их читать🙂
Вот пример такого поста, ради которого я подписан на его канал https://t.me/crossjoin/32
Там он пишет про всякое про софт и про хард. Это могут быть свои мысли, или комментарии интересных новостей, или какие-то полезные ссылки.
Мне нравится как он пишет. Тексты получаются живые и с душой. Даже когда я не согласен с его мнением - мне всё равно интересно их читать🙂
Вот пример такого поста, ради которого я подписан на его канал https://t.me/crossjoin/32
Telegram
Cross Join - канал о разработке
Недавно Фил Ранжин написал в твиттере тредик, что мол все аджайл-практики и книги по ним - говно, и только мудрый руководитель на опыте может всё разрулить.
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь.…
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь.…
Прыгуны - это хорошо или плохо?
Недавно поступил вопрос:
«Что делать, если сменил пяток компаний из-за неподходящих условий, и теперь твое резюме кричит "я работаю недолго в компаниях", что читается HR'ами как "я от бабушки ушел и от дедушки ушел и от тебя уйду"?»
Хотелось бы рассмотреть несколько вариаций данной ситуации.
Вы по резюме прыгун, но таким быть не хотите
Если вы не хотите быть прыгуном, но на неделе вы каждые полгода-год меняете работу, то тут надо внимательно посмотреть, почему так получилось. Возможно, вам просто кажется, что вы не такой, а вы такой.
А возможно, просто обстоятельства сложились неудачным образом, и с вами произошла череда неудачных совпадений.
Если это совпадения, то вам надо объясниться, почему факты таковы, что про вас можно подумать не то, что вам бы хотелось.
Если вы уже дошли до собеса, то объяснять это надо, но аккуратно. Не поливайте никого грязью и не рассказывайте, какие все дураки и кидалы. Это создаст о вас негативное впечатление и покажется, что вы так будете про всех своих работодателей думать и говорить. Тем не менее надо спокойно объяснить, что так совпало, что устраивался туда, где, например, договоренности не соблюдались, а вы человек порядочный и так не можете работать, когда какая-то из сторон необязательная.
Правда, иной раз можно до собеса и не дойти, а пропасть на этапе эйчар фильтра. Так что пишите какое-то пояснительное письмо при отклике, или в графе «о себе» что-то такое поясняющее пишите, что ищете постоянную комфортную работу и прыгать без нужды не хотите.
Есть шанс, что часть эйчаров не дочитает до этого момента, но тут уже мало что можно поделать. Старайтесь по возможности обойти этот фильтр и заходить куда-то напрямую к нанимающим менеджерам через знакомства и рекомендации.
На крайний случай есть не очень честный лайфхак, но тут уж вам решать, использовать его или нет. Сократите количество прыжков и растяните сроки в резюме. Эйчар фильтр пройдете, на собес попадете, а когда уже вы понравитесь людям, то мелкие нестыковки уже в понимающей обстановке объясните. Тем более сразу с порога трудовую никто не просит предъявить, чтобы всё сверить.
Вы прыгун, ну и что?
Это вполне нормально. Есть куча мест, где нужны работники на короткий срок, или где готовы к постоянной ротации. Плюс есть мнение (я не согласен, что оно единственно верное), что так легче себе набить хорошую зарплату.
Да, определенный класс долгосрочных вакансий для вас, скорее всего, будет закрыт (ну я бы для долгосрочного сотрудничества прыгуна не рассматривал), но, наверное, это не такая большая трагедия и потеря.
Итог
Рынок сейчас таков, что заботиться надо не о строчках с мест работы, а о своих профессиональных навыках. Были бы нормальные скиллы, а работа и денежки найдутся.
Главное, сами поймите, в каком формате вам хочется работать и на каких условиях. Ну и работодателю всё это понятно донесите.
Недавно поступил вопрос:
«Что делать, если сменил пяток компаний из-за неподходящих условий, и теперь твое резюме кричит "я работаю недолго в компаниях", что читается HR'ами как "я от бабушки ушел и от дедушки ушел и от тебя уйду"?»
Хотелось бы рассмотреть несколько вариаций данной ситуации.
Вы по резюме прыгун, но таким быть не хотите
Если вы не хотите быть прыгуном, но на неделе вы каждые полгода-год меняете работу, то тут надо внимательно посмотреть, почему так получилось. Возможно, вам просто кажется, что вы не такой, а вы такой.
А возможно, просто обстоятельства сложились неудачным образом, и с вами произошла череда неудачных совпадений.
Если это совпадения, то вам надо объясниться, почему факты таковы, что про вас можно подумать не то, что вам бы хотелось.
Если вы уже дошли до собеса, то объяснять это надо, но аккуратно. Не поливайте никого грязью и не рассказывайте, какие все дураки и кидалы. Это создаст о вас негативное впечатление и покажется, что вы так будете про всех своих работодателей думать и говорить. Тем не менее надо спокойно объяснить, что так совпало, что устраивался туда, где, например, договоренности не соблюдались, а вы человек порядочный и так не можете работать, когда какая-то из сторон необязательная.
Правда, иной раз можно до собеса и не дойти, а пропасть на этапе эйчар фильтра. Так что пишите какое-то пояснительное письмо при отклике, или в графе «о себе» что-то такое поясняющее пишите, что ищете постоянную комфортную работу и прыгать без нужды не хотите.
Есть шанс, что часть эйчаров не дочитает до этого момента, но тут уже мало что можно поделать. Старайтесь по возможности обойти этот фильтр и заходить куда-то напрямую к нанимающим менеджерам через знакомства и рекомендации.
На крайний случай есть не очень честный лайфхак, но тут уж вам решать, использовать его или нет. Сократите количество прыжков и растяните сроки в резюме. Эйчар фильтр пройдете, на собес попадете, а когда уже вы понравитесь людям, то мелкие нестыковки уже в понимающей обстановке объясните. Тем более сразу с порога трудовую никто не просит предъявить, чтобы всё сверить.
Вы прыгун, ну и что?
Это вполне нормально. Есть куча мест, где нужны работники на короткий срок, или где готовы к постоянной ротации. Плюс есть мнение (я не согласен, что оно единственно верное), что так легче себе набить хорошую зарплату.
Да, определенный класс долгосрочных вакансий для вас, скорее всего, будет закрыт (ну я бы для долгосрочного сотрудничества прыгуна не рассматривал), но, наверное, это не такая большая трагедия и потеря.
Итог
Рынок сейчас таков, что заботиться надо не о строчках с мест работы, а о своих профессиональных навыках. Были бы нормальные скиллы, а работа и денежки найдутся.
Главное, сами поймите, в каком формате вам хочется работать и на каких условиях. Ну и работодателю всё это понятно донесите.
Поменяй компанию, или поменяй компанию
Думаю, все мы так или иначе работали в ситуациях, когда вроде бы в целом в работе неплохо, но есть какие-то моменты, которые прям конкретно не нравятся.
Что же делать, как же быть?
Эскапизм
В ИТшной среде, особенно на позиции рядовых разработчиков, или менеджеров низшего уровня, эскапизм является довольно популярной практикой.
Рынок труда такой, что, если ты более-менее нормальный специалист, умеешь делать работу, можешь написать своё имя без ошибок и не ходишь под себя – тебе всегда найдется место в другой компании.
Зачем бороться с трудностями, когда от них можно просто убежать?
В принципе, стратегия рабочая, но есть нюансы.
Трудности есть на любой работе и далеко убежать не получится. Плюс, убегая от известных трудностей, вы бежите в неизвестные, про которые вам на собеседовании вряд ли расскажут. Уже по факту, когда вы придете в новую компанию, вам скажут «нуууу…. просто так исторически сложилось».
Инициатива и изменение
Более трудный и боевой вариант – взять дело в свои руки и сделать из всего плохого всё хорошее.
Тоже хорошая стратегия, но есть нюансы.
Усилий и времени придется затратить много, а результат может оказаться плохим. В итоге силы, время, нервы впалили, а карьера простаивает, вы профессионально стагнируете и вообще света белого впереди не видно.
Срединный путь
Лично я придерживаюсь того, что если мне в целом комфортно работается и я вижу определенные перспективы для себя и для компании, то я выбираю путь инициативы и изменения.
Как это делать – это, наверное, тема для отдельного поста. А по-хорошему, и отдельной книги. Например, я сейчас читаю М. Уоткинс «Первые 90 дней», и там вся книга про то, как производить изменения в компании на разных её стадиях, при этом не выстрелив себе в ногу.
Однако, если я увижу, что уже потратил достаточное количество сил и времени, а результат так и остается недостижим, то тогда я выберу эскапизм. Жизнь у меня одна и тратить её на борьбу с ветряными мельницами я не готов.
В моей практике было так, что многое получалось изменить, а бывало, что приходилось сменить саму компанию. Выбор я старался делать осознанный. Не скажу, что он был идеален, но в целом – ни о чем не жалею.
Итог
Постарайтесь после первых проблем не впадать в крайности, а всё взвесить и хорошенько проанализировать. С холодной головой прикиньте, выгодно ли вам сбегать или производить серьезные изменения.
Ведь побег - это легко, но оставляет вас на том же уровне, а изменения – трудно, но позволяет вам расти.
Думаю, все мы так или иначе работали в ситуациях, когда вроде бы в целом в работе неплохо, но есть какие-то моменты, которые прям конкретно не нравятся.
Что же делать, как же быть?
Эскапизм
В ИТшной среде, особенно на позиции рядовых разработчиков, или менеджеров низшего уровня, эскапизм является довольно популярной практикой.
Рынок труда такой, что, если ты более-менее нормальный специалист, умеешь делать работу, можешь написать своё имя без ошибок и не ходишь под себя – тебе всегда найдется место в другой компании.
Зачем бороться с трудностями, когда от них можно просто убежать?
В принципе, стратегия рабочая, но есть нюансы.
Трудности есть на любой работе и далеко убежать не получится. Плюс, убегая от известных трудностей, вы бежите в неизвестные, про которые вам на собеседовании вряд ли расскажут. Уже по факту, когда вы придете в новую компанию, вам скажут «нуууу…. просто так исторически сложилось».
Инициатива и изменение
Более трудный и боевой вариант – взять дело в свои руки и сделать из всего плохого всё хорошее.
Тоже хорошая стратегия, но есть нюансы.
Усилий и времени придется затратить много, а результат может оказаться плохим. В итоге силы, время, нервы впалили, а карьера простаивает, вы профессионально стагнируете и вообще света белого впереди не видно.
Срединный путь
Лично я придерживаюсь того, что если мне в целом комфортно работается и я вижу определенные перспективы для себя и для компании, то я выбираю путь инициативы и изменения.
Как это делать – это, наверное, тема для отдельного поста. А по-хорошему, и отдельной книги. Например, я сейчас читаю М. Уоткинс «Первые 90 дней», и там вся книга про то, как производить изменения в компании на разных её стадиях, при этом не выстрелив себе в ногу.
Однако, если я увижу, что уже потратил достаточное количество сил и времени, а результат так и остается недостижим, то тогда я выберу эскапизм. Жизнь у меня одна и тратить её на борьбу с ветряными мельницами я не готов.
В моей практике было так, что многое получалось изменить, а бывало, что приходилось сменить саму компанию. Выбор я старался делать осознанный. Не скажу, что он был идеален, но в целом – ни о чем не жалею.
Итог
Постарайтесь после первых проблем не впадать в крайности, а всё взвесить и хорошенько проанализировать. С холодной головой прикиньте, выгодно ли вам сбегать или производить серьезные изменения.
Ведь побег - это легко, но оставляет вас на том же уровне, а изменения – трудно, но позволяет вам расти.
SDCast
Есть хороший и очень уважаемый мной подкаст - SDCast. Он выходит в формате интервью с одним гостем.
Слушаю его с интересом уже лет 5, да и с Костей лично давненько уже знаком.
Как я там побывал
Недавно мне довелось побывать там гостем. В своей голове я представлял, что я приду, мы о многом поговорим (ибо во многом схожи по интересам), и будет круто, весело, интересно и полезно.
В реальности вышло немного не так🙂 Помимо того, что я трудноватый собеседник, так я еще и излишне заволновался, видимо, из-за особо теплого отношения к подкасту.
В итоге я скомкано и много набуробил по разным темам, не успевая никуда погрузиться достаточно глубоко. Как дед, который забыл принять таблетки, и решил всем окружающим рассказать всю свою жизнь: как рос, как учился, как работал, как консалтингом занимался и т.д.😀
Так что в целом для обычной беседы по куче разных интересов, наверное, мои рассказы вполне сгодятся. Для раскрытия какой-то темы полностью – этого точно будет маловато. Но столько тем в разумное время чисто физически раскрыть нормально бы и не получилось. Иными словами, я бил по площадям
Если в результате прослушивания вам не понравятся слова-паразиты, сбивчивость и скакание с темы на тему – сорян, уже ничего не изменить. Я для себя сделал выводы, что надо работать над собой, над планом выступления, над умением чутко слушать собеседника, больше практиковаться и т.д.
А если вам хочется обсудить какие-то конкретные темы подробнее, то приходите в чат подкаста https://t.me/SDCast , где я тоже состою, там и обсудим.
Спасибо Косте
Костя делает замечательное дело уже много лет, и я ему искренне благодарен за это.
Итог
Слушайте выпуск со мной по ссылке https://sdcast.ksdaemon.ru/2021/04/sdcast-131/. Надеюсь кому-то будет интересно и/или полезно. Задавайте вопросы, дискутируйте. Я всегда открыт к общению.
Бонусные ссылки примерно про одно и то же на разных платформах:
https://www.patreon.com/posts/49781483
https://www.youtube.com/watch?v=HbCZwpj7qGs
https://twitter.com/SDCast_podcast/status/1380144615764987904
https://twitter.com/KSDaemon/status/1380145775762620428
https://vk.com/feed?w=wall-194574132_36
https://www.facebook.com/SDCastPodcast/posts/284904473207097
Есть хороший и очень уважаемый мной подкаст - SDCast. Он выходит в формате интервью с одним гостем.
Слушаю его с интересом уже лет 5, да и с Костей лично давненько уже знаком.
Как я там побывал
Недавно мне довелось побывать там гостем. В своей голове я представлял, что я приду, мы о многом поговорим (ибо во многом схожи по интересам), и будет круто, весело, интересно и полезно.
В реальности вышло немного не так🙂 Помимо того, что я трудноватый собеседник, так я еще и излишне заволновался, видимо, из-за особо теплого отношения к подкасту.
В итоге я скомкано и много набуробил по разным темам, не успевая никуда погрузиться достаточно глубоко. Как дед, который забыл принять таблетки, и решил всем окружающим рассказать всю свою жизнь: как рос, как учился, как работал, как консалтингом занимался и т.д.😀
Так что в целом для обычной беседы по куче разных интересов, наверное, мои рассказы вполне сгодятся. Для раскрытия какой-то темы полностью – этого точно будет маловато. Но столько тем в разумное время чисто физически раскрыть нормально бы и не получилось. Иными словами, я бил по площадям
Если в результате прослушивания вам не понравятся слова-паразиты, сбивчивость и скакание с темы на тему – сорян, уже ничего не изменить. Я для себя сделал выводы, что надо работать над собой, над планом выступления, над умением чутко слушать собеседника, больше практиковаться и т.д.
А если вам хочется обсудить какие-то конкретные темы подробнее, то приходите в чат подкаста https://t.me/SDCast , где я тоже состою, там и обсудим.
Спасибо Косте
Костя делает замечательное дело уже много лет, и я ему искренне благодарен за это.
Итог
Слушайте выпуск со мной по ссылке https://sdcast.ksdaemon.ru/2021/04/sdcast-131/. Надеюсь кому-то будет интересно и/или полезно. Задавайте вопросы, дискутируйте. Я всегда открыт к общению.
Бонусные ссылки примерно про одно и то же на разных платформах:
https://www.patreon.com/posts/49781483
https://www.youtube.com/watch?v=HbCZwpj7qGs
https://twitter.com/SDCast_podcast/status/1380144615764987904
https://twitter.com/KSDaemon/status/1380145775762620428
https://vk.com/feed?w=wall-194574132_36
https://www.facebook.com/SDCastPodcast/posts/284904473207097
Telegram
SDCast discussions
Обсуждаем выпуски подкаста, делимся впечатлениями и предлагаем гостей! Сайт: sdcast.ksdaemon.ru
В группе включены одобрения ибо спаммеры задолбали.
В группе включены одобрения ибо спаммеры задолбали.
Байкшеддинг
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
Менеджеры с техническим бэкграундом
Хороший менеджер с внятным техническим бэкграундом – человек редкий. И скорее всего далеко не каждому удалось с таким поработать. Однако те, кто с подобными ребятами сталкивался, отмечают их разумность, эффективность и быстроту результатов.
В чем разница с гуманитариями?
Как показывает моя и чужая практика – ощутимая разница присутствует. Она начинает проявляться, как только дело касается какой-то инженерной практики, разработки, инфраструктуры и т. д.
Можно сколько угодно говорить про то, что менеджер не должен разбираться в деталях, он должен только подбирать крутую команду и направлять её. Однако эти лидерские разговоры быстро разбиваются о быт инженерных задач.
Да, конечно, менеджеру не надо прям в деталях знать, как их делать, но, если он в целом более-менее компетентен, можно сэкономить море времени на обсуждениях, согласованиях и даже разоблачении обманщиков. Сэкономить и время, и нервы, и трудозатраты.
А если вы подрядчик, то, выставляя вперед такого толкового менеджера, можно сразу заработать побольше авторитета в глазах заказчика.
Осторожнее с менеджерами-технарями
Звучит всё вышесказанное так, как будто прямо сейчас надо всех программистов перевести в менеджеры и наступит счастье. Однако это не так. Очень часто бывает, что хороший программист становится плохим менеджером, который приносит боль себе и коллегам.
Всё, что я говорил выше, относится к сравнению хороший менеджер без технического бэкграунда vs хороший менеджер с оным.
А в общем случае, конечно, лучше хороший менеджер-гуманитарий, чем плохой менеджер-технарь
Я перестаю быть крутым инженером, а менеджеров много
Оооочень частая проблема технарей – боязнь обесцениться в рядового менеджера, каких много.
Поэтому я этот пост и пишу. Не надо бояться. Если у вас правда получится стать толковым менеджером, то у вас будет очевидный плюс среди моря гуманитариев в менеджменте.
Кто знает в этом толк – вас с руками оторвет, не переживайте.
Итог
Если вы столкнулись с толковым менеджером технарем – радуйтесь и держите его.
Если видите, что человек может и хочет расти в менеджмент, а сейчас простой инженер – помогите ему, возможно, у вас
получится вырастить очень ценного сотрудника.
Если вы не хотите быть менеджером, то и не будьте🙂 Хорошие инженеры тоже очень нужны, важны и востребованы.
Хороший менеджер с внятным техническим бэкграундом – человек редкий. И скорее всего далеко не каждому удалось с таким поработать. Однако те, кто с подобными ребятами сталкивался, отмечают их разумность, эффективность и быстроту результатов.
В чем разница с гуманитариями?
Как показывает моя и чужая практика – ощутимая разница присутствует. Она начинает проявляться, как только дело касается какой-то инженерной практики, разработки, инфраструктуры и т. д.
Можно сколько угодно говорить про то, что менеджер не должен разбираться в деталях, он должен только подбирать крутую команду и направлять её. Однако эти лидерские разговоры быстро разбиваются о быт инженерных задач.
Да, конечно, менеджеру не надо прям в деталях знать, как их делать, но, если он в целом более-менее компетентен, можно сэкономить море времени на обсуждениях, согласованиях и даже разоблачении обманщиков. Сэкономить и время, и нервы, и трудозатраты.
А если вы подрядчик, то, выставляя вперед такого толкового менеджера, можно сразу заработать побольше авторитета в глазах заказчика.
Осторожнее с менеджерами-технарями
Звучит всё вышесказанное так, как будто прямо сейчас надо всех программистов перевести в менеджеры и наступит счастье. Однако это не так. Очень часто бывает, что хороший программист становится плохим менеджером, который приносит боль себе и коллегам.
Всё, что я говорил выше, относится к сравнению хороший менеджер без технического бэкграунда vs хороший менеджер с оным.
А в общем случае, конечно, лучше хороший менеджер-гуманитарий, чем плохой менеджер-технарь
Я перестаю быть крутым инженером, а менеджеров много
Оооочень частая проблема технарей – боязнь обесцениться в рядового менеджера, каких много.
Поэтому я этот пост и пишу. Не надо бояться. Если у вас правда получится стать толковым менеджером, то у вас будет очевидный плюс среди моря гуманитариев в менеджменте.
Кто знает в этом толк – вас с руками оторвет, не переживайте.
Итог
Если вы столкнулись с толковым менеджером технарем – радуйтесь и держите его.
Если видите, что человек может и хочет расти в менеджмент, а сейчас простой инженер – помогите ему, возможно, у вас
получится вырастить очень ценного сотрудника.
Если вы не хотите быть менеджером, то и не будьте🙂 Хорошие инженеры тоже очень нужны, важны и востребованы.
Максимальная утилизация ресурсов - это плохо
Есть совершенно понятная и очевидная каждому, не шибко разбирающемуся менеджеру мысль – все должны быть при деле.
Есть команда, есть рабочие руки, и все их надо нагрузить. И запланировать работу так, чтобы как только они освободятся, работа уже их ожидала: без отрыва от производства, так сказать.
Где-то тут могут крыться неочевидные проблемы. Давайте поищем.
Простои и ожидания
Если бестолковый менеджер всё-таки углубится в то, как его команда работает, то он обнаружит, что задачи часто не изолированные, а один работник сначала пилит свой кусочек задачи, затем отдает его другому, тот работает с ним и своей частью, передает дальше.
И вот чем дольше простои между тем, как один другому передал, а другой от чего-то левого освободился, принял задачу и начал свою часть пилить, тем медленнее задача завершится. А чем медленнее задачи завершаются, тем длиннее копится очередь этих задач.
А чем нагруженнее параллельными задачами каждый работник в этой цепи, тем дольше эти простои. Ой, оказывается, если нагрузить людей морем параллельной работы, она быстро не сделается, вот это лайфхак!
Вот вам замечательное видео с визуализацией по этому поводу https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy
Отряд замечает потерю бойца
Если в такой высоконагруженной команде с морем параллельных дел, когда все «при деле» (читай «работают изо всех сил не особо успевая»), выбывает хотя бы один человек, всё может резко усугубиться. Хотя бы одно звено в еле работающей цепи вываливается, и в этом месте скапливаются такие горы работы, которые сложно будет разгрести.
А выбыть может человек по сотне причин, в то время как успешный эффективный менеджер и не представляет, что его люди могут болеть, увольняться, ходить в отпуск, выгорать и прочим образом терять эффективность.
Какие новые идеи?
Потеря времени и способностей для креативного мышления – еще один отрицательный фактор для перегруженных команд. Некогда придумывать новые решения, некогда разбираться в новых технологиях и том, как их адаптировать для своих процессов, некогда даже проанализировать свои процессы на предмет разумности и эффективности.
Некогда точить пилу, когда всё время надо пилить.
Итог
Понятно, что бездельничать люди не должны, но при этом надо тщательно подходить к объему работы. И объему параллельной работы.
Не стоит думать, что если команда не успевает N задач делать, то чтобы повысить эффективность, надо им дать 2N задач и сказать, чтобы они «просто делали параллельно».
Подумайте об этом сами, покажите статью и видео эффективным менеджерам.
Есть совершенно понятная и очевидная каждому, не шибко разбирающемуся менеджеру мысль – все должны быть при деле.
Есть команда, есть рабочие руки, и все их надо нагрузить. И запланировать работу так, чтобы как только они освободятся, работа уже их ожидала: без отрыва от производства, так сказать.
Где-то тут могут крыться неочевидные проблемы. Давайте поищем.
Простои и ожидания
Если бестолковый менеджер всё-таки углубится в то, как его команда работает, то он обнаружит, что задачи часто не изолированные, а один работник сначала пилит свой кусочек задачи, затем отдает его другому, тот работает с ним и своей частью, передает дальше.
И вот чем дольше простои между тем, как один другому передал, а другой от чего-то левого освободился, принял задачу и начал свою часть пилить, тем медленнее задача завершится. А чем медленнее задачи завершаются, тем длиннее копится очередь этих задач.
А чем нагруженнее параллельными задачами каждый работник в этой цепи, тем дольше эти простои. Ой, оказывается, если нагрузить людей морем параллельной работы, она быстро не сделается, вот это лайфхак!
Вот вам замечательное видео с визуализацией по этому поводу https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy
Отряд замечает потерю бойца
Если в такой высоконагруженной команде с морем параллельных дел, когда все «при деле» (читай «работают изо всех сил не особо успевая»), выбывает хотя бы один человек, всё может резко усугубиться. Хотя бы одно звено в еле работающей цепи вываливается, и в этом месте скапливаются такие горы работы, которые сложно будет разгрести.
А выбыть может человек по сотне причин, в то время как успешный эффективный менеджер и не представляет, что его люди могут болеть, увольняться, ходить в отпуск, выгорать и прочим образом терять эффективность.
Какие новые идеи?
Потеря времени и способностей для креативного мышления – еще один отрицательный фактор для перегруженных команд. Некогда придумывать новые решения, некогда разбираться в новых технологиях и том, как их адаптировать для своих процессов, некогда даже проанализировать свои процессы на предмет разумности и эффективности.
Некогда точить пилу, когда всё время надо пилить.
Итог
Понятно, что бездельничать люди не должны, но при этом надо тщательно подходить к объему работы. И объему параллельной работы.
Не стоит думать, что если команда не успевает N задач делать, то чтобы повысить эффективность, надо им дать 2N задач и сказать, чтобы они «просто делали параллельно».
Подумайте об этом сами, покажите статью и видео эффективным менеджерам.
YouTube
The resource utilization trap
Henrik Kniberg explains the resource utilization trap, how it impacts our ability to deliver and what we can do about it.
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
Некогда точить пилу, надо пилить!
Мудрый анекдот
Мужик пилит дерево, к нему подходит другой и говорит:
— Мужик, давно пилишь?
— 3 дня.
— А может тебе пилу заточить?
— Некогда мне, пилить нужно.
В реальной жизни
Эта абсурдная ситуация окружает нас сплошь и рядом. Порой в это даже сложно поверить.
- Есть рутинные ежедневные действия, которые вы делаете руками, но не автоматизировали до сих пор? Некогда точить пилу!
- Есть коллеги, у которых каждый день пожары, и они просто занимаются их тушением, никак не пытаясь разобраться в первопричинах? Некогда точить пилу!
- Есть желание вайти вайти, но при этом вы не занимаетесь изучением базовых фундаментальных принципов, а заучиваете что будет, если в реакте написать так, или сяк? Некогда точить пилу!
- Есть желание похудеть к лету, но вы не разбираетесь в питании, тренировках, а просто прочитали в яндекс.дзене, что если делать 100 скручиваний на пресс каждый день, то будет зашибись. Некогда точить пилу!
Остановитесь
Прекратите тратить время и генерировать сумбурный бесполезный труд. Остановитесь, подумайте о том, где действительно корень проблемы и вдумчиво разберитесь с этим. Локально вы потеряете чуть больше времени, но глобально вы сильно выиграете и по времени, и по качеству результатов своего труда.
Итог
Постоянно помните мудрый анекдот, и при малейших признаках того, что вы закрутились в суете, берите паузу для анализа ситуации.
Помогите сначала себе, потом своим товарищам осознать проблему и найти разумное решение.
Наточите, блин, уже свою пилу!
Мудрый анекдот
Мужик пилит дерево, к нему подходит другой и говорит:
— Мужик, давно пилишь?
— 3 дня.
— А может тебе пилу заточить?
— Некогда мне, пилить нужно.
В реальной жизни
Эта абсурдная ситуация окружает нас сплошь и рядом. Порой в это даже сложно поверить.
- Есть рутинные ежедневные действия, которые вы делаете руками, но не автоматизировали до сих пор? Некогда точить пилу!
- Есть коллеги, у которых каждый день пожары, и они просто занимаются их тушением, никак не пытаясь разобраться в первопричинах? Некогда точить пилу!
- Есть желание вайти вайти, но при этом вы не занимаетесь изучением базовых фундаментальных принципов, а заучиваете что будет, если в реакте написать так, или сяк? Некогда точить пилу!
- Есть желание похудеть к лету, но вы не разбираетесь в питании, тренировках, а просто прочитали в яндекс.дзене, что если делать 100 скручиваний на пресс каждый день, то будет зашибись. Некогда точить пилу!
Остановитесь
Прекратите тратить время и генерировать сумбурный бесполезный труд. Остановитесь, подумайте о том, где действительно корень проблемы и вдумчиво разберитесь с этим. Локально вы потеряете чуть больше времени, но глобально вы сильно выиграете и по времени, и по качеству результатов своего труда.
Итог
Постоянно помните мудрый анекдот, и при малейших признаках того, что вы закрутились в суете, берите паузу для анализа ситуации.
Помогите сначала себе, потом своим товарищам осознать проблему и найти разумное решение.
Наточите, блин, уже свою пилу!
Инфантил расправил плечи
Сегодня хочется поговорить о довольно скользкой теме.
Скользкая, потому что есть в ней и полезное зерно, но в глобальном смысле много бед может приключиться.
Успешная инфосекта
Существует ряд мотивационной хрени в разной форме: книги, курсы, видео, организации. И ладно бы, если бы это была просто абстрактная мотивация что-то созидать, но там в подавляющем большинстве случаев всё завязано на деньги. А в идеале не просто деньги, а легкие деньги от бездумного действия.
Вам там расскажут, что каждый может стать миллиардером, регулярно летающем на своем бизнес джете на Мальдивы просто, чтобы выпить тропический коктейль.
И главное, что для этого нужно сделать – ВИЗУАЛИЗИРОВАТЬ И ДЕЙСТВОВАТЬ. Обратите внимание, что про подумать, проанализировать, прикинуть риски, составить хороший план и так далее, там не очень-то говорится. Это ведь скучно, сложно и не каждый захочет заморачиваться.
Ожидание
Я реально знаю таких людей, которые начитались подобной литературы, напосещались таких тренингов.
Вот немного реальных примеров того, что они ожидают:
- Личный розовый кадиллак за год (это не шутка) с продажи косметики и бытовой химии.
- Новенький феррари за год с продажи оконных рам и входных дверей.
- Доход от 150к рублей в месяц после двух месяцев прохождения копеечных курсов по инстацыганству.
- Не работать никогда на дядю, будучи фрилансером, работая с солнечных пляжей по всему миру (про такое катастрофическое заблуждение в ИТ я отдельный пост напишу).
- Много денег и успеха, если всего лишь произносить каждое утро перед зеркалом аффирмации про деньги и успех.
А если обобщить, то это бизнес атлант, расправляющий плечи и летящий на крыльях мечты к заветным миллиардам и широкому общественному признанию.
Реальность
Начитавшиеся вдохновляющей литературы инфантилы начинают бездумно делать какие-то действия, при этом ожидая только самого успешного успеха.
В результате они тратят кучу времени, сил, остатков денег и нервов своих близких людей, при этом не получая ничего толкового в результате. Итог – разочарование, злость, депрессия, свистящая фляга.
При этом никому не приходит в голову, что если бы действительно был легкий рецепт успешного успеха, то уже все вокруг были бы суперзвездами.
Какая реальная польза?
Реальная польза в такой мотивации для умных людей существует. Зарядить человека на деятельность - это хорошо и полезно. А умный уже сам поймет, что надо не просто действовать абы как, а рационально и запланировано.
Итог
Будьте осторожны и вдумчивы. Критически мыслите, анализируя прочитанное и просмотренное.
Не гонитесь за легким и сказочным успехом.
Помните, что в большинстве случаев успеху сопутствует огромный труд и подготовка.
Сегодня хочется поговорить о довольно скользкой теме.
Скользкая, потому что есть в ней и полезное зерно, но в глобальном смысле много бед может приключиться.
Успешная инфосекта
Существует ряд мотивационной хрени в разной форме: книги, курсы, видео, организации. И ладно бы, если бы это была просто абстрактная мотивация что-то созидать, но там в подавляющем большинстве случаев всё завязано на деньги. А в идеале не просто деньги, а легкие деньги от бездумного действия.
Вам там расскажут, что каждый может стать миллиардером, регулярно летающем на своем бизнес джете на Мальдивы просто, чтобы выпить тропический коктейль.
И главное, что для этого нужно сделать – ВИЗУАЛИЗИРОВАТЬ И ДЕЙСТВОВАТЬ. Обратите внимание, что про подумать, проанализировать, прикинуть риски, составить хороший план и так далее, там не очень-то говорится. Это ведь скучно, сложно и не каждый захочет заморачиваться.
Ожидание
Я реально знаю таких людей, которые начитались подобной литературы, напосещались таких тренингов.
Вот немного реальных примеров того, что они ожидают:
- Личный розовый кадиллак за год (это не шутка) с продажи косметики и бытовой химии.
- Новенький феррари за год с продажи оконных рам и входных дверей.
- Доход от 150к рублей в месяц после двух месяцев прохождения копеечных курсов по инстацыганству.
- Не работать никогда на дядю, будучи фрилансером, работая с солнечных пляжей по всему миру (про такое катастрофическое заблуждение в ИТ я отдельный пост напишу).
- Много денег и успеха, если всего лишь произносить каждое утро перед зеркалом аффирмации про деньги и успех.
А если обобщить, то это бизнес атлант, расправляющий плечи и летящий на крыльях мечты к заветным миллиардам и широкому общественному признанию.
Реальность
Начитавшиеся вдохновляющей литературы инфантилы начинают бездумно делать какие-то действия, при этом ожидая только самого успешного успеха.
В результате они тратят кучу времени, сил, остатков денег и нервов своих близких людей, при этом не получая ничего толкового в результате. Итог – разочарование, злость, депрессия, свистящая фляга.
При этом никому не приходит в голову, что если бы действительно был легкий рецепт успешного успеха, то уже все вокруг были бы суперзвездами.
Какая реальная польза?
Реальная польза в такой мотивации для умных людей существует. Зарядить человека на деятельность - это хорошо и полезно. А умный уже сам поймет, что надо не просто действовать абы как, а рационально и запланировано.
Итог
Будьте осторожны и вдумчивы. Критически мыслите, анализируя прочитанное и просмотренное.
Не гонитесь за легким и сказочным успехом.
Помните, что в большинстве случаев успеху сопутствует огромный труд и подготовка.
Иллюзия компетентности в обучении
Так как обучение – важный аспект жизни и работы в ИТ, то хотелось бы рассмотреть проблему иллюзии компетентности и то, как с этим бороться.
Суть проблемы
Вы читаете теорию, разбираетесь и даже полностью понимаете. И потом с чувством гордости удаляетесь лопатить другую теорию, потому что прошлую «вы уже знаете», и так далее.
Здесь две проблемные точки.
- Понять теорию – не значит вспомнить её, когда потребуется и успешно применить на практике.
- Теория загружается в голову, нон-стопом вытесняя постепенно предыдущую. При этом субъективно кажется, что вы знаете и помните сразу всё.
Личный пример проблемы
Обожаю слушать подкасты (вот мой тред про них https://twitter.com/_jeck/status/1326871921833676811)
Бывает, послушаю утром один подкаст, а потом оставшийся день он у меня где-то на фоне в голове варится потихонечку. Вроде чай пью, а вроде и мысль какая-то промелькнула хорошая про то, как что-то из этого подкаста у себя в проекте применить.
И на следующий день сохраняется довольно хорошее понимание того, про что там была речь и что с этим новым знанием делать, как его и когда применять.
А бывают дни, когда один за другим слушаю. И к вечеру такое ощущение, что ничего, кроме последнего подкаста, и не слушал, и не понял, и забыл. Только если сильно напрячься и целенаправленно попытаться вспомнить, то кой-чего и всплывет в памяти.
То же и с изучение теории буквально на каждом шагу. Прочитал, допустим, про то, как explain в базе работает, индексы строятся и ходишь гордый. А приходит время медленных запросов и «ой, что-то как-то я тут забыл, здесь не получается, вон то должны быть так, а оно вроде как и эдак».
Что делать
Стараться комбинировать теорию и практику. Да, не всегда это получается.
Тем не менее во многих случаях возможно, просто люди это редко делают. А почему редко делают? Потому что прочитать, понять и преисполниться гордостью легко, а вот потом еще и на практике это всё закрепить – ощутимо труднее. Поэтому и выбирают легкий, но неэффективный путь.
Лучше не загружать в голову очень много за раз. Давать себе переварить в фоне эти знания, подумать о них время от времени, прикинуть как, зачем и куда их девать.
Да, кажется, что вы не успеваете, что вокруг столько всего нужного и некогда делать паузы. Но постарайтесь думать об обучении не как о спринте, а как о марафоне. Медленный, но эффективный и комфортный темп в долгосрочной перспективе будет куда приятнее и полезнее, чем изматывающие спринты, после которых половина вылетает из головы, да и вообще уже ничего учить не хочется.
Итог
Знайте об эффекте иллюзии компетентности, старайтесь критически анализировать себя в этом ключе, напоминайте себе об этом.
Учитесь размеренно и не забывайте подкреплять теорию практикой. Продуктивной учебы!
Бонусный контент
Мы с каналом Psy в IT договорились написать пост на эту тему, каждый у себя в канале. Вариант ребят здесь https://t.me/psyvit/406
Так как обучение – важный аспект жизни и работы в ИТ, то хотелось бы рассмотреть проблему иллюзии компетентности и то, как с этим бороться.
Суть проблемы
Вы читаете теорию, разбираетесь и даже полностью понимаете. И потом с чувством гордости удаляетесь лопатить другую теорию, потому что прошлую «вы уже знаете», и так далее.
Здесь две проблемные точки.
- Понять теорию – не значит вспомнить её, когда потребуется и успешно применить на практике.
- Теория загружается в голову, нон-стопом вытесняя постепенно предыдущую. При этом субъективно кажется, что вы знаете и помните сразу всё.
Личный пример проблемы
Обожаю слушать подкасты (вот мой тред про них https://twitter.com/_jeck/status/1326871921833676811)
Бывает, послушаю утром один подкаст, а потом оставшийся день он у меня где-то на фоне в голове варится потихонечку. Вроде чай пью, а вроде и мысль какая-то промелькнула хорошая про то, как что-то из этого подкаста у себя в проекте применить.
И на следующий день сохраняется довольно хорошее понимание того, про что там была речь и что с этим новым знанием делать, как его и когда применять.
А бывают дни, когда один за другим слушаю. И к вечеру такое ощущение, что ничего, кроме последнего подкаста, и не слушал, и не понял, и забыл. Только если сильно напрячься и целенаправленно попытаться вспомнить, то кой-чего и всплывет в памяти.
То же и с изучение теории буквально на каждом шагу. Прочитал, допустим, про то, как explain в базе работает, индексы строятся и ходишь гордый. А приходит время медленных запросов и «ой, что-то как-то я тут забыл, здесь не получается, вон то должны быть так, а оно вроде как и эдак».
Что делать
Стараться комбинировать теорию и практику. Да, не всегда это получается.
Тем не менее во многих случаях возможно, просто люди это редко делают. А почему редко делают? Потому что прочитать, понять и преисполниться гордостью легко, а вот потом еще и на практике это всё закрепить – ощутимо труднее. Поэтому и выбирают легкий, но неэффективный путь.
Лучше не загружать в голову очень много за раз. Давать себе переварить в фоне эти знания, подумать о них время от времени, прикинуть как, зачем и куда их девать.
Да, кажется, что вы не успеваете, что вокруг столько всего нужного и некогда делать паузы. Но постарайтесь думать об обучении не как о спринте, а как о марафоне. Медленный, но эффективный и комфортный темп в долгосрочной перспективе будет куда приятнее и полезнее, чем изматывающие спринты, после которых половина вылетает из головы, да и вообще уже ничего учить не хочется.
Итог
Знайте об эффекте иллюзии компетентности, старайтесь критически анализировать себя в этом ключе, напоминайте себе об этом.
Учитесь размеренно и не забывайте подкреплять теорию практикой. Продуктивной учебы!
Бонусный контент
Мы с каналом Psy в IT договорились написать пост на эту тему, каждый у себя в канале. Вариант ребят здесь https://t.me/psyvit/406
Онбординг
С проблемой несистемного онбординга сотрудников сталкиваются многие. Причем неважно, насколько часто к вам устраиваются новые люди.
Если поток новых людей большой, нужно проводить много рутинных однотипных действий и легко в них запутаться, забыть, забить, исказить.
Если поток новых людей маленький, вроде работы меньше, а вроде и мало кто помнит, что именно нужно делать.
Так там дел на 5 минут
Проблема в том, что действительно кажется, что дел на 5 минут, а по факту это совсем не так. Выдать нужную технику, помочь в её настройке, выдать необходимые доступы, проверить, познакомить с нужными людьми, объяснить некоторые процессы, регламенты и т.д.
Продумайте процесс
Не действуйте стихийно, каждый раз придумывая и вспоминая, что еще нужно сделать, чтобы человек смог нормально работать.
Потратьте время, продумайте хорошенько процесс онбординга.
Представьте себе нового сотрудника, у которого нет ни техники, ни доступов, ни понимания, с кем и как работать.
Продумайте его типовые задачи, которые вы ему поручите в обозримом будущем.
Подумайте, как он будет их выполнять, чего ему не хватит, с какими проблемами он столкнется, какие вопросы вам задаст.
Напишите инструкцию
Чтобы ничего не забыть, не пропустить и не быть единственным хранителем сакрального знания, напишите хорошую пошаговую инструкцию. Тогда в какой-то момент вам даже не обязательно самому онбордить, а вы сможете этот процесс делегировать. Либо вас просто спокойно могут уволить, не боясь, что процесс сломается😁
Анализируйте и актуализируйте
Скорее всего идеальной всеобъемлющей инструкции с первого раза у вас не выйдет. Но это не повод опускать руки и думать, что такой подход не работает.
Вам нужно лишь после каждого такого онбординга проводить анализ его эффективности. И если где-то что-то пошло не так, постарайтесь соответствующим образом актуализировать свою инструкцию, чтобы в будущем избежать этих проблем.
Итог
Всё как всегда: системный подход и инструкции.
Ну и в целом хочется сказать, что если у вас нет внятного процесса онбординга, то это уже с самого начала сотрудничества создает негативное впечатление.
Вы бросаете растерянного нового работника на произвол судьбы, и вряд ли он вам будет за это благодарен.
На мой взгляд, не лучший старт для новых трудовых отношений. Особенно, если вы надеетесь на долгосрочное сотрудничество.
С проблемой несистемного онбординга сотрудников сталкиваются многие. Причем неважно, насколько часто к вам устраиваются новые люди.
Если поток новых людей большой, нужно проводить много рутинных однотипных действий и легко в них запутаться, забыть, забить, исказить.
Если поток новых людей маленький, вроде работы меньше, а вроде и мало кто помнит, что именно нужно делать.
Так там дел на 5 минут
Проблема в том, что действительно кажется, что дел на 5 минут, а по факту это совсем не так. Выдать нужную технику, помочь в её настройке, выдать необходимые доступы, проверить, познакомить с нужными людьми, объяснить некоторые процессы, регламенты и т.д.
Продумайте процесс
Не действуйте стихийно, каждый раз придумывая и вспоминая, что еще нужно сделать, чтобы человек смог нормально работать.
Потратьте время, продумайте хорошенько процесс онбординга.
Представьте себе нового сотрудника, у которого нет ни техники, ни доступов, ни понимания, с кем и как работать.
Продумайте его типовые задачи, которые вы ему поручите в обозримом будущем.
Подумайте, как он будет их выполнять, чего ему не хватит, с какими проблемами он столкнется, какие вопросы вам задаст.
Напишите инструкцию
Чтобы ничего не забыть, не пропустить и не быть единственным хранителем сакрального знания, напишите хорошую пошаговую инструкцию. Тогда в какой-то момент вам даже не обязательно самому онбордить, а вы сможете этот процесс делегировать. Либо вас просто спокойно могут уволить, не боясь, что процесс сломается😁
Анализируйте и актуализируйте
Скорее всего идеальной всеобъемлющей инструкции с первого раза у вас не выйдет. Но это не повод опускать руки и думать, что такой подход не работает.
Вам нужно лишь после каждого такого онбординга проводить анализ его эффективности. И если где-то что-то пошло не так, постарайтесь соответствующим образом актуализировать свою инструкцию, чтобы в будущем избежать этих проблем.
Итог
Всё как всегда: системный подход и инструкции.
Ну и в целом хочется сказать, что если у вас нет внятного процесса онбординга, то это уже с самого начала сотрудничества создает негативное впечатление.
Вы бросаете растерянного нового работника на произвол судьбы, и вряд ли он вам будет за это благодарен.
На мой взгляд, не лучший старт для новых трудовых отношений. Особенно, если вы надеетесь на долгосрочное сотрудничество.
Сегодня в 19 буду проводить вебинар в Хекслете.
Тема - гайд для начинающего тимлида.
Приходите посмотреть, послушать, поспрашивать.
Более подробное описание: https://t.me/hexlet_ru/2405
Просто ссылка на трансляцию: https://youtu.be/y_HkXvFovAc
Если вам не нравится смотреть, но нравится читать, то после вебинара я соберу подготовительные материалы и запощу статьей хабр.
Тема - гайд для начинающего тимлида.
Приходите посмотреть, послушать, поспрашивать.
Более подробное описание: https://t.me/hexlet_ru/2405
Просто ссылка на трансляцию: https://youtu.be/y_HkXvFovAc
Если вам не нравится смотреть, но нравится читать, то после вебинара я соберу подготовительные материалы и запощу статьей хабр.
Telegram
Хекслет
«Я стал тимлидом. Аааааа!»
С какими сложностями могут столкнуться начинающие тимлиды? Какие инструменты могут помочь на старте для построения процесса? Как справляться с синдромом самозванца? Как строить коммуникацию с командой (особенно при изменении роли…
С какими сложностями могут столкнуться начинающие тимлиды? Какие инструменты могут помочь на старте для построения процесса? Как справляться с синдромом самозванца? Как строить коммуникацию с командой (особенно при изменении роли…
Гайд для начинающего тимлида
Как и обещал вчера – вот моя статья https://habr.com/ru/post/559394/ по мотивам того, о чем я рассказывал на вчерашнем вебинаре в Хекслете.
Надеюсь, такое дублирование поможет еще большему количеству людей ознакомиться с материалом, определиться в карьере и избежать типовых проблем.
Очень благодарен своей жене, которая вычитывает и редактирует каждый мой пост и каждую статью. Без неё всё было бы несколько косноязычнее и хуже в плане некоторых синтаксических особенностей🧐
Она тоже в свободное время пишет тексты и ведет телеграм-канал. Если вы киноман или просто ищете, что бы еще посмотреть, то Катюха вам обязательно посоветует👍
Сегодня для подписчиков канала Тимлид Очевидность у неё максимально релевантный контент. «Тед Лассо» – сериал, который обожают все тимлиды https://t.me/katyuha_smotrit/59
Как и обещал вчера – вот моя статья https://habr.com/ru/post/559394/ по мотивам того, о чем я рассказывал на вчерашнем вебинаре в Хекслете.
Надеюсь, такое дублирование поможет еще большему количеству людей ознакомиться с материалом, определиться в карьере и избежать типовых проблем.
Очень благодарен своей жене, которая вычитывает и редактирует каждый мой пост и каждую статью. Без неё всё было бы несколько косноязычнее и хуже в плане некоторых синтаксических особенностей🧐
Она тоже в свободное время пишет тексты и ведет телеграм-канал. Если вы киноман или просто ищете, что бы еще посмотреть, то Катюха вам обязательно посоветует👍
Сегодня для подписчиков канала Тимлид Очевидность у неё максимально релевантный контент. «Тед Лассо» – сериал, который обожают все тимлиды https://t.me/katyuha_smotrit/59
Хабр
Гайд начинающего тимлида
В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает.Всё это я проговаривал на вебинаре в Хекслете тут. Однако я уверен, что есть такие...
Сегодня приду одним из гостей в подкаст Цинковый Прод https://znprod.io/
Речь пойдет о собеседованиях.
Это не какое-то мое сольное выступления, а скорее здоровая (надеюсь) дискуссия ведущих и троих гостей. Так что какого-то внятного, структурированного материала я не готовил. Просто надеюсь приятно поболтать с ребятами о довольно холиварной теме в индустрии.
Не сомневаюсь, что ведущие всё направят в нужное, полезное и веселое русло🙂
Смотрите стрим сегодня в 20:00 на их ютуб канале https://www.youtube.com/channel/UC6cTShKx3lJWw-EzSr_ZAfw
Или ждите субботы, пока выйдет смонтированный аудио выпуск.
Речь пойдет о собеседованиях.
Это не какое-то мое сольное выступления, а скорее здоровая (надеюсь) дискуссия ведущих и троих гостей. Так что какого-то внятного, структурированного материала я не готовил. Просто надеюсь приятно поболтать с ребятами о довольно холиварной теме в индустрии.
Не сомневаюсь, что ведущие всё направят в нужное, полезное и веселое русло🙂
Смотрите стрим сегодня в 20:00 на их ютуб канале https://www.youtube.com/channel/UC6cTShKx3lJWw-EzSr_ZAfw
Или ждите субботы, пока выйдет смонтированный аудио выпуск.
Подготовка к собеседованию по STAR
По мотивам вчерашнего выпуска Цинкового Прода про собеседования https://www.youtube.com/watch?v=ezt11G9fCVM хотелось бы чуть подробнее раскрыть тему про STAR, которую я немножко упомянул.
Что это такое
STAR – акроним от Situation Task Action Result. Ситуация, задача, действие, результат. Фактически это просто формат простой структуры рассказа о каких-то своих достижениях (хотя для фейлов тоже подойдет)
Зачем это использовать
Собеседования – это всегда стресс. Мысли путаются, ладошки потеют, язык заплетается. И если вам в таком стрессовом состоянии надо рассказать о своих успехах, а у вас нет четкой структуры, то получится скорее всего не очень понятно и наглядно.
Вы будете перескакивать с темы на тему, со следствия на предпосылки, с результата на действие. Впечатление будет смазано, а тема не раскрыта понятным образом.
Отдельно стоит отметить, что лучше всего заготовить несколько таких рассказов о вашем успешном успехе и неудачной неудаче заранее. Структура — это хорошо, но репетиция рассказа тоже важна. Иначе можно заволноваться, и без репетиций начать мямлить даже по четкой формуле рассказа.
Еще к плюсам рассказа об успехах по STAR можно отнести то, что это демонстрирует, насколько вы комплексно понимаете задачу и подходите к её решению. То есть вы не просто делаете какое-то действие, которое вас попросили сделать, а понимаете и способны проанализировать изначальную проблему, да еще и способны оценить конкретный результат своих действий.
Пример
Ситуация
В одном из разделов на сайте периодически протухают ссылки на внешние ресурсы. Ссылок сотни, уследить за ними в разумные сроки невозможно. На это уйдут десятки человекочасов в месяц.
Задача
Минимизировать количество протухших ссылок и время их существования на сайте.
Действие
Написан бот, автопроверятель ссылок, который каждый день ходит по этим ссылкам, смотрит на коды ответов и оповещает контент-менеджеров на почту о возникновении проблем.
Результат
Количество протухших ссылок в разделе снизилось до нуля (в среднем). Время на ручную проверку сотен этих ссылок снизилось до нуля.
Итог
Заготовьте и отрепетируйте пару-тройку рассказов о себе по STAR. Времени это у вас много не займет, а лишним точно не будет. Вы и впечатление хорошее произведете, и сами будете довольны своим рассказом в столь стрессовой ситуации.
По мотивам вчерашнего выпуска Цинкового Прода про собеседования https://www.youtube.com/watch?v=ezt11G9fCVM хотелось бы чуть подробнее раскрыть тему про STAR, которую я немножко упомянул.
Что это такое
STAR – акроним от Situation Task Action Result. Ситуация, задача, действие, результат. Фактически это просто формат простой структуры рассказа о каких-то своих достижениях (хотя для фейлов тоже подойдет)
Зачем это использовать
Собеседования – это всегда стресс. Мысли путаются, ладошки потеют, язык заплетается. И если вам в таком стрессовом состоянии надо рассказать о своих успехах, а у вас нет четкой структуры, то получится скорее всего не очень понятно и наглядно.
Вы будете перескакивать с темы на тему, со следствия на предпосылки, с результата на действие. Впечатление будет смазано, а тема не раскрыта понятным образом.
Отдельно стоит отметить, что лучше всего заготовить несколько таких рассказов о вашем успешном успехе и неудачной неудаче заранее. Структура — это хорошо, но репетиция рассказа тоже важна. Иначе можно заволноваться, и без репетиций начать мямлить даже по четкой формуле рассказа.
Еще к плюсам рассказа об успехах по STAR можно отнести то, что это демонстрирует, насколько вы комплексно понимаете задачу и подходите к её решению. То есть вы не просто делаете какое-то действие, которое вас попросили сделать, а понимаете и способны проанализировать изначальную проблему, да еще и способны оценить конкретный результат своих действий.
Пример
Ситуация
В одном из разделов на сайте периодически протухают ссылки на внешние ресурсы. Ссылок сотни, уследить за ними в разумные сроки невозможно. На это уйдут десятки человекочасов в месяц.
Задача
Минимизировать количество протухших ссылок и время их существования на сайте.
Действие
Написан бот, автопроверятель ссылок, который каждый день ходит по этим ссылкам, смотрит на коды ответов и оповещает контент-менеджеров на почту о возникновении проблем.
Результат
Количество протухших ссылок в разделе снизилось до нуля (в среднем). Время на ручную проверку сотен этих ссылок снизилось до нуля.
Итог
Заготовьте и отрепетируйте пару-тройку рассказов о себе по STAR. Времени это у вас много не займет, а лишним точно не будет. Вы и впечатление хорошее произведете, и сами будете довольны своим рассказом в столь стрессовой ситуации.
YouTube
#114 Говорим про собеседования с Ильей Матвиенко, Александром Хайдаршиным и Евгением Антоновым
Ребята рассказали про свою боль, поделились мыслями. Также с фланга атаковал проблему Евгений Антонов, автор канала "Тимлид Очевидность"
00:00 Приветствие. Знакомимся с гостями.
2:57 О боли тимлида в собеседованиях, инфоцыганстве и буткемп проектах
12:46…
00:00 Приветствие. Знакомимся с гостями.
2:57 О боли тимлида в собеседованиях, инфоцыганстве и буткемп проектах
12:46…
Подкаст Кода Кода
В начале апреля был гостем в довольно новом подкасте Кода Кода. Ссылка на подкаст на разных платформах https://podcast.ru/1551786898
Сегодня вышел этот выпуск. Говорили об удаленной работе и распределенных командах. К разговору я подготовился, так что надеюсь вам будет интересно и/или полезно. Ссылка на выпуск https://music.yandex.ru/album/13732143/track/84350254
В рамках этой подготовки я написал структурированный текст, который опубликую на хабре чуть позже.
Хочу добавить, что подкаст молодой, но лично мне он довольно интересен. Там нет хардкорных тем, но затрагивается глобально всё, что регулярно окружает нас в жизни и работе в ИТ.
Добавил себе в список подкастов для регулярного прослушивания.
Отдельное спасибо автору подкаста за то, что смонтировал мой часовой бубнеж в получасовой внятный рассказ, при этом умудрившись ни капельки не потерять суть повествования.
В начале апреля был гостем в довольно новом подкасте Кода Кода. Ссылка на подкаст на разных платформах https://podcast.ru/1551786898
Сегодня вышел этот выпуск. Говорили об удаленной работе и распределенных командах. К разговору я подготовился, так что надеюсь вам будет интересно и/или полезно. Ссылка на выпуск https://music.yandex.ru/album/13732143/track/84350254
В рамках этой подготовки я написал структурированный текст, который опубликую на хабре чуть позже.
Хочу добавить, что подкаст молодой, но лично мне он довольно интересен. Там нет хардкорных тем, но затрагивается глобально всё, что регулярно окружает нас в жизни и работе в ИТ.
Добавил себе в список подкастов для регулярного прослушивания.
Отдельное спасибо автору подкаста за то, что смонтировал мой часовой бубнеж в получасовой внятный рассказ, при этом умудрившись ни капельки не потерять суть повествования.
Podcast.ru
КОДА КОДА – Podcast.ru
Подкаст о жизни в IT. Без обсуждения хардкорных технологий и успешного успеха в стартапах. Поговорим о том, что интересует программистов и менеджеров, но сложно обсудить с коллегами и начальством. Мы слушаем реальные истории айтишников и обсуждаем их. Ищем…