Сначала система, потом личный контроль

Когда есть процесс, который касается нескольких людей, выполнения некоторых действий вручную, каких-то специфичных знаний, то я стараюсь организовывать вокруг этого хотя бы более-менее понятную, регламентированную систему.

Система
Казалось бы, очевидная вещь, необходимая для того, чтобы избежать ошибок человеческого фактора и лишних трат времени. Однако на практике далеко не всегда люди задумываются о том, что какой-то ряд действий можно объединить в систему. А если не задуматься о группе событий, то каждый новый случай приходится решать как уникальный: погружаться в контекст, вспоминать, что как надо делать, спрашивать у других участников, в очередной раз согласовывать и т.д.

Это как бороться постоянно с одними и теми же симптомами, но не пытаться разобраться с самой болезнью.

Всегда думал, что это настолько понятно и очевидно, что даже не хотел пост на эту тему делать. Однако ретроспективно вспомнив то, что мне доводилось видеть в жизни в целом, и работе в частности, решил всё же написать:)

На днях дочитал хорошую книгу, классику менеджмента Питера Друкера «Эффективный руководитель», первое издание которой вышло еще в 1966 году. Там автор посвятил довольно много времени важности того, чтобы руководитель понимал, где типовые случаи и надо построить систему, а где уникальные ситуации, к которым нужен индивидуальный подход.

Личный контроль
Как бы ни хотелось верить в то, что системный процесс является идеальным средством от комплекса проблем, это не совсем так.
Система дает общие, понятные, почти прямые, рельсы, по которым катятся однотипные дела. Однако она не может долго идеально существовать и быть всегда одинаково эффективной.

Обязательно какие-то части станут со временем не актуальными. Периодически нужно проверять, насколько все корректно работает и тюнить это.

А еще обязательно найдется способ хакнуть и извратить систему. Например, KPI для работников, которые они придумали как обойти.

Почему я говорю именно про личный контроль? Потому что, к сожалению, я не знаю, как прям идеально осуществлять контроль без этого. Любая система опосредованного контроля – тоже потенциально уязвимая система, где промежуточные звенья могут схалтурить, умолчать, не разобраться и т.д.

Тем не менее я не говорю, что абсолютно всё всегда надо контролировать лично. Но периодически закатывать рукава, производить проверку и тюнинг системы необходимо. Не стоит закрывать глаза и надеяться «авось всё нормально».

Пример
В качестве примера можно использовать мой пост про онбординг, который я писал некоторое время назад https://news.1rj.ru/str/general_it_talks/118

Итог
Постарайтесь выделить группу событий, которую можно объединить в четкую, понятную, управляемую систему.
Не почивайте на лаврах, не ленитесь, а периодически проверяйте и корректируйте эту систему.

Сегодня вышел очередной выпуск подкаста Кода кода, где я с удовольствием выполняю роль соведущего☺️

Этот выпуск для меня особенный. Возможно, вы помните по этому моему посту https://news.1rj.ru/str/general_it_talks/142 как я искренне люблю и ценю доклад Вадима Макишвили 36. Судя по комментариям к этому посту, таких почитателей его творчества среди нас не мало.

В этом выпуске Вадим был одним из гостей и раскрылся для меня с очень неожиданной стороны по части своего стороннего проекта. За что уровень моего уважения к нему еще вырос.
Ну а если вы не знали (мне кажется явно это в докладах не проговаривалось, или я прослушал), почему доклады 42 и 55 имеют именно такие названия, то в нашем подкасте вы сможете найти ответ на этот вопрос😎

Не хочется, чтобы вы подумали, что только Вадимом единым будет интересен выпуск. Еще одна гостья, Лидия Меншенина, тоже рассказала много не менее интересного и полезного по теме.

А тема выпуска - профессиональное выгорание и кризис среднего возраста. Берегите свое психическое здоровье, радуйтесь жизни и слушайте Кода кода.

Ссылка на телеграм канал подкаста и конкретный выпуск https://news.1rj.ru/str/kodakodacast/86

Да там легко!

Случалось ли с вами такое, что вам что-то прям совсем не понятно, вы обращались за помощью, а вам очень быстро показывали и объясняли, при этом еще и говоря «да там всё просто»? А вы потом чувствовали себя каким-то ущербным и тупым, потому что там же вроде просто было, а вы прям совсем не врубились.

Что люди чувствуют
Недавно имел несколько разговоров с разными людьми по этому поводу, все они рассказывали примерно одну и ту же историю.
Историю про то, как они в минуты дискомфорта (а незнание чего-то и обращение за помощью – это дискомфорт) слышали от товарищей, как там всё элементарно, а потом приунывали из-за этого.

Когда тебе тяжело, а кто-то это сходу обесценивает (пусть и не специально) – это не очень приятная история.
А если ты джуниор, начинающий и не очень уверенный в себе специалист, которому более опытный коллега с ходу говорит, что всё легче легкого, то тут запросто можно почувствовать себя дурачком.

