Айти — командная игра. Одиночки в ней давно неконкурентны.

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

Слово «команда» в айти все еще считается баззвордом из HR'ского паверпоинта, а быть «менеджером» — зашкварно, из-за каких-то старых душных баек про «был хороший программист, а стал плохой менеджер».

Да вы не волнуйтесь так, мы и как программисты так-то были не очень!

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

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

Как обычно, всё написанное — компиляция моего субъективного опыта за 13+ лет в индустрии, который я получил в основном общаясь с другими, более умными людьми. За что им спасибо. Думаю, они себя узнают здесь.

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

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

👨‍👨‍👦‍👦 Собирать из них крутую команду. На разных уровнях нужны разные юниты. Надо трезво понимать каких персонажей вам не хватает, а каких в избытке. Какие сработаются, а какие нет. Какие скоро уйдут, обвинив компанию в предательстве, и кого надо нанять на их место (или пора бы уже валить самому).

🤦‍♂️ Наводить отношения с разными по духу людьми. Понять как общаться с тем чуваком, который уже месяц не может добавить тебе поле в API, постоянно требуя согласовать его с менеджером, СЕО, уборщицей.

👵 Знать, что делать в айти когда ты дед.

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

Сегодняшняя моя теория будет строиться вокруг трёх показателей:

1️⃣ Этап эволюции проекта

2️⃣ Уровни персонажей

3️⃣ Классы персонажей

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

Разберём их подробно.

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

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

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

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

Новый цикл эволюции проекта — как новая карта в RPG. Резко меняется количество ресурсов, типы юнитов, их мотивация и цели всего похода

Понимать это головой сложно, потому что эволюция идёт медленно и не заметна глазу. Но нужно.

Ниже я положу картинку где на этой карте находятся популярные айти-компании, на мой взгляд.

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

Мотивация: ⭐️⭐️⭐️
Команда: ⭐️⭐️⭐️
Ресурсы: 💩💩💩
Стабильность: 💩💩💩

Клетка «старт». Запускаем проект с нуля любыми доступными ресурсами.

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

Главное преимущество стартапа — его скорость и, да-да, маленькость. Не мне вам объяснять, что если стартап целится в «новый Facebook» — это сразу провал.

Хороший стартап понимает, что завтра может сдохнуть (и в 99.999% так и будет). Самое плохое, что можно тут сделать — начать думать на долгий срок — строить процессы, писать документацию, размышлять о миллионах, и.т.д. Потому тут нужны люди, понимающие и одобряющие такой «распиздяйский» подход.

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

Фокус Больше делаем, меньше думаем.

Мотивация: ⭐️⭐️💩
Команда: ⭐️⭐️💩
Ресурсы: ⭐️💩💩
Стабильность: ⭐️⭐️💩

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

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

Цель Выйти на стабильную высоту. А потом повторить.

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

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

Фокус Делаем и думаем пополам.

Мотивация: ⭐️⭐💩
Команда: ⭐️💩💩
Ресурсы: ⭐️⭐️⭐️
Стабильность: ⭐️⭐️⭐️

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

Стабильность. Никто не хочет ничего менять.

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

Цель Отдохнуть. Никто ничего сделать всё равно не успеет.

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

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

Фокус Ничего не делаем и не меняем, сидим думоем строим бюрократию.

Мотивация: 💩💩💩
Команда: ⭐️💩💩
Ресурсы: ⭐️⭐️💩
Стабильность: ⭐️⭐️💩

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

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

Команда Демотивирована. Последний «старожил» вчера ушел работать в FAANG. Все вокруг токсят и скроллят линкедин. Даже цитаты про «успех всегда даётся нелегко», развешанные HR'ами по офису уже как-то не помогают. СТРАННО.

Фокус Вроде как что-то делаем, но пока в основном думаем и объясняем бюрократам необходимость перемен. Они не верят.

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

Мотивация: ⭐️⭐️💩
Команда: 💩💩💩 (обычно приходится менять)
Ресурсы: ⭐️💩💩
Стабильность: ⭐️💩💩

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

