Как вести журнал ошибочных решений в команде: от простого к сложному Цель журнала в том, чтобы фиксировать и показывать паттерны ваших ошибок на всём протяжении изменяющейся жизни а) продукта; б) команды и устранять именно их (паттерны-причины), которые создают следствия (ошибки). – Тегируйте каждую запись по типу ошибки: неверные изначальные данные, неправильная оценка, спешка, избегание конфликта, и т.п. причины. Анализируйте ошибки, ищите повторы, устраняйте причины ошибок, чтобы не лечить следствие ошибок каждый раз. Разделяйте плохое решение и плохой исход Четыре разных типа задач: хорошее решение и хороший исход / хорошее и плохой исход / плохое решение, но хороший исход / плохое решение и плохой исход. Самый недооценённый тип: «плохое решение / хороший исход», при правильном заполнении и поиске тех самых причин, в таких идеях спрятан ключ как вам прийти к самым успешным решениям. Пишите «пре-мортемЫ» заранее, а потом сравнивайте с настоящей причиной. Помогает подложить ту самую соломку где надо, знаю команду, в которой есть чел с отдельной ролью именно под это.

«Мы ожидаем изменение метрики на X%, уверенность в этом 70%». Это два разных ощущения, понимание их помогает калибровать общее ощущение вашей реальности

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

Записывайте, какую историю вы рассказали о решении с ошибкой (совет на будущее из прошлого: старайтесь избегать одной яркой истории)

– Самое полезное поле: «первые звоночки или первый момент, когда мы заметили/могли заметить ошибку». Ловите самые ранние сигналы ошибок. И эти сигналы могут приходить ощущениями ещё на стадии планирования (и даже раньше). – Второе по полезности поле: «что мы защищали»: утверждённый ранее родмэп, упрямство, личное авторство, бюджет, обещание СЕО/инвесторам, красивую историю-презу. Ошибки держится на подобном, пойми на чём именно. – Добавьте поле «Чья это была ошибка: человек / процесс / Система». Люди – без имён, это не поиск виноватых! Видя как ошибка живет на каждом из этапов, вы сможете лучше видеть слабые и сильные места в командных и продуктовых процессах и понимать, как на них влиять. Ещё одно недооцененное поле «Кто возражал и чем закончилось» для фиксации возражений которые вы систематически игнорите и недослушиваете (почему?). Часто, те кто возражают это: 1) люди с низким статусом в команде; 2) те, кто говорит осторожно; 3) тот, кто говорит самую больную правду и именно они часто оказываются правы. Ещё раз – без имён! – История побочных эффектов ошибок – то, что решение сломало в соседних фичах/механиках/процессах/метриках. Помогает видеть и лучше понимать связи внутри продукта. – Ведите журнал и по ошибкам конкурентов, это а) чужие; б) бесплатные уроки, и они могут делают вас лучше, чем собственные провалы, потому что в них нет эго, которое защищается. – Статус: «ошибка признана / решение пересмотрено / отменено» превращает журнал из архива в рабочий инструмент. Раз в год перечитывайте журнал и ищи решение, которое тогда казалось ошибкой, а теперь нет (или наоборот). Время переворачивает оценки чаще, чем кажется и является лучшим лекарством от уверенности в собственных суждениях (о времени). Будьте абсолютно честны, только так этот журнал будет работать. Честность в том, чтобы записывать даже те ошибки, которые страшно/некомфортно признавать. Свежий взгляд в журнал продукт возвращает честность. Spend ten minutes every day deliberately writing down what you got wrong. Not journaling about ego gratitude lists, but a f***ing. daily. error. log.

ИИ должен был упростить локализацию. Но на практике у многих команд получилось немного иначе: больше контента на проверку, больше правок, больше промптов и ещё больше решений. Отсюда и появляется та самая AI-fatigue (усталость). И проблема здесь не в самом ИИ, а в том, как мы встраиваем его в процессы. Если ваш пайплайн выглядит примерно так: AI-транскрибация → AI-перевод → AI-рерайт → проверка человеком → новый промпт → ещё одна проверка… То действительно ли мы экономим время? В идеале хороший ИИ вообще не должен постоянно напоминать о своём присутствии. Он должен тихо работать внутри процесса: забирать рутину, учитывать терминологию и контекст, а людям оставлять те решения, где действительно нужен человеческий опыт. Если же ИИ приходится постоянно контролировать, исправлять и перепромпчивать, то автоматизировали мы только производство контента. А всю возню вокруг него оставили людям.

