Для начала — начало.
С официальной частью покончено, переходим к делу.
Сразу предупрежу — сегодня я расскажу о скучной нужной теории, в следующем посте перейдем к рассмотрению методики на основании проекта — примера.
Немного нытья
В прошлом посте я попросил в комментариях помочь мне. Дело в том, что я не могу физически знать всего, не могу предугадать все ситуации и уж тем более с ними столкнуться. Мне искренне жаль, что никто в комментариях не стал отвечать на поставленный мной вопрос — какие еще маркеры можно использовать для определения стадии проекта как критерия для рассмотрения возможности начала работы над следующим. И это плохо, так как по сути получается монолог. Я бы хотел вести диалог с теми, кто читает эту серию постов, так как именно в диалоге можно получить дополнительные знания, передав их общественности. Почему так происходит — судить не берусь, причин возникает в голове много, как простых, так и обидных. Хотелось бы знать — имеет ли смысл в статьях вообще задавать какие то вопросы вам, читатели, или это — лишняя трата времени? (в очередной раз взял и задал вопрос :)))))
Теория ограничений
Или ТОС. Основоположник — Элияху Голдратт. Израильский физик — преподаватель, который в один прекрасный момент посмотрел и сказал — «Эй! Да в бизнесе действуют те же самые процессы, что и в физике, только никто на них не обращает внимания!». На данный момент, к сожалению, умер.
Основа его теории истекает из способа анализа данных. Вот что делаем мы, когда завалим очередной проект? «Неучтенные факторы, чтож поделать» — поделать что то можно, иначе бы вы все это не читали. «Ну так получилось, в следующий раз буду умней» — правда? Или вообще эпическое — «Так сложились звезды». Да, кстати. Надеюсь никто из вас не против того, что виноват в провале проектов он сам, а не какие то внешние факторы? Это я разжевывал в первых частях, за что кстати и получил несколько упреков. Если не согласны — либо перечитайте начало, либо вообще не читайте — смысл?
Что то я отвлекся. В общем и целом, мы не склонны проанализировать проблему с точки зрения банальной логики. В физике же, получив совсем не тот результат, который ожидалось, ученые не опускают результат как неудачный пример («Да это Зевс молнией херакнул»), а ищут ему простое и понятное объяснение. Ну или не совсем простое, иначе мы бы все были спецами по квантовой физике, но тем не менее укладывающееся в некие рамки и закономерности.
И вот этот самый дядька, жутко умный от физических знаний, и с соответствующим образом , решил взяться за бизнес. Да взялся так, что его консультациями пользовались огромное количество фирм, его литература стала настольным справочником подвижников теории ограничений, да и вес его и авторитет признавали и признают не в единой сфере.
Суть его теории заключается в том, что в любом производственном процессе существует некий ограничивающий фактор, самое слабое звено, которое и задает темп работы всей цепочки. Допустим, что на заводе деталь проходит последовательно через станки 1, 2 и 3. Станок 1 делает 100 деталей в час, станок 3 — 300 деталей в час, станок 2 — 10. Соответственно, производительность всей линии — 10 деталей в час.
«Да это же банально» — воскликнете вы. Дык. О чем и речь. Только сказать, что все банально, и принять действия, чтобы эту банальщину убрать — разные вещи. Вот что касается действий — тут все гораздо сложнее, так как отточено психологически на протяжении долгого времени.
Как бороться с ограничением
Итак, мы определили, что станок 2 у нас является ограничением цепочки, задающим ритм работы всей линии. Первое, что приходит на ум — увеличить его пропускную способность, попросту увеличив количество станков типа 2. Сейчас вы спросите — да какие, нафик, станки?! У нас программирование! Терпение, доберемся и до него, просто пример со станками проще в восприятии (ибо нагляден), а так же, так как ТОС требует пересмотра в корне мировоззрения, то — от простого к сложному. А пока просто попробуйте во время прочтения попытаться понять, как это можно применить к практике разработки ПО.
Увеличение количества станков — решение, конечно, но не факт, что на это есть средства, а так же не факт, что накладные расходы не увеличатся.
Второй способ не настолько прозрачен, и неприятен на уровне физиологии, но тем не менее это так — нужно ограничить производство на станке 1. В текущем виде мы только создаем горы запаса у станка 2, при этом связывая капитал. Почему это сложно? Потому что если человек не работает все время, то он бесполезен, и мы тут же нечинаем искать способы его сократить. Вид слоняющегося без дела тела приводит нас в подсознательную панику, так как мы, скорее всего, учли не все, что надо сделать, а значит зарплата платится просто так, и вполне можно выполнить за счет прозябающего со скуки человека какие либо работы.
На самом деле это не так. Задача состоит в том, чтобы выжать все, что возможно, из станка 2, при этом рассчитывая, что он будет являться ограничением для цепочки, и производительность надо подстроить под его нужды. Кроме ограничения выпуска (зачем делать больше, чем мы реально можем переработать?), необходимо обеспечить запас на случай поломки станка 1, чтобы работы не останавливались ни в коем случае. Этот запас называется буфером.
Кроме этого, можно повысить производительность станка 2, поставив перед ним контроль качества, для того чтобы он не обрабатывал детали, которые являются заведомо бракованными. Задача состоит в том, чтобы понять, что время работы станка 2 является наиболее ценным, и тратить каждую минуту его работы разумно. Даже в ущерб мнимой разумности работы других станков.
От простого к сложному
Мы рассмотрели с вами одну линию. Теперь давайте представим себе более сложное производство. К примеру, мы выпускаем некое устройство. Хотя… Почему некое. Мы выпускаем пульты для телевизоров. у нас существует линия 1, которая выпускает корпуса с производительностью 1000 штук в час. У нас существует линия, которая выпускает начинку в виде распаянных плат с производительностью 100 штук в час. И у нас существует линия резиновых изделий, выпускающая кнопки с производительностью 1000 штук в час. После этого все детали попадают на сборку и мы получаем заветный пульт от телека — предмет вожделения, если судить по современному фольклору, каждого мужчины.
Первое, что стоит уяснить — производительность (текущая) нашего производства — 100 штук в час. прикручиваем линии 1 и 3 до выпуска 100 изделий в час.
Второе — давайте рассмотрим детальней линию 2. У нас существует процесс нарезки заготовок, который выдает 500 заготовок плат в час, есть станок для травления/мехобработки печатной платы и шелкографии с производительностью 100 плат в час, и есть станок для распайки, который выдает 300 плат в час. Что у нас будет, если все будет работать на 100%? Станок 1 будет работать в полную мощь, пожирая запасы текстолита и выдавая связанные запасы с огромной скоростью (запасы, которые аккумулированны в виде нарезанных заготовок — их уже никуда не деть, они все — ждуть обработки и только). Станок 2 будет пыхтеть на свои 100%, а рабочий станка 3 будет постоянно жаловаться на отсутствие комплектующих. Звиздец.
Первое, что надо сделать — определить процент барака, получаемого на станке 1. Пусть дядя орудует старинным станком, выдавая одну хреновую деталюху на десяток валидных. Значит, нам надо прикрутить мощность станка 1 до 110 в час (лучше ее немного варьировать, чтобы дать возможность обеспечить запас на сутки в случае, если станок 1 будет простаивать.
Далее — необходимо поставить линию контроля качества перед станком 2, которая будет этот брак выявлять. Зачем делать плату на детали, которая уже автоматом является браком?
Затем необходимо скоординировать действия станка 3 так (составить график, etc), чтобы он был загружен на 100% получаемой от станка 2 продукции. Таким образом, мы выжмем все, что у нас имеется из линии 2.
Логично? Да, конечно. Очень все прозрачно и понятно, прям банальности какие то написал. Ну если вы так считаете, то давайте посмотрим что делаем мы.
Ужасаемся вместе.
Рассмотрим разработку сайта. Над проектом работают — дизайнер, верстальщик и программист. Специфика сайта такова, что мы обязаны загрузить верстальщика по самые уши. Причину придумайте сами — куча выпадающих менюшек, специфичных таблиц, — да мало ли что. Я уверен, что многие смогут привести пример подобного проекта. Отдельно коснусь приведенных в проекте сроков и стоймостей — все это является плодом моего воображения, и нисколько не является предметом для обсуждения.
Пока у нас идет разработка концепции дизайна, все идет нормально — старт работ, и вроде как все по плану. После этого начинается проработка страниц сайта. Дизайнер выполняет одну станицу, скажем, за 1 день. верстальщику нужно 3 дня, чтобы выдать html страничку. Программист тратит 1 день, чтобы эту страничку оживить и заполнить данными. Страница дизайнера стоит 2 т.р., страница верстальщика — 4 т.р., страница программиста — 2 т.р. Общее число страниц на проекте — 30.
Думаю, из постановки вопроса станет ясно, к чему я сейчас веду. И вы совершенно правы — когда дизайнер начинает работать над страницами без перебоя — мы уподобились линии 2 из прошлого примера.
Немного поясню. как правило, дизайнер выполняет работы до тех пор, пока они не закончатся. т.е. от начала работ над страницами до их окончания пройдет 30 дней. При этом верстальщик сможет реально обработать за это время только 10 страниц. Т.е. вы заморозили в активах 60 т.р… Мои поздравления.
Почему? Потому что вы рассчитались с дизайнером за работы, выполнение которых необязательно. Время верстки составит 90 дней, из которых в течение 60 дней верстальщик будет разгребать завалы из графики, которые скопились перед ним. Т.е. он является ограничением во всей цепочке операций. Размер буфера через 30 дней, когда дизайнер сдаст работы, будет максимальным (в буфере будет нарезанной графики на 60 дней работы верстальщика и на 60 т.р.).
Теперь представим, что к вам приходит человек с работой на 10 дней. Для выполнения работы нужно потратить 20 т.р. Которых, с учетом того что 60 т.р. заморожено в виде графики, которая сейчас реально не нужна, у вас нет. Клиента мы потеряли.
Кроме этого представим (опять же, наш пример — не более чем выдумка, так что представить можно все что угодно), что дизайнер может слажать с графикой. По причине незнания, или еще какой — не суть важно. Но вполне возможно, что часть картинок, переданных им, могут не подойти. Что случится в этом случае? Верстальщик, столкнувшись с проблемой, завернет графику, потребовав исправлений. Дизайнер, который месяц как уже не вспоминал о проекте, вдруг узнает, что он прислал не то. Верстальщик бросит на полпути сделанную работу, и приступит к следующему этапу. Программист скажет, что «вы и так оборзели, я работаю день через трое, а тут еще и не по тому порядку, по которому договорились». Пока вы получите пакет от дизайнера — пройдет время. Да, время это скомпенсируется тем, что мы создали чудовищных размеров буфер перед верстальщиком, если это, конечно, не завершение работ. Видите ком проблем и нервов, который свалится на вас? Разве не похоже на дядю с его станком резки деталей и решением проблемы?
Действия, которые казались нам такими очевидными, вдруг эту самую очевидность теряют. Нет? Скажите, для вас будет нормальной практикой договориться с дизайнером, что он передает материалы пакетами, каждый из которых оплачивается отдельно? И делает это в течение 3-х мес, а не одного как он рассчитывал? А легко ли будет вам ввести приемку материалов от дизайнера без отвлечения от работы самого верстальщика?
Естественно, вы можете сказать, что мой пример выдуман и слишком упрощен и утрирован. Естественно. Если я начну с самого начала задвигать методологию критической цепи без предварительной подготовки, то, скорее всего, я получу кучу отрицательных отзывов. Так как, по сути дела, хоть реальный проект другой (не такой упрощенный и утрированный), все равно, идеи, озвученные тут, найдут свое отражение и в нем.
Так что я предлагаю Вам подумать о том, насколько описанная мною ситуация и предпринятые меры оправданы (хоть вы и согласились, что в случае со станками оно работает), ну и ожидать следующей публикации. Как я и обещал, в ней будет проанализирован приближенный к реальным проект, и выстроена методика его выполнения.
Спасибо.
Автор: dtcDev