Кризис как зима для коммунальных служб — всегда внезапен.

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

Цель Спасти корабль любыми способами, даже если это означает полный разворот.

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

Фокус Много делаем, пофиг что менять, главное — выжить.

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

А может и нет.

Каждая айти-компания сегодня придумывает свои уровни градации разработчиков. У Яндекса их восемь, у Microsoft тринадцать, а у Netflix вообще один — там каждый по-умолчанию Senior Engineer потому что Fuck The Police, видимо.

За сравнением, как обычно, отправляю всех на levels.fyi.

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

Для внешней же оценки эти уровни мало годятся. В разных компаниях они несовместимы, а единой шкалы так никто и не придумал.

Штош.

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

Важнейшая вещь, которую надо понять сразу на берегу: грейд может плавать, но он никогда не обнуляется. Если РНР-программист дорос до «сеньора», а потом решил свичнуться в iOS-разработку — он не становится снова «джуном». Грейды они не про технологии вообще.

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

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

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

Это неправильно. Стажер не умеет и не знает, а джун — знает, но еще не умеет.

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

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

Зачем нужен? Джунов хорошо брать на стабильных этапах, когда появляются рутинные некритические задачи, которые никто не хочет делать. Компания дешево закрывает рутину, джун набирается опыта на ошибках, а сеньоры их менторят и закрывают свои Performance Review. Профит и рост для всех.

Опыт до 2-3 лет, не более

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

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

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

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

2471 Я — джун

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

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

Зачем нужен? Писать код (ничоси). Совсем хорошо работает под присмотром сеньора или лида. Ведь мидл хоть и самостоятелен, но не автономен. Он уже знает и уже умеет, но не знает куда грести. Когда ему не говорят что делать — он начинает заниматься всякой фигнёй типа замены либ на более модные.

Опыт 3-10 лет

Как собеседовать? Большая часть статей об айти-собеседованиях в интернете написана именно под мидлов. В том числе и мой краткий гайд о том, как нанимать нормальных людей.

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

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

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

— У нас есть 10 микросервисов, нам надо авторизовать запросы на них. Как будем решать?
— Я бы взял JWT.
— Хорошая идея, а как будем обрабатывать логауты, ведь JWT не хранит состояние?
— Сделаем короткие токены как в OAuth и при логауте будем на сутки класть их в блек-лист
— Прикольно, а на чем запилим блек-лист?
— Нужен какой-то быстрый кеш, я бы взял Redis
— Охуенно, а как будешь масштабировать когда перестанем влезать в память? ...

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

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

1930 Я — мидл

Промежуточный уровень между мидлом и сеньором.

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

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

Зачем нужен? Когда компания вырастет — он станет вашим новым сеньором и вам не придётся искать их с нуля. Что обычно дорого и отнимает минимум полгода на обучение и интеграцию.

Я бы вообще ввёл High-Middle Developer в стандарт, а то какое резюме ни откроешь — одни сеньоры вокруг.

Хотя в 23 я тоже был сеньором. В 30 стал называть себя просто инженером.

1218 Я — сильный мидл

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

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

К сожалению, в славянских галерах есть проблема. Мы тут не одиноки и такая же проблема есть во всех бедных странах, где цветет айти-аутсорс. Лычка «сеньора» в них превратилась в вознаграждение — её дают каждому второму гребцу просто чтобы потешить его ЧСВ.

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

К счастью, такие «сеньоры» вычисляются и отсеиваются сразу на ранних этапах.

Сеньор — это уже не столько про умение программировать, сколько степень зрелости человека как инженера. А мы все знаем, что почему-то зрелость приходит не по моточасам, проведенным за компьютером, и не с количеством проектов, а с годами. Да и то не всегда.

Мудрость приходит к старости, но сама старость нисколько не означает мудрость. То же самое и с сеньорами.

Чем характеризуется? Джун знает, миддл умеет, а сеньор имеет опыт. Он больше фокусируется на тактике и вопросах «зачем мы это делаем», а не «какой бы нам фреймворк взять». Ему насрать на код. Сочетает софт и хард скиллы в равных долях.

