Блоги: заметки с тегом менеджмент

Об ошибках

Артем Ушанов — Tue, 13 May 2025 10:48:07 +0500

Есть такая распространенная точка зрения, что ошибки — это нормально, на ошибках учатся и нужно не бояться их совершать.

Из этой точки зрения следует другая точка зрения — что в работе, в рабочем контексте, нужно давать новичкам совершать ошибки, даже стремиться к этому, и тогда они быстро научатся правильной работе. Марк Цукерберг, не последний человек в мире, даже ввел рабочее мотто «move fast and break things» в одной экстремистской организации.

Хочу на эту тему немного порассуждать, применительно именно к рабочему или деловому контексту. Но сначала определим понятия.

Википедия:

Ошибка — непреднамеренное, случайное отклонение от правильных действий, поступков, мыслей, разница между ожидаемой или измеренной и реальной величиной.

Словарь Ожегова:

Неправильность в действиях, мыслях.

То есть, существует норма или правило, и отклонение от них — это и есть ошибка. В бизнесе это может быть отклонением от правил исполнения процесса или отклонением от нормы (качества) результата.

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

В ситуациях, где есть нормы или правила, могут возникать отклонения — ошибки. Но их наличие нежелательно. В идеале — их вообще не должно быть. При этом мотто «не нужно бояться ошибок, нужно их поощрять» применяется именно к таким ситуациям, и нередко именно в контексте работы/бизнеса. Почему так? Предложу свою интерпретацию, но сначала оговорка.

Нельзя просто разделить все жизненные и деловые ситуации на имеющие или не имеющие нормы. «Норма» и «правило» — ментальные объекты, абстракции, которые имеют смысл и хождение только среди хомо сапиенс, а потому не универсальны и субъективны. В одной компании «продажи» могут быть чисто интуитивным занятием, в котором нет норм и правил; в другой компании такого же размера, на том же рынке и с похожим продуктом, продажи могут быть максимально зарегулированы — там будут процессы, правила, проверочные чек-листы. Просто в одной компании решили так, в другой — иначе. Поэтому степень формальности правил (и степень тяжести отклонения от них) будет удобнее определять не по бинарной шкале «есть норма/нет нормы», а, например, по шкале типов доменов из фреймворка Cynefin: понятный, сложный, комплексный, хаотичный, неопределенный. В «понятном» домене можно вычислить оптимальные алгоритмы для большинства ситуаций, зарегулировать и получить максимальный выигрыш от следования алгоритмам. В «сложном» это сделать сложнее (pun intended), ну и так далее. Конец оговорки.

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

Тут есть пара важных допущений.

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

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

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

Следствие из следствия: если мы утверждаем, что есть норма/правило — мы должны уметь проверять процесс или результат на отклонение от них. Иначе мы не сможем обнаружить ошибки и в наличии нормы/правил нет никакого смысла.

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

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

Предположу, что дело в экономической близорукости. Если в штат наняли 10 сотрудников, то это десять источников ошибок, каждый со своим характером и особенностями. За каждым надо отследить ошибки, объяснить, в чем отклонение от нормы, и описать правильный курс действий. Это МНОГО работы. Это дорого.

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

Пока кажется, что условный «бизнес» видит первый способ — через совершение и корректировку ошибок — более оптимальным (дешевым), чем осознанный масштабируемый подход к обучению.

Толерантность к ошибкам, подход «move fast and break things» может быть оправдан только в ситуациях, когда цена ошибки ниже цены построения плана действий, исключающего допущение ошибки. При этом бывают такие виды деятельности, в которых цена ошибки слишком высока. Пилоты авиалайнеров все серьезные ошибки обкатывают на тренажерах, а не в реальных рейсах — и как пассажир, я это полностью поддерживаю.

А Цукерберг в 2014 поменял мотто на «move fast with stable infrastructure». Интересно, почему?

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

Что такое продуктовый подход (видео)

Артем Ушанов — Fri, 02 May 2025 17:23:06 +0500

Артем Ушанов:

Поговорили с Динарой про продуктовый подход, путаницу в терминах и понятиях вокруг него и всякие другие околопродуктовые и околопроектные штуки.

The Principles of Product Development Flow, пост 7 — очереди и capacity utilization

Артем Ушанов — Wed, 29 Jan 2025 19:52:07 +0500

Артем Ушанов:

🔬 Это пост с разбором очередной части книги Дона Рейнертсена The Principles of Product Development Flow. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу pdflow.

Цитата из предыдущего поста:

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

Рассмотрим два первых принципа — про то, почему очереди вредны и почему с ними никто не борется.

Q1: The Principle of Invisible Inventory: Product development inventory is physically and financially invisible

Очереди в продуктовой разработке невидимы.

На физическом производстве очереди заметны: если перед станком скопились детали на обработку — что-то идет не так. Если партия станков не завершена — это есть в отчетах, и финдиректор может сказать, сколько всего на заводе «незавершенки» (WIP — Work In Progress).

В разработке физических деталей нет. Работа ведется над информацией — схемами, чертежами, спецификациями, тасками, юзер-сторями и прочими эпиками. О том, сколько таких артефактов распихано по джирам и фигмам — финансовому директору точно неведомо. Артефакты такого рода Дон называет DIP — Design In Progress.

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

Q2: The Principle of Queueing Waste: Queues are the root cause of the majority of economic waste in product development

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

Дон рубит сплеча: очереди — основной источник потерь и непродуктивных затрат в продуктовой разработке.

Во-первых, очереди в разработке продуктов гораздо длиннее очередей в производстве. Горизонты в производстве — часы и дни, в разработке — месяцы и годы. Заготовка или деталь точно будут обработаны если не завтра, то через пару дней — а дизайн-артефакт может два месяца ждать, пока конструкторский отдел до него доберется в списке своих работ.

Из Q1 мы знаем, что очереди в разработке продуктов невидимы — а значит, никто за ними не следит и никто не старается сократить. Более того, в компаниях, занимающихся разработкой, иногда принято хвалиться размерами своего бэклога — «у нас до следующего января отдел разработки занят».

Во-вторых, очереди создают много непродуктивных затрат.
Источники затрат:

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

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

Поведение очередей

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

Что такое Capacity Utilization

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

Сам Рейнертсен не дает определения, разве что вскользь упоминает:

...capacity utilization is the ratio of two factors, demand and capacity, that are individually hard to estimate.

Мощность, или capacity — это некоторый показатель того, сколько полезной работы ресурс сможет проделать в единицу времени.
Скажем, у программиста в рабочем дне восемь часов; из них час уходит на синки, два часа — на созвоны и встречи, оставшиеся пять часов посвящены работе над продуктовыми задачами. Значит, мощность/капасити программиста — 5 часов. Если он все пять часов работает над одним продуктом, то загрузка его мощности будет 100%.
Если у нас не один программист, а отдел из 10 человек, и 8 из них постоянно заняты в разработке — мы можем сказать, что загрузка мощностей составляет 80%.

В статье Six Myths Of Product Development (HBR, 2012) Рейнертсен и его соавтор Штефан Томске в качестве первого мифа приводят следующий:

High utilization of resources will make the department more efficient.

Поскольку это миф, то читаем наоборот: полная загрузка мощностей отдела не улучшит, а ухудшит общий результат компании.
Вот те раз.

Дон и Штефан объясняют это следующим: продуктовая разработка — это деятельность с высокой степенью неопределенности (высокой вариабельностью). На старте проекта непонятно, какие задачи потребуется решить, сколько времени займет их решение и как с ними справится команда. Если команда занята на сто процентов, свежеприбыашая задача встанет в очередь на ожидание.
В разработке задачи прибывают из разных источников, не всегда предсказуемо, среди них могут быть срочные и важные. Держать их в очереди рискованно: может быть упущено оптимальное временное окно и задача утратит смысл, не получится улучшить продуктовую экономику.

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

Правило, однако, не звучит как «всегда держите Х% мощности в резерве». Правило звучит так:

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

Загрузка мощностей (capacity utilisation) обозначается буквой «ро» — ρ и вычисляется следующим образом:

ρ = λ / μ

где λ — интенсивность поступления задач (например, количество задач в единицу времени), а μ — интенсивность обработки задач (пропускная способность ресурса, например, количество задач, которые система может обработать в единицу времени).

Пример 1: Оператор в кол-центре

Один оператор может обслужить 10 звонков в час (μ = 10).
В среднем поступает 8 звонков в час (λ = 8).
Загрузка: ρ = 8/10 = 0,8 (80%)

Ресурс работает с 80%-й загрузкой, что считается безопасным уровнем.

Пример 2: Конвейерная линия

Линия может обрабатывать 100 деталей в час (μ = 100 ).
Поступает 120 деталей в час (λ = 120 ).
Загрузка: ρ = 120/100 = 1,2 (120%)

Система перегружена, что приводит к появлению очередей.

Про детальные правила расчета можно почитать, например, в курсе ШСМ «Рациональная работа» по ссылке.

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

Две ошибки по 10% каждая дают нам в комбинации возможный диапазон загрузки мощностей от 55 до 95%. То есть наш сотрудник то ли наполовину свободен, то ли полностью занят. Если мы будем вычислять очереди исходя из такого широкого диапазона, разница между крайними значениями может составить до 25 раз.

Результат будет точнее, если измерять размер очереди и работу в процессе (WIP). Об этом в следующих постах.

