Люди выбирают не первых и лучших, а своих
Недавно читал книгу «Всё закончится, а ты нет» и встретил там фразу «Люди выбирают не первых и лучших, а своих».
Мне кажется, если в это глубоко вдуматься, понять и принять, то отпадут некоторые страдания от собственной неидеальности.
В чем проблема?
У тимлидов много разных направлений: проекты, люди, техника. По каждому направлению всегда море задач. Всё успеть, да ещё и хорошо – просто нереально.
Начинаешь чем-то жертвовать: где-то задачу не сделал совсем, где-то что-то забыл, где-то уголок срезал, чтобы впихнуть невпихуемое, и уже чувствуешь, что по многим фронтам как будто бы плохо всё.
В бытовой жизни примерно та же история. Где-то ты на рутинные вещи подзабил, где-то семье мало времени уделил, где-то коришь себя за то, что не успеваешь заниматься хобби или ленишься ходить в театр, например.
И вот получается, что общее настроение такое, что и там, и тут что-то постоянно недотягиваешь и вообще «кому я, нафиг, такой нужен?»
В чем суть ключевой фразы?
На мой взгляд, какими бы «недостаточно хорошими» мы себя ни ощущали, нас же кто-то выбирает. На работу взяли, фидбэк о работе дают не самый ужасный, с позором взашей не увольняют, а у кого-то есть партнер, который также совершил сознательный выбор.
Почему так?
А потому, что выбирают не самого идеального, а своего.
Одна команда принимает тимлида, который душевную атмосферу внутри создает, другая – того, что держит заказчиков и техдолг в ежовых рукавицах, третья – только супер лютого технаря, который может научить величайшим сложнейшим премудростям.
В романтических отношениях похожая история. Зачастую выбирают не самого богатого/высоко/красивого, а того, с кем будет персонально комфортно, уютно, безопасно.
Вспомните сами каких-нибудь мастеров/тренеров/репетитиров, чьими услугами вы пользуетесь регулярно. Там же не лучшие из лучших, только топовые небожители. Там те, кто делает «достаточно хорошо» и при этом вам персонально подходит. «Ваш» человек, одним словом.
Что это значит?
Это значит, что необязательно себя корить за неидеальность во всех аспектах жизни и работы. Если вы делаете «достаточно хорошо», то обязательно для вас найдется местечко, где вы будете «своим». И там вам будет хорошо.
А даже если и «недостаточно хорошо» делаете, то по-любому тоже что-то подвернется, только с более низким качеством, так сказать.
Итог
Хочется пожелать вам и себе перестать гнобить себя за малейшие неидеальности и посоветовать хорошо подумать, что/кого вы чувствуете «своим» и где бы вас так воспринимали. Порефлексировать и стремиться туда, где будет комфортно и не будет осуждения за малейшие огрехи.
Недавно читал книгу «Всё закончится, а ты нет» и встретил там фразу «Люди выбирают не первых и лучших, а своих».
Мне кажется, если в это глубоко вдуматься, понять и принять, то отпадут некоторые страдания от собственной неидеальности.
В чем проблема?
У тимлидов много разных направлений: проекты, люди, техника. По каждому направлению всегда море задач. Всё успеть, да ещё и хорошо – просто нереально.
Начинаешь чем-то жертвовать: где-то задачу не сделал совсем, где-то что-то забыл, где-то уголок срезал, чтобы впихнуть невпихуемое, и уже чувствуешь, что по многим фронтам как будто бы плохо всё.
В бытовой жизни примерно та же история. Где-то ты на рутинные вещи подзабил, где-то семье мало времени уделил, где-то коришь себя за то, что не успеваешь заниматься хобби или ленишься ходить в театр, например.
И вот получается, что общее настроение такое, что и там, и тут что-то постоянно недотягиваешь и вообще «кому я, нафиг, такой нужен?»
В чем суть ключевой фразы?
На мой взгляд, какими бы «недостаточно хорошими» мы себя ни ощущали, нас же кто-то выбирает. На работу взяли, фидбэк о работе дают не самый ужасный, с позором взашей не увольняют, а у кого-то есть партнер, который также совершил сознательный выбор.
Почему так?
А потому, что выбирают не самого идеального, а своего.
Одна команда принимает тимлида, который душевную атмосферу внутри создает, другая – того, что держит заказчиков и техдолг в ежовых рукавицах, третья – только супер лютого технаря, который может научить величайшим сложнейшим премудростям.
В романтических отношениях похожая история. Зачастую выбирают не самого богатого/высоко/красивого, а того, с кем будет персонально комфортно, уютно, безопасно.
Вспомните сами каких-нибудь мастеров/тренеров/репетитиров, чьими услугами вы пользуетесь регулярно. Там же не лучшие из лучших, только топовые небожители. Там те, кто делает «достаточно хорошо» и при этом вам персонально подходит. «Ваш» человек, одним словом.
Что это значит?
Это значит, что необязательно себя корить за неидеальность во всех аспектах жизни и работы. Если вы делаете «достаточно хорошо», то обязательно для вас найдется местечко, где вы будете «своим». И там вам будет хорошо.
А даже если и «недостаточно хорошо» делаете, то по-любому тоже что-то подвернется, только с более низким качеством, так сказать.
Итог
Хочется пожелать вам и себе перестать гнобить себя за малейшие неидеальности и посоветовать хорошо подумать, что/кого вы чувствуете «своим» и где бы вас так воспринимали. Порефлексировать и стремиться туда, где будет комфортно и не будет осуждения за малейшие огрехи.
Я принес. Немного своих анонсов
Сейчас у многих выходные, но если ты – завсегдатай всяких конференций, подкастов, вебинаров и всего такого прочего, то часть выходных тратится на подготовку.
Так как я в разгаре подготовки, а многие из вас в разгаре отдыха, я решил сегодня не слать сюда чего-то такого, что прямо сейчас надо читать, смотреть, слушать, переваривать.
Я поделюсь с вами ближайшими анонсами того, над чем я сейчас работаю.
1. 15 мая сессия для Podlodka Soft Skills на тему того, что надо спрашивать работодателей при трудоустройстве. Эдакое публичное собеседование наоборот. Посмотреть описание можно тут https://podlodka.io/softcrew
2. 25 мая буду докладывать на родине своих родителей, в Новосибирске, на Codefest про разные вариации тимлидов: когда какие нужны, какими навыками должны обладать и как самим, меняя работу (а можно и не меняя), это знание использовать с толком. Описание тут https://14.codefest.ru/lecture/2484
3. Ну и продолжаю трудиться над подкастами «Кода кода» (выбрали темы, гостей, и вот-вот начнем записывать первые выпуски нового сезона) и «Три тимлида заходят в бар» (релизнули только один выпуск, но записали на самом деле про запас уже несколько).
Буду рад встречам с вами в онлайне и в офлайне.
Сейчас у многих выходные, но если ты – завсегдатай всяких конференций, подкастов, вебинаров и всего такого прочего, то часть выходных тратится на подготовку.
Так как я в разгаре подготовки, а многие из вас в разгаре отдыха, я решил сегодня не слать сюда чего-то такого, что прямо сейчас надо читать, смотреть, слушать, переваривать.
Я поделюсь с вами ближайшими анонсами того, над чем я сейчас работаю.
1. 15 мая сессия для Podlodka Soft Skills на тему того, что надо спрашивать работодателей при трудоустройстве. Эдакое публичное собеседование наоборот. Посмотреть описание можно тут https://podlodka.io/softcrew
2. 25 мая буду докладывать на родине своих родителей, в Новосибирске, на Codefest про разные вариации тимлидов: когда какие нужны, какими навыками должны обладать и как самим, меняя работу (а можно и не меняя), это знание использовать с толком. Описание тут https://14.codefest.ru/lecture/2484
3. Ну и продолжаю трудиться над подкастами «Кода кода» (выбрали темы, гостей, и вот-вот начнем записывать первые выпуски нового сезона) и «Три тимлида заходят в бар» (релизнули только один выпуск, но записали на самом деле про запас уже несколько).
Буду рад встречам с вами в онлайне и в офлайне.
Три тимлида зашли в бар (созвонились), чтобы поговорить о бесконечных созвонах
Невозможно было обойти стороной тему созвонов / встреч / митингов / синков и прочего, что можно называть как угодно, но суть остается всё та же :)
Тема эта прям сильно болит у тимлидов, менеджеров и прочих сочувствующих, но бывают команды, где у каждого разработчика тоже может быть по несколько созвонов в день каждый день.
Надеюсь, наше бухтение, лайфхаки и прибаутки по этой теме будут интересны и полезны.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут
Приятного прослушивания! Заносите в комментарии свои лайфхаки борьбы с бесчисленным множеством созвонов.
Невозможно было обойти стороной тему созвонов / встреч / митингов / синков и прочего, что можно называть как угодно, но суть остается всё та же :)
Тема эта прям сильно болит у тимлидов, менеджеров и прочих сочувствующих, но бывают команды, где у каждого разработчика тоже может быть по несколько созвонов в день каждый день.
Надеюсь, наше бухтение, лайфхаки и прибаутки по этой теме будут интересны и полезны.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут
Приятного прослушивания! Заносите в комментарии свои лайфхаки борьбы с бесчисленным множеством созвонов.
Не знаешь? Пиши доку
Когда-то я делал доклад про онбординг и там озвучивал капитанскую мысль: надо стараться по максимуму прикладывать силы новичков к генерации документации.
В чем смысл
Вы работаете в вашем проекте довольно давно. У вас есть много контекста и замыленный глаз. Когда новичок приходит в проект, ничего о нем не зная, и читает имеющуюся доку, то он очень хорошо детектит то, где непонятно или неактуально.
А еще он – представитель самой релевантной аудитории для докочитателей. Он из тех, кто не знает многих деталей и тонкостей, и идет читать доку, чтобы разобраться.
Поэтому именно он может дополнить документацию самым понятным образом.
Так что основная идея такова:
⁃ Новый человек приходит, читает. Где-то понимает, где-то не понимает.
⁃ Старшие товарищи объясняют непонятное, а он идет и дописывает.
⁃ Либо он сам разбирается и всё равно идет дописывать, ведь он же не последний приходящий сюда новичок.
⁃ Старшие товарищи подписываются на обновление документации и просто поглядывают одним глазом, чтобы там чего-то откровенно неправильного и странного не появилось.
⁃ В результате получаем регулярно пополняемую документацию на основе реальных рабочих сложностей.
Как порой бывает
Иногда я встречаю обратный подход. Люди уверены, что документацию могут писать только главные мудрецы команды.
Но разбивается обычно это о то, что главным мудрецам банально некогда доки писать, у них критические фичи горят.
А некоторым просто вломяру, ведь где небожительное написание кода, а где приземленные буковки документации (тут надо перевоспитывать)?
В итоге такие команды верят в то, что документацию написать и поддерживать некогда/невозможно.
Недавний пример
В паре команд, где я нынче менеджер, мы создавали документацию про сложный процесс, который умеют старожилы, но новички от него люто страдают.
Нашли одного инициативного старожила, который очень сильно помог побороться с проблемой чистого листа. Сгенерил базовый каркас доки, насколько смог хорошо.
А дальше новички, заходившие в этот процесс, вносили уже свои корректировки, сталкиваясь с трудностями.
Отзывы от команды были очень положительными. Особенно от тех, кто впервые заходил в этот процесс с уже более-менее готовой документацией.
А я продолжаю радоваться, периодически получая уведомления, что новые правки продолжают вноситься.
Итог
Документация нужна и важна. Её могут писать не только опытнейшие люди в команде, но и те, кто только пришел, столкнулся с непонятками и разобрался в них.
Это очень дешевый и регулярный способ пополнения и актуализации имеющейся у вас документации.
Когда-то я делал доклад про онбординг и там озвучивал капитанскую мысль: надо стараться по максимуму прикладывать силы новичков к генерации документации.
В чем смысл
Вы работаете в вашем проекте довольно давно. У вас есть много контекста и замыленный глаз. Когда новичок приходит в проект, ничего о нем не зная, и читает имеющуюся доку, то он очень хорошо детектит то, где непонятно или неактуально.
А еще он – представитель самой релевантной аудитории для докочитателей. Он из тех, кто не знает многих деталей и тонкостей, и идет читать доку, чтобы разобраться.
Поэтому именно он может дополнить документацию самым понятным образом.
Так что основная идея такова:
⁃ Новый человек приходит, читает. Где-то понимает, где-то не понимает.
⁃ Старшие товарищи объясняют непонятное, а он идет и дописывает.
⁃ Либо он сам разбирается и всё равно идет дописывать, ведь он же не последний приходящий сюда новичок.
⁃ Старшие товарищи подписываются на обновление документации и просто поглядывают одним глазом, чтобы там чего-то откровенно неправильного и странного не появилось.
⁃ В результате получаем регулярно пополняемую документацию на основе реальных рабочих сложностей.
Как порой бывает
Иногда я встречаю обратный подход. Люди уверены, что документацию могут писать только главные мудрецы команды.
Но разбивается обычно это о то, что главным мудрецам банально некогда доки писать, у них критические фичи горят.
А некоторым просто вломяру, ведь где небожительное написание кода, а где приземленные буковки документации (тут надо перевоспитывать)?
В итоге такие команды верят в то, что документацию написать и поддерживать некогда/невозможно.
Недавний пример
В паре команд, где я нынче менеджер, мы создавали документацию про сложный процесс, который умеют старожилы, но новички от него люто страдают.
Нашли одного инициативного старожила, который очень сильно помог побороться с проблемой чистого листа. Сгенерил базовый каркас доки, насколько смог хорошо.
А дальше новички, заходившие в этот процесс, вносили уже свои корректировки, сталкиваясь с трудностями.
Отзывы от команды были очень положительными. Особенно от тех, кто впервые заходил в этот процесс с уже более-менее готовой документацией.
А я продолжаю радоваться, периодически получая уведомления, что новые правки продолжают вноситься.
Итог
Документация нужна и важна. Её могут писать не только опытнейшие люди в команде, но и те, кто только пришел, столкнулся с непонятками и разобрался в них.
Это очень дешевый и регулярный способ пополнения и актуализации имеющейся у вас документации.
Я принес. Иногда лучше делать, а не планировать
Сегодня на повестке дня довольно спорная, на мой взгляд, статья https://habr.com/ru/companies/ruvds/articles/788920/
Статья, кстати, бешено заплюсована на хабре.
Моё личное мнение такое: в статье есть довольно инфантильно-популистская часть про то, что, грубо говоря, менеджеры не нужны, они паразиты и вообще только усложняют работу, гады такие.
Я работал и работником руками (сисадмином, разработчиком), и менеджером (тимлидом, техническим менеджером проектов), и я своими глазами видел, как без разумного менеджмента происходящего всё может пойти сильно не так, а проекты развалиться, не дожив до релиза. Так что в этом пункте я не соглашусь.
Однако соглашусь в том, что бюрократизация может выходить из разумных пределов, и люди тратят больше времени и денег на согласования формулировки одного названия или предложения, чем уже сели бы да сделали на уровне «достаточно хорошо» или даже «удовлетворительно».
Про «политику» в офисно-корпоративных историях тоже скорее соглашусь. Нередко на позициях тимлида и выше уже приходится в этом как-то хотя бы минимально участвовать, либо утыкаться в стеклянный карьерный потолок, либо и вовсе прослыть нелояльным и отправиться на мороз.
Интересно будет в комментариях прочитать ваше мнение о данной статье.
Сегодня на повестке дня довольно спорная, на мой взгляд, статья https://habr.com/ru/companies/ruvds/articles/788920/
Статья, кстати, бешено заплюсована на хабре.
Моё личное мнение такое: в статье есть довольно инфантильно-популистская часть про то, что, грубо говоря, менеджеры не нужны, они паразиты и вообще только усложняют работу, гады такие.
Я работал и работником руками (сисадмином, разработчиком), и менеджером (тимлидом, техническим менеджером проектов), и я своими глазами видел, как без разумного менеджмента происходящего всё может пойти сильно не так, а проекты развалиться, не дожив до релиза. Так что в этом пункте я не соглашусь.
Однако соглашусь в том, что бюрократизация может выходить из разумных пределов, и люди тратят больше времени и денег на согласования формулировки одного названия или предложения, чем уже сели бы да сделали на уровне «достаточно хорошо» или даже «удовлетворительно».
Про «политику» в офисно-корпоративных историях тоже скорее соглашусь. Нередко на позициях тимлида и выше уже приходится в этом как-то хотя бы минимально участвовать, либо утыкаться в стеклянный карьерный потолок, либо и вовсе прослыть нелояльным и отправиться на мороз.
Интересно будет в комментариях прочитать ваше мнение о данной статье.
Хабр
Иногда лучше делать, а не планировать
Пожилой рабочий на строительстве «Эмпайр-стейт-билдинг» в 1930 г., источник . Вся стройка от подготовки стройплощадки до торжественного запуска лифтов заняла 410 дней В последнее время часто...
CAP-теорема тимлидов
Недавно мы с Серафимой Чекулаевой готовили контент для совместного вебинара в KOTELOV подкасте на тему взаимодействия тимлидов и продактов.
В ходе разговора Серафима сказала, что она будучи продактом, ценила в тимлидах три вещи: пипл-менеджмент, техническую компетентность и процессно-проектную деятельность. Но при этом она больше двух вещей не ожидала никогда.
Я подумал: «Черт возьми, это же CAP-теорема, но про тимлидов» 🙂
Ты чего, дед, какая теорема?
Есть такая идея, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных, доступность, устойчивость к фрагментации.
Ну то есть имеются три стула, на все три не сядешь, на два можно. А какие два нужны именно вам, следует подбирать по вашей ситуации.
Тимлиды
То же самое и с тимлидами. Хочется, чтобы они всё сразу умели, хотели и делали. Но в реальности полный набор навыков еще поди найди у человека, а даже если и нашел, то появляется классическая ситуация, когда 80% времени надо код писать и 80% времени заниматься менеджментом.
Так что можно проектировать нанимаемого тимлида (или себя самого, если угодно) согласно CAP-теореме для тимлидов.
Понимаем, что за команда, чего не хватает, какие уже есть люди и компетенции в команде, и недостающие вещи дотягиваем тимлидом. Эта методика хорошо разрешает вопросы типа «А вот бывает техлид и тимлид. Кто из них что делает?». Техлид будет за технику и архитектуру, а тимлид – за внутренние и внешние коммуникации, ведения проектов, организацию рабочих процессов.
Если в команде нет сильных технарей, тимлид будет покрывать техническую составляющую и на сдачу как-то поддерживать либо внутренние коммуникации между людьми, либо организацию и контроль комплексного ведения проектов, чтобы четенько, в срок, прозрачно, понятно для внешнего наблюдателя.
В общем, смысл вы, надеюсь, поняли.
А ты кто?
Я бывал в разных комбинациях. В данный момент я про людей и процессы/проекты, работаю с очень сильными технарями.
На прошлой работе был больше про разработку, а баланс между людьми и процессами варьировал в зависимости от того, что сильнее болит. Сначала болели (можно сказать, отсутствовали) процессы и занимался ими. Потом перестали болеть и я больше уделял внимание пипл-менеджменту.
Потом стало казаться, что пипл-менеджмент и процессы/проекты приносят больше глобального профита, поэтому от техники стал отходить постепенно.
Все три стула сразу
На мой взгляд, такое возможно исключительно в том случае, когда они маленькие. То есть маленькая команда (2-3 человека) и небольшой набор проектов (чтобы не рваться по разным сторонам).
Ну либо когда человек работает по 10-12 часов в день. Но тут у меня есть опасения по поводу долгосрочной перспективы, а также его мотивации и здоровья. Да и качество с такими регулярными овертаймами обычно хромает.
Итог
Забавная отсылка к оригинальной CAP-теореме заставляет задуматься: «Сам я на каких стульях сижу? А хочу на каких сидеть?».
Пишите в комментариях, на каких стульях сидите вы. А если на всех трех сразу, и у вас это замечательно получается, то делитесь секретами успеха и продуктивности!
Недавно мы с Серафимой Чекулаевой готовили контент для совместного вебинара в KOTELOV подкасте на тему взаимодействия тимлидов и продактов.
В ходе разговора Серафима сказала, что она будучи продактом, ценила в тимлидах три вещи: пипл-менеджмент, техническую компетентность и процессно-проектную деятельность. Но при этом она больше двух вещей не ожидала никогда.
Я подумал: «Черт возьми, это же CAP-теорема, но про тимлидов» 🙂
Ты чего, дед, какая теорема?
Есть такая идея, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных, доступность, устойчивость к фрагментации.
Ну то есть имеются три стула, на все три не сядешь, на два можно. А какие два нужны именно вам, следует подбирать по вашей ситуации.
Тимлиды
То же самое и с тимлидами. Хочется, чтобы они всё сразу умели, хотели и делали. Но в реальности полный набор навыков еще поди найди у человека, а даже если и нашел, то появляется классическая ситуация, когда 80% времени надо код писать и 80% времени заниматься менеджментом.
Так что можно проектировать нанимаемого тимлида (или себя самого, если угодно) согласно CAP-теореме для тимлидов.
Понимаем, что за команда, чего не хватает, какие уже есть люди и компетенции в команде, и недостающие вещи дотягиваем тимлидом. Эта методика хорошо разрешает вопросы типа «А вот бывает техлид и тимлид. Кто из них что делает?». Техлид будет за технику и архитектуру, а тимлид – за внутренние и внешние коммуникации, ведения проектов, организацию рабочих процессов.
Если в команде нет сильных технарей, тимлид будет покрывать техническую составляющую и на сдачу как-то поддерживать либо внутренние коммуникации между людьми, либо организацию и контроль комплексного ведения проектов, чтобы четенько, в срок, прозрачно, понятно для внешнего наблюдателя.
В общем, смысл вы, надеюсь, поняли.
А ты кто?
Я бывал в разных комбинациях. В данный момент я про людей и процессы/проекты, работаю с очень сильными технарями.
На прошлой работе был больше про разработку, а баланс между людьми и процессами варьировал в зависимости от того, что сильнее болит. Сначала болели (можно сказать, отсутствовали) процессы и занимался ими. Потом перестали болеть и я больше уделял внимание пипл-менеджменту.
Потом стало казаться, что пипл-менеджмент и процессы/проекты приносят больше глобального профита, поэтому от техники стал отходить постепенно.
Все три стула сразу
На мой взгляд, такое возможно исключительно в том случае, когда они маленькие. То есть маленькая команда (2-3 человека) и небольшой набор проектов (чтобы не рваться по разным сторонам).
Ну либо когда человек работает по 10-12 часов в день. Но тут у меня есть опасения по поводу долгосрочной перспективы, а также его мотивации и здоровья. Да и качество с такими регулярными овертаймами обычно хромает.
Итог
Забавная отсылка к оригинальной CAP-теореме заставляет задуматься: «Сам я на каких стульях сижу? А хочу на каких сидеть?».
Пишите в комментариях, на каких стульях сидите вы. А если на всех трех сразу, и у вас это замечательно получается, то делитесь секретами успеха и продуктивности!
Я принес. Что такое жизнь без работы и что такое работа после саббатикала?
Пару месяцев назад мы с коллегами делали митап в Питере на тему «Как быть счастливым на работе?».
Сегодня хочу поделиться с вами одним из докладов митапа на очень интересную тему https://www.youtube.com/watch?v=vURgYlDurxk
У многих моих знакомых идея того, чтобы долго (год и дольше) не работать, вызывает совершенно разные мнения:
⁃ Ну и правильно, от работы кони дохнут!
⁃ Я совершенно точно не могу не работать, вы чего?
⁃ Наконец-то доиграю, дочитаю, досмотрю всё накопленное.
⁃ Займусь чем-то общественно полезным.
⁃ Бизнесок свой, давно задуманный, замучу.
Мнения представлять можно разные, но мало кто реально в такой долгосрочный саббатикал ходил. А тут вот можно послушать реальную историю.
Лично для меня в этой истории почему-то очень ярко отложилось то, как у докладчика изменился уровень потребления.
Когда перерабатывал, то потреблял больше и дороже, как бы награждая себя за это своё старание и страдание. А когда перестал в этой суете крутиться, успокоился, то отказалось этого всего и не надо уже.
А был ли у вас опыт, когда вы полгода-год не работали? Что делали? Как впечатления? А если бы сейчас так можно было, чем бы занялись?
Пару месяцев назад мы с коллегами делали митап в Питере на тему «Как быть счастливым на работе?».
Сегодня хочу поделиться с вами одним из докладов митапа на очень интересную тему https://www.youtube.com/watch?v=vURgYlDurxk
У многих моих знакомых идея того, чтобы долго (год и дольше) не работать, вызывает совершенно разные мнения:
⁃ Ну и правильно, от работы кони дохнут!
⁃ Я совершенно точно не могу не работать, вы чего?
⁃ Наконец-то доиграю, дочитаю, досмотрю всё накопленное.
⁃ Займусь чем-то общественно полезным.
⁃ Бизнесок свой, давно задуманный, замучу.
Мнения представлять можно разные, но мало кто реально в такой долгосрочный саббатикал ходил. А тут вот можно послушать реальную историю.
Лично для меня в этой истории почему-то очень ярко отложилось то, как у докладчика изменился уровень потребления.
Когда перерабатывал, то потреблял больше и дороже, как бы награждая себя за это своё старание и страдание. А когда перестал в этой суете крутиться, успокоился, то отказалось этого всего и не надо уже.
А был ли у вас опыт, когда вы полгода-год не работали? Что делали? Как впечатления? А если бы сейчас так можно было, чем бы занялись?
YouTube
Что такое жизнь без работы и что такое работа после саббатикала? \ Олег Смоляков, Яндекс
В этом докладе мы рассмотрим саббатикал как проект и поговорим о том, как я пришёл к такому решению, почему просто не уволился, как объяснил руководителю, что ухожу, но вернусь (и как меня отпустили).
А ещё разберёмся со страхами вокруг саббатикала: надо…
А ещё разберёмся со страхами вокруг саббатикала: надо…
Перформанс ревью. Плюсы, минусы, подводные камни
В этом выпуске мы поговорили на животрепещущую для бигтехов тему – перформанс ревью.
Вокруг этого процесса куча споров. Много и сторонников, и противников.
Тем не менее, это практически стандартная процедура для многих крупных компаний, так что разбираться точно надо.
Я специально постарался поднакинуть для драматизма, но мои товарищи неплохо это всё отбили :)
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Приносите в комментарии свою трактовку плюсов и минусов ревью. Всегда интересно узнавать чужой опыт и мысли.
В этом выпуске мы поговорили на животрепещущую для бигтехов тему – перформанс ревью.
Вокруг этого процесса куча споров. Много и сторонников, и противников.
Тем не менее, это практически стандартная процедура для многих крупных компаний, так что разбираться точно надо.
Я специально постарался поднакинуть для драматизма, но мои товарищи неплохо это всё отбили :)
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Приносите в комментарии свою трактовку плюсов и минусов ревью. Всегда интересно узнавать чужой опыт и мысли.
Крыша потекла
Сегодня мой пост будет основываться на картинке, в которой многие из нас могут узнать себя.
Крыша прохудилась, но Хаггис её не чинит. В дождь слишком мокро, чтобы работать, а в солнечную погоду дыра в крыше не так уж и беспокоит.
Техдолг, рефакторинг и улучшалки
Когда мы в разгаре производства крупных фичей или приближающихся дедлайнов, наступаем на какие-то грабли, которые клятвенно обещаем себе поправить потом, когда гореть перестанет.
Но случаются релизы, шумные и расслабленные выдохи, и мы говорим себе: «Ну вроде как-то и так прожили. Щас бы отдохнуть. Может, потом уже и не пригодится это». И не делаем. А потом колесо сансары делает свой оборот, и всё начинается заново.
Причем этим страдают и менеджеры, и инженеры.
Что делать?
У меня на многое один ответ – дисциплина. Это вы уже могли понять по тому, как я пятый год каждую пятницу без пропусков посты делаю 🙂
Если вы точно знаете, что делать надо, но малодушно не делаете, потому что «чет неохота сейчас», «мне бы что-то поинтереснее», «да может, пронесет в следующий раз», то тут хорошо работает бэклог, напоминалки, дедлайны и вообще планирование, чтобы не плыть просто по течению и желанию левой пятки.
Другое дело, что надо и правда быть уверенным, что что-то делать надо. В пылу задач и проблем вам может что-то показаться, вас триггернуло и про это завели задачу. Но потом с уже остывшей головой и другими частями тела лучше бы менее эмоционально к этому вернуться и понять, а точно ли оно нужно. Сделать дополнительный подход валидации.
Например
Был у меня случай, когда требовалось на куче серверов не самым легким образом ПО обновить, но было некогда, мы пилили новые фичи и страдали. Однако когда крупный релиз был закончен, мы всё же обновились, и это оказалось не зря, потому что дальше пошел разгар другого проекта, начали появляться в публичном поле всякие критические уязвимости. Если бы мы не обновились в межсезонье, то пришлось бы в горячий сезон ставить всё на стоп и обновляться.
А был обратный пример, когда разок наткнулись на проблему, нашли обходной путь, фичу запилили. Но инженерное негодование вскипело, решили делать большой рефакторинг. Делали-делали, а оказалось, что проектом заниматься некому, он заморожен, и вообще впустую время потратили.
Итог
Дисциплина помогает делать то, что надо делать, а не только то, что хочется делать.
Но должна быть и рациональная переоценка после того, как эмоционально пригорело, чтобы не сделать лишнего.
Сегодня мой пост будет основываться на картинке, в которой многие из нас могут узнать себя.
Крыша прохудилась, но Хаггис её не чинит. В дождь слишком мокро, чтобы работать, а в солнечную погоду дыра в крыше не так уж и беспокоит.
Техдолг, рефакторинг и улучшалки
Когда мы в разгаре производства крупных фичей или приближающихся дедлайнов, наступаем на какие-то грабли, которые клятвенно обещаем себе поправить потом, когда гореть перестанет.
Но случаются релизы, шумные и расслабленные выдохи, и мы говорим себе: «Ну вроде как-то и так прожили. Щас бы отдохнуть. Может, потом уже и не пригодится это». И не делаем. А потом колесо сансары делает свой оборот, и всё начинается заново.
Причем этим страдают и менеджеры, и инженеры.
Что делать?
У меня на многое один ответ – дисциплина. Это вы уже могли понять по тому, как я пятый год каждую пятницу без пропусков посты делаю 🙂
Если вы точно знаете, что делать надо, но малодушно не делаете, потому что «чет неохота сейчас», «мне бы что-то поинтереснее», «да может, пронесет в следующий раз», то тут хорошо работает бэклог, напоминалки, дедлайны и вообще планирование, чтобы не плыть просто по течению и желанию левой пятки.
Другое дело, что надо и правда быть уверенным, что что-то делать надо. В пылу задач и проблем вам может что-то показаться, вас триггернуло и про это завели задачу. Но потом с уже остывшей головой и другими частями тела лучше бы менее эмоционально к этому вернуться и понять, а точно ли оно нужно. Сделать дополнительный подход валидации.
Например
Был у меня случай, когда требовалось на куче серверов не самым легким образом ПО обновить, но было некогда, мы пилили новые фичи и страдали. Однако когда крупный релиз был закончен, мы всё же обновились, и это оказалось не зря, потому что дальше пошел разгар другого проекта, начали появляться в публичном поле всякие критические уязвимости. Если бы мы не обновились в межсезонье, то пришлось бы в горячий сезон ставить всё на стоп и обновляться.
А был обратный пример, когда разок наткнулись на проблему, нашли обходной путь, фичу запилили. Но инженерное негодование вскипело, решили делать большой рефакторинг. Делали-делали, а оказалось, что проектом заниматься некому, он заморожен, и вообще впустую время потратили.
Итог
Дисциплина помогает делать то, что надо делать, а не только то, что хочется делать.
Но должна быть и рациональная переоценка после того, как эмоционально пригорело, чтобы не сделать лишнего.
Я принес. Пучок подкастов
Я в шутку называю себя подкастологом, потому что слушаю и смотрю несколько десятков разных ИТ-подкастов. А еще и два подкаста веду в компании своих товарищей.
Я начал увлекаться подкастами году в 2013-м. Капец, больше десяти лет прошло. Для меня это было окно в разные увлекательные и полезные идеи и новости из индустрии. Пожалуй, для меня подкасты даже интереснее, чем доклады на конференциях (хотя я не умаляю их важность).
Так что у меня есть чем с вами поделиться сегодня.
Олдовое
Еще в 2020-м году я писал пост/тред про подкасты.
Аудио подкасты
К посту я прикреплю два скрина (в один не влезает) из Pocket Casts со списком аудио подкастов, которые я слушаю.
Пока скринил, проверил подкасты на активность и с сожалением обнаружил, что многие клевые подкасты перестали быть активны во второй половине прошлого года.
Папка с миксом
Папка в телеграме с миксом активных аудио и видео подкастов https://www.tg-me.com/addlist/PCvdlc8oAE80NmEy
Я в шутку называю себя подкастологом, потому что слушаю и смотрю несколько десятков разных ИТ-подкастов. А еще и два подкаста веду в компании своих товарищей.
Я начал увлекаться подкастами году в 2013-м. Капец, больше десяти лет прошло. Для меня это было окно в разные увлекательные и полезные идеи и новости из индустрии. Пожалуй, для меня подкасты даже интереснее, чем доклады на конференциях (хотя я не умаляю их важность).
Так что у меня есть чем с вами поделиться сегодня.
Олдовое
Еще в 2020-м году я писал пост/тред про подкасты.
Аудио подкасты
К посту я прикреплю два скрина (в один не влезает) из Pocket Casts со списком аудио подкастов, которые я слушаю.
Пока скринил, проверил подкасты на активность и с сожалением обнаружил, что многие клевые подкасты перестали быть активны во второй половине прошлого года.
Папка с миксом
Папка в телеграме с миксом активных аудио и видео подкастов https://www.tg-me.com/addlist/PCvdlc8oAE80NmEy
Попугай-менеджмент
Многие знают про чайка-менеджмент – это когда прилетел, покричал, навалил кучу… задач и улетел.
А попугай-менеджмент – это отсылка к распространенному анекдоту про то, что попугай научился говорить: «Какой статус по этой задаче?» – и стал ПМом (проектным менеджером).
И вроде ха-ха, дурацкая и легкая работенка, ходить и всех задалбывать этими вопросами. Но не всё так просто.
На работе
Конечно, мы сейчас выносим за скобки планирование, менеджмент процессов, приоритизацию, слаженную работу между апстримом и даунстримом, риск-менеджмент и прочее. Просто говорим про работу попугаем.
Так вот, когда я был тимлидом одной команды и в её задачах варился, я смеялся над этим анекдотом и плакал от смеха. Но чем больше становилось у меня команд, чем больше становилось таких проектов, где затронуто много внешних команд, тем больше я стал плакать не от смеха, а от жизы.
Иногда и правда бывает, что крутые специалисты делают сложные вещи, но как только дело касается обязательств и коннекта со смежниками, там может случиться ступор, забывчивость, рассинхрон и прочее.
И вот летаешь как попугай и говоришь: «Вы тут до финального решения договорились? Нет? Ну тогда договоритесь». И так несколько итераций, пока договора не случится.
Это нудно, но порой необходимо, чтобы что-то хорошее всё же в итоге случилось. Так что ничего зазорного в этом нет.
Смотрел недавно одно видео, где девушка, проработавшая 10 лет в «Маккинзи», а ныне СЕО клиник «Скандинавия», рассказывала, что у неё есть принцип семи раз. То есть семь раз надо повторить одно и то же, чтобы из ничего случилось что-то. Я её хорошо понимаю 🙂
В жизни
Я уже рассказывал, что делаю сейчас капитальный ремонт в квартире. И со строителями только попугай-менеджмент и работает (ну еще не платить денег, если они вконец оборзели, но это другая история).
Вот реально как с золотыми рыбками говоришь. Дизайн-проект дал, всё объяснил, покивали, а сделали не так. Только многократное объяснение дает хоть какое-то повышение шанса, что сделают так, как надо, а не так, как фляга просвистела.
И вот вроде не хочется таким со взрослыми людьми заниматься, но получается, что не быть попугаем – вредить себе же. Это у меня в квартире в итоге плохо будет. А строителям-то пофигу, они на другие объекты пойдут работать. Интересная корреляция с некоторым пластом айтишников (неважно, разработчиков или менеджеров) даже вырисовывается 🙂
Итог
Быть попугаем – это нудно. Грустно, что со взрослыми людьми и крутыми профессионалами так работать иногда приходится. Но кажется, что в жизни в целом так работает частенько, и не стоит надеяться, что везде будут попадаться исполнители, коллеги и друзья такие, что никогда этим заниматься не придется.
Многие знают про чайка-менеджмент – это когда прилетел, покричал, навалил кучу… задач и улетел.
А попугай-менеджмент – это отсылка к распространенному анекдоту про то, что попугай научился говорить: «Какой статус по этой задаче?» – и стал ПМом (проектным менеджером).
И вроде ха-ха, дурацкая и легкая работенка, ходить и всех задалбывать этими вопросами. Но не всё так просто.
На работе
Конечно, мы сейчас выносим за скобки планирование, менеджмент процессов, приоритизацию, слаженную работу между апстримом и даунстримом, риск-менеджмент и прочее. Просто говорим про работу попугаем.
Так вот, когда я был тимлидом одной команды и в её задачах варился, я смеялся над этим анекдотом и плакал от смеха. Но чем больше становилось у меня команд, чем больше становилось таких проектов, где затронуто много внешних команд, тем больше я стал плакать не от смеха, а от жизы.
Иногда и правда бывает, что крутые специалисты делают сложные вещи, но как только дело касается обязательств и коннекта со смежниками, там может случиться ступор, забывчивость, рассинхрон и прочее.
И вот летаешь как попугай и говоришь: «Вы тут до финального решения договорились? Нет? Ну тогда договоритесь». И так несколько итераций, пока договора не случится.
Это нудно, но порой необходимо, чтобы что-то хорошее всё же в итоге случилось. Так что ничего зазорного в этом нет.
Смотрел недавно одно видео, где девушка, проработавшая 10 лет в «Маккинзи», а ныне СЕО клиник «Скандинавия», рассказывала, что у неё есть принцип семи раз. То есть семь раз надо повторить одно и то же, чтобы из ничего случилось что-то. Я её хорошо понимаю 🙂
В жизни
Я уже рассказывал, что делаю сейчас капитальный ремонт в квартире. И со строителями только попугай-менеджмент и работает (ну еще не платить денег, если они вконец оборзели, но это другая история).
Вот реально как с золотыми рыбками говоришь. Дизайн-проект дал, всё объяснил, покивали, а сделали не так. Только многократное объяснение дает хоть какое-то повышение шанса, что сделают так, как надо, а не так, как фляга просвистела.
И вот вроде не хочется таким со взрослыми людьми заниматься, но получается, что не быть попугаем – вредить себе же. Это у меня в квартире в итоге плохо будет. А строителям-то пофигу, они на другие объекты пойдут работать. Интересная корреляция с некоторым пластом айтишников (неважно, разработчиков или менеджеров) даже вырисовывается 🙂
Итог
Быть попугаем – это нудно. Грустно, что со взрослыми людьми и крутыми профессионалами так работать иногда приходится. Но кажется, что в жизни в целом так работает частенько, и не стоит надеяться, что везде будут попадаться исполнители, коллеги и друзья такие, что никогда этим заниматься не придется.
Я принес. Публичное собеседование: Как собеседовать работодателя
Недавно моя коллега и товарищ по подкасту Настя Абрашитова позвала меня провести сессию на мною любимой Podlodka Soft Skills Crew.
Тема этого сезона была про собеседования, смену работы и всё такое прочее. Сосредоточились на том, что спрашивать у работодателя на собеседованиях.
А мне вроде рассказать про это уже и нечего. Статью на Хабре писал, в круглом столе тимлидской подлодке версию для тимлидов тоже уже предлагал. Однако мы вспомнили, что сейчас в моде публичные собеседования)
В итоге я заготовил вопросов на роль бэкендера, а Настя заготовила образ мутного работодателя, из которого надо было эту мутноту выспросить. Расставила там ловушки и пасхалки. Большинство я нашел, но немного и пропустил.
Мне кажется, было и забавно, и поучительно.
Напоминаю, что на собеседованиях вы тоже можете и должны задавать вопросы работодателю, и эти вопросы надо подготовить. Надеюсь, данное видео и сопроводительные ссылки в описании вам помогут в этом деле.
https://www.youtube.com/watch?v=x-duHH6AIQk
Недавно моя коллега и товарищ по подкасту Настя Абрашитова позвала меня провести сессию на мною любимой Podlodka Soft Skills Crew.
Тема этого сезона была про собеседования, смену работы и всё такое прочее. Сосредоточились на том, что спрашивать у работодателя на собеседованиях.
А мне вроде рассказать про это уже и нечего. Статью на Хабре писал, в круглом столе тимлидской подлодке версию для тимлидов тоже уже предлагал. Однако мы вспомнили, что сейчас в моде публичные собеседования)
В итоге я заготовил вопросов на роль бэкендера, а Настя заготовила образ мутного работодателя, из которого надо было эту мутноту выспросить. Расставила там ловушки и пасхалки. Большинство я нашел, но немного и пропустил.
Мне кажется, было и забавно, и поучительно.
Напоминаю, что на собеседованиях вы тоже можете и должны задавать вопросы работодателю, и эти вопросы надо подготовить. Надеюсь, данное видео и сопроводительные ссылки в описании вам помогут в этом деле.
https://www.youtube.com/watch?v=x-duHH6AIQk
YouTube
Публичное собеседование: Как собеседовать работодателя / Евгений Антонов (Yandex Infrastructure)
Собеседование - это не только когда вас спрашивают, а вы отвечаете.
Совершенно нормально и правильно тоже задавать вопросы.
Ведь выбор места работы – важное и ответственное дело. Поэтому надо постараться разузнать о предлагаемой работе побольше.
На этой…
Совершенно нормально и правильно тоже задавать вопросы.
Ведь выбор места работы – важное и ответственное дело. Поэтому надо постараться разузнать о предлагаемой работе побольше.
На этой…
Три тимлида заходят в бар и обсуждают дружбу на работе
В кругах тимлидов и прочих руководителей вечно ходят споры про то, насколько можно и нужно дружить с теми, кто находится под твоим руководством.
Тема эта неоднозначная, и, лично мне кажется, что ответы на неё будут ощутимо разные в зависимости от твоей высоты и иерархии.
То есть будет ощутимая разница между тимлидом и мидл-менеджером.
Послушав наш сегодняшний выпуск, вы в некоторой мере сможете в этом убедиться, ведь у нас есть и мидл-менеджеры, и тимлид+, так я себя назову по совокупности причин.
А еще вы узнаете: как ведущие подкаста сохраняют товарищеские отношения, находясь в рабочих отношениях, в чем заключается принцип шашлык-лидершип и прочее интересное.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Рассказывайте в комментариях, насколько дружны или формалистичный ваши отношения с коллегами.
В кругах тимлидов и прочих руководителей вечно ходят споры про то, насколько можно и нужно дружить с теми, кто находится под твоим руководством.
Тема эта неоднозначная, и, лично мне кажется, что ответы на неё будут ощутимо разные в зависимости от твоей высоты и иерархии.
То есть будет ощутимая разница между тимлидом и мидл-менеджером.
Послушав наш сегодняшний выпуск, вы в некоторой мере сможете в этом убедиться, ведь у нас есть и мидл-менеджеры, и тимлид+, так я себя назову по совокупности причин.
А еще вы узнаете: как ведущие подкаста сохраняют товарищеские отношения, находясь в рабочих отношениях, в чем заключается принцип шашлык-лидершип и прочее интересное.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Рассказывайте в комментариях, насколько дружны или формалистичный ваши отношения с коллегами.
Алгоритмизация: время- и нервосбережение
Раньше, когда нам с женой надо было куда-то полететь/поехать на несколько дней/недель, приходилось очень много времени тратить на подготовку. Долго собирались, могли что-то забыть, постоянно были в нервном напряжении, гоняя в голове то, что могли упустить.
Теперь же мы стали это делать намного быстрее и намного спокойнее. В последние разы даже собрались настолько быстро, что первое время относились с подозрением. Это как, когда код написал, а он сразу заработал и все тесты прошли:)
Как так?
Заколебались при сборах каждый раз начинать с нуля и придумали инструкцию/чеклист, что нужно собрать из вещей, что нужно иметь в дорожной аптечке, что проверить на выключенность перед выходом из дома (привет соседям, заливающим и оставляющим без воды других, пока отдыхают на даче без связи).
Чем это еще хорошо?
Недавно где-то читал, как подобная алгоритмизация способствует душевному спокойствию.
Не надо сталкиваться с неопределенностью, испытывать из-за этого тревогу, заниматься бесконечной хаотичной перепроверкой. Всё максимально детерминировано. Знай себе проходись по всем пунктам, а дальше занимайся спокойно своими делами.
Лично я с этим очень согласен. Для мутных вещей с множеством мелочей алгоритмизация меня сильно успокаивает.
А в работе как у меня?
Мне кажется, что я со своей методикой постепенной регулярной работы тоже пытаюсь добавить себе спокойствия в этом хаосе.
Я ежедневно откусываю небольшой кусочек от нужного направления и спокойно живу дальше, зная, что каждый день я потихоньку это буду делать и какого-то приемлемого результата добьюсь.
Лично мне так намного спокойнее, чем то наскоком делать, то окукливаться после спурта, то прокрастинировать в надежде на последний момент.
Так это ж всё очевидно!
Я иногда выныриваю из айтишного пузыря, где множество начитанных про успешный успех, тайм-менеджмент и 87 навыков высокоэффективных людей. И если в нашем пузыре никого не удивишь базовыми чеклистами, тудушными инструментами и всем таким, то снаружи вижу всякое: лютейшие откровения про то, что можно вести список дел и перестать забывать, или ставить уведомлялки-напоминалки на конкретное время, или писать инструкции для коллег, чтобы они сделали то, что надо, а не то, что боженька на душу положит.
Это я не к тому, что айтишники какие-то небожители. И у нас хватает разгильдяев, и снаружи хватает организованных. А к тому, что очевидные простецкие штуки для вас могут оказаться полезными для некоторых ваших товарищей и близких. Так что не стесняйтесь делиться, и не думайте, что если вам это очевидно, то и другим будет очевидно тоже.
Итог
Алгоритмы и чеклисты сильно экономят время и нервы, являются небольшими островками душевного спокойствия и безопасности.
Делитесь со своими товарищами очевидными полезностями, ведь может оказаться, что для них это неочевидно.
Поделитесь в комментариях своим опытом использования инструкций и чеклистов для быта или работы, которые вам сильно помогают. Хочется чего-то интересного для себя на ус намотать.
Раньше, когда нам с женой надо было куда-то полететь/поехать на несколько дней/недель, приходилось очень много времени тратить на подготовку. Долго собирались, могли что-то забыть, постоянно были в нервном напряжении, гоняя в голове то, что могли упустить.
Теперь же мы стали это делать намного быстрее и намного спокойнее. В последние разы даже собрались настолько быстро, что первое время относились с подозрением. Это как, когда код написал, а он сразу заработал и все тесты прошли:)
Как так?
Заколебались при сборах каждый раз начинать с нуля и придумали инструкцию/чеклист, что нужно собрать из вещей, что нужно иметь в дорожной аптечке, что проверить на выключенность перед выходом из дома (привет соседям, заливающим и оставляющим без воды других, пока отдыхают на даче без связи).
Чем это еще хорошо?
Недавно где-то читал, как подобная алгоритмизация способствует душевному спокойствию.
Не надо сталкиваться с неопределенностью, испытывать из-за этого тревогу, заниматься бесконечной хаотичной перепроверкой. Всё максимально детерминировано. Знай себе проходись по всем пунктам, а дальше занимайся спокойно своими делами.
Лично я с этим очень согласен. Для мутных вещей с множеством мелочей алгоритмизация меня сильно успокаивает.
А в работе как у меня?
Мне кажется, что я со своей методикой постепенной регулярной работы тоже пытаюсь добавить себе спокойствия в этом хаосе.
Я ежедневно откусываю небольшой кусочек от нужного направления и спокойно живу дальше, зная, что каждый день я потихоньку это буду делать и какого-то приемлемого результата добьюсь.
Лично мне так намного спокойнее, чем то наскоком делать, то окукливаться после спурта, то прокрастинировать в надежде на последний момент.
Так это ж всё очевидно!
Я иногда выныриваю из айтишного пузыря, где множество начитанных про успешный успех, тайм-менеджмент и 87 навыков высокоэффективных людей. И если в нашем пузыре никого не удивишь базовыми чеклистами, тудушными инструментами и всем таким, то снаружи вижу всякое: лютейшие откровения про то, что можно вести список дел и перестать забывать, или ставить уведомлялки-напоминалки на конкретное время, или писать инструкции для коллег, чтобы они сделали то, что надо, а не то, что боженька на душу положит.
Это я не к тому, что айтишники какие-то небожители. И у нас хватает разгильдяев, и снаружи хватает организованных. А к тому, что очевидные простецкие штуки для вас могут оказаться полезными для некоторых ваших товарищей и близких. Так что не стесняйтесь делиться, и не думайте, что если вам это очевидно, то и другим будет очевидно тоже.
Итог
Алгоритмы и чеклисты сильно экономят время и нервы, являются небольшими островками душевного спокойствия и безопасности.
Делитесь со своими товарищами очевидными полезностями, ведь может оказаться, что для них это неочевидно.
Поделитесь в комментариях своим опытом использования инструкций и чеклистов для быта или работы, которые вам сильно помогают. Хочется чего-то интересного для себя на ус намотать.
Я принес. Продуктивный инженер
Сегодня я вам принес выпуск подкаста DevZen, в котором очень интересно ребята обсуждают, как быть продуктивным, у кого какие привычки, лайфхаки и особенности для комфортной работы.
Я послушал полтора часа за один присест. Очень жизненная получилась дискуссия.
Не скажу, что я прям что-то новое для себя узнал. Скорее узнал подтверждения тому, что мои привычки и лайфхаки, которые я для себя вырабатывал за 17 лет в ИТ, оказались довольно схожи с мнением ребят.
Ну и в целом я довольно много таких материалов анализирую. Так что то, что мне может оказаться известным, кому-то, не так сильно интересующемуся, может и зайти в новинку, так что послушайте.
А если даже там для вас ничего нового не будет, то всё равно сложится приятное ощущение, что какую-то жизненную жизу обсудил в кругу единомышленников.
Ссылка
https://devzen.ru/episode-466/
Сегодня я вам принес выпуск подкаста DevZen, в котором очень интересно ребята обсуждают, как быть продуктивным, у кого какие привычки, лайфхаки и особенности для комфортной работы.
Я послушал полтора часа за один присест. Очень жизненная получилась дискуссия.
Не скажу, что я прям что-то новое для себя узнал. Скорее узнал подтверждения тому, что мои привычки и лайфхаки, которые я для себя вырабатывал за 17 лет в ИТ, оказались довольно схожи с мнением ребят.
Ну и в целом я довольно много таких материалов анализирую. Так что то, что мне может оказаться известным, кому-то, не так сильно интересующемуся, может и зайти в новинку, так что послушайте.
А если даже там для вас ничего нового не будет, то всё равно сложится приятное ощущение, что какую-то жизненную жизу обсудил в кругу единомышленников.
Ссылка
https://devzen.ru/episode-466/
Тимлиды, разбор кейсов и подкасты
Всё это обсудили с товарищами из KOTELOV подкаста. Вообще очень много тем собрали и так интересно было беседовать, что получился долгий выпуск.
Признаюсь честно, обсудить мы хотели ещё больше, но это уже было за гранью разумного по таймингу🙂
Я много раз записывался в разных подкастах и сам веду парочку, но обычно это всё удаленно.
А тут у ребят оказалась студия для записи в Питере, поэтому записались очно и вышли в ютубе.
В который раз убеждаюсь, что такой формат делает разговор живее и привычнее нам для восприятия. Но и сложностей для производства хватает.
Описание и ссылки на выпуск тут https://www.tg-me.com/kotelov_love/904
Всё это обсудили с товарищами из KOTELOV подкаста. Вообще очень много тем собрали и так интересно было беседовать, что получился долгий выпуск.
Признаюсь честно, обсудить мы хотели ещё больше, но это уже было за гранью разумного по таймингу🙂
Я много раз записывался в разных подкастах и сам веду парочку, но обычно это всё удаленно.
А тут у ребят оказалась студия для записи в Питере, поэтому записались очно и вышли в ютубе.
В который раз убеждаюсь, что такой формат делает разговор живее и привычнее нам для восприятия. Но и сложностей для производства хватает.
Описание и ссылки на выпуск тут https://www.tg-me.com/kotelov_love/904
Telegram
KOTELOV
Йоуу, выпуск для тимлидов 🔥
У нас в гостях Женя Антонов aka Тимлид очевидность, серийный спикер крупных конф и соведущий подкастов «Кода кода» и «Три тимлида заходят в бар».
Сейчас Женя руководит командами разработки в Яндексе в роли старшего технического…
У нас в гостях Женя Антонов aka Тимлид очевидность, серийный спикер крупных конф и соведущий подкастов «Кода кода» и «Три тимлида заходят в бар».
Сейчас Женя руководит командами разработки в Яндексе в роли старшего технического…
Трудоемкость != сроки
Недавно видел один доклад, где в шуточной форме рассказывалась жизненная история о том, что разработчики стараются максимально обтекаемо говорить о трудоемкости задачи, чтобы ни в коем случае не закоммититься на сроки.
Шутка, как говорится, смешная, а ситуация страшная. И актуальная.
И в данном посте, раз уж канал больше про менеджмент, я бы хотел обсудить недопонимание трудоемкости и сроков со стороны менеджеров/заказчиков.
Сколько нужно времени, чтобы это сделать?
Спросите вы у разработчика. И мы сейчас скипнем ситуацию (потому что в пост не влезет), когда он скажет: «Я не знаю, я этого ни разу не делал», или «Тут всё так сложно, что мы одно чиним, другое ломается», или «За день точно сделаю», а по факту безвылазно будет делать только эту задачу всю неделю.
Представим, вам ответили: «За один день можно сделать». И дальше в этот момент некоторые менеджеры или заказчики начинают ошибочно думать, что задача будет готова завтра. И вот этот один день отсчитывается с данного момента.
Но ведь это в корне не верно. Трудоемкость может быть и один день, но, возможно, сейчас человек делает другую важную задачу и не может отвлечься, или завтра он уходит в отпуск, заболевает, командируется, увольняется. Следовательно, сроки начала сдвигаются, а вот про них никто в моем примере не спросил.
Пример из жизни
Как-то мне довелось быть тимлидом в команде, где на 5 человек было 12–15 проектных направлений. И там такое недопонимание доставляло много боли.
Каждый заказчик каждого направления считал, что уж он-то важнее всего и его задачу мы готовы начинать прямо сейчас, а остальной десяток подождет. И по факту оценка трудоемкости, конечно, никак не коррелировала со сроками поставки.
Пришлось очень много времени потратить, чтобы люди поняли, что они не одни в вакууме, что команда делает сразу много по всем фронтам, что приоритеты и планы вот такие, а если хотите побыстрее, тодеритес давайте договариваться.
Особо печально, когда менеджеры, которые вроде как должны эти простейшие вещи понимать, может, их и понимают, но не принимают. Ну не хотят люди вот этих вот каких-то сложностей, не хотят принимать, что есть кто-то страждущий, кроме них, есть другие приоритеты, кроме их планов на квартал, а хотят просто магии. Хотят волшебства, чтобы вжух – и у них всё появилось, а у других хоть трава не расти. Как вы будете делать – не волнует. Можно ли так вообще физически сделать – тоже не волнует.
Не надо так.
Итог
Оценка трудоемкости – это совершенно не одно и то же, что прогноз сроков поставки. Вы должны понимать, что и зачем вы спрашиваете, чтобы правильно интерпретировать ответы, самим потом не разочаровываться и других не заколебывать.
А еще так в жизни случается, что каждый сам кузнец своего счастья. Так что, если вам даже назвали трудоемкость, время старта работ, прогноз по срокам, и для вас это что-то очень важное, то постарайтесь вместе с исполнителями разобраться, нет ли чего-то, вносящего риски срыва сроков: завязка на смежные команды, плохо работающего или выгоревшего сотрудника, высокую неопределенность реализации и прочее.
Недавно видел один доклад, где в шуточной форме рассказывалась жизненная история о том, что разработчики стараются максимально обтекаемо говорить о трудоемкости задачи, чтобы ни в коем случае не закоммититься на сроки.
Шутка, как говорится, смешная, а ситуация страшная. И актуальная.
И в данном посте, раз уж канал больше про менеджмент, я бы хотел обсудить недопонимание трудоемкости и сроков со стороны менеджеров/заказчиков.
Сколько нужно времени, чтобы это сделать?
Спросите вы у разработчика. И мы сейчас скипнем ситуацию (потому что в пост не влезет), когда он скажет: «Я не знаю, я этого ни разу не делал», или «Тут всё так сложно, что мы одно чиним, другое ломается», или «За день точно сделаю», а по факту безвылазно будет делать только эту задачу всю неделю.
Представим, вам ответили: «За один день можно сделать». И дальше в этот момент некоторые менеджеры или заказчики начинают ошибочно думать, что задача будет готова завтра. И вот этот один день отсчитывается с данного момента.
Но ведь это в корне не верно. Трудоемкость может быть и один день, но, возможно, сейчас человек делает другую важную задачу и не может отвлечься, или завтра он уходит в отпуск, заболевает, командируется, увольняется. Следовательно, сроки начала сдвигаются, а вот про них никто в моем примере не спросил.
Пример из жизни
Как-то мне довелось быть тимлидом в команде, где на 5 человек было 12–15 проектных направлений. И там такое недопонимание доставляло много боли.
Каждый заказчик каждого направления считал, что уж он-то важнее всего и его задачу мы готовы начинать прямо сейчас, а остальной десяток подождет. И по факту оценка трудоемкости, конечно, никак не коррелировала со сроками поставки.
Пришлось очень много времени потратить, чтобы люди поняли, что они не одни в вакууме, что команда делает сразу много по всем фронтам, что приоритеты и планы вот такие, а если хотите побыстрее, то
Особо печально, когда менеджеры, которые вроде как должны эти простейшие вещи понимать, может, их и понимают, но не принимают. Ну не хотят люди вот этих вот каких-то сложностей, не хотят принимать, что есть кто-то страждущий, кроме них, есть другие приоритеты, кроме их планов на квартал, а хотят просто магии. Хотят волшебства, чтобы вжух – и у них всё появилось, а у других хоть трава не расти. Как вы будете делать – не волнует. Можно ли так вообще физически сделать – тоже не волнует.
Не надо так.
Итог
Оценка трудоемкости – это совершенно не одно и то же, что прогноз сроков поставки. Вы должны понимать, что и зачем вы спрашиваете, чтобы правильно интерпретировать ответы, самим потом не разочаровываться и других не заколебывать.
А еще так в жизни случается, что каждый сам кузнец своего счастья. Так что, если вам даже назвали трудоемкость, время старта работ, прогноз по срокам, и для вас это что-то очень важное, то постарайтесь вместе с исполнителями разобраться, нет ли чего-то, вносящего риски срыва сроков: завязка на смежные команды, плохо работающего или выгоревшего сотрудника, высокую неопределенность реализации и прочее.
Я принес. Так много тимлидов хороших и разных. А я какой?
Как я уже писал ранее, я в этом году помогал в организации менеджерского трека на конференции Codefest.
Но помимо организационных вопросов, мне удалось выступить там с докладом.
Мне очень радостно от ламповости аудитории на конференции, от количества присутствовавших людей и желающих обсудить разные вопросы после доклада.
Признаться честно, именно эта душевная и ламповая атмосфера и стала для меня одним из решающих факторов для участия в ПК.
Про что доклад?
Доклад про разновидности тимлидов и разные ситуации в команде и компании.
О том, как это всё матчится друг с другом и почему частая вакансия играющего тренера, который 80% времени пишет код и 80% занимается менеджментом, не приносит ничего хорошего ни самим тимлидам, ни компаниям.
Постарался предложить, как, где и когда можно порезать скоуп или качество, чтобы не пытаться впихивать невпихуемое и работать эффективно и счастливо.
Вопросы после доклада тоже мне очень понравились: многое было точно подмечено, разумно предложено и жизненно сформулировано.
Рад был со многими лично увидеться повторно или познакомиться впервые.
Ссылка
https://www.youtube.com/watch?v=vr4MhKiar5s
Как я уже писал ранее, я в этом году помогал в организации менеджерского трека на конференции Codefest.
Но помимо организационных вопросов, мне удалось выступить там с докладом.
Мне очень радостно от ламповости аудитории на конференции, от количества присутствовавших людей и желающих обсудить разные вопросы после доклада.
Признаться честно, именно эта душевная и ламповая атмосфера и стала для меня одним из решающих факторов для участия в ПК.
Про что доклад?
Доклад про разновидности тимлидов и разные ситуации в команде и компании.
О том, как это всё матчится друг с другом и почему частая вакансия играющего тренера, который 80% времени пишет код и 80% занимается менеджментом, не приносит ничего хорошего ни самим тимлидам, ни компаниям.
Постарался предложить, как, где и когда можно порезать скоуп или качество, чтобы не пытаться впихивать невпихуемое и работать эффективно и счастливо.
Вопросы после доклада тоже мне очень понравились: многое было точно подмечено, разумно предложено и жизненно сформулировано.
Рад был со многими лично увидеться повторно или познакомиться впервые.
Ссылка
https://www.youtube.com/watch?v=vr4MhKiar5s
YouTube
Евгений Антонов. Так много тимлидов хороших и разных. А я какой?
Профессия тимлида — одна, а кого ни спроси, все делают разное. Глянешь вакансии — там и вовсе всё на свете надо делать.
Хочу помочь тимлидам самоопределиться, чем же конкретно им нужно заниматься (в зависимости от особенностей развития компании), а также…
Хочу помочь тимлидам самоопределиться, чем же конкретно им нужно заниматься (в зависимости от особенностей развития компании), а также…
Три тимлида зашли в бар и обсудили профессиональное развитие
Кто-то говорит, что постоянная учеба в ИТ – это необходимость и вообще «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
А кто-то говорит, что надо уже отстать от человека, у которого глаза настолько выжжены монитором, что превратились в угольки, потому что он днем работает, вечером учится, ночью пет-проекты делает, а на выходных в хакатоне участвует.
Всё, что нам удалось обсудить по этой теме, со всеми идеями, историями из жизни, мотивационными призывами и гуманистической заботой, вы можете послушать в сегодняшнем выпуске.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Рассказывайте в комментариях, как профессионально развиваетесь вы сами, как помогаете своей команде. А может, и не тратите на это время вовсе, но при этом прекрасно себя чувствуете и волосы у вас шелковистые.
Кто-то говорит, что постоянная учеба в ИТ – это необходимость и вообще «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
А кто-то говорит, что надо уже отстать от человека, у которого глаза настолько выжжены монитором, что превратились в угольки, потому что он днем работает, вечером учится, ночью пет-проекты делает, а на выходных в хакатоне участвует.
Всё, что нам удалось обсудить по этой теме, со всеми идеями, историями из жизни, мотивационными призывами и гуманистической заботой, вы можете послушать в сегодняшнем выпуске.
Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.
Приятного прослушивания!
Рассказывайте в комментариях, как профессионально развиваетесь вы сами, как помогаете своей команде. А может, и не тратите на это время вовсе, но при этом прекрасно себя чувствуете и волосы у вас шелковистые.