Зачем нужен? Чтобы делать хорошо сразу, а не как обычно. Ну и следить за тем, чтобы остальные делали хорошо.

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

Опыт 10+ лет, меньше я пока не встречал

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

Хотя здесь всё равно продолжает неплохо работать мой подход с диалогами о систем-дизайне, как я делал для мидлов. Просто если с мидлами это было делать легко — с высоты своего опыта ты сразу видишь недостатки, то с сеньорами будьте готовы, что их опыт может победить ваш. В таких случаях я предлагаю кандидату самому назвать мне плюсы и минусы, которые он видит в собственном. Красиво перекладываю свою работу! :D

Другие хорошие вопросы для сеньора:

• «Тебе нужно построить вот такой вот абстрактный проект. Какие вопросы ты задашь продукт оунеру, что войдёт в MVP, как будем потом масштабировать и какие ресурсы тебе для этого пригодятся на следующие пару-тройку месяцев» — мой любимый вопрос, им одним можно покрыть большую часть тех-интервью. Проект чаще всего берется похожий на тот, что делает команда.
• «Как бы ты выбирал между Х и Y» или «Твоя любимая база данных» — вопросы на выявление фанбойства. К этому уровню его уже быть не должно. Только холодный расчёт.
• «Член твоей команды нафакапил — твои действия?» — немножечко реверанс в сторону софт-скиллов.
• «Зачем тебе вообще это всё программирование?» — красивый вопрос вне зависимости от грейда. Только если от джуна я здесь ожидаю «горящих глаз», то от сеньора уже скорее «потухших глаз» и тактической расчетливости. Может дать много косвенных намёков на мотивацию и опыт чувака.

601 Я сеньор и мне даже нет 25! 1454 Я — сеньор постарше

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

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

Зачем нужен? Разгребать препятствия на пути команды. Определять направление. Решать вопросики. Нанимать и увольнять. Отчитываться. Разгребать вообще всё говно в компании за тех и за других. Чтобы понимать весь спектр навыков, рекомендую глянуть Роадмап Тимлида.

Как собеседовать? Исключительно по софт-скиллам и культурной совместимости как это делает Google на culture fit интервью. Навыки программирования здесь важны лишь на уровне знания как проводить код-ревью и пайплайны сборки-тестирования-деплоя.

Самое важное — чтобы лида приняла команда. Найм лида «втихаря» — популярная, но абсолютно отвратительная практика. Хороший лид должен и сам это понимать.

Хорошие вопросы для лида:

• «Высокий миддл Олег подошел к вам и просит повышения до сеньора — ваши действия?». Ответ типа «мы вместе составим план карьерного роста, поставим задачи, будем проводить ревью» — сразу красный флаг. Чувак тупо мыслит по книжке. Ответ «сначала выясню почему он хочет сеньора — ради бабла, лычки или чего-то еще, и от этого уже будем плясать» уже лучше.
• «Два чувака из вашей команды подрались из-за нового фреймворка — что будем делать?» — проверяет азы конфликт-солвинга. Хороший лид назначит посредника, плохой бросится решать проблемы сам.
• «Как вы видите идеальную систему оценки продуктивности разработчиков в команде» — хороший лид знает, что ее не существует, и все строится исключительно на человеческих отношениях. Плохой начнет придумывать перфоманс ревью.

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

680 Я — лид

Дальше в любой компании идёт длинный хвост лидов-над-лидами и техно-менеджеров.

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

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

В зависимости от размера компании, этой прослойки может вообще не существовать, а может и доходить до 3-5 слоев в каком-нибудь Амазоне.

Если лид еще может иногда пописывать код, то у принципал инженера на это просто нет времени. Да и платят ему уже давно не за код.

Ведь написание кода — самое простое и приятное, что есть в разработке вообще

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

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

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

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

✅ Смешной третий вариант, который пока в TODO потому что все ушли на йогу.

389 Жиза, я сейчас тут!

