Sometimes you are the hammer and sometimes you are the nail
Недавно услышал в одном видео эту фразу и захотелось написать пост. Хоть сегодня и пятница, но это выходной, поэтому пост будет немного расплывчатый. Пост выходного дня, так сказать 🙂
Борьба
Я увлекаюсь борьбой, и то видео было о том, как автор канала, черный пояс по джиу-джитсу, боролся с сильно превосходящим по весу соперником и проигрывал ему несколько раз подряд.
Для авторитета и самооценки мастеров такого уровня это может быть довольно болезненно. Но автор не постеснялся это всё смонтировать и выложить в широкий публичный доступ. Еще и снабдил комментариями, где рассказал, в чем именно он сплоховал и почему.
Смотреть было интересно, полезно, и уважение к мастерству этого человека не стало меньше, ведь я видел на его канале и кучу побед.
Мультики
Недавно смотрел с женой мультфильм (вот она писала про него пост у себя в канале https://www.tg-me.com/katyuha_smotrit/141), он был про девочку, которую преследовали неудачи.
У неё постоянно всё валилось из рук, шло не по плану и казалось, что дело совсем плохо. Но потом оказалось, что сталкиваясь с неудачами, её постоянно везучие знакомые опускали руки, в то время как она продолжала бороться, пока не получится задуманное.
В итоге вышло так, что её закалили неудачи и умение их спокойно принимать, делать выводы и пробовать снова.
Жизнь и работа
По сути все примеры выше, как и ключевая фраза про то, что какой бы ты ни был везунчик, сильный, смелый, ловкий, умелый, ты обязательно не пройдешь мимо неудач, срыва планов, своих же косяков и т.д. И то, как ты умеешь признавать свои ошибки, делать из них выводы и предпринимать новые попытки – очень важно.
Взять, допустим, смену работы. В ИТ же привыкли, что в среднем хороший специалист может найти работу довольно быстро. Но у меня есть один товарищ, который хотел не абы какую работу. Поэтому он готовился сильно заранее, когда начались собеседования, он получил 48 или 49 отказов, но руки не опустил и после полусотни неудач всё же добился, чего хотел.
Про джунов даже говорить сейчас грустно. Люди по полгода, год, два могут стучаться во все двери, лишь бы им щелочку приотворили, чтобы они могли просочиться. И просачиваются же) Правда, таких очень мало.
Или, например, есть у нас в комьюнити люди, которые в целом довольно успешные, но стоит им столкнуться с трудностями и неудачами, как видно, кто впадает в уныние и апатию, а кто продолжает трудиться и добиваться результата.
А уж с теми, кто может публично признаться, что он где-то в чем-то ошибся, да еще и дать другим опыт, как не наступать на грабли, вообще очень круто общаться и работать.
Итог
Ошибки и неудачи случаются у всех. Это нормально.
Желаю вам уметь их признавать, делать из них выводы и находить в себе силы, чтобы не опускать руки, всё же добиваться того, чего бы вы сами хотели (а не того, что вам навязывает окружение).
Недавно услышал в одном видео эту фразу и захотелось написать пост. Хоть сегодня и пятница, но это выходной, поэтому пост будет немного расплывчатый. Пост выходного дня, так сказать 🙂
Борьба
Я увлекаюсь борьбой, и то видео было о том, как автор канала, черный пояс по джиу-джитсу, боролся с сильно превосходящим по весу соперником и проигрывал ему несколько раз подряд.
Для авторитета и самооценки мастеров такого уровня это может быть довольно болезненно. Но автор не постеснялся это всё смонтировать и выложить в широкий публичный доступ. Еще и снабдил комментариями, где рассказал, в чем именно он сплоховал и почему.
Смотреть было интересно, полезно, и уважение к мастерству этого человека не стало меньше, ведь я видел на его канале и кучу побед.
Мультики
Недавно смотрел с женой мультфильм (вот она писала про него пост у себя в канале https://www.tg-me.com/katyuha_smotrit/141), он был про девочку, которую преследовали неудачи.
У неё постоянно всё валилось из рук, шло не по плану и казалось, что дело совсем плохо. Но потом оказалось, что сталкиваясь с неудачами, её постоянно везучие знакомые опускали руки, в то время как она продолжала бороться, пока не получится задуманное.
В итоге вышло так, что её закалили неудачи и умение их спокойно принимать, делать выводы и пробовать снова.
Жизнь и работа
По сути все примеры выше, как и ключевая фраза про то, что какой бы ты ни был везунчик, сильный, смелый, ловкий, умелый, ты обязательно не пройдешь мимо неудач, срыва планов, своих же косяков и т.д. И то, как ты умеешь признавать свои ошибки, делать из них выводы и предпринимать новые попытки – очень важно.
Взять, допустим, смену работы. В ИТ же привыкли, что в среднем хороший специалист может найти работу довольно быстро. Но у меня есть один товарищ, который хотел не абы какую работу. Поэтому он готовился сильно заранее, когда начались собеседования, он получил 48 или 49 отказов, но руки не опустил и после полусотни неудач всё же добился, чего хотел.
Про джунов даже говорить сейчас грустно. Люди по полгода, год, два могут стучаться во все двери, лишь бы им щелочку приотворили, чтобы они могли просочиться. И просачиваются же) Правда, таких очень мало.
Или, например, есть у нас в комьюнити люди, которые в целом довольно успешные, но стоит им столкнуться с трудностями и неудачами, как видно, кто впадает в уныние и апатию, а кто продолжает трудиться и добиваться результата.
А уж с теми, кто может публично признаться, что он где-то в чем-то ошибся, да еще и дать другим опыт, как не наступать на грабли, вообще очень круто общаться и работать.
Итог
Ошибки и неудачи случаются у всех. Это нормально.
Желаю вам уметь их признавать, делать из них выводы и находить в себе силы, чтобы не опускать руки, всё же добиваться того, чего бы вы сами хотели (а не того, что вам навязывает окружение).
👍55❤24
Надо что-то менять
Сегодня у нас вышел выпуск про смену карьеры внутри ИТ.
Нам очень хотелось рассмотреть не классические варианты типа «был разработчик, стал тимлид», или «был тестировщик, стал разработчик», а что-то более необычное. Например, когда после СТО и тимлидства становятся менеджером по маркетингу 🙂
В общем что-то такое, что мало связано друг с другом, или то, где требуются нестандартные усилия для перехода.
Ну и в целом хотелось послушать такие истории, вдохновиться самим и вдохновить ими наших слушателей. Многое возможно, главное не забираться в одно болото и там вечно сидеть, а понимать, что ты делаешь, что тебе нравится делать, что нужно для того, чтобы изменить свою карьеру, знать, что такие изменения точно возможны, а местами и необходимы.
Радикальная смена карьерного трека - это большой труд и стресс. Мы постараемся всё это обсудить и понять, как лучше подготовиться к такому переходу, как его осуществлять и как работать дальше.
Буду очень благодарен, если вы в комментариях напишете о своих карьерных приключениях. Очень люблю такие истории 🙂
Ну а для поклонников ИТ-подкастов я могу спойлернуть, что одна из гостей нашего сегодняшнего выпуска - соведущая очень уважаемой мною Подлодки.
Приятного прослушивания!
Ссылка на пост с описанием и картиночками тут
Сегодня у нас вышел выпуск про смену карьеры внутри ИТ.
Нам очень хотелось рассмотреть не классические варианты типа «был разработчик, стал тимлид», или «был тестировщик, стал разработчик», а что-то более необычное. Например, когда после СТО и тимлидства становятся менеджером по маркетингу 🙂
В общем что-то такое, что мало связано друг с другом, или то, где требуются нестандартные усилия для перехода.
Ну и в целом хотелось послушать такие истории, вдохновиться самим и вдохновить ими наших слушателей. Многое возможно, главное не забираться в одно болото и там вечно сидеть, а понимать, что ты делаешь, что тебе нравится делать, что нужно для того, чтобы изменить свою карьеру, знать, что такие изменения точно возможны, а местами и необходимы.
Радикальная смена карьерного трека - это большой труд и стресс. Мы постараемся всё это обсудить и понять, как лучше подготовиться к такому переходу, как его осуществлять и как работать дальше.
Буду очень благодарен, если вы в комментариях напишете о своих карьерных приключениях. Очень люблю такие истории 🙂
Ну а для поклонников ИТ-подкастов я могу спойлернуть, что одна из гостей нашего сегодняшнего выпуска - соведущая очень уважаемой мною Подлодки.
Приятного прослушивания!
Ссылка на пост с описанием и картиночками тут
👍11🔥4❤2🤡1
Нет ничего более постоянного, чем временное
Вроде бы это довольно известная житейская мудрость, но я посчитал, что не будет лишним напомнить об этом и вам, и самому себе.
В жизни
Бывает такое, что-то в быту немного поломается, и вместо того, чтобы потратить час на хорошую починку, тратишь 5 минут на костыльный хотфикс.
Сломалось что-то, ты изолентой подмотал, и вроде держится. Правда периодически разваливается и приходится перематывать. А еще теперь сильно дергать нельзя, а то точно распадется на молекулы. Да и перед гостями стыдно. В итоге так и живешь месяцами.
А еще бывает, что подмотал ты изолентой не просто так. И ведь часа у тебя этого лишнего не было, ты в театр опаздывал. А из театра уже уставший пришел. Когда чинить? А потом утром только позавтракал, уже на работу пора. После работы, понятное дело, отдохнуть надо, тут не до починок. Ну а на выходных то дела, то поваляться, то погулять, какое там ремонтировать? В итоге так в изоленте у тебя оно и мумифицировано навечно.
В работе
Абсолютно то же самое. Сначала либо поленились сразу сделать хорошо, либо надо было к дедлайну успеть. Накостыляли, а исправлять и некогда, ведь уже следующие дедлайны поджимают.
Что же делать?
Как минимум осознать то, что любой ваш временный костыль станет, скорее всего, постоянным, если сразу не сделать нормально.
А если уж костыльнули, то запишите это куда-то в список дел на будущее. И пусть это будет такой же важной задачей, как новая фича, или как поваляться на диване после работы. Иначе вы точно забудете, что надо исправлять, и просто полубессознательно смиритесь с неудобным костылем. И вместо того, чтобы решение подстраивать под себя, будете сами подстраиваться под неудачное решение.
А как же «продать» менеджерам техдолг
Часто такой вопрос поступает. В первую очередь, конечно, разговорами и объяснениями, почему так вышло, почему надо исправлять, чем плохо, если не исправить. Иногда этого хватает, если аргументы убедительны.
Но не всегда некоторые люди готовы понимать слова и аргументы. Порой их нужно познакомить с реально осуществившимся фактом, чтобы тогда, пусть и через «ой-ой-ой», дошло, что нельзя вечно закрывать глаза на проблему.
Был у меня один случай
Просто в качестве одного из многих примеров, когда аргументы не так убедительны, как факты.
Лет 10 назад приходилось админить локальную сеть из нескольких десятков компьютеров. Половина была бухгалтерскими машинами с кучей 1С-ных баз на кучу разных коммерческих предприятий.
Я на тот момент только устроился на работу и обнаружил, что даже антивирусов никаких у людей нет. Начал спрашивать, предлагать, на что быстро получил ответ, что денег нет, идите нафиг.
А тогда только начали набирать популярность вирусы-шифровальщики. И понятное дело, в один день куча 1С-ных баз зашифровались, и колом встали куча разных коммерческих организаций.
В итоге деньги сразу появились. Заплатили выкуп шифровальщикам и кое-как вернули базы, еще сверху навалили денег на антивирусы, дополнительные работы, настройки фаерволов и прочее.
Итог
Временное и не очень качественное решение с высокой вероятностью станет постоянным, и вам с этим придется жить. Надеюсь, что, осознавая это, вы сможете себя спасти от поспешных и «легких» неудачных действий.
Вроде бы это довольно известная житейская мудрость, но я посчитал, что не будет лишним напомнить об этом и вам, и самому себе.
В жизни
Бывает такое, что-то в быту немного поломается, и вместо того, чтобы потратить час на хорошую починку, тратишь 5 минут на костыльный хотфикс.
Сломалось что-то, ты изолентой подмотал, и вроде держится. Правда периодически разваливается и приходится перематывать. А еще теперь сильно дергать нельзя, а то точно распадется на молекулы. Да и перед гостями стыдно. В итоге так и живешь месяцами.
А еще бывает, что подмотал ты изолентой не просто так. И ведь часа у тебя этого лишнего не было, ты в театр опаздывал. А из театра уже уставший пришел. Когда чинить? А потом утром только позавтракал, уже на работу пора. После работы, понятное дело, отдохнуть надо, тут не до починок. Ну а на выходных то дела, то поваляться, то погулять, какое там ремонтировать? В итоге так в изоленте у тебя оно и мумифицировано навечно.
В работе
Абсолютно то же самое. Сначала либо поленились сразу сделать хорошо, либо надо было к дедлайну успеть. Накостыляли, а исправлять и некогда, ведь уже следующие дедлайны поджимают.
Что же делать?
Как минимум осознать то, что любой ваш временный костыль станет, скорее всего, постоянным, если сразу не сделать нормально.
А если уж костыльнули, то запишите это куда-то в список дел на будущее. И пусть это будет такой же важной задачей, как новая фича, или как поваляться на диване после работы. Иначе вы точно забудете, что надо исправлять, и просто полубессознательно смиритесь с неудобным костылем. И вместо того, чтобы решение подстраивать под себя, будете сами подстраиваться под неудачное решение.
А как же «продать» менеджерам техдолг
Часто такой вопрос поступает. В первую очередь, конечно, разговорами и объяснениями, почему так вышло, почему надо исправлять, чем плохо, если не исправить. Иногда этого хватает, если аргументы убедительны.
Но не всегда некоторые люди готовы понимать слова и аргументы. Порой их нужно познакомить с реально осуществившимся фактом, чтобы тогда, пусть и через «ой-ой-ой», дошло, что нельзя вечно закрывать глаза на проблему.
Был у меня один случай
Просто в качестве одного из многих примеров, когда аргументы не так убедительны, как факты.
Лет 10 назад приходилось админить локальную сеть из нескольких десятков компьютеров. Половина была бухгалтерскими машинами с кучей 1С-ных баз на кучу разных коммерческих предприятий.
Я на тот момент только устроился на работу и обнаружил, что даже антивирусов никаких у людей нет. Начал спрашивать, предлагать, на что быстро получил ответ, что денег нет, идите нафиг.
А тогда только начали набирать популярность вирусы-шифровальщики. И понятное дело, в один день куча 1С-ных баз зашифровались, и колом встали куча разных коммерческих организаций.
В итоге деньги сразу появились. Заплатили выкуп шифровальщикам и кое-как вернули базы, еще сверху навалили денег на антивирусы, дополнительные работы, настройки фаерволов и прочее.
Итог
Временное и не очень качественное решение с высокой вероятностью станет постоянным, и вам с этим придется жить. Надеюсь, что, осознавая это, вы сможете себя спасти от поспешных и «легких» неудачных действий.
👍42❤6
Как тимлиду собеседовать работодателя
Не так давно мне довелось поучаствовать в круглом столе на тему того, что тимлид должен уточнить у своего будущего работодателя, чтобы принять решение о трудоустройстве.
Я считаю эту тему очень важной и нужной. Причем и для самого тимлида, и для компании.
Если хорошо подготовиться, то можно довольно неплохо понять, насколько вы подходите друг другу. Можно избежать неприятных сюрпризов, когда вы устроились и думали, что будете делать одно, а от вас требуют другое. Можно обговорить свои интересы и сделать так, чтобы у работодателя не было каких-то неактуальных ложных ожиданий от вас.
Делюсь с вами ссылкой и надеюсь, что она вам когда-нибудь сможет помочь🤝
https://www.youtube.com/watch?v=p1wXMci7L2Q
Не так давно мне довелось поучаствовать в круглом столе на тему того, что тимлид должен уточнить у своего будущего работодателя, чтобы принять решение о трудоустройстве.
Я считаю эту тему очень важной и нужной. Причем и для самого тимлида, и для компании.
Если хорошо подготовиться, то можно довольно неплохо понять, насколько вы подходите друг другу. Можно избежать неприятных сюрпризов, когда вы устроились и думали, что будете делать одно, а от вас требуют другое. Можно обговорить свои интересы и сделать так, чтобы у работодателя не было каких-то неактуальных ложных ожиданий от вас.
Делюсь с вами ссылкой и надеюсь, что она вам когда-нибудь сможет помочь🤝
https://www.youtube.com/watch?v=p1wXMci7L2Q
YouTube
Круглый стол: Как тимлиду собеседовать работодателя — Чеклист / Е. Антонов, Т. Аква, Е. Кателла
Как тимлиду выбрать компанию?
При выборе компании существует много дополнительных критериев, помимо денег. Пусть и работаем мы за деньги, но при этом хочется трудиться в комфортной и адекватной обстановке.
Мы собираем брейншторм - как проводить скрининг…
При выборе компании существует много дополнительных критериев, помимо денег. Пусть и работаем мы за деньги, но при этом хочется трудиться в комфортной и адекватной обстановке.
Мы собираем брейншторм - как проводить скрининг…
👍27❤11
Восьмичасовой рабочий день
Думаю, многие из вас сталкивались с необходимостью трекать время, писать отчеты за каждые 8 часов рабочего дня, а то и за каждый час (да, такое тоже бывает). Хочется сегодня поговорить об эффективности рабочего дня именно в ИТ, где, как ни крути, а всё же труд интеллектуальный.
Я не претендую на высоту интеллектуального труда, но подчеркиваю, что это умственный труд, а не стояние на каком-нибудь конвейере и прикручивание ручек к холодильнику.
И уж ни в коем случае тут я не буду рассказывать какие ИТ-шники интеллектуальная элита, а работники «ручного» труда якобы ниже классом. Нет. Я ценю и уважаю любой труд, если человек его выполняет добросовестно. Равно как и испытываю антипатию к труду, делаемому «на отвали», без малейшего желания задуматься, что ты не только делаешь фигню, но, возможно, еще и вредишь.
Учет времени
Я уверен, что польза и вред от трекинга времени – это большая тема для отдельного поста. Сегодня просто остановимся на том, что порой он бывает.
Обычно он проявляется в форме «вы должны отчитаться, на какие задачи и сколько вы тратили рабочее время, но так, чтобы получилось 8 часов». Однажды я попал в ситуацию, где руководитель сказал всем сотрудникам, что «у нас нет огня в глазах» и настоял, чтобы писали отчет про каждый час рабочего дня. Закончилось это ничем, так же как и началось. Мы писали эти отчеты и сдавали около недели. Отчеты копились на столе руководителя и доподлинно неизвестно, читал ли он их. Потом в один из дней мы просто перестали их сдавать, а руководитель сделал вид, что ничего и не происходило. Смею предположить, что польза этих отчетов не была высока.
Так к чему я веду? К тому, что почти каждый, с кем я разговаривал про трекинг времени, отмечал, что это «тухлая математика», когда ты 4-6 полезных часов пытаешься растянуть на 8 и надеешься, что никто не спросит «почему так долго?».
4-6 часов
Я общался с очень многими программистами и менеджерами из совершенно разных компаний, от мелких региональных, до крупнейших техногигантов страны. Все отмечали, что количество продуктивных часов в их рабочем дне около 4-6. Да, программисты сидят за компьютером 8 часов, но если посчитать перекуры, чаепития, листание хабра, ютуба, твиттера и чатиков, то получится эти самые 4-6.
А если говорить о «потоке», в который может и правда попасть программист и фигачить часов 10, нафигачив при этом то, что не мог сделать последнюю неделю, то да, такое случается. Но это же разовый выброс, девиация. А те, кто испытывал это чудесное состояние, когда весь день с утра до ночи можешь кодить, а потом еще и на следующий так удается, знают, что эта продуктивность быстро заканчивается и начинается период упадка, когда с ватной головой целый день тупишь в монитор. А если среднее арифметическое вычислить из этих периодов подъема и упадка, то опять же получим те самые 4-6 часов на день.
К менеджерам относится то же самое. Только менеджер чуть более на виду и может чуть ли не все 8 часов присутствовать на встречах каждый день, развивая какую-то деятельность. Но опыт и мой, и многих тимлидов, и ПМов, с кем я про это говорил, приводит к той же идее, что продуктивных часов там 4-6, когда ты вовлечен, можешь эффективно думать, что-то предлагать, что-то контролировать. А в остальное время встреча таких менеджеров похожа на игру «Растения против зомби», где собрались с одной стороны овощи, с другой стороны зомби, и между ними происходит какой-то вялый замес.
Думаю, многие из вас сталкивались с необходимостью трекать время, писать отчеты за каждые 8 часов рабочего дня, а то и за каждый час (да, такое тоже бывает). Хочется сегодня поговорить об эффективности рабочего дня именно в ИТ, где, как ни крути, а всё же труд интеллектуальный.
Я не претендую на высоту интеллектуального труда, но подчеркиваю, что это умственный труд, а не стояние на каком-нибудь конвейере и прикручивание ручек к холодильнику.
И уж ни в коем случае тут я не буду рассказывать какие ИТ-шники интеллектуальная элита, а работники «ручного» труда якобы ниже классом. Нет. Я ценю и уважаю любой труд, если человек его выполняет добросовестно. Равно как и испытываю антипатию к труду, делаемому «на отвали», без малейшего желания задуматься, что ты не только делаешь фигню, но, возможно, еще и вредишь.
Учет времени
Я уверен, что польза и вред от трекинга времени – это большая тема для отдельного поста. Сегодня просто остановимся на том, что порой он бывает.
Обычно он проявляется в форме «вы должны отчитаться, на какие задачи и сколько вы тратили рабочее время, но так, чтобы получилось 8 часов». Однажды я попал в ситуацию, где руководитель сказал всем сотрудникам, что «у нас нет огня в глазах» и настоял, чтобы писали отчет про каждый час рабочего дня. Закончилось это ничем, так же как и началось. Мы писали эти отчеты и сдавали около недели. Отчеты копились на столе руководителя и доподлинно неизвестно, читал ли он их. Потом в один из дней мы просто перестали их сдавать, а руководитель сделал вид, что ничего и не происходило. Смею предположить, что польза этих отчетов не была высока.
Так к чему я веду? К тому, что почти каждый, с кем я разговаривал про трекинг времени, отмечал, что это «тухлая математика», когда ты 4-6 полезных часов пытаешься растянуть на 8 и надеешься, что никто не спросит «почему так долго?».
4-6 часов
Я общался с очень многими программистами и менеджерами из совершенно разных компаний, от мелких региональных, до крупнейших техногигантов страны. Все отмечали, что количество продуктивных часов в их рабочем дне около 4-6. Да, программисты сидят за компьютером 8 часов, но если посчитать перекуры, чаепития, листание хабра, ютуба, твиттера и чатиков, то получится эти самые 4-6.
А если говорить о «потоке», в который может и правда попасть программист и фигачить часов 10, нафигачив при этом то, что не мог сделать последнюю неделю, то да, такое случается. Но это же разовый выброс, девиация. А те, кто испытывал это чудесное состояние, когда весь день с утра до ночи можешь кодить, а потом еще и на следующий так удается, знают, что эта продуктивность быстро заканчивается и начинается период упадка, когда с ватной головой целый день тупишь в монитор. А если среднее арифметическое вычислить из этих периодов подъема и упадка, то опять же получим те самые 4-6 часов на день.
К менеджерам относится то же самое. Только менеджер чуть более на виду и может чуть ли не все 8 часов присутствовать на встречах каждый день, развивая какую-то деятельность. Но опыт и мой, и многих тимлидов, и ПМов, с кем я про это говорил, приводит к той же идее, что продуктивных часов там 4-6, когда ты вовлечен, можешь эффективно думать, что-то предлагать, что-то контролировать. А в остальное время встреча таких менеджеров похожа на игру «Растения против зомби», где собрались с одной стороны овощи, с другой стороны зомби, и между ними происходит какой-то вялый замес.
👍81🔥17💯9👌2
Как оптимизировать эти 4-6 часов?
Мы поговорили о том, что 8 часов нет, а есть 4-6. И раз мы так ощутимо ужались, хотелось бы что-то придумать, чтобы проводить это время с пользой.
Можно придумать много специфичных лайфхаков, но тогда не влезет в пост. Прошу вас поделиться своим опытом в комментариях.
А я хочу рассмотреть, на мой взгляд, очень важную мысль. В условиях ограниченного продуктивного времени один из главнейших врагов – переключение контекста. Если нам не дают (или мы сами себе не даем) спокойно и сосредоточенно поработать хотя бы полчаса-час, то все наши 4-6 часов за день превратятся в тыкву. Мы только в голову нужный контекст загружаем, как нас оттуда выдергивают, и приходится все заново вспоминать и восстанавливать. Картиночка про это https://uploads-ssl.webflow.com/60464d9e47cd9412d1663cc2/6077046573bfd05d8c7ed605_heeris.png
Примеры таких отвлечений:
⁃ Любишь поболтать в чатике, поэтому каждые 5-10 минут ходишь туда что-то написать.
⁃ Менеджер / тот, кого ты менеджеришь, постоянно дергает какими-то вопросами, на которые ответить может сам, или которые могут подождать.
⁃ Коллега, который зовет на перекур или попить чай каждые семь с половиной минут.
⁃ Громкие товарищи в опенспейсе, которые начинают прям там же с кем-то созваниваться или «решать вопросики» громогласным тоном типичного бати, которому позвонили по межгороду.
В итоге замечал за собой я, и мои коллеги, и товарищи по индустрии, что если ты вот в таком режиме поработаешь, то запросто можешь сказать «я за день толком ничего и не сделал». И это будет правдой.
Мне видится это печальной историей, когда мы за много денег компании можем не делать ничего полезного целыми днями просто потому, что или сами себя в такую позицию загнали, или менеджмент такие условия создает, или мы сами – менеджеры, создающие условия для неэффективности команды и растраты денег.
Итог
На мой, и не только мой, взгляд 8 часов продуктивного умственного труда – это миф.
Чтобы не тратить поистине важные часы впустую, постарайтесь поменьше переключать контекст сами и объясните тем, кто вас дергает, что это нифига не полезно никому. И вы свою работу хорошо не сделаете, и они от вас ничего в срок не получат.
Ну и поделитесь, пожалуйста, своими лайфхаками, как вы выжимаете пользу из своего рабочего дня.
Мы поговорили о том, что 8 часов нет, а есть 4-6. И раз мы так ощутимо ужались, хотелось бы что-то придумать, чтобы проводить это время с пользой.
Можно придумать много специфичных лайфхаков, но тогда не влезет в пост. Прошу вас поделиться своим опытом в комментариях.
А я хочу рассмотреть, на мой взгляд, очень важную мысль. В условиях ограниченного продуктивного времени один из главнейших врагов – переключение контекста. Если нам не дают (или мы сами себе не даем) спокойно и сосредоточенно поработать хотя бы полчаса-час, то все наши 4-6 часов за день превратятся в тыкву. Мы только в голову нужный контекст загружаем, как нас оттуда выдергивают, и приходится все заново вспоминать и восстанавливать. Картиночка про это https://uploads-ssl.webflow.com/60464d9e47cd9412d1663cc2/6077046573bfd05d8c7ed605_heeris.png
Примеры таких отвлечений:
⁃ Любишь поболтать в чатике, поэтому каждые 5-10 минут ходишь туда что-то написать.
⁃ Менеджер / тот, кого ты менеджеришь, постоянно дергает какими-то вопросами, на которые ответить может сам, или которые могут подождать.
⁃ Коллега, который зовет на перекур или попить чай каждые семь с половиной минут.
⁃ Громкие товарищи в опенспейсе, которые начинают прям там же с кем-то созваниваться или «решать вопросики» громогласным тоном типичного бати, которому позвонили по межгороду.
В итоге замечал за собой я, и мои коллеги, и товарищи по индустрии, что если ты вот в таком режиме поработаешь, то запросто можешь сказать «я за день толком ничего и не сделал». И это будет правдой.
Мне видится это печальной историей, когда мы за много денег компании можем не делать ничего полезного целыми днями просто потому, что или сами себя в такую позицию загнали, или менеджмент такие условия создает, или мы сами – менеджеры, создающие условия для неэффективности команды и растраты денег.
Итог
На мой, и не только мой, взгляд 8 часов продуктивного умственного труда – это миф.
Чтобы не тратить поистине важные часы впустую, постарайтесь поменьше переключать контекст сами и объясните тем, кто вас дергает, что это нифига не полезно никому. И вы свою работу хорошо не сделаете, и они от вас ничего в срок не получат.
Ну и поделитесь, пожалуйста, своими лайфхаками, как вы выжимаете пользу из своего рабочего дня.
👍63🔥11👨💻1
Developer Experience… Как много в этом слове.
Должен признаться, что поначалу я думал, что DX это чисто про то, какая у тебя IDE, и как ты у себя рабочее окружение настроил: в какой цвет консольку покрасил, как между окошками переключаешься, какой почтовый клиент используешь.
Однако по мере обсуждения с Виктором и гостями, я понял, что DX это практически всё, что окружает нас в нашей работе: устройства, софт, процессы, оргструктура разных команд, платформенная разработка и т.д.
Заодно обсудили, что для некоторых людей какие-то части DX могут быть важными, нужными и интересными, а для других вовсе нет.
Это одна из немногих записей, после которой я стал ощутимо иначе рассматривать тему выпуска 🙂
Надеюсь вы тоже сможете для себя что-то новое и интересное почерпнуть.
Спасибо нашим гостям, которые помогли нам разобраться: Феде Борщёву, Илье Сауленко и Мише Кабищеву.
Приятного прослушивания!
Ссылка на пост с описанием и картиночками тут
ВНИМАНИЕ КОНКУРС!
Так как этот выпуск последний в сезоне, то мы и наш спонсор @ozon_tech хотели бы закончить его на позитивной ноте.
Мы придумали небольшой конкурс, который подразумевает ПОДАРКИ 🙂
Ждем участников!
Ссылка на конкурс тут
Должен признаться, что поначалу я думал, что DX это чисто про то, какая у тебя IDE, и как ты у себя рабочее окружение настроил: в какой цвет консольку покрасил, как между окошками переключаешься, какой почтовый клиент используешь.
Однако по мере обсуждения с Виктором и гостями, я понял, что DX это практически всё, что окружает нас в нашей работе: устройства, софт, процессы, оргструктура разных команд, платформенная разработка и т.д.
Заодно обсудили, что для некоторых людей какие-то части DX могут быть важными, нужными и интересными, а для других вовсе нет.
Это одна из немногих записей, после которой я стал ощутимо иначе рассматривать тему выпуска 🙂
Надеюсь вы тоже сможете для себя что-то новое и интересное почерпнуть.
Спасибо нашим гостям, которые помогли нам разобраться: Феде Борщёву, Илье Сауленко и Мише Кабищеву.
Приятного прослушивания!
Ссылка на пост с описанием и картиночками тут
ВНИМАНИЕ КОНКУРС!
Так как этот выпуск последний в сезоне, то мы и наш спонсор @ozon_tech хотели бы закончить его на позитивной ноте.
Мы придумали небольшой конкурс, который подразумевает ПОДАРКИ 🙂
Ждем участников!
Ссылка на конкурс тут
👍8🔥4❤2❤🔥1
Улучшая можно и ухудшить
Сегодня хочется поговорить про несколько контринтуитивную штуку. В некоторых случаях желание где-то что-то оптимизировать приводит не только к улучшению, но и к ухудшению.
Надо оптимизировать, от этого становится лучше
Совершенно логичная и понятная мысль: надо искать то, что можно улучшить и улучшать это.
Есть у вас какой-то ручной труд, вдобавок сопровождаемый человеческими ошибками? Вот кандидат на автоматизацию. Станет быстрее и качественнее.
Есть неэффективный инструмент, с которым и работа медленно идет, и людей на рынке труда мало? Вот еще кандидат на оптимизацию, замену, стандартизацию.
Конечно, надо искать в процессах, инструментах, командах, управлении места для улучшения и работать над ними.
Не надо оптимизировать, от этого становится хуже
Но ведь бывают и другие случаи, когда оптимизации во вред могут пойти.
Вот допустим, есть у вас команда, где есть менеджер, который вам требования генерит, разработчики и тестировщики.
Вы придумали, как ускорить работу менеджера. Менеджер стал генерить кучу каких-то полезных идей и гипотез, начал наваливать это на разработчиков. Разработчики стали тонуть в потоке задач, пытаясь за всё сразу взяться и поскорее сделать. В итоге везде пооткусывали, внимание распылили, качество в спешке ухудшили, а довозить что-то работающее до продакшена стали еще медленнее, чем раньше.
Или ускорили разработчиков, они море тасочек на тестировщиков вылили, а те либо не глядя выпускают в прод (что ухудшает качество), либо добросовестно тестируют, и не быстрее, чем раньше (ведь их пропускная способность осталась такая же), подливают это дело на прод. В итоге либо ничего не изменилось, либо качество ухудшили.
Что именно надо оптимизировать?
Примеры выше – классические примеры локальных оптимизаций. Эта проблема идет из того, что при улучшении мы смотрим на какую-то конкретную часть, забывая о том, что конечный продукт выпускает вся система. Следовательно, улучшения нам нужны такие, которые будут влиять на всю эту систему в положительном ключе.
Оптимизировать нам в первую очередь нужно не то, что легче оптимизировать, а то, что во всей цепочке производства продукта является самым слабым звеном, узким бутылочным горлышком. Тогда можно существенно увеличить пропускную систему целиком, потому что вся система работает со скоростью самого медленного звена.
Т.е. в примере выше нам надо было проанализировать данную команду и не решать, где можно сейчас улучшить, а понять сначала, чье направление медленнее всех работу выполняет. И потом уже улучшения придумывать для него конкретно.
Итог
Могу порекомендовать почитать пару книг, которые затрагивают теорию ограничений систем, и прикинуть это на свои дела, компанию, проекты.
Элияху Голдратт «Цель. Процесс непрерывного совершенствования»
Джин Ким, Джордж Спаффорд, Кевин Бер «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему»
Старайтесь оптимизировать в первую очередь самые слабые звенья, а не то, что проще всего оптимизировать. Иначе и пользы особой не принесете, и даже вред можно причинить.
Сегодня хочется поговорить про несколько контринтуитивную штуку. В некоторых случаях желание где-то что-то оптимизировать приводит не только к улучшению, но и к ухудшению.
Надо оптимизировать, от этого становится лучше
Совершенно логичная и понятная мысль: надо искать то, что можно улучшить и улучшать это.
Есть у вас какой-то ручной труд, вдобавок сопровождаемый человеческими ошибками? Вот кандидат на автоматизацию. Станет быстрее и качественнее.
Есть неэффективный инструмент, с которым и работа медленно идет, и людей на рынке труда мало? Вот еще кандидат на оптимизацию, замену, стандартизацию.
Конечно, надо искать в процессах, инструментах, командах, управлении места для улучшения и работать над ними.
Не надо оптимизировать, от этого становится хуже
Но ведь бывают и другие случаи, когда оптимизации во вред могут пойти.
Вот допустим, есть у вас команда, где есть менеджер, который вам требования генерит, разработчики и тестировщики.
Вы придумали, как ускорить работу менеджера. Менеджер стал генерить кучу каких-то полезных идей и гипотез, начал наваливать это на разработчиков. Разработчики стали тонуть в потоке задач, пытаясь за всё сразу взяться и поскорее сделать. В итоге везде пооткусывали, внимание распылили, качество в спешке ухудшили, а довозить что-то работающее до продакшена стали еще медленнее, чем раньше.
Или ускорили разработчиков, они море тасочек на тестировщиков вылили, а те либо не глядя выпускают в прод (что ухудшает качество), либо добросовестно тестируют, и не быстрее, чем раньше (ведь их пропускная способность осталась такая же), подливают это дело на прод. В итоге либо ничего не изменилось, либо качество ухудшили.
Что именно надо оптимизировать?
Примеры выше – классические примеры локальных оптимизаций. Эта проблема идет из того, что при улучшении мы смотрим на какую-то конкретную часть, забывая о том, что конечный продукт выпускает вся система. Следовательно, улучшения нам нужны такие, которые будут влиять на всю эту систему в положительном ключе.
Оптимизировать нам в первую очередь нужно не то, что легче оптимизировать, а то, что во всей цепочке производства продукта является самым слабым звеном, узким бутылочным горлышком. Тогда можно существенно увеличить пропускную систему целиком, потому что вся система работает со скоростью самого медленного звена.
Т.е. в примере выше нам надо было проанализировать данную команду и не решать, где можно сейчас улучшить, а понять сначала, чье направление медленнее всех работу выполняет. И потом уже улучшения придумывать для него конкретно.
Итог
Могу порекомендовать почитать пару книг, которые затрагивают теорию ограничений систем, и прикинуть это на свои дела, компанию, проекты.
Элияху Голдратт «Цель. Процесс непрерывного совершенствования»
Джин Ким, Джордж Спаффорд, Кевин Бер «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему»
Старайтесь оптимизировать в первую очередь самые слабые звенья, а не то, что проще всего оптимизировать. Иначе и пользы особой не принесете, и даже вред можно причинить.
👍23🔥6❤4
Можно ли руководить тем, не знаю чем?
Периодически сталкиваюсь с вопросами о том, можно ли руководить в той сфере, в которой ты особенно не соображаешь. Ну, например, умеешь ты заниматься маркетингом, а руководить пришел разработчиками.
Я считаю, что можно. Но есть нюансы.
Отдельно напомню, что у меня был пост про менеджеров с техническим бэкграундом https://www.tg-me.com/general_it_talks/111
Успех вопреки
Думаю, что многие из нас сталкивались с руководителями, которые в вашей конкретной сфере либо не понимали, либо понимали очень мало. Я точно сталкивался. И я видел, как сталкиваются мои друзья, знакомые, товарищи по индустрии. И в ряде случаев у таких команд был успех. Однако успех этот был не благодаря подобным руководителям, а вопреки.
В чем тут может быть проблема? Руководитель не понимает специфики, не понимает аргументов за и против при принятии каких-то решений, а просто думает, что разработка – это какая-то магия. И вообще «я вот слышал, что в Яндексе сделали за неделю проект, у которого в названии слово, похожее на ваше слово, так что давайте-ка и вы за недельку уложитесь».
В целом это еще нормально, если человек не понимает, но хочет и пытается разобраться. Тут хорошая команда может помочь, доучить, объяснить. А бывают такие, кто не понимают и понимать не хотят. А если на это наслаивается микроменеджмент, то это вообще караул. То есть человек и не понимает вообще сути происходящего, и по отдельным словам, которые разобрал во время обсуждения, скидывает первые попавшиеся ссылки из гугла, настаивая на том, чтобы команда сделала именно так.
Вот в таком случае данный товарищ только мешает, а команда демотивируется. Дело не будет сделано хорошо и вовремя, только если команда не самоорганизуется и не сделает всё чисто своими силами. В данном случае тогда встает вопрос: а зачем вообще такой руководитель-дармоед нужен?
Вот вам анекдот:
– Пап, а что такое некомпетентность и безразличие?
– Я не знаю и мне плевать.
Успех благодаря
А бывают такие руководители, которые, даже не разбираясь в предмете, будут делать всё, чтобы их команда достигала успеха. Ведь для этого руководитель и нужен.
Такой менеджер встанет в первую линию обороны своей команды от буйства изменяющихся требований заказчика, постоянных дисфункций процессов внутри команды, проблемных коммуникаций со смежниками, и т.д.
Подумает о том, как команду развивать, помогать учиться, мотивировать, удерживать, дать экспертам возможность и свои навыки применять по полной (а не сидеть на семи созвонах за день), и с другими товарищами делиться знаниями, облегчая ротацию кадров в случае чего.
Ну и сам такой руководитель не будет брезговать разобраться (хотя бы по верхам) в том, чем занимается команда, чтобы уметь с ней разговаривать на одном языке.
Итог
На мой взгляд, можно быть руководителем в том, в чем ты не очень-то разбираешься. Но для чайка-менеджеров это будет сложно. Ну или для них будет легко, а для их команды сложно.
Не будьте, как батя из анекдота 🙂
Периодически сталкиваюсь с вопросами о том, можно ли руководить в той сфере, в которой ты особенно не соображаешь. Ну, например, умеешь ты заниматься маркетингом, а руководить пришел разработчиками.
Я считаю, что можно. Но есть нюансы.
Отдельно напомню, что у меня был пост про менеджеров с техническим бэкграундом https://www.tg-me.com/general_it_talks/111
Успех вопреки
Думаю, что многие из нас сталкивались с руководителями, которые в вашей конкретной сфере либо не понимали, либо понимали очень мало. Я точно сталкивался. И я видел, как сталкиваются мои друзья, знакомые, товарищи по индустрии. И в ряде случаев у таких команд был успех. Однако успех этот был не благодаря подобным руководителям, а вопреки.
В чем тут может быть проблема? Руководитель не понимает специфики, не понимает аргументов за и против при принятии каких-то решений, а просто думает, что разработка – это какая-то магия. И вообще «я вот слышал, что в Яндексе сделали за неделю проект, у которого в названии слово, похожее на ваше слово, так что давайте-ка и вы за недельку уложитесь».
В целом это еще нормально, если человек не понимает, но хочет и пытается разобраться. Тут хорошая команда может помочь, доучить, объяснить. А бывают такие, кто не понимают и понимать не хотят. А если на это наслаивается микроменеджмент, то это вообще караул. То есть человек и не понимает вообще сути происходящего, и по отдельным словам, которые разобрал во время обсуждения, скидывает первые попавшиеся ссылки из гугла, настаивая на том, чтобы команда сделала именно так.
Вот в таком случае данный товарищ только мешает, а команда демотивируется. Дело не будет сделано хорошо и вовремя, только если команда не самоорганизуется и не сделает всё чисто своими силами. В данном случае тогда встает вопрос: а зачем вообще такой руководитель-дармоед нужен?
Вот вам анекдот:
– Пап, а что такое некомпетентность и безразличие?
– Я не знаю и мне плевать.
Успех благодаря
А бывают такие руководители, которые, даже не разбираясь в предмете, будут делать всё, чтобы их команда достигала успеха. Ведь для этого руководитель и нужен.
Такой менеджер встанет в первую линию обороны своей команды от буйства изменяющихся требований заказчика, постоянных дисфункций процессов внутри команды, проблемных коммуникаций со смежниками, и т.д.
Подумает о том, как команду развивать, помогать учиться, мотивировать, удерживать, дать экспертам возможность и свои навыки применять по полной (а не сидеть на семи созвонах за день), и с другими товарищами делиться знаниями, облегчая ротацию кадров в случае чего.
Ну и сам такой руководитель не будет брезговать разобраться (хотя бы по верхам) в том, чем занимается команда, чтобы уметь с ней разговаривать на одном языке.
Итог
На мой взгляд, можно быть руководителем в том, в чем ты не очень-то разбираешься. Но для чайка-менеджеров это будет сложно. Ну или для них будет легко, а для их команды сложно.
Не будьте, как батя из анекдота 🙂
👍29❤7🥰4🔥1
Посиделки на DevOne'е
Не так давно был в гостях у подкаста DevOne.
Ребята хотели записать выпуск про личный бренд, но никаких тайных секретов продвижения личного бренда, на мой взгляд, я там не раскрыл. Хотя и тут в канале никаких тайных секретов не раскрываю🙂 Сплошь очевидность, порядочность и труд.
Да и вообще не считаю, что он у меня какой-то особенный имеется.
Если прям очень хочется угореть по личному бренду, то я бы рекомендовал послушать доклады Баруха Садогурского на эту тему в Подлодке и на коференции Mobius.
Однако считаю, что выпуск получился не только лайтовым приятным разговором, но и может быть полезен тем, кто планирует начать вести какую-то публичную деятельность: подкасты, каналы, блоги, доклады и тому подобное. Планирует, но не знает КАК начать, а еще плохо представляет ЗАЧЕМ это делать.
Отдельное уважение хочу выразить ребятам из DevOne подкаста за хорошую профессиональную подготовку (на любых уровнях, от софта до юридических аспектов) к записи и комфортное общение. Мне прям очень понравилось👍
Ссылка на выпуск https://devone.mave.digital/ep-11
Не так давно был в гостях у подкаста DevOne.
Ребята хотели записать выпуск про личный бренд, но никаких тайных секретов продвижения личного бренда, на мой взгляд, я там не раскрыл. Хотя и тут в канале никаких тайных секретов не раскрываю🙂 Сплошь очевидность, порядочность и труд.
Да и вообще не считаю, что он у меня какой-то особенный имеется.
Если прям очень хочется угореть по личному бренду, то я бы рекомендовал послушать доклады Баруха Садогурского на эту тему в Подлодке и на коференции Mobius.
Однако считаю, что выпуск получился не только лайтовым приятным разговором, но и может быть полезен тем, кто планирует начать вести какую-то публичную деятельность: подкасты, каналы, блоги, доклады и тому подобное. Планирует, но не знает КАК начать, а еще плохо представляет ЗАЧЕМ это делать.
Отдельное уважение хочу выразить ребятам из DevOne подкаста за хорошую профессиональную подготовку (на любых уровнях, от софта до юридических аспектов) к записи и комфортное общение. Мне прям очень понравилось👍
Ссылка на выпуск https://devone.mave.digital/ep-11
10 выпуск 1 сезона
#10 — Немного о личном (бренде) — Подкаст «DevOne»
В новом выпуске DevOne мы поговорили с Женей Антоновым — айтишником с 15-летним стажем, автором телеграм-канала «Тимлид-очевидность» и соведущим подкаста «Кода кода». Обсудили персональный бренд, его влияние на карьерный рост, саморазвитие и человека
👍8❤6🔥2
Играющий тренер
Прошлый пост вызвал активный отклик. Я почувствовал, что сегодня надо зайти с другой стороны. В тимлидском комьюнити эта боль очень даже существует.
Кто это
Довольно распространенная вакансия, где руководителя разработки хотят с глубокими экспертными знаниями. Ну, кажется, что всё нормально, и ничего сильно подозрительного нет.
А потом читаешь текст вакансии и там говорится, что подобный тимлид должен:
⁃ проектировать и реализовывать сложные архитектурные решения;
⁃ заниматься наймом команды;
⁃ заниматься людьми, их обучением, ростом, мотивацией;
⁃ заниматься рабочими процессами;
⁃ заниматься проектным менеджментом.
Ну то есть примерно быть разработчиком, тестировщиком, админом/девопсом, эйчаром и ПМом в одном лице.
Это то, что прямо сразу в голову приходит. Напишите в комментариях, чем еще «должен» заниматься играющий тренер.
80 на 80
Отсюда появляется золотое правило для тимлидов подобного рода. В вакансии пишут, что они 80% времени должны писать код, но мы-то понимаем, что менеджерских активностей тут еще на 80%. А уж как вы эти 160% уложите в рабочие дни, да так, чтобы качество у каждого вида деятельности не страдало – это ваши заботы.
Зато вам будут платить аж на 20-25% больше, чем какому-нибудь сеньору, который только задачи из to do забирает в in progress, пишет код и в done их двигает. При этом не теряя своих хард скиллов, свободно конвертируемых в деньги на рынке труда любой страны и любой компании.
Здоровый тимлид
В реальности я не спорю, что лучше тимлиду иметь хорошие хард скиллы, чем не иметь. Но на всех стульях сразу не посидишь. Поэтому стул надо выбирать исходя из ситуации.
Если у вас большая команда, расхлябанные рабочие процессы и проблемы с коммуникациями между смежными отделами, ну и нанимайте такого тимлида, который это пофиксит, а не будет сидеть 80% времени просто код педалить.
Если у вас 1-2-3 землекопа и всё уже отлажено в целом, то пусть приходит и правда какую-то серьезную часть времени код пилит, попутно подтюнивая эволюционирующие рабочие процессы, направляя команду и проект к светлому будущему.
Сознательный тимлид
А еще хочется затронуть тему сознательности у тимлидов. У каждого своя мотивация и у каждого свой интерес. Кому-то ближе работа с людьми, кому-то с процессами, а кто-то не хочет совсем уж отпускать код. И вот каждый должен хорошенько подумать о том, что он хочет, что ему предлагает его текущая или потенциальная позиция, сделать соответствующие выводы, насколько ему это подходит.
В этом плане мне очень нравится пример Антона Околелова из подкаста Цинковый прод. Он как-то писал, что ему не хочется расставаться с кодом, но и тимлидить нравится. Поэтому он сознательно идет тимлидом в небольшие команды (2-3 человека), чтобы в комфортном для себя режиме на двух стульях усиживать без вреда для дела.
Итог
Думайте что вам ближе, ищите что по душе.
Предлагают вакансию играющего тренера – хорошенько анализируйте, насколько она адекватна, прежде чем соглашаться.
Прошлый пост вызвал активный отклик. Я почувствовал, что сегодня надо зайти с другой стороны. В тимлидском комьюнити эта боль очень даже существует.
Кто это
Довольно распространенная вакансия, где руководителя разработки хотят с глубокими экспертными знаниями. Ну, кажется, что всё нормально, и ничего сильно подозрительного нет.
А потом читаешь текст вакансии и там говорится, что подобный тимлид должен:
⁃ проектировать и реализовывать сложные архитектурные решения;
⁃ заниматься наймом команды;
⁃ заниматься людьми, их обучением, ростом, мотивацией;
⁃ заниматься рабочими процессами;
⁃ заниматься проектным менеджментом.
Ну то есть примерно быть разработчиком, тестировщиком, админом/девопсом, эйчаром и ПМом в одном лице.
Это то, что прямо сразу в голову приходит. Напишите в комментариях, чем еще «должен» заниматься играющий тренер.
80 на 80
Отсюда появляется золотое правило для тимлидов подобного рода. В вакансии пишут, что они 80% времени должны писать код, но мы-то понимаем, что менеджерских активностей тут еще на 80%. А уж как вы эти 160% уложите в рабочие дни, да так, чтобы качество у каждого вида деятельности не страдало – это ваши заботы.
Зато вам будут платить аж на 20-25% больше, чем какому-нибудь сеньору, который только задачи из to do забирает в in progress, пишет код и в done их двигает. При этом не теряя своих хард скиллов, свободно конвертируемых в деньги на рынке труда любой страны и любой компании.
Здоровый тимлид
В реальности я не спорю, что лучше тимлиду иметь хорошие хард скиллы, чем не иметь. Но на всех стульях сразу не посидишь. Поэтому стул надо выбирать исходя из ситуации.
Если у вас большая команда, расхлябанные рабочие процессы и проблемы с коммуникациями между смежными отделами, ну и нанимайте такого тимлида, который это пофиксит, а не будет сидеть 80% времени просто код педалить.
Если у вас 1-2-3 землекопа и всё уже отлажено в целом, то пусть приходит и правда какую-то серьезную часть времени код пилит, попутно подтюнивая эволюционирующие рабочие процессы, направляя команду и проект к светлому будущему.
Сознательный тимлид
А еще хочется затронуть тему сознательности у тимлидов. У каждого своя мотивация и у каждого свой интерес. Кому-то ближе работа с людьми, кому-то с процессами, а кто-то не хочет совсем уж отпускать код. И вот каждый должен хорошенько подумать о том, что он хочет, что ему предлагает его текущая или потенциальная позиция, сделать соответствующие выводы, насколько ему это подходит.
В этом плане мне очень нравится пример Антона Околелова из подкаста Цинковый прод. Он как-то писал, что ему не хочется расставаться с кодом, но и тимлидить нравится. Поэтому он сознательно идет тимлидом в небольшие команды (2-3 человека), чтобы в комфортном для себя режиме на двух стульях усиживать без вреда для дела.
Итог
Думайте что вам ближе, ищите что по душе.
Предлагают вакансию играющего тренера – хорошенько анализируйте, насколько она адекватна, прежде чем соглашаться.
👍52🔥17
Как делать (бес)толковые собрания
Пару месяцев назад побывал на регулярном митапе Vladimir TechTalks.
Рассказывал о типичных проблемах при организации встреч, созвонов, собраний, и о том, как их избегать.
Тема довольно актуальная и часто болящая. Так что надеюсь, что какие-то полезные мысли удастся донести, и работа станет немного легче и приятнее.
Отдельные слова уважения организаторам митапа. Очень заботливо, душевно и качественно всё было сделано👍
Ссылка на видео https://rutube.ru/video/a1a6c67f4e7b3dba91d30e8a57b58cba/
Мой доклад на 40-й минуте
А еще на 1ч 26-й минуте Виктор Корейша, известный вам по подкасту Кода кода, рассказывает про настолки и их потенциальную пользу для работы.
Пару месяцев назад побывал на регулярном митапе Vladimir TechTalks.
Рассказывал о типичных проблемах при организации встреч, созвонов, собраний, и о том, как их избегать.
Тема довольно актуальная и часто болящая. Так что надеюсь, что какие-то полезные мысли удастся донести, и работа станет немного легче и приятнее.
Отдельные слова уважения организаторам митапа. Очень заботливо, душевно и качественно всё было сделано👍
Ссылка на видео https://rutube.ru/video/a1a6c67f4e7b3dba91d30e8a57b58cba/
Мой доклад на 40-й минуте
А еще на 1ч 26-й минуте Виктор Корейша, известный вам по подкасту Кода кода, рассказывает про настолки и их потенциальную пользу для работы.
RUTUBE
Vladimir TechTalks #15 в ВлГУ
Vladimir TechTalks #15 в ВлГУ
16 сентября 2022 года
00:02:22
Аналитика в IT Service Management
Александра Румянцевa, Head of Service Management
в Altenar
Обсудим, зачем нужен бизнес-аналитик и почему он — важная роль в управлении IT услугами компании.…
16 сентября 2022 года
00:02:22
Аналитика в IT Service Management
Александра Румянцевa, Head of Service Management
в Altenar
Обсудим, зачем нужен бизнес-аналитик и почему он — важная роль в управлении IT услугами компании.…
👍13🔥6
Немного о критике и действии
Есть такая известная фраза, которую приписывают много кому, от Сталина до кого-то из киноиндустрии: «Не согласен – критикуй, критикуешь – предлагай, предлагаешь – делай, делаешь – отвечай!». Часто о ней вспоминаю, что на работе, что в быту.
Не согласен – критикуй
Здесь обычно всё в избытке.
Очень много кого хлебом не корми, дай покритиковать. Все дураки, всё делают не так, виноваты все вокруг.
И печаль в том, что частенько на этом всё и заканчивается. Побубнили в курилке, какой начальник дурак, негатив слили и рассосались по своим местам делать плохо. Но уже с моральным оправданием, что виноват в этом кто-то другой.
Критикуешь – предлагай
До этого этапа уже доходят далеко не все.
А если и доходят, то часто опять же на уровне курилки.
Очень много слышал в работе недовольств по кухням, курилкам и чатикам, но как дело доходит до публичных чатов, собраний, обсуждений, эта категория граждан внезапно становится визуально всем довольна и сидит тихонечко, кивая головой.
Мне кажется, что это не самая эффективная стратегия. Если ты считаешь, что сейчас плохо, и ты знаешь, как можно лучше, то зачем молча терпеть плохое, когда можно хотя бы попробовать предложить улучшение? Вдруг ты такой мудрый, что никто, кроме тебя не догадался, и ты сможешь помочь как всему коллективу, так и себе в частности?
А если окажется, что предложить нечего, а просто изо дня в день ходишь про всех говоришь, какие они дураки и всё делают неправильно, то, может быть, стоит задуматься, чем ты от дураков отличаешься тогда.
Предлагаешь – делай
Сложность всё нарастает!
От предложений до действий мало кто доходит. Одно дело предложить что-то другим, а другое – самому еще напрягаться.
Очень радуюсь, когда встречаю людей, которые и предлагают что-то полезное, и делают что-то своими руками, или хорошо курируют реализацию процесса. Ставлю акцент на «хорошо курируют», ибо чайка-менеджерам, которые прилетят, покричат «делайте хорошо, а плохо не делайте» и улетят в закат, я не очень-то рад.
Делаешь – отвечай
Это вообще топовый уровень сложности!
Даже если мы рассматриваем «отвечай» не как «если сделаешь плохо, вычтем с тебя деньги, или уволим», а хотя бы просто «ты критиковал, что плохо, ты предложил, как лучше, ты сделал, – покажи результат, покажи, как именно стало лучше». Даже в этом варианте без наказания уже отваливается подавляющее большинство критикующих.
Сам-то что?
Сам стараюсь не молчать, когда вижу плохое, думаю и предлагаю хорошее, не боюсь делать и показывать результат. Ведь если я искренне уверен, что я прав и можно лучше, то надо действовать, если такая возможность имеется.
Не всегда получается так хорошо, как бы мне хотелось, это правда. Но если совсем ничего не делать, то и совсем ничего не изменится к лучшему.
Недавно столкнулся с ситуацией, когда в результате своей деятельности накосячил и пришлось из своих денег частично компенсировать. Считаю это справедливым, не ропщу, не уклоняюсь от ответственности, ведь недоработка была моя. Тем не менее, в целом по этому делу я в хорошем плюсе, так что, если бы я изначально побоялся начинать и нести хоть какую-то ответственность, то этого плюса не случилось.
Не всегда такое возможно
Обязательно кто-то заметит, что не всегда есть возможность кому-то предложить и что-то сделать, а потом еще результат продемонстрировать. Я не понаслышке знаком с такой ситуацией, когда как ни заноси предложения, тебя в лучшем случае отправят в игнор, а то и токсичным активом окрестят. Такое бывает.
Итог
Если у вас есть возможность что-то поменять, то неплохо бы перейти от пустых унылых разговоров о том, какие все вокруг дураки, к более конструктивной критике и реальному делу.
А если нет такой возможности, то тут уж решать вам: или смиряться, или менять что-то более радикально, или продолжать просто сливать куда-то свой негатив, или еще что-то, от чего вам станет легче.
Есть такая известная фраза, которую приписывают много кому, от Сталина до кого-то из киноиндустрии: «Не согласен – критикуй, критикуешь – предлагай, предлагаешь – делай, делаешь – отвечай!». Часто о ней вспоминаю, что на работе, что в быту.
Не согласен – критикуй
Здесь обычно всё в избытке.
Очень много кого хлебом не корми, дай покритиковать. Все дураки, всё делают не так, виноваты все вокруг.
И печаль в том, что частенько на этом всё и заканчивается. Побубнили в курилке, какой начальник дурак, негатив слили и рассосались по своим местам делать плохо. Но уже с моральным оправданием, что виноват в этом кто-то другой.
Критикуешь – предлагай
До этого этапа уже доходят далеко не все.
А если и доходят, то часто опять же на уровне курилки.
Очень много слышал в работе недовольств по кухням, курилкам и чатикам, но как дело доходит до публичных чатов, собраний, обсуждений, эта категория граждан внезапно становится визуально всем довольна и сидит тихонечко, кивая головой.
Мне кажется, что это не самая эффективная стратегия. Если ты считаешь, что сейчас плохо, и ты знаешь, как можно лучше, то зачем молча терпеть плохое, когда можно хотя бы попробовать предложить улучшение? Вдруг ты такой мудрый, что никто, кроме тебя не догадался, и ты сможешь помочь как всему коллективу, так и себе в частности?
А если окажется, что предложить нечего, а просто изо дня в день ходишь про всех говоришь, какие они дураки и всё делают неправильно, то, может быть, стоит задуматься, чем ты от дураков отличаешься тогда.
Предлагаешь – делай
Сложность всё нарастает!
От предложений до действий мало кто доходит. Одно дело предложить что-то другим, а другое – самому еще напрягаться.
Очень радуюсь, когда встречаю людей, которые и предлагают что-то полезное, и делают что-то своими руками, или хорошо курируют реализацию процесса. Ставлю акцент на «хорошо курируют», ибо чайка-менеджерам, которые прилетят, покричат «делайте хорошо, а плохо не делайте» и улетят в закат, я не очень-то рад.
Делаешь – отвечай
Это вообще топовый уровень сложности!
Даже если мы рассматриваем «отвечай» не как «если сделаешь плохо, вычтем с тебя деньги, или уволим», а хотя бы просто «ты критиковал, что плохо, ты предложил, как лучше, ты сделал, – покажи результат, покажи, как именно стало лучше». Даже в этом варианте без наказания уже отваливается подавляющее большинство критикующих.
Сам-то что?
Сам стараюсь не молчать, когда вижу плохое, думаю и предлагаю хорошее, не боюсь делать и показывать результат. Ведь если я искренне уверен, что я прав и можно лучше, то надо действовать, если такая возможность имеется.
Не всегда получается так хорошо, как бы мне хотелось, это правда. Но если совсем ничего не делать, то и совсем ничего не изменится к лучшему.
Недавно столкнулся с ситуацией, когда в результате своей деятельности накосячил и пришлось из своих денег частично компенсировать. Считаю это справедливым, не ропщу, не уклоняюсь от ответственности, ведь недоработка была моя. Тем не менее, в целом по этому делу я в хорошем плюсе, так что, если бы я изначально побоялся начинать и нести хоть какую-то ответственность, то этого плюса не случилось.
Не всегда такое возможно
Обязательно кто-то заметит, что не всегда есть возможность кому-то предложить и что-то сделать, а потом еще результат продемонстрировать. Я не понаслышке знаком с такой ситуацией, когда как ни заноси предложения, тебя в лучшем случае отправят в игнор, а то и токсичным активом окрестят. Такое бывает.
Итог
Если у вас есть возможность что-то поменять, то неплохо бы перейти от пустых унылых разговоров о том, какие все вокруг дураки, к более конструктивной критике и реальному делу.
А если нет такой возможности, то тут уж решать вам: или смиряться, или менять что-то более радикально, или продолжать просто сливать куда-то свой негатив, или еще что-то, от чего вам станет легче.
👍31🔥13
Лакмусовая бумажка культуры компании
Я видел, как рассматривают много разных факторов, говоря о культуре компании. Десятки докладов сделаны про разные аспекты, глядя на которые, можно понять, каково в компании будет работаться именно вам. Да и сам я посты писал про всякое.
Но недавно в одном из подкастов услышал определение, которое меня очень триггернуло. Я сначала не понял, а потом как понял. Рассказал коллегам, пообсуждал с товарищами по индустрии из разных компаний, и все мы сошлись на том, что это очень мудрая мысль.
«Культура компании – это то, кого нанимают, кого повышают и кого увольняют»
Попробуйте хорошенько об этом подумать, глядя на свою текущую компанию, и понять, насколько это отражает общую обстановку, атмосферу компании, ваши дальнейшие перспективы работы в ней.
Кого нанимают
Где-то ищут умных и талантливых.
Где-то – активных и энергичных.
Где-то – знакомых и проверенных.
Где-то – знакомых, с которыми можно деньги компании попилить.
Где-то – громко кричащих и рисующих красивые презентации.
Где-то – амбициозных и пробивных.
Где-то – наоборот, неамбициозных, покорных, с выученной беспомощностью.
Где-то – более «сильных», чем руководитель, а где-то, наоборот, более «слабых».
Кого повышают
Где-то повышают за успехи в труде.
Где-то – за то, что преданно смотрел в глаза и смеялся над шутками начальника на собрании.
Где-то – за то, что согласен регулярно овертаймить.
Где-то – за то, что сумел организовать труд так, что больше никому не нужно овертаймить.
Где-то – за то, что ты «удобный», ведь вы же СЕМЬЯ.
Где-то – за то, что сумел собрать классную команду.
Где-то – за то, что развалил текущую команду, ведь надо место освободить под друзей и подруг начальника.
Где-то – за то, что в курилке смешные шутки рассказываешь и вообще всегда на виду.
Кого увольняют
Где-то увольняют за то, что многократно срывал сроки и планы.
Где-то – за то, что не согласен с начальником. Ведь он начальник, а ты дурак.
Где-то – за то, что делал слишком мало.
Где-то – за то, что делал слишком много и стал карьерной угрозой для начальника.
Где-то – за то, что токсичен и разлагаешь коллектив.
Где-то – за то, что просто ты не друг начальника, а ему надо своего друга пристроить на твою позицию.
Где-то – за то, что распилил бюджет на проект.
Где-то – за то, что не справился с тем, чтобы этот бюджет правильно посчитать и превысил его в разы.
Где-то – за то, что посчитал бюджет и задавал слишком много вопросов о том, почему так много денег пропадает зря.
Итог
Я предлагаю каждому подумать сейчас о том, как обстоят дела у вас в компании, понять, выстраивается ли из этого какая-то внятная система и дальше уже, исходя из этой системы, понять свои дальнейшие перспективы.
Я подумал, у меня прям явно система четкая выстраивается. Но может это просто у меня и тех, с кем я успел обсудить, так совпало, а вы сейчас опровергнете.
Пишите в комментариях, насколько у вас получилось выявить закономерности 🙂
Я видел, как рассматривают много разных факторов, говоря о культуре компании. Десятки докладов сделаны про разные аспекты, глядя на которые, можно понять, каково в компании будет работаться именно вам. Да и сам я посты писал про всякое.
Но недавно в одном из подкастов услышал определение, которое меня очень триггернуло. Я сначала не понял, а потом как понял. Рассказал коллегам, пообсуждал с товарищами по индустрии из разных компаний, и все мы сошлись на том, что это очень мудрая мысль.
«Культура компании – это то, кого нанимают, кого повышают и кого увольняют»
Попробуйте хорошенько об этом подумать, глядя на свою текущую компанию, и понять, насколько это отражает общую обстановку, атмосферу компании, ваши дальнейшие перспективы работы в ней.
Кого нанимают
Где-то ищут умных и талантливых.
Где-то – активных и энергичных.
Где-то – знакомых и проверенных.
Где-то – знакомых, с которыми можно деньги компании попилить.
Где-то – громко кричащих и рисующих красивые презентации.
Где-то – амбициозных и пробивных.
Где-то – наоборот, неамбициозных, покорных, с выученной беспомощностью.
Где-то – более «сильных», чем руководитель, а где-то, наоборот, более «слабых».
Кого повышают
Где-то повышают за успехи в труде.
Где-то – за то, что преданно смотрел в глаза и смеялся над шутками начальника на собрании.
Где-то – за то, что согласен регулярно овертаймить.
Где-то – за то, что сумел организовать труд так, что больше никому не нужно овертаймить.
Где-то – за то, что ты «удобный», ведь вы же СЕМЬЯ.
Где-то – за то, что сумел собрать классную команду.
Где-то – за то, что развалил текущую команду, ведь надо место освободить под друзей и подруг начальника.
Где-то – за то, что в курилке смешные шутки рассказываешь и вообще всегда на виду.
Кого увольняют
Где-то увольняют за то, что многократно срывал сроки и планы.
Где-то – за то, что не согласен с начальником. Ведь он начальник, а ты дурак.
Где-то – за то, что делал слишком мало.
Где-то – за то, что делал слишком много и стал карьерной угрозой для начальника.
Где-то – за то, что токсичен и разлагаешь коллектив.
Где-то – за то, что просто ты не друг начальника, а ему надо своего друга пристроить на твою позицию.
Где-то – за то, что распилил бюджет на проект.
Где-то – за то, что не справился с тем, чтобы этот бюджет правильно посчитать и превысил его в разы.
Где-то – за то, что посчитал бюджет и задавал слишком много вопросов о том, почему так много денег пропадает зря.
Итог
Я предлагаю каждому подумать сейчас о том, как обстоят дела у вас в компании, понять, выстраивается ли из этого какая-то внятная система и дальше уже, исходя из этой системы, понять свои дальнейшие перспективы.
Я подумал, у меня прям явно система четкая выстраивается. Но может это просто у меня и тех, с кем я успел обсудить, так совпало, а вы сейчас опровергнете.
Пишите в комментариях, насколько у вас получилось выявить закономерности 🙂
👍59🔥24
Люди и Кода кода
Мы решили не изменять нашей традиции делать новогодний выпуск наоборот.
Сегодня мы, совместно с Тимуром Тукаевым, автором и ведущим подкаста «Люди и код», представляем вам разговор не о работе, команде, процессах и технологиях.
Это будет развлекательный эпизод о развлекающих активностях 🙂
Небольшой спойлер: после прослушивания рассказа Виктора, мне очень захотелось узнать, что там за клевая такая ягодка, которую всё время хочется жамкать.
Надеюсь вам будет интересно, а у кого-то всплывут теплые ностальгические воспоминания.
Приходите поделиться в комментариях своими мнениями по поводу того, что мы обсудили, что вы любите, и что мы забыли обсудить из того, что вы любите 🙂
Ссылка на выпуск тут
Бонусный контент
Существует еще и вторая часть новогоднего выпуска.
В ней мы с Виктором берем интервью у Тимура про подкасты: как их делать, как измерять, как продвигать, как находить темы, гостей, и многое другое. Мне, как заправскому подкастологу, слушающему подкастов 30 всяких разных, было очень интересно это пообсуждать.
Мы решили не изменять нашей традиции делать новогодний выпуск наоборот.
Сегодня мы, совместно с Тимуром Тукаевым, автором и ведущим подкаста «Люди и код», представляем вам разговор не о работе, команде, процессах и технологиях.
Это будет развлекательный эпизод о развлекающих активностях 🙂
Небольшой спойлер: после прослушивания рассказа Виктора, мне очень захотелось узнать, что там за клевая такая ягодка, которую всё время хочется жамкать.
Надеюсь вам будет интересно, а у кого-то всплывут теплые ностальгические воспоминания.
Приходите поделиться в комментариях своими мнениями по поводу того, что мы обсудили, что вы любите, и что мы забыли обсудить из того, что вы любите 🙂
Ссылка на выпуск тут
Бонусный контент
Существует еще и вторая часть новогоднего выпуска.
В ней мы с Виктором берем интервью у Тимура про подкасты: как их делать, как измерять, как продвигать, как находить темы, гостей, и многое другое. Мне, как заправскому подкастологу, слушающему подкастов 30 всяких разных, было очень интересно это пообсуждать.
👍9🔥6🎄4🤩1
Итог
Все вы знаете, что у меня в каждом посте имеется Итог.
Пусть будет и в последний рабочий день года тоже свой итог.
Не стану сегодня вас грузить рабочими моментами, ведь у многих уже предновогоднее настроение. А у канала вдобавок к этому еще и недавно был день рождения.
Тимлиду Очевидность уже 3 года!💪
Эти 3 года пролетели очень быстро. Но если внимательно посмотреть назад, то я обнаруживаю кучу разных событий, мероприятий, людей, идей и возможностей, которые появились благодаря тому, что я когда-то решил завести этот канал. Ни разу я не пожалел об этом решении, и ни дня мне не было в тягость из-за ведения канала, сколько бы я времени на него не тратил.
А еще я рад, что этот канал не только мне дает какие-то возможности, но и его читателям.
Всегда греет душу, когда кто-то пишет, что попробовали ту или иную идею и им лично зашло, или всей команде зашло.
Для этого канал и затевался: делиться идеями, опытом, помогать кому-нибудь делать свою жизнь и работу немного комфортнее, приятнее, продуктивнее.
Спасибо
Спасибо, что читаете, комментируете, предлагаете темы, пробуете, действуете, думаете, приходите пообщаться!🤝
Приложу красивую картиночку со статистикой и пожелаю вам нового года по возможности лучше, чем бешеный нынешний.❤️
Все вы знаете, что у меня в каждом посте имеется Итог.
Пусть будет и в последний рабочий день года тоже свой итог.
Не стану сегодня вас грузить рабочими моментами, ведь у многих уже предновогоднее настроение. А у канала вдобавок к этому еще и недавно был день рождения.
Тимлиду Очевидность уже 3 года!💪
Эти 3 года пролетели очень быстро. Но если внимательно посмотреть назад, то я обнаруживаю кучу разных событий, мероприятий, людей, идей и возможностей, которые появились благодаря тому, что я когда-то решил завести этот канал. Ни разу я не пожалел об этом решении, и ни дня мне не было в тягость из-за ведения канала, сколько бы я времени на него не тратил.
А еще я рад, что этот канал не только мне дает какие-то возможности, но и его читателям.
Всегда греет душу, когда кто-то пишет, что попробовали ту или иную идею и им лично зашло, или всей команде зашло.
Для этого канал и затевался: делиться идеями, опытом, помогать кому-нибудь делать свою жизнь и работу немного комфортнее, приятнее, продуктивнее.
Спасибо
Спасибо, что читаете, комментируете, предлагаете темы, пробуете, действуете, думаете, приходите пообщаться!🤝
Приложу красивую картиночку со статистикой и пожелаю вам нового года по возможности лучше, чем бешеный нынешний.❤️
❤60🎉11👍8🎄6☃2🔥2🎅2❤🔥1
Проклятие знания
Проклятие знания — термин, предложенный психологом Робином Хогартом для обозначения психологического феномена, заключающегося в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей.
Эта штука встречается в работе чаще, чем нам бы этого хотелось.
Обучение и менторство
Видел много раз, что опытный наставник довольно непонятно и непродуктивно чему-то учит новичков. Он уже и забыл, как был сам начинающим специалистом, и что вот эти вот «простейшие азы, которые очевидны», на самом деле не простейшие, не очевидные, и требуют детального объяснения.
В итоге обучающий сыплет сложными терминами и абстракциями, а обучающийся готов провалиться под землю от чувства собственной ничтожности. Ведь наставник же говорит, что там всё легче легкого, значит, это обучающийся – плохой, глупый, неправильный.
Заказчик-исполнитель
В отношениях заказчиков и исполнителей тоже порой всё плохо. Заказчик выдает лишь половину нужной информации, потому что он знает уже хорошо свою доменную область и «ЭТО ЖЕ ОЧЕВИДНО» (оригинальная цитата, с которой я столкнулся в подобном случае).
Или наоборот, исполнитель рассказывает продавцу тортиков, какие он паттерны проектирования использует, как CI/CD настроит и почему синглтон нынче считают моветоном.
Абсолютно то же самое происходит во взаимодействии менеджер-программист. Один про код, другой про РОИ, ДАУ, МАУ, CJM и прочее.
Программист-программист
Уже вроде проще. Да, но нет.
Тут тоже сильно зависит от компетенции и знания глоссария. Кстати, здесь в какой-то мере помогает, например, теория паттернов проектирования. Ведь тут у всех появляется общий словарь и одинаковое понимание абстракций.
Что делать
На мой взгляд, надо хорошенько думать о собеседнике. Надо прикидывать, что он знает, что не знает. Давать как можно больше контекста по теме разговора. Надо уточнять, всё ли понятно. Ну т.е. совет, казалось бы, обо всём и ни о чем.
Давайте чуть более практический пример. Если я хочу, чтобы пентестеры проверили мой новый проект, я не напишу им «Доброго времени суток, коллеги! Прошу проверить мой проект.», как это могли бы сделать некоторые. Я сообщу им весь потенциально нужный контекст, которого они не знают.
Например, я объясню:
⁃ Что за проект и какая у него основная цель. Это нужно для общего понимания, на что делать упор при проверке.
⁃ Когда дедлайн по запуску. Чтобы сроки выполнения сматчить.
⁃ Есть ли пользовательский ввод и если да, то где и какой: формы, загружаемые файлы, регистрации, авторизации и прочее. Чтобы этому уделили максимальное внимание и ничего не осталось незамеченным.
⁃ Есть ли интеграции с внешними системами. Чтобы понимали, какие данные могут поступать извне и куда, в случае прорыва периметра, куда злоумышленник может попасть еще.
⁃ Какой стэк технологий, где конфиги, данные о внешних модулях и библиотеках. Чтобы выяснить все данные об известных уязвимостях.
⁃ Где конфиги сервера и как получить туда доступ. Ведь не только на уровне кода бывают уязвимости.
Все эти пункты дают ответы сразу на многие вопросы, которые потенциально возникали бы спустя часы бестолкового поиска вслепую. Заодно меньше шанс, что что-то пропустят, потому что не знали про это и оно лежало в каком-то неочевидном месте.
Возможно, этих данных окажется недостаточно, и тогда я готов отвечать на дополнительные вопросы. Но я буду знать, что я изначально покрыл большинство темных пятен и люди будут уже что-то уточнять, довольно неплохо ориентируясь в проекте.
Итог
Формирования общего глоссария с собеседником, передача полного контекста, мысль о том, что всё, что очевидно для тебя, может быть неочевидно для кого-то другого – всё это ведет к минимизации негативного эффекта проклятия знания, устранению лишней пустой работы и вопросов.
А еще это довольно уважительно по отношению к собеседнику. А люди любят, когда их уважают.
Проклятие знания — термин, предложенный психологом Робином Хогартом для обозначения психологического феномена, заключающегося в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей.
Эта штука встречается в работе чаще, чем нам бы этого хотелось.
Обучение и менторство
Видел много раз, что опытный наставник довольно непонятно и непродуктивно чему-то учит новичков. Он уже и забыл, как был сам начинающим специалистом, и что вот эти вот «простейшие азы, которые очевидны», на самом деле не простейшие, не очевидные, и требуют детального объяснения.
В итоге обучающий сыплет сложными терминами и абстракциями, а обучающийся готов провалиться под землю от чувства собственной ничтожности. Ведь наставник же говорит, что там всё легче легкого, значит, это обучающийся – плохой, глупый, неправильный.
Заказчик-исполнитель
В отношениях заказчиков и исполнителей тоже порой всё плохо. Заказчик выдает лишь половину нужной информации, потому что он знает уже хорошо свою доменную область и «ЭТО ЖЕ ОЧЕВИДНО» (оригинальная цитата, с которой я столкнулся в подобном случае).
Или наоборот, исполнитель рассказывает продавцу тортиков, какие он паттерны проектирования использует, как CI/CD настроит и почему синглтон нынче считают моветоном.
Абсолютно то же самое происходит во взаимодействии менеджер-программист. Один про код, другой про РОИ, ДАУ, МАУ, CJM и прочее.
Программист-программист
Уже вроде проще. Да, но нет.
Тут тоже сильно зависит от компетенции и знания глоссария. Кстати, здесь в какой-то мере помогает, например, теория паттернов проектирования. Ведь тут у всех появляется общий словарь и одинаковое понимание абстракций.
Что делать
На мой взгляд, надо хорошенько думать о собеседнике. Надо прикидывать, что он знает, что не знает. Давать как можно больше контекста по теме разговора. Надо уточнять, всё ли понятно. Ну т.е. совет, казалось бы, обо всём и ни о чем.
Давайте чуть более практический пример. Если я хочу, чтобы пентестеры проверили мой новый проект, я не напишу им «Доброго времени суток, коллеги! Прошу проверить мой проект.», как это могли бы сделать некоторые. Я сообщу им весь потенциально нужный контекст, которого они не знают.
Например, я объясню:
⁃ Что за проект и какая у него основная цель. Это нужно для общего понимания, на что делать упор при проверке.
⁃ Когда дедлайн по запуску. Чтобы сроки выполнения сматчить.
⁃ Есть ли пользовательский ввод и если да, то где и какой: формы, загружаемые файлы, регистрации, авторизации и прочее. Чтобы этому уделили максимальное внимание и ничего не осталось незамеченным.
⁃ Есть ли интеграции с внешними системами. Чтобы понимали, какие данные могут поступать извне и куда, в случае прорыва периметра, куда злоумышленник может попасть еще.
⁃ Какой стэк технологий, где конфиги, данные о внешних модулях и библиотеках. Чтобы выяснить все данные об известных уязвимостях.
⁃ Где конфиги сервера и как получить туда доступ. Ведь не только на уровне кода бывают уязвимости.
Все эти пункты дают ответы сразу на многие вопросы, которые потенциально возникали бы спустя часы бестолкового поиска вслепую. Заодно меньше шанс, что что-то пропустят, потому что не знали про это и оно лежало в каком-то неочевидном месте.
Возможно, этих данных окажется недостаточно, и тогда я готов отвечать на дополнительные вопросы. Но я буду знать, что я изначально покрыл большинство темных пятен и люди будут уже что-то уточнять, довольно неплохо ориентируясь в проекте.
Итог
Формирования общего глоссария с собеседником, передача полного контекста, мысль о том, что всё, что очевидно для тебя, может быть неочевидно для кого-то другого – всё это ведет к минимизации негативного эффекта проклятия знания, устранению лишней пустой работы и вопросов.
А еще это довольно уважительно по отношению к собеседнику. А люди любят, когда их уважают.
👍58👏6😁1
Свистать всех на онбординг!
Если вы достаточно давно меня знаете и читаете, то вы в курсе, что я тот еще подкастолог 🙂 Как-то даже делал тред с ИТ подкастами в твиттере.
В каждом подкасте есть для меня своя особенность и ценность. Один более развлекательный, второй подкидывает интересные мысли о менеджменте, третий залезает поглубже в технологии, кто-то предлагает интересный визионерский взгляд на будущее, а где-то – просто люди, которые мне симпатичны и интересны.
А есть один очень уважаемый мною подкаст, который является для меня эталоном раскрытия темы. Вот если я хочу в какой-то конкретной теме разобраться, я ищу, нет ли у них такого выпуска.
Думаю, многие уже догадались, что это Podlodka.
Я бывал у разных подкастов в гостях, но никогда не думал, что пригожусь в Подлодке. Тем не менее внезапно оказалось, что пригодился 🙂
Сегодня вышел выпуск про онбординг, где я постарался рассказать, как сделать его комфортно, эффективно и без сложных изысков.
Очень рад, что ребята решили поднять эту тему.
С кем в индустрии ни говорил, почти у каждого есть несколько примеров, где история про интеграцию в компанию смешная, а ситуация – страшная. То есть проблема распространенная и требует внимания, вдумчивого разбора, сознательных действий по её решению.
Надеюсь, мне, Егору и Жене в этом выпуске удастся принести кому-нибудь несколько полезных мыслей и сделать, пусть и небольшой, но полезный вклад в индустрию и комьюнити.
Ссылка на выпуск, например, тут https://www.youtube.com/watch?v=voXuxOJ6TWM&ab_channel=Podlodka или тут https://podlodka.io/302
Приятного прослушивания!👍
Если вы достаточно давно меня знаете и читаете, то вы в курсе, что я тот еще подкастолог 🙂 Как-то даже делал тред с ИТ подкастами в твиттере.
В каждом подкасте есть для меня своя особенность и ценность. Один более развлекательный, второй подкидывает интересные мысли о менеджменте, третий залезает поглубже в технологии, кто-то предлагает интересный визионерский взгляд на будущее, а где-то – просто люди, которые мне симпатичны и интересны.
А есть один очень уважаемый мною подкаст, который является для меня эталоном раскрытия темы. Вот если я хочу в какой-то конкретной теме разобраться, я ищу, нет ли у них такого выпуска.
Думаю, многие уже догадались, что это Podlodka.
Я бывал у разных подкастов в гостях, но никогда не думал, что пригожусь в Подлодке. Тем не менее внезапно оказалось, что пригодился 🙂
Сегодня вышел выпуск про онбординг, где я постарался рассказать, как сделать его комфортно, эффективно и без сложных изысков.
Очень рад, что ребята решили поднять эту тему.
С кем в индустрии ни говорил, почти у каждого есть несколько примеров, где история про интеграцию в компанию смешная, а ситуация – страшная. То есть проблема распространенная и требует внимания, вдумчивого разбора, сознательных действий по её решению.
Надеюсь, мне, Егору и Жене в этом выпуске удастся принести кому-нибудь несколько полезных мыслей и сделать, пусть и небольшой, но полезный вклад в индустрию и комьюнити.
Ссылка на выпуск, например, тут https://www.youtube.com/watch?v=voXuxOJ6TWM&ab_channel=Podlodka или тут https://podlodka.io/302
Приятного прослушивания!👍
YouTube
Podlodka #302 – Онбординг
Все мы слышали истории плохого онбординга новичков в компанию: начиная c того, что в течение месяца сотруднику не выдавали ноутбук, заканчивая тем, что первые недели работы целиком состояли из буллшитных встреч про ценности и миссию. Вместе с Евгением Антоновым…
🔥32👍12👏3❤1
Редукционизм
По сути редукционизм – это объяснение свойств и поведения сложных объектов или систем через свойства и поведения их простых составных частей.
Вроде звучит логично. Поэтому одно время философы активно культивировали эту идею.
Однако несколько позже маятник философии качнулся в другую сторону (к холизму) и сказал нам, что «целое больше, чем сумма его частей».
Бытовой пример
Вот есть у вас механические часы. Они являют собой набор пружинок и шестеренок.
Если перед вами рассыпать все эти детали, то изучив по отдельности каждое колесико, его размер, состав, скорость вращения, вы вряд ли сможете понять, как эти часы работают.
Еще из того, что шестеренки могут крутиться, совершенно не очевидно, что из этого получится прибор, показывающий время.
А если усилить пружинку и увеличить диаметр у двух колесиков, то это не значит, что часы будут показывать время «еще лучше».
Да и совершенно не обязательно, что именно время будет показывать прибор, собранный из шестеренок.
К чему это я
К тому, что в работе нас зачастую окружает подобный редукционизм сплошь и рядом. Он ловко зацепляется за карго-культ бездумного повторения за кем-то другим и мы получаем абсолютно бестолковые практики, которые не только не помогают, но и мешают.
Рабочий пример №1
Приходит к вам менеджер и просит оценить срок у вот этих трех задач.
Вы оцениваете (про то, как оценивать, поговорим в другом посте) и отдаете 3 цифры. Менеджер складывает 3 цифры и радостно убегает к заказчику докладывать, когда будет закончен проект.
Где тут редукционизм? Менеджер не учел, что у него есть сложная система, где есть вы, 3 задачи, еще другие проекты, еще другие непредвиденные дела, текучка, каждая задача может ненароком зацепить что-то еще, а вас может зацепить более сложный проект или более интересная работа с более дальновидными менеджерами.
Рабочий пример №2
Приходит к вам эйчар и говорит, что с завтрашнего дня надо ввести грейды.
Где тут может крыться редукционизм?
Например, грейды вводятся, но при этом дальше ничего не меняется. Нет понятной системы пересмотра грейдов, нет прозрачной тарифной сетки по каждому грейду, нет системы развития людей от грейда к грейду. Просто грейд ради грейдов.
Получается, что человек не понимает, что там, где грейды существуют и как-то свою функцию выполняют, они являются лишь частью более сложной системы, и только в комплексе система будет работать. А если просто вы накидали пару шестереночек в коробку, то время эта коробка показывать не будет.
Где тут еще редукционизм?
Сами грейды описать – очень и очень сложная задача. Я видел много таких таблиц, где написано, что джуниор должен знать такие-то функции языка, уметь сякие линукс команды, а мидл всё это, плюс еще фреймворк, а сениор плюс еще один фреймворк и тесты умеет писать.
Ну разве это говорит нам о том, насколько действительно велика ценность каждого разработчика? Там же много еще всякого того, что обычно в инженерной сетке грейдов мало кто прописывает. Как человек с другими технарями и менеджерами взаимодействует, насколько проявляет инициативу и ответственность в работе, как обучается и обучает других, как в целом на команду влияет в моральном плане, в плане производительности, насколько он в конце концов может генерить какие-то альтернативные креативные решения.
Да и в целом человек – слишком сложная система, чтобы взять и однозначно сказать, какие его «качества и свойства» ценны для работы, а какие нет. А система, состоящая из таких человеков, еще сложнее.
Кстати, я не отрицаю систему грейдирования целиком и полностью, просто это тема для отдельного большого поста. А сегодня я вам просто показал реальную историю, когда бездумно заносят грейды ради грейдов в отрыве от всей социотехнической системы.
Итог
Я считаю, что внедрение новых инструментов и практик должно оцениваться по комплексному влиянию на всю систему. Но об этом редко хотят задуматься, потому что это сложно, не всегда возможно свести к какой-то конкретной цифре и ненароком можно получить неожиданные неприятные факты, говорящие, что вы занимаетесь ненужной чепухой. А ведь job security никто не отменял🙂
По сути редукционизм – это объяснение свойств и поведения сложных объектов или систем через свойства и поведения их простых составных частей.
Вроде звучит логично. Поэтому одно время философы активно культивировали эту идею.
Однако несколько позже маятник философии качнулся в другую сторону (к холизму) и сказал нам, что «целое больше, чем сумма его частей».
Бытовой пример
Вот есть у вас механические часы. Они являют собой набор пружинок и шестеренок.
Если перед вами рассыпать все эти детали, то изучив по отдельности каждое колесико, его размер, состав, скорость вращения, вы вряд ли сможете понять, как эти часы работают.
Еще из того, что шестеренки могут крутиться, совершенно не очевидно, что из этого получится прибор, показывающий время.
А если усилить пружинку и увеличить диаметр у двух колесиков, то это не значит, что часы будут показывать время «еще лучше».
Да и совершенно не обязательно, что именно время будет показывать прибор, собранный из шестеренок.
К чему это я
К тому, что в работе нас зачастую окружает подобный редукционизм сплошь и рядом. Он ловко зацепляется за карго-культ бездумного повторения за кем-то другим и мы получаем абсолютно бестолковые практики, которые не только не помогают, но и мешают.
Рабочий пример №1
Приходит к вам менеджер и просит оценить срок у вот этих трех задач.
Вы оцениваете (про то, как оценивать, поговорим в другом посте) и отдаете 3 цифры. Менеджер складывает 3 цифры и радостно убегает к заказчику докладывать, когда будет закончен проект.
Где тут редукционизм? Менеджер не учел, что у него есть сложная система, где есть вы, 3 задачи, еще другие проекты, еще другие непредвиденные дела, текучка, каждая задача может ненароком зацепить что-то еще, а вас может зацепить более сложный проект или более интересная работа с более дальновидными менеджерами.
Рабочий пример №2
Приходит к вам эйчар и говорит, что с завтрашнего дня надо ввести грейды.
Где тут может крыться редукционизм?
Например, грейды вводятся, но при этом дальше ничего не меняется. Нет понятной системы пересмотра грейдов, нет прозрачной тарифной сетки по каждому грейду, нет системы развития людей от грейда к грейду. Просто грейд ради грейдов.
Получается, что человек не понимает, что там, где грейды существуют и как-то свою функцию выполняют, они являются лишь частью более сложной системы, и только в комплексе система будет работать. А если просто вы накидали пару шестереночек в коробку, то время эта коробка показывать не будет.
Где тут еще редукционизм?
Сами грейды описать – очень и очень сложная задача. Я видел много таких таблиц, где написано, что джуниор должен знать такие-то функции языка, уметь сякие линукс команды, а мидл всё это, плюс еще фреймворк, а сениор плюс еще один фреймворк и тесты умеет писать.
Ну разве это говорит нам о том, насколько действительно велика ценность каждого разработчика? Там же много еще всякого того, что обычно в инженерной сетке грейдов мало кто прописывает. Как человек с другими технарями и менеджерами взаимодействует, насколько проявляет инициативу и ответственность в работе, как обучается и обучает других, как в целом на команду влияет в моральном плане, в плане производительности, насколько он в конце концов может генерить какие-то альтернативные креативные решения.
Да и в целом человек – слишком сложная система, чтобы взять и однозначно сказать, какие его «качества и свойства» ценны для работы, а какие нет. А система, состоящая из таких человеков, еще сложнее.
Кстати, я не отрицаю систему грейдирования целиком и полностью, просто это тема для отдельного большого поста. А сегодня я вам просто показал реальную историю, когда бездумно заносят грейды ради грейдов в отрыве от всей социотехнической системы.
Итог
Я считаю, что внедрение новых инструментов и практик должно оцениваться по комплексному влиянию на всю систему. Но об этом редко хотят задуматься, потому что это сложно, не всегда возможно свести к какой-то конкретной цифре и ненароком можно получить неожиданные неприятные факты, говорящие, что вы занимаетесь ненужной чепухой. А ведь job security никто не отменял🙂
👍32🔥12⚡2😱1❤🔥1
Целеполагание
Сегодня хочется выразить свое мнение по поводу того, что целеполагание – штука хоть и очевидно важная, но иногда незаслуженно игнорируемая.
Например
Однажды мне принесли в команду запрос на изготовление довольно большого проекта.
Я начал уточнять, зачем он нужен, почему именно такой и именно так, спросили ли у пользователей, правда ли он им необходим, провели ли какой-то кастдев, посчитали ли хоть какой-то прогноз по деньгам и вот это вот всё.
Оказалось, что нафиг это никому не нужно, и за час вопросов я сэкономил примерно человекогод разработки.
Вот пример того, что без целеполагания можно впаливать очень много труда людей и денег компании впустую.
Еще пример – карьерные проблемы. Хочет человек позицию лида, но делает абсолютно рутинную работу и сознательно не развивается, не двигается в этом направлении в своей компании, не ходит на рынок труда, а просто хочет и ждет.
Вроде цель есть, но это скорее фантазия, а не цель. Обычно с осознанной целью идет какое-то более конкретное планирование, типа «хочу быть лидом, поговорю с руководителем, спрошу, насколько это возможно, предложу взять на себя такие-то дела, а если ничего не выйдет, составлю хорошее резюме, попробую выйти на рынок труда именно за этой позицией, или с явно проговоренной перспективой роста туда».
Еще видел такие случаи, когда ребята занимались спортом в режиме, грубо говоря, обычного физкультурника, а потом зачем-то шли на соревнования и там им быстро делали больно и обидно (в кикбоксинге такое бывает). При расспросах оказывалось, что там совсем никакого целеполагания и планирования не было. Кто-то хотел на соревнования, но не готовился должным образом, а кто-то не хотел, но зачем-то заявился. У них всех наблюдалось много темных пятен в мотивации и логической связи мотива с целью.
Цель –> план
На мой взгляд, если очень хорошо попыхтеть над понятным и сознательным формированием цели, то из этого потом можно изготовить уже хороший план, который к этой цели действительно отведет.
А иногда бывает, что человек составляет какие-то планы, а цель не сформировал. В итоге дошел до середины, потратил кучу времени, денег, сил, и понял, что вообще не туда пошел, и не нужен ему такой план вообще. Сам я таким тоже грешил и довольно много всякого труда в мусорку слил. Где-то, тем не менее, это был любопытный опыт, а где-то – просто время потерял зря.
У самурая нет цели, только путь
Многие любят эту фразу, оправдывая вообще отсутствие цели и метание по рандомным сторонам.
Я тоже ее люблю, но только в контексте того, что иногда даже может не быть конкретной цели, вопреки всяким там успешным учениям об успехе, но нужное направление понимать для себя надо. Иначе как вообще знать, куда идти и что делать?
Итог
В работе и быту целеполагание и «направлениеполагание» очень важно. Не менее важно и следующее из этого планирование.
Однако не стоит впадать и совсем уж в крайность, когда «максимально эффективные» люди уже и забыли, в чем для них радость от жизни, ведь их жизнь на 100% состоит из «нужных задач».
Сегодня хочется выразить свое мнение по поводу того, что целеполагание – штука хоть и очевидно важная, но иногда незаслуженно игнорируемая.
Например
Однажды мне принесли в команду запрос на изготовление довольно большого проекта.
Я начал уточнять, зачем он нужен, почему именно такой и именно так, спросили ли у пользователей, правда ли он им необходим, провели ли какой-то кастдев, посчитали ли хоть какой-то прогноз по деньгам и вот это вот всё.
Оказалось, что нафиг это никому не нужно, и за час вопросов я сэкономил примерно человекогод разработки.
Вот пример того, что без целеполагания можно впаливать очень много труда людей и денег компании впустую.
Еще пример – карьерные проблемы. Хочет человек позицию лида, но делает абсолютно рутинную работу и сознательно не развивается, не двигается в этом направлении в своей компании, не ходит на рынок труда, а просто хочет и ждет.
Вроде цель есть, но это скорее фантазия, а не цель. Обычно с осознанной целью идет какое-то более конкретное планирование, типа «хочу быть лидом, поговорю с руководителем, спрошу, насколько это возможно, предложу взять на себя такие-то дела, а если ничего не выйдет, составлю хорошее резюме, попробую выйти на рынок труда именно за этой позицией, или с явно проговоренной перспективой роста туда».
Еще видел такие случаи, когда ребята занимались спортом в режиме, грубо говоря, обычного физкультурника, а потом зачем-то шли на соревнования и там им быстро делали больно и обидно (в кикбоксинге такое бывает). При расспросах оказывалось, что там совсем никакого целеполагания и планирования не было. Кто-то хотел на соревнования, но не готовился должным образом, а кто-то не хотел, но зачем-то заявился. У них всех наблюдалось много темных пятен в мотивации и логической связи мотива с целью.
Цель –> план
На мой взгляд, если очень хорошо попыхтеть над понятным и сознательным формированием цели, то из этого потом можно изготовить уже хороший план, который к этой цели действительно отведет.
А иногда бывает, что человек составляет какие-то планы, а цель не сформировал. В итоге дошел до середины, потратил кучу времени, денег, сил, и понял, что вообще не туда пошел, и не нужен ему такой план вообще. Сам я таким тоже грешил и довольно много всякого труда в мусорку слил. Где-то, тем не менее, это был любопытный опыт, а где-то – просто время потерял зря.
У самурая нет цели, только путь
Многие любят эту фразу, оправдывая вообще отсутствие цели и метание по рандомным сторонам.
Я тоже ее люблю, но только в контексте того, что иногда даже может не быть конкретной цели, вопреки всяким там успешным учениям об успехе, но нужное направление понимать для себя надо. Иначе как вообще знать, куда идти и что делать?
Итог
В работе и быту целеполагание и «направлениеполагание» очень важно. Не менее важно и следующее из этого планирование.
Однако не стоит впадать и совсем уж в крайность, когда «максимально эффективные» люди уже и забыли, в чем для них радость от жизни, ведь их жизнь на 100% состоит из «нужных задач».
👍50🔥12