Почему компании так упорно хотят иметь Fullstack разработчиков?
Здесь уже написано множество статей о том, кто такой Fullstack, в чем его плюсы и минусы, в каких проектах есть смысл нанимать таких разработчиков, а где — нет. Я буду исходить из мысли, что вы понимаете, что такое Fullstack и с чем его едят.
Мысль, которую я хотел бы выразить заключается в следующем — «Почему, даже большие аутсорсинговые и продуктовые компании, хотят нанимать Fullstack и/или развивать своих сотрудников в этом направлении?».
Вопрос, в контексте статьи, интересный, но отвечать на него я не хочу, я хочу лишь порассуждать на эту тему.
Возьмем управляющего большой компании, скажем, больше 500 человек, который получил следующую сводку от руководства: «Нам необходимо набрать 20 разработчиков для наших будущих продуктов/заказов».
Руководство не волнует, будут ли это BE или FE или Fullstack — им нужно сдать в срок заказ или выпустить продукт. Управляющий, начитавшийся многих статей о Fullstack, думает: «Вот же оно — Решение!» и начинает набирать Fullstack, исходя из мысли, что можно набрать 15 таких разработчиков и закрыть все вакансии да еще и денег сэкономить, ведь зарплаты таких разработчиков редко превышают зарплаты более узкоспециализированных разработчиков.
Но, спустя какое-то время, начинаются проблемы, не через месяц, так через год. Оказывается, что продукт/приложение оказывается не способным выдержать нагрузку или добавление новых фич стало трудоемким и неэффективным.
Это случается не всегда и не со всеми, но случается все чаще. Почему так? Потому что, первое, что необходимо сделать после утверждения MVP (минимального рабочего продукта) — это убедиться, что все стало на свои места и дальнейшее развития продукта пойдет максимально прогнозируемо с минимально возможным количество ошибок. И, как правило, спрогнозировать дальнейший путь приложения/продукта, может лишь квалифицированный специалист.
Я ни в коем случае не против Fullstack, как явления, потому как эффективность таких разработчиков доказана в определенных случаях, но меня сильно беспокоит появившиеся тенденции к развитию текущих узких специалистов в Fullstack для любых продуктов, в независимости от того нужно это или нет.
Это один из древнейших споров: «Широкий профиль из узкий?».
Все мы прекрасно знаем, что сейчас, нанять толкового специалиста — большой труд и иногда, непосильная задача.
Судя по личному опыту проведения более сотни интервью, в основном с ребятами из ЕС и СНГ, часто приходиться идти на уступки руководству и нанимать хотя бы немного дотягивающего по уровню специалиста в огнем в глазах, в надежде, что он еще принесет пользу и станет «Rock Star». Все чаще видишь «Senior Dev / Senior Fullstack Dev», с миллиардом лет опыта, который не можешь решить FizzBuzz, посчитать сумму чисел Фибоначчи или написать пример рекурсии.
Сейчас сложно быть в топе, хотя бы в одном направлении, будь-то FE в Web, Android, iOs, разработке игр или же BE в
той же разработке игр, Data Science, Big Query, DB analyst, и т.д. Чтобы быть реально полезным, надо, чтобы не только «котелок варил», но и знать все тренды и иметь багаж практического опыта, а этого можно достигнуть, лишь изучая что-то новое ежедневно.
Я согласен с тем, что любой разработчик должен знать основы программирования, иметь алгоритмическую подготовку, знать и понимать различие паттернов и понимать, в общих чертах, как работает и FE и BE. Но, по-прежнему считаю, что толковый специалист их конкретной области, сделает все быстрее и лучше, чем специалист широкого профиля.
Да и, задумайтесь сами, с кем бы вы хотели работать и обучаться — с Fullstack или умудренным сединами, FE, BE, GameDev, DevOps гуру?
P.S. Есть определенное количество одаренных ребят, способных работать и поспевать во всем, что делают, будь-то FE, BE и т.п. Но их еще меньше, чем толковых узких специалистов, и закрыть все необходимые вакансии и потребности на рынке они, увы, не смогут. Я только рад, если человек сменил род деятельности и перешел в другую область, но, он по-прежнему, будет занят в одной области, а не в десятке областей.
Комментарии (39)
28 августа 2016 в 19:45
+1↑
↓
Мне кажется, ваша боль не от фулстэка как такового, а от неадекватной самооценки кандидатов в каждом втором резюме. Так это и не у фулстэкеров встречается сплошь и рядом. А фулстэк на то и фулстэк, чтобы уметь поднять веб-продукт целиком и уметь смотреть на систему в целом. Да, это требует колоссального количества познаний. Но невозможного в этом я ничего не вижу.28 августа 2016 в 19:55
0↑
↓
Я по-этому и написал, что есть толковые ребята, которые могут это сделать, но меня беспокоит то, что компании хотят, чтобы максимальное количество разработчиков были фулл-стэк.28 августа 2016 в 19:58
+3↑
↓
Думаю вы правы, что это обыкновенное стремление снизить затраты за счет найма одного человека-оркестра вместо двоих, а то и троих :) И насчет развития узких специалистов до фулстэкеров — тоже объяснимо, если принять во внимание стремление к взаимозаменяемости людей в команде.28 августа 2016 в 20:02
0↑
↓
Есть еще проблема у работника «надоело одно и тоже, хочу чего-то нового»=)28 августа 2016 в 21:04 (комментарий был изменён)
+3↑
↓
полностью согласен, это стремление снизить затраты за счёт найма человека-оркестра очень заметно в менее денежной области: разработке и производстве электроникипримеров много:
1. Знакомый с богатым опытом работы хотел устроится на разраба прошивок двигателей в Дубну (цена бага миллионы и десятки миллионов рублей), пообещали до кризиса за 150тр, но после кризиса вместо этого взяли двух студентов на вырост за 30тр (до первого сожжёного мегаватника видать). будут год ескд изучать, а потом год отладочные платы — видать результаты им не нужны вообще.
2. Я сам держу три разных резюме (плисовод, микроконтроллерный си/с++, разработчик электроники) не получил ни одного предложения если выставить желаемую з/п более 100тр уже за пол года, ну да, за 60–80тр (для МКС) вылазят куча неадекватов, гос контор и прочих сомнительных мест с переработками, командировками и фин ответственностью за срывы сроков (работал там, спасибо не надо, редко платили выше 50% от обещанного из-за «сделать вчера» и штрафов).
3. Ко мне постоянно обращаются сомнительные «крутые конторы» в которых «все программисты уже на крузаках ездят», стартаперы, оборонка, все они просят что то разработать, все замолкают после просьбы о предоплате хотя-бы отладочных плат, и части моего времени (обычно это суммы не более 10тр из 200т и выше). А без предоплаты я даже паяльник в руки не возьму и IDE не запущу, точка.
4. У меня есть маленькое хобби по разработке и производству некоего гаджета, аналогично — никто из русских не покупает за 20 евро (ноют: дорого), в европе и не только как пирожки даже за 200 уходило, знай только по 500шт отгружай.ну и так далее.
я долго могу рассказывать о фин несостоятельности заказчиков и ненужности разработчиков электроники.
По-моему и разработчики и результаты их работы у нас попросту не нужны и наш бизнес с ними слабо умеет работать.Вот недавно работодатель на основном месте работы огорчил:
Извинился и сказал что не тянет наши разработки в плане маркетинга и увеличения объёма продаж, поэтому новых разработок больше не будет, нас увольняет с н.г. и оставляет за нами только авторские % от маржи с каждого изделия что тоже неплохо. Увеличив этот процент до 30 за что спасибо им, по сути они дают 100% свободного времени, за половину от текущей зарплаты. Жаль, изделия то очень хорошие (кроме себестоимости выше Китая) и мне за них не стыдно, я буду по ним ещё много статей писать. Более того наши изделия показывают стабильный рост продаж в полтора раза в год уже пять лет подряд несмотря на кризис и тд. Вот так вот вышло.28 августа 2016 в 21:07
0↑
↓
У вас-то частный случай, связанный с проблемой иного плана — как найти работу инженеру при стагнации экономики и без эмиграции в другую страну.28 августа 2016 в 21:12
0↑
↓
извиняюсь. забыл добавить главное:
для пунктов 1–3 во всех этих случаях нужен не только фулстек разработчик от прошивок до платы, перечня компонентов и технологии,а ещё чтоб он внедрил это в производство, а нередко и организовал закупку компонентов и оптимизировал себестоимость и обеспечил качество — инженер сопровождения и спец по тестирования/качеству. Для примера в нашей конторе в глубинке этим занимаются пятеро, и у всех з/п существенно выше чем они максимум могут заплатить за одного такого «оркестра».
28 августа 2016 в 22:08
0↑
↓
Снижение затрат и есть причина появления потребности в таких специалистах. Зачастую компаниям нужны люди, которые будут эффективно закрывать тикеты вроде «Добавить сортировку по полю Х» или «Добавить новый REST-поинт для выгрузки из таблицы Y». Особых знаний и умений для реализации такой функциональности не нужно, а платить хочется как можно меньше. А ведь такой работы на проектах очень и очень много (по крайней мере, на стадии поддержки). А профессионалы, которые выходят за грань описанного крайне и крайне редки.
28 августа 2016 в 20:01
0↑
↓
Это тоже вполне ожидаемо, т.к. увеличивает взаимозаменяемость специалистов и устраняет одно звено коммуникации между разработкой FE и BE. Эффективнее, в общем.> Да, это требует колоссального количества познаний
Да не колоссального на самом деле. Фуллстэки ведь тоже имеют специализацию. Кто-то один фреймворк хорошо знает, кто-то другой.
28 августа 2016 в 19:50
–1↑
↓
По своему опыту, могу сказать, что те, кто себя иенуют фул-стек разработчиками, не имеют никакого представления о современных практиках разработки фронт-енда. Максимум, что они могут — это поработать со стилями и сделать что-то небольшое с помощью jQuery. В этом нет ничего плохого, просто при найме нужно учитывать эти реалии.28 августа 2016 в 19:53
–1↑
↓
И да, пардон за рекламу, именно для заполнения пропасти между говнокодером-jQuery-стом и взрослым разработчиком с современным тулчейном, я работаю над второй версией фреймворка Matreshka.js.28 августа 2016 в 21:42 (комментарий был изменён)
0↑
↓
Вышеназванное ничего общего с фуллстек не имеет. Судя по моему опыту, настоящих фуллстек инжереров очень очень мало, они такими стали не по приказу начальства, а по своей инициативе и ввиду возможно своей любознательности и задротства.
28 августа 2016 в 20:04
+1↑
↓
Специализация появилась не просто так, и именно благодаря специализации мы имеем такие технологии, о которых еще век назад даже фантасты не могли мечтать. Специалист всегда предпочтительнее неспециалиста в своей области. Единственное применение fullstack-разработчика я вижу в небольших проектах, где пары «на-все-руки-мастер» будет достаточно для создания продукта28 августа 2016 в 20:13 (комментарий был изменён)
0↑
↓
А почему fullstack разработчик не может быть специалистом? Чаще всего не смотря на свою fullstack-ость он будет разрабатывать не более одного компонента системы в единицу времени, что вполне позволяет ему совершенствовать навыки как во frontend так и в backend стеках.
В таком случае разработчик выступает не в роли «на-все-руки-мастер», а в качестве бекендера с хорошим знанием фронтенда и наоборот.28 августа 2016 в 20:17
0↑
↓
Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний, и предположить что опыт/знания в каждой области бесконечны, тогда очевидно, что профильный специалист будет иметь больше знаний/опыта чем fullstack, если рассматривать их именно в контексте разработки одного компонента системы.28 августа 2016 в 20:29 (комментарий был изменён)
0↑
↓
Такое можно было бы сказать о фундаментальных областях, таких как алгоритмы\проектирование, но никак не о том или ином стеке. В пример можно взять тот же frontend стек, технологии и подходы там сменяются достаточно быстро (от 6 мес. до года), что вполне позволяет не отставать от узких специалистов, если знаешь основы и периодически работаешь в этой области.28 августа 2016 в 20:39
0↑
↓
Но ведь и в каждой технологии/фреймворке существует много тонкостей. Можно копипастить примеры из документации, а можно знать где подводные камни и как их обойти.28 августа 2016 в 20:55
+1↑
↓
На эти тонкости натыкаются все, как узкие специалисты, как и фуллстек, и тем и тем приходится копаться в issue\гуглить\просматривать сообщества и блоги по используемой платформе. Фуллстеку это немного сложнее (из-за объемов информации), тут вы правы.Сам почти год назад переключился c BE на FE стек, адаптация заняла примерно 1–2 месяца, каких-то особых проблем не почувствовал. Сложности ожидаемо были не с тем, чтобы изучить очередной фреймворк\сборщик\транспайлер, а с фундаментальными вещами, такими как проектирование приложений.
28 августа 2016 в 21:22
0↑
↓
Возможно вы правы, мне сложно грамотно оценивать подобные вещи. У меня было несколько проектов, где я выступал в качестве fullstack-разработчика, и тем не менее я не отношу себя к этой категории. Одно дело «сделать когда надо», другое дело «чувствовать себя как рыба в воде».
28 августа 2016 в 21:49
0↑
↓
Специалисты «по фреймворкам» это очень ограниченный люди, я бы лучше взял в команду в общем плане толкового человека чем некого эксперта одного фреймворка. Фреймворки умирают и рождаются, и при этом желательно чтобы опыт оставался с тобой.Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний
Это не так, далеко не так. Люди обычно разно мотивированы, и кроме этого некоторые вообще случайные люди в своей професиии.28 августа 2016 в 22:39
0↑
↓
Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
28 августа 2016 в 20:54
0↑
↓
> Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний,
> и предположить что опыт/знания в каждой области бесконечны
Если бы к квалификации программистов применялись математические законы, то да. Но дело в том, что
а) два программиста никогда не получают одинаковое количество опыта/знаний за единицу времени
б) опыт и знания в каждой области всегда конечны и практически всегда различны.
Поэтому каждый специалист индивидуален, и на практике корреляции между опытом программиста в каком-то одном конкретном инструментарии и широтой его знаний других инструментов/технологий как бы и не прослеживается.28 августа 2016 в 21:19
0↑
↓
Я согласен, программисты бывают разные. Есть Fullstack-разработчики которые в каждой сфере знают больше чем профильный программист. С другой стороны я уверен, что всегда можно найти профильного программиста, который знает больше чем Fullstack в конкретной сфере.
28 августа 2016 в 21:08
0↑
↓
Что-то вы людей совсем уж за идиотов держите. Вся поверхность современного программирования, действительно, неохватная. Сотни платформ, тысячи языков программирования, сотни тысяч фреймворков. Но фуллстак — это не всё это вместе, а две-три платформы, столько же фреймворков и языков. Это можно выучить даже за время обучения в ВУЗе. А если в своё время поленился — потом само собой выйдет. Будет что-то тормозить, потекут абстракции — залезешь во внутренний слой стека, надо будет что-нибудь потестить — перейдёшь на внешний. И потом, свой собственный уровень стека за 5 лет ты изучишь досконально. А что потом? Программист, который перестаёт учиться, убивает программиста в себе. На мой взгляд, фулстек программист — это крайне естественное явление.28 августа 2016 в 21:17
0↑
↓
За те 5 лет, что Вы будете изучать 3 фреймворка, выйдут еще 33. Сколько времени нужно тратить, чтобы одинаково *глубоко* знать тонкости всех сфер? Вы думаете новые направления, такие как DevOps, например, появляются с потолка? Причина ведь в том, что кол-во и сложность решений постоянно растет и вам просто не хватит 24 часов в сутках, чтобы быть на острие лезвия в каждой сфере.28 августа 2016 в 22:21
0↑
↓
Попробуйте выбирать те технологии, которые проживут минимум пять лет, в таком случае вместе с их развитием вы будете развиваться и сами. Нет никакой необходимости знать все 100500 яваскирпт фреймворков. Как вы метко заметили, они выходят каждый месяц. Попытки изучить их всех — вот настоящая трата времени, гораздо полезнее будет изучить низлежащий по стеку фреймворк.
28 августа 2016 в 20:09
+5↑
↓
Foolstack-разработчик28 августа 2016 в 20:10
0↑
↓
«Почему, даже большие аутсорсинговые и продуктовые компании, хотят нанимать Fullstack и/или развивать своих сотрудников в этом направлении?».
Компаниям нужно иметь много качественного человеческого ресурса (HR — human resources, если кто забыл). Это актив который стоит конкретных денег, и приносит конкретные деньги.
Чем этот ресурс более однообразен, тем лучше. Full-stack программистов легко перебрасывать с проекта на проект. Легко нанимать (их много), легко увольнять (легко найти замену). Его можно купить у партнеров, его можно продать партнерам.
Т.е. это вопрос денег, ничего личного.
28 августа 2016 в 20:16
0↑
↓
Да, но если качество страдает, вопрос денег стоит еще острее28 августа 2016 в 20:28
0↑
↓
Видимо не достаточно страдает, что бы отказатсья от этой идеи.
Но вообще тут взаимное движение. Т.е. с одной стороны прогеров подгоняют под full-stack, с другой стороны языки и технологии тоже подгоняют под full-stack, ну и задачи само собой. В основном сейчас люди занимаются разного уровня интеграциями, а не разработкой там каких-то новых вещей.
Не считаю что это правильно, потому что как раз интеграцию-то можно автоматизировать. А вот разработку нового нельзя.
Но тут решают не программисты, а деньги
28 августа 2016 в 21:26
0↑
↓
А вот я не пойму, откуда такая озабоченность неудовлетворённостью потребностей рынка? Что-ли вы его убить хотите:-)28 августа 2016 в 22:20
+1↑
↓
Последствия общения с HR)
28 августа 2016 в 21:33 (комментарий был изменён)
0↑
↓
Но, по-прежнему считаю, что толковый специалист их конкретной области, сделает все быстрее и лучше, чем специалист широкого профиля.
Фуллстек не тратит дополнительное времени на коммуникацию, тк работает один, он привык видеть всю картину и менее зависеть от прогресса коллег. Допустим если нужно сделать фичу быстро (первую версию, скажем пилот, а дальше если нормально пойдет вся команда подключится), то фуллстек в человекочасах сделает гораздо быстрее (раза в 2 минимум быстрее) и без особого ущерба качеству чем команда из ускоспециализированных специалистов.28 августа 2016 в 21:34 (комментарий был изменён)
0↑
↓
Или вовсе сделает совсем не то, экономия на коммуникации она такая. Если это не research задача, то команда из нескольких человек намного быстрее найдет все подводные камни в тз.28 августа 2016 в 21:38 (комментарий был изменён)
+1↑
↓
Человек которому доверяют работать индивидуально как правило заслужил такую репутацию, и как правило перед тем как приступить к задаче он задает все нужные вопросы по имеющися требованиям плюс интересуетя перспективой проекта чтобы предвидеть потенциально узкие места.28 августа 2016 в 21:54 (комментарий был изменён)
0↑
↓
Вопросы задают все, но правильные вопросы обычно появляются во время командного обсуждения или прямо во время выполнения задачи.
Получается два варианта:
1) фуллстек действует строго по тз, результат — «я его слепила из того что было»
2) фуллстек задает много уточняющх\корректирующих тз вопросов постановщику задачи, результат — отсутствие экономии времениКак альтернатива этому — коллективное обсуждение, в процессе которого каждый разработчик сможет более глубоко взглянуть на свою часть задачи и задать более правильные вопросы еще до начала её выполнения.
28 августа 2016 в 21:59 (комментарий был изменён)
0↑
↓
Вы не поняли смысла, фуллстек товарищ способен и задает все нужные вопросы самостоятельно, не отвлекая узких специалистов, и обычно досточно задачть все вопросы на начальном этапе разработки фичи. Кроме этого в процессе выполнения он не отвлекает узких специалстов вопросами вида «а где там и как и откуда, какой там формат API и тд», а просто делает результат. Но если честно это не значит что фуллстек всегда будет так действовать (некоторые все же предпочитают фокусировать в бэкенде или фронте, ресерче, тимлидстве и тд), но в момент необходимости его навыки и способности могут быть очень полезны для команда/компании.28 августа 2016 в 22:13 (комментарий был изменён)
0↑
↓
Вполне понял, дело в том, что даже при командной работе совсем непросто выяснить ответы следующие вопросы:
— что мы делаем?
— для чего мы это делаем?
—, а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.
28 августа 2016 в 22:19 (комментарий был изменён)
0↑
↓
Речь ведь была о том чтобы запилить фичу, разумеется стратегические решения в одиночку не принимаются, хотя зависит от состава команды (иногда просто никто не хочет или не способен учавствовать в процесс принятий решений кроме одного-двух человек). Смысл фуллстека в моем понимании проявляется когда нужно сделать что-то быстро и без особого ущерба качеству, такое нужно не всегда если конечно это допустим не конвеерная разработка прототипов. Также в целом приятнее общаться с фуллстеком видя что он или уже знает о чем идет речь или схватывает все на лету, общая техническая эрудиция на высоком уровне.PS предоплагает что когда фуллстек берется сделать что-то «быстро» и относительно качественно, то все вопросы (очень общие вопросы) указанные выше уже решены, дело перешло к конкретике.