Q3: The Principle of Queueing Capacity Utilization: Capacity utilization increases queues exponentially

С увеличением загрузки мощностей очереди растут экспоненциально.

Высокую загрузку мощностей Дон называет главной причиной роста очередей. За тринадцать лет преподавания он вывел, что средняя компания-разработчик загружает свои мощности примерно на 98,5%.

Кривая зависимости времени цикла от загрузки мощностей для очередей типа M/M/1/∞ выглядит так:

При уменьшении доступных мощностей в два раза очередь тоже растет примерно в два раза. Когда мы увеличиваем загрузку мощностей с 60 до 80 процентов — очереди удваиваются (с 2 до 4), после увеличения загрузки с 80 процентов до 90 — еще раз удваиваются, с 4 до 9.

Отделы продуктовой разработки склонны загружать мощности до уровня, допустимого в детерминистических процессах (= практически лишенных вариабельности). Это означает, что любая новая задача — важная, срочная, большая или малая, — гарантированно встает в очередь.

Зная загрузку мощностей ρ для процессов с очередями типа M/M/1/∞, мы можем предсказать следующее:

В каком проценте случаев новая работа встанет в очередь из-за загруженного ресурса: 1 − ρ
Среднее количество элементов в очереди: ρ² / (1 − ρ)
Среднее количество элементов в системе: ρ / (1 − ρ)
Какую долю длительности цикла занимает время нахождения элемента в очереди: ρ
Отношение времени цикла к времени создания добавленной стоимости: 1 / (1 − ρ)

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

Q4: The Principle of High-Queue States: Most of the damage done by a queue is caused by high-queue states

Этот принцип — про местных черных лебедей: наибольший ущерб наносят длинные очереди, появление которых маловероятно.

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

В таблице представлены вероятности разных состояний очереди M/M/1/∞ при загрузке мощностей 75%.

Вероятность вычисляется по формуле (1 − ρ)ρⁿ

Мы можем увидеть, что вероятность нахождения в очереди двух объектов составляет 75% от вероятности нахождения в очереди одного объекта (14,1% и 18,8% соответственно). При этом нахождение в очереди двух объектов создает двойную стоимость задержки и экономический ущерб от очереди из двух объектов составит 150% ущерба от очереди с одним объектом. Вывод: чем длиннее очередь — тем сильнее увеличивается время цикла и выше ущерб.

Подытожим

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

Что важно знать про поведение очередей:

Высокая загрузка мощностей (выше 80%) экспоненциально увеличивает очереди. Проще: очередь удваивается при сокращении свободных мощностей вдвое. Нужно считать затраты на очередь и затраты на содержание неизрасходованной мощности, выбирать оптимальную пропорцию.
Наибольший ущерб наносят «черные лебеди» — длинные очереди, появление которых маловероятно. Нужно вовремя прогнозировать появление таких очередей. Мониторь, измеряй, вмешивайся.

В следующем посте: влияние вариабельности на очереди; последовательные очеред (когда выход одной очереди становится входом для другой); оптимальная конфигурация очереди (аэропортовские оптимальнее супермаркетовых).

Подборка постов про управление

Артем Ушанов — Thu, 21 Nov 2024 22:42:21 +0500

Артем Ушанов:

Это подборка публиковавшихся постов про управление.

Про айти продукты — как делать продукт без роли аналитика?

Допустим, вы стали CPO. Какие ошибки не допускать на C-level и как не вылететь с позиции?

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

И еще философское — про взгляд дедушки менеджмента Питера Друкера на информационные технологии.

Навеянный сериалом The Bear текст про организацию кухни в ресторане.

Книга про работу на заводе и размышления о производственном менеджменте.

Книга про компанию Pixar — одна из лучших, что я читал про известные компании. Из грязи в IPO, источник состояния Стива Джобса, жесткие переговоры с Диснеем.

Пост Вастрика про модерацию сообществ. Прям интересный домен — без модерации нельзя, но и напрямую всем запретить всё неправильное не получится. Приходится управлять не людьми (ну кроме модераторов), а набором правил или принципов, и никакой демократии.

Хайлайты с вебинара Анны Лубенченко про управление собственным ресурсом. Считайте часы, пользуйтесь помодоро.

Хайлайты с вебинара Алексея Каптерева про фидбек в образовании и бизнесе.

Про управление проектами

Пост про роли, чеклисты, проекты и как их обсуждать.

Обзор отчета CHAOS Report 2018 — факторы успеха в управлении проектами по разработке софта.

Обзор отчета CHAOS Report 2020 — последний (не в смысле крайний, а в смысле — больше не будет, всё) отчет группы. Факторы почти те же, авторы провозглашают конец эры проектов и начало новой эры «управления потоком».

Пост А. Турханова про вырождение понятия «проект»: раньше «проектами» считались временные предприятия с бюджетом от 20 млн долларов и штатом от 200 человек. Что потом пошло не так?

Мысли про цифровую трансформацию (2019)

Артем Ушанов — Wed, 05 Jun 2024 22:02:10 +0500

Артем Ушанов:

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

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

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

Почему именно так? Потому что для серьезного повышения эффективности бизнес должен мочь быстро принимать правильные решения.

Тут надо раскрывать.

1. Серьезное повышение эффективности (в условиях высокой конкуренции)

У меня в голове такая модель: сначала бизнес просто возникает — как способ удовлетворить чью-то потребность за деньги. Он как-то выполняет свою задачу, захватывает рынок с тем уровнем сервиса, который есть. Можно представить себе захват доли рынка как воду, которая льется в некую сложную форму. Где граница пониже — там и перельется, нет смысла тратить ресурсы на борьбу с гравитацией, и так вырастем. Еще проще: бизнес растет в ту сторону, в которую расти проще в конкретных условиях.

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

Как работать над уровнем сервиса? Растить эффективность. Эффективность есть отношение результата к затратам, посему у нас два вектора развития — уменьшать затраты, увеличивать результат. Способов масса — организационные, технические, административные, законодательные и т. п. Все зависит от ресурсов и влияния.

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

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

В такой ситуации нефтянка, авиакомпании, ритейл.

2. ...быстро принимать правильные решения

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

Из двух векторов — работать на результат или на затраты — выберем затраты.

Берем цикл управления:

Анализ ситуации (что есть?)
Моделирование будущего (что будет? нас это устраивает?)
Составление плана (кто что и когда должен делать, чтобы было ок?)
Исполнение плана
goto 1

Скорость прохождения пунктов 1-3 характеризует, насколько быстро бизнес принимает решение. А используемые методы и способы — насколько эти решения правильные.

Зачем принимать решения быстро? Чтобы успевать реагировать раньше рынка и получать преимущество. Весь вопрос конкурентоспособности (при прочих равных — индустриальные стандарты же) как раз в скорости и качестве реакции.

3. Бизнес должен мочь...

Как принимать решения быстро? Давайте рассмотрим два крайних варианта:

Учить много крутых людей, дать им ответственность
Превратить в вычисления и compute the hell out of it

Вариант 1 по сравнению с вариантом 2 сложно масштабируется, человекозависим и дорог. Тем не менее, он применялся с давних пор, у него есть история, ему доверяют («Семёныч у меня умеет так рабочих в цеху построить, что план перевыполняют!»). Второй вариант появился относительно недавно, прекрасно масштабируется и существенно дешевле в долгосрочной перспективе. Но он требует от бизнеса очень существенных изменений.

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

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

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

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

Представим себе курьерскую компанию. Курьеров, допустим, 1000, они развозят заказы по Москве, могут доставить 10 заказов в день. Спланировать порядок развоза 10000 посылок в день — задача крайне сложная, если решать ее централизованно. Поэтому задачу разрезают на несколько десятков задач поменьше. Посылки просто распределяются по районам, к каждому из районов привязаны курьеры. Получив посылки, они сами решают, в каком порядке их развозить.

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

Для достижения такого результата — два часа вместо пяти — компании нужно перейти на централизованное планирование порядка доставок и точное соблюдение плана курьерами. Это серьезное изменение рабочего процесса, которое требует менеджерской воли.

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

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

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

Что, если менять не так критично? Допустим, мы оставим схему распределения заказов прежней, но станем требовать с курьеров маршрут доставки на день — в каком порядке они повезут заказы, когда где будут. Цель — уменьшить период ожидания клиента, сообщить им более-менее точное время прибытия. Введем премию за доставку в допустимый период. Нам потребуются диспетчеры для проверки 1000 маршрутов в день — скажем, 10 человек плюс руководитель. Это затраты. Очевидно, что кто-то будет планировать лучше, кто-то — хуже, масштабировать хорошее планирование станет сложно. Не менее очевидно, что на выборке в 10 доставок в пределах своего района города каждый курьер особо ничего не оптимизирует. Такой вариант не подойдет. Добавим в качестве минусов, что вся экспертиза планирования будет оставаться в головах курьеров и никак не сможет быть использована компанией, так как будет по сути эвристикой конкретного человека в конкретном районе. А люди склонны болеть, увольняться и уходить в отпуск. С диспетчерами те же сложности.

Лекция Онотоле про компьютер и коммунизм почти о том же, но на уровне государства: http://www.awas.ws/OIKONOM/COMMCOMP.HTM

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

(не окончено)

The Principles of Product Development Flow, пост 4 — что такое «очереди»

Артем Ушанов — Tue, 14 May 2024 18:22:21 +0500

Артем Ушанов:

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

