Size: a a a

Архитектура ИТ-решений

2020 June 05

AL

Alexander Luchkov in Архитектура ИТ-решений
Daria Kaftan
Сейчас на рынке ит нет проблем с гарантиями трудоустройства.
Ну... не уверен. В разных сегментах очень поразному сейчас. Джуны программисты всем разве нужны ?
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alexander Luchkov
Ну... не уверен. В разных сегментах очень поразному сейчас. Джуны программисты всем разве нужны ?
Всем нужны бойцы типа альфы спецназа, но денег на это нет
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Меняю одного мидла на двух джунов, с доплатой
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Бойцы никому не нужны. Всем нужен продукт, который можно продать) Желательно нахаляву)))
источник

CM

Cucumba Morozov in Архитектура ИТ-решений
Daria Kaftan
А почему?
Разорвал? Компания — один из наших заводов микроэлектроники. И зарплаты ниже, чем мне тогда платили, и характер работы не тот, что мне интересен
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Нужно вводить трансферы, как в футболе.
Взял многообещающего джуна, сделал сеньором, продал за кучу денег.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alexander Luchkov
Бойцы никому не нужны. Всем нужен продукт, который можно продать) Желательно нахаляву)))
Вон вчера ж говорили, что на таких алжайл строится
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Phil Delgyado
Нужно вводить трансферы, как в футболе.
Взял многообещающего джуна, сделал сеньором, продал за кучу денег.
Кстати, тема
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я бы тогда только этим бы и занимался )
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Daria Kaftan
Вон вчера ж говорили, что на таких алжайл строится
Пусть строится, мне не жалко)
источник

CM

Cucumba Morozov in Архитектура ИТ-решений
С этой историей в ВУЗе и трудоустройством у нас много кто отвалился. Потому что договор подписывают люди, которые ещё не понимают, что им профессионально интересно. Ближе к делу уже понимают (или нет), а дальше уже понятно, как действовать

Но если вообще не знаешь, что делать с жизнью — хороший вариант, решения принимают за тебя
источник

F

Fagor in Архитектура ИТ-решений
Пока не попробуешь, не узнаешь. И работа - это работа. Я считаю нормальным что через пару месяцев человек заявляет - не вариант.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Stanislav Takt
Жень, ну не натягивается эта сова на глобус. В мире все уже по-другому. Для меня недавним открытием стало общение с русским инвестором в Долине, который сам лабает на Питоне  и Солидити.
У меня было общение с инвестором, который тоже хотел код писать вместо проф. команды разработчиков (нас, то есть). Чем все законочилось для нас - проекте перевили типа inhouse. Чем все закончилось для проекта - ничем. Он не вышел в прод. Так что то, что инвестор какой-то там что-то там пишет, вообще не показатель.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Phil Delgyado
Ну, что бы появилась общая  wiki на несколько команд - уже нужен архитектор.
Ну это не правда. Часто хватает и рук. отдела разработки или РП, который управляет этими командами. Идея о том, что надо обмениваться знаниями использовать для этого инструменты не является прераготивой архитектора. А вот выступить независимым арбитром в технических решений - вот это уже ближе к архитектору
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Daria Kaftan
Хороший конвейер в работоспособными юнитами - вещь рабочая же. Зачем обязательно делать команду условных "универсалов"? (которые на самом деле нифига не универсалы, но тем не менее)
Для большинства команд, которые пишут приложения уровня того же ЕГРН и  других enterprise ИС:
- сложно выстроить работоспособный конвеер (мне не встречалось). Стоимость решения задача на ui/be в зависмости от story может быть разной и это сразу будет приводить к сбоям в конвеере (либо одни простаивают, либо другие).  scrum, и особенно kanban, они про взаимопомощь и заменяемость.
- мотивация, десять лет писать на одном им том же spring может кому-то и интересно, но лично мне было бы скучно. Если рядом есть возможность помочь команде и изучить другое - почему бы и нет?
- отличие в разработке backend и frontend это какой-то миф. Единственное что может выстреливать - это верстка, ну тогда нужен в команде кто-то кто ее знает. И то, это прям редкие случаи, когда нельзя разобраться. Современная web разработка по паттернам ушла достаточно вперед от backend разработки и развивается гораздо стремительней (правда, я думаю, уже тоже стабилизируется)

Плюсы раздельных:
- использование сфокусированных на конкретных задач исполнителей (например, каждый микросервис закреплен за конкретным человеком) в краткосрочной перспективе позволяет достигать лучших результатов. В долгосрочной - нет, т.к. уход любого приведет к потере знаний. Грамотное жонглирование ресурсами силами тимлида может дать эффект.
- проще искать людей, т.к. fullstack специалисты встречаются на рынке реже.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Roman Tsirulnikov
“средненько но предсказуемо”
Кстати да, для бизнеса это часто важнее чем "вроде как быстро, но не предсказуемо". Потому как разработка для бизнеса это только часть конвеера. Плюс маркетинг, продажи и т.п.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Eugene Istomin
Ещё раз, Agile работает хорошо с людьми, у которых 15+ лет реального опыта.
Именно из него черпается "гибкость за три дня"
Вот, прям четко сформулировали. И за эти 15 лет можно уже и в fullstack вырасти, если жить в консервативном мире java
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Phil Delgyado
Охх, я повспоминаю свои ощущения от SAFe. Хотя про компании на 1000+ я не очень понимаю, при мне его натягивали на проект человек на 40, получалось плохо
5-6 команд. Для SAFe это мало. Тут лучше какой-нибудь более легковесный framework тип less или scrum of scrum
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Daria Kaftan
Вот не факт. Как обычно бывает с джунами: ты в него полтора года вкладываешься, а потом он говорит тебе "шпасибо" и уходит к конкурентам.
А вот это уже зависит от политики компании. Если она строит разработку на джунах потому что они получают 50, а мидлы 120, то да. Через полтора года этому джуну поднимают з.п. в 1.5 раза, а на рынке от стоит почему-то в два раза дороже.
А если компания целеноправленно растит своих кадров и дает им нормальные деньги по мере их роста, то в целом пришедшие в компанию как на первое место работы специалисты работают дольше.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Смена работы это тоже некий challenge, для которого нужен опыт. И если компания платит тебе среднерыночную з.п. твою, зачем ее менять? Это позиция многих. Я знаю компанию, в которой люди работают всю свою карьеру (это уже лет 10-15) и при этом еще и получают процентов на 30 ниже рынка. Причем некоторые из них могли бы получать и на 30% больше рынка в силу своих компетенций.
источник