Lost Vikings! Каждый герой со своей способностью и чтобы пройти надо переключаться между героями. С тех пор много такого вышло, но их помню как первых. Может еще раньше была такая механика?
Название уже не помню Drakan чтоли. RPG, где играть за девушку и летать на разных драконах модно было. Там была удивительная механика с отсечением. Можно было биться с мобом как в готике/ведьмаке и долго его ковырять, а можно было провести 'идеальный удар' и отсечь руку мобу, и тогда он через несколько секунд подыхал. Чтобы такое сделать надо наловчиться было, но и результат впечатлял. Большущий моб помирал с 1 удара вместо 10-15ти
Поддержу. Сам был частью поцесса миграции с 2х датаценторв в AWS. И деже те, кто это затеял говорили, что оно не будет дешевле в AWS, но будет сильно меньше геморроя с людьми.
Держать штат админов
Обновлять зоопарк операционок новыми версиями
Следить за сертификатами
Нанимать/уволтнять, добавлять тимлидов чтобы с сотней админов управится
Уметь настраивать 150 разных сервисов и обновлять их! 10 версий оракла, 4 mySQL, 2 версии Spark, и т.д.
Самое, на мой взгляд, главное в облаках ( о чем мы как инженеры мало задумываемся, а бизнес сильно) это нереально быстрое прототипирование и запуск новых решений.
Захотел поставить redis перед приложением - 5 кликов и готово, захотел БД на 3ТВ поставить, чтобы отчетность или бигдату погонять - 15-20 минут курения мануала и готово. Через месяц можно дропнуть если эксперимент не выгорит. И не надо держать парк специалистов под все.
Выше было хорошо сказано про человека-оркестр, котрый в крупные компании не нужен. Там нужна четкая шестеренка в конкретное место работающего механизма. Посоветую, можете не принимать во внимание, но если попробуете - интересно услышать отзыв.
Вместо одного резюме вида 'я умею вот все, возьмите меня на работу и найдите мне применение', сделать несколько с фокусом на конкретные направления.
В одном про С и все что Только с этой экосистемой связано, второе Java и т.д.
К примеру, резюме на системное программирование и С, резюме на ентерпрайз и java, резюме на web и php. Принцип вы поняли.
У аутстаффинга даже может быть та же зарплата, что и у продуктовой компании.
Это классический вин-вин. Смотрите
Представьте, что у вас идея, внедрить блокчейн/ии/любую модную вещь в продукт и есть гипотеза, что это будет выгодно. И вам для этого нужны специалисты. По классике, надо дофига денег, чтобы специалистов найти, устроить в штат, платить за них налоги (округлим как 0.75 от ЗП), следить за мотивацией, нанять руководителей. Вот наняли 5 человек. А гипотеза не сработала. Что тогда делать? Вот не нужны больше эти 5 специалистов. Вы же знаете наш КЗОТ - задолбаешься увольнять, тем более, что и не за что. Спецы хорошие, просто вектор продукта поменялся. Если сейчас их уволить- то это же дофига денег потратить. И тут аутстафф приходит и говорит - возьмите у нас людей. Вот их ставка (зп сотрудника плюс налоги что галера за него платит, плюс маржа), но зато если вам будут не нужны они, то вам не надо будет тратиться на рассчет, на HR, на то да се. Просто платите лишнюю копеечку и вас избавят от головной боли.
При таких отношениях и джуна под видом миддла не надо продавать.
Дв и черевато это. Буквально месяц назад отказались от 4х таких 'специалистов' и на взаимодействие с такой 'галерой' поставили крест.
С другой стороны, бывает что отношения и доверие с годами так растет, что эти отношения 'галера аутстафф' - 'продукт' вместе идеально работают. Галера, доказавшая что она фуфло не поставляет, закрывает и найм и собеседования и архитектуру. И в идеале становится не аутстаффом, а придворным ИТ подразделением заказчика. Тогда всем хорошо. В галеру всегда идет прогнозируемый поток финансов. А заказчик экономит на своем ит отделе. (Это конечно риск отдавать компетенции на сторону), но где-то это оеально рабочая бизнес модель.
Справедливости ради добавлю еще один минус аутстаффа: карьерный потолок в том проекте, куда вас продали.
Даже если вы уже можете и архитектором быть и тех лидом - то заказчик с большей вероятностью будет на такие ответственные позиции ставить сотрудников из своего штата, чем из аутстаффа. Т.к это ппосто менее рисково.
Вот прям бомбануло с текста. С трудом удерживаюсь, чтобы конструктивно ответить вместо штампа 'автор не разбирается в вопросе'. Наверное был неудачный опыт с одной компанией и вылился в такой текст. С моего 'галерного' опыта - это скорее исключение.
У хорошей галеры все хорошо с мотивацией и удержанием - смотоите текучку люксофта/епама/accenture. Смотрите с точки зрения бизнеса.
Галере не выгодно тратиться на найм (никому не выгодно), так что, будут холить и лелеять как и в продуктовой компании. Если это не так - это повод посмотреть на себя объективно
Аутсорсу и аутстаффу выгодно продать спеца подороже. Если есть возможность сделать вас сеньером - сделают. Еще выгоднее джуна продать как сеньера, но это уже попахивает.
Галере выгодна унификация скиллов и грейдов, чтобы между проектами легко тасовать людей, стартовать новые и не попасть в ситуацию, когда Вася сеньер только за 10 лет на одном проекте и научился супер быстро json перекладывать. Потому много внимания ассессментам, скиллам, выравниванию ожиданий.
В идеале, у галеры так выстроены процессы, что есть куча инженеров и чуть-чуть административного персонала. Им не надо выжимать сотрудников, тратиттся на найм и т.д. их бизнес - люди!
В матерой галере и выбор проектов побольше, и бенч не вечный. И область развития спокойно меняется с сохранением зп и грейда. Вот нет там такого что middle java backend при переходе в bigdata и python станет джуном. Конечно до сеньерской позиции в новом техстеке придется работать дольше.
Очень жаль, что у автора такой негативный опыт. Мне кажется он не от 'галеры' вообще, а от компании, которая только встала на этот путь. И она еще не галера, а так ботик. До звания галеры надо еще дорасти.
По мне так в галерах куда меньше соков выжимают, чем в тех же ит подраздедениях банков.
Минусы галер? Для меня тодько один - ты делаешь не свой продукт. Иногда это обидно.
Ну нее, описанный процесс не может относиться к Большой компании. Разве что это очередной сервис, и до него уже 50 таких же сделано. Расскажите про то, что делается до и после описанных шагов? Подковерные войны где найти бюджет на проект ( разные отделы со своими целями), как заказать железо под проект и оплачивать его с костов проекта ( поддержка битбакета, доп агенты для тимсити, стенды разработки). Где документирование? В больших компаниях много стандартизировано, а в вашем процессе выглядит как небольшой проектик. Потому я ожидал, что расскажете что то, что ОТЛИЧАЕТ процесс в большой компании от средней. А сейчас вы описади типовой и хорошиц процесс. Ничего против него не имею.
В языках есть структура, и предложение на любом языке - по сути четко заполненный опросник фичи, которая потом реализуется в виде перевода.
Если будет такой опросник с четкими формтами для разработки и найдется такой клиент/аналитик, который его заполнит идеально - то да, верю, что ИИ по нему может сгенерировать корректную программу.
Так что всего лишь остается создать такой шаблон и научить его заполнять. Кто бы это делать должен? Так этим команда разработки и занимаются!
Lost Vikings! Каждый герой со своей способностью и чтобы пройти надо переключаться между героями. С тех пор много такого вышло, но их помню как первых. Может еще раньше была такая механика?
Название уже не помню Drakan чтоли. RPG, где играть за девушку и летать на разных драконах модно было. Там была удивительная механика с отсечением. Можно было биться с мобом как в готике/ведьмаке и долго его ковырять, а можно было провести 'идеальный удар' и отсечь руку мобу, и тогда он через несколько секунд подыхал. Чтобы такое сделать надо наловчиться было, но и результат впечатлял. Большущий моб помирал с 1 удара вместо 10-15ти
Поддержу. Сам был частью поцесса миграции с 2х датаценторв в AWS. И деже те, кто это затеял говорили, что оно не будет дешевле в AWS, но будет сильно меньше геморроя с людьми.
Держать штат админов
Обновлять зоопарк операционок новыми версиями
Следить за сертификатами
Нанимать/уволтнять, добавлять тимлидов чтобы с сотней админов управится
Уметь настраивать 150 разных сервисов и обновлять их! 10 версий оракла, 4 mySQL, 2 версии Spark, и т.д.
Самое, на мой взгляд, главное в облаках ( о чем мы как инженеры мало задумываемся, а бизнес сильно) это нереально быстрое прототипирование и запуск новых решений.
Захотел поставить redis перед приложением - 5 кликов и готово, захотел БД на 3ТВ поставить, чтобы отчетность или бигдату погонять - 15-20 минут курения мануала и готово. Через месяц можно дропнуть если эксперимент не выгорит. И не надо держать парк специалистов под все.
Выше было хорошо сказано про человека-оркестр, котрый в крупные компании не нужен. Там нужна четкая шестеренка в конкретное место работающего механизма. Посоветую, можете не принимать во внимание, но если попробуете - интересно услышать отзыв.
Вместо одного резюме вида 'я умею вот все, возьмите меня на работу и найдите мне применение', сделать несколько с фокусом на конкретные направления.
В одном про С и все что Только с этой экосистемой связано, второе Java и т.д.
К примеру, резюме на системное программирование и С, резюме на ентерпрайз и java, резюме на web и php. Принцип вы поняли.
У аутстаффинга даже может быть та же зарплата, что и у продуктовой компании.
Это классический вин-вин. Смотрите
Представьте, что у вас идея, внедрить блокчейн/ии/любую модную вещь в продукт и есть гипотеза, что это будет выгодно. И вам для этого нужны специалисты. По классике, надо дофига денег, чтобы специалистов найти, устроить в штат, платить за них налоги (округлим как 0.75 от ЗП), следить за мотивацией, нанять руководителей. Вот наняли 5 человек. А гипотеза не сработала. Что тогда делать? Вот не нужны больше эти 5 специалистов. Вы же знаете наш КЗОТ - задолбаешься увольнять, тем более, что и не за что. Спецы хорошие, просто вектор продукта поменялся. Если сейчас их уволить- то это же дофига денег потратить. И тут аутстафф приходит и говорит - возьмите у нас людей. Вот их ставка (зп сотрудника плюс налоги что галера за него платит, плюс маржа), но зато если вам будут не нужны они, то вам не надо будет тратиться на рассчет, на HR, на то да се. Просто платите лишнюю копеечку и вас избавят от головной боли.
При таких отношениях и джуна под видом миддла не надо продавать.
Дв и черевато это. Буквально месяц назад отказались от 4х таких 'специалистов' и на взаимодействие с такой 'галерой' поставили крест.
С другой стороны, бывает что отношения и доверие с годами так растет, что эти отношения 'галера аутстафф' - 'продукт' вместе идеально работают. Галера, доказавшая что она фуфло не поставляет, закрывает и найм и собеседования и архитектуру. И в идеале становится не аутстаффом, а придворным ИТ подразделением заказчика. Тогда всем хорошо. В галеру всегда идет прогнозируемый поток финансов. А заказчик экономит на своем ит отделе. (Это конечно риск отдавать компетенции на сторону), но где-то это оеально рабочая бизнес модель.
Справедливости ради добавлю еще один минус аутстаффа: карьерный потолок в том проекте, куда вас продали.
Даже если вы уже можете и архитектором быть и тех лидом - то заказчик с большей вероятностью будет на такие ответственные позиции ставить сотрудников из своего штата, чем из аутстаффа. Т.к это ппосто менее рисково.
Вот прям бомбануло с текста. С трудом удерживаюсь, чтобы конструктивно ответить вместо штампа 'автор не разбирается в вопросе'. Наверное был неудачный опыт с одной компанией и вылился в такой текст. С моего 'галерного' опыта - это скорее исключение.
У хорошей галеры все хорошо с мотивацией и удержанием - смотоите текучку люксофта/епама/accenture. Смотрите с точки зрения бизнеса.
Галере не выгодно тратиться на найм (никому не выгодно), так что, будут холить и лелеять как и в продуктовой компании. Если это не так - это повод посмотреть на себя объективно
Аутсорсу и аутстаффу выгодно продать спеца подороже. Если есть возможность сделать вас сеньером - сделают. Еще выгоднее джуна продать как сеньера, но это уже попахивает.
Галере выгодна унификация скиллов и грейдов, чтобы между проектами легко тасовать людей, стартовать новые и не попасть в ситуацию, когда Вася сеньер только за 10 лет на одном проекте и научился супер быстро json перекладывать. Потому много внимания ассессментам, скиллам, выравниванию ожиданий.
В идеале, у галеры так выстроены процессы, что есть куча инженеров и чуть-чуть административного персонала. Им не надо выжимать сотрудников, тратиттся на найм и т.д. их бизнес - люди!
В матерой галере и выбор проектов побольше, и бенч не вечный. И область развития спокойно меняется с сохранением зп и грейда. Вот нет там такого что middle java backend при переходе в bigdata и python станет джуном. Конечно до сеньерской позиции в новом техстеке придется работать дольше.
Очень жаль, что у автора такой негативный опыт. Мне кажется он не от 'галеры' вообще, а от компании, которая только встала на этот путь. И она еще не галера, а так ботик. До звания галеры надо еще дорасти.
По мне так в галерах куда меньше соков выжимают, чем в тех же ит подраздедениях банков.
Минусы галер? Для меня тодько один - ты делаешь не свой продукт. Иногда это обидно.
Ну нее, описанный процесс не может относиться к Большой компании. Разве что это очередной сервис, и до него уже 50 таких же сделано. Расскажите про то, что делается до и после описанных шагов? Подковерные войны где найти бюджет на проект ( разные отделы со своими целями), как заказать железо под проект и оплачивать его с костов проекта ( поддержка битбакета, доп агенты для тимсити, стенды разработки). Где документирование? В больших компаниях много стандартизировано, а в вашем процессе выглядит как небольшой проектик. Потому я ожидал, что расскажете что то, что ОТЛИЧАЕТ процесс в большой компании от средней. А сейчас вы описади типовой и хорошиц процесс. Ничего против него не имею.
В языках есть структура, и предложение на любом языке - по сути четко заполненный опросник фичи, которая потом реализуется в виде перевода.
Если будет такой опросник с четкими формтами для разработки и найдется такой клиент/аналитик, который его заполнит идеально - то да, верю, что ИИ по нему может сгенерировать корректную программу.
Так что всего лишь остается создать такой шаблон и научить его заполнять. Кто бы это делать должен? Так этим команда разработки и занимаются!