Может показаться, что это чисто проблемы джунов. Я, будучи начинающим в профессии специалистом, тоже от этого страдал. Сейчас я как-то уже на опыте принял, что кое-что я знаю, а еще море всего я не знаю, и это нормально. И другие тоже кучу всего не знают, и это нормально. Не очень нормально, скорее, кичиться тем, что ты знаешь якобы всё, и при этом особо ничем не интересоваться и не развиваться.

Пообщавшись с людьми разных компетенций побольше, я сделал для себя вывод, что это проблема не только новичков. Много людей среднего и даже высокого уровня профессионализма могут обладать неуверенностью в себе, чувством некой незащищенности и тоже могут унывать или даже злиться от такой, казалось бы, безобидной, обесценивающей фразы.

Что делать
На мой взгляд, тут можно как минимум немного поменять подход, не говоря ультимативно «да тут всё легко», а сказать за себя: «Я это понимаю, я в этом разбираюсь, сейчас тебе помогу». И человек не будет страдать, что он якобы не разбирается в простых вещах, а скорее порадуется, что нашел того, кто в теме и может оказать помощь.

Я уверен, что найдутся те, кто скажет: «Да чего с ними цацкаться? Пусть скажут спасибо, что хоть так объяснили», или «Ну конечно и неженки, вот при Сталине такого не было». Это их право иметь свою точку зрения. Я тут никому ничего не навязываю, просто подсветил проблему, которую многократно наблюдал в жизни. А дальше уже каждый сам решает, как он с ней работает, и как он с кем общается, и как потом с ним общаются в ответ.

Итог
Помогая кому-то, откажитесь от фразы «там всё легко» и посмотрите на результат.
Возможно, ваш собеседник станет вас ценить чуточку больше, а уровень стресса у него станет чуточку меньше. А если ему приятно, а вам не сложно (если вам не сложно), то почему бы и не попытаться?🙂

Никто не вечен на проекте

Сегодня хочется поговорить про то, как важно жить с мыслью, что на проекте никто не остается навсегда.
Какая бы у вас ни была статистика долгосрочного сотрудничества с работниками и заказчиками, рано или поздно это изменится. И надо быть к этому готовым.

Басфактор
Есть такое понятие как bus factor, фактор автобуса. Детали тут https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0
а если коротко, то это число, показывающее, сколько людей из вашей команды должен сбить автобус, чтобы работа над проектом встала.
Этим термином пользуются, когда пытаются подсветить проблему существования «незаменимых» сотрудников в компании. Т.е. если есть один сотрудник, который умеет делать что-то уникальное и это является неотъемлемой частью производства, то у вас басфактор равен единице. Как только этот сотрудник заболеет, уйдет в отпуск, уволится, или еще чего похуже, то всё ваше производство встанет, дела не будут делаться, вы в панике будете пытаться его работу на кого-то переложить, но никто не умеет. Вы попытаетесь нанять того, кто умеет, а их тоже поди еще поищи. Трудно, короче. Не надо так.

Альтернативный вариант кадровой непредсказуемости
Представим ситуацию, что вы на проекте как сыр в масле катаетесь, команда классная, начальник крутой, и вы планируете здесь работать долго и счастливо. Однако – бац, вашу компанию покупает какой-нибудь банк, выставляет вам нового начальника, начинает в короткие сроки накачивать команду людьми, которых в спешке запылесосил десятками. В один момент вы теряете и хорошего начальника, и уютную команду, а ваше счастье мигом трансформируется в уныние.

Ну или теряются не работники и их начальники, а какие-нибудь наработанные контакты на стороне крупного заказчика, а с новыми не факт, что удастся договориться. Клиенты уходят, деньги – тоже, компания и её работники страдают.

Memento mori
Это я все к чему? К тому что поговорки типа «надейся на лучшее, а готовься к худшему», или даже «помни о смерти» учат нас тому, что нужно быть готовым к неотвратимо наступающим изменениям. И зачастую эти изменения могут быть не в лучшую сторону. Можно пытаться их оттянуть, сгладить, распределить, но тем не менее они случатся. Не стоит питать иллюзий.

Итог
Так что, руководитель, помни: ни один сотрудник у тебя на проекте не вечен, и организуй работу таким образом, чтобы это не стреляло тебе в ногу.

А работникам стоит помнить, что если у вас сейчас легкая ситуация и вы кайфово поживаете, то всё может измениться в худшую для вас сторону в любой момент. Какой-то запасной план иметь необходимо.

Где нанимать подходящих ИТ-специалистов в свою команду
Зарплата специалиста в регионах это 0.8 от московской зарплаты в IT-индустрии. Из-за этого многие думают, что региональные IT-специалисты хуже по некоторым техническим скиллам.

На самом деле, если посмотреть на опыт агентства Benchmark, которое регулярно нанимает специалистов и выводит целые IT-команды, то самый большой провал бывает в soft навыках, и им действительно нужно уделять внимание на собеседовании с региональным специалистом. При этом по hard навыкам они ничуть не уступают. Если вы готовы работать с сотрудниками удаленно, то региональные кандидаты значительно расширят вашу воронку и ускорят найм.

