Даже если процесс разделения начнется. Компаниям понадобится 3-5 лет. Не говоря о том что датацентры aws уже локализованны. Выбираешь регион Европа и вуаля. Данные хранятся в Европе в местных датацентрах. А все критические вещи (госуха военка) и так уже локализованы в местных компаниях с сертификацией.
Они стартовали 20 лет назад в совершенно другую эпоху. Давайте возьмём единорогов за последние лет 5-10.
Также не понятно что за огромное количество продуктов у openai? У них ровно 1 основной продукт - chatgpt.
Сравнивать множество моделей опенаи можно с гуглом который множество алгоритмов поиска использовал и не только алгоритмов непосредственно поиска но и хранения и процессинга и изобрел фактически бигдату и современный распределённый процессинг (заложил много первых кирпичиков). Это тоже были огромные капиталовложения.
Они вкладываются в инновации и это нормально. Насчёт прибыльности это вопрос стратегии (инновировать или оптимизировать) и зависит от рынка и конкурентов. Пока что делают ставку на инновации вперед
Я так язык выучил. Смотрел сериалы в оригинале с субтитрами плюс читал статьи на английском и в какой-то момент понял что могу понимать язык без субтитров и переводчика и даже говорить что-то в ответ
А зубрежку ненавижу. Нормально осваивать и изучать слово или правило через выполнение упражнений чтобы разные ассоциативные нейронные связи вырабатывались. А зубрежку это юзлес :D
Скорее всего это не не очень легко, это просто нереально. Придется конкретные юзкейсы платежеспособных пользователей покрывать и накручивать автоматизацию поверх. Как разные букалки слотов календаря (Calendly) работают поверх гугл-календаря.
То что вы описываете с мохоркой кажется не везение и не раскрутка, а постоянный поиск возможностей и их тестирование. Собственно мне видится что вы правы что разработка 1%, маркетинг 10%, но вы ничего не написали про самое главное - саму работу над продуктом, над исследованием рынка, проверке гипотез и тп. Мне кажется там вполне 40% может скрываться.
То что вы описали это domain knowledge, а точнее та его часть которая связана с тем как должна работать конкретная система. Им может владеть кто угодно. У нас например архитекты и продакты ей почти не владеют, а программисты наоборот. С другой стороны то что вы описываете можно записать в документации и этим будет владеть кто угодно и можно топов и продактов тоже на аутсорс отдавать. Так что получается вообще нет незаменимых сотрудников.
Топов я несколько раз видел как меняли как перчатки и не происходило ровным счётом ничего...
Но при этом вы правы что 1 единственный программист не является незаменимым.
Вообще глобально я гораздо чаще видел что именно уход программистов наиболее критичен для того чтобы куски системы продолжали работать и не создавать проблем. Также как они были ключевыми в разработке чего-то нового без онбординга новой команды который бы длился 6-12 месяцев.
При этом инфраструктурные инженеры (типа опсов) точно также зачастую критичны.
Я думаю автора текста интересует какой процент уволенных относился к высококвалифицированным кадрам (а точнее конкретно к разработке, ТК его интересует именно это) а не к скажем уборщикам например
У вас получается что лидер это "тот кто вдохновляет и даёт расти". Но это больше похоже на преподавателя или няньку.
Почему-то мне кажется что лидер это совсем другое. Я себе могу легко представить лидера который вообще не даёт расти - просто потому что это не в скоупе решаемых задач. Обычно у него цель довести какой-то проект до конца в том числе за счёт отношения людей к лидеру (а не просто табличками в Эксель).
В общем, для начала бы определиться кто такой лидер вообще.
Профсоюз это не часть бизнеса. По крайней мере в германии - это примерно как программист Петя и программист Вася в компании Х решили организовать профсоюз, и теперь юридически компания (бизнес) вынужден учитывать пожелания или требования профсоюза. Они от бизнеса не зависят и не являются его частью ни фактически ни юридически.
Наверное есть и другие формы, когда это может быть частью бизнеса, но я про такие не слышал (кроме кейсов коррумпированного профсоюза).
Как раз в германии хороший кейс того что профсоюзы не ограничивают компанию в финансовых и производственных маневрах, если они обоснованы экономически. Как раз живу в германии и прошел уже через 2 сокращения, каждый раз изучая процесс с юридической стороны. 1 раз у нас был профсоюз.
Честно говоря насчет германии мне кажется тут даже слишком палку перегнули в сторону прав трудящихся. Я бы предпочел быть немного ближе к Швейцарии или хотябы ЮК (но все еще чтобы было очень далеко до США).
В этой логике нет проблем, также как и нет проблем с профсоюзом если это все действительно так. Профсоюз подобное согласует за пару дней.
Проблемы начинают возникать там когда корпорация с капиталом в несколько миллонов раз превосходящи капитал одного сотрудника и мощью сотен юристов и прочего персонала начинает злоупотреблять своим положением диктовать условия труда и увольнения. Экстримальные проявления этого можете посмотреть в условиях труда на фабриках в 19-20 веке, когда были 12-16 часовые смены, детский труд, всевозможные заболевания и травмы без компенсаций. Спасибо если не скажут построить дачу директору во внерабочее время под предлогом потери работы. Общество пришло к тому что работодателя нужно ограничивать.
В конце концов это нам как обществу решать какие правила игры принимать для работы компаний и предприятий в нашей стране. Люди с соц взглядами (которые преобладают на пост советском пространстве) склоняются к идеям социального государства и защищенности прав трудящихся и граждан. Современными примерами противоположного подхода могут быть США где вас могут держать на рабской визе и уволить одним днем без каких либо компенсаций, так и китай где распространены потогонки. В целом в РФ тоже распространены злоупотребления положением начальника как только вы выйдете из пузыря ИТшников. Переработки (неоплачиваемые) считаются нормой также как периодически ущемляется право на отпуск и неработу в выходные. Это при том что у нас еще относительно драконовское законодательство - даже это не всегда помогает.
А чем то что вы называете тимлидом отличает от техлида? я пока только 1 особенность заметил - ему нужны софтскилы чтобы общаться с бизнесом. Все остальное на 90+% подходит под описание техлида. Выходит тимлид это техлид с софтскилами и немного бизнес майндсетом? :)
По поводу клея - в англоязычной среде это делают часто staff инженеры. Етсь даже ряд статей про путь Staff engineer и прямо таки "being glue" от Tanya Reilly. Стафф инженеры при этом часто следуют архетипу "техлид". Так что опять же (из моего пузыря) похоже на описание техлида.
Под конец про общую ответственность за команду - это очень похоже на работу обычного технического менеджера.
И самый главный вопрос к вашим рассуждениям - а если команда кроссфункциональная. Допустим есть 1-2 бекендера, 1 QA, 1 ML и 1 DS researcher или скажем Front+UX+Back+QA - как тимлид будет взаимодействовать с частью команды, которая не является его прямой специализацией? например если он бывший бэк? точно также как менеджер не тимлид, верно? в чем тогда разница? или ваше понятие тимлид не применимо к таким командам?
Дак менеджер это и есть тимлид а тимлид это менеджер. В англоязычной среде его даже называют engineering manager.
Хотя вопрос того что вы подразумеваете под этим термином.
Возможно то что вы подразумеваете то что в статье описано как менеджер+техлид.
Это часто встречаемая комбинация которую часто называют тимлидом.
Также в статье отличный кейс приведен когда это перестает работать - как только команды кросфункциональные.
Вы вот себе тимлида у которого в команде рфонтендер бекендер дизайнер и датасаентист как представляете? Он от того что вы называете менеджер чем будет отличаться?
В менеджменте так не рассуждают обычно (По крайней мере в моем пузыре продуктовой разработки) .
Есть позиция, есть ожидания от человека на этой позиции. Если всех устраивает перформанс то всем ок. Перформанс редко зависит от языка и его знания. Гораздо больше влияют другие скиллы. По крайней мере в моем пузыре продуктовых бекендов на менеджд языках.
Также у вас есть стоимость найма. Тратить деньги на поиск идеального кандидата часто хуже чем нанять не идеального и он доучиться.
Также не верен тезис про то что всегда плохо человеку платить пока он учится. Часто ситуация такая что человек нужен ASAP и лучше нанять чела щас который 3 месяца будет учиться чем 3 месяца нанимать идеального.
Теория ограничений она про конвейерное производство. Применять его к инженерной и проектной (или продуктовой) работе не очень подходит. Я бы даже сказал пытаться натягивать сову на глобус можно но лучше сконцентрироваться на других подходах.
Но в разработке этот подход зато подходит для "конвейеров" данных (дата пайплайнов и цепочек вызовов апи, или цепочек шагов обработки запроса.) вот там для оптимизации это прям применимо непосредственно. Например нет смысла ускорять обработку запросов если ботлнек в базе. Все прям по теории ограничений.
Насчёт Европы и 2025 чушь написана.
Даже если процесс разделения начнется. Компаниям понадобится 3-5 лет. Не говоря о том что датацентры aws уже локализованны. Выбираешь регион Европа и вуаля. Данные хранятся в Европе в местных датацентрах. А все критические вещи (госуха военка) и так уже локализованы в местных компаниях с сертификацией.
Странно что столько апвойтов у такой статьи.
99.99% людей тоже не способны на создание нового. Почему-то до этого вас это не смущало
Сравнение с faang выглядит некорректным.
Они стартовали 20 лет назад в совершенно другую эпоху. Давайте возьмём единорогов за последние лет 5-10.
Также не понятно что за огромное количество продуктов у openai? У них ровно 1 основной продукт - chatgpt.
Сравнивать множество моделей опенаи можно с гуглом который множество алгоритмов поиска использовал и не только алгоритмов непосредственно поиска но и хранения и процессинга и изобрел фактически бигдату и современный распределённый процессинг (заложил много первых кирпичиков). Это тоже были огромные капиталовложения.
Они вкладываются в инновации и это нормально. Насчёт прибыльности это вопрос стратегии (инновировать или оптимизировать) и зависит от рынка и конкурентов. Пока что делают ставку на инновации вперед
Загружать можно через просмотр контента
Я так язык выучил. Смотрел сериалы в оригинале с субтитрами плюс читал статьи на английском и в какой-то момент понял что могу понимать язык без субтитров и переводчика и даже говорить что-то в ответ
А зубрежку ненавижу. Нормально осваивать и изучать слово или правило через выполнение упражнений чтобы разные ассоциативные нейронные связи вырабатывались. А зубрежку это юзлес :D
Скорее всего это не не очень легко, это просто нереально. Придется конкретные юзкейсы платежеспособных пользователей покрывать и накручивать автоматизацию поверх. Как разные букалки слотов календаря (Calendly) работают поверх гугл-календаря.
То что вы описываете с мохоркой кажется не везение и не раскрутка, а постоянный поиск возможностей и их тестирование. Собственно мне видится что вы правы что разработка 1%, маркетинг 10%, но вы ничего не написали про самое главное - саму работу над продуктом, над исследованием рынка, проверке гипотез и тп. Мне кажется там вполне 40% может скрываться.
Дак уже есть куча стартапов и продуктов которые пытаются заменить АИ. Так что мы видели не просто чатгпт а конкретных заменителей.
В теории у больших Корп есть больше ресурсов и экспертизы чем у стартапов, но большие клопы и гораздо неповоротливее.
В общем возможно но звучит сомнительно пока.
Но вообще отрицание это первая стадия на пути к принятию неизбежного :D
Мысль у вас верная но детали хромают.
То что вы описали это domain knowledge, а точнее та его часть которая связана с тем как должна работать конкретная система. Им может владеть кто угодно. У нас например архитекты и продакты ей почти не владеют, а программисты наоборот. С другой стороны то что вы описываете можно записать в документации и этим будет владеть кто угодно и можно топов и продактов тоже на аутсорс отдавать. Так что получается вообще нет незаменимых сотрудников.
Топов я несколько раз видел как меняли как перчатки и не происходило ровным счётом ничего...
Но при этом вы правы что 1 единственный программист не является незаменимым.
Вообще глобально я гораздо чаще видел что именно уход программистов наиболее критичен для того чтобы куски системы продолжали работать и не создавать проблем. Также как они были ключевыми в разработке чего-то нового без онбординга новой команды который бы длился 6-12 месяцев.
При этом инфраструктурные инженеры (типа опсов) точно также зачастую критичны.
Я думаю автора текста интересует какой процент уволенных относился к высококвалифицированным кадрам (а точнее конкретно к разработке, ТК его интересует именно это) а не к скажем уборщикам например
Нет. Кажется Вы просто обе взяли чатгпт с похожими промптами.
У вас получается что лидер это "тот кто вдохновляет и даёт расти". Но это больше похоже на преподавателя или няньку.
Почему-то мне кажется что лидер это совсем другое. Я себе могу легко представить лидера который вообще не даёт расти - просто потому что это не в скоупе решаемых задач. Обычно у него цель довести какой-то проект до конца в том числе за счёт отношения людей к лидеру (а не просто табличками в Эксель).
В общем, для начала бы определиться кто такой лидер вообще.
Профсоюз это не часть бизнеса. По крайней мере в германии - это примерно как программист Петя и программист Вася в компании Х решили организовать профсоюз, и теперь юридически компания (бизнес) вынужден учитывать пожелания или требования профсоюза. Они от бизнеса не зависят и не являются его частью ни фактически ни юридически.
Наверное есть и другие формы, когда это может быть частью бизнеса, но я про такие не слышал (кроме кейсов коррумпированного профсоюза).
Как раз в германии хороший кейс того что профсоюзы не ограничивают компанию в финансовых и производственных маневрах, если они обоснованы экономически. Как раз живу в германии и прошел уже через 2 сокращения, каждый раз изучая процесс с юридической стороны. 1 раз у нас был профсоюз.
Честно говоря насчет германии мне кажется тут даже слишком палку перегнули в сторону прав трудящихся. Я бы предпочел быть немного ближе к Швейцарии или хотябы ЮК (но все еще чтобы было очень далеко до США).
В этой логике нет проблем, также как и нет проблем с профсоюзом если это все действительно так. Профсоюз подобное согласует за пару дней.
Проблемы начинают возникать там когда корпорация с капиталом в несколько миллонов раз превосходящи капитал одного сотрудника и мощью сотен юристов и прочего персонала начинает злоупотреблять своим положением диктовать условия труда и увольнения. Экстримальные проявления этого можете посмотреть в условиях труда на фабриках в 19-20 веке, когда были 12-16 часовые смены, детский труд, всевозможные заболевания и травмы без компенсаций. Спасибо если не скажут построить дачу директору во внерабочее время под предлогом потери работы. Общество пришло к тому что работодателя нужно ограничивать.
В конце концов это нам как обществу решать какие правила игры принимать для работы компаний и предприятий в нашей стране. Люди с соц взглядами (которые преобладают на пост советском пространстве) склоняются к идеям социального государства и защищенности прав трудящихся и граждан. Современными примерами противоположного подхода могут быть США где вас могут держать на рабской визе и уволить одним днем без каких либо компенсаций, так и китай где распространены потогонки. В целом в РФ тоже распространены злоупотребления положением начальника как только вы выйдете из пузыря ИТшников. Переработки (неоплачиваемые) считаются нормой также как периодически ущемляется право на отпуск и неработу в выходные. Это при том что у нас еще относительно драконовское законодательство - даже это не всегда помогает.
А чем то что вы называете тимлидом отличает от техлида? я пока только 1 особенность заметил - ему нужны софтскилы чтобы общаться с бизнесом. Все остальное на 90+% подходит под описание техлида. Выходит тимлид это техлид с софтскилами и немного бизнес майндсетом? :)
По поводу клея - в англоязычной среде это делают часто staff инженеры. Етсь даже ряд статей про путь Staff engineer и прямо таки "being glue" от Tanya Reilly. Стафф инженеры при этом часто следуют архетипу "техлид". Так что опять же (из моего пузыря) похоже на описание техлида.
Под конец про общую ответственность за команду - это очень похоже на работу обычного технического менеджера.
И самый главный вопрос к вашим рассуждениям - а если команда кроссфункциональная. Допустим есть 1-2 бекендера, 1 QA, 1 ML и 1 DS researcher или скажем Front+UX+Back+QA - как тимлид будет взаимодействовать с частью команды, которая не является его прямой специализацией? например если он бывший бэк? точно также как менеджер не тимлид, верно? в чем тогда разница? или ваше понятие тимлид не применимо к таким командам?
Интересно послушать ваше мнение
То что вы называете тимлидом - в статье называется техлидом (ролью, не лычкой). У вас тимлид просто еще выполняет/совмещает роль техлида из статьи.
Дак менеджер это и есть тимлид а тимлид это менеджер. В англоязычной среде его даже называют engineering manager.
Хотя вопрос того что вы подразумеваете под этим термином.
Возможно то что вы подразумеваете то что в статье описано как менеджер+техлид.
Это часто встречаемая комбинация которую часто называют тимлидом.
Также в статье отличный кейс приведен когда это перестает работать - как только команды кросфункциональные.
Вы вот себе тимлида у которого в команде рфонтендер бекендер дизайнер и датасаентист как представляете? Он от того что вы называете менеджер чем будет отличаться?
В менеджменте так не рассуждают обычно (По крайней мере в моем пузыре продуктовой разработки) .
Есть позиция, есть ожидания от человека на этой позиции. Если всех устраивает перформанс то всем ок. Перформанс редко зависит от языка и его знания. Гораздо больше влияют другие скиллы. По крайней мере в моем пузыре продуктовых бекендов на менеджд языках.
Также у вас есть стоимость найма. Тратить деньги на поиск идеального кандидата часто хуже чем нанять не идеального и он доучиться.
Также не верен тезис про то что всегда плохо человеку платить пока он учится. Часто ситуация такая что человек нужен ASAP и лучше нанять чела щас который 3 месяца будет учиться чем 3 месяца нанимать идеального.
Теория ограничений она про конвейерное производство. Применять его к инженерной и проектной (или продуктовой) работе не очень подходит. Я бы даже сказал пытаться натягивать сову на глобус можно но лучше сконцентрироваться на других подходах.
Но в разработке этот подход зато подходит для "конвейеров" данных (дата пайплайнов и цепочек вызовов апи, или цепочек шагов обработки запроса.) вот там для оптимизации это прям применимо непосредственно. Например нет смысла ускорять обработку запросов если ботлнек в базе. Все прям по теории ограничений.
По-моему все очень понятно.
Надо продать рекламу вакансий в Корп блоге.
Генеришь бессмысленную стать непонятно о чем и вуаля. 5 минут работы и реклама продана.
Вы можете заметить что практически единственное что не было сгенерировано в статье это последняя часть про рекламу.
В остальном в статье обычная вода из сео статей
Это не минусы Котлин. Это вы просто не привыкли.