Берегись бэклога

🔲 Российские компании делают первые шаги в сторону применения искусственного интеллекта. Для многих ИТ-руководителей запуск ИИ-проекта становится задачей, поставленной «сверху».

Вопрос — что именно делать, с чего начать и как не потратить ресурсы впустую?

Ниже — три принципа, которые помогут подойти к ИИ-проектам осознанно: без погони за трендами и с реальными результатами.

1️⃣ Не отказывайтесь от R&D
Важно помнить, что ИИ-проекты включают обязательный этап R&D, который охватывает разработку и проверку концепции (proof of concept). На этом этапе формулируются проблемы, исследуются решения и определяются затраты, что позволяет выявить скрытые риски, способные значительно увеличить бюджет и сроки.

2️⃣ Отталкивайтесь от проблемы, а не технологии
Внедрение ИИ — популярное, но не всегда лучшее решение. Прежде чем запускать R&D, стоит внимательнее посмотреть на бизнес-задачу. Если она решается за счет автоматизации без моделей ИИ — начните с этого. Иначе эксперимент с искусственным интеллектом съест бюджет и время, не дав выгоды.

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

3️⃣ Встраивайте ИИ в рутину
Дайте сотрудникам простой ИИ-инструмент для использования в регулярных задачах — написать письмо, подготовить сводку, получить ответ из базы знаний.

Когда ИИ становится частью ежедневной рутины, команда начинает самостоятельно находить точки, где ещё можно повысить эффективность. Так формируется внутренний спрос на ИИ-решения, которые приживаются в работе, а не делаются «для отчёта» и уходят в стол.

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

⚡️Скоро поделимся best practices по применению ИИ на примере ведущих российских и зарубежных компаний, которые могут вдохновить вас на новые проекты.

Подписывайтесь на Берегись бэклога 💫

Как выбрать подрядчика для разработки ИТ-системы?

В продолжение темы делимся опытом наших экспертов и рассказываем, как грамотно выбрать ИТ-партнера для создания собственного сервиса.

Вот список из 8 шагов, который мы составили вместе со специалистами «КОРУС Консалтинг»: руководителем направления заказной разработки Еленой Никитиной и директором по развитию бизнеса Полиной Ефремовой.

1️⃣ Определите пул потенциальных партнеров для реализации проекта.

2️⃣ Проведите исследование рынка возможных подрядчиков:

➡️ Посмотрите их портфолио;
➡️ Соберите отзывы о компаниях от коллег и в ИТ-сообществе;
➡️ Проверьте репутацию подрядчиков, их присутствие в инфополе, награды и рейтинги;
➡️ Проанализируйте надежность подрядчиков, включая их финансовое состояние и способность выполнить проект в срок.

3️⃣ Направьте потенциальным партнерам Request for proposal (RFP), включив в него требования к системе.

4️⃣ Оцените, обладает ли партнер отраслевой экспертизой. Если подрядчик задает вопросы, которые показывают, что команда не понимает, как устроена ваша индустрия, это тревожный сигнал.

5️⃣ Обратите внимание на то, стремится ли партнер погрузиться в задачу, вникнуть в особенности процессов и разобраться в нюансах того, как система будет использоваться. Задайте себе вопрос, комфортно ли вам общаться с командой подрядчика.

6️⃣ Получите коммерческие предложения и сравните их. Обратите внимание на то, насколько проработана оценка проекта: детализация — признак зрелости подрядчика.

7️⃣ Обсудите полученные предложение с подрядчиками. После того, как вы поймете, что включила в оценку каждая из команд, сможете объективно оценить проект и выбрать оптимального поставщика услуги.

8️⃣ Познакомьтесь с потенциальным менеджером проекта и командой. Это позволит проверить их квалификацию и слаженность работы друг с другом.

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

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

Подписывайтесь на «Берегись бэклога» 💫

💥 Первый совет — выбирайте подрядчиков по ставкам.

Кажется, в ИТ-проектах все просто: сравнили ставку — выбрали подрядчика. Но ставка «₽/час» редко отражает реальную цену проекта. В новой серии «вредных советов» — инструкция, как попасть в классическую ловушку дешевой разработки.

Ваш пошаговый план:

1️⃣ Запросите 3–5 КП в одном формате
Главное — Excel с цифрами. Особенно — колоночка «₽/час». Не отвлекайтесь на кейсы, методику оценки и глубину погружения в бизнес. Это только путает.