Как искать и отбирать кандидатов из регионов — в статье: https://media.benchmark.ru.com/dev_search_region

P.S. От лица автора канала Тимлид Очевидность я хотел бы тоже выразить своё личное отношение к этой ситуации.
На мой взгляд с пандемией действительно очень выросли зарплаты ИТ-специалистов.

Кто-то научился работать на удаленке и больше не хочет находиться в региональном офисе, а хочет работать из дома за столичную зарплату. Многие скилловые ребята не хотят работать за Российскую столичную зарплату, а хотят х1.5-2 зарабатывать так же из дома на международном рынке. Кто-то из крупных компаний смог хорошо заработать, и поставил перед собой большие планы по разработке, поэтому собирает людей с рынка компетентных людей с удвоенной силой, попутно пытаясь составить конкуренцию валютным зарплатам.

Как ИТ специалист я безусловно рад такому рынку сейчас. Как тот, кто на на консалтинге видит всякое в найме, в том числе и региональном, я искренне сочувствую малому и среднему бизнесу, которому нужны ИТшники. Особенно в регионах. Для многих это превращается в едва посильную ношу.

Также хочу отметить, что, на мой личный субъективный взгляд ,вот этот коэффициент 0.8 на регион все больше пропадает.

Помню как лет 5 назад было нормальной практикой говорить сотруднику прямо «ты на удаленке, значит тебе на 20-30%» меньше платим. Хотя почему меньше? Я же ведь вам на аренде офиса и оборудовании экономлю. А ведь аренда хорошего офиса с разными плюшками может запросто быть тысяч 50 на человека.

Так вот сейчас, если кто-то так скажет, то человек может легко найти того работодателя, который не хочет заниматься крохоборством этих 20 процентов. Многие уже и крупные и не очень работодатели, которые научились действительно нормально работать на удаленке, не занимаются уже такими вещами. Опять же, это мое личное субъективное наблюдение.

Насчет переживаний про софт скиллы в регионах - я бы советовал обратить внимание на организацию онбординга, менеджмент людей и проектов. Организационная работа на этом уровне поможет меньше завязываться на скиллах конкретного человека, и выстраивать систему, которая нивелирует подобные минусы (если они вообще существуют).

У нас в подкасте Кода кода вышел новый выпуск.

В этот раз обсуждали специфику работы с западными заказчиками. Поговорили об особенностях культурного взаимодействия, работе в разных часовых поясах, требованиях к уровню владения английским языком.
Немного посравнивали стартапы в России и США.

Ссылка на пост с выпуском https://news.1rj.ru/str/kodakodacast/91

Однажды тимлид – навсегда тимлид

Неоднократно слышал, что бывших тимлидов не бывает. И я почти согласен с этим утверждением. Согласен с этим на своем примере и на примере других своих товарищей по профессии.


Откаты
Я встречал истории, когда человек быстро откатывается из тимлидов, потому что это не для него. Может, поставили его насильно на эту должность, может, не сошлись ожидания и реальность, может, просто решил попробовать, чтобы посмотреть пойдет или нет.

Тут нет ничего стыдного и позорного, работник не становится плохим. По сути это делает человека даже более хорошим и ценным сотрудником: он получил полезный опыт, который далеко не у каждого есть, получше узнал себя, побольше определился, чем именно нравится и не нравится заниматься. Главное, не чмырить и не унижать себя при этом, а наоборот, порадоваться, что ты попробовал.

Но так, чтобы человек годами был тимлидом и теперь говорит: «Нет, всё, хочу назад рядовым разработчиком», прям уходит и надолго остается линейным работником, – таких примеров не слышал. Если вы слышали, поделитесь в комментариях.

Зато краткосрочных таких историй много. Был тимлидом, очень устал, перегорел, откатился в спокойное однозадачное двигание задачек в жире. Поработал, морально отдохнул и опять как-то само собой получается, что тут на что-то хочется повлиять, здесь кому-то помочь, вон там явно же кто-то не может договориться, надо разобраться. И так человек снова в колею эту входит. Потому что характер такой, потому что мотивация такая: повлиять на что-то более глобальное, на что нельзя повлиять из рядовой позиции.

Сам чего?
У меня всегда как-то само собой складывалось, что я приходил рядовым сотрудником, а потом двигался в тимлиды. Затем шел в другую компанию, и там происходило то же самое.
Да, мне иногда приходится трудновато: море переключений контекста, созвонов, переписок, согласований, контроля, документации, квадратиков и стрелочек. И я думаю: «вот бы просто сидеть, код писать постоянно, а не вот это вот всё». И я могу себе позволить иногда устроить такие разгрузочные дни. И в качестве смены деятельности это клево, люблю, когда такое случается.

Но для себя я на данный момент жизни решил, что прям 20 дней в месяц просто тягать задачи из жиры и потихоньку их прогать, мне уже не очень интересно. Мне хочется, чтобы результат моей работы был более масштабен. Не из честолюбия, а просто хочется, чтобы вокруг было больше приятного и хорошего. Больше понятных задач в проектах, больше нужных задач, больше понимания с заказчиками, больше культуры и порядка в разработке, больше нормальных, человеческих, работающих процессов у меня и моих коллег.
И если я чувствую, что я могу принести там везде пользу, то почему бы этого не сделать?