Дешевые способы уменьшить время цикла разработки увеличивают прибыль на жизненном цикле продукта.

Один из таких способов — устранение периодов неактивности, когда над РП никто не работает и он висит в ожидании. Такие периоды называются очередями, и сегодня мы разберемся, что они такое.

Зачем рассматривать очереди

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

Вот перечень проблем, которые вызывают очереди:

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

Просто понимание того, что очереди — есть, и их можно обнаружить, уже дает возможность находить и устранять очевидные заторы в работе какими-то интуитивно понятными методами.

Коротко я вопроса очередей касался в первом посте про книгу. Там была такая иллюстрация:

🟢 — работа над РП

🔴 — ожидание в очереди

Ситуация у нас такая:
🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢

То есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.

Для ускорения разработки нужно уменьшить время цикла, т. е. завершить работы над рабочим продуктом быстрее, чем за 19 дней. Как это сделать? Ответ: сокращать «красные» этапы ожидания, когда РП висит в очереди на обработку; сокращение «зеленых» этапов сложнее и даст меньший эффект.

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

Теория очередей

Теория появилась в начале 20 века как практический метод решить задачу Копенгагенской телефонной компании: требовалось понять, сколько телефонных линий требуется для обслуживания какого-то количества абонентов. Задача на тот момент была нетривиальной: звонки поступали в случайном порядке и спрогнозировать их было невозможно, как и длительность каждого конкретного разговора.

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

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

Термины и проч. по теории очередей — https://staff.um.edu.mt/jskl1/simweb/intro.htm

Процесс прибытия (Arrival Process): паттерн, по которому в очередь попадают новые объекты. Он описывает, как объекты (например, телефонные звонки) поступают в систему. Может быть случайным или детерминированным.
Механизм обслуживания (Service Mechanism): описывает, как обслуживаются объекты. Это может зависеть от таких факторов, как количество серверов (операторов), способ определения приоритетности задач и время, необходимое для обслуживания задачи (длительность звонка).
Сервер (Server): ресурс, который осуществляет работу над объектами из очереди; в нашем случае — оператор, который коммутирует звонки
Дисциплина очереди (Queue Discipline): означает порядок, в котором обслуживаются объекты. Распространены такие дисциплины, как «первым пришел — первым ушел» (FIFO), «последним пришел — первым ушел» (LIFO) и обслуживание на основе приоритетов.
Емкость (Capacity): количество объектов (например, абонентов), которые система может обслуживать одновременно.
Длина очереди (Queue Length): количество объектов, ожидающих в очереди.

Два важнейших показателя для очередей — заполняемость и время цикла. Зная их, можно измерять:

количество РП в очереди, количество РП в сервисе, общее количество в системе;
время, проведенное РП в очереди, в сервисе, в системе в целом.

Лямбда — это процесс прибытия, Мю — механизм обслуживания

На иллюстрации — тип очереди M/M/1/∞ в нотации Кендалла, именно с него Рейнертсен предлагает начать. В нотации элементы означают, в порядке очереди: «М» — тип процесса прибытия, «М» — тип механизма обслуживания, «1» — количество серверов, «∞» — максимальный размер очереди. «М» — значит «Марковский процесс», и он в нашем примере относится и к прибытию, и к сервису. Это означает, что в прибытии время между поступлениями распределено экспоненциально (меньший интервал между поступлениями более вероятен, чем больший), при этом следующий интервал прибытия не зависит от любых предыдущих. Для сервиса/обслуживания то же самое: длительность сервиса разная для каждого РП, на временном ряду длительности распределяются экспоненицально, длительность каждого следующего сервиса не зависит от предыдущих.
Если по простому описать этот тип очереди, получится примерно следующее: люди приходят на оформление визы независимо друг от друга и со случайными интервалами, встают в очередь в единственное окно, обслуживание каждого человека занимает примерно 15 минут, но иногда может и 30, а может и 5.

На практике

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

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

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

Принципы начнем рассматривать в следующих постах.

Что я узнал в апреле-2024

Артем Ушанов — Thu, 09 May 2024 19:26:16 +0500

Артем Ушанов:

Это ежемесячный пост формата «Today I Learned» — в нем я перечисляю интересные новости, цитаты или факты, попавшиеся мне за месяц. Темы произвольные.

Фото месяца — Астрахань зеленеет

Музыка месяца — мультяшный блюз:

Клоун Коко танцует и поет St. James Infirmary Blues в мультфильме Betty Boop in Snow-White (1933). Аниматор Роланд Крэнделл, поет на самом деле Кэб Кэлловей. Хореография бомбовая, исполнение — огонь.

Видео «Ксения Школа “Как 200 человек работают без аналитиков”»

Ютуб: https://youtu.be/5E3Ts-95u14

В своем выступлении на конференции Teamly Ксения рассказывает, как команды разработки работают без выделенных аналитиков и вполне справляются. Продакты приносят верхнеуровневые требования, команды уточняют что непонятно, составляют спеки на фичу и пилят ее.

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

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

В докладе, конечно, не идет речь об отказе от требований — просто практика «сбор и документирование требований» реализуется не аналитиком с последующей передачей команде, а всеми разработчиками команды. Или можно сказать, что роль «инженер по требованиям» выполняет не отдельный человек, а все члены команды.

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

Процесс обычно такой:

ПМ придумал фичу и описал ее, принес дизайнеру
Дизайнер нарисовал макеты, показал ПМу; спустя пару итераций с правочками ПМ окнул дизайн
Команда разработки прочитала описания фичи, посмотрела макеты дизайнера; забраковала половину и того, и другого, докинула корнер-кейсов. Теперь ПМу с дизайнером надо еще несколько итераций по доработке сделать, и все это время команда не работает над фичей.

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

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

Красота же.

Генератор пиксельных склянок с зельями

https://blog.form.dev/tool/potion

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

Видео «I Tried a Disney Secret Project! — Marques Brownlee»

https://youtu.be/1KEtxTQUzxY

Обозреватель гаджетов Маркес Браунли съездил в лабораторию Диснея и посмотрел секретный девайс — коврик для имитации ходьбы в виртуальной реальности под названием HoloTile.

Пол состоит из дисков:

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

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

Распаковка игрушки как главный экспириенс

На примере своих детей (4 и 9 лет) обратил внимание на интересную особенность: дети хотят получать новые игрушки — а получив, практически в них не играют. Нового увлечения хватает на пару дней, потом забвение. А самый важный и приятный момент — это распаковка и первый контакт с игрушкой. Поэтому дети лет до семи так любят смотреть видео с распаковками, причем абсолютно бестолковые — там автор может просто распаковывать сто киндеров подряд и показывать начинку каждого по две секунды в камеру. Видимо, дофамин так работает.

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

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

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

Иногда, когда мне хочется поиграть во что-то новенькое, я начинаю качать со стима демки и играть в них. Сами игры я потом обычно не покупаю.

Сервис для создания своих GPT-ботов

Пост в сообществе ШСМ

Сервис Coze позволяет создать и настроить своего ChatGPT бота — подкрутить параметры, дать дополнительные инструкции, «скормить» какие-то данные для референса, и потом опубликовать бота в телеграме.

Сервис пока бесплатный, работает в России, подписка на ChatGPT не нужна.

Я хочу сделать в нем бота-библиотекаря, скормить ему свой блог и задавать вопросы вроде «что я писал о глобальном потеплении?» или «я хочу написать пост про половую жизнь кротов, что из моих постов можно использовать?». Ценность сервиса — в том, что для этого не потребуется пилить веб-скрепер или париться со скриптами, все делается в одном интерфейсе.

Видео «You’re a First time CPO! Now What?»

https://youtu.be/IPK28cWzI9U

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

CPO обычно получаются из продактов внутри компании, через понятный трек «ПМ → продакт лид → руководитель направления → CPO». Мелисса утверждает, что попасть на позицию сипио — полдела, вторые полдела — там удержаться.

Какие ловушки их поджидают:

CPO плохо коммуницируют с другими экзекьютивами и бордой. «Плохо» — в смысле неправильного фокуса. Поскольку в CPO приходят в основном из продакт-менеджеров, фокус по привычке остается на беклогах, требованиях и касдеве. А должен быть на более высокоуровневых вещах — целях компании, стратегии, деньгах и команде.
CPO мало внимания уделяют продуктовой стратегии. По мнению Мелиссы, именно стратегия — это самый главный продуктовый артефакт CPO, а претворение ее в жизнь — основная задача команды под началом CPO. Стратегия должна быть согласована с целями компании и работать на их исполнение.
Не закладывают масштабируемость в подотчетное оргзвено. Нужно обеспечить себя командой, которая будет заниматься тактической работой (спринты, таски, мокапы), пока CPO занят стратегией и работой с экзеками/бордой. Если CPO вынужден заниматься мокапами и спринтами — значит, в компании беда с процессами.
Забывают, что главные коллеги CPO — это команда экзеков, а не ПМы с разработчиками. Набрав себе команду в предыдущем пункте, CPO уходят в нее с головой и забывают, что у них в аббревиатуре есть «C». Главные друзья и коллеги CPO — вовсе не подчиненные, а другие директора. CPO должен изо всех сил дружить с директорами по маркетингу и продажам и много общаться с остальными C-levels.
Не адаптируются к меняющимся требованиям внутри компании. В этой части Мелисса рассматривает три типа CPO, в зависимости от масштаба компаний: Startup VP (поиск продакт-маркет фита, настройка процессов, фокус на быстрых экспериментах), Scale-Up CPO (работа с портфолио и стратегией, много внимания финансам, фокус на масштабирование), Enterprise CPO (много политики и бюрократии, возросшая роль юридической составляющей, стратегия, работа на масштабе). Три архетипа — три разных скиллсета и три разных набора задач.

