Айти — командная игра. Одиночки в ней давно неконкурентны.
Индустрия позврослела, перестала верить в сиюминутную сингулярность, и на первое место вышли люди и отношения между ними, а не процессы и технологии. К сожалению, иногда этого не понимают ни программисты, ни рекрутеры, ни некоторые менеджеры.
Слово «команда» в айти все еще считается баззвордом из HR'ского паверпоинта, а быть «менеджером» — зашкварно, из-за каких-то старых душных баек про «был хороший программист, а стал плохой менеджер».
Да вы не волнуйтесь так, мы и как программисты так-то были не очень!
У меня уже было два поста на схожую тему: Войти в Айти — для самых маленьких, и Краткий гайд о том, как нанимать нормальных людей — для тех, кто постарше. Оба они описывали лишь часть картины, потому переставали мне нравиться уже через неделю после выхода.
Сегодня я хочу копнуть поглубже. Расскажу как с опытом менялось моё восприятие мира айти, какие типы людей и компаний я начал замечать, и как вести себя в зависимости от этого.
Как обычно, всё написанное — компиляция моего субъективного опыта за 13+ лет в индустрии, который я получил в основном общаясь с другими, более умными людьми. За что им спасибо. Думаю, они себя узнают здесь.
Отдельное спасибо Вастрик.Клубу за инсайды и опыт, который лег в основу этого поста
upd: Появилась версия на английском
upd2: Пост обновлён и актуализирован на 2021 год
😎 Понимать кто ты сам и что дальше. Синдром самозванца в айти сегодня популярнее некуда. Лекарство от него — научиться понимать кто мудак, ты или чувак напротив. Ну и осознать что же такое творится на более высоких уровнях (вам ведь тоже когда-то придется их занять).
💃 Научиться находить и собеседовать правильных людей. Рекрутеры хорошо работают как фильтр входящих, но головой думать приходится всё равно нам.
👨👨👦👦 Собирать из них крутую команду. На разных уровнях нужны разные юниты. Надо трезво понимать каких персонажей вам не хватает, а каких в избытке. Какие сработаются, а какие нет. Какие скоро уйдут, обвинив компанию в предательстве, и кого надо нанять на их место (или пора бы уже валить самому).
🤦♂️ Наводить отношения с разными по духу людьми. Понять как общаться с тем чуваком, который уже месяц не может добавить тебе поле в API, постоянно требуя согласовать его с менеджером, СЕО, уборщицей.
👵 Знать, что делать в айти когда ты дед.
Почему в качестве буллета для сбора крутой команды использован эмодзи гей-пары с детьми? Как же разнообразие цветов кожи?
Ну вот, одно пропущенное слово «белой» и шутка из просто несмешной становится непонятно несмешной. Почему нельзя редактировать комментарии?
Гейский эмодзи метафорически символизирует засилие патриархата и токсичной маскулинности в айти. Как же еще.
Опечатка: уборшицей -> уборщицей
Они как минимальный набор приборов в самолёте, на которые надо время от времени смотреть, чтобы понимать где находишься. Иногда это очевидно, а иногда приходится вести машину исключительно по ним. Вот с командой так же.
Сегодняшняя моя теория будет строиться вокруг трёх показателей:
1️⃣ Этап эволюции проекта
2️⃣ Уровни персонажей
3️⃣ Классы персонажей
Каждый из них по-своему важен. У любого хорошего менеджера они входят в список базовых софт-скиллов. Но не у всех.
Разберём их подробно.
В конце поста я дам референсы на оригинальные книжки и модели, которые легли в основу рассказанного, но сейчас постараюсь не грузить вас булщит-коучингом.
В посте Войти в Айти я делил компании на Кровавые Интерпрайзы, Галеры, Стартапы, и.т.д. Такое разделение близко к народу, потому и собрало огромное число лайков, однако реальной пользы от него мало.
Реальные компании редко бывают чистокровными представителями одной из крайностей. Внутри кровавого корпората всегда есть экспериментальные проекты-стартапы, а маленькая продуктовая компания всегда может скатиться в аутсорс/аутстаф-галеру, обслуживающую крупного инвестора или заказчика.
Деление компаний по профилю полезно лишь для первого приближения. На практике важнее понять что там за проект. Так мы приходим к первой важной картинке поста:
В картинке ниже в "Цикле роста" на стрелках "взлетаем" и "пилим новое" (судя по блоку текста "Цикл роста")?
Любой проект (или вся компания, если у нее один проект) проходит свой путь от «стартапа», через долину «взрывного роста», выходит на плато «успешной компании» и потом качается на волнах «допиливания-реструктуризации». На любом из этих этапов можно просрать все полимеры и свалиться в «провал» или «кризис».
Новый цикл эволюции проекта — как новая карта в RPG. Резко меняется количество ресурсов, типы юнитов, их мотивация и цели всего похода
Понимать это головой сложно, потому что эволюция идёт медленно и не заметна глазу. Но нужно.
Ниже я положу картинку где на этой карте находятся популярные айти-компании, на мой взгляд.
Василий, не прими за личное - но многие проекты в суровых DAX-компаниях совсем не подходят под это определение "любой проект".
Мы говорим о BMW, Audi, Siemens, Krupps - да и ABB, SAP и многое другое.
Про любой проект/компанию.
Егор Бирюков, аааа, откуда мнение, что в NASA без митингов и агиля работают? :/
я только крутить деревья умею, поэтому хотел бы сказать, что имелся ввиду конечный автомат, а не цепь маркова
Как обычно, ИМХО. Картинка основана исключительно на моих ощущениях. В комментах ниже можете приводить примеры ярких, по вашему мнению, представителей того или иного цикла.
А как же Яндекс и МРГ?
А там же внутри дофига разных проектов на разных стадиях. От Яндекса на картинке есть Лавка :)
Кажется, процессорное направление Intel в жопе и должен проследовать за AMD
А почему AirBnb в жопу летит? Я не следил за ними, но вроде все хорошо у ребят, не?
Постоянно вижу новости, что у AirBnB проблемы с баблом. Роста нет, плюс их зарегулировали во многих странах и будут прессовать еще больше. Их попытки уйти в другие рынки (лакшери и туры) провалились. Сейчас вся sharing economy летит в пизду, ломая влажные мечты об "уберизации" всего подряд из 2010-х годов
а такси, такси где?
Last.fm жаль
Для бодишопов картинка будет немного другая. После первого выхода на плато успеха и шагов к реструктуризации, уже всё, какая-то часть будет всюду плотно реструктурироваться, другая мимикрировать под стартап, везде будет ощущаться немножко кризис, но это мб потому что я не особо бюрократ
Medium уже в жепе.
А Airbnb чего в жопу летит?
Пользуясь случаем, реквестую пост про прошлое, настоящее и будущее shared economy
Как таксист со стажем я бы разделил Убер на субкомпании - eats, freight, ATG и обычный RIde разные компании на разных этапах (финансово тоже)
Забавно видеть свою компанию на карте, и осознавать, где она была 4 года назад, когда меня нанимала 😁
что не так с Medium? вроде ничё так платформа, популярная. Не?
Про Sublime Text не понимаю - офигенный текстовый редактор, с каждым релизом работает всё лучше и лучше, он по баблу скатывается, или что?
А вот Facebook/Atlassian/Dropbox на деле выглядят летящими в жопу)
Хотя может это всё уже устарело просто к середине 2020
токсичный @oleg
twitter реструктурируется после того как полетел в жопу, по ощущениям
stadia сделала гоп в клеточку RIP
Мотивация: ⭐️⭐️⭐️
Команда: ⭐️⭐️⭐️
Ресурсы: 💩💩💩
Стабильность: 💩💩💩
Клетка «старт». Запускаем проект с нуля любыми доступными ресурсами.
Цель Собрать воедино все возможности и запустить продукт. Ограничений нет, но обычно мало ресурсов и никакой стабильности.
Главное преимущество стартапа — его скорость и, да-да, маленькость. Не мне вам объяснять, что если стартап целится в «новый Facebook» — это сразу провал.
Хороший стартап понимает, что завтра может сдохнуть (и в 99.999% так и будет). Самое плохое, что можно тут сделать — начать думать на долгий срок — строить процессы, писать документацию, размышлять о миллионах, и.т.д. Потому тут нужны люди, понимающие и одобряющие такой «распиздяйский» подход.
Команда Кучка гипермотивированных чуваков. Обычно минимум душнил (они не умеют в стартапы). Высокие грейды не нужны (одного сеньора хватит), нужна производительность. Бюрократии нет, но и процессов тоже.
Фокус Больше делаем, меньше думаем.
Запускаем проект с нуля или внутри большой компании — не важно.
Разница огромная, делал и то, и то.
В большой компании у тебя (почти) нет проблем с ресурсами (внезапно в твой стартап можно захайрить целый отдел, не нужно думать про раунд инвестиций и cash burn), но есть огромное количество проблем со всей бюрократией (нельзя нанимать "неправильных" людей, нельзя выбирать "запрещенные" технологии).
В целом "стартап в большой компании" это худшее из двух миров, в моем опыте.
Егор Бирюков, согласен, что-то я психанул в этой строчке
Вастрик, а нет ли ощущения, что документация -- это самое важное, светлое, и прекрасное, что можно сделать для IT проекта? Да, в стартапе наверняка часто меняют все подряд, но документация даёт возможность понять происходящее N новым людям и безболезненно заменить старое. Или я не прав? Не стоит писать хотя бы общие доки в стартапе?
Привет из "стартапа в большой компании". Очень зависит от деталей реализации, бывает, что зэды корпорации относятся к стартапу как к черненькой коробочке, которая высасывает твои инвестиции пару лет, потом выходит на самоокупаемость и уже начинает в ответ срать деньгами тебе в лицо. В такой реализации для сотрудника проблем мало: никому за пределами коробочки не интересен контингент работников, в случае неудач компанию закрывают, вирусом стартап не сносит. В случае явного провала всех распускают, пожимают руки и прощаются на позитивной ноте.
Егор Бирюков, худшее или лучшее - это сугубо личное восприятие )) аналогично - опыт и там, и там - внутренний стартап комфортнее - требуется больше коммуникационных (вернее, политических) скиллов + админ поддержка, которой надо заручиться сразу - без нее, да, сдохнет все быстро
Dmitry Burlakov, имхо, в хорошем стартапе всё так быстро меняется, что лучшая тех.документация — это таск-трекер, а продуктовая/маркетинговая — архив роадмапов общими мазками. То есть ходовые сущности, которые ты так и так генеришь. Главное, чтоб не на словах всё.
согласен с Егор Бирюков - стартап внутри компании это очень такое себе
Мотивация: ⭐️⭐️💩
Команда: ⭐️⭐️💩
Ресурсы: ⭐️💩💩
Стабильность: ⭐️⭐️💩
Стартап превратился в продукт, который зарабатывает и растёт. Начинается цикл роста, который является по сути метанием между двумя состояниями — «фигачим новую фичу» (опять как стартап) и «стабилизируем успех».
Цикл понятный и приятный. Проблема лишь в том, что с каждой итерацией любая компания всё больше тяготеет к стабилизации, чем к стартапам. Люди выдыхаются и хотят уже свою бэху.
Цель Выйти на стабильную высоту. А потом повторить.
Тут уже можно писать документацию, отдавать технические долги (никто ведь не мог подумать, что юнит-тесты пригодятся!), нанимать персонажей в команду для новых рейдов.
Команда Первые неприятные перемены. Отваливаются выгорающие, приходят новые, но чуть менее мотивированные чуваки. Появляется бюрократия, но пока в разумных пределах. С каждой итерацией всё больше.
Фокус Делаем и думаем пополам.
По моей практике, на этой стадии обычно отваливаются выгорающие старички. Те, кто был на старте и строил собственноручно, но так и не получил бэху. Печальное зрелище вселенской несправедливости. Особенно, когда ещё не столько ресурсов и стабильности, чтоб привлекать «незамотивированных чуваков»
мляяяя, так вот где я щас((
хахаха не в бровь, а в пах
Мотивация: ⭐️⭐💩
Команда: ⭐️💩💩
Ресурсы: ⭐️⭐️⭐️
Стабильность: ⭐️⭐️⭐️
Деньги льются рекой, процессы налажены, структура устойчива, корпоративная машина движется по рельсам и вряд ли завтра остановится. Фаундеры дописывают мемуары «успех — это просто».
Стабильность. Никто не хочет ничего менять.
Проблема одна: ни одна компания не задержится здесь надолго. Внутренние склоки и растущая бюрократия обязательно всё испортят. Такова человеческая природа.
Цель Отдохнуть. Никто ничего сделать всё равно не успеет.
Команда Как правило на этом этапе из членов «старой» команды остаётся один-два человека. Остальные отваливаются из-за невыносимой бюрократии, окешивают свои опционы и уходят в новые стартапы.
На их место приходят обычные среднячки с рынка, которые хотят делать то, что им говорят, уходить с работы в пять и ходить на тим-ивенты играть в душные паб-квизы. Ну, это их хотя бы мотивирует.
Фокус Ничего не делаем и не меняем, сидим думоем строим бюрократию.
Видно опыт Delivery Hero тебя травмировал.
"ни одна компания не задержится здесь надолго", а что насчёт Google?
У гугла довольно деверсифицированиые активы) Куча сервисов которые живут своей жизнью. Причем насколько я знаю там автономные команды, которые между собой мало пересекаются. И среди их продуктов есть успешные и те которые уже давно умерли
Мотивация: 💩💩💩
Команда: ⭐️💩💩
Ресурсы: ⭐️⭐️💩
Стабильность: ⭐️⭐️💩
Самое неблагодарное время. В кризис пока никто не верит, ведь «мы десять лет так делали и всё было хорошо», но компания уже явно летит вниз. Любая успешная попытка спасти ситуацию воспринимается как должное, так что больших бонусов не ждите. Из плюсов: всё еще сильная инфраструктура и много денег.
Цель Точно найти болевые точки и пристрелить их, не совершая резких движений, который могут заметить бюрократы.
Команда Демотивирована. Последний «старожил» вчера ушел работать в FAANG. Все вокруг токсят и скроллят линкедин. Даже цитаты про «успех всегда даётся нелегко», развешанные HR'ами по офису уже как-то не помогают. СТРАННО.
Фокус Вроде как что-то делаем, но пока в основном думаем и объясняем бюрократам необходимость перемен. Они не верят.
Это — время менеджеров. Простой разработчик вряд ли сможет что-то изменить, его сразу забьют палками.
Почему никто не любят hr?а, знаю
Мотивация: ⭐️⭐️💩
Команда: 💩💩💩 (обычно приходится менять)
Ресурсы: ⭐️💩💩
Стабильность: ⭐️💩💩
Когда проваливается реструктуризация и кончаются ресурсы, начинается полноценный кризис. Его, наконец-то, замечают все.
Кризис как зима для коммунальных служб — всегда внезапен.
Поэтому самое сложное в кризисных компаниях — что не все еще понимают, что пришел пиздец, и все еще пытаются играть в реструктуризацию. Но в отличии от нее здесь нужно не придумывать новые процессы, а выбрасывать старые — в этом главное отличие.
Цель Спасти корабль любыми способами, даже если это означает полный разворот.
Команда Обычно меняется полностью вплоть до менеджмента. Старые члены стали такими токсичными, что с ними невозможно даже разговаривать. Зато наконец-то отступает бюрократия, что возвращает всех во времена стартапа. Нужно просто уметь правильно всё подать.
Именно поэтому «антикризисные менеджеры» по сути те же стартаперы
Фокус Много делаем, пофиг что менять, главное — выжить.
Выход из кризиса может создать совершенно новую компанию с обновлёнными продуктами и целями, что заново запустит рост или реорганизацию. Пример — Microsoft.
А может и нет.
Даешь стикерпак!
Иван Белый, https://t.me/addstickers/vas3k_wtf
А инвесторы и кредиторы не выебут?
А если делал на свои то грусненько, все деньги просраны
За смерть-то? Конечно выебут. Так что инвесторов надо выбирать не в долине, а с умом
Каждая айти-компания сегодня придумывает свои уровни градации разработчиков. У Яндекса их восемь, у Microsoft тринадцать, а у Netflix вообще один — там каждый по-умолчанию Senior Engineer потому что Fuck The Police, видимо.
За сравнением, как обычно, отправляю всех на levels.fyi.
Корпоративные грейды нужны чтобы увеличить количество ступенек карьерной лестницы внутри компании. Потому что если не повышать программиста минимум раз в год — он грустит и уходит работать в FAANG.
Для внешней же оценки эти уровни мало годятся. В разных компаниях они несовместимы, а единой шкалы так никто и не придумал.
Штош.
За годы разговоров с друзьями из айти мы выработали общую для всех нас линейку. Сейчас она вполне стабильна и неплохо помогает при найме. Она базируется на привычных ступенях джун-мидл-сеньор, и, наконец-то, строго их разделяет.
Важнейшая вещь, которую надо понять сразу на берегу: грейд может плавать, но он никогда не обнуляется. Если РНР-программист дорос до «сеньора», а потом решил свичнуться в iOS-разработку — он не становится снова «джуном». Грейды они не про технологии вообще.
Конечно, у такого свитчера будет период адаптации в полгода-год, но если рекрутер пытается купить вас как джуна только потому что вы недавно сменили стек — он явно не понимает что делает.
Распределяющая шляпа в профиль. Очень хочется надеяться, что все же вялость миддла преодолима при наличии жизни вне айти и не в перекладывании жсонов
Here in Mexico every developer is Senior developer // навеяно фан фактом про Netflix
Внезапно осознал где на этой линии сейчас нахожусь я.
Минимально жизнеспособный персонаж. Знает базовые алгоритмы и может решить задачу, если кто-то расскажет ему как. Обычно выпускник универа или курсов по программированию.
Популярное наебалово, особенно в российских компаниях — брать джунов как стажеров. От чего многие думают, что позиция джуна зашкварная и надо сразу после школы идти в мидлы, а там через два года и тимлидом станешь. Отсюда столько поломанных судеб.
Это неправильно. Стажер не умеет и не знает, а джун — знает, но еще не умеет.
Иногда этап джуна действительно можно перепрыгнуть, если пилить пет-проджекты или фрилансить в студенчестве. Но щас таких всё меньше, все хотят быть сеньорами-подкастерами в 22.
Чем характеризуется? Джун знает, но пока не умеет. Что отличает его от интерна, которого надо учить с нуля, и от мидла, который уже умеет работать автономно.
Зачем нужен? Джунов хорошо брать на стабильных этапах, когда появляются рутинные некритические задачи, которые никто не хочет делать. Компания дешево закрывает рутину, джун набирается опыта на ошибках, а сеньоры их менторят и закрывают свои Performance Review. Профит и рост для всех.
Опыт до 2-3 лет, не более
Как собеседовать? Самое важное в джуне — «горящие глаза», желание учиться и умение копать базовые штуки для вашей области.
Потому на собеседованиях я обычно пряо ставлю простенькую задачку из той области, где ему придется работать: делаем веб — прошу заверстать формочку логина, ищу бекендера — сделай мне crud api с выборкой из своей любимой базы, девопса — расскажи как будешь делать централизованные логи.
Обычно тут я все-таки хочу видеть хоть какой-то код, потому что с джунами часто бывает проблема, что человек начитался хабра и очень круто стелит про фреймворки, но написать ничего не может.
Главное — чтобы по итогу собеседования было не гнетущее чувство «ух, его еще столькому придется научить», а скорее «он ничо, немного косячит, но если я накидаю ему задач — разберется».
Блин, кликнул в я - джун. я ж не джун :)
+1) неинтуитивно что это кнопка)
емае, я тоже кликнул. и ведь не отожмешь обратно)
Вот что отличает джунов - жмут на всё до того, как поймут что это
Про QA не забываем!
Какое прекрасное время... как детство
Самостоятельный юнит, который может решить любую поставленную техническую задачу. Способен задавать правильные вопросы и приносить работающие решения. Знает пицот языков и фреймворков, потому что всё еще считает программирование самым важным этапом разработки.
Чем характеризуется? В своей линейке я определяю мидла так — он может самостоятельно сделать всё, о чем его попросят. Мидлы — опора любой команды. Они еще не зазнались, но уже умеют.
Зачем нужен? Писать код (ничоси). Совсем хорошо работает под присмотром сеньора или лида. Ведь мидл хоть и самостоятелен, но не автономен. Он уже знает и уже умеет, но не знает куда грести. Когда ему не говорят что делать — он начинает заниматься всякой фигнёй типа замены либ на более модные.
Опыт 3-10 лет
Как собеседовать? Большая часть статей об айти-собеседованиях в интернете написана именно под мидлов. В том числе и мой краткий гайд о том, как нанимать нормальных людей.
Всё потому что мидл — это последний уровень, который можно собеседовать исключительно по хард-скиллам. Задачки вида «как бы ты написал вот такой микросервис», «какие бы структуры или базу данных взял бы для того-то», «а почему не другое» тестируют мидлов идеально.
Я даже не всегда прошу писать для этого код, если человек 5-10 лет в индустрии — скорее всего он уже умеет, а мелочи пофиксим на кодревью. Я устраиваю сессию по систем-дизайну, где мы вместе пытаемся построить какой-нибудь сервис или продукт как будто мы работаем в одной команде. Примеры всегда беру приближенные к реальным задачам команды. Полчаса плотного диалога обычно хватает чтобы прощупать все сильные и слабые стороны.
Для мидла-бекендера это выглядит как-то так (пример сильно упрощен и отображает лишь формат, а не реальную постановку задачи):
— У нас есть 10 микросервисов, нам надо авторизовать запросы на них. Как будем решать?
— Я бы взял JWT.
— Хорошая идея, а как будем обрабатывать логауты, ведь JWT не хранит состояние?
— Сделаем короткие токены как в OAuth и при логауте будем на сутки класть их в блек-лист
— Прикольно, а на чем запилим блек-лист?
— Нужен какой-то быстрый кеш, я бы взял Redis
— Охуенно, а как будешь масштабировать когда перестанем влезать в память? ...
Суть ясна. Разговор получается очень комфортным для обеих сторон потому что я не навязываю ни подход, ни выбор технологий, я лишь реагирую на предложения кандидата и задаю уточняющие вопросы чтобы понять глубину его знаний.
Цель собеседования на мидла — понять, что чувак может без выебонов решить любую задачу, которую вы ему ставите, даже если ему придется для этого общаться с другими людьми или учиться чему-то новому.
Промежуточный уровень между мидлом и сеньором.
Сидеть пять-семь лет в мидлах тяжело. Разработчик уже вырос, а его грейд нет. Обидно. Потому я обычно дополнительно делю мидлов на вялых и сильных, но вы можете делить по-американски на low и high.
Чем характеризуется? Сильный мидл — это почти сеньор. Он уже автономен, но ему не хватает софт-скиллов, либо наоборот. Для такого уровня нет названия и специализированных задач, но ценить таких чуваков надо. Ну и платить соответственно. Отдельный уровень по сути для этого и нужен.
Зачем нужен? Когда компания вырастет — он станет вашим новым сеньором и вам не придётся искать их с нуля. Что обычно дорого и отнимает минимум полгода на обучение и интеграцию.
Я бы вообще ввёл High-Middle Developer в стандарт, а то какое резюме ни откроешь — одни сеньоры вокруг.
Хотя в 23 я тоже был сеньором. В 30 стал называть себя просто инженером.
Ну и что получается в итоге )) у меня ок с софт скилами, я под присмотром синьора, но в целом автономен, пилю довольно важные задачки, но тк мой опыт работы 2 года и я начал прям со стажерства, поэтому я не могу решить любую задачу без выеьонов, скорее я могу разобраться в любой задаче без выебонов) кто я в этой пучине))? Похоже, просто долбаеб)
Наверное, это тот момент, когда ощущаешь себя мидлом, но проходишь собесы на позиция сеньора с минимально-сеньорской зарплатой
я стал называть себя инженером когда получил документ подтверждающий это. коробит от программиста, разработчика. Ты специалист или только буковки клацать
Автономный персонаж с опытом, личной экспертизой и софт-скиллами. Побывал во многих компаниях и лично пожил на разных стадиях эволюций. Программирование для него давно уже не искусство, а скорее сборка конструктора из известных блоков.
В глубине душие сеньора уже заебало все это айти, но он спокоен, прокачал софт-скиллы и понимание того, что многие задачи можно решать вообще без кода.
К сожалению, в славянских галерах есть проблема. Мы тут не одиноки и такая же проблема есть во всех бедных странах, где цветет айти-аутсорс. Лычка «сеньора» в них превратилась в вознаграждение — её дают каждому второму гребцу просто чтобы потешить его ЧСВ.
«Это важный для нас заказчик, вот закончишь проект — официально дадим тебе сеньора», — каждый раз смеюсь когда слышу. От того и полный рынок 23-летних сеньоров. К сожалению, так это не работает.
К счастью, такие «сеньоры» вычисляются и отсеиваются сразу на ранних этапах.
Сеньор — это уже не столько про умение программировать, сколько степень зрелости человека как инженера. А мы все знаем, что почему-то зрелость приходит не по моточасам, проведенным за компьютером, и не с количеством проектов, а с годами. Да и то не всегда.
Мудрость приходит к старости, но сама старость нисколько не означает мудрость. То же самое и с сеньорами.
Чем характеризуется? Джун знает, миддл умеет, а сеньор имеет опыт. Он больше фокусируется на тактике и вопросах «зачем мы это делаем», а не «какой бы нам фреймворк взять». Ему насрать на код. Сочетает софт и хард скиллы в равных долях.
Зачем нужен? Чтобы делать хорошо сразу, а не как обычно. Ну и следить за тем, чтобы остальные делали хорошо.
Фишка в том, что не всем нужны сеньоры. Большинство задач в современном айти не требуют опыта вообще. Мидлы получаются выгоднее.
Опыт 10+ лет, меньше я пока не встречал
Как собеседовать? Вот здесь обычно у всех сложности. Сеньору нафиг не упали ваши деревья и алгоритмы на бумажках. Он мыслит крупными блоками. Рекрутеры же лишь видят, что он не сыпет определениями как второкурсник, от чего отбрасывают хороших кандидатов. Оценить опыт всегда сложнее, чем знания.
Хотя здесь всё равно продолжает неплохо работать мой подход с диалогами о систем-дизайне, как я делал для мидлов. Просто если с мидлами это было делать легко — с высоты своего опыта ты сразу видишь недостатки, то с сеньорами будьте готовы, что их опыт может победить ваш. В таких случаях я предлагаю кандидату самому назвать мне плюсы и минусы, которые он видит в собственном. Красиво перекладываю свою работу! :D
Другие хорошие вопросы для сеньора:
593 Я сеньор и мне даже нет 25! 1444 Я — сеньор постарше
Наконец-то кто-то написал правильную градацию по опыту, а не классические "3 года синьор" по Даннинг-Крюгеру. Спасибо!
«Твоя любимая база данных» – все ненавижу
Количество проектов - это опыт. Почему зрелость не приходит с количеством проектов? Если целенаправленно поиском нового опыта (не только в айти, а по жизни вообще) не заниматься, с "годами" ничего не изменится.
Если 10 лет пилить интернет магазины, тоже синьором не станешь) Количество проектов - это необходимое, но не достаточное требование.
"предлагаю кандидату самому назвать мне плюсы и минусы, которые он видит в собственном ...". Тут слово пропущено. "Резюме" ?
Техлид, тимлид, сквад-лид, трайб-лид, чаптер-лид, и.т.д.
Сеньор, который уже полностью абстрагировался от написания кода, хотя и может, если надо. Просто с определенного момента любой компании становится выгоднее, чтобы человек не сам свои буковки программировал, а говорил остальным куда программировать.
Техлидов иногда называют инжиниринг-менеджерами, но это только всех запутывает. Техлиды — продолжение именно инженерной вертикали. Они решают те же инженерные задачи, просто на более высоком уровне.
Зачем нужен? Разгребать препятствия на пути команды. Определять направление. Решать вопросики. Нанимать и увольнять. Отчитываться. Разгребать вообще всё говно в компании за тех и за других. Чтобы понимать весь спектр навыков, рекомендую глянуть Роадмап Тимлида.
Как собеседовать? Исключительно по софт-скиллам и культурной совместимости как это делает Google на culture fit интервью. Навыки программирования здесь важны лишь на уровне знания как проводить код-ревью и пайплайны сборки-тестирования-деплоя.
Самое важное — чтобы лида приняла команда. Найм лида «втихаря» — популярная, но абсолютно отвратительная практика. Хороший лид должен и сам это понимать.
Хорошие вопросы для лида:
Важно, чтобы команда тоже слышала ответы, потому что часто они могут понравиться вышестоящему менеджеру, но не понравиться команде. Такие истории на моём опыте заканчивались плохо.
А что делать-то, если два чувака из вашей команды подрались из-за нового фреймворка?
Тут как с system design interview, нет правильных ответов
Вот, да. Ждем свой ответ. Голосую за вариант "авторитарно выбрать третий фреймворк", чтобы никому не обидно было
Драчунов за фреймворк на мороз обоих ;)
Вот, да. Ждем свой ответ. Голосую за вариант "авторитарно выбрать третий фреймворк", чтобы никому не обидно было
Или заставить каждого написать на доске плюсы своего инструмента и минусы инструмента оппонента
Konstantin, добить слабого
Например, понять, кто из них останется в команде, а кто - свалит через пол-года.
Выслушать доводы, взять паузу на дополнительное изучение темы и общение с колегами если нужно, привлечь свой технический опыт и дипломатию, продать обоим один из этих фреймворком или третий фреймворк или вообще иной путь.
А вообще, ты должен был сам заранее выбрать фреймворк и другие части архитектуры, тут твой проёб
Ещё если времени много можно подключиться в спор модератором и постараться быстро конструктивно его завершить
По драке - всё просто, ничего ни делать, они такое сами должны решить.
Только я попросил бы написать минусы своего фреймворка и плюсы оппонента. Но суть может быть совсем в другом: одному нагрубили в общественном транспорте, а у второго закончилось молоко в кофе машине. Такой себе психотерапевт на полставки
Возможно ли такое, что по техническом опыту человек - сильный мидл, а по софт скилам и другим задачам вполне успешно справляется с задачами лида? Хотелось бы услышать разные мнения
Дальше в любой компании идёт длинный хвост лидов-над-лидами и техно-менеджеров.
Однако, никогда не стоит путать лидов с менеджерами. Лидеров уважают за их экспертизу и опыт, а менеджеров просто ставят двигать тикеты в жире и проводить 1:1. Менеджером может быть хоть выпускник универа.
Я однажды работал в компании под управлением джуна-менеджера, которого мне приходилось учить как нами управлять. Весьма популярная практика в американских компаниях. Было тяжело.
В зависимости от размера компании, этой прослойки может вообще не существовать, а может и доходить до 3-5 слоев в каком-нибудь Амазоне.
Если лид еще может иногда пописывать код, то у принципал инженера на это просто нет времени. Да и платят ему уже давно не за код.
Ведь написание кода — самое простое и приятное, что есть в разработке вообще
Дальнейший рост привязан исключительно к иерархии внутри компании, потому его по сути и нет. С принципал позиций уже либо хантятся в СТО, либо уходят делать свой бизнес.
HR'ам приходится придумывать специальные грейды и бенефиты, чтобы хоть как-то удерживать этих ребят. Так появляются всякие «сеньор эксепшенал инженеры» и «феллоу оф компани». Это даёт возможность:
✅ Держать ключевых чуваков с помощью больших опционов, зарплат и высокоуровневых тасков. Когда знаешь, что купишь квартирку на опцион через годик — это весьма мотивирует терпеть всё происходящее :)
✅ Создавать у простых кодеров мнимое ощущение, что им надо активно расти. Часто компании прописывают выгодные для себя условия повышений, типа, «должен активно участвовать в гильдиях, писать технические посты в корпоративный блог и организовывать митапы». Повышение за это, конечно же, сразу не дают, только когда место освободится. Зато компания получает дополнительные рычаги влияния, мотивации, ну и бесплатный пиарчик.
✅ Смешной третий вариант, который пока в TODO потому что все ушли на йогу.
Не хватило кнопки "Я-принципал", ну да ладно, пойду впишусь в лиды, раз сюда нельзя.
Добавил!
Можно во все сразу записаться !)
Ну и где добавил-то?) не вижу такой кнопки)
Я сейчас в подобной позиции и меня постоянно держит чувство, что я ничего полезного не делаю (потому что очень мало пишу код. Очень. Мало.).
Популярный конфликт на собеседованиях:
Компания хочет оценить программиста. Иногда интервьюеру кажется, что просмотр кода может в этом помочь. Окей. Я лишь один раз в жизни видел чтобы кого-то увольняли за плохой код, но иногда и сам прошу джунов или мидлов показать мастерство.
Например, когда на проекте уже есть парочка говнокодеров, я скорее найму человека с легким и читаемым стилем, чтобы он пинал всех на код-ревью, чем потом буду разгребать хитровыебанные алгоритмы от всех троих.
Кандидат хочет побыстрее найти работу. Он подал резюме уже в десятки компаний. Восемь из них попросили выполнить тестовое задание, которое «займет буквально один ваш вечер», от чего он праведно негодует — это где столько вечеров раздают-то!
Гитхаба и пет-проджектов у человека нет — теперь это легально. Весь свой код он пишет на работе, а дома отдыхает, как и положено. Происходит классический конфликт, который можно решить только признав его и договорившись.
Подход, который я увидел в паре немецких компаний и теперь топлю сам:
Покажи мне любой свой код на гитхабе. Если его нет — держи тестовое задание, напиши его красиво и выложи потом на гитхаб, чтобы показывать на интервью в других местах
Всё просто и честно. Интервьюеры могут посмотреть свежий-сочний код, а кандидату не надо тратить свои вечера на каждое задание, можно написать код один раз и носить с собой.
К сожалению, сейчас лишь единицы из опрошенных мной компаний разрешают это. Каждый может помочь это изменить.
Если вы компания — разрешите выкладывать ваше тестовое задание на гитхаб и принимать имеющиеся. Напишите об этом открыто в своей вакансии. Можете твитнуть об этом с мешненом @vas3k и я ретвитну вашу вакансию (если остальное описание тоже будет честным и без булщита).
Если вы ищете работу — перед каждым тестовым требуйте разрешения выложить его на гитхаб чтобы показывать другим и рассказывайте компаниям почему это будет честнее и выгоднее для всех.
Так победим.
Тут возникает новая проблема - кандидаты могут смотреть решения друг друга. Что может слегка снизить эффективность решения одной из основных задач тестовых - отсекания говнокодеров.
h1k3r, вот это хороший аргумент, кстати. В теории я могу представить себе такое идеальное преступление, но на практике же этот подлог раскрывается так же просто, как любое вранье в резюме — после пары вопросов «а тут зачем так сделал» будет сразу видно, что человек не понимает о чем говорит. Риск не оправдывает себя.
А если же кандидат нашел гитхабы людей до него, спиздил их решения, сам во всем разобрался, сумел замести все улики и предоставить хороший код — такого героя можно сразу тимлидом брать :D
Если же компания большая и хантит реально много (50+ человек в месяц), она может придумать 3-5-10 разных тестовых заданий для пущего спокойствия.
Вастрик, тоже верно. У меня видимо слегка замыленый взгляд на вещи. За последние 3 месяца проверил штук 30 тестовых. У нас задача на рефакторинг приложения из 150 строк, знания фреймворков и библиотек мы не видим смысла проверять. В этом случае просмотр других решений может дать много идей, ведь кандидаты в коммитах часто пишут какой недостаток кода пытаются иправить. Но если писать с ноля - твои вариант отличный.
Васю в президенты!
а мне кажется, для отсева говнокод кров надо давать код на ревью. Там сразу и будет понятно, как человеку нравится писать. Правда, там где давали, там сразу был какое-то адовый говнокод, который хотелось переписать. Лучше более менее сносный код, но с некоторыми косяками. Также это покажет, знает, не знает кандидат технологии, подхода к её использованию и так далее
Теперь самое интересное.
Классы определяют набор способностей, сильных и слабых мест каждого члена команды. Людей без слабых мест не бывает, потому в хорошей команде персонажи как бы прикрывают слабые места друг друга.
Классы важно знать чтобы:
Главное — не увлекаться. Тут как с новой бензопилой: лучше держать её в гараже, а не бежать на рождественскую ярмарку (хоть и хочется).
Модель может подходить, а может не подходить. Надо каждый раз смотреть по ситуации. Видал я наркоманов, которые так и до хьюман дизайна кукухой доезжали. Потому подам всё как бы иронично.
А что не так с Хьюман дизайном-то?
Lukke Armageddon, потому что он антинаучен
Охрененные карточки!
Я знаю системы, где работников разделяют на 48 классов типа «Увлечённый Мечтатель» или «Коварный Диктатор». Полная дичь. Если что-то невозможно запомнить — это тем более не получится применять в жизни.
Для себя я всё свёл к набору из четырёх базовых классов, из которых строятся остальные.
На собеседовании я всегда стараюсь определить кто передо мной
Каждый класс отлично определяется вопросами вида «как бы вы поступили, случись такая-то ситуация». Обычно я совмещаю их с техническими вопросами. Ситуации беру приближенные к реальности, конечно.
Персонаж может иметь больше одного класса, а может не иметь ни одного. В последнем случае, правда, будет тяжеловато всем.
Это по Адизесу?
по Бартлу скорее
"48 классов типа" это случайно не из Myers-Briggs Type Indicator (MBTI)? https://www.16personalities.com/free-personality-test
Какой-то сложный квадрант.
Как это так вышло что тут параллельные шкалы?
Тот, кто хуячит. Хуятор — основа любого общества. Как шахтёр или строитель. Он просто делает то, что нужно делать. Дали шахту — надо копать. Дали таску — надо пилить.
Увидев список тасков в жире он берёт верхний и начинает его делать. Потом берет следующий. Не всегда быстро, но таков путь. Хуяторы обычно самые говноустойчивые люди в команде и увольняются последними.
Неорганизованность хуятор считает распиздяйством.
На плохие новости всегда реагирует выводом, что все вокруг просто лентяи и недостаточно работали. Надо напрячься и работать усерднее. Хуятор не умеет не работать.
Когда нужен? Почти всегда, кроме реструктуризации (ниже нарисую картинку, там будет понятнее).
Зачем? Молча делать работу, которая определена. Хуятор может неделю писать юнит-тесты и даже не поехать кукухой.
Минусы Хуятор перманентно пребывает в одном из двух состояний — либо завален работой по уши, либо он выгорел и сидит в депрессии. Ему постоянно некогда.
Обычно хуяторы вырастают и обзаводятся дополнительными скиллами, но пару раз я видел хуятора, который дорос до менеджера. Страшно. В России так часто бывает. Быть подчинённым у хуятора чисто физически тяжело — избегайте.
Как договариваться Ставить чёткие таски. Любая неопределённость злит хуятора. Однако, проблема может возникнуть тогда, когда тасков вообще нет. Тут придётся импровизировать и выдумывать. Ну и постоянно напоминать, что это не спринт, это марафон.
А Scrum Master думал, что спринт..
Cooch, Пусть и дальше думает.
Бля, у меня такой руководитель был. Успевал еще хуячить кучу строк говнокода за который кичился, всех называл дураками.
Я хуятор и тимлид. ПАМАГИТЕ
похоже на нашего СЕО
Раскройте список хуяторов под кнопкой за деньги!
Хех, видимо у меня затяжная стадия депресии после 2 лет хуяторства
и правда было сложно не доставать ребят которые хотят работать с 9 до 5-ти и не ломать и их work-life balance в след за своим
в англ версии хуятор это doer. я аж немного рсстроился - открыл англ версию только чтобы посмотреть меткий перевод хуятора
Тот самый чувак, у которого в голове пятьдесят новых идей, каждую из которых надо сделать ASAP, ведь «эта фича точно выстрелит». Каждое утро он начинает с мысли, что пора переписать всё с нуля.
Постоянно всем рассказывает какой новый фреймворк увидел на гитхабе и какие сейчас тренды в айти. Люди его любят, как источник вдохновения, но иногда не верят в его сказки.
В английском для этого класса есть более точное название — Explorer, а в бизнес-книжках таких ещё называют Предпринимателями
Когда нужен? На запуске нового проекта, бурном росте или выходе из кризиса. Короче, всё, что не стабильность. Стабильность для него смерть. В крупных компаниях задерживается редко.
Зачем? Вдохновлять других, внедрять новые идеи, не давать продукту закостенеть в устаревших технологиях, которым уже целых два месяца. Никто так не пишет уже, вы что.
Минусы Экспериментатор обожает начинать, но редко доводит дело до конца в одиночку. У него всегда появляются «более перспективные идеи». Не умеет смотреть в перспективу и увольняется после первого же кризиса.
Как договариваться На любую новую идею экспериментатор говорит ДА-ДА-ДА-ЩА. Проблема в том, что он забывает об этом через три секунды. Работают стандартные методы контроля типа «создай таск» и «напиши как сделаешь».
Во втором абзаце потерялось согласование.)
Похоже список классов не является дизъюнктной совокупностью множеств (сорри у меня по дискретке тройка была, надеюсь кто-то понял), в смысле можно быть сразу в нескольких
мечтаю чтобы на все мои начинания находились продолжатели
Бюрократу совершенно насрать ЧТО делать, главное — КАК делать. Процессы превыше всего, а результат по его мнению придёт, если делать всё правильно и терпеть.
Он люто ненавидит, когда что-то не по порядку. Даже ручки на столе он раскладывает строго по размеру под монитором, который он протирает каждый понедельник.
Бюрократ не до конца понимает «экспериментаторов», которые по его мнению только все портят необдуманными нововведениями.
Ахиллесова пята бюрократа — карьерный рост и будущее в целом. Ему всегда важно видеть четкий план того, что будет через месяц, через год, через пятнадцать лет, иначе он начинает теряться и волноваться.
Зато если дать ему такой план (или что-то похожее) — он без вопросов пойдет действовать по нему, прочитает 15 книжек и реорганизует все процессы как там написано.
Зачем нужен? Наводить порядок и налаживать процессы. Защищать продукт от необдуманных телодвижений. Документация, структуризация и разбор технического долга, который наговнокодили Хуяторы и Исследователи — вот основная задача бюрократа.
Когда? Когда этап стартапа пройден, рост стабилен, и риск просрать много денег становится неиллюзорен. Бюрократы помогают сохранить систему в целом, при этом испортив жизнь всем её частям по отдельности. Такой вот парадокс.
Минусы Абсолютная бюрократия — как тепловая смерть вселенной. Она эффективна как машина с катающимися шариками с YouTube — шарики завораживающе скатываются по сложным поверхностям, но смысла в этом движении нет никакого. Теперь всё — процесс.
Несмотря на очевидные минусы, бюрократы бывают полезны. Подумайте кому бы вы доверили заполнять свою налоговую декларацию — въедчивому Бюрократу или креативному Исследователю, который и пять минут на месте усидеть не может. То-то же.
Как договариваться Стандартный ответ бюрократа на любой вопрос — НЕТ. Просто выдыхайте и продолжайте предъявлять аргументы (возможно даже одни и те же). Бейте в то, как это улучшит организацию и процессы, пока не услышите ДА. Так работает.
После этого «да» можно быть на 146% уверенным, что всё будет сделано как надо. Бюрократа не надо проверять, это его обижает.
Так исследователь или экспериментатор?
Очень люблю документацию, когда есть чёткий процесс, но не говорю Нет. С удовольствием открыт новым штукам. Теперь буду бояться рассказывать как я люблю документацию, налаживать процессы, а то вдруг подумают, что я бюрократ.
Бля… после устройства на работу я не сел писать код, а разгрёб место, файлы и железо предшественника, перенёс наработки в git, составил хронику разработки, расспросил народ, кто за что ответственнен — и попутно записывал всё себе в файлик.
Походу, меня раскрыли
Помните того весельчака, который пишет весьма средненький код, но имеет друзей во всех командах, постоянно всем отвечает в слаке, завел канал с мемами и постоянно ходит по митапам и конференциям? Вот это типичный интегратор.
Зачем нужен? Налаживать связи между людьми. Поддерживать постоянный обмен информацией. Бегать «решать вопросики» с людьми из разных команд. Ну и просто для атмосферы.
Даже если он не копает яму вместе со всеми, он всё равно полезен команде, ведь благодаря ему остальные копают гораздо лучше.
Когда нужен? В моменты реструктуризации и кризиса интеграторы выходят на первый план. Они объединяют оставшихся и интегрируют новеньких. А вот в стартапе интегратору скучно, потому что людей не так много, а значит и возможностей.
Минусы Интегратор постоянно со всеми соглашается и ищет взвешенную позицию, как в посте Оставайся Посередине. Это хорошо на переговорах, но так же означает, что на проекте от него не стоит ожидать новых прорывных идей.
Он не нападающий, он скорее защитник, как и бюрократ. Только связывает людей не процессами, а отношениями.
Как договариваться Чтобы переманить интегратора на свою сторону, надо договариваться не с ним, а со всеми его окружающими. Он двигается относительно них.
это шо DISC и Адизес в одном наборе?
"А вот стартапе интегратору скучно" - пропустил в
Я чувствую себя каким-то дивергентом, что я принадлежу сразу ко всем группам, но некоторые выпадают в зависимости от ситуации.
Можно ли отнести фасилитацию к скиллу этого класса?
Кажется классы всё ж не оч, из интегратора мне кажется многое ко мне тоже подходит не только хорошее а не плохое ахах =) не понятно что мешает интегрируя приносить прорывные идеи. Ну или как минимум ставить услышанное что-то на флаг и координировать и делать реальностью. Вообще общаться со всеми, распространять информацию и идеи, огранизовывать разное в зрелом стартапе было оч интересно. Даже больше чем кодить порой.
А ладно вижу дальше, классы это базис, из которого набирается каждый перс по уровням каждого класса (абилки)
Похоже, я интерхуятор. С редкими приступами экспериментирования.
Перечисленные выше классы не случайно названы базовыми. Чистого Бюрократа или Хуятора можно встретить разве что среди джунов-студентов ну или в крайне редких случаях изоляции в крупных компаниях. Персонажи базовых классов не способны выживать в одиночку, а вот их сочетания уже да.
Поэтому:
Любой специалист выше мидла сочетает в себе минимум два класса
Наша цель уметь их правильно определять и подстраиваться.
Приведу для примера самые популярные вокруг меня, остальные сами додумаете.
Узнал в себе ниХуятора. Надеюсь, просто выгорание, а не жизненная черта
Хуятор, который сам генерит идеи и сразу их делает, чтобы завтра же выбросить и сделать новую. Идеальный нападающий. Он решает проблемы быстрее, чем остальные успевают их вообще понять.
Главный минус Стартапера — он не умеет жить в стабильности, а бюрократы вызывают у него физическую боль.
Не увидел сочетания ХуяторИнтегратор. Делает сам, и заставляет делать свою работу всех в округе?
Хорошо знакомое мне сочетание потому что, ну, я сам такой. Сейчас стараюсь качать скилл Интегратора, ведь он был бы очень полезен в дальнейшем, но пока как-то в основном получается Бюрократ.
Ну а вообще всё это херня, конечно, она может как отлично работать для меня, так и нихуя не подходить больше никому в мире. Ошибка выжившего. Потому я пишу этот пост вообще не понимая кому это надо. Но вы за это платите доллар, так что это и ваша вина тоже.
Следующий пост будет про чонить модненькое и смешное типа No Code, а то всё какие-то глубокие темы пошли, которые никто младше тридцати всё равно не понимает, и думает это всё фигня, которую диды придумали лишь бы не работать.
Узнал своих коллег, хорошая классификация:)
Мне меньше 30ти, но я искренне пускаю слезу
За такие посты я и подписался, хоть и мне всего 20. Спасибо за пост, понимаю что мне не хватает Хуятора должном количестве, потому что джун-Архитектор - ну такое)
ничо не фигня, дидам нравится)
Я плачу свои доллары (!) как раз за такие посты! Пиши их ещё
NoCode - огонь! Случайно заглянул в их мирок, был удивлён наполеоновским планам.
С нетерпением ждал продолжения и расшифровки классификации из "Войти в айти" потому что нахожусь на стадии самоопределения. Пост супер! Спасибо!
Отличный пост. Пиши ещё. Всяких разных, чтоб разнообразие было и тебе самому интересно.
Ничего, к 45 должно стать ясно, кто еще выжил, и кому нужны такие посты. Пока терпим, затягиваем пояса, скидываемся по доллару.
ну так на то нам и 30, чтобы понимать)
диды вечно чонить придумают лишь бы не работать, всегда удивляло в дидах, подрос и перестало удивлять лолд)
Антипод Стартапера. Идеальный защитник. Персонаж, который обожает залезать в каждую щель и наводить там «чистоту».
Часто обитает в службах безопасности (ИБ). Там, где не надо ничего производить, но нужно всеми силами охранять. Опричник следит чтобы ни один байт не прошел по незащищённому соединению, а когда обнаруживает дыру — сам находит и казнит виновного. В этом его кайф.
Сочетает в себе любовь к экспериментам и структурный подход бюрократа. Каждую идею он записывает, анализирует и наносит на схему. Дай архитектору большую исследовательскую задачу — он закроется в комнате на неделю и вынесет оттуда чёткий план действий или архитектуры проекта.
Делать он его не будет, конечно, он же не Хуятор. Хотя может прокачать этот скилл.
О да, на схему структурированного беклога в мой гигантский ноушен
С одной стороны можно слишком на большой срок напланировать, а с другой, так идеи и важные мысли которые постепенно приходят собираются вместе, не теряются и когда до них доходит дело, получается уже почти готовый тикет со ссылками на статьи в интернетах которые за это время вышли и своими размышлениями
ооо да, это я
Решает проблемы. Прямо обожает это говно. Только решая чужие проблемы он чувствует себя удовлетворённым. Траблшутер готов фиксить упавший прод даже ночью. Этим он похож на Стартапера, но в отличии от него, может дольше жить в стабильности крупной компании. Как бы точа топор и выжидая.
О, привет!
У нас в Компании есть такой один. Свет в оконце, реально. Я давно выгорел и забил, а он тащит и типу походу в кайф
Наконец-то нашёл себя!
Да вот четко про "решая чужие проблемы". Я формулировал себе это так: мои клиенты это не кастомеры продукта, а менеджеры и разработчики вокруг меня, облегчая жизнь им, я чувствую себя лучше.
Последняя важная деталь для понимания классов. Один класс — простой крестьянин. Два класса — автономный боевой юнит. Но есть персонажи, которые ведут всех на бой. Их уважают и за ними следуют. Таких называют заезженным словом «лидеры», но в нашей схеме у них очень просто определение:
Лидер — тот, кто сочетает не два, а сразу три базовых класса
👩🔬 + 🏃♂️ + 🤝
👨💼 + 🤝 + 🏃♂️
...
Любых. В разных пропорциях. Иногда даже сам того не подозревая.
Не стоит путать лидеров с лидами и менеджерами. Лид — это звание. Его можно получить за выслугу лет. Менеджер — это вертикаль, как разработчик, в менеджеры хоть после школы можно идти. Лидер — это именно персонаж. Как «лидер мнений».
Раскрывать тут тему лидерства я не буду, пост и так уже слишком большой. Просто оставлю вам пару книжек для изучения.
Смахивает на модели Белбина, но попроще.
может крайне глупый вопрос, но я не понял, почему "в менеджеры хоть после школы можно идти"? т.е. вот то, что я сейчас книжки всякие читаю, курсы по руководству проектами, это все, так сказать, не в кассу?
Pavel, имелось в виду, что чтобы стать просто менеджером, не нужно перед этим становиться кем-то еще. А книжки читать нужно, да.
Это какая-то британская система получается. "Джентельмен может управлять чем угодно по праву рождения, при условии соответствующего воспитания".
На практике, в нашем всратом АйТи, менеджер без инженерного опыта = говноменеджер/эффективный менеджер/сова-из-мема менеджер.
Всё рассказанное выше — лишь моя интерпретация. Она может быть искажена моим кругом общения или областью, где я кручусь. Не будьте глупыми и не воспринимайте её как руководство к действию.
Чтобы вы могли строить свои теории, я порекомендую вам книжки, на которых я отчасти построил эти. Когда-то их мне рекомендовали мои же начальники. Ссылок не даю, потому что опять скажут реклама.
Отсюда взята система этапов эволюции компании. Там она названа модным словом STARS, потому что американские коучи обожают мотивационные аббревиатуры про космос. Несмотря на это, книжка хорошо рассказывает как выживать на каждом из этапов.
Где-то здесь лежат корни классов персонажей. Только там они названы Producer, Entrepreneur, Administrator и Integrator, что образует аббревиатуру модели PAEI. Самый её сок — там рассказано как общаться представителям одного класса с представителями другого, чтобы не загрызть друг друга.
Книга чисто для менеджеров, но, стоит почитать всем, кто хоть раз общался с живыми людьми по работе. Ну то есть да, рекомендую абсолютно всем.
Подобных моделей еще существует много. Из понравившихся еще помню DISC и набор персоналий по Myers & Briggs, так что мне сложно судить какая повлияла больше. По факту, всё это было придумано еще в прошлом тысячелетии, а если пытаться копнуть глубже, оттуда на тебя вообще смотрит Карл Юнг.
Но не стоит. Помните про бензопилу на рождественской ярмарке.
Ещё в Team Fortress 2 был действительно неплохой набор персонажей. Без шуток. Ну а карточные игры типа MTG и DnD очень помогают развивать подобное мышление.
А то мне вот всё детство говорили, что игры — зло, вот я и вырос таким неприспособленным.
Спасибо! Вастрик гений :)
Team Fortress 2 топ. Сбалансированная команда адекватных игроков рулит и катком проходится по карте. Иногда, конечно, не хватает универальной эмки/калаша.
Ну вот и начался список рекомендуемых книг от автора :)
Никита @tonsky ещё похожую карту делал и тоже рассказывал как им между собою общаться. Где-то на ютюбе лежит. UPD: "Обретение навыков" https://www.youtube.com/watch?v=ZKB0oaeF3_Q
Рекомендую все три книги Максима Батырева «45 татуировок продавана/менеджера/личности». Написаны очень легко и понятным языком
кайфанул
статья огонь! не перестаю тебе удивляться! все четко и по делу.
Приплел даже игрофикацию процесса - круто.
В качестве логичного продолжения статьи и общего тренда предлагаю рассмотреть процесс построения сообществ в компаниях. Ты это классное делаешь про себя - клуб, патрон и т.д. Возможно пора расширять инструментарий ибо корпоративная культура очень сильный инструмент для взаимодействия.
и да - доллар не зря )))
Теперь отношения к коду не имею ))) но довелось побывать в давай деплой деплой методолоджи )
Статья шикарная ) 🔔 буду выглядывать в соседних разработчиках эти перки
Только к середине текста понял что мне продают Адизеса за доллор(
Было очень интересно читать, спасибо!
Мне очень понравился поворот на «лидера»
Хоть я и пездюк, но мне тоже интересно. Люблю послушать рассказы дидов о местоположении граблей, чтобы потом со знанием дела по ним попрыгать.
Охеренная статья, блаходарочка) Пойду обратно интегрировать, но уже навеселе
Пойду давать ссылку что ли, если пост общедоступный. Прям нормас.
Хорошая статья! Только теперь осталось в людях также хорошо разбираться...
Офигенно!
Я не из ойти, но система рабочая и для других областей
@vas3k, пост классный, спасибище.
24-х летние маркетологи одобряют 👍
Сильно помогает когда уже сам начинаешь работать на проектах с другими людьми и помечать такие вещи.
"Хуятор может неделю писать юнит-тесты и даже не поехать кукухой" - прекрасно!
спасибо
Заебумба. Респект таким парням.
Просто великолепно!
Круто! Нарисуй потом графичек по составу твоей аудитории плиз.
Прикольно, когда ты доезжаешь что походу лидер.
Хреново что ты уже успел некисло выгореть.
p.s. Вастрик, спасибо!
p.p.s. Надо бы по работать, но я пошёл медитировать.
Характеристики классов прям четко напомнили "Принципы работы" Далио, он у себя каждому работнику карточку бейсбольную с основными характеристиками выдумывал.
Интересное мнение. Как мне кажется, факторов влияющих на людей на работе гораздо больше, чем быстро/взвешенно и исследование/следование плану. И как следствие сочетаний. Да и важность гладкого командного взаимодействия и общения далеко не для всех проектов важна и ценна, тут все зависит. По поводу лидерства – я вообще не очень понимаю что это такое. Скорее быть уважаемым и иметь последователей и ввести кого-то – это что-то ортогональное и может быть совершенно у разных людей, даже если они и не обладают тремя классами. Хотя я ещё не видел людей, за которыми мне бы хотелось следовать. Но интересный пост. Спасибо.
Адизес молодец!
Вастрик - это новый Стив Жопс!
Настолько круто, что стыдно делиться ссылкой!
Я разрыдался на упоминании Team Fortress 2 при планировании команды ибо как сам допёр до этой идеи своей головой года 4 назад.
В остальном я поражаюсь что при наличии всех необходимых знаний, IRL (особенно на просторах СНГ) команды строят мутные личности и делают это, пардон, жопой об косяк. Отбор устроен по методу тыка и без чётко определённых целей, без понимания кто и для каких задач нужен. Кругом карго-культ собеседований гугла, методики ряда "чингачгук смотри опытным глазом", HR-директора, знающие своё дело на вес золота. Брр. Удивляюсь как индустрия ещё дышит.
Я у мамы Опричник, хехе. И я правда дохуя лет в этом вашем ИБ.
Ещё один доллар по делу, ладна!
На самом деле, больно не от менеджера-хуятора, а от любого руководителя, который диаметрален тебе.
Только если твой менеджер не набрал черты всех и уже забыл как писать код.
Отличная статья, спасибо!
Ребят, а как сохранить в pdf, epub статью-лонгрид? Не нашел кнопки.
Перечитываю раз третий, примеряю, кайфую
#збс
как сказал бы Юрий.
хоть любые классификации - это всего лишь классификации, но знать их стоит.
моё уважение!
See also https://www.youtube.com/watch?v=ZKB0oaeF3_Q by @tonsky
не получилось бы?