Итог
Мое личное мнение, что если ты такой человек, что тимлидить тебе по душе, то ты можешь устать, ты можешь даже откатиться назад, но, скорее всего, так или иначе ты встанешь на этот путь снова. Иными словами, тимлид – это состояние души, а от себя не убежишь:)

Бонусный контент
Эту тему мы выбрали вместе с Настей Абрашитовой, менеджером проектов из Яндекса. Знаю Настю уже полтора года и очень уважаю её профессионализм. Её пост вы можете прочитать тут https://news.1rj.ru/str/tealmead/41

В последнее время меня со всех сторон окружает тема разрешения конфликтов и обратной связи.

Причем рабочие конфликты порой меркнут в сравнении с бытовыми. Ну и действительно, одно дело какой-то наемный менеджер не дождался вовремя задачу и разволновался, а другое дело, когда ты человеку затопил его личную квартиру, и он в бешенстве.

Где-то по этой теме мне приходится действовать на практике, а где-то можно и потеоретизировать.
Сегодня вышла статья https://skillsetter.io/blog/feedback-problems где я получил ряд проблемных кейсов, проанализировал их и предложил несколько вариантов их решения.

Ссылка на телеграм канал https://news.1rj.ru/str/skillsetter/497

Что вам от меня надо?

Сегодня хочется поговорить про обсуждения ожиданий от кандидата при найме.
На мой взгляд, актуальнее всего это будет для позиций менеджеров и тимлидов, чем для разработчиков (у которых всё более четко и понятно).

Суть проблемы
Человек устраивается на работу тимлидом. Проходит собеседование, отвечает на все нужные вопросы, выходит на работу и начинает свою бурную деятельность. Тюнит процессы разработки в команде: CI/CD настроил, гитфлоу внедрил, научил команду как кодревью делать, и т.д.

А через месяц его вызывают к руководству на ковер и говорят, что он не справляется. Команда стала за этот месяц релизить фичи медленнее. Кто чем занят на работе – непонятно.
Почему до сих пор за месяц не начали работать по спринтам? Где эти все стендапы, груминги, демо, ретроспективы? Сколько 1-1 провел? Ах, нисколько?! А ты уже продумал, чем на корпоративе команду развлекать?
Чем ты там вообще занимался? Зачем ты эти гитфлоу свои внедрял? Кто тебя просил? Мы думали, ты командой руководить пришел, а не свои эти задротства программистские ковырять!

Тимлид думал, что делает хорошее и полезное дело, а в итоге оказалось, что руководство хотело совсем не этого.

Что делать?
Надо было сразу оговаривать как ожидания от этой позиции, так и критерии успешности их выполнения. А по итогу разговора лучше бы зафиксировать письменно, чтобы не было недомолвок из серии «Ну мы думали, ты понимаешь! Это же очевидно! Это подразумевалось!»

В идеале это делать не в начале своей работы в компании, а еще на этапе собеседования, чтобы точно сматчить свои планы на работу с планами компании. И понять сразу, насколько вы друг другу подходите, чтобы не было потом неприятных сюрпризов.

Да, вы можете сказать, что это долго, что никто не будет так долго с кандидатом обсуждать и разглагольствовать. На мой взгляд, это не так. Хорошего тимлида сейчас попробуй найди, а цена неудачи и перенайма высока. Лучше я потрачу лишние час-два на эти разговоры, чем потом все будут страдать, терять время, деньги и душевные силы.

А если вам на собесе говорят, что некогда про это разговаривать, то задумайтесь, как вам там дальше с ними будет работаться, если у них на этапе найма (когда вы им ничем не обязаны) уже нет времени на то, что важно для вас и для бизнеса.

Итог
Обязательно проговаривайте как можно раньше и ваши ожидания от работы, и ожидания компании от вас. По возможности фиксируйте письменно.

Менторинг

Сегодня вышел очередной выпуск подкаста Кода кода, где мы с Виктором, и нашими уважаемыми гостями попытались разобраться с тем, что же такое менторинг, консалтинг, наставничество, и есть ли между ними отличия.

Не забыли осветить опасность инфоцыганства и профанации.

Нам очень важно получить от вас обратную связь о подкасте. Что вы вообще думаете о формате, о темах, гостях, подаче? Пожалуйста напишите в комментарии или здесь, или в канале подкаста🤝

Приятного прослушивания https://news.1rj.ru/str/kodakodacast/96

Лайвкодить или не лайвкодить? Вот в чем вопрос

Уже много времени горит, полыхает спор про то, нужен ли (важен ли) лайвкодинг на собеседовании.