Популярный конфликт на собеседованиях:

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

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

Кандидат хочет побыстрее найти работу. Он подал резюме уже в десятки компаний. Восемь из них попросили выполнить тестовое задание, которое «займет буквально один ваш вечер», от чего он праведно негодует — это где столько вечеров раздают-то!

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

Подход, который я увидел в паре немецких компаний и теперь топлю сам:

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

Всё просто и честно. Интервьюеры могут посмотреть свежий-сочний код, а кандидату не надо тратить свои вечера на каждое задание, можно написать код один раз и носить с собой.

К сожалению, сейчас лишь единицы из опрошенных мной компаний разрешают это. Каждый может помочь это изменить.

Если вы компания — разрешите выкладывать ваше тестовое задание на гитхаб и принимать имеющиеся. Напишите об этом открыто в своей вакансии. Можете твитнуть об этом с мешненом @vas3k и я ретвитну вашу вакансию (если остальное описание тоже будет честным и без булщита).

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

Так победим.

Теперь самое интересное.

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

Классы важно знать чтобы:

• Собирать нужную команду в зависимости от ситуации
• Понимать как общаться с каждым из них
• Не набрать одинаковых персонажей с одинаковыми слабыми сторонами (да-да, дайверсити!)
• Понимать кто сработается сразу, а кому понадобится посредник
• Знать когда персонаж уйдёт или выгорит

Главное — не увлекаться. Тут как с новой бензопилой: лучше держать её в гараже, а не бежать на рождественскую ярмарку (хоть и хочется).

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

Я знаю системы, где работников разделяют на 48 классов типа «Увлечённый Мечтатель» или «Коварный Диктатор». Полная дичь. Если что-то невозможно запомнить — это тем более не получится применять в жизни.

Для себя я всё свёл к набору из четырёх базовых классов, из которых строятся остальные.

На собеседовании я всегда стараюсь определить кто передо мной

Каждый класс отлично определяется вопросами вида «как бы вы поступили, случись такая-то ситуация». Обычно я совмещаю их с техническими вопросами. Ситуации беру приближенные к реальности, конечно.

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

Тот, кто хуячит. Хуятор — основа любого общества. Как шахтёр или строитель. Он просто делает то, что нужно делать. Дали шахту — надо копать. Дали таску — надо пилить.

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

Неорганизованность хуятор считает распиздяйством.

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

Когда нужен? Почти всегда, кроме реструктуризации (ниже нарисую картинку, там будет понятнее).

Зачем? Молча делать работу, которая определена. Хуятор может неделю писать юнит-тесты и даже не поехать кукухой.

Минусы Хуятор перманентно пребывает в одном из двух состояний — либо завален работой по уши, либо он выгорел и сидит в депрессии. Ему постоянно некогда.

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

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

1131 Похоже на меня

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

Постоянно всем рассказывает какой новый фреймворк увидел на гитхабе и какие сейчас тренды в айти. Люди его любят, как источник вдохновения, но иногда не верят в его сказки.

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

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

Минусы Экспериментатор обожает начинать, но редко доводит дело до конца в одиночку. У него всегда появляются «более перспективные идеи». Не умеет смотреть в перспективу и увольняется после первого же кризиса.

Как договариваться На любую новую идею экспериментатор говорит ДА-ДА-ДА-ЩА. Проблема в том, что он забывает об этом через три секунды. Работают стандартные методы контроля типа «создай таск» и «напиши как сделаешь».

1059 Да это же я!

Бюрократу совершенно насрать ЧТО делать, главное — КАК делать. Процессы превыше всего, а результат по его мнению придёт, если делать всё правильно и терпеть.

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

Бюрократ не до конца понимает «экспериментаторов», которые по его мнению только все портят необдуманными нововведениями.

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

Зато если дать ему такой план (или что-то похожее) — он без вопросов пойдет действовать по нему, прочитает 15 книжек и реорганизует все процессы как там написано.

