Привет! Я — Ася Маркевич, HRD диджитал-продакшена ДАЛЕЕ. Уже 5 лет работаю в агентстве, с тех пор наш штат вырос с 80 до 300+ человек. Сегодня хочу порассуждать о том, что дженералистов (кстати, кто это?) становится все меньше. И это проблема для всего рынка заказной разработки. А помогать мне в этом будет наш тимлид Дмитрий Александров.
Начнем с того, что наведем порядок в терминах.
Разбираемся в терминах
Дженералист — это не общепринятый термин, но его используют для обозначения тех, кто попал в IT на рассвете появления популярных инструментов, то есть 25-30 лет назад. Сегодня эти специалисты занимают должности технических директоров ну или хотя бы тимлидов. И отличает их от нынешнего поколения разработчиков тот факт, что они начинали карьеру, когда большинство инструментов не было развито, а некоторые технологии еще даже не появились.
Дженералисты успели поработать с бОльшим количеством инструментов в первые 3-5 лет своей карьеры, чем те, кто пришел в профессию после 2015 года. Соответственно, и представление об IT у них более полное.
Сегодня разработчики стали все больше замыкаться на узкой специализации. За прошедшие годы технологий стало больше. Они обросли окружением и версиями, и требуют все больше времени на освоение.
В результате на рынке становится все меньше дженералистов.
Зачем нужны дженералисты
Дженералист повышает качество проработки проекта
Для дженералиста его участок проекта — это не отдельный этап, а часть общего. Он понимает, как его решения повлияют на весь проект. Это достигается за счет того, что такой специалист имеет представление обо всех инструментах, задействованных на проекте. Причем не из гуглов и ютубов, а из реального опыта использования. Даже если опыт небольшой.
Дженералисты могут быстрее идентифицировать и устранить проблему
Если специалист понимает особенности разных технологий и инструментов, он быстрее идентифицирует источник проблемы и придумает, как ее решить.
Дженералисты особенно полезны в стартапах, где ресурсы ограничены. А ещё на стадии аналитики, когда нужно оценить задачу и понять, какие технологии подходят для решения бизнес-задачи.
Дженералистов правда скоро не будет?
Сегодняшние дженералисты — это люди, которые получили базовое IT-образование, стартовали в профессии, когда технологий и инструментов было меньше, а значит, больше возможностей уместить их в голове и применять в работе. Вряд ли найдутся дженералисты младше 40 лет.
Кто приходит в IT сегодня
А вот сегодня бэкграунд людей, которые стартуют в профессии, чаще всего другой. Порог входа снизился, плюс добавьте всевозможные IT-курсы, после которых люди тоже находят работу.
И это не нападка на тех, кто приходит в IT сегодня, какой бы бэкграунд у них ни был. Скорее, вопрос к самому рынку, который стал другим и потянул за собой коренные изменения в том, что касается порога входа.
Вот пример: допустим, человек отучился на React-разработчика, устраивается в компанию и пишет код. Если он и учится чему-то новому, то только в рамках стека технологий, который использует команда. Он наращивает компетенции в узкой нише.
Если этот фронтендер станет менять работу, то будет искать позиции с релевантными требованиями к опыту. В какой момент у этого React-разработчика появится возможность погрузиться в смежные с его специальностью направления? Он может вовсе не наступить. В итоге человек остаётся в узкой специализации. Это не плохо и не хорошо. Но это значит, что он вряд ли станет дженералистом.
Я не утверждаю, что дженералистов не будет вовсе. Просто современные тенденции и ситуация на кадровом рынке играют не в пользу расширения компетенций.
Как проблема с дженералистами связана с рынком заказной разработки
Агентский бизнес не позволяет иметь раздутый штат, а простой специалистов бьет по рентабельности. Кроме того, в агентство приходят клиенты из разных сфер. Такому бизнесу необходимы дженералисты в команде, и обычно эту роль выполняет технический директор.
Агентству интересны универсальные солдаты. Например, у нас нет разделения на бизнес- и системных аналитиков, потому что мы не уверены, что для специалистов обоих типов хватит загрузки, рабочих часов. Поэтому ищем на рынке тех, кто способен закрывать обе задачи. Мы также любим разработчиков, которые могут работать с разными инструментами: React и Vue.js, к примеру. Если говорить об агентствах поменьше — они вообще редко берут на работу специалистов, отдают предпочтение фулстекам. Последние — не дженералисты, но стоят ближе к ним, чем какой-нибудь laravel-разработчик.
Если дженералистов не будет, работа над проектом станет менее эффективной и более дорогой: нехватка знаний приводит к большему количеству ошибок и переделок. По итогу это влияет на экономику проекта: его стоимость вырастет как для агентства, так и для клиента. Со мной поделился мнением коллега-тимлид, Дмитрий Александров:
Довольно часто бывают ситуации, когда люди из разных специальностей друг друга понимают с трудом. Я бы не сказал, что это сильно мешает работе, но дискомфорт и снижение качества результата определённо есть. В основном это случается как раз с узкими специалистами: бэкендеры и фронты, менеджеры и админы/бэки/фронты (непосредственные исполнители). Более осведомленными во всех процессах являются тимлиды, QA и аналитики, хотя и их знания достаточно специфичны.
В условиях, когда дженералистов станет в целом меньше, доступ агентства к таким специалистам снизится еще сильнее. Ведь мы конкурируем не только с другими агентствами, но и с продуктовыми компаниями. Причём из-за растянутости во времени, процесс происходит незаметно.
Что с этим делать?
Первое, что приходит на ум — растить дженералистов изнутри. Люди же как-то до сих пор становятся тимлидами и техдирами. И не всем из них 40+ лет.
Но для агентства это сложный путь, сопряженный с большим уровнем риска. Кроме того, вряд ли получится вырастить именно дженералистов. Исходные условия для попадания в сферу уже не те. Да и IT давно стал необъятным.
Второй вариант — смириться и растить современных дженералистов — Т-шейперов.
Современные дженералисты — Т-шейперы
T-шейперы — это люди, которые имеют узкую специализацию, но при этом обладают общими знаниями своей сферы. Таких специалистов сложно схантить. Но их можно вырастить внутри.
Чем они отличаются от дженералистов? Можно выделить вот такой список. Он примерный:
Они пришли в IT позже дженералистов,
Т-шейперы начинали с узкой специализации
Уже после того, как стали экспертами в ней, Т-шейперы решили расширять карту своих компетенций.
Как их растить внутри?
Во-первых, время сотрудников в агентстве распределено между проектами и часто в дефиците.
Во-вторых, где гарантии, что такие инвестиции к вам вернутся? С точки зрения бизнеса обучать человека компетенциям, которые не относятся к его прямым обязанностям, не выгодно. Агентство часто становится ситом для кадров. И не забываем о риске того, что вы обучите человека, а он уйдет в другую компанию.
Но не все так плохо.
Многие компании — как продуктовые, так и агентства — практикуют ротацию кадров, переводят специалистов с проекта на проект. Так риск выгорания снижается, у сотрудника появляется возможность изучить и попробовать себя в новых технологиях или в новой роли.
Аргументы о том, что дженералистов скоро не будет, и это отразится на агентском бизнесе, мне кажутся логичными. Но при этом я не могу представить ситуации, в которой человек в течение всей профессиональной карьеры фокусируется только на одном инструменте или технологии. Люди устают делать одно и то же.
В идеале компании нужно учиться управлять процессом роста Т-шейперов.
Системный подход приведет к тому, что таких людей будет много и уход одного не станет критичным для бизнеса. А сама среда будет привлекать в компанию людей, которые заинтересованы в развитии и уже идут по пути расширения компетенций.
Чувствуете ли вы нехватку т.н. дженералистов?
Комментарии (65)
saboteur_kiev
24.03.2024 19:16+1Так это же про архитекторов, чья роль в разных компаниях слишком размыта.
Просто зачастую в ентерпрайзах архитекторы часто не занимаются ни архитектурой, ни релизными активностями, а пилят какой-то POC и деньги за непонятно что.Но там где архитектор совмещает работу с тех.лидом, он как раз и знает весь стек проекта, с ним дружат и девелоперы и девопсы, ну и проект дружит с логикой.
sergey-gornostaev
24.03.2024 19:16+2чья роль в разных компаниях слишком размыта
Ох, в самое сердце. Одни хотят, чтобы я 40 часов в неделю сидел на созвонах с бизнесом и интеграционными партнёрами. Другие хотят, чтобы я прорабатывал технические аспекты реализации продуктов. Третьи хотят, чтобы я учил и направлял команду. Четвёртые хотят R&D. Ни у кого из них моего ресурса не хватит даже на реализацию всех их идей, не говоря уж о совмещении различных интересов.
dyadyaSerezha
24.03.2024 19:16А зама взять на помощь? Вот хоть меня.
sergey-gornostaev
24.03.2024 19:16Как говорится, девять женщин ребёнка за месяц не родят. Зама ровно так же засыпали бы всем тем же, поэтому стараемся бороться с причинами, а не следствием. К тому же я и сам зам в некотором роде, тащу техническую составляющую части проектов, пока корпоративный архитектор тонет в бюрократических процедурах и совещаниях.
poxvuibr
24.03.2024 19:16А как вы с этим боретесь? Как выбираете чем заниматься и что говорите тем, чьи задачи делать не будете?
sergey-gornostaev
24.03.2024 19:16Пока не очень удачно, если честно, но некоторый прогресс есть. До руководства удалось донести факт ограниченности ресурса, и теперь линейный и функциональный руководители договариваются между собой и сортируют список моих задач по порядку выполнения. После нескольких итераций пришло и понимание, что такая сортировка - это не выбор правильной последовательности, а только выбор где и на сколько сильно будет больно потом. Что в свою очередь привело к тому, что выбор приоритетов стал очень взвешенными, темпы разработки снизились до более разумного уровня, отбор задач в бэклог тщательнее, часть созвонов вообще отменилась, часть стали ограничивать по времени и загонять в жёсткие регламенты, часть перекладывают на корпоративного архитектора и тимлида бэкендеров. Последнее - костыль, который сам по себе периодически приносит проблемы, но пока без этого обойтись не получается.
Asyamarkevich Автор
24.03.2024 19:16+1Хотела поставить плюсик вашему комментарию, но карма на сегодня исчерпалась) Так что ставлю его в виде комментария
dyadyaSerezha
24.03.2024 19:16Значит, эникейщиков не хватает... Шучу, шучу про эникейщиков, не бейте палкой! Но это неизбежно, как и написано в тексте - программирование как индустрия разлослось в десятки раз за последние 30 лет. Если я знал почти наизусть весь Win API для Windows 3.1, то сейчас это десятки тысяч функций - и это только самый нижний, базовый уровень, а сколько над этим надстроено фреймворков, продуктов и прочего? Нельзя объять необъятное - кто сказал? (Прутков?)
Asyamarkevich Автор
24.03.2024 19:16Палкой не бьем! У нас тут приличное и цивилизованное сообщество)
DustCn
24.03.2024 19:16+7Дженералисты, эх... вот как это называется.
Я вот такой женераль. Начинал на МК61 сейчас ковыряюсь в HPC. Могу вчера код на фортране ковырять, сегодня чета в хугинфейс сабмиттить на питоне. И что вы думаете? Мой карьерный рост прекратился лет 10 назад, когда в конторе мне сказали, что я классный пожарник, что лучше всех умею детектить и фиксить баги и все такое. Но у меня видите ли, нет специализации. Мне нужен огородик, в котором я буду растить свои экспертизы. А за сэкономленное время других людей - грейд не дают, как и прибавку к зп.
Так что не надо вам в эти женерали. :)
xaosxaos2
24.03.2024 19:16Пожарный в таком случае, пожарник это жертва пожара.
Zenitchik
24.03.2024 19:16Жертва пожара - погорелец. Пожарник - не жертва пожара ни в одном словаре.
Мне попадалось, что пожарник - это как дружинник, только пожарный, но это неточно. Скорее всего, просто неправильное слово.
xaosxaos2
24.03.2024 19:16"В дореволюционной Москве «пожарниками» называли лжепогорельцев, которые прикидывались пострадавшими от огня, дабы вызвать сострадание и получить милостыню. Настоящие жертвы пожара в полицейских протоколах назывались «погорельщиками», а ложные – «пожарниками»"
Zenitchik
24.03.2024 19:16Это из какого словаря? Дайте ссылку.
xaosxaos2
24.03.2024 19:16Первая страница из поиска в гугле. Плюс, конечно это не авторитет, но знакомый пожарный, когда его называют пожарником, доходчиво объясняет оппоненту, почему он не пожарник, а пожарный. К сожалению я не помню, какой версии придерживается он, но могу уточнить при встрече.
Zenitchik
24.03.2024 19:16Первая страница из поиска в гугле.
Вы же понимаете, что у разных людей могут быть разные выдачи гугла? У меня на первой странице такого нет. Зато есть
"разговорное: работник пожарной команды"
"Пожарник – прежде пожарный-любитель, член добровольной пожарной комады"
"В словаре Даля пожарник – устраивающий пожарные команды и заправляющий ими"
он не пожарник, а пожарный
То что пожарник - это не пожарный, это не ответ на вопрос, кто такой пожарник.
xaosxaos2
24.03.2024 19:16Послушайте, всё что я знал, я Вам выдал. Если Вам надо, разбирайтесь и ищите.
Zenitchik
24.03.2024 19:16Извините. Я ошибочно подумал, что Вы настроены на дискуссию.
xaosxaos2
24.03.2024 19:16Я не филолог. Поэтому очень долго для меня что пожарный, что пожарник был синонимом. Пока несколько лет назад, случайно или нет уже не помню, было аргументировано описано различие. Мне этого хватило, чтобы изменить свои понятия о данных словах. Вполне возможно, что аргументы были не верны и ошибочны. Но что есть с тем и играем. Мы подискутировали, Вы высказали своё мнение, я своё. Доказывать. Зачем?
Zenitchik
24.03.2024 19:16Доказывать. Зачем?
С целью распространения достоверной информации и замедления распространения неверной.
Я не возражал Вам, что пожарник - это не пожарный. Моё возражение относилось к тому, кто такой пожарник.
Но если Вам лень продолжать дискуссию - я Вас полностью понимаю, и не настаиваю. Мне, честно говоря, тоже лень.
xaosxaos2
24.03.2024 19:16С целью распространения достоверной информации и замедления распространения неверной.
Вы наивны с своих заблуждениях. Хотите пример? Не вопрос. Достоверная ли информация из любой религиозной книги? И любой (подчеркиваю ЛЮБОЙ) Ваш ответ будет неверным :)
sshikov
24.03.2024 19:16А за сэкономленное время других людей - грейд не дают, как и прибавку к зп.
Это смотря где. Хотя вы правы - понимание того, сколько стоит такая активность есть далеко не всегда. И не у всех. Но встречается.
muxa_ru
24.03.2024 19:16Сегодняшние дженералисты — это люди, которые получили базовое IT-образование,
Ага, а между занятиями по профильному IT-образованию приходилось охотится на динозавров, чтобы выполнить норму сдачи мяса в колхоз. Тех кто не выполнял норму, Сталин отправлял в тюрьму где людей лично пытал Иван Грозный.
ruomserg
24.03.2024 19:16+13Нет, дело не в том, что дженералисты знают "всё ит". Эта эпоха кончилась, наверное, в 70-х. Дело в том, что они знают, как оно там работает под слоями абстракций и геологическими формациями библиотек. Потому что еще успели поработать на относительно медленных и проще устроенных системах ближе к железу. А разговаривая с относительно недавними разработчиками - я иногда не понимаю, как они вообще ухитряются выдавать годное. Ибо их базовые знания - либо чистая мифология и зельеварение (известно, что если хочешь полететь на метле - надо взять сушеную жабу, слизь саламандры, глаза жужелицы и варить на медленном огне 6 часов), либо сознательная слепота ("там тьма, ужас и монстры - я об этом даже не буду думать"). Мне это дико (благо я начинал с восьмибитных КР580ВМ80А, цельнотянутых i8080, и далее через все поколения персоналок и кусок промышленных контроллеров) - я бы повесился работать с системой, которая с определенного уровня становится магией, и с которой ты при всем желании ничего не можешь сделать. А молодым ничего, норм...
Впрочем, я сейчас еще одну интересную вещь скажу. Наблюдая за своими детьми, я обнаружил что они вообще к компьютеру относятся совершенно не так как я. Для них ПК - это бытовой прибор наравне с микроволновкой или чайником. Хотим разогреть пиццу - идем к микроволновке. Хотим в интернет или поиграть - включаем компьютер. А для меня, компьютер всегда был потрясающим приключением, которое хочется программировать. Впрочем, когда я поделился этим со своими родителями - они сказали, что история повторяется. Для них в институте - один калькулятор (Б3-18) в группе был подарком судьбы: вместо расчетов столбиком, логарифмической линейки и таблиц Брадиса - просто жмешь кнопки, и получаешь сразу ответ (втч логарифмичекие функции, экспонента, тригонометрические и обратные!). И они (если он попадал в руки) на нем считали, даже если не было особо и нужно! :-) А мы (их дети) уже относились к калькуляторам безо всякого пиетета, и без понимания что оно там внутри делает.
Asyamarkevich Автор
24.03.2024 19:16+1Очень интересный пример про детей) И со смартфонами у них наверняка так же. Разве что какой-нибудь Vision Pro может на них произвести похожее впечатление, как компьютер на детей поколения 90-х. И то не факт)
Asyamarkevich Автор
24.03.2024 19:16А вот нынешним разработчикам наверняка диким кажется ваш опыт. Они наверно, слушая рассказы про все это, думают про себя: "Ну, не повезло работать с таким старьем и продираться через дебри. Слава богу, сейчас этим уже не надо заниматься)))"
И они уйдут, так и не узнав, что порядочная часть знаний осталась на уровне магии. На самом деле, мне кажется, сложно за собой отследить такое поведение и что-то с ним делать. Ну вот с той же микроволновкой пример: "греет? функцию свою выполняет? класс, я о ней вообще не буду думать. есть куча других тем, о чем подумать". Это не камень в огород нынешних разработчиков. Это просто то, как мы все устроены.muxa_ru
24.03.2024 19:16+1Когда Вы не задумываетесь как у Вас работает микроволновка - Вы иногда остаётесь без ужина.
Когда IT-разработчики не задумываются о том как работает компьютер, в это может быть вовлечено очень много людей.
ncix
24.03.2024 19:16+3диджитал-продакшена
А можно для седых дженералистов пояснить, что значит этот новояз? Чем занимается компания в сфере "диджитал-продакшен"?
soymiguel
24.03.2024 19:16+12Давайте уж честно: «сложно схантить» по факту имеет суффикс «за те пять копеек и песни про «мы семья и у нас офигенные тим-билдинги пополам с печеньками с изюмом в кухонном уголке», которые мы предлагаем в качестве высочайшей милости через восемьсот раундов собеседований каждое по восемь часов в течение всего-то месяцев восьми».
Ну да, 45-летнего так не схантишь, если он не совсем на головку хром.
igorts
24.03.2024 19:16Интересный термин, раньше не встречал как то.
Я сам из таких. Основная особенность, на мой взгляд, это инженерный подход к проблеме - поиск и применение наиболее подходящего инструмента под задачу, а не натягивание задачи на известный тебе стек.
Вспоминаю, как просил отдел разработки, специализирующийся на Java, написать простой парсер excel файлов с конвертацией и загрузкой в бд.
Мне выкатили оценку трудоемкости в неделю на Java.
Плюнул, написал парсер на powershell за день, примитивно, но все что надо сделал.
xxxphilinxxx
24.03.2024 19:16+3Простите, позанудствую :) мне тут видится ложное противопоставление: наверняка ведь совсем не из-за выбора Java vs Powershell назвали неделю вместо одного дня. Не знаю ваших подробностей, но оценка обычно включает обработку редких и пограничных случаев, тщательное тестирование, правки багов, доставку в среду исполнения, демонстрацию с обработкой обратной связи, "причесывание" кода, документирование, разнообразные риски и т.д. и т.п., поэтому оценка в неделю означает не то, что балбесу-разработчику действительно нужна целая неделя на написание какого-то примитивного скриптика, да еще и на неподходящей технологии, а то, что он уверен, что через неделю решение будет полностью готово - на мой взгляд, это как раз характеризует ответственный инженерный подход в противопоставление "тяп-ляп и в продакшн". Примитивное решение на коленке при этом может получиться всего за несколько часов - правило 80/20, которое, кажется, вполне ложится на ваш пример.
Asyamarkevich Автор
24.03.2024 19:16Да, термин не очень известный) И не строгий. Может, есть другое обозначение, мне не встречалось.
Это правда, мы тоже видим разницу больше в подходе и вообще в том, как человек строит ход мыслей, когда сталкивается с той или иной задачей.
sshikov
24.03.2024 19:16+2Простой парсер excel на java - это где-то 10 строк. Три вложенных цикла - по страницам .xls файла, строкам, колонкам. Плюс еще 10 строк - преобразование типов данных, кои бывают разные, в разные же типы базы. Плюс еще строк 10 - само сохранение.
Даже если я ошибаюсь в два раза - это не существенно, я такое реально делал раз десять за свою практику. Реально можно написать за час, не сильно напрягаясь. За день - если вы никогда этого не делали, тоже норм. И если вы на windows, и у вас есть доступ к COM объекту Excel, то на любом из языков с поддержкой COM, то еще чуть проще.
А вот если вы ко мне придете и попросите чтобы моя команда это написала (причем переносимое на линукс) - я тоже попрошу неделю срока. Потому что не знаю, кто именно будет писать, и как глубоко придется объяснить человеку суть дела, сколько времени уйдет на тестирование, и т.п. Иными словами - оценку вам выкатили совершенно адекватную. При мне начинающий java-программист писал такое месяц, и при этом все еще не закончил.
igorts
24.03.2024 19:16+1Я не заставлял их писать на Java - это был их выбор
На мое предложение написать с помощью скриптового языка мне ответили - мы знаем Java, будем делать на Java ;)
sshikov
24.03.2024 19:16Ну, есть такая штука, как Apache POI, это один из самых старых, и самых продвинутых пакетов поддержки форматов Офиса, помимо собственно COM. Так что выбор (одного из) языков для JVM - он в принципе-то вполне логичный.
А так да, я бы тоже начал писать на груви, а не на Java :) Ну или на скале. Не то чтобы на скриптовом языке в полном смысле этого слова, но на чуть более гибком, чем Java.
xenon
Недавно (полгода назад) про аналогичное писал: А далее наша планета попробует в IT без генералистов. И меня эта ситуация пугает... Сфера выросла от перфокарт до "этого вашего интернета" за одно поколение и продолжает расти-расширяться. В медицине та же проблема, что один врач не может хорошо знать все темы, но там за сотни лет как-то устоялось разделение ролей, наладилось их взаимодействие. И человек за эти сотни лет не усложнился.
Вот из недавнего вижу проблему, которую на меня скинули (как на главного по любой непонятной фигне и по безопасности) - Content Security Policy. Нужно было натянуть ее на готовое приложение. В целом CSP - подход замечательный, мне нравится, как раз страхует от некомпетентности исполнителя. Однако, хорошо ее натянуть "снаружи" (просто расставив правильные HTTP хидеры и чтобы сразу было все безопасно) - не получится. Значит, именно фронт-енд программист должен исходно писать CSP-friendly приложение. А все древние гайды для чайников учат использовать onlick="...". Конечно, можно просто бить фронтендеров по рукам, чтобы они его не использовали. Будут запуганные. Но по-хорошему - даже фронтендер должен знать про XSS атаки, хотя бы на уровне нескольких простых самодельных эксплойтов - тогда сможет понимать, почему эта сатанинская CSP - это радость и счастье. Мы не можем сделать веб-разработчиков тут, а безопасников там, разделить их, как ЛОРа и кардиолога в разных кабинетах.
Даже если вы наймете 15 генералистов в штат - код будут писать фронтендеры, которые про XSS и SQL Injection в лучшем случае что-то краем уха слышали...
dyadyaSerezha
А провести обучение по безопасному коду этих фронтендеров - не судьба? В смысле, жалко бабок?
xenon
Эх, если б я был такой же умный, как моя жена потом!
Да можно даже не на курсы какие-то, а самому объяснить, там не слишком-то и сложная тема. Но о том и речь, и даже вы (если другими словами) то о том же и говорите - нужно из фронтендеров делать немного генералистов. Просто разделить обязанности "ты пишешь фронт, а ты занимаешься безопасностью" - невозможно.
dyadyaSerezha
Да полно инфы на тему безопасности в инете, включая онлайн-курсы, которые проходятся самостоятельно. Насчёт разделения, вообще не понял. Если безопасность это обычная часть требований, то и программист должен это знать. Вот и всё. Эдак можно сказать, что бэкендер только код должен писать, а как там с БД или брокерами сообщений работать, не его дело. Смешно же?