Вот именно, а не ультиматумы ставить "отдельная комната, проводной интернет и т. п." И работодателю, принимая решение о переходе на удалёнку, надо быть готовым к тому, что кто-то из сотрудников не захочет идти навстречу в таких вопросах или только за отдельную плату пойдёт, поскольку это существенное изменений условий сотрудничества и работник может не считать его вин-вин, а может счесть попыткой переложить проблемы работодателя на плечи работников.
Если возможно описать требования клиента до начала работ по собственно разработке продукта, то аджайл просто не нужен. Он для тех ситуаций, когда это невозможно, когда, например, заказчик хочет создать новую отрасль или взорвать существующую вопреки мнению экспертов "это так не работает" ) Аджайл он для продуктов, в которых предполагается постоянная проверка бизнес-гипотез с постоянной готовностью к "не взлетело — выкидываем и пробуем следующую"
"Составить требования заказчика" как-то дико для меня звучит. Почти как "Изя, у мужчины должно быть своё мнение и сейчас мама твоё тебе расскажет". ) Вы, наверное, про сбор требований и ограничений? Agile предполагает работу в условиях высокой неопределенности, когда полные требования просто невозможно собрать заранее, когда они меняются по ходу дела после получения обратной связи
Прочитать весь офсайт — не проблема? Почему вообще админ должен погружаться в нюансы биллинга, если в задаче этого явно не сказано? Переход на серверлесс или даже spot instances требует архитектурных изменений, близких к проектированию cloud native систем
Не всегда возможно на сегодня даже голосом общаться через сеть — это нужно учитывать и принимать решение то ли увольнять людей, то ли обеспечивать их старлинками, то ли делать для них исключения из общих правил.
А сможет ли он без опыта сравнить адекватно? Посчитает, например, стоимость EC2 инстансов плюс-минус аналогичных имеющимся, укажет в минусах сложность доступа (роли и вот это вот всё), в плюсах автоматическое поднятие при аварии и всё. Но забудет (если это слово уместно) про стоимость трафика, публичных IP/LB и прочего, просто потому что не привык, что надо за каждый чих платить отдельно. Вы примете решение переезжать, сроки будут превышены (тот же LB настроить надо), надежность получите выше, но счета будут превышены многократно, может на порядки, а о возможности ограничении расходов (забудем, что она кривовато работает) ни вы, ни админ не знаете.
Комментарий не про техническое обеспечение, а что в целом видео+звук дает лучшее качество коммуникаций чем один звук — добавляются частично невербальные каналы коммуникаций
Но не потому что нет техрука, а потому что принял решение идти в облака без озвучивания исполнителям своих реальных требований и ограничений. Админам что — техническую задачу переезда они решат, но хотел-то бизнес не переехать, а улучшить какие-то бизнес-метрики, не ухудшая (или не сильно ухудшая) другие
Для задач миграции достаточно близки они — сущности сворма хорошо ложатся на сущности кубернетеса. Может не 1:1 и обратное неверно, но перенести в кубер приложения, уже работающие в сворме с соблюдением лучших практик последнего, достаточно просто и необходимости что-то серьёзно допиливать нет, если нет необходимости использовать фичи кубера, которых нет в сворме, как это часто бывает когда кубер выбирается просто как стандарт де-факто в оркестрации контейнеров, а не как средство добавить в систему что-то чего нет в сворме принципиально нет или делается внешними решениями разной степени костыльности.
Сисадмина могут назначить техническим руководителем проекта перехода бизнес-руководители, верящие презентациям. Постоянного технического руководителя может вообще не быть в небольшой компании, а могут назначить самого опытного технаря, например, далекого от маркетинга и прочих бизнесовых штучек.
Там ссылки на другие разделы, от управления ролями и пользователями до бухгалтерии
Вот про это и забывают в презентациях.
SaaS сервисы в разы дороже виртуалок, бо они на тех же виртуалках
Вот именно, а не ультиматумы ставить "отдельная комната, проводной интернет и т. п." И работодателю, принимая решение о переходе на удалёнку, надо быть готовым к тому, что кто-то из сотрудников не захочет идти навстречу в таких вопросах или только за отдельную плату пойдёт, поскольку это существенное изменений условий сотрудничества и работник может не считать его вин-вин, а может счесть попыткой переложить проблемы работодателя на плечи работников.
Если возможно описать требования клиента до начала работ по собственно разработке продукта, то аджайл просто не нужен. Он для тех ситуаций, когда это невозможно, когда, например, заказчик хочет создать новую отрасль или взорвать существующую вопреки мнению экспертов "это так не работает" ) Аджайл он для продуктов, в которых предполагается постоянная проверка бизнес-гипотез с постоянной готовностью к "не взлетело — выкидываем и пробуем следующую"
И даже без исключения для local host? Блин
"Составить требования заказчика" как-то дико для меня звучит. Почти как "Изя, у мужчины должно быть своё мнение и сейчас мама твоё тебе расскажет". ) Вы, наверное, про сбор требований и ограничений? Agile предполагает работу в условиях высокой неопределенности, когда полные требования просто невозможно собрать заранее, когда они меняются по ходу дела после получения обратной связи
Придумываем себе проблемы и героически их решаем? )
Прочитать весь офсайт — не проблема? Почему вообще админ должен погружаться в нюансы биллинга, если в задаче этого явно не сказано? Переход на серверлесс или даже spot instances требует архитектурных изменений, близких к проектированию cloud native систем
Причём тут умственные способности, если речь о нюансах биллинга и задачи оптимизировать затраты не ставилось? Как и перехода на serverless вычисления
Есть местные станции, а есть местные ретрансляторы центральных станций, разве что рекламу местную вставляют.
Не всегда возможно на сегодня даже голосом общаться через сеть — это нужно учитывать и принимать решение то ли увольнять людей, то ли обеспечивать их старлинками, то ли делать для них исключения из общих правил.
А сможет ли он без опыта сравнить адекватно? Посчитает, например, стоимость EC2 инстансов плюс-минус аналогичных имеющимся, укажет в минусах сложность доступа (роли и вот это вот всё), в плюсах автоматическое поднятие при аварии и всё. Но забудет (если это слово уместно) про стоимость трафика, публичных IP/LB и прочего, просто потому что не привык, что надо за каждый чих платить отдельно. Вы примете решение переезжать, сроки будут превышены (тот же LB настроить надо), надежность получите выше, но счета будут превышены многократно, может на порядки, а о возможности ограничении расходов (забудем, что она кривовато работает) ни вы, ни админ не знаете.
Комментарий не про техническое обеспечение, а что в целом видео+звук дает лучшее качество коммуникаций чем один звук — добавляются частично невербальные каналы коммуникаций
Но не потому что нет техрука, а потому что принял решение идти в облака без озвучивания исполнителям своих реальных требований и ограничений. Админам что — техническую задачу переезда они решат, но хотел-то бизнес не переехать, а улучшить какие-то бизнес-метрики, не ухудшая (или не сильно ухудшая) другие
Для более эффективных коммуникаций.
Для задач миграции достаточно близки они — сущности сворма хорошо ложатся на сущности кубернетеса. Может не 1:1 и обратное неверно, но перенести в кубер приложения, уже работающие в сворме с соблюдением лучших практик последнего, достаточно просто и необходимости что-то серьёзно допиливать нет, если нет необходимости использовать фичи кубера, которых нет в сворме, как это часто бывает когда кубер выбирается просто как стандарт де-факто в оркестрации контейнеров, а не как средство добавить в систему что-то чего нет в сворме принципиально нет или делается внешними решениями разной степени костыльности.
Динамически можно определять список поддерживаемых
А если нет отдельной комнаты? Увольнять или пускай мучается?
Сисадмина могут назначить техническим руководителем проекта перехода бизнес-руководители, верящие презентациям. Постоянного технического руководителя может вообще не быть в небольшой компании, а могут назначить самого опытного технаря, например, далекого от маркетинга и прочих бизнесовых штучек.