Зачем нужен? Наводить порядок и налаживать процессы. Защищать продукт от необдуманных телодвижений. Документация, структуризация и разбор технического долга, который наговнокодили Хуяторы и Исследователи — вот основная задача бюрократа.

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

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

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

Как договариваться Стандартный ответ бюрократа на любой вопрос — НЕТ. Просто выдыхайте и продолжайте предъявлять аргументы (возможно даже одни и те же). Бейте в то, как это улучшит организацию и процессы, пока не услышите ДА. Так работает.

После этого «да» можно быть на 146% уверенным, что всё будет сделано как надо. Бюрократа не надо проверять, это его обижает.

518 Я — бюрократ!

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

Зачем нужен? Налаживать связи между людьми. Поддерживать постоянный обмен информацией. Бегать «решать вопросики» с людьми из разных команд. Ну и просто для атмосферы.

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

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

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

Он не нападающий, он скорее защитник, как и бюрократ. Только связывает людей не процессами, а отношениями.

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

1135 Похоже, я интегратор!

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

Поэтому:

Любой специалист выше мидла сочетает в себе минимум два класса

Наша цель уметь их правильно определять и подстраиваться.

Приведу для примера самые популярные вокруг меня, остальные сами додумаете.

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

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

678 Да, я тоже стартапер!

Хорошо знакомое мне сочетание потому что, ну, я сам такой. Сейчас стараюсь качать скилл Интегратора, ведь он был бы очень полезен в дальнейшем, но пока как-то в основном получается Бюрократ.

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

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

Антипод Стартапера. Идеальный защитник. Персонаж, который обожает залезать в каждую щель и наводить там «чистоту».

Часто обитает в службах безопасности (ИБ). Там, где не надо ничего производить, но нужно всеми силами охранять. Опричник следит чтобы ни один байт не прошел по незащищённому соединению, а когда обнаруживает дыру — сам находит и казнит виновного. В этом его кайф.

254 О, я опричник. Класс!

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

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

859 Вот это точно я!

Решает проблемы. Прямо обожает это говно. Только решая чужие проблемы он чувствует себя удовлетворённым. Траблшутер готов фиксить упавший прод даже ночью. Этим он похож на Стартапера, но в отличии от него, может дольше жить в стабильности крупной компании. Как бы точа топор и выжидая.

1219 Я — траблшутер

Последняя важная деталь для понимания классов. Один класс — простой крестьянин. Два класса — автономный боевой юнит. Но есть персонажи, которые ведут всех на бой. Их уважают и за ними следуют. Таких называют заезженным словом «лидеры», но в нашей схеме у них очень просто определение:

Лидер — тот, кто сочетает не два, а сразу три базовых класса

👩‍🔬 + 🏃‍♂️ + 🤝

👨‍💼 + 🤝 + 🏃‍♂️

...

Любых. В разных пропорциях. Иногда даже сам того не подозревая.

Не стоит путать лидеров с лидами и менеджерами. Лид — это звание. Его можно получить за выслугу лет. Менеджер — это вертикаль, как разработчик, в менеджеры хоть после школы можно идти. Лидер — это именно персонаж. Как «лидер мнений».

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

774 А я, получается, лидер

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

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

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

Где-то здесь лежат корни классов персонажей. Только там они названы Producer, Entrepreneur, Administrator и Integrator, что образует аббревиатуру модели PAEI. Самый её сок — там рассказано как общаться представителям одного класса с представителями другого, чтобы не загрызть друг друга.

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

Подобных моделей еще существует много. Из понравившихся еще помню DISC и набор персоналий по Myers & Briggs, так что мне сложно судить какая повлияла больше. По факту, всё это было придумано еще в прошлом тысячелетии, а если пытаться копнуть глубже, оттуда на тебя вообще смотрит Карл Юнг.

Но не стоит. Помните про бензопилу на рождественской ярмарке.

Ещё в Team Fortress 2 был действительно неплохой набор персонажей. Без шуток. Ну а карточные игры типа MTG и DnD очень помогают развивать подобное мышление.

А то мне вот всё детство говорили, что игры — зло, вот я и вырос таким неприспособленным.