Ограничение рулит. Продолжение с числами

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

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

Пусть у нас есть маленькая команда из двух разработчиков и одного тестировщика. Все задачи перед релизом проходят и через разработку, и через тестирование. Разрабы пилят по 2 задачи в час, тестер справляется с 3 задачами в час. Разраб стоит 80 тугриков в час, а тестер — 60.

Посчитаем стоимость одной задачи по классическим человеко-часам. Для этого просто сложим стоимость задачи разраба и тестера. В итоге получим 60 тугриков. 80/2 + 60/3 = 60 тугриков

Если менеджера не устраивает стоимость, то он может использовать понятный приём — повысить эффективность самого дорогого сотрудника. Представим, что специальными средствами удалось повысить производительность программиста в два раза — до 4 задач в час. Стоимость задачи упадёт до 40 тугриков. Менеджер рад, на каждой задаче он сэкономил компании треть затрат. Можно рассчитывать на премию. 80/4 + 60/3 = 40 тугриков

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

Чтобы узнать реальную стоимость задачи, нужно поделить стоимость часа всей команды на те 3 задачи, которые она может релизить. Команда стоит 220 тугриков в час, а значит одна задача — 73.3 тугрика.

Когда разраб стал колбасить по 4 задачи в час, вся команда всё так же продолжила релизить только 3 задачи в час. Оптимизации затрат не произошло. Задача как стоила 73.3 тугрика, так и стоит. Можно повышать эффективность программистов хоть до 20 задач в час, но это никак не изменит ни стоимость задачи, ни скорость работы команды в целом.

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

Смотрите, оба разраба выдают в тестирование по 2 задачи в час, а тестер может переварить только 3 задачи в час — значит перед тестером растёт очередь из задач, которые нужно взять в работу. Каждый час в эту очередь добавляется одна задача. После ускорения разраба мы получим только то, что очередь перед тестером будет расти быстрее.

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

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

Наверное, все айтишники слышали фразу "тестировщик стоит дешевле разработчика, поэтому пускай тестирование [можно вставить любую грязную работу]". Если вдруг наш менеджер слишком долго работал в IT, то может провернуть ещё и следующий финт. Взять и отправить тестера на какой-нибудь неважный, но длинный звонок.

Ну а чё, он самый дешёвый член команды. Только вот после такого финта скорость тестера в этот день упадёт до 2 задач в час. А значит стоимость задачи вырастет до 110 тугриков.

Что в итоге. Наша команда тратит 220 тугриков в час и может релизить 3 задачи в час. То есть, столько задач, сколько способно "переварить" наше ограничение — тестировщик. Значит час работы нашего тестировщика будет стоить 220 тугриков. А любые оптимизации в работе программистов никак не изменят ни скорость работы команды, ни стоимость готовой задачи.

В следующий раз расскажу, как я применял ТОС в реальном проекте.