Аутсорсам, основной бизнес которых был -- такие мелкие доработки в рамках техподдержки соболезную и выводы в общем-то справедливые в статье.
Но если добавить реального контекста, то получается: "Я -- бывший сисадмин с техническим образованием. Раньше я платил за мелкие задачи по разработке фриласерам и мелким агентствам. Теперь делаю сам с клодом"
Ну и ладно бы просто темы про бэкграунд просто не было в статье, но там написана просто неправда:
я же не технарь
А гугл говорит:
Образование · Вуз: ТНУ им. В. И. Вернадского '14. Факультет математики и информатики. Кафедра прикладной математики. Очное отделение. Выпускник (магистр) https://vk.ru › paul.molyanov
Через полгода скитаний я устроился сисадмином на госслужбу
Сейчас в любом аутсорсе, что в разработке, как в примере в статье, что в вашем бизнесе по производству контента одна и та же тенденция. То, ради чего раньше привлекали фрилансеров или агентства с невысокой квалификацией на мелкие разовые работы сейчас многие заказчики стали делать сами.
В разработке это боты и микроправки в сайтах на вордпрессе, в вашей сфере контента - это например SMM для заказчиков, которым не нужен прорыв, а нужно просто обозначить в интернете, что они живы и работают
Если бы SpaceX организовывался на долгосрочную перспективу, они бы позаботились о том, чтобы не развалиться при возможном уходе гендира, на котором всё сконцентрировано
Разве это не странно - утверждать, что компания, которой 23 года и в которой всё крутится вокруг одного человека строится на более долгосрочную перспективу, чем компания, которая уже существует 110 лет?
Даже если согласиться с тезисом, что у Боинга сидят барыги в руководстве в рамках указанного вами срока, превосходство SpaceX точно не означает абсолютно ничего в плане того, как у них строится управление
Чем еще можно это объяснить:
разницей в возрасте компаний (110 лет против 23х лет), а как следствие разница в целеполагании (сохранить текущие позиции на нескольких рынках против лидерства в одном рынке), подходах к инновациям и управлению в целом
моделью принятия решений (коллегиальные органы против высокой концентрации власти и решений на личности гения основателя и одновременно гендира)
определенными ключевыми сотрудниками с уникальной экспертизой и навыками
уровнем риска - одно из направлений бизнеса для Боинга ("ну разрабатываем потихоньку, чё спешить-то? Сделаем всё качественно, если не успеем - всё равно перекроем бабками от авиации") против режима "сдохни или умри" для SpaceX, например там был момент, что если бы ракета не взлетела, то это бы означало смерть компании
и другой кучей факторов, как это всегда бывает с масштабными процессами
Так что ваш вывод о том, что успехи одной компании и неудачи другой означают, что в одной инженерное управление, а в другой - современный менеджмент (в плохом смысле слова) несостоятелен :)
Роняние капитализации личными выходками основателя и запускание 400 ракет разве автоматически означает, что управление идет через создание работающих систем, а не через финансы?
Это сравнение предельно наглядно демонстрирует разницу между современным менеджментом и инженерным управлением. Между современным подходом управления “через финансы” и через создание работающих систем. Между двумя типами руководства.
А где-то есть факты, подтверждающие, что одна из компаний управляется "через финансы", а другая "через создание работающих систем"?
Это не кодинг на вайтборде, а настоящий Kubernetes-кластер в настоящем облаке и возможность пользоваться любой доступной информацией: Гугл, свои наработки, дока.
Так что нагуглить быстренько или использовать свои наработки - окэй, а звонок другу, если "другом" для помощи по такой простой задаче будет разработчик, то толку от такого сотрудника будет не так много.
А если друг работает где-то в другом месте, то мы лучше друга наймем, который знает или умеет нагуглить:)
Леонид не HR, а руководитель DevOps юнита, он в начале статьи представился
А насчёт грейдов, то они уж точно не усложняют текущие задачи.
Они позволяют объективно сформулировать необходимые знания, навыки и ответственность, нужные на каждом уровне. Ну и от этого формируется понятная траектория развития сотрудника, а не просто "ну ты вроде норм работал, но не особо развился по ощущениям, потому без повышения в этот раз"
По всем бывшим сотрудникам, если только не было каких-то прям жестких эксцессов, я дам хорошую рекомендацию. Значит ли это что такие сотрудники соответствуют требованиям на новом месте?
Если человек проработал 10 лет до этого, но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
А вот затраты на испытательный в реалиях текущих зп девопс инженеров очень даже может ударить по бюджету, если учесть все косвенные затраты - ожидание ухода с другого места, раскочегаривание нового поиска и новое ожидание выхода. Это вам не стажёра искать
Аутсорсам, основной бизнес которых был -- такие мелкие доработки в рамках техподдержки соболезную и выводы в общем-то справедливые в статье.
Но если добавить реального контекста, то получается: "Я -- бывший сисадмин с техническим образованием. Раньше я платил за мелкие задачи по разработке фриласерам и мелким агентствам. Теперь делаю сам с клодом"
Ну и ладно бы просто темы про бэкграунд просто не было в статье, но там написана просто неправда:
А гугл говорит:
Образование · Вуз: ТНУ им. В. И. Вернадского '14. Факультет математики и информатики. Кафедра прикладной математики. Очное отделение. Выпускник (магистр) https://vk.ru › paul.molyanov
https://vc.ru/life/299336-kak-kopiraiter-s-birzhi-otkryl-agentstvo-s-oborotom-30-millionov-v-god
Сейчас в любом аутсорсе, что в разработке, как в примере в статье, что в вашем бизнесе по производству контента одна и та же тенденция. То, ради чего раньше привлекали фрилансеров или агентства с невысокой квалификацией на мелкие разовые работы сейчас многие заказчики стали делать сами.
В разработке это боты и микроправки в сайтах на вордпрессе, в вашей сфере контента - это например SMM для заказчиков, которым не нужен прорыв, а нужно просто обозначить в интернете, что они живы и работают
А у вас есть источники, чтобы показать, что SpaceX организовывается на долгосрочную перспективу, что там инженерное управление, а не через финансы?)
Если бы SpaceX организовывался на долгосрочную перспективу, они бы позаботились о том, чтобы не развалиться при возможном уходе гендира, на котором всё сконцентрировано
Разве это не странно - утверждать, что компания, которой 23 года и в которой всё крутится вокруг одного человека строится на более долгосрочную перспективу, чем компания, которая уже существует 110 лет?
Даже если согласиться с тезисом, что у Боинга сидят барыги в руководстве в рамках указанного вами срока, превосходство SpaceX точно не означает абсолютно ничего в плане того, как у них строится управление
Чем еще можно это объяснить:
разницей в возрасте компаний (110 лет против 23х лет), а как следствие разница в целеполагании (сохранить текущие позиции на нескольких рынках против лидерства в одном рынке), подходах к инновациям и управлению в целом
моделью принятия решений (коллегиальные органы против высокой концентрации власти и решений на личности гения основателя и одновременно гендира)
определенными ключевыми сотрудниками с уникальной экспертизой и навыками
HR брендом - SpaceX притягивает личным брендом основателя и декларацией инновационности
уровнем риска - одно из направлений бизнеса для Боинга ("ну разрабатываем потихоньку, чё спешить-то? Сделаем всё качественно, если не успеем - всё равно перекроем бабками от авиации") против режима "сдохни или умри" для SpaceX, например там был момент, что если бы ракета не взлетела, то это бы означало смерть компании
и другой кучей факторов, как это всегда бывает с масштабными процессами
Так что ваш вывод о том, что успехи одной компании и неудачи другой означают, что в одной инженерное управление, а в другой - современный менеджмент (в плохом смысле слова) несостоятелен :)
Роняние капитализации личными выходками основателя и запускание 400 ракет разве автоматически означает, что управление идет через создание работающих систем, а не через финансы?
А где-то есть факты, подтверждающие, что одна из компаний управляется "через финансы", а другая "через создание работающих систем"?
На основе чего был выведен этот тезис?
Сопоставимость бюджетов не означает, что выводы, сделанные на примере частной компании можно перенести на страну
Не совпадение, а референс:)
Спасибо за внимательность, поправили
Каким образом хранение файлов в S3 уменьшает его отказоустойчивость?
Так говорите, как будто это что-то плохое...
А ведь уже есть разработчики, которые даже не слышали о том, что был когда-то какой-то флеш...
https://www.youtube.com/watch?v=2KtxSgS2u2g&ab_channel=KURUCHBRO
Надо будет передать эту информацию кому следует (Оле) :)
Абсолютно!
Цитата из статьи:
Так что нагуглить быстренько или использовать свои наработки - окэй, а звонок другу, если "другом" для помощи по такой простой задаче будет разработчик, то толку от такого сотрудника будет не так много.
А если друг работает где-то в другом месте, то мы лучше друга наймем, который знает или умеет нагуглить:)
Это сколько лет нужно чтобы столько писем нападало?)
Эх, сейчас бы в 2к24 килобайты экономить:)
Леонид не HR, а руководитель DevOps юнита, он в начале статьи представился
А насчёт грейдов, то они уж точно не усложняют текущие задачи.
Они позволяют объективно сформулировать необходимые знания, навыки и ответственность, нужные на каждом уровне. Ну и от этого формируется понятная траектория развития сотрудника, а не просто "ну ты вроде норм работал, но не особо развился по ощущениям, потому без повышения в этот раз"
Звучит здраво, однако есть нюанс
По всем бывшим сотрудникам, если только не было каких-то прям жестких эксцессов, я дам хорошую рекомендацию. Значит ли это что такие сотрудники соответствуют требованиям на новом месте?
Если человек проработал 10 лет до этого, но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
А вот затраты на испытательный в реалиях текущих зп девопс инженеров очень даже может ударить по бюджету, если учесть все косвенные затраты - ожидание ухода с другого места, раскочегаривание нового поиска и новое ожидание выхода. Это вам не стажёра искать