Ну подключите меня к задаче в таком случае В проблемных и кризисных ситуациях и дефиците времени реакцией коллег выше может стать фраза "ну подключите меня". Это значит, что коллегу нужно добавить во все переписки, коллы, раздать доступ и ОБИЗАТИЛЬНА воткнуть синк на 30 минут в чей-то обед. И вот тогда все и полетит Недавно обсуждала этот паттерн со знакомым. Его кейс звучал так: на одном из этапе воронки в пути клиента, после небольшой перестройки процессов, конверсия ухудшилась. Они в конце прошлого года думали что переделать. В начале года подключили руководителя и поставили задачу на контроль со всеми вытекающими. В конце q1 ситуация только ухудшилась. В начале q2 добавили еще одного специалиста. И в конце q2 ситуация стала субъективно еще хуже. В цифрах данные рано собирать, но обсуждения затянулись, передача инфы страдает и вылезли другие проблемы большого количества людей. Короче на встречу с клиентом про тест продукта ходило два человека года назад, а теперь подключается 5. Клиент, мягко говоря, теряется. Не всем понятно, кто ответственен за обещания, за общение, за встречи и тд. Попытки выключить вовлеченных рук-лей из процесса успехом не увенчалась Ну то есть фактически 📍у нас процесс тонет 📍сейчас, подождите, я прыгну, проверю, возьму на контроль 📍 ... 📍да, точно, правда тонет Мы с коллегой сошлись на мнении, что так выражается беспомощность в решении проблем. Вроде как что-то сделать надо, а идей нет Как вы обычно включаетесь в проблемы коллектива и команды, если проблема у подчиненных, но не в вашей зоне компетенций и у вас около 0 понимания, что делать то?

Помните классический жизненный цикл разработки ПО - SDLC? Так мы работали много лет, и многие продолжают. Но с приходом ИИ Amazon предложил новую концепцию - AI-Driven Product Development Lifecycle, AIPDLC. Это подход, при котором жизненный цикл продукта не просто дополняется ИИ-помощниками, а ставит ИИ во главу угла. То есть использование ИИ-ассистентов в обычном SDLC, конечно, ускоряет процесс, но человек все равно остается главным участником процесса - оркестрирует, декомпозирует, валидирует и собирает вручную. В AIPDLC человек - инициатор, он задает замысел, намерение (intent), устанавливает архитектурные рамки, описывает граничные условия. А в конце проводит финальную проверку. Вся реализация - рисёч и составление плана, постановка и декоспозиция задач, итеративная разработка и тестирование, проверка на безопасность и законность - всё это берет на себя ИИ. Понятно, что с кондачка такие вещи не делаются, нужна целая цифровая трансформация. Вот, например, целая стратегия от Сбера. Так что скоро процессы разработки заметно трансформируются, особенно когда пройдет период адаптации индустрии, и появятся готовые тулкиты для таких подходов по адекватной цене. #ai #process

Иногда тянет поругать чей-то бизнес, мол, ну как же собственник допускает такой бардак/косяк/тухляк… А потом вспоминаешь про себя и собственную конторку, и сразу запал кого-то ругать улетучивается. Вспоминаешь, как это тяжело - заставить свою компанию работать хорошо. Зачастую, чтобы поддерживать даже порядок в туалете, надо буквально поселиться там и тыкать всех вокруг, и тюкать. А потом всё равно устаешь, плюешь и отворачиваешься (чтобы не смотреть и не расстраиваться). И как быть? Можно полагаться на процессы, можно рассчитывать на правильных людей, но эффективнее всего создать правильную культуру: «Здесь так принято (не принято)». Если ты один рубишься за порядок в туалете, ты всё равно устанешь и сдашься. А вот если тебе удастся создать правильное отношение к делу / рабочему месту / клиенту / себе - небольшой шанс появляется. Уже после останется полирнуть процессами, нанять «своих» людей, расстаться с «чужими», и должно полететь. Не факт, что в «правильную» сторону, но точно «в твою».

Твоя красивая оргсхема из квадратиков ни хрена не чинит 🔵 Был у меня дизайнер, который стабильно не правил опечатки на макетах. Приносят ему баннер, там слово с ошибкой во весь экран, а он спокойно: ‘’это не моя зона, мне копирайтер такой текст передал, пусть копирайтер и правит’’. И ведь формально он прав) Вычитывать текст не его работа. А копирайтер уверен: явную-то опечатку дизайнер сам поправит, не развалится) Итог - баннер с ошибкой висит, оба честно закрыли свой кусок, а разгребаю это я... Вот чего не видно на красивой оргсхеме: квадратик описывает, что человек делает ВНУТРИ своей зоны. А задача упала не внутри зоны, а как раз в зазор между двумя другими. Можно бесконечно дорисовывать квадратики и тасовать людей, легче не станет: разваливается-то всё на передачах. Чинить надо стыки, а не квадратики. У каждого стыка должен быть хозяин - тот, кто отвечает за передачу дальше. Сделал и отдал → сделал и проследил, что приняли Мы, например, сделали карточку старта проекта: продажник при передаче обязан заполнить всё - что за клиент, что обсудили, что сделано. Пока не передал, задача не закрыта. Точка. Так что рисуйте зоны ответственности и стыки между ними. И на каждый стык хозяина передачи. Иначе последней инстанцией, куда стекается каждая проваленная задача, так и останетесь вы.

Неудачи и ошибки Общение определение ошибки — это не достижение целевого состояния, когда результат не равен цели. Давайте разберем на простом примере: мы хотим сварить кофе в кофе-машине. Что может пойти не так? Мы можем не сварить кофе, сварить не то кофе: не того объема, не того вкуса, неправильной температуры, не поставить чашку и т.д. Самый печальный результат будет если мы сломаем кофе-машину. Почему не получилось сварить кофе, как хотелось? Ошибка может быть на разных уровнях: 1. Мы можем не знать, как пользоваться машиной, не понимать как с ней работать. Надписи могут быть запутанными, множество кнопок. 2. Мы можем ошибиться в действиях: случайно нажать не на ту кнопку, поставить чашку не туда и так далее. 3. Сама кофе-машина может не работать или не работать плохо: не залили воду, просто сломана, необходимо засыпать кофе, засорилась и т.д. 4. Окружение может повлиять на задачу: в здании отключилось электричество, перед кофе-машиной стояла большая очередь, ко мне подошел начальник и попросил зайти в кабинет к нему. То есть, ошибки могут быть двух видов: ошибка результата и ошибка различного рода в процессах. Чтобы разграничить их дальше, ошибки результата дальше мы будем назвать неудачей. Не получилось сварить чашку кофе. Чтобы дальше было яснее, нужно разграничить 2 типа ошибок: 1. финальная ошибка, состояние когда результат не равен цели. Этот тип ошибок будем называть неудачи. Не получилось. 2. ошибка или отклонение самом процессе. Вот как раз тот набор отклонений от нормального процесса сварить кофе. Сама по себе ошибка процесса может быть неприятной, но не фатальной. Мы нажали на не ту кнопку, потом нажали на правильную. В машине нет воды — налили ее. Ошибка в процессе не всегда приводит к неудаче — не достижению цели. Да и сама неудача может различаться по своим параметрам: одно дело мы вообще не сварили кофе, другое — когда сварили кофе не того объема. Мы хотели сварить большую чашку, а сварили маленькую. В ряде случаев мы даже не посчитаем это как неудачу. Если брать цель как построение безошибочных систем, то это не значит, мы не должны не допускать ошибок вообще. Нам нужно сделать, чтобы все ошибки не превращались в значительные неудачи. #ЧФ #ошибки

Что делать, если команда ждет от менеджера продуктов ответов на все вопросы? Представьте, что команда постоянно приходит к вам с вопросами: — Как лучше сделать? — Что выбрать? — Какой вариант правильный? — Что сейчас важнее? Сначала это кажется нормальным: менеджер продуктов знает больше контекста, лучше понимает цели бизнеса и действительно может быстрее принять решение. Но через некоторое время происходит незаметная подмена: команда приходит за ответами уже не потому, что без них не может решить задачу. Она приходит потому, что именно так в команде привыкли принимать решения. Именно здесь менеджер продуктов постепенно становится узким местом. Если каждое обсуждение заканчивается словами «сейчас скажу, как правильно», количество задач растет быстрее, чем способность одного человека на них отвечать. В результате команда начинает ждать. Скорость падает. А самостоятельность не развивается. Чтобы этого не происходило, не обязательно переставать отвечать на вопросы. Важно выбирать подход в зависимости от ситуации. Разберем три действия под разные типы ситуаций. 1. Дать готовый ответ Используйте этот подход, если решение уже принято или у команды нет части контекста. Например: — есть ограничения бизнеса или законодательства; — решение зависит от договоренностей с партнером; — приоритет уже определен руководством. В этом случае обсуждение ничего не изменит. Самый быстрый путь — просто передать информацию. 2. Дать критерии выбора Если решение может принять сама команда, не отвечайте на вопрос «что делать?». Помогите ответить на вопрос «как выбрать?». Вместо: «Давайте делать вариант А.» лучше сказать: «Наша цель сейчас — сократить время до первой ценности. Какой вариант лучше помогает этого добиться?» или: «Для нас сейчас важнее скорость проверки гипотезы, чем идеальная архитектура.» Так команда получит ориентир, который сможет использовать и в следующий раз. 3. Построить обсуждение Если задача сложная и однозначного ответа нет, помогите команде разобраться в проблеме. Например, предложите сначала обсудить: — Какие есть варианты? — Какие риски у каждого? — Что можно проверить самым дешевым способом? — Какое решение будет проще изменить позже? — Какой вариант сильнее влияет на целевую метрику? В этом случае менеджер продуктов управляет уже не решением, а процессом его принятия. Так, со временем происходит важное изменение: вместо ожидаемых от вас ответов у коллег появляются критерии для самостоятельного принятия решения. И вместо «Как правильно?» команда начинает спрашивать «Какой вариант лучше соответствует нашей цели?» Именно так появляется самостоятельность. Как понять, что вы стали узким местом? Есть несколько простых признаков: • большинство обсуждений заканчиваются вашим финальным словом; • команда редко предлагает собственный вариант решения; • без вашего участия задачи начинают останавливаться; • одни и те же вопросы повторяются снова и снова. Если узнаете свою команду — скорее всего, она просто адаптировалась к тому, как у вас принято принимать решения. Что попробовать уже на следующем обсуждении? Когда вы в следующий раз услышите вопрос «Как лучше сделать?», не отвечайте сразу. Сначала определите, какой ситуации соответствует этот вопрос: а) Если у команды нет необходимой информации — дайте ее. б) Если решение очевидно не единственное — дайте критерии выбора. в) Если проблема сложная — помогите структурировать обсуждение. Так постепенно меняется не только качество решений, но и способ, которым команда их принимает. Возможно, главный вопрос для менеджера продуктов звучит не так: «Какое решение сейчас правильное?» А так: «Как сделать так, чтобы в следующий раз команда смогла принять его без меня?» @productmindset

Граф: циклы, наблюдающие за циклами (часть 2) Если присмотреться к тому, как Системы на практике реализуют процессы совершенствования, вырисовывается определенная закономерность: они никогда не сводятся к одному циклу.

Системы — это сети циклов, соединённые с другими циклами

Так, грамотно управляемая компания представляет собой граф циклов: быстрые операционные циклы (ежедневный/еженедельные совещания/анализ метрик) встроены в более медленные управленческие циклы (квартальное планирование), те – в циклы аудита (ежегодные и, что важно, независимые, которые проверяют, соответствуют ли реальности цифры, выдаваемые операционными циклами), а все они — в самый медленный цикл уровеня совета директоров, который задаётся вопросом верны ли сами цели. Технологии ИИ пришли к такой архитектуре аналогичным путём. Грамотный конвейер обучения ИИ – это цикл типа «чемпион = претендент», когда модель-кандидат должна превзойти текущую модель, прежде чем заменить её, а также циклы мониторинга дрейфа, отслеживающие, соответствуют ли поступающие данные тем, на которых модель обучалась и механизмы отката (автоматический возврат к предыдущей версии, если показатели после развертывания выходят за допустимые пределы). Сюда же входят отложенные оценочные выборки, недоступные для цикла обучения, своего рода "слепой" цикл, чья единственная задача выявлять случаи, когда оптимизирующий цикл пытается обхитрить свои собственные тесты. Каждый элемент здесь — это цикл. Надёжность системы кроется в связях между ними: какой цикл передает данные другому, какой наблюдает за каким и какой может наложить вето на действия другого. Проблема Гудхарта решается методом парных показателей: каждому оптимизирующему циклу сопоставляется цикл, отслеживающий контрметрику и выявляющий способы "дешёвого" достижения KPI. Проблема "слепоты" по отношению к вышестоящим уровням решается иерархией, в которой более медленный цикл определяет целевые показатели для быстрого, а пересмотр целей сам по себе является регламентированным циклом, а не случайным решением того, кто установил их изначально. Конфликты разрешаются через явный арбитраж: над конфликтующими циклами стоит ещё один цикл, который принимает решение по поводу возникающих компромиссов. Проблему деградации показателей решают с помощью аудиторских контуров, единственная функция которых – периодически проверять, сохраняют ли данные других контуров связь с реальностью.

Иными словами, меняется структура процессов цикла. Цикл больше не изолирован в Системе

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

Рост без фундамента — путь к провалу Бурный рост бизнеса может выглядеть как успех — заказы множатся, география расширяется, команда растёт. Но если всё это происходит быстрее, чем укрепляются внутренние процессы, радость быстро сменяется проблемами. Перегрузка ломает то, что ещё не успело окрепнуть: срываются сроки, страдает качество, команда выгорает, а финансовые дыры растут. Перед масштабированием стоит задать себе честные вопросы: готовы ли вы к нагрузке? Есть ли чёткие процессы, достаточные ресурсы и гибкость в модели? Управление стартапом и зрелым бизнесом — это разная игра. То, что работало при малом объёме, может провалиться на большом. Рост — это хорошо, но только если за ним стоит прочная опора. Устойчивое масштабирование требует не только амбиций, но и системы Фаундер | Бизнес и Стартапы

#мнение Чем любят грешить менеджеры Здравствуй, дорогой читатель. Это пост про фильтр перед внедрением чего угодно в команду: сначала попробуй сам В целом проджекты/коучи/продакты и любый IT-менеджеры достаточно часто жалуются что внедрения буксуют, команды сопротивляются чему-то правильному и очевидно нужному. Меня давно раздражает ситуация, когда человек сходил на курс, посмотрел вебинар, словил инсайт, а затем через день несёт его как новый порядок жизни: теперь у нас OKR, переходим на Kanban, ИИ агент для логов и вообще всем курсор! И классика провести через ретро под соусом "tech excellence/улучшения инструментов/команда не знала о таком" Правило простое: не внедрять в команду то, что хотя бы минимально не пощупал сам. Не "прочитал", не "было на прошлом месте", не "знаю, как должно быть", а попробовал, пожил внутри и понял где бесит Первые пару лет бытности проджектом почти все мои внедрения и улучшения проваливались. Спасибо большое Жене из Яндекс Денег с позицией "ну ты сам научись дашборды делать в повербиай, а потом команде затирай как правильнее". Отсюда выросло огромное количество разных инициатив, которые я предварительно тестировал на себе. Вот несколько примеров 1) Когда я хотел больше прозрачности и нормальной гигиены задач, я сначала несколько месяцев кошмарил самого себя в Notion: цели, инициативы, месячные планы, задачи, статусы, прогресс, декомпозиция и связи задач 2) С OKR было так же: несколько лет связки годовые->квартальные->месячные цели, с полным трекингом и всеми OKR ритуалами 3) С ИИ безопасностью я несколько раз жестко косячил, собрал ai-repo-safety-skill и внедрял сканеры скиллов 4) С быстрым фронтом через ИИ я пошёл в OpenDesign, сделал несколько прототипов, а потом на внутреннем демо Twinby с автономными целями /goal и админкой на Angular знатно облажался. Полезная лужа, после которой я перестал лезть к разработчикам с советами в зоне, где сам ещё не прожил достаточно боли 5) С Text2SQL история такая же. Можно красиво сказать “давайте сделаем агента, чтобы менеджеры и аналитики сами спрашивали базу”, но потом приходят вопросы: как актуализировать метаданные, как объяснить агенту бизнесовый смысл полей, как ограничить доступы, как понять что ответ не бред и тп. Я поковырял VannaAI (царствие ему), сделал семантическую разметку и CLI на Rust. На скрине тот самый "txttsql" : агентик RAG, файловый семантический слой и защищённый read only SQL исполнитель для аналитики. Только после этого у меня появился сильный голос по таким вопросам Я не верю в менеджера, который должен уметь всё лучше команды. Если ПМ пишет код за разработчиков, дизайнит за дизайнеров, считает за аналитиков и ещё модерирует все созвоны, то он не молодец, а узкое место с конечной емкостью календаря. Но хороший менеджер должен хотя бы один раз зайти в чужую реальность ногами: хочешь понять разработчиков, сделай маленькую инженерную задачу; хочешь понять аналитиков, сам достань ответ из данных; хочешь внедрить OKR, поживи квартал со своими OKR; хочешь требовать прозрачности, стань прозрачным сам Любое внедрение должно начинаться с руководителя не потому, что руководитель умнее всех, а потому что он первым платит маленькую цену: пробует, ошибается, показывает где было больно и только потом приходит к людям с предложением что-то менять. Не “я придумал, теперь вы живите”, а “я попробовал, вот что понял, давайте проверим вместе”

Из чего состоит «сделать» Представьте, что на работе вас попросили добавить поддержку нового способа оплаты через Яндекс.Сплит. Если вы взялись это сделать, вот, что от вас ждут: Сначала вы очень хорошо подумаете и разберетесь в задаче. Куда добавить? Какие ограничения? Как это выглядело бы для клиентов? Затем вы очень хорошо подумаете о решении. Как это будет работать под капотом? Какие есть еще варианты? Что есть из готового, а что нужно и стоит писать самим? Какие требования и ограничения? Потом вы очень хорошо подумаете о краевых случаях. Какие они? Что с ними делать? На что можно забить? Какие не дадут запуститься? Тут вы еще и об ошибках подумаете. Скажем, что делать, если вебхук от Сплита пришел, когда мы лежали? А что делать, если Сплит вовремя не ответил, когда пытались создать заказ? Ретрай? Сколько раз, с какой паузой? Затем подумаете о данных. Что нам надо хранить, в каком виде? Это будет jsonb или нам вообще не нужен список товаров? А если решим расширить существующую модель заказов, как ее смигрировать? Что мы пока не знаем о данных и их хранении? Потом прикинете, как это все проверять. Какие тесты и для чего нужны? Что проверим автоматом, а что вручную? Есть ли у Сплита песочница, как в ней потыкаться? Потом придумаете, как запускать. Сразу всем? Втихаря на 10%? А за чем следить? Потом придумаете «анонс». Как и кому мы об этом рассказываем? Какие слова и термины используем, на что напираем? Что нашим клиентам от того, что у нас появился Сплит? Наконец начнете все это программировать. Возможно, сами, возможно, ллмкой. Проверите то, что получается. Что-то проверите автоматическими тестами, что-то руками, что-то агентом. Главное сейчас — убедиться, что оно готово к пуску. Затем ревью и пара-тройка раундов исправлений. Наконец смержите все в мастер и выкатите в прод. Еще раз убедитесь, что все работает. Не протыкал — не сделал. Если пуск затрагивает коллег, расскажете им об этом. Убедитесь, что не осталось хвостов. Если что-то нужно перепроверить через месяц-два, добавите задачку в календарь или агента. Поздравляю, теперь вы официально сделали задачу. P. S. Конечно, этот список меняется от компании к компании и от разработчика к разработчику. Если вы соло-предприниматель, все на вас. Если вы в бигтехе, анонсы писать не будете, но придется помудохаться с безопасниками. Если вы джун, от вас мало что ждут, но надеются, что вы со временем сможете закрывать весь список. Если вы сеньор, вы и сами все это знаете и регулярно делаете.

Из каких элементов состоит системная компания В прошлом посту мы подняли тему, что для роста на одном из этапов бизнесу придется начать строить систему. Давайте разберем, из каких элементов она состоит: Видение компании - кто наш клиент, какую проблему у него решаем, какая у нас линейка продуктов, какая наша стратегическая цель (хотя бы на 1 год), кто наши конкуренты и почему, чем мы отличаемся и куда идем. Четкая оргструктура - роли, которые отвечают за процессы в компании, их названия, кто кому подчиняется, у какой роли какой конечный продукт, какая система мотивации, функционал и полномочия. Люди в оргструктуре - люди стоят на конкретных ролях, знают их, понимают и исполняют. Кто-то может занимать несколько ролей. Но нет такого, что я просто вольный художник, делаю, что хочу. Финансовый учет - тут базово 3 отчета: отчет о прибылях и убытках, отчет о движении денежных средст и баланс. Идеально еще иметь бюджет на следующие 3 месяца и сверять его регулярно в разрезе план/факт. Описанные и соблюдаемые ключевые процессы компании - продажи, оплата, предоставление продукта и исполнение обязательств, найм и адаптация новых сотрудников, оплата заявок. Ритуалы регулярного менеджмента - еженедельные встречи тет-а-тет руководителей с каждым своим подчиненным о целях, планах и фактах работы, обратной связью, еженедельные общие собрания по отделам с подведением итогов недели, поощрением красавчиков и синхронизацией по движению к целям, ежемесячные общие собрания для всех сотрудников компании для общей синхронизации всех игроков на пути к целям. Аналитика - сбор и отслеживание ключевых показателей бизнеса: маркетинг, продажи, предоставление, финансы, Nord Star метрика. Естественно это невозможно без внедренных систем фиксации всех событий: CRM, календари, канбан проектов и задач и др. Стандарты найма - кто наш игрок, кто нет. Какие ценности. Какая планка. Обязательные этапы отбора. Описание процесса отбора самой массовой и повторяемой позиции в компании. Риск-контур - бухгалтерия, документы, GR, пароли и доступы, полиграф, хранение данных, контроль утечек, тайные покупки. Какие еще элементы забыл? Давайте докидаем в комментариях.

Пазлы — Как внедрить ИИ? — спросил владелец компании — Собирай пазлы Приходят месяц назад два предпринимателя. «Хотим, — говорят. — Искать клиентов с помощью нейросетей». Дал обоим схему: 1. Найти одного вручную, письменно фиксируя каждый шаг 2. Переложить один шаг на нейросеть 3. Повторить ручками все, кроме ИИ-кусочка Делать, пока большая часть задач будет автоматизирована. Один вернулся. «3-5 лидов на разработку сайтов в неделю, — говорит с восторгом. — Без манагеров». Второй пропал. Я сходил к нему. «Херня этот ваш ИИ: отдал схему сотрудникам, они объяснили, что без людей не поедет», — недовольно буркнул он. Похожие компании, процессы, цели. У одних — рекордная выручка; вторых — падение вместе с рынком. В одном случае фаундер сделал сам; другом — отдал «надежным» человекам. 200 лет наше образование производит винтики — людей, действующих по алгоритмам. Они умеют точить педали, озвучивать скрипты, идти по чеклистам. Но не создавать алгоритмы: ибо нет алгоритма создания алгоритмов :) Вывод прост: лучшее, что может сделать предприниматель в 2026 году — задокументировать процессы компании так, чтобы ими мог управлять ИИ. Выполнить этот квест может только он: и неважно, какого размера штат. Собирать пазлы страшно, муторно и непонятно. Люди такое не любят.