Нашел в своих заметках. Сегодня не пятница. Но я не умею ждать.

Увидел где-то в репостах материал одного из блогеров про продуктивность. Он привёл пример, который меня зацепил. Он написал, что мы всегда хотим сделать что-то хорошо и боимся оплошать, сделать плохо и поэтому часто даже не приступаем к действиям. Эта мысль меня поразила и подтолкнула к переосмыслению многих вещей. Я вдруг понял, насколько часто именно страх “сделать не идеально” блокирует любые шаги вперёд.

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

Когда мы слышим слово «перфекционизм» или представляем себе перфекциониста, нам сразу рисуется образ отличного работника — трудолюбивого, въедливого, чуть ли не идеального специалиста. Но на деле это не так. Это одно из распространённых заблуждений. Перфекционизм не гарантирует результат и не делает человека продуктивным. Он может парализовать, замедлить и даже полностью обнулить инициативу. Часто под маской “идеальной работы” скрывается просто незавершённая работа.

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

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

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

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

Это конечно база для продуктовой разработки и agile подхода, но бывает что увлекаешься идеей чего-то большего и забываешь делать итеративно.

Все же знают что такое MVP и итеративный подход? Просто на всякий себе продублирую:


1.Определите ядро ценности. Выделите один‑единственный сценарий, который максимально решает ключевую задачу пользователя.

2.Соберите минимум функционала. Сделайте так, чтобы он работал: пусть интерфейс будет сырым, а логика — базовой.

3.Запустите в «пилоте». Отдайте инструмент первой группе пользователей или коллег.

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

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

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

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

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

Возможно, не стоит доходить до пределов ребят из провинции Лакония с их «если», но пример с них брать точно стоит. В здоровом письме — здоровый дух. А лучшая встреча - это короткая встреча

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

Оказывается эта шайтан машина сама может и деплоить

Давно слежу за Notion. В последний год компания превращается в полноценное рабочее окружение офисного сотрудника или фрилансера. Причем делает это не путем сооружения гигантского комбайна, а отдельными приложениями и интеграциями.

Notion: для базы данных, проектов и документации

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

Notion Mail: пока переход на него идет со скрипом. Слишком гибкий для почтового клиента, от которого в большинстве ждешь что после установки все работает с коробки вполне достаточно.

И вот последняя новость: Notion может выступать бекендом для сайтов разработанных с помощью Replit.

Осталось сносную работу с таблицами сделать и в принципе можно полноценный флоу многих сотрудников закрыть

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

Если вам зададут вопрос: "Чем занимаетесь?": Вы наверно ответите, “Я юрист" или "Я руководитель отдела продаж" или что-нибудь подобное.

Но задумывались ли вы, насколько ПОВЕРХНОСТНО это описывает вашу деятельность?

Исследование McKinsey показало шокирующий факт: 67% сотрудников не могут подробно описать свои ежедневные рабочие процессы за пределами должностных инструкций.

Мы делаем то, что делаем, чаще всего потому, что "делали так всегда".

И это убивает инновации.

Недавний анализ 500 компаний от Harvard Business School выявил прямую связь между способностью точно описать свои процессы и инновационным потенциалом организации.

"Нельзя улучшить то, что не понимаешь," – отмечал легендарный бизнес-стратег Питер Друкер.

“Мы постоянно говорим о нашем ПРОДУКТЕ, но никогда не обсуждаем детально, КАК именно мы его создаем. Когда мы наконец проанализировали наши процессы, оказалось, что 40% действий были излишними или неэффективными” - говорит один из основателей EdTech-стартапа

Это не просто корпоративная проблема. Это вопрос эволюции нашего мышления.

Что делать?

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

ЧТО конкретно вы делаете каждый день
КАК вы это делаете
ПОЧЕМУ вы делаете именно так

Компании, инвестирующие в детальное картирование своих процессов, демонстрируют на 23% более высокие показатели производительности (Bain & Company, 2024).

Поставьте себе сегодня этот сложный вопрос: "Чем я НА САМОМ ДЕЛЕ занимаюсь?"
Ответ может изменить вашу карьеру и бизнес.

А вы можете детально описать, ЧТО именно вы делаете каждый день?

В общем я понял, вайб-кодинг это как однорукий бандит игровой автомат. Закидываешь монету в виде токенов и тянешь за рычаг, а потом уже как повезёт.

Все эти правила, библиотеки это как шаманские суеверия у лудоманов. Где-то сработало раз и используешь постоянно без влияния на результат.

Как одна страховая компания выросла с $1 млрд до $13 млрд, сфокусировавшись на ЦЕННОСТИ для клиента
"Мы всегда так делали" — самая дорогостоящая фраза в бизнесе.

Вот реальная история, которая это доказывает:

В 1990-х Progressive Insurance работала как все страховые компании десятилетиями:
Клиент попадает в аварию и звонит агенту
Агент заполняет формы и отправляет их в офис
Формы проверяются, сортируются, накапливаются в пачки
Через 5+ дней аварийный комиссар наконец выезжает оценить ущерб
Еще через несколько дней принимается решение о выплате

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

Внутренняя эффективность компании стояла во главе угла.

Но когда Progressive задались вопросом "ЧТО мы на самом деле делаем?", они выделили три основных действия, создающих РЕАЛЬНУЮ ЦЕННОСТЬ для клиента:
1 Сбор информации об аварии
2 Осмотр поврежденного автомобиля
3 Определение суммы выплаты

