8465
правок
Изменения
м
Нет описания правки
В выступлении будет обзор теории и приземление ее на конкретные кейсы, которые я слушал в паре десятков выступлений по теме, выделяя в них проявление общих элементов. Приходите, чтобы получить готовую теоретическую базу и набор практических шаблонов!
= Краткое содержание =
Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача. У меня в мае была статья [https://habr.com/ru/articles/1035522/ «Об организации труда ИИ-агентов»], но дополнения к ней появились почти сразу. Но я попробовал и вроде у меня получилось. Краткие тезисы.
# '''SDD – это старый известный водопад'''. Его не получилось реализовать на людях, и теперь попытались сделать на агентах.
## Не работает по тем же причинам: агенты делают не то и не так, в ответ идет наращивание подробностей в спецификации, как делают аналитики при разборках с разработчиками о том, кто виноват, в результате спецификация быстро становится не читаемой и не проверяемой. Причины известны с 1990-х.
## Третья – спецификацию невозможно обсуждать с бизнесом, он ее не понимает.
## Проверка спецификации по характеру работы сильно отличается от написания кода, '''это – другая компетенция'''. Когда разработчикам это навязывают, теряется мотивация.
# Есть ограниченный класс задач, которые решаются хорошо – когда есть типовые решения: сайт-визитка, типовой интернет-магазин, типовой документооборот, типовая CRM небольшого бизнеса. Раньше делали платформу с точками расширения, теперь можно сделать harness для скелета решения и чек-лист для проверки спецификации.
# Есть способы несколько облегчить проблемы SDD.
## Возложить проверку на ИИ, а разработчики пусть пишут чек-лист и архитектурные принципы.
## Проверяем не спецификацию, а точки принятия решений, в которых ИИ делал выбор из альтернатив – это ближе и проще.
## В спецификации пишем не способ решения, а краткую архитектуру и набор тест-кейсов – это получается не SDD, а '''TDD/BDD''', хотя формат OpenSpec это позволяет.
# Можно работать через прототипы. Тем более, что бизнес сам с удовольствием вайбкодит прототипы. Правда, он потом требует их поставить в прод, а разработка не может понятно объяснить, почему не может это сделать. Это направление точно будет развиваться. При этом описание архитектуры, тест-кейсы и другая документация таким приложениям нужны, но может появляться позже, по мере того, как прототип стабилизируется.
# Но вот сделать harness-платформу, на которой бизнес будет вайбкодить все, что ему нужно, как предлагает '''Disrupt-PDCL''' от Сбера – точно не получится, как 25 лет назад не получилось обеспечить разработку приложений за счет создания CASE-средств. Причины – те же, платформа не обеспечит сложные случаи, для которых нужна '''совместная работа бизнеса и разработчиков''' над поиском решений, приемлемых по сложности и решающих проблемы бизнеса. Надо уметь включать в эту команду ИИ-агентов.
# ИИ-агенты хорошо делают частные задачи. При этом процесс разработки расщепляется на более мелкие операции. Это уже было – когда вместо программиста появилась команда из аналитика, разработчика и тестировщика, а позднее веб-мастер превратился в дизайнера и фронт-разработчика. И есть обратные процессы, когда специализации объединяются – как было с кроссфункциональными командами вместо отделов и происходит сейчас с '''tiny-team'''. Можно использовать те же схемы для проектирования процесса, в презентации у меня была '''схема Акта деятельности''' из СМД-методологии, поверх которой нарисовано конкретное разделение труда.
# Важно помнить, что '''недостаточно разделить на операции, необходимо обеспечить компетенцию исполнителей, снабдить их знаниями'''. Даже когда это ИИ-агенты. Это – вертикальное измерение разделения труда. Если у вас агент проверяет архитектуру или качество кода по чек-листу, то надо поверх запускать '''HADI-цикл''', в котором ведется мониторинг текущего качества, выявляются проблемные типы задач и решаются доработкой harness. Об этом забывают, не ставят доработку harness как процесс. При этом можно перераспределять задачи между ИИ и человеком: ставишь ИИ-агента, который делит задачи на простые и сложные по каким-то критериям, простые отдает ИИ (их может быть несколько с разными моделями), а сложные – человеку. И поверх – мониторинг и совершенствование.
# В целом тут большое поле деятельности, ИИ-агенты сейчас позволяют сделать то, до чего не доходили руки: покрыть тестами, актуализировать документацию, написать скрипты, чтобы создавать тестовые стенды на основе боевых и так далее.
# ИИ меняет не только разработку, но и бизнес. Если гипотеза проверяется за 3-5 дней вместо 2-3 месяцев, надо перестраивать весь процесс и роль ИТ в нем. Раньше бизнес говорил: «куча идей, разработка не успевает», теперь вопрос к качеству идей. Работа владельца продукта стала новым ограничением.
# '''Внедрять ИИ по площади бессмысленно'''. Теория ограничений Голдратта говорит: ускорение в конкретном месте только тогда дает бизнес-эффект, когда это место является ограничением для бизнеса. Внедрение по площади приводит к тому, что ИИ в точках ограничений появляется позднее, чем в других местах – там операционка зашкаливает. Поэтому проекты массового внедрения ИИ не дают бизнес-эффекта. Правильный подход – фокусировка: пилоты для апробирования, точечные внедрения в критических участках с ожидаемым результатом, и лишь затем – распространение. Распространять – необходимо: ИИ – инфраструктура, как электричество или интернет: освоить необходимо, применять надо там, где уместно. '''ИИ не даст конкурентного преимущества, потому что будет у всех'''.
# Работа с ИИ дает лог работы сотрудника, подробнее, чем таск-трекер. Это можно использовать для анализа и совершенствования работы. Хотя понятно, что сначала попробуют использовать для контроля. Это пока практически не прорабатывается, а по сути тут – тоже HADI-цикл.
# И в заключении была пара слайдов про те изменения, которые ИИ принесет в жизнь – когда у каждого из нас будут свои ИИ-помощники, организующие жизнь. И роботы – Китай активно работает в эту сторону, в том числе снижая стоимость, да и у нас разработки ведутся, на конференции было выступление Сбера с впечатляющими результатами.
= Презентация =
