Каша с мюслями

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

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

ИИ вне разработки

В прошлых постах много писал про разработку. А что поменялось в процессах других отделов?

Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев было попробовано много инструментов.
Начиналось все, как думаю и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, начали обсуждать с ChatGPT свои сделки.
Сами лиды при этом лежат в CRM, сметы считаются в таблицах, кп готовится в фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнерами, клиентом, технической командой и тд.

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

Поэтому мы продвинулись чуть дальше. Но перед этим нужно понять классические проблемы отдела продаж (не только наших). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора кп, синхронизация с командой, все это приводит к длинному онбордингу, на который накладывается еще и длинный цикл сделки и в итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в:
контактах в CRM
отработанных лидах и кейсах (которые часто неструктурированы и разбросаны по системам)
всяческих шаблонах и готовых упаковках
опыте конкретных людей

Соответственно, чтобы выходить на новый уровень качества/скорости, нужно усиливать эту капитализацию с ИИ.
Все перечисленные пункты на самом деле раскладываются на 2 задачи:
накопление знаний (четкая структура, быстрый и простой доступ)
типовые кросс-командные решения

Поэтому первое, что мы сделали — ии-агента с поиском по нашим решениям. Позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, больше нескольких сотен и никто не знает про все). А второе — агент, который позволяет оценивать уровень качества кп по оформлению и принятым практикам. Таким образом регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему.

Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с gpt и еще кучу всего делает. А тут ему еще одну вспомогательную систему дали. Мотивации туда заходить не так много. А новые инструменты добавляются централизовано, а значит долго и не извлекают экспертизу и знания конкретного сейлза в общие практики. А артефакты подготовки конкретного кп все также передаются в гугл-папках, CRM, чатах и тд.

И тут становится понятно, что эти проблемы давно решены в разработке:
— экспертиза, знания и правила - это скиллы для ии-агентов
— общее хранилище данных - репозитории, где работают все инженеры (вместе с им-агентами) в одном контексте
— генерация артефактов с кодинговыми агентами работает лучше всяких чатов с gpt.

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

Мы сделали один общий git-репозиторий для продаж. Он содержит:
Схему данных о клиентах и их заявках для накоплениях всех артефактов о заявках
mcp CRMки
набор скиллов для работы с кодинговыми агентами

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

Стримы, как зона ответственности

Глядя на предыдущий пост, становится понятно, что зона ответственности должна быть в размере объекта поставки специалиста — что «под ключ» может сделать специалист. Если атомарной задачей может стать фича целиком, то это и есть новый объект поставки.

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

В мире, где опытный специалист может с клодом сделать фичу так, как он хочет, быстро и почти автономно (реальный кейс нашего архитектора — 39 часовой околоавтономный рефакторинг проекта  с fable 5), этому специалисту просто не хочется дробить задачу и объяснять детали младшим специалистам, а потом за ними проверять, и все это с большой задержкой (часы / дни) вместо минут у клода.

Но у этого специалиста все еще остается ограничение — контекстная вместимость и приоритеты. Он не может удерживать в голове 10 разнородных треков. Даже 3 уже сложно. А значит ценно для такого старшего специалиста полностью передать один из этих контекстов на младших специалистов. То есть, чтобы они взяли «под ключ» какой-то из стримов. Сложность этого стрима очевидно должна быть соразмерна грейду специалиста. Как и размер объектов поставки в рамках этого стрима.
И поэтому в новой матрице грейдов мы сфокусировали внимание и конкретизировали не только блоки по разработке (техническим скиллам), но и блоки по работе с требованиями, ответственностью и самостоятельностью в достижении бизнес-результата.

Эти мета-скиллы всегда были важны, но часто по моим наблюдениям (не только нашей компании) им предавали меньшее значение, чем технике.
Сейчас значение этих скиллов будет расти вместе с упрощением / ускорением разработки.

Поэтому мы плавно меняем матрицу и фокусируемся на них уже сейчас в развитии и обучении.

Монорепы на пути к AI SDLC

