В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 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-практики, вы правы, многие компании не готовы быть адаптивными, потому что это требует серьезной культурной смены. Для изменения культуры требуется изменить организационный дизайн, что не всегда легко достижимо.
Любая экспонента упирается в сингулярность, за которой следует смена закономерностей.
В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 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-практики, вы правы, многие компании не готовы быть адаптивными, потому что это требует серьезной культурной смены. Для изменения культуры требуется изменить организационный дизайн, что не всегда легко достижимо.