Современный IT менеджмент - штука довольно странная. С одной стороны менеджеры и прочие продукт-овнеры с задачами, проработанными до уровня “ну чтоб нормально было”. С другой, разработчики с видом таинственных мудрецов, рассказывающие, что программирование - работа творческая, а значит никакой оценке и предсказанию не поддающаяся. Все это обильно посыпано различными несомненно необходимыми ритуалами и заклинаниями в виде спринтов с покер-пленингом и скрам-мастерами, берндаун чартами, велосити и, конечно же, ревью-360. Не то чтобы я считал все вышеперечисленное абсолютно бесполезным, нет, просто случаев бессознательного встраивания этих эвентов и техник в свой рабочий процесс на моей практике встречалось в разы больше, чем их осознанного применения. Думать и въезжать в суть - долго и сложно, а копипастить из книжки или доклада - легко и просто.
Сталкиваясь с чьими-то управленческими решениями, или с необходимостью принимать эти решения самому, зачастую возникает интуитивное ощущение какой-то лажи. Жопой, как говорится, чую, что делать так не следует. Но почему? Как объяснить всем остальным и самому себе почему это решение “не очень”? И какое тогда “очень”? На лицо явный недостаток понятийного аппарата. Знакомство с Теорией Ограничений как раз предоставляет набор терминов и показателей, которыми можно оперировать при оценке тех или иных мер, а также вселяет надежду, что менеджмент это все еще про “думать и нести ответственность” а не про “джиру и митинги”.
Вот несколько утверждений, которые помогают ответить на вопрос “а задумали ли мы фигню?”:
- Цель коммерческой организации - приносить прибыль. Оказывается надо деньги делать. Не закрывать тикеты. И даже не писать “хороший поддерживаемый код”™. Деньги.
- Любое решение в первую очередь стоит рассматривать в контексте цели. Ожидаемый результат приближает нас к ней? Если да - хорошо, если нет, то давайте лучше сделаем то, что приблизит.
- Любой производственный процесс есть не что иное, как цепочка связанных действий, в которой есть “слабейшее” звено, ограничивающее производительность всей цепи целиком. Такое звено называется Ограничением системы.
- Невозможно произвести продукта больше, чем его способно обработать Ограничение.
- Простой Ограничения равен простою всей цепи целиком.
Какие же выводы можно из этого сделать? Во-первых, только Ограничение должно работать на пределе своих возможностей, в то время как все остальные должны подстраивать свою производительность под его пропускную способность. Иначе результатом будет рост объемов незавершенного производства, а значит дополнительные издержки. Во-вторых, все освободившиеся ресурсы остальной системы должны быть направлены на оптимизацию входного потока для Ограничения, т.е. делать так, чтобы нашему важнейшему звену было как можно меньше работы, а ту что осталось, оно могло выполнять как можно быстрее и проще. Плюс необходимо пробовать устранить текущего Ограничение и искать новое. В-третьих, любые изменения, улучшения и оптимизации, направленные НЕ на Ограничение - пустая трата ресурсов. Чтобы не было сделано, система не станет производить больше.
Рассмотрим, пожалуй, самый очевидный пример. Есть некая команда из трех разработчиков и одного тестировщика. И менеджер, конечно, куда без него. Пока продукт не протестирован, он не может быть доставлен клиенту. Тестировщик способен проверить то, что в среднем производит один разработчик. Как результат, мы имеем: вечно задолбаного тестера, работающего на пределе возможностей с постоянным ощущением “я не справляюсь и это все из-за меня”; раздраженного менеджера, потрясающего кулаками и вопрошающего “ну когда там уже?” и группу разработчиков, которые на любой вопрос разводят руками и говорят “оно в тестировании, ожидайте”. Ситуация довольно понятная, и, к сожалению, весьма распространенная. Что же можно с ней поделать?
Вариант раз. Не делать ничего. Оставить все как есть. Тестировщик в конце концов уволится, наймем нового, посеньористее. Разработчикам бонусы, они то вон сколько кода написали. Не самый плохой вариант. Лучше не становится, но и сильно хуже вроде тоже. Живем.
Вариант два. Ресурс разработчика очень дорогой. Поэтому его использование необходимо оптимизировать. Сходим на конференцию и послушаем про аджайл. Внедрим скрам, ретроспективы и пленинги. Начнем большой рефакторинг, чтобы можно было делать фичи быстрее. Наймем специального дядьку, наденем на него шляпу с надписью DevOPS, чтобы разработчики не отвлекались на всякое, а делали фичи еще быстрее. Разрешим не протестированный функционал катить в прод, но закрывать его за какими нибудь фича-флагами. Релизнуто - значит сделано. Рядом с тестировщиком посадим менеджера, приоритизировать его задачи. Не тестировать, вы что, время менеджера слишком дорогое, чтобы тратить его на подобное. Хороший план, неправда ли? Можно выступить на конференции и отчитаться об инновациях. Продукта правда выпускается столько же, а затраты возросли, но это лишь скучные детали, не будем об этом.
Вариант три. Делать столько “фич”, сколько способно переварить тестирование. Почему “тестирование”, а не “тестировщик”? Потому что в час нужды и менеджер и разработчики не чураются потратить свое дорогое время на то, что поможет быстрее запустить продукт. Освободившиеся ресурсы резработки направлены на автоматизацию и всяческое облегчение жизни тестированию, ведь цель всего происходящего - выдавать как можно больше продукта в единицу времени клиенту; сделать так, чтобы продукт как можно быстрее начал приносить деньги, или хотя бы какой-нибудь фидбек.
Данный пример, ясное дело, весьма утрированный. В реальной жизни все сложнее, есть масса нюансов, которые необходимо учитывать и вообще “не все так однозначно”. Однако он весьма неплохо иллюстрирует различные подходы к решению проблем, которые весьма распространены среди руководящего(и не только) состава. В процессе знакомства с трудами Годратта меня не покидала мысль: “ну это же просто здравый смысл. Нужно делать то что, нужно, т.е. соответствует поставленной Цели и не делать то, что не нужно, т.е. того, что этой самой Цели не служит”. Если все так просто, то почему тогда такое количество неэффективных и, порой, откровенно глупых решений принимается ежедневно? Остается лишь развести руками. Или писать заметки в бложик, в надежде, что это хоть кому-то поможет.