У больших компаний часто это обязательная секция
Возьмите ФААНГ (или МААНГ?) и его российский вариант типа Яндекса, или Авито. Там лайвкодинг секция – обязательная. Где-то даже менеджеров заставляют онлайн, или на доске, или на листочке код писать. У них есть для этого свой ряд объяснений:
⁃ отсеивают совсем не умеющих написать простой цикл или условие, переброситься парой букв в строке;
⁃ стандартизируют найм при огромном входном потоке и условии, что порой набор идет не в конкретную команду, а в компанию в целом;
⁃ отсеивают по максимуму, говоря, что лучше они не наймут подходящего, чем наймут неподходящего. У них желающих много, могут себе позволить.

Я лично такие секции не люблю и плохо прохожу, потому что не трачу десятки часов в литкоде. Да и просто волнуюсь на собесах, а лайвкодинг в стрессе не очень эффективный получается и еще больше стресс усугубляет. Тем не менее я не отвергаю вышеприведенных аргументов. На мой взгляд, это естественное развитие событий при таких больших масштабах. Правда когда этих секций штуки 3, то это уже даже на мой, довольно понимающий взгляд, перебор.

Яростно критикуют такой подход обычно, не учитывая масштабы найма и орг.структуру, либо обидевшись, что не прошли подобный собес. Либо просто сидючи в небольших компаниях и нанимая по 1-2-5- людей в год. А какой-то серьезной критики от тех, кто выстроил огромный найм на потоке, я не слышал. Если вы слышали – напишите, пожалуйста, в комментарии, интересно будет ознакомиться.

Есть нюанс
Еще лично мое мнение, что крупные наниматели не говорят вслух, но, возможно, имеет место несколько манипулятивный отсев по мотивации.
Ведь чтобы хорошо пройти эту секцию, где на самом деле не совсем «просто цикл и ифчик написать», нужно потратить достаточное количество времени на подготовку, прорешивание литкода и т.д. А если человек всё это сделал, значит, он целеустремленный и трудолюбивый, и к нам хочет. Так что щас мы его к себе возьмем, да поднасядем на него хорошенько, а он будет везти.

Что у маленьких
Это мы рассмотрели крупные компании. А в мелких что? А в них тоже это есть?
Порой да, но не всегда. Кто-то бездумно косплеит крупных, хотя им это не нужно. Кто-то искренне идейно убежден, что только листочек и жонглирование буквами поможет определить, насколько программист хорошо подходит на эту работу.

Я считаю, в более точечном и конкретном найме лучше подойдут секции проблем солвинга, систем дизайна и кодревью.

Что я думаю?
Думаю, что нет смысла спорить, нужно это или не нужно. Просто примите это как данность. Много где это есть, но далеко не везде. Не хотите писать код в онлайн редакторе, или на листочке? Считаете это унизительным? Ну и не ходите туда, где это делают. А когда вас зовут на собес, заранее уточните, будет ли лайвкодинг. Лично я заранее спрашиваю об этом. Потому что знаю, что если мне прям очень засвербит туда пройти, то мне надо сидеть и готовиться (я уже наполовину менеджер, что я говорю, какой лайвкодинг, куда я готовиться собрался?:)), а без подготовки я мало что прям хорошего покажу. Ничего плохого и стыдного в этом не вижу. Как и не вижу смысла тратить и свое, и чужое время, приходя на собес, где меня ждут подобные сюрпризы.

А если вы сами собеседуете, а найм у вас более конкретный, и вы сами решаете что спрашивать на собесе, подумайте сто раз над тем, нужен ли вам там лайвкодинг и точно ли он показывает то, что вам кажется.

Итог
Не гребите всех под одну гребенку, но и сами не позволяйте себя загребать, если вам этого не хочется. Сейчас программист волен выбирать, куда ему на собес идти, а куда нет. Вот и ходите туда, куда хочется. Но если сильно вам надо туда, где есть лайвкодинг, то не жалуйтесь (это не поможет), а выделите время на хорошую подготовку.

Умение признавать свои ошибки

Вроде бы очевидная вещь, как и всё, что обсуждается у меня в канале. Однако как же часто я сталкиваюсь с людьми, которые не хотят и не умеют признавать свои ошибки. Хотелось бы коротко обсудить, чем это чревато.

Проблемы внешние
Неуважение.
Человек опоздал на встречу и без извинений просто начинает разговор как ни в чем не бывало. Или вам предоставили какой-то некорректный сервис, вы указали на проблему, а там просто притворились, что ничего не произошло.
Как всё это выглядит со стороны? Очень неуважительно и неприятно. Хочется ли вам продолжать работу с таким человеком и сервисом вообще? Хочется ли общаться с ними вежливо и корректно?

Избегание ответственности.
Кто никогда не признается своих ошибок, валит на других, всячески юлит, лишь бы не сказать «да, извините, я тут косякнул и поэтому случилась проблема», тот избегает ответственности за свои поступки. Не знаю, как вы к этому относитесь, но лично мое мнение, что с такими людьми мне было бы не очень комфортно работать, или даже просто общаться в быту.

Проблемы внутренние
Помимо всяких имиджевых проблем, которые создают себе и другим люди, не умеющие признавать своих ошибок, я хотел бы рассмотреть и чуть более глубокие.

