На фоне большого количества статей и материалов о том, что фулстеки не нужны, фулстеки не существуют, фулстеки плохо, сложилось мнение о том, какими преимуществами обладает фулстек над узкими специалистами, и почему фулстеки нужны.
Хотел в начале статьи оставить список ссылок на другие статьи про фулстеков, но их что-то слишком много оказалось, поэтому извините. Я лишь хочу сказать, что материалов о том, почему фулстек хорошо и почему фулстек плохо, достаточно. И каждая из них правдива минимум на 50%.
Тут наверное личные эмоции и мысли, не претендующие на последнюю инстанцию.
Как я уже говорил, меня зовут Павел, скоро будет 7 лет, как я получаю деньги за программирование. И весь этот период я именовал себя в резюме, на собеседованиях и в прочих местах: Backend developer со знанием и умением во Frontend и DevOps. Так или иначе в профессиональной карьере чаще работал как бекендер на проектах, но никогда не боялся, ни фронта, ни опс. Поэтому гордо добавлял эти две сферы в своё описание. Правда с приходом в компанию Mad Devs и, поработав на одном из проектов с командой MadOps нашей, убрал из своего описания DevOps, потому что теперь я считаю, что совершенно в нём не разбираюсь. Всё в сравнении познаётся, как известно. Надеюсь когда-нибудь поработать с такими же фронтенд-специалистами, которые «уговорят» меня убрать приписку «фронтенд». Главное, не встретить бекендера, который заставит убрать бекенд из резюме, иначе вообще ничего не останется.
Самые частые аргументы специалистов, которые пишут и считают, что фулстек плохо, звучат так: Нет погружения ни в одну из сфер, Нельзя быть Senior Fullstack Developer, узкие специалисты высокого класса зарабатывают больше, чем сильные фулстеки и т.д. И знаете, я с ними согласен.
Последние несколько месяцев работаю над проектом Peklo Tool, в котором использую Ruby на бекенде, VueJS на фронте, и Go для реализации текстового генератора.
И я чувствую проблемы:
- чувствую, что вот этот код на Go можно написать лучше, и он будет работать быстрее или использовать меньше ресурсов системы;
- чувствую, что мой webpack конфиг можно настроить гораздо лучше, в нём сейчас много мусора;
- чувствую, что эту вёрстку можно сделать используя современные фичи CSS, SCSS, или взять PostCSS или другой экстенш;
- чувствую, что код на рельсах можно оптимизировать, чтобы меньше запросов в БД производилось, например;
- чувствую, что индексы нужно по-человечески в базе настроить;
- чувствую, что вот этот Dockerfile нужно переписать, чтобы слоёв меньше было (или больше);
- и так далее, так далее, так далее...
Я всё это чувствую. Более того, я очень хочу это всё сделать. И, когда появляется свободная минутка, частично решаю хотя бы одну из этих проблем.
Вы спросите меня: а почему сразу в этом месте не заиспользуешь штуку N, чтобы проблем таких не было?
А я отвечу: я не знаю штуку N, настолько хорошо, чтобы быстро её применить в проекте в определённом кейсе. Я только отниму время у разработки, — читай проблема: Нет полного погружения.
И я не совру, ведь проекту, на котором я сейчас работаю, нужны фичи. PekloTool — это профессиональная тулза для генерации кампаний контекстной рекламы. Тулза молодая, разработка ведётся чуть больше года, но в прод она вышла полноценно пару месяцев назад только. В итоге, сейчас мы делаем все полезные для подобного продукта фичи.
Откуда я знаю, что нужны фичи и что фичи полезные будут? Очень просто, потому что я фулстек. Я вижу проект целиком. Я вижу цели проекта, вижу как он работает, вижу его косяки не только технические, о которых писал выше, а косяки, которые пользователям будут видны.
И тут мы подходим к главной мысли этой статьи: я считаю, что современный фулстек должен быть не просто кодером, который умеет в бекенд, фронтенд или ещё что-то. Фулстек — это тот, кто участвует в развитии проекта. Кроме компетенций по бекенду, фронтенду и т.д. фулстек должен обладать пониманием предметной области проекта, UX / UI знаниями и даже немного маркетингом. Фулстек должен знать, каким образом проект выполняет свою основную задачу: будь то зарабатывание денег или спасение мира. Фулстек должен быть на короткой ноге с «заказчиком» проекта. У любого проекта есть «заказчик», если аутсорс компания, это заказчик, в продуктовой компании — это стейкхолдер или продакт. «Заказчик» должен видеть в фулстеке того специалиста, с которым можно посоветоваться по всем вопросам по поводу проекта.
В хендбуке новичка Mad Devs (тот самый документ, который тебе дают почитать в первый день работы компании) есть пункт под названием: «Customer Affinity» (англ. — «Клиентская близость»). Суть термина я описал в предыдущем абзаце. Фулстек всегда должен надевать на себя шапку заказчика, идеальный вариант — это когда «заказчик» составляет задачи на спринт вместе с фулстеком. То есть фулстек понимает историю появления каждого таска, а не просто решает задачи, которые ему поставили. Я считаю, что если человек просто делает таски и его работа на этом заканчивается, даже если он делает бекенд, фронтенд, мобилку и т.д., это не фулстек. Это просто бекендер, который умеет во фронтенд, или наоборот.
Вот я всё это пишу, и у читателя могут возникнуть две мысли:
- какой бред. Тут каждому своё. Если вы так думаете, скорее всего вы узкий специалист, тогда ваше мнение понятно. Но, если вы фулстек, я вас «обрадую». Вы теряете огромный пласт полезной деятельности, которая принесёт пользу вашему проекту, а также теряете возможность приобретения важных компетенций, которые могут определить дальнейшее развитие вашей карьеры;
- это что фулстек на продакт-оунера должен быть похож? Да вы правы. За исключением пары моментов: продакт-оунер часто бывает и тимлидом всей команды проекта. Лидерские качества я приписывать фулстеку не буду. Это про другое. Ну и продакт-оунер должен уметь считать стоимость разработки проекта, фулстек не обязан думать о финансах, которые относятся к разработке. С его позиции деньги на разработку уже есть. Он, конечно, может предлагать варианты по удешевлению разработки, но только в процентом или качественном выражении, не в количественном. Может быть ещё пару моментов я каких-то упускаю, что должен уметь продакт, но мне можно, я ж фулстек.
Есть ещё одна сторона медали, которую хочется описать. Это грусть. Проблема фулстеков ещё и в том, что они перегружены. Это очевидно. Как правило, мы делаем очень объёмные задачи, комплексные фичи. У нас есть ещё общение с заказчиком, чтобы придумывать фичи и задачи, о которых я писал выше. Плюс, когда ты видишь проект целиком с технической точки зрения, ты чаще работаешь над инфраструктурой, архитектурой и прочими вещами. Чем больше информации, тем больше идей, а чем больше идей, тем больше шанс, что они воплотятся в жизнь. В итоге, ты чаще задумываешься: а может NoSQL БД, а может GraphQL, а может ещё что-нибудь. Вот тут занятость и появляется сама собой. Я не говорю о том, что сразу бегу всё переносить на условный GraphQL, но некоторые идеи поменьше ты иногда сам принимаешь, и воплощаешь в жизнь. Короче, занят очень.
А хочется что? Хочется новую библиотеку попробовать, больше изучить конфиг Gitlab CI, покурить что-нибудь интересное и относительно новое для себя на фронте, например, Logux. А времени нет, ты ответственный за проект. Я не скажу, что эта грусть, прямо грустная грусть. В противовес этому я получаю большой кайф: от того, когда вижу положительные отзывы пользователей; когда они радостно пишут о фиче, из-за которой ты не спал пару дней; когда растёт количество пользователей.
В заключении выражу мысль о том, что у узких и широких специалистов есть свои, как преимущества для проекта, их карьеры, окружения, так и недостатки. Конкретные профессиональные, по моему мнению, преимущества и недостатки опишу в одном из следующих материалов, если конечно этот будет встречен тепло.
Я рад тому, что я фулстек, потому что это та работа, которая мне нравится, которую я не прочь поделать в выходные, и которой занимаюсь с удовольствием.
Комментарии (37)
YuryZakharov
01.04.2019 02:34Соглашусь с ganqqwerty, и от себя добавлю, что в современном аджайлнутом мире фуллстеки — это просто способ удешевления разработки. Насколько оправданный — отдельная тема, но такая точка зрения у бизнеса есть. И выжимают из них по полной, так, что действительно получается и качество по всему стеку среднее, и времени и сил смотреть по сторонам (да и вглубь) — нету.
eugene_bx
01.04.2019 10:33Фулстек плюс ещё devops и за счёт использования скрама, часть функций менеджера на себе тянет, вот и хорошая экономия.
ghrb
01.04.2019 04:51Работа в выходные оплачивается по ТК в двойном размере? Как относится семья к работе в выходные?
kalashnikovisme Автор
01.04.2019 10:38Мне кажется, это тема для отдельной статьи.Скажу вкратце:
* работаю в белую, но не по ТК
* у нас с женой есть много совместных проектов (речь не про работу), так что проблем с общением и времяпрепровождением нетghrb
01.04.2019 11:56Я просто ещё про один признак перегрузки — работа в выходные, плюс очень удобная для работодателя — бесплатная.
kalashnikovisme Автор
01.04.2019 16:40Переработка небесплатная, конечно. Все часы логируются в соответствии с договором.
Единственный недочёт перегрузки я описал в статье, других недочётов от перегрузки нет.
DarkGenius
01.04.2019 08:23Так что делать фуллстеку-то? Уходить в узкую область или продолжать развивать кругозор?
Vlad_IT
01.04.2019 09:56+1Надо взвешивать плюсы и минусы. ЗП у fullstack и узкого специалиста, плюс-минус равны, но узкому быстрее расти.
Я ушел с fullstack разработки во frontend, и знания fullstack'а мне очень помогают понимать весь процесс разработки, легко читать серверный код, чтобы лучше понимать его поведение на мои запросы, иногда могу что-то дописать (но по этическим соображениям стараюсь этого не делать, если под это выделены люди). Я стал меньше уставать, т.к. из-за того, что я лучше знаю свою область, мне приходится меньше штудировать документацию, ловить баги. Учиться приходится столько же, т.к. материала для изучения все равно очень много даже в узких областях. Но думаю, в этом нет необходимости, можно спокойно сосредоточится только на том, что необходимо в работе.
Надо понимать, что плюсов fullstack'а больше для работодателя, а не для вас лично. Нужно в первую очередь думать о себе, понимать, что нужно в вам, чтобы проще и эффективнее работать, также нужно выделять время на отдых и хобби, иначе если перегорите, потеряете очень много времени и сил на восстановление (если вообще восстановитесь).DarkGenius
01.04.2019 10:00Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор? Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит. Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.
Vlad_IT
01.04.2019 10:17Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор?
Можно просто сделать смещение в определенную сторону. Например, больше заниматься backend разработкой, а frontend по мелочи. Или заниматься frontend разработкой, а backend заменить на nodejs. Моя основная мысль, чтобы на работе использовать один стек, а дома в своих проектах можно заниматься чем хочется.
Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит.
Это сложная проблема. В жизни очень много чего интересного, чем мне хотелось бы заниматься, но времени и сил на все не хватает. Но нужно оценивать свои силы, чтобы потом не перегореть и не потерять интерес ко всему.
Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.
Я плавно переходил. Я не бросал fullstack разработку, просто сконцентрировал обучение на frontend, да и сейчас по мелочи пишу на питоне. Таким образом, у вас будет серьезный плюс над другими узкими разработчиками, например в frontend — вы будете понимать внутреннюю кухню бека, лучше понимать взаимодействие фронта и бека, легче будет общаться с backend'разработчиками, понимать их. Это отличный пункт в резюме.
т.е. я не говорю, что стоит бросить один стек, достаточно сконцентрировать свое внимание на определенном, а также поменять специализацию с фуллстека на определенную. Выберите ту, которую лучше знаете, или которая больше нравится.
kalashnikovisme Автор
01.04.2019 16:44Думаю, если нравится фулстечить, нужно продолжать фулстечить. Я обещал не сравнивать узкие специализации и фулстек в этом материале. Но если обратиться к этой, здесь есть зависимость от личности ещё. Я не являюсь психологом, но точно знаю, что люди, которым нравится пытаться объять необъятное и те, которым нравится углубляться в одной сфере — это люди разного типа. И они кайфуют от разного.
titulusdesiderio
01.04.2019 09:09ТС, я категорически с вами не согласен. Фулстек это просто термин обозначающий компетенции во фронте (мобайле) и беке, а не философия. Но за то что так доходчиво и развёрнуто поделились своим видением — жирный плюс.
oldd
01.04.2019 13:32Из таких специалистов получаются классные менеджеры, которые понимают, что нужно заказчику и понимают, что, как и кому делать. Ценнейшие люди на небольших и быстрых проектах, и знание многих ЯП, методологий, архитектурных принципов просто необходимы.
Рекомендую прокачивать скилл ораторского искусства и уверенности, это поможет и время высвободить, и ЗП увеличитьkalashnikovisme Автор
01.04.2019 16:45Спасибо за комментарий. Скилл ораторского искусства и уверенности прокачен. Выступаю примерно 50 раз в год.
jakobz
01.04.2019 18:11Наиболее сложные вещи сейчас творятся вокруг API между фронтом и сервером. Фронту надо удобно и пачками таскать данные. Беку — делать это быстро. Фронту — просто, понятно, консистентно, менеджить стейт. Нужды фронта определяют дизайн API, а часто — вообще архитектуру всего бекенда.
Когда бек и фронт делают архитектуру сами по себе, получается полный треш и угар, в стиле «вот вам REST-API как в книжке, GET /users?id=123, живите как хотите». И фронт начинает делать распределенные join-ы данных из нескольких микросервисов, а бек — чинить возникшие от этого проблемы с перформансом.
Или все пытаются имплементнуть что-то дикое, что вообще бы техлид-фуллстек отговорил бы делать на этапе дизайна.
Или фронтам приходится закрывать архитектурные дыры бека, вроде «покажите какой-нибудь спиннер там пока наши микро-сервисы синхронизируются через очередь», или «если сервис А лежит, а Б — нет, должно как-то там все работать».
Короче фулл-стеки нужны как минимум, чтобы тех-лидить веб-проекты. Тех лид на веб-проекте без фулл-стека — это какое-то дно, непонятно как вообще оно может работать.
fenix163
02.04.2019 02:57Соглашусь с titulusdesiderio и расширю ответ. Автор путает широту знаний и глубину. Если он знает только back, он backend'ер. Если front, то frontend'ер. Если он знает и то и то, то fullstack. Даже если он и то и то знает плохо, то это лишь означает, что он плохой fullstack. Это что касается широты. Что касается глубины — это стандартная градация junior, middle, senior. Автор пытается скрестить сеньора и тимлида, уровень знаний и уровень ответственности за отдел. Строго говоря это разные позиции. И заказчик (внутренний/внешний — не важно) в общем случае не может общаться с fullstack-разработчиком, потому что это обычный программист, пусть даже и сеньор, у которого не может быть функций управления отделом, управления загрузкой отдела и планирования. Максимум, что может быть это менторство. Автор описывает скорее неофициального тимлида, который стал таким из-за экономии на новом сотруднике или из-за того, что просто знал больше остальных сотрудников и захотел немного выделиться и больше участвовать в процессах управления. Но в целом fullstack != тому, кого описывает автор.
kalashnikovisme Автор
02.04.2019 03:02Мне кажется, вы прочитали материал невнимательно.
В статье точно есть цитата, что фулстекам не хватает глубины. А также есть мысль, что я не приписываю фулстеку лидерские качества (тимлидинг соответственно, думаю, это очевидно).
Ни о каких «отделах» в статье речи не идёт в принципе. Взаимодействия и отношения внутри отделов разработки — это отдельная тема. К этой статье отношения не имеет.
Вы два раза в своём комментарии упомянули, что я якобы имел ввиду, что фулстек — это тимлид. Поэтому во второй раз попрошу вас внимательно перечитать и обратить внимание, что тимлидерских качеств я фулстеку не придавал, а наоборот обращал внимание, что это про другое.
И так же, прошу обратить ваше внимание на начало моего материала, где явно дал понять, что это личное мнение, не претендующее на последнюю инстанцию.
megahertz
02.04.2019 08:32Однажды ты спросишь меня, что я люблю больше, frontend или backend. Я отвечу, что fullstack. Ты уйдешь, так и не узнав, что я еще и под android умею, и под ios немного.
ganqqwerty
Мне кажется, что если у вас в проекте есть фуллстеки, то тут вероятно что-то из нижеперечисленного:
1) вы консалтинговая компания, которая быстренько прибегает (желательно по тендеру), говнокодит и убегает.
2) вы разрабатываете что-то очень простенькое, где вопросы ядреных оптимизаций не стоят.
3) ваши фуллстеки — это просто перегруженные работой бэки, взявшие на себя фронт, а тот, кто вас нанял, отлично экономит до поры. Либо они выгорят, либо они какие-то мутанты
4) ваши фуллстеки — это девелоперы, которые отлично понимают разницу между собственными интересами и интересами тех, кто их нанял. Они честно работают положенные часы, тратя их на изучение всего что нужно для фуллстеченья. В итоге проект двигается очень медленно или становится кривым, но так как мы не умеем отслеживать продуктивностью программистов, такие ребята могут устроить себе этакий оплачиваемый университет за два-три года.
eggstream
Есть еще вариант. В эпоху микро- и наносервисов часто возникает ситуация, когда фронт, бэк и овнер — одно лицо, потому что больше нет смысла. Я пришел во фуллстек из фронта. Создать простенький бэк для общения с остальными сервисами на основе современного фреймворка — не особая проблема, большая часть проекта — привычный мне фронт
JustDont
Я работаю примерно в такой же парадигме, но вот называть себя фуллстек-программистом мне совсем не хочется, потому что де-факто 90+% времени работа идёт над фронтом. Могу ли я бек поковырять? Да конечно могу, но это не фуллстек. Фуллстек будет тогда, когда вы бизнес-критичный функционал будете реализовывать везде (и на фронте, и на беке), а задачи уровня «написать хендлеров express, чтоб у фронта был чистый единый бек, после которого оно уже расходится в разные стороны» — это по силам любому вменяемому программисту, не страдающего пуризмом в извращённой форме («если это не в браузере, то делать не буду»).
eggstream
Так фишка именно в том, что бизнес-логика как раз и реализована на бэке, а на фронте только максимально удобный UI для неё. И как бы пафосно это не звучало, но хороший программист может писать код на любом человеческом языке программирования (не считая, может быть, марсианских чисто функциональных языков и диалектов брейнфака) и вынос кода с фронта на бэк должен быть если не тривиальной, то, по крайней мере, решаемой задачей. Подход с бизнес-логикой на фронте, когда для бэка остается роль тонкой прокладки для роутинга и синхронизации с другими сервисами, мне совершенно не нравится — получаются какие-то совершенно неповоротливые монстры. Вот и выходит где-то 60% работы на бэке, 35% на фронте и 5% DevOps (минимум для разворачивания собственного окружения и как черновик для прода)
JustDont
Мне кажется, что вы просто моё «бизнес-критичный функционал» не так прочитали. Это как раз всё то, что продаёт продукт — вплоть до дизайна (если речь про сайты для широкой публики). Понятно, что без всего остального один только дизайн никому не нужен, но и очередной фейсбук никому не будет нужен, если с ним можно общаться только через JSON. И в этом смысле практически всегда будет и бизнес-критичный функционал на фронте, и на беке, и может быть и еще где-нибудь.
ЗЫ: Я очень не люблю словосочетания «бизнес-логика», потому что под это что только не подписывают. Никогда не видели, как делающий кнопочки фронтэндщик рассуждает, что переключение стилей нажимаемых кнопок — это у него «бизнес-логика»? А я видел.
eggstream
Я много чего видел и слышал. И отнесение изменения состояния интерфейса к бизнес-логике, и обзывание роутинга на сервере фронтендом (или даже фронтендом бэкенда или бэкендом фронтенда), и то, как три строчки размытых хотелок называют ТЗ.
Моё мнение, что любой сервис должен быть в первую очередь доступен и полностью работоспособен через API, во вторую — иметь доступ к этому API через максимально простой интерфейс, и только на третьем месте — свистелки, метеоризм и прочий реакт с вебпаком, как бы ни странно это звучало от человека, чьим основным хлебом очень долго был фронт.
JustDont
Чрезмерные обобщения до добра вас никогда не доведут. Не любой.
Широкому слою общепубличных вещей «простой интерфейс» к API вообще нафиг не сдался, и может спокойно полностью отсутствовать.
Для вещей, где важна именно клиентская логика работы — да тот же гугльдокс — бекэнд будет в многие разы проще фронтэнда. Он конечно всё равно нужен, но соль совершенно не в нём.
amakhrov
В большинстве приложений не стоят вопросы ядреных оптимизаций.
И даже в оставшемся меньшинстве ядреные оптимизации нужны, как правило, только для небольшого подмножества задач.
Так что ваш пункт 2 покрывает довольно-таки большой спектр работ )
Либо стоит уточнить, что вы называете ядреными оптимизациями.
arheops
В обычной жизни СРАЗУ надо минимальная оптимизация или полное ее отсутствие.
Переоптимизация — типичная ошибка джунов.
ukko
Насколько большие проекты вы разрабатываете? RPS?
Я веду к тому, что совсем без оптимизации нельзя. Как минимум индексы должны быть проставлены корректно
arheops
Да 90% сайтов работает вообще без индексов. Или со стандартными индексами как Wordpress
Если у вас наблюдаются тормоза в базе и вы не в курсе про индексы, то платится за 2-3 часа *DB expert и он вам ставит индексы.
Более того, я постоянно вижу высоконагруженные системы, в которых не только индексов нет, но и на 128Gb RAM сервере mysql использует конфиг по умолчанию и выделяет себе 2гб. Ничего, работает все. Просто ставят быстрые SSD и куча процессоров.
Оптимизация имеет смысл, когда у вас уже есть пользователи. На старте более важно, чтоб работало хоть как-то.
Я разрабатываю разные проекты, у меня вторая специализация mysql. Но по факту эти оптимизации не везде нужны, мягко говоря. Современное железо нереально круто. Даже full-scan по таблице в 2млн выполняется секунды.
ukko
Ок, понял свою ошибку…
Индексы — слишком надуманный пример.
Пусть будет пример с циклом в цикле в котором идёт обращением к БД.
На нормальном ревью, коллеги должны отклонить такой запрос. Ведь даже, несмотря на знаменитое высказывание кнута о преждевременной оптимизации, допускать такое в коде — просто небрежность.
kalashnikovisme Автор
Про использование запросов в цикле — это, конечно, жесть. Речь всё-таки о менее тяжких преступлениях: о 3-4 запросах, которые идут по порядку, хотя можно было в один, об использовании ORM в тот момент, когда можно без неё обойтись, просто с ней быстрее и т.д.
arheops
У меня есть один проект, где запросы в цикле работают год уже.
Да, там можно соптимизировать. Да, я знаю как.
Но оптимизация будет стоить не меньше дня разработки, а неоптимизированный код кушает всего два ядра из 56, потому будет еще работать долго. Просто вынесен на отдельные ядра и все.
Я все же придерживаюсь позиции, что лучше иметь начальные знания у всех разработчиков, чем глубокие, но 10х размер команды.
Как минимум пока проект не приносит миллион в год.
Понятно, что если у вас 50-500 человек сидит в офисе, то выгоднее для всего кроме прототипов узкая специализация. Но в малых командах не все так очевидно.
kalashnikovisme Автор
Но, если даже в команде 50 человек есть тимлид или ведущий разработчик, который является тем самым фулстеком, что может быть полезен в любой части системы, как минимум на уровне общения и принятия решений — это безусловно плюс.
Работал в такой команде. Был кайфово, что есть хотя бы, кто всё знает.
titulusdesiderio
5) фулстеки-одиночки задействованы на MVP. В одно лицо гораздо проще быстрее и дешевле сделать MVP. Да, БД будет не оптимизирована, вместо вёрстки бутстрап и прочие недостатки. НО без стендап митингов, согласований между командами, и прочего, MVP будет готов через неделю, а не месяц. А потом, если MVP «зайдёт» можно выделить фронтов с дизанеромам, беков с девопсами, аналитиков и запилить уже полноценный проект по этим вашим скрамам с аджайлами.
kalashnikovisme Автор
Здесь абсолютная верная мысль. Тут, конечно, появляется вопрос о том, как правильно делать MVP, но это другая тема.
kalashnikovisme Автор
Если честно, совсем не понял ваш четвёртый пункт. Вы имеете ввиду, что мы устраиваем себе оплачиваемый университет, изучая в нём предметную область, продакт-оунерство и т.д.?
ganqqwerty
Изучая в нем технологии бэка, фронта и девопс. Я лично очень за, да и работодателю обычно по боку, маржа все равно отличная, пусть лучше девелопер учится в день часика по три из восьми, чем будет недовольно эти же три часа сидеть в снэпчатиках.