Октябрь ворвался в нашу жизнь, разрушив планы на сентябрь 😀 Свел в кучку некоторые материалы, над которыми я усердно трудился. Я ведь пишу посты без ИИ, вот этими вот руками. Поддержите меня какой-нибудь реакцией 🙏🏻 Что там с ИИ ▪️Сейчас в мире ИИ обновления сыпятся почти ежедневно, уже внимание к ним ослабло, но за топовыми моделями следим тут и тут. ▪️Еще вот тут писал про новый класс моделей, очень быстрых в классификации. Сейчас, кстати, такие стали появляться и в опенсорсе. ▪️Чего ждать от ИИ до конца десятилетия - тут. Подходы и процессы ▪️Метод Event Storming для изучения командой бизнес-доменов ▪️Постановка задач с помощью EARS ▪️Поиск бутылочных горлышек в процессах с помощью теории ограничений В помощь разработке ▪️Структурирование контента с помощью schema.org ▪️Нагрузочное тестирование приложений Из жизни ▪️Экономим на MS Office ▪️Путешествие мухи во все тяжкие ▪️Почему кокпиты самолетов разных цветов #summary

Иллюзия простоты Со стороны кажется: нашёл нишу, запустил продукт — и прибыль на руках. Реальность другая: за каждым успешным проектом скрыта огромная работа. Анализ рынка, стратегия, процессы, управление командой, финансы, юридические вопросы — всё требует внимания. Пример: владелец небольшого кафе решил открыть «по простому»: арендовал помещение, купил оборудование, запустил меню. Через месяц понял, что гости не приходят, сотрудники путаются в заказах, поставки задерживаются. Только наладив систему заказов, обучение персонала и маркетинг, он вышел в стабильную работу. Что делать предпринимателю: ✅ тестируйте идеи на небольших партиях ✅ стройте процессы, а не делайте всё сами ✅ инвестируйте в обучение команды ✅ учитывайте все аспекты — финансы, налоги, маркетинг. 🛠 Бизнес простым кажется только тем, кто не понимает всех нюансов работы и ответственности. Фаундер | Бизнес и Стартапы

Любой бизнес хочет более быстрого развития. Если вы делаете публичный продукт, это позволяет быстрее тестировать гипотезы, привлекать больше трафика и в конечном счете заработать больше денег. Но, как и у плохих танцоров, все время что-то мешает. На эту тему есть Теория ограничений (Theory of Constraints, TOC). Сформулировал ее в своей книге Элияху Голдратт еще в 1984 году. Главный принцип очень прост:

Скорость всей системы определяется её самым узким местом.

Мы ж программист, поэтому возьмем в пример IT-команду: 👨‍💻 Разработчики быстро пишут код 🧪 QA быстро тестирует 🚀 DevOps быстро выкатывает Но все задачи перед релизом должны пройти через одного человека, который делает code review. То есть даже если команда увеличит скорость разработки в 2 раза, релизов больше почти не станет. Потому что ограничение осталось прежним. Согласно товарищу Голдратту нужно повторять в цикле 5 шагов: 1️⃣ Найди ограничение Что прямо сейчас тормозит всю систему? Это человек или процесс, из-за которого дело затормозилось. 2️⃣ Используй его максимально эффективно Убери простои, лишние действия и переключения. 3️⃣ Подстрой систему под него Остальные процессы должны работать с учётом ограничения. То есть сделай так, чтобы ограничение не выглядело таковым, будто всё так и должно быть. 4️⃣ Расширь ограничение Автоматизируй, перераспредели работу, добавь людей или ресурсы, чтобы увеличить пропускную способность. 5️⃣ Повтори Если ограничение исчезло, значит, узким местом стало что-то другое. Если нет, значит не докрутил, повтори. Один из методов TOC, применяемый в производствах, - барабан - буфер - канат: ▪️барабан — производство должно работать по установленному ритму; ▪️буфер — перед ограничением должен находиться некоторый буфер запасов материалов, защищающий ограничение от простоев; ▪️канат — материалы должны подаваться в производство только тогда, когда запасы в буфере достигли определенного минимума. В общем, применяйте в своих производствах, и будет вам счастье. #process

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