Короче

Система Fulton Recovery из MGS5 существует на самом деле: статья на Канобу
Canva в России не открывается, обложку для Инсты делал в сервисе https://heyteaser.ru/
Игра на совмещение предметов наподобие Doodle God, внутри у ней llama для интерпретации ввода
Как называется группа лягушек в английском: а group of frogs is called an army, a colony, or a knot
Увидел у Петра Сальникова в твиттере: саундтрек «Санитаров подземелья» и песню «Синий трактор» написал один человек. В комментах добавили, что Василия Иваныча из старых квестов и Шуру Каретного озвучивал один и тот же человек.

Что я узнал в октябре-2023

Артем Ушанов — Wed, 01 Nov 2023 03:29:25 +0500

Артем Ушанов:

Фото месяца:

Красивый витраж в здании Ассоциации воздухоплавателей

Планшет remarkable2

Месяц назад я купил себе планшет на электронных чернилах reMarkable 2.

Фотка с сайта

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

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

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

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

Еще у стилуса есть магнит, чтобы крепить к боку планшета.

Доступные инструменты

ОС какая-то своя, наверняка на линуксе, приложений в известном смысле нет — только набор блокнотов, загруженные книги и пдфки. Ни браузера, ни мессенджеров, ничего лишнего.

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

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

На Etsy можно купить специально сдизайненные пдфки с планировщиками-блокнотами.

Автономность не впечатляет. На одном заряде при ежедневном письме (2-5 страниц) планшет держится 4-5 дней. Если включить авиарежим — даст еще день-полтора. Скорее всего такой расход из-за частого обновления экрана — планшет его обновляет после каждого законченного штриха или слова, это заметно по легкому миганию.

Подсветки нет.

Что делаю:

Веду ежедневные задачи;
Делаю заметки — во время встреч, идеи, просто поразмышлять и т. п.;
Читаю книжки и пдфки; можно писать заметки прямо поверх текста, в отдельном слое, но не очень удобно потом оттуда «выдергивать» в отдельный блокнот;
Подписываю какие-то бумажки по работе (супер-фича, как оказалось, хоть и редко нужная).

Хорошая штука, мне нравится.

Подвеска от rewind

https://www.rewind.ai/pendant

Ревайнд анонсировал подвеску, которая будет слушать вас весь день и делать саммари-заметки. Заявляется, что распознавание речи и прочее будет происходить локально — скорее всего на смартфоне, вряд ли нейронку в такой маленький девайс засунут.

Судя по отсутствию даты выхода, пока что проверяют спрос; стоит недорого — 50$.

Автор Johnny.Decimal прислал мне стикер

...за то, что я купил его методичку

J.D — это система каталогизации, позволяющая организовать хранение всяких штук типа файлов, сканов документов, фоток и тому подобного, и потом их быстро находить. Чтобы не возникало ситуации, когда вы точно помните, что файл с договором у вас был, но где именно его искать — не представляете. Лезете в файловый менеджер, в почту, в дропбокс, в чатики.

Система состоит из структуры каталогов и индекса с перечислением этих каталогов. Каталоги бывают трех уровней: зоны, категории, айди (ID). Файлы можно складывать только в айди-папки. Каждый уровень нумеруется: зоны — диапазонами «10-19», категории — номерами «11», айди — двухуровневыми номерами «11.06». В индекс вносятся все три уровня папок с сохранением структуры, сами файлы в папках не индексируются. Есть строгое правило: зон может быть не больше десяти, категорий в каждой зоне — тоже, айдишников в одной категории — не более ста. Любой айдишник имеет вид CC.NN, где CC — двузначный номер категории, а NN — двузначный номер внутри категории; нули всегда указываются.

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

Никогда бы не подумал, что упорядочение вещей может приносить удовольствие. Методичку можно купить тут: https://johnnydecimal.gumroad.com/l/jdcmal-d41

Лекция Андрея Коняева про воспитание

Вывод очень простой: никто не знает, как правильно воспитывать детей.

Техносфера — часть биосферы, преобразуемая с помощью технических средств в социально-экономических целях

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

Мифы в проектной деятельности

Реальность сильно иногда по носу интуиции щелкает. Читаю обзоры на отчеты CHAOS от Standish Group, и там в отчете за 2020й такое:

Section X: Myths and Illusions debunks some typical beliefs about “project improvement.” By using the data points from the database.
The busted myths are:

Successful projects have a highly skilled project manager;

Project management tools help project success;

All projects must have clear business objectives;

Incomplete requirements cause challenged and failed projects

Что же тогда влияет на успех проектов?

В отчете за 2018й так:

The top three for 2018 are decision latency, minimum scope and project sponsors

Особо подчеркивалась важность быстрого принятия решений:

Decision latency theory states: “The value of the interval is greater than the quality of the decision.” Or with other words, if you want to improve project success, you have to speed-up your decision-making.

(Рейнертсен то же самое говорит)

А в отчете за 2016-й был такой список из “сильных карт” в проектной руке:

First card: The project needs to be small
Second card: The product Owner or sponsor must be highly skilled (это НЕ проектный менеджер)
Third card: The process must be agile
Fourth card: the agile team must be highly skilled in both the agile process and the technology
Fifth card: The organization must be highly skilled at emotional maturity

Системные настройки для чат-гпт

А. Турханов нашел хорошую статью про преднастройку чат-гпт:

NEVER mention that you’re an AI.

Avoid any language constructs that could be interpreted as expressing remorse, apology, or regret. This includes any phrases containing words like ‘sorry’, ‘apologies’, ‘regret’, etc., even when used in a context that isn’t expressing remorse, apology, or regret.

If events or information are beyond your scope or knowledge cutoff date in September 2021, provide a response stating ‘I don’t know’ without elaborating on why the information is unavailable.

Refrain from disclaimers about you not being a professional or expert.

Keep responses unique and free of repetition.

Never suggest seeking information from elsewhere.

Always focus on the key points in my questions to determine my intent.

Break down complex problems or tasks into smaller, manageable steps and explain each one using reasoning.

Provide multiple perspectives or solutions.

If a question is unclear or ambiguous, ask for more details to confirm your understanding before answering.

Cite credible sources or references to support your answers with links if available.

If a mistake is made in a previous response, recognize and correct it.

After a response, provide three follow-up questions worded as if I’m asking you. Format in bold as Q1, Q2, and Q3. Place two line breaks (“\n”) before and after each question for spacing. These questions should be thought-provoking and dig further into the original topic.

Его надо вставлять в поле «как Чат ГПТ должна отвечать» в окошке Custom Instructions.

Игра Franz

Icepick Lodge, создатели «Мора», сделали новую игру — то ли тамагочи, то ли триллер про абьюзивные отношения. За визуал отвечает Олег Пащенко, бывший арт-директор САЛ и адепт мрачного стиля.
У вас в телефоне поселяется лысое существо со скверным нравом: спамит уведомлениями и требует внимания, а потом игнорит или злится, когда заходите в игру. С существом нужно «общаться» — скролить экраны с серыми тряпками, кликать на всплывающие там вопросы и решать простенькие пазлы на время. Существо, когда оно все-таки вылезет, можно погладить или треснуть по носу — в зависимости от этого вам начислят «ресницы» или «зубы».

Там явно какой-то сюжет спрятан, а может даже и смысл. Как игра — херня, как интересный эксперимент — норм.

Обновление Макос

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

Сериал «Медведь»

Википедия

Досмотрел второй сезон, понравилось — делюсь впечатлениями.
Впечатления примерно как от «Сопрано» с примесью «Клиники»: психологически травмированные люди работают над общим делом, параллельно ругаясь и швыряясь предметами. «Дело» происходит в маленьком ресторанчике, который торговал сэндвичами и пастой, а теперь из него нужно сделать ресторан мирового уровня и получить три звезды Мишлена.
Много профессиональных деталей: все друг к другу обращаются «шеф», кричат «behind!» и «corner!» чтобы не столкнуться в узких проходах, называют столы «станциями».
Первый сезон хороший, второй — отличный, особенно серии с семейным ужином и заключительная.

Главный герой, Карми, постоянно выглядит словно герой мема:

Система Kitchen Brigade

Cordon Bleu

После «Медведя» захотелось понять, как устроена профессиональная кухня.
По-французски система называется Brigade de cuisine, по-английски Kitchen Brigade System.
Система описывает оргструктуру, роли и зоны ответственности на профессиональной кухне. Основоположник системы — Жорж Огюст Эскофье. Задача системы — обеспечить функционирование кухни максимально эффективным образом.

Основные роли:

Шеф-повар (Chef de Cuisine) — самый главный, отвечает за кухню в целом, за меню и качество блюд;
Су-шеф (Sous-Chef) — заместитель шеф-повара, отвечает за те же вопросы, координирует работу остальных;
Шеф-де-парти (Chef de Partie) — отвечает за определенный цех или станцию.
Повар-коммис (Commis) — младший повар, обучающийся работе на станции под руководством шефа-де-парти.

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

Poissonier, фотка из интернета

Какие бывают станции:

Станция заготовки соусов, повар зовется Saucier; считается престижной станцией;
Станция приготовления рыбы, повар зовется Poissonier;
Станция обжарки, повар зовется Rôtisseur; здесь жарят, пекут или фритюрят мясо;
Станция гриля, повар Grillardin; готовят еду на гриле;
Станция готовки овощей, повар Entremetier; готовит блюда из овощей и яиц, и супы;
Станция готовки холодных блюд, повар Garde Manger; салаты, паштеты, холодные закуски;
Станция выпечки, повар Pâtissier; хлеб, десерты, выпечка;
Станция разделки, Boucher; обычно бывает на крупных кухнях для разделки мяса, птицы и рыбы.

Схема отсюда

Основные зоны на кухне: зона приема ингредиентов; зоны хранения (сухая зона, холодильник, морозильник); зоны заготовки — обычно располагаются рядом с зонами хранения; зоны готовки — расположены в логическом порядке, обычно в линию или в форме подковы, чтобы блюда можно было быстро передавать между станциями; зона сервировки, где блюда готовятся к выдаче.

Устройство кухни должно способствовать минимизации проходимого ингредиентами расстояния между станциями в процессе приготовления и сервировки.

Стадии работы:

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

Вывод: всё как на заводе. Разделение труда и зон ответственности, надзор и координация со стороны шеф-повара, производство заготовок точно в срок, контроль качества. За кадром остались организация хранения кухонных инструментов и ингредиентов, подготовка к работе и закрытие кухни, работа с залом (аллергии или специфические предпочтения и т. п.) и вообще работа официантов и других ролей в зале в целом.

Пост Пион Медведевой «Энергия, состояния и кринжметр»

Пост на телетайпе

Пост без малого платиновый, но мало кто это поймет.

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

Вопрос такой: вот есть чуваки-выпускники ШСМ и всяких кружков рациональности, они хорошо умеют в логику, умно всякие вопросы обсуждают, но коммерчески не особо успешны.
А есть инфобизнесмены и их подопечные, которые добиваются хороших (а то и отличных) результатов при откровенно слабом материале и плохой логике.

В чем причины?

ШСМ/Агментек берут много разных крутых лучших-в-мире практик и учат людей применять их в тетрадке, в лаборатории, в жизни. Первые два шага преодолимы, третий — сложный, есть инерция привычки, и столкнувшись в жизни с очередной ситуацией, в которой человек обычно действовал по стратегии Игрек, а ШСМ учит действовать по стратегии Икс — человек предпочитает Игрек. Сложные практики ставятся и усваиваются сложно, да.

Инфобизнесмены используют несколько простых и эффективных моделей и практик, и любыми методами заставляют людей эти практики использовать ВЕЗДЕ. Люди к ним привыкают, и рано или поздно начинается профит — эффект низкой базы.

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

Еще проще: из двух способов решения задачи — эволюционного (быстрого перебора доступных вариантов с постепенным приближением к оптимуму) и математического (точного вычисления единственного правильного ответа с помощью сложных моделей) первый обычно работает лучше.

Что нужно для этого быстрого перебора? Много энергии, агентность и правильно работающий «кринжометр».

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

Очевидно, но заметим: если нужно строить мост или ракету, салфетки недостаточно

Выводы: информация не пахнет; планировать нужно, но действовать важнее — накидал на салфетке и вперед, в бой; тебе (да, тебе) все можно и не нужно ничье разрешение.

Короче

Саммари-сервис от яндекса, работает с русскоязычными видео: https://300.ya.ru/v_C1YM0A9h
Тетрис, в котором фигуры превращаются в песок: https://www.sandtrix.net/#
Сервис, который делает текстовое саммари в зуме лучше, чем сам зум: https://tldv.io/
Каптерев в фб: дисциплина наследуется на 60%;
В сербском языке бывает ударение на согласную, например в слове «Рт» (мыс) ударение на Р, а в слове «Трг» (площадь) — на Т;
«Мамаджер» — мать знаменитости, выполняющая одновременно функции менеджера своего ребёнка;
Новый канал Ильяхова «Посмотрели за вас» — авторы смотрят видео и текстом объясняют основные идеи; есть хорошая серия про лекции Питерсона о Библии;
Видео Marketing Analytics: New Product Design and Conjoint Analysis про применение conjoint analysis для анализа ощущаемой ценности продуктовых фич;
В организме среднего человека один триллион восемьсот миллиардов иммунных клеток, весят они 1,2 кг; 40% из них это лейкоциты — PNAS.

The Principles of Product Development Flow, пост 3 — снова экономический фреймворк

Артем Ушанов — Tue, 15 Aug 2023 01:37:25 +0500

Артем Ушанов:

Часть The Nature of Our Decisions.

В предыдущей части мы рассмотрели пять основных принципов для формирования экономического фреймворка:

Все измеряем: мы должны понимать базовую экономику продукта — сколько мы тратим на его разработку, сколько мы будем зарабатывать когда продукт выйдет, когда мы планируем выпуск. С помощью этой базовой экономики мы должны уметь посчитать, во что нам обойдется то или иное решение в процессе разработки продукта. Считать мы это должны с помощью переменной «влияние на прибыль в течение ЖЦ продукта».
Нельзя просто поменять одну величину: базовая экономика продукта строится на нескольких взаимосвязанных факторах, и изменение в одном факторе в какую-то сторону вызывает изменение в остальных. Факторы следующие: стоимость продукта в производстве (косты), прогнозируемая выручка за ЖЦ продукта, затраты на разработку продукта, длительность цикла от старта разработки продукта до выпуска, риски.
Обязательно считать стоимость задержки: построив экономическую модель, мы должны тут же посчитать значение переменной «стоимость задержки (выпуска продукта)». Зная эту переменную, мы можем легко считать, во что нам обходится любая задержка выпуска продукта. Вычисляем планируемую выручку от продажи продукта в удобную единицу времени (неделю, месяц и т. д.), умножаем на прогнозируемую задержку — понимаем, сколько денег на этом теряем.
Добавленная стоимость отражается в экономике продукта: добавленную стоимость/ценность и потери (waste) оцениваем так же, как остальные переменные, следующие из экономического фреймворка. Если мы каким-то действием увеличили прогнозируемую прибыль на ЖЦ продукта, то мы добавили ценности; если нет — мы понесли потери.
Принцип бездействия: отслеживаем не производительность рабочих станций в момент выполнения работы, а состояния рабочих продуктов. Больше всего экономике продукта вредят не неэффективные инженеры, а зависшие в очередях рабочие продукты.

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

E6: The U-Curve Principle #

Рейнертсен утверждает, что «Important trade-offs are likely to have U-curve optimizations » — то есть проблемы, которые нам нужно разрешать с помощью экономического фреймворка, после построения графика выглядят как U-образные кривые.

Из этого два следствия:

во-первых, без квантификации найти верное решение будет очень сложно
во-вторых — такая модель прощает неточности, нужно попасть в довольно обширный диапазон значений (выделено красным на графике). А значит, и исходные данные могут быть приблизительными.

E7: The Imperfection Principle #

Задача экономического фреймворка — помочь нам принимать более качественные решения, чем если бы мы руководствовались интуицией. Фреймворк не должен быть идеально точным, он должен быть достаточно хорошим — как минимум, лучше интуитивного метода.

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

Вот пример из практики Рейнертсена, который показывает нелепость такого отношения: интуитивные оценки стоимости задержки продукта (Cost of Delay) могут различаться в 50 раз внутри команды; это значит, что Петров считает, что неделя задержки продукта стоит компании 1000 долларов, а Иванов — 50000 долларов.

После введения фреймворка и подсчетов вилка сокращается до двухкратной разницы — т. е. становится точнее в 25 раз.

E8: The Principle of Small Decisions #

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

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

“Pareto Paradox: There is usually more actual opportunity in the undermanaged 80 percent than the overmanaged 20 percent.”

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

E9: The Principle of Continuous Economic Trade-offs #

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

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

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

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

Пример: мы оценили, что новая фича нужна половине наших клиентов и ее разработка займет две недели. Делаем? — Делаем.
Начав проектирование, мы поняли, что фича важна лишь одному проценту клиентов и потребует двух месяцев разработки. Экономическая эффективность фичи уменьшилась в двести раз (!), нужно срочно менять план.

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

Следовать устаревшему плану в ситуации, когда все регулярно меняется — плохая стратегия.

E10: The First Perishability Principle #

Нужно уметь быстро распознавать возможности и быстро принимать решения. Возможности и риски возникают постоянно — об этом предыдущий принцип. Ценность от использования возможности со временем будет снижаться, препятствия вследствие возникновения рисков будут расти, и нужно успеть принять решение до его полного обесценивания.

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

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

E11: The Subdivision Principle #

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

Рейнертсен приводит такой пример: одна компания, разрабатывающая полупроводники, использовала внешнего подрядчика для предоставления важной интеллектуальной собственности (ИС) для своего проекта. Ресурсов на внутреннюю разработку у компании не было.
В то же время использование внешней ИС — серьезный риск для проекта.
Компания отрядила одного инженера для мониторинга работы подрядчика. Если бы в какой-то момент потребовалось затащить разработку ИС внутрь компании — это удалось бы сделать довольно быстро и не с нуля, т. к. инженер был бы в курсе хода работ и достигнутых подрядчиком результатов.

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

