Щербинин думает про…

Про дашборды, которые не нужны

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

— Тут видно, что команда перегружена.
— Ну, перегружена — и что?
— Надо ввести WIP-лимиты, ограничить количество задач в работе.

Окей, ограничить количество задач — уже решение. До этого я смотрел на цифры, как в старом анекдоте: «Двести». — «Что двести?»

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

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

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

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

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

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

Вполне может оказаться, что сам дашборд после этого делать незачем.

#Management #Analytics #AI

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

Мне хочется, чтобы мы наконец занялись тем, что и раньше называли хорошей инженерией, но часто оставляли на совести конкретного разработчика.

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

У агента нет такого фонового знания, да и доверяем мы ему пока меньше. Поэтому любые неоднозначности проявляются быстрее. Где-то терминология менялась со временем, где-то соседние части системы развивались немного по-разному, где-то архитектурное решение хорошо описано, но ничем автоматически не проверяется. Само по себе это нормально. Агент просто заставляет договориться, какой вариант мы считаем правильным.

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

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

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

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

Кажется, это полезное изменение и для агентов, и для нас самих.

Про автономную работу

Поставил агенту задачу, заблокировал ноут, отошёл. Возвращаешься — комп спит, ничего не посчитано, время просто потеряно.

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

caffeinate -d

Я так и гонял её с -d, а это, оказывается, про дисплей: экран всё время горит. Если смотреть не надо, честнее -i — экран гаснет, система не спит. Чего она не умеет вообще, так это крышку: закрыли ноут, он всё равно уснёт.

Хотя закрывать его и не надо. Комп теперь стоит на питании и в сети, в кодексе включён remote — и я из метро с телефона отвечаю агенту на вопросы, чтобы он не встал посреди ресёрча.

Про гольф

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

Условия:

Найти максимально длинное кольцо, которое можно составить из предложенных костяшек, или вывести 0, если закольцевать их нельзя.

Вход: строка из пар чисел от 0 до 6 через пробел. Каждая пара — костяшка.

Пример: 01 11 12 22 31 32

Данные подаются на STDIN: cat data | golf.pl

Пример ответа: 11 12 22 23 31

Абсолютно лучшее решение выдал ChatGPT 5.6 Sol, 102 символа:

#!/usr/bin/perl -ap
sub f{my$e=pop;@b=@_ if$e==$s&&@_>@b;s/$e//?$_=$e.f(@_,$e.$_,chop):0for@F;$e}f$s=$_%10for@F;$_="@b"||0

Если понимаете, что тут написано, — с меня пиво.

Про два сегодняшних инсайта

Сегодня научился запускать агентов по-новому. Собрал из них целую команду разработки: UX-дизайнеры, продакты, архитекторы. Они проходят discovery и delivery — общаются между собой, принимают решения, спорят. Есть даже критики, которые толкают команду к решению получше. А в финале договариваются и выдают готовый проект с документацией. Получается очень круто.

С этой командой я весь день делал один большой проект. Всё работало. К вечеру у меня на руках был готовый продукт.

А потом я его стёр. Целиком. Весь день работы — в помойку.

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

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

Спалил весь недельный лимит токенов из-за Fable, но он реально хорош, так что не жалко.

Поэтому сейчас иду смотреть обзор нового GPT-5.6, и вероятно покупать вторую MAX подписку. И сегодня же объявят об объединении Codex и приложения ChatGPT. Интересно, что у них получится, свой Claude Code или что-то особенное?

Начало минут через 10, вот тут: https://openai.com/live/

Приходите обсуждать в комменты 👇

Про то, что вы больше не пишете код

«Нас всех заменят?» — этот вопрос мне задают чаще любого другого. Отвечаю честно: нет. Но тот, кем вы были вчера, уже заменён. Не роботом — вами же, в новой роли.

Смотрите на цифры. Annie Vella, Distinguished Engineer из Westpac, полгода вела исследование среди инженеров из 28 стран. Результат: 82% стали тратить на написание кода меньше времени. Не «немного меньше» — большинство писать почти перестали. Код теперь набивает агент.

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

Появился новый слой работы, которого раньше не было. Vella назвала его middle loop. Есть inner loop — написал, собрал, запустил, поправил (его вылизали IDE и TDD). Есть outer loop — коммит, ревью, деплой, мониторинг (его оптимизировал DevOps). А между ними теперь сидите вы и следите за агентом, который делает то, что вы делали руками.

Работа в этом слое — три штуки. Directing: объяснить, что вы хотите получить, дать контекст и границы, зашить стандарты в инструкции для агента. Evaluating: прочитать то, что он выдал, и решить — принять, переписать или выкинуть. Correcting: починить и встроить так, чтобы не разъехалось по всей базе.

Звучит легче, чем писать самому? Не легче. Код от агента с подвохом: он правдоподобный. Компилируется, запускается, выдаёт результат — а логическая ошибка сидит тремя коммитами глубже. Расслабиться на ревью нельзя. Раньше вы учились на своих ошибках, теперь вылавливаете чужие. Это другая нагрузка, и она тяжелее.

Так что же делать? Вкладываться туда, куда переехала ценность.

Первое — учиться писать спеку. «Specs are the new code» — не лозунг. AWS своим Kiro сжал двухнедельную фичу до двух дней не потому, что агент быстрый, а потому что ТЗ было точным. Главный баг 2026 года — не кривой код, а корректный код по кривому ТЗ. Кто умеет формулировать, что строить, — тот и дорогой.

Второе — строить харнесс. Agent = Model + Harness, и надёжность в проде на 90% даёт обвязка, а не модель. Тесты, линтеры, гейты, инструкции — всё, что ловит ошибку агента раньше вас. Сильный инженер теперь не тот, кто быстро пишет, а тот, кто строит систему, где агент не может налажать.

Заменят не всех. Заменят тех, кто остался писателем кода, когда работа стала про постановку и проверку.

Про качалку

Полгода меня тихо бесило, что из приложения для тренировок нельзя вытащить свои же данные. Вся история — сколько жал, когда, каким весом — лежит внутри, красиво нарисована, и всё, только глазами. Пересел на Hevy: там есть экспорт и API.

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

И тут до меня дошло, что выбрал-то я продукт вообще не по интерфейсу — а по одной вещи: пускает ли он к данным моего агента.

Раньше продукты выигрывали интерфейсом. Теперь между мной и приложением стоит агент, и я первым делом смотрю, сможет ли он залезть туда вместо меня. Нет API — до свидания, ухожу к тому, у кого дверь открыта.

Так что если делаете продукт, а апишки до сих пор нет — бросайте читать и идите делайте. Сегодня.

П.С. Я не против красивых экранов. Я против тех, из которых нельзя выйти.

#AI #Product

Про последнюю милю

За несколько недель этой весной случилась странная вещь. Все крупные AI-лаборатории и гиперскейлеры, будто не сговариваясь, вложили почти девять миллиардов долларов в одно и то же. Не в новые модели. В инженеров, которых сажают внутрь чужих компаний.

Anthropic в мае завела отдельную компанию корпоративных услуг на $1.5 млрд вместе с Goldman и Blackstone. Метит в средний бизнес без своих AI-команд: региональные банки, производителей, локальные клиники. Их инженеры приходят и строят решения на Claude под конкретный бизнес.

OpenAI сделала DeployCo — отдельную структуру больше чем на $4 млрд под управлением фонда TPG. Схема: прийти, продиагностировать, найти приоритетные процессы, собрать и вывести в прод рабочую систему. Заодно купили британскую Tomoro со 150 такими инженерами и клиентами вроде Tesco и Virgin Atlantic.

Microsoft в июле объявила Frontier Company — $2.5 млрд и 6000 инженеров. Глава коммерции Althoff специально открестился от скромного ярлыка «forward-deployed» и назвал это «крупнейшей outcome-driven инженерной организацией в индустрии». Ключевое слово — outcome, результат. Первые клиенты: Лондонская биржа, Unilever, Novo Nordisk.

AWS вложила миллиард в своё forward-deployed подразделение — и объявила за два дня до Microsoft, лишь бы успеть первой. Их инженеры садятся с командами заказчика и собирают прод-систему прямо на его данных.

Все они продают последнюю милю. Модель сегодня есть у всех и примерно одинаковая. А превратить её в работающий продукт внутри конкретного бизнеса — с его данными, процессами, правилами, с измеримым результатом вместо красивой демки — оказалось дорого, долго и трудно. Именно тут всё и застревает. Microsoft описала это прямее некуда: «эпоха пилотов кончилась, началась эпоха результатов».

Про кейс Block

Посмотрел доклад Энджи Джонс с AI Engineer World's Fair: два года она переводила инженерию Block на AI-агентов — весь путь с цифрами и неудобным финалом.

Началось с парадокса. Через пару месяцев 90% инженеров регулярно пользовались агентами — на бумаге компания all-in on AI. А CEO был уверен, что инженерия AI не использует: фичи до клиентов быстрее не доезжали. У Энджи были метрики и счета за токены, но прав был CEO: adoption сам по себе ценности не даёт.

Чтобы понять, где застряли, Энджи построила шкалу зрелости — она мерит не агента, а инженера:

0 — AI не используется вообще;
1 — AI как autocomplete;
2 — чатится с агентом, но код и PR делает сам;
3 — делегирует агенту задачи и ревьюит результат;
4 — гоняет несколько агентов параллельно;
5 — отдаёт целую задачу и получает готовый к выкатке результат.

Почти вся организация сидела на единичке-двойке.

До третьей добирались через чемпионов, а не массовое обучение. Правило 1/9/90: в сообществе 1% создаёт, 9% участвуют, 90% молча потребляют — учить всех 3500 бессмысленно, вкладываться надо в тот процент, который поднимет остальных. Полсотни инженеров получили треть рабочего времени и приводили репозитории в порядок для агентов: agents.md, файлы правил, обязательный AI-ревьюер. Плюс делегирование перенесли туда, где рождается работа: баг в Slack — агент предложил варианты, команда выбрала, PR через пять минут. Итог трёх месяцев: AI-authored кода +69%, автоматических PR — в 21 раз.

Четвёртая ступень ломает ревью: PR в разы больше, живые ревьюеры не успевают — лечится обязательным AI-ревьюером и циклом auto-fix (один агент находит, другой чинит).

Пятая потребовала не инструмента, а модели организации: оркестратор Builder Bot с картой всех 25 000 репозиториев компании — без неё агент пишет локальный патч, но не спланирует изменение через несколько систем.

Это ровно те этапы, про которые я писал вчера: agents.md в репах — context engineering, AI-ревьюер с auto-fix — харнесс, Builder Bot для любого сотрудника — облачная платформа агентов. Block прошёл их на практике.

И финал. «Это ощущалось как мечта — пока не стало кошмаром»: в феврале Block сократил 4000 человек, почти 40% штата, в день лучшего квартала в истории. Из-за ИИ? Джек Дорси говорит прямо: AI-инструменты плюс маленькие плоские команды — новый способ работать. Скептики возражают: перенаняли в ковид и завернули оптимизацию в модную обёртку; Дорси перенайм признаёт, но одним им всё не объясняет. Доклад заканчивается вопросами без ответа: что мы делаем, куда идём и точно ли хотим туда попасть.

#AI #AI4SDLC #Engineering #Management

Про облачные платформы агентов

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

1️⃣ Prompt engineering.

Эра GPT-3. Учились разговаривать с моделью: подбирать формулировки, класть в запрос пару примеров , просить рассуждать шаг за шагом. Вышла новая версия модели — переписывай промпты заново.

2️⃣ Context engineering.

Лето 2025-го. Контекстные окна выросли настолько, что в них стало помещаться всё: код, документация, история задачи. И навык сменился: важно не как сформулировать вопрос, а что модель должна знать, чтобы ответить. Собираешь ей документацию, соглашения команды, примеры и ограничения — как онбординг новому коллеге. Отсюда файлы AGENTS.md, которые сейчас лежат почти в каждом живом репозитории.

3️⃣ Harness engineering.

Начало 2026-го. Харнесс — обвязка вокруг модели: какие инструменты ей разрешено вызывать, в какой песочнице она работает, какие проверки запускаются после каждого шага, когда она обязана остановиться и позвать человека. Google в свежем whitepaper вывел формулу Agent = Model + Harness и оценил вклад обвязки в ~90% результата: одна и та же модель с разным харнессом в бенчмарке — это разница между топ-30 и топ-5. Агент чаще всего ошибается не потому, что модель глупая, а потому что его плохо собрали.

4️⃣ Облачные платформы агентов.

Агенты переезжают с ноутбука разработчика в облако и живут там постоянно: сами берут задачи, пишут код в собственном окружении, гоняют тесты, открывают PR, реагируют на события — по расписанию, по вебхуку, по сигналу из мониторинга. Cursor запустил cloud agents, Anthropic — Claude Tag, который живёт в Slack и, по их данным, пишет и мержит 65% кода собственной продуктовой команды, а Warp целиком пивотнулся из терминала в облачную платформу агентов Oz.

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

Про AI Productivity Paradox, или почему AI-ассистенты не ускорили ваши релизы

Покопался в свежих исследованиях про эффект, который сейчас ловят почти все команды: разработчики с AI закрывают заметно больше задач, а релизы быстрее не выходят. Эффект уже назвали AI Productivity Paradox, и цифры везде похожие. У MIT и Wharton агенты пишут в семь раз больше кода, а релизов от этого — плюс двадцать процентов. У GitLab 78% разработчиков говорят, что кодят быстрее, и одновременно 79% признают, что поставка не ускорилась.

Главная мысль всех этих работ: ускорять написание кода бессмысленно, пока всё, что после него, осталось прежним. Объяснения сходятся к четырём причинам.

1️⃣ Написание кода никогда не было узким местом
Это примерно треть пути до продакшена. Остальное — ревью, тесты, интеграция, выкатка, поддержка — как требовало людей, так и требует. Фред Брукс написал об этом ещё сорок лет назад: серебряной пули нет, ускорение одного этапа не ускоряет систему.

2️⃣ Конвейер после кода не рассчитан на такой объём
Ревью и QA строились под скорость человеческих рук. Теперь PR висят в ревью в разы дольше, всё больше мержится без ревью вообще, инцидентов после выкаток — в разы больше. Каждая третья команда признаётся, что боится выкатывать свой AI-код в прод.

3️⃣ Ощущение скорости обманывает
В контролируемом эксперименте METR опытные разработчики были уверены, что AI ускорил их на 20%. Замер показал: на 19% медленнее. Генерация выглядит как прогресс, а часы на проверку и доводку чужого кода мозг не записывает.

4️⃣ Копится comprehension debt — долг понимания
Код смерджили, тесты зелёные, а через три дня никто не может объяснить, как он работает. Когда он упадёт в проде, чинить будет тот, кто видит его впервые.

Для руководителей главный вывод такой: писать код стало почти бесплатно, а всё, что после — понять, проверить, выкатить и поддержать, — подорожало. Значит, и вкладываться нужно туда. Я вижу три направления:

— Spec-driven development. Самое дорогое теперь — чётко сказать, что вы хотите получить: критерии приёмки, способ проверки, запреты. Плохая спека просто быстрее производит неправильный код.
— DDD. Код с ясными границами ответственности проверять в разы дешевле, чем логику, размазанную по системе. А в захламлённой базе модель видит техдолг как образец и копирует его — это уже прозвали generative debt.
— Supervisory engineering. Работа инженера сдвигается от «писать» к «проверять»: поставить агенту задачу, посмотреть результат, вовремя вмешаться. Под эту работу нет даже строчки в матрице грейдов, хотя именно она теперь решает, сколько команда выпускает.

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

#AI #AI4SDLC #Engineering #Management #Processes

Про законы Лармана

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

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

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

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

4. Культура подчиняется структуре.

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

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

Ещё по теме: про менеджера менеджеров и плоскую структуру

Про прогресс

Водителей заменяют self-driving cars, работа бухгалтеров автоматизируется, а код и тексты уже пишет GPT-модель. Историк Льюис Мамфорд считает, что создание таких «машин» помогает людям высвободить время для чего-то большего. Роботизация и автоматизация стали основными двигателями человеческой эволюции.

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

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

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

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

Что делать, чтобы учиться размышлять? Есть два главных способа:

1. Мышление через проговаривание. Это можно делать в группах по интересам, с коллегами и близкими. Чаще делитесь своими размышлениями.

2. Мышление письмом. Этим я занимаюсь прямо сейчас. А вы можете попрактиковаться со мной в комментариях.

Как вы думаете, какие навыки должен осваивать современный человек, чтобы оставаться на гребне волны прогресса?

Про PPPI

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

Практически это выглядит так, что на 1v1 с сотрудником мы смотрим в его документ. Вот, что там написано:

P — прогресс. Какие задачи выполнил человек за прошедший период. Желательно измеримые.

P — план. Что сотрудник собирается сделать до следующей встречи. Максимум 3-5 ключевых проектов.

P — проблемы, с которыми сотрудник столкнулся, не смог преодолеть или потратил слишком много времени. Где ему нужна ваша помощь.

I — идеи человека по улучшению процессов.

Не стоит воспринимать этот документ как жёсткий комитмент. Я, например, никогда не проверяю, соответствует ли предыдущий план текущему прогрессу. Не используйте PPPI для надзора и контроля. Он просто помогает структурировать работу и выровнять ожидания.

Поучаствовал в подкасте «IT-шниками не рождаются»

Вместе с Бесланом Курашовым записали подкаст на полтора часа для канала «karpov courses»!

Поговорили о разном, не только про IT:

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

Кажется, получился ламповый информативный выпуск, смотрите на YouTube

Про ситуационное лидерство

Часто начинающие руководители приходят с таким вопросом: «Вот есть человек, и одну задачу он делает круто и быстро, даже следить не надо. А как даю другую, так спустя два дня ничего не сделано и результата нет. Что это значит и как быть?»

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

Есть две основные модели. Слева модель Пола Хёрси про «готовность делать», она мне больше нравится. А справа модель Кена Бланшара. В каждой модели нужен разный подход в зависимости от квадрата, в котором вы с сотрудником находитесь. Но в целом модели похожи.

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

А если у сотрудника есть мотивация и точное понимание, как делать задачу, то это уровень «делегирование». От руководителя не требуется много поддержки и надзора.

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

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

Как скрам-артефакты помогают продуктовым компаниям не проседать в качестве

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

Основные поинты:

— Функциональные команды выполняют только часть задач и часто не задумываются о влиянии на продукт.

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

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

Выступлению полгода, но актуальность сохранилась на 100%. Посмотрите полностью

Про систему гильдий

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

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

Представьте, что разработчики разошлись по кросс-функциональным продуктовым командам. Кто теперь обновит Python и Django до новой версии? Кто добавит правила для линтеров? А кто предложит внедрить DDD?

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

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

Подробно разобраться в этом вопросе поможет гильд-канвас. Нашёл подробный гайд на 60 страниц с подробной теорией и руководством по построению гильдии вплоть до вопросов для фасилитации.

ПДФка ниже ↓