Ведь нежелание признать, что ты где-то не прав, что ты не все делаешь идеально, ведет к тому, что ты и новому учиться не можешь. Ты закостеневаешь в том, чему когда-то научился, и больше уже неспособен учиться новому. Зачем учиться, если ты уже безгрешен и умеешь всё делать идеально? Проще ворчать как дед на всё новое и непонятное, и делить мнения на два лагеря: твоё и неправильное.

А еще, если вы отрицаете свою вину в проблемах, то и не сможете избежать повторения этих проблем. Ведь чтобы проблема исправилась, нужно изменить своё поведение, приводящее к ней. А вы не измените, потому что и «так всё идеально, это просто другие дурачки и всё плохо делают, жить мешают».

Итог
Каждый может ошибаться. Это нормально. И будет совсем хорошо и порядочно, если вы сможете признавать свои ошибки, учиться на них и не допускать их.

Сегодня каналу Тимлид Очевидность исполнилось 2 года!

Для меня это очень важно. Это проект, в который я вложил довольно много времени, сил и частичку души❤️
Поэтому, когда мне недавно писали с просьбой канал продать, я сразу же решительно отказался, даже не доходя до обсуждения цены:)

Искренне рад, что читателей появляется всё больше. Надеюсь, что мои посты, хоть и очевидные, но кому-то из вас приносят пользу.
Мне до сих пор не верится, что канал читает так много людей, что это прям по-настоящему🙂

Клево, что стало приходить больше людей в комменты, общаться, обмениваться опытом, подкидывать хорошие идеи для работы, жизни и следующих постов. Спасибо вам большое🤝

Уверен, что вы заметили, что у меня появилось больше рекламы в последние месяцы.
Когда я заводил канал, то я и не думал, что когда-то он начнет приносить хоть какую-то копеечку. Но раз предложения есть – я не могу отказаться от всех. Сами понимаете, взрослая жизнь, семья, финансовые обязательства и так далее.

Тем не менее хочу, чтобы вы знали, что:
а) Я стараюсь соглашаться только на релевантную рекламу, которая может быть потенциально интересна читателям.

б) Я в последние месяцы от многих предложений отказался только потому, что не хочется с рекламой слишком частить. Пока для себя решил, что будет график: 1 рекламный пост в неделю и 1 традиционный пятничный мой. Где-то в промежутках могу что-нибудь запостить, что в душеньку запало, или рассказать вам о выходе очередного выпуска «Кода кода», где я уже некоторое время являюсь соведущим.

P.S. Отдельная благодарность моей жене, которая помогает мне приводить тексты в хорошо читаемый вид. Кстати, у неё есть свой душевный канал про кино и сериалы, вдруг вам будет интересно https://news.1rj.ru/str/katyuha_smotrit Хотя бы такой маленькой рекламкой отблагодарю за те часы, которые она провела над вычиткой текстов за 2 года существования канала🙂

Итог
Спасибо, что читаете🥰

Специальный новогодний выпуск Кода кода

В этом выпуске нет рассказов про эффективность и полезность, а просто мы сели с жёнами и потрепались про всё на свете: хобби, кино, игры, регионы, смешные названия выпусков, забавные истории.
На мой взгляд, получилось душевно❤️

ссылка на выпуск https://news.1rj.ru/str/kodakodacast/111

Свежая кровь

Некоторое время назад я писал пост про добавочную стоимость старожилов https://news.1rj.ru/str/general_it_talks/135
В этот раз хочется рассмотреть ситуацию почти обратную, и обсудить ценность новых сотрудников.

Новые сотрудники – это боль
Да, новые сотрудники – это сразу куча новых забот и проблем. Человек какое-то время вникает, выдает мало пользы, отвлекает других, делает задачи долго, никаких местных порядков и процессов не знает. А бывает еще и так, что после того, как потратили на взаимную интеграцию уже некоторое время, оказывается, что человек не подходит, и надо еще гемороиться с расставанием, перенаймом и вот этим всем снова и снова. Короче, проблем тут хватает.

Однако в этот добрый предпраздничный день хочется не концентрироваться на заунывном негативе, а рассмотреть и позитивные аспекты.

Новые сотрудники – это свежесть и бодрость (не всегда)
Если вам очень повезло и вы наняли того, кто будет не просто жопочасы отсиживать, а прям активно хочет что-то делать хорошее, доброе, полезное, то вот в чем я вижу профит от нового человека (видел это не раз на практике):