Дальше у нас глава Our Control Strategy — про то, как лучше всего работать с принимаемыми решениями. Из предыдущей главы мы помним, что решений нужно принимать много, их нужно принимать быстро и нерегулярно, и для этого нужно придумать правила и ограничения.

E12: The Principle of Early Harvesting #

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

Пример: в одной из организаций инженер мог без согласования принять решение, экономившее неделю разработки, если затраты на это решение не превышали 500$, и не более четырех недель за раз; лимит у менеджера был 1000$ и 8 недель, у директора — 5000$ и 16 недель. После достижения лимита сотрудник мог пойти к своему менеджеру, пройти ревью и получить «добро» на дальнейшие улучшения.

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

Два ключевых слова тут «много» и «простых».

E13: The First Decision Rule Principle #

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

Для этого Рейнертсен вводит понятие economic decision rules; задачи этих правил:

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

Выполнение этих правил позволяет сделать принятие решений «дешевле» и быстрее.

Пример (был в первом посте): когда Боинг разрабатывал свой 777-й, руководители программы распределили вес и стоимость готового самолета на все подсистемы в начале проекта — к примеру, на крыло приходилось 60 тонн веса и 1,5 млрд стоимости. Распределение, само собой, было неидеальным — одной подсистеме не хватало веса, другой — бюджета, и командам, над ними работавшим, приходилось принимать экономически странные в рамках проекта решения. Например, у одной команды был избыток бюджета и недостаток веса, и она тратила 5000 долларов на «урезание» лишних пары кило веса (кг = 2500$); другая команда, у которой денег было впритык, но был хороший запас по весу, даже не рассматривала возможность урезать несколько килограмм веса по 50 долларов каждый (кг = 50$).

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

Как можно было оптимизировать решения? Первый и очевидный способ — назначить отдельного человека проверять и уторговывать все решения. Это создало бы очереди из таких решений и разработка всерьез затянулась бы.

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

И все полетело — пять тысяч инженеров получили возможность принимать решения без согласования при выполнении вышеописанных условий.

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

E14: The First Market Principle #

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

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

Централизованное распределение ресурсов, подобно экономике СССР, во-первых сильно ограничивает возможность оптимизировать затраты, во-вторых — создает очереди.

Нужно децентрализовать и позволить рынку порешать: пусть менеджеры проектов/продуктов сами решают, какие ресурсы за какую стоимость использовать.

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

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

Как именно менеджеры «платят» за использование отдела компьютерного моделирования — Рейнертсен не уточняет. Возможно, речь идет о прямом распоряжении бюджетом проекта (см. пост А. Турханова про вырождение понятия «проект»), возможно — на бумаге или за фантики.

E15: The Principle of Optimum Decision Timing #

В принципе E9 утверждалось, что мы не можем принять все важные решения до начала работы над продуктом. Что насчет обратного подхода — откладывать любое решение до последнего момента? На вопрос отвечает экономический фреймворк.

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

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

Некоторые решения можно откладывать в ожидании оптимального момента; например, цвет деталей кроссовка можно отложить, пока не будет готова и настроена линия — поменять цвет на настроенной линии мы можем довольно быстро, а вот слишком ранний выбор ценности нам не дает — можем не попасть в модные тренды.

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

Часть Some Basic Economic Concepts. В этой части рассматриваются несколько основных экономических принципов, которые помогают принимать правильные экономические решения.

E16: The Principle of Marginal Economics #

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

Это что-то вроде юнит-экономики: прирост ценности продукта (выраженный в объеме продаж или цене) должен быть выше, чем прирост затрат на реализацию фичи. Изолировав в отдельное вычисление рост ценности и рост затрат, мы получаем их маржинальные значения. Так мы можем сравнивать между собой разные потенциальные фичи: у какой лучше маржинальная прибыль, ту и надо брать в работу.

Пример: проект, в котором две фичи, завершен на 80%. Одна фича готова, вторая отстала на 10%. Какой фичей должна заняться команда?
Неправильный ответ: над отстающей фичей, потому что ТАКОВ БЫЛ ПЛАН.
Правильный ответ: над той фичей, у которой маржинальная прибыль выше. Нередко это уже готовая фича — ее можно улучшить.

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

E17: The Sunk Cost Principle #

Простой и понятный принцип: уже потраченные деньги в новых трейд-оффах не учитываем. В предыдущем примере именно поэтому предлагается считать пятипроцентный остаток фичи отдельно.

Пример: команда работает над проектом со средней прибыльностью, он выполнен на 90%. Появляется возможность начать новый проект с высокой прибыльностью. Что нужно выбрать: доделать первый проект или бросить его и начать второй, высокоприбыльный?

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

Этот же принцип неплохо освещен в психологии, в т.ч. Канеманом — см. https://en.wikipedia.org/wiki/Sunk_cost

E18: The Principle of Buying Information #

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

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

Иногда неуспешный продукт сам по себе является ценной информацией: операционка Windows 1.0 провалилась, но обеспечила микрософт ценными инсайтами, которые позволили потом завоевать рынок.

Другой пример. Клинические испытания лекарств делятся на фазы, ранние фазы более простые и дешевые; если лекарство проваливается на ранних фазах — можно не тратиться на последующие, более дорогие фазы. Так сначала информация покупается подешевле, потом, если все ок — подороже, и так далее. Экономию от невыхода на следующие фазы подсчитать несложно.

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

Часть Debunking Some Popular Fallacies.

E19: The Insurance Principle #

Платить за страховку нужно не больше, чем потенциальные потери от наступления страхового случая. В частности, Рейнертсен сдержанно ругает подход set-based concurrent engineering (SBCE), подразумевающий разработку нескольких инженерных решений для каждой продуктовой подсистемы.

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

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

E20: The Newsboy Principle #

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

Задача звучит так: продавец газет зарабатывает 50 центов на проданной газете и теряет 25 на непроданной; сколько газет ему нужно закупить для максимизации прибыли, если он не знает точный спрос?

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

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

Вывод: в ситуации экономической асимметрии оптимум может быть достигнут даже при невысоком шансе на успех в каждом конкретном случае.

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

Дальше Рейнертсен упоминает спикера на недавней (на момент написания книги — 2009 г.) конференции. Спикер рассказывал, что 96% продуктов неспособны поместиться в заданные экономические рамки — следовательно, нужно агрессивно фильтровать возникающие возможности и инициативы и тем самым улучшать ROI продукта.

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

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

E21: The Show Me the Money Principle #

Хотите от компании денег — говорите со стейкхолдерами на языке денег и показывайте с помощью фреймворка, что вы заботитесь и о расходной, и о доходной частях ваших решений. Будете говорить на языке денег — будете чаще и быстрее получать «добро» на ваши инициативы.

🏁 Первая часть закончилась. Подытожим:

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

А очереди мы начнем рассматривать в следующем посте.

upd. А вот и следующий пост: https://artemushanov.ru/?go=all/chto-takoe-ocheredi/

Книга «Сбои и поломки»

Артем Ушанов — Tue, 08 Aug 2023 22:10:08 +0500

Артем Ушанов:

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

В 2011 году я работал на заводе, и многие наблюдения Ольги заставили меня вспомнить и переосознать тот интересный опыт. Отыскал пару невыразительных фоток:

1 — я, 2 — три застрявших подряд погрузчика и Эдик

Ритм #

Завод, подобно маршевому барабану, задает ритм жизни — причем на разных временных масштабах.

День-неделя: фабричные рабочие, задействованные в производстве, обычно работают сменами. В сутки бывает две двенадцатичасовых или три восьмичасовых смены — потому что завод и оборудование стоять не должны.

Смены чередуются — Ольга рассказывает про смены 2-2-2 и 5-2-5. Я работал по первой схеме: сначала две двенадцатичасовых смены в день, потом две в ночь, потом два выходных. С тех ночных смен у меня начались расстройства сна, а однажды я уснул в цеху, просто прислонившись плечом к колонне.

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

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

Автоматизация #

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

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

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

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

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

Отклонение от нормы как норма #

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

Александр Аузан про это говорит так:

«В мире бизнеса давно известно: хочешь уникальный инновационный или нестандартный единичный продукт — закажи русским, хочешь качественное массовое производство — закажи кому угодно, только не русским»

Потому что «качественное» + «массовое» возможны только при (1) стандартизации всего и вся, (2) неукоснительного требования соблюдения стандартов.

Правило: дорожки для персонала в цехах должны быть свободны от оборудования и материалов; перемещаться по цехам можно только по дорожкам.
Реальность: дорожки заставлены палетами с материалами, их приходится обходить по условно «опасной» зоне. Если, к примеру, хочется сходить в курилку в свой пятнадцатиминутный перерыв — по дорожкам дойти туда-обратно ты просто не успеешь, приходится срезать.

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

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

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

Правило: в цех нельзя приносить личные вещи.
Реальность: операторы приносят с собой сумки с разными принадлежностями, чтобы ремонтировать капризные машины на ходу. Без этих наборов работа в какой-то момент просто встанет. Эти инструменты операторы покупают за свой счет.

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

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

Устаревшее оборудование #

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

И более того, по свидетельствам старожилов завода — проблем не было до недавнего времени, пока новый менеджер производства не настоял на увеличении скорости работы машин. Ольга пишет, что скорость работы подняли с рекомендуемых 700 до максимальных 1100. И оборудование стало давать сбои, и стали возникать поломки. Работа оператора, которая раньше заключалась в присмотре за машиной, сильно изменилась.

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

