Внезапно сменил работу
Кажется, буквально только что прогремела моя статья о собеседованиях, феерично завершившаяся попаданием в 2ГИС. Восемь месяцев — чертовски маленький срок. Никогда не занимался «джобхоппингом», так что и сейчас не открывал резюме, не искал работу, готовился к аттестации. Встроился в процессы, накупил корпоративного мерча, подружился с коллегами и стал регулярно ездить в офис (который при мне перенесли в другое здание и расширили). Уже прям ассоциировал себя с 2ГИС.
Но внезапно мне сделали очень заманчивое предложение. Такое, от которого невозможно отказаться. Позвали в расширяющуюся финтех-компанию архитектором на новые продукты. Очень грустно уходить из 2ГИС, но я бы себя не простил, если бы не воспользовался открывшейся возможностью.
Сегодня на теперь уже старом месте работы было exit-интервью. Кстати, хорошая практика — компания обращает внимание на особенности в статистике увольнений. Задавали вопросы о том, что было хорошо, а что можно улучшить.
Вообще впечатления от 2ГИС самые тёплые. Из плюсов я бы выделил развитую корпоративную культуру и приятную атмосферу работы (не в последнюю очередь благодаря коллегам). Я с удовольствием читал внутренний новостной портал, ходил на презентации фич и самопрезентации новичков, участвовал в местных квизах. Прям сильный косяк вышел только с хакатоном, я вам об этом писал, но там скорее всего просто конкретные организаторы лажанули.
Одна из самых крутых киллер-фич 2ГИС, как работодателя — упрощённое взятие выходных и отпусков. По большей части не нужно никаких специальных согласований, если ты внезапно повёз ребёнка к врачу, или сам устал и хочешь денёк отоспаться.
Однако, в других местах отсутствие формализма порождает сложности. В Росатоме, например, процессы движения задач по жизненному циклу были зарегламентированы сильнее: нельзя передать что-то в разработку без аналитики, постановщик задачи сам следит за её статусами, задача целиком переназначается всегда на текущего одного ответственного человека (на стадии разработки на программиста, на стадии тестирования на тестировщика и т.д.). В 2ГИС иногда задачи приходили от бизнеса с необходимостью самостоятельно ходить по людям и уточнять, что на самом деле хотели. Делалось это как бы для экономии на аналитиках, что лично мне кажется большим заблуждением: бизнес таким образом платил за время более дорогого программиста, который ещё и выполнял работу аналитика дольше, потому что специализируется на другом. В итоге то, что казалось экономией, в моём понимании было скорее увеличением расходов и сроков. То же самое касалось, например, архитектуры и техдолга (но это типичная проблема подавляющего большинства бизнесов — техдолг вообще никто не умеет считать и оценивать).
Я бы сказал так: 2ГИС как бы вырос из стартапа и стал практически бигтехом, особенно после покупки Сбером. Если не бигтехом, то энтерпрайзом точно. Но в итоге оставил часть недостатков стартапа (экономия на «второстепенных» вещах, отсутствие регламентов) и получил часть недостатков энтерпрайза (слабое влияние сотрудников на конечный продукт, очень затянутое планирование и согласование новых задач, заметное количество легаси).
С другой стороны в той же мере присутствуют одновременно плюсы стартапа (простые организационные процессы, неформальная атмосфера) и плюсы энтерпрайза (стабильная компания с офисами, конкурентными зарплатами, рыночным белым оформлением, айти брендом и корпоративной культурой).
Если вы дисциплинированы, компетентны и не боитесь некоторых трудностей, то я однозначно готов советовать работу в 2ГИС. Сейчас идёт набор разработчиков на C#, Go, дата-саентистов, присоединяйтесь :) Уровни мидл и сеньор.
#dev@clockstackwheels#life@clockstackwheels
https://www.youtube.com/watch?v=ZgzpdrMUAj0
Выступление на Mеталлообрабатывающем Форуме 2023 в Крокус-Экспо "Управление производством в условиях высокой вариативности".
Коротко: Существующие и широко распространенные, "зашитые" в ERP, MES и APS системы подходы строятся на возможности детального пооперационного планирования, которое в свою очередь основано на предположении о существовании нормативов на каждую операцию. В условиях многономенклатурного, единичного и мелкосерийного производства это не работает. То есть большинство малых и средних производственных предприятий не имеют адекватных инструментов для управления.
Но решение есть, оно основано на подходе ТОС и называется метод "Барабан - Буфер-Канат". В докладе приводятся соответствующие кейсы, реализованные на практике нашей командой.
#управление_производством#барабан_буфер_канат#ббк#dbr
Кейс-задача
Посещал я как-то хорошее предприятие, заявившееся в национальный проект повышения производительности труда. До меня у них был эксперт проекта и отказал им в помощи - "мы не сможем вам помочь, у вас итак все хорошо".
Из беседы выясняется, что действительно все хорошо. Выпускают они товар народного потребления, скажем так. Работают под заказ. Поток завода имеет V тип (одно сырье, много различной продукции на выходе). Ограничение потока – один из оконечных переделов, где собственно и происходит переключение с одной продукции на другую (с одного заказа на другой). Система оплаты труда - везде оклад, только на ограничении - сдельная оплата. Естественно, на последнем переделе много переналадок. Но время на переналадки максимально минимизировано (они прекрасно понимают, что это - потери). Кстати, сама переналадка происходит в автоматическом режиме. Ограничение не простаивает по причине нехватки сырья для работы - для него всегда есть определенный буфер сырья.
Как считаете, есть ли у предприятия возможности для увеличения результативности? Если нет - почему, если есть - в чем они?
#управление_производством
#барабан_буфер_канат
#ббк
#dbr
(продолжение поста)
Теперь необходимо синхронизировать запуск в нашу производственную цепочку сырья (материалов) с работой нашего барабана. Этот механизм (механизм запуска в производство) называется Канат. Не хватает только определиться с незавершенным производством. Сколько именно держать НЗП в потоке? Ровно столько, чтобы наш РОМ никогда не простоял и не больше. Ведь мы помним – производство на самом деле полно неопределенности, вариативности и т.д. Надо защитить РОМ от этой неопределенности. Для этого введем буфер – время от начала производства до его завершения.
А как же планы работ для каждой операции? Да они на самом деле и не нужны. Есть работа перед станком – работай. Нет работы – жди, когда появится работа или пойди помоги другу. Ну а если работа есть, причем есть выбор из нескольких деталей? Тогда делай наиболее приоритетную – ту, буфер которой больше всего уже потреблен (осталось меньшая доля времени до сдачи заказа).
И что в результате получается? У нас появляется гораздо более простой, а значит более выполнимый график работы для РОМ и первого ресурса в потоке и система приоритетов для остальных ресурсов. Это и есть метод Барабан – буфер – канат. Его легко реализовать и его можно использовать на любом производстве, какая бы вариабельность не была. Простота решения в результате дает надежный конечный результат, сокращение производственного цикла и рост прибыли.
А зачем тогда намудрили с детальным планированием, нормами времени? Да это было просто начальное приближение. Наука тогда находилась в таком состоянии, что и это было прорывом. Но вот зачем упорствовать и использовать давно устаревшие исходные предположения в 21 веке, это вопрос. Инерция, понимаешь. Да еще и подкрепленная всякими волшебными словами: ERP, MES. APS. Завораживает.
Вы все еще? Тогда мы идем …
#управление_производством
#барабан_буфер_канат
#ббк
#dbr
Отжившие установки в управлении производством
Что лежит в основе большинства современных программных продуктов для управления производством?
Очень простые допущения.
1. Производственный цикл может быть разделен на простые операции.
2. Длительность операций можно стандартизировать и ввести соответствующие нормы.
3. На основе введенных норм можно составить детальные планы, оптимизирующие использование оборудования.
4. Оборудование и человеческий труд необходимо использовать эффективно. Простой оборудования и людей – это потери.
Допущения эти настолько просты и очевидны, что никому не приходит поставить их под сомнение. Тем более программисту, которому необходимо разработать программный продукт. Более того, эти допущения подтверждены «научным подходом» Фредерика Тейлора. Это он в начале 20 века, обнаружив на промышленных предприятиях бардак, решил применить свой научный подход. То есть разделить производственный цикл на операции, найти способы оптимизации этих операций и ввести соответствующие нормативы для каждого рабочего, выполняющего свою собственную простую операцию. Гениально? Конечно. Для массового производства однотипных изделий.
Прошло больше века. Конечно, массовые производства существуют и там открытие Тейлора вполне себе работает. Но в то же самое время существует большое количество предприятий, в которых:
1. На одних же и тех же станках производится большое количество изделий, имеющих различные операции обработки и различную их последовательность.
2. Многие изделия (если не все) производятся мелкосерийно.
3. Спрос на различные изделия очень изменчив и прогнозируется очень слабо. Держать запасы готовой продукции – очень неразумно.
4. Поддерживать такое огромное количество нормативов накладно и бессмысленно. Все равно не удастся стандартизировать все операции, для всех операторов. К тому же люди все – таки разные!
В таких условиях детальные планы теряют всякий смысл, поскольку их необходимо будет постоянно пересчитывать. Работать по таким детальным планам – мучение.
Кроме того, предположение об эффективном использовании ресурсов на поверку оказывается просто ошибочным. Стремление к эффективности приводит к увеличению партий ( а иногда это невозможно), к увеличению производственного цикла (у всех должен быть запас работы), к увеличению производственного цикла и к неудовлетворению клиента. Но оказывается, все это зря. Эффективность на самом деле – ложная цель. Нам нужна не эффективность, а скорость потока. Именно увеличение скорости потока ведет к увеличению генерации денег. Чем больше в единицу времени мы производим готовой продукции, тем больше мы зарабатываем. А раз мы больше зарабатываем, значит наши затраты становятся более оправданными. То есть мы становимся более эффективными, уходя от стремления к эффективности. Контринтуитивный результат.
Итак, что же делать? Решение предложено Голдраттом: давайте не будем составлять детальные планы для каждой операции. Все равно они сорвутся. Давайте не будем ставить целью эффективное использование всех ресурсов.
Давайте внимательно посмотрим на наш поток и выделим в потоке наиболее загруженный ресурс. А он всегда есть – ресурс с ограниченной мощностью (РОМ) или ограничение потока. Весь наш поток не сможет выпускать в единицу времени больше изделий, чем проходит через ограничение. Так давайте составим график работы именно РОМ и обеспечим, чтобы именно этот ресурс и был максимально использован (назовем такой график барабаном). Другие ресурсы в потоке имеют излишние мощности по отношению к РОМ. И они могут и даже должны некоторое время простаивать! Их нельзя загружать больше, чем РОМ. Мы не должны их эффективно использовать, это вредно!
#управление_производством
#барабан_буфер_канат
#ббк
#dbr
🔓VCs Are Ready To Sell: These Unlocks Could Crash Prices
Tomorrow, VC investors in #JTO will have $12M unlocked, which may impact the price. Major VC unlocks of #ID, #SAGA, #PRCL, and #DBR tokens in March and April could also influence market prices.
📌 Share and Join 🌕@Crypto_Medias