⁃ Взбадривает болото. Порой с низкой ротацией в коллективе или несколько вязкими процессами со временем складывается более-менее равновесная ситуация, где всем норм, и никто никаких активных действий совершать не хочет. И вот свежий человек способен сгенерировать какие-то новые идеи, взяться за их реализацию.
Я сам не из тех, кто постоянно кричит про выход из зоны комфорта. Я люблю что-то комфортное и стабильное, однако очень радуюсь, если приходит человек с разумным, осознанным энтузиазмом и приносит новые идеи. Готов всегда идти навстречу, обсуждать, пробовать.
Конечно, я не имею в виду случаи, когда приходит новый разработчик и с порога говорит: «Тут всё фигня и надо переписать на svelte». Или новый менеджер, который говорит: «Вы что, без скрама и сторипоинтов вообще жизнь – не жизнь! Жду вас завтра на ретро!»
⁃ У него нет выученной беспомощности. Про это я тоже писал пост https://news.1rj.ru/str/general_it_talks/66
Т.е. человек еще не обескровлен скрипучими процессами и инертностью коллектива. Он не живет в позиции «Ой, да тут никому ничего не надо, не стоит даже пытаться».
⁃ Приносит новый опыт, которого у вас в команде нет. Вы же берете человека откуда-то. Он там работал, чего-то видал, чего-то делал. Интеграция чужого опыта тоже может быть очень полезна. Особенно если к найму подойти осознанно и не набирать людей глупее себя, чтобы они тебя не подсидели (да, такое бывает регулярно), а целенаправленно подумать, какой экспертизы не хватает команде и попытаться нанять человека, который бы её принес.

Итог
Желаю вам в новом году хороших, бодрых, профессиональных коллег.
Всех поздравляю с наступающим праздником🥳 Успехов вам!💪

Управление конфликтами

Сегодня хочется затронуть тему, которая в нашей жизни присутствует примерно всегда. На работе, в быту, даже на отдыхе так или иначе мы сталкиваемся с какими-то конфликтными ситуациями.

Хочу дать вам разных материалов, которые, на мой взгляд, очень хорошо и емко рассказывают про конфликты, их предпосылки, стратегии разрешения и вот это вот всё.

И бонусом небольшую шпаргалку, которую я составил самостоятельно на тему разрешения конфликтов. Это не универсальная, самая лучшая в мире инструкция, а скорее мой личный опыт, основанный на теории и практике.

Материалы
https://habr.com/ru/company/oleg-bunin/blog/568820/ – мне прям очень понравилась статья, жаль, что второй части у неё вроде бы не вышло, ну или я не нашел.
https://youtu.be/C7eDwMKSHRU?t=2932 – наглядный доклад Кости Подрубного про конфликты.
А. Орлов "Джедайские техники конструктивного общения". Коротко, по делу, с примерами, очень толково.
М. Гоулстон "Как разговаривать с мудаками". Придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже🙂

Шпаргалка
• Вывести конфликт в конструктивное русло. Без эмоций, оскорблений, неаргументированной критики.
• Понять истинные цели и мотивацию каждого участника конфликта. Попытаться найти что-то общее.
• Добиться того, чтобы все говорили «на одном языке» и понимали друг друга.
• В случае необходимости можно обращаться к внешнему арбитру, эскалировать. Но постараться не прослыть жалобщиком, паникером и скандалистом.
• В идеале прийти к win-win или хотя бы не сильно обидному компромиссу.
• Договориться о конкретных действиях и наметить план их выполнения.
• Постараться сделать всё это так, чтобы в дальнейшем желание сотрудничать с вами не пропало.

Итог
Конфликты – это неизбежно и нормально. А вот то, как их удастся разрешить – это тонкое и полезное искусство, которому надо учиться. Надеюсь, этот пост и материалы из него помогут вам в будущем хоть немного упростить себе жизнь во всяких неприятных ситуациях.

P.S. Сорян, что на каникулах загружаю, просто расписание такое🙂 Хорошего всем отдыха, жду вас 10 января свежими, бодрыми, улыбающимися!🥳

У нас в Кода кода вышел новый выпуск

В этот раз мы поговорили про собеседования и как их проводить.
Выпуск получился несколько дольше обычного, потому что тема объемная, холиварная, и меня немного понесло😁
Тем не менее слушается, вроде как, не затянуто.

Приятного прослушивания!🙂
https://news.1rj.ru/str/kodakodacast/115

Сначала наденьте маску на себя, потом на ребенка

Этот пост будет в рабочем плане более актуальным для тимлидов, менеджеров, менторов джунов и прочих людей, кто вынужден так или иначе бороться не только со своими проблемами, но и с трудностями других людей.

Что в самолете?
Почти каждый знает, что в самолетах есть правило о том, что если какая-то опасная ситуация и нужно надевать кислородные маски, то взрослый человек сначала должен надеть маску на себя, а потом уже на любимого (скорее всего) ребенка.
Оно звучит контринтуитивно. Как же это так? Ведь это любимочка, кровиночка, золотце и надо первым делом кидаться спасать его. Ан нет! Если кинуться помогать ребенку, то можно самому схватить недостаток кислорода, потерять сознание. Ребенок пока не способен самостоятельно действовать без паники в таких ситуациях и вас спасать, поэтому сначала нужно точно обеспечить себе нормальную жизнедеятельность, а потом уже в этом стабильном состоянии спасать кого требуется.