В прошлом посте рассказывал про то, как мы перенесли документацию в гит и сделали удобный инструмент согласования бизнес-требований с заказчиками.

Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта.

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

Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет.

Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предудыщий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты.
Это гарантирует синхронизацию артефактов между собой, сократит время на менеджмент подзадач, позволит агентам точнее выполнять задачу.

Идеальный процесс тогда может выглядеть так:
– Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы.
– Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг)
– Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе.
– Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе.
– Ветка проходит ревью у тимлида целиком.
– Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты.
Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже.

Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике.

Спецификации на пути к автономной разработке

В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО.
Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить) и масштаб компании дает как преимущества, так и создает проблемы.
С одной стороны мы видим очень много разных проектов. Это дает возможность проанализировать их и найти общие паттерны, выработать общие подходы к разработке, стараться автоматизировать их. С другой стороны внутренние инструменты, которые мы создаем, должны отвечать требованиям очень разных команд. Нет возможности срезать углы и закастомить под конкретную команду — всегда должно быть общее решение.

Теперь вернемся к AI SDLC. По моему мнению сейчас не столь важны инструменты, сколько создание общей среды для агентов и людей. Накопление знаний и создание общего контекста. LLM меняются, инструменты меняются, данные и знания остаются.

Это значит, что первая задача, которую надо решить на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты.
И первая задача, которую все решают при создании ПО — сбор бизнес требования. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдает требования обычно обрывочно и неструктурировано. Их нужно собирать с заказчика, анализировать и на основе них синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа Гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и тд.
Но даже после согласования документации есть не менее объемная задача поддержания документации в актуальном состоянии.
И при этом хочется, чтобы конечные доки лежали в том же месте, что и код и другие артефакты по проекту. Тогда и получится максимально использовать агентов для последующей генерации уже технической спецификации, кода, тестов и тд.

В целом, работать через mcp с теми же гугл доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с агентом. Он должен указать документ, с которым работает, изменить его (например, автоматически обработать комментарии заказчика) через mcp часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл докам, который умеет обработать комментарии, внести правки в режиме предложений. Но этого все еще недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория.

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

Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе и она автоматически попадает в репозиторий, где ее же и использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации.

Но мало сделать, надо еще и внедрить. Для внедрения мы сделали простой yaml-конфиг, описывающий структуру документации в репозитории. Разработчикам / аналитикам нужно добавить только этот конфиг и репозиторий автоматически покажется в интерфейсе сервиса для просмотра и согласования документов.

Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI-SDLC.

Корпоративное ПО в эпоху AI

8 месяцев назад мы с коллегами обсуждали выбор ПО для автоматизации части внутренних процессов. Мы были в классической ситуации, которую сами помогаем решать нашим клиентам: каждый отдел использует свои инструменты разного уровня автоматизации, от экселек с аппскриптами до специализированного ПО под конкретные задачи. Типичная «лоскутная автоматизация». Мастер данные при этом не хранятся в единой системе: сотрудники в 1С, клиенты в CRM, финансы в агрегаторе, отчетность в таблицах, ДО и КЭДО в отдельных сервисах, управление проектами в трекере. Все это помазано сверху самописными сервисами, которые перекладывают данные между системами.

Мы, как и наши клиенты, встали перед выбором: либо делать кастомную систему, либо покупать коробочное решение. Прикинув, что коробочное обойдется скорее всего дешевле, мы начали смотреть варианты. И пока выбирали, я начал переделывать одну из систем для хранения маркетинговых данных с nocode на самописную. А мы все еще выбирали, смотрели альтернативы. Любые из них, как и полагается коробкам, были не совсем подходящими для наших данных и процессов. Мы начали обсуждать как будем натягивать потенциальное решение на текущие системы и что придется поменять в процессах и какие системы придется сделать для синхронизации текущих источников данных.

Тем временем вышел opus4.5, я смог достаточно качественно «кодить» в перерывах между звонками по 5-10 минут, моя самописная система разрасталась и уже покрывала несколько важных процессов. Затем прошел этап внедрения. Часть администраторов проектов стали работать в моей системе. Постепенно к созданию системы подключились и другие разработчики. За несколько месяцев довели продукт до продакшн-уровня, заместили часть текущих систем, выработали подходы к работе и документации для еще более быстрой разработки и даже дали менеджерам делать простые инструменты (не затрагивающие кор-функционал) под себя самостоятельно через согласование спецификаций.

