Вас не могут просто так сдернуть с удаленки (по ТК)

Один из способов давить на сотрудника, чтобы он ушел без выплат - угроза дисциплинарными взысканиями. Что тут самое простое пытаются сделать: "отменяют" удаленку, дескать, с завтрашнего дня выходи в офис, а то вменим тебе прогулы, впаяем дисциплинарки и уволим по статье.

Что вам важно помнить

🔵 если у вас в ТК-договоре прописана удаленка, вас не могут просто с нее снять в одностороннем порядке, условия трудового договора так не меняются. Вы должны будете подписать документ об изменениях в договоре, что можете не делать;

🟡 если у вас допник к ТК с удаленкой (бессрочный), его тоже не могут отозвать в одностороннем порядке, тут та же история с соглашением сторон;

Когда вызов с удаленки без согласия возможен

🟣 если вас предупредили за 2 месяца + "если в компании произошли организационные и технологические условия труда, которые существенно изменили условия труда" (а значит, вас единственного из команды вытащить не смогут, кроме того, компании понадобится еще доказать эту самую смену условий труда);

🟢 если перевод на дистанционку был временный, с фиксированной датой окончания в договоре/допнике;

А если нет ни договора с удаленкой, ни допника

Тут есть такой концепт, как "фактически сложившиеся отношения".

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

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

❗️Традиционно, напоминаю: если вас увольняют не по вашей воле, ничего не подписывайте на месте, всегда берите время посоветоваться с юристом

🔜 Еще очень, очень советую культовый доклад Витали Шароватова про правовые нюансы увольнений.

Запоздалый дисклеймер

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

Другие мои посты про увольнения

- 3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК);
- Про увольнения с ГПХ-договора;
- Поговорим про плохие увольнения;

Завершилась активная часть благотворительного ивента для джунов

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

Через 2 часа ребята закончат двухдневную разработку макета на HTML/CSS/JS (без фреймворков), и начнется презентация работ.

Заходите посмотреть, какие у них классные результаты получились ❤️

🗓 стартуем сегодня, 29 сентября, в 18:00 по Мск

🎙 запись трансляции останется по той же ссылке

➡️ больше об ивенте тут

Ревью работ благотворительного ивента для джунов фронтов, ч1

Сегодня будет трансляция первой части ревью проектов ребят на HTML/CSS/JS.

❗️Важно: команды работали над проектом всего 1.5 дня. Они сделали все, что было в их силах за это короткое время. В проектах есть ошибки, и это нормально. Не надо ребят за это тыкать.

Любые нападки на проекты буду зачищать.

💫 Кому полезно

Всем фронтам, кому интересно послушать и поболтать про верстку, бест практисы и сложности

🗓 Когда будет

Сегодня, 30 сентября, в 18:00 по Мск. Запись останется!

📎 Ссылки на работы команд

Сегодня посмотрим работы 4 команд

🔸 Команда #1
🔸 Команда #3
🔸 Команда #4
🔸 Команда #6

Ревью работ благотворительного ивента для джунов фронтов, ч2

Сегодня будет трансляция первой части ревью проектов ребят на HTML/CSS/JS.

❗️Важно: команды работали над проектом всего 1.5 дня. Они сделали все, что было в их силах за это короткое время. В проектах есть ошибки, и это нормально. Не надо ребят за это тыкать.

Любые нападки на проекты буду зачищать.

💫 Кому полезно

Всем фронтам, кому интересно послушать и поболтать про верстку, бест практисы и сложности

🗓 Когда будет

Сегодня, 1 октября, в 18:00 по Мск. Запись останется!

📎 Ссылки на работы команд

Сегодня посмотрим работы 4 команд

🔸 Команда #2
🔸 Команда #5
🔸 Команда #7
🔸 Команда #8

Как я учусь на тимлида (ч.1)

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

Как курс организован

В нем 9 модулей, 1 месяц - 1 модуль. Каждый модуль состоит из интенсивной трехдневки - 3 дня теоретических и практических занятий, по 5 часов в день. И дальше 3 недели еженедельных отработок кейсов в мини-группах, по 1 разу в неделю.

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

Что проходили

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

🔵разобрали концепцию PAEI (функций менеджмента), жизненный цикл компаний и как одно с другим связано. Я раньше много слышала про Ицхака Адизеса, глыбу и титана менеджмента, но впервые прикоснулась к его теориям.

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