Как мы обычно тестируем новые гипотезы: 0. Рождение идея В ходе любой встрече, в душе или за толчком. 1. Мини-валидация Провалидировать среди старейшн - остальные фаундеры, C-lvl. 2. Рисерч рынка Добыть все, что возможно быстро. Если есть время и ресурс - сходить к потенциальному или действующему конкуренту - выбить инфу. 3. Подготовка почвы Отработать все сценарии. Приготовить документацию. Пообщаться со всеми стейкхолдерами. 4. Бенчмарки и метрики Устанавливаем правила игры на успех/провал в численном выражнии 5. Фокус-группа Шикарно если уже есть аудитория и протестировать все можно на ней. Отбираем горячих кроликов. 6. Тестовая прогонка Пошла костыльная работа, ошибки, много чатов и корректировок. Вскрылись первые пробелы подготовленной почты 7. Редакция v.1 Отработали возражения. Провели необходимую итерацию 8. Аутбаунд машина Погнали в Clay, Apollo, Instantly, HeyReach и тому подобное быстро набирать холодных кроликов в тестировании гипотезы. 9. Редакция v.2 Еще раз отработали на новой холодной аудитории 10. Включение перформа Собрали лендинг если надо. Заливаем траффик. 11. Синхронизация часов Вернулись в пунк 4 и сверили часы. Проход или нет. 12. Scale Если работает - разрабатываем, масштабируем, вливаем ресуры. Это примерно то, как это выглядит на стадии series-A. А если помоложе, то можно осуществлять все в 3-4 действия. Так стартап постепенно превращается в корпорацию.

Люди гибнут за канбан: 7 способов убить даже хорошую доску Сначала доска выглядит бодро. Всё красное, всё срочное, у каждой задачи дедлайн и высокий приоритет. Потом оказывается, что 18 задач просрочены, ещё 12 критические, а сигнал, который стоит почти на каждой карточке, уже ничего не значит. Где-то рядом висит задача «Работа с сайтом» на несколько месяцев, с десятками сообщений внутри, которую невозможно закрыть, потому что работа с сайтом как ремонт. Ни один из этих шагов не был глупостью, каждый делали из желания навести порядок. Отсюда и вырастают доски, которые команда уже не использует для работы, а просто обслуживает. И почти всегда путь туда собран из вполне разумных решений. Обсудим, какие семь привычек убивают даже хорошую доску и как на каждом шаге свернуть в другую сторону.

Про структуры и системы Попало прямо в сердечко, цитирую:

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

Ну правда жеж? #продуктовыйпуть

Почему люди ошибаются Случайно прикусить язык во время еды это прекрасный пример, что можно облажаться, даже имея многолетний опыт. Люди ошибаются по многим причинам:  1. Необходимость научения. Любой процесс требует определенных навыков, где-то больших где-то меньших. Если мы говорим про медицину — то даже такая простая вещь как поставить укол, требует определенных навыков.   2. Люди могут находится в разном физическом и эмоциональном состоянии. Усталые и голодные люди будут совершать больше ошибок, чем отдохнувшие и с достаточным уровнем сахара в крови.  3. Вариативность, которая свойственна как человеку как сложной системе. 4. Внешние факторы и другие причины.  Но одна из самых основных причин ошибок — это когда задача не учитывает особенности людей, тому как они обрабатывают информацию и как работают. Чтобы правильно проектировать процессы, нужно понимать особенности человека и то, как он взаимодействует со средой.  Этот раздел как раз будет посвящен особенностями работы человека. ;)

Завершилось лето, кончился отдых, можно нормально работать. На каникулах ленился я и прогуливал блог. Но теперь всё, баста, взялся за ум! Для начала - всех с началом учебного года! Новый год - как утро нового дня, новые возможности и перспективы, новые активности и привычки. Не прогуливайте свой блог, это затягивает, а жизнь не ждёт. Теперь итоги лета. Хотя плотность постов и была так себе, выделю кой-какие, которые вы, возможно, пропустили. Памятки, инструкции, курсы 🔹Терминология в сфере ИИ для начинающих 🔹Настройка Claude локально 🔹Анализ с помощью NotebookLM 🔹Свободные AI и ML курсы 🔹The AI-Native SDLC playbook Искусственный интеллект 🔹Stack Overflow для агентов 🔹Примеры ИИ в рабочих процессах 🔹Взлом HuggingFace Фронтенд 🔹Менеджер процессов PM2 🔹WYSIWYG-редакторы Инструменты 🔹Эмуляторы AWS 🔹Скрейпинг данных 🔹Сервисы туннелирования 🔹Геолокация по IP 🔹Развитие Git - GitButler Процессы 🔹Spec-Driven Development - SDD 🔹AI-Driven Product Development Lifecycle - AIPDLC 🔹Улучшение процессов через цикл Деминга - PDCA 🔹Jobs To Be Done - JTBD Найм 🔹Кого нанимают в 2026? 🔹Фиктивная компания в топе HH Опыт 🔹Про генерацию PDF 🔹Про гибридный (векторный+семантический) поиск Ну а мы тем временем продолжаем. #summary

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

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

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