Это дало кратный буст и уже значительно сказалось на бизнесе: от прямой экономии ФОТ (проще всего посчитать в экономике) до онлайн-мониторинга показателей и сокращения времени принятия управленческих решений. Всего за несколько месяцев я увидел, как капитализировалась большая часть нашего опыта, данных, процессов, живущая до этого в головах, документах и разрозненных системах.
Более того, благодаря подключению «нетехнарей» получилось сократить цикл создания ценности в продукте: бизнес-пользователи лучше всего знают свои процессы и теперь они могут не рассказывать аналитикам, а что же нужно сделать, чтобы аналитики написали ТЗ, передали в разработку и тд. Теперь они сами часто пишут тз, согласуют его и реализуют нужный им функционал. (Для скептиков: не пугайтесь, есть гардрейлы и централизованная архитектура, а эффект от распараллеливания кратно превосходит риски).

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

Инженер будущего

Последние 4 месяца активно работаем над формированием образа специалистов, которые должны работать в компании. Этот вопрос пересекается с производственным процессом, потому что именно он диктует формат команд и роли внутри них.
В этом посте позволю себе немного пофантазировать на тему будущего процесса разработки и места человека в нем.

Думаю, что уже сейчас человек является бутылочным горлышком в производственном цикле.
Представим роботизированную линию в каком-нибудь цеху. В нем есть участки, на которых стоят роботы с производительностью 100 изделий в час, но между участками есть этапы с людьми с производительностью 10 деталей. Общая производительность конвейера - 10 деталей.

Классический конвейер разработки выглядит также: аналитика -> дизайн -> разработка -> кодревью -> тестирование -> релиз
Между каждыми этапами есть много административных временных издержек, а какие-то из этапов могут полностью блокироваться человеком.
Стандартный пример — согласование требований. Аналитик написал ТЗ, ждёт согласования заказчика. Оно асинхронное и даже одна итерация правок может занимать от 1 дня до недели.
Это не создавало проблем раньше, тк одно согласованное ТЗ, даже если на него уходила неделя, создавало большой объем работы на следующих этапах. Соответственно общая производительность зависела от производительности «участка» разработки.

Сейчас же скорость создания артефактов в каждом участке, включая разработку, выросла в разы. И узким местом стали согласования, проверки качества и тд. То есть все, что делает человек между участками производства.
Какой смысл от того, что я могу написать ТЗ за 1 час вместо 6, если для согласования мне все равно придется подождать минимум день? Или какой смысл от быстрого написания кода, если мне нужно ждать кодревью от другого человека (при том, что его еще и завалило сверху бОльшим количеством ревью)?

Текущие инструменты в основном применяют для ускорение участков, но не на пайплайна целиком. В такой конфигурации можно получить прирост общей производительности в единицы или в лучшем случае пару десятков процентов, если «был запас». Но кратный прирост не получится.

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

Тогда роль «инженера будущего» в постоянном улучшении и ускорении пайплайна. Фактически как сейчас CI/CD, только в качестве шагов — агенты, которые делают те или иные проверки, вносят изменения в создаваемый продукт, а инженер отслеживает, в чем агенты ошибаются и изменяет самих агентов, или добавляет новых, чтобы в будущем система не допускала таких же ошибок.

Тогда разработка — это полностью продукт агентов
А продукт инженера будущего — это анкетная система по автономному предсказуемому произведению цифровых продуктов с заданным качеством.

Ограничения ИИ (человека?)

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

Основное ограничение, которое я увидел, это не «умение ставить задачи», а ограничение самого человека. То есть ИИ ограничен мышлением того, кто с ним работает. Нельзя получить результат лучше, чем сделал бы сам человек.

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

