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

?v=1

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

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

ТОС


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

© Habrahabr.ru