Часть 2. Решение#
Это вторая часть большой статьи-размышления об LLM и вайб-кодинге в руках бизнеса.
Ситуация в IT-проектах, за которыми я наблюдаю, такова, что бизнес хочет быть ближе к разработке, но это приводит к ряду проблем, о которых я рассказываю в первой части: LLM и вайб-кодинг в руках бизнеса - новый вызов IT-проектам
В этой части поговорим о других проблемах, которые скрыты от глаз бизнеса, пока он погружен в код, какие риски это создаёт и какое решение я вижу оптимальным.
Менее явные проблемы вайб-кодинга#
Использование LLM и вайб-кодинга бизнесом порождает и ряд менее явных проблем, которые, тем не менее, обостряют ситуацию в целом. Вот, что бизнес упускает, когда фокусируется на архитектуре и коде проекта:
1. Избыточный функционал в ТЗ#
ТЗ, составленные LLM, часто избыточны и раздувают расходы. LLM не ориентируется в ситуации бизнеса, она не знает финансовых возможностей стартапа, который реализует IT-проект и не стремится сэкономить его бюджет. И даже если попросить её об этом, придётся очень постараться, чтобы передать ей не только цифры, но и ваши намерения и ощущения относительно происходящего. А также дополнить контекст финансово-экономической ситуацией в стране и регионе, рассказать о конкурирующих решениях и т.д.
Пример 1. Один из наших потенциальных клиентов составил ТЗ с помощью LLM, оценка проекта по которому вышла в 30 млн. руб при том, что у клиента было в 10 раз меньше, и описанный в ТЗ функционал ему был совершенно не нужен
В итоге мало кто уделит этому должное значение, потому что вайб-кодинг уж очень увлекает и сулит быстрые и красивые результаты. А последствиями оказываются перерасход бюджетов и затраты, которые выжимают и без того ограниченные ресурсы проекта.
2. Потеря фокуса на продукте и бизнесе#
Увлекаясь погружением в разработку несложно потерять концентрацию на продукте, рынках и решении проблем пользователей. Легко увлечься и перестать думать с позиции реального клиента вашего продукта, поскольку появляется желание внедрить и эту функцию, и тот завораживающий визуальный эффект, и интегрировать с десятком смежных систем. В то время, как клиенту может быть нужно совсем другое, что он в итоге не получит.
А между тем внимание распыляется на неважное, время и ресурсы проекта уходят. Когда их нужно было пустить в усиление продукта и улучшение product-market-fit.
Пример 2. Практически в каждом проекте, реализуемом бизнесом своими руками с помощью LLM и вайб-кодинга, я сталкиваюсь со сложностями приоритезации задач. Всё кажется таким простым в реализации и нужным для проекта, что хочется реализовывать и внедрять. А приоритеты расставляются умозрительно, не опираясь на глубинные исследования ЦА и анализ конкурентов.
Один из проектов на моих глазах закрылся от использования такого подхода, потому что потерял темп, а когда фаундер очнулся, поезд уже уходил, потому что на горизонте появилась масса конкурентов.
Важно помнить, что в век LLM не только вы получаете усиление и ускорение в виде ИИ-агентов. Конкуренты тоже внедряют эти технологии и двигаются в том же темпе. Поэтому преимущество в более раннем старте проекта легко потерять за недели и месяцы фокуса на реализации ненужного функционала.
3. Неизвестный уровень специалистов#
В отсутствие глубокой технической экспертизы реальный уровень команды разработчиков проверить некому, а значит бизнес вынужден выплачивать им столько, сколько они хотят, без возможности этими расходами управлять и не вызывать при этом разногласий.
Неопытному техническому руководителю крайне сложно отличить разработчика уровня junior от разработчика уровня middle. А middle от senior - вообще почти невозможно. Особенно учитывая, насколько сложно сегодня стало проводить технические интервью, когда кандидаты на какие только ухищрения не идут - от использования LLM на втором экране до подсказывающего голоса в наушнике.
Пример 3. Выполняя аудит проектов, я регулярно сталкиваюсь с завышенными оценками на выполнение задач, что сжигает бюджеты бизнеса и приводит к конфликтам, которые можно просто не допустить.
Пример 4. На одном из техинтервью я явно слышал, как фоновый голос подсказывал кандидату ответы на мои вопросы. Кандидат неловко делал вид, что думает, а когда получал ответ, иногда нелепо проговаривал вслух что-то типа “- А, да!” и начинал отвечать.
Когда я обратил его внимание на то, что всё слышу и задал вопрос о том, что за голос у него на заднем плане, он ответил, что ничего нет и продолжил как ни в чём не бывало. Но после этого всё пошло ещё хуже, и даже голос перестал ему помогать. Знаний у него было примерно ноль.
4. Неэффективность сопутствующих процессов#
Разработка – это не только архитектура и код, но и процессы управления, командной работы, распределения задач, выстраивания коммуникации и часто без опытного технического руководителя они выстроены крайне неэффективно.
Пример 5. В одной из компаний я столкнулся с нетипичной коммуникацией руководства и процессом распределения задач, где любой разработчик мог выполнять задачи на любом проекте, а управление командой и распределение задач осуществлял нетехнический руководитель. В итоге это вело к неявным проблемам, о существовании которых бизнес даже не догадывался и считал естественной текучку кадров и некачественное выполнение ими задач, в то время как команда ощущала демотивацию, кто-то уже выгорел, а другие выполняли свои задачи спустя рукава.
Решение – внешний CTO#
В первой части я говорил о 2 вариантах решения возникающих проблем:
Продолжить ещё глубже погружаться в разработку - по сути, стать техническим руководителем своей команды. Что совершенно нереально, если только вы не хотите с этого момента поменять свою роль и основательно обучиться IT.
Вернуться на бизнесовый уровень, а разработку оставить разработчикам, выстроив управление силами технического руководителя.
И если бизнес всё-таки решит встать на путь управления силами технического руководителя, то таким руководителем может стать внешний CTO. Что меняется при его входе в проект:
- доверие бизнесу восстанавливается
- каждый начинает заниматься своим делом
- бизнес ставит задачи на бизнесовом языке
- разработка предлагает техническую реализацию
- разработка берёт ответственность за архитектуру и код
- CTO зарабатывает доверие и уважение в команде
- Эффективность управления разработкой повышается
- Расходы снижаются, а темпы внедрения нарастают
- Команда знает, что за процессом следит взгляд опытного CTO
- Ощущение контроля у команды усиливает её эффективность
Кому это подойдёт#
Если в вашем проекте всё пока ещё не так, как перечислено выше, и вы ощущаете, что процесс разработки слабо управляем и не очень предсказуем – возможно, вам стоит посмотреть в сторону смены подхода. Иначе вы рискуете скатиться в технические нюансы и перестать заниматься бизнесом. Потому что разработка софта – очень широкая и динамичная сфера. А LLM создают невероятно обманчивую иллюзию того, что это так просто – написал промпт и получил результат.
На старте это действительно может начинаться примерно так. Но если вы уже вышли за этап MVP, у вас есть клиенты, и вы всё ещё управляете командой разработчиков самостоятельно, то, скорее всего, теряете в эффективности и увеличиваете риски вскоре утратить контроль над проектом.
Задачи CTO#
Между тем внешний CTO решает целый ряд ключевых задач:
- Аудит архитектуры. Выявление узких мест и технического долга.
- Оптимизация процессов. Внедрение Agile, DevOps, CI/CD.
- Управление командой. Восстановление мотивации и ответственности.
- Стратегическое планирование. Дорожная карта развития продукта.
- Коммуникация с бизнесом. Перевод бизнес-задач на язык разработки и обратно.
Как понять, что проекту нужен CTO?#
Идентифицировать необходимость помогут следующие признаки:
- Разработка постоянно срывает дедлайны, а бизнес не понимает почему.
- Команда жалуется на нереалистичные требования или отсутствие ясности в задачах.
- Бизнес тратит больше 20% времени на обсуждение технических деталей.
- В проекте накапливается технический долг, но нет ресурсов его закрыть.
- Продукт работает нестабильно, а клиенты жалуются на баги.
Внешний CTO или штатный?#
Уровень зарплатных ожиданий хорошего штатного CTO – это сотни тысяч рублей. У молодого проекта, как правило, таких бюджетов нет, а потребность уже есть. И единственный способ закрыть её без рисков – это хороший внешний CTO. Здесь возможна работа в формате проектной, почасовой занятости по запросу или на решение конкретных задач. При этом вы привнесёте в компанию глубочайшую экспертизу руководителя, посвятившего свою жизнь IT и разработке и знающего её до винтиков.
О моём пути к роли CTO#
К слову, на данный момент я 25 лет в разработке, и первую свою позицию CTO я занял спустя ни много ни мало – 13 лет от начала пути в IT. Сейчас у меня почти вдвое больше опыта, и я понимаю, что тогда был лишь технически подкованным разработчиком, только начинающим свой путь в управлении командами и едва-едва погружающимся в бизнесе.
Сейчас же это сменилось уверенным общением как с бизнесом, так и с его клиентами, способностью глубоко анализировать требования к системам как в разрезе бизнеса, так и их техническую реализацию, чтобы формулировать задачи на понятном разработчикам языке и добиваться их корректного и своевременного выполнения.
Приходите за услугой внешнего CTO и воспользуйтесь моим опытом. Он уже сэкономил время, нервы и деньги многим моим клиентам – IT-компаниям и стартапам.
Авторы
Юрий Абдуллин @yury_eaCCO/CTO, IT-предприниматель, ментор IT-стартапов.
25 лет в разработке информационных систем (обо мне)
Открыты к новым проектам
Выполняем профессиональную разработку информационных систем, сервисов и платформ:
- дорабатываем MVP до полноценных систем
- проектириуем и внедряем ИИ-агентов
- проводим аудит кода и процессов
- обеспечиваем качественный QA и DevOps