⠀Всё остальное — просто бюрократия.
Произошел идеологический сдвиг: от "времени компании" к "времени клиента".
Они поняли простую истину: клиенту нужны эти три ценности БЫСТРО, а не тогда, когда удобно компании.
Что они сделали?
Радикально перестроили процесс, максимально ускорив создание ценности:
Клиент звонит на единый номер 24/7 (информация собирается сразу и эффективно)
Один сотрудник берет на себя ПОЛНУЮ ответственность за весь процесс
Аварийные комиссары постоянно в разъездах на фирменных авто (готовы быстро осмотреть)
Комиссары работают в три смены для круглосуточной доступности
Решение о выплате принимается НА МЕСТЕ происшествия (мгновенная доставка третьей ценности)

Заметьте: базовые операции приносящие ценность клиенту остались теми же. Изменилась организация процесса и его фокус — на быструю доставку ценности клиенту.

Результаты?

Время доставки ценности клиенту: с 7+ дней до ОДНОГО дня.

Каждый день ожидания стоил компании $28 на аренду подменных автомобилей и хранение — почти полугодовая прибыль с одного полиса!

При 10,000+ претензий ежедневно экономия стала колоссальной.

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

Компания выросла с $1 млрд до $13 млрд годового дохода.
Средний годовой прирост — 17%. В консервативной страховой отрасли!
Из аутсайдера — в третью по величине страховую компанию США.
И все это без слияний и поглощений. Только за счет выявления процессов, создающих РЕАЛЬНУЮ ЦЕННОСТЬ, устранения всего лишнего и максимального ускорения доставки этой ценности клиенту.

Progressive поняла, что оптимизация процессов — это не просто операционная задача, а мощное стратегическое оружие.

Задайте себе эти вопросы:

"Какие именно действия в нашем бизнесе создают РЕАЛЬНУЮ ЦЕННОСТЬ для клиента?"

"Как быстрее доставить эту ценность, устранив все лишнее?"

Ответы могут стоить миллиарды.

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

Выше делал репост с канала Михаила Руденко, о том как знание зачастую ведёт к дискредитации инструментов, а не к увеличению эффективности работы.

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

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

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

Читая книгу Эрика Риса “Метод стартапа” нашел, как принято сегодня говорить фреймворк, для определения эффективности работы по обучению. Если быть точным, там речь была немного о другом) я его переделал под мой запрос. Возможно, HR’ы практикуют подобное, я не в курсе. Приведу вам его немного в переработанном виде.

Работа по оценке проведенного обучения проводится в 4 этапа:

1. Исполнение. Тут идет оценка, насколько сотрудники освоили материал. Осталось ли у них неясность или противоречия после прохождения курса?
2. Изменение поведения. После проведенного обучения стали ли сотрудники работать по другому? Применяют ли они приобретенные знания и навыки?
3. Результат для потребителя. Как отражаются преобразования в работе сотрудников на потребителях? Они положительные или негативные?
4. Финансовый результат. Ну и последний этап, не по значимости, а по воронке. Этап, на котором мы оцениваем возврат инвестиций в обучение.

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

Если вам в следующий раз кто-то скажет что-то типа “Да ерунда этот ваш фреймворк/методология” вы знаете какой вопрос задать следующим.

Прочитал очередную в этом году книгу по менеджменту - "Быстрее, лучше, дешевле" - Майкла Хаммера.

Подготовил для вас конспект:
https://telegra.ph/Bystree-luchshe-deshevle-Majkl-Hammer-Liza-Hershman-08-09

Как римские легионеры изобрели первый в истории рюкзак и создали самую эффективную армию древности

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

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

Сегодня мы будем говорить об упрощении в таком значимом в в древнем мире (да не только в дренвем) деле как война.

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

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

Результат? Колонна растягивалась на километры. Скорость передвижения падала до скорости улитки. Идеальная мишень для партизанских атак.

Решение: Консул Гай Марий принимает радикальное решение. Он распродаёт всех армейских мулов и приказывает: "Отныне каждый солдат несёт своё снаряжение сам!"

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

По сути, первый в истории походный рюкзак.

Результат: Армия Мария начинает проходить по 30 километров в день — невероятная скорость для того времени. Легионеров прозвали "мулы Мария" — они это название носили с гордостью.

Мобильность + дисциплина = непобедимость. Рим начинает свой путь к мировому господству.

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

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

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

P.S. Кстати, принцип furca используется до сих пор — в современных туристических рюкзаках с внешней рамой. Технология, которой 2100 лет!

Готовлюсь к обучению по AI и понял одну вещь: мы застряли в парадоксе.
С одной стороны, все говорят "AI — это будущее нашей работы". С другой — используем его как продвинутый чат для советов и генерации текстов.
Но если мы действительно хотим интегрировать AI в процессы, нужны агентные системы. А это уже не промпты — это код. Хочешь автоматизировать аналитику или построить систему работы с данными? Нужно понимать ORM, DRY, TDD, Git.
И вот тут возникает вопрос: как менеджеру (вроде меня) строить надёжные AI-решения, которые не будут сжигать бюджет на токены и галлюцинировать так, что результатам нельзя доверять?

Я вижу два пути:
1. Переориентировать технические команды на работу с AI-флоу. как гипотеза быстрое и дёшево проверить.
2. Погружать менеджеров в основы кода и архитектуры. Много крови и пота, но если получиться - в итоге очень гибкая и скилловая команда.

В последнее время очень много внимания и сил уделяю Ai крафтингу (честно пытался найти синоним на русском, так не смог). Плавно перехожу от сценариев использования ИИ в чатботах к активному использованию вайбкодинга и создания оценочных систем.

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

Возможно будет небольшой крен в эту сторону в моих постах. А пока держите первый интересный материал от Мартина Фаулера про стандартные сценарии работы с LLM:

https://martinfowler.com/articles/gen-ai-patterns/