Это создаст проблемы

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

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

Стоит помнить, что любое решение для кого-то будет хорошим, для кого-то плохим. "Оптимум" - это когда при прочих равных влияние недовольных на продукт минимально.

Получать результат за единицу времени

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

Как получать ценность в каждую единицу времени? Я использую три способа:
1. Ценность пользователя транслируется всей команде.
Это происходит, в первую очередь, на уровне языка. Даже программисты разговаривают терминами, понятными пользователям. Например, названия модулей, блоков или частей продукта совпадают с названиями ролей пользователей. Пусть даже код лежит в одном репозитории и изменяется под задачи пользователя настройками зон видимости.
2. Постановка задачи должна включать ответ на вопрос "чтобы что?"
Это и расширяет трансляцию ценностей, и даёт любому участнику команды правильный ценностный контекст. "Я, пользователь, хочу отчёт, чтобы показать руководителю динамику своей работы". "Я, пользователь, хочу отчёт, чтобы выстроить приоритеты для собственной деятельности". Почувствуйте разницу в контекстах.
3. Не надо делать слишком хорошо. Сделай нормально, но сделай.

В кейсе про трекер, конечно, главной ценностью было, в итоге, соблюдение SLA и снижение потерь от инцидентов. Но за один прыжок в неё не попасть, это игра в долгую. Плюс, надо не забывать, что в таком продукте основную ценность приносит не ИТ-программа, а процессы, которые выстраиваются вокруг автоматизированного workflow. На первой итерации мы действительно просто развернули трекер. У нас не было настроенных процессов, в форме была куча ненужных или непонятных полей, не всегда было понятно, кому маршрутизировать заявку. Но мы работали на одну метрику - 100% заявок должны получить ответ. Мы её выполнили, пользователи нам поверили. Поверили, что мы можем не только показывать красивые картинки. А мы получили опыт, который потом трансформировали в формальные процессы, базу знаний, инструкции для линий поддержки. Главное - делать.

Всегда есть те, для кого проблема будет преимуществом

На одной из ретроспектив я с удивлением услышал благодарность продукт-менеджеру от одного из участников команды: "Спасибо за то, что ты знаешь, как работает наш продукт и отвечаешь на наши вопросы даже по ночам!". В моей парадигме управления продуктом такая ситуация - это мегафейл! Знания о продукте должны быть общими, их должно быть можно получить без обращения к менеджеру или коллеге по команде. Без этого у нас дикие риски остаться без знаний, низкая скорость выхода новых фич и высокие риски изменениями поломать что-то "переделав логику из лучших побуждений". Но команда с удовольствием приняла высказывание, менеджеру продукта такая похвала тоже пришлась в удовольствие. А самое главное, что это всё происходило в компании, которая показывает уверенный рост и занимает далеко не последнее место на своём рынке.

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

Ретроспектива - это анализ сделанного, а не ответ на вопрос "почему не сделали»

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

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

Так же, на ретроспективе, важно не забывать и о позитивных рисках - "почему мы смогли сделать это быстрее, чем планировали" или "почему нам было это сделать проще, чем планировали". Без результата эти вопросы бесполезны, а значит и ценности у ретроспективы будет в несколько раз меньше.

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

Техническая красота решения

Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит":
- уменьшится время на борьбу с багами при выходе новых версий?
- увеличится time2market?
- уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов?
Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно сделать, чтобы начать собирать метрики, должны попадать в спринт, а не лежать вечно на задворках бэклога. Если хотим снизить баги при выходе новых версий - давайте время на юнит и автотетсты.

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

Как говорить меньше, а делать больше

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

Мифы и легенды утреннего стендапа

Утренний стендап - это инструмент, в первую очередь, менеджера. Именно здесь менеджер продукта понимает, работает ли его команда по процессу, или внутри царит "творческий беспорядок". Процесс необходим для повторяемости результата. Для продукта это даже более важно, чем для проекта. Ежедневный стендап - это инструмент внутри операционного цикла, из котрого сам менеджер должен быть исключён. Задача менеджера помогать команде поддерживать и развивать процессы.

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

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