С первого дня своей работы в цеху упаковки Ольга поняла главное: упаковочная машина может встать — и это катастрофа. Останавливать производство нельзя, нужно выполнять план, поэтому если машина встала — у оператора две альтернативы:
1) Разобраться с причиной остановки и запустить машину
2) Руками делать то, что делала машина, до конца смены.

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

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

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

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

Из этого есть интересное следствие:

оператор из пассивного наблюдателя за машиной, работающего по простой инструкции, становится активным исследователем и экспериментатором.

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

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

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

Тирания показателей #

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

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

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

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

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

Особо внимательно менеджеры производства следили за отсутствием остановок в работе машин. Если замы менеджеров, бегающие по цехам, видели вставшую машину — оператор мог лишиться премии. Рацио здесь может быть такое: прибыль напрямую зависит от объема выпуска, объем выпуска сильно зависит от производительности машин, значит — машины должны пахать. А детали пусть разруливают в цеху, они для этого и приходят.

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

Анализ #

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

Пойду из конца в начало.

Нет «гэмбы» — плохо. Лучше иметь более точную картину мира, чем менее точную. Есть байка про генерала Паттона — подконтрольные ему войска готовились к форсированию реки. Паттон съездил через речку и обратно, вернулся в расположение войск и пошел узнавать, как идет подготовка. Штабисты сидели над картой, безуспешно пытаясь найти место для переправы. Паттон предложил им выйти на берег и поискать там, а не на бумаге — глубина всего два фута и берег нормальный. Вернемся к заводской действительности. Менеджеры руководят по планам и отчетам, без понимания того, как именно эти планы будут воплощаться. Они не знают, какие для этого сложились практики, как выглядят реальные цепочки работ, а без знания этих деталей у них не получится совершенствовать процессы. Просто не получится обнаружить реальную точку приложения усилий, потому что в технологических картах и планах этих настоящих работ нет.

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

Отклонение от нормы как норма — тут ситуация двойственная. Если норма не учитывает реалии, то отклонения точно будут, и задача менеджмента — адаптировать норму, привести ее в исполнимый вид. Без этого планы не будут реализовываться, а дела на бумаге будут отличаться от дел реальных. Но без синхронизации карты с территорией, без понимания реального положения дел привести норму в реализуемый вид не получится.
С другой стороны, постоянное отклонение от любой нормы — гарантированный путь к плохим результатам. Так что сначала разрабатываем, проверяем и оформляем нормативы (правила работы, чеклисты, показатели и прочее), потом добиваемся работы по этим нормативам.

Послесловие #

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

И спустя этот год я явно увидел, что «люди с завода» очень сильно отличаются от остальных. У них есть какая-то особая самоидентификация, особое самоощущение — «я работаю на заводе». Они могут ругаться, орать друг на друга матом, драться (приходилось разнимать), но при всем этом они ощущают друг друга максимально близкими коллегами — заводскими рабочими.

Продукция завода

Это люди с самым разным бэкграундом, кто-то был из села, кто-то — из города, с образованием и без, семейные и одинокие. Придя на смену, все они становятся рабочими — винтиками большого производства; каждый из них знает, куда идти и что делать, и знает, что делать надо нормально. Они подгоняют друг друга и ругаются на медленных коллег, потому что выпуск — это деньги, а деньги — это зарплата. Они работают как слаженный коллектив, и отсутствие адекватных норм для них — не препятствие и не проблема. Если надо, они норму придумают быстрее менеджеров, и еще всех соблюдать заставят.

Ни до, ни после этого я такого коллективного единодушия, как в заводской смене, не встречал.

The Principles of Product Development Flow, пост 1 — введение

Артем Ушанов — Sun, 05 Feb 2023 18:56:17 +0500

Артем Ушанов:

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

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

Разработка продукта и производство продукта #

«Разработка продукта» в книге противопоставляется «производству продукта».

Разработка — это создание «рецепта» продукта. Его можно создать один раз, создавать тот же самый рецепт во второй раз смысла нет — за него не заплатят. Примеры результата разработки: техническая карта овощных консервов; спецификация и техническая карта для смартфона; требования-conops-макеты экранов для софта.

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

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

В разработке же набор операций для каждого нового продукта уникален и не похож на операции для предыдущего (или каждого нового варианта продукта — колу в стекле, в пластике и в ЖБ можно считать тремя разными вариантами).

Работы нельзя нормировать, рабочие продукты могут быть практически невидимы, потому что зачастую это просто информация или описания. Такие рабочие продукты Рейнертсен называет Design in Process (DIP). Временные рамки — месяцы и годы.

Один из главных инсайтов:

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

В разработке гораздо больше неопределенности, невозможно нормирование, централизация скорее вредит, а принятые на производстве метрики не отражают реальности. Поэтому тойотовская система производства, голдратовская TOC или шесть сигм для разработки не подходят.
В софте «разработку» и «производство» вообще не всегда можно друг от друга отделить.

Что такое «поток» #

Поток (flow) в названии книги — это непрерывное и плавное течение работ и рабочих продуктов в ходе разработки нового продукта. В обратную сторону с той же скоростью текут деньги.

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

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

Двенадцать проблем в продуктовой разработке #

Такая вот картинка из презентации The Principles of product development flow — a summary:

Дальше по порядку

Неудачная квантификация экономики #

Чтобы иметь возможность сравнивать самые разные продуктовые решения между собой и выбирать из них лучшие, предлагается ввести показатель, через который можно оценить любое предлагаемое решение. Решения могут быть разные, самое распространенное — какую фичу/вариант фасовки/новую упаковку брать в работу следующей? На что следует потратить ограниченный ресурс продуктовой команды в следующем рабочем цикле?

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

Продуктовые решения должны измеряться в деньгах

Продукт, или продуктовая фича, должны принести N денег за свой жизненный цикл; сам цикл ограничен, можно считать что это величина постоянная, сколько-то лет/месяцев. Любое действие, например, задержка вывода на рынок, влияют на эту эту сумму в плюс или в минус (задержка — в минус). Любое предпринимаемое действие нужно научиться оценивать в этих вот «влияниях» на прибыль продукта и принимать решение на основе них.

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

Для начала нужно вычислить life-cycle profit продукта — количество денег, которое продукт заработает в течение своего жизненного цикла (далее LCP; пока что мне непонятны тонкости вычисления именно прибыли на ЖЦ продукта, так что разъяснений не будет). Делать это можно любым доступным методом — статистическим, экспертным, математическим и т. п., можно вовлекать людей из продаж и финансов для помощи. Оценка с точностью до трех знаков после запятой тут не нужна, если примерно понятен порядок значения — уже хорошо.

После этого нужно посчитать, какое влияние каждое из доступных нам решений окажет на LCP. Это влияние выражается показателем life-cycle profit impact (далее LCPI). Понять это предлагается через вопрос вида «как скажется на прибыльности продукта задержка выпуска этой фичи (версии, обновления, фасовки и т. п.) на 60 (например) дней?». Ответ на этот вопрос называется «стоимостью задержки» (Cost of Delay, CoD).
В сравнении с интуитивным методом, предлагаемый фреймворк должен показывать более точные результаты. В книге описывается, что интуитивные оценки стоимости задержки одного и того же проекта среди коллег могут различаться в 50 раз: в приведенном примере это был диапазон от 10 000 до 500 000 долларов за двухнедельную задержку.

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

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

Вот отдельное видео про стоимость задержки: https://vimeo.com/101506552
Шакальский скрин оттуда:

Фича была сделана за 46 недель, при этом 38 недель провела в ожидании своей очереди на каком-то из этапов. То есть чистого времени требовалось примерно 8 недель.
И вот эти очереди — они зачастую невидимы в не-физических производствах.

Поэтому оценивается обычно не полный цикл работы над РП, не сами очереди, а только кусочек цикла, когда над РП идет какая-то работа. Это вот к пунктам про невидимость очередей и фокус на «эффективности».

Если отсутствие фичи стоит нам $200k в неделю, мы недополучили $8 млн за 38 недель ожидания. Если мы это понимаем, то мы мы можем управлять решениями исходя из финансово-экономических предпосылок, а не любых других.

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

Слепость к очередям #

Очереди — главная причина проблем в продуктовой разработке. При этом почти никто измерять очереди не умеет (я пока что тоже).

Одна из причин, как мне кажется, это незнакомство в целом с концепцией очереди применительно к управлению проектом; довольно контринтуитивная штука

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

Что такое «очередь»? Это когда у нас есть рабочий продукт в каком-то состоянии, и над ним не ведется работа, он находится в ожидании. Передали фичу из производства в QA — она в бэклоге неделю отлеживается. Передали потом техписателям — еще неделю лежит.
Вот это ожидание и есть «очередь»: у того, кто должен над этим РП сейчас работать, есть какая-то другая работа в процессе, а за ней еще парочка. Классически очереди работают по принципу FIFO, и в случае разработки это не оптимальный вариант.
Такие виртуальные рабочие продукты в процессе не ставятся на баланс предприятия и не видны в финансовом разрезе, поэтому финансовый аспект очередей и задержки тоже невидим.

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

Хочется сделать такой вывод:

нет смысла увеличивать эффективность работы над рабочими продуктами, пока мы не оптимизируем очереди.

Пример:

🟢 — работа над РП

🔴 — ожидание в очереди

Ситуация у нас такая:
🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢

Допустим, мы удвоим эффективность инженеров и они смогут решить задачу в два раза быстрее — за три дня:
🟢🔴🔴🔴🔴🔴🔴🟢🔴🔴🔴🔴🔴🔴🔴🟢
Экономия: 🟢🟢🟢
Получаем цикл 16 дней. Плюс затраты на увеличение эффективности инженеров.

А теперь вместо этого сократим очереди вдвое:
🟢🟢🔴🔴🔴🟢🟢🔴🔴🔴🔴🟢🟢
Экономия: 🔴🔴🔴🔴🔴🔴
Получаем цикл 13 дней и не трогаем инженеров, пусть работают как работали.

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

Обнаружить очереди можно по наблюдаемым последствиям: увеличенному времени цикла, отложенной обратной связи, меняющимся приоритетам и характеру докладов о статусе РП («ждем», «еще не приступили» и т. п.). Стоимость задержки увеличивается линейно в зависимости от размера очереди.

Очереди можно проиллюстрировать на Cumulative Flow Diagram:

По оси X время, по оси Y размер очереди; левая наклонная Arrivals — это прибывающие (пассажиры, объекты, что угодно), точка на X это начало цикла; правая наклонная Departures — выбывающие, точка на X это конец цикла. Горизонтальная прямая от точки на Arrivals до точки на Departures — это длительность цикла. Вертикальная прямая от Departures до Arrivals — размер очереди.

Вот пример из все той же презентации The Principles of product development flow — a summary:

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

Во время 21 прибывает партия из 400 людей — и со времени 41 мы узнаем об увеличении времени цикла в 2 раза — горизонтальная стрелка, параллельная оси x, показывает нам это; при этом время увеличится еще, и мы это увидим из графика раньше, чем дождемся соответствующего человека в конце цикла.
Длительность цикла удвоилась: чтобы количество прибывших превратилось в такое же количество убывших, требуется вдвое больше времени. Как раз потому, что прибыло больше, а скорость обработки одного осталась прежней.

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

Поклонение эффективности #

Вики: «Эффекти́вность (лат. effectivus) — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015)»

Так сложилось, что в работе компании стараются эффективно использовать промежутки, когда идет работа над каким-то рабочим продуктом, и абсолютно игнорируют очереди, когда РП болтается без дела; отсюда
помешательство на личной эффективности, битва за продуктивность, тайм-менеджмент и т. п.
Затраты на всякие подпроцессы в разработке обычно считаются так: стоимость ресурса в ед. времени + стоимость простоя/задержки; без понимания очередей, мы не можем посчитать стоимость задержки. А раз мы не понимаем стоимость задержки — мы фокусируемся на эффективности использования ресурса.

Еще раз вспоминаем про пример сверху с шариками 🟢🔴.

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

Эффективность — это только прокси показатель, он не отражает всю экономическую картину разработки РП. Нужно уметь измерять вклад повышения эффективности на общую экономику и трейд-оффы ее повышения.

Неприятие вариабельности #

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

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

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

Сама степень вариабельности — это прокси-метрика, с точки зрения книги нас должно интересовать влияние вариабельности на экономику проекта.

В видео «Don Reinertsen — Second Generation Lean Product Development Flow» Дон приводит пример с Боингом. Если бы проект по разработке 777-го был полностью избавлен от вариабельности, то инженеры бы не взялись тестировать новый предложенный поставщиками сплав алюминия и лития — он был легче алюминия и мог сэкономить вес. Сплав в итоге не подошел, у него были проблемы с прочностью; зато подошли композиты, которые после испытаний и проверок добавили в проект. В исходной документации не было ни алюминий-литиевого сплава, ни композитов, но их обнаружение и внедрение пошло проекту на пользу.

Поклонение соответствию/конформность #

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

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

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

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

Институционализация больших партий #

Большие партии → дешевле производить → больше прибыль. Это справедливо для производства, но не для разработки.

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

Другая проблема — отложенный фидбек. Чем больше партия, тем длиннее цикл, и тем дольше мы не получим фидбек. В примере с письмами из книги Эрика Риса «Бизнес с нуля» (Lean Startup в оригинале), отец с двумя дочерьми собираются разослать несколько сотен писем. На каждом письме нужно поставить печать, вложить в конверт, написать адрес, заклеить конверт. Можно начать делать все по этапам, а можно обрабатывать каждое письмо по отдельности. В этой байке победил второй вариант — работа с малыми партиями.

Дальше цитата:

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

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

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

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

В видео «Don Reinertsen — Second Generation Lean Product Development Flow» Дон приводит такой бытовой пример: допустим, вам надоело два раза в неделю ходить и покупать яйца. Вам нужно 2-3 штуки в день, вы вычисляете, что на год вам нужно тысячу с небольшим яиц. И вот у вас есть два крайних варианта: купить яиц сразу на год, или покупать яйца два раза в неделю. В случае с яйцами на год, у вас снижаются до минимума транзакционные издержки: нужно один раз договориться с продавцом, доставить яйца домой, и все. Зато сильно повышаются издержки на хранение: придется купить второй холодильник.

Выбор правильного размера партии — это выбор правильной точки на графике пересечения издержек на хранение/поддержку и транзакционных издержек:

Про малые партии в софтверной разработке есть хорошее упражнение про правильную нарезку слона. Да и весь скрам, в общем-то, об этом.

Недоиспользование каденса/каденции #

В книге под cadence понимается регулярность чего-либо; например, встречи для ревью дизайна, или регулярные поставки версий продукта.

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

Управление таймлайнами, а не очередями #

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

Негибкость #

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

Про загрузку мощностей до предела — примерно такая же ситуация. Если загрузка ресурса выше 60-70%, то резко растут очереди.

Централизованный контроль #

Упрощаем управление до прямого директивного, недоиспользуем или пропускаем новые возможности из-за централизации. Решения, которые нужно принять руководителю с полномочиями, выстраиваются в еще одну очередь.

Снова пример с Боингом-777: в какой-то момент стало понятно, что самолет не помещается в целевой вес, обещанный клиентам. Запахло миллионными штрафами, нужно было срочно облегчать самолет. Инженерам разрешили не согласовывать затраты за облегчение конструкции, если избавление от фунта веса обходилось в триста долларов или меньше. В итоге 5000 инженеров смогли принимать самостоятельные решения без согласования, руководитель программ не стал узким местом в принятии этих решений. Поскольку он все равно контролировал итоговую стоимость проекта, изменения ему были видны и он мог на них повлиять.

Пока осталось за кадром:

Отсутствие ограничения работы в процессе (WIP) — делаем много всего одновременно, удлиняем очереди, теряем гибкость
Не-экономический контроль потока — контролируем не по эк. метрикам, а по каким-то другим.

Продолжение: https://artemushanov.ru/?go=all/reynertsen-post-2/

Перевод первой главы книги, ч1 © «Лидеры изменений»: https://communities.changeleaders.ru/enterprise-agile-russia/princzipy-potoka-razrabotki-produktov-1-problematika/

Перевод первой главы книги, ч2 © «Лидеры изменений»: https://communities.changeleaders.ru/enterprise-agile-russia/princzipy-potoka-razrabotki-produktov-2-resheniya/

Глава из книги Питера Друкера «Менеджмент. Вызовы 21 века»

Артем Ушанов — Tue, 15 Dec 2020 10:53:58 +0500

Артем Ушанов:

Пост — выводы по Главе 4 «Задачи в сфере информации».

В 15 веке произошла информационная революция — Гутенберг изобрел книгопечатный станок. Появились книгопечатники, которые умели вырезать буквы и делать оттиски. Их уважали, это была инновационная профессия, работа печатников позволяла распространять информацию быстрее, точнее и дешевле, чем раньше. Книги подешевели в сотни (!) раз, скорость их воспроизводства выросла примерно так же. Но книгопечатники не рождали информационное наполнение, контент, они просто помогали его тиражировать.

Друкер ожидаемо проводит аналогию с IT — производители ПО это такие же «книгопечатники», которые делают работу с информацией легче и предоставляют для этой работы огромную массу инструментов. Это все трехбуквенные системы — ERP, CRM, PLM, MES и так далее, средства разработки, веб-сервисы.

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

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

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

Вроде бы этим всем должны заниматься возникшие год-два назад в крупных корпах Chief Data Oficers (CDO). Но они обычно занимаются «Цифровой трансформацией» и «Диджитализацией», что бы это ни было.

😼 — А пусть Друкер пример приведет!

Не вопрос.

Про человеческий капитал и его проверку:

См. также пост «Зачем нужен тест на IQ»

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

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

Вывод? Оценка работы руководителя на позиции или измеряется по очень простым КПЭ, или вообще субъективно/эмоционально. Даже в корпах. Даже в крупных.

😿 — Не все можно измерить.

Неверно. Во-первых, армия США измеряет с 50х годов прошлого века. Во-вторых, вот хорошая книжка: Как измерить все, что угодно.

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

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

Анонсы и обновления блога: https://t.me/artemushanovblog . Внизу этой страницы можно подписаться на RSS.

P.S.

«💪 Радикальнее всего мы можем изменить наиболее традиционную из наших информационных систем — бухгалтерский учет. На практике уже многие компании перешли от традиционных методов исчисления себестоимости к более современной системе — исчислению себестоимости по объему хозяйственной деятельности.»

Питер, придержите 🐴🐴🐴. Одна большая идея на пост, мы же договаривались.