Немного неудобно, но хочу поговорить о буферах +28




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

Это не чушь, и не шутка. Статья действительно о буферах. И она не про буфер обмена. Речь пойдёт о буферах, которые помогают работать лучше.

ТОС


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

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

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

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

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

Буфер в производстве


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

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

Решение предлагается простое, как дрова – создать перед ограничением буфер. Перестроить линию так, чтобы ограничению всегда было, чем заняться, и оно не простаивало.

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

Время – более универсальная характеристика, т.к. она понятна без знания производительности. Можно просто, без изысков и с полным здравым смыслом сказать: ограничение защищено на четыре часа. Или – у него буфер времени в четыре часа.

Что бы там ни случилось до ограничения, есть четыре часа на исправление – и за это время производительность линии не снизится.

Буфер в снабжении


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

Так вот, буфер в снабжении – это держать на складе столько единиц товара, чтобы хватило до следующей поставки. Логично до противного.

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

Буфер в данном случае тупо защищает от дефицита – отсутствия товара в тот момент, когда он необходим – неважно кому, собственному цеху завода или очередному покупателю пива.

Буфер в проектах


В проектах Голдратт ставит простую цель – уложиться в срок без снижения качества и увеличения стоимости. Прям как в рекламном буклете.

Что защищать в проекте? Недолго думая, Голдратт предлагает защищать критический путь – цепочку этапов или задач, которая определяет конечный срок выполнения проекта. Если учились в ВУЗе достаточно давно, то помните – нас всех заставляли этот критический путь рассчитывать.

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

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

Если память не изменяет, Голдратт утверждал, что все, как один, заложили буфер размером процентов в 90%. Но никто не хотел в этом признаваться, потому что оценки выполнения проектов не поддаются регламентации, и делаются «по опыту», который у всех обычно трудный.

На реальное выполнение каждого этапа проекта нужно примерно 10% времени, которое на него заложено. Это время, когда прям что-то делается, а не планируется или анализируется. А дальше просто – никто же толком не умеет укладываться в сроки и планировать свою работу. Имея запас времени, десятикратно превосходящий трудозатраты, всё равно все опаздывают, потому что начинают не вовремя (в книге это названо «синдром студента»).

Ну Голдратт и говорит – парни, хорош. Давайте мы все ваши буферы вытащим из оценок, суммируем и поместим в конец проекта. Никаких локальных буферов, только один общий – на весь проект. Точнее, на его критическую цепь.

Прям все буферы ему, конечно, не отдали, но в 2-3 раза свои оценки урезали. Заодно и срок проекта в 2-3 раза сократился, потому что в общий буфер пошла не вся сумма, а её разумная и объяснимая часть – начальство не согласилось на очень уж большой запас времени.

Всем парням сказали – не ориентируйтесь на сроки, просто делайте. Как можно скорее, но без увеличения стоимости или снижения качества. По сути, сказал ориентироваться не на плановую дату завершения, а на дату начала. Ну и всё заколосилось.

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

От чего защищает буфер?


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

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

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

Посмотрим на более приземленные примеры буферов.

Буфер недельных закупок


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

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

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

Буфер – техподдержка


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

Я раньше работал на заводах и, пока штат ИТ был маленький, проблему отсутствия буфера особо не ощущал. Ну, мешают мне звонки и сообщения в скайпе – я просто не брал трубку и не отвечал. Кому сильно надо – прибежит. И услышит, что я занят.

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

Человек на техподдержке стал буфером, защищающим развитие ИТ-систем.

Буфер – поменьше говорить


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

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

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

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

Хочешь что-то изменить – измени. Но не надо никому об этом рассказывать, пока не сделал. Такой примерно буфер. Защищает прям сильно.

Буфер коммуникаций


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

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

Мне нравятся эти буферы. Они позволяют не тратить моё «внимание руководства», которого и так мало. А кому сильно надо – всё равно найдёт, как связаться.

Бюрократический буфер


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

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

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

Буфер ценностей


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

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

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

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

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

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

Но это уже немного другая история – буферы, про которые мы не думали. Хотя, последние месяцы наглядно показали, кто думал о защите, а кто – об удобных ценностях.

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

Теперь, поняв принцип, хочу почитать ваши варианты буферов. Если они будут про программистов или их менеджеров – прям вообще хорошо будет. Заранее спасибо.




Комментарии (11):

  1. GraDea
    /#21928578

    Проблема применимости toc в IT в том, что боттлнек (в отличие от физических заводов) может скакать по системе. Сегодня затык в тестировании, завтра в разработке, потом в деплое. При этом мы могли ничего не менять. Накапливать буферы перед каждым потенциальным боттлнеком? Боюсь, вы утонете в незавершенке.

    • nmivan
      /#21928694

      После смерти Голдратта его последователи написали книгу «Новая цель», там этот вопрос рассмотрен, с плавающим ограничением.
      Они предложили такое решение — создавать ограничение искусственно. Известное ограничение лучше, чем неизвестное, т.к. понятно, куда усилия надо прикладывать.
      А вся остальная цепочка перестраивается под ограничение.

    • /#21929620 / -1

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

      • GraDea
        /#21930818

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

        • /#21931156

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

          • GraDea
            /#21932070

            Перед как раз нужен, вы имели ввиду?

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

            • /#21932342

              Да, описался.

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

  2. drWhy
    /#21928838

    Говорить о буферах на пальцах, без КДПВ и вообще без единой картинки просто непозволительно.

    КДПВ
    ??????

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

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

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

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

    Такая система работы Toyota получила название «система канбан», и ее назначение — управлять потоком материала, обеспечивая бесперебойное функционирование системы «точно вовремя».
    Джеффри К. Лайкер, «Дао Toyota: 14 принципов менеджмента ведущей компании мира»

    • genew
      /#21930580

      На секунду подумал что на КДПВ будут буфераы

  3. v1000
    /#21929656

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

  4. vaniacer
    /#21932012

    Все ждал когда тема перескочит на «буферы» но нет, поэтому вот:
    image