Плюсы и минусы Agile
Мнения о состоянии Agile расходятся: кто-то считает, что ему плохо и он уже умирает, а кто-то – что с ним все в порядке. Разберемся, за что мы любим Agile и какие у него есть ограничения.
Плюсы – это гибкость, быстрая обратная связь и прозрачность для клиента. Минусы – сложно оценить, когда получится результат. Фокус зачастую оказывается на процессах, а не на результате. Кроме того, считается, что большие и сложные проекты невозможно делать по Agile.
А если пофантазировать, как с помощью искусственного интеллекта усилить плюсы и нивелировать минусы? Например, спринт будет длиться не две недели, а два дня: накопился пул задач – и за два дня их все сделали. Или обследование предприятия будет занимать не три месяца, а три дня. Было бы замечательно.
Руководитель проекта садится перед монитором, видит все показатели своего проекта и управляет процессом с помощью микрофона и наушников. Пока, к сожалению, так не получается.
Использование искусственного интеллекта в личной жизни уже стало практикой: мы все так или иначе его используем и считаем, что делаем это эффективно. А с бизнесом вопрос пока спорный. Статистика за 2025 год показывает, что окупилось внедрение искусственного интеллекта только в 5% проектов. Остальные 95% проектов заявленных выгод не достигли. Поэтому эффективность ИИ в бизнесе нам еще предстоит доказать.
В нашей компании принято решение: если мы не будем заниматься ИИ сейчас, то через полгода или год будет уже поздно. Поэтому мы проводим эксперименты. Некоторыми их результатами я поделюсь в этой статье.
Контекст проекта внедрения
Большой проект внедрения начался в октябре 2024 года. Это проект внедрения типовой конфигурации «1С:ERP.Управление холдингом» в крупной нефтяной компании.
Мы занимаемся блоком МТО, который включает четыре функциональных направления: планирование, выбор поставщика, склады и управление договорами. В первой волне запуска участвует около 1000 человек из 14 организаций.
У нас уже закончены фазы проектирования и разработки. Сейчас ведется сбор обратной связи, затем будет подготовка к опытной эксплуатации и запуск. Всего с нашей стороны в команде работает около 60 человек.
Мы используем гибридный подход. Крупные этапы для бюджетирования и контракта ведем по Waterfall. Внутри этих этапов применяем итерационный подход, чтобы гибко и адаптивно собирать обратную связь и давать нужный результат.
Все эксперименты, о которых пойдет речь дальше, по сути, стали результатом сбора обратной связи от клиента и брейншторма команды.
Обратная связь как источник изменений
Обратную связь нужно собирать не только от клиента, но и от команды. И команде эту обратную связь тоже нужно давать.
Чтобы нивелировать конфликты, которые возможны на проекте, я рекомендую проводить встречи «один на один». У нас были случай, когда после общения с заказчиком мы договаривались о том, что нужно поменять лида. Встречи «один на один» – очень эффективный способ коммуникации.
Возвращаясь к обратной связи от заказчика: он подсветил, что качество проектной документации на проекте недостаточно высокое. С этого и начался наш первый эксперимент.
Как любая серьезная компания, мы постарались визуализировать образ будущего результата – представили, каким должен быть искусственный ассистент для аналитика и владельца продукта. А если серьезно, то ассистент, с нашей точки зрения, – это усиление и продолжение тех навыков и умений, которыми обладает сотрудник.
Можно вспомнить силовой скафандр из первого «Аватара»: человеческая раса была усилена скафандрами, с помощью которых она «прессовала» местное население Пандоры. Искусственный ассистент должен работать примерно так же – не заменять человека, а усиливать его возможности.
Первый эксперимент: ИИ-ассистент для аналитика
К концу второго этапа у нас накопилось около 200 проектных документов разного рода. Каждый из них прошел несколько версий согласования в СЭД заказчика. У каждого документа было около восьми-десяти согласующих.
Если перемножить это на 10–20 замечаний к каждой версии документов, получается четыре-пять тысяч замечаний. Все они были оцифрованы в журнале учета замечаний. Каждое замечание мы снимали, подтверждали и таким образом согласовывали документы. Получилась большая масса замечаний.
Основные претензии к качеству касались скорости исправлений и мелких дефектов. По содержательной части замечаний не было, но встречались такие комментарии: «Здесь вы неправильно называете нашу информационную систему», «Здесь документ называется неправильно», «Здесь вы ссылаетесь на документ из другой области, и он называется не так».
Все бы ничего, но, если эти замечания выкатывают в последний день перед сдачей этапа, быстро все поправить, учесть, закрыть, подтвердить, а затем еще раз согласовать новую версию становится очень сложно.
Мы собрались с командой, разобрали обратную связь от заказчика и с помощью техники «5 почему» добрались до коренных причин, из-за которых качество документов оказалось не таким, какого хотел заказчик. Нашли в том числе причины, относящиеся к заказчику. На ретроспективе мы аккуратно на них намекнули, но эффект, конечно, был небольшой. Поэтому сфокусировались на том, на что можем повлиять сами.
Мы решили, что с помощью искусственного интеллекта можно улучшить качество документов, в том числе перейти к описанию постановки задач с помощью ИИ-ассистента для аналитика.
Цель эксперимента сформулировали так: повысить скорость постановки задач минимум в два раза, одновременно улучшив качество и точность названий метаданных, реквизитов, справочников, регистров и так далее.
Образ будущего результата – диалоговое окно чата, в котором аналитик описывает содержательную часть постановки задачи. Затем машина некоторое время думает и выдает описание в терминах, понятных разработчику и соответствующих конфигурации. Полученный результат можно сразу отдавать в разработку.
Мы реализовали ассистента на технологии RAG. Создали базу знаний и загрузили в нее около 5000 файлов – всю проектную документацию, материалы встреч и протоколы, накопленные за два этапа.
В качестве LLM используется Qwen, развернутая в облаке VK. Таким образом, мы контролируем периметр, в котором используются проектные документы, чтобы они никуда не уходили вовне. Серверная часть написана отдельно, JavaScript используется на клиенте.
Первые итоги MVP-версии мы подвели в конце февраля 2026. Если честно, желаемого результата не достигли. Скорость улучшилась: мы действительно стали быстрее получать постановки задач. Но точность пока хромает. Результат нельзя напрямую отдавать в разработку – приходится проводить несколько итераций.
Мы договорились потратить на ассистента дополнительное время и провести еще одну итерацию. Придумали техническое решение, позволяющее загрузить в RAG-базу знаний объекты метаданных типовой «1С:ERP.Управление холдингом», чтобы повысить точность.
В дальнейшем планируем использовать ИИ-ассистента для формирования пользовательских инструкций. Это происходит на последней фазе: когда разработка закончена, перед опытной эксплуатацией нужно очень быстро подготовить инструкции.
Возможно, подключим ИИ-ассистента и к формированию протоколов встреч. Обычные ИИ-инструменты достаточно точно делают саммари организационных встреч. Но на технических встречах используются термины, специфичные для клиента. Здесь RAG-база знаний будет полезнее и поможет получать именно тот результат, который нам нужен.
Сейчас мы используем этот инструмент внутри проекта. Если удастся достичь требуемых результатов, в дальнейшем планируем выпустить его на рынок как отдельный продукт.
Второй эксперимент: ИИ-ассистент для владельца продукта
Если первый эксперимент уже находится на завершающей стадии, то ИИ-ассистент для владельца продукта пока только в планах.
Первая проблема, которую мы хотим решить, – точность прогноза календарных сроков. Проект начинается, мы детально составляем план-график, и все выглядит хорошо. Но стоит произойти какому-то сдвигу, например задержаться согласованию документа, как весь план-график приходится быстро пересобирать. Его точность начинает страдать. Затем все перестают обращать на него внимание и работают как попало. Мы считаем, что с этим нужно бороться.
Вторая проблема – точность оценки стоимости и трудозатрат на новые фичи, которые заказчик придумывает по ходу проекта.
Мы внедрили процесс управления запросами на изменения. Я рад, что и заказчик, и команда понимают: любые изменения должны пройти через этот процесс. Он стандартный и несложный. В нем есть обязательный шаг – оценка трудоемкости с нашей стороны и расчет того, во сколько изменение обойдется заказчику. Здесь тоже нужно повышать точность.
Что бизнесу даст точное прогнозирование?
Во-первых, бизнес сможет получать точный прогноз запуска программного обеспечения. Можно будет прямо указывать в контракте: например, 1 сентября мы запускаем в опытную эксплуатацию определенный блок. Сейчас все примерно представляют сроки, но никто не готов подписаться кровью или штрафными санкциями под тем, что запуск состоится именно в эту дату.
Классический пример – публичное пари Илона Маска с администрацией штата Южная Австралия в 2017 году. Компания Tesla пообещала меньше чем за 100 дней запустить батарею мощностью 100 МВт и сделала это быстрее. Это был классный PR-ход. После этого все хотели иметь дело с Tesla, потому что ребята сделали то, что обещали. Мы считаем, что этим тоже можно пользоваться.
Второе преимущество связано с оценкой трудоемкости. Предположим, бизнес планирует получить выгоду от двух фичей. Одна из них более трудоемкая, чем другая. Если трудоемкость оценена точно, естественно, лучше выбрать менее затратную и более выгодную фичу. Благодаря этому бизнес сможет получать больший эффект от внедрения ИТ.
Казалось бы, бери и запускай ИИ-ассистента. Но не все так просто.
Люди боятся, что искусственный интеллект отнимет у них работу. Мы тоже слышим похожие опасения от своих сотрудников. Согласно исследованию BCG за 2025 год, 76% руководителей считают, что сотрудники в восторге от искусственного интеллекта. Но лишь 31% сотрудников с этим согласны. Руководитель пребывает во вдохновении, а люди на местах не очень хотят искусственный интеллект.
Есть и второе опасение. Если какой-то Петя говорит, что сделает разработку за два дня, пусть Петя это и делает. Если искусственный интеллект оценивает разработку в два дня, пусть искусственный интеллект ее и делает. Это перекладывание ответственности.
Вайбкодинг ведет к тому, что скоро искусственный интеллект действительно будет все это программировать. Но пока реалии таковы, что люди должны сами отвечать за свои оценки.
Снимать эти возражения мы планируем с помощью метода Делфи – анонимного опроса экспертов. Модератор в асинхронном режиме рассылает задачу. Эксперт оценивает ее и поясняет, почему получилась именно такая оценка трудоемкости.
Мы считаем, что этот метод можно использовать с участием искусственного интеллекта. Эксперт будет усилен ИИ-ассистентом – тем самым ассистентом «на стероидах». Это позволит постепенно обкатать инструмент и ввести его в практику нашей команды для оценки трудоемкости.
Вторая задача – сменить фокус команды с «успеть сдать заказчику в срок» на «сдать заказчику раньше срока». Если мы будем сдавать проекты раньше, в контракте можно прописывать дополнительные бонусы для компании.
Мы обсуждали с командой, как это сделать. Сейчас у нас есть таск-трекер. Каждая задача разработчика сначала получает плановую оценку трудоемкости, которая фиксируется в системе. Затем задача проходит жизненный цикл в таск-трекере: попадает в спринт и так далее. Исполнитель фиксирует фактическое время работы. После закрытия задачи у нас есть план и факт.
Если загрузить эти данные в RAG-базу знаний по аналогии с ассистентом аналитика, мы получим базу задач: что хотели сделать, за какое время планировали это сделать и сколько времени потратили в действительности.
Мы хотим накопить такую базу, а затем использовать ее для обучения искусственного интеллекта. После этого потребуется провести еще несколько экспериментов и итераций.
«Новые-старые» инструменты
Изобрести что-то революционно новое сейчас тяжело. Но можно взять старые проверенные инструменты и попробовать задействовать их по-новому. Или, зная все их плюсы и минусы, просто попробовать еще раз. Одни и те же инструменты могут работать на одном проекте и не работать на другом. Пока вы не проведете эксперимент, не узнаете, будет от них эффект или нет.
Таск-трекер
Поскольку мы работаем с типовыми конфигурациями 1С, на своих проектах используем «1С:Систему проектирования прикладных решений» – СППР.
Аналитики загружают функциональные и технические требования, описывают задачи и связывают их с объектами метаданных. При этом разработчики тоже должны оперативно получать эту информацию.
Мы взяли решение с открытым исходным кодом OpenProject и доработали его под себя. У него была бесплатная версия Community Edition. Это достаточно удобный инструмент. Интерфейс немного устарел, встречаются некоторые ошибки, но мы к ним уже привыкли.
Мы доработали интеграцию с СППР. Сейчас аналитики работают в СППР и планируют в ней демонстрации: указывают, к какой дате должна быть продемонстрирована каждая задача. Затем данные по интеграции уходят в OpenProject. Там тикет проходит весь жизненный цикл. Разработка завершается, статус возвращается в СППР – и все довольны.
Важный момент: мы развиваем таск-трекер силами собственной команды. Частично тратим проектный ресурс на доработку инструмента, зато можем сделать необходимое изменение за часы, а не за месяцы. При использовании решения от вендора нам пришлось бы ждать, пока инструмент начнут развивать с учетом нашего запроса.
Кроме того, для своих экспериментов, в том числе связанных с искусственным интеллектом, мы можем самостоятельно делать необходимые доработки.
Система взаимодействия
Второе решение я бы назвал не отдельным инструментом, а системой взаимодействия.
Головная боль любого руководителя проекта – коммуникации. Проект начинается, все вроде бы хорошо. Затем как снежный ком накапливаются почта, документы, чаты и звонки. Протокол формируется два дня, а к этому времени уже забываешь, что обсуждали.
Возникают проблемы и с документами. Разные люди начинают редактировать разные версии. Нужно учесть все замечания, затем объединить их в одну версию и где-то все это сложить. Это кошмар, особенно на больших проектах.
На маленьком проекте негатив клиента еще можно как-то сгладить, потратив дополнительный ресурс. На большом проекте потери становятся видны сразу.
Как мы решали эту проблему? Это не реклама, а практический опыт. Мы взяли сервисы «Яндекса», причем по предложению клиента. У него уже были внедрены «Яндекс.Диск» и «Яндекс.Телемост» как канал общения.
Мы начали использовать их внутри проекта и прописали это в плане коммуникаций команды. Сначала это было пожеланием, а затем стало обязательным требованием.
Следом подключили «Яндекс.Документы» и совместное редактирование в браузере. Открыли по ссылке документ на «Яндекс.Диске», вдвоем отредактировали все необходимое и отправили клиенту ссылку на актуальную версию. При этом в документ можно продолжать вносить изменения.
Последним инструментом, который мы запустили, стал «Яндекс.Мессенджер». Когда Telegram начал сбоить, мы решили, что самое время переехать.
В «Яндекс.Мессенджере» есть возможность обсуждать сообщения в тредах, как в Slack. В общем чате задается вопрос, затем обсуждение продолжается в отдельной ветке. Мы начали этим пользоваться.
Но реальность немного сложнее. Разработчики, привыкшие к Telegram, хотят работать в Telegram. У некоторых до сих пор Outlook в качестве почтового клиента. Кто-то работает с локальными версиями документов, и мы с этим боремся. Сам клиент иногда говорит: «Пришлите мне лучше файл вложением. Не люблю Яндекс.Диск».
Здесь нужно находить компромисс и выбирать, в каком виде передавать материалы. Мы договорились с командой, что все проектные документы отправляем только ссылками на «Яндекс.Диск». А статусные презентации и подобные материалы можем высылать вложением, чтобы пойти заказчику навстречу.
Есть еще один удобный сценарий. Мы начинаем обсуждать с командой какой-то вопрос в «Яндекс.Мессенджере». Если обсуждение затягивается, по одной кнопке запускаем вызов для всех, и команда подключается к «Яндекс.Телемосту». Там автоматически выполняются конспектирование и транскрибация. После завершения встречи мы получаем протокол на почту. Мы считаем, что это классно.
Гибридный подход и культура экспериментов
Никаких особых открытий здесь нет. Я считаю, что сейчас работает гибридный подход – сочетание Waterfall и Agile.
На привычные вещи можно посмотреть под новым углом и использовать их иначе. Но нужно помнить, что у каждого инструмента есть свои границы применимости. Только эксперименты дадут ответ на вопрос, повышает конкретный инструмент эффективность или нет.
Сначала нужно собрать обратную связь, в том числе от команды, и посмотреть, где находятся точки роста. Затем вместе с командой использовать методику «5 почему» и добраться до коренных причин, чтобы работать уже с ними.
А все, что будет запланировано, необходимо закрепить за конкретными ответственными и установить сроки – иначе идеи просто уйдут на полку.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт