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

Накопление ошибок Ошибки — они как тараканы: при свете — разбегаются.  Одна ошибка редко приводит к коллапсу всей системы. С маленькими ошибками справляется большинство систем. Хотя бывают случаи когда маленькая ошибка приводит к значительным последствиям. Например, один неверный поворот руля и мировая торговля замерла на 6 дней, когда контейнеровоз Эвер Гивен блокировал Суэцкий канал. (Хотя и там не все так просто: наложился сильный ветер, плюс в прессе упоминали технические неполадки).  В большинстве случаев ошибки и неполадки должны накопиться до определенного предела, чтобы произошла авария. Это видно из расследований, что авариям предшествует множество ошибок и маленьких неполадок, ошибок в коммуникации и т.д.  Если сразу обнаруживать и корректировать ошибки, то вероятность серьезных происшествий снизится.  В каких-то случаях это понятно интуитивно. Новые сотрудники будут ошибаться, и это естественно. Смысл обучения и подготовки сотрудников как раз в том, чтобы исправлять и корректировать эти ошибки. Если закрепиться неправильный способ выполнения, то откорректировать его будет гораздо сложнее.  В сложных системах, где влияет множество факторов и ситуация постоянно меняется — там могут ошибаться даже опытные сотрудники, поэтому необходимо быстро и четко понимать, что случилось не так.  Это как медсестры обнаружили, что ввели слишком большую дозу лекарства пациенту. Благодаря тому, что это быстро заметили, то негативных последствий удалось избежать.   Система обнаружения и исправления ошибок — это своего рода иммунная система. Как только мы поняли что за ошибка и научились с ней работать — ошибки подобного рода нам не страшны. Это как ослабленный вирус: обработали, научились справляться.  Если же мы замели ошибку «под ковер», то мы ничему не научились, мы не поняли как справляться с подобной ошибкой.  Чтобы обнаружить и исправить ошибки, нам нужно выполнять 2 параметра:  1) обнаруживать ошибки максимально быстро;  2) обнаруживать ошибки максимально полно.    #чф #ошибки

Хорошие ошибки То есть, у нас есть хорошие и плохие ошибки. На мой взгляд, критерием как мы можем отличить «хорошую» ошибку от «плохой» являются два вопроса: 1. получим ли мы новое знание от этой ошибки 2. может ли ошибка принести значительный ущерб Значительный — больше чем мы планируем потерять. По тому как процессы работают с отклонениям их можно расположить между двумя полюсами: 1. процессы, где отклонение приведет к значительной неудаче, катастрофе или аварии. Это обслуживание и управление самолетами, работа атомных электростанций, содержание опасных вирусов, управление машинами, массовое производство и тому подобные процессы. 2. процессы, где вариативность можно и нужно наращивать. Творчество, создание кинофильмов, поиск новых сплавов и/или материалов, разработка новых идей, поиск новых вирусов или молекул лекарства и так далее. Если мы хотим получить что-то новое — то надо начать делать неожиданные вещи. Понятно, что не надо хаотично дергать руль автомобиля, но попробовать новый варианты доехать до работы или с работы или попробовать новую кухню — хороший вариант. То есть, в ряде процессов нам надо наращивать вариативность или количество разнообразных ошибок. Можно запланировать систему, которая будет искать эти «полезные ошибки». Равно как Талеб предложил построить антихрупкую систему, которая за счет ошибок становится прочнее, точно также можно и настроить систему, которая будет искать эти новые возможности, и в том числе за счет ошибок — будет становится лучше. В обучении есть интересный парадокс: самое полезное для нас знание мы узнавали случайно. То есть, благодаря какой-то ошибке и какой-то вариабельности процесса. #ЧФ #ошибки

Лучший ход Кажется, я долго искал критерий хорошего архитектурного решения. Сейчас думаю про четыре штуки, которые одновременно делает "лучший ход":

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

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

После хорошего рефакторинга правильное решение начинает требовать меньше усилий, чем неправильное.

Возможно, именно это и является настоящей единицей эволюции сложных систем. Если так смотреть, эволюция сложных систем идёт не через новые объекты, функции или процессы. Она идёт через сдвиги в стоимости следующего перехода. Хороший пример из нашей работы — текстовый daily в Slack по шаблону «доставлено / планирую / блокеры». Проверяется по всем четырём пунктам: Локальная польза сейчас — утром за 2 минуты команда видит, кто чем занят, без созвона. Закрывает разрыв — не нужно дёргать людей в личку «ну что там у тебя», блокеры всплывают сами. Удешевляет следующий шаг — если у кого-то затык, помочь можно сразу, а не когда уже сгорело. Повторяют другие — новый человек в команде заходит в канал, смотрит вверх, копирует формат. Никто не объясняет заново. Форма поверхности изменена: написать по шаблону дешевле, чем не написать. Поэтому шаблон живёт сам, без напоминаний. А теперь посмотрите на свою команду. Поищите такие примеры — где хороший ход стал дешевле плохого сам собой, без напоминаний и продавливания. Делитесь в комментариях. Давайте обмениваться опытом 👇

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

Как повысить эффективность бизнес-процессов с помощью оптимизации пайплайна В любой сфере деятельности ключевую роль играет эффективность. Оптимизация пайплайна — это не просто улучшение отдельных этапов работы, а комплексный подход к повышению производительности всей системы. Такой подход помогает сократить издержки, ускорить выполнение задач и устранить возможные задержки. Начинать следует с детального анализа текущего процесса. Это позволяет выявить слабые места и понять, где именно теряется время или ресурсы. Следующий шаг — внедрение автоматизации, перераспределение ресурсов и использование современных инструментов, которые позволяют работать быстрее и точнее. Важно помнить, что оптимизация — это не разовое действие. Пайплайн требует регулярного пересмотра и адаптации, особенно в условиях быстро меняющейся рыночной среды и технологического прогресса. Фаундер | Бизнес и Стартапы

Когда ошибки полезны У меня не было никаких неудач. Я с успехом определил пять тысяч способов, которые никуда не годятся. В результате я на пять тысяч способов ближе к тому способу, который сработает. Для изобретения лампы накаливания Томасу Эдисону понадобилось поставить больше 11 тысяч опытов. Многие слышали такое выражение как «ошибайся часто». Эдисон вообще говорил, что у него не было ошибок — были успешные опыты, чтобы определить как не работает процесс. Если посмотреть на историю человечества, то ошибки принесли нам кучу пользы: пеницилин, стикеры 3М, липучки, слинки, микроволновка, каучук, медленная готовка, виагра и т.д. Америку, кстати, тоже по ошибке открыли. Плыли-то в Индию. Мы ведь можем настраивать процессы по-разному. Какие-то процессы нужно настраивать, чтобы снижать количество ошибок. А если ошибки нам могут принести пользу — то наоборот: нужно настраивать процессы так, чтобы ошибок было больше. Тогда возникает ключевой вопрос: а как определить какие ошибки полезные, а какие ошибки не очень? При каких условиях ошибаться хорошо? #ЧФ #ошибки

M&Ms — менеджмент — Как уследить за всеми? — спросил фаундер стартапа. — В неделю по десять новых сотрудников выходит. — По быстрым сигналам Менеджер группы Van Halen требовал, чтобы за кулисами музыкантов ждала тарелка M&Ms без единого коричневого драже. «Звездный выпендреж», — подумал я. Оказалось — хитрый метод управления. «Если мы видели хоть одну коричневую конфету — проверяли все. Организатор на площадке не читал договор — будут технические проблемы, которые могут разрушить шоу и даже поставить под угрозу жизнь группы», — рассказывал Дэвид Ли Рот. Чем больше масштаб компании — тем меньше возможностей следить за всем. Да это и не нужно. Достаточно определить «коричневый M&Ms» — выделить ключевое качество и простой метод его проверки. Например, в Stripe считают, что налоговые консультанты должны быть пунктуальны и точны. Поэтому встречи с ними назначают на 12.47. Те, кто приходят в 13.00, попадают под аудит. Вывод прост: случайная выборка в широком диапазоне снимает головную боль ——————————- Пост написан год назад. С приходом ИИ стал еще актуальнее :)

Что считать ошибкой Другой вопрос, который возникает, если мы займемся работой с ошибками — это что считать ошибкой. В школе нас приучили что для каждой задачи есть одно правильное решение. Любое другое решение — это ошибка. В жизни же совсем по-другому. Случаи, когда будет четкое разграничение ошибка / не ошибка — они достаточно редки. У нас будет больше ситуаций в серой зоне, где нельзя четко определить, что такое ошибка или нет. Во всех процессах есть различного рода отклонения. Профессор Деминг называл подобное состояние вариативностью. Вариативность — это в том числе разброс целевого параметра. Рост и вес людей колеблется в определенных пределах. Однако нежелательным состоянием является лишь определенные значения. Длина готового изделия также может колебаться в определенных пределах. Какое отклонение мы будем считать ошибкой? Что мы будем считать ошибкой? Но с отклонениями все просто. Уже определили какие отклонения при нормальной вариативности будут ошибкой. Но будет и другие случаи, когда мы не определяем ошибка это или нет. Банкомат не прочитал карту — это ошибка банкомата, специальная стратегия или испорченная карта? Это нормально или это ошибка? Почему это важно? Если мы признаем какой-то случай ошибкой — у нас появляется возможность исправить его, изменить процессы. Если же нет — то это событие у нас останется неисправленым. *** Давайте разберем такой случай. У пациента после операции стоит катетер в вене — он нужен для капельниц. Капельницы ставят утром и вечером. Ему поставили капельницу вечером в день операции и на следующий день утром. Вечером капельницу не поставили, так как его перевели на уколы. Катетер убрали после того, как пациент обратил на это внимание. По факту, катетер можно было бы убрать после утренней капельницы. Но катетер может стоять до 3х дней, так что никакого вреда пациенту не нанесли. Вопрос: как трактовать такое событие? С одной стороны — никакого вреда не случилось. С другой стороны — определенный дискомфорт, плюс непонятная коммуникация о том, как и когда надо убирать катетер. Если мы не представляем это как ошибку — то мы не работаем с этим событием, и мы не отлаживаем поток информации. #ЧФ #ошибки

Фабрики разочарований Мы пока не умеем щелкать и перемещаться в желаемую точку Б, поэтому дико прикольное занятие – искать "сдвиги" Иногда это чуть-чуть другой ракурс, чуть-чуть новая мысль, но она тебя меняет или, хотя бы, заставляет прийти в сознание На днях я наткнулась на классное определение:   Великие лидеры – это люди, которые считают себя доверенными лицами, распоряжающимися временем других людей Еще проще – вы даете людям цель, стояющую их времени Которая worth it! Когда я работала в ИТ-стартапе (доставка день-в-день), на рынке в РФ мы были топ-4. К нам приходили ребята на собеседования со словами "да не хочу я в Яндекс и Сбер, это не интересно, я хочу попробовать в команде, которая может с ними побиться" Я помню много-много лет любви к книге "Кто?" (Who) – как набирать А-плейеров, но есть очень простая история. У клевых людей всегда есть выбор, и они знают, что он есть! Просто деньги, просто плюшки, просто страховка – это такое "общее место" – ну ок, это везде есть. Но может и не быть, кстати, если есть забег, стоящий твоего времени Такой сдвиг меняет все - если ты руководитель, то нельзя просрать то, что тебе доверено (чужое время! второго такого не будет никогда) - если ты в команде – то совещания, процессы и так далее – нужны если они служат сбережению времени, пока мы бежим к цели, а не наоборот :) Есть емкая английская фраза – гуд фрикшен, бед фрикшен – хорошее трение и плохое, бесполезное Первое – заставляет вас думать Второе – сбивает с толку, истощает Компании часто думают, что для УСПЕХОВ нужны ИЗМЕНЕНИЯ. Прямо ВОТ ТАКИЕ А я постоянно повторяю, что нужны крошечные шаги и постоянная уборка, уборка, уборка. Уже напроцессили все процессов, пришло время каждые две недели что-то срезать, отказываться, переставать делать Мелочь? Но это все время, которое worth it! СЕО Дропбокс, кстати, назвал тупые встречи "OurMeetinggeddon" (от Армагедон или, лучше, – гандон? 😁🫶🏻) Начните выпиливать то, что вас бесит Вы очень друг друга полюбите за то время, которое заберете с фабрики разочарований, и пустите в хорошее дело :)

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

Ну подключите меня к задаче в таком случае В проблемных и кризисных ситуациях и дефиците времени реакцией коллег выше может стать фраза "ну подключите меня". Это значит, что коллегу нужно добавить во все переписки, коллы, раздать доступ и ОБИЗАТИЛЬНА воткнуть синк на 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 году — задокументировать процессы компании так, чтобы ими мог управлять ИИ. Выполнить этот квест может только он: и неважно, какого размера штат. Собирать пазлы страшно, муторно и непонятно. Люди такое не любят.