The Goal или почему стартаперам нужно прочитать
книгу про завод

The Goal – первая книга Голдратта (Eliyahu M. Goldratt), которая попала мне в руки. Я заглотила ее на одном дыхании вместе с длиннющим интервью в конце. Книга – о заводе. Об оборудовании, производительности, распределении ресурсов, логистике… куча терминов и незнакомая предметная область. Но она захватила внимание с первых страниц и не отпускала до задней обложки.

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

В какой-то момент Алекс – это главный герой – встречает старого знакомца – ученого и тот задает ему правильный вопрос:

Что такое продуктивность? Немного подумав, Алекс отвечает, что есть вообще-то формула, по которой продуктивность рассчитывается как добавленная стоимость на одного работника….

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

А действительно, как понять продуктивный ты или нет? Если ты работаешь 8 часов в день ты продуктивный? А если 10? А если открываешь фейсбук 15 раз в день? И у кого продуктивность выше – у тебя, который сидит на работе допоздна плюс выходные или у того парня, который в 18:00 уже уходит домой? И зависит ли она от того, что ты делаешь?

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

Сейчас, в 21-м веке мы уже знаем, что цель коммерческой организации – зарабатывать деньги. Но понимаем ли мы, что это значит? Каждое ли наше действие или действие наших работников приближает компанию к деньгам или нет?

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

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

Обычно компании измеряют свою работу в полученных деньгах – заработали за квартал столько-то. По сравнению с прошлым кварталом это составляет такой-то процент. Молодцы! Или не молодцы. Продвинутые компании считают чистую прибыль, ROI и Cash Flow. Интернет-компании к этому прибавляют измерения трафика и конверсии. Самые усердные компании измеряют каждого работника вдоль и поперек с помощью KPI.

Это все, конечно, хорошо, но не дает ответ на вопрос «Как улучшить показатели?», «Как заработать больше денег?». Допустим, померяем мы нашего рабочего – он переносит с места на место 20 рельсов в день, но если сильно постарается, то будет переносить 23 рельса. Ок, но сколько денег компании принесет перенос 3-х дополнительных рельса в день?

Перенесемся в наши ИТ-реалии. Допустим, у нас технологический стартап, в котором есть программисты, и они выполняют задачи. Меряем программистов скоростью выполнения задач (velocity). Хорошие программисты должны выполнять Х задач за спринт. Наладили систему, программисты сидят работают, не ленятся, стучат по кнопкам и даже кофе реже ходят наливать. Отлично!

Но приближает ли компанию к деньгам количество запрограммированных задач? В прошлом месяце закрыли 100 задач, а в этом 105, и что? И можем ли мы гарантировать, что все эти задачи сделаны качественно. Ведь если требовать от программистов быстро колбасить, то будет страдать качество кода.

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

Подглядела у ребят из Spotify (здесь и здесь) agile-схему, основанную не на скорости закрытия задач (velocity), а на скорости внедрения полезных улучшений (impact). Смысл в том, чтобы засчитывать изменения, которые действительно улучшают приложение. Изменение одобряется только если оно положительно влияет на заранее определенные метрики (изменяет поведение пользователей в лучшую сторону).

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

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

Книга закончилась, мне ее не хватило. К счастью Голдратт написал вторую – It's Not Luck, и она оказалась… впрочем, об этом написано в следующей статье

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