🟢 говорили о том, как налаживать контакты с субординатами. Как сделать в команде прозрачную, доверительную атмосферу, но не сажать себе сотрудников на шею. Подробно раскрывалась тема 1-1: зачем это надо, что в них делать, о чем говорить с человеком, как поддерживать контакт между этими встречами.

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

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

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

Практика

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

Мы отработали 6 кейсов: 3 из них - в лекционные дни, чтобы сразу потыкать материал, 3 - в межсессионные занятия.

Как эти кейсы выглядят примерно:

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

- "горят сроки, горят жопы, горят сотрудники. Что делать в этом бардаке, если тебя запихали это всё тушить, и какие шансы не полететь кукухой";

- "к вам набежал HR BP и сказал, что как тимлид вы - бестолочь, потому что не поддерживаете его (странные, на ваш взгляд) инициативы. Как объяснить CTO и HR BP, что вы, вообще-то, норм, и, при этом, не набрать проблем команде";

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

Что в итоге

Первый месяц показал, что:

🟣 организация у Стратоплана на высоте: все четко, комфортно сделано, через все процессы ведут за ручку. Даже мне с моим диагностированным СДВГ удается не отставать от одногруппников;

🔵 я очень недооценивала пул проблем, с которыми может сталкиваться тимлид. Стало немного понятнее, чем они занимаются, кроме вытирания носов субординатам;

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

Благотворительный HTML-ивент: как это было

В конце августа я анонсирована благотворительный ивент в пользу НКО "Ночлежка".

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

Все команды получили от меня код-ревью (ч.1, ч.2).

〰️ Какую ставила перед собой задачу

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

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

Получилось и то, и другое.

〰️ Результаты в цифрах

🔵 собрала 8 команд по 4-5 человек, в общей сумме было 34 участника;

🔵 в НКО улетело 35к рублей;

🔵 мои личные затраты на организацию - $12 за покупку макета;

🔵 активная часть ивента с разработкой заняла 31 час;

🔵 до финала добрались все 8 команд и 33 участника (один отвалился);

🔵 ревью всех команд заняло 9 часов;

🔵 количество моей радости - безмерное;

〰️ Подготовка

Сама по себе подготовка не заняла много времени и сил. Чтобы мероприятие увидело свет, мне понадобилось:

🟡 написать пост с идеей и призывом поучаствовать. Я волновалась, что сумма доната в НКО (800р с носа) отпугнет людей, но нет: нужное количество участников набралось так быстро, что я удвоила количество команд, изначально планировала всего 4;

🟡 выбрать макет для верстки. Вот это было нетривиально.

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

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

🟡 сборка команд - самая каверзная история. Чтобы реализовать ее, я создала в ноушене табличку, куда занесла всех участников.

Ячейки содержали имена, ссылки на тг-профили, то краткое "о себе", которое скинули ребята и проставленный на основании этого "о себе" условный грейд: "джун", "миддл", "лид".

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

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

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

〰️ Организация

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

🟢 один центральный общий канал в тг со всеми апдейтами. Апдейты структурированные, по пунктам.

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

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

Вот эта публичность и прозрачность помогала не повторять по многу раз одно и то же;

〰️ Как все прошло

В общем, очень ровно и мирно.

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

❌ у всех команд за час до презентации упали prod-деплои (на gh-pages и vercel). Чинили с горящими жопами, еще там было не вполне понятно, как чинить-то (и спасибо одному из лидов, который разобрался и всех подхватил);

Считаю, что результаты классные, и оно того стоило. Спасибо участникам и всем, кто меня поддержал! ❤️

❗️Благотворительный React-ивент для Junior-разработчиков (с опытом тоже можно)

Делаю благотворительный онлайн ивент, чтобы помочь джунам получить проект в портфолио и собрать деньги в пользу НКО "Старость в радость" (или любого зарубежного аккредитованного НКО, если вы не в РФ).

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

📘 Что будет

🔸 мы соберемся 8 командами по 4-5 человек (можно заявиться и одиночкой, и несколькими людьми: команды я соберу);

🔸 после аппрува участия участник вносит 1500 рублей сразу в "Старость в радость"/зарубежное НКО (❌мне ничего переводить не надо) и присылает чек;

🔸 мы готовим ТЗ + макет в Figma;

🔸 команды тратят выходные в околохакатанном формате и реализуют ТЗ на React (дополнительный стек каждая команда выберет сама);

🔸 мы с Женей делаем публичное код-ревью всем командам. Каждая команда получит 2 ревью: верстки от меня и логики от Жени;

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

🗓 Когда будет

