Всё верно. Сейчас так. Но я не пишу про то, что сейчас. Есть примеры в мире, где уже активно используют ГИИ для кодинга в реальных проектах. Но это не тема данной статьи.
У меня прогноз на следующие 5 лет, который я делаю на основе статей по текущим трендам. Прогноз вероятностен и может быть даже футуристичен, может не сбыться. Однако так выглядят тренды.
Забавно, что вы сразу записали меня в “кого угодно, только не разработчика”. А я начинал программировать ещё школьником на Паскале на древнем УКНЦ МС-511 (кто помнит эти чудо-машины советской эпохи — привет из прошлого!). Работал программистом с 2000 года, со второго курса, и набил шишек в реальных проектах почти за 10 лет практики. Я могу ручками вести разработку через VIM, настроить ci/cd, использую docker, понимаю в архитектуре и т.д.
Сейчас я продолжаю кодить, но больше для себя в свободное время — это дает свободу выбирать интересные задачи, а не только то, что приносит деньги.
В статье (которую, похоже, вы не дочитали) я как раз и пишу про ДОПОЛНЕНИЕ возможностей разработчика с помощью ГИИ, а не про замену людей. Это принципиально разные вещи.
Самолёт летает лучше любого человека и даже любой птицы, но мы же не говорим, что “самолёты заменят людей”. Мы говорим, что самолёты расширили наши возможности передвижения.
Так и с ГИИ в разработке — это инструмент, который берёт на себя часть рутины и помогает быстрее решать знакомые задачи. Дальше в перспективе 5 лет будет интереснее — это главная мысль. А творческое мышление, понимание бизнес-контекста, архитектурные решения — это всё остаётся за человеком.
Зачем спорить с тем, чего я не писал? Например, в этой дискуссии с первого поста начинается разговор о “замене разработчиков” и другими словами излагается то же самое, что я написал, хотя в статье речь о совершенно другом - о дополнении и новых возможностях? Или Agile-coach — это точно никак не программист и не читая сразу минус в карму, не читая?
Кстати, а вы сами пробовали использовать ГИИ в своей работе, использовали Cursor с подпиской или дополнения к IDE? Было бы интересно узнать ваш опыт, без предвзятости.
Откуда у вас такие данные, что генеративные модели “уперлись и вышли на плато”, особенно в контексте генерации кода?
Анализ статей с показателями показывают совсем другую картину.
Вот конкретные цифры по бенчмарку HumanEval (% успешно решенных задач кодирования): от ~30% до более 90% за три года. Это не экспонента? На других бенчмарках тренд аналогичный. Можно посмотреть на ежемесячные обновления бенчмарков на HuggingFace Open LLM Leaderboard или McKinsey Technology Trends Outlook. Пока выхода на плато авторитетные источники не выдают.
Стратегические бизнес-решения — да, их должен принимать тот, кто видит большую картину и несет ответственность. ИИ тут пока даже рядом не стоял.
Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.
Рутинные ежедневные решения — вот здесь ГИИ уже может помочь. Но даже тут, контекст решает всё.
ГИИ хорошо помогает в узкоспециализированных задачах, если ему дать правильный контекст. Например, я пробовал его сам использовать для генерации unit-тестов для своих проектов — это снимает рутину, но ревью написанных тестов всё равно делаю я сам и может с 5 раза я получу то, что хотел.
Любые аналогии условны, как и аналогия с мультиком.
Можно увидеть три формата отношения к ГИИ среди участников
“Вау-подход”: “А нука ГИИ, напиши весь проект!” - получают кучу галлюцинаций, неработающего кода и разочаровываются.
“Нет-подход”: “Это всё бесполезно, видел я уже всё это в другом месте”- не получают никаких преимуществ
“Умный подход”: ГИИ используется для конкретных задач под контролем человека/команды, с направленными промтами, отсеиванием глюков (именно этот подход описан в статье)
Думаю, ключевое отличие от “двоих из ларца” в том, что хороший ИИ не просто тупо исполняет, а предлагает варианты, которые могут натолкнуть на новые идеи. Как джуниор, который иногда выдает неожиданно полезные мысли.
Нам нужно оставаться “умнее” в контексте задачи, технической архитектуры и бизнес-требований. Но это не значит, что мы должны знать все детали реализации.
Время рассудит. Прогноз всегда вероятностен. Человек не оракул и будущее не видит. Любой ответ ГИИ тоже вероятностную природу имеет. Каждый должен относится критически и к прогнозу и к ответам ГИИ. Это нормально.
В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 100 задач параллельно, а держать общий фокус команды на одной задаче. ГИИ может в этом помочь, устранив потери на рутину и ожидания. Но надо использовать ГИИ с умом, а "не пытаться микроскопом забить гвозди".
Кал Ньюпорт в книге “Digital Minimalism” писал: “Технологии должны служить нашим глубинным ценностям, а не превращать нас в рабов эффективности. Когда мы оптимизируем только скорость и объем, мы жертвуем глубиной и качеством — как работы, так и жизни”.
Технология должна не просто ускорять процессы, а освобождать людей от рутины для более глубокой, осмысленной работы. Поэтому нужно создавать технологии, которые увеличивают человеческие возможности, а не заменяют людей или заставляют их работать как машины.
Вы как думаете, возможен ли такой подход в реальной корпоративной среде? Или всё же культура “быстрее, больше, лучше, стресс, ещё больше и лучше и ещё быстрее” перевесит человеческие потребности? Дело же не в ГИИ, а в нас, людях. У ИИ нет целей, желаний и эмоций, нет ничего человеческого.
Я наблюдал за изменениями частоты релизов за 10 лет в разных компаниях. Если раньше только обсуждали, что надо чаще релизиться, то последние два года частота выпусков стала расти как факт. Экспоненциальная закономерность - это гипотеза, но пока она подтверждает моё личное наблюдение. Почти всё что связано с информацией и накоплением знаний имеет экспоненциальный тренд. Например, экспоненциален рост числа патентов, производительность процессоров, стоимость хранения 1 бита информации и т.д.
Согласен, что на текущем этапе преимущество только для джунов и может быть мидлов. Однако кроме непосредственно программирования есть ещё в разработке аналитика, документация, автотесты, ci/cd и т.д. - у ребят, кто этим занимается в разы больше рутины, чем у программистов-синьоров.
Я сам сейчас занимаюсь разработкой в IDE Cursor и решаю прикладные задачи: создать кастомизированный опросник через телеграм, или дашборд по метрикам, удобно написать сервис для ретро и т.д. Таким образом делаю всё то, на что не хватило бы времени без ГИИ, но упрощает и улучшает мою работу. Мой личный опыт связан с разработкой непосредственно и вышел в ИТ-менеджмент я когда то давно из разработки.
И надо понимать, что инструменты развиваются. Что будет полезным из ГИИ синьорам через 2-3 года мы увидим. Прогноз всегда вероятностен и точно не линеен.
Вы правы, если посмотреть так, то многое встает на свои места. Мы действительно проходим знакомый путь: новый инструмент → хайп → завышенные ожидания → разочарование → продуктивное использование. Прямо по классической кривой Гартнера. С практической точки зрения, полностью поддерживаю ваш здравый подход.
Помню на одном митапе в 2010 году говорили, как облачные технологии должны были “уничтожить” профессию системного администратора в компаниях. А по факту просто изменили требуемые навыки.
Есть небольшое отличие от других ПО конечно, современные ГИИ-инструменты иногда выдают такое, что даже их создатели удивляются :-)
Наблюдаю, что частота растёт. Всё верно. Но закономерность роста частоты релизов подобно закону Мура экспоненциальная, не линейная. В начале этот рост экспоненты не так заметен. Я написал в статье, что в перспективе 5 лет движение будет стремительным, несмотря на то, что скорость на старте пока не так сильно ощущаем. Противоречий нет.
Всё верно, именно об этом моя статья, что людям придётся быть умнее "двоих из ларца" в любой решаемой задаче, а эти "двое" будут исполнителями, которых постоянно надо будет учить. Но зато рутину они снимут.
Пока есть любая зависимость, линейная, или экспоненциальная как в контектсе ГИИ и ИТ-технологий в целом, то можно строить прогнозы. Экспоненциальные тренды - это тоже тренды. Но как только экспонента уйдёт в сингулярность происходит смена прежних закономерностей, и вот за точкой смены трендов конечно начинается чистая фантастика, а не прогноз.
Спасибо за ваш комментарий — всегда ценю мнение практиков, особенно руководителей разработки 👍
Знаете, тут как с шахматами — разные люди видят одну и ту же доску, но замечают разные комбинации. Мой взгляд сформирован работой с десятками команд и работой в области ИТ уже более 20 лет.
Полностью согласен насчет “копировать без понимания = катастрофа”. Но ГИИ тут не причём. Это всего лишь инструмент. Ноутбуком можно гвозди забивать, но это не будет не очень эффективное его использование😅 Голову человека никто не отменит и конечно не заменит.
По поводу галлюцинаций — абсолютная правда! Для того чтобы работать с глюками и нужен будет человек. Поэтому команды останутся, изменится характер работы и инструменты. И не многовенно, а мой прогноз в перспективе 5 лет.
Кстати, интересно узнать — как именно ваша команда использует ИИ в качестве “второго мнения”? У вас есть какой-то формализованный процесс или это больше на усмотрение каждого разработчика?
P.S. Моя идея не в том, что ИИ заменит разработчиков (это как раз галлюцинация, но со стороны маркетологов ИИ 😉), а в том, что изменятся требуемые навыки — от механического кодинга к более высокоуровневой работе с постановкой задачи, бизнес-логикой и валидацией. Но, возможно, мы говорим об одном и том же, просто с разных сторон?
Перечитайте пожалуйста статью, я наоборот писал, что люди будут в процессе. "ГИИ не заменит нас, но изменит нашу работу. " - моя цитата в итоге подразумевает именно это. Другое дело, что изменится характер работы. Например, оператор экскаватора конкурирует сегодня с 10 рабочими у которых есть только лопата. Экскаватор эффективнее лопаты, но требует определённых навыков управления им у человека. ГИИ дополнит, но не заменяет работу Agile-команды.
Был в советское время анекдот "10 студентов заменяют трактор", но вопрос зачем?
Спасибо за комментарий. В тексте я не писал, что Agile уйдёт в прошлое. Речь шла о стандартной принятой практике в большинстве компаний в 2 недельные спринты - это будет долго для нового времени. Изменится принцип "Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale. " Потому что частота выпуска будет стремительно расти, а темпы будут видимо ускоряться начиная с 2026-2027 года.
Замечательный комментарий вы дали. Чтобы дать лучший ответ почему появилась представленная мной модель, то напишу немного подробнее откуда появилась модель Cynefin.
Модель Cynefin была создана Дэвидом Сноуденом, академиком и консультантом по управлению. Это произошло в начале 2000-х годов, когда он работал в IBM Institute for Knowledge Management. Дэвид Сноуден, создатель модели Cynefin, не разрабатывал ее специально для Agile или любого другого конкретного подхода. Однако его модель оказалась полезной в контексте Agile, поскольку она помогает любым командам лучше понимать и категоризировать проблемы, с которыми они сталкиваются, и выбирать наиболее эффективные стратегии для их решения.
Модель Cynefin была разработана как фреймворк для помощи в принятии решений и управления сложностью. Главная идея заключается в том, что разные типы проблем и ситуаций требуют разных подходов к управлению и решению.
Когда изменения являются неизбежными и неопределенность велика работают Agile-команды, а понимание того, какие проблемы и задачи являются простыми, сложными, сложными или хаотическими, может помочь команде определить наиболее эффективные стратегии для их решения.
Сноуден разделил проблемы на пять категорий: простые, сложные, сложные, хаотические и бесформенные. Для каждой категории он предложил свой подход к решению проблем.
Простые проблемы: здесь причинно-следственная связь очевидна, и лучшие практики применяются для решения проблем. Сложные проблемы: в этой области требуется анализ экспертов для выбора наилучшего курса действий, поскольку существует несколько правильных ответов. Комлексные проблемы: в этой области необходим эксперимент и обучение, поскольку причинно-следственные связи не предсказуемы, и решения возникают в процессе. Хаотические проблемы: здесь действия предпринимаются для установления стабильности, прежде чем оценивать и вводить порядок. Беспорядочные проблемы: в этой области требуется определение правильного домена и декомпозиция проблемы. Это область, где не ясно, какой тип проблемы перед нами, и поэтому необходимо уточнение.
Если большинство ваших проблем комплексные, то лучше всего подойдут практики Agile. Но нужно понимать, что просто выбрать подход к решению проблемы - это только малая часть всей работы. Ведь мир не состоит только из задач и проблем. Более того команды часто сталкиваются с проблемами сразу из разных областей.
Модель, о которой я писал в статье, появилась из моего практического опыта работы по "кикофу" команд и проведения тренингов по основам Agile/Scrum. Когда то я пытался использовать только модель Cynefin для объяснения, когда лучше всего применять Agile, но многие не принимали её и воспринимали исключительно как теорию. Возможно, потому что Cynefin была создана для помощи в решении проблем, а не для выбора подхода Waterfall или Agile.
Жизнь сложна и многогранна. Модели помогают нам лучше понять ее. И выбор, какую модель использовать и в какой ситуации, всегда остается за вами.
Отличный комментарий! Действительно, не каждая организация занимается "рокетсайнс". Важно понимать, что "неопределенность в требованиях" не должна стать оправданием для отсутствия планирования и анализа. И когда возникает настоящая неопределённость, такая с которой надо работать через Agile-практики, вы правы, многие компании не готовы быть адаптивными, потому что это требует серьезной культурной смены. Для изменения культуры требуется изменить организационный дизайн, что не всегда легко достижимо.
Всё верно. Сейчас так. Но я не пишу про то, что сейчас. Есть примеры в мире, где уже активно используют ГИИ для кодинга в реальных проектах. Но это не тема данной статьи.
У меня прогноз на следующие 5 лет, который я делаю на основе статей по текущим трендам. Прогноз вероятностен и может быть даже футуристичен, может не сбыться. Однако так выглядят тренды.
Забавно, что вы сразу записали меня в “кого угодно, только не разработчика”. А я начинал программировать ещё школьником на Паскале на древнем УКНЦ МС-511 (кто помнит эти чудо-машины советской эпохи — привет из прошлого!). Работал программистом с 2000 года, со второго курса, и набил шишек в реальных проектах почти за 10 лет практики. Я могу ручками вести разработку через VIM, настроить ci/cd, использую docker, понимаю в архитектуре и т.д.
Сейчас я продолжаю кодить, но больше для себя в свободное время — это дает свободу выбирать интересные задачи, а не только то, что приносит деньги.
В статье (которую, похоже, вы не дочитали) я как раз и пишу про ДОПОЛНЕНИЕ возможностей разработчика с помощью ГИИ, а не про замену людей. Это принципиально разные вещи.
Самолёт летает лучше любого человека и даже любой птицы, но мы же не говорим, что “самолёты заменят людей”. Мы говорим, что самолёты расширили наши возможности передвижения.
Так и с ГИИ в разработке — это инструмент, который берёт на себя часть рутины и помогает быстрее решать знакомые задачи. Дальше в перспективе 5 лет будет интереснее — это главная мысль. А творческое мышление, понимание бизнес-контекста, архитектурные решения — это всё остаётся за человеком.
Зачем спорить с тем, чего я не писал? Например, в этой дискуссии с первого поста начинается разговор о “замене разработчиков” и другими словами излагается то же самое, что я написал, хотя в статье речь о совершенно другом - о дополнении и новых возможностях? Или Agile-coach — это точно никак не программист и не читая сразу минус в карму, не читая?
Кстати, а вы сами пробовали использовать ГИИ в своей работе, использовали Cursor с подпиской или дополнения к IDE? Было бы интересно узнать ваш опыт, без предвзятости.
Откуда у вас такие данные, что генеративные модели “уперлись и вышли на плато”, особенно в контексте генерации кода?
Анализ статей с показателями показывают совсем другую картину.
Вот конкретные цифры по бенчмарку HumanEval (% успешно решенных задач кодирования): от ~30% до более 90% за три года. Это не экспонента? На других бенчмарках тренд аналогичный.
Можно посмотреть на ежемесячные обновления бенчмарков на HuggingFace Open LLM Leaderboard или McKinsey Technology Trends Outlook. Пока выхода на плато авторитетные источники не выдают.
Стратегические бизнес-решения — да, их должен принимать тот, кто видит большую картину и несет ответственность. ИИ тут пока даже рядом не стоял.
Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.
Рутинные ежедневные решения — вот здесь ГИИ уже может помочь. Но даже тут, контекст решает всё.
ГИИ хорошо помогает в узкоспециализированных задачах, если ему дать правильный контекст. Например, я пробовал его сам использовать для генерации unit-тестов для своих проектов — это снимает рутину, но ревью написанных тестов всё равно делаю я сам и может с 5 раза я получу то, что хотел.
Любые аналогии условны, как и аналогия с мультиком.
Можно увидеть три формата отношения к ГИИ среди участников
“Вау-подход”: “А нука ГИИ, напиши весь проект!” - получают кучу галлюцинаций, неработающего кода и разочаровываются.
“Нет-подход”: “Это всё бесполезно, видел я уже всё это в другом месте”- не получают никаких преимуществ
“Умный подход”: ГИИ используется для конкретных задач под контролем человека/команды, с направленными промтами, отсеиванием глюков (именно этот подход описан в статье)
Думаю, ключевое отличие от “двоих из ларца” в том, что хороший ИИ не просто тупо исполняет, а предлагает варианты, которые могут натолкнуть на новые идеи. Как джуниор, который иногда выдает неожиданно полезные мысли.
Нам нужно оставаться “умнее” в контексте задачи, технической архитектуры и бизнес-требований. Но это не значит, что мы должны знать все детали реализации.
Время рассудит. Прогноз всегда вероятностен. Человек не оракул и будущее не видит. Любой ответ ГИИ тоже вероятностную природу имеет. Каждый должен относится критически и к прогнозу и к ответам ГИИ. Это нормально.
Любая экспонента упирается в сингулярность, за которой следует смена закономерностей.
В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 100 задач параллельно, а держать общий фокус команды на одной задаче. ГИИ может в этом помочь, устранив потери на рутину и ожидания. Но надо использовать ГИИ с умом, а "не пытаться микроскопом забить гвозди".
Кал Ньюпорт в книге “Digital Minimalism” писал: “Технологии должны служить нашим глубинным ценностям, а не превращать нас в рабов эффективности. Когда мы оптимизируем только скорость и объем, мы жертвуем глубиной и качеством — как работы, так и жизни”.
Технология должна не просто ускорять процессы, а освобождать людей от рутины для более глубокой, осмысленной работы. Поэтому нужно создавать технологии, которые увеличивают человеческие возможности, а не заменяют людей или заставляют их работать как машины.
Вы как думаете, возможен ли такой подход в реальной корпоративной среде? Или всё же культура “быстрее, больше, лучше, стресс, ещё больше и лучше и ещё быстрее” перевесит человеческие потребности? Дело же не в ГИИ, а в нас, людях. У ИИ нет целей, желаний и эмоций, нет ничего человеческого.
Я наблюдал за изменениями частоты релизов за 10 лет в разных компаниях. Если раньше только обсуждали, что надо чаще релизиться, то последние два года частота выпусков стала расти как факт. Экспоненциальная закономерность - это гипотеза, но пока она подтверждает моё личное наблюдение. Почти всё что связано с информацией и накоплением знаний имеет экспоненциальный тренд. Например, экспоненциален рост числа патентов, производительность процессоров, стоимость хранения 1 бита информации и т.д.
Согласен, что на текущем этапе преимущество только для джунов и может быть мидлов. Однако кроме непосредственно программирования есть ещё в разработке аналитика, документация, автотесты, ci/cd и т.д. - у ребят, кто этим занимается в разы больше рутины, чем у программистов-синьоров.
Я сам сейчас занимаюсь разработкой в IDE Cursor и решаю прикладные задачи: создать кастомизированный опросник через телеграм, или дашборд по метрикам, удобно написать сервис для ретро и т.д. Таким образом делаю всё то, на что не хватило бы времени без ГИИ, но упрощает и улучшает мою работу. Мой личный опыт связан с разработкой непосредственно и вышел в ИТ-менеджмент я когда то давно из разработки.
И надо понимать, что инструменты развиваются. Что будет полезным из ГИИ синьорам через 2-3 года мы увидим. Прогноз всегда вероятностен и точно не линеен.
Вы правы, если посмотреть так, то многое встает на свои места. Мы действительно проходим знакомый путь: новый инструмент → хайп → завышенные ожидания → разочарование → продуктивное использование. Прямо по классической кривой Гартнера. С практической точки зрения, полностью поддерживаю ваш здравый подход.
Помню на одном митапе в 2010 году говорили, как облачные технологии должны были “уничтожить” профессию системного администратора в компаниях. А по факту просто изменили требуемые навыки.
Есть небольшое отличие от других ПО конечно, современные ГИИ-инструменты иногда выдают такое, что даже их создатели удивляются :-)
Вы сами используете ГИИ-инструменты в работе?
Наблюдаю, что частота растёт. Всё верно. Но закономерность роста частоты релизов подобно закону Мура экспоненциальная, не линейная. В начале этот рост экспоненты не так заметен. Я написал в статье, что в перспективе 5 лет движение будет стремительным, несмотря на то, что скорость на старте пока не так сильно ощущаем. Противоречий нет.
Всё верно, именно об этом моя статья, что людям придётся быть умнее "двоих из ларца" в любой решаемой задаче, а эти "двое" будут исполнителями, которых постоянно надо будет учить. Но зато рутину они снимут.
Пока есть любая зависимость, линейная, или экспоненциальная как в контектсе ГИИ и ИТ-технологий в целом, то можно строить прогнозы. Экспоненциальные тренды - это тоже тренды. Но как только экспонента уйдёт в сингулярность происходит смена прежних закономерностей, и вот за точкой смены трендов конечно начинается чистая фантастика, а не прогноз.
Спасибо за ваш комментарий — всегда ценю мнение практиков, особенно руководителей разработки 👍
Знаете, тут как с шахматами — разные люди видят одну и ту же доску, но замечают разные комбинации. Мой взгляд сформирован работой с десятками команд и работой в области ИТ уже более 20 лет.
Полностью согласен насчет “копировать без понимания = катастрофа”. Но ГИИ тут не причём. Это всего лишь инструмент. Ноутбуком можно гвозди забивать, но это не будет не очень эффективное его использование😅 Голову человека никто не отменит и конечно не заменит.
По поводу галлюцинаций — абсолютная правда! Для того чтобы работать с глюками и нужен будет человек. Поэтому команды останутся, изменится характер работы и инструменты. И не многовенно, а мой прогноз в перспективе 5 лет.
Кстати, интересно узнать — как именно ваша команда использует ИИ в качестве “второго мнения”? У вас есть какой-то формализованный процесс или это больше на усмотрение каждого разработчика?
P.S. Моя идея не в том, что ИИ заменит разработчиков (это как раз галлюцинация, но со стороны маркетологов ИИ 😉), а в том, что изменятся требуемые навыки — от механического кодинга к более высокоуровневой работе с постановкой задачи, бизнес-логикой и валидацией. Но, возможно, мы говорим об одном и том же, просто с разных сторон?
Перечитайте пожалуйста статью, я наоборот писал, что люди будут в процессе. "ГИИ не заменит нас, но изменит нашу работу. " - моя цитата в итоге подразумевает именно это. Другое дело, что изменится характер работы. Например, оператор экскаватора конкурирует сегодня с 10 рабочими у которых есть только лопата. Экскаватор эффективнее лопаты, но требует определённых навыков управления им у человека. ГИИ дополнит, но не заменяет работу Agile-команды.
Был в советское время анекдот "10 студентов заменяют трактор", но вопрос зачем?
Спасибо за комментарий. В тексте я не писал, что Agile уйдёт в прошлое. Речь шла о стандартной принятой практике в большинстве компаний в 2 недельные спринты - это будет долго для нового времени. Изменится принцип "Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale. " Потому что частота выпуска будет стремительно расти, а темпы будут видимо ускоряться начиная с 2026-2027 года.
Замечательный комментарий вы дали. Чтобы дать лучший ответ почему появилась представленная мной модель, то напишу немного подробнее откуда появилась модель Cynefin.
Модель Cynefin была создана Дэвидом Сноуденом, академиком и консультантом по управлению. Это произошло в начале 2000-х годов, когда он работал в IBM Institute for Knowledge Management.
Дэвид Сноуден, создатель модели Cynefin, не разрабатывал ее специально для Agile или любого другого конкретного подхода. Однако его модель оказалась полезной в контексте Agile, поскольку она помогает любым командам лучше понимать и категоризировать проблемы, с которыми они сталкиваются, и выбирать наиболее эффективные стратегии для их решения.
Модель Cynefin была разработана как фреймворк для помощи в принятии решений и управления сложностью. Главная идея заключается в том, что разные типы проблем и ситуаций требуют разных подходов к управлению и решению.
Когда изменения являются неизбежными и неопределенность велика работают Agile-команды, а понимание того, какие проблемы и задачи являются простыми, сложными, сложными или хаотическими, может помочь команде определить наиболее эффективные стратегии для их решения.
Сноуден разделил проблемы на пять категорий: простые, сложные, сложные, хаотические и бесформенные. Для каждой категории он предложил свой подход к решению проблем.
Простые проблемы: здесь причинно-следственная связь очевидна, и лучшие практики применяются для решения проблем.
Сложные проблемы: в этой области требуется анализ экспертов для выбора наилучшего курса действий, поскольку существует несколько правильных ответов.
Комлексные проблемы: в этой области необходим эксперимент и обучение, поскольку причинно-следственные связи не предсказуемы, и решения возникают в процессе.
Хаотические проблемы: здесь действия предпринимаются для установления стабильности, прежде чем оценивать и вводить порядок.
Беспорядочные проблемы: в этой области требуется определение правильного домена и декомпозиция проблемы. Это область, где не ясно, какой тип проблемы перед нами, и поэтому необходимо уточнение.
Если большинство ваших проблем комплексные, то лучше всего подойдут практики Agile. Но нужно понимать, что просто выбрать подход к решению проблемы - это только малая часть всей работы. Ведь мир не состоит только из задач и проблем. Более того команды часто сталкиваются с проблемами сразу из разных областей.
Модель, о которой я писал в статье, появилась из моего практического опыта работы по "кикофу" команд и проведения тренингов по основам Agile/Scrum. Когда то я пытался использовать только модель Cynefin для объяснения, когда лучше всего применять Agile, но многие не принимали её и воспринимали исключительно как теорию. Возможно, потому что Cynefin была создана для помощи в решении проблем, а не для выбора подхода Waterfall или Agile.
Жизнь сложна и многогранна. Модели помогают нам лучше понять ее. И выбор, какую модель использовать и в какой ситуации, всегда остается за вами.
Отличный комментарий! Действительно, не каждая организация занимается "рокетсайнс". Важно понимать, что "неопределенность в требованиях" не должна стать оправданием для отсутствия планирования и анализа. И когда возникает настоящая неопределённость, такая с которой надо работать через Agile-практики, вы правы, многие компании не готовы быть адаптивными, потому что это требует серьезной культурной смены. Для изменения культуры требуется изменить организационный дизайн, что не всегда легко достижимо.