Весь таймменеджмент умещается в одну фразу: "Понять, что можно просрать, а что нельзя, и сосредоточиться на втором". Любой другой выбор - лишь иллюзия, такая же, как и у ребёнка, которого спрашивают: "Какую кашу ты будешь: манную или овсяную?". Всегда есть внешние обстоятельства, которые диктуют нам контекст, в котором мы делаем тот самый, единственный выбор. Работаешь в найме - контекст задаёт руководитель. Ты глава собственной фирмы - контекст зависит от договоров с клиентами и дат выплат ЗП сотрудникам. Отличие взрослого от ребёнка в том, что взрослый может сам выбирать свой контекст - например, работать по найму или открыть собственный бизнес. Но это выбор не имеет к таймменеджменту никакого отношения.

Собственно, прочитав мой пост, вы теперь можете не читать больше ни одной книги про таймменеджмент, ибо, отжав воду, вы получите ровно ту заветную фразу :)

Врач - лучший учитель по CustDev

Хотите прокачать навык по сбору проблем и подтверждению гипотез с пользой для здоровья? Сходите на приём к врачу и запишите разговор с ним. Ведь врач на приёме занимается именно проблемным интервью:
— Что беспокоит?
— Когда началось?
— Колет или тянет?
— Какие лекарства уже принимали?

Каждый вопрос - это вопрос о вас, о вашей жизни и, одновременно, проверка гипотезы:
— Больнее, когда нажимаю или когда отпускаю?
— Когда надавливаете
— Значит, вероятность аппендицита низкая.

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

Готовясь к интервью, задайте себе мысленно вопрос: "А не похож ли я на врача, которому нравится лечить аппендицит и он всем средствами пытается обнаружить его у пациента?". И составляйте вопросы так, чтобы не быть таким врачом:
— Какую обувь предпочитаете?
— Спортивную, в основном - кеды, кроссы
— Вы завязываете шнурки на них сидя или стоя?
— Я вообще не завязываю, так как купил эластичные и просто надеваю
— А бегом вы занимаетесь?
— Конечно! Два-три раза в неделю бегаю.
— И на спортивных кроссах тоже используете эластичные шнурки?
— Нет, там, конечно, обычные, чтобы лучше держали ногу.
— Доверили бы машинке завязать шнурки на спортивных кроссах, чтобы не наклоняться к ним?
— Нет, мне важно чувствовать силу затяжки. И, кстати, я не наклоняюсь, я всегда завязываю сидя, поставив ногу на пятку, чтобы правильно расположить кроссовок на ноге.
— Круто, не знал! А зимой тоже бегаете?
— Зимой мне нравятся коньки. Кстати, там как раз такой гемор со шнуровкой и разшнуровкой - каждый виточек затяни, потом растяни...

Ну, а если пока не получается кастдевить - не трать деньги на курсы, просто сходи к врачу :)

ChatGPT - не инструмент, а сотрудник

Очень многие уже попробовали ChatGPT для своих задач. И очень много негатива, связанного именно с тем, чем ChatGPT является - генеративной (то есть, "выдумывательной") сетью. У меня "картинка схлопнулась" в отношении к ChatGPT, как только я стал относиться к нему не как к инструменту, а как к еще одному сотруднику - Чату Виленовичу Аитову:
- как и любому сотруднику, Чату Виленовичу нужно конкретно формулировать задачу (а правильная постановка задачи зачастую половина дела);
- как и любой другой сотрудник, Чат Виленович выдаёт суждения и результаты с "персональным когнитивным искажением", поэтому нужна хотя бы минимальная проверка результата;
- как и любой другой сотрудник, Чат Виленович требует обучения именно на ваших данных

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

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

Как понять, что ты чему-то научился?

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

Сначала всё просто. Если твои взгляды поменялись, точка зрения изменилась - значит, ты научился. Перестал думать, что земля плоская? Узнал, что параллельные прямые могут пересекаться? Перестал верить правым и стал верить левым - всё это примеры роста.

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

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

Прочитал этот пост и сформировал свою точку зрения на этот вопрос - отлично, значит, ты научился! :)