2️⃣ Не задавайте уточняющих вопросов
Если оценку прислали за два дня и красиво оформили — уже хорошо. Спрашивать, как считали, какие роли заложены и как выстроят архитектуру? Не стоит тратить на это время.

3️⃣ Допустите, что в ставке — всё
Поддержка, передача кода, рост стоимости часа, риски — всё наверняка включено в 666 ₽/час. Если подрядчик просит уточнить — он просто осложняет вам жизнь. Нормальный подрядчик сам знает, как лучше для вашей компании.

⚡ А если серьёзно…
Когда выбор идёт только по ставке, теряется главное: подход, зрелость команды, контроль сроков. Итог — расходы на исправления, доработки, управленческая боль и потерянное время.

📌 Поделитесь в комментариях:
Случалось, что ставка казалась выгодной, а вышло наоборот? Какой урок вынесли?

Или просто напишите: «было». Мы поймём.

⚡️ Запускаем новую рубрику

Редакция «Берегись бэклога» вдохновилась «Вредными советами» Г. Остера и запускает серию постов-инструкций, которые точно не приведут вас к успешному ИТ-проекту.

❌Мы часто наблюдаем закономерности в ИТ-проектах:
— ТЗ на три тома
— растянутые согласования
— проекты без внутреннего заказчика

Они повторяются в разных компаниях и командах — настолько часто, что захотелось взглянуть на них с другой стороны.

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

Следите за серией. И улыбайтесь 🙃

Применение ИИ в бизнесе сейчас популярно, перспективно и на первый взгляд — просто. Однако запуск ИИ-проекта — это не про «прикрутить модель» к процессу. За видимой простотой кроются неочевидные издержки на полноценную систему: этап R&D, аренду ИТ-инфраструктуры и формирование команды. Если игнорировать эти факторы на старте, есть риск недооценить масштаб задачи и сжечь бюджет задолго до первых результатов.

❗️Как избежать негативного сценария?

При расчёте эффективности ИИ-проекта учитывайте не только прямые затраты на разработку, но и скрытые ограничения — финансовые, технические и организационные. Рассказываем, с чем придется столкнуться.

Ключевые ограничения ИИ-проектов:

📌 Команда
Реализация требует выделенной команды. Ее состав будет отличаться в зависимости от типа проекта. Так, для усиления любой команды нужны дата-инженеры и архитекторы. Дополнительные роли для LLM-проекта — LLM-инженеры или prompt-инженеры. Для ML-проекта — ML-инженеры и MLOps-инженеры, которые обеспечат CI/CD и деплой моделей. Это новые роли, которых текущем штате часто не бывает. При этом рынок — перегрет.

📌 Инфраструктура и данные
Если используются чувствительные данные, то размещение модели внутри ИТ-контура компании становится обязательным. Это значит, что нужно дополнительное ПО, оборудование, сопровождение — в общем, снова увеличение бюджета.

📌 Оборудование
Современные ИИ-сценарии могут требовать использования особого оборудования типа GPU и TPU, графических и тензорных процессоров. При этом LLM-проекты гораздо более требовательны с точки зрения количества и мощности процессоров, чем ML-проекты. Поэтому, если ваш проект связан с языковыми моделями, инфраструктурные требования к нему возрастут в разы. А поставки оборудования ограничены санкциями, квотами и перегруженными производственными цепочками.

📌 R&D и качество результата
Модель редко дает ожидаемый результат с первого раза. Поэтому в план ML-проекта стоит закладывать время и финансы на обучение модели в несколько итераций. В случае с LLM чаще используют дообучение или адаптацию модели через fine tune, prompt engineering, RAG, а не полное обучение с нуля. Но даже такие подходы требуют ресурсов и экспертизы.

Кроме того, если проект использует языковые модели (например, ChatGPT, Claude, GigaChat), возможны так называемые «галлюцинации» — убедительные, но ложные ответы. Это особенно критично в сценариях с высоким уровнем доверия к модели и требует отдельной проработки.

⚡️Учитывая эти факторы на старте, вы получите реалистичный расчёт окупаемости — и сократите риск того, что проект остановится в середине пути.

Подписывайтесь на Берегись бэклога 💫

Channel photo updated

Channel created