Почему ИИ нельзя внедрить как ERP, нельзя раздать как Office, и что тогда остаётся

В ТЗ на «внедрение ИИ» перед самым конкурсом вписали маленький пункт: перевести перевод внутренних документов с ПРОМТа на нейросеть. Документы конфиденциальные, в облако нельзя, а то, что влезает в закрытый контур, испытаний не проходит — и контракт на десятки миллионов повис на одном абзаце. Разбираю, почему ИИ нельзя внедрить как ERP и нельзя просто раздать как Office, что реально влезает в контур (с ценами в рублях), и как мы вытащили задачу из клетки, которая не закрывается ничем.

Почему разовую задачу теперь можно автоматизировать — если её дёшево проверить

Сорок лет нас учили: автоматизировать надо рутину. Это был не закон автоматизации, а закон окупаемости — разработка стоила дорого. ИИ сделал её почти бесплатной, и переменная сменилась: не повторяемость, а проверяемость. Разбираю на миграции, которую «нельзя было автоматизировать».

Есть положение, в котором у вас есть всё, кроме возможности что-либо изменить. Вы видите, что проект идёт не туда. Вы можете это доказать — цифры, переписка, уехавшие вехи. Вы говорите об этом на каждом статусе. И не происходит ничего.

Это не про плохих людей и не про слабого руководителя. Это устойчивая конструкция, у неё есть условия возникновения и предсказуемое поведение. Складывается она везде, где отвечать приходится одному, работу делает другой, и другого нельзя заменить.

Обычно это подряд. Но не обязательно: если вы отвечаете за результат программы, а люди, которые её делают, вам не подчиняются, — конструкция ровно та же, только без договора.

Дальше — из чего она состоит, почему из неё не выйти доказательствами и что оказалось единственным работающим. Одна моя попытка выбраться провалилась; про неё тоже.

Чистых случаев не бывает. Никто не приходит к этому решению с пустым бэклогом. Приходят так: два старых проекта ещё дышат — мелкие доработки, лицензионные отчисления, поддержка по договору. Деньги идут. На команду их не хватает, но они идут — предсказуемо, каждый месяц, в одну и ту же дату. Плюс переговоры, и не одни: вероятность, что хотя бы одни закроются к осени, кажется вполне приличной.

Баланс отрицательный, и это видно. Но отрицательный он не на всю сумму фонда оплаты труда, а на разницу. Разница выглядит преодолимой. Именно поэтому решение откладывается: будь поток нулевым, его приняли бы в первую неделю.

Так что вопрос звучит не «всё кончено, что делать», а гораздо мягче: ждать новые проекты или сокращать?

Дальше — о том, почему этот вопрос поставлен неправильно и почему цена промедления начинает начисляться заметно раньше, чем кончаются деньги на счёте.

Оговорка на входе. ИТ-рынок труда сжимается, о причинах спорят — конец импортозамещающего цикла, стоимость денег, сжатие корпоративных бюджетов. Этот текст не о причинах и ни одной из них не защищает. Он о том, как устроено одно управленческое решение в уже сжимающемся рынке.

Мне понадобилось разобраться, что происходит на большом проекте внедрения: почему сроки едут и куда девается ресурс. Разработку вела внешняя команда, живьём я её не вёл и контекста не имел — на руках были только следы: трекер, вики, гит, списания времени.

Начал я с самого очевидного — померить, кто из аналитиков сколько делает. Провозился неприлично долго, получил красивые графики и всё выбросил. Дальше — почему выбросил и что нашлось, когда я перестал смотреть на людей.

Сразу оговорюсь про две вещи. Первая: это не статья про оценку эффективности сотрудников, скорее наоборот — про то, почему у меня не получилось её написать.

Вторая — про сам кейс. Он тяжёлый. Спринт вдвое больше собственного лимита, треть незавершёнки без движения месяцами, задачи с семнадцатью сменами исполнителя. Нормальным этот проект не был, и типичным я его не выдаю. Полезен он ровно этим: в здоровой команде все описанные ниже эффекты тоже есть, но дают процентов пять и потому не видны. Здесь они дают триста и становятся различимы. Это стенд, а не образец, и интересен тут метод, а не кейс.

Десять человек на совещании: пятеро со стороны заказчика, пятеро со стороны подрядчика. Полтора часа обсуждают три поля в экранной форме. Не архитектуру, не интеграцию, не модель данных — три поля. Сначала долго не могут понять, что означают цифры в них. Потом понимают: одно число складывается с другим и должно давать третье. Договариваются переименовать поля и переставить их в логичном порядке. Попутно выясняется важное: корректировка данных не обязана делаться через сторно с повторным вводом, это может быть отдельный процесс.

Полтора часа на десятерых — пятнадцать человеко-часов. Само исправление занимает полчаса работы аналитика с разработчиком.

Обнаружение дефекта обошлось в тридцать раз дороже, чем его устранение. И это ещё удачный случай: дефект хотя бы всплыл.

Ключевое здесь не в том, что кто-то поленился. Ключевое в том, что до совещания в систему не заглянул никто. Ни один пользователь не открыл форму и не посмотрел на неё с интересом. Если бы посмотрел — те же три поля стоили бы тридцать минут переписки.

Проект к этому моменту шёл третий год.

Ситуация с пандемией и резкий переход всех в онлайн заставил нас срочно переводить привычные мероприятия в полностью онлайн формат. В частности, хотелось бы поделиться своим совсем свежим опытом по проведению сессии стратегического планирования в дистанционном режиме. Регулярные сессии стратегического планирования мы начали проводить шесть лет назад. Сначала мы делали одну сессию в конце года, но недавно перешли на более гибкий формат с одной годовой сессией и тремя промежуточными для пересмотра и корректировки стратегии. В частности, на такой очередной сессии в конце 2018 года и было принято решение об инициации стратегического проекта по созданию в компании условий для удаленной работы. Эта тема достойна отдельного разговора, кому интересно, есть краткое видео и несколько материалов.

Объявили в городе выставку ослов. Огородили место, продали билеты люди пришли, побродили немного и спрашивают друг друга:

— А где же ослы?

И вышел, как оказалось не в дверь, а в окно:)

Есть ли сейчас вакансии?