Подал заявку на выступление на ProductCamp! Фишка конференции в том, что в сетку попадают доклады, за которое проголосовало больше всего людей. Буду признателен, если поддержите голосом мой доклад. Если, конечно, считаете тему интересной https://docs.google.com/forms/d/e/1FAIpQLSd4kjAx07fAbV7DBcow_HMC-KxcLnyl7nXPDOfe54Nwpyd-lg/viewform

На 10-й странице :)

Классикой управления является задавать три вопроса:
- почему это произошло?
- что мы сделали не так?
- что мы поменяем, чтобы это не происходило?

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

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

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

​​Команда – это когда достоинства одного перекрывают недостатки другого.

Эта избитая заезженная фраза остается лучшей характеристикой команды. Собирая такие команды для рабочих задач, я решил применить её и для себя самого. Много лет я периодически начинал ходить в спортзал, меня хватало на 2-3 месяца. "Нужна команда", - решил я, и в этот раз заложил в бюджет ежемесячную оплату тренера. Раньше я брал уроки эпизодически - чтобы поставить технику, подготовить программу и далее заниматься по ней самостоятельно. В этот раз я подобрал сценарий – "я + тренер = миникоманда". И вот уже 9 месяцев подряд минимум 4 раза в неделю (за редкими исключениями) я хожу в зал. Да, это стоит денег – я "нанял на работу" человека, который закрывает мою слабую сторону самоорганизованности на длинной дистанции. Но результат однозначно стоит того.

Когда запускаешь стартап, нанимать людей не самый продуктивный путь, пока ты на этапе поиска болей, проверки гипотез и подбора сходящейся экономики. Нормальные стартаперы находят партнёров с такими же горящими глазами и вместе бегут вперед. У меня так ни разу не получилось. "Хорошо", - решил я, - "хватит ломиться в закрытую дверь". И пошел на курс #productgames. У руля стоит Андрей Торбичев, автор канала "Индекс дятла". Но выбрал я курс не за медийность лидера. У курса совершенно гениальная система монетизации, когда платят все! И те, кто приходит со своим проектом, чтобы бустануть его, и те, кто приходит учиться запускать проекты. "Бесплатного сыра нет, а программа уже не первая – значит, ценность от неё есть", - решил я. И вписался.

Сейчас закончилась четвёртая неделя обучения из девяти. Самое время перевести дух и сделать первые выводы. Какие? Об этом немного позже. Не переключайтесь :)

​​И вот долгожданный миг знакомства с командой. На предыдущем потоке в #productgames соревновались именно команды между собой. Были питчи кейсодержателей и участники могли выбрать, в какую команду пойдут. В этом потоке организаторы сделали ставку на солопренеров – людей, которые, вооружившись ИИ, пытаются запустить бизнес в одиночку. Уже есть примеры таких успешных бизнесов, прогнозы оптимистичны. Но при всей привлекательности идеи для таких интровертов, как я, всё-таки моё мнение остаётся на стороне командной работы. Хотя бы потому, что знания в современном мире устаревают настолько быстро, что вряд ли можно успеть за ними во всех дисциплинах.

Таким образом, на моём потоке всего две команды. Никаких питчей и возможности выбора. Как организаторы собирали людей под проекты – загадка. В моей команде 5 человек, большинство с предыдущего опытом курсов или хакатонов от #productgames. Леди А, леди Н, леди И, мистер Э и мистер А. Как объединить 5 самостоятельных специалистов с большим опытом, привыкших работать самостоятельно или в коллективах, где правила определяют они сами, в одну команду, чтобы двигаться в одном направлении? Первый вызов и проверка лидерских качеств.

Главные правила, на которых я пробую строить командную работу – открытость и взаимоуважение. Я отдаю себе отчёт, что команда – не мои подчинённые, что каждый волен достигать собственных целей. Поэтому сделал "Кондуит из Швамбрании" – свод правил, которые должны помочь построить культуру взаимодействия внутри нашей маленькой группы. Если будет интересно – пишите, опубликую в комментарии.

Первая командная встреча. Естественно, выяснилось, что единого времени для ежедневных встреч, в которое будет удобно всем, не нашлось. Большинству участников было удобно вечером, поэтому выбрали для встреч 20:00. Я сначала лелеял надежду встречаться с теми, кто не мог вечером, в утреннее время, но быстро понял, что это невыполнимая миссия – скорость нашего движения была впечатляющей, а ценность встречи была именно в совместном обсуждении и интерпретации полученных результатов, фиксации дальнейших шагов на их основе. Поэтому, скрипя сердцем, почти сразу пришлось потерять связь с леди И. Мистер А подключился только в конце недели, вернувшись из отпуска. Но стартанули мы бодро. Какие задачи были на первом спринте? Об этом будет следующий пост. Не переключайтесь :)

​​С разницей в 2 месяца вышло два авторитетных исследования, всколыхнувшие интернет:

• MIT (август 2024): «95% Gen AI проектов проваливаются»
• Wharton (октябрь 2024): «74% компаний видят позитивный ROI от Gen AI»

Закономерный вопрос: «Кто врёт?». Парадоксальный ответ: «Никто!». Да просто потому, что исследователи задавали два разных вопроса:

• MIT спрашивал: «Сколько компаний успешно запустили custom AI-агентов в production?» — ответ 5%
• Wharton спрашивал: «Сколько топ-менеджеров получают пользу от ChatGPT, Copilot и подобных инструментов?» — ответ 74%

Это как спросить:
— «Сколько людей открыли свой ресторан?» — 5%
— «Сколько людей научились готовить дома?» — 74%

Разные вопросы — разные ответы. Но оба отчёта сходятся в одном: успех определяет не технология, а люди.

Самая неожиданная цифра из Wharton: инвестиции в обучение падают на 8%, хотя использование Gen AI растёт на 35% за год. Компании тратят миллионы на инструменты, но не учат людей ими пользоваться. Результат? 43% боятся, что сотрудники разучатся думать из-за зависимости от ИИ.

MIT, в свою очередь, прямо называет проблему неуспеха внедрения корпоративных решений: компании избегают «friction» — трения, дискомфорта, необходимости менять процессы и учиться. Хотят купить решение и нажать кнопку «запустить». Думаю, это знакомо всем, кто сделал хоть один проект в средней или крупной компании :)

Так каши не сварить. Wharton показывает, что успешные компании учат итерировать — не «сделай за меня», а «помоги мне сделать лучше». MIT добавляет: самые успешные компании покупают готовое (67% успеха) и учат людей его адаптировать под свои задачи.

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

Попробуйте сегодня решить одну задачу через ИИ. Любую. Анализ данных, письмо клиенту, код, идею для поста. Получилось? Отлично — делайте так каждый день, пробуйте более сложные задачи. Не получилось? Не говорите «ИИ — фигня». Спросите себя:

— Я дал ему достаточно контекста?
— Я показал примеры желаемого результата?
— Я задал конкретный вопрос?

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

Я 25 лет в IT, но дети научили меня больше, чем годовой курс по ИИ
Он рисовал маму из палки-палки-огуречика. С летающей собакой-картофелиной. И был абсолютно счастлив. А я сидел перед документацией по LangChain и боялся сделать первый кривой шаг.

Но начну с другой истории.

2000-й год, мне двадцать, и я случайно стал руководителем IT-отдела. ак именно это вышло — отдельная история, но суть в другом: в столь юном возрасте я вдруг оказался по ту сторону стола, где нужно задавать умные вопросы и делать вид, что точно знаешь, чем хороший программист отличается от очень хорошего. Усы отрастил для солидности — других аргументов в двадцать лет у меня не было. 🙂 Провожу собеседование, спрашиваю кандидата: "Как будешь сортировать список?"

Я учился в МАИ на прикладной математике, и мы там, как полагается приличным людям, писали алгоритмы сортировки руками — пузырьком, вставками, слиянием. Знали машины Тьюринга, нормальные алгоритмы Маркова, и искренне верили, что без этого фундамента в профессии делать нечего — примерно как хирургу без знания анатомии. Жду пузырька. Слияния. Быстрой сортировки — для смелых.

Он смотрит спокойно и говорит: "Загружу в ComboBox и вызову метод sort".

Oооооо, майн n log n - что-то такое пронеслось у меня в голове и, видимо, в глазах тоже мелькнуло. Внутри забурлило, крышечка подпрыгнула не хуже, чем у забытого на плите чайника. Просто sort?! А где же пузырёк, слияние и прочие бессонные ночи первого курса!?!?

Я ему отказал. Мне кажется, тот кандидат был рад 🙂 С возрастом я не раз возвращался к этой истории, прокручивая её в голове как старую видеокассету. Конечно, я тогда погорячился — встроенный sort быстрее, надёжнее и протестированнее любой ручной реализации. Тот парень просто решал задачу на другом уровне абстракции. А я со своим Тьюрингом и Марковым застрял на предыдущем.

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

Джон Бэкус — автор языка программирования Фортран — честно признавался: он придумал язык высокого уровня, потому что ему было лень ковыряться в машинных кодах. И как же подпрыгивали крышечки в тот момент у программистов на ассемблере! Критики говорили, что компилятор никогда не сгенерирует код лучше написанного вручную. Ошибались — Fortran впустил в программирование целую армию учёных и инженеров, которым регистры процессора были настолько же интересны, насколько мне сейчас интересна вышивка крестиком.

Потом были базы данных — и программисты, которые хранили данные в файлах, крутили носом: «SQL? Серьёзно? Я за десять минут напишу обход дерева, который будет быстрее этого вашего SELECT». Потом был веб — и десктопщики морщились: «Это не настоящее программирование, это вёрстка». Потом были фреймворки, потом — облака, потом — no-code. И каждый раз — одни и те же подпрыгивающие крышечки. Одни и те же люди, которые путали «я так привык» с «так правильно».

Сейчас — очередной виток. Андрей Карпати год назад ввёл термин «вайб-кодинг», а буквально на этой неделе объявил его устаревшим. Теперь это «agentic engineering» — модели доросли до профессионального использования. По словам Джареда Фридмана из Y Combinator, четверть стартапов последнего набора имеют кодовую базу, на 95% написанную ИИ. Причём это не ребята, которые не умеют программировать, — это сильные технари, которые год назад писали бы всё руками.

Вернёмся ко мне, но через 25 лет от ранее описанных событий. Те же декорации, другая пьеса. Я решил освоить ИИ. Купил курс. Составил план. Первая неделя: трансформеры, RAG, файн-тюнинг. Вторая - понимаю теорию, а руки не двигаются. Как если бы прочитал учебник по плаванию, сдал тест на отлично — и стоял на краю бассейна, вцепившись в поручень. Третья - хожу, потому что абонемент оплачен. На четвёртой месяц бросил.

И тут - ребёнок на кухне. Он не гуглил "лучшие практики рисования". Не сравнивал себя с Pinterest. Водил пальцем по экрану: "Это мама. А это собака, но она летает, потому что я так хочу".

Что-то щёлкнуло. Не как в кино, а без оркестра и крупного плана. Просто тихое понимание: мой ребёнок не боялся нарисовать кривую маму. А я боялся написать кривой промпт. Вся моя профессиональная серьёзность - это и есть тот самый страх, просто в дорогом костюме. Курс не зашёл не потому, что был плохой. Я осваивал новое старым способом - методично, правильно, как профессионал. Но профессионал - это тот, кто УЖЕ умеет. А когда ты ещё не умеешь, профессионализм превращается в клетку.

На следующий день я открыл ChatGPT: "Сделай переводчик с кошачьего на человеческий". Без плана. Без архитектуры. Получилось криво - но впервые за месяц понравилось. Потому что нельзя же переживать за качество переводчика с кошачьего - его и качества-то не существует. 🙂 Потом были ещё десять таких же нелепых проектов. И я не заметил, как игра стала работой - как перешёл от переводчика с кошачьего к архитектуре агентных систем.

Теперь когда берусь за новый инструмент - первые две недели ЗАПРЕЩАЮ себе делать "правильно". Только играть. Только криво. Только ради интереса. Профессионализм включается потом. Сначала — летающая собака-картофелина.

А вы — когда последний раз разрешали себе сделать что-то кривое, не сравнивая себя с профессионалом?

А вы разговариваете с ИИ-агентом как с товарищем, коллегой или как с подчинённым? :)