Помимо программирования я увлекаюсь еще несколькими диаметрально противоположными вещами и одно из них - это керамика, а точнее производство форм для отливки фарфоровых изделий. И т.к. я новичок в этом вопросе – я очень много вещей сейчас познаю на собственных ошибках и получаемом опыте. Сегодня утром у меня закончился 24 часовой эксперимент с подготовкой трех болванок для чистовых форм снятых по сырому глиняному макету. И он увы закончился неутешительно для меня. Ибо по сути я потратил сутки впустую и с результатами работать дальше не получится. Это был эксперимент и все в общем-то хорошо полученные данные помогут двигаться дальше, да и пост не про это.
Короче, я попробовал провести несколько параллелей с разработкой и опытом, который мы получаем в первом и втором случае. Мысль, наверное, кому-то покажется банальной, но на самом деле все не так очевидно, как кажется на первый взгляд.
А вот то, что на самом деле очевидно, так это то, что для разных производственных циклов есть разное время пожинания первых результатов. Например в той же разработке, пишешь фронтенд на чем угодно и по сути сразу видишь условно конечный результат прям у себя под пальцами на мониторе, пишешь бекенд и видишь результат промежуточный, но тоже в какой-то степени конечный в виде api или работающих процедур в авто или ручных тестах, а если создаешь мобильное приложение, так вообще по сути сразу можешь залить его к себе на тестовое устройство и пощелкать, как будто это уже финальный результат. Но даже тут есть разные периоды ожидания: фронтенд, если сложный, имеет некоторое время на компиляцию, бекенд требует поднятия СУБДшек, докеров там с еще какими-то тулингами типа веб серверов, кеш слоев и тд. на что уйдет какое-то время Мобилка тоже компилируется не за пару секунд, еще и на устройство копируется. А если вспомнить разработку на сях с гцц и прочими радостями, то там часами компиляция может проходить, а потом еще в довесок все это дело на пзу какое-нибудь надо прошить, после собрать тестовый стенд и только спустя пару часов осознать, что в логике допущена ошибка и все по новой. В общем, время реакции на первый результат запуска может отличаться от пары секунд до нескольких часов. В случае с керамикой, у меня мой "запущенный тест" занял 24 часа и признаюсь честно, у меня нет опыта работы с длинными производственными циклами разработки, когда от действия до результата проходит ну дольше часа наверное. И этот опыт меня сейчас учит многому.
Например:
Важность соблюдения технического процесса.
Мне, как и любому современному человеку пришедшего из мира ИТ в оффлайн хобби, результат хочется сразу и вот прям на блюдечке, но есть вещи, которые делаются в материальном производстве именно так и никак иначе. И это в какой-то мере звучит диковато.. Поэтому, конечно, из-за этого пытаюсь где-то что-то оптимизировать, зная, что все процессы всегда перезаложены и не оптимальны. Ух, сколько мне это сейчас стоит сил и нервов)) В результате пытаюсь перестраиваться и следовать "инструкциям". Хотя справедливости ради, некоторые оптимизации действительно дают результат, но они скорее связаны с заменой материалов на более современные. В ИТ мире есть всегда более одного варианта достижения идентичного результата, но мы не всегда задумываемся над оптимальностью применения того или иного способа, берем просто какой удобнее в моменте.
Или вот еще крайне полезный выученный урок:
Своевременность действий.
Я привык, что в ИТ многие вещи можно доделать или даже переделать почти в любой момент. Но в керамике - это не возможно от слова совсем. Ошибся или не сделал чего-то в нужное время - брак. Не сдул пылинки-волосинки с макета формы перед заливкой - получи артефакты на форме и выкинь её в помойку. Вспоминая всякие блю-грин канареечные деплойменты и откаты релизов конечно сидишь расстроенный у испорченных гипсовых форм. =)
Не привычно это все очень, но начинаешь в какой-то момент задумываться, – а как эти практики можно было бы применить в разработке и стало бы лучше?
Ответ конечно на поверхности и конечно можно применять. В общем-то почти все наши практики строились поверх знания мира материально. Но с получением прикладного опыта с оффлайн производством, я даже как-то совершенно по другому стал понимать значение термина "Мура" (это неравномерность выполнения работы по японски) в бережливом производстве и канбан методе.
Увы, несмотря на все гибкие методологии и практики связанные с применением разных там фреймворков и методов в ИТ, суть их применения в большинстве компаний, какие мне довелось воочию увидеть или пощупать - это повышение частотности вносимых изменений и снижения затрат на одну итерацию. Но пользуясь многими продуктами созданными по этой "сути", даримый мне ими опыт заставляет задумываться о необходимости смещения акцента в сторону повышения контроля за качеством выпускаемой итерации, возможно даже в ущерб скорости. Но это не будет коррелировать с целями бизнеса и безмерно раздутыми бюджетами ИТ компаний.
И вот в общем-то мысля – если материальное производство начинает жертвовать качеством в угоду снижения себестоимости, то получается брак и ширпотреб. А если мы жертвуем в нематериальном производстве этими же вещами что получается?
Правильно – нематериальный ширпотреб.
----
Живите теперь с этой мыслю, а я пойду заново заливать формы ибо отрицательный результат – тоже результат. =)