Я не думаю, что будут спасательные миссии — слишком далеко для нынешних технологий. Это примерно как во времена великих географических открытий скорее — смогут справиться сами, молодцы, нет — следующие ждут. Маск, помнится, вообще сразу говорит, что первые колонизаторы Марса пойдут на верную смерть.
Значительно проще было бы сделать компанию полного цикла — с врачами, учителями, строителями и прочим. Вопросы продовольствия тоже решать централизовано. Если заняться этим на уровне штата, при тех деньгах, что там вращаются — это не должно быть проблемой.
А по факту имеем отличный пример того, как интересно иногда работают рыночные механизмы — вроде и бабла куча, а простым людям жить совсем плохо, а входящим в 1% мирового населения по доходам — сносно.
Скорее рота спецназа. Но смысл в том, что эти люди решают другой спектр проблем, чем нужно выживальщикам. А лучше всего в этих проблемах разбираются их охранники и врачи, скорее всего. Так что вожаками будут именно кто-то из них, а Цукерберги станут не очень нужными в силу своих умений, приобретённых на месте основной занятости.
В комментарии Касперского: "… подчеркивают, что арестован Стоянов был как частное лицо и вменяемые ему действия не относятся к его работе в качестве топ-менеджера."
Ну и при чем тут дружба, понять сложно. Как раз было бы значительно лучше, если бы дружба с силовиками никогда не работала.
«Не пригодная к выживанию» форма жизни существует уже несколько миллионов лет. И только её существование может привести к появлению искусственной формы жизни.
При этом «смысл» в существовании вообще найти довольно сложно.
Typescript не убирает те возможности, которые даёт JS, а расширяет их. В некоторых случаях удобен интерфейс и статическая типизация, в другом динамическая. В одой команде большая часть людей работали с фронтендом многие годы, в другом куча людей с бекенда, которые JS знают, но без знакомых абстракций теряются. В одном проекте 20k строк, в другом 200k, в третьем 1M+.
И то, и другое не более, чем инструменты. А с точки зрения машины, удобнее всего минифицированный JS, поэтому его всё равно лучше процессить.
В целом же, нормальный программист должен быть знаком с разными подходами к программированию, и понимать когда-какой подход/инструмент лучше применим. Мне так кажется.
По моему опыту, переход на TS значительно улучшил качество архитектуры и уменьшил количество неявных проблем в коде. Поэтому для меня — оправдался.
Нюансы: изначально я бекенд разработчик, когда стал заниматься JS было лет 8 опыта на C#, Java и C++. Это может быть одна из причин, что мозгу значительно проще прицепиться к хорошо знакомым абстракциям.
С другой стороны, я чаще всего работаю в fullstack командах, где народ потихоньку осваивает FE после многолетнего опыта в BE. И в этом случае плюс огромный.
Ну и в целом, я встречаю совсем немного граблей. Так что, мне кажется, у вас в голове картина в разы более драматична, чем оно есть в реальности.
Моё субъективное мнение, что читеры имеют некоторые проблемы в реальной жизни/пониженную самооценку, и компенсируют это в игре. Для успешного человека это действительно странно, потому что с какого-то момента задача превзойти себя в том, что делаешь. А читы этому только помешают…
Вы работали в очень специфичных командах, по ходу. В нормальной команде специалист постоянно доказывает работой (кодом, консультацией товарищей и т.д.), что он профи, и после этого его зовут на совещания. И, что характерно, такие специалисты митинги по возможности пропускают, потому что иначе квалификация падает, и работать приходится 60+ часов в неделю.
Из личного опыта пустословов из нормальных команд очень быстро уходят.
Угу, и при подходе «одному надо уточнить» очень часто потом вся команда работает в оверхедах, потому что зачем их мнение спрашивать — ониж работать должны.
Плюс к тому люди, которые непосредственно выполняющие какую-то работу вполне могут дать очень дельные комментарии. В итоге, исходя из личного опыта ситуация «один уточняет — другие делают» работает в разы хуже, и для команды, и для клиента.
Возможно, мне просто не везло с уточняющими — поэтому у нас очень разное восприятие того, как лучше.
Судя по описанию — вы работали(те) в весьма странной компании. Какой IT бизнес может выдержать такую нагрузку левыми людьми, представить мягко говоря сложно.
Оно достаточно неплохо работает, если применяется с умом, плюс на слуху, и есть много людей, которым он знаком. Плюс куча инструментов, которые его поддерживают.
Скрам появился, потому что клиент часто не понимает, что ему надо. И в результате получает не то, что ему было надо/закрывал проект. Появился он не от хорошей жизни, и не как киллер фича, а как попытка дать ответ на вопрос «как максимально быстро дать клиенту посмотреть, что у нас получается, получить фитбек и внести коррективы». Плюс возможность частых релизов (раз в 1-2 недели).
Это не серебренная пуля, и она далеко не всегда подходит. К примеру, его сомнительно использовать для разработки ПО для ракеты или атомной станции, потому что там требования четко определены на старте и не будут меняться — в этом случае процесс будет скорее мешать. Точно также, в случае мейнтенанс команды скрам подходит плохо, потому что постоянно появляются высокоприоритетные таски, которые должны решаться ASAP. Скрам с его итерациями в этом случае подходит плохо.
Да, Скрам зарождаться начал в 1986 году, а манифест был написан в 2001. «Модная технология» выждала где-то в 3-8 раз больше времени — и исходя из наблюдений количество проектов на нём (и других гибких) только растёт, а вот классика управления (RUP) используется всё реже.
Скорее, мало кто понимает, что такое скрам. И все выхватывают то, что привлекает их.
А поскольку некоторые менеджеры изначально считают, что они главные — получается палочная система под лозунгом аджайла, на которую навешивают тайм трекинд с загрузкой 8/8.
На моём первом скрам-проекте был нанят внешний скрам-мастер. И первые полгода она чуть ли не палкой била менеджера (PO) во время каждого митинга, пока тот не отучился от привычки раздавать команды в стиле «шоб завтро булО!».
Я видел скрам на 2 долгих проектах. Отличный процесс, в котором когда надо ужимался скоуп для того, чтоб впихнуть технические стори, постоянно закрывался технический долг и даже сроки когда надо двигались.
Проблема не в процессе, а в очень небольшом количестве грамотных менеджеров. Да и разработчиков, которые постоянно думают не только о красивом решении проблемы, но и о потребностях бизнеса — очень немного.
Это не подводные камни методологии, а следствия особенностей разработки ПО, не понятных менеджерам, особенно привлеченным со стороны. Истина про «скупой платит дважды» зачастую очень сложна, поэтому часто прослеживается «а чего это вы время тратите на непонятную фигню — давайте лучше вот эту фичу прикрутим». При чём, чем дальше человек от разработки, тем чаще такая логика встречается.
И такая проблема встречается всегда, когда начинают трекать время и задавать вопросы.
При этом есть обратная сторона — если время совсем не трекать, и дать разработчикам делать всё, что их душе угодно — можно на выходе получить очень красивое с технологической стороны решение, которым никто не будет пользоваться. Обратная сторона не всегда случается, конечно же, потому что некоторые разработчики достаточно опытны, чтоб понимать потребности бизнеса. Но это та же история, что и с крутым менеджментом — всё просто и без проблем работает.
Мне кажется, тут проблема не в процессе, а в его непонимании (во-первых) и отсутствии эффективной коммуникации между разработчиками и менеджерами во-вторых.
Те же проблемы миграции между версиями фреймворков легко объясняются понятием Technical Debt, и тыканьем в статьи о том, как он управляется через призму Скрама. Также до менеджмента надо доносить, что есть технические стори — которые дают выигрыш в производительности в будущем.
Ну и строго говоря, скрам как процесс рассчитан как раз на гармоничное сосуществование менеджеров и разработчиков, когда одни могут эффективно доносить до других те проблемы, которые надо решить для жизнедеятельности проекта и со стороны разработки, и со стороны управления. А то, что описываете вы это попытка бездумно навязать только одну точку зрения в экстремальном виде, прикрываясь переходом на новый процесс.
При этом с одной стороны, менеджеры явно зарвались, а с другой стороны, во всей команде разработки не нашлось людей, которые смогли бы эффективно донести свою позицию до руководства. Что тоже странно.
Мы тут, конечно, посмеялись над КНДР. Но я что-то не припоминаю ни одной другой страны, где бы при населении в 25 миллионов человек, плохих природных условиях, слабому доступу к ресурсам и фактической изоляции от остального мира (по крайней мере, обмен технологиями весьма затруднён) — была бы своя космическая программа, развивалась атомная промышленность да ещё и планшеты делали.
Мне кажется, было бы интересно без постоянных усмешек посмотреть, что они делают. Потому что по ощущениям эти смешные ребята точно обгоняют нас, а возможно — и большинство других. Это в пересчёте ресурс/результат
А по факту имеем отличный пример того, как интересно иногда работают рыночные механизмы — вроде и бабла куча, а простым людям жить совсем плохо, а входящим в 1% мирового населения по доходам — сносно.
Не "жители Питера", а вы и — возможно — некоторые ваши друзья и знакомые.
А делается оно для обычных пользователей, для которых это сложно.
Ну и при чем тут дружба, понять сложно. Как раз было бы значительно лучше, если бы дружба с силовиками никогда не работала.
При этом «смысл» в существовании вообще найти довольно сложно.
И то, и другое не более, чем инструменты. А с точки зрения машины, удобнее всего минифицированный JS, поэтому его всё равно лучше процессить.
В целом же, нормальный программист должен быть знаком с разными подходами к программированию, и понимать когда-какой подход/инструмент лучше применим. Мне так кажется.
Нюансы: изначально я бекенд разработчик, когда стал заниматься JS было лет 8 опыта на C#, Java и C++. Это может быть одна из причин, что мозгу значительно проще прицепиться к хорошо знакомым абстракциям.
С другой стороны, я чаще всего работаю в fullstack командах, где народ потихоньку осваивает FE после многолетнего опыта в BE. И в этом случае плюс огромный.
Ну и в целом, я встречаю совсем немного граблей. Так что, мне кажется, у вас в голове картина в разы более драматична, чем оно есть в реальности.
Из личного опыта пустословов из нормальных команд очень быстро уходят.
Плюс к тому люди, которые непосредственно выполняющие какую-то работу вполне могут дать очень дельные комментарии. В итоге, исходя из личного опыта ситуация «один уточняет — другие делают» работает в разы хуже, и для команды, и для клиента.
Возможно, мне просто не везло с уточняющими — поэтому у нас очень разное восприятие того, как лучше.
Это не серебренная пуля, и она далеко не всегда подходит. К примеру, его сомнительно использовать для разработки ПО для ракеты или атомной станции, потому что там требования четко определены на старте и не будут меняться — в этом случае процесс будет скорее мешать. Точно также, в случае мейнтенанс команды скрам подходит плохо, потому что постоянно появляются высокоприоритетные таски, которые должны решаться ASAP. Скрам с его итерациями в этом случае подходит плохо.
Да, Скрам зарождаться начал в 1986 году, а манифест был написан в 2001. «Модная технология» выждала где-то в 3-8 раз больше времени — и исходя из наблюдений количество проектов на нём (и других гибких) только растёт, а вот классика управления (RUP) используется всё реже.
А поскольку некоторые менеджеры изначально считают, что они главные — получается палочная система под лозунгом аджайла, на которую навешивают тайм трекинд с загрузкой 8/8.
На моём первом скрам-проекте был нанят внешний скрам-мастер. И первые полгода она чуть ли не палкой била менеджера (PO) во время каждого митинга, пока тот не отучился от привычки раздавать команды в стиле «шоб завтро булО!».
Проблема не в процессе, а в очень небольшом количестве грамотных менеджеров. Да и разработчиков, которые постоянно думают не только о красивом решении проблемы, но и о потребностях бизнеса — очень немного.
И такая проблема встречается всегда, когда начинают трекать время и задавать вопросы.
При этом есть обратная сторона — если время совсем не трекать, и дать разработчикам делать всё, что их душе угодно — можно на выходе получить очень красивое с технологической стороны решение, которым никто не будет пользоваться. Обратная сторона не всегда случается, конечно же, потому что некоторые разработчики достаточно опытны, чтоб понимать потребности бизнеса. Но это та же история, что и с крутым менеджментом — всё просто и без проблем работает.
Те же проблемы миграции между версиями фреймворков легко объясняются понятием Technical Debt, и тыканьем в статьи о том, как он управляется через призму Скрама. Также до менеджмента надо доносить, что есть технические стори — которые дают выигрыш в производительности в будущем.
Ну и строго говоря, скрам как процесс рассчитан как раз на гармоничное сосуществование менеджеров и разработчиков, когда одни могут эффективно доносить до других те проблемы, которые надо решить для жизнедеятельности проекта и со стороны разработки, и со стороны управления. А то, что описываете вы это попытка бездумно навязать только одну точку зрения в экстремальном виде, прикрываясь переходом на новый процесс.
При этом с одной стороны, менеджеры явно зарвались, а с другой стороны, во всей команде разработки не нашлось людей, которые смогли бы эффективно донести свою позицию до руководства. Что тоже странно.
Мне кажется, было бы интересно без постоянных усмешек посмотреть, что они делают. Потому что по ощущениям эти смешные ребята точно обгоняют нас, а возможно — и большинство других. Это в пересчёте ресурс/результат