Вы не вошли.
Каталог полезных советов и ссылок, принесенных разными it-анонами, c 1-й по 332-ю страницы:
анон с обучением руководству в айти, я пришёл из общерабочего треда!
анон с обучением руководству в айти, я пришёл из общерабочего треда!
Ага, привет. Если я правильно понимаю, у тебя два разных вопроса: "как продать идею руководства" и "как этому руководству учиться" (поправь, если это не так).
Так вот, если "как продать" - то лично для меня главным selling point было именно расширение компетенций. Но при этом человек, которого ты в это втаскиваешь, должен очень четко понимать, что хороший разработчик (аналитик, QA, кто там еще бывает) и хороший тимлид (техлид, engineering manager, вот это всё) - это две очень, очень разные вещи, они вообще не совпадают. я неоднократно видел, как брали хорошего разраба, и всё то, что делало его хорошим разрабом, превращало его в токсичного микроменеджера, от которого взвывала вся команда.
Но, понятно, в зависимости от конкретного товарища, мотивировать могут и деньги, и погоны на плечи. Просто в моей практике, если деньги и погоны - единственная мотивация, оно работало плохо, и если человеку неинтересно именно управление людьми, то надо давать деньги и погоны по-другому, а к живым людям его не пускать. Но это мое личное убеждение, его многие считают неправильным.
Если про "как учиться": когда я начинал, был очень вменяемым "Стратоплан". С тех пор они убрали очень много материалов в платные курсы, понабрали тренеров разной степени раздражательности (меня лично, опять же, если ты берешь совсем неопытного чувака, ему как раз может зайти), но наверное, именно в русскоязычном сегменте ничего более вменяемого я всё ещё не видел.
В англоязычном сегменте вариантов больше, но там я в основном читаю книжки и статьи, и тут всё зависит от того, что именно сейчас "болит" у команды, на какой она стадии, чего хотите добиться. Если у чувака под началом оказывается сложившаяся команда из русскоязчных токсиков с проблемами в процессах - это одно, если чуваку надо нанимать команду под себя из индусов - это вообще про другое. Тут только гуглить, прикладывать к конкретной команде, проебываться, рефлексировать, гуглить и пробовать снова.
Опять же, если совсем новичок - есть LinkedIn Learning, можно купить подписку и пусть проходит все базовые курсы про то, что людям надо показывать светлое будущее, общаться ненасильственно, как выявлять проблемы в процессах, как делать 1:1, как делать найм и онбординг и как увольнять так, чтобы не получить эль-скандаль на весь хабр в РФ или судебный иск, если не в РФ.
Это если навскидку. Не знаю, помогло или ты вообще про другое?
Аноны, извиняюсь за оффтоп, но мне нужна помощь.
Посоветуйте годный бесперебойник для пк, чтобы держал заряд и можно было нормально выключить комп, когда рубят электричество. Раньше (лет 15 назад) у меня был Cyber, он минут 10 без электрики работал, а года три назад я купил новый, тоже Cyber, он ни минуты не держит((
Что сейчас годного поставляют на российский рынок? Что можете посоветовать?
Аноны, извиняюсь за оффтоп, но мне нужна помощь.
Посоветуйте годный бесперебойник для пк, чтобы держал заряд и можно было нормально выключить комп, когда рубят электричество. Раньше (лет 15 назад) у меня был Cyber, он минут 10 без электрики работал, а года три назад я купил новый, тоже Cyber, он ни минуты не держит((
Что сейчас годного поставляют на российский рынок? Что можете посоветовать?
У них же мощность разная бывает, анон. Если ты взял слишком маломощный, то он держать не будет, конечно. Надо плясать от мощности твоего блока питания. А так любой с подходящей мощностью должен держать, если он не бракованный. Я брала Ippon с год назад, норм держит.
Надо плясать от мощности твоего блока питания
А как это можно узнать? Просто я нуб совсем в этих вопросах.
Если я правильно понимаю, у тебя два разных вопроса: "как продать идею руководства" и "как этому руководству учиться" (поправь, если это не так).
Спасибо, что расписал, анон!
У меня скорее ситуация, что некоторых принудительно поставили тимлидами (оооочень условными), но чтобы не копить фрустрацию, я б им хотел подкинуть каких-то суперкоротких книжек или курсов смешных. ЛинкедИн есть, но меня там ничего не вдохновило, может, искал не так, хз. Короче, надо людям вернуть фан, что быть лидом можно, нужно, не страшно. Если ты знаешь название книжки про это или можешь ткнуть носом, куда рыть, моё тебе с кисточкой.
Даже если прям одно название можешь сказать про engineering management, может, хоть меня спасёт
У меня скорее ситуация, что некоторых принудительно поставили тимлидами (оооочень условными), но чтобы не копить фрустрацию, я б им хотел подкинуть каких-то суперкоротких книжек или курсов смешных. ЛинкедИн есть, но меня там ничего не вдохновило, может, искал не так, хз. Короче, надо людям вернуть фан, что быть лидом можно, нужно, не страшно. Если ты знаешь название книжки про это или можешь ткнуть носом, куда рыть, моё тебе с кисточкой.
Даже если прям одно название можешь сказать про engineering management, может, хоть меня спасёт
Блядь, я смотрю, эта прекрасная тенденция превращать хороших разрабов в так себе руководителей не умирает Окей.
Тогда можно глянуть вот тут:
https://www.youtube.com/@StratoplanSchool - это Стратоплан (они мне всё ещё не платят за рекламу, а жаль). Если боль больше на стороне проджект-менеджмента (не пипл-лидства), то прицельно можно смотреть видео Орлова из Стратоплана, кмк, мало кто так хорошо рассказывает о том, что, блять, работает из этого нашего аджайла на практике, а что не очень (у него видео раскиданы по разным каналам, можно искать по "александр орлов стратоплан"). Именно в категории "смешно и ненапряжно": Черная книга Скрам: https://iselihovkin.com/book .
Опять же, посмотреть видео под интересующую проблему, еще можно тут: https://www.youtube.com/@ManagementChannel (тут и проджект, и пипл-лидство)
Я зашел на курсеру, охуел от выдачи на 22 страницы про тимлидство, - наверное, можно еще посмотреть там и на Udemy.
Про engineering management: сам не читал, но ее рекомендовали мне независимо сразу два человека, которым доверяю: An Elegant Puzzle: Systems of Engineering Management by Will Larson. Но хз, насколько оно новичку.
Опять же, вопрос: что у вас понимается под EM. Если туда же входит еще проджект менеджмент, то им надо прочитать а) скрам-гайд (не аджайл манифест, а именно что гайд), и если у вас нет возможности делать нормальный скрам (а она есть, по-моему, только у фаанг и еще топ-5% рынка), то б) что-нибудь базовое по канбану (тут индустриального стандартна нет, последний раз, когда я смотрел, более-менее универсальным был Essential Kanban Condensed). Ну и в качестве совсем тяжелой артиллерии можно заполировать PMBoK. Но кажется, это не очень удовлетворяет твоему реквесту по суперкороткое, ненапряжное и не-демотивирующее
Не знаю насчет тимлидства, но я бы давал эту книжку любому разрабу, который выходит за пределы миддла: Soft Skills: The software developer's life manual by John Sonmez .
С пипл-лидством "смешно и ненапряжно" у меня что-то совсем пусто. Это тот кусок, который я бы рекомендовал искать под конкретную боль. Из серии: твои тимлиды хорошо делают 1:1? Если нет, то пусть читают и учатся делать их. Когда пройдут этот этап, пусть копают дальше по следующей острой боли
У меня скорее ситуация, что некоторых принудительно поставили тимлидами (оооочень условными), но чтобы не копить фрустрацию, я б им хотел подкинуть каких-то суперкоротких книжек или курсов смешных.
А вообще знаешь, я тут подумал. Понимаешь, де-факто, у тебя тимлиды-джуны. Причем, судя по всему, не сильно мотивированные джуны.
И... я вот вообще не уверен, что тут какие-то книжки и курсы помогут. Если бы я в успехе такой хуйни был заинтересован, наверное, я бы или сам менторил чуваков, или нашел бы им менторов, которые бы их плотно держали за лапку неделю за неделей, с планом развития и освоения компетенций, 1-ту-1, и вот этим всем заворачиванием в ватку.
Отредактировано (2023-03-30 21:51:24)
прекрасная тенденция превращать хороших разрабов в так себе руководителей
Я другой анон, но если тебе не сложно - можешь тоже дать совет? Под катом длинная простыня.
ЗЫ: спасибо за ссылки и рекомендации, я это всё постараюсь изучить.
Отредактировано (2023-03-30 23:04:50)
Блядь, я смотрю, эта прекрасная тенденция превращать хороших разрабов в так себе руководителей не умирает Окей.
Анон, тебе смешно, а как теоретически построить работу людей, которых кинули в один котёл, причём старые разрабы адекватики, про новых сказать ничего нельзя, и это все, что у нас есть. И новые хлопают глазами с ожиданием скрама-хуяма, а старые понимают всё с полуслова и их, блин, не предупреждали, что они теперь курицы-наседки для малолеток и свалившихся с неба сеньоров. А, и всё это равноудалено по глобусу друг от друга и от менеджмента. И ещё корона, когда даже тревел под запретом был.
То, что я не поседел, я скидываю только на то, что ослеп и просто не вижу в зеркале седых волос.
За ссылки и книжки отдельное спасибо, что заморочился и всё разложил
У меня скорее ситуация, что некоторых принудительно поставили тимлидами (оооочень условными), но чтобы не копить фрустрацию, я б им хотел подкинуть каких-то суперкоротких книжек или курсов смешных
Книжка «Как пасти котов» Самые основы, зато название байтит.
Книжка «Как пасти котов» Самые основы, зато название байтит.
Спасибо!
Миддлы- радостно схватили клавиатуры и начали хуячить велосипеды из говна и палок, вместо использования уже существующих механизмов, и даже не задавшись вопросом об их существовании. Я это почти сразу отсек, объяснил, что велосипеды надо уничтожить и в следующий раз спрашивать меня.
Анон, ты прости, но это выглядит как описание очень плохой архитектуры с кучей велосипедов (твоих собственных).
с ними уже попробовали, как со взрослыми, они чот не смогли. Что блин делать-то? Да, я могу в качестве дубинки привлечь РП, но это же не дело его дергать каждый раз, хотелось бы самому как-то разобраться.
А в чём сейчас проблема? Они не прочитали документацию? Они прочитали, но не поняли её? Они по ней не вкурили, как делать ваш проект? Есть что-то, на чём они застряли?
У нас помогало такое: если разработчик не понимает, что и где писать, или пишет хуйню, сначала собираемся и рисуем на настенной доске, что и как мы делаем, не на самом абстрактном уровне, а чуть поглубже. "Берём вот такую объектную модель, вот такой стек, нам надо реализовать вот такие сущности, мы делаем это вот так".
На этом этапе вопросов может не быть не потому, что люди всё отлично поняли, а потому, что они не поняли достаточно, чтобы задавать вопросы.
Эту ситуацию, кстати, для себя проработай отдельно, тебе надо понимать - не задают вопросов потому, что всё понятно, или потому, что нихуя не понятно.
Что бывает у вас с человеком, сказавшим, что он нихуя не понял - орут ли на него? У нас всё стало лучше, когда мы договорились, что можно говорить "я нихуя не понял" или "я не понял, как это писать" и не получить пиздюлей и презрения от тех, кто понял лучше. Понятно, что миддл должен что-то сам понять, но если он не понял и скрывает, что не понял, потому что он живой человек и не хочет получить пизды - вы далеко не продвинетесь. У человека должна быть возможность сказать "я застрял".
У вас канбан какой-то есть или его аналоги? Трекер, задачки, их состояние? Каждый разработчик может показать и объяснить, чем он сейчас занят, в общем трекере и в среде разработки?
А в чём сейчас проблема? Они не прочитали документацию? Они прочитали, но не поняли её? Они по ней не вкурили, как делать ваш проект? Есть что-то, на чём они застряли?
Не прочитали документацию. Точнее так: часть людей прочитали документацию и техпроект, задали вопросы по тем местам, которые не поняли, обсудили со мной что надо делать и успешно делают. Один человек не прочитал документацию и тех.проект, теперь спамит в общий чат вопросами, ответы на которые есть в тех.проекте и той документации, которую он не прочитал. То есть буквально - "а мы используем технологию Х для вот этого?", когда в тех.проекте русским языком написано - "для вот этого мы используем технологию Y по такой-то причине"
У нас помогало такое: если разработчик не понимает, что и где писать, или пишет хуйню, сначала собираемся и рисуем на настенной доске, что и как мы делаем, не на самом абстрактном уровне, а чуть поглубже. "Берём вот такую объектную модель, вот такой стек, нам надо реализовать вот такие сущности, мы делаем это вот так".
На этом этапе вопросов может не быть не потому, что люди всё отлично поняли, а потому, что они не поняли достаточно, чтобы задавать вопросы.
Это как раз было сделано, я несколько раз объяснял людям архитектуру с общими схемами, схемами отдельных блоков, что мы где используем, зачем это используем.
Что бывает у вас с человеком, сказавшим, что он нихуя не понял - орут ли на него? У нас всё стало лучше, когда мы договорились, что можно говорить "я нихуя не понял" или "я не понял, как это писать" и не получить пиздюлей и презрения от тех, кто понял лучше. Понятно, что миддл должен что-то сам понять, но если он не понял и скрывает, что не понял, потому что он живой человек и не хочет получить пизды - вы далеко не продвинетесь. У человека должна быть возможность сказать "я застрял".
Если не понял - ему объясняют. Дают документацию. Ещё раз объясняют индивидуально. Конкретно этого человека поставили на конкретный блок, потому что он а) уже имеет опыт разработки подобных вещей по нужной технологии б) как раз разрабатывал этот блок, его надо только расширить в) имеет опыт самостоятельной разработки. Результат - человек жалуется на то, что не знаком с нужной библиотекой (с которой он уже работал и документацию по которой должен был ещё раз прочитать, об этом всем говорили, документацию скидывали, время выделали), непрерывно спамит меня и общий чат вопросами, из которых становится предельно ясно, что документацию он либо не читал, либо вообще не понял, о чем там речь. И это полбеды, но приходится по два-три раза отвечать ему на один и тот же вопрос. Буквально:
У вас канбан какой-то есть или его аналоги? Трекер, задачки, их состояние? Каждый разработчик может показать и объяснить, чем он сейчас занят, в общем трекере и в среде разработки?
Есть, трекер, задачки, состояние, ежедневные мать его планерки с объяснением кто чем занят и что планирует. На вчерашней вечерней планерке с участием РП полчаса занял отчет четырех разрабов по задачам проекта и проблемам, с которыми они столкнулись и ещё час - ответ на вопросы одного человека (угадайте, кого).
Анон, ты прости, но это выглядит как описание очень плохой архитектуры с кучей велосипедов (твоих собственных).
Я, если честно, не понял, с чего ты сделал такой вывод. У нас есть определеный механизм, допустим, интеграции с какой-то внешней системой. Задача разработчика при передаче данных в эту систему - использовать существующий механизм, а не клепать свой собственный отдельный велосипед. Ты считаешь это очень плохой архитектурой?
Мне кажется, проблема в том, что некоторым разрабам впадлу читать доку, оттуда и вопросы. И этим разрабам надо вставить пиздюлей.
Мне кажется, проблема в том, что некоторым разрабам впадлу читать доку, оттуда и вопросы. И этим разрабам надо вставить пиздюлей.
простой, но неправильный ответ.
правильный - устроить совместные чтения. да, долго, но единственное, что работает.
Анон пишет:Мне кажется, проблема в том, что некоторым разрабам впадлу читать доку, оттуда и вопросы. И этим разрабам надо вставить пиздюлей.
простой, но неправильный ответ.
правильный - устроить совместные чтения. да, долго, но единственное, что работает.
Да я и не говорю, что мой вариант правильный) но пиздюли бы тоже проблему решили. Но соглашусь, что совместные чтения с рисованием деталей на вайтборде все же эффективней.
Задача разработчика при передаче данных в эту систему - использовать существующий механизм, а не клепать свой собственный отдельный велосипед. Ты считаешь это очень плохой архитектурой?
Я полностью понимаю, что сужу о том, чего в глаза не видел, но в моем опыте "у нас кастомная интергация" всегда оказывалась велосипедами с нарушением солида. Обычно никто не может объяснить, почему не используются стандартные решения или популярные библиотеки, кроме как "нам хотелось написать свое". Или "сложный проект", но в чем конкретно неподъемная сложность не объясняют.
Т.е. я хочу сказать, что сам подход "новым разрабам нужно выучить наизусть десять талмудов чтобы работать на нашем проекте" очень сильно попахивает плохими практиками. На последнем моем проекте джуну надо узнать что такое gRPC, чтобы работать с внешними сервисами.
Т.е. я хочу сказать, что сам подход "новым разрабам нужно выучить наизусть десять талмудов чтобы работать на нашем проекте" очень сильно попахивает плохими практиками.
у нас в конторе только два правила: если вы чего-то не знаете, вы идёте и спрашиваете. не спрашиваете вы, спрашивают с вас.
и второе: если к тебе пришли с вопросом - ответь. РТФМ за ответ тоже считается, если действительно в нем это написано. сказать "я не знаю, зато знает Вася" тоже считается.
магическим образом, когда к тебе приходят и вместо "я нихуя не понимаю" говорят "я прочитал тут, и сделал так, но написано, что должно быть 10, а у меня выходит -100, что за хуйня" - и отвечать легче, и общая грамотность повышается.
У нас помогало такое: если разработчик не понимает, что и где писать, или пишет хуйню, сначала собираемся и рисуем на настенной доске, что и как мы делаем, не на самом абстрактном уровне, а чуть поглубже. "Берём вот такую объектную модель, вот такой стек, нам надо реализовать вот такие сущности, мы делаем это вот так".
На этом этапе вопросов может не быть не потому, что люди всё отлично поняли, а потому, что они не поняли достаточно, чтобы задавать вопросы.
Можно еще реверснуть и сказать: "напиши последовательно, что и как ты будешь делать, ДО того, как ты это сделаешь. И неси на ревью, ДО того как начнешь делать". За спам вопросов вида "сепульки и сепуляторы" - говорить "иди думай над вариантами и продумай все решение от и до, на ревью обсудим твои вопросы".
Но вообще, конечно, это не миддловый уровень, имхо, это джун+. И тут вопрос: либо чувак стремительно в него деградировал (вопрос, почему?), либо он всегда таким был, тогда не надо рассчитывать на миддловый уровень самостоятельности. Правда, мне говорили, что у меня охуевшие критерии для миддлов, так что допускаю, что я охуевший в этом смысле.
Анон, тебе смешно, а как теоретически построить работу людей, которых кинули в один котёл, причём старые разрабы адекватики, про новых сказать ничего нельзя, и это все, что у нас есть. И новые хлопают глазами с ожиданием скрама-хуяма, а старые понимают всё с полуслова и их, блин, не предупреждали, что они теперь курицы-наседки для малолеток и свалившихся с неба сеньоров. А, и всё это равноудалено по глобусу друг от друга и от менеджмента. И ещё корона, когда даже тревел под запретом был.
То, что я не поседел, я скидываю только на то, что ослеп и просто не вижу в зеркале седых волос.
Да мне не то что бы смешно, я просто повидал достаточно много дерьма
Но если тебе не выговориться, а реально обсудить, - я пока не очень понимаю проблему. Старые разрабы саботируют менторинг? Все процессы покрашились с приходом новых разрабов? Перформанс просел из-за провалов в коммуникации? С перформансом все норм, но команда крашится? Что-то ещё? А в чем объективно оно выражается?
Короче, сама по себе удаленная команда в стадии сторминга (ты же в курсе, да, про вот эти стадии жизни команды?) - это нормально и ничего особо уникального в самой ситуации, кмк, нет. Дальше вопрос про конкретную проблему (если она вообще есть).
Старые разрабы саботируют менторинг?
Вот это, да.
Дополню: Естественно, из-за провала в коммуникации. Руководство сделало неправильно всё, что можно было сделать неправильно, но это фиг с ним, мы уже пережили. Отсутствие личных (неформальных) контактов. Очень жесткое соблюдение процессов (привычных для старых, чудных для новых), чтоб всё не посыпалось (не посыпалось), не оставило никому свободного времени, чтобы не раздражаться на глупые вопросы.
Отредактировано (2023-03-31 19:08:18)