Что на работе?
А на работе всё то же самое. Если ты какой-нибудь тимлид, то у тебя куча дел, которые тебе нужно и важно сделать самому, при этом к тебе еще приходят твои коллеги за помощью регулярно. А может и не приходят, а ты сам видишь, что помощь нужна и хочется броситься быстрее всех спасать.

Очень часто встречается ситуация, когда тимлиды молодые, огнеглазые, неопытные, пытаются целый день спасать всех на свете, а потом под конец дня понимают, что их важные и нужные задачи с места особо не сдвинулись. В результате они остаются до ночи овертаймить, либо переносят их на следующий день вместе с чувством вины, бесполезности своей работы, стыдом и страхом, что скоро продолбаются дедлайны и вскроется, что они некомпетентны.

У меня так тоже было первое время. Очень уж хочется всем помочь. А потом оказывается, что тебе-то в твоих делах никто не поможет, их можно только самостоятельно сделать, а нет уже ни сил, ни времени на них, чтобы еще и сделать хорошо.

Что делать?
А делать всё то же, что и в самолете. Делать хорошо и вовремя согласно приоритетам свои важные дела, а потом уже надевать плащ, маску, доспехи и нестись спасать всех на свете.

А еще вы удивитесь тому, что если не спасти кого-то сразу (потому что спасаете себя), то может оказаться, что этот человек уже не только сам спасся к тому моменту, как вы освободились, а еще и научился чуточку лучше справляться сам.

Итог
Делайте важные дела первым делом. Делайте то, что зависит лично от вас, первым делом. Когда вы знаете, что всё важное сделано и на вас не давят ни сроки, ни ваша психика, вы сможете более счастливо и продуктивно жить и трудиться. Меньше будете выгорать, больше будете пользы приносить себе и окружающим.

Позаботьтесь о читателе

В мире всё сильнее и активнее расцветает удаленная работа и письменная коммуникация (к сожалению, голосовухи тоже). Поэтому становится всё важнее уметь правильно, понятно и вежливо писать тексты (сообщения в чатике, письма, документацию, статьи и т.д.).

Суть идеи
Позаботьтесь о читателе.
Эта идея мне была всегда интуитивно понятна, но более формализовано я её прочитал в книге Максима Ильяхова и Людмилы Сарычевой «Новые правила деловой переписки».
Там это не совсем в какую-то отдельную главу выделено, а просто сквозит через всю книгу во множестве примеров.

Я считаю, что подумать о комфорте получателя сообщения – это и порядочно, и эффективно одновременно.

Что делать?
Попробовать представить себя на месте человека, которому мы пишем, посмотреть на свое сообщение глазами читающего, прикинуть на себя контекст, интонацию, пользу. Возможно, это наведет на какие-то мысли по улучшениям.

Нужны примеры
⁃ Вы собираете встречу, на которой хотите обсудить три важные фичи в разработке проекта. Но называете её «о проекте», не добавляете никакого описания, и кидаете её семи людям. Смотрим со стороны этих людей. Совсем непонятно, о чем конкретно в этом проекте мы будем разговаривать, подготовиться к этой встрече невозможно, и я совсем не понимаю, а точно ли я там нужен, или окажется, что про мою часть работы там ничего нет, а я зря время потрачу.

Очевидный простор для улучшений: указать побольше контекста в описание встречи и понятно её назвать.

⁃ Вы продолбали дедлайн и теперь пишете в соседний отдел «Доброго времени суток, коллеги! Пожалуйста, сделайте эту штуку через 7.5 секунд. Заранее спасибо!». Теперь ставим себя на сторону коллеги, который в разгаре своих дел получает такое письмо. Вы что там совсем уже? Какие добрые времена суток? Что я вам за 7.5 секунд сделаю? Почему заранее не предупредили? Спасибо заранее какое-то, как будто я прям точно сейчас подорвусь и начну ваши косяки закрывать. А если не сделаю, то у меня проблемы будут или у вас?

Очевидный простор для улучшений: как порядочный человек извиниться за такую срочность, объяснить хотя бы в общих чертах, почему так вышло, почему эта задача важна и почему нельзя никак её откладывать. В идеале еще и предложить помощь в исполнении, потому что продолбались-то вы.

⁃ Вы участвуете в почтовой переписке, понимаете, что нужно что-то сделать, чего не можете сделать вы, а может, ваш коллега. Форвардите ему весь тред без пояснений, пусть почитает. Идем на место коллеги. Ну и что вы мне нафорвардили, мне весь тред теперь читать? А точно мне нужно его читать, или вы не тому нафорвардили? А что нужно сделать-то в итоге, вы ж по ходу треда 3 раза переобулись. Ну вы там совсем уже.

Очевидный простор для улучшений: форвардинг треда с кратким резюме, что и почему нужно сделать.

Итог
Уважайте и заботьтесь о читающих ваши сообщения, как хотите, чтобы уважали и заботились о вас.

У нас вышел новый выпуск подкаста

Сегодня в подкасте Кода кода мы поговорили про обучение внутри компании, внешние митапы, конференции и вот это вот всё.

Приятного прослушивания❤️
https://news.1rj.ru/str/kodakodacast/121