Ваши дефициты перекликаются с 6-ю слоями сопротивления из ТОС https://habr.com/ru/articles/725018/ Только вы третий и четвертый слой пропустили, потому что работаете наверно больше со стороны подрядчика, и склонны эти проблемы перекладывать на дефицит компетентности со стороны заказчика. Но на самом деле тут как раз дефицит компетентности со стороны подрядчика, потому что касаются конкретного решения. Меж тем, как известно, на рынке всегда есть и дефицит компетентных подрядчиков, готовых работать за небольшие деньги.
И какая связь вашего примера с будущим опенсорс? Для стороннего пользователя библиотеки хорошее решение будет написать (навайбкодить) свой вариант и выложить в опенсорс, чтобы и другие разработчики по описанной выше схеме Дмитрия присоединились и поделились технической экспертизой.
А в целом я согласен, что полного "вне цивилизации" не будет. Те, кто оказался "вне", то есть в малом количестве на мало пригодной для жизни территории, конечно вымрут. Но останется много людей на территориях гораздо лучше приспособленных для жизни чем сибирская тайга. И там цивилизация соответственно останется, хоть и в слегка менее технологичной форме.
По ТК работник должен выполнять те функции, которые прописаны в трудовом договоре. Соответственно для начала работодателям неплохо бы научиться принимать людей на работу...
Надо искать связи не с hh-индексом, а только с количеством вакансий. Если компании перестают публиковать новые вакансии и закрывают старые, то значит готовятся к сокращению штата.
У вас примеры не очень. У людей там был выбор: остаться и доживать или пробовать уехать. Безусловно остались те, кто не смотрел в будущее, то есть и размножаться то не планировал. Значит они и не могли выжить, только дожить до неминуемого конца. Все люди смертны, независимо от того чем отапливают дома.
Ещё поддержу, что с ИИ нет и не может быть идеи - код генерируется из спеки. Генераторы кода есть и они работают (недавно только были статьи на хабре), но ИИ тут не причем.
Спецификации во всех проектах разработки нужны, чтобы было понимание к чему идем, разрабатывая продукт. То есть это не для постоянной генерации ода заново, а для проверки, что код "правильный", то есть делает то, что нужно.
Я всегда считал, что должна быть команда. Очень тяжело как аналитику работать с невовлечёнными разработчиками. Также тяжело быть как разработчику работать с аналитиками не вникающими в сам продукт.
Если от общих рассуждений отойти к делу? Сейчас многие системы документооборота перешли на всякие ноу-код и лоу-код инструменты, которые позволяют быстро поменять внутри системы точечно какие-то вещи, типа процесса отчета по проекту, вот вроде как ваш "живой регламент". А вы то, что за продукт демонстрировать будете? есть уже описание?
Ну и вот это навязывание подрядчика в любом случае выйдет боком, то есть к дефициту смысла.
За PDCA плюс.
А сколько у вас сейчас это живет?
Ваши дефициты перекликаются с 6-ю слоями сопротивления из ТОС https://habr.com/ru/articles/725018/
Только вы третий и четвертый слой пропустили, потому что работаете наверно больше со стороны подрядчика, и склонны эти проблемы перекладывать на дефицит компетентности со стороны заказчика. Но на самом деле тут как раз дефицит компетентности со стороны подрядчика, потому что касаются конкретного решения. Меж тем, как известно, на рынке всегда есть и дефицит компетентных подрядчиков, готовых работать за небольшие деньги.
И какая связь вашего примера с будущим опенсорс?
Для стороннего пользователя библиотеки хорошее решение будет написать (навайбкодить) свой вариант и выложить в опенсорс, чтобы и другие разработчики по описанной выше схеме Дмитрия присоединились и поделились технической экспертизой.
то есть с одной стороны ускоряем, с другой стороны замедляем, ведь придется заваривать пять чашек вместо трех.
А в целом я согласен, что полного "вне цивилизации" не будет. Те, кто оказался "вне", то есть в малом количестве на мало пригодной для жизни территории, конечно вымрут. Но останется много людей на территориях гораздо лучше приспособленных для жизни чем сибирская тайга. И там цивилизация соответственно останется, хоть и в слегка менее технологичной форме.
Что-то вы так плохо про деревья думаете
По ТК работник должен выполнять те функции, которые прописаны в трудовом договоре. Соответственно для начала работодателям неплохо бы научиться принимать людей на работу...
.
Надо искать связи не с hh-индексом, а только с количеством вакансий. Если компании перестают публиковать новые вакансии и закрывают старые, то значит готовятся к сокращению штата.
У вас примеры не очень.
У людей там был выбор: остаться и доживать или пробовать уехать. Безусловно остались те, кто не смотрел в будущее, то есть и размножаться то не планировал. Значит они и не могли выжить, только дожить до неминуемого конца. Все люди смертны, независимо от того чем отапливают дома.
да, чем меньше мест хранения тем лучше.
чем больше резервных копий, тем лучше
Точно, тут вы правы. Но сейчас многие свои собранные столы пытаются ещё и продавать.
и даже не столы, а чертежи столов...
Ещё поддержу, что с ИИ нет и не может быть идеи - код генерируется из спеки. Генераторы кода есть и они работают (недавно только были статьи на хабре), но ИИ тут не причем.
Спецификации во всех проектах разработки нужны, чтобы было понимание к чему идем, разрабатывая продукт. То есть это не для постоянной генерации ода заново, а для проверки, что код "правильный", то есть делает то, что нужно.
Я всегда считал, что должна быть команда. Очень тяжело как аналитику работать с невовлечёнными разработчиками. Также тяжело быть как разработчику работать с аналитиками не вникающими в сам продукт.
Если заменить слово думать на изобретать, то текст улучшиться.
можно заголовок отредактировать - "Управленческие паттерны, которые позволяют компаниям в России выживать"
Тут вот по соседству статья появилась https://habr.com/ru/articles/1056626/ про живые регламенты. А как тут с кастомизацией проектной деятельности?
Если от общих рассуждений отойти к делу?
Сейчас многие системы документооборота перешли на всякие ноу-код и лоу-код инструменты, которые позволяют быстро поменять внутри системы точечно какие-то вещи, типа процесса отчета по проекту, вот вроде как ваш "живой регламент".
А вы то, что за продукт демонстрировать будете?
есть уже описание?
задача со звездочкой *
ну да, не прямо удобно, но как есть