Из этого следует интересный эффект, который я также наблюдаю при общении с разными руководителями. Они начинают сравнивать (даже явно, если более прямолинейны) результат специалиста с «дефолтным» результатом от модели. То есть модель уже задаёт некоторый бейслайн качества и ожидание от человека.

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

Фазовый переход

В разработке цифровых продуктов уже произошел.

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

Сейчас мы переходим на следующий слой: работа с функционалом. Теперь атомарной единицей поставки инженера перестал быть код, работа или какой-то артефакт. Теперь объектом поставки должно сразу являться решение бизнес задачи.

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

Что это значит с точки зрения скиллов? Это (как и раньше) требует:

1. Высокой технической квалификации (архитектура, системное мышление, фундаментальное (а не специализированное) образование с обучением базовым принципам, а не конкретным технологиям.

2. Высокой насмотренности и «продуктовой чуйки»

3. Понимания бизнесового контекста и смежных направлений (экономики, продаж, …).

Что это значит с точки зрения образования?

1. Невыгодно учить начинающих специалистов конкретной специализации. Начинающие специалисты должны сразу учиться «в широкую» фундаментальным принципам создания ПО. Как в универе, хотя тогда казалось, что это бесполезно.

2. В образовании должно быть больше фокуса инженеров на бизнесе и продукте помимо технологий

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

Такие вот мюсли на сегодня.

Программисты не нужны(?) 3

Всего 8 месяцев прошло с последнего поста на тему замены разработчиков ИИ. Как и в прошлый раз я снова ошибся со сроками. Сначала было 10 лет, потом 5, теперь я думаю, что самые инициативные компании сменят парадигму уже в этом году, а более инертные в течение 2-3 лет.

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

Производство цифрового продукта состоит из множества этапов. Каждый из них традиционно делает свой набор специалистов. Чтобы дойти до разработки, нужно сначала, чтобы бизнес аналитик собрал требования, провалидировал их, ЛПРы все согласовали, системный аналитик запроектировал решение, архитектор(ы) согласовал, дизайнер нарисовал, артдир отревьюил, лиды разработки декомпозировали на задачи и тд. И всем этим дирижируют ПМы с продактами. Это долгий, сложный и дорогой пайплайн. И если раньше казалось, что ИИ просто ускоряет каждого специалиста внутри этого пайплайна (очевидно), то сейчас ощущение, что ИИ может стирать границы между этапами и таким образом ускорять весь пайплайн целиком.

Стандартный пайплайн довольно дорогой и не всегда эффективный. Но:
1. Предсказуемый. Четкие этапы, четкие зоны ответственности. Проблему «ответственности» или владения задачей / этапом ИИ не решает.
2. Экономит время более дорогих специалистов. Опытные разработчики или архитекторы вполне могут составить продуктовые требования и запроектировать всю систему на бумаге. Но их время дороже, чем время аналитика. Плюс вместо этого они могут заняться своими задачами, которые аналитик не сделает. Теперь же благодаря ИИ временные затраты на написание чего бы то ни было (например, тех же ТЗ) существенно сокращаются. Настолько, что написание одним специалистом с последующей передачей контекста другим становится непозволительным оверхедом.
3. Узкие компетенции в нетиповых случаях. Конечно, есть много ситуаций, где нужны узкоспециализированные высококвалифицированные специалисты: высоконагруженные системы, уникальные кейсы, специфика технологии / класса систем и тд. Поэтому специализация важна. Но ИИ существенно поднимает компетенции в узких технологиях при наличии общей высокой квалификации у специалиста. Раньше фронтендер вряд ли написал бы bash скрипт, а сейчас сможет. Так что этот пункт я бы закрыл ИИ на половину.

Итого из 3 пунктов ИИ закрывает 1.5, 50% причин (по версии автора данного канала) наличия сложного, долгого и дорого пайплайна производства нивелируются ИИ инструментами.

Ну и что дальше? Ценность написания кода, документации, тестов и прочих артефактов существенно снижается. (При этом ценность результата не меняется, это важно, но не для этого поста)

Вот следствия:
1. Специализация (например, бекенд или devops) важна только для самых сложных кейсов, нетиповых и уникальных задач, которых в обычной жизни бывает не более 10-20%. В общем случае специализация не должна иметь значения, тк опытный инженер должен уметь сделать 80% результата самостоятельно. Фронтендер, просто пишущий код и «заблокированный бекендом» драматически теряет ценность.

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

3. С точки зрения продукта: растет ценность понимания, как решить продуктовую задачу лучшим образом. Не подождать, пока продакт с аналитиком и кто угодно еще все придумают, а самостоятельно запроектировать продуктовое решение исходя из потребностей бизнеса. А затем его еще и реализовать (см предыдущий пункт)

4. С точки зрения бизнеса: определить, а что вообще нужно, чтобы потом переложить это на продукт (см предыдущий пункт)

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

Потенциал

Последнее время, когда в компании стало 200+ человек, я все чаще стал задумываться над драйверами роста. Как поддерживать рост и масштабироваться дальше?
С одной стороны многое меняется, становится более зрелым, а с другой стороны более зрелые процессы неизбежно накладывают отпечаток на эффективности. Вопрос: как найти грань, когда процессы все еще помогают (делают контролируемее, управляемее, стандартизованнее и тд), но еще не становятся бессмысленной «обузой» (а часто это не так просто распознать).

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

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

В итоге для себя я сформулировал это так, что есть некая шкала качества/результата, можно назвать как угодно. И у этой шкалы есть 2 планки. Одна — процедурная — ограничивает шкалу снизу. Ниже нее мы не можем падать в выдаваемом результате и ее обеспечивают наши процедуры и лучшие практики, которые мы вырабатываем годами. Вторая — человеческая — ограничивает наш потенциал сверху. Мы не можем прыгнуть выше, чем лучшие профессионалы в нашей команде.

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

Должности и роли

У нас в компании 5 основателей, которые работают вместе уже 10 лет. И каждый раз, когда люди узнают этот факт, они удивляются и спрашивают:«как вы распределяете обязанности».

На этот вопрос у меня никогда не было четкого ответа: ну как-то распределяем, причем жесткой привязки к направлениям нет, то есть все занимаются всем. Иногда «должности» меняются в зависимости от того, что больше горит/болит/драйвит у каждого.
Раньше я думал, что наверно это неправильно. Должно же быть какое-то четкое разделение обязанностей. Но при этом как-то ведь оно у нас работает, работает неплохо и даже более того, оно воспроизводится ровно в таком же формате в командах внутри.

И недавно, мой более опытный коллега (подписывайтесь на его канал, кстати, не реклама), помог найти недостающий пазл. Каждый из нас не закрывает какую-то конкретную должность, но берет на себя какую-то роль, в которой он силен, и мы интуитивно распределяем зоны работы так, чтобы в каждой зоне оказывался человек с наиболее подходящей под текущие потребности ролью.

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

Итог такой, что неважно, какие конкретно «должности» занимает человек. Важно, чтобы его роль или сильные стороны хорошо комбинировались с ролями его партнеров и получалась синергия.

Моя критическая функция

Из предыдущего поста плавно вытекает то, что и у себя самого тоже есть критическая функция.
Одна из частых проблем, с которой сталкиваются известные мне руководители, включая меня, это пренебрежение критической функцией в пользу других задач. У каждого руководителя есть задачи, которые может выполнить только он, управленческие. Например, у меня это может быть найм ключевых специалистов, ведение ключевых клиентов, запуск новых продуктов и услуг или поиск партнерств. Такие задачи исключительно моя работа. Но вместо нее я часто скатываюсь в операционные задачи, которые отвлекают от критических, при этом «заполняя» пространство дня.
Обычно это происходит потому что «некому», «мне привычно», «я сделаю быстро» и тд. И очень тяжело себя от этого отучить. А в итоге это все приводит к тому, что «нет времени» и «перегруз».

В чем корень проблемы?

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

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

3. Контролируем процесс, а не результат. Вместо того, чтобы заранее обозначить зоны ответственности и договориться об образе результата, начинаем погружаться в детали и мелочи. Иногда из-за недоверия, иногда просто из интереса. Но в любом случае это нагружает дополнительным контекстом и в совокупности с предыдущими пунктами провоцирует еще больше работы и забирание ее с реальных ответственных за результат.

Что делать? Да хз, вот некоторые принципы, которые я сам стараюсь применять последнее время:

1. Задавать себе вопрос: «эта задача/деятельность точно моя критическая функция?». Если нет, то «почему я это делаю?». Это ок делать что-то, потому что реально некому, или быстрее, или интересно или что угодно еще, главное прийти к этому выводу осознанно и четко понимать, зачем я обменял время, которое мог потратить на свою критическую функцию, на эту новую задачку.

2. Обозначать ответственность на старте и возвращать ее в процессе. Не сажать всех подряд себе на шею, забирая ответственность за результат, а стараться помогать через консультации или конкретные задачи.

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

4. Контроль через результаты, а не задачки. Сначала договорились о метриках или «линейке», которую будем прикладывать к какому-то процессу. Затем регулярно контролируем прогресс по этой линейке, а не управляем конкретными задачами.

Одно из интересных следствий предыдущего поста — удовлетворение процесса такой же критерий успеха, как и получение объективного результата. А неудовлетворение достаточно для прекращения работы.

Раньше я всегда старался объективизировать цели и результаты. Чтобы можно было однозначно сказать, например: прошел ли человек испытальный срок, хорошо ли справляется с работой и тд. Но проблема в том, что вывести объективную метрику не всегда получается. Даже скорее чаще не получается. И вот ты чувствуешь, что «что-то не так», но из-за того, что не можешь вывести объективный критерий, идешь на компромиссы и оттягиваешь неизбежное решение.

Например, нанял человека в команду. Где-то он справляется, а где-то лажает, но вроде что-то делает, старается, вроде дырки закрывает, но все равно что-то не то. И вот он проходит испытательный срок, потому что как будто нет объективных критериев для непрохождения. Потом ситуация повторяется, но ощущение несоответствия ожиданиям растет.

И совсем недавно я (с помощью старших товарищей) осознал, что вот этого ощущения «несоответствия» должно быть достаточно для принятия решения и в этом нет ничего плохого. Конечно, необходимо четко понимать, что хочется получить от человека. И важно, чтобы человеку со старта было понятно, что ожидается на его позиции. Иначе получится самодурство. Но вот это «ожидается» может быть выражено разными способами. Возвращаясь к предыдущему посту, я могу ожидать результат (и хорошо бы он был выражен объективно), но тогда не залезаю в процесс, а могу ожидать соблюдение процесса, который меня удовлетворит. И требование «удовлетворить» уже само по себе достаточный критерий для оценки.

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

Процесс или результат

Последнее время, когда работы и направлений стало столько, что погрузиться в каждое физически невозможно, все чаще начал пользоваться принципом «процесс или результат».

Заключается в том, что нужно четко определить, что хочешь получить от исполнителя (подрядчика, коллеги и тд). Получить всегда можно одно из двух: либо процесс, либо результат. И важно решить для себя и обозначить исполнителю, что нужно.
Затем, если хочешь получить результат, нельзя влезать в процесс, можно только «консультировать» по запросу, не забирая ответственность за решения.
Если хочешь, чтобы исполнитель следовал твоему процессу, то он не может отвечать за результат. Тогда его цель — сделать так, чтобы процесс меня удовлетворял. Но ответственность за результат перетекает тогда тоже на мне.

Этот принцип позволяет договориться об образе результата и критериях его оценки. А еще сохраняет ответственность на исполнителе, если выбрана цель результат.

Использование ИИ

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

В этом посте хотел бы поделиться ключевыми поинтами из нашей беседы с коллегами.

ИИ — это новая технологическая революция, которая поменяет не просто рабочие процессы, но привычные способы работы с информацией, потребления контента и в целом образ жизни. Как интернет или смартфоны. Это нельзя отрицать, а значит, надо направить осознанные усилия на изучение и внедрение.
Наибольшими скептиками являются, как ни странно, старшие специалисты.
Использование само не поедет. Его нужно пропагандировать.

Последний пункт — ключевой. Без пропаганды, демонстрации способов внедрения и активной стимуляции использования новых инструментов никто ниче делать не будет, к сожалению.
Поэтому пропаганда должна идти с самого верха компании.
Другими словами, нужно сделать так, чтобы использование ИИ-инструментов стало новой нормой, как «использование ПК» раньше.

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

OpenAI выпустила подробный гайд как раз о том, как «приучить» команды использовать ИИ.

Ключевые мысли из статьи:
Начинать нужно с малого. Понять, что УЖЕ могут делать готовые инструменты ИИ из вашей рутинной работы.
Есть 6 примитивов работы с ИИ, из которых строятся более сложные сценарии: создание контента, исследования, кодинг, анализ данных, генерация идей и автоматизация.
«Внедрить ИИ» можно с помощью мощной пропаганды и помощи сотрудникам.

В статье рассмотрено много примеров, что можно делать, а также как помочь сотрудникам начать.
Мы, например, проводим внутренние и внешние вебинары. Завтра как раз один из них

Стадии зрелости юнитов

Этот пост для меня, хочется зафиксировать свои наблюдения за последние 4 года, пока я не обнулился.

Первый раз мы разделили производство на 2 юнита в конце 20го года по совету Макса Десятых. Юнит означает самостоятельность и ответственность за экономику, то есть является самостоятельной боевой единицей. Этим он отличается от отдела, который может быть привязан к специализации. Например, дизайн-отдел, который обслуживает другие отделы, но не сам не зарабатывает.

В конце 22 года мы выделили devops-юнит из отдела. То есть начали предоставлять услуги по devops для внешних клиентов, а не только обслуживать внутренних.
Параллельно в то же время запустили наш продукт smartbotpro.ru, который тоже являлся отдельным юнитом.

В 23 году по мере роста стало понятно, что это и есть наша стратегия роста. Компания на 600 человек, это 10 компаний по 60. И мы начали систематизировать опыт создания юнитов. Со временем стало яснее, на какие этапы это декомпозируется, и что на этих этапах важно.

С момента отделения первого юнита прошло уже 4 года, а за последние 2 года мы получили еще несколько портфелей проектов на разных этапах зрелости. Каждым портфелем управляет несколько человек (это важно) — партнеров.

Первая цель партнеров и первый этап — научиться делать проекты и следить за экономикой. На этом этапе проекты «падают» в портфель из компании и в пути проекта от заявки до перехода в работу будущие партнеры (мы назвали их кандидатами) участвуют в роли второго пилота. Их задача — открыть для себя механику работы, научиться отслеживать экономику, работать с планированием, учиться продавать и понять, как устроен бизнес в целом помимо производства.
Здесь они еще совсем не самодостаточные (не могут обеспечивать сами себя) и не самостоятельные (в основном выступают вторым пилотом).

На второй этап совет партнеров переходит, когда команда разрослась, а портфель проектов стабилизировался и достаточно диверсифицирован. Сами партнеры к этому моменту должны уметь закрывать функции производства, HR (найм, обучение, рост), контроля финансов в своей команде.

Следующая зона роста для партнеров — продажи и аккаунтинг. Они должны научиться самостоятельно получать новую работу и балансировать ее с предыдущими блоками (производство, HR).

Как только эти компетенции появляются у партнеров в каком-то виде, они готовы к отделению юнита. Тк выполняются основные критерии: самодостаточность и самостоятельность.

На этом можно остановиться.

Но если не останавливаться, то что дальше?
Дальше партнеры начинают «дозревать» и по другим направлениям бизнеса.
Последовательность «захвата» выглядит так:
Производство -> продажи -> маркетинг
По административным функциям (финансы, бекофис, HR, …) совет партнеров пользуется «услугами» основной компании, как руками, но задаёт стратегию и управляет ее реализацией. И постепенно забирает на себя и эти функции внутрь, если стратегия не может эффективно выполняться «платформой» внутри компании.

Пока что самый зрелый отдельный юнит дошел до такого уровня.

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

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

Программисты не нужны(?)

Год назад написал пост про замену разработчиков на ИИ-ассистентов.
Перечитал, пост не потерял актуальности, единственная ошибка во времени. Я думал, что в запасе лет 10, сейчас уже кажется, что 5 или даже еще меньше. Темп развития Gen AI еще ускорился относительно прошлого года, а порог входа еще сильнее снизился благодаря nocode-инструментам и всяким saasкам вокруг llmок. Вообще, кажется, что навык автоматизации с модельками на n8n для IT-специалистов со временем должен стать таким же базовым, как знание excel. Но это тема отдельного поста.

А тема этого — скиллы, которые остаются востребованными в IT на фоне падения спроса на разработчиков. Это скиллы, которые позволяют реализовывать комплексные проекты.

1. Широкая насмотренность. Важнее не копать вглубь, а знать на достаточном уровне разные подходы, методологии и технологии, чтобы суметь адаптировать их под свой проект. Речь не только про технику, но и про продуктовую насмотренность, и про «бизнесовую» — как работают те или иные бизнес-процессы и что для продукта важно.

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

3. Удержание нескольких контекстов. Отсутствие этого навыка не позволяет развиваться и замыкает специалиста в рамках своего направления. Не позволяет перейти к следующему пункту.

4. Управление командами и стыковка их между собой. Все более важно не просто выполнять задачи или даже лидить команду, а управлять несколькими командами разной специализации. Для этого нужны все пункты выше. Даже если эти команды содержат по 1 человеку в паре с ИИ-ассистентом, создание общего роадмапа, качественная синхронизация работы и результатов — ключевой навык для запуска комплексного проекта.

5. Получение результата из полной неопределенности. Абстрактный пункт. Но фактически вырождается в умение найти путь запуска проекта на основе насмотренности и опыта, собрать роадмап, состыковать несколько команд, постоянно трекать результаты, срезать углы, знать все этапы работы и корректировать планы в процессе. Наверное это то, за что ценят и будут ценить специалистов независимо от степени развития ИИ (но это не точно)

Accountable и responsible

Недавно наш руководитель разработки Виталий скинул подход к делегированию через RACI.
Ключевые слова — это responsible и accountable. Интересно, что перевести на русский можно одним словом — ответственный. Но английское разделение на 2 слова дает совсем другое понимание смысла.

Responsible — ответственный за выполнение задач.
Accountable — ответственный за итоговый результат.

В управлении проектами это особенно важно и мы далеко не сразу поняли разницу. Например, у вас есть команда с крутым тимлидом разработки, крутым менеджером, крутым старшим аналитиком. Каждый из них делает свою работу максимально качественно. Но кто отвечает за общий результат? Кто отвечает за достижение целей проекта / клиента?

На ум сразу приходит менеджер, но это так только на первый взгляд. На практике ответственность (responsibility) менеджера в том, чтобы попасть в бюджет и сроки и сделать реализацию проекта прогнозируемой и системной. Определить курс проекта на старте, когда ничего неясно и есть только расплывчатые требования?
Срезать углы при декомпозиции и оценке задач, потому что на самом деле бизнесовые цели можно достичь проще? Почувствовать пульс клиента на встрече и скорректировать ход проекта, даже если это потребует издержек со стороны исполнителя? Может, предложить продуктовые идеи по развитию или даже настоять на своем решении, чтобы сэкономить деньги клиента или помочь ему заработать больше?
Нет, все это про accountable — ответственность за общий результат. Тот самый ответственный, которому позвонит клиент, если что-то пойдет не так. Тот самый ответственный, которого клиент порекомендует знакомым, потому что именно он ведет проект. «Единое окно» для достижения результата и целей клиента.

Именно поэтому в свое время мы ввели роль «директора проекта». Это не менеджер и не аналитик, не лид и не архитектор. Но это эксперт, который сможет довести до результата проект и удовлетворить клиента.
Важно, что это именно роль. То есть выполнять ее может специалист из любого направления (например, менеджер). Но осознание этой роли и ожиданий от нее и делает человека accountable за проект.