Ивент будет длиться все выходные 26-27 октября, с 10:00 утра субботы до 17:00 воскресенья. Далее - код-ревью в течение 4 дней.

⭐️ Кто может участвовать

Все, у кого есть базовые или выше знания React (+ HTML/CSS/JS). Если вы можете набросать на Реакте простую тудушку - можно участвовать;

✉️ Как участвовать

🔸написать мне в личку (@natti_davydova) письмо, начать его с "хочу участвовать в React-ивенте", обязательно рассказать там, какой у вас опыт (чтобы я смогла сделать сбалансированные команды);

🔸заявляться можно и по одиночке, и сразу несколькими людьми;

🔸после аппрува вашего участия, вы вносите 1500 рублей в НКО "Старость в радость" (или $15 в любое аккредитованное НКО, если вы не в РФ) и присылаете мне чек;

🔸 до 20 октября включительно будут сформированы команды, и вы успеете познакомиться, подготовить репозиторий для работы и договориться по стеку (стейт-менеджер итд);

🔸26 октября получите инструкции, и начнем;

🙁 А если у нас ничего не получится?

🔸 по организационным вопросам я буду поддерживать вас в течение всего ивента;

🔸 даже если у вас не получится закончить ТЗ, вы получите код-ревью и понимание, куда самостоятельно двигаться дальше;

В любом случае, вы унесете с собой новый опыт, красивый уникальный проект и получите возможность поработать в команде (либо поменторить новичков и возглавить команду);

4 софт-скилловых совета, которые облегчат вам жизнь на работе

Я сейчас не буду выдавать вам что-то обтекаемое, типа "будьте проактивными", хочу написать конкретику, которая будет полезна тем, кто хочет не испортить себе рабочие будни.

1️⃣ Не шутите над потенциально больными для собеседников темами

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

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

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

2️⃣ Задавайте вопросы и задавайте их правильно

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

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

Например, если какая-то неочевидная штука не выходит (вылетает странная бага / не ясно, как двигаться по плохой документации / вопрос по смежному сервису итд) за 1.5-2 часа, идем писать запрос;

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

3️⃣ В ревью/фидбеках отделяйте важное от неважного

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

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

В ряде случаев, неважные замечания помечают как nit или nitpick (буквально - "я докопался до мышей, хочешь - правь, не хочешь - ну и нафиг").

4️⃣ Отказывая, всегда предлагайте альтернативу

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

Пример

К вам приходит менеджер и говорит: "надо срочно сделать вот эту задачу за 2 часа". Задача в 2 часа не впихнется, даже если уминать ногами.

❌ ответ "не успеем, вообще нереально" не поможет двинуться дальше и поставит собеседника в крайне неудобную позицию;

✔️ ответ: "не успеем в полном объеме, но можно выделить самое критичное и сделать за 3 часа, а остальное доделать еще потом за 3" уже даст место для переговоров;

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

Вывод

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

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

Выкладываю задание с благотворительного HTML-ивента

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

〰️ Суть задания

Сверстать макет на HTML/CSS/JS без фреймворков. Для слайдеров и эффектов можно брать готовые либы, а можно пробовать написать самим.

〰️ Макет

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

Поэтому слева у вас полноценный макет без картинок (со слоями и ассетами), а справа шакальный jpg, как пример, как это должно быть с картинками. Картинки вы будете вставлять на ваше усмотрение (откуда брать бесплатные hi-res иллюстрации, смотрите в разделе поста "Ассеты и тексты");

🔵 макет потребует специальных шрифтов (откуда их брать, смотрите в разделе поста "Ассеты и тексты");

🔵 к макету оставлены мои комментарии. Часть из них про какие-то обязательные моменты, часть - про то, как усложнить себе задачу, если хочется больше челленджа;

🔵 макет идет только на десктоп. (что делать с адаптивом, смотрите в разделе "Адаптив");

〰️ Ассеты и тексты

🔵картинки в высоком разрешении вы можете скачать бесплатно на Unsplash (например, по запросу Construction). Картинки будут много весить, не забудьте минифицировать их любым удобным вам способом (например, на сайте TinyPng);

🔵 в макете используются бесплатные шрифты из Google Fonts. Вы можете подключить их отсюда: Jost, Barlow (если в макете найдутся еще какие-то семейства шрифтов, ищите тоже на Google Fonts, а если там нет, заменяйте на любые понравившиеся оттуда);

🔵 если нужны дополнительные бесплатные иконки, берем с Flaticon;

🔵 местами, вам понадобятся отсутствующие тексты, например, для элементов слайдеров. Лучше генерировать разные через ChatGPT или аналоги, чем вставлять в Lorem Ipsum;

〰️ Адаптив

🔵 его в макете нет, остается на ваше усмотрение.

Попробуйте сделать так, чтобы прилично работало на стандартных брейкпойнтах (≥1400px, ≥1200px, ≥992px, ≥768px, ≥576px, <576px);

〰️ Как усложнить, если все слишком легко и быстро делается

🔵часть комментов про усложнения оставлена в самом макете;

🔵 кроме этого, можно:

▫️сделать анимации блоков на скролл (хотите - полностью кастомные, хотите - через библиотечки, например, можно подключить Animate.css и через js приделать коллбэк на скролл);

▫️перевести все на Astro / любой фреймворк;

▫️разобраться, как через сборщик автоматически минифицировать картинки;

▫️ попробовать сделать SVG-спрайты для части ассетов;

▫️добавить всякие микроанимации на ховеры и клики;

▫️написать кастомный слайдер вместо подключаемой библиотеки;

▫️ поиграть с оптимизациями (тег <picture>, critical css итд);

〰️ Ревью работ команд

Я в этих ревью много рассказывала про хорошие практики верстки:

🔵 часть #1

🔵часть #2

〰️ Мои вебинары про БЭМ

Два больших вебинара про БЭМ и нейминг, могут вам пригодиться по ходу работы:

🔵Структура HTML-страницы (часть #1)

🔵Структура HTML-страницы (часть #2)

Если у вас есть любые вопросы, задавайте в комментах!

Разрабы vs менеджеры ч.1: где ТЗ?

С большим интересом смотрю доклад "Что делать, если разработчики бесят" Серафимы Чекулаевой. Название острое, но сам доклад очень корректный и рефлексивный, лично мне заходит.

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

И первая проблема, о которой она говорит:

менеджеры приходят посоветоваться по задаче, верхнеуровнево прикинуть, что и как по фичам и срокам, а их отправляют таски заводить и ТЗ писать

Как менеджеры это видят

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

🔵 их ровно так же дерут за сроки, как и нас, причем, условный хэд продукта или инвестор не удовольствуются "а у них там оценка в сторипойнтах, будут делать то ли неделю, то ли месяц";

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

Нет смысла писать развернутое ТЗ на фичу, чтобы потом выкинуть ее из-за того, что слишком долго делать, и оно себя не оправдает. Это ужасно демотивирующе: выбрасывать часы работы в мусорку раз за разом. Куда проще "быстренько созвониться и уточнить".

Как линейные работники (разрабы/дизайнеры/QA итд) это видят

🔵 "быстренькие" созвоны неподготовлены и неструктурированы.

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

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

🔵"ну вы оцените верхнеуровнево" менеджеры легким движением руки превращают в железобетонные коммиты.

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

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

Что тут не помогает

Подход "это их работа, и меня она не касается, пусть валят все сами делать".

Как минимум, потому что мы делаем одну фичу, и тут сложно друг друга не коснуться.

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

Что тут может помочь

Для менеджеров:

🔵 формировать заранее повестку созвона и готовиться к нему. Для брейншторма не надо полного ТЗ, зачастую достаточно будет четко сформулированных вопросов и простых скетчей из прямоугольников и стрелочек в excalidraw;

🔵 закладываться на то, что точно оценить задачу в часах, если это не что-то очевиднейшее, практически невозможно. Лучше не брать верхнеуровневую оценку за жесткий коммит, плюс, стоит к ней еще докидывать сколько-то на случай нежданчиков;

Для линейных работников

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

🔵 оценивать задачи, скорей всего, все равно, придется. Но можно упростить себе немного жизнь: не оценивайте прям на созвоне, но дайте четкое время, когда сможете дать оценку. Например: "дай мне после созвона пару часов на ресерч, и я приду с вариантами";

🔵 ну и не надо лицо кривить на нетехнических специалистов, если они что-то не понимают. Это не значит, что они тупые: вам если продакт начнет за метрики плотно задвигать, вы тоже офигеете. Если вас не понимают, попробуйте переформулировать;

Следующую часть про формализм постараюсь катнуть в понедельник, там тоже интересно будет

Разрабы vs менеджеры ч.2: формализм

Разрабы vs менеджеры ч.1: где ТЗ?

Продолжаю анализировать причины недопониманий между линейными работниками и менеджерами, сформулированные в классном докладе Серафимы Чекулаевой: "Что делать, если разработчики бесят".

Вторая причина, о которой она рассказывает:

Разрабы все делают бездумно и добуквенно по ТЗ, даже если там ошибки. А потом такие: "а чо вы хотели? Как написали, так и сделано"

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

Как менеджеры это видят

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

Ошибаться - нормально, и когда твою ошибку демонстративно тащат в разработку и подают как "я сделал фигню, но ведь по ТЗ", это фрустрирует;

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

🔸если человек подходит к работе настолько формалистски и бездумно, значит, ему пофиг на проект и юзеров, и что он тогда тут вообще забыл;

Как линейные работники (разрабы/дизайнеры/QA итд) это видят

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

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

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

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

🔸 ощущение, что на тебя перекладывают чужие проблемы. Кто написал хреновое ТЗ, тому и результат выдаем соответствующий. Хотите другого результата? Давайте ТЗ получше;

Что тут не помогает

Играть в "горячую картошку" ответственности.

- вы должны классно сделать фичу!
- но вы ж не даете ни ТЗ, ни сроков!
- но можно же сделать хорошо свой код!
- но можно сделать и хорошее ТЗ, да?

Когда тычешь пальцем в соседа, дескать, все из-за него, жопошника, сосед ведь тоже ткнет пальцем в тебя. Оно надо?

Что тут может помочь

Для менеджеров:

🔸 рассказывать про продукт. Не на уровне "вот наши офигенные годовые цели", а более локально: какие сейчас проблемы? Куда движемся следующие 2-4 недели? Зачем нам те или иные фичи, что от них ждем?

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

🔸 давать время на ознакомление с ТЗ до груминга и оценок в часах/сторипойнтах. Дайте людям спокойно посмотреть на задачи самостоятельно, сформировать вопросы, и только потом просите оценки;

Для линейных работников

🔸 помнить, что на той стороне - тоже живые люди, которые задыхаются от расфокуса (после 5-7 часов созвонов в день и адской мультизадачности). Они не из вредности что-то забывают или путают в описаниях задач, как и мы не из желания напакостить можем продолбаться с кодом или дизайнами;

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

В следующий понедельник выдам 3 часть: про письменные/созвонные коммуникации

Завершилась активная часть благотворительного React-ивента для джунов

В сентябре я анонсировала благотворительный React-ивент для джунчиков-фронтов в пользу "Старость в радость".

Ребята полчаса назад завершили двухдневную разработку проекта на React (с авторизацией, MUI, запросами на бэк итд).

Заходите посмотреть, какие у них классные результаты получились ❤️

🗓 стартуем сегодня, 27 октября, в 18:00 по Мск

🎙 запись трансляции останется по той же ссылке

➡️ больше об ивенте тут

Обзор: Курс "Продвинутый Debug во Frontend"

Прошла небольшой, очень классный курс "Продвинутый debug во Frontend" от Димы Холстинина (в Kobezzza.lab).

〰️ Почему вообще решила попробовать

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

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

〰️ Что внутри курса

10 лекций общей суммой примерно часов на 7, покрывающие всю необходимую для юного дебагера инфу:

🔵 собственно, разбор debugger; и что с ним делать, чтобы было осмысленно и полезно;

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

Из самого любопытного: узнала, что есть классная штука для раздебаживания анимаций, CSS Overview с удобной статой по всей странице (цвета, типографика итд), как просто и комфортно овер-райдить и блокировать реквесты (вместо вот тех костылей, какими я сама пользовалась всю жизнь);

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

🔵 дебаг разных сред: ноды, андроида и iOS. Со второй и третьей очень ценно: рассказано, как завести эмуляторы для live-like тестирования, потому что бывает, что просто суженного браузера не хватает, и нужно попробовать вот именно Сафари конкретной версии на конкретной версии iOS;

🔵 отладка в проде: разница между dev и prod-сборками, сорсмапы, циклические импорты и что с ними делать, очень кратко затронуты штуки для логирования;

🔵 всякие некатегоризированные, но полезные мелочи: введение в eslint, анализаторы бандлов, чтобы оптимизировать ассеты, lighthouse;

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

〰️ Впечатления

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

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

〰️ Кому подойдет

Джунам, особенно тем, кто уже более-менее подружился с первым фреймворком. Миддлам тоже будет интересно, особенно если вы еще тему оптимизаций не трогали.

〰️ Кому не подойдет

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

➡️ Если вам стало интересно и кажется полезным, приходите на сайт "Продвинутый debug во Frontend", посмотрите поподробней программу. По промокоду DAVYDOVA будет скидка на 500р

Стремные мифы про "возрастных" кандидатов

У меня сгорело от вылетевших в паблик (возможно, фейковых) внутренних рекомендаций яндексовских эйчаров про "кандидатов 40+" не берем. В пепел просто, в угли сгорело. И ведь, даже если это окажется фейком, принципиально легче не становится: эйджизм в индустрии есть, выйди на хэдхантер и собирай примеры, как грибы.

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

Расскажу вам историю 3-летней давности, которую не могу забыть. Я пригласила HR-ку на митап, чтобы она поотвечала на насущные вопросы джунов. Ну и спросила, есть ли какие-то факторы, из-за которых она не покажет тимлиду идеально подходящее по скиллам резюме.

HR ответила, цитирую, следующее: "если у меня молодая, активная команда, а кандидат - дама под 30 с двумя детьми, не покажу. Как она в бар с командой будет по пятницам ходить?". Мы знатно охренели всем присутствующим составом: почти все были ~30-летние. Как и почему она решила, что после 30 люди не ходят в бар - загадка.

Так вот, про мифы.

🔸 после 30 (и после 40) люди не начинают стремительно тупеть. Почти все джуны, кого я вижу в моем сообществе, возрастом 30+, и они прекрасно учатся, отлично усваивают инфу и укладываются в изучении джун-минимума примерно в то же время, что и их младшие коллеги;

🔸 после 30 (и после 40) люди не сморщиваются, а продолжают жить активной жизнью. Не присматривают себе умиральную яму, а занимаются хобби, спортом, путешествуют, учатся новому, заводят друзей, детей, бизнесы.

🔸 после 30 (и после 40) люди не начинают по-стариковски бубнить. Они не общаются, как в том меме, "йоу, скейтборд, дискета". Маловероятно, что вы сможете угадать возраст собеседника просто по онлайн-диалогу, да и в живом общении особых различий нет. Ну, может, набор мемасиков будет чутка различаться.

Я знаю, что меня читают не только джуны, но и рекрутеры, и нанимающие менеджеры. Нет ни единой причины, почему человек 30+/40+ не сможет интегрироваться в вашу команду, если у него порядок по хардам и софтам.

Бывают ли кандидаты-жопники? Бывают, конечно, и пассивные амебы, и душные зануды, и необучаемые дурачки, но будем честны, это не от возраста зависит.

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

Как я учусь на тимлида (ч.2)

Прошла второй месяц обучения на тимлида в Стратоплане.

О том, как я там вообще оказалась
О модуле #1

Что проходили

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

А конкретнее:

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

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

🟢 базовое проведение переговоров: как общаться, чтобы не переехать собеседника асфальтовым катком или, напротив, не сдать ему все позиции.

Самое классное, что мы это потом отрабатывали, потому что мало просто о таком слушать, нужно самому пробовать, но про практику я ниже расскажу;

🔵проведение конструктивных переговоров "вниз":

- как принимать указания сверху и корректно их уточнять, как расставлять акценты в процессе;

- как определиться со своим решением по ситуации и внятно его сформулировать без "ну там на нас спустили какие-то требования, а я их просто передаю";

- как донести сформулированное команде, чтобы не демотивировать людей нафиг;

- как защищать команду, быть для нее "зонтиком";

🟡 проведение конструктивных переговоров "вверх": как лучше въехать в проблемы "наверху", через какие типы аргументов заходить, как улучшать прозрачность на каждом этапе;

Практика

Кейсов снова было много, и в этот раз мы буквально проводили ролевые игры: каждый желающий смог отработать полноценные переговоры 2-3 раза.

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

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

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

Что в итоге

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

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

Про ценность фидбека после собесов и тестовых

Фидбек на тестовые и собесы - одна из самых больных тем в найме, не важно, разраб ты, дизайнер или менеджер. Спроси сотню человек, от чего их калит, когда речь идет о поиске работы, в топ-3 причин будет "не дают развернутую обратную связь".

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

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

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

Какой только ерунды я ни встречала в фидбеках на тестовые знакомых джунов/пре-миддлов. Порой, хотелось спросить: "чувак, а ты точно разработчик? Или нейросетка, прикидывающаяся человеком?".

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

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

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

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

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

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

Что делать, если хочется получить развивающий фидбек

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

И вот когда вы синтезируете что-то среднее из нескольких таких отзывов, получите ценный и более-менее объективный результат.

А завязывать свою самооценку на фидбеках от черт-те кого и в черт-те